idnits 2.17.1 draft-ietf-pppext-eap-srp-03.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 abstract seems to contain references ([RFC2284], [RFC1661], [RFC2945]), 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 974 has weird spacing: '... to perta...' == Line 1007 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 (July 2001) is 8322 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) -- Looks like a reference, but probably isn't: '1' on line 688 -- Looks like a reference, but probably isn't: '2' on line 685 -- Looks like a reference, but probably isn't: '3' on line 676 == Missing Reference: 'Disconnect' is mentioned on line 926, but not defined ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' -- Obsolete informational reference (is this intentional?): RFC 1334 (Obsoleted by RFC 1994) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 2138 (Obsoleted by RFC 2865) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 January 2002 B. Aboba 5 Microsoft Corporation 6 H. Haverinen 7 Nokia Mobile Phones 8 July 2001 10 EAP SRP-SHA1 Authentication Protocol 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This document is the product of the Point-to-Point Protocol 35 Extensions Working Group of the Internet Engineering Task Force 36 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 37 mailing list. Distribution of this memo is unlimited. 39 Abstract 41 The Extensible Authentication Protocol (EAP) [RFC2284] describes a 42 framework that allows the use of multiple authentication mechanisms. 43 This document defines an authentication mechanism for EAP called 44 SRP-SHA1, based on the Secure Remote Password (SRP) [RFC2945] 45 protocol. 47 EAP can be used with the Point-to-Point Protocol (PPP) [RFC1661] for 48 link authentication. 50 Table of Contents 52 1. Introduction ........................................... 2 53 2. Detailed Description of EAP SRP-SHA1 Authentication .... 3 54 2.1. EAP SRP-SHA1 Packet Formats .......................... 4 55 2.2. EAP SRP-SHA1 Challenge Subtype-Data .................. 6 56 2.3. EAP SRP-SHA1 Client Key Subtype-Data ................. 8 57 2.4. EAP SRP-SHA1 Server Key Subtype-Data ................. 8 58 2.5. EAP SRP-SHA1 Client Validator Subtype-Data ........... 9 59 2.6. EAP SRP-SHA1 Server Validator Subtype-Data ........... 10 60 2.7. EAP SRP-SHA1 Subtype 3 Response Packet ............... 12 61 2.8. EAP SRP-SHA1 Lightweight Challenge Subtype-Data ...... 12 62 2.9. EAP SRP-SHA1 Lightweight Response Subtype-Data ....... 13 63 3. Identity Privacy Support ............................... 13 64 3.1 Step One ............................................. 14 65 3.2 Step Two ............................................. 15 66 3.3 Using the Pseudonym .................................. 15 67 4. Use with ECP ........................................... 16 68 4.1. One-Way Versus Bidirectional Encryption .............. 17 69 4.2. One-Way Versus Mutual Authentication ................. 17 70 4.3. DESEbis Versus 3DES .................................. 18 71 5. Use with AAA ........................................... 18 72 6. Examples ............................................... 19 73 6.1. Successful Authentication ............................ 19 74 6.2. Client Unauthenticated ............................... 19 75 6.3. Server Unverified .................................... 20 76 7. Security Considerations ................................ 21 77 8. Intellectual Property Rights Notices ................... 21 78 8.1. Patent Issues ........................................ 21 79 8.2. Full Copyright Statement ............................. 22 80 9. References ............................................. 23 81 9.1. Normative References ................................. 23 82 9.2. Informative References ............................... 23 83 10. Acknowledgements ....................................... 24 84 11. Authors' Addresses ..................................... 24 85 12. Appendix A - Well-Known Prime Modulus .................. 25 87 1. Introduction 89 EAP allows the use of multiple authentication mechanisms within a 90 single negotiation framework. When used with PPP, this protocol 91 overcomes the chief design limitation of the original PPP authentica- 92 tion mechanisms, PAP [RFC1334] and CHAP [RFC1994], which required 93 that the protocol to be used for authentication be chosen before the 94 peer's identity was known. EAP also simplifies the process of adding 95 new authentication mechanisms and linking them into external authen- 96 tication services. 98 SRP is an open source protocol that provides strong, password-based 99 authentication based on cryptographic hashing. Unlike PAP, the pass- 100 word never appears on the wire. Unlike CHAP (and variants MS-CHAPv1 101 [RFC2433] and MS-CHAPv2 [RFC2759]), access to a cleartext password is 102 not required for the authenticator. Unlike all of these authentica- 103 tion protocols, SRP is resistant to dictionary attacks against the 104 over-the-wire information. SRP is also resistant to eavesdropping 105 and active attacks. As a side-effect, SRP also creates a session key 106 that is resistant to man-in-the-middle attacks and can be used for 107 data encryption. 109 SHA-1 [FIPS180] is a message digest algorithm that can be used as a 110 hashing mechanism for SRP, producing an SRP variant known as SRP- 111 SHA1. For calculation of the shared key in SRP, SHA-1 is used in an 112 interleaved form to produce 40 octet hashes. See section 3.1 of 113 [RFC2945] for details. 115 This document describes the message exchanges necessary for one peer 116 to authenticate the other using EAP and SRP-SHA1. When used with 117 PPP, the peers are independent and equal, and either or both may 118 demand authentication from the other, and different protocols MAY be 119 used independently in each direction. 121 When the PPP Encryption Control Protocol (ECP) [RFC1968] is used 122 along with EAP SRP-SHA1, this document describes methods that SHOULD 123 be used to generate the necessary shared keys from the SRP-SHA1 ses- 124 sion key. Because authentication necessarily requires prior arrange- 125 ment between the peers, pre-configured keys MAY be used in place of 126 the SRP-SHA1 session key, and any such selection is outside the scope 127 of this document. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14 [RFC2119]. 133 2. Detailed Description of EAP SRP-SHA1 Authentication 135 Unlike CHAP, SRP-SHA1 requires more than one exchange to authenticate 136 the peer. For this reason, three primary message subtypes are 137 defined. 139 With SRP, the authenticator must communicate at least three values to 140 the authenticatee, referred to as 's' (the password salt), 'B' (an 141 ephemeral public key), and 'M2' (a hash value). The authenticatee 142 must communicate at least three values to the authenticator, referred 143 to as 'C' (the client name), 'A' (an ephemeral public key), and 'M1' 144 (a hash value). 146 (The value 'u' passed from authenticator to authenticatee in the gen- 147 eral SRP algorithm is derived from the first 32 bits of a SHA-1 hash 148 of the 'B' value itself in the SRP-SHA1 algorithm. Thus, it does not 149 need to be sent explicitly.) 151 In order to send its last value (M1), the authenticatee needs A, B, 152 and u. However, in order to guarantee that the authenticatee's value 153 chosen for A isn't a rogue value (see section 3.2.4 of the SRP 154 description [SRP]), the value of u must not be sent until the authen- 155 ticatee reveals A. This implies that there are at least three steps 156 -- authenticatee sends A, authenticator sends B, authenticatee sends 157 M1. 159 The adaptation described in this document recommends the use of the 160 EAP Identity Request/Response mechanism to obtain C from the peer. 161 It then uses a new message type, called EAP SRP-SHA1, with three main 162 subtypes to handle the SRP authentication. The Subtype 1 Request 163 ("Challenge") message contains s, g, and N. The Subtype 1 Response 164 ("Client Key") contains A. The Subtype 2 Request ("Server Key") con- 165 tinues with B and the Subtype 2 Response ("Client Validator") con- 166 tains M1. Finally, the Subtype 3 Request ("Server Validator") con- 167 tains the M2 value and the Subtype 3 response is an acknowledgement 168 containing only the Subtype number and no data. 170 A fourth subtype is used for optional lightweight rechallenges. 172 2.1. EAP SRP-SHA1 Packet Formats 174 All EAP SRP-SHA1 authentication is driven by the authenticator 175 (server). The authenticatee (client) MUST NOT retransmit Response 176 messages, but SHOULD terminate the link if a Request is not received 177 within a reasonable time period. The authenticator SHOULD silently 178 ignore unexpected Response messages. The authenticatee MUST respond 179 using EAP Nak if any unknown Subtype or otherwise unacceptable mes- 180 sage is received. 182 Rationale: 184 Although the EAP Nak message is intended to signal only that a 185 given EAP Type is unknown to the authenticatee and that a 186 different Type should be used, its use here is still consistent 187 with that meaning. If the authenticator attempts to use a 188 subtype unknown to the authenticatee, then authentication using 189 EAP SRP-SHA1 is itself not possible, and another Type should be 190 tried. 192 A summary of the EAP SRP-SHA1 Request/Response packet format is shown 193 below. The fields are transmitted from left to right. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Code | Identifier | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Subtype | Subtype-Data ... 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+- 203 Code 205 1 - Request 206 2 - Response 208 Identifier 210 The Identifier field is one octet and aids in matching responses 211 with requests. The Identifier MUST be changed for each new 212 Request message sent and MUST NOT be changed on retransmission of 213 a given message. The Identifier in the Response message MUST 214 match the corresponding Request. The authenticator MUST discard 215 non-matching Response messages. 217 Length 219 The Length field is two octets and indicates the length of the 220 EAP packet including the Code, Identifier, Length, Type, Subtype, 221 and Subtype-Data fields. Octets outside the range of the Length 222 field should be treated as Data Link Layer padding and should be 223 ignored on reception. Truncated packets (with Length greater 224 than the link layer reported length) MUST be silently discarded. 226 Type 228 19 - EAP SRP-SHA1 230 Subtype 232 1 - Challenge / Client Key 233 2 - Server Key / Client Validator 234 3 - Server Validator 235 4 - Lightweight Rechallenge 237 The Subtype field is one octet and must contain the value 1, 2, 238 3, or 4. If any other subtype value is encountered in an EAP 239 SRP-SHA1 Request message, then the authenticatee SHOULD return an 240 EAP Response with the Type field set to Nak. In EAP SRP-SHA1 241 Response messages, the Subtype value must be copied from the 242 corresponding Request message. The authenticator should treat 243 unknown Subtype values in Response messages as malformed packets 244 and silently discard. 246 Subtype-Data 248 The format of the Subtype-Data field is determined by the Code 249 and Subtype fields as described in the sections below. 251 2.2. EAP SRP-SHA1 Challenge Subtype-Data 253 The EAP SRP-SHA1 Challenge (Subtype 1 Request) packet MUST be sent 254 after the peer's identity has been obtained; use of the EAP Identity 255 Request/Response packet as described in [RFC2284] is RECOMMENDED. 256 Using the peer's unauthenticated identity, the authenticator MUST 257 look up the password salt, verifier ('v'), prime modulus ('N'), and 258 generator ('g') values in an implementation-dependent manner. Use of 259 EAP Identity is not required by this specification, and determination 260 of salt, verifier, prime modulus, and generator MAY be done in any 261 convenient implementation-dependent manner. 263 The authenticatee MUST validate that the specified generator value is 264 indeed a generator modulo N, as described in the SRP documentation 265 [SRP]. In many cases, an efficient method to do this is to keep a 266 list of known-good values, and compare against this list. Since the 267 full validation procedure is complex, the authenticator SHOULD use a 268 longer timeout value if the default generator and modulus are not 269 used; at least 30 seconds is RECOMMENDED. 271 A summary of the EAP SRP-SHA1 Challenge Subtype-Data format is shown 272 below. Code (1), Identifier, Length, Type (19), and Subtype (1) 273 fields are as described above. The fields are transmitted from left 274 to right and are not padded or justified. 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 | Name Length | Server Name ... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 281 | Salt Length | Salt ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 283 | Gen Length | Generator ... 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 285 | Prime Modulus ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+- 287 Name Length 289 A single octet giving the length of the Server Name field in 290 octets. The server name identifies the authenticator, and is 291 used by the authenticatee in an implementation-dependent manner. 292 It MAY be used by the authenticatee to select an appropriate 293 secret for authentication or displayed to a user. 295 Server Name 297 The authenticator's name. This field is not authenticated. It 298 SHOULD NOT be used by the authenticatee as an authenticated peer 299 name. 301 Salt Length 303 A single octet giving the length of the Salt field in octets. 304 This MUST be at least 4 octets and MAY be any length up to 255 305 octets. 307 Salt 309 Password salt string; may contain any values. The contents of 310 this field correspond to 's' in the SRP documentation. 312 Gen Length 314 A single octet giving the length of the Generator field in 315 octets. This value MAY be zero to select the default generator 316 value of 2. 318 Generator 320 The Generator value, called 'g' in the SRP documentation, is in 321 network byte order. If the Gen Length field is zero, then the 322 Generator field is omitted, and g is set to 2. 324 Prime Modulus 326 The Prime Modulus value, called 'N' in the SRP documentation, is 327 in network byte order and fills the rest of the message to the 328 length specified by the Length field in the EAP header. 330 This value MAY be omitted to select the 2048 bit value for N 331 listed in Appendix A. In this case, the Generator value MUST NOT 332 be present in the message in order to default to 2. 334 If the Prime Modulus Length field is present, then it SHOULD be 335 at least 64 octets (512 bits). Longer values are RECOMMENDED. 337 2.3. EAP SRP-SHA1 Client Key Subtype-Data 339 The EAP SRP-SHA1 Client Key (Subtype 1) Response message MUST be sent 340 in reply to an EAP SRP-SHA1 Subtype 1 Request message. 342 A summary of the EAP SRP-SHA1 Client Key Subtype-Data format is shown 343 below. Code (2), Identifier, Length, Type (19), and Subtype (1) 344 fields are as described above. The fields are transmitted from left 345 to right. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Value A ... 351 +-+-+-+-+-+-+-+-+-+- 353 Value A 355 The result of (g^a) mod N, where 'a' is a randomly chosen number 356 in the range 1 .. N (exclusive). The randomly chosen number is 357 the authenticatee's private key, and the Value A field is the 358 corresponding public key. This field is in network byte order 359 and is not padded. 361 The A value MUST NOT be zero modulo N. If the authenticator 362 receives a bad value for this field, it MUST take action to 363 disconnect or disable the link. 365 2.4. EAP SRP-SHA1 Server Key Subtype-Data 367 The EAP SRP-SHA1 Server Key (Subtype 2 Request) message MUST be sent 368 by the authenticator after reception of a valid EAP SRP-SHA1 Client 369 Key (Subtype 1) Response message. 371 A summary of the EAP SRP-SHA1 Server Key Subtype-Data format is shown 372 below. Code (1), Identifier, Length, Type (19), and Subtype (2) 373 fields are as described above. The fields are transmitted from left 374 to right. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Value B ... 380 +-+-+-+-+-+-+-+-+-+- 381 Value B 383 The result of (v + g^b) mod N, where 'b' is a randomly chosen 384 number in the range 1 .. N (exclusive), and v is the stored 385 verifier from the authentication database. The randomly chosen 386 number is the authenticator's private key, and the Value B field 387 is the corresponding public key. This field is in network byte 388 order and is not padded. 390 The B value MUST NOT be zero modulo N. If the authenticatee 391 receives a bad value for this field, it MUST take action to 392 disconnect or disable the link. 394 2.5. EAP SRP-SHA1 Client Validator Subtype-Data 396 The EAP SRP-SHA1 Client Validator (Subtype 2 Response) message MUST 397 be sent by the authenticatee in response to a valid EAP SRP-SHA1 Sub- 398 type 2 Request. The authenticator validates this Response message by 399 calculating the M1 value from its own copies of A, B, and K, and com- 400 pares the result. If the values match, then the authentication is 401 successful, and EAP SRP-SHA1 Server Validator Request SHOULD be sent. 402 If the values do not match, then EAP Failure SHOULD be returned and 403 the link terminated. 405 A summary of the EAP SRP-SHA1 Client Validator Subtype-Data format is 406 shown below. Code (2), Identifier, Length (30), Type (19), and Sub- 407 type (2) fields are as described above. The fields are transmitted 408 from left to right. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Reserved |E| 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Value M1 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | M1 (continued) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | M1 (continued) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | M1 (continued) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | M1 (continued) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Reserved 427 Must be zero on transmit by the authenticatee, ignored on 428 reception by the authenticator. 430 E Bit 432 This bit is set if the authenticatee intends to use the derived 433 session key (K) for ECP, as described in section 4. If this bit 434 is zero, then K will not be used, and if ECP is negotiated, it 435 must use a different keying mechanism. 437 Value M1 439 The 20 octet result of SHA1(SHA1(N) xor SHA1(g), 440 SHA1(clientname), s, A, B, K, id, Type). The single octet "id" 441 value used in this calculation MUST be the EAP Identifier field 442 from the EAP SRP-SHA1 Challenge (Subtype 1) Request message. The 443 single octet "Type" value is a copy of the EAP Type field, which 444 is fixed at 19 (decimal). 446 As described in SRP [RFC2945], the authenticatee computes x = SHA1(s, 447 SHA1(clientname, ":", password)), and then computes K = 448 SHA_Interleave((B - g^x)^(a + u*x) mod N). The authenticator com- 449 putes K = SHA1_Interleave((A * v^u)^b mod N). The calculated K 450 values MAY be used with ECP (see section 4), lightweight rechallenge 451 (section 2.8), and identity privacy (section 3). Finally, M1 is com- 452 puted as SHA1(SHA1(N) xor SHA1(g), SHA1(clientname), s, A, B, K, id, 453 Type). (Note that reference [SRP] gives different definitions of 454 these values; the [RFC2945] document should be treated as the norma- 455 tive reference.) 457 The SHA1 hash to produce the long-term private key x, described above 458 and in [RFC2945], SHOULD be used by default in EAP SRP-SHA1. As an 459 implementation option, however, the x value used above MAY instead be 460 derived from any mutually-chosen hashing algorithm, provided that the 461 security of that algorithm is acceptable to both authentication par- 462 ties. Note that such usage requires prior arrangement between the 463 peers. 465 2.6. EAP SRP-SHA1 Server Validator Subtype-Data 467 The EAP SRP-SHA1 Server Validator (Subtype 3 Request) message MUST be 468 sent by the authenticator after reception of a valid EAP SRP-SHA1 469 Client Validator (Subtype 2) Response. If the authenticatee receives 470 a Server Validator message with invalid contents, it MUST terminate 471 the link. 473 A summary of the EAP SRP-SHA1 Server Validator Subtype-Data format is 474 shown below. Code (1), Identifier, Length, Type (19), and Subtype 475 (3) fields are as described above. The fields are transmitted from 476 left to right. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Reserved |E| 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Value M2 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | M2 (continued) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | M2 (continued) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | M2 (continued) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | M2 (continued) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Hidden Pseudonym ... 494 +-+-+-+-+-+-+-+-+-+-+-+-+- 496 Reserved 498 Must be zero on transmit by the authenticator, ignored on 499 reception by the authenticatee. 501 E Bit 503 This bit is set if the authenticator intends to use the derived 504 session key (K) for ECP, as described in section 4. If this bit 505 is zero, then K will not be used, and if ECP is negotiated, it 506 must use a different keying mechanism. This bit MUST be 0 if the 507 authenticator uses a proxy authentication mechanism that does not 508 provide access to the session key. (See section 5.) 510 Value M2 512 The 20 octet result of SHA1(A, M1, K, id, Type). The single 513 octet "id" value used in this calculation MUST be the EAP 514 Identifier field from the EAP SRP-SHA1 Challenge (Subtype 1) 515 Request message. The single octet "Type" value is a copy of the 516 EAP Type field, which is fixed at 19 (decimal). 518 Hidden Pseudonym 520 This optional field is described in section 3. The Hidden 521 Pseudonym field extends to the end of the message as indicated by 522 the EAP Length field. 524 2.7. EAP SRP-SHA1 Subtype 3 Response 526 The authenticatee MUST transmit a EAP SRP-SHA1 Subtype 3 Response 527 message in reply to a valid Server Validator message from the peer. 528 This Response message has no Subtype-Data field. The Code (2), Iden- 529 tifier, Length (6), Type (19), and Subtype (3) fields are as 530 described above. 532 2.8. EAP SRP-SHA1 Lightweight Challenge Subtype-Data 534 The EAP SRP-SHA1 Lightweight Challenge (Subtype 4 Request) message 535 MAY be used by the authenticator for periodic rechallenges at any 536 time after EAP authentication is complete. 538 After rechallenge with this mechanism, the shared session key remains 539 unchanged. This property may be useful when this key is used with 540 ECP, because regular reauthentication (starting with a new Subtype 1 541 Request) will change the key. This mechanism may also be useful with 542 external security servers, because the NAS can implement this feature 543 without making additional queries to the server if the server sup- 544 plies the K value. 546 A summary of the EAP SRP-SHA1 Lightweight Challenge Subtype-Data for- 547 mat is shown below. Code (1), Identifier, Length, Type (19), and 548 Subtype (4) fields are as described above. The fields are transmit- 549 ted from left to right. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Challenge ... 555 +-+-+-+-+-+-+-+-+-+-+- 557 Challenge 559 The Challenge value is a sequence of random data. This field MAY 560 be any length up to the MTU, but MUST be at least four octets. 561 The authenticatee MUST NOT reply if the Challenge field is too 562 short. 564 2.9. EAP SRP-SHA1 Lightweight Response Subtype-Data 566 The EAP SRP-SHA1 Lightweight Response (Subtype 4 Response) message 567 SHOULD be sent by the authenticatee in response to a Lightweight 568 Challenge message. The authenticatee MAY instead use EAP Nak with 569 Type-Data set to 19 (EAP SRP-SHA1) to restart full SRP authentica- 570 tion. 572 The authenticator MUST take action to disconnect or disable the ses- 573 sion if the Lightweight Response value is invalid or if a preset 574 number of Lightweight Challenge messages are sent without a valid 575 response. 577 A summary of the EAP SRP-SHA1 Lightweight Response Subtype-Data for- 578 mat is shown below. Code (2), Identifier, Length (26), Type (19), 579 and Subtype (4) fields are as described above. The fields are 580 transmitted from left to right. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Response | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Response (continued) | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Response (continued) | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Response (continued) | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Response (continued) | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Response 598 The Response value is calculated as SHA1(id, K, Challenge, 599 clientname). 601 3. Identity Privacy Support 603 The optional Hidden Pseudonym field in the Subtype 3 Request message 604 is generated by server in two steps. In the first step, the server 605 produces a pseudonym in an implementation-dependent manner. In the 606 second step, the pseudonym is obscured for communication to the 607 client. 609 3.1. Step One 611 Because this step needs to be reversible only on the server, any con- 612 venient method MAY be used, although use of either one of the two 613 methods outlined here is suggested. Regardless of construction 614 method, the pseudonym constructed by the server MUST conform to the 615 grammar specified for the "username" portion of an NAI, as specified 616 in [RFC2486]. 618 3.1.1. Method A 620 The server constructs a padded client name string by prepending the 621 length of the client name in bytes to the client name, and pads to 622 the next 8 octet boundary with random data (the "|" operator 623 represents concatenation): 625 paddedname = length(clientname) | clientname | random{0..7} 627 A 56 bit key is then generated from a locally-stored password and the 628 current date (to the nearest day) by extracting the first 56 bits 629 from the result of SHA1(local-password, date-string). The paddedname 630 is then encrypted using DES [FIPS46] with this key. The encrypted 631 result is converted to a printable string using the BASE64 method 632 described in section 4.3.2.4 of [RFC1421], but without the '=' pad- 633 ding. This string is the pseudonym used in Step Two below. 635 If the client name is an NAI and this is known to the server, then 636 the realm SHOULD be removed to limit the string length. The realm 637 will be supplied by the client when the pseudonym is used. 639 The advantages of this method are that the server need not store the 640 generated pseudonym because it can always decrypt the value provided 641 by the client, the generated pseudonym for a given client changes 642 frequently because of the use of the date in the hash, and previous 643 pseudonyms are always usable because prior dates can be tested as 644 well. The disadvantage is that it requires the use of reversible 645 encryption. 647 3.1.2. Method B 649 The server generates a random value (a nonce) and converts it to a 650 printable string as in method A. The server MUST store a copy of 651 this value in stable storage and relate it to the true client iden- 652 tity. 654 The advantages of this method are that the pseudonym changes with 655 every connection and DES is not required. The disadvantage is that 656 stable storage is required. 658 3.2. Step Two 660 The pseudonym is communicated to the client using a hiding mechanism 661 relying on the session key so that the client can undo the hiding. 662 Because this operation must be reversible on the client side, the 663 server MUST use the method described here (based on [KPS]) for this 664 step. The length of the pseudonym from Step One is prepended as a 665 single octet to the front of the pseudonym and random octets are 666 appended to pad the data to the next 20 octet boundary: 668 value = length(pseudonym) | pseudonym | random{0..19} 670 The Hidden Pseudonym for the Server Validator message is then calcu- 671 lated by breaking the value above into a sequence of 20 octet seg- 672 ments (v[1] through v[n]): 674 hpn[1] = SHA1(id, K, clientname) ^ v[1] 675 hpn[2] = SHA1(id, K, hpn[1]) ^ v[2] 676 hpn[3] = SHA1(id, K, hpn[2]) ^ v[3] 677 ... 679 The "id" number is the EAP Identifier octet for Subtype 3 Request. 680 The hpn[1] through hpn[n] values are then concatenated to form the 681 Hidden Pseudonym. On reception of the Server Validator, the client 682 undoes this hiding. It calculates: 684 v[1] = SHA1(id, K, clientname) ^ hpn[1] 685 v[2] = SHA1(id, K, hpn[1]) ^ hpn[2] 686 ... 688 The client extracts the decoded pseudonym from the v[1] through v[n] 689 sequence, and saves it in stable storage. The client MUST discard 690 the pseudonym if the length octet is invalid; either greater than the 691 remaining length of the unhidden value or 20 or more octets less than 692 that length. 694 3.3. Using the Pseudonym 696 On the next connection to the server, the client SHOULD transmit the 697 stored pseudonym in response to the first received EAP Identity 698 request. In order to do this, it MUST concatenate three strings, as 699 follows: 701 identity = "pseudo_" | pseudonym | realm 703 The first string is the constant 7 character string "pseudo_". This 704 string allows the server to identify this name as a pseudonym. The 705 second string is the stored pseudonym itself. The third string is 706 the NAI separator ("@") and realm, if any, as specified by an 707 administrator. The client's user interface SHOULD allow the user to 708 specify the NAI user name and realm as separate values if the pseu- 709 donym feature is supported. 711 The server, on finding the peer name starting with "pseudo_", 712 attempts to decode it in an implementation-dependent manner. If 713 Method A was chosen in Step One, then this consists of generating DES 714 keys with the current date as well as several prior dates, and 715 attempting to decrypt with each of those keys, only one of which will 716 result in a usable client name. If Method B was chosen, then the 717 server looks up the pseudonym in the local storage to find the 718 corresponding client. 720 If decoding to the padded client name fails or does not result in a 721 known client name, then the server requests the regular (non- 722 pseudonym) identity by resending the EAP Identity request with a new 723 (changed) ID number. The client MUST distinguish between retransmis- 724 sions of the EAP Identity request, which will have the same ID 725 number, and for which the pseudonym MAY be sent, and a new EAP Iden- 726 tity request, which will have a different ID number, and for which 727 the client's actual name MUST be sent. The server MUST NOT allow the 728 use of a pseudonym in reply to its resent request, because the client 729 is required to supply its actual name. 731 As an implementation option, the client may wish to support only 732 obscured connections when possible. In this case, the client SHOULD 733 have a boolean flag for "use private connections when possible." If 734 the server does not offer a pseudonym, then the flag is ignored. If 735 the server does offer a pseudonym, then the client MUST disconnect or 736 disable the link if it has used its actual name for EAP Identity and 737 reconnect after a random interval. This option SHOULD be disabled 738 and an administrator notified if use of a pseudonym fails more than 739 once, in order to prevent loss of functionality. 741 4. Use with ECP 743 The 40 octet shared key ('K') calculated by the SRP-SHA1 authentica- 744 tion procedure MUST be used to form encryption keys as described in 745 this section if PPP encryption is in use and the E bits in both the 746 Client Validator and the Server Validator messages were set. 748 For the DESEbis [RFC2419] algorithm, a shared 56 bit key is neces- 749 sary, and for the 3DES [RFC2420] algorithm, a shared 168 bit key is 750 required. Complicating this, ECP may be negotiated in only one 751 direction or both. In addition, PPP authentication may be performed 752 one-way (the most common case) or mutually, and when mutual authenti- 753 cation is chosen, different authentication schemes may be used to 754 authenticate each peer. The effects of these details are described 755 below. 757 The "decryptor" is the peer that sends ECP Configure-Request suggest- 758 ing an algorithm and receives a corresponding ECP Configure-Ack. The 759 "encryptor" is the sender of the ECP Configure-Ack, and will transmit 760 the encrypted data. 762 Rekeying can be accomplished at any time by restarting EAP authenti- 763 cation. When rekeying, the decryptor SHOULD accept data encrypted 764 with the prior key until the Subtype 3 Response is sent. The encryp- 765 tor SHOULD suspend data transmission, if possible, when the Subtype 3 766 Request is sent and resume after Subtype 3 Response. 768 4.1. One-Way Versus Bidirectional Encryption 770 ECP may be negotiated in one direction on the link, or in both direc- 771 tions. For each separate ECP session, the K value that is chosen for 772 the shared key should be the value associated with the EAP SRP-SHA1 773 authentication in which the decryptor is the authenticator. If the 774 decryptor was not an EAP SRP-SHA1 authenticator, then the K value 775 associated with the other EAP SRP-SHA1 authentication session is used 776 instead as described in the next section. 778 4.2. One-Way Versus Mutual Authentication 780 If only one peer authenticates the other using SRP-SHA1, and the 781 other either does not authenticate its peer at all or uses a method 782 that does not result in encryption keys, then the one K value associ- 783 ated with this authentication MUST be used for both encryption ses- 784 sions. The first 20 octets of K are used for the encryption of data 785 sent by the authenticatee to the authenticator, and the second 20 786 octets of K are used for encryption of data in the opposite direc- 787 tion. 789 If mutual authentication with algorithms that produce encryption keys 790 is done, such as SRP-SHA1, then two K values are produced. As 791 described above, the K values are used so that the encryptor is the 792 authenticatee for the corresponding authentication session, and the 793 decryptor is the authenticator. 795 4.3. DESEbis Versus 3DES 797 For DESEbis, the first 8 octets of the key value are used. DES keys 798 are constructed such that the most significant bit (MSB) of each 799 octet is reserved for parity, and must be discarded. 801 For 3DES, 24 octets of key value are used by most implementations. 802 As for DESEbis, the MSBs are discarded. If the 40 octet K value has 803 been split into two 20 octet values because one-way authentication is 804 in use, then an extra 4 octets are needed for each key. The SHA-1 805 algorithm is run again over the 40 octet K value to produce a 20 806 octet hash. This hash is split into two 10 octet values that are 807 then appended to the two 20 octet values from the split K value. The 808 first 24 octets of each 30 octet value is used as the 3DES key. 810 5. Use with AAA 812 The SRP exchange uses the client name as part of the calculation, and 813 thus depends on leaving this string unmodified between the authenti- 814 catee and authenticator. If a mechanism, such as a AAA protocol, is 815 used to perform the SRP authentication on behalf of a Network Access 816 Server (NAS), then the client name MUST be identical on both ends. 817 In particular, if a Network Access Identifier [RFC2486] is used with 818 a proxy authentication server, then the implementor MUST take steps 819 to preserve the client name string end-to-end. 821 Use of a AAA protocol also makes the use of the session key (K) for 822 ECP keying problematic, because the contents of this key are avail- 823 able only at the authentication endpoints (where SRP is run), and not 824 the link layer endpoints (where ECP is run). 826 For RADIUS [RFC2138], no common method exists to transfer the session 827 key to the NAS, but some implementations are known to have 828 proprietary extensions for this purpose. If such an extension is 829 available, it SHOULD be used to transfer the key and the Server Vali- 830 dator E bit MUST then be set to 1. Otherwise, if the extension is 831 not available, then the E bit MUST be cleared to 0. 833 For other AAA protocols, encryption session key transfer SHOULD be 834 used to send K to the NAS. 836 Use of a directory access protocol for the hash values, rather than a 837 AAA protocol, would also solve this problem. Such usage is outside 838 the scope of this document. 840 6. Examples 842 6.1. Successful Authentication 844 In the case where the EAP SRP-SHA1 authentication is successful, the 845 conversation may appear as follows: 847 Authenticatee Authenticator 848 ----------------------- ------------------------------------------- 849 <- EAP-Request id=100 / Identity 850 EAP-Response id=100 / 851 Identity ("MyName") -> 852 <- EAP-Request id=101 / SRP-SHA1 853 Subtype 1 ("TheServer", salt, generator, 854 modulus) 855 EAP-Response id=101 / 856 SRP-SHA1 Subtype 1 857 (A) -> 858 <- EAP-Request id=102 / SRP-SHA1 859 Subtype 2 (B) 860 EAP-Response id=102 / 861 SRP-SHA1 Subtype 2 862 (E, M1) -> 863 <- EAP-Request id=103 / SRP-SHA1 864 Subtype 3 (E, M2, hidden-pseudonym) 865 EAP-Response id=103 / 866 SRP-SHA1 Subtype 3 -> 867 <- EAP-Success id=104 869 Note that M1 and M2 were calculated with "id" set to 101, the EAP 870 Identifier field for the Subtype 1 Request. The id is shown as an 871 integer that increments by 1 for each EAP Request, but this is not 872 required. Any values MAY be used, provided that repetition is minim- 873 ized. 875 6.2. Client Unauthenticated 877 In the case where the client fails to authenticate to the server, the 878 conversation may appear as follows: 880 Authenticatee Authenticator 881 ----------------------- ------------------------------------------- 882 <- EAP-Request id=50 / Identity 883 EAP-Response id=50 / 884 Identity ("MyName") -> 885 <- EAP-Request id=51 / SRP-SHA1 886 Subtype 1 ("TheServer", salt, generator, 887 modulus) 888 EAP-Response id=51 / 889 SRP-SHA1 Subtype 1 890 (A) -> 891 <- EAP-Request id=52 / SRP-SHA1 892 Subtype 2 (B) 893 EAP-Response id=52 / 894 SRP-SHA1 Subtype 2 895 (E, M1) -> 896 <- EAP-Failure id=53 898 (At its option, the authenticator MAY choose to send a false Subtype 899 3 message with a random number in place of M2, followed by EAP 900 Failure. Doing so limits the amount of information that an attacker 901 has available.) 903 6.3. Server Unverified 905 In the case where the client's verification of the server is unsuc- 906 cessful, the conversation will appear as follows: 908 Authenticatee Authenticator 909 ----------------------- ------------------------------------------- 910 <- EAP-Request id=75 / Identity 911 EAP-Response id=75 / 912 Identity ("MyName") -> 913 <- EAP-Request id=76 / SRP-SHA1 914 Subtype 1 ("TheServer", salt, generator, 915 modulus) 916 EAP-Response id=76 / 917 SRP-SHA1 Subtype 1 918 (A) -> 919 <- EAP-Request id=77 / SRP-SHA1 920 Subtype 2 (B) 921 EAP-Response id=77 / 922 SRP-SHA1 Subtype 2 923 (E, M1) -> 924 <- EAP-Request id=78 / SRP-SHA1 925 Subtype 3 (E, M2, hidden-pseudonym) 926 [Disconnect] -> 928 (The "disconnect" operation is medium-dependent. On a PPP link, it 929 consists of sending LCP Terminate-Request followed by sending a Close 930 event to the physical layer.) 932 7. Security Considerations 934 EAP SRP-SHA1 is a security protocol. 936 The security of SRP on the wire relies on having a prime modulus that 937 is large enough to make brute force attack of the key exchange 938 infeasible. A length of at least 1024 bits is recommended. In addi- 939 tion, the SRP document [RFC2945] describes tests that MUST be per- 940 formed on the chosen modulus and generator values and random numbers. 941 SRP is a significant improvement over the situation with PAP, which 942 has no on-the-wire security, and with CHAP, which is vulnerable to 943 dictionary attacks against a captured Challenge/Response pair. 945 The security of the credentials stored in the authenticator's data- 946 base relies on the entropy in the chosen password, the difficulty of 947 hash inversion of a salted string, and the security of the system 948 containing the database. For this reason, the chosen password SHOULD 949 be restricted to limit the effectiveness of dictionary attacks 950 against a disclosed database. However, since typical passwords have 951 only a few bits of entropy, the database itself MUST be protected 952 against disclosure. 954 The method used to hide the pseudonym has not be subjected to 955 rigorous analysis, but is believed to be sufficient for the task. 956 Because the outer layer of hiding must be decoded by the authenti- 957 catee, and interception of this information would link one session to 958 another, it is not believed that stronger methods for the inner layer 959 are useful. If strong identity privacy is a concern, this mechanism 960 should not be used. 962 8. Intellectual Property Rights Notices 964 8.1. Patent Issues 966 The SRP key-exchange protocol described in this document is available 967 worldwide on a royalty-free basis for commercial and non-commercial 968 uses. This specifically includes simultaneous bidirectional use of 969 SRP, which is distinct from SRP-Z. No usage of SRP-Z is described in 970 this document. 972 "The IETF takes no position regarding the validity or scope of 973 any intellectual property or other rights that might be claimed 974 to pertain to the implementation or use of the technology 975 described in this document or the extent to which any license 976 under such rights might or might not be available; neither does 977 it represent that it has made any effort to identify any such 978 rights. Information on the IETF's procedures with respect to 979 rights in standards-track and standards-related documentation 980 can be found in BCP-11. Copies of claims of rights made 981 available for publication and any assurances of licenses to 982 be made available, or the result of an attempt made 983 to obtain a general license or permission for the use of such 984 proprietary rights by implementors or users of this 985 specification can be obtained from the IETF Secretariat." 987 "The IETF invites any interested party to bring to its 988 attention any copyrights, patents or patent applications, or 989 other proprietary rights which may cover technology that may be 990 required to practice this standard. Please address the 991 information to the IETF Executive Director." 993 8.2. Full Copyright Statement 995 "Copyright (C) The Internet Society 2001. All Rights 996 Reserved. 998 This document and translations of it may be copied and 999 furnished to others, and derivative works that comment on or 1000 otherwise explain it or assist in its implementation may be 1001 prepared, copied, published and distributed, in whole or in 1002 part, without restriction of any kind, provided that the above 1003 copyright notice and this paragraph are included on all such 1004 copies and derivative works. However, this document itself may 1005 not be modified in any way, such as by removing the copyright 1006 notice or references to the Internet Society or other Internet 1007 organizations, except as needed for the purpose of developing 1008 Internet standards in which case the procedures for copyrights 1009 defined in the Internet Standards process must be followed, or 1010 as required to translate it into languages other than English. 1012 The limited permissions granted above are perpetual and will 1013 not be revoked by the Internet Society or its successors or 1014 assigns. 1016 This document and the information contained herein is provided 1017 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1018 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1019 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1020 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1021 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1022 PARTICULAR PURPOSE." 1024 9. References 1026 9.1. Normative References 1028 [RFC2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication 1029 Protocol (EAP)," RFC 2284, March 1998 1031 [RFC2945] T. Wu, "The SRP Authentication and Key Exchange System," 1032 RFC 2945, September 2000 1034 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)," RFC 1661, 1035 July 1994 1037 [FIPS180] National Institute of Standards and Technology (NIST), 1038 "Announcing the Secure Hash Standard," FIPS 180-1, U.S. 1039 Department of Commerce, April 1995 1041 9.2. Informative References 1043 [RFC1334] B. Lloyd, W. Simpson, "PPP Authentication Protocols," RFC 1044 1334, October 1992 1046 [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication 1047 Protocol (CHAP)," RFC 1994, August 1996 1049 [RFC2433] G. Zorn, S. Cobb, "Microsoft PPP CHAP Extensions," RFC 1050 2433, October 1998 1052 [RFC2759] G. Zorn, "Microsoft PPP CHAP Extensions, Version 2," RFC 1053 2759, January 2000 1055 [RFC1968] G. Meyer, "The PPP Encryption Control Protocol (ECP)," RFC 1056 1968, June 1996 1058 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1059 Requirement Levels," BCP 14 and RFC 2119, March 1997 1061 [SRP] T. Wu, "The Secure Remote Password Protocol", Proceedings 1062 of the 1998 Internet Society Symposium on Network and 1063 Distributed Systems Security, San Diego, CA, pp. 97-111 1065 [RFC2486] B. Aboba, M. Beadles, "The Network Access Identifier," RFC 1066 2486, January 1999 1068 [FIPS46] National Bureau of Standards, "Data Encryption Standard", 1069 FIPS PUB 46, January 1977 1071 [RFC1421] J. Linn, "Privacy Enhancement for Internet Electronic 1072 Mail: Part I: Message Encryption and Authentication 1073 Procedures," RFC 1421, February 1993 1075 [KPS] C. Kaufman, R. Perlman, and M. Speciner, "Network 1076 Security: Private Communications in a Public World," 1077 Prentice Hall, ISBN 0-13-061466-1, March 1995 1079 [RFC2419] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol, 1080 Version 2 (DESE-bis)," RFC 2419, September 1998 1082 [RFC2420] H. Kummert, "The PPP Triple-DES Encryption Protocol 1083 (3DESE)," RFC 2420, September 1998 1085 [RFC2138] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote 1086 Authentication Dial In User Service (RADIUS)", RFC 2138, 1087 April 1997 1089 10. Acknowledgements 1091 The authors are grateful for the many critiques and ideas offered on 1092 the IETF PPP Extensions mailing list and by private mail. In partic- 1093 ular, we thank N. Asokan, Jacques Caron, and Vernon Schryver. 1095 The hiding method used for the pseudonym was adapted from RFCs 2661 1096 and 2138, both of which were based on the "Mixing in the Plaintext" 1097 section in the book "Network Security" by Kaufman, Perlman and 1098 Speciner [KPS]. 1100 11. Authors' Addresses 1102 James Carlson 1103 Sun Microsystems 1104 1 Network Drive MS UBUR02-212 1105 Burlington MA 01803-2757 1106 Email: james.d.carlson@sun.com 1107 Phone: +1 781 442 2084 1108 Fax: +1 781 442 1677 1110 Bernard Aboba 1111 Microsoft Corporation 1112 One Microsoft Way 1113 Redmond WA 98052 1114 Email: bernarda@microsoft.com 1115 Phone: +1 425 936 6605 1116 Henry Haverinen 1117 Nokia Mobile Phones 1118 P.O. Box 88 1119 FIN-33721 Tampere 1120 Finland 1121 Email: henry.haverinen@nokia.com 1122 Phone: +358 50 594 4899 1123 Fax: +358 3 318 3690 1125 12. Appendix A - Well-Known Prime Modulus 1127 This 2048 bit prime modulus (and corresponding generator value 2) are 1128 borrowed from the SRP GSS-API mechanism, an IETF work in progress. 1130 0xAC, 0x6B, 0xDB, 0x41, 0x32, 0x4A, 0x9A, 0x9B, 1131 0xF1, 0x66, 0xDE, 0x5E, 0x13, 0x89, 0x58, 0x2F, 1132 0xAF, 0x72, 0xB6, 0x65, 0x19, 0x87, 0xEE, 0x07, 1133 0xFC, 0x31, 0x92, 0x94, 0x3D, 0xB5, 0x60, 0x50, 1134 0xA3, 0x73, 0x29, 0xCB, 0xB4, 0xA0, 0x99, 0xED, 1135 0x81, 0x93, 0xE0, 0x75, 0x77, 0x67, 0xA1, 0x3D, 1136 0xD5, 0x23, 0x12, 0xAB, 0x4B, 0x03, 0x31, 0x0D, 1137 0xCD, 0x7F, 0x48, 0xA9, 0xDA, 0x04, 0xFD, 0x50, 1138 0xE8, 0x08, 0x39, 0x69, 0xED, 0xB7, 0x67, 0xB0, 1139 0xCF, 0x60, 0x95, 0x17, 0x9A, 0x16, 0x3A, 0xB3, 1140 0x66, 0x1A, 0x05, 0xFB, 0xD5, 0xFA, 0xAA, 0xE8, 1141 0x29, 0x18, 0xA9, 0x96, 0x2F, 0x0B, 0x93, 0xB8, 1142 0x55, 0xF9, 0x79, 0x93, 0xEC, 0x97, 0x5E, 0xEA, 1143 0xA8, 0x0D, 0x74, 0x0A, 0xDB, 0xF4, 0xFF, 0x74, 1144 0x73, 0x59, 0xD0, 0x41, 0xD5, 0xC3, 0x3E, 0xA7, 1145 0x1D, 0x28, 0x1E, 0x44, 0x6B, 0x14, 0x77, 0x3B, 1146 0xCA, 0x97, 0xB4, 0x3A, 0x23, 0xFB, 0x80, 0x16, 1147 0x76, 0xBD, 0x20, 0x7A, 0x43, 0x6C, 0x64, 0x81, 1148 0xF1, 0xD2, 0xB9, 0x07, 0x87, 0x17, 0x46, 0x1A, 1149 0x5B, 0x9D, 0x32, 0xE6, 0x88, 0xF8, 0x77, 0x48, 1150 0x54, 0x45, 0x23, 0xB5, 0x24, 0xB0, 0xD5, 0x7D, 1151 0x5E, 0xA7, 0x7A, 0x27, 0x75, 0xD2, 0xEC, 0xFA, 1152 0x03, 0x2C, 0xFB, 0xDB, 0xF5, 0x2F, 0xB3, 0x78, 1153 0x61, 0x60, 0x27, 0x90, 0x04, 0xE5, 0x7A, 0xE6, 1154 0xAF, 0x87, 0x4E, 0x73, 0x03, 0xCE, 0x53, 0x29, 1155 0x9C, 0xCC, 0x04, 0x1C, 0x7B, 0xC3, 0x08, 0xD8, 1156 0x2A, 0x56, 0x98, 0xF3, 0xA8, 0xD0, 0xC3, 0x82, 1157 0x71, 0xAE, 0x35, 0xF8, 0xE9, 0xDB, 0xFB, 0xB6, 1158 0x94, 0xB5, 0xC8, 0x03, 0xD8, 0x9F, 0x7A, 0xE4, 1159 0x35, 0xDE, 0x23, 0x6D, 0x52, 0x5F, 0x54, 0x75, 1160 0x9B, 0x65, 0xE3, 0x72, 0xFC, 0xD6, 0x8E, 0xF2, 1161 0x0F, 0xA7, 0x11, 0x1F, 0x9E, 0x4A, 0xFF, 0x73