Internet Draft Allan Rubens Category: Experimental Merit Network, Incorporated expires in six months Pat R. Calhoun US Robotics Access Corp. June 1996 Enhanced Remote Authentication Dial In User Service (RADIUS) Extensible Authentication Protocol Support Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 material 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). Abstract The RADIUS Protocol allows for authentication using existing PPP authentication protocols such as PAP and CHAP. This document describes how the Enhanced RADIUS Protocol could also include the PPP Extensible Authentication Protocol, EAP. Rubens [Page 1] DRAFT Extensible Authentication Protocol Support June 1996 1. Introduction The PPP extensions WG is considering a new authentication protocol for PPP called EAP - PPP Extensible Authentication Protocol. EAP is described in [2]. EAP is intended to provide support for authentication protocols which do not fit into the PAP or CHAP model using a standard mechanism. The protocols include varieties of smart cards, S/key, Public Key and Kerberos. EAP is designed to allow a RADIUS style helper to handle all authentication protocol support where the NAS acts as a transit mechanism for EAP packets. The following diagram gives an example of how an EAP authentication using S/key might be accomplished with Enhanced RADIUS. This example may be extended to other EAP protocols easily, but this concrete example serves to make it a easier to understand the basic concept: PPP-Client NAS (RADIUS-client) RADIUS-server ---------- ------------------- ------------- 1) <-- LCP EAP-Request 2) LCP EAP ACK --> 3) Start-EAP --> 4) <-- EAP/identity 5) <-- EAP/identity 6) EAP-resp/myid --> 7) EAP-resp/myid --> 8) <-- EAP/S-key:S-key challenge 9) <-- EAP/S-key:S-key challenge 10) EAP-resp/myid:S-keypw --> 11) EAP/myid:S-keypw --> 12) <-- EAP/Success 13) <-- EAP/Success Rubens [Page 2] DRAFT Extensible Authentication Protocol Support June 1996 The following describes one way to make this work with RADIUS: a) Upon receiving an EAP-Response as the authentication protocol, the NAS sends a RADIUS-EAP-Request to the RADIUS-server. The absence of an EAP-Packet attribute in this request indicates that this is a Start-EAP indication. b) The RADIUS-server responds by sending a RADIUS-EAP-ACK with an EAP-Packet attribute specifying the EAP packet to be issued to the NAS. The EAP type of this packet will normally be "Identity", but it could be any other valid EAP type if the server does not need to know the user identity before beginning authentication. The NAS forwards the EAP packet on to the PPP client. c) The PPP client responds by sending an EAP-Response packet, which the NAS forwards to the RADIUS-server in the EAP-Packet attribute of a RADIUS-EAP-Request. d) Based on the user's identity, the RADIUS-server determines if it is able to authenticate the user locally, otherwise it may proxy the request to a remote RADIUS server. e) The RADIUS-server decides whether the response is okay and sends a RADIUS-EAP-Ack or RADIUS-EAP-Reject with the appropriate EAP success/failure packet inside an EAP-MSG attribute. The NAS forwards the EAP packet to the PPP client, and accepts or rejects the connection. The above scenario creates a situation in which the NAS never needs to touch an EAP packet. An alternative which may be used by NAS vendors wanting to simplify things would be for the NAS to, 1) always send an EAP Identity request message to the client, and 2) to forward the response to the RADIUS-server in the EAP-Packet attribute of a RADIUS-EAP-Request. Unless the NAS interprets the EAP-Packet field of RADIUS-EAP-Requests, it will not see the user id supplied by the client. Rather than doing this interpretation, it is suggested that a simple mechanism be defined for the RADIUS server to set the userid in the NAS with a special attribute. It is important to have a userid for logging and accounting purposes. In the case where the RADIUS Server does not support the EAP Extension, the following scenario would occur: Rubens [Page 3] DRAFT Extensible Authentication Protocol Support June 1996 PPP-Client NAS (RADIUS-client) RADIUS-server ---------- ------------------- ------------- 1) <-- LCP EAP-Request 2) LCP EAP ACK --> 3) Start-EAP --> 4) <-- Command Unrecognized 5) <-- LCP CHAP Request In the case where the local RADIUS-server does support EAP, but the remote RADIUS-server does not, the following would occur: PPP-Client NAS (RADIUS-client) RADIUS-server RADIUS-Server ---------- ------------------- ------------- ------------- 1) <-- LCP EAP-Request 2) LCP EAP ACK --> 3) Start-EAP --> 4) <-- EAP/identity 5) <-- EAP/identity 6) EAP-resp/myid --> 7) EAP-resp/myid --> 8) EAP-resp/myid --> 9) <-- Command Unrecognized 10) <-- Command Unrecognized 11) <-- LCP CHAP Request Rubens [Page 4] DRAFT Extensible Authentication Protocol Support June 1996 2. Command Name and Command Code Command Name: RADIUS-EAP-Request Command Code: 300 Command Name: RADIUS-EAP-Response Command Code: 301 Command Name: RADIUS-EAP-Ack Command Code: 302 Command Name: RADIUS-EAP-Reject Command Code: 303 3. Command Meanings 3.1 RADIUS-EAP-Request Description RADIUS-EAP-Request packets are sent by the Radius Client to the Radius Server, and convey EAP-Responses from the client through the NAS and on to the Radius server. RADIUS-EAP-Requests will normally include a single EAP-Packet attribute which contains the EAP packet. A RADIUS-EAP-Request sent from the NAS to the RADIUS server that does not contain an EAP-Packet attribute signals to the RADIUS server that it is to initiate EAP authentication with the client. Upon receipt of a RADIUS-EAP-Request, A RADIUS Server MUST issue a reply. The reply may be either: 1) a RADIUS-EAP-Response containing an EAP-Request in a single EAP-Packet attribute, 2) a RADIUS-EAP-Ack containing an EAP-Packet of type "success", or 3) a RADIUS-EAP-Reject containing an EAP-Packet of type "failure". A Command-Unrecognized packet is returned if the server does not support EAP. A summary of the RADIUS-EAP-Request packet format is shown below. The fields are transmitted from left to right. Rubens [Page 5] DRAFT Extensible Authentication Protocol Support June 1996 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Flags | Ver | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Integrity Code | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 254 for Enhanced RADIUS. Flags The Flag field is used as defined in [1]. Version MUST be set to 2 Command 300 for RADIUS-EAP-Request Identifier The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MAY remain unchanged. Rubens [Page 6] DRAFT Extensible Authentication Protocol Support June 1996 Length The total length of the message, including this header. Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet | Shared Secret ) Attributes The Attribute field is variable in length, and contains a list of zero or more Attributes. It MAY contain zero or one EAP-Packet attributes. If it does not contain an EAP-Packet attribute, it is an indication to the server that server that EAP should be initiated by the server. If it contains one EAP-Packet attribute, this attribute contains the reply to the last EAP-Request issued by the server (or the reply to the EAP-Identity that can be issued by the NAS). The remainder of the attributes are those normally sent on an Access-Request by the NAS. 3.2 RADIUS-EAP-Response Description RADIUS-EAP-Response packets are sent by the RADIUS-Server to the NAS. They contain the next EAP-Request packet to be passed to the client. The RADIUS-EAP-Response MUST contain a single EAP-Packet attribute. After issuing the included EAP-Request to the client, the NAS remains in a state where it awaits further EAP-Responses from the client. A summary of the RADIUS-EAP-Request packet format is shown below. The fields are transmitted from left to right. Rubens [Page 7] DRAFT Extensible Authentication Protocol Support June 1996 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Flags | Ver | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Integrity Code | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 254 for Enhanced RADIUS. Flags The Flag field is used as defined in [1]. Version MUST be set to 2 Command 301 for RADIUS-EAP-Response Identifier The Identifier field is a copy of the Identifier field of the RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent. Length The total length of the message, including this header. Rubens [Page 8] DRAFT Extensible Authentication Protocol Support June 1996 Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet | Shared Secret ) Attributes The Attribute field MUST contains only a single EAP-Packet attribute which contains an EAP-Request packet. 3.3 RADIUS-EAP-Ack Description RADIUS-EAP-Ack packets are sent by the RADIUS server to the NAS. They contain the next EAP-Request or EAP-Success packet to be passed to the client. The RADIUS-EAP-Ack packet MUST contain a single EAP-Packet attribute. After issuing the included EAP-Success packet to the client, the NAS should end the authentication phase with a positive response. A summary of the RADIUS-EAP-Ack packet format is shown below. The fields are transmitted from left to right. Rubens [Page 9] DRAFT Extensible Authentication Protocol Support June 1996 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Flags | Ver | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Integrity Code | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 254 for Enhanced RADIUS. Flags The Flag field is used as defined in [1]. Version MUST be set to 2 Command 302 for RADIUS-EAP-Ack Identifier The Identifier field is a copy of the Identifier field of the RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent. Length The total length of the message, including this header. Rubens [Page 10] DRAFT Extensible Authentication Protocol Support June 1996 Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet | Shared Secret ) Attributes The Attribute field contains only a single EAP-Packet attribute which contains an EAP-Request packet. 3.4 RADIUS-EAP-Reject Description RADIUS-EAP-Reject packets are sent by the RADIUS server to the NAS. They are sent in response to a RADIUS-EAP-Request that results in an authentication failure. RADIUS-EAP-Reject packets contain a single EAP-Packet attribute containing an EAP failure packet. After issuing the included EAP failure packet to the client, the NAS should end the authentication phase with a negative result. A summary of the RADIUS-EAP-Reject packet format is shown below. The fields are transmitted from left to right. Rubens [Page 11] DRAFT Extensible Authentication Protocol Support June 1996 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Flags | Ver | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Integrity Code | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 254 for Enhanced RADIUS. Flags The Flag field is used as defined in [1]. Version MUST be set to 2 Command 303 for RADIUS-EAP-Reject Identifier The Identifier field is a copy of the Identifier field of the RADIUS-EAP-Request which caused this RADIUS-EAP-Reject to be sent. Length The total length of the message, including this header. Rubens [Page 12] DRAFT Extensible Authentication Protocol Support June 1996 Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet | Shared Secret ) Attributes The Attribute field contains only a single EAP-Packet attribute which contains an EAP-Request packet. Other attributes valid on an Access-Reject message may also be present. 4. Attribute Name and Attribute Code Attribute Name: EAP-Packet Attribute Code: 300 5. Attribute Meanings 5.1 EAP-Packet Description This attribute is used to contain the actual EAP-Requests to be sent from the Radius server to the client (RADIUS-EAP-Ack and RADIUS-EAP-Reject) and the EAP-Responses to be sent from the client to the Radius server (RADIUS-EAP-Requests). These EAP-Requests and Responses are exactly as defined in [2]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | String ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rubens [Page 13] DRAFT Extensible Authentication Protocol Support June 1996 Type 300 for EAP-Packet Length >= 6 Flags The Flags field MUST be set to 1 (The attribute MUST be supported by the receiving device). Of course, the attribute would only be supported if the implementation supported EAP. String The String field is the exact EAP packet data to be transported from client to server or server to client. It is not Null terminated and may contain arbitrary binary values. 6. Motivation The motivation for this extension to Enhanced RADIUS is to allow RADIUS, which is the most common Authentication protocol deployed today, to keep up with the new authentication protocols currently being worked on by the PPP Extensions WG. This extension allows the NAS' to support a variety of authentication protocols by delegating the task to the Authentication server. The NAS needs to simply forward packets from the PPP client to the local RADIUS Server. Note, however, that the same RADIUS Server must be used throughout the whole transaction process (see section 7 on dealing with proxy'ed requests). If the local RADIUS server becomes unavailable at any time during the authentication phase, the NAS will have to begin LCP negotiations again with the PPP client. Since the EAP messages are simply forwarded from/to the NAS and the RADIUS Server, the support of the Message Integrity Check in the Enhanced RADIUS header allows both parties to authenticate themselves. Rubens [Page 14] DRAFT Extensible Authentication Protocol Support June 1996 7. Description (or Implementation Rules) Upon negotiating LCP EAP with the PPP client, the NAS must send a EAP Start message to the local RADIUS Server (note this should only be done if the NAS is aware that its local RADIUS Server is capable of the Enhanced RADIUS protocol [1]). The EAP-Start message is an EAP-Request with no EAP-Packet attribute present. If the RADIUS Server does not support this extension, a Command-Unrecognized message will be returned to the NAS. Upon receipt of this packet, the NAS will NAK the PPP client and request PAP or CHAP as the authentication protocol. 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 EAP-Start request. In the case that the domain is determined based on the user id, the local RADIUS-server must issue the EAP-identity request. The response from the PPP user must be proxied to the final authentication server. If the RADIUS Server does support this extension, an EAP-Identity message is returned to the NAS. Upon receipt of this packet, the NAS will complete the LCP negotiation phase and will enter the EAP authentication phase. The NAS will then forward the packet which was contained in the EAP-Packet attribute of the EAP-Request-Ack to the PPP client. For proxied RADIUS requests, a Command-Unrecognized message may be received following the EAP-Identity response. This would occur if the messages was proxied to a RADIUS-server which does not support the EAP extension. Note that if at any point an EAP-Request-Reject message is received from the RADIUS Server, the NAS SHOULD issue an LCP Terminate Request to the PPP Client. At this point, the PPP Client will exchange a series of request/response messages with the RADIUS Server. This is done until either an EAP-Request-Reject is received (which will disconnect the user), or an EAP-Request-Success is received which the NAS would then successfully end the authentication phase. The RADIUS-server will always include the CLASS attribute in all messages to the NAS. The NAS MUST include this same attribute in the subsequent message to the RADIUS-server which includes the response from the PPP client. The CLASS attribute which is Rubens [Page 15] DRAFT Extensible Authentication Protocol Support June 1996 associated with the EAP-Request-Success message from the RADIUS-server is the one which should be used by the NAS in all accounting messages for the authenticated user. The RADIUS-EAP-Ack issued by the server to the NAS will contain all of the attributes which are contained in an Access-Accept in addition to the EAP-Packet attribute. The Port number and NAS Identifier are included in the attributes issued by the NAS in the original RADIUS-EAP-Request message. The NAS is not responsible for the retransmission of any EAP messages. The PPP client and the RADIUS-server are responsible for for any retransmissions. References [1] Calhoun, Rubens, "Enhanced RADIUS", Internet-Draft, draft-rfced-exp-calhoun-radius-enhanced-00.txt, US Robotics Access Corp., June 1996. [2] Blunk, Volbretch, "PPP Extensible Authentication Protocol", Internet-Draft, draft-ietf-pppext-eap-auth-01.txt., Merit Networks Inc., July 1995. Rubens [Page 16]