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 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 5-32767 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 Brian Korver Derrell Piper Network Alchemy 1538 Pacific Ave Santa Cruz, CA 95060-9311 United States of America Harkins, Korver, Piper Expires in 6 months [Page 20]