idnits 2.17.1 draft-ietf-pppext-eap-srp-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 542 has weird spacing: '... to perta...' == Line 575 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 2001) is 8443 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) ** Obsolete normative reference: RFC 2284 (ref. '2') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 1334 (ref. '4') (Obsoleted by RFC 1994) ** Downref: Normative reference to an Informational RFC: RFC 2433 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2759 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Carlson 3 INTERNET-DRAFT Sun Microsystems 4 Expires September 2001 March 2001 6 PPP EAP SRP-SHA1 Authentication Protocol 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is the product of the Point-to-Point Protocol 31 Extensions Working Group of the Internet Engineering Task Force 32 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 33 mailing list. Distribution of this memo is unlimited. 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method for 38 transporting multi-protocol datagrams over point-to-point links. PPP 39 also defines an Extensible Authentication Protocol (EAP) [2] 40 framework to allow the use of multiple authentication mechanisms 41 without fixing the mechanism to be used during initial link 42 negotiation. This document defines an authentication mechanism for 43 EAP called SRP-SHA1, and allows the use of the Secure Remote Password 44 (SRP) [3] protocol as a PPP link authentication method. 46 Table of Contents 48 1. Introduction ........................................... 2 49 2. Detailed Description of EAP SRP-SHA1 Authentication .... 3 50 2.1. EAP SRP-SHA1 Packet Formats ............................ 4 51 2.2. EAP SRP-SHA1 Part 1 Request Packet ..................... 5 52 2.3. EAP SRP-SHA1 Part 1 Response Packet .................... 6 53 2.4. EAP SRP-SHA1 Part 2 Request Packet ..................... 7 54 2.5. EAP SRP-SHA1 Part 2 Response Packet .................... 8 55 2.6. EAP SRP-SHA1 Success Packet ............................ 9 56 3. Use with EAP ........................................... 11 57 3.1. One-Way Versus Bidirectional Encryption ................ 11 58 3.2. One-Way Versus Mutual Authentication ................... 11 59 3.3. DESEbis Versus 3DES .................................... 12 60 4. Security Considerations ................................ 12 61 5. Intellectual Property Rights Notices ................... 12 62 5.1. Patent Issues .......................................... 12 63 5.2. Full Copyright Statement ............................... 13 64 6. References ............................................. 14 65 7. Author's Address ....................................... 15 66 8. Appendix A - Well-Known Prime Modulus .................. 15 68 1. Introduction 70 PPP-EAP allows the use of multiple authentication mechanisms within a 71 single negotiation framework. This design overcomes the chief design 72 limitation of the original PPP authentication mechanisms, PAP [4] and 73 CHAP [5], which require that the protocol to be used for authentica- 74 tion be chosen before the user's identity is known. EAP also simpli- 75 fies the process of adding authentication mechanisms to PPP. 77 SRP is an open source protocol that provides strong, password-based 78 authentication based on cryptographic hashing that is resistant to 79 eavesdropping and active attacks. Unlike PAP, the password never 80 appears on the wire. Unlike CHAP (and variants MS-CHAPv1 [6] and 81 MS-CHAPv2 [7]), access to the cleartext password is not required for 82 the authenticator. Unlike all of these protocols, SRP is resistant 83 to man-in-the-middle attacks. As a side-effect, SRP also creates a 84 session key that can be used for data encryption. 86 SHA-1 [8] is a message digest algorithm that can be used as a hashing 87 mechanism for SRP, producing an SRP variant known as SRP-SHA1. For 88 calculation of the shared key in SRP, SHA-1 is used in an interleaved 89 form to produce 40 octet hashes. See [3] for details. 91 This document describes the message exchanges REQUIRED for one PPP 92 peer to authenticate the other using EAP and SRP-SHA1. As with all 93 PPP authentication mechanisms, the peers are independent and equal, 94 and either or both may demand authentication from the other, and dif- 95 ferent protocols may be used independently in each direction. 97 When the PPP Encryption Control Protocol (ECP) [9] is used along with 98 EAP SRP-SHA1, this document describes methods that SHOULD be used to 99 generate the necessary shared keys from the SRP-SHA1 session key. 100 Because authentication necessarily requires prior arrangement between 101 the peers, pre-configured keys MAY be used in place of the SRP-SHA1 102 session key, and any such selection is outside the scope of this 103 document. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in BCP 14 [10]. 109 2. Detailed Description of EAP SRP-SHA1 Authentication 111 Unlike CHAP, SRP-SHA1 requires more than one exchange to authenticate 112 the peer. For this reason, the usual EAP Request/Response is insuf- 113 ficient, and two separate Request/Response messages are defined. 115 With SRP, the authenticator must communicate at least three values to 116 the authenticatee, referred to as 's' (the password salt), 'B' (an 117 ephemeral public key), and 'M2' (a hash value). The authenticatee 118 must communicate at least three values to the authenticator, referred 119 to as 'C' (the client name), 'A' (an ephemeral public key), and 'M1' 120 (a hash value). 122 (The value 'u' passed from authenticator to authenticatee in the gen- 123 eral SRP algorithm is derived from the first 32 bits of a SHA-1 hash 124 of the 'B' value itself in the SRP-SHA1 algorithm. Thus, it does not 125 need to be sent explicitly.) 127 In order to send its last value (M1), the authenticatee needs A, B, 128 and u. However, in order to guarantee that the authenticatee's value 129 chosen for A isn't a rogue value (see section 3.2.4 of the SRP 130 description [11]), the value of u must not be sent until the authen- 131 ticatee reveals A. This implies that there are at least three steps 132 -- authenticatee sends A, authenticator sends B, authenticatee sends 133 M1. 135 The adaptation described in this document uses the EAP Identity 136 Request/Response mechanism to obtain C from the peer. It then uses 137 two new message types -- EAP SRP-SHA1 Parts 1 and 2 -- to handle the 138 SRP authentication. The Part 1 Request message contains s, g, and N. 139 The Part 1 Response contains A. The Part 2 Request continues with B 140 and the Part 2 Response contains M1. Finally, the M2 value is 141 returned in a modified EAP Success message. 143 2.1. EAP SRP-SHA1 Packet Formats 145 A summary of the PPP EAP SRP-SHA1 Request/Response packet format is 146 shown below. The fields are transmitted from left to right. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Code | Identifier | Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | Type-Data ... 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 156 Code 158 1 - Request 159 2 - Response 161 Identifier 163 The identifier field is one octet and aids in matching responses 164 with requests. 166 Length 168 The Length field is two octets and indicates the length of the 169 EAP packet including the Code, Identifier, Length, Type, and Data 170 fields. Octets outside the range of the Length field should be 171 treated as Data Link Layer padding and should be ignored on 172 reception. 174 Type 176 19 - EAP SRP-SHA1 Part 1 177 20 - EAP SRP-SHA1 Part 2 179 Type-Data 181 The format of the Type-Data field is determined by the Code 182 field. The formats associated with EAP SRP-SHA1 are described in 183 the sections below. 185 2.2. EAP SRP-SHA1 Part 1 Request Packet 187 The PPP EAP SRP-SHA1 Part 1 Request packet is SHOULD be sent after 188 the peer's identity has been obtained using the EAP Identity 189 Request/Response packets described in [2]. Using the peer's unau- 190 thenticated identity, the authenticator SHOULD look up the password 191 salt, verifier ('v'), prime modulus, and generator values in an 192 implementation-dependent manner. Use of EAP Identity is not required 193 by this specification, and determination of salt, verifier, prime 194 modulus, and generator may be done in any convenient manner. 196 A summary of the PPP EAP SRP-SHA1 Part 1 Request packet format is 197 shown below. Length and Type fields are as described above. The 198 fields are transmitted from left to right. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Code | Identifier | Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Salt Length | Prime Modulus Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Salt ... | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Prime Modulus ... | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Generator ... 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Code 216 1 - Request 218 Identifier 220 The Identifier field is one octet and aids in matching responses 221 with requests. The Identifier field SHOULD be changed on each 222 Request packet sent, but MAY be kept the same on retransmit. 224 Type 226 19 - EAP SRP-SHA1 Part 1 228 Salt Length 230 Length of the Salt field in octets. This MUST be at least 4 231 octets and MAY be any length up to 255 octets. This field is not 232 padded. 234 Prime Modulus Length 236 Length of the Prime Modulus field in octets. This value MAY be 237 zero to select the 2048 bit value for N listed in Appendix A and 238 select g=2. In this case, neither the Prime Modulus nor the 239 Generator field is present in the message. 241 If the Prime Modulus Length field is non-zero, then it SHOULD be 242 at least 64 octets (512 bits). Longer values are RECOMMENDED. 244 Salt 246 Password salt string; may contain any values and be of any 247 length, subject to link MTU restrictions. 249 Prime Modulus 251 Prime Modulus value. This value (called 'N' in the SRP 252 documentation) is in network byte order and has a length equal to 253 the Prime Modulus Length field. 255 Generator 257 The Generator value. This value (called 'g' in the SRP 258 documentation) is in network byte order and fills the rest of the 259 message without padding. If the Prime Modulus Length field is 260 omitted, then g is set to 2. 262 2.3. EAP SRP-SHA1 Part 1 Response Packet 264 The PPP EAP SRP-SHA1 Part 1 Response message MUST be sent in reply to 265 an EAP SRP-SHA1 Part 1 Request message and MUST NOT be retransmitted 266 on a time-out. Duplicate and invalid Response messages MUST be 267 ignored by the authenticator and SHOULD be logged. Invalid Request 268 messages MUST be acknowledged by the authenticatee with the EAP Nak 269 message; this includes Request messages with an unacceptable modulus 270 or generator value. 272 A summary of the PPP EAP SRP-SHA1 Part 1 Response packet format is 273 shown following. Length and Type fields are as described above. The 274 fields are transmitted from left to right. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Code | Identifier | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Value A ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Code 286 2 - Response 288 Identifier 290 The Identifier field is one octet and MUST match the Identifier 291 from the most recently received Part 1 Request. 293 Type 295 19 - EAP SRP-SHA1 Part 1 297 Value A 299 The result of (g**a) mod N, where 'a' is a randomly chosen number 300 in the range 1 .. N (exclusive). The randomly chosen number is 301 the authenticatee's private key, and the Value A field is the 302 corresponding public key. This field is not padded. 304 The A value MUST NOT be zero. If the authenticator receives zero 305 for this field, it SHOULD take action to disconnect the link. 307 2.4. EAP SRP-SHA1 Part 2 Request Packet 309 The PPP EAP SRP-SHA1 Part 2 Request message MUST NOT be sent until a 310 valid Part 1 Response message has be received. The Part 2 Request 311 message may be retransmitted on time-out. Once a valid Part 1 312 Response message has been received, it is not necessary to send 313 another Part 1 Request unless re-authentication is desired. 315 A summary of the PPP EAP SRP-SHA1 Part 2 Request packet format is 316 shown following. Length and Type fields are as described above. The 317 fields are transmitted from left to right. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Code | Identifier | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Value B ... 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Code 329 1 - Request 331 Identifier 333 The Identifier field is one octet and aids in matching responses 334 with requests. The Identifier field MUST be changed on each 335 Request packet sent. 337 Type 339 20 - EAP SRP-SHA1 Part 2 341 Value B 343 The result of (v + g**b) mod N, where 'b' is a randomly chosen 344 number in the range 1 .. N (exclusive), and v is the stored 345 verifier from the authentication database. The randomly chosen 346 number is the authenticator's private key, and the Value B field 347 is the corresponding public key. This field is not padded. 349 The B value MUST NOT be zero. If the authenticatee receives zero 350 for this field, it SHOULD take action to disconnect the link. 352 2.5. EAP SRP-SHA1 Part 2 Response Packet 354 The PPP EAP SRP-SHA1 Part 2 Response message MUST be sent by the 355 authenticatee in response to a valid EAP SRP-SHA1 Part 2 Request. 356 The authenticator validates this message by calculating the M1 value 357 from its own copies of A, B, and K, and compares the result. If the 358 values match, then the authentication is successful, and EAP Success 359 SHOULD be returned. If the values do not match, then EAP Failure 360 SHOULD be returned and the link terminated. 362 As described in SRP, the authenticatee computes x = SHA1(s, 363 passphrase), and then computes K = SHA_Interleave((B - g^x)^(a + u*x) 364 mod N). The authenticator computes K = SHA1_Interleave((A * v^u)^b 365 mod N). M1 may then be computed as SHA1(A, B, K). 367 A summary of the PPP EAP SRP-SHA1 Part 2 Response packet format is 368 shown below. Length and Type fields are as described above. The 369 fields are transmitted from left to right. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Code | Identifier | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Value M1 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | M1 (continued) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | M1 (continued) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | M1 (continued) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | M1 (continued) | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | M1 | 387 +-+-+-+-+-+-+-+-+ 389 Code 391 2 - Response 393 Identifier 395 The Identifier field is one octet and MUST match the Identifier 396 from the most recently received Part 2 Request. 398 Length 400 25 402 Type 404 20 - EAP SRP-SHA1 Part 2 406 Value M1 408 The 20 octet result of SHA1(A, B, K). 410 2.6. EAP SRP-SHA1 Success Packet 412 The PPP EAP SRP-SHA1 Success message MUST be sent by the authentica- 413 tor in response to a valid EAP SRP-SHA1 Part 2 Response packet, and 414 MUST NOT be retransmitted on an authenticator time-out. The SRP-SHA1 415 Success message MUST NOT be sent if a valid Part 2 Response has not 416 been received. If the authenticatee receives a Success message with 417 invalid contents, it SHOULD terminate the link to avoid man-in-the- 418 middle attacks. An authenticatee SHOULD retransmit its Part 2 419 Response message if a time-out occurs waiting for the Success mes- 420 sage, and an authenticator MUST retransmit the Success message if a 421 duplicate Part 2 Response is received. 423 A summary of the PPP EAP Success packet format is shown below. 424 Length and Type fields are as described above. The fields are 425 transmitted from left to right. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Code | Identifier | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Value M2 | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | M2 (continued) | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | M2 (continued) | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | M2 (continued) | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | M2 (continued) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Code 445 3 - Success 447 Identifier 449 The Identifier field is one octet and MUST match the Identifier 450 from the most recently transmitted Part 2 Request and received 451 Part 2 Response. 453 Length 455 24 457 Value M2 459 The 20 octet result of SHA1(A, B, K). 461 3. Use with ECP 463 The 40 octet value K calculated by the SRP-SHA1 authentication pro- 464 cedure SHOULD be used to form encryption keys if PPP encryption is in 465 use. For the DESEbis [12] algorithm, a shared 56 bit key is neces- 466 sary, and for the 3DES [13] algorithm, a shared 168 bit key is 467 required. Complicating this, ECP may be negotiated in only one 468 direction or both. In addition, PPP authentication may be performed 469 one-way (the most common case) or mutually, and when mutual authenti- 470 cation is chosen, different authentication schemes may be used to 471 authenticate each peer. The effects of these details are described 472 below. 474 The "decryptor" is the peer that sends ECP Configure-Request suggest- 475 ing an algorithm and receives a corresponding ECP Configure-Ack. The 476 "encryptor" is the sender of the ECP Configure-Ack, and will transmit 477 the encrypted data. 479 3.1. One-Way Versus Bidirectional Encryption 481 When encryption is employed in only one direction, then the K value 482 that is chosen for the shared key is the value associated with the 483 EAP SRP-SHA1 authentication in which the decryptor is the authentica- 484 tor. If the decryptor did not authenticate its peer with EAP SRP- 485 SHA1, then the K value associated with the other authentication ses- 486 sion is used instead. 488 3.2. One-Way Versus Mutual Authentication 490 If only one peer authenticates the other using SRP-SHA1, and the 491 other either does not authenticate its peer at all or uses a method 492 that does not result in encryption keys, then the one K value associ- 493 ated with this authentication SHOULD be used for both encryption ses- 494 sions. The first 20 octets of K are used for the encryption of data 495 sent by the authenticatee to the authenticator, and the second 20 496 octets of K are used for encryption of data in the opposite direc- 497 tion. 499 If mutual authentication with algorithms that produce encryption keys 500 is done, such as SRP-SHA1, then two K values are produced. The K 501 values are used so that the encryptor is the authenticatee for the 502 corresponding authentication session, and the decryptor is the 503 authenticator. 505 3.3. DESEbis Versus 3DES 507 For DESEbis, the first 8 octets of the key value are used. DES keys 508 are constructed such that the most significant bit (MSB) of each 509 octet is reserved for parity. 511 For 3DES, 24 octets of key value are used by most implementations. 512 As for DESEbis, the MSBs are discarded. If the 40 octet K value has 513 been split into two 20 octet values because one-way authentication is 514 in use, then an extra 4 octets are needed for each key. The SHA-1 515 algorithm is run again over the 40 octet K value to produce a 20 516 octet hash. This hash is split into two 10 octet values that are 517 then appended to the two 20 octet values from the split K value. The 518 first 24 octets of each 30 octet value is used as the 3DES key. 520 4. Security Considerations 522 The security of SRP relies on having a prime modulus that is large 523 enough to make brute force attack of the key exchange infeasible. A 524 length of at least 1024 bits is recommended. In addition, the SRP 525 document [3] describes tests that MUST be performed on the chosen 526 modulus and generator values and random numbers. 528 The hash values stored in the authenticator's database SHOULD be pro- 529 tected against disclosure and the user's choice password SHOULD be 530 restricted to limit the effectiveness of dictionary attacks. 532 5. Intellectual Property Rights Notices 534 5.1. Patent Issues 536 The SRP key-exchange protocol described in this document is available 537 worldwide on a royalty-free basis for commercial and non-commercial 538 uses. 540 "The IETF takes no position regarding the validity or scope of 541 any intellectual property or other rights that might be claimed 542 to pertain to the implementation or use of the technology 543 described in this document or the extent to which any license 544 under such rights might or might not be available; neither does 545 it represent that it has made any effort to identify any such 546 rights. Information on the IETF's procedures with respect to 547 rights in standards-track and standards-related documentation 548 can be found in BCP-11. Copies of claims of rights made 549 available for publication and any assurances of licenses to 550 be made available, or the result of an attempt made 551 to obtain a general license or permission for the use of such 552 proprietary rights by implementors or users of this 553 specification can be obtained from the IETF Secretariat." 555 "The IETF invites any interested party to bring to its 556 attention any copyrights, patents or patent applications, or 557 other proprietary rights which may cover technology that may be 558 required to practice this standard. Please address the 559 information to the IETF Executive Director." 561 5.2. Full Copyright Statement 563 "Copyright (C) The Internet Society 2001. All Rights 564 Reserved. 566 This document and translations of it may be copied and 567 furnished to others, and derivative works that comment on or 568 otherwise explain it or assist in its implementation may be 569 prepared, copied, published and distributed, in whole or in 570 part, without restriction of any kind, provided that the above 571 copyright notice and this paragraph are included on all such 572 copies and derivative works. However, this document itself may 573 not be modified in any way, such as by removing the copyright 574 notice or references to the Internet Society or other Internet 575 organizations, except as needed for the purpose of developing 576 Internet standards in which case the procedures for copyrights 577 defined in the Internet Standards process must be followed, or 578 as required to translate it into languages other than English. 580 The limited permissions granted above are perpetual and will 581 not be revoked by the Internet Society or its successors or 582 assigns. 584 This document and the information contained herein is provided 585 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 587 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 588 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 589 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 590 PARTICULAR PURPOSE." 592 6. References 594 [1] W. Simpson, "The Point-to-Point Protocol (PPP)," RFC 1661, 595 07/1994 597 [2] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 598 Protocol (EAP)," RFC 2284, 03/1998 600 [3] T. Wu, "The SRP Authentication and Key Exchange System," 601 RFC 2945, 09/2000 603 [4] B. Lloyd, W. Simpson, "PPP Authentication Protocols," RFC 604 1334, 10/1992 606 [5] W. Simpson, "PPP Challenge Handshake Authentication Protocol 607 (CHAP)," RFC 1994, 08/1996 609 [6] G. Zorn, S. Cobb, "Microsoft PPP CHAP Extensions," RFC 2433, 610 10/1998 612 [7] G. Zorn, "Microsoft PPP CHAP Extensions, Version 2," RFC 2759, 613 01/2000 615 [8] National Institute of Standards and Technology (NIST), 616 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 617 Department of Commerce, 04/1995 619 [9] G. Meyer, "The PPP Encryption Control Protocol (ECP)," RFC 1968, 620 06/1996 622 [10] S. Bradner, "Key words for use in RFCs to Indicate Requirement 623 Levels," BCP 14 and RFC 2119, 03/1997 625 [11] T. Wu, "The Secure Remote Password Protocol", in 626 Proceedings of the 1998 Internet Society Symposium on 627 Network and Distributed Systems Security, San Diego, CA, 628 pp. 97-111 630 [12] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol, Version 631 2 (DESE-bis)," RFC 2419, September 1998. 633 [13] H. Kummert, "The PPP Triple-DES Encryption Protocol (3DESE)," 634 RFC 2420, September 1998. 636 7. Author's Address 638 James Carlson 639 Sun Microsystems 640 1 Network Drive MS UBUR02-212 641 Burlington MA 01803-2757 643 Phone: +1 781 442 2084 Email: james.d.carlson@sun.com 644 Fax: +1 781 442 1677 646 8. Appendix A - Well-Known Prime Modulus 648 This 2048 bit prime modulus (and corresponding generator value 2) are 649 borrowed from the SRP GSS-API mechanism, an IETF work in progress. 651 0xAC, 0x6B, 0xDB, 0x41, 0x32, 0x4A, 0x9A, 0x9B, 652 0xF1, 0x66, 0xDE, 0x5E, 0x13, 0x89, 0x58, 0x2F, 653 0xAF, 0x72, 0xB6, 0x65, 0x19, 0x87, 0xEE, 0x07, 654 0xFC, 0x31, 0x92, 0x94, 0x3D, 0xB5, 0x60, 0x50, 655 0xA3, 0x73, 0x29, 0xCB, 0xB4, 0xA0, 0x99, 0xED, 656 0x81, 0x93, 0xE0, 0x75, 0x77, 0x67, 0xA1, 0x3D, 657 0xD5, 0x23, 0x12, 0xAB, 0x4B, 0x03, 0x31, 0x0D, 658 0xCD, 0x7F, 0x48, 0xA9, 0xDA, 0x04, 0xFD, 0x50, 659 0xE8, 0x08, 0x39, 0x69, 0xED, 0xB7, 0x67, 0xB0, 660 0xCF, 0x60, 0x95, 0x17, 0x9A, 0x16, 0x3A, 0xB3, 661 0x66, 0x1A, 0x05, 0xFB, 0xD5, 0xFA, 0xAA, 0xE8, 662 0x29, 0x18, 0xA9, 0x96, 0x2F, 0x0B, 0x93, 0xB8, 663 0x55, 0xF9, 0x79, 0x93, 0xEC, 0x97, 0x5E, 0xEA, 664 0xA8, 0x0D, 0x74, 0x0A, 0xDB, 0xF4, 0xFF, 0x74, 665 0x73, 0x59, 0xD0, 0x41, 0xD5, 0xC3, 0x3E, 0xA7, 666 0x1D, 0x28, 0x1E, 0x44, 0x6B, 0x14, 0x77, 0x3B, 667 0xCA, 0x97, 0xB4, 0x3A, 0x23, 0xFB, 0x80, 0x16, 668 0x76, 0xBD, 0x20, 0x7A, 0x43, 0x6C, 0x64, 0x81, 669 0xF1, 0xD2, 0xB9, 0x07, 0x87, 0x17, 0x46, 0x1A, 670 0x5B, 0x9D, 0x32, 0xE6, 0x88, 0xF8, 0x77, 0x48, 671 0x54, 0x45, 0x23, 0xB5, 0x24, 0xB0, 0xD5, 0x7D, 672 0x5E, 0xA7, 0x7A, 0x27, 0x75, 0xD2, 0xEC, 0xFA, 673 0x03, 0x2C, 0xFB, 0xDB, 0xF5, 0x2F, 0xB3, 0x78, 674 0x61, 0x60, 0x27, 0x90, 0x04, 0xE5, 0x7A, 0xE6, 675 0xAF, 0x87, 0x4E, 0x73, 0x03, 0xCE, 0x53, 0x29, 676 0x9C, 0xCC, 0x04, 0x1C, 0x7B, 0xC3, 0x08, 0xD8, 677 0x2A, 0x56, 0x98, 0xF3, 0xA8, 0xD0, 0xC3, 0x82, 678 0x71, 0xAE, 0x35, 0xF8, 0xE9, 0xDB, 0xFB, 0xB6, 679 0x94, 0xB5, 0xC8, 0x03, 0xD8, 0x9F, 0x7A, 0xE4, 680 0x35, 0xDE, 0x23, 0x6D, 0x52, 0x5F, 0x54, 0x75, 681 0x9B, 0x65, 0xE3, 0x72, 0xFC, 0xD6, 0x8E, 0xF2, 682 0x0F, 0xA7, 0x11, 0x1F, 0x9E, 0x4A, 0xFF, 0x73