Network Working Group                       D Harkins, B Korver, D Piper
INTERNET-DRAFT                                           Network Alchemy
draft-harkins-ipsec-ike-crack-00.txt                       October 18, 1999

      IKE Challenge/Response for Authenticated Cryptographic Keys
                  <draft-harkins-ipsec-ike-crack-00.txt>

Status of this Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and working groups.  Note that other groups may also
   distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

Table of Contents

   1.  Abstract......................................................2
   2.  Terms and Definitions.........................................2
   3.  The Protocol..................................................5
   3.1 IKE Challenge/Response Abstract Representation................6
   3.2 IKE Challenge/Response Authentication Failures................6
   4.  Legacy Authentication Method (LAM) Identifiers................7
   4.1 LAM Types.....................................................7
   4.2 LAM Attributes................................................8
   5.  Legacy Authentication Method (LAM) Profiles...................8
   5.1 LAM Profiles: Password........................................9
   5.2 LAM Profiles: One-Time Password...............................10
   5.3 LAM Profiles: Challenge/Response..............................11
   5.4 LAM Profiles: SecurID.........................................14
   5.5 LAM Profile Matrix............................................17
   6.  The IKE Challenge/Response Vendor ID Signature................17
   7.  Security Considerations.......................................18

Harkins, Korver, Piper     Expires in 6 months                  [Page 1]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   Acknowledgments...................................................19
   References........................................................19
   Authors' Address..................................................20

1. Abstract

   This memo describes a new exchange a la [HC98] which provides for
   authentication when one side is using a unidirectional authentication
   technique such as RADIUS, SecurID, or OTP (hereafter referred to, for
   convenience, as "legacy authentication methods").

   The protocol described here is to be used as a "phase 1" exchange
   ([HC98]).  The result of this exchange is a mutually authenticated
   IKE security association ([HC98]).  The keys that result from this SA
   are also mutually authenticated and thereby convey this status to any
   SA's created from it for any other security service, such as IPSec
   [Pip98].

2. Terms and Definitions

2.1 Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [Bra96].

2.2 Exchange Definition

   This exchange is motivated by the use of roaming IPSec-enabled
   clients which use legacy authentication methods for authentication
   instead of using a public key certificate.  Therefore the parties to
   this exchange are a "client" and a "gateway".  The "client" is always
   the initiator of this exchange and is assumed to be coming from an IP
   address that cannot be known to the "gateway" a priori.  This
   assumption, though, is not a requirement.

   The protocol described in this memo is a separate exchange and not
   another authentication method for an existing exchange.  Unlike the
   other exchanges in [HC98] this exchange does not have negotiable
   authentication methods.  All other attributes and their status from
   [HC98] are unaffected.  Unless otherwise overridden by a requirement
   in this memo all requirements in [HC98] exist in this memo.

   The SKEYID state from [HC98] will be authenticated using digital
   signatures so the authentication method negotiated in the [HC98]
   protection suite MUST be one of the digital signature methods from
   [HC98].  The digital signature method offered by the client in his
   protection suite offer MUST be compatible with the public key he will

Harkins, Korver, Piper     Expires in 6 months                  [Page 2]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   be generating and using in this exchange.

   This exchange will use the value 240 (see Section 6).

2.3 New Payloads

   This exchange requires two new payloads to carry new information
   unique to this exchange.  These are a "Raw Public Key Payload" used
   to carry an unauthenticated public key; and a Challenge/Response
   payload used to convey a challenge from the gateway to the client and
   used by the client to respond to a challenge from the gateway.  The
   Challenge/Response payload contains attributes denoting specific
   information conveyed from the client to the gateway and back.  The
   actual legacy authentication method will determine the specific
   contents of this payload.

   Each of these payloads consists of the ISAKMP generic header
   ([MSST98]) and a payload-specific body whose length is not fixed.
   The "Payload Length" in the generic header includes the length of the
   header itself.  All fields labeled "RESERVED" MUST be filled with
   zero prior to sending and each party to the exchange MUST verify that
   value on all payloads it is sent.

2.3.1 The Raw Public Key Payload (PK)

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !   RESERVED    !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       raw public key                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The payload type for this payload is 128 (see Section 6).  The body
   of this payload will contain a public key of the type used by the
   authentication method negotiated in the first exchange of messages
   (in the SA payload).

   The raw public key is in the form of SubjectPublicKeyInfo [RFC2459]
   and MUST be DER encoded.

