idnits 2.17.1 draft-harkins-ipsra-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-26) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines 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. ** 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 129: '...beled "RESERVED" MUST be filled with z...' RFC 2119 keyword, line 130: '...party to the exchange MUST verify that...' RFC 2119 keyword, line 152: '...tor (client) and MUST be set in every ...' RFC 2119 keyword, line 171: '...RE payload, the gateway MUST terminate...' RFC 2119 keyword, line 172: '...the exchange and MUST respond with an ...' (34 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 (August 25, 2000) is 8645 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) == Unused Reference: 'CR98' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'PKCS1' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RASW97' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RSA' is defined on line 918, 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC96') ** 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: 17 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D Harkins, D Piper 2 INTERNET-DRAFT Nokia 3 draft-harkins-ipsra-crack-00.txt August 25, 2000 5 IKE Challenge/Response for Authenticated Cryptographic Keys (Revised) 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 To learn the current status of any Internet Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Table of Contents 35 1. Abstract......................................................2 36 2. Terms and Definitions.........................................2 37 2.1 Requirements Terminology and Notation.........................2 38 2.2 IKE Exchange Integration......................................2 39 2.3 IKE Authentication Method Definition..........................3 40 2.4 The Challenge/Response Payload (CHRE).........................3 41 2.5 LAM Types.....................................................4 42 2.6 LAM Attributes................................................5 43 3. The Protocol..................................................6 44 3.1 IKE Challenge/Response Abstract Representation................7 45 3.2 IKE Challenge/Response Failures...............................8 46 4. Legacy Authentication Method (LAM) Profiles...................9 47 4.1 LAM Profiles: Password........................................10 48 4.2 LAM Profiles: One-Time Password...............................11 49 4.3 LAM Profiles: Challenge/Response..............................12 50 4.4 LAM Profiles: SecurID.........................................15 51 4.5 LAM Profile Matrix............................................17 52 5. The IKE Challenge/Response Vendor ID Signature................17 53 6. Security Considerations.......................................18 54 Acknowledgments...................................................18 55 References........................................................18 56 Authors' Address..................................................19 58 1. Abstract 60 This memo describes a new IKE authentication method ([HC98]) which 61 provides for mutual authentication when one side is using a legacy- 62 based secret-key authentication technique such as RADIUS, SecurID, or 63 OTP and the other side is using public-key authentication, with 64 optional digital certificates. 66 The generic protocol described herein is an open-ended IKE phase 1 67 exchange ([HC98]). The result of this exchange is a mutually 68 authenticated IKE security association ([HC98]). The keys that are 69 derived from this SA are also authenticated and thereby convey this 70 state to any SA's created from it for any other security service, 71 such as IPsec [Pip98]. 73 2. Terms and Definitions 75 2.1 Requirements Terminology and Notation 77 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 78 "MAY" that appear in this document are to be interpreted as described 79 in [Bra96]. 81 The notation of this memo is similar to [HC98]. Like [HC98] it uses 82 payloads defined in [MSST98]. The notation for the new payload is: 84 CHRE is the newly defined "challenge/response payload" 86 To prevent confusion in the protocol diagrams (e.g. between the 87 Diffie-Hellman public values), the client's payloads are sometimes 88 post-fixed with "i", for "initiator", and the gateway's payloads are 89 sometimes post-fixed with "r", for "responder". 91 2.2 IKE Exchange Integration 93 This protocol is motivated by mobile IPsec-enabled clients who desire 94 to use legacy authentication techniques instead of digital 95 certificates. Therefore the parties to this exchange are a "client" 96 and a "gateway". The client is always the initiator of this exchange 97 and is assumed to be coming from an IP address that cannot be known a 98 priori by the gateway. 100 The protocol described in this memo is an IKE exchange using a newly 101 defined IKE authentication method. All other attributes and their 102 status from [HC98] are unaffected. Unless otherwise overridden by a 103 specific requirement in this memo, all requirements in [HC98] exist 104 in this memo. 106 2.3 IKE Authentication Method Definition 108 The following new IKE authentication method value is defined for 109 CRACK from the IKE private-use space (see Section 6): 111 Authentication Mode Value 112 ------------------- ----- 113 IKE_A_CRACK 128 115 2.4 The Challenge/Response Payload (CHRE) 117 This draft requires a new payload to carry new information unique to 118 this exchange. The Challenge/Response payload is used to convey a 119 challenge from the gateway to the client and is used by the client to 120 respond to a challenge from the gateway. The Challenge/Response 121 payload contains attributes denoting specific information conveyed 122 from the client to the gateway and back. The actual legacy 123 authentication method will determine the contents of this payload at 124 the various points in the exchange. 126 This payload consists of the ISAKMP generic header ([MSST98]) and a 127 payload-specific body whose length is not fixed. The "Payload 128 Length" in the generic header includes the length of the header 129 itself. All fields labeled "RESERVED" MUST be filled with zero (0) 130 prior to sending and each party to the exchange MUST verify that 131 value on all payloads it is sent. 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 ! Next Payload ! RESERVED ! Payload Length ! 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 ! LAM Type ! RESERVED ! 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | | 140 ~ generic challenge/response blob ~ 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The payload type for this payload is 128, which is taken from the 145 ISAKMP private use space (see Section 6). The body of this payload 146 may also contain attributes used to convey authentication information 147 (see Section 4.2). 149 The LAM Type field denotes the legacy authentication method (see 150 Section 5) associated with the exchange. The LAM Type must be set in 151 all CHRE payloads in an exchange. The LAM Type is selected by the 152 initiator (client) and MUST be set in every CHRE payload to the same 153 value throughout the exchange. 155 2.5 LAM Types 157 Different legacy authentication methods are denoted by unique LAM 158 type identifiers in the Challenge/Response payloads. The legacy 159 authentication methods defined for this protocol are as follows: 161 LAM Type Identifier Value 162 ------------------- ----------- 163 CRACK_PASSWORD 1 164 CRACK_OTP 2 165 CRACK_CHALLENGE_RESPONSE 3 166 CRACK_SECURID 4 167 5-32767 168 32768-65535 170 If the gateway is not configured to support the requested LAM type while 171 processing the client's first CHRE payload, the gateway MUST terminate 172 the exchange and MUST respond with an ISAKMP Notify (PROPOSAL-NOT- 173 CHOSEN). 175 A conformant gateway MUST support at least one of the specified LAM 176 Types. A gateway MAY support more than one LAM Type and it's assumed 177 that the choice of which LAM Types are supported is implementation 178 specific and determined from local policy configuration, perhaps on a 179 per-user basis based on the content of the first CHRE payload and its 180 associated attributes. 182 CRACK_PASSWORD specifies a simple username/password mechanism. It's 183 used for any simple host-based password or one-way hash mechanism. 184 It also useful for proxy-based password authentication schemes, like 185 TACACS and RADIUS. 187 CRACK_OTP specifies that a one-time password mechanism. It's useful 188 for the S/KEY [Hal95] and OTP [HM96] schemes. 190 CRACK_CHALLENGE_RESPONSE specifies a token-based challenge/response 191 mechanism. It's useful for a wide variety of cryptographic tokens, 192 typically based on DES. 194 CRACK_SECURID specifies a SecurID mechanism. It's useful for the RSA 195 SecurID system. The CRACK_SECURID closely resembles 196 CRACK_CHALLENGE_RESPONSE. 198 2.6 LAM Attributes 200 The Challenge/Response payload contains attributes used to convey 201 information between the client and the gateway authenticating the 202 client. These are standard [MSST98] attribute payloads associated 203 with the Challenge/Response payloads. The following LAM attributes 204 are valid: 206 Attribute Value Type 207 ---------- ------- ------ 208 CRACK_T_USERNAME 16390 variable 209 CRACK_T_SECRET 16391 variable 210 CRACK_T_DOMAIN 16392 variable 211 CRACK_T_PIN 16393 variable 212 CRACK_T_CHALLENGE 16394 variable 213 CRACK_T_MESSAGE 16395 variable 214 CRACK_T_FIN 16396 basic 216 CRACK_T_USERNAME specifies the client user identity that's requesting 217 authentication. The syntax and format of CRACK_T_USERNAME is 218 specific to each LAM type. 220 CRACK_T_SECRET specifies secret information the client sends in an 221 attempt to authenticate, for instance a password or passcode. The 222 syntax and format of CRACK_T_SECRET is specific to each LAM type. 224 CRACK_T_DOMAIN specifies the domain or realm the client is requesting 225 authentication credentials within. The syntax and format of 226 CRACK_T_DOMAIN is specific to each LAM type. 228 CRACK_T_PIN specifies the client's PIN. The syntax and format of 229 CRACK_PIN is specific to each LAM type. 231 CRACK_T_CHALLENGE specifies any challenge the gateway may choose to 232 issue to the client. The syntax and format of CRACK_T_CHALLENGE is 233 specific to each LAM type. 235 CRACK_T_MESSAGE specifies an ASCII string to be displayed to the user 236 upon receipt of the corresponding CHRE payload. CRACK_T_MESSAGE is 237 valid for all LAM types. Upon receipt, the contents of 238 CRACK_T_MESSAGES SHOULD be displayed to the client user, typically 239 along with the CHRE challenge. 241 CRACK_T_FIN specifies the server's response to the authentication 242 exchange at all critical decision points specific to each LAM type. 243 The following table defines the values for CRACK_T_FIN: 245 Finish Types Value 246 ------------ ----- 247 RESERVED 0 248 CRACK_FIN_SUCCESS 1 249 CRACK_FIN_MORE 2 251 CRACK_FIN_SUCCESS indicates the gateway has successfully 252 authenticated the client. This value successfully terminates the 253 CRACK exchange. This value is legal for all LAM types. 255 CRACK_FIN_MORE indicates the gateway requires an additional round- 256 trip to authentication the client. This is only legal for LAM 257 types which define its use. It MUST NOT be used unless defined in 258 the corresponding LAM profile. 260 3. The Protocol 262 This protocol uses digital signatures and proof of possession of a 263 legacy secret to bind each party to the exchange as well as to the 264 keying material that results from the exchange. This trust is 265 acquired differently for the client and the gateway. The client 266 trusts the gateway's public key either because it came from a 267 certificate which is signed by a trusted certification authority or 268 because the client trusts it by some out-of-band mechanism (for 269 instance it is loaded into his policy store prior to hitting the 270 road). The gateway trusts the client because the client has 271 successfully authenticated himself using a legacy authentication 272 method through a secure channel. 274 The reader should note that the channel in which the client's legacy 275 proof is transmitted is secure from a man-in-the-middle attack due to 276 the fact that the Diffie-Hellman public values and the attributes 277 from the accepted offer, among other things, are signed. As in 278 [HC98], the signature uses a pseudo-random function (prf), which is 279 either negotiated in the initial SA payload or is the HMAC version 280 [KBC96] of a hash function, over state from the exchange and keyed 281 with "SKEYID". 283 The "SKEYID*" secret state is generated according to the rules for 284 digital signature authentication of [HC98]. In other words. 286 SKEYID = prf(Ni_b | Nr_b, g^xy) 287 SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) 288 SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) 289 SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) 291 The data portion of the pseudo-random function consists of the 292 clients's Diffie-Hellman public value concatenated with the gateway's 293 Diffie-Hellman public value concatenated with the client's cookie 294 (from the [MSST98] header) concatenated with the gateway's cookie 295 concatenated with the body of the client's initial SA offer. 296 Graphically, the signature is over: 298 digest = prf (SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b) 300 Generally the pseudo-random function is the [KBC96] version of the 301 negotiated hash function but this can be overridden if the signature 302 algorithm is tied to a particular hash function (e.g. [DSS]) in which 303 case the pseudo-random function will the the [KBC96] version of the 304 hash function tied to the signature method. 306 The data being signed includes any padding prepended to the body of 307 the payloads (for alignment to the length of the prime modulus) but 308 does not include the ISAKMP header from any payload. The client MUST 309 verify the signature. If the signature is not valid the exchange MUST 310 be terminated by the client. 312 First, we describe the protocol abstractly using the aforementioned 313 notation and then separate profiles are defined for each of the 314 various LAM types. 316 3.1 IKE Challenge/Response Abstract Representation 318 The IKE Challenge/Response protocol is abstractly defined as follows: 320 Main Mode using CRACK is defined as 322 Client (I) Gateway (R) 323 ----------- ----------- 324 HDR, SAi, ---> 325 <--- HDR, SAr 326 HDR, KEi, Ni, 327 [, CERTREQ] ---> 328 <--- HDR, [CERT, ] KEr, 329 Nr, SIG 330 HDR*, CHRE ---> 331 <--- HDR*, CHRE 332 [ HDR*, CHRE ---> 333 <--- HDR*, CHRE ] 335 Aggressive Mode using CRACK is defined as 337 Client (I) Gateway (R) 338 ----------- ----------- 339 HDR, SAi, KEi, Ni 340 [, CERTREQ] ---> 341 <--- HDR, SAr, [CERT, ] KEr, 342 Nr, SIG 343 HDR*, CHRE ---> 344 <--- HDR*, CHRE 345 [ HDR*, CHRE ---> 346 <--- HDR*, CHRE ] 348 Where SIG is a digital signature of the aforementioned information. 349 Any ambiguity about which key was used can be dispelled by optionally 350 sending a certificate payload which indicates the public key that 351 should be used to verify the signature. 353 Note that the number of messages in an exchange is not fixed. The 354 gateway can respond with any number of challenges (CHRE payloads) to 355 which the client responds with responses (also CHRE payloads) for 356 each. When the gateway has successfully authenticated the client, it 357 responds with a CHRE payload with an associated attribute list 358 containing (at least) the CRACK_T_FIN attribute with the value of 359 CRACK_FIN_SUCCESS. Depending on the LAM Type, the gateway may respond 360 with CRACK_FIN_MORE, indicating that the exchange needs to continue 361 for an additional round. 363 3.2 IKE Challenge/Response Failures 365 CRACK requires the gateway to send ISAKMP Notify payloads under 366 certain circumstances detailed in this section and elsewhere in this 367 draft. These Notify payloads use the same format for the 368 Notification Payload ([MSST98]) and differ only in the "Notification 369 Data" field. 371 The Notification Payload MUST have the following format: 373 o Payload length - set to the value 28 + "Notification Data" 374 o DOI - set to the value zero (0) (ISAKMP) 375 o Protocol ID - set to the value one (1) (PROTO_ISAKMP) 376 o SPI Size - set to the value 16 377 o Notify Message Type - set to the value 24 378 o SPI - set to the ISAKMP initiator and responder cookies 380 If the contents of the CHRE payload(s) that the client sends fail to 381 satisfy the legacy authentication method, the gateway MUST terminate 382 the connection and MUST respond with an ISAKMP (AUTHENTICATION- 383 FAILED) [MSST98]. 385 AUTHENTICATION-FAILED MUST include the following "Notification Data": 387 o LAM Type (two octets) - set to the associated LAM Type 388 o RESERVED (two octets) - MUST be zero (0) (alignment) 390 In addition AUTHENTICATION-FAILED SHOULD contain the following 391 "Notification Data" when applicable: 393 o Status (variable length) - implementation-specific 394 authentication failure status 396 If LAM Type, signature algorithm, or corresonding public-key 397 requested by a CERTREQ cannot be located, the gateway MUST terminate 398 the connection and MUST respond with an ISAKMP Notify (PROPOSAL-NOT- 399 CHOSEN) [MSST98]. 401 PROPOSAL-NOT-CHOSEN MUST include the following "Notification Data": 403 o LAM Type (two octets) - set to the LAM Type the server requires 404 for the client; MAY be different than the LAM Type specified in 405 the first CHRE payloads if the server required a different LAM 406 Type than was offered 407 o RESERVED (two octets) - MUST be zero (0) (alignment) 409 In addition PROPOSAL-NOT-CHOSEN SHOULD contain the following 410 "Notification Data" when applicable: 412 o Status (variable length) - authentication failure status 414 Because these Notify messages are only sent under the security of the 415 Phase 1 shared secret and only after the gateway has proven its 416 identity to the client, the client can trust the authenticity of 417 these messages and MUST terminate the exchange upon receipt of any of 418 these Notify messages. 420 4. Legacy Authentication Method (LAM) Profiles 422 Each defined LAM type uses the CHRE payload and LAM attributes in a 423 different manner. This section profiles the acceptable use of each 424 for the defined LAM types and details the list of acceptable 425 attributes for each profile. 427 The Challenge/Response profile examples include the exchange of 428 CERTREQ and CERT payloads which may be used when the client does not 429 have access to the server's public-key or has access to multiple 430 server keys. In other examples, the CERTREQ and CERT payloads are 431 omitted for simplicity, but these MAY be used with any of the defined 432 profiles, according to the additional requirements in Section 3.1. 434 4.1 LAM Profiles: Password 436 The Password profile supports legacy operating system (OS) 437 authentication along with proxy-based password authentication 438 protocols, like RADIUS or TACACS+. 440 It is assumed in this example that the client has the gateway's 441 public key, either through a certificate or a trusted raw public key, 442 prior to initiation of the exchange. This example is given using Main 443 Mode. 445 Client (I) Gateway (R) 446 ----------- ----------- 447 HDR1, SAi, ---> 448 <--- HDR2, SAr, 449 HDR1, KEi, Ni ---> 450 <--- HDR2, KEr, Ni, SIG 451 HDR3*, CHRE1 ---> 452 <--- HDR4*, CHRE2 454 For Password, the CHRE payloads are used as follows: 456 HDR3*, CHRE1 ---> 458 The CHRE1 payload contains the client's username as a 459 CRACK_T_USERNAME attribute and a password as a CRACK_T_SECRET 460 attribute. The format of the client password is dictated by the 461 corresponding host OS or proxy authentication server and may be 462 either plaintext or binary. 464 <--- HDR4*, CHRE2 466 The CHRE2 payload contains a CRACK_T_FIN attribute with the value of 467 CRACK_FIN_SUCCESS. 469 The following attributes are defined for Password: 471 CRACK_T_USERNAME (client -> gateway, required) 473 CRACK_T_USERNAME is sent in the client's first CHRE payload and MUST 474 contain the client's username which is used as an index key by 475 the host OS or proxy password authentication server. 477 CRACK_T_SECRET (client -> gateway, required) 478 CRACK_T_SECRET is sent in the client's first CHRE payload and MUST 479 contain the client's password. 481 CRACK_T_DOMAIN (client -> gateway, optional) 483 CRACK_T_DOMAIN is sent in the client's second message and MAY be 484 used to specify the authentication domain that the client is 485 requesting authentication within. 487 CRACK_T_FIN (gateway -> client, required) 489 CRACK_T_FIN is used to successfully terminate the exchange. 491 4.2 LAM Profiles: One-Time Password 493 The OTP profile supports both the S/KEY and OTP one-time password 494 schemes. 496 It is assumed in this example that the client has the gateway's 497 public key, either through a certificate or a trusted raw public key, 498 prior to initiation of the exchange. The example is given using 499 Aggressive Mode. 501 Client (I) Gateway (R) 502 ----------- ----------- 503 HDR1, SAi, KEi, Ni ---> 504 <--- HDR2, SAr, KEr, Nr, SIG 505 HDR3*, CHRE1 ---> 506 <--- HDR4*, CHRE2 507 HDR5*, CHRE3 ---> 508 <--- HDR6*, CHRE4 510 For OTP, the CHRE payloads are used as follows: 512 HDR3*, CHRE1 ---> 514 The CHRE1 payload contains only any associated attributes 515 such as a username. 517 <--- HDR4*, CHRE2 519 The CHRE2 payload contains the OTP server's challenge 520 text which MUST be displayed to the client user. 522 HDR5*, CHRE3 ---> 524 The CHRE3 payload contains the client's one-time password 525 response. 527 <--- HDR6*, CHRE4 529 The CHRE4 payload contains a CRACK_T_FIN attribute with the value 530 of CRACK_FIN_SUCCESS. 532 The following attributes are defined for OTP: 534 CRACK_T_USERNAME (client -> gateway, required) 536 CRACK_T_USERNAME is sent in the client's first CHRE payload and MUST 537 contain the client's username which is used as an index key by 538 the OTP server. 540 CRACK_T_CHALLENGE (gateway -> client, required) 542 CRACK_T_CHALLENGE is sent in the gateway's first CHRE payload 543 and MUST contain the OTP challenge to be issued to the client. 545 CRACK_T_SECRET (client -> gateway, required) 547 CRACK_T_SECRET is sent in the client's second CHRE payload and 548 contains the client's one-time password. 550 CRACK_T_MESSAGE (gateway -> client, optional) 552 CRACK_T_MESSAGE is optionally sent in any server message and MAY 553 by used by the server to provide optional text to be displayed 554 to the user along with any associated challenge text. 556 CRACK_T_FIN (gateway -> client, required) 558 CRACK_T_FIN is used to successfully terminate the exchange. 560 4.3 LAM Profiles: Challenge/Response 562 The Challenge/Response profile supports various token cards that 563 follow a standard challenge/response exchange. The client's token 564 card information (the response) depends on the gateway's request (the 565 challenge). 567 It is assumed in this example that the client does not have the 568 gateway's public key and requires a certificate issued by a trusted 569 Certification Authority. Note that in this case, identity protection 570 of the gateway is lost. Whether a certificate is requested and sent 571 or not, the client's identity is never open to a passive attack (i.e. 572 the client retains identity protection regardless). 574 The following example shows an exchange where a full 575 challenge/response exchange is followed: 577 Client (I) Gateway (R) 578 ----------- ----------- 579 HDR1, SAi, KEi, Ni, 580 CERTREQ ---> 581 <--- HDR2, SAr, CERT, KEr, 582 Nr, SIG 583 HDR3*, CHRE1 ---> 584 <--- HDR4*, CHRE2 585 HDR5*, CHRE3 ---> 586 <--- HDR6*, CHRE4 588 If more challenges were required to authenticate this client, message 589 six would be another CHRE payload containing a challenge to the 590 client. This would force a message seven which would be another CHRE 591 payload. This can be repeated until the gateway authenticates the 592 client (or authentication fails, see below). 594 Alternatively, some challenge-response tokens cache their last 595 computed result and do not require a challenge from the gateway 596 unless they get out of sync (perhaps due to intrusion detection). In 597 this case, the gateway may be able to authenticate the client in the 598 second message and would return, assuming success a CHRE2 containing 599 CRACK_T_FIN attribute with the value of CRACK_T_FIN_SUCCESS. There 600 would also be no fifth nor sixth message. 602 The following example shows an exchange where the client can pre- 603 compute his expected response: 605 Client (I) Gateway (R) 606 ----------- ----------- 607 HDR1, SAi, KEi, Ni, 608 CERTREQ ---> 609 <--- HDR2, SAr, CERT, KEr, 610 Nr, SIG 611 HDR3*, CHRE1 ---> 612 <--- HDR4*, CHRE2 614 For Challenge/Response, the CHRE payloads are used as follows: 616 HDR3*, CHRE1 ---> 618 When the client is using a token that can compute the 619 next expected response without requiring a challenge, 620 the CHRE1 payload contains the client's username and 621 expected response. When the client does not 622 have an expected response, or has chosen not to use 623 the current one for whatever reason, the CHRE payload 624 contains only the client's username. 626 <--- HDR4*, CHRE2 628 The CHRE2 payload contains the gateway's challenge 629 text which MUST be displayed to the client user unless 630 the client has presented an expected response (as 631 above) in which case this is identical to CHRE4 below. 633 HDR5*, CHRE3 ---> 635 The CHRE3 payload, when used, contains the client's 636 response to the gateway challenge. 638 <--- HDR6*, CHRE4 640 The CHRE4 payload contains a CRACK_T_FIN attribute with the 641 value of CRACK_FIN_SUCCESS. 643 The following attributes are defined for Challenge/Response: 645 CRACK_T_USERNAME (client -> gateway, required) 647 CRACK_T_USERNAME is sent in the client's second message and MUST 648 contain the client's username which is used as an index key for 649 authentication by the server. 651 CRACK_T_SECRET (client -> gateway, required) 653 CRACK_T_SECRET contains the client's response and is sent in the 654 client's second message if an anticipated challenge is used, and 655 in the client's third message if the client is responding to 656 a gateway challenge. 658 CRACK_T_PIN (client -> gateway, optional) 660 CRACK_PIN is optionally sent in any client message and MAY by 661 used if the authentication protocol also requires the client 662 to provide a PIN. 664 CRACK_T_MESSAGE (gateway -> client, optional) 666 CRACK_MESSAGE is optionally sent in any server message and MAY 667 by used by the server to provide optional text to be displayed 668 to the user along with any associated challenge text. 670 CRACK_T_FIN (gateway -> client, required) 672 CRACK_T_FIN is used to successfully terminate the exchange. 674 4.4 LAM Profiles: SecurID 676 The SecurID profile supports the RSA SecurID protocol. With SecurID 677 the client will be passing the output of the SecurID card as the body 678 of the first CHRE payload (in the second message it sends) and its 679 identity as an associated CRACK_T_USERNAME attribute. Assuming the 680 client and gateway are in sync (i.e. they are not in "Next Code" 681 mode) there is a single CHRE payload. 683 It is assumed in this example that the client has the gateway's 684 public key, either through a certificate or a trusted raw public key, 685 prior to initiation of the exchange. 687 The following example shows a simple SecurID authentication using 688 aggressive mode: 690 Client (I) Gateway (R) 691 ----------- ----------- 692 HDR1, SAi, KEi, Ni ---> 693 <--- HDR2, SAr, KEr, 694 Nr, SIG1 695 HDR3*, CHRE1 ---> 696 <--- HDR4*, CHRE2 698 For simple SecurID, the CHRE payloads are used as follows: 700 HDR3*, CHRE1 ---> 702 The CHRE1 payload contains the client's username and the current 703 Passcode displayed by the client's SecurID token. 705 <--- HDR4*, CHRE2 707 The CHRE2 payload contains a CRACK_T_FIN attribute with the value 708 of CRACK_FIN_SUCCESS. 710 When the client and gateway clocks are slightly out of sync, the gateway 711 will respond with an additional challenge payload to which the client 712 MUST respond with another reponse payload. This is known as "Next Code" 713 mode. 715 The following example shows a SecurID authentication where "Next Code" 716 mode is required: 718 Client (I) Gateway (R) 719 ----------- ----------- 720 HDR1, SAi, KEi, Ni ---> 721 <--- HDR2, SAr, KEr, 722 Nr, SIG 723 HDR3*, CHRE1 ---> 724 <--- HDR4*, CHRE2 725 HDR5*, CHRE3 ---> 726 <--- HDR6*, CHRE4 728 For SecurID with "Next Code", the CHRE payloads are used as follows: 730 HDR3*, CHRE1 ---> 732 The CHRE1 payload contains the client's username and the current 733 Passcode displayed by the client's SecurID token. 735 <--- HDR4*, CHRE2 737 The CHRE2 payload contains a CRACK_T_FIN attribute with the value 738 of CRACK_FIN_MORE. 740 HDR5*, CHRE3 ---> 742 The CHRE3 payload contains the client's next Passcode 743 displayed by the client's SecurID token. 745 <--- HDR6*, CHRE4 747 The CHRE4 payload contains a CRACK_T_FIN attribute with the value 748 of CRACK_FIN_SUCCESS. 750 The following attributes are defined for SecurID: 752 CRACK_T_USERNAME (client -> gateway, required) 754 CRACK_T_USERNAME is sent in the client's second message and MUST 755 contain the client's username which is used as an index key by 756 the ACE server. 758 CRACK_T_PIN (client -> gateway, optional) 760 CRACK_T_PIN is sent in the client's second message and MAY be 761 used when the SecurID card is not a PINPAD card. 763 CRACK_T_MESSAGE (gateway -> client, optional) 765 CRACK_T_MESSAGE is optionally sent in any server message and MAY 766 by used by the server to provide optional text to be displayed 767 to the user along with any associated challenge text. 769 CRACK_T_FIN (gateway -> client, required) 771 CRACK_T_FIN is used to successfully terminate the exchange and 772 to request the client continue under "Next Code" mode. 774 4.5 LAM Profile Matrix 776 Each of the LAM's supported by IKE Challenge/Response fall into one 777 of the defined LAM profiles. This section details the classification 778 for those methods, including all of the types defined for the 779 experimental XAUTH protocol [PB99]. 781 Password 782 DIAMETER 783 LDAP 784 NDS (Netware Directory Services) 785 NT Domain 786 RADIUS 787 TACACS 788 TACACS+ 789 UNIX Login 791 OTP 792 OTP 793 S/KEY 795 Challenge/Response 796 AXENT Defender 797 CheckPoint ActivCard 798 CRYPTOCard CRYPTOCard 799 Digital Pathways SNK 800 LeeMah InfoCard 801 Secure Computing SafeWord (Enigma Logic DES Gold) 803 SecurID 804 RSA SecurID 806 5. The IKE Challenge/Response Vendor ID Signature 808 This memo describes a protocol that lives on top of [MSST98] and as a 809 companion to [HC98]. These standards-track protocols reserve some of 810 their "magic number" space for private use by mutually consenting 811 parties. It is from this number space that this memo obtains some of 812 the "magic numbers" it needs (payload types, exchange value, 813 attributes). As part of the "mutually consenting parties" part of 814 the requirement implementors of this protocol are encouraged to use a 815 Vendor ID payload to announce willingness to engage in this protocol. 816 The contents of the Vendor ID payload will be the following 817 hexadecimal string: 0x13f11823f966fa91900f024ba66a86b, which is the 818 result of an MD5 hash of "IKE Challenge/Response for Authenticated 819 Cryptographic Keys (Revised)" without the quotation marks. An [HC98] 820 implementation that implements this protocol that obtains a Vendor ID 821 payload with this string in the body of the payload can assume that 822 the sender of the Vendor ID payload has likewise implemented this 823 protocol and is therefore a "mutually consenting party". 825 If this protocol is advanced to standards-track status IANA will 826 assign new "magic numbers" out of the appropriate number spaces (the 827 "magic numbers" will no longer be from the private use ranges) and 828 the requirement to use a Vendor ID payload will go away. 830 6. Security Considerations 832 The channel that results from the exchange of the first two messages 833 is secured because the gateway signs his Diffie-Hellman public value 834 and it is the resulting SKEYID state (see [HC98]) that protects the 835 channel. The channel is secured from the client's perspective because 836 he knows that the gateway was the actual source of the Diffie-Hellman 837 public value and is an active party to the exchange. The channel is 838 secured from the gateway's perspective because the client has proved 839 proof-of-possession of a long-term shared secret and would not have 840 sent his sensitive information if a man-in-the-middle was detected by 841 the client. 843 While this seems to be a weak form of assurance, the exchange could 844 only be foiled by an intentionally malfunctioning client and if that 845 is the case then all bets are off regardless of the method of 846 authentication. (If Alice and Bob establish IPsec SA's in the 847 traditional fashion, using a [HC98] exchange nothing could stop Alice 848 from sending all the sensitive information Bob conveys to her to 849 Eve.) Also note that this technique is used in other popular on-line 850 certificate enrollment schemes ([MLSW99]). 852 As noted, this whole scheme can fail if the client is intentionally 853 malicious. Also, if the token card and knowledge of how to generate 854 valid credentials is conveyed to a third-party this scheme would fail 855 (but not due to any protocol failure). 857 The number of messages in this protocol is dictated by the type of 858 legacy authentication method employed. Since this protocol is open- 859 ended, a host implementation may wish to limit the number of CHRE 860 round-trips using locally defined policy. 862 Acknowledgments 864 The authors would like to thank the sales and marketing staff of all 865 companies who said, "Just give us something that uses token cards!" 866 We would like to recognize Roy Pereira and Stephane Beaulieu, authors 867 of [PB99], which was borrowed from liberally in creation of this 868 memo. 870 References 872 [Bra96] Bradner, S., "The Internet Standards Process -- 873 Revision 3", BCP 9, RFC 2026, October 1996. 875 [CR98] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol", 876 draft-calhoun-diameter-02.txt, March 1998, a work in 877 progress. 879 [DSS] National Institute of Standards and Technology, U.S. 880 Department of Commerce, "Digital Signature Standard", 881 FIPS 186, May 1994. 883 [Hal95] N. Haller, "The S/KEY One-Time Password System", RFC1760, 884 February 1995. 886 [HC98] D. Harkins, D. Carrel, "The Internet Key Exchange", 887 RFC2409, November 1998. 889 [HM96] N. Haller, C. Metz, "A One-Time Password System", RFC1938, 890 May 1996. 892 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 893 Hashing for Message Authentication", RFC 2104, February 894 1997. 896 [MLSW99] M. Myers, X. Liu, J. Schaad, and J. Weinstein, "Certificate 897 Management Messages over CMS", draft-ietf-pkix-cmc-05.txt, 898 a work in progress. 900 [MSST98] D. Maughan, M. Schertler, M. Schneider, J. Turner, 901 "Internet Security Association and Key Management Protocol 902 (ISAKMP)", RFC2408, November 1998. 904 [PB99] R. Pereira, S. Beaulieu, "Extended Authentication within 905 ISAKMP/Oakley", draft-ietf-ipsec-isakmp-xauth-05.txt, 906 September, 1999, a work in progress. 908 [Pip98] Piper, D., "The Internet IP Security Domain Of 909 Interpretation for ISAKMP", RFC 2407, November 1998. 911 [PKCS1] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 912 Specifications Version 2", September 1998. 914 [RASW97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 915 Authentication Dial In User Service (RADIUS)", RFC2138, 916 April 1997. 918 [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for 919 Obtaining Digital Signatures and Public-Key Cryptosystems", 920 Communications of the ACM, v. 21, n. 2, February 1978. 922 Authors' Address 924 Dan Harkins 925 Derrell Piper 926 Nokia Corporation 927 1538 Pacific Ave 928 Santa Cruz, CA 95060-9311 929 United States of America