RADIUS Working Group Pat Calhoun INTERNET-DRAFT Sun Microsystems Updates: RFC 2138 Allan C. Rubens Category: Standards Track Merit Network, Inc. Bernard Aboba 8 May 1998 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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). The distribution of this memo is unlimited. It is filed as , and expires November 1, 1998. 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. Changes from -04 draft Updated section on retransmission Added section on fragmentation Added EAP-Timeout attribute Updated references. 4. 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 Calhoun, Rubens & Aboba [Page 1] INTERNET-DRAFT 8 May 1998 authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. In order to provide for support of EAP within RADIUS, two new attributes, EAP-Message and Sig- nature, were introduced as RADIUS extensions in [4]. This document describes how these new attributes may be used for providing EAP sup- port within RADIUS. In the proposed scheme, 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 typically occur using a proprietary pro- tocol developed by the backend security server vendor, it is also pos- sible 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. 4.1. Requirements language This specification uses the same words as [6] 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 "", 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 interoperate 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 implementation Calhoun, Rubens & Aboba [Page 2] INTERNET-DRAFT 8 May 1998 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 "uncondition- ally compliant"; one that satisfies all the must and must not require- ments but not all the should or should not requirements for its proto- cols is said to be "conditionally compliant." 5. Protocol overview The EAP conversation between the authenticating peer (dial-in user) and the NAS begins with the negotiation of EAP within LCP. Once EAP has been negotiated, the NAS MUST send an EAP-Request/Identity message to the authenticating peer, unless identity is determined via some other means such as Called-Station-Id or Calling-Station-Id. The peer will then respond with an EAP-Response/Identity which the the NAS will then forward to the RADIUS server in the EAP-Message attribute of a RADIUS Access-Request packet. The RADIUS Server will typically use the EAP-Response/Identity to determine which EAP type is to be applied to the user. In order to permit non-EAP aware RADIUS proxies to forward the Access- Request packet, if the NAS sends the EAP-Request/Identity, the NAS MUST copy the contents of the EAP-Response/Identity into the User-Name attribute and MUST include the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. NAS-Port SHOULD be included in the attributes issued by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware prox- ies, if a User-Name attribute was included in an Access-Request, the RADIUS Server MUST include the User-Name attribute in subsequent Access-Challenge and Access-Accept packets. Without the User-Name attribute, accounting and billing becomes very difficult to manage. If identity is determined via another means such as Called-Station-Id or Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request, and the RADIUS Server MUST include them in every Access-Challenge and Access-Accept. 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 Called-Station-Id or Calling-Station-Id), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. In cases where an EAP-Request/Identity packet will not be sent, the NAS will send to the RADIUS server a RADIUS Access-Request packet containing an EAP-Message attribute sig- nifying EAP-Start. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). However, it should be noted that since no User-Name attribute is included in the Access-Request, Calhoun, Rubens & Aboba [Page 3] INTERNET-DRAFT 8 May 1998 this approach is not compatible with RADIUS as specified in [2], nor can it easily be applied in situations where proxies are deployed, such as roaming or shared use networks. If the RADIUS server supports EAP, it MUST respond with an Access- Challenge packet containing an EAP-Message attribute. If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. The EAP-Message attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. In the case where the NAS does not initially send an EAP-Request/Identity message to the peer, the Access-Challenge typically will contain an EAP-Message attribute encapsulating an EAP-Request/Identity message, requesting the dial-in user to identify themself. The NAS will then respond with a RADIUS Access-Request packet containing an EAP-Message attribute encapsulat- ing an EAP-Response. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received. Reception of a RADIUS Access-Reject packet, with or without an EAP- Message attribute encapsulating EAP-Failure, MUST result in the NAS issuing an LCP Terminate Request to the authenticating peer. A RADIUS Access-Accept packet with an EAP-Message attribute encapsulating EAP- Success successfully ends the authentication phase. 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. 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. For proxied RADIUS requests there are two methods of processing. If the domain is determined based on the Called-Station-Id, the RADIUS Server may proxy the initial RADIUS Access-Request/EAP-Start. If the domain is determined 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. On receiving an Access-Reject, the NAS MUST send an LCP Terminate Request to the authenticating peer, and disconnect. 5.1. Retransmission As noted in [1], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. Thus if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. As in RADIUS [2], the RADIUS client is responsible for retransmission of packets between the RADIUS client and the RADIUS server. Calhoun, Rubens & Aboba [Page 4] INTERNET-DRAFT 8 May 1998 Note that it may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of EAP-Timeout and Password-Retry attributes within the Access-Challenge packet. 5.2. Fragmentation Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information. 5.3. Examples The example below shows the conversation between the authenticating peer, NAS, and RADIUS server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior. Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> <- PPP EAP-Request/ Identity PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- PPP EAP-Request/ OTP/OTP Challenge PPP EAP-Response/ OTP, OTPpw -> RADIUS Calhoun, Rubens & Aboba [Page 5] INTERNET-DRAFT 8 May 1998 Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts In the case where the NAS first sends an EAP-Start packet to the RADIUS server, the conversation would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EA-Request/ Identity PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- PPP EAP-Request/ OTP/OTP Challenge PPP EAP-Response/ OTP, OTPpw -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success Calhoun, Rubens & Aboba [Page 6] INTERNET-DRAFT 8 May 1998 (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts In the case where the client fails EAP authentication, the conversa- tion would appear as follows: Autheticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> 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 OTP/OTP Challenge <- PPP EAP-Request/ OTP/OTP Challenge PPP EAP-Response/ OTP, OTPpw -> RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- 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: Calhoun, Rubens & Aboba [Page 7] INTERNET-DRAFT 8 May 1998 Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected) 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: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> 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 Terminate (User Disconnected) 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 ------------------- --- ------------- Calhoun, Rubens & Aboba [Page 8] INTERNET-DRAFT 8 May 1998 <- PPP LCP Request-EAP auth PPP LCP NAK-EAP auth -> <- PPP LCP Request-CHAP auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected) In the case where the NAS 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 Request-CHAP auth PP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected) 6. Alternative uses Currently the conversation between the backend security server and the RADIUS server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Radius vendors and backend security vendors, it is recommended that RADIUS-encapsulated EAP be used for this conversation. 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. Calhoun, Rubens & Aboba [Page 9] INTERNET-DRAFT 8 May 1998 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 MUST add these attributes prior to sending an Access-Accept/EAP-Success message to the NAS. 7. Attributes 7.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. If multiple EAP- Messages are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. Access-Accept and Access-Reject packets SHOULD only have ONE EAP- Message attribute in them, containing EAP-Success or EAP-Failure. It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptog- raphy. In order to prevent attackers from subverting EAP by attack- ing RADIUS/EAP, (for example, by modifying the EAP-Success o EAP- Failure packets) it is necessary that RADIUS/EAP provide integrity protection at least as strong as those used in the EAP methods themselves. The Signature attribute specified in [4] MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access- Reject packets containing an EAP-Message attribute. For Access- Accepts the Signature is calculated as specified in [4]. For Access-Challenge, Access-Accept, and Access-Reject packets, the Signature is calculated as follows: Signature = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) The Signature attribute is zeroed for the purposes of the calcula- tion and the shared secret is used as the key for the HMAC-MD5 hash. The Signature is calculated and inserted in the packet before the Authenticator is calculated. Access-Request packets 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 Calhoun, Rubens & Aboba [Page 10] INTERNET-DRAFT 8 May 1998 correct value of the Signature and silently discard the packet if it does not match the value sent. A RADIUS Server not supporting EAP-Message MUST return an Access-Reject if it receives an Access- Request containing an EAP-Message attribute. A RADIUS Server receiving an EAP-Message attribute that it does not understand MUST return an Access-Reject. Access-Challenge, Access-Accept, or Access-Reject packets including an EAP-Message attribute without a Signature attribute SHOULD be silently discarded by the NAS. A NAS 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 summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right. 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 | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 79 for EAP-Message Length >=3 (EAP packet enclosed) =2 (EAP-Start message) String The String field includes EAP packets, as defined in [1]. If mul- tiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be passed by RADIUS. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2. EAP-Timeout Description This attribute is used only in Access-Challenge packets and Calhoun, Rubens & Aboba [Page 11] INTERNET-DRAFT 8 May 1998 provides the NAS with the timeout interval to apply during EAP authentication. A summary of the EAP-Timeout attribute format is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for EAP-Timeout Length 6 Value The field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds the NAS should wait for an EAP- Response before retransmitting. 8. Security considerations Since the purpose of EAP is to provide enhanced security for PPP authentication, it is critical that RADIUS support for EAP be secure. In particular, the following issues must be addressed: Separation of the EAP server and PPP authenticator Connection hijacking Man in the middle attacks Multiple databases Negotiation attacks 8.1. Separation of the EAP server and PPP authenticator As described in [8] and [9], it is possible for the EAP endpoints to mutually authenticate, negotiate a ciphersuite, and derive a session key for subsequent use in PPP encryption. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to pass the session key to the PPP encryption module. The situation may be more complex when EAP/RADIUS is used, since the PPP authenticator will typically not reside on the same machine as the Calhoun, Rubens & Aboba [Page 12] INTERNET-DRAFT 8 May 1998 EAP server. For example, the EAP server may be a backend security server, or a module residing on the RADIUS server. In the case where the EAP server and PPP authenticator reside on dif- ferent machines, there are several implications for security. Firstly, mutual authentication will occur between the peer and the EAP server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to. As described earlier, when EAP/RADIUS is used to encapsulate EAP pack- ets, the Signature attribute is required in EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the RADIUS server. Since the Signature attribute involves a HMAC-MD5 hash, it is possible for the RADIUS server to verify the integrity of the Access-Request as well as the NAS or tunnel server's identity. Similarly, Access-Challenge pack- ets sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel server to determine the integrity of the packet and verify the iden- tity of the RADIUS server. Morever, EAP packets sent via the methods described in [8] and [9] contain their own integrity protection, so that they cannot be successfully modified by a rogue NAS or tunnel server. The second issue that arises in the case of an EAP server and PPP authenticator residing on different machines is that the session key negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the session key from the EAP server to the authenticator or tunnel server that needs to use the key. The specification of this transit mechanism is outside the scope of this document. 8.2. Connection hijacking In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the backend security server. RADIUS does not support encryption, and as described in [2], only Access-Reply and Access- Challenge packets are integrity protected. Moreover, the integrity protection mechanism described in [2] is weaker than that likely to be used by some EAP methods, making it possible to subvert those methods by attacking EAP/RADIUS. In order to provide for authentication of all packets in the EAP exchange, all EAP/RADIUS packets MUST be authenticated using the Sig- nature attribute, as described previously. 8.3. Man in the middle attacks Since RADIUS security is based on shared secrets, end-to-end security is not provided in the case where authentication or accounting packets are forwarded along a proxy chain. As a result, attackers gaining Calhoun, Rubens & Aboba [Page 13] INTERNET-DRAFT 8 May 1998 control of a RADIUS proxy will be able to modify EAP packets in tran- sit without fear of detection. This represents a weakness of RADIUS which cannot be remedied without providing end-to-end data object security. 8.4. Multiple databases In many cases a backend security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the backend security server also functions as a RADIUS server, two separate user databases will exist, each containing information about the security requirements for the user. This represents a weakness, since security may be compromised by a successful attack on either of the servers, or their backend databases. With multiple user databases, adding a new user may require multiple operations, increasing the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In this case, three stores of user information may exist. In order to address these threats, consolidation of databases is rec- ommended. This can be achieved by having both the RADIUS server and backend security server store information in the same backend database; by having the backend security server provide a full RADIUS implementation; or by consolidating both the backend security server and the RADIUS server onto the same machine. 8.5. Negotiation attacks In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or RADIUS server causes the authenticating peer to choose a less secure authentication method so as to make it easier to obtain the user's password. For example, a session that would normally be authenticated with EAP would instead authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via one EAP type occurs via a less secure EAP type, such as MD5. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those described in [7]. Protection against negotiation attacks requires the elimination of downward negotiations. This can be achieved via implementation of per- connection policy on the part of the authenticating peer, and per-user policy on the part of the RADIUS server. For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate EAP when calling one service, while negotiating CHAP for another service, even if both services are accessible via the same phone number. Calhoun, Rubens & Aboba [Page 14] INTERNET-DRAFT 8 May 1998 With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, there is a presumption that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, it is likely that there is some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. For a NAS, it may not be possible to determine whether a user is required to authenticate with EAP until the user's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. In such cases, if any users of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every call. This avoids forcing an EAP-capable client to do more than one authentication, which weakens security. If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Pass- word 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, if CHAP has been negotiated but EAP is required, the RADIUS server MUST respond with an Access-Reject, rather than an Access-Chal- lenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP. If EAP is negotiated but is not supported by the RADIUS proxy or server, then the server or proxy MUST respond with an Access-Reject. In these cases, the NAS MUST send an LCP-Terminate and disconnect the user. This is the correct behavior since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be ful- filled. An EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user dialing in from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user dialing into another location (and encounter- ing an EAP-incapable proxy) might be consistently disconnected. 9. 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. 10. References [1] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Protocol (EAP)." RFC 2284, Merit Network, Inc., March 1998. Calhoun, Rubens & Aboba [Page 15] INTERNET-DRAFT 8 May 1998 [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April 1997. [3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1997. [4] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, draft-ietf-radius-ext-01.txt, Livingston, June, 1997. [5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm." RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [6] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [7] M. Slatalla, J. Quittner. "Masters of Deception." HarperCollins, New York, 1995. [8] B. Aboba, D. Simon. "PPP EAP TLS Authentication Protocol." Work in progress, draft-ietf-pppext-eaptls-03.txt, Microsoft, April 1998. [9] G. Carter. "PPP EAP ISAKMP Authentication Protocol." Work in progress, draft-ietf-pppext-eapisakmp-00.txt, Entrust, November 1997. 11. Authors' Addresses Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025 Phone: 847-548-0926 Fax: 650-786-6445 EMail: pcalhoun@toast.net 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: 425-936-6605 Calhoun, Rubens & Aboba [Page 16] INTERNET-DRAFT 8 May 1998 EMail: bernarda@microsoft.com r Calhoun, Rubens & Aboba [Page 17]