Harkins, Korver, Piper     Expires in 6 months                  [Page 3]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

2.3.2 The Challenge/Response Payload (CHRE)

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !   RESERVED    !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !           LAM Type            !           RESERVED            !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~              generic challenge/response blob                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The payload type for this payload is 129 (see Section 6).  The body
   of this payload may also contain attributes used to convey
   authentication information (see Section 4.2).

   The LAM Type field denotes the legacy authentication method (see
   Section 5) associated with the exchange.  The LAM Type must be set in
   all CHRE payloads in an exchange.  The LAM Type is selected by the
   initiator (client) and MUST be set to the same value throughout the
   exchange.

2.3 Notation

   The notation of this memo is similar to [HC98].  Like [HC98] it uses
   payloads defined in [MSST98].  The notation for the new payloads is:

   CHRE is the "challenge/response payload".

   PK is the "raw public key payload".

   To prevent confusion (e.g. g^g for the Diffie-Hellman public value of
   the gateway) the client's payloads are denoted with "i", as it is the
   initiator, and the gateway's payloads are denoted with "r", as it is
   the responder.

   The number of messages in this protocol is dictated by the type of
   legacy authentication method employed.  Depending on the method a
   message could be one of two possible outcomes.  This choice in
   denoted by < opt1 | opt2>.  For instance, if the gateway may respond
   with either a Signature payload or a Challenge/Response payload this
   is denoted < SIG | CHRE >.

Harkins, Korver, Piper     Expires in 6 months                  [Page 4]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

3. The Protocol

   This protocol uses digital signatures to bind each party to the
   exchange as well as to the secret keying material that results from
   the exchange.  The signatures are verified because the peers trust
   each other's public keys.  This trust is acquired differently for the
   client and the gateway.  The client trusts the gateway's public key
   either because it came from a certificate which is signed by a
   trusted certification authority or because the client trusts it by
   some out-of-band mechanism (for instance it is loaded into his policy
   store prior to embarking on his voyage).  The gateway trusts the
   client's public key because the client has successfully authenticated
   himself and his public key using a legacy authentication method and
   can further prove possession of the corresponding private key.

   The reader should note that the channel in which the client's public
   key is transmitted is secure from a man-in-the-middle attack due to
   the fact that the gateway's Diffie-Hellman public value is signed.
   In the case of [RSA], the signature is a [PKCS1] private key
   encryption (see [HC98]) of a hash, using the negotiated hash
   algorithm from the SA payloads, of the Diffie-Hellman public value.
   In the case of [DSS], the signature is a standard FIPS-186 signature
   of the Diffie-Hellman value.  In either case, the data to sign
   includes any padding pre-pended to the body of the payload (for
   alignment to the length of the prime modulus) but does not include
   the ISAKMP header.  The client MUST verify the signature on this
   value.  If the signature is not valid the exchange MUST be
   terminated.

   The "SKEYID*" secret state is generated according to the rules for
   digital signature authentication of [HC98]. In other words.

      SKEYID = prf(Ni_b | Nr_b, g^xy)
      SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
      SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
      SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

   First, we describe the protocol abstractly using the aforementioned
   notation and then separate profiles are given for each of the defined
   LAM types.

Harkins, Korver, Piper     Expires in 6 months                  [Page 5]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

