PPPEXT Working Group H. AnderssonINTERNET-DRAFT S. JosefssonCategory: Standards Track RSA Security<draft-josefsson-pppext-eap-tls-eap-05.txt> Glen ZornSeptember 2002 Cisco Dan Simon Ashwin Palekar Microsoft Protected EAP Protocol (PEAP)This document is an Internet-Draft and is in full conformance with allprovisions ofSection 10 of RFC 2026.Internet-Drafts are working documents of the Internet Engineering TaskForce (IETF), its areas, and its working groups. Note that other groupsmay also distribute working documents as Internet- Drafts.Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as reference materialor to cite them other than as "work in progress."The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txtThe list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved.AbstractThe Extensible Authentication Protocol (EAP), defined inRFC 2284,provides for support of multiple authentication methods. While EAP wasoriginally created for use with PPP, it has since been adopted for usewith IEEE 802.1X "Network Port Authentication".Since its deployment, a number of weaknesses in EAP have becomeapparent. These include lack of protection of the user identity or theEAP negotiation; no standardized mechanism for key exchange; no built-insupport for fragmentation and reassembly; and lack of support for fastreconnect.Andersson et al. Standards Track [Page 1]
INTERNET-DRAFT PEAP September 2002By wrapping the EAP protocol within TLS, Protected EAP (PEAP) addressesthese deficiencies. Any EAP method running within PEAP is provided withbuilt-in support for key exchange, session resumption and fragmentationand reassembly.Table of Contents1. Introduction ..........................................31.1 EAP Issues ......................................31.2 Requirements language ...........................51.3 Terminology .....................................52. Protocol overview .....................................62.1 PEAP Part 1 ....................................62.2 PEAP Part 2 ....................................102.3 Version negotiation ............................112.4 Error handling .................................122.5 Retry behavior .................................122.6 Session resumption .............................122.7 Fragmentation ..................................132.8 Key derivation .................................142.9 Ciphersuite negotiation ........................163. Detailed description of the PEAP protocol ............183.1 PEAP Packet Format .............................183.2 PEAP Request Packet ............................203.3 PEAP Response Packet ...........................224. Security considerations ..............................234.1 Method negotiation .............................234.2 TLS session cache handling .....................244.3 Certificate revocation .........................244.4 Separation of EAP server and PPP authenticator..254.5 Separation of PEAP Part 1 and Part 2 Servers ...264.6 Identity verification ..........................275. Normative references ................................286. Informative references ..............................29Appendix A - Examples ........................................31Acknowledgments ..............................................40Author's Addresses ...........................................40Intellectual Property Statement ..............................41Full Copyright Statement .....................................41Andersson et al. Standards Track [Page 2]
INTERNET-DRAFT PEAP September 20021. IntroductionThe Extensible Authentication Protocol (EAP), described in [RFC2284],provides a standard mechanism for support of multiple authenticationmethods. Through the use of EAP, support for a number of authenticationschemes may be added, including smart cards, Kerberos, Public Key, OneTime Passwords, and others.One of the goals of EAP is to enable development of new authenticationmethods without requiring deployment of new code on the Network AccessServer (NAS). As a result, the NAS acts as a "passthrough", and need notunderstand specific EAP methods.Figure 1 describes the relationship between the EAP peer, NAS andbackend authentication server. As described in the figure, the EAPconversation "passes through" the NAS on its way between the client andthe backend authentication server. While the authenticationconversation is between the EAP peer and backend authentication server,the NAS and backend authentication server need to have established trustfor the conversation to proceed.In PEAP, the conversation between the EAP peer and the backend server isencrypted and integrity protected within a TLS channel, and mutualauthentication is required between the EAP peer and the backend server.As a result, the NAS does not have knowledge of the TLS master secretderived between the EAP Peer and the backend authentication server, andcannot decrypt the PEAP conversation. In order to providing keyingmaterial for link-layer ciphersuites however, the NAS does obtain themaster session keys, which are derived from the TLS master secret via aone-way function.1.1. EAP IssuesWith the increasing adoption of EAP, a number of deficiencies havebecome apparent. Since the EAP method negotiation is unprotected, wherean attacker can easily access the medium (such as on a wireless networkor where EAP is run over IP), it is possible for an attacker to injectpackets in order to cause the negotiation of a method with lessersecurity. Denial of service attacks are also possible. By protecting theEAP negotiation within a TLS channel, PEAP addresses this issue.Since the initial EAP Identity Request/Response exchange is sent in theclear, an attacker snooping on the conversation can collect useridentities for use in subsequent attacks. By initially negotiating a TLSchannel, PEAP provies support for identity protection.Andersson et al. Standards Track [Page 3]
INTERNET-DRAFT PEAP September 2002+-+-+-+-+-+ +-+-+-+-+-+| | | || | | || Cipher- | | Cipher- || Suite | | Suite || | | |+-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V+-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+| | EAP | |<======>| || | Conversation | | | || |<================================>| Backend || Client | (over PPP, | NAS | | Server || | 802.11,etc.) | |<=======| || | | | Keys | || | | | | |+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | EAP API | EAP API | | V V+-+-+-+-+-+ +-+-+-+-+-+| | | || | | || EAP | | EAP || Method | | Method || | | |+-+-+-+-+-+ +-+-+-+-+-+Figure 1 - Relationship between EAP client, backend authentication server and NAS.Andersson et al. Standards Track [Page 4]
INTERNET-DRAFT PEAP September 2002Since EAP does not include support for fragmentation and reassembly,individual methods need to include this capability. By including supportfor fragmentation and reassembly within PEAP, methods leveraging PEAP donot need to support this on their own.Where EAP is used for authentication in wireless networks, theauthentication latency is a concern. As a result, it is valuable to beable to do a quick re-authentication on roaming between access points.PEAP supports this capability by leveraging the TLS session resumptionfacility, and any EAP method running under PEAP can take advantage ofit.In order to provide keying material for a wide range of link layerciphersuites, EAP methods need to provide a key hierarchy generatingauthentication and encryption keys, as well as initialization vectors.Development of a secure key hierarchy is complex, and not easy togeneralize for all EAP methods. By relying on the well-reviewed TLS[RFC2246] key derivation method, PEAP provides the required keyingmaterial for any EAP method running within it. This frees EAP methoddevelopers from taking on the difficult (and error prone) task ofdesigning a key hierarchy for each method.1.2. Requirements languageIn this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL","RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted asdescribed in [RFC2119].1.3. TerminologyThis document frequently uses the following terms:Access Point A Network Access Server implementing 802.11.Authenticator The end of the link requiring the authentication.Authentication Server An Authentication Server is an entity that provides an Authentication Service to an NAS. This service verifies from the credentials provided by the peer, the claim of identity made by the peer.Link layer ciphersuite The ciphersuite negotiated for use at the link layer.Andersson et al. Standards Track [Page 5]
INTERNET-DRAFT PEAP September 2002Master key The key derived between the EAP client and EAP server during the EAP authentication process.Master session key The keys derived from the master key that are subsequently used in generation of the transient session keys for authentication, encryption, and IV-generation. So that the master session keys are usable with any link layer ciphersuite, they are longer than is necessary, and are truncated to fit.NAS Short for "Network Access Server".Peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802.1X) or 802.11 wireless link, which is being authenticated by the NAS. In IEEE 802.1X, this end is known as the Supplicant.TLS Ciphersuite The ciphersuite negotiated for protection of the PEAP Part 2 conversation.Transient session keys The transient session keys are derived from the master session keys, and are of the appropriate size and type for use with the chosen link layer ciphersuite.2. Protocol overviewProtected EAP (PEAP) is comprised of a two-part conversation:[1] In Part 1, a TLS session is negotiated, with server authenticating to the client and optionally the client to the server. The negotiated key is then used to encrypt the rest of the conversation.[2] In Part 2, within the TLS session, a complete EAP conversation is carried out, unless part 1 provided client authentication.In the next two sections, we provide an overview of each of the parts ofthe PEAP conversation.2.1. PEAP Part 1The PEAP conversation typically begins with the authenticator and thepeer negotiating EAP. The authenticator will typically send an EAP-Request/Identity packet to the peer, and the peer will respond with anAndersson et al. Standards Track [Page 6]
INTERNET-DRAFT PEAP September 2002EAP-Response/Identity packet to the authenticator, containing the peer'suserId.Once the optional initial Identity Request/Response exchange iscompleted, while nominally the EAP conversation occurs between theauthenticator and the peer, the authenticator MAY act as a passthroughdevice, with the EAP packets received from the peer being encapsulatedfor transmission to a backend authentication server. In the discussionthat follows, we will use the term "EAP server" to denote the ultimateendpoint conversing with the peer.Once having received the peer's Identity, and determined that PEAPauthentication is to occur, the EAP server MUST respond with aPEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP,the Start (S) bit set, and no data. Assuming that the peer supportsPEAP, the PEAP conversation will then begin, with the peer sending anEAP-Response packet with EAP-Type=PEAP.The data field of the EAP-Response packet will encapsulate one or moreTLS records in TLS record layer format, containing a TLS client_hellohandshake message. The current cipher spec for the TLS records will beTLS_NULL_WITH_NULL_NULL and null compression. This current cipher specremains the same until the change_cipher_spec message signals thatsubsequent records will have the negotiated attributes for the remainderof the handshake.The client_hello message contains the client's TLS version number, asessionId, a random number, and a set of TLS ciphersuites supported bythe client. The version offered by the client MUST correspond to TLSv1.0 or later.The EAP server will then respond with an EAP-Request packet with EAP-Type=PEAP. The data field of this packet will encapsulate one or moreTLS records. These will contain a TLS server_hello handshake message,possibly followed by TLS certificate, server_key_exchange,certificate_request, server_hello_done and/or finished handshakemessages, and/or a TLS change_cipher_spec message.Since after the TLS session is established, another complete EAPnegotiation will occur and the peer will authenticate using a secondarymechanism, with PEAP the client need not authenticate as part of TLSsession establishment. As a result, although the EAP-Request packet sentby the EAP Server MAY contain a certificate_request message, this is notrequired.The certificate_request message indicates that the server desires theclient to authenticate itself via public key. Typically when the EAPserver sends a certificate_request message, the intent is to completeAndersson et al. Standards Track [Page 7]
INTERNET-DRAFT PEAP September 2002the PEAP authentication without requiring negotiation of an additionalEAP method, so that only an EAP-Success or EAP-Failure message is sentinside the TLS channel. However, it is valid for the server to requesta certificate in the server_hello and for the client refuse to provideone. In this case, the EAP server MUST require that PEAP Part 2 becompleted.Note that since TLS client certificates are sent in the clear, ifidentity protection is required, then it is possible for the TLSauthentication to be re-negotiated after the first serverauthentication. To accomplish this, after the server_finished messageis sent, and before PEAP part 2, the server sends a TLS hello_request.This allows the client to perform client authentication by sending aclient_hello if it wants to, or, send a no_renegotiation alert to theserver indicating that it wants to continue with PEAP part 2 instead.Since this re-negotiation occurs within the encrypted TLS channel, itdoes not reveal client certificate details.The server_hello handshake message contains a TLS version number,another random number, a sessionId, and a TLS ciphersuite. The versionoffered by the server MUST correspond to TLS v1.0 or later. In order toprovide confidentiality, integrity and replay protection, andauthentication, the negotiated TLS ciphersuite MUST provide all of thesesecurity services.If the client's sessionId is null or unrecognized by the server, theserver MUST choose the sessionId to establish a new session; otherwise,the sessionId will match that offered by the client, indicating aresumption of the previously established session with that sessionID.The server will also choose a TLS ciphersuite from those offered by theclient; if the session matches the client's, then the TLS ciphersuiteMUST match the one negotiated during the handshake protocol executionthat established the session.PEAP implementations need not necessarily support all TLS ciphersuiteslisted in [RFC2246]. Not all TLS ciphersuites are supported by availableTLS tool kits and licenses may be required to support some TLSciphersuites (e.g. TLS ciphersuites utilizing the IDEA encryptionalgorithm). To ensure interoperability, PEAP peers and AuthenticatorsMUST be able to negotiate the following TLS ciphersuites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHATLS as described in [RFC2246] supports compression as well asciphersuite negotiation. Therefore during the PEAP Part 1 conversationthe EAP endpoints MAY request or negotiate TLS compression.Andersson et al. Standards Track [Page 8]
INTERNET-DRAFT PEAP September 2002If the EAP server is not resuming a previously established session, thenit MUST include a TLS server_certificate handshake message, and aserver_hello_done handshake message MUST be the last handshake messageencapsulated in this EAP-Request packet.The certificate message contains a public key certificate chain foreither a key exchange public key (such as an RSA or Diffie-Hellman keyexchange public key) or a signature public key (such as an RSA or DSSsignature public key). In the latter case, a TLS server_key_exchangehandshake message MUST also be included to allow the key exchange totake place.The peer MUST respond to the EAP-Request with an EAP-Response packet ofEAP-Type=PEAP. The data field of this packet will encapsulate one ormore TLS records containing a TLS change_cipher_spec message andfinished handshake message, and possibly certificate, certificate_verifyand/or client_key_exchange handshake messages. If the precedingserver_hello message sent by the EAP server in the preceding EAP-Requestpacket indicated the resumption of a previous session, then the peerMUST send only the change_cipher_spec and finished handshake messages.The finished message contains the peer's authentication response to theEAP server.If the preceding server_hello message sent by the EAP server in thepreceeding EAP-Request packet did not indicate the resumption of aprevious session, then the peer MUST send, in addition to thechange_cipher_spec and finished messages, a client_key_exchange message,which completes the exchange of a shared master secret between the peerand the EAP server.The EAP server MUST then respond with an EAP-Request packet with EAP-Type=PEAP, which includes, in the case of a new TLS session, one or moreTLS records containing TLS change_cipher_spec and finished handshakemessages. The latter contains the EAP server's authentication responseto the peer. The peer will then verify the hash in order toauthenticate the EAP server.If the EAP server authenticates unsuccessfully, the peer MAY send anEAP-Response packet of EAP-Type=PEAP containing a TLS Alert messageidentifying the reason for the failed authentication. The peer MAY senda TLS alert message rather than immediately terminating the conversationso as to allow the EAP server to log the cause of the error forexamination by the system administrator.To ensure that the EAP Server receives the TLS alert message, the peerMUST wait for the EAP-Server to reply before terminating theconversation. The EAP Server MUST reply with an EAP-Failure packetsince server authentication failure is a terminal condition.Andersson et al. Standards Track [Page 9]
INTERNET-DRAFT PEAP September 2002If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=PEAP, and no data. The EAP-Server thencontinues with Part 2 of the PEAP conversation.2.1.1. Forging of Success and Failure packetsWithin EAP, Success and Failure packets are not authenticated, so thatthey may be forged by an attacker without fear of detection. Forged EAPFailure packets can be used to convince an EAP peer to disconnect.Forged EAP Success packets may be used by a rogue NAS to convince a peerto let itself access the network, even though the NAS has notauthenticated itself.By requiring mutual authentication and by encrypting and integrityprotecting the EAP conversation within a TLS channel, PEAP providesprotection against these attacks. Since the EAP Server MUST authenticateitself to the EAP Peer in PEAP Part 1, once the TLS channel has beenbrought up, EAP Success or Failure packets should be sent down theencrypted channel, rather than being sent in cleartext. As a result,once PEAP has been selected as the authentication method, and the PEAPconversation has begun, a peer receiving cleartext Success or Failurepackets MUST silently discard them.2.2. PEAP Part 2The second portion of the PEAP conversation consists of another completeEAP conversation occurring within the TLS session negotiated in PEAPPart 1. It will therefore occur only if establishment of the TLS sessionin Part 1 is successful. It MUST NOT occur if the EAP Serverauthenticates unsuccessfully or if an EAP-Failure has been sent by theEAP Server to the peer, terminating the conversation. Since all packetssent within the PEAP Part 2 conversation occur after TLS sessionestablishment, they are protected using the negotiated TLS ciphersuite.Part 2 of the PEAP conversation typically begins with the Authenticatorsending an EAP-Request/Identity packet to the peer, protected by the TLSciphersuite negotiated in PEAP Part 1. The peer responds with an EAP-Response/Identity packet to the authenticator, containing the peer'suserId. Since this Identity Request/Response exchange is protected bythe ciphersuite negotiated in TLS, it is protected against snooping orpacket modification attacks.After the TLS session-protected Identity exchange, the EAP server willthen select authentication method(s) for the peer, and will send an EAP-Request with the EAP-Type set to the initial method. As described in[RFC2284], the peer can NAK the suggested EAP method, suggesting analternative. Since the NAK will be sent within the TLS channel, it isprotected from snooping or packet modification. As a result, an attackerAndersson et al. Standards Track [Page 10]
INTERNET-DRAFT PEAP September 2002snooping on the exchange will be unable to inject NAKs in order to"negotiate down" the authentication method. An attacker will also notbe able to determine which EAP method was negotiated.As with a normal EAP conversation described in [RFC2284], an EAPconversation encapsulated within the TLS channel as within PEAP Part 2continues until the EAP server sends an EAP-Failure or EAP-Success. Thereceipt of an EAP-Failure or EAP-Success within the TLS protectedchannel results in a shutdown of the TLS channel by the peer and EAPserver. The EAP-Failure or EAP-Success packet sent within the TLSchannel is protected from snooping or packet modification, and as aresult, while an EAP server MAY send an additional EAP-Failure or EAP-Success message in cleartext, this is not required, since it addsanother round-trip. As described in [RFC2869], a RADIUS Access-Accept orAccess-Reject packet need not contain an EAP-Message attribute, sincethe NAS determines the success of the conversation from the RADIUSmessage (Accept/Reject), not the encapsulated EAP-Message attribute.2.3. Version negotiationPEAP packets contain a two bit version field, which enables PEAPimplementations to be backward compatible with previous versions of theprotocol. Implementations of this specification MUST use a version fieldset to 1. Version negotiation proceeds as follows:[1] In the first EAP-Request sent with EAP type=PEAP, the EAP server MUST set the version field to the highest supported version number.[2] If the EAP client supports this version of the protocol, it MUST respond with an EAP-Response of EAP type=PEAP, and the version number proposed by the EAP server.[3] If the EAP client does not support this version, it responds with an EAP-Response of EAP type=PEAP and a lower version number, indicating the highest supported version number.[4] If the EAP server supports the version proposed by the client, then all future EAP-Request and EAP-Response packets of EAP type=PEAP MUST include the version field set to the agreed upon version number.[5] If the EAP server does not support the version number proposed by the EAP client, it responds with an EAP-Failure sent in the clear.This version negotiation procedure guarantees that the EAP client andserver will agree to the latest version supported by both parties. Ifversion negotiation fails, then use of PEAP will not be possible, andanother mutually acceptable EAP method will need to be negotiated ifAndersson et al. Standards Track [Page 11]
INTERNET-DRAFT PEAP September 2002authentication is to proceed.2.4. Error handlingOther than supporting TLS alert messages, PEAP does not have its ownerror message capabilities. This is unnecessary since errors in the PEAPPart 1 conversation are communicated via TLS alert messages, and errorsin the PEAP Part 2 conversation are expected to be handled by individualEAP methods.If an error occurs at any point in the PEAP conversation, the EAP serverSHOULD send an EAP-Request packet with EAP-Type=PEAP, encapsulating aTLS record containing the appropriate TLS alert message. The EAP serverSHOULD send a TLS alert message rather than immediately terminating theconversation so as to allow the peer to inform the user of the cause ofthe failure and possibly allow for a restart of the conversation. Toensure that the peer receives the TLS alert message, the EAP server MUSTwait for the peer to reply with an EAP-Response packet.2.5. Retry behaviorAs with other EAP protocols, the EAP server is responsible for retrybehavior. This means that if the EAP server does not receive a replyfrom the peer, it MUST resend the EAP-Request for which it has not yetreceived an EAP-Response. However, the peer MUST NOT resend EAP-Responsepackets without first being prompted by the EAP server.For example, if the initial PEAP start packet sent by the EAP serverwere to be lost, then the peer would not receive this packet, and wouldnot respond to it. As a result, the PEAP start packet would be resent bythe EAP server. Once the peer received the PEAP start packet, it wouldsend an EAP-Response encapsulating the client_hello message. If theEAP-Response were to be lost, then the EAP server would resend theinitial PEAP start, and the peer would resend the EAP-Response.As a result, it is possible that a peer will receive duplicate EAP-Request messages, and may send duplicate EAP-Responses. Both the peerand the EAP Server should be engineered to handle this possibility.2.6. Session resumptionThe purpose of the sessionId within the TLS protocol is to allow forimproved efficiency in the case where a client repeatedly attempts toauthenticate to an EAP server within a short period of time. Thiscapability is particularly useful for support of wireless roaming.It is left up to the peer whether to attempt to continue a previoussession, thus shortening the PEAP Part 1 conversation. Typically theAndersson et al. Standards Track [Page 12]
INTERNET-DRAFT PEAP September 2002peer's decision will be made based on the time elapsed since theprevious authentication attempt to that EAP server. Based on thesessionId chosen by the peer, and the time elapsed since the previousauthentication, the EAP server will decide whether to allow thecontinuation, or whether to choose a new session.In the case where the EAP server and the authenticator reside on thesame device, then the client will only be able to continue sessions whenconnecting to the same NAS or tunnel server. Should these devices be setup in a rotary or round-robin then it may not be possible for the peerto know in advance the authenticator it will be connecting to, andtherefore which sessionId to attempt to reuse. As a result, it is likelythat the continuation attempt will fail.In the case where the EAP authentication is remoted then continuation ismuch more likely to be successful, since multiple NAS devices and tunnelservers will remote their EAP authentications to the same backendauthentication server.If the EAP server is resuming a previously established session, then itMUST include only a TLS change_cipher_spec message and a TLS finishedhandshake message after the server_hello message. The finished messagecontains the EAP server's authentication response to the peer.2.7. FragmentationA single TLS record may be up to 16384 octets in length, but a TLSmessage may span multiple TLS records, and a TLS certificate message mayin principle be as long as 16MB. The group of PEAP messages sent in asingle round may thus be larger than the PPP MTU size, the maximumRADIUS packet size of 4096 octets, or even the Multilink MaximumReceived Reconstructed Unit (MRRU). As described in [2], the multilinkMRRU is negotiated via the Multilink MRRU LCP option, which includes anMRRU length field of two octets, and thus can support MRRUs as large as64 KB.However, note that in order to protect against reassembly lockup anddenial of service attacks, it may be desirable for an implementation toset a maximum size for one such group of TLS messages. Since a typicalcertificate chain is rarely longer than a few thousand octets, and noother field is likely to be anywhere near as long, a reasonable choiceof maximum acceptable message length might be 64 KB.If this value is chosen, then fragmentation can be handled via themultilink PPP fragmentation mechanisms described in [RFC1990]. Whilethis is desirable, EAP methods are used in other applications such as[IEEE80211] and there may be cases in which multilink or the MRRU LCPoption cannot be negotiated. As a result, a PEAP implementation MUSTAndersson et al. Standards Track [Page 13]
INTERNET-DRAFT PEAP September 2002provide its own support for fragmentation and reassembly.Since EAP is an ACK-NAK protocol, fragmentation support can be added ina simple manner. In EAP, fragments that are lost or damaged in transitwill be retransmitted, and since sequencing information is provided bythe Identifier field in EAP, there is no need for a fragment offsetfield as is provided in IPv4.PEAP fragmentation support is provided through addition of flag bitswithin the EAP-Response and EAP-Request packets, as well as a TLSMessage Length field of four octets. Flags include the Length included(L), More fragments (M), and PEAP Start (S) bits. The L flag is set toindicate the presence of the four octet TLS Message Length field, andMUST be set for the first fragment of a fragmented TLS message or set ofmessages. The M flag is set on all but the last fragment. The S flag isset only within the PEAP start message sent from the EAP server to thepeer. The TLS Message Length field is four octets, and provides thetotal length of the TLS message or set of messages that is beingfragmented; this simplifies buffer allocation.When a PEAP peer receives an EAP-Request packet with the M bit set, itMUST respond with an EAP-Response with EAP-Type=PEAP and no data. Thisserves as a fragment ACK. The EAP server MUST wait until it receives theEAP-Response before sending another fragment. In order to prevent errorsin processing of fragments, the EAP server MUST increment the Identifierfield for each fragment contained within an EAP-Request, and the peerMUST include this Identifier value in the fragment ACK contained withinthe EAP-Response. Retransmitted fragments will contain the sameIdentifier value.Similarly, when the EAP server receives an EAP-Response with the M bitset, it MUST respond with an EAP-Request with EAP-Type=PEAP and no data.This serves as a fragment ACK. The EAP peer MUST wait until it receivesthe EAP-Request before sending another fragment. In order to preventerrors in the processing of fragments, the EAP server MUST increment theIdentifier value for each fragment ACK contained within an EAP-Request,and the peer MUST include this Identifier value in the subsequentfragment contained within an EAP-Response.2.8. Key derivationSince the normal TLS keys are used in the handshake, and thereforeshould not be used in a different context, new keys must be derived fromthe TLS master secret for use with the selected link layer ciphersuites.In the most general case, keying material must be provided forauthentication, encryption and initialization vectors (IVs) in eachdirection.Andersson et al. Standards Track [Page 14]
INTERNET-DRAFT PEAP September 2002Since EAP methods may not know the link layer ciphersuite that has beennegotiated, it may not be possible for them to provide link layerciphersuite-specific keys. In addition, attempting to provide such keysis undesirable, since it would require the EAP method to be revised eachtime a new link layer ciphersuite is developed. As a result, PEAPderives master session keys which can subsequently be truncated for usewith a particular link layer ciphersuite. Since the truncationalgorithms are ciphersuite-specific, they are not discussed here;examples of such algorithms are provided in [RFC3079]. This draft alsodoes not discuss the format of the attributes used to communicate themaster session keys from the backend authentication server to the NAS;examples of such attributes are provided in [RFC2548].For both peer and EAP server, the derivation of master session keysproceeds as follows:[1] Given the master key negotiated by the TLS handshake, the pseudorandom function (PRF) defined in the specification for the version of TLS in use, and the value random defined as the concatenation of the handshake message fields client_hello.random and server_hello.random (in that order), the value PRF(master key, "client PEAP encryption", random) is computed up to 128 bytes, and the value PRF("", "client PEAP encryption", random) is computed up to 64 bytes (where "" is an empty string).[2] The peer master session encryption key (the one used for encrypting data from peer to EAP server) is obtained by truncating to the correct length the first 32 bytes of these two PRF output strings.[3] The EAP server master session encryption key (the one used to encrypting data from EAP server to peer), if different from the client master session encryption key, is obtained by truncating to the correct length the second 32 bytes of this same PRF output string.[4] The peer master session authentication key (the one used for computing MACs for messages from peer to EAP server), if used, is obtained by truncating to the correct length the third 32 bytes of this same PRF output string.[5] The EAP server master session authentication key (the one used for computing MACs for messages from EAP server to peer), if used, and if different from the peer master session authentication key, is obtained by truncating to the correct length the fourth 32 bytes of this same PRF output string.[6] The peer master session initialization vector (IV), used for messages from peer to EAP server, is obtained by truncating to theAndersson et al. Standards Track [Page 15]
INTERNET-DRAFT PEAP September 2002 cipher's block size the first 32 bytes of the second PRF output string mentioned above.[7] Finally, the EAP server master session initialization vector (IV), used for messages from peer to EAP server, is obtained by truncating to the cipher's block size the second 32 bytes of this second PRF output.Algorithms for the truncation of these encryption and authenticationmaster session keys are specific to each link layer ciphersuite. Linklayer ciphersuites in use with PPP include DESEbis [RFC2419], 3DES[RFC2420] and MPPE [RFC3078]. IEEE 802.11 ciphersuites are described in[IEEE80211]. An example of how encryption keys for use with MPPE[RFC3078] are derived from the TLS master session keys is given in[RFC3079]. Additional keys or other non-secret values (such as IVs) canbe obtained as needed by extending the outputs of the PRF beyond 128bytes and 64 bytes, respectively.2.9. Ciphersuite negotiationSince TLS supports TLS ciphersuite negotiation, peers completing the TLSnegotiation will also have selected a TLS ciphersuite, which includeskey strength, encryption and hashing methods. However, unlike in[RFC2716], within PEAP, the negotiated TLS ciphersuite relates only tothe mechanism by which the PEAP Part 2 conversation will be protected,and has no relationship to link layer security mechanisms negotiatedwithin the PPP Encryption Control Protocol (ECP) [RFC1968] or withinIEEE 802.11 [IEEE80211].As a result, PEAP does not support secure negotiation of link layerciphersuites. While such a negotiation is preferable from a securityperspective, it is in practice difficult to integrate with existing PPPand IEEE 802.11 link layer security negotiation, as well as with backendauthentication servers.Depending on the link layer technology in use, the link layer securitynegotiation will occur at different stages in the connection process. InIEEE 802.11, selection of the link layer security mechanism occurs viathe association/re-association messages, prior to authentication. Incontrast, within PPP, link layer security negotiation occurs in ECP[RFC1968], which occurs after authentication.As a result, within IEEE 802.11, by the time that PEAP is invoked, thelink layer security technology has already been selected. Thus if PEAPwere to support a protected link layer ciphersuite negotiation whoseconclusion disagreed with the IEEE 802.11 negotiation, a reassociation(and additional authentication!) would be required to synchronize theresults of the two negotiations. Within PPP, it is conceivable that theAndersson et al. Standards Track [Page 16]
INTERNET-DRAFT PEAP September 2002results of a PEAP secure link layer security negotiation could besubsequently reflected in the ECP negotiation.There are other issues as well. While link layer ciphersuitenegotiation occurs between the peer and the NAS, the EAP conversationoccurs between the peer and the EAP server. Since the EAP server maynot be aware of the link layer ciphersuites supported by the NAS, it isconceivable that the NAS and peer can negotiate a link layer ciphersuitethat is not supported by the NAS. To address this issue, it would benecessary for the NAS to send the list of supported link layerciphersuites to the backend authentication server, and have the backendsecurity server respond with a list of acceptable choices. However, whenused with technologies such as IEEE 802.11 where link layer securitytechnology selection occurs prior to authentication, multipleassociation/reassociation exchanges might be required to synchronize thenegotiations, resulting in extended connectivity loss.The situation typically cannot be addressed merely by omitting IEEE802.11 link layer security negotiation. Unless all users on the AP areto be authenticated with PEAP or an alternative EAP method providingsecure link layer security negotiation, then omitting IEEE 802.11security negotiation would leave some users without the ability tonegotiate security mechanisms.For these reasons, protected negotiation of link layer ciphersuiteswithin PEAP is considered impractical and is omitted from thisspecification.Andersson et al. Standards Track [Page 17]
INTERNET-DRAFT PEAP September 20023. Detailed description of the PEAP protocol3.1. PEAP Packet FormatA summary of the PEAP Request/Response packet 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Flags |Ver| Data...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 1 - Request 2 - ResponseIdentifier The Identifier field is one octet and aids in matching responses with requests.Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.Type 25 - PEAPFlags 0 1 2 3 4 5 +-+-+-+-+-+-+ |L M S R R R| +-+-+-+-+-+-+ L = Length included M = More fragments S = PEAP start R = Reserved (must be zero)Andersson et al. Standards Track [Page 18]
INTERNET-DRAFT PEAP September 2002 The L bit (length included) is set to indicate the presence of the four octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S bit (PEAP start) is set in a PEAP Start message. This differentiates the PEAP Start message from a fragment acknowledgment.Version 0 1 +-+-+ |R 1| +-+-+ R = Reserved (must be zero)Data The format of the Data field is determined by the Code field.Andersson et al. Standards Track [Page 19]
INTERNET-DRAFT PEAP September 20023.2. PEAP Request PacketA summary of the PEAP Request packet format is shown below. The fieldsare 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Flags |Ver| TLS Message Length+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TLS Message Length | TLS Data...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 1Identifier The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet.Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and TLS Response fields.Type 25 - PEAPFlags 0 1 2 3 4 5 +-+-+-+-+-+-+ |L M S R R R| +-+-+-+-+-+-+ L = Length included M = More fragments S = PEAP start R = Reserved (must be zero) The L bit (length included) is set to indicate the presence of theAndersson et al. Standards Track [Page 20]
INTERNET-DRAFT PEAP September 2002 four octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S bit (PEAP start) is set in a PEAP Start message. This differentiates the PEAP Start message from a fragment acknowledgment.Version 0 1 +-+-+ |R 1| +-+-+ R = Reserved (must be zero)TLS Message Length The TLS Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the TLS message or set of messages that is being fragmented.TLS data The TLS data consists of the encapsulated packet in TLS record format.Andersson et al. Standards Track [Page 21]
INTERNET-DRAFT PEAP September 20023.3. PEAP Response PacketA summary of the PEAP Response packet format is shown below. The fieldsare 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Code | Identifier | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Flags |Ver| TLS Message Length+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TLS Message Length | TLS Data...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code 2Identifier The Identifier field is one octet and MUST match the Identifier field from the corresponding request.Length The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, and TLS data fields.Type 25 - PEAPFlags 0 1 2 3 4 5 +-+-+-+-+-+-+ |L M S R R R| +-+-+-+-+-+-+ L = Length included M = More fragments S = PEAP start R = Reserved (must be zero) The L bit (length included) is set to indicate the presence of the four octet TLS Message Length field, and MUST be set for the firstAndersson et al. Standards Track [Page 22]
INTERNET-DRAFT PEAP September 2002 fragment of a fragmented TLS message or set of messages. The M bit (more fragments) is set on all but the last fragment. The S bit (PEAP start) is set in a PEAP Start message. This differentiates the PEAP Start message from a fragment acknowledgment.Version 0 1 +-+-+ |R 1| +-+-+ R = Reserved (must be zero)TLS Message Length The TLS Message Length field is four octets, and is present only if the L bit is set. This field provides the total length of the TLS message or set of messages that is being fragmented.TLS data The TLS data consists of the encapsulated TLS packet in TLS record format.4. Security Considerations4.1. Method negotiationIf the peer does not support PEAP, or does not wish to utilize PEAPauthentication, it MUST respond to the initial EAP-Request/PEAP-Startwith a NAK, suggesting an alternate authentication method. Since the NAKis sent in cleartext with no integrity protection or authentication, itis subject to spoofing. Unauthentic NAK packets can be used to trickthe peer and Authenticator into "negotiating down" to a weaker form ofauthentication, such as EAP-MD5 (which only provides one wayauthentication and does not derive a key).Since a subsequent protected EAP conversation can take place within theTLS session, selection of PEAP as an authentication method does notlimit the potential secondary authentication methods. As a result, theonly legitimate reason for a peer to NAK PEAP as an authenticationmethod is that it does not support it. Where the additional security ofPEAP is required, server implementations SHOULD respond to a NAK with anEAP-Failure, terminating the authentication conversation.Andersson et al. Standards Track [Page 23]
INTERNET-DRAFT PEAP September 20024.2. TLS session cache handlingIn cases where a TLS session has been successfully resumed, in somecircumstances, it is possible for the EAP server to skip the PEAP Part2 conversation entirely, and immediately send an EAP-Success messagewithin the TLS channel established via session resumption.PEAP "fast reconnect" is desirable in applications such as wirelessroaming, since it minimizes interruptions in connectivity. It is alsodesirable when the "inner" EAP mechanism used is such that it requiresuser interaction. The user should not be required to re-authenticateherself, using biometrics, token cards or similar, every time the radioconnectivity is handed over between access points in wirelessenvironments.However, there are issues that need to be understood in order to avoidintroducing security vulnerabilities.Since PEAP Part 1 may not provide client authentication, establishmentof a TLS session (and an entry in the TLS session cache) does not byitself provide an indication of the peer's authenticity. The peer'sauthenticity is only proven by successful completion of the PEAP Part 2authentication.Some PEAP implementations may not be capable of removing TLS sessioncache entries established in PEAP Part 1 after an unsuccessful PEAP Part2 authentication. In such implementations, the existence of a TLSsession cache entry provides no indication that the peer has previouslybeen authenticated. As a result, implementations that do not remove TLSsession cache entries after a failed PEAP Part 2 authentication MUST useother means than successful TLS resumption as the indicator of whetherthe client is authenticated or not. Failing to do this would enable apeer to gain access by completing PEAP Part 1, tearing down theconnection and re-connect and resume PEAP Part 1 thereby proving herselfauthenticated. Thus, TLS resumption MUST only be used as an indicatorof whether the client is authenticated or not if the implementationsupports TLS session cache removal.If an EAP server implementing PEAP removes TLS session cache entries ofpeers failing PEAP Part 2 authentication, then it SHOULD skip the PEAPPart 2 conversation entirely after a successful session resumption,immediately sending an EAP-Success message within the TLS channel.4.3. Certificate revocationSince the EAP server is on the Internet during the EAP conversation, theserver is capable of following a certificate chain or verifying whetherthe peer's certificate has been revoked. In contrast, the peer may orAndersson et al. Standards Track [Page 24]
INTERNET-DRAFT PEAP September 2002may not have Internet connectivity, and thus while it can validate theEAP server's certificate based on a pre-configured set of CAs, it maynot be able to follow a certificate chain or verify whether the EAPserver's certificate has been revoked.In the case where the peer is initiating a voluntary Layer 2 tunnelusing PPTP or L2TP, the peer will typically already have Internetconnectivity established at the time of tunnel initiation. As a result,during the EAP conversation it is capable of checking for certificaterevocation.As part of the TLS negotiation, the server presents a certificate to thepeer. The peer SHOULD verify the validity of the EAP servercertificate, and SHOULD also examine the EAP server name presented inthe certificate, in order to determine whether the EAP server can betrusted. Please note that in the case where the EAP authentication isremoted, the EAP server will not reside on the same machine as theauthenticator, and therefore the name in the EAP server's certificatecannot be expected to match that of the intended destination. In thiscase, a more appropriate test might be whether the EAP server'scertificate is signed by a CA controlling the intended destination andwhether the EAP server exists within a target sub-domain.In the case where the peer is attempting to obtain network access, itwill not have Internet connectivity. The TLS Extensions [TLSEXT] supportpiggybacking of an Online Certificate Status Protocol (OCSP) responsewithin TLS, therefore can be utilized by the peer in order to verify thevalidity of server certificate. However, since all TLS implementationsdo not implement the TLS extensions, it may be necessary for the peer towait to check for certificate revocation until after Internet access hasbeen obtained. In this case, the peer SHOULD conduct the certificatestatus check immediately upon going online and SHOULD NOT send datauntil it has received a positive response to the status request. If theserver certificate is found to be invalid, then the peer SHOULDdisconnect.4.4. Separation of the EAP server and the authenticatorAs a result of a complete PEAP Part 1 and Part 2 conversation, the EAPendpoints will mutually authenticate, and derive a session key forsubsequent use in link layer security. Since the peer and EAP clientreside on the same machine, it is necessary for the EAP client module topass the session key to the link layer encryption module.The situation may be more complex on the Authenticator, which may or maynot reside on the same machine as the EAP server. In the case where theEAP server and the Authenticator reside on different machines, there areseveral implications for security. Firstly, the mutual authenticationAndersson et al. Standards Track [Page 25]
INTERNET-DRAFT PEAP September 2002defined in PEAP will occur between the peer and the EAP server, notbetween the peer and the authenticator. This means that as a result ofthe PEAP conversation, it is not possible for the peer to validate theidentity of the NAS or tunnel server that it is speaking to.The second issue is that the session key negotiated between the peer andEAP server will need to be transmitted to the authenticator. Thereforea mechanism needs to be provided to transmit the session key from theEAP server to the authenticator or tunnel server that needs to use thekey. The specification of this transit mechanism is outside the scope ofthis document.4.5. Separation of PEAP Part 1 and Part 2 ServersThe EAP server involved in PEAP Part 2 need not necessarily be the sameas the EAP server involved in PEAP Part 1. For example, a localauthentication server or proxy might serve as the endpoint for the Part1 conversation, establishing the TLS channel. Subsequently, once theEAP-Response/Identity has been received within the TLS channel, it canbe decrypted and forwarded in cleartext to the destination realm EAPserver. The rest of the conversation will therefore occur between thedestination realm EAP server and the peer, with the local authenticationserver or proxy acting as an encrypting/decrypting gateway. This permitsa non-TLS capable EAP server to participate in the PEAP conversation.Note however that such an approach introduces security vulnerabilities.Since the EAP Response/Identity is sent in the clear between the proxyand the EAP server, this enables an attacker to snoop the user'sidentity. It also enables a remote environments, which may be publichot spots or Internet coffee shops, to gain knowledge of the identity oftheir users. Since one of the potential benefits of PEAP is identityprotection, this is undesirable.If the EAP method negotiated during PEAP Part 2 does not support mutualauthentication, then if the Part 2 conversation is proxied to anotherdestination, the PEAP peer will not have the opportunity to verify thesecondary EAP server's identity. Only the initial EAP server's identitywill have been verified as Part of TLS session establishment.Similarly, if the EAP method negotiated during PEAP Part 2 is vulnerableto dictionary attack, then an attacker capturing the cleartext exchangewill be able to mount an offline dictionary attack on the password.Finally, when a Part 2 conversation is terminated at a differentlocation than the Part 1 conversation, the Part 2 destination is unawarethat the EAP client has negotiated PEAP. As a result, it is unable toenforce policies requiring PEAP. Since some EAP methods require PEAP inorder to generate keys or lessen security vulnerabilities, where suchAndersson et al. Standards Track [Page 26]
INTERNET-DRAFT PEAP September 2002methods are in use, such a configuration may be unacceptable.In summary, PEAP encrypting/decrypting gateway configurations arevulnerable to attack and SHOULD NOT be used. Instead, the entire PEAPconnection SHOULD be proxied to the final destination, and thesubsequently derived master session keys need to be transmitted back.This provides end to end protection of PEAP. The specification of thistransit mechanism is outside the scope of this document, but mechanismssimilar to [RFC2548] can be used. These steps protects the client fromrevealing her identity to the remote environment.In order to find the proper PEAP destination, the EAP client SHOULDplace a Network Access Identifier (NAI) conforming to [RFC2486] in theIdentity Response.There may be cases where a natural trust relationship exists between the(foreign) authentication server and final EAP server, such as on acampus or between two offices within the same company, where there is nodanger in revealing the identity of the station to the authenticationserver. In these cases, using a proxy solution without end to endprotection of PEAP MAY be used. The PEAP encrypting/decrypting gatewaySHOULD provide support for IPsec protection of RADIUS in order toprovide confidentiality for the portion of the conversation between thegateway and the EAP server, as described in [RFC3162].4.6. Identity verificationSince the TLS session has not yet been negotiated, the initial Identityrequest/response occurs in the clear without integrity protection orauthentication. It is therefore subject to snooping and packetmodification.In configurations where all users are required to authenticate with PEAPand the first portion of the PEAP conversation is terminated at a localbackend authentication server, without routing by proxies, the initialcleartext Identity Request/Response exchange is not needed in order todetermine the required authentication method(s) or route theauthentication conversation to its destination. As a result, the initialIdentity and Request/Response exchange MAY NOT be present, and asubsequent Identity Request/Response exchange MAY occur after the TLSsession is established.If the initial cleartext Identity Request/Response has been tamperedwith, after the TLS session is established, it is conceivable that theEAP Server will discover that it cannot verify the peer's claim ofidentity. For example, the peer's userID may not be valid or may not bewithin a realm handled by the EAP server. Rather than attempting toproxy the authentication to the server within the correct realm, the EAPAndersson et al. Standards Track [Page 27]
INTERNET-DRAFT PEAP September 2002server SHOULD terminate the conversation.The PEAP peer can present the server with multiple identities. Thisincludes the claim of identity within the initial EAP-Response/Identity(MyID) packet, which is typically used to route the EAP conversation tothe appropriate home backend authentication server. There may also besubsequent EAP-Response/Identity packets sent by the peer once the TLStunnel has been established.Note that since the PEAP peer may not present a certificate, it is notalways possible to check the initial EAP-Response/Identity against theidentity presented in the certificate, as is done in [RFC2716].Moreover, it cannot be assumed that the peer identities presented withinmultiple EAP-Response/Identity packets will be the same. For example,the initial EAP-Response/Identity might correspond to a machineidentity, while subsequent identities might be those of the user. Thus,PEAP implementations SHOULD NOT abort the authentication just becausethe identities do not match. However, since the initial EAP-Response/Identity will determine the EAP server handling theauthentication, if this or any other identity is inappropriate for usewith the destination EAP server, there is no alternative but toterminate the PEAP conversation.The protected identity or identities presented by the peer within PEAPPart 2 may not be identical to the cleartext identity presented in PEAPPart 1, for legitimate reasons. In order to shield the userID fromsnooping, the cleartext Identity may only provide enough information toenable routing of the authentication request to the correct realm. Forexample, the peer may initially claim the identity of "nouser@bigco.com"in order to route the authentication request to the bigco.com EAPserver. Subsequently, once the TLS session has been negotiated, in PEAPPart 2, the peer may claim the identity of "fred@bigco.com". Thus, PEAPcan provide protection for the user's identity, though not necessarilythe destination realm, unless the PEAP Part 1 conversation terminates atthe local authentication server.As a result, PEAP implementations SHOULD NOT attempt to compare theIdentities claimed with Parts 1 and 2 of the PEAP conversation.Similarly, if multiple Identities are claimed within PEAP Part 2, theseSHOULD NOT be compared. An EAP conversation may involve more than oneEAP authentication method, and the identities claimed for each of theseauthentications could be different (e.g. a machine authentication,followed by a user authentication).5. Normative references[RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm",RFC1321, April 1992.Andersson et al. Standards Track [Page 28]
INTERNET-DRAFT PEAP September 2002[RFC1570] Simpson, W., Editor, "PPP LCP Extensions",RFC 1570, January 1994.[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,RFC 1661, July 1994.[RFC1962] D. Rand. "The PPP Compression Control Protocol",RFC 1962, Novell, June 1996.[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)",RFC 1968, June 1996.[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)",RFC 1990, August 1996.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119, March 1997.[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",RFC2246, November 1998.[RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)",RFC 2284, March 1998.[RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier",RFC2486, January 1999.[TLSEXT] Blake-Wilson, S., et al. "TLS Extensions", Internet draft (work in progress),draft-ietf-tls-extensions-02.txt, December 2001.[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.6. Informative references[RFC2419] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 (DESE-bis)",RFC 2419, September 1998.[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",RFC 2420, September 1998.[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",RFC2548, March 1999.Andersson et al. Standards Track [Page 29]
INTERNET-DRAFT PEAP September 2002[RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol",RFC 2716, October 1999.[RFC3078] Pall, G., Zorn, G., "Microsoft Point-to-Point Encryption (MPPE) Protocol",RFC 3078, March 2001.[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)",RFC 3079, March 2001.[FIPSDES] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977).[IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999.[MODES] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980).Andersson et al. Standards Track [Page 30]
INTERNET-DRAFT PEAP September 2002Appendix A - ExamplesIn the case where the identity exchange occurs within PEAP Part 1, theconversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP (PEAP Start, S bit set)EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)EAP-Response/EAP-Type=PEAP([TLS certificate,] TLS client_key_exchange,[TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP (TLS change_cipher_spec, TLS finished)TLS channel established(messages sent within the TLS channel)EAP-Response/EAP-Type=PEAP -> <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/Andersson et al. Standards Track [Page 31]
INTERNET-DRAFT PEAP September 2002 EAP-Type=XEAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X -> <- EAP-SuccessTLS channel torn down(messages sent in cleartext)Where all peers are known to support PEAP, and the PEAP Part 1conversation is carried out between the peer and a local EAP server, thecleartext identity exchange may be omitted and the conversation appearsas follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ EAP-Type=PEAP (PEAP Start, S bit set)EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)EAP-Response/EAP-Type=PEAP([TLS certificate,] TLS client_key_exchange,[TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP (TLS change_cipher_spec, TLS finished)TLS channel establishedAndersson et al. Standards Track [Page 32]
INTERNET-DRAFT PEAP September 2002(messages sent within the TLS channel)EAP-Response/EAP-Type=PEAP -> <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X -> <- EAP-SuccessTLS channel torn down(messages sent in cleartext)In the case where the PEAP fragmentation is required, the conversationwill appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP (PEAP Start, S bit set)EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) (Fragment 1: L, M bits set)Andersson et al. Standards Track [Page 33]
INTERNET-DRAFT PEAP September 2002EAP-Response/EAP-Type=PEAP -> <- EAP-Request/ EAP-Type=PEAP (Fragment 2: M bit set)EAP-Response/EAP-Type=PEAP -> <- EAP-Request/ EAP-Type=PEAP (Fragment 3)EAP-Response/EAP-Type=PEAP([TLS certificate,] TLS client_key_exchange,[TLS certificate_verify,] TLS change_cipher_spec, TLS finished) (Fragment 1: L, M bits set)-> <- EAP-Request/ EAP-Type=PEAPEAP-Response/EAP-Type=PEAP(Fragment 2)-> <- EAP-Request/ EAP-Type=PEAP (TLS change_cipher_spec, TLS finished)TLS channel established(messages sent within the TLS channel)EAP-Response/EAP-Type=PEAP -> <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X ->Andersson et al. Standards Track [Page 34]
INTERNET-DRAFT PEAP September 2002 <- EAP-SuccessTLS channel torn down(messages sent in cleartext)In the case where the server authenticates to the client successfully inPEAP Part 1, but the client fails to authenticate to the server in PEAPPart 2, the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP (PEAP Start, S bit set)EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)EAP-Response/EAP-Type=PEAP([TLS certificate,] TLS client_key_exchange,[TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP (TLS change_cipher_spec, TLS finished)TLS channel established(messages sent within the TLS channel)EAP-Response/EAP-Type=PEAP -> <- EAP-Request/ IdentityAndersson et al. Standards Track [Page 35]
INTERNET-DRAFT PEAP September 2002EAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X or NAK -> <- EAP-Request/ EAP-Type=XEAP-Response/EAP-Type=X -> <- EAP-Failure (TLS session cache entry flushed)TLS channel torn down(messages sent in cleartext)In the case where server authentication is unsuccessful in PEAP Part 1,the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Type=PEAP (PEAP Start)EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS server_hello_done)EAP-Response/EAP-Type=PEAP(TLS client_key_exchange,[TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=PEAP (TLS change_cipher_spec,Andersson et al. Standards Track [Page 36]
INTERNET-DRAFT PEAP September 2002 TLS finished)EAP-Response/EAP-Type=PEAP(TLS change_cipher_spec,TLS finished) <- EAP-Request/ EAP-Type=PEAPPPP EAP-Response/EAP-Type=PEAP(TLS Alert message) -> <- EAP-Failure (TLS session cache entry flushed)In the case where a previously established session is being resumed, theEAP server supports TLS session cache flushing for unsuccessful PEAPPart 2 authentications and both sides authenticate successfully, theconversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- PPP EAP-Request/ EAP-Request/ EAP-Type=PEAP (PEAP Start)EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS change_cipher_spec TLS finished)EAP-Response/EAP-Type=PEAP(TLS change_cipher_spec, TLS finished) -> <- EAP-SuccessAndersson et al. Standards Track [Page 37]
INTERNET-DRAFT PEAP September 2002In the case where a previously established session is being resumed, andthe server authenticates to the client successfully but the client failsto authenticate to the server, the conversation will appear as follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Request/ EAP-Type=PEAP (TLS Start)EAP-Response/EAP-Type=PEAP(TLS client_hello) -> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS change_cipher_spec, TLS finished)EAP-Response/EAP-Type=PEAP(TLS change_cipher_spec, TLS finished) -> <- EAP-Request EAP-Type=PEAP (TLS Alert message)EAP-ResponseEAP-Type=PEAP -> <- EAP-Failure (TLS session cache entry flushed)In the case where a previously established session is being resumed, andthe server authentication is unsuccessful, the conversation will appearas follows:Authenticating Peer Authenticator------------------- ------------- <- EAP-Request/ IdentityEAP-Response/Identity (MyID) -> <- EAP-Request/ EAP-Request/ EAP-Type=PEAP (TLS Start)Andersson et al. Standards Track [Page 38]
INTERNET-DRAFT PEAP September 2002EAP-Response/EAP-Type=PEAP(TLS client_hello)-> <- EAP-Request/ EAP-Type=PEAP (TLS server_hello, TLS change_cipher_spec, TLS finished)EAP-Response/EAP-Type=PEAP(TLS change_cipher_spec,TLS finished) <- EAP-Request/ EAP-Type=PEAPEAP-Response/EAP-Type=PEAP(TLS Alert message) -> <- EAP-Failure (TLS session cache entry flushed)Andersson et al. Standards Track [Page 39]
INTERNET-DRAFT PEAP September 2002AcknowledgmentsThanks to Jan-Ove Larsson and Magnus Nystrom of RSA Security, andNarendra Gidwani and Bernard Aboba of Microsoft for useful discussionsof this problem space.Author AddressesHakan AnderssonRSA SecurityBox 107 04SE-121 29 StockholmSwedenPhone: +46 8 725 9758Fax: +46 8 649 4970EMail: handersson@rsasecurity.comSimon JosefssonRSA SecurityBox 107 04SE-121 29 StockholmSwedenPhone: +46 8 725 0914Fax: +46 8 649 4970EMail: sjosefsson@rsasecurity.comGlen ZornCisco Systems500 108th Avenue N.E.Suite 500Bellevue, Washington 98004USAPhone: + 1 425 438 8210Fax: + 1 425 438 1848EMail: gwz@cisco.comDan SimonMicrosoft CorporationOne Microsoft WayRedmond, WA 98052Phone: +1 425 706 6711EMail: dansimon@microsoft.comAshwin PalekarAndersson et al. Standards Track [Page 40]
INTERNET-DRAFT PEAP September 2002Microsoft CorporationOne Microsoft WayRedmond, WA 98052Phone: +1 425 882 8080EMail: ashwinp@microsoft.comIntellectual Property StatementThe IETF takes no position regarding the validity or scope of anyintellectual property or other rights that might be claimed to pertainto the implementation or use of the technology described in thisdocument or the extent to which any license under such rights might ormight not be available; neither does it represent that it has made anyeffort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-related documentation can be found inBCP-11. Copies of claims ofrights made available for publication and any assurances of licenses tobe made available, or the result of an attempt made to obtain a generallicense or permission for the use of such proprietary rights byimplementors or users of this specification can be obtained from theIETF Secretariat.The IETF invites any interested party to bring to its attention anycopyrights, patents or patent applications, or other proprietary rightswhich may cover technology that may be required to practice thisstandard. Please address the information to the IETF ExecutiveDirector.Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it orassist in its implementation may be prepared, copied, published anddistributed, in whole or in part, without restriction of any kind,provided that the above copyright notice and this paragraph are includedon all such copies and derivative works. However, this document itselfmay not be modified in any way, such as by removing the copyright noticeor references to the Internet Society or other Internet organizations,except as needed for the purpose of developing Internet standards inwhich case the procedures for copyrights defined in the InternetStandards process must be followed, or as required to translate it intolanguages other than English. The limited permissions granted above areperpetual and will not be revoked by the Internet Society or itssuccessors or assigns. This document and the information containedherein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS ORAndersson et al. Standards Track [Page 41]
INTERNET-DRAFT PEAP September 2002IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THEINFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."Expiration DateThis memo is filed as <draft-josefsson-pppext-eap-tls-eap-05.txt>, andexpires March 19, 2003.Andersson et al. Standards Track [Page 42]
draft-josefsson-pppext-eap-tls-eap-05
| Document | Document type | This is an older version of an Internet-Draft whose latest revision state is "Expired". Expired & archived This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream | (None) | ||
| Other formats |