idnits 2.17.1 draft-ietf-pppext-eap-auth-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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 86: '...ed, an implementation MUST specify the...' RFC 2119 keyword, line 106: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 109: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 112: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 118: '... MAY This word, or the adjecti...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 507 has weird spacing: '...pe-Data field...' -- 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 1995) is 10633 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 628, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1334 (ref. '3') (Obsoleted by RFC 1994) ** Downref: Normative reference to an Informational RFC: RFC 1760 (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 L J Blunk 3 J R Vollbrecht 4 Internet Draft Merit Network, Inc. 5 expires September 1995 March 1995 7 PPP Extensible Authentication Protocol (EAP) 8 10 Status of this Memo 12 This document is the product of the Point-to-Point Protocol 13 Extensions Working Group of the Internet Engineering Task Force 14 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 15 mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is not appropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 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. 40 PPP also defines an extensible Link Control Protocol, which allows 41 negotiation of an Authentication Protocol for authenticating its peer 42 before allowing Network Layer protocols to transmit over the link. 44 This document defines the PPP Extensible Authentication Protocol. 46 Table of Contents 48 1. Introduction .......................................... 1 49 1.1 Specification of Requirements ................... 1 50 1.2 Terminology ..................................... 2 52 2. PPP Extensible Authentication Protocol (EAP) .......... 3 53 2.1 Configuration Option Format ..................... 5 54 2.2 Packet Format ................................... 6 55 2.2.1 Request and Response ............................ 7 56 2.2.2 Success and Failure ............................. 9 58 3. Initial EAP Request/Response Types .................... 10 59 3.1 Identity ........................................ 11 60 3.2 Notification .................................... 12 61 3.3 Nak ............................................. 13 62 3.4 Password ........................................ 14 63 3.5 MD5-Challenge ................................... 15 64 3.6 MD4-S/Key and MD5-S/Key ......................... 16 65 3.7 Echoed User Input and Non-echoed User Input ..... 17 66 3.8 Kerberos V4 and Kerberos V5 ..................... 18 67 3.9 Vendor specific ................................. 19 69 REFERENCES ................................................ 21 71 ACKNOWLEDGEMENTS .......................................... 21 73 CHAIR'S ADDRESS ........................................... 21 75 AUTHOR'S ADDRESS .......................................... 21 77 1. Introduction 79 In order to establish communications over a point-to-point link, each 80 end of the PPP link must first send LCP packets to configure the data 81 link during Link Establishment phase. After the link has been 82 established, PPP provides for an optional Authentication phase before 83 proceeding to the Network-Layer Protocol phase. 85 By default, authentication is not mandatory. If authentication of 86 the link is desired, an implementation MUST specify the 87 Authentication-Protocol Configuration Option during Link 88 Establishment phase. 90 These authentication protocols are intended for use primarily by 91 hosts and routers that connect to a PPP network server via switched 92 circuits or dial-up lines, but might be applied to dedicated links as 93 well. The server can use the identification of the connecting host 94 or router in the selection of options for network layer negotiations. 96 This document defines the PPP Extensible Authentication Protocol 97 (EAP). The Link Establishment and Authentication phases, and the 98 Authentication-Protocol Configuration Option, are defined in The 99 Point-to-Point Protocol (PPP) [1]. 101 1.1. Specification of Requirements 103 In this document, several words are used to signify the requirements 104 of the specification. These words are often capitalized. 106 MUST This word, or the adjective "required", means that the 107 definition is an absolute requirement of the specification. 109 MUST NOT This phrase means that the definition is an absolute 110 prohibition of the specification. 112 SHOULD This word, or the adjective "recommended", means that there 113 may exist valid reasons in particular circumstances to 114 ignore this item, but the full implications must be 115 understood and carefully weighed before choosing a 116 different course. 118 MAY This word, or the adjective "optional", means that this 119 item is one of an allowed set of alternatives. An 120 implementation which does not include this option MUST be 121 prepared to interoperate with another implementation which 122 does include the option. 124 1.2. Terminology 126 This document frequently uses the following terms: 128 authenticator 129 The end of the link requiring the authentication. The 130 authenticator specifies the authentication protocol to be 131 used in the Configure-Request during Link Establishment 132 phase. 134 peer The other end of the point-to-point link; the end which is 135 being authenticated by the authenticator. 137 silently discard 138 This means the implementation discards the packet without 139 further processing. The implementation SHOULD provide the 140 capability of logging the error, including the contents of 141 the silently discarded packet, and SHOULD record the event 142 in a statistics counter. 144 displayable message 145 This is interpreted to be human readable string of 146 characters, and MUST NOT affect operation of the protocol. 147 It is recommended that the message contain displayable 148 ASCII characters 32 through 126 decimal. Mechanisms for 149 extension to other character sets are the topic of future 150 research. 152 2. PPP Extensible Authentication Protocol (EAP) 154 The PPP Extensible Authentication Protocol (EAP) is a general 155 protocol for PPP authentication which supports multiple 156 authentication mechanisms. EAP does not select a specific 157 authentication mechanism at Link Control Phase, but rather postpones 158 this until the Authentication Phase. This allows the authenticator 159 to request more information before determining the specific 160 authentication mechanism. This also permits the use of a "back-end" 161 server which actually implements the various mechanisms while the PPP 162 authenticator merely passes through the authentication exchange. 164 1. After the Link Establishment phase is complete, the authenticator 165 sends one or more Requests to authenticate the peer. The Request 166 has a type field to indicate what is being requested. Examples of 167 Request types include "identity", "password", "MD5-challenge", 168 "generic user input" (for token cards), "s/key", etc. The 169 "password" and "MD5-challenge" requests correspond closely to the 170 "PAP" and "CHAP" authentication protocols, respectively. 171 Typically, the authenticator will send an initial "identity" 172 Request followed by one or more Requests for authentication 173 information. However, an initial "identity" Request is not 174 required, and may be bypassed in cases where the identity is 175 presumed (leased lines, dedicated dial-ups, etc.). 177 2. The peer sends a Response packet in reply to each Request. The 178 Response will vary with each Request type. 180 3. The authenticator terminates the authentication phase with a 181 Success or Failure reply. On a Success reply, the authenticator 182 will proceed to the Network Phase. On a Failure reply, the link 183 will be terminated. 185 Advantages 187 The EAP protocol can support multiple authentication mechanisms 188 without having to pre-negotiate a particular one during LCP Phase. 190 Certain devices (e.g. a NAS) do not necessarily have to understand 191 each request type and may be able to simply act as a passthrough 192 agent for a "back-end" server on a host. The device only need look 193 for the success/failure code to terminate the authentication phase 195 Disadvantages 197 EAP does require the addition of a new authentication type to LCP and 198 thus PPP implementations will need to be modified to use it. It also 199 strays from the previous PPP authentication model of negotiating a 200 specific authentication mechanism during LCP. 202 2.1. Configuration Option Format 204 A summary of the Authentication-Protocol Configuration Option format 205 to negotiate the EAP Authentication Protocol is shown below. The 206 fields are transmitted from left to right. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | Authentication-Protocol | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Type 216 3 218 Length 220 4 222 Authentication-Protocol 224 ???? (Hex) for PPP Extensible Authentication Protocol (EAP) 226 2.2. Packet Format 228 Exactly one PPP EAP packet is encapsulated in the Information field 229 of a PPP Data Link Layer frame where the protocol field indicates 230 type hex ???? (PPP EAP). A summary of the EAP packet format is shown 231 below. The fields are transmitted from left to right. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Code | Identifier | Length | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Data ... 239 +-+-+-+-+ 241 Code 243 The Code field is one octet and identifies the type of EAP packet. 244 EAP Codes are assigned as follows: 246 1 Request 247 2 Response 248 3 Success 249 4 Failure 251 Identifier 253 The Identifier field is one octet and aids in matching responses 254 with requests. 256 Length 258 The Length field is two octets and indicates the length of the EAP 259 packet including the Code, Identifier, Length and Data fields. 260 Octets outside the range of the Length field should be treated as 261 Data Link Layer padding and should be ignored on reception. 263 Data 265 The Data field is zero or more octets. The format of the Data 266 field is determined by the Code field. 268 2.2.1. Request and Response 270 Description 272 The Request packet is sent by the authenticator to the peer. Each 273 Request has a type field which serves to indicate what is being 274 requested. The authenticator MUST transmit an EAP packet with the 275 Code field set to 1 (Request). Additional Request packets MUST be 276 sent until a valid Response packet is received, or an optional 277 retry counter expires. Retransmitted Requests MUST be sent with 278 the same Identifier value in order to distinguish them from new 279 Requests. The contents of the data field is dependent on the 280 Request type. The peer MUST send a Response packet in reply to a 281 Request packet. Responses MUST only be sent in reply to a 282 received Request and never retransmitted on a timer. The 283 Identifier field of the Response MUST match that of the Request. 285 A summary of the Request and Response packet format is shown below. 286 The fields are transmitted from left to right. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Code | Identifier | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Type-Data ... 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 296 Code 298 1 for Request; 300 2 for Response. 302 Identifier 304 The Identifier field is one octet. The Identifier field MUST be 305 the same if a Request packet is retransmitted due to a timeout 306 while waiting for a Response. Any new Requests MUST modify the 307 Identifier field. If a duplicate Response is received, it must be 308 silently discarded. 310 Type 312 The Type field is one octet. This field indicates the Type of 313 Request or Response. Only one Type may be specified per EAP 314 Request or Response. Normally, the Type field of the Response 315 will be the same as the Type of the Request. However, there is a 316 specific Response Type for indicating that a Request type is 317 unacceptable. This Response Type will indicate an acceptable 318 Request type for authentication. An initial specification of 319 Types follows in a later section of this document. 321 Type-Data 323 The Type-Data field varies with the Type of Request and the 324 associated Response. 326 2.2.2. Success and Failure 328 Description 330 The Success packet is sent by the authenticator to the peer to 331 acknowledge successful authentication. The authenticator MUST 332 transmit an EAP packet with the Code field set to 3 (Success). 334 If the authenticator cannot authenticate the peer (unacceptable 335 Responses to one or more Requests) then the implementation MUST 336 transmit an EAP packet with the Code field set to 4 (Failure). An 337 authenticator may with to issue multiple Requests before sending a 338 Failure response in order to allow for human typing mistakes. 340 Implementation Note: Because the Success and Failure packets 341 are not acknowledged, they may be potentially lost. A peer 342 MUST allow for this circumstance. The peer can use a Network 343 Protocol packet as an alternative indication of Success. 344 Likewise, the receipt of a LCP Terminate-Request can be taken 345 as a Failure. 347 A summary of the Success and Failure packet format is shown below. 348 The fields are transmitted from left to right. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Code | Identifier | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Code 358 3 for Success; 360 4 for Failure. 362 Identifier 364 The Identifier field is one octet and aids in matching replies to 365 Responses. The Identifier field MUST match the Indentifier field 366 of the Response packet that it is sent in response to. 368 Length 370 4 372 3. Initial EAP Request/Response Types 374 This section defines the initial set of EAP Types used in 375 Request/Response exchanges. More Types may be defined in follow-on 376 documents. The Type field is one octet and identifies the structure 377 of an EAP Request or Response packet. The first 3 Types are 378 considered special case Types. The remaining Types define 379 authentication exchanges. The Nak Type is valid only for Response 380 packets, it may not be sent in a Request. The Nak Type may only be 381 sent in repsonse to a Request with an authentication Type. 383 The initial EAP Types are assigned as follows: 385 1 Identity 386 2 Notification 387 3 Nak (Response only) 388 4 Password 389 5 MD5-Challenge 390 6 MD4-S/Key 391 7 MD5-S/Key 392 8 Echoed user input 393 9 Non-echoed user input 394 10 Kerberos V4 395 11 Kerboros V5 396 240-255 Vendor Specific (reserved) 398 3.1. Identity 400 Description 402 The Identity Type is used to query the identity of the peer. 403 Generally, the authenticator will issue this as the initial 404 Request. An optional displayable message may be included to 405 prompt the peer. A Response MUST be sent to this Request with a 406 Type of 1 (Identity). 408 Type 410 1 412 Type-Data 414 This field MAY contain a displayable message in the Request. The 415 Response uses this field to return the Identity. If the Identity 416 is unknown, this field should be zero bytes in length. The field 417 SHOULD NOT be null terminated. The length of this field is 418 derived from the Length field of the Request/Response packet. 420 3.2. Notification 422 Description 424 The Notification Type is optionally used to convey a displayable 425 message from the authenticator to the peer. The peer SHOULD 426 display this message to the user or log it if it cannot be 427 displayed. It is intended to provide an acknowledged notification 428 of some imperative nature. Examples include a password with an 429 expiration time that is about to expire, an S/Key id which is 430 nearing 0, an authentication failure warning, etc. In most 431 circumstances, notification should not be required. 433 Type 435 2 437 Type-Data 439 The Type-Data field in the Request contains a displayable message 440 greater than zero octets in length. The length of the message is 441 determined by Length field of the Request packet. The message 442 SHOULD NOT be null terminated. A Response MUST be sent in reply 443 to the Request with a Type field of 2 (Notification). The Type- 444 Data field of the Response is zero octets in length. The 445 Response should be sent immediately (independent of how the 446 message is displayed or logged). 448 3.3. Nak 450 Description 452 The Nak Type is valid only in Response messages. It is sent in 453 reply to a Request where the desired authentication Type is 454 unacceptable. Authentication Types are numbered 4 and above. 455 The Response contains the authentication Type desired by the peer. 457 Type 459 4 461 Type-Data 463 This field MUST contain a single octet indicating the desired 464 authentication type. 466 3.4. Password 468 Description 470 The Password Type is analagous to the PPP PAP protocol [3]. The 471 Request may contain an optional displayable message to prompt the 472 peer. A Repsonse MUST be sent in reply to the Request. The 473 Response MAY be either of Type 4 (Password) or Type 3 (Nak). The 474 Nak reply indicates the peer's desired authentication mechanism 475 Type. 477 Type 479 4 481 Type-Data 483 This field MAY contain a displayable message in the Request. The 484 Response uses this field to return the Password. The field SHOULD 485 NOT be null terminated. The length of this field is derived from 486 the Length field of the Request/Response packet. 488 3.5. MD5-Challenge 490 Description 492 The MD5-Challenge Type is analagous to the PPP CHAP protocol [3] 493 (with MD5 as the specified algorithm). The PPP Authentication 494 Protocols RFC [3] should be referred to for further implementation 495 specifics. The Request contains a "challenge" message to the 496 peer. A Repsonse MUST be sent in reply to the Request. The 497 Response MAY be either of Type 5 (MD5-Challenge) or Type 3 (Nak). 498 The Nak reply indicates the peer's desired authentication 499 mechanism Type. 501 Type 503 5 505 Type-Data 507 The contents of the Type-Data field is summarized below. For 508 reference on the use of this fields see the PPP Authentication 509 Protocols RFC [3]. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Value-Size | Value ... 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Name ... 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 3.6. MD4-S/Key and MD5-S/Key 521 Description These protocols are defined in "The S/KEY One-Time 522 Password System" [4]. The Request contains a displayable message 523 consisting of the S/Key count and a seed. A Repsonse MUST be sent in 524 reply to the Request. The Response MAY be either of Type 6 or 7 525 (MD4-S/key or MD5-S/key) or Type 3 (Nak). The Nak reply indicates 526 the peer's desired authentication mechanism Type. 528 Type 530 6 for MD4-S/key; 532 7 for MD5-S/key. 534 Type-Data 536 The Type-Data field contains the S/Key "challenge" (count and seed) 537 as a displayable message in the Request. This field is used for the 538 6 words (displayable text) from the S/Key dictionary [4] in the 539 Response. The messages SHOULD NOT be null terminated. The length of 540 the field is derived from the Length field of the Request/Reply 541 packet. 543 3.7. Echoed User Input and Non-echoed User Input 545 Description 547 The user Input type are used where a user must provide physical 548 input. The typical application would be for "Token" cards where a 549 challenge or time-based token is retrieved from the card and 550 entered by the user. The non-echoed Type would be used in cases 551 where the entered data is potentially sensitive and thus should be 552 hidden. A Repsonse MUST be sent in reply to the Request. The 553 Response MAY be either of Type 8 or 9 (User Input) or Type 3 554 (Nak). The Nak reply indicates the peer's desired authentication 555 mechanism Type. 557 Type 559 8 for Echoed User Input; 561 9 for Non-echoed User Input. 563 Type-Data 565 The Type-Data field contains a displayable message in the Request. 566 The peer must then prompt the user for input in response to the 567 Request. This field is then used to return the input in the 568 Response. The message SHOULD NOT be null terminated. The length 569 of the data is derived from the Length field of the 570 Request/Response packet. 572 3.8. Kerberos V4 and Kerberos V5 574 These protocols are to be defined in a later document. 576 3.9. Vendor specific 578 Description 580 These Type field are reserved for Vendor Specific authentication 581 mechanism. 583 Security Considerations 585 Security issues are the primary topic of this RFC. 587 The interaction of the authentication protocols within PPP are 588 highly implementation dependent. This is indicated by the use of 589 SHOULD throughout the document. 591 For example, upon failure of authentication, some implementations 592 do not terminate the link. Instead, the implementation limits the 593 kind of traffic in the Network-Layer Protocols to a filtered 594 subset, which in turn allows the user opportunity to update 595 secrets or send mail to the network administrator indicating a 596 problem. 598 There is no provision for re-tries of failed authentication. 599 However, the LCP state machine can renegotiate the authentication 600 protocol at any time, thus allowing a new attempt. It is 601 recommended that any counters used for authentication failure not 602 be reset until after successful authentication, or subsequent 603 termination of the failed link. 605 There is no requirement that authentication be full duplex or that 606 the same protocol be used in both directions. It is perfectly 607 acceptable for different protocols to be used in each direction. 608 This will, of course, depend on the specific protocols negotiated. 610 In practice, within or associated with each PPP server, there is a 611 database which associates "user" names with authentication 612 information ("secrets"). It is not anticipated that a particular 613 named user would be authenticated by multiple methods. This would 614 make the user vulnerable to attacks which negotiate the least 615 secure method from among a set (such as PAP rather than EAP). 616 Instead, for each named user there should be an indication of 617 exactly one method used to authenticate that user name. If a user 618 needs to make use of different authentication methods under 619 different circumstances, then distinct user names SHOULD be 620 employed, each of which identifies exactly one authentication 621 method. 623 References 625 [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 626 1661. 628 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 629 USC/Information Sciences Institute, October 1994. 631 [3] Lloyd, B., and Simpson, W., "PPP Authentication Protocols", 632 RFC 1334, October 1992. 634 [4] Haller, N., "The S/KEY One-Time Password System", RFC 1760, 635 Bellcore, February 1995. 637 Acknowledgments 639 This protocol derives much of its inspiration from Dave Carrel's 640 AHA draft as well as the PPP CHAP protocol [3]. Bill Simpson 641 provided much of the boilerplate used throughout this document. 642 Al Rubens (Merit) also provided valuable feedback. 644 Chair's Address 646 The working group can be contacted via the current chair: 648 Fred Baker 649 cisco Systems, Inc. 651 EMail: fbaker@cisco.com 653 Author's Address 655 Questions about this memo can also be directed to: 657 Larry J Blunk John R Vollbrecht 659 EMail: ljb@merit.edu EMail: jrv@merit.edu