3.1 IKE Challenge/Response Abstract Representation

   The IKE Challenge/Response protocol is defined as follows:

   Client (I)                     Gateway (R)
  -----------                     -----------
   HDR, SAi, KEi, Ni
     [, CERTREQ]          --->
                          <---     HDR, SAr, [CERT, ] KEr,
                                   SIG1, Nr
   HDR*, CHRE, PK         --->
                          <---     HDR*, < SIG2 | CHRE >
   HDR*, < SIG3 | CHRE >  --->

   Where SIG1 is a digital signature of KEr using the gateway's private
   key (any ambiguity about which key was used can be dispelled by
   optionally sending a certificate payload which indicates the public
   key used to verify the signature).  SIG2 and SIG3 are digital
   signatures, using the gateway's private key and the client's private
   key respectively, over an authenticating digest.  This digest is the
   prf output (see [HC98]) using SKEYID_a as a key and a hash (using the
   negotiated hash function) of all packets sent in the protocol, not
   including the current exchange, excluding retransmissions, and prior
   to encryption (or after decryption), when applicable.

   Note that the number of messages in the exchange is not fixed.  The
   gateway can respond with any number of challenges (CHRE payloads) to
   which the client responds with responses (also CHRE payloads).  When
   the gateway has concluded authenticating the client (i.e., when it is
   ready to accept the client's public key), it responds with SIG2.
   When the gateway returns a SIG payload, the client MUST conclude the
   protocol in his next response by return his corresponding SIG
   payload.

   Since this protocol is open-ended, a host implementation may wish to
   limit the number of CHRE round-trips using locally defined policy.

3.2 IKE Challenge/Response Authentication Failures

   If the contents of the (possibly multiple) CHRE payload(s) that the
   client sends fail to satisfy the legacy authentication method the
   gateway MUST respond with an ISAKMP Notify payload (AUTHENTICATION-
   FAILED) [MSST98].

Harkins, Korver, Piper     Expires in 6 months                  [Page 6]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   The Notification Payload MUST have the following format:

     o  Payload length - set to the value 36
     o  DOI - set to the value zero (0) (ISAKMP)
     o  Protocol ID - set to the value one (1) (PROTO_ISAKMP)
     o  SPI Size - set to the value 16
     o  Notify Message Type - set to the value 24
     o  SPI - set to the ISAKMP initiator and responder cookies

   with the following "Notification Data":

     o  LAM Type (two octets) - set to the LAM Type the server requires
        for the client; MAY be different than the LAM Type specified in
        any CHRE payloads if the server required a different LAM Type
        than what was offered
     o  RESERVED (two octets) - MUST be zero (0) (alignment)
     o  Status (four octets) - authentication failure status (private to
        the implementation); SHOULD be omitted when unused

   Due to the nature of this protocol, that notify payload can only
   occur once the secure channel has been established and the client can
   be assured of the authenticity of it.  The client MUST terminate the
   exchange upon receipt of such a notify payload.

4. Legacy Authentication Method (LAM) Identifiers

4.1 LAM Types

   Different legacy authentication methods are denoted by a unique LAM
   type identifier in the Challenge/Response payloads.  The legacy
   authentication methods supported by this protocol are as follows:

   Legacy Authentication Method           Value
   -----------------------------       -----------
   CRACK_PASSWORD                           1
   CRACK_OTP                                2
   CRACK_CHALLENGE_RESPONSE                 3
   CRACK_SECURID                            4
   <reserved>                            5-32767
   <private use>                       32768-65535

   CRACK_PASSWORD specifies a simple username/password mechanism.  It's
   used for any simple host-based password check mechanism.  It also
   useful for proxy-based password authentication schemes, like TACACS
   and RADIUS.

   CRACK_OTP specifies that a one-time password mechanism.  It's useful
   for the S/KEY [Hal95] and OTP [HM96] schemes.

Harkins, Korver, Piper     Expires in 6 months                  [Page 7]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   CRACK_CHALLENGE_RESPONSE specifies a token-based challenge/response
   mechanism.  It's useful for a wide variety of cryptographic tokens,
   typically based on DES.

   CRACK_SECURID specifies a SecurID mechanism.  It's useful for the RSA
   SecurID system.  The CRACK_SECURID closely resembles
   CRACK_CHALLENGE_RESPONSE.

4.2 LAM Attributes

   The Challenge/Response payload contains attributes used to convey
   information between the client and the gateway used to authenticate
   the client.  These are standard [MSST98] attribute payloads
   associated with the Challenge/Response payload.  The following LAM
   attributes are valid, see section 6:

   Attribute            Value            Type
   ----------          -------          ------
   CRACK_USERNAME       16384          variable
   CRACK_DOMAIN         16385          variable
   CRACK_PIN            16386          variable
   CRACK_MESSAGE        16387          variable

   CRACK_USERNAME specifies the client user identity that's requesting
   authentication.  The syntax and format of CRACK_USERNAME is specific
   to each LAM type.

   CRACK_DOMAIN specifies the domain or realm the client is requesting
   authentication credentials within.  The syntax and format of
   CRACK_DOMAIN is specific to each LAM type.

   CRACK_PIN specifies the client's PIN.  The syntax and format of
   CRACK_PIN is specific to each LAM type.

   CRACK_MESSAGE specifies an ASCII string to be displayed to the user
   upon receipt of the corresponding CHRE payload.  CRACK_MESSAGE is
   valid for all LAM types.  Upon receipt, the contents of
   CRACK_MESSAGES SHOULD be displayed to the client user, typically
   along with the CHRE challenge.

5. Legacy Authentication Method (LAM) Profiles

   Each defined LAM type uses the CHRE payload and LAM attributes in a
   different manner.  This section profiles the acceptable use of each
   for the defined LAM types and details the list of acceptable
   attributes for each profile.

   The Challenge/Response profile examples include the exchange of

Harkins, Korver, Piper     Expires in 6 months                  [Page 8]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   CERTREQ and CERT payloads which may be used when the client does not
   have access to the server's public-key or has access to multiple
   server keys.  In other examples, the CERTREQ and CERT payloads are
   omitted for simplicity, but these MAY be used with any of the defined
   profiles.  When used, the corresponding SIG payloads MUST contain any
   CERTREQ or CERT payloads that were exchanged.

5.1 LAM Profiles: Password

   The Password profile supports legacy operating system (OS)
   authentication along with proxy-based password authentication
   protocols, like RADUIS.

   It is assumed in this example that the client has the gateway's
   public key, either through a certificate or a trusted raw public key,
   prior to initiation of the exchange.

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR1, SAi, KEi, Ni     --->
                          <---     HDR2, SAr, KEr,
                                     SIG1, Nr
   HDR3*, CHRE1, PK       --->
                          <---     HDR4*, SIG2
   HDR5*, SIG3            --->

   Where the digest that is signed (resulting in SIG2 and SIG3) is:

   digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
                KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
                [ | HDR4 | SIG2 ]))

