Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-radius-eap-00.txt < prev next >

Wrap

Text File | 1997-02-19 | 31KB | 793 lines

RADIUS Working Group Pat Calhoun INTERNET-DRAFT US Robotics Access Corp. <draft-ietf-radius-eap-00.txt> Allan C. Rubens 19 February 1997 Merit Network, Inc. Bernard Aboba Microsoft Extensible Authentication Protocol Support in RADIUS 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft- ietf-radius-eap-00.txt>, and expires September 1, 1997. Please send comments to the authors. 2. Abstract The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This document describes how the EAP-Message and Signature attributes may be used for providing EAP support within RADIUS. 3. Introduction The Extensible Authentication Protocol (EAP), described in [1], pro- vides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including token cards, Kerberos, Public Key, S/Key, and others. In order to provide for support of EAP within RADIUS, two new attributes, EAP-Message and Signature, were introduced as RADIUS extensions in [5]. This document describes how these new attributes may be used for providing EAP support within RADIUS. Calhoun, Rubens & Aboba [Page 1] INTERNET-DRAFT 19 February 1997 The scheme described here is similar to that proposed in [2], in that the RADIUS server is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and a backend security server. While the conversation between the RADIUS server and the backend security server will typi- cally occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use RADIUS-encapsulated EAP via the EAP-Message attribute. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication- specific code, which can instead reside on a backend security server. 3.1. Requirements language This specification uses the same words as [7] for defining the signif- icance of each particular requirement. These words are: MUST This word, or the adjectives "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the speci- fication. MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- nition is an absolute prohibition of the specification. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interop- erate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another imple- mentation which does not include the option.(except, of course, for the feature the option provides) An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be Calhoun, Rubens & Aboba [Page 2] INTERNET-DRAFT 19 February 1997 "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant." 4. Protocol overview The EAP conversation between the authenticating peer and the NAS begins with the negotiation of EAP within LCP. Once EAP has been nego- tiated, the NAS will typically send to the RADIUS server a RADIUS Access-Request packet containing an EAP-Message attribute signifying EAP-Start. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). The Port number and NAS Identifier are included in the attributes issued by the NAS in the Access-Request packet. If the RADIUS server supports EAP, it MUST respond with an Access- Challenge packet containing an EAP-Message attribute. The EAP-Message attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. The Access-Challenge typically will con- tain an EAP-Message attribute encapsulating an EAP-Request/Identity message, requesting the authenticating peer to identify itself. The NAS will then respond with a RADIUS Access-Request packet containing an EAP-Message attribute encapsulating an EAP-Response, etc. The con- versation continues until either a RADIUS Access-Reject packet is received (with an EAP-Message attribute encapsulating EAP-Failure) which results in the NAS disconnecting the user, or a RADIUS Access- Accept packet is received (with an EAP-Message attribute encapsulating EAP-Success) successfully ending the authentication phase. Note that if a RADIUS Access-Reject packet with an EAP-Message attribute encap- sulating EAP-Failure is received from the RADIUS Server, the NAS SHOULD issue an LCP Terminate Request to the authenticating peer. The above scenario creates a situation in which the NAS never needs to manipulate an EAP packet. An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer. This involves having the NAS send an EAP- Request/Identity message to the authenticating peer, and forwarding the EAP-Response/Identity packet to the RADIUS server in the EAP-Mes- sage attribute of a RADIUS Access-Request packet. While this approach will save a round-trip, it cannot be universally employed. There are circumstances in which the user's identity may not be needed (such as when authentication and accounting is handled based on the calling or called phone number), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. Unless the NAS interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user's iden- tity. Therefore, it is suggested that the RADIUS Server return the user's identity by inserting it in the User-Name attribute of subse- quent Access-Challenge and Access-Accept packets. Without the user's identity, accounting and billing becomes very difficult to manage. Calhoun, Rubens & Aboba [Page 3] INTERNET-DRAFT 19 February 1997 In cases where a backup RADIUS servers is available, were the primary server to fail at any time during the EAP conversation, it would be desirable for the NAS to be able to redirect the conversation to an alternate RADIUS server. However, for the backup server to be able to pick up the conversation, it must be provided with the state of the EAP conversation prior to the interruption. This can be accomplished by having the RADIUS Access-Request include the series of EAP-Message attributes representing the previous history of the EAP conversation. Similarly, the RADIUS Challenge returned by the RADIUS server must also include all previous EAP-Message attributes. The sequence number field in the EAP-Message attribute MUST be used in order to determine which attribute is to be processed. The attribute with the highest sequence number is the most recent attribute. The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain all of the expected attributes which are currently returned in an Access-Accept packet. For proxied RADIUS requests there are two methods of processing. If the domain is determined based on the DNIS the RADIUS Server may proxy the initial RADIUS Access-Request/EAP-Start. If the domain is deter- mined based on the user's identity, the local RADIUS Server MUST respond with a RADIUS Access-Challenge/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server. For proxied RADIUS requests, the NAS may receive an Access-Reject packet in response to its Access-Request/EAP-Identity packet. This would occur if the message was proxied to a RADIUS Server which does not support the EAP-Message extension. At this point, the NAS MUST re-open LCP with the authenticating peer and request either CHAP or PAP as the authentication protocol. Again, such an Access-Reject packet indicating lack of EAP capability will not contain an EAP-Mes- sage attribute. If the NAS is unable to negotiate EAP with the authenticating peer, what happens next is a matter of policy. In circumstances where EAP is required of all users accessing the NAS, the NAS MUST disconnect the user. However, in circumstances where EAP is mandatory for some users, and optional or not required for others, the decision cannot be made until the user's identity is ascertained. In this case, the NAS will negotiate another authentication method, such as CHAP, and will pass the User-Name and CHAP-Password attributes to the RADIUS Server in an Access-Request packet. If the user is not required to use EAP, then the RADIUS Server will respond with an Access-Accept or Access-Reject packet as appropriate. However, should the user require EAP, then the RADIUS Server will respond with an Access-Challenge packet containing an EAP-Message attribute. The EAP-Message attribute will either encap- sulate an EAP-Request/Identity packet, or if the RADIUS Server makes use of the User-Name attribute in the Access-Request, it may encapsu- late an EAP challenge. On receiving the EAP-Message attribute, the NAS will either attempt to negotiate EAP if it had not done so previously, Calhoun, Rubens & Aboba [Page 4] INTERNET-DRAFT 19 February 1997 or if negotiation had previously been attempted and failed, it MUST disconnect the user. The NAS is not responsible for the retransmission of any EAP messages. The authenticating peer and the RADIUS Server are responsible for any retransmissions. The example below shows the conversation between the authenticating peer, NAS, and RADIUS server, for the case of an S/Key authentication. S/Key is used only for illustrative purposes; other authentication protocols could also have been used, although they would show somewhat different behavior. Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP EAP-Request PPP LCP EAP ACK -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request S-Key/S-Key Challenge <- PPP EAP-Request/ S-Key/ S-Key Challenge PPP EAP-Response/ S-Key, S-Keypw -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ S-Key, S-Keypw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success IPCP phase starts Calhoun, Rubens & Aboba [Page 5] INTERNET-DRAFT 19 February 1997 In the case where the NAS sends the authenticating peer an EAP- Request/Identity packet without first sending an EAP-Start packet to the RADIUS server, the conversation would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP EAP-Request PPP LCP EAP ACK -> <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request S-Key/S-Key Challenge <- PPP EAP-Request/ S-Key/ S-Key Challenge PPP EAP-Response/ S-Key, S-Keypw -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ S-Key, S-Keypw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success IPCP phase starts In the case where the client fails EAP authentication, the conversa- tion would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP EAP-Request PPP LCP EAP ACK -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ Calhoun, Rubens & Aboba [Page 6] INTERNET-DRAFT 19 February 1997 Identity PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request S-Key/S-Key Challenge <- PPP EAP-Request/ S-Key/ S-Key Challenge PPP EAP-Response/ S-Key, S-Keypw -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ S-Key, S-Keypw -> <- RADIUS Access-Reject/ EAP-Message/EAP-Failure <- PPP EAP-Failure (client disconnected) In the case that the RADIUS server or proxy does not support EAP-Mes- sage, the conversation would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP EAP-Request PPP LCP EAP ACK -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject <- PPP LCP CHAP-Request PPP LCP CHAP-Response-> RADIUS Access-Request-> <- RADIUS Access-Accept In the case where the local RADIUS Server does support EAP-Message, but the remote RADIUS Server does not, the conversation would appear as follows: Calhoun, Rubens & Aboba [Page 7] INTERNET-DRAFT 19 February 1997 Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP EAP-Request PPP LCP EAP ACK -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote RADIUS Server) <- PPP LCP CHAP-Request PPP LCP CHAP-Response-> RADIUS Access-Request-> <- RADIUS Access-Accept (proxied from remote RADIUS Server) In the case where the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP EAP-Request PPP LCP EAP NACK -> <- PPP LCP CHAP-Request PPP LCP CHAP-Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Challenge/ EAP-Message Calhoun, Rubens & Aboba [Page 8] INTERNET-DRAFT 19 February 1997 (User Disconnected) 5. Alternative uses While the conversation between the RADIUS server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use RADIUS-encapsulated EAP via the EAP-Message and Signature attributes. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code within the RADIUS server. Authentication-specific code can then reside on a backend security server instead. In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a backend security server, the Security Server will typically return an Access-Accept/EAP-Success message without inclusion of the expected attributes currently returned in an Access-Accept. This means that the RADIUS server will need to add these attributes prior to sending an Access-Accept/EAP-Success message to the NAS. 6. Attributes 6.1. EAP-Message Description This attribute encapsulates Extensible Authentication Protocol [1] packets so as to allow the NAS to authenticate dial-in users via EAP without having to understand the protocol. The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS Server within an Access-Request message. The RADIUS Server may then return EAP message in Access-Challenge, Access-Accept and Access-Reject packets. Access-Request packets including one or more EAP-Message attributes MUST also contain a Signature attribute, described in [5], in order to provide for authentication of the shuttled EAP packets. Access- Requests including an EAP-Message attribute without a Signature attribute SHOULD be silently discarded by the RADIUS server. A RADIUS Server supporting EAP-Message MUST calculate the correct value of the Signature and silently discard the packet if it does not match the value sent. A RADIUS Server not supporting EAP-Mes- sage MUST return an Access-Reject. A RADIUS Server receiving EAP messages that it does not understand SHOULD return an Access- Reject. A summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right. Calhoun, Rubens & Aboba [Page 9] INTERNET-DRAFT 19 February 1997 0 1 2 3 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence No. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 67 for EAP-Message Length >=5 (EAP packet enclosed) =2 (EAP start message) Sequence Number The Sequence Number field, which is two octets in length, is used in order to build a "history" of the transaction. The EAP-Message attribute with the highest identifier represents the current packet to process. The history is passed along in each Access- request/Access-Challenge in order to support the concept of RADIUS backup servers, as described earlier. EAP-Message attributes with the same sequence number are to be con- catenated, in order to allow an EAP packet to be larger than the 253 octet limit for a RADIUS attribute. String The String field includes EAP packets, as defined in [1]: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7. Acknowledgments Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren- dra Gidwani of Microsoft for useful discussions of this problem space. 8. References [1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network, Calhoun, Rubens & Aboba [Page 10] INTERNET-DRAFT 19 February 1997 Inc., June, 1996. [2] A. Rubens, P.R. Calhoun. "DIAMETER Extensible Authentication Pro- tocol Support." draft-calhoun-diameter-eap-00.txt, Merit Network, Inc., US Robotics Access Corp., February, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, Daydreamer, January, 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1997. [5] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- ext-00.txt, Livingston, January, 1997. [6] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." draft-bradner-key-words-02.txt, Harvard University, August, 1996. 9. Authors' Addresses Pat R. Calhoun US Robotics Access Corp. 8100 N. McCormick Blvd. Skokie, IL 60076-2999 Phone: 847-342-6898 EMail: pcalhoun@usr.com Allan C. Rubens Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 Phone: 313-647-0417 EMail: acr@merit.edu Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Calhoun, Rubens & Aboba [Page 11] INTERNET-DRAFT 19 February 1997 Calhoun, Rubens & Aboba [Page 12]