RFC 7170
Tunnel Extensible Authentication Protocol (TEAP) Version 1
5. Cryptographic Calculations
For key derivation and crypto-binding, TEAP uses the Pseudorandom Function (PRF) and MAC algorithms negotiated in the underlying TLS session. Since these algorithms depend on the TLS version and ciphersuite, TEAP implementations need a mechanism to determine the version and ciphersuite in use for a particular session. The implementation can then use this information to determine which PRF and MAC algorithm to use.5.1. TEAP Authentication Phase 1: Key Derivations
With TEAPv1, the TLS master secret is generated as specified in TLS. If a PAC is used, then the master secret is obtained as described in [RFC5077]. TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to derive the session_key_seed. The label used in the derivation is "EXPORTER: teap session key seed". The length of the session key seed material is 40 octets. No context data is used in the export process. The session_key_seed is used by the TEAP authentication Phase 2 conversation to both cryptographically bind the inner method(s) to the tunnel as well as generate the resulting TEAP session keys. The other TLS keying materials are derived and used as defined in [RFC5246].
5.2. Intermediate Compound Key Derivations
The session_key_seed derived as part of TEAP Phase 2 is used in TEAP Phase 2 to generate an Intermediate Compound Key (IMCK) used to verify the integrity of the TLS tunnel after each successful inner authentication and in the generation of Master Session Key (MSK) and Extended Master Session Key (EMSK) defined in [RFC3748]. Note that the IMCK MUST be recalculated after each successful inner EAP method. The first step in these calculations is the generation of the base compound key, IMCK[n] from the session_key_seed, and any session keys derived from the successful execution of nth inner EAP methods. The inner EAP method(s) may provide Inner Method Session Keys (IMSKs), IMSK1..IMSKn, corresponding to inner method 1 through n. If an inner method supports export of an Extended Master Session Key (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in [RFC5295]. The usage label used is "TEAPbindkey@ietf.org", and the length is 64 octets. Optional data parameter is not used in the derivation. IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | "\0" | 64) where "|" denotes concatenation, EMSK is the EMSK from the inner method, "TEAPbindkey@ietf.org" consists the ASCII value for the label "TEAPbindkey@ietf.org" (without quotes), "\0" = is a NULL octet (0x00 in hex), length is the 2-octet unsigned integer in network byte order, and TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. If an inner method does not support export of an Extended Master Session Key (EMSK), then IMSK is the MSK of the inner method. The MSK is truncated at 32 octets if it is longer than 32 octets or padded to a length of 32 octets with zeros if it is less than 32 octets. However, it's possible that the peer and server sides might not have the same capability to export EMSK. In order to maintain maximum flexibility while prevent downgrading attack, the following mechanism is in place. On the sender of the Crypto-Binding TLV side: If the EMSK is not available, then the sender computes the Compound MAC using the MSK of the inner method.
If the EMSK is available and the sender's policy accepts MSK-based
MAC, then the sender computes two Compound MAC values. The first
is computed with the EMSK. The second one is computed using the
MSK. Both MACs are then sent to the other side.
If the EMSK is available but the sender's policy does not allow
downgrading to MSK-generated MAC, then the sender SHOULD only send
EMSK-based MAC.
On the receiver of the Crypto-Binding TLV side:
If the EMSK is not available and an MSK-based Compound MAC was
sent, then the receiver validates the Compound MAC and sends back
an MSK-based Compound MAC response.
If the EMSK is not available and no MSK-based Compound MAC was
sent, then the receiver handles like an invalid Crypto-Binding TLV
with a fatal error.
If the EMSK is available and an EMSK-based Compound MAC was sent,
then the receiver validates it and creates a response Compound MAC
using the EMSK.
If the EMSK is available but no EMSK-based Compound MAC was sent
and its policy accepts MSK-based MAC, then the receiver validates
it using the MSK and, if successful, generates and returns an MSK-
based Compound MAC.
If the EMSK is available but no EMSK Compound MAC was sent and its
policy does not accept MSK-based MAC, then the receiver handles
like an invalid Crypto-Binding TLV with a fatal error.
If the ith inner method does not generate an EMSK or MSK, then IMSKi
is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method
fails, then it is not included in this calculation. The derivation
of S-IMCK is as follows:
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
where TLS-PRF is the PRF negotiated as part of TLS handshake
[RFC5246].
5.3. Computing the Compound MAC
For authentication methods that generate keying material, further protection against man-in-the-middle attacks is provided through cryptographically binding keying material established by both TEAP Phase 1 and TEAP Phase 2 conversations. After each successful inner EAP authentication, EAP EMSK and/or MSKs are cryptographically combined with key material from TEAP Phase 1 to generate a Compound Session Key (CMK). The CMK is used to calculate the Compound MAC as part of the Crypto-Binding TLV described in Section 4.2.13, which helps provide assurance that the same entities are involved in all communications in TEAP. During the calculation of the Compound MAC, the MAC field is filled with zeros. The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out. 2 The EAP Type sent by the other party in the first TEAP message. 3 All the Outer TLVs from the first TEAP message sent by EAP server to peer. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included. 4 All the Outer TLVs from the first TEAP message sent by the peer to the EAP server. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.5.4. EAP Master Session Key Generation
TEAP authentication assures the Master Session Key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an Intermediate Compound Key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the MSKs from
inner EAP methods with key material from TEAP Phase 1. The resulting
MSK and EMSK are generated as part of the IMCKn key hierarchy as
follows:
MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
EMSK = TLS-PRF(S-IMCK[j],
"Extended Session Key Generating Function", 64)
where j is the number of the last successfully executed inner EAP
method.
The EMSK is typically only known to the TEAP peer and server and is
not provided to a third party. The derivation of additional keys and
transportation of these keys to a third party are outside the scope
of this document.
If no EAP methods have been negotiated inside the tunnel or no EAP
methods have been successfully completed inside the tunnel, the MSK
and EMSK will be generated directly from the session_key_seed meaning
S-IMCK = session_key_seed.
6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the TEAP
protocol, in accordance with BCP 26 [RFC5226].
The EAP Method Type number 55 has been assigned for TEAP.
The document defines a registry for TEAP TLV types, which may be
assigned by Specification Required as defined in [RFC5226].
Section 4.2 defines the TLV types that initially populate the
registry. A summary of the TEAP TLV types is given below:
0 Unassigned
1 Authority-ID TLV
2 Identity-Type TLV
3 Result TLV
4 NAK TLV
5 Error TLV
6 Channel-Binding TLV
7 Vendor-Specific TLV 8 Request-Action TLV 9 EAP-Payload TLV 10 Intermediate-Result TLV 11 PAC TLV 12 Crypto-Binding TLV 13 Basic-Password-Auth-Req TLV 14 Basic-Password-Auth-Resp TLV 15 PKCS#7 TLV 16 PKCS#10 TLV 17 Trusted-Server-Root TLV The Identity-Type defined in Section 4.2.3 contains an identity type code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial types defined are: 1 User 2 Machine The Result TLV defined in Section 4.2.4, Request-Action TLV defined in Section 4.2.9, and Intermediate-Result TLV defined in Section 4.2.11 contain a Status code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial types defined are: 1 Success 2 Failure The Error-TLV defined in Section 4.2.6 requires an error code. TEAP Error-TLV error codes are assigned based on a Specification Required basis as defined in [RFC5226]. The initial list of error codes is as follows: 1 User account expires soon 2 User account credential expires soon
3 User account authorizations change soon 4 Clock skew detected 5 Contact administrator 6 User account credentials change required 1001 Inner Method Error 1002 Unspecified authentication infrastructure problem 1003 Unspecified authentication failure 1004 Unspecified authorization failure 1005 User account credentials unavailable 1006 User account expired 1007 User account locked: try again later 1008 User account locked: admin intervention required 1009 Authentication infrastructure unavailable 1010 Authentication infrastructure not trusted 1011 Clock skew too great 1012 Invalid inner realm 1013 Token out of sync: administrator intervention required 1014 Token out of sync: PIN change required 1015 Token revoked 1016 Tokens exhausted 1017 Challenge expired 1018 Challenge algorithm mismatch 1019 Client certificate not supplied 1020 Client certificate rejected
1021 Realm mismatch between inner and outer identity
1022 Unsupported Algorithm In Certificate Signing Request
1023 Unsupported Extension In Certificate Signing Request
1024 Bad Identity In Certificate Signing Request
1025 Bad Certificate Signing Request
1026 Internal CA Error
1027 General PKI Error
1028 Inner method's channel-binding data required but not supplied
1029 Inner method's channel-binding data did not include required
information
1030 Inner method's channel binding failed
1031 User account credentials incorrect [USAGE NOT RECOMMENDED]
2001 Tunnel Compromise Error
2002 Unexpected TLVs Exchanged
The Request-Action TLV defined in Section 4.2.9 contains an action
code that is assigned on a Specification Required basis as defined in
[RFC5226]. The initial actions defined are:
1 Process-TLV
2 Negotiate-EAP
The PAC Attribute defined in Section 4.2.12.1 contains a Type code
that is assigned on a Specification Required basis as defined in
[RFC5226]. The initial types defined are:
1 PAC-Key
2 PAC-Opaque
3 PAC-Lifetime
4 A-ID
5 I-ID
6 Reserved 7 A-ID-Info 8 PAC-Acknowledgement 9 PAC-Info 10 PAC-Type The PAC-Type defined in Section 4.2.12.6 contains a type code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial type defined is: 1 Tunnel PAC The Trusted-Server-Root TLV defined in Section 4.2.18 contains a Credential-Format code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial type defined is: 1 PKCS#7-Server-Certificate-Root The various values under the Vendor-Specific TLV are assigned by Private Use and do not need to be assigned by IANA. TEAP registers the label "EXPORTER: teap session key seed" in the TLS Exporter Label Registry [RFC5705]. This label is used in derivation as defined in Section 5.1. TEAP registers a TEAP binding usage label from the "User Specific Root Keys (USRK) Key Labels" name space defined in [RFC5295] with a value "TEAPbindkey@ietf.org".7. Security Considerations
TEAP is designed with a focus on wireless media, where the medium itself is inherent to eavesdropping. Whereas in wired media an attacker would have to gain physical access to the wired medium, wireless media enables anyone to capture information as it is transmitted over the air, enabling passive attacks. Thus, physical security can not be assumed, and security vulnerabilities are far greater. The threat model used for the security evaluation of TEAP is defined in EAP [RFC3748].
7.1. Mutual Authentication and Integrity Protection
As a whole, TEAP provides message and integrity protection by establishing a secure tunnel for protecting the authentication method(s). The confidentiality and integrity protection is defined by TLS and provides the same security strengths afforded by TLS employing a strong entropy shared master secret. The integrity of the key generating authentication methods executed within the TEAP tunnel is verified through the calculation of the Crypto-Binding TLV. This ensures that the tunnel endpoints are the same as the inner method endpoints. The Result TLV is protected and conveys the true Success or Failure of TEAP, and it should be used as the indicator of its success or failure respectively. However, as EAP terminates with either a cleartext EAP Success or Failure, a peer will also receive a cleartext EAP Success or Failure. The received cleartext EAP Success or Failure MUST match that received in the Result TLV; the peer SHOULD silently discard those cleartext EAP Success or Failure messages that do not coincide with the status sent in the protected Result TLV.7.2. Method Negotiation
As is true for any negotiated EAP protocol, NAK packets used to suggest an alternate authentication method are sent unprotected and, as such, are subject to spoofing. During unprotected EAP method negotiation, NAK packets may be interjected as active attacks to negotiate down to a weaker form of authentication, such as EAP-MD5 (which only provides one-way authentication and does not derive a key). Both the peer and server should have a method selection policy that prevents them from negotiating down to weaker methods. Inner method negotiation resists attacks because it is protected by the mutually authenticated TLS tunnel established. Selection of TEAP as an authentication method does not limit the potential inner authentication methods, so TEAP should be selected when available. An attacker cannot readily determine the inner EAP method used, except perhaps by traffic analysis. It is also important that peer implementations limit the use of credentials with an unauthenticated or unauthorized server.7.3. Separation of Phase 1 and Phase 2 Servers
Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a different server than the Phase 2 conversation can introduce vulnerabilities if there is not a proper trust relationship and
protection for the protocol between the two servers. Some vulnerabilities include: o Loss of identity protection o Offline dictionary attacks o Lack of policy enforcement o Man-in-the-middle attacks (as described in [RFC7029]) There may be cases where a trust relationship exists between the Phase 1 and Phase 2 servers, such as on a campus or between two offices within the same company, where there is no danger in revealing the inner identity and credentials of the peer to entities between the two servers. In these cases, using a proxy solution without end-to-end protection of TEAP MAY be used. The TEAP encrypting/decrypting gateway MUST, at a minimum, provide support for IPsec, TLS, or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server. In addition, separation of the inner and outer method servers allows for crypto-binding based on the inner method MSK to be thwarted as described in [RFC7029]. Implementation and deployment SHOULD adopt various mitigation strategies described in [RFC7029]. If the inner method is deriving EMSK, then this threat is mitigated as TEAP utilizes the mutual crypto-binding based on EMSK as described in [RFC7029].7.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies
TEAP addresses the known deficiencies and weaknesses in the EAP method. By employing a shared secret between the peer and server to establish a secured tunnel, TEAP enables: o Per-packet confidentiality and integrity protection o User identity protection o Better support for notification messages o Protected EAP inner method negotiation o Sequencing of EAP methods o Strong mutually derived MSKs o Acknowledged success/failure indication
o Faster re-authentications through session resumption o Mitigation of dictionary attacks o Mitigation of man-in-the-middle attacks o Mitigation of some denial-of-service attacks It should be noted that in TEAP, as in many other authentication protocols, a denial-of-service attack can be mounted by adversaries sending erroneous traffic to disrupt the protocol. This is a problem in many authentication or key agreement protocols and is therefore noted for TEAP as well. TEAP was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password-based secrets. To that extent, the TEAP authentication mitigates several vulnerabilities, such as dictionary attacks, by protecting the weak credential-based authentication method. The protection is based on strong cryptographic algorithms in TLS to provide message confidentiality and integrity. The keys derived for the protection relies on strong random challenges provided by both peer and server as well as an established key with strong entropy. Implementations should follow the recommendation in [RFC4086] when generating random numbers.7.4.1. User Identity Protection and Verification
The initial identity request response exchange is sent in cleartext outside the protection of TEAP. Typically, the Network Access Identifier (NAI) [RFC4282] in the identity response is useful only for the realm of information that is used to route the authentication requests to the right EAP server. This means that the identity response may contain an anonymous identity and just contain realm information. In other cases, the identity exchange may be eliminated altogether if there are other means for establishing the destination realm of the request. In no case should an intermediary place any trust in the identity information in the identity response since it is unauthenticated and may not have any relevance to the authenticated identity. TEAP implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those Identities authenticated in Phase 2. Identity request/response exchanges sent after the TEAP tunnel is established are protected from modification and eavesdropping by attackers.
Note that since TLS client certificates are sent in the clear, if identity protection is required, then it is possible for the TLS authentication to be renegotiated after the first server authentication. To accomplish this, the server will typically not request a certificate in the server_hello; then, after the server_finished message is sent and before TEAP Phase 2, the server MAY send a TLS hello_request. This allows the peer to perform client authentication by sending a client_hello if it wants to or send a no_renegotiation alert to the server indicating that it wants to continue with TEAP Phase 2 instead. Assuming that the peer permits renegotiation by sending a client_hello, then the server will respond with server_hello, certificate, and certificate_request messages. The peer replies with certificate, client_key_exchange, and certificate_verify messages. Since this renegotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using an EAP method (for example, EAP-TLS) within the TLS session in TEAP Phase 2 instead of using TLS handshake renegotiation.7.4.2. Dictionary Attack Resistance
TEAP was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password-based secrets. TEAP mitigates dictionary attacks by allowing the establishment of a mutually authenticated encrypted TLS tunnel providing confidentiality and integrity to protect the weak credential-based authentication method.7.4.3. Protection against Man-in-the-Middle Attacks
Allowing methods to be executed both with and without the protection of a secure tunnel opens up a possibility of a man-in-the-middle attack. To avoid man-in-the-middle attacks it is recommended to always deploy authentication methods with the protection of TEAP. TEAP provides protection from man-in-the-middle attacks even if a deployment chooses to execute inner EAP methods both with and without TEAP protection. TEAP prevents this attack in two ways: 1. By using the PAC-Key to mutually authenticate the peer and server during TEAP authentication Phase 1 establishment of a secure tunnel. 2. By using the keys generated by the inner authentication method (if the inner methods are key generating) in the crypto-binding exchange and in the generation of the key material exported by the EAP method described in Section 5.
TEAP crypto binding does not guarantee man-in-the-middle protection if the client allows a connection to an untrusted server, such as in the case where the client does not properly validate the server's certificate. If the TLS ciphersuite derives the master secret solely from the contribution of secret data from one side of the conversation (such as ciphersuites based on RSA key transport), then an attacker who can convince the client to connect and engage in authentication can impersonate the client to another server even if a strong inner method is executed within the tunnel. If the TLS ciphersuite derives the master secret from the contribution of secrets from both sides of the conversation (such as in ciphersuites based on Diffie-Hellman), then crypto binding can detect an attacker in the conversation if a strong inner method is used.7.4.4. PAC Binding to User Identity
A PAC may be bound to a user identity. A compliant implementation of TEAP MUST validate that an identity obtained in the PAC-Opaque field matches at minimum one of the identities provided in the TEAP Phase 2 authentication method. This validation provides another binding to ensure that the intended peer (based on identity) has successfully completed the TEAP Phase 1 and proved identity in the Phase 2 conversations.7.5. Protecting against Forged Cleartext EAP Packets
EAP Success and EAP Failure packets are, in general, sent in cleartext and may be forged by an attacker without detection. Forged EAP Failure packets can be used to attempt to convince an EAP peer to disconnect. Forged EAP Success packets may be used to attempt to convince a peer that authentication has succeeded, even though the authenticator has not authenticated itself to the peer. By providing message confidentiality and integrity, TEAP provides protection against these attacks. Once the peer and authentication server (AS) initiate the TEAP authentication Phase 2, compliant TEAP implementations MUST silently discard all cleartext EAP messages, unless both the TEAP peer and server have indicated success or failure using a protected mechanism. Protected mechanisms include the TLS alert mechanism and the protected termination mechanism described in Section 3.3.3. The success/failure decisions within the TEAP tunnel indicate the final decision of the TEAP authentication conversation. After a success/failure result has been indicated by a protected mechanism, the TEAP peer can process unprotected EAP Success and EAP Failure messages; however, the peer MUST ignore any unprotected EAP Success
or Failure messages where the result does not match the result of the protected mechanism. To abide by [RFC3748], the server sends a cleartext EAP Success or EAP Failure packet to terminate the EAP conversation. However, since EAP Success and EAP Failure packets are not retransmitted, the final packet may be lost. While a TEAP-protected EAP Success or EAP Failure packet should not be a final packet in a TEAP conversation, it may occur based on the conditions stated above, so an EAP peer should not rely upon the unprotected EAP Success and Failure messages.7.6. Server Certificate Validation
As part of the TLS negotiation, the server presents a certificate to the peer. The peer SHOULD verify the validity of the EAP server certificate and SHOULD also examine the EAP server name presented in the certificate in order to determine whether the EAP server can be trusted. When performing server certificate validation, implementations MUST provide support for the rules in [RFC5280] for validating certificates against a known trust anchor. In addition, implementations MUST support matching the realm portion of the peer's NAI against a SubjectAltName of type dNSName within the server certificate. However, in certain deployments, this might not be turned on. Please note that in the case where the EAP authentication is remote, the EAP server will not reside on the same machine as the authenticator, and therefore, the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a certification authority (CA) controlling the intended domain and whether the authenticator can be authorized by a server in that domain.7.7. Tunnel PAC Considerations
Since the Tunnel PAC is stored by the peer, special care should be given to the overall security of the peer. The Tunnel PAC MUST be securely stored by the peer to prevent theft or forgery of any of the Tunnel PAC components. In particular, the peer MUST securely store the PAC-Key and protect it from disclosure or modification. Disclosure of the PAC-Key enables an attacker to establish the TEAP tunnel; however, disclosure of the PAC-Key does not reveal the peer or server identity or compromise any other peer's PAC credentials. Modification of the PAC-Key or PAC-Opaque components of the Tunnel PAC may also lead to denial of service as the tunnel establishment will fail. The PAC-Opaque component is the effective TLS ticket extension used to establish the tunnel using the techniques of [RFC5077]. Thus, the security considerations defined by [RFC5077]
also apply to the PAC-Opaque. The PAC-Info may contain information about the Tunnel PAC such as the identity of the PAC issuer and the Tunnel PAC lifetime for use in the management of the Tunnel PAC. The PAC-Info should be securely stored by the peer to protect it from disclosure and modification.7.8. Security Claims
This section provides the needed security claim requirement for EAP [RFC3748]. Auth. mechanism: Certificate-based, shared-secret-based, and various tunneled authentication mechanisms. Ciphersuite negotiation: Yes Mutual authentication: Yes Integrity protection: Yes. Any method executed within the TEAP tunnel is integrity protected. The cleartext EAP headers outside the tunnel are not integrity protected. Replay protection: Yes Confidentiality: Yes Key derivation: Yes Key strength: See Note 1 below. Dictionary attack prot.: Yes Fast reconnect: Yes Cryptographic binding: Yes Session independence: Yes Fragmentation: Yes Key Hierarchy: Yes Channel binding: Yes
Notes 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [NIST-SP-800-57]. [RFC3766], Section 5 advises use of the following required RSA or DH (Diffie-Hellman) module and DSA (Digital Signature Algorithm) subgroup size in bits for a given level of attack resistance in bits. Based on the table below, a 2048-bit RSA key is required to provide 112-bit equivalent key strength: Attack Resistance RSA or DH Modulus DSA subgroup (bits) size (bits) size (bits) ----------------- ----------------- ------------ 70 947 129 80 1228 148 90 1553 167 100 1926 186 150 4575 284 200 8719 383 250 14596 4828. Acknowledgements
This specification is based on EAP-FAST [RFC4851], which included the ideas and efforts of Nancy Cam-Winget, David McGrew, Joe Salowey, Hao Zhou, Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc. The TLV processing was inspired from work on the Protected Extensible Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan Smith, Sean Turner, and Simon Josefsson. The method for linking identity and proof-of-possession by placing the tls-unique value in the challengePassword field of the CSR as described in Section 3.8.2 was inspired by the technique described in "Enrollment over Secure Transport" [RFC7030]. Helpful review comments were provided by Russ Housley, Jari Arkko, Ilan Frenkel, Jeremy Steiglitz, Dan Harkins, Sam Hartman, Jim Schaad, Barry Leiba, Stephen Farrell, Chris Lonvick, and Josh Howlett.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010. [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010. [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
9.2. Informative References
[IEEE.802-1X.2013] IEEE, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2013. [NIST-SP-800-57] National Institute of Standards and Technology, "Recommendation for Key Management", NIST Special Publication 800-57, July 2012. [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", February 2014. [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007. [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1 /ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. [RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010. [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol", RFC 6124, February 2011. [RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, "Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method", RFC 6678, July 2012. [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013. [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013. [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, October 2013. [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over Secure Transport", RFC 7030, October 2013. [X.690] ITU-T, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, November 2008.
Appendix A. Evaluation against Tunnel-Based EAP Method Requirements
This section evaluates all tunnel-based EAP method requirements described in [RFC6678] against TEAP version 1.A.1. Requirement 4.1.1: RFC Compliance
TEAPv1 meets this requirement by being compliant with RFC 3748 [RFC3748], RFC 4017 [RFC4017], RFC 5247 [RFC5247], and RFC 4962 [RFC4962]. It is also compliant with the "cryptographic algorithm agility" requirement by leveraging TLS 1.2 for all cryptographic algorithm negotiation.A.2. Requirement 4.2.1: TLS Requirements
TEAPv1 meets this requirement by mandating TLS version 1.2 support as defined in Section 3.2.A.3. Requirement 4.2.1.1.1: Ciphersuite Negotiation
TEAPv1 meets this requirement by using TLS to provide protected ciphersuite negotiation.A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms
TEAPv1 meets this requirement by mandating TLS_RSA_WITH_AES_128_CBC_SHA as a mandatory-to-implement ciphersuite as defined in Section 3.2.A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key Establishment
TEAPv1 meets this requirement by mandating TLS_RSA_WITH_AES_128_CBC_SHA as a mandatory-to-implement ciphersuite that provides certificate-based authentication of the server and is approved by NIST. The mandatory-to-implement ciphersuites only include ciphersuites that use strong cryptographic algorithms. They do not include ciphersuites providing mutually anonymous authentication or static Diffie-Hellman ciphersuites as defined in Section 3.2.A.6. Requirement 4.2.1.2: Tunnel Replay Protection
TEAPv1 meets this requirement by using TLS to provide sufficient replay protection.
A.7. Requirement 4.2.1.3: TLS Extensions
TEAPv1 meets this requirement by allowing TLS extensions, such as TLS Certificate Status Request extension [RFC6066] and SessionTicket extension [RFC5077], to be used during TLS tunnel establishment.A.8. Requirement 4.2.1.4: Peer Identity Privacy
TEAPv1 meets this requirement by establishment of the TLS tunnel and protection identities specific to the inner method. In addition, the peer certificate can be sent confidentially (i.e., encrypted).A.9. Requirement 4.2.1.5: Session Resumption
TEAPv1 meets this requirement by mandating support of TLS session resumption as defined in Section 3.2.1 and TLS session resume using a PAC as defined in Section 3.2.2 .A.10. Requirement 4.2.2: Fragmentation
TEAPv1 meets this requirement by leveraging fragmentation support provided by TLS as defined in Section 3.7.A.11. Requirement 4.2.3: Protection of Data External to Tunnel
TEAPv1 meets this requirement by including the TEAP version number received in the computation of the Crypto-Binding TLV as defined in Section 4.2.13.A.12. Requirement 4.3.1: Extensible Attribute Types
TEAPv1 meets this requirement by using an extensible TLV data layer inside the tunnel as defined in Section 4.2.A.13. Requirement 4.3.2: Request/Challenge Response Operation
TEAPv1 meets this requirement by allowing multiple TLVs to be sent in a single EAP request or response packet, while maintaining the half- duplex operation typical of EAP.A.14. Requirement 4.3.3: Indicating Criticality of Attributes
TEAPv1 meets this requirement by having a mandatory bit in each TLV to indicate whether it is mandatory to support or not as defined in Section 4.2.
A.15. Requirement 4.3.4: Vendor-Specific Support
TEAPv1 meets this requirement by having a Vendor-Specific TLV to allow vendors to define their own attributes as defined in Section 4.2.8.A.16. Requirement 4.3.5: Result Indication
TEAPv1 meets this requirement by having a Result TLV to exchange the final result of the EAP authentication so both the peer and server have a synchronized state as defined in Section 4.2.4.A.17. Requirement 4.3.6: Internationalization of Display Strings
TEAPv1 meets this requirement by supporting UTF-8 format in the Basic-Password-Auth-Req TLV as defined in Section 4.2.14 and the Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.A.18. Requirement 4.4: EAP Channel-Binding Requirements
TEAPv1 meets this requirement by having a Channel-Binding TLV to exchange the EAP channel-binding data as defined in Section 4.2.7.A.19. Requirement 4.5.1.1: Confidentiality and Integrity
TEAPv1 meets this requirement by running the password authentication inside a protected TLS tunnel.A.20. Requirement 4.5.1.2: Authentication of Server
TEAPv1 meets this requirement by mandating authentication of the server before establishment of the protected TLS and then running inner password authentication as defined in Section 3.2.A.21. Requirement 4.5.1.3: Server Certificate Revocation Checking
TEAPv1 meets this requirement by supporting TLS Certificate Status Request extension [RFC6066] during tunnel establishment.A.22. Requirement 4.5.2: Internationalization
TEAPv1 meets this requirement by supporting UTF-8 format in Basic- Password-Auth-Req TLV as defined in Section 4.2.14 and Basic- Password-Auth-Resp TLV as defined in Section 4.2.15.
A.23. Requirement 4.5.3: Metadata
TEAPv1 meets this requirement by supporting Identity-Type TLV as defined in Section 4.2.3 to indicate whether the authentication is for a user or a machine.A.24. Requirement 4.5.4: Password Change
TEAPv1 meets this requirement by supporting multiple Basic-Password- Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a single EAP authentication, which allows "housekeeping"" functions such as password change.A.25. Requirement 4.6.1: Method Negotiation
TEAPv1 meets this requirement by supporting inner EAP method negotiation within the protected TLS tunnel.A.26. Requirement 4.6.2: Chained Methods
TEAPv1 meets this requirement by supporting inner EAP method chaining within protected TLS tunnels as defined in Section 3.3.1.A.27. Requirement 4.6.3: Cryptographic Binding with the TLS Tunnel
TEAPv1 meets this requirement by supporting cryptographic binding of the inner EAP method keys with the keys derived from the TLS tunnel as defined in Section 4.2.13.A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication
TEAPv1 meets this requirement by supporting the Request-Action TLV as defined in Section 4.2.9 to allow a peer to initiate another inner EAP method.A.29. Requirement 4.6.5: Method Metadata
TEAPv1 meets this requirement by supporting the Identity-Type TLV as defined in Section 4.2.3 to indicate whether the authentication is for a user or a machine.
Appendix B. Major Differences from EAP-FAST
This document is a new standard tunnel EAP method based on revision of EAP-FAST version 1 [RFC4851] that contains improved flexibility, particularly for negotiation of cryptographic algorithms. The major changes are: 1. The EAP method name has been changed from EAP-FAST to TEAP; this change thus requires that a new EAP Type be assigned. 2. This version of TEAP MUST support TLS 1.2 [RFC5246]. 3. The key derivation now makes use of TLS keying material exporters [RFC5705] and the PRF and hash function negotiated in TLS. This is to simplify implementation and better support cryptographic algorithm agility. 4. TEAP is in full conformance with TLS ticket extension [RFC5077] as described in Section 3.2.2. 5. Support is provided for passing optional Outer TLVs in the first two message exchanges, in addition to the Authority-ID TLV data in EAP-FAST. 6. Basic password authentication on the TLV level has been added in addition to the existing inner EAP method. 7. Additional TLV types have been defined to support EAP channel binding and metadata. They are the Identity-Type TLV and Channel-Binding TLVs, defined in Section 4.2.
(page 83 continued on part 4)