For Password, the CHRE payload is used as follows:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR3*, CHRE1, PK       --->

   The CHRE1 payload contains the client's password.  The format
   of the client password is dictated by the corresponding host
   OS or proxy authentication server and may be either plaintext
   or binary.

The following attributes are defined for Password:

  CRACK_USERNAME

    CRACK_USERNAME is sent in the client's second message and MUST

Harkins, Korver, Piper     Expires in 6 months                  [Page 9]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

    contain the client's username which is used as an index key by
    the host OS or proxy password authentication server.

  CRACK_DOMAIN

    CRACK_DOMAIN is sent in the client's second message and MAY be
    used to specify the authentication domain that the client is
    requesting authentication within.

5.2 LAM Profiles: One-Time Password

   The OTP profile supports both the S/KEY and OTP one-time password
   schemes.

   It is assumed in this example that the client has the gateway's
   public key, either through a certificate or a trusted raw public key,
   prior to initiation of the exchange.

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR1, SAi, KEi, Ni     --->
                          <---     HDR2, SAr, KEr,
                                     SIG1, Nr
   HDR3*, CHRE1, PK       --->
                          <---     HDR4*, CHRE2
   HDR5*, CHRE3           --->
                          <---     HDR6*, SIG2
   HDR7*, SIG3            --->

   Where the digest that is signed (resulting in SIG2 and SIG3) is:

   digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
                KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | HDR4 |
                CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ]))

Harkins, Korver, Piper     Expires in 6 months          [Page 10]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

For OTP, the CHRE payload is used as follows:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR3*, CHRE1, PK       --->

   The CHRE1 payload is always empty and contains only any
   associated attributes.

                          <---     HDR4*, CHRE2

   The CHRE2 payload contains the OTP server's challenge
   text which MUST be displayed to the client user.

   HDR5*, CHRE3           --->

   The CHRE3 payload contains the client's one-time password
   response.

The following attributes are defined for OTP:

  CRACK_USERNAME

    CRACK_USERNAME is sent in the client's second message and MUST
    contain the client's username which is used as an index key by
    the OTP server.

  CRACK_MESSAGE

    CRACK_MESSAGE is optionally sent in any server message and MAY
    by used by the server to provide optional text to be displayed
    to the user along with any associated challenge text.

5.3 LAM Profiles: Challenge/Response

   The Challenge/Response profile supports various token cards that
   follow a standard challenge/response exchange.  The client's token
   card information (the response) depends on the gateway's request (the
   challenge).

   It is assumed in this example that the client does not have the
   gateway's public key and requires a certificate issued by a trusted
   Certification Authority.  Note that in this case, identity protection
   of the gateway is lost.  Whether a certificate is requested and sent
   or not, the client's identity is never open to a passive attack (i.e.
   the client retains identity protection regardless).

