idnits 2.17.1 draft-hoffman-sla-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == 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 616 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** There are 108 instances of lines with control characters in the document. ** 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 111: '...The client MUST both verify the signat...' RFC 2119 keyword, line 128: '...ast message, and MUST come from the re...' RFC 2119 keyword, line 139: '...HRE in message N MUST contain the SLA_...' RFC 2119 keyword, line 171: '...exchange MUST verify that value on all...' RFC 2119 keyword, line 188: '...ed by the initiator and MUST be set in...' (25 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? 'Hal95' on line 230 looks like a reference -- Missing reference section? 'HM96' on line 231 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Dan Harkins 2 draft-hoffman-sla-00.txt Derrell Piper 3 December 17, 2002 Paul Hoffman 4 Expires in six months 6 Secure Legacy Authentication (SLA) for IKEv2 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 SLA is a new IKEv2 exchange that reuses most of the features of the 31 IKEv2 Initial (Phase 1) exchange but allows for legacy authentication 32 that is not susceptible to man-in-the-middle attacks. It has a flexible 33 number of messages based on the type of authentication being used, and 34 is extensible for new authentication mechanisms. SLA will work with 35 remote access configuration in the same way as IKEv2's Initial exchange. 37 Introduction 39 This document is *not* meant to become an RFC. Instead, if the IPsec 40 WG agrees, it should be part of the IKEv2 RFC. The next version of this 41 draft can be specified as changes to the IKEv2 document. 43 It is possible that the format of the tag-length-value attributes will 44 change to match those that are currently in XAUTH. If that happens, 45 all of the usage examples from XAUTH can bin incorporated. This would 46 increase code-reuse for folks who already have done XAUTH. 48 1. Exchange overview 50 Re-use of IKEv2 code is an important goal for SLA. SLA's messages are 51 very similar to those in IKEv2's Initial exchange. The resulting key 52 material is derived in the same fashion as IKEv2, and SLA uses the same 53 denial-of-service protection as IKEv2's Initial exchange. Because SLA 54 has a different exchange number than IKEv2's Initial exchange, there is 55 no ambiguity for either party about whether or not legacy authentication 56 will be used. 58 The SLA protocol is based on earlier proposals for secure legacy 59 authentication such as Hybrid and CRACK. In SLA, the authentication of 60 each side happens very differently. The responder (who is usually a 61 security gateway) authenticates itself to the initiator first using 62 standard IKEv2 authentication methods. After that, the initiator (who is 63 usually a remote access client) authenticates itself to the responder 64 using a legacy authentication mechanism such as username-password, 65 SecurID token, and so on. 67 In this description, "message N" is the last message in the exchange. 68 Because the number of messages is variable, there is no specified number 69 for the message. 71 A quick summary of the exchange is: 73 - Message 1 is the same as the IKEv2 message 1. 75 - Message 2 is the same as the IKEv2 message 2 except that it includes 76 the responder's authentication payload. This allows the remote access 77 client to authenticate the responder before engaging in sensitive legacy 78 authentication. 80 - Message 3 is the same as the IKEv2 message 3 except that the 81 identification payload and the authentication payload are replaced by 82 the first challenge/response payload, which identifies the initiator and 83 the legacy authentication mechanism being used. 85 - Messages 4 through N-1 consist of the legacy authentication steps. 86 Each message consists of a single challenge/response payload. 88 - The last message, N, always comes from the responder, and it includes 89 a challenge/response payload that states that the authentication is 90 complete. It also contains the SAr2, TSi, and TSr payloads from IKEv2 91 message 4. 93 2. Exchange details 95 All information not defined here is assumed to be the same as for the 96 IKEv2 Initial exchange. Messages 1 and 2 are: 98 Initiator Responder 99 ----------- ----------- 100 HDR, SAi1, KEi, Ni --> 102 <-- HDR, SAr1, KEr, Nr, AUTH 104 The responder's AUTH payload is computed over all of message 1 105 concatenated with all of message 2. Because the contents of the AUTH 106 payload cannot be known when creating the concatenation, a dummy AUTH 107 payload is constructed which consists of the payload header that would 108 have been used (including a correct length field), but with each octet 109 of the contents set to 0x00. 111 The client MUST both verify the signature as being valid for the 112 gateway's public key as well as verify that the signed exchange matches 113 the actual data sent by the client in the first message. 115 Message 3 is: 117 HDR*, CHRE, 118 SAi2, TSi, TSr --> 120 Message 4 through message N-1 have the format: 122 HDR*, CHRE 124 This is the challenge/response message described in section 3. The 125 contents of the CHRE payloads is specific to the legacy authentication 126 method chosen. 128 Message N is the last message, and MUST come from the responder. If the 129 responder successfully authenticates the initiator, message N is: 131 <-- HDR*, CHRE, 132 SAr2, TSi, TSr 134 If the responder does not successfully authenticate the initiator, 135 message N is: 137 <-- HDR*, CHRE 139 In either case, the CHRE in message N MUST contain the SLA_T_FIN 140 attribute to tell the initiator whether or not the authentication 141 succeeded. 143 2.1 Error codes 145 Errors are indicated with IKEv2 Notify exchanges. They are: 147 REFUSE-TO-DO-SLA 148 Responder unwilling to do SLA (after message 1) 150 REFUSE-TO-GO-FORWARD 151 Initiator (after message 2) cannot or does not want to continue 152 the exchange. This may be due to the initiator not being able to 153 validate the signature on the AUTH in message 2, the initiator 154 not liking SAr1 or KEr, and so on. 156 3. The Challenge/Response Payload (CHRE) 158 The Challenge/Response payload is used to convey a challenge from the 159 responder to the initiator and is used by the initiator to respond to a 160 challenge from the responder. The Challenge/Response payload contains 161 attributes denoting specific information conveyed from the initiator to 162 the responder and back. The actual legacy authentication method will 163 determine the contents of this payload at the various points in the 164 exchange. 166 This payload consists of the IKEv2 generic header and a payload-specific 167 body whose length is not fixed. The body consists of one or more 168 attributes, described below. The "Payload Length" in the generic header 169 includes the length of the header itself. All fields labeled "RESERVED" 170 MUST be filled with zero (0) prior to sending and each party to the 171 exchange MUST verify that value on all payloads it is sent. 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ! Next Payload ! RESERVED ! Payload Length ! 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 ! LAM Type ! RESERVED ! 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | 180 ~ one or more attributes ~ 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 The payload type for this payload is [[ TBA ]]. 186 The LAM Type field denotes the legacy authentication method associated 187 with the exchange. The LAM Type must be set in all CHRE payloads in an 188 exchange. The LAM Type is selected by the initiator and MUST be set in 189 every CHRE payload to the same value throughout the exchange. 191 3.1 LAM Types 193 Different legacy authentication methods are denoted by unique LAM 194 type identifiers in the Challenge/Response payloads. 196 If the responder is not configured to support the requested LAM type 197 while processing the initiator's first CHRE payload, the responder MUST 198 terminate the exchange and MUST respond with an IKEv2 Notify 199 of type NO-PROPOSAL-CHOSEN. 201 A conformant responder MUST support at least one of the specified LAM 202 Types. A responder MAY support more than one LAM Type and it's assumed 203 that the choice of which LAM Types are supported is 204 implementation-specific and determined from local policy configuration, 205 perhaps on a per-user basis based on the content of the first CHRE 206 payload and its associated attributes. 208 The legacy authentication methods are: 210 LAM Type Identifier Value 211 ------------------- ----------- 212 RESERVED 0 213 SLA_PASSWORD 1 214 SLA_OTP 2 215 SLA_CHALLENGE_RESPONSE 3 216 SLA_SECURID 4 217 5-32767 218 32768-65535 220 This table will be maintained by IANA. Additional LAM types MAY be 221 defined. Such definitions MUST be in standards-track RFCs and registered 222 with IANA. 224 SLA_PASSWORD 225 A simple username/password mechanism. It is used for any simple 226 host-based password or one-way hash mechanism. It also useful for 227 proxy-based password authentication schemes. 229 SLA_OTP 230 A one-time password mechanism. It is useful for the S/KEY [Hal95] 231 and OTP [HM96] schemes. 233 SLA_CHALLENGE_RESPONSE 234 A token-based challenge/response mechanism. It's useful for a wide 235 variety of cryptographic tokens, typically based on DES. 237 SLA_SECURID 238 A SecurID-like mechanism. It's useful for the RSA SecurID system. 239 The SLA_SECURID closely resembles SLA_CHALLENGE_RESPONSE. 241 3.2 LAM Attributes 243 The Challenge/Response payload contains attributes used to convey 244 information between the initiator and the responder authenticating the 245 initiator. Attributes have the structure: 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 ! Attribute Tag ! Attribute Length ! 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 ~ Attribute content ~ 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 The attribute length is specified in octets. 258 Attribute name Attribute tag 259 -------------- ------------- 260 RESERVED 0 261 SLA_T_USERNAME 1 262 SLA_T_SECRET 2 263 SLA_T_DOMAIN 3 264 SLA_T_PIN 4 265 SLA_T_CHALLENGE 5 266 SLA_T_MESSAGE 6 267 SLA_T_FIN 7 269 This table will be maintained by IANA. Additional LAM attributes MAY be 270 defined. Such definitions MUST be in standards-track RFCs and registered 271 with IANA. 273 SLA_T_USERNAME 274 The initiator user identity that's requesting authentication. The 275 syntax and format of SLA_T_USERNAME is specific to each LAM type. 277 SLA_T_SECRET 278 Secret information the initiator sends in an attempt to 279 authenticate, for instance a password or passcode. The syntax and 280 format of SLA_T_SECRET is specific to each LAM type. 282 SLA_T_DOMAIN 283 The domain or realm the initiator is requesting authentication 284 credentials within. The syntax and format of SLA_T_DOMAIN is 285 specific to each LAM type. 287 SLA_T_PIN 288 The initiator's PIN. The syntax and format of SLA_PIN is specific 289 to each LAM type. 291 SLA_T_CHALLENGE 292 Any challenge the responder may choose to issue to the initiator. 293 The syntax and format of SLA_T_CHALLENGE is specific to each LAM 294 type. 296 SLA_T_MESSAGE 297 An ASCII string to be displayed to the user upon receipt of the 298 corresponding CHRE payload. SLA_T_MESSAGE is valid for all LAM 299 types. Upon receipt, the contents of SLA_T_MESSAGES SHOULD be 300 displayed to the initiator user, typically along with the CHRE 301 challenge. 303 SLA_T_FIN 304 The responder's response to the authentication exchange at all 305 critical decision points specific to each LAM type. The following 306 table defines the values for SLA_T_FIN: 308 Finish Types Value 309 ------------ ----- 310 RESERVED 0 311 SLA_FIN_SUCCESS 1 312 SLA_FIN_MORE 2 314 SLA_FIN_SUCCESS indicates the responder has successfully 315 authenticated the initiator. This value successfully terminates the 316 SLA exchange. This value is legal for all LAM types. 318 SLA_FIN_MORE indicates the responder requires an additional round- 319 trip to authentication the initiator. This is only legal for LAM 320 types which define its use. It MUST NOT be used unless defined in 321 the corresponding LAM profile. 323 4. Legacy Authentication Method (LAM) Profiles 325 Each defined LAM type uses the CHRE payload and LAM attributes in a 326 different manner. This section profiles the acceptable use of each 327 for the defined LAM types and details the list of acceptable 328 attributes for each profile. 330 In the profiles, the CHRE payloads are numbered. Thus, CHRE1 is 331 the CHRE payload in message 3 of the SLA exchange, CHRE2 is the 332 CHRE payload in message 4, and so on. 334 4.1 LAM Profiles: Password 336 The Password profile supports legacy operating system (OS) 337 authentication along with proxy-based password authentication protocols. 339 The password exchange consists of exactly two CHRE payloads: 341 - The CHRE1 payload contains the initiator's username as a 342 SLA_T_USERNAME attribute and a password as a SLA_T_SECRET attribute. The 343 format of the initiator password is dictated by the corresponding host 344 OS or proxy authentication server and may be either plaintext or binary. 346 - The CHRE2 payload contains a SLA_T_FIN attribute with the value of 347 SLA_FIN_SUCCESS. 349 The following attributes are defined for Password: 351 SLA_T_USERNAME (initiator -> responder, required) 353 SLA_T_USERNAME is sent in the initiator's first CHRE payload and 354 MUST contain the initiator's username which is used as an index key 355 by the host OS or proxy password authentication server. 357 SLA_T_SECRET (initiator -> responder, required) 359 SLA_T_SECRET is sent in the initiator's first CHRE payload and MUST 360 contain the initiator's password. 362 SLA_T_DOMAIN (initiator -> responder, optional) 364 SLA_T_DOMAIN is sent in the initiator's second message and MAY be 365 used to specify the authentication domain that the initiator is 366 requesting authentication within. 368 SLA_T_FIN (responder -> initiator, required) 370 SLA_T_FIN is used to successfully terminate the exchange. 372 4.2 LAM Profiles: One-Time Password 374 The OTP profile supports both the S/KEY and OTP one-time password 375 schemes. 377 The OTP exchange consists of exactly four CHRE payloads. 379 - The CHRE1 payload contains only any associated attributes such as a 380 username. 382 - The CHRE2 payload contains the OTP server's challenge text which MUST 383 be displayed to the initiator user. 385 - The CHRE3 payload contains the initiator's one-time password response. 387 - The CHRE4 payload contains a SLA_T_FIN attribute with the value of 388 SLA_FIN_SUCCESS. 390 The following attributes are defined for OTP: 392 SLA_T_USERNAME (initiator -> responder, required) 394 SLA_T_USERNAME is sent in the initiator's first CHRE payload and 395 MUST contain the initiator's username which is used as an index key 396 by the OTP server. 398 SLA_T_CHALLENGE (responder -> initiator, required) 400 SLA_T_CHALLENGE is sent in the responder's first CHRE payload and 401 MUST contain the OTP challenge to be issued to the initiator. 403 SLA_T_SECRET (initiator -> responder, required) 405 SLA_T_SECRET is sent in the initiator's second CHRE payload and 406 contains the initiator's one-time password. 408 SLA_T_MESSAGE (responder -> initiator, optional) 410 SLA_T_MESSAGE is optionally sent in any responder message and MAY by 411 used by the responder to provide optional text to be displayed to 412 the user along with any associated challenge text. 414 SLA_T_FIN (responder -> initiator, required) 416 SLA_T_FIN is used to successfully terminate the exchange. 418 4.3 LAM Profiles: Challenge/Response 420 The Challenge/Response profile supports various token cards that follow 421 a standard challenge/response exchange. The initiator's token card 422 information (the response) depends on the responder's request (the 423 challenge). 425 The Challenge/Response profile consists of at least two CHRE payloads. 426 If more challenges are required to authenticate this initiator, the 427 CHRE2 payload contain a challenge to the initiator. The initiator would 428 respond with CHRE3, and the responder with CHRE4. This can be repeated 429 until the responder authenticates the initiator (or authentication 430 fails, see below). 432 When the initiator is using a token that can compute the next expected 433 response without requiring a challenge, the CHRE1 payload contains the 434 initiator's username and expected response. When the initiator does not 435 have an expected response, or has chosen not to use the current one for 436 whatever reason, the CHRE1 payload contains only the initiator's 437 username. 439 The CHRE2 payload contains the responder's challenge text which MUST be 440 displayed to the initiator user unless the initiator has presented an 441 expected response (as above) in which case this is identical to CHRE4 442 below. 444 The CHRE3 payload, when used, contains the initiator's response to the 445 responder challenge. 447 The CHRE4 payload contains a SLA_T_FIN attribute with the value of 448 SLA_FIN_SUCCESS, or another challenge. 450 The following attributes are defined for Challenge/Response: 452 SLA_T_USERNAME (initiator -> responder, required) 454 SLA_T_USERNAME is sent in the initiator's second message and MUST 455 contain the initiator's username which is used as an index key for 456 authentication by the responder. 458 SLA_T_SECRET (initiator -> responder, required) 460 SLA_T_SECRET contains the initiator's response and is sent in the 461 initiator's second message if an anticipated challenge is used, and 462 in the initiator's third message if the initiator is responding to a 463 responder challenge. 465 SLA_T_PIN (initiator -> responder, optional) 467 SLA_PIN is optionally sent in any initiator message and MAY by used 468 if the authentication protocol also requires the initiator to 469 provide a PIN. 471 SLA_T_MESSAGE (responder -> initiator, optional) 473 SLA_MESSAGE is optionally sent in any responder message and MAY by 474 used by the responder to provide optional text to be displayed to 475 the user along with any associated challenge text. 477 SLA_T_FIN (responder -> initiator, required) 479 SLA_T_FIN is used to successfully terminate the exchange. 481 4.4 LAM Profiles: SecurID 483 The SecurID profile supports the RSA SecurID protocol. With SecurID the 484 initiator will be passing the output of the SecurID card as the body of 485 the CHRE1 payload and its identity as an associated SLA_T_USERNAME 486 attribute. Assuming the initiator and responder are in sync (that is, 487 they are not in "Next Code" mode), the authentication completes with the 488 CHRE2 payload. 490 For simple SecurID, the CHRE payloads are used as follows: 492 - The CHRE1 payload contains the initiator's username and the current 493 Passcode displayed by the initiator's SecurID token. 495 - The CHRE2 payload contains a SLA_T_FIN attribute with the value of 496 SLA_FIN_SUCCESS. 498 When the initiator and responder clocks are slightly out of sync, the 499 responder will respond with an additional challenge payload to which the 500 initiator MUST respond with another response payload. This is known as 501 "Next Code" mode. 503 For SecurID with "Next Code", the CHRE payloads are used as follows: 505 - The CHRE1 payload contains the initiator's username and the current 506 Passcode displayed by the initiator's SecurID token. 508 - The CHRE2 payload contains a SLA_T_FIN attribute with the value 509 of SLA_FIN_MORE. 511 - The CHRE3 payload contains the initiator's next Passcode 512 displayed by the initiator's SecurID token. 514 - The CHRE4 payload contains a SLA_T_FIN attribute with the value 515 of SLA_FIN_SUCCESS. 517 The following attributes are defined for SecurID: 519 SLA_T_USERNAME (initiator -> responder, required) 521 SLA_T_USERNAME is sent in the initiator's second message and MUST 522 contain the initiator's username which is used as an index key by 523 the ACE server. 525 SLA_T_PIN (initiator -> responder, optional) 527 SLA_T_PIN is sent in the initiator's second message and MAY be used 528 when the SecurID card is not a PINPAD card. 530 SLA_T_MESSAGE (responder -> initiator, optional) 532 SLA_T_MESSAGE is optionally sent in any responder message and MAY by 533 used by the responder to provide optional text to be displayed to 534 the user along with any associated challenge text. 536 SLA_T_FIN (responder -> initiator, required) 538 SLA_T_FIN is used to successfully terminate the exchange and to 539 request the initiator continue under "Next Code" mode. 541 4.5 LAM Profile Matrix 543 Each of the LAM's supported by IKE Challenge/Response fall into one 544 of the defined LAM profiles. This section details the classification 545 for those methods. 547 Password 548 DIAMETER 549 LDAP 550 NDS (Netware Directory Services) 551 NT Domain 552 RADIUS 553 TACACS 554 TACACS+ 555 UNIX Login 557 OTP 558 OTP 559 S/KEY 561 Challenge/Response 562 AXENT Defender 563 CheckPoint ActivCard 564 CRYPTOCard CRYPTOCard 565 Digital Pathways SNK 566 LeeMah InfoCard 567 Secure Computing SafeWord (Enigma Logic DES Gold) 569 SecurID 570 RSA SecurID 572 5. Additional security considerations 574 Each legacy authentication mechanism has its own security 575 considerations. Using any particular legacy authentication mechanism 576 exposes the IKEv2 system to the same attacks as the legacy 577 authentication mechanism. 579 The encrypted channel that results after the the first two messages is 580 secured because the responder signs its Diffie-Hellman public value. The 581 channel is secured from the initiator's perspective because the 582 initiator knows that the responder was the actual source of the 583 Diffie-Hellman public value and is an active party to the exchange. The 584 channel is secured from the responder's perspective because the 585 initiator has proved proof-of-possession of a long-term shared secret 586 and would not have sent its sensitive information if a man-in-the-middle 587 was detected by the initiator. 589 6. Additional IANA considerations 591 Create a LAM Type registry from section 3.1. 593 Create a LAM Attribute registry from section 3.1. 595 7. Authors' Addresses 597 Dan Harkins 598 dharkins@trpz.com 600 Derrell Piper 601 ddp@electric-loft.org 603 Paul Hoffman 604 paul.hoffman@vpnc.org