idnits 2.17.1 draft-harkins-ipsec-ike-crack-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([Pip98], [HC98]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '...protection suite MUST be one of the di...' RFC 2119 keyword, line 92: '...tion suite offer MUST be compatible wi...' RFC 2119 keyword, line 112: '...labeled "RESERVED" MUST be filled with...' RFC 2119 keyword, line 113: '...party to the exchange MUST verify that...' RFC 2119 keyword, line 133: '... and MUST be DER encoded....' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 1999) is 8955 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2459' is mentioned on line 132, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Unused Reference: 'CR98' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RASW97' is defined on line 834, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-02 -- Possible downref: Normative reference to a draft: ref. 'CR98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Downref: Normative reference to an Informational RFC: RFC 1760 (ref. 'Hal95') ** Obsolete normative reference: RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1938 (ref. 'HM96') (Obsoleted by RFC 2289) ** Obsolete normative reference: RFC 2408 (ref. 'MSST98') (Obsoleted by RFC 4306) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-isakmp-xauth-05 -- Possible downref: Normative reference to a draft: ref. 'PB99' ** Obsolete normative reference: RFC 2407 (ref. 'Pip98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Obsolete normative reference: RFC 2138 (ref. 'RASW97') (Obsoleted by RFC 2865) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA' Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D Harkins, B Korver, D Piper 2 INTERNET-DRAFT Network Alchemy 3 draft-harkins-ipsec-ike-crack-00.txt October 18, 1999 5 IKE Challenge/Response for Authenticated Cryptographic Keys 6 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and working groups. Note that other groups may also 14 distribute working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Table of Contents 29 1. Abstract......................................................2 30 2. Terms and Definitions.........................................2 31 3. The Protocol..................................................5 32 3.1 IKE Challenge/Response Abstract Representation................6 33 3.2 IKE Challenge/Response Authentication Failures................6 34 4. Legacy Authentication Method (LAM) Identifiers................7 35 4.1 LAM Types.....................................................7 36 4.2 LAM Attributes................................................8 37 5. Legacy Authentication Method (LAM) Profiles...................8 38 5.1 LAM Profiles: Password........................................9 39 5.2 LAM Profiles: One-Time Password...............................10 40 5.3 LAM Profiles: Challenge/Response..............................11 41 5.4 LAM Profiles: SecurID.........................................14 42 5.5 LAM Profile Matrix............................................17 43 6. The IKE Challenge/Response Vendor ID Signature................17 44 7. Security Considerations.......................................18 45 Acknowledgments...................................................19 46 References........................................................19 47 Authors' Address..................................................20 49 1. Abstract 51 This memo describes a new exchange a la [HC98] which provides for 52 authentication when one side is using a unidirectional authentication 53 technique such as RADIUS, SecurID, or OTP (hereafter referred to, for 54 convenience, as "legacy authentication methods"). 56 The protocol described here is to be used as a "phase 1" exchange 57 ([HC98]). The result of this exchange is a mutually authenticated 58 IKE security association ([HC98]). The keys that result from this SA 59 are also mutually authenticated and thereby convey this status to any 60 SA's created from it for any other security service, such as IPSec 61 [Pip98]. 63 2. Terms and Definitions 65 2.1 Requirements Terminology 67 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 68 "MAY" that appear in this document are to be interpreted as described 69 in [Bra96]. 71 2.2 Exchange Definition 73 This exchange is motivated by the use of roaming IPSec-enabled 74 clients which use legacy authentication methods for authentication 75 instead of using a public key certificate. Therefore the parties to 76 this exchange are a "client" and a "gateway". The "client" is always 77 the initiator of this exchange and is assumed to be coming from an IP 78 address that cannot be known to the "gateway" a priori. This 79 assumption, though, is not a requirement. 81 The protocol described in this memo is a separate exchange and not 82 another authentication method for an existing exchange. Unlike the 83 other exchanges in [HC98] this exchange does not have negotiable 84 authentication methods. All other attributes and their status from 85 [HC98] are unaffected. Unless otherwise overridden by a requirement 86 in this memo all requirements in [HC98] exist in this memo. 88 The SKEYID state from [HC98] will be authenticated using digital 89 signatures so the authentication method negotiated in the [HC98] 90 protection suite MUST be one of the digital signature methods from 91 [HC98]. The digital signature method offered by the client in his 92 protection suite offer MUST be compatible with the public key he will 93 be generating and using in this exchange. 95 This exchange will use the value 240 (see Section 6). 97 2.3 New Payloads 99 This exchange requires two new payloads to carry new information 100 unique to this exchange. These are a "Raw Public Key Payload" used 101 to carry an unauthenticated public key; and a Challenge/Response 102 payload used to convey a challenge from the gateway to the client and 103 used by the client to respond to a challenge from the gateway. The 104 Challenge/Response payload contains attributes denoting specific 105 information conveyed from the client to the gateway and back. The 106 actual legacy authentication method will determine the specific 107 contents of this payload. 109 Each of these payloads consists of the ISAKMP generic header 110 ([MSST98]) and a payload-specific body whose length is not fixed. 111 The "Payload Length" in the generic header includes the length of the 112 header itself. All fields labeled "RESERVED" MUST be filled with 113 zero prior to sending and each party to the exchange MUST verify that 114 value on all payloads it is sent. 116 2.3.1 The Raw Public Key Payload (PK) 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 ! Next Payload ! RESERVED ! Payload Length ! 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | | 123 ~ raw public key ~ 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 The payload type for this payload is 128 (see Section 6). The body 128 of this payload will contain a public key of the type used by the 129 authentication method negotiated in the first exchange of messages 130 (in the SA payload). 132 The raw public key is in the form of SubjectPublicKeyInfo [RFC2459] 133 and MUST be DER encoded. 135 2.3.2 The Challenge/Response Payload (CHRE) 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 ! Next Payload ! RESERVED ! Payload Length ! 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 ! LAM Type ! RESERVED ! 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | | 144 ~ generic challenge/response blob ~ 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 The payload type for this payload is 129 (see Section 6). The body 149 of this payload may also contain attributes used to convey 150 authentication information (see Section 4.2). 152 The LAM Type field denotes the legacy authentication method (see 153 Section 5) associated with the exchange. The LAM Type must be set in 154 all CHRE payloads in an exchange. The LAM Type is selected by the 155 initiator (client) and MUST be set to the same value throughout the 156 exchange. 158 2.3 Notation 160 The notation of this memo is similar to [HC98]. Like [HC98] it uses 161 payloads defined in [MSST98]. The notation for the new payloads is: 163 CHRE is the "challenge/response payload". 165 PK is the "raw public key payload". 167 To prevent confusion (e.g. g^g for the Diffie-Hellman public value of 168 the gateway) the client's payloads are denoted with "i", as it is the 169 initiator, and the gateway's payloads are denoted with "r", as it is 170 the responder. 172 The number of messages in this protocol is dictated by the type of 173 legacy authentication method employed. Depending on the method a 174 message could be one of two possible outcomes. This choice in 175 denoted by < opt1 | opt2>. For instance, if the gateway may respond 176 with either a Signature payload or a Challenge/Response payload this 177 is denoted < SIG | CHRE >. 179 3. The Protocol 181 This protocol uses digital signatures to bind each party to the 182 exchange as well as to the secret keying material that results from 183 the exchange. The signatures are verified because the peers trust 184 each other's public keys. This trust is acquired differently for the 185 client and the gateway. The client trusts the gateway's public key 186 either because it came from a certificate which is signed by a 187 trusted certification authority or because the client trusts it by 188 some out-of-band mechanism (for instance it is loaded into his policy 189 store prior to embarking on his voyage). The gateway trusts the 190 client's public key because the client has successfully authenticated 191 himself and his public key using a legacy authentication method and 192 can further prove possession of the corresponding private key. 194 The reader should note that the channel in which the client's public 195 key is transmitted is secure from a man-in-the-middle attack due to 196 the fact that the gateway's Diffie-Hellman public value is signed. 197 In the case of [RSA], the signature is a [PKCS1] private key 198 encryption (see [HC98]) of a hash, using the negotiated hash 199 algorithm from the SA payloads, of the Diffie-Hellman public value. 200 In the case of [DSS], the signature is a standard FIPS-186 signature 201 of the Diffie-Hellman value. In either case, the data to sign 202 includes any padding pre-pended to the body of the payload (for 203 alignment to the length of the prime modulus) but does not include 204 the ISAKMP header. The client MUST verify the signature on this 205 value. If the signature is not valid the exchange MUST be 206 terminated. 208 The "SKEYID*" secret state is generated according to the rules for 209 digital signature authentication of [HC98]. In other words. 211 SKEYID = prf(Ni_b | Nr_b, g^xy) 212 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 213 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) 214 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 216 First, we describe the protocol abstractly using the aforementioned 217 notation and then separate profiles are given for each of the defined 218 LAM types. 220 3.1 IKE Challenge/Response Abstract Representation 222 The IKE Challenge/Response protocol is defined as follows: 224 Client (I) Gateway (R) 225 ----------- ----------- 226 HDR, SAi, KEi, Ni 227 [, CERTREQ] ---> 228 <--- HDR, SAr, [CERT, ] KEr, 229 SIG1, Nr 230 HDR*, CHRE, PK ---> 231 <--- HDR*, < SIG2 | CHRE > 232 HDR*, < SIG3 | CHRE > ---> 234 Where SIG1 is a digital signature of KEr using the gateway's private 235 key (any ambiguity about which key was used can be dispelled by 236 optionally sending a certificate payload which indicates the public 237 key used to verify the signature). SIG2 and SIG3 are digital 238 signatures, using the gateway's private key and the client's private 239 key respectively, over an authenticating digest. This digest is the 240 prf output (see [HC98]) using SKEYID_a as a key and a hash (using the 241 negotiated hash function) of all packets sent in the protocol, not 242 including the current exchange, excluding retransmissions, and prior 243 to encryption (or after decryption), when applicable. 245 Note that the number of messages in the exchange is not fixed. The 246 gateway can respond with any number of challenges (CHRE payloads) to 247 which the client responds with responses (also CHRE payloads). When 248 the gateway has concluded authenticating the client (i.e., when it is 249 ready to accept the client's public key), it responds with SIG2. 250 When the gateway returns a SIG payload, the client MUST conclude the 251 protocol in his next response by return his corresponding SIG 252 payload. 254 Since this protocol is open-ended, a host implementation may wish to 255 limit the number of CHRE round-trips using locally defined policy. 257 3.2 IKE Challenge/Response Authentication Failures 259 If the contents of the (possibly multiple) CHRE payload(s) that the 260 client sends fail to satisfy the legacy authentication method the 261 gateway MUST respond with an ISAKMP Notify payload (AUTHENTICATION- 262 FAILED) [MSST98]. 264 The Notification Payload MUST have the following format: 266 o Payload length - set to the value 36 267 o DOI - set to the value zero (0) (ISAKMP) 268 o Protocol ID - set to the value one (1) (PROTO_ISAKMP) 269 o SPI Size - set to the value 16 270 o Notify Message Type - set to the value 24 271 o SPI - set to the ISAKMP initiator and responder cookies 273 with the following "Notification Data": 275 o LAM Type (two octets) - set to the LAM Type the server requires 276 for the client; MAY be different than the LAM Type specified in 277 any CHRE payloads if the server required a different LAM Type 278 than what was offered 279 o RESERVED (two octets) - MUST be zero (0) (alignment) 280 o Status (four octets) - authentication failure status (private to 281 the implementation); SHOULD be omitted when unused 283 Due to the nature of this protocol, that notify payload can only 284 occur once the secure channel has been established and the client can 285 be assured of the authenticity of it. The client MUST terminate the 286 exchange upon receipt of such a notify payload. 288 4. Legacy Authentication Method (LAM) Identifiers 290 4.1 LAM Types 292 Different legacy authentication methods are denoted by a unique LAM 293 type identifier in the Challenge/Response payloads. The legacy 294 authentication methods supported by this protocol are as follows: 296 Legacy Authentication Method Value 297 ----------------------------- ----------- 298 CRACK_PASSWORD 1 299 CRACK_OTP 2 300 CRACK_CHALLENGE_RESPONSE 3 301 CRACK_SECURID 4 302 5-32767 303 32768-65535 305 CRACK_PASSWORD specifies a simple username/password mechanism. It's 306 used for any simple host-based password check mechanism. It also 307 useful for proxy-based password authentication schemes, like TACACS 308 and RADIUS. 310 CRACK_OTP specifies that a one-time password mechanism. It's useful 311 for the S/KEY [Hal95] and OTP [HM96] schemes. 313 CRACK_CHALLENGE_RESPONSE specifies a token-based challenge/response 314 mechanism. It's useful for a wide variety of cryptographic tokens, 315 typically based on DES. 317 CRACK_SECURID specifies a SecurID mechanism. It's useful for the RSA 318 SecurID system. The CRACK_SECURID closely resembles 319 CRACK_CHALLENGE_RESPONSE. 321 4.2 LAM Attributes 323 The Challenge/Response payload contains attributes used to convey 324 information between the client and the gateway used to authenticate 325 the client. These are standard [MSST98] attribute payloads 326 associated with the Challenge/Response payload. The following LAM 327 attributes are valid, see section 6: 329 Attribute Value Type 330 ---------- ------- ------ 331 CRACK_USERNAME 16384 variable 332 CRACK_DOMAIN 16385 variable 333 CRACK_PIN 16386 variable 334 CRACK_MESSAGE 16387 variable 336 CRACK_USERNAME specifies the client user identity that's requesting 337 authentication. The syntax and format of CRACK_USERNAME is specific 338 to each LAM type. 340 CRACK_DOMAIN specifies the domain or realm the client is requesting 341 authentication credentials within. The syntax and format of 342 CRACK_DOMAIN is specific to each LAM type. 344 CRACK_PIN specifies the client's PIN. The syntax and format of 345 CRACK_PIN is specific to each LAM type. 347 CRACK_MESSAGE specifies an ASCII string to be displayed to the user 348 upon receipt of the corresponding CHRE payload. CRACK_MESSAGE is 349 valid for all LAM types. Upon receipt, the contents of 350 CRACK_MESSAGES SHOULD be displayed to the client user, typically 351 along with the CHRE challenge. 353 5. Legacy Authentication Method (LAM) Profiles 355 Each defined LAM type uses the CHRE payload and LAM attributes in a 356 different manner. This section profiles the acceptable use of each 357 for the defined LAM types and details the list of acceptable 358 attributes for each profile. 360 The Challenge/Response profile examples include the exchange of 361 CERTREQ and CERT payloads which may be used when the client does not 362 have access to the server's public-key or has access to multiple 363 server keys. In other examples, the CERTREQ and CERT payloads are 364 omitted for simplicity, but these MAY be used with any of the defined 365 profiles. When used, the corresponding SIG payloads MUST contain any 366 CERTREQ or CERT payloads that were exchanged. 368 5.1 LAM Profiles: Password 370 The Password profile supports legacy operating system (OS) 371 authentication along with proxy-based password authentication 372 protocols, like RADUIS. 374 It is assumed in this example that the client has the gateway's 375 public key, either through a certificate or a trusted raw public key, 376 prior to initiation of the exchange. 378 Client (I) Gateway (R) 379 ----------- ----------- 380 HDR1, SAi, KEi, Ni ---> 381 <--- HDR2, SAr, KEr, 382 SIG1, Nr 383 HDR3*, CHRE1, PK ---> 384 <--- HDR4*, SIG2 385 HDR5*, SIG3 ---> 387 Where the digest that is signed (resulting in SIG2 and SIG3) is: 389 digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr | 390 KEr | SIG1 | Nr | HDR3 | CHRE1 | PK 391 [ | HDR4 | SIG2 ])) 393 For Password, the CHRE payload is used as follows: 395 Client (I) Gateway (R) 396 ----------- ----------- 397 HDR3*, CHRE1, PK ---> 399 The CHRE1 payload contains the client's password. The format 400 of the client password is dictated by the corresponding host 401 OS or proxy authentication server and may be either plaintext 402 or binary. 404 The following attributes are defined for Password: 406 CRACK_USERNAME 408 CRACK_USERNAME is sent in the client's second message and MUST 409 contain the client's username which is used as an index key by 410 the host OS or proxy password authentication server. 412 CRACK_DOMAIN 414 CRACK_DOMAIN is sent in the client's second message and MAY be 415 used to specify the authentication domain that the client is 416 requesting authentication within. 418 5.2 LAM Profiles: One-Time Password 420 The OTP profile supports both the S/KEY and OTP one-time password 421 schemes. 423 It is assumed in this example that the client has the gateway's 424 public key, either through a certificate or a trusted raw public key, 425 prior to initiation of the exchange. 427 Client (I) Gateway (R) 428 ----------- ----------- 429 HDR1, SAi, KEi, Ni ---> 430 <--- HDR2, SAr, KEr, 431 SIG1, Nr 432 HDR3*, CHRE1, PK ---> 433 <--- HDR4*, CHRE2 434 HDR5*, CHRE3 ---> 435 <--- HDR6*, SIG2 436 HDR7*, SIG3 ---> 438 Where the digest that is signed (resulting in SIG2 and SIG3) is: 440 digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr | 441 KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | HDR4 | 442 CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ])) 444 For OTP, the CHRE payload is used as follows: 446 Client (I) Gateway (R) 447 ----------- ----------- 448 HDR3*, CHRE1, PK ---> 450 The CHRE1 payload is always empty and contains only any 451 associated attributes. 453 <--- HDR4*, CHRE2 455 The CHRE2 payload contains the OTP server's challenge 456 text which MUST be displayed to the client user. 458 HDR5*, CHRE3 ---> 460 The CHRE3 payload contains the client's one-time password 461 response. 463 The following attributes are defined for OTP: 465 CRACK_USERNAME 467 CRACK_USERNAME is sent in the client's second message and MUST 468 contain the client's username which is used as an index key by 469 the OTP server. 471 CRACK_MESSAGE 473 CRACK_MESSAGE is optionally sent in any server message and MAY 474 by used by the server to provide optional text to be displayed 475 to the user along with any associated challenge text. 477 5.3 LAM Profiles: Challenge/Response 479 The Challenge/Response profile supports various token cards that 480 follow a standard challenge/response exchange. The client's token 481 card information (the response) depends on the gateway's request (the 482 challenge). 484 It is assumed in this example that the client does not have the 485 gateway's public key and requires a certificate issued by a trusted 486 Certification Authority. Note that in this case, identity protection 487 of the gateway is lost. Whether a certificate is requested and sent 488 or not, the client's identity is never open to a passive attack (i.e. 489 the client retains identity protection regardless). 491 The following example shows an exchange where a full 492 challenge/response exchange is followed: 494 Client (I) Gateway (R) 495 ----------- ----------- 496 HDR1, SAi, KEi, Ni, 497 CERTREQ ---> 498 <--- HDR2, SAr, CERT, KEr, 499 SIG1, Nr 500 HDR3*, CHRE1, PK ---> 501 <--- HDR4*, CHRE2 502 HDR5*, CHRE3 ---> 503 <--- HDR6*, SIG2 504 HDR7*, SIG3 ---> 506 Where the digest that is signed (resulting in SIG2 and SIG3) is: 508 digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | CERTREQ | HDR2 | 509 SAr | CERT | KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | 510 HDR4 | CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ])) 512 If more challenges were required to authenticate this client, message 513 six would be another CHRE payload and not a SIG payload. This would 514 force message seven to be another CHRE payload. This can be repeated 515 until the gateway authenticates the client (or authentication fails, 516 see below). If this was the case, messages six and seven would be 517 different and the exchange would be more than seven messages. The 518 authenticating digest would therefore be correspondingly different. 520 Alternatively, some challenge-response tokens cache their last 521 computed result and do not require a challenge from the gateway 522 unless they get out of sync (perhaps due to intrusion detection). In 523 this case, the gateway may be able to authenticate the client in the 524 second message and would return, assuming success, SIG2 instead of 525 CHRE2. The authenticating digest would therefore be correspondingly 526 different. 528 The following example shows an exchange where the client can pre- 529 compute his expected response: 531 Client (I) Gateway (R) 532 ----------- ----------- 533 HDR1, SAi, KEi, Ni, 534 CERTREQ ---> 535 <--- HDR2, SAr, CERT, KEr, 536 SIG1, Nr 537 HDR3*, CHRE1, PK ---> 538 <--- HDR4*, SIG2 539 HDR5*, SIG3 ---> 541 Where the digest that is signed (resulting in SIG2 and SIG3) is: 543 digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | CERTREQ | HDR2 | 544 SAr | CERT | KEr | SIG1 | Nr | HDR3 | CHRE1 | PK 545 [ | HDR4 | SIG2 ])) 547 For Challenge/Response, the CHRE payload is used as follows: 549 Client (I) Gateway (R) 550 ----------- ----------- 551 HDR3*, CHRE1, PK ---> 553 When the client is using a token that can compute the 554 next expected response without requiring a challenge, 555 the CHRE1 payload contains the expected response and 556 any associated attributes. When the client does not 557 have an expected response, or has chosen not to use 558 the current one for whatever reason, the CHRE payload 559 is empty and contains only any associated attributes. 561 <--- HDR4*, CHRE2 563 The CHRE2 payload contains the gateway's challenge 564 text which MUST be displayed to the client user. 566 HDR5*, CHRE3 ---> 568 The CHRE3 payload, when used, contains the client's 569 response to the gateway challenge. 571 The following attributes are defined for Challenge/Response: 573 CRACK_USERNAME 575 CRACK_USERNAME is sent in the client's second message and MUST 576 contain the client's username which is used as an index key for 577 authentication by the server. 579 CRACK_PIN 581 CRACK_PIN is optionally sent in any client message and MAY by 582 used if the authentication protocol also requires the client 583 to provide a PIN. 585 CRACK_MESSAGE 587 CRACK_MESSAGE is optionally sent in any server message and MAY 588 by used by the server to provide optional text to be displayed 589 to the user along with any associated challenge text. 591 5.4 LAM Profiles: SecurID 593 The SecurID profile supports the RSA SecurID protocol. With SecurID 594 the client will be passing the output of the SecurID card as the body 595 of the first CHRE payload (in the second message it sends), and its 596 identity in the body of the IDi payload. Assuming the client and 597 gateway are in sync (i.e. they are not in "Next Code" mode) there is 598 a single CHRE payload. 600 It is assumed in this example that the client has the gateway's 601 public key, either through a certificate or a trusted raw public key, 602 prior to initiation of the exchange. 604 The following example shows a typical SecurID authentication: 606 Client (I) Gateway (R) 607 ----------- ----------- 608 HDR1, SAi, KEi, Ni ---> 609 <--- HDR2, SAr, KEr, 610 SIG1, Nr 611 HDR3*, CHRE1, PK ---> 612 <--- HDR4*, SIG2 613 HDR5*, SIG3 ---> 615 Where the digest that is signed (resulting in SIG2 and SIG3) is: 617 digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr | 618 KEr | SIG1 | Nr | HDR3 | CHRE1 | PK 619 [ | HDR4 | SIG2 ])) 621 If the client and gateway are slightly out of sync (i.e. "Next Code" 622 mode) the gateway will respond with an additional challenge to which 623 the client must respond with another CHRE payload. Because there are 624 multiple CHRE payloads in this example the first is denoted CHRE1, 625 the second CHRE2, etc. Because "Next Code" requires additional 626 messages to be sent, the authenticating hash will be different than 627 when the client and gateway are in sync (hopefully this is obvious). 629 The following example shows a SecurID authentication when "Next Code" 630 mode is required: 632 Client (I) Gateway (R) 633 ----------- ----------- 634 HDR1, SAi, KEi, Ni ---> 635 <--- HDR2, SAr, KEr, 636 SIG1, Nr 637 HDR3*, CHRE1, PK ---> 638 <--- HDR4*, CHRE2 639 HDR5*, CHRE3 ---> 640 <--- HDR6*, SIG2 641 HDR7*, SIG3 ---> 643 Where the digest that is signed (resulting in SIG2 and SIG3) is: 645 digest = prf(SKEYID_a, H(HDR1 | SAi | KEi | Ni | HDR2 | SAr | 646 KEr | SIG1 | Nr | HDR3 | CHRE1 | PK | HDR4 | 647 CHRE2 | HDR5 | CHRE3 [ | HDR6 | SIG2 ])) 649 For SecurID, the CHRE payload is used as follows: 651 Client (I) Gateway (R) 652 ----------- ----------- 653 HDR3*, CHRE1, PK ---> 655 The CHRE1 payload contains the current Passcode displayed 656 by the client's SecurID token. 658 <--- HDR4*, CHRE2 660 The CHRE2 payload, when used, signifies the ACE server is 661 requesting a "Next Code" response. The CHRE2 payload is 662 always empty and contains only any associated attributes. 664 HDR5*, CHRE3 ---> 666 The CHRE3 payload, when used, contains the client's next 667 Passcode displayed by the client's SecurID token. 669 The following attributes are defined for SecurID: 671 CRACK_USERNAME 673 CRACK_USERNAME is sent in the client's second message and MUST 674 contain the client's username which is used as an index key by 675 the ACE server. 677 CRACK_PIN 679 CRACK_PIN is sent in the client's second message and MAY be 680 used when the SecurID card is not a PINPAD card. 682 CRACK_MESSAGE 684 CRACK_MESSAGE is optionally sent in any server message and MAY 685 by used by the server to provide optional text to be displayed 686 to the user along with any associated challenge text. 688 5.5 LAM Profile Matrix 690 Each of the LAM's supported by IKE Challenge/Response fall into one 691 of the defined LAM profiles. This section details the classification 692 for those methods, including all of the types defined for the 693 experimental XAUTH protocol [PB99]. 695 Password 696 DIAMETER 697 LDAP 698 NDS (Netware Directory Services) 699 NT Domain 700 RADIUS 701 TACACS 702 TACACS+ 703 UNIX Login 705 OTP 706 OTP 707 S/KEY 709 Challenge/Response 710 AXENT Defender 711 CheckPoint ActivCard 712 CRYPTOCard CRYPTOCard 713 Digital Pathways SNK 714 LeeMah InfoCard 715 Secure Computing SafeWord (Enigma Logic DES Gold) 717 SecurID 718 RSA SecurID 720 6. The IKE Challenge/Response Vendor ID Signature 722 This memo describes a protocol that lives on top of [MSST98] and as a 723 companion to [HC98]. These standards-track protocols reserve some of 724 their "magic number" space for private use by mutually consenting 725 parties. It is from this number space that this memo obtains some of 726 the "magic numbers" it needs (payload types, exchange value, 727 attributes). As part of the "mutually consenting parties" part of 728 the requirement implementors of this protocol are encouraged to use a 729 Vendor ID payload to announce willingness to engage in this protocol. 730 The contents of the Vendor ID payload will be the following 731 hexadecimal string: 0x0d33611a5d521b5e3c9c03d2fc107e12, which is the 732 result of an MD5 hash of "IKE Challenge/Response for Authenticated 733 Cryptographic Keys" without the quotation marks. An [HC98] 734 implementation that implements this protocol that obtains a Vendor ID 735 payload with this string in the body of the payload can assume that 736 the sender of the Vendor ID payload has likewise implemented this 737 protocol and is therefore a "mutually consenting party". 739 If this protocol is advanced to standards-track status IANA will 740 assign new "magic numbers" out of the appropriate number spaces (the 741 "magic numbers" will no longer be from the private use ranges) and 742 the requirement to use a Vendor ID payload will go away. 744 7. Security Considerations 746 The channel that results from the exchange of the first two messages 747 is secured because the gateway signs his Diffie-Hellman public value 748 and it is the resulting SKEYID state (see [HC98]) that protects the 749 channel. The client, though, does not sign his Diffie-Hellman public 750 value as this would be a Chicken-and-Egg problem. The channel is 751 secured from the client's perspective because he knows that the 752 gateway was the actual source of the Diffie-Hellman public value. 753 The channel is secured from the gateway's perspective because the 754 client would not have sent his sensitive information if a man-in-the- 755 middle was detected. 757 While this seems to be a weak form of assurance, the exchange could 758 only be foiled by an intentionally malfunctioning client and if that 759 is the case then all bets are off regardless of the method of 760 authentication. (If Alice and Bob establish IPSec SA's in the 761 traditional fashion, using a [HC98] exchange nothing could stop Alice 762 from sending all the sensitive information Bob conveys to her to 763 Eve.) Also note that this technique is used in other popular on-line 764 certificate enrollment schemes ([MLSW99]). 766 This subtle authentication technique is only used to validate the 767 client's public key. The SKEYID state which will be used to 768 establish subsequent security associations for other security 769 services (such as those from [Pip98]) is authenticated in the same 770 fashion as the other digital signature methods from [HC98]. 772 As noted, this whole scheme can fail if the client is intentionally 773 malicious. Also, if the token card and knowledge of how to generate 774 valid credentials is conveyed to a third party this scheme would fail 775 (but not due to any protocol failure). 777 The public key that the client authenticates using his legacy 778 authentication method and the corresponding private key used to 779 authenticate the SKEYID state SHOULD be freshly generated immediately 780 prior to use and SHOULD only be used once. 782 If the client does not have the gateway's public key prior to 783 initiation of the protocol the identity of the gateway can be 784 obtained with a passive attack. 786 Acknowledgments 788 The authors would like to thank the sales and marketing staff of all 789 companies who said, "Just give us something that uses token cards!" 790 We would like to recognize Roy Pereira and Stephane Beaulieu, authors 791 of [PB99], which was borrowed from liberally in creation of this 792 memo. Thanks also to Lambert. He's not like all the other sheep. 794 References 796 [Bra96] Bradner, S., "The Internet Standards Process -- 797 Revision 3", BCP 9, RFC 2026, October 1996. 799 [CR98] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 800 draft-calhoun-diameter-02.txt, March 1998, a work in 801 progress. 803 [DSS] National Institute of Standards and Technology, U.S. 804 Department of Commerce, "Digital Signature Standard", 805 FIPS 186, May 1994. 807 [Hal95] N. Haller, "The S/KEY One-Time Password System", RFC1760, 808 February 1995. 810 [HC98] D. Harkins, D. Carrel, "The Internet Key Exchange", 811 RFC2409, November 1998. 813 [HM96] N. Haller, C. Metz, "A One-Time Password System", RFC1938, 814 May 1996. 816 [MLSW99] M. Myers, X. Liu, J. Schaad, and J. Weinstein, "Certificate 817 Management Messages over CMS", draft-ietf-pkix-cmc-05.txt, 818 a work in progress. 820 [MSST98] D. Maughan, M. Schertler, M. Schneider, J. Turner, 821 "Internet Security Association and Key Management Protocol 822 (ISAKMP)", RFC2408, November 1998. 824 [PB99] R. Pereira, S. Beaulieu, "Extended Authentication within 825 ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt, 826 September, 1999, a work in progress. 828 [Pip98] Piper, D., "The Internet IP Security Domain Of 829 Interpretation for ISAKMP", RFC 2407, November 1998. 831 [PKCS1] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 832 Specifications Version 2", September 1998. 834 [RASW97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 835 Authentication Dial In User Service (RADIUS)", RFC2138, 836 April 1997. 838 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 839 Obtaining Digital Signatures and Public-Key Cryptosystems", 840 Communications of the ACM, v. 21, n. 2, February 1978. 842 Authors' Address 844 Dan Harkins 845 Brian Korver 846 Derrell Piper 847 Network Alchemy 848 1538 Pacific Ave 849 Santa Cruz, CA 95060-9311 850 United States of America