-----Original Message----- From: ietf-enroll-bounces@mit.edu [mailto:ietf-enroll-bounces@mit.edu] On Behalf Of Lord, Chris Sent: Wednesday, December 17, 2003 3:47 PM To: ietf-enroll@mit.edu Subject: [ietf-enroll] PEAPOD I-D on imprinting/enrollment Dear enroll mailing list members: While researching protocols to enroll a device into secure network we have come to believe that an enrollment protocol must balance mutual authentication, implementation issues, and the user's experience. There are real-world common usage models where mutual authentication is required for enrollment. (This is especially true in environments with overlapping wireless networks.) This mutual authentication must be simple enough to be usable by the average person, must not be too complex to implement or too slow to execute, and must maintain adequate security. Secure network credentials are based on cryptographic material which is complex for an end user to evaluate - we want to make such evaluations as easy as possible. Due to security reasons, the user must make decisions based on the cryptographic information in the credentials as opposed to non-cryptographic information in the credentials (i.e., present a hash of a key as opposed to a user name). The goal, then, is to provide a flexible solution that enables users to deal with complex information and come to the access control decisions they actually desire. The attached protocol (called PEAPOD) is an attempt to devise a protocol that enables user-friendly representations of information to be used for enrollment decisions. A suitable user interface is necessary to complete the user experience, but the protocol establishes the elements that need to be shown to the user. The PEAPOD model assumes that each enrollment entity has a public/private key pair. When a network authenticator receives a connection request from an unknown device (public key not recognized), it communicates with a user to determine whether the device should be allowed access. Similarly, when a device finds a network authenticator it doesn't recognize, the device takes steps (either through the PEAPOD protocol or through a device-side user) to confirm that the network authenticator is a trusted entity. PEAPOD assumes the existence an out-of-band channel between the user controlling the network authenticator and the device/device user. PEAPOD does not force these authentication decisions, but it enables them to be made. We are interested in sharing PEAPOD as input and in any feedback from list members. Note that this draft has NOT been presented to the PPPEXT working group. Thanks in advance. Dave Bowler Chris Lord PPPEXT Working Group Christopher Lord Internet Draft David Bowler Document: draft-peapod-00-06.txt Intel Expires: April 2004 October 2003 Protected EAP for Ordinary Devices (PEAPOD) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft specifies a mutual authentication protocol based in the Extensible Authentication Protocol (EAP) framework. This protocol makes use of ancillary protocols and standards for the validation of client device and authentication server credentials. The protocol is based on public/private key pairs but does not require use of a traditional certificate authority. PEAPOD is largely based on the Internet-Draft Protected EAP, see [PEAP] for details. This specification will highlight where PEAPOD deviates from PEAP. This protocol was designed based on the requirements for securely introducing client devices into an unmanaged 802.1x [IEEE8021X] based network. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Lord, Bowler Standards Track [Page 1] INTERNET DRAFT PEAPOD October 2003 Table of Contents 1. Introduction...................................................2 EAP/PEAP Issues................................................3 Terminology....................................................4 2. Protocol overview..............................................5 PEAPOD Part 1..................................................5 PEAPOD Part 2..................................................8 Version negotiation...........................................10 Error handling................................................10 Retry behavior................................................10 Session resumption............................................10 Fragmentation.................................................11 Key derivation................................................11 3. Detailed description of the PEAPOD protocol...................12 PEAPOD Outer Packet Format....................................12 PEAPOD Outer Request Packet...................................14 PEAPOD Outer Response Packet..................................16 PEAPOD Query Request Packet...................................18 PEAPOD Query Response Packet..................................19 PEAPOD Peer Secret Request Packet.............................20 PEAPOD Peer Secret Response Packet............................21 PEAPOD Display Request Packet.................................22 PEAPOD Display Response Packet................................23 4. Security considerations.......................................24 Method negotiation............................................24 TLS session cache handling....................................24 Self-signed certificates vs. certificate chains...............24 Certificate revocation........................................25 5. References....................................................26 Appendix A - Examples............................................27 Acknowledgments..................................................31 Author Addresses.................................................31 Intellectual Property Statement..................................31 Full Copyright Statement.........................................32 1. Introduction The Extensible Authentication Protocol (EAP) provides a standard protocol that extensibly supports multiple authentication schemes. The Protected EAP (PEAP) protocol was developed to extend EAP in a way that allows for encrypted and integrity-protected mutual authentication. For this to work, it has generally been envisioned that the Network Access Server (NAS) or an associated backend authentication server will have knowledge of at least one traditional certificate authority (CA) and will have access to applicable certificate revocations lists. Lord, Bowler Standards Track [Page 2] INTERNET DRAFT PEAPOD October 2003 The PEAPOD protocol also extends EAP with the goal of establishing secure mutual authentication. However, PEAPOD is designed to avoid the use of traditional CAs, certificate revocation lists, etc. This is of greater help when dealing with simple wireless devices and environments in which use of commercial CAs are problematic. The PEAPOD protocol, similar to the PEAP protocol, makes use of Transport Layer Security (TLS) [RFC2246] to establish an encrypted tunnel and exchange certificates between entities. EAP/PEAP Issues As EAP becomes increasingly popular, a number of weaknesses have become apparent. Since EAP method negotiation is unprotected over a medium to which an attacker has easy access, it is possible for an attacker to inject and/or modify packets in order to cause "less secure" methods of authentication to be negotiated. An attacker can also collect information snooped during the authentication for possible future attacks. PEAP addresses these issues by using TLS to establish an encrypted channel between the peer and the authentication server. PEAP assumes that the peer in this connection has, or will have soon after a connection is established, access to a CA with which to validate the identity of the authentication server. No method other than walking a certificate chain back to a trusted root is given for a peer to make a decision to trust the authentication. This is problematic for three reasons. First, in the past, certificates have been issued by CAs to entities other than the logical entity with which a peer believes it is communicating. In some cases this has been accomplished by attackers supplying the CA with incorrect information, while other times the information is correct but confusing to a human who may be making a trust decision based on it. (Example: A group administrator is assigning rights based on a certificate from John Smith, but incorrectly assumes that this is from the senior VP John Smith when it is actually from the new contractor John Smith.) Second, there have been cases where an attacker generates a root certificate which looks very similar to the root certificate of a trusted CA. While common certificate chain code will determine that the root certificate is not trusted, it is a fairly common practice to let an end-user make a decision about whether this new certificate should be added to the list of trusted CAs. Third, there are the issues of complexity and cost in accurately deploying a public key infrastructure based on a CA. A large Lord, Bowler Standards Track [Page 3] INTERNET DRAFT PEAPOD October 2003 corporate entity may have sufficient IT support to run an internal CA and do so effectively, but this is not likely to be the case for the home user or smaller business. Also, some devices may lack sufficient computing resources to be storing large sets of authentication information. The decision may be made to install one root certificate and trust all certificates off that root, but this is likely to result in trusting a larger group than actually desired. PEAPOD addresses these issues by eliminating the required use of CA information. Instead, certificates communicated over TLS are potentially self-signed, letting authentication entities know that the peer is the one represented by the key in the certificate but nothing else. In all cases, it is recommended that the trust decision be based on the certificate in the certificate chain that is at the lowest reasonable level (a root certificate being highest, a leaf certificate being lowest). This solution can be problematic for some peers with no way to receive trusted user interaction, so PEAPOD has a method for communicating a shared secret from the authentication server as a secondary means for authentication of the server. Terminology 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 the credentials provided by the peer, and provides server authentication credentials for the peer to validate. 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 PEAPOD Part 2 conversation. Lord, Bowler Standards Track [Page 4] INTERNET DRAFT PEAPOD October 2003 2. Protocol overview PEAPOD is comprised of a two-part conversation, with most of the second part being optional at the discretion of the peer. [1] In Part 1, a TLS session is established with the server and client mutually authenticating by certificate exchange. The negotiated TLS key is then used to encrypt the conversation in Part 2. [2] In Part 2, the authentication server asks the peer if it requires a shared secret be sent to provide additional authentication. If the peer does require this, the server computes the shared secret and communicates it over the TLS session. The next two sections provide a more detailed overview of the two parts of the PEAPOD conversation. PEAPOD Part 1 The PEAPOD conversation MAY begin with the authenticator and the peer negotiating EAP. The authenticator will typically send an EAP- Request/Identity packet to the peer, and the peer will respond with an EAP-Response/Identity packet to the authenticator, containing an identifier (possibly a userId) for the peer. Once the optional initial Identity Request/Response exchange is completed, while nominally the EAP conversation occurs between the authenticator and the peer, the authenticator MAY act as a pass- through device, with the EAP packets received from the peer being encapsulated for transmission to a backend authentication server. If a backend authentication server is involved, the channel between the authentication server and the authenticator SHOULD be secured. In the discussion that follows, the term "EAP server" will be used to denote the ultimate endpoint conversing with the peer. Once it has determined that PEAPOD authentication is to occur, the EAP server MUST respond with a PEAPOD/Start packet, which is an EAP- Request packet with EAP-Type=PEAPOD, the Start (S) bit set, and no data. Assuming that the peer supports PEAPOD, the PEAPOD conversation will then begin, with the peer sending an EAP-Response packet with EAP-Type=PEAPOD. The data field of this EAP-Response packet will encapsulate a TLS record in TLS record layer format, containing a TLS client_hello handshake message. The current cipher spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null compression. This current cipher Lord, Bowler Standards Track [Page 5] INTERNET DRAFT PEAPOD October 2003 spec remains in use until the change_cipher_spec message signals that subsequent records will have the negotiated attributes for the remainder of the handshake. The client_hello message contains the client's TLS version number, a sessionId, a random number, and a set of TLS ciphersuites supported by the client. The version offered by the client MUST correspond to TLS v1.0 or later. The EAP server will then respond with an EAP-Request packet with EAP- Type=PEAPOD. The data field of this packet will encapsulate one or more TLS records. If a previous session is not being resumed, and no errors have occurred, this packet MUST encapsulate the server_hello, certificate, certificate_request, and server_hello_done messages; it MAY include a server_key_exchange message. If a previous session is being resumed, this packet MUST encapsulate the server_hello, change_cipher_spec, and finished handshake messages. The server_hello handshake message contains a TLS version number, another random number, a sessionId, and a TLS ciphersuite. The version offered by the server MUST correspond to TLS v1.0 or later. In order to provide confidentiality, integrity and replay protection, and authentication, the negotiated TLS ciphersuite MUST provide all of these security services. If the client's sessionId is null, unrecognized by the server, or is relating to a session the server does not desire to resume, the server MUST either choose a new sessionId to establish a new session or choose to send an empty sessionId to indicate that the new session will not be resumable. If the server recognizes the client's sessionId and desires to resume the previous session, the server's sessionId will match the one sent by the client. The server will also choose a TLS ciphersuite from those offered by the client; if the session matches the client's, then the TLS ciphersuite MUST match the one negotiated during the handshake protocol execution that established the session. If a session is being resumed, the peer MUST NOT require that PEAPOD Part 2 be executed, though an authentication server MAY elect to perform the PEAPOD Part 2 conversation. PEAPOD implementations do not need to support all TLS ciphersuites listed in [RFC2246]. Not all TLS ciphersuites are supported by available TLS tool kits, and licenses may be required to support some TLS ciphersuites (e.g. TLS ciphersuites utilizing the IDEA encryption algorithm). To ensure interoperability, PEAPOD peers and Authenticators MUST be able to negotiate the following TLS ciphersuite: TLS_RSA_WITH_3DES_EDE_CBC_SHA Lord, Bowler Standards Track [Page 6] INTERNET DRAFT PEAPOD October 2003 Additionally, it is RECOMMENDED that PEAPOD peers and Authenticators be able to negotiate the following TLS ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS supports compression as well as ciphersuite negotiation. Therefore, during the PEAPOD Part 1 conversation the EAP endpoints MAY request or negotiate TLS compression. The certificate message contains a certificate chain ending in a public key certificate for either a key exchange public key (such as an RSA or Diffie-Hellman key exchange public key) or a signature public key (such as an RSA or DSS signature public key). In the latter case, a TLS server_key_exchange handshake message MUST also be included to allow the key exchange to take place. The certificate chain MAY consist of only a self-signed certificate. See the section ?Self-signed certificates vs. certificate chains? for a discussion on the security ramifications. Note that server authentication may actually be performed in PEAPOD Part 2 based on the client?s response to a PEAPOD Query Request. The peer MUST respond to the EAP-Request with an EAP-Response packet of EAP-Type=PEAPOD. The data field of this packet will encapsulate one or more TLS records containing a TLS change_cipher_spec message and finished handshake message. If a previous session is not being resumed, this packet MUST also include certificate and client_key_exchange messages and MAY include a certificate_verify message. The certificate message will be used to authenticate the peer to the server. The client_key_exchange completes the exchange of a shared master secret between the peer and the EAP server. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server. After the TLS session is established, there is no further PEAPOD authentication of the peer. This lack of secondary authentication is why the peer is required to send a certificate if one is requested by the server. (Note: This is unlike PEAP where in PEAP Part 2 the client sends its certificate to the server inside of the TLS tunnel setup based on the server's certificate.) In PEAPOD the TLS client certificates are sent in the clear; if identity protection is required, the certificate SHOULD NOT contain any identifying information other than the public key. The EAP server MUST then respond with an EAP-Request packet with EAP- Type=PEAPOD, which includes, in the case of a new TLS session, one or more TLS records containing TLS change_cipher_spec and finished Lord, Bowler Standards Track [Page 7] INTERNET DRAFT PEAPOD October 2003 handshake messages. The latter contains the EAP server's authentication response to the peer. The peer will then verify the finished handshake hash in order to authenticate the EAP server. If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=PEAPOD containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator. To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP Server to reply before terminating the conversation. The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition. If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=PEAPOD, with no data. If a previous TLS session was not resumed, the EAP-Server then continues with Part 2 of the PEAPOD conversation. If a previous TLS session was resumed, it is RECOMMENDED that the EAP-Server not continue with Part 2 of the PEAPOD conversation, since Part 2 SHOULD be considered redundant with the session resumption. 2.1.1.Forging of Success and Failure packets Within EAP, Success and Failure packets may be trivially forged since they are not authenticated in any way. Forging packets can results in either failing a connection that should not have been failed or accepting a connection that should not have been accepted. By requiring mutual authentication, and securing EAP communication inside a TLS tunnel, PEAPOD provides protection against forging attacks. Since the PEAPOD Authenticator and peer MUST both authenticate themselves during PEAPOD Part 1, once the TLS tunnel is established all Success/Failure packets SHOULD be sent within the TLS tunnel. Once PEAPOD has been selected as the authentication method and the PEAPOD conversation has begun, a peer receiving Success/Failure packets in the clear (outside the TLS tunnel) MUST silently discard the packets. PEAPOD Part 2 The second portion of the PEAPOD conversation consists of an optional secondary authentication of the server to the peer. This part is included to allow the peer a method of authenticating the server in the case that the peer does not have the ability to validate the Lord, Bowler Standards Track [Page 8] INTERNET DRAFT PEAPOD October 2003 server based on the server's certificate. The PEAPOD Part 2 conversation will occur only if establishment of the TLS session in Part 1 is successful. It MUST NOT occur if the EAP Server or the peer authenticates unsuccessfully or if an EAP-Failure has been sent by the EAP Server to the peer, terminating the conversation. Since all packets sent within the PEAPOD Part 2 conversation occur after TLS session establishment, they are protected using the negotiated TLS ciphersuite. Part 2 of the PEAPOD conversation begins with the Authenticator sending an EAP-Request/Query Request packet to the peer, protected by the TLS ciphersuite negotiated in PEAPOD Part 1. The peer responds with an EAP-Response/Query Response packet to the authenticator, containing information as to whether the peer requires a Peer Secret be sent and whether the peer has user display capabilities. At this point the authenticator MAY send an EAP-Request/Display Request packet to the peer. This message SHOULD NOT be sent if the EAP-Response/Query Response packet sent by the peer does not indicate that the peer has the ability to display authentication credentials to a user. The peer responds with an EAP-Response/Display Response packet indicating whether or not it displayed credentials to the user. The conversation MAY proceed whether or not the peer displayed credentials. There is no PEAPOD message by which the authenticator can instruct the peer to turn off its display. When to turn off the display is an implementation choice of the peer. If the peer does not require that a Peer Secret be communicated (the Part 1 conversation was sufficient for authentication), the PEAPOD Part 2 conversation ends. If the peer does require that a Peer Secret be communicated, the server computes and transmits a Peer Secret. The Peer Secret is of the form: H = HMAC-SHA1 (Secret, (Pd | Pa | TLS created random #)) HMAC-SHA1 is the keyed hash function described in RFC2104. Secret is a value communicated to the authentication server via an ancillary protocol (and known by the peer). Pd and Pa are string representations of the peer's and authenticator's public keys respectively. TLS created random # is a SHA1 hash of the pre-master secret used in establishing the TLS session. Therefore, H is a HMAC-SHA1 of the public keys and a nonce value using the secret string as an input key value to HMAC-SHA1. H is then communicated over the TLS session. Upon receiving the authenticator's H value, the peer computes its own H value using the same algorithm. The peer compares it to H from the authenticator. Lord, Bowler Standards Track [Page 9] INTERNET DRAFT PEAPOD October 2003 Upon successful match, the peer returns a success code over the EAP protocol to the authenticator. Upon an unsuccessful match, the peer returns an error code over the EAP protocol to the authenticator. At the peer?s discretion, this may be considered a terminal error, in which case the peer also includes a TLS alert in the EAP Response packet. If the peer does not consider this to be a terminal error, the server may resend the Peer Secret packet until either the H value matches or the peer considers the number of failures to constitute a terminal error. Version negotiation PEAPOD packets contain a three-bit version field, which allows for the possibility of PEAPOD implementations being backward compatible with previous versions of the protocol. The version negotiation protocol for PEAPOD is the same as is found in [PEAP] section 2.3. For the version of PEAPOD described in this document, the version number is 1. Error handling Error handling for PEAPOD is largely the same as is found in [PEAP] section 2.5. The exceptions to this are when errors for Part 2 Requests for Display and Peer Secret are communicated. The Response packets for these messages have success flags. In the event of an error, these flags will be set to 0. After the response with the 0 flags, a TLS alert MAY be sent if the peer implementation considers this to be a terminal error. Retry behavior The retry behavior for PEAPOD is the same as is found in [PEAP] section 2.6. Session resumption Session resumption is based on the same as is found in [PEAP]; however, due to the differences in PEAPOD this section is self- contained. The purpose of the sessionId within the TLS protocol is to allow for improved efficiency in the case where a client repeatedly attempts to authenticate to an EAP server within a short period of time. This Lord, Bowler Standards Track [Page 10] INTERNET DRAFT PEAPOD October 2003 capability is particularly useful in environments in which multiple reconnects are likely (wireless roaming, etc.). It is left up to the peer whether to attempt to continue a previous session. If a peer chooses to attempt to continue a previous session, it is implicitly agreeing that the server sufficiently authenticated during the previous session, and the peer does not require that the server further authenticate itself. Resuming a session shortens the PEAPOD Part 1 conversation and, at the discretion of the server, eliminates the Part 2 conversation (including the PEAPOD Query Peer Authentication Request packet). Based on the sessionId chosen by the peer, the time elapsed since the previous authentication, and whether the peer sufficiently authenticated itself in the previous session, the EAP server will decide whether to allow the continuation, or whether to choose a new session. The EAP server MUST NOT allow the continuation of the previous session if the peer did not sufficiently authenticate itself during the previous session. A client will only be able to resume a session when communicating with the same authentication server it communicated with in the previous session. As a result, the likelihood of successful resumption increases when the authentication is handled by a backend authentication server, since multiple NAS devices and servers will remote their EAP authentications to the same backend authentication server. Fragmentation The fragmentation for PEAPOD is the same as is found in [PEAP] section 2.8. Key derivation The key derivation for PEAPOD is the same as is found in [PEAP] section 2.9. Lord, Bowler Standards Track [Page 11] INTERNET DRAFT PEAPOD October 2003 3. Detailed description of the PEAPOD protocol PEAPOD Outer Packet Format A summary of the PEAPOD Outer 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 - Response Identifier 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 TBD - PEAPOD Flags 0 1 2 3 4 +-+-+-+-+-+ |L M S R R| +-+-+-+-+-+ L = Length included M = More fragments S = PEAPOD start Lord, Bowler Standards Track [Page 12] INTERNET DRAFT PEAPOD October 2003 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 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 (PEAPOD start) is set in a PEAPOD Start message. This differentiates the PEAPOD Start message from a fragment acknowledgment. Version 0 1 2 +-+-+-+ |R R 1| +-+-+-+ R = Reserved (must be zero) Data The format of the Data field is determined by the Code field. Lord, Bowler Standards Track [Page 13] INTERNET DRAFT PEAPOD October 2003 PEAPOD Outer Request Packet A summary of the PEAPOD Outer Request 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 | TLS Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS Message Length | TLS Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 - Request Identifier 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 TBD - PEAPOD Flags 0 1 2 3 4 +-+-+-+-+-+ |L M S R R| +-+-+-+-+-+ L = Length included M = More fragments S = PEAPOD start R = Reserved (must be zero) The L bit (length included) is set to indicate the presence of Lord, Bowler Standards Track [Page 14] INTERNET DRAFT PEAPOD October 2003 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 (PEAPOD start) is set in a PEAPOD Start message. This differentiates the PEAPOD Start message from a fragment acknowledgment. Version 0 1 2 +-+-+-+ |R 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. If the record layer indicates that the record carries application data, that data will consist of packets for either the PEAPOD Query Request or the PEAPOD Peer Secret Request. The formats of these packets are described below. If the record layer does not indicate that the record carries application data, the record carries standard TLS data, and will be treated as such. Lord, Bowler Standards Track [Page 15] INTERNET DRAFT PEAPOD October 2003 PEAPOD Outer Response Packet A summary of the PEAPOD Outer 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 | TLS Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLS Message Length | TLS Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 - Response Identifier 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 TBD - PEAPOD Flags 0 1 2 3 4 +-+-+-+-+-+ |L M S R R| +-+-+-+-+-+ L = Length included M = More fragments S = PEAPOD 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 Lord, Bowler Standards Track [Page 16] INTERNET DRAFT PEAPOD October 2003 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 (PEAPOD start) is set in a PEAPOD Start message. This differentiates the PEAPOD Start message from a fragment acknowledgment. Version 0 1 2 +-+-+-+ |R 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. If the record layer indicates that the record carries application data, that data will consist of packets for either the PEAPOD Query Response or the PEAPOD Peer Secret Response. The formats of these packets are described below. If the record layer does not indicate that the record carries application data, the record carries standard TLS data, and will be treated as such. Lord, Bowler Standards Track [Page 17] INTERNET DRAFT PEAPOD October 2003 PEAPOD Query Request Packet A summary of the PEAPOD Query Request 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 | Opcode | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 - Request Identifier 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 packet including the Code, Identifier, Length, Type, Opcode, and Flags. Type TBD - PEAPOD Opcode 1 - Query peer Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A D R R R R R R| +-+-+-+-+-+-+-+-+ A - The peer should indicate if it requires a peer secret D - The peer should indicate if it can display authentication information to the peer's user R - Reserved (must be zero) Lord, Bowler Standards Track [Page 18] INTERNET DRAFT PEAPOD October 2003 PEAPOD Query Response Packet A summary of the PEAPOD Query Request 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 | Opcode | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 - Response Identifier 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 packet including the Code, Identifier, Length, Type, Opcode, and Flags. Type TBD - PEAPOD Opcode 1 - Query peer Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |A D R R R R R R| +-+-+-+-+-+-+-+-+ A - The peer requires a peer secret to be sent D - The peer can show authentication information to its user R - Reserved (must be zero) Lord, Bowler Standards Track [Page 19] INTERNET DRAFT PEAPOD October 2003 PEAPOD Peer Secret Request Packet A summary of the PEAPOD Peer Secret Request 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 | Opcode | Flags | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 - Request Identifier 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 packet including the Code, Identifier, Length, Type, Opcode, Flags, and Data. Type TBD - PEAPOD Opcode 2 - Peer secret Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R R R R R R R R| +-+-+-+-+-+-+-+-+ R - Reserved (must be zero) All flag bits will be set to 0 on this request. Data The binary representation of H as calculated above. The value is 160 bits in length. Lord, Bowler Standards Track [Page 20] INTERNET DRAFT PEAPOD October 2003 PEAPOD Peer Secret Response Packet A summary of the PEAPOD Peer Secret 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 | Opcode | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 - Response Identifier 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 packet including the Code, Identifier, Length, Type, Opcode, and Flags. Type TBD - PEAPOD Opcode 2 - Peer secret Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S R R R R R R R| +-+-+-+-+-+-+-+-+ S - Success in matching secret R - Reserved (must be zero) Lord, Bowler Standards Track [Page 21] INTERNET DRAFT PEAPOD October 2003 PEAPOD Display Request Packet A summary of the PEAPOD Display Request 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 | Opcode | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 - Request Identifier 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 packet including the Code, Identifier, Length, Type, Opcode, and Flags. Type TBD - PEAPOD Opcode 3 - Display Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R R R R R R R R| +-+-+-+-+-+-+-+-+ R - Reserved (must be zero) All flag bits will be set to 0 on this request. Lord, Bowler Standards Track [Page 22] INTERNET DRAFT PEAPOD October 2003 PEAPOD Display Response Packet A summary of the PEAPOD Display 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 | Opcode | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 - Response Identifier 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 packet including the Code, Identifier, Length, Type, Opcode, and Flags. Type TBD - PEAPOD Opcode 3 - Display Flags 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S R R R R R R R| +-+-+-+-+-+-+-+-+ S - Success in displaying information R - Reserved (must be zero) Lord, Bowler Standards Track [Page 23] INTERNET DRAFT PEAPOD October 2003 4. Security considerations Method negotiation If the peer does not support PEAPOD, or does not wish to use PEAPOD for this authentication, it MUST respond to the initial request to start PEAPOD with a NAK and suggest an alternate authentication method. The server SHALL determine if the suggested method is acceptable. If not, the server MUST respond to a NAK with an EAP- Failure, terminating the conversation. TLS session cache handling A client is allowed to attempt reconnection of a TLS session. If a client attempts to resume a TLS session, and the server accepts the request to resume the session, the client MUST NOT require the server to do PEAPOD Part 2. A successfully resumed TLS session SHALL be sufficient to complete the PEAPOD protocol. If, after having established an initial TLS session with a client, the authentication server determines that it should not communicate with the client in the future, the authentication server SHOULD clear the session cache of all related sessions, and MUST NOT resume a session with the client. In effect, resuming a TLS session is an implicit statement by both authenticating entities that they are sufficiently satisfied by the credentials of the prior session that they are willing to skip another round of authentication. Self-signed certificates vs. certificate chains PEAPOD is designed around the idea that certificates are simply objects that transport public keys. As such, ?identifying? information is irrelevant and should not be relied upon for trust decisions. The idea is that public key information is communicated over an ancillary channel and then, when proof that an end entity is the one represented by a given public key, trust decisions are made on that public key. In this model, self-signed certificates are preferred since they present only the information being used in a given trust decision. However, it does make sense to use certificate chains in environments in which an issuer is perceived as granting rights (as opposed to certifying identity). For instance, a corporate IT department may have a root certificate and configure authentication servers to trust Lord, Bowler Standards Track [Page 24] INTERNET DRAFT PEAPOD October 2003 that any entity with an IT-issued certificate is trustworthy of access to the corporate intranet. For simpler networks and/or simpler devices, self-signed certificates should be used as a means of preventing unintended trust decisions. For networks in which a certificate chain makes sense, the root certificate should be owned by the network owner and what trust decisions are made based on that certificate should be fully understood. Certificate revocation For TLS certificates that are self-signed, there is no certificate revocation list with which a validating entity can check. Instead, a certificate begins to be rejected when either it expires, or one of the validating entities begins to reject the certificate based on some local policy. An example of setting such a policy would be an end-user setting options to no longer allow connections with the holder of a given certificate. For TLS certificates that are part of a certificate chain, the validity of certificates should be checked against certificate revocation lists from the level of the certificate being used in a trust decision (possibly the root certificate) down to the leaf certificate. The solution for certificate revocation with use of certificate chains is similar to the method presented in PEAP. Lord, Bowler Standards Track [Page 25] INTERNET DRAFT PEAPOD October 2003 5. References [PEAP] Josefsson et.al, "Protected EAP Protocol", Internet draft (work in progress), draft-josefsson-pppext-eap-tls-eap-06.txt, March 2003 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, November 1998. [RFC3268] Chown, P., ?Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)?, RFC 3268, June 2002. [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [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. Lord, Bowler Standards Track [Page 26] INTERNET DRAFT PEAPOD October 2003 Appendix A - Examples In the case where the identity exchange occurs within PEAPOD Part 1, and PEAPOD Part 2 is used to exchange a secret, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ -> Identity (MyID) <- EAP-Request/ EAP-Type=PEAPOD (PEAPOD Start, S bit set) EAP-Response/ -> EAP-Type=PEAPOD (TLS client_hello) <- EAP-Request/ EAP-Type=PEAPOD (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ -> EAP-Type=PEAPOD (TLS certificate, TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=PEAPOD (TLS change_cipher_spec, TLS finished) TLS channel established (messages sent within the TLS channel) <- EAP-Request/ EAP-Type=PEAPOD (Query Request, Peer Authentication requirements) EAP-Response/ -> EAP-Type=PEAPOD (Query Response, Lord, Bowler Standards Track [Page 27] INTERNET DRAFT PEAPOD October 2003 Flags=A) <- EAP-Request/ EAP-Type=PEAPOD (Secret Request Packet, Secret data) EAP-Response/ -> EAP-Type=PEAPOD (Secret Response Packet, Flags=S) <- EAP-Success TLS channel torn down (messages sent in cleartext) Lord, Bowler Standards Track [Page 28] INTERNET DRAFT PEAPOD October 2003 Where all peers are known to support PEAPOD, and the PEAPOD Part 2 secret exchange is not needed, the conversation appears as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ EAP-Type=PEAPOD (PEAPOD Start, S bit set) EAP-Response/ -> EAP-Type=PEAPOD (TLS client_hello) <- EAP-Request/ EAP-Type=PEAPOD (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ -> EAP-Type=PEAPOD (TLS certificate, TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) <- EAP-Request/ EAP-Type=PEAPOD (TLS change_cipher_spec, TLS finished) TLS channel established (messages sent within the TLS channel) <- EAP-Request/ EAP-Type=PEAPOD (Query Request, Peer Authentication requirements) EAP-Response/ -> EAP-Type=PEAPOD (Query Response, Flags= (all zeroes) ) <- EAP-Success TLS channel torn down (messages sent in cleartext) Lord, Bowler Standards Track [Page 29] INTERNET DRAFT PEAPOD October 2003 In the case where the identity exchange occurs within PEAPOD Part 1, and a previous session is resumed, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ -> Identity (MyID) <- EAP-Request/ EAP-Type=PEAPOD (PEAPOD Start, S bit set) EAP-Response/ -> EAP-Type=PEAPOD (TLS client_hello) <- EAP-Request/ EAP-Type=PEAPOD (TLS server_hello, TLS change_cipher_spec, TLS finished) EAP-Response/ -> EAP-Type=PEAPOD (TLS change_cipher_spec, TLS finished) TLS channel established TLS channel torn down (messages sent in cleartext) <- EAP-Success - need examples of failure cases, etc. Lord, Bowler Standards Track [Page 30] INTERNET DRAFT PEAPOD October 2003 Acknowledgments Author Addresses Christopher Lord Intel Corporation 2111 NE 25th Ave M/S: JF3-232 Hillsboro, OR 97124-5961 USA Phone: +1-503-264-0152 Fax: +1-503-264-0170 Email: chris.lord@intel.com David Bowler Intel Corporation 2111 NE 25th Ave M/S: JF3-232 Hillsboro, OR 97124-5961 USA Phone: +1-503-264-9292 Fax: +1-503-264-0170 Email: david.bowler@intel.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Lord, Bowler Standards Track [Page 31] INTERNET DRAFT PEAPOD October 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Lord, Bowler Standards Track [Page 32]