Harkins, Korver, Piper     Expires in 6 months          [Page 11]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   The following example shows an exchange where a full
   challenge/response exchange is followed:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR1, SAi, KEi, Ni,
     CERTREQ              --->
                          <---     HDR2, SAr, CERT, KEr,
                                     SIG1, Nr
   HDR3*, CHRE1, PK       --->
                          <---     HDR4*, CHRE2
   HDR5*, CHRE3           --->
                          <---     HDR6*, SIG2
   HDR7*, SIG3            --->

   Where the digest that is signed (resulting in SIG2 and SIG3) is:

   digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | CERTREQ | HDR2 |
                SAr | CERT | KEr | SIG1 | Nr | HDR3 | CHRE1 | PK |
                HDR4 | CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ]))

   If more challenges were required to authenticate this client, message
   six would be another CHRE payload and not a SIG payload.  This would
   force message seven to be another CHRE payload.  This can be repeated
   until the gateway authenticates the client (or authentication fails,
   see below).  If this was the case, messages six and seven would be
   different and the exchange would be more than seven messages.  The
   authenticating digest would therefore be correspondingly different.

   Alternatively, some challenge-response tokens cache their last
   computed result and do not require a challenge from the gateway
   unless they get out of sync (perhaps due to intrusion detection).  In
   this case, the gateway may be able to authenticate the client in the
   second message and would return, assuming success, SIG2 instead of
   CHRE2.  The authenticating digest would therefore be correspondingly
   different.

Harkins, Korver, Piper     Expires in 6 months          [Page 12]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   The following example shows an exchange where the client can pre-
   compute his expected response:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR1, SAi, KEi, Ni,
     CERTREQ              --->
                          <---     HDR2, SAr, CERT, KEr,
                                     SIG1, Nr
   HDR3*, CHRE1, PK       --->
                          <---     HDR4*, SIG2
   HDR5*, SIG3            --->

   Where the digest that is signed (resulting in SIG2 and SIG3) is:

   digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | CERTREQ | HDR2 |
                SAr | CERT | KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
                [ | HDR4 | SIG2 ]))

For Challenge/Response, the CHRE payload is used as follows:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR3*, CHRE1, PK       --->

     When the client is using a token that can compute the
     next expected response without requiring a challenge,
     the CHRE1 payload contains the expected response and
     any associated attributes.  When the client does not
     have an expected response, or has chosen not to use
     the current one for whatever reason, the CHRE payload
     is empty and contains only any associated attributes.

                          <---     HDR4*, CHRE2

     The CHRE2 payload contains the gateway's challenge
     text which MUST be displayed to the client user.

   HDR5*, CHRE3           --->

     The CHRE3 payload, when used, contains the client's
     response to the gateway challenge.

The following attributes are defined for Challenge/Response:

  CRACK_USERNAME

    CRACK_USERNAME is sent in the client's second message and MUST

Harkins, Korver, Piper     Expires in 6 months          [Page 13]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

    contain the client's username which is used as an index key for
    authentication by the server.

  CRACK_PIN

    CRACK_PIN is optionally sent in any client message and MAY by
    used if the authentication protocol also requires the client
    to provide a PIN.

  CRACK_MESSAGE

    CRACK_MESSAGE is optionally sent in any server message and MAY
    by used by the server to provide optional text to be displayed
    to the user along with any associated challenge text.

5.4 LAM Profiles: SecurID

   The SecurID profile supports the RSA SecurID protocol.  With SecurID
   the client will be passing the output of the SecurID card as the body
   of the first CHRE payload (in the second message it sends), and its
   identity in the body of the IDi payload. Assuming the client and
   gateway are in sync (i.e. they are not in "Next Code" mode) there is
   a single CHRE payload.

   It is assumed in this example that the client has the gateway's
   public key, either through a certificate or a trusted raw public key,
   prior to initiation of the exchange.

