idnits 2.17.1 draft-ietf-pppext-chap-ds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 60: '...ed, an implementation MUST specify the...' RFC 2119 keyword, line 80: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 83: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 86: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 92: '... MAY This word, or the adjecti...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10388 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '8' is mentioned on line 244, but not defined == Missing Reference: '9' is mentioned on line 246, but not defined ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') ** Downref: Normative reference to an Historic RFC: RFC 1352 (ref. '4') Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson 3 Internet Draft DayDreamer 4 expires in six months November 1995 6 PPP Challenge Handshake Authentication Protocol (CHAP) 7 draft-ietf-pppext-chap-ds-00.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months, and may be updated, replaced, or obsoleted by other documents 24 at any time. It is not appropriate to use Internet Drafts as 25 reference material, or to cite them other than as a ``working draft'' 26 or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 30 Directories on: 32 ftp.is.co.za (Africa) 33 nic.nordu.net (Europe) 34 ds.internic.net (US East Coast) 35 ftp.isi.edu (US West Coast) 36 munnari.oz.au (Pacific Rim) 38 Abstract 40 The Point-to-Point Protocol (PPP) [1] provides a standard method for 41 transporting multi-protocol datagrams over point-to-point links. 43 PPP also defines an extensible Link Control Protocol, which allows 44 negotiation of an Authentication Protocol for authenticating its peer 45 before allowing Network Layer protocols to transmit over the link. 47 This document defines a method for Authentication using PPP, which 48 uses a random Challenge, with a cryptographically hashed Response 49 which depends upon the Challenge and a secret key. 51 1. Introduction 53 In order to establish communications over a point-to-point link, each 54 end of the PPP link must first send LCP packets to configure the data 55 link during Link Establishment phase. After the link has been 56 established, PPP provides for an optional Authentication phase before 57 proceeding to the Network-Layer Protocol phase. 59 By default, authentication is not mandatory. If authentication of 60 the link is desired, an implementation MUST specify the 61 Authentication-Protocol Configuration Option during Link 62 Establishment phase. 64 These authentication protocols are intended for use primarily by 65 hosts and routers that connect to a PPP network server via switched 66 circuits or dial-up lines, but might be applied to dedicated links as 67 well. The server can use the identification of the connecting host 68 or router in the selection of options for network layer negotiations. 70 This document defines the PPP authentication protocols. The Link 71 Establishment and Authentication phases, and the Authentication- 72 Protocol Configuration Option, are defined in The Point-to-Point 73 Protocol (PPP) [1]. 75 1.1. Specification of Requirements 77 In this document, several words are used to signify the requirements 78 of the specification. These words are often capitalized. 80 MUST This word, or the adjective "required", means that the 81 definition is an absolute requirement of the specification. 83 MUST NOT This phrase means that the definition is an absolute 84 prohibition of the specification. 86 SHOULD This word, or the adjective "recommended", means that there 87 may exist valid reasons in particular circumstances to 88 ignore this item, but the full implications must be 89 understood and carefully weighed before choosing a 90 different course. 92 MAY This word, or the adjective "optional", means that this 93 item is one of an allowed set of alternatives. An 94 implementation which does not include this option MUST be 95 prepared to interoperate with another implementation which 96 does include the option. 98 1.2. Terminology 100 This document frequently uses the following terms: 102 authenticator 103 The end of the link requiring the authentication. The 104 authenticator specifies the authentication protocol to be 105 used in the Configure-Request during Link Establishment 106 phase. 108 peer The other end of the point-to-point link; the end which is 109 being authenticated by the authenticator. 111 silently discard 112 This means the implementation discards the packet without 113 further processing. The implementation SHOULD provide the 114 capability of logging the error, including the contents of 115 the silently discarded packet, and SHOULD record the event 116 in a statistics counter. 118 2. Challenge-Handshake Authentication Protocol 120 The Challenge-Handshake Authentication Protocol (CHAP) is used to 121 periodically verify the identity of the peer using a 3-way handshake. 122 This is done upon initial link establishment, and MAY be repeated 123 anytime after the link has been established. 125 1. After the Link Establishment phase is complete, the 126 authenticator sends a "challenge" message to the peer. 128 2. The peer responds with a value calculated using a "one-way 129 hash" function. 131 3. The authenticator checks the response against its own 132 calculation of the expected hash value. If the values match, 133 the authentication is acknowledged; otherwise the connection 134 SHOULD be terminated. 136 4. At random intervals, the authenticator sends a new challenge to 137 the peer, and repeats steps 1 to 3. 139 Advantages 141 CHAP provides protection against playback attack by the peer through 142 the use of an incrementally changing identifier and a variable 143 challenge value. The use of repeated challenges is intended to limit 144 the time of exposure to any single attack. The authenticator is in 145 control of the frequency and timing of the challenges. 147 This authentication method depends upon a "secret" known only to the 148 authenticator and that peer. The secret is not sent over the link. 150 Although the authentication is only one-way, by negotiating CHAP in 151 both directions the same secret set may easily be used for mutual 152 authentication. 154 Since CHAP may be used to authenticate many different systems, name 155 fields may be used as an index to locate the proper secret in a large 156 table of secrets. This also makes it possible to support more than 157 one name/secret pair per system, and to change the secret in use at 158 any time during the session. 160 Disadvantages 162 CHAP requires that the secret be available in plaintext form. 163 Irreversably encrypted password databases commonly available cannot 164 be used. 166 It is not as useful for large installations, since every possible 167 secret is maintained at both ends of the link. 169 Implementation Note: To avoid sending the secret over other links 170 in the network, it is recommended that the challenge and response 171 values be examined at a central server, rather than each network 172 access server. Otherwise, the secret SHOULD be sent to such 173 servers in a reversably encrypted form. Either case requires a 174 trusted relationship, which is outside the scope of this 175 specification. 177 Design Requirements 179 The CHAP algorithm requires that the length of the secret MUST be at 180 least 1 octet. The secret SHOULD be at least as large and 181 unguessable as a well-chosen password. It is preferred that the 182 secret be at least the length of the hash value for the hashing 183 algorithm chosen (16 octets for MD5). This is to ensure a 184 sufficiently large range for the secret to provide protection against 185 exhaustive search attacks. 187 The one-way hash algorithm is chosen such that it is computationally 188 infeasible to determine the secret from the known challenge and 189 response values. 191 Each challenge value SHOULD be unique, since repetition of a 192 challenge value in conjunction with the same secret would permit an 193 attacker to reply with a previously intercepted response. Since it 194 is expected that the same secret MAY be used to authenticate with 195 servers in disparate geographic regions, the challenge SHOULD exhibit 196 global and temporal uniqueness. 198 Each challenge value SHOULD also be unpredictable, least an attacker 199 trick a peer into responding to a predicted future challenge, and 200 then use the response to masquerade as that peer to an authenticator. 202 Although protocols such as CHAP are incapable of protecting against 203 realtime active wiretapping attacks, generation of unique 204 unpredictable challenges can protect against a wide range of active 205 attacks. 207 A discussion of sources of uniqueness and probability of divergence 208 is included in the Magic-Number Configuration Option [1]. 210 2.1. Configuration Option Format 212 A summary of the Authentication-Protocol Configuration Option format 213 to negotiate the Challenge-Handshake Authentication Protocol is shown 214 below. The fields are transmitted from left to right. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Length | Authentication-Protocol | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Algorithm | 222 +-+-+-+-+-+-+-+-+ 224 Type 226 3 228 Length 230 5 232 Authentication-Protocol 234 c223 (hex) for Challenge-Handshake Authentication Protocol. 236 Algorithm 238 The Algorithm field is one octet and indicates the authentication 239 method to be used. Up-to-date values of the CHAP Algorithm field 240 are specified in the most recent "Assigned Numbers" RFC [2]. 241 Current values are assigned as follows: 243 0 unused (reserved) 244 1 SKAP with Kerberos tickets [8] 245 2 unused (reserved) 246 3 SKAP with X.509 Certificates [9] 247 4 unused (reserved) 248 5 CHAP with MD5 [3] 250 2.2. Packet Format 252 Exactly one Challenge-Handshake Authentication Protocol packet is 253 encapsulated in the Information field of a PPP Data Link Layer frame 254 where the protocol field indicates type hex c223 (Challenge-Handshake 255 Authentication Protocol). A summary of the CHAP packet format is 256 shown below. The fields are transmitted from left to right. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Code | Identifier | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Data ... 264 +-+-+-+-+ 266 Code 268 The Code field is one octet and identifies the type of CHAP 269 packet. CHAP Codes are assigned as follows: 271 1 Challenge 272 2 Response 273 3 Success 274 4 Failure 276 Identifier 278 The Identifier field is one octet and aids in matching challenges, 279 responses and replies. 281 Length 283 The Length field is two octets and indicates the length of the 284 CHAP packet including the Code, Identifier, Length and Data 285 fields. Octets outside the range of the Length field should be 286 treated as Data Link Layer padding and should be ignored on 287 reception. 289 Data 291 The Data field is zero or more octets. The format of the Data 292 field is determined by the Code field. 294 2.2.1. Challenge and Response 296 Description 298 The Challenge packet is used to begin the Challenge-Handshake 299 Authentication Protocol. The authenticator MUST transmit a CHAP 300 packet with the Code field set to 1 (Challenge). Additional 301 Challenge packets MUST be sent until a valid Response packet is 302 received, or an optional retry counter expires. 304 A Challenge packet MAY also be transmitted at any time during the 305 Network-Layer Protocol phase to ensure that the connection has not 306 been altered. 308 The peer SHOULD expect Challenge packets during the Authentication 309 phase and the Network-Layer Protocol phase. Whenever a Challenge 310 packet is received, the peer MUST transmit a CHAP packet with the 311 Code field set to 2 (Response). 313 Whenever a Response packet is received, the authenticator compares 314 the Response Value with its own calculation of the expected value. 315 Based on this comparison, the authenticator MUST send a Success or 316 Failure packet (described below). 318 Implementation Note: Because the Success might be lost, the 319 authenticator MUST allow repeated Response packets after 320 completing the Authentication phase. To prevent discovery of 321 alternative Names and Secrets, any Response packets received 322 having the current Challenge Identifier MUST return the same 323 reply Code returned when the Authentication phase completed 324 (the message portion MAY be different). Any Response packets 325 received during any other phase MUST be silently discarded. 327 When the Failure is lost, and the authenticator terminates the 328 link, the LCP Terminate-Request and Terminate-Ack provide an 329 alternative indication that authentication failed. 331 A summary of the Challenge and Response packet format is shown below. 332 The fields are transmitted from left to right. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Code | Identifier | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Value-Size | Value ... 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Name ... 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Code 346 1 for Challenge; 348 2 for Response. 350 Identifier 352 The Identifier field is one octet. The Identifier field MUST be 353 changed each time a Challenge is sent. 355 The Response Identifier MUST be copied from the Identifier field 356 of the Challenge which caused the Response. 358 Value-Size 360 This field is one octet and indicates the length of the Value 361 field. 363 Value 365 The Value field is one or more octets. The most significant octet 366 is transmitted first. 368 The Challenge Value is a variable stream of octets. The 369 importance of the uniqueness of the Challenge Value and its 370 relationship to the secret is described above. The Challenge 371 Value MUST be changed each time a Challenge is sent. The length 372 of the Challenge Value depends upon the method used to generate 373 the octets, and is independent of the hash algorithm used. 375 The Response Value is the one-way hash calculated over a stream of 376 octets consisting of the Identifier, followed by (concatenated 377 with) the "secret", followed by (concatenated with) the Challenge 378 Value. The length of the Response Value depends upon the hash 379 algorithm used (16 octets for MD5). 381 Name 383 The Name field is one or more octets representing the 384 identification of the system transmitting the packet. There are 385 no limitations on the content of this field. For example, it MAY 386 contain ASCII character strings or globally unique identifiers in 387 ASN.1 syntax. The Name should not be NUL or CR/LF terminated. 388 The size is determined from the Length field. 390 2.2.2. Success and Failure 392 Description 394 If the Value received in a Response is equal to the expected 395 value, then the implementation MUST transmit a CHAP packet with 396 the Code field set to 3 (Success). 398 If the Value received in a Response is not equal to the expected 399 value, then the implementation MUST transmit a CHAP packet with 400 the Code field set to 4 (Failure), and SHOULD take action to 401 terminate the link. 403 A summary of the Success and Failure packet format is shown below. 404 The fields are transmitted from left to right. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Code | Identifier | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Message ... 412 +-+-+-+-+-+-+-+-+-+-+-+-+- 414 Code 416 3 for Success; 418 4 for Failure. 420 Identifier 422 The Identifier field is one octet and aids in matching requests 423 and replies. The Identifier field MUST be copied from the 424 Identifier field of the Response which caused this reply. 426 Message 428 The Message field is zero or more octets, and its contents are 429 implementation dependent. It is intended to be human readable, 430 and MUST NOT affect operation of the protocol. It is recommended 431 that the message contain displayable ASCII characters 32 through 432 126 decimal. Mechanisms for extension to other character sets are 433 the topic of future research. The size is determined from the 434 Length field. 436 Security Considerations 438 Security issues are the primary topic of this RFC. 440 The interaction of the authentication protocols within PPP are highly 441 implementation dependent. This is indicated by the use of SHOULD 442 throughout the document. 444 For example, upon failure of authentication, some implementations do 445 not terminate the link. Instead, the implementation limits the kind 446 of traffic in the Network-Layer Protocols to a filtered subset, which 447 in turn allows the user opportunity to update secrets or send mail to 448 the network administrator indicating a problem. 450 There is no provision for re-tries of failed authentication. 451 However, the LCP state machine can renegotiate the authentication 452 protocol at any time, thus allowing a new attempt. It is recommended 453 that any counters used for authentication failure not be reset until 454 after successful authentication, or subsequent termination of the 455 failed link. 457 There is no requirement that authentication be full duplex or that 458 the same protocol be used in both directions. It is perfectly 459 acceptable for different protocols to be used in each direction. 460 This will, of course, depend on the specific protocols negotiated. 462 The secret SHOULD NOT be the same in both directions. This allows an 463 attacker to replay the peer's challenge, accept the computed 464 response, and use that response to authenticate. 466 In practice, within or associated with each PPP server, there is a 467 database which associates "user" names with authentication 468 information ("secrets"). It is not anticipated that a particular 469 named user would be authenticated by multiple methods. This would 470 make the user vulnerable to attacks which negotiate the least secure 471 method from among a set (such as PAP rather than CHAP). If the same 472 secret was used, PAP would reveal the secret to be used later with 473 CHAP. 475 Instead, for each user name there should be an indication of exactly 476 one method used to authenticate that user name. If a user needs to 477 make use of different authentication methods under different 478 circumstances, then distinct user names SHOULD be employed, each of 479 which identifies exactly one authentication method. 481 Passwords and other secrets should be stored at the respective ends 482 such that access to them is as limited as possible. Ideally, the 483 secrets should only be accessible to the process requiring access in 484 order to perform the authentication. 486 The secrets should be distributed with a mechanism that limits the 487 number of entities that handle (and thus gain knowledge of) the 488 secret. Ideally, no unauthorized person should ever gain knowledge 489 of the secrets. It is possible to achieve this with SNMP Security 490 Protocols [4], but such a mechanism is outside the scope of this 491 specification. 493 Other distribution methods are currently undergoing research and 494 experimentation. The SNMP Security document also has an excellent 495 overview of threats to network protocols. 497 Acknowledgements 499 David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge 500 handshake at SDC when designing one of the protocols for a "secure" 501 network in the mid-1970s. Tom Bearson built a prototype Sytek 502 product ("Poloneous"?) on the challenge-response notion in the 1982- 503 83 timeframe. Another variant is documented in the various IBM SNA 504 manuals. Yet another variant was implemented by Karl Auerbach in the 505 Telebit NetBlazer circa 1991. 507 Kim Toms and Barney Wolff provided useful critiques of earlier 508 versions of this document. 510 Special thanks to Dave Balenson, Steve Crocker, James Galvin, and 511 Steve Kent, for their extensive explanations and suggestions. Now, 512 if only we could get them to agree with each other. 514 References 516 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 517 51, RFC 1661, Daydreamer, July 1994. 519 [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC- 520 1700, USC/Information Sciences Institute, October 1994. 522 [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", 523 MIT Laboratory for Computer Science and RSA Data Security, 524 Inc., RFC 1321, April 1992. 526 [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security 527 Protocols", Trusted Information Systems, Inc., Hughes LAN 528 Systems, Inc., MIT Laboratory for Computer Science, RFC 1352, 529 July 1992. 531 Chair's Address 533 The working group can be contacted via the current chair: 535 Fred Baker 536 Cisco Systems 537 519 Lado Drive 538 Santa Barbara, California 93111 540 EMail: fred@cisco.com 542 Author's Address 544 Questions about this memo can also be directed to: 546 William Allen Simpson 547 Daydreamer 548 Computer Systems Consulting Services 549 1384 Fontaine 550 Madison Heights, Michigan 48071 552 Bill.Simpson@um.cc.umich.edu 553 bsimpson@MorningStar.com (prefered) 554 Table of Contents 556 1. Introduction .......................................... 1 557 1.1 Specification of Requirements ................... 1 558 1.2 Terminology ..................................... 2 560 2. Challenge-Handshake Authentication Protocol ........... 3 561 2.1 Configuration Option Format ..................... 5 562 2.2 Packet Format ................................... 6 563 2.2.1 Challenge and Response .......................... 7 564 2.2.2 Success and Failure ............................. 10 566 SECURITY CONSIDERATIONS ...................................... 11 568 ACKNOWLEDGEMENTS ............................................. 12 570 REFERENCES ................................................... 12 572 CHAIR'S ADDRESS .............................................. 14 574 AUTHOR'S ADDRESS ............................................. 14