idnits 2.17.1 draft-ietf-pppext-eap-auth-02.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-19) 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 83: '...ed, an implementation MUST specify the...' RFC 2119 keyword, line 103: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 106: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 109: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 115: '... MAY This word, or the adjecti...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 512 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 (June 1996) is 10170 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 613, 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 in six months June 1996 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 MD5-Challenge ................................... 14 63 3.5 S/Key ........................................... 15 64 3.6 Generic Token Card .............................. 16 66 REFERENCES ................................................... 18 68 ACKNOWLEDGEMENTS ............................................. 18 70 CHAIR'S ADDRESS .............................................. 18 72 AUTHOR'S ADDRESS ............................................. 18 74 1. Introduction 76 In order to establish communications over a point-to-point link, each 77 end of the PPP link must first send LCP packets to configure the data 78 link during Link Establishment phase. After the link has been 79 established, PPP provides for an optional Authentication phase before 80 proceeding to the Network-Layer Protocol phase. 82 By default, authentication is not mandatory. If authentication of 83 the link is desired, an implementation MUST specify the 84 Authentication-Protocol Configuration Option during Link 85 Establishment phase. 87 These authentication protocols are intended for use primarily by 88 hosts and routers that connect to a PPP network server via switched 89 circuits or dial-up lines, but might be applied to dedicated links as 90 well. The server can use the identification of the connecting host 91 or router in the selection of options for network layer negotiations. 93 This document defines the PPP Extensible Authentication Protocol 94 (EAP). The Link Establishment and Authentication phases, and the 95 Authentication-Protocol Configuration Option, are defined in The 96 Point-to-Point Protocol (PPP) [1]. 98 1.1. Specification of Requirements 100 In this document, several words are used to signify the requirements 101 of the specification. These words are often capitalized. 103 MUST This word, or the adjective "required", means that the 104 definition is an absolute requirement of the specification. 106 MUST NOT This phrase means that the definition is an absolute 107 prohibition of the specification. 109 SHOULD This word, or the adjective "recommended", means that there 110 may exist valid reasons in particular circumstances to 111 ignore this item, but the full implications must be 112 understood and carefully weighed before choosing a 113 different course. 115 MAY This word, or the adjective "optional", means that this 116 item is one of an allowed set of alternatives. An 117 implementation which does not include this option MUST be 118 prepared to interoperate with another implementation which 119 does include the option. 121 1.2. Terminology 123 This document frequently uses the following terms: 125 authenticator 126 The end of the link requiring the authentication. The 127 authenticator specifies the authentication protocol to be 128 used in the Configure-Request during Link Establishment 129 phase. 131 peer The other end of the point-to-point link; the end which is 132 being authenticated by the authenticator. 134 silently discard 135 This means the implementation discards the packet without 136 further processing. The implementation SHOULD provide the 137 capability of logging the error, including the contents of 138 the silently discarded packet, and SHOULD record the event 139 in a statistics counter. 141 displayable message 142 This is interpreted to be human readable string of 143 characters, and MUST NOT affect operation of the protocol. 144 It is recommended that the message contain displayable 145 ASCII characters 32 through 126 decimal. Mechanisms for 146 extension to other character sets are the topic of future 147 research. 149 2. PPP Extensible Authentication Protocol (EAP) 151 The PPP Extensible Authentication Protocol (EAP) is a general 152 protocol for PPP authentication which supports multiple 153 authentication mechanisms. EAP does not select a specific 154 authentication mechanism at Link Control Phase, but rather postpones 155 this until the Authentication Phase. This allows the authenticator 156 to request more information before determining the specific 157 authentication mechanism. This also permits the use of a "back-end" 158 server which actually implements the various mechanisms while the PPP 159 authenticator merely passes through the authentication exchange. 161 1. After the Link Establishment phase is complete, the authenticator 162 sends one or more Requests to authenticate the peer. The Request 163 has a type field to indicate what is being requested. Examples of 164 Request types include Identity, MD5-challenge, S/Key, Generic 165 Token Card, etc. The MD5-challenge type corresponds closely to 166 the CHAP authentication protocol. Typically, the authenticator 167 will send an initial Identity Request followed by one or more 168 Requests for authentication information. However, an initial 169 Identity Request is not required, and may be bypassed in cases 170 where the identity is presumed (leased lines, dedicated dial-ups, 171 etc.). 173 2. The peer sends a Response packet in reply to each Request. As 174 with the Request packet, the Response packet contains a type field 175 which corresponds to the type field of the Request. 177 3. The authenticator ends the authentication phase with a Success or 178 Failure packet. 180 Advantages 182 The EAP protocol can support multiple authentication mechanisms 183 without having to pre-negotiate a particular one during LCP Phase. 185 Certain devices (e.g. a NAS) do not necessarily have to understand 186 each request type and may be able to simply act as a passthrough 187 agent for a "back-end" server on a host. The device only need look 188 for the success/failure code to terminate the authentication phase. 190 Disadvantages 192 EAP does require the addition of a new authentication type to LCP and 193 thus PPP implementations will need to be modified to use it. It also 194 strays from the previous PPP authentication model of negotiating a 195 specific authentication mechanism during LCP. 197 2.1. Configuration Option Format 199 A summary of the Authentication-Protocol Configuration Option format 200 to negotiate the EAP Authentication Protocol is shown below. The 201 fields are transmitted from left to right. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | Authentication-Protocol | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Type 211 3 213 Length 215 4 217 Authentication-Protocol 219 C227 (Hex) for PPP Extensible Authentication Protocol (EAP) 221 2.2. Packet Format 223 Exactly one PPP EAP packet is encapsulated in the Information field 224 of a PPP Data Link Layer frame where the protocol field indicates 225 type hex C227 (PPP EAP). A summary of the EAP packet format is shown 226 below. The fields are transmitted from left to right. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Code | Identifier | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Data ... 234 +-+-+-+-+ 236 Code 238 The Code field is one octet and identifies the type of EAP packet. 239 EAP Codes are assigned as follows: 241 1 Request 242 2 Response 243 3 Success 244 4 Failure 246 Identifier 248 The Identifier field is one octet and aids in matching responses 249 with requests. 251 Length 253 The Length field is two octets and indicates the length of the EAP 254 packet including the Code, Identifier, Length and Data fields. 255 Octets outside the range of the Length field should be treated as 256 Data Link Layer padding and should be ignored on reception. 258 Data 260 The Data field is zero or more octets. The format of the Data 261 field is determined by the Code field. 263 2.2.1. Request and Response 265 Description 267 The Request packet is sent by the authenticator to the peer. Each 268 Request has a type field which serves to indicate what is being 269 requested. The authenticator MUST transmit an EAP packet with the 270 Code field set to 1 (Request). Additional Request packets MUST be 271 sent until a valid Response packet is received, or an optional 272 retry counter expires. Retransmitted Requests MUST be sent with 273 the same Identifier value in order to distinguish them from new 274 Requests. The contents of the data field is dependent on the 275 Request type. The peer MUST send a Response packet in reply to a 276 Request packet. Responses MUST only be sent in reply to a 277 received Request and never retransmitted on a timer. The 278 Identifier field of the Response MUST match that of the Request. 280 Implementation Note: Because the authentication process will 281 often involve user input, some care must be taken when deciding 282 upon retransmission strategies and authentication timeouts. It 283 is suggested a retransmission timer of 6 seconds with a maximum 284 of 10 retransmissions be used as default. One may wish to make 285 these timeouts longer in certain cases (e.g. where Token Cards 286 are involved). Additionally, the peer must be prepared to 287 silently discard received retransmissions while waiting for 288 user input. 290 A summary of the Request and Response packet format is shown below. 291 The fields are transmitted from left to right. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Code | Identifier | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Type-Data ... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 301 Code 303 1 for Request; 305 2 for Response. 307 Identifier 309 The Identifier field is one octet. The Identifier field MUST be 310 the same if a Request packet is retransmitted due to a timeout 311 while waiting for a Response. Any new (non-retransmission) 312 Requests MUST modify the Identifier field. If a peer recieves a 313 duplicate Request for which it has already sent a Response, it 314 MUST resend it's Response. If a peer receives a duplicate Request 315 before it has sent a Response to the initial Request (i.e. it's 316 waiting for user input), it MUST silently discard the duplicate 317 Request. 319 Length 321 The Length field is two octets and indicates the length of the EAP 322 packet including the Code, Identifier, Length, Type, and Type-Data 323 fields. Octets outside the range of the Length field should be 324 treated as Data Link Layer padding and should be ignored on 325 reception. 327 Type 329 The Type field is one octet. This field indicates the Type of 330 Request or Response. Only one Type may be specified per EAP 331 Request or Response. Normally, the Type field of the Response 332 will be the same as the Type of the Request. However, there is 333 also a Nak Response Type for indicating that a Request type is 334 unacceptable to the peer. When sending a Nak in response to a 335 Request, the peer may indicate an alternative desired 336 authentication Type which it supports. An initial specification of 337 Types follows in a later section of this document. 339 Type-Data 341 The Type-Data field varies with the Type of Request and the 342 associated Response. 344 2.2.2. Success and Failure 346 Description 348 The Success packet is sent by the authenticator to the peer to 349 acknowledge successful authentication. The authenticator MUST 350 transmit an EAP packet with the Code field set to 3 (Success). 352 If the authenticator cannot authenticate the peer (unacceptable 353 Responses to one or more Requests) then the implementation MUST 354 transmit an EAP packet with the Code field set to 4 (Failure). An 355 authenticator may wish to issue multiple Requests before sending a 356 Failure response in order to allow for human typing mistakes. 358 Implementation Note: Because the Success and Failure packets 359 are not acknowledged, they may be potentially lost. A peer 360 MUST allow for this circumstance. The peer can use a Network 361 Protocol packet as an alternative indication of Success. 362 Likewise, the receipt of a LCP Terminate-Request can be taken 363 as a Failure. 365 A summary of the Success and Failure packet format is shown below. 366 The fields are transmitted from left to right. 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Code | Identifier | Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Code 376 3 for Success; 378 4 for Failure. 380 Identifier 382 The Identifier field is one octet and aids in matching replies to 383 Responses. The Identifier field MUST match the Indentifier field 384 of the Response packet that it is sent in response to. 386 Length 388 4 390 3. Initial EAP Request/Response Types 392 This section defines the initial set of EAP Types used in 393 Request/Response exchanges. More Types may be defined in follow-on 394 documents. The Type field is one octet and identifies the structure 395 of an EAP Request or Response packet. The first 3 Types are 396 considered special case Types. The remaining Types define 397 authentication exchanges. The Nak Type is valid only for Response 398 packets, it may not be sent in a Request. The Nak Type may only be 399 sent in repsonse to a Request which usea an authentication Type code. 400 Support for EAP Types 1-4 is MANDATORY. These Types, as well as 401 types 5 and 6, are defined in this document. Follow-on RFCs will 402 define additional EAP Types. 404 1 Identity 405 2 Notification 406 3 Nak (Response only) 407 4 MD5-Challenge 408 5 S/Key (RFC 1760) 409 6 Generic Token Card 411 3.1. Identity 413 Description 415 The Identity Type is used to query the identity of the peer. 416 Generally, the authenticator will issue this as the initial 417 Request. An optional displayable message may be included to 418 prompt the peer in the case where there expectation of interaction 419 with a user. A Response MUST be sent to this Request with a Type 420 of 1 (Identity). 422 Implementation Note: The peer may obtain the Identity via user 423 input. It is suggested that the authenticator retry the 424 Indentity Request in the case of an invalid Identity or 425 authentication failure to allow for potential typos on the part 426 of the user. It is suggested that the Identity Request be 427 retried a minimum of 3 times before terminating the 428 authentication phase with a Failure reply. The Notification 429 Request may be used to indicate an invalid authentication 430 attempt prior to transmitting a new Identity Request 431 (optionally, the failure may be indicated within the message of 432 the new Identity Request itself). 434 Type 436 1 438 Type-Data 440 This field MAY contain a displayable message in the Request. The 441 Response uses this field to return the Identity. If the Identity 442 is unknown, this field should be zero bytes in length. The field 443 need not be null terminated. The length of this field is derived 444 from the Length field of the Request/Response packet. 446 3.2. Notification 448 Description 450 The Notification Type is optionally used to convey a displayable 451 message from the authenticator to the peer. The peer SHOULD 452 display this message to the user or log it if it cannot be 453 displayed. It is intended to provide an acknowledged notification 454 of some imperative nature. Examples include a password with an 455 expiration time that is about to expire, an S/Key id which is 456 nearing 0, an authentication failure warning, etc. In most 457 circumstances, notification should not be required. 459 Type 461 2 463 Type-Data 465 The Type-Data field in the Request contains a displayable message 466 greater than zero octets in length. The length of the message is 467 determined by Length field of the Request packet. The message 468 need not be null terminated. A Response MUST be sent in reply to 469 the Request with a Type field of 2 (Notification). The Type-Data 470 field of the Response is zero octets in length. The Response 471 should be sent immediately (independent of how the message is 472 displayed or logged). 474 3.3. Nak 476 Description 478 The Nak Type is valid only in Response messages. It is sent in 479 reply to a Request where the desired authentication Type is 480 unacceptable. Authentication Types are numbered 4 and above. 481 The Response contains the authentication Type desired by the peer. 483 Type 485 3 487 Type-Data 489 This field MUST contain a single octet indicating the desired 490 authentication type. 492 3.4. MD5-Challenge 494 Description 496 The MD5-Challenge Type is analagous to the PPP CHAP protocol [3] 497 (with MD5 as the specified algorithm). The PPP Authentication 498 Protocols RFC [3] should be referred to for further implementation 499 specifics. The Request contains a "challenge" message to the 500 peer. A Repsonse MUST be sent in reply to the Request. The 501 Response MAY be either of Type 4 (MD5-Challenge) or Type 3 (Nak). 502 The Nak reply indicates the peer's desired authentication 503 mechanism Type. Support for the MD5-Challenge mechanism is 504 MANDATORY. 506 Type 508 4 510 Type-Data 512 The contents of the Type-Data field is summarized below. For 513 reference on the use of this fields see the PPP Authentication 514 Protocols RFC [3]. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Value-Size | Value ... 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Name ... 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 3.5. S/Key 526 Description The S/Key system is defined in "The S/KEY One-Time 527 Password System" [4]. The Request contains a displayable message 528 consisting of the S/Key count and a seed. A Repsonse MUST be sent in 529 reply to the Request. The Response MUST be of Type 5 (S/key) or Type 530 3 (Nak). The Nak reply indicates the peer's desired authentication 531 mechanism Type. 533 Type 535 5 537 Type-Data 539 The Type-Data field contains the S/Key "challenge" (count and seed) 540 as a displayable message in the Request. This field is used for the 541 6 words (displayable text) from the S/Key dictionary [4] in the 542 Response. The messages need not be null terminated. The length of 543 the field is derived from the Length field of the Request/Reply 544 packet. 546 3.6. Generic Token Card 548 Description 550 The Generic Token Card Type is defined for use with various Token 551 Card implementations which require user input. The Request 552 contains an ASCII text message and the Reply contains the Token 553 Card information necessary for authentication. Typically, this 554 would be information read by a user from the Token card device and 555 entered as ASCII text. 557 Type 559 6 561 Type-Data 563 The Type-Data field in the Request contains a displayable message 564 greater than zero octets in length. The length of the message is 565 determined by Length field of the Request packet. The message 566 need not be null terminated. A Response MUST be sent in reply to 567 the Request with a Type field of 6 (Generic Token Card). The 568 Response contains data from the Token Card required for 569 authentication. The length is of the data is determined by the 570 Length field of the Response packet. 572 Security Considerations 574 Security issues are the primary topic of this RFC. 576 The interaction of the authentication protocols within PPP are highly 577 implementation dependent. 579 For example, upon failure of authentication, some implementations do 580 not terminate the link. Instead, the implementation limits the kind 581 of traffic in the Network-Layer Protocols to a filtered subset, which 582 in turn allows the user opportunity to update secrets or send mail to 583 the network administrator indicating a problem. 585 There is no provision for retries of failed authentication. However, 586 the LCP state machine can renegotiate the authentication protocol at 587 any time, thus allowing a new attempt. It is recommended that any 588 counters used for authentication failure not be reset until after 589 successful authentication, or subsequent termination of the failed 590 link. 592 There is no requirement that authentication be full duplex or that 593 the same protocol be used in both directions. It is perfectly 594 acceptable for different protocols to be used in each direction. 595 This will, of course, depend on the specific protocols negotiated. 597 In practice, within or associated with each PPP server, there is a 598 database which associates "user" names with authentication 599 information ("secrets"). It is not anticipated that a particular 600 named user would be authenticated by multiple methods. This would 601 make the user vulnerable to attacks which negotiate the least secure 602 method from among a set (such as PAP rather than EAP). Instead, for 603 each named user there should be an indication of exactly one method 604 used to authenticate that user name. If a user needs to make use of 605 different authentication methods under different circumstances, then 606 distinct user names SHOULD be employed, each of which identifies 607 exactly one authentication method. 609 References 611 [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1661. 613 [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, 614 USC/Information Sciences Institute, October 1994. 616 [3] Lloyd, B., and Simpson, W., "PPP Authentication Protocols", 617 RFC 1334, October 1992. 619 [4] Haller, N., "The S/KEY One-Time Password System", RFC 1760, 620 Bellcore, February 1995. 622 Acknowledgments 624 This protocol derives much of its inspiration from Dave Carrel's AHA 625 draft as well as the PPP CHAP protocol [3]. Bill Simpson provided 626 much of the boilerplate used throughout this document. Al Rubens 627 (Merit) also provided valuable feedback. 629 Chair's Address 631 The working group can be contacted via the current chair: 633 Karl Fox 634 Ascend Communications 636 EMail: karl@MorningStar.Com 638 Author's Address 640 Questions about this memo can also be directed to: 642 Larry J Blunk John R Vollbrecht 644 EMail: ljb@merit.edu EMail: jrv@merit.edu