Harkins, Korver, Piper     Expires in 6 months          [Page 14]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   The following example shows a typical SecurID authentication:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR1, SAi, KEi, Ni     --->
                          <---     HDR2, SAr, KEr,
                                     SIG1, Nr
   HDR3*, CHRE1, PK       --->
                          <---     HDR4*, SIG2
   HDR5*, SIG3            --->

   Where the digest that is signed (resulting in SIG2 and SIG3) is:

   digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
                KEr | SIG1 | Nr | HDR3 | CHRE1 | PK
                [ | HDR4 | SIG2 ]))

   If the client and gateway are slightly out of sync (i.e. "Next Code"
   mode) the gateway will respond with an additional challenge to which
   the client must respond with another CHRE payload.  Because there are
   multiple CHRE payloads in this example the first is denoted CHRE1,
   the second CHRE2, etc.  Because "Next Code" requires additional
   messages to be sent, the authenticating hash will be different than
   when the client and gateway are in sync (hopefully this is obvious).

   The following example shows a SecurID authentication when "Next Code"
   mode is required:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR1, SAi, KEi, Ni     --->
                          <---     HDR2, SAr, KEr,
                                     SIG1, Nr
   HDR3*, CHRE1, PK       --->
                          <---     HDR4*, CHRE2
   HDR5*, CHRE3           --->
                          <---     HDR6*, SIG2
   HDR7*, SIG3            --->

   Where the digest that is signed (resulting in SIG2 and SIG3) is:

   digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr |
                KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | HDR4 |
                CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ]))

Harkins, Korver, Piper     Expires in 6 months          [Page 15]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

For SecurID, the CHRE payload is used as follows:

    Client (I)                     Gateway (R)
   -----------                     -----------
   HDR3*, CHRE1, PK       --->

   The CHRE1 payload contains the current Passcode displayed
   by the client's SecurID token.

                          <---     HDR4*, CHRE2

   The CHRE2 payload, when used, signifies the ACE server is
   requesting a "Next Code" response.  The CHRE2 payload is
   always empty and contains only any associated attributes.

   HDR5*, CHRE3           --->

   The CHRE3 payload, when used, contains the client's next
   Passcode displayed by the client's SecurID token.

The following attributes are defined for SecurID:

  CRACK_USERNAME

    CRACK_USERNAME is sent in the client's second message and MUST
    contain the client's username which is used as an index key by
    the ACE server.

  CRACK_PIN

    CRACK_PIN is sent in the client's second message and MAY be
    used when the SecurID card is not a PINPAD card.

  CRACK_MESSAGE

    CRACK_MESSAGE is optionally sent in any server message and MAY
    by used by the server to provide optional text to be displayed
    to the user along with any associated challenge text.

Harkins, Korver, Piper     Expires in 6 months          [Page 16]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

5.5 LAM Profile Matrix

   Each of the LAM's supported by IKE Challenge/Response fall into one
   of the defined LAM profiles.  This section details the classification
   for those methods, including all of the types defined for the
   experimental XAUTH protocol [PB99].

  Password
    DIAMETER
    LDAP
    NDS (Netware Directory Services)
    NT Domain
    RADIUS
    TACACS
    TACACS+
    UNIX Login

  OTP
    OTP
    S/KEY

  Challenge/Response
    AXENT Defender
    CheckPoint ActivCard
    CRYPTOCard CRYPTOCard
    Digital Pathways SNK
    LeeMah InfoCard
    Secure Computing SafeWord (Enigma Logic DES Gold)

  SecurID
    RSA SecurID

6. The IKE Challenge/Response Vendor ID Signature

   This memo describes a protocol that lives on top of [MSST98] and as a
   companion to [HC98].  These standards-track protocols reserve some of
   their "magic number" space for private use by mutually consenting
   parties.  It is from this number space that this memo obtains some of
   the "magic numbers" it needs (payload types, exchange value,
   attributes).  As part of the "mutually consenting parties" part of
   the requirement implementors of this protocol are encouraged to use a
   Vendor ID payload to announce willingness to engage in this protocol.
   The contents of the Vendor ID payload will be the following
   hexadecimal string: 0x0d33611a5d521b5e3c9c03d2fc107e12, which is the
   result of an MD5 hash of "IKE Challenge/Response for Authenticated
   Cryptographic Keys" without the quotation marks. An [HC98]
   implementation that implements this protocol that obtains a Vendor ID
   payload with this string in the body of the payload can assume that

Harkins, Korver, Piper     Expires in 6 months          [Page 17]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   the sender of the Vendor ID payload has likewise implemented this
   protocol and is therefore a "mutually consenting party".

   If this protocol is advanced to standards-track status IANA will
   assign new "magic numbers" out of the appropriate number spaces (the
   "magic numbers" will no longer be from the private use ranges) and
   the requirement to use a Vendor ID payload will go away.

