idnits 2.17.1 draft-calhoun-enh-radius-eap-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-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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 32 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2], [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 196: '...DIUS-EAP-Request, A RADIUS Server MUST...' RFC 2119 keyword, line 237: '... MUST be set to 2...' RFC 2119 keyword, line 245: '...Identifier field MUST be changed whene...' RFC 2119 keyword, line 248: '... Identifier MAY remain unchanged....' RFC 2119 keyword, line 269: '... Attributes. It MAY contain zero or o...' (9 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 (June 1996) is 10170 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 649 looks like a reference -- Missing reference section? '1' on line 645 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Allan Rubens 2 Category: Experimental Merit Network, Incorporated 3 expires in six months Pat R. Calhoun 4 US Robotics Access Corp. 5 June 1996 7 Enhanced Remote Authentication Dial In User Service (RADIUS) 8 Extensible Authentication Protocol Support 9 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 Abstract 32 The RADIUS Protocol allows for authentication using existing 33 PPP authentication protocols such as PAP and CHAP. This 34 document describes how the Enhanced RADIUS Protocol could 35 also include the PPP Extensible Authentication Protocol, EAP. 37 1. Introduction 39 The PPP extensions WG is considering a new authentication protocol 40 for PPP called EAP - PPP Extensible Authentication Protocol. EAP is 41 described in [2]. 43 EAP is intended to provide support for authentication protocols which 44 do not fit into the PAP or CHAP model using a standard mechanism. The 45 protocols include varieties of smart cards, S/key, Public Key and 46 Kerberos. EAP is designed to allow a RADIUS style helper to handle 47 all authentication protocol support where the NAS acts as a transit 48 mechanism for EAP packets. 50 The following diagram gives an example of how an EAP authentication 51 using S/key might be accomplished with Enhanced RADIUS. This example 52 may be extended to other EAP protocols easily, but this concrete 53 example serves to make it a easier to understand the basic concept: 55 PPP-Client NAS (RADIUS-client) RADIUS-server 56 ---------- ------------------- ------------- 58 1) <-- LCP EAP-Request 60 2) LCP EAP ACK --> 62 3) Start-EAP --> 64 4) <-- EAP/identity 66 5) <-- EAP/identity 68 6) EAP-resp/myid --> 70 7) EAP-resp/myid --> 72 8) <-- EAP/S-key:S-key challenge 74 9) <-- EAP/S-key:S-key challenge 76 10) EAP-resp/myid:S-keypw --> 78 11) EAP/myid:S-keypw --> 80 12) <-- EAP/Success 82 13) <-- EAP/Success 83 The following describes one way to make this work with RADIUS: 85 a) Upon receiving an EAP-Response as the authentication protocol, 86 the NAS sends a RADIUS-EAP-Request to the RADIUS-server. The 87 absence of an EAP-Packet attribute in this request indicates that 88 this is a Start-EAP indication. 90 b) The RADIUS-server responds by sending a RADIUS-EAP-ACK with an 91 EAP-Packet attribute specifying the EAP packet to be issued to the 92 NAS. The EAP type of this packet will normally be "Identity", but 93 it could be any other valid EAP type if the server does not need to 94 know the user identity before beginning authentication. The NAS 95 forwards the EAP packet on to the PPP client. 97 c) The PPP client responds by sending an EAP-Response packet, which 98 the NAS forwards to the RADIUS-server in the EAP-Packet attribute 99 of a RADIUS-EAP-Request. 101 d) Based on the user's identity, the RADIUS-server determines if it 102 is able to authenticate the user locally, otherwise it may proxy 103 the request to a remote RADIUS server. 105 e) The RADIUS-server decides whether the response is okay and sends 106 a RADIUS-EAP-Ack or RADIUS-EAP-Reject with the appropriate EAP 107 success/failure packet inside an EAP-MSG attribute. The NAS 108 forwards the EAP packet to the PPP client, and accepts or rejects 109 the connection. 111 The above scenario creates a situation in which the NAS never needs to 112 touch an EAP packet. An alternative which may be used by NAS vendors 113 wanting to simplify things would be for the NAS to, 1) always send an 114 EAP Identity request message to the client, and 2) to forward the 115 response to the RADIUS-server in the EAP-Packet attribute of a 116 RADIUS-EAP-Request. 118 Unless the NAS interprets the EAP-Packet field of 119 RADIUS-EAP-Requests, it will not see the user id supplied by the 120 client. Rather than doing this interpretation, it is suggested that a 121 simple mechanism be defined for the RADIUS server to set the userid in 122 the NAS with a special attribute. It is important to have a userid 123 for logging and accounting purposes. 125 In the case where the RADIUS Server does not support the EAP 126 Extension, the following scenario would occur: 128 PPP-Client NAS (RADIUS-client) RADIUS-server 129 ---------- ------------------- ------------- 131 1) <-- LCP EAP-Request 133 2) LCP EAP ACK --> 135 3) Start-EAP --> 137 4) <-- Command Unrecognized 139 5) <-- LCP CHAP Request 141 In the case where the local RADIUS-server does support EAP, but the 142 remote RADIUS-server does not, the following would occur: 144 PPP-Client NAS (RADIUS-client) RADIUS-server RADIUS-Server 145 ---------- ------------------- ------------- ------------- 147 1) <-- LCP EAP-Request 149 2) LCP EAP ACK --> 151 3) Start-EAP --> 153 4) <-- EAP/identity 155 5) <-- EAP/identity 157 6) EAP-resp/myid --> 159 7) EAP-resp/myid --> 161 8) EAP-resp/myid --> 163 9) <-- Command Unrecognized 165 10) <-- Command Unrecognized 167 11) <-- LCP CHAP Request 168 2. Command Name and Command Code 170 Command Name: RADIUS-EAP-Request 171 Command Code: 300 173 Command Name: RADIUS-EAP-Response 174 Command Code: 301 176 Command Name: RADIUS-EAP-Ack 177 Command Code: 302 179 Command Name: RADIUS-EAP-Reject 180 Command Code: 303 182 3. Command Meanings 184 3.1 RADIUS-EAP-Request 186 Description 188 RADIUS-EAP-Request packets are sent by the Radius Client to the 189 Radius Server, and convey EAP-Responses from the client through the 190 NAS and on to the Radius server. RADIUS-EAP-Requests will normally 191 include a single EAP-Packet attribute which contains the EAP packet. 192 A RADIUS-EAP-Request sent from the NAS to the RADIUS server that 193 does not contain an EAP-Packet attribute signals to the RADIUS 194 server that it is to initiate EAP authentication with the client. 196 Upon receipt of a RADIUS-EAP-Request, A RADIUS Server MUST 197 issue a reply. The reply may be either: 1) a RADIUS-EAP-Response 198 containing an EAP-Request in a single EAP-Packet attribute, 2) a 199 RADIUS-EAP-Ack containing an EAP-Packet of type "success", or 3) a 200 RADIUS-EAP-Reject containing an EAP-Packet of type "failure". A 201 Command-Unrecognized packet is returned if the server does not 202 support EAP. 204 A summary of the RADIUS-EAP-Request packet format is shown 205 below. The fields are transmitted from left to right. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Code | Flags | Ver | Command | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Identifier | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | Authenticator | 216 | | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 | Message Integrity Code | 221 | | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Attributes ... 225 +-+-+-+-+-+-+-+-+-+-+-+-+- 227 Code 229 254 for Enhanced RADIUS. 231 Flags 233 The Flag field is used as defined in [1]. 235 Version 237 MUST be set to 2 239 Command 241 300 for RADIUS-EAP-Request 243 Identifier 245 The Identifier field MUST be changed whenever the content of the 246 Attributes field changes, and whenever a valid reply has been 247 received for a previous request. For retransmissions, the 248 Identifier MAY remain unchanged. 250 Length 252 The total length of the message, including this header. 254 Authenticator 256 The Authenticator field is a random 16 octet value. If the 257 Timestamp option is supported, the first four octets contain a 258 timestamp of when the packet was sent from the peer. 260 Message Integrity Code 262 This field contains an MD5 hash of the following: 264 MD5( packet | Shared Secret ) 266 Attributes 268 The Attribute field is variable in length, and contains a list of 269 zero or more Attributes. It MAY contain zero or one EAP-Packet 270 attributes. If it does not contain an EAP-Packet attribute, it is 271 an indication to the server that server that EAP should be 272 initiated by the server. If it contains one EAP-Packet attribute, 273 this attribute contains the reply to the last EAP-Request issued by 274 the server (or the reply to the EAP-Identity that can be issued by 275 the NAS). The remainder of the attributes are those normally sent 276 on an Access-Request by the NAS. 278 3.2 RADIUS-EAP-Response 280 Description 282 RADIUS-EAP-Response packets are sent by the RADIUS-Server to the 283 NAS. They contain the next EAP-Request packet to be passed to the 284 client. 286 The RADIUS-EAP-Response MUST contain a single EAP-Packet 287 attribute. 289 After issuing the included EAP-Request to the client, the NAS 290 remains in a state where it awaits further EAP-Responses from the 291 client. 293 A summary of the RADIUS-EAP-Request packet format is shown 294 below. The fields are transmitted from left to right. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Code | Flags | Ver | Command | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Identifier | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 | Authenticator | 305 | | 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 | Message Integrity Code | 310 | | 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Attributes ... 314 +-+-+-+-+-+-+-+-+-+-+-+-+- 316 Code 318 254 for Enhanced RADIUS. 320 Flags 322 The Flag field is used as defined in [1]. 324 Version 326 MUST be set to 2 328 Command 330 301 for RADIUS-EAP-Response 332 Identifier 334 The Identifier field is a copy of the Identifier field of the 335 RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent. 337 Length 339 The total length of the message, including this header. 341 Authenticator 343 The Authenticator field is a random 16 octet value. If the 344 Timestamp option is supported, the first four octets contain a 345 timestamp of when the packet was sent from the peer. 347 Message Integrity Code 349 This field contains an MD5 hash of the following: 351 MD5( packet | Shared Secret ) 353 Attributes 355 The Attribute field MUST contains only a single EAP-Packet 356 attribute which contains an EAP-Request packet. 358 3.3 RADIUS-EAP-Ack 360 Description 362 RADIUS-EAP-Ack packets are sent by the RADIUS server to the NAS. 363 They contain the next EAP-Request or EAP-Success packet to be 364 passed to the client. 366 The RADIUS-EAP-Ack packet MUST contain a single EAP-Packet 367 attribute. 369 After issuing the included EAP-Success packet to the client, the 370 NAS should end the authentication phase with a positive response. 372 A summary of the RADIUS-EAP-Ack packet format is shown below. The 373 fields are transmitted from left to right. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Code | Flags | Ver | Command | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Identifier | Length | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | Authenticator | 384 | | 385 | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 | Message Integrity Code | 389 | | 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Attributes ... 393 +-+-+-+-+-+-+-+-+-+-+-+-+- 395 Code 397 254 for Enhanced RADIUS. 399 Flags 401 The Flag field is used as defined in [1]. 403 Version 405 MUST be set to 2 407 Command 409 302 for RADIUS-EAP-Ack 411 Identifier 413 The Identifier field is a copy of the Identifier field of the 414 RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent. 416 Length 418 The total length of the message, including this header. 420 Authenticator 422 The Authenticator field is a random 16 octet value. If the 423 Timestamp option is supported, the first four octets contain a 424 timestamp of when the packet was sent from the peer. 426 Message Integrity Code 428 This field contains an MD5 hash of the following: 430 MD5( packet | Shared Secret ) 432 Attributes 434 The Attribute field contains only a single EAP-Packet attribute 435 which contains an EAP-Request packet. 437 3.4 RADIUS-EAP-Reject 439 Description 441 RADIUS-EAP-Reject packets are sent by the RADIUS server to the NAS. 442 They are sent in response to a RADIUS-EAP-Request that results in 443 an authentication failure. RADIUS-EAP-Reject packets contain a 444 single EAP-Packet attribute containing an EAP failure packet. 446 After issuing the included EAP failure packet to the client, the 447 NAS should end the authentication phase with a negative result. 449 A summary of the RADIUS-EAP-Reject packet format is shown below. 450 The fields are transmitted from left to right. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Code | Flags | Ver | Command | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Identifier | Length | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 | Authenticator | 461 | | 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 | Message Integrity Code | 466 | | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Attributes ... 470 +-+-+-+-+-+-+-+-+-+-+-+-+- 472 Code 474 254 for Enhanced RADIUS. 476 Flags 478 The Flag field is used as defined in [1]. 480 Version 482 MUST be set to 2 484 Command 486 303 for RADIUS-EAP-Reject 488 Identifier 490 The Identifier field is a copy of the Identifier field of the 491 RADIUS-EAP-Request which caused this RADIUS-EAP-Reject to be sent. 493 Length 495 The total length of the message, including this header. 497 Authenticator 499 The Authenticator field is a random 16 octet value. If the 500 Timestamp option is supported, the first four octets contain a 501 timestamp of when the packet was sent from the peer. 503 Message Integrity Code 505 This field contains an MD5 hash of the following: 507 MD5( packet | Shared Secret ) 509 Attributes 511 The Attribute field contains only a single EAP-Packet attribute 512 which contains an EAP-Request packet. Other attributes valid 513 on an Access-Reject message may also be present. 515 4. Attribute Name and Attribute Code 517 Attribute Name: EAP-Packet 518 Attribute Code: 300 520 5. Attribute Meanings 522 5.1 EAP-Packet 524 Description 526 This attribute is used to contain the actual EAP-Requests to be 527 sent from the Radius server to the client (RADIUS-EAP-Ack and 528 RADIUS-EAP-Reject) and the EAP-Responses to be sent from the client 529 to the Radius server (RADIUS-EAP-Requests). These EAP-Requests and 530 Responses are exactly as defined in [2]. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Attribute Type | Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Flags | String ... | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 Type 542 300 for EAP-Packet 544 Length 546 >= 6 548 Flags 550 The Flags field MUST be set to 1 (The attribute MUST be supported 551 by the receiving device). Of course, the attribute would only be 552 supported if the implementation supported EAP. 554 String 556 The String field is the exact EAP packet data to be transported 557 from client to server or server to client. It is not Null 558 terminated and may contain arbitrary binary values. 560 6. Motivation 562 The motivation for this extension to Enhanced RADIUS is to allow 563 RADIUS, which is the most common Authentication protocol deployed 564 today, to keep up with the new authentication protocols currently 565 being worked on by the PPP Extensions WG. 567 This extension allows the NAS' to support a variety of 568 authentication protocols by delegating the task to the 569 Authentication server. The NAS needs to simply forward packets from 570 the PPP client to the local RADIUS Server. Note, however, that the 571 same RADIUS Server must be used throughout the whole transaction 572 process (see section 7 on dealing with proxy'ed requests). If the 573 local RADIUS server becomes unavailable at any time during the 574 authentication phase, the NAS will have to begin LCP negotiations 575 again with the PPP client. 577 Since the EAP messages are simply forwarded from/to the NAS and the 578 RADIUS Server, the support of the Message Integrity Check in the 579 Enhanced RADIUS header allows both parties to authenticate 580 themselves. 582 7. Description (or Implementation Rules) 584 Upon negotiating LCP EAP with the PPP client, the NAS must send a 585 EAP Start message to the local RADIUS Server (note this should only 586 be done if the NAS is aware that its local RADIUS Server is capable 587 of the Enhanced RADIUS protocol [1]). The EAP-Start message is an 588 EAP-Request with no EAP-Packet attribute present. 590 If the RADIUS Server does not support this extension, a 591 Command-Unrecognized message will be returned to the NAS. Upon 592 receipt of this packet, the NAS will NAK the PPP client and request 593 PAP or CHAP as the authentication protocol. 595 For Proxied RADIUS requests there are two methods of processing, 596 if the domain is determined based on the DNIS the RADIUS-server may 597 proxy the initial EAP-Start request. In the case that the domain is 598 determined based on the user id, the local RADIUS-server must 599 issue the EAP-identity request. The response from the PPP user 600 must be proxied to the final authentication server. 602 If the RADIUS Server does support this extension, an EAP-Identity 603 message is returned to the NAS. Upon receipt of this packet, the 604 NAS will complete the LCP negotiation phase and will enter the EAP 605 authentication phase. The NAS will then forward the packet which 606 was contained in the EAP-Packet attribute of the EAP-Request-Ack to 607 the PPP client. 609 For proxied RADIUS requests, a Command-Unrecognized message may be 610 received following the EAP-Identity response. This would occur 611 if the messages was proxied to a RADIUS-server which does not 612 support the EAP extension. 614 Note that if at any point an EAP-Request-Reject message is received 615 from the RADIUS Server, the NAS SHOULD issue an LCP Terminate 616 Request to the PPP Client. 618 At this point, the PPP Client will exchange a series of 619 request/response messages with the RADIUS Server. This is done 620 until either an EAP-Request-Reject is received (which will 621 disconnect the user), or an EAP-Request-Success is received which 622 the NAS would then successfully end the authentication phase. 624 The RADIUS-server will always include the CLASS attribute in all 625 messages to the NAS. The NAS MUST include this same attribute in 626 the subsequent message to the RADIUS-server which includes the 627 response from the PPP client. The CLASS attribute which is 628 associated with the EAP-Request-Success message from the 629 RADIUS-server is the one which should be used by the NAS in 630 all accounting messages for the authenticated user. 632 The RADIUS-EAP-Ack issued by the server to the NAS will contain all 633 of the attributes which are contained in an Access-Accept in 634 addition to the EAP-Packet attribute. 636 The Port number and NAS Identifier are included in the attributes 637 issued by the NAS in the original RADIUS-EAP-Request message. 639 The NAS is not responsible for the retransmission of any EAP 640 messages. The PPP client and the RADIUS-server are responsible for 641 for any retransmissions. 643 References 645 [1] Calhoun, Rubens, "Enhanced RADIUS", Internet-Draft, 646 draft-rfced-exp-calhoun-radius-enhanced-00.txt, 647 US Robotics Access Corp., June 1996. 649 [2] Blunk, Volbretch, "PPP Extensible Authentication Protocol", 650 Internet-Draft, draft-ietf-pppext-eap-auth-01.txt., 651 Merit Networks Inc., July 1995.