7. Security Considerations

   The channel that results from the exchange of the first two messages
   is secured because the gateway signs his Diffie-Hellman public value
   and it is the resulting SKEYID state (see [HC98]) that protects the
   channel.  The client, though, does not sign his Diffie-Hellman public
   value as this would be a Chicken-and-Egg problem.  The channel is
   secured from the client's perspective because he knows that the
   gateway was the actual source of the Diffie-Hellman public value.
   The channel is secured from the gateway's perspective because the
   client would not have sent his sensitive information if a man-in-the-
   middle was detected.

   While this seems to be a weak form of assurance, the exchange could
   only be foiled by an intentionally malfunctioning client and if that
   is the case then all bets are off regardless of the method of
   authentication.  (If Alice and Bob establish IPSec SA's in the
   traditional fashion, using a [HC98] exchange nothing could stop Alice
   from sending all the sensitive information Bob conveys to her to
   Eve.)  Also note that this technique is used in other popular on-line
   certificate enrollment schemes ([MLSW99]).

   This subtle authentication technique is only used to validate the
   client's public key.  The SKEYID state which will be used to
   establish subsequent security associations for other security
   services (such as those from [Pip98]) is authenticated in the same
   fashion as the other digital signature methods from [HC98].

   As noted, this whole scheme can fail if the client is intentionally
   malicious.  Also, if the token card and knowledge of how to generate
   valid credentials is conveyed to a third party this scheme would fail
   (but not due to any protocol failure).

   The public key that the client authenticates using his legacy
   authentication method and the corresponding private key used to
   authenticate the SKEYID state SHOULD be freshly generated immediately
   prior to use and SHOULD only be used once.

   If the client does not have the gateway's public key prior to
   initiation of the protocol the identity of the gateway can be

Harkins, Korver, Piper     Expires in 6 months          [Page 18]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

   obtained with a passive attack.

Acknowledgments

   The authors would like to thank the sales and marketing staff of all
   companies who said, "Just give us something that uses token cards!"
   We would like to recognize Roy Pereira and Stephane Beaulieu, authors
   of [PB99], which was borrowed from liberally in creation of this
   memo.  Thanks also to Lambert.  He's not like all the other sheep.

References

   [Bra96]   Bradner, S., "The Internet Standards Process --
             Revision 3", BCP 9, RFC 2026, October 1996.

   [CR98]    P. Calhoun, A. Rubens, "DIAMETER - Base Protocol",
             draft-calhoun-diameter-02.txt, March 1998, a work in
             progress.

   [DSS]     National Institute of Standards and Technology, U.S.
             Department of Commerce, "Digital Signature Standard",
             FIPS 186, May 1994.

   [Hal95]   N. Haller, "The S/KEY One-Time Password System", RFC1760,
             February 1995.

   [HC98]    D. Harkins, D. Carrel, "The Internet Key Exchange",
             RFC2409, November 1998.

   [HM96]    N. Haller, C. Metz, "A One-Time Password System", RFC1938,
             May 1996.

   [MLSW99]  M. Myers, X. Liu, J. Schaad, and J. Weinstein, "Certificate
             Management Messages over CMS", draft-ietf-pkix-cmc-05.txt,
             a work in progress.

   [MSST98]  D. Maughan, M. Schertler, M. Schneider, J. Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC2408, November 1998.

   [PB99]    R. Pereira, S. Beaulieu, "Extended Authentication within
             ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt,
             September, 1999, a work in progress.

   [Pip98]   Piper, D., "The Internet IP Security Domain Of
             Interpretation for ISAKMP", RFC 2407, November 1998.

   [PKCS1]   B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography

Harkins, Korver, Piper     Expires in 6 months          [Page 19]


INTERNET DRAFT           IKE Challenge/Response         October 18, 1999

             Specifications Version 2", September 1998.

   [RASW97]  C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
             Authentication Dial In User Service (RADIUS)", RFC2138,
             April 1997.

   [RSA]     R. Rivest, A. Shamir, and L. Adleman, "A Method for
             Obtaining Digital Signatures and Public-Key Cryptosystems",
             Communications of the ACM, v. 21, n. 2, February 1978.

Authors' Address

  Dan Harkins <dharkins@network-alchemy.com>
  Brian Korver <briank@network-alchemy.com>
  Derrell Piper <ddp@network-alchemy.com>
  Network Alchemy
  1538 Pacific Ave
  Santa Cruz, CA 95060-9311
  United States of America

Harkins, Korver, Piper     Expires in 6 months          [Page 20]