Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7170

Tunnel Extensible Authentication Protocol (TEAP) Version 1

Pages: 101
Proposed Standard
Errata
Updated by:  9427
Part 3 of 4 – Pages 58 to 83
First   Prev   Next

Top   ToC   RFC7170 - Page 58   prevText

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].
Top   ToC   RFC7170 - Page 59

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.
Top   ToC   RFC7170 - Page 60
     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].
Top   ToC   RFC7170 - Page 61

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
Top   ToC   RFC7170 - Page 62
   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
Top   ToC   RFC7170 - Page 63
   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
Top   ToC   RFC7170 - Page 64
   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
Top   ToC   RFC7170 - Page 65
   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
Top   ToC   RFC7170 - Page 66
   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].
Top   ToC   RFC7170 - Page 67

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
Top   ToC   RFC7170 - Page 68
   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
Top   ToC   RFC7170 - Page 69
   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.
Top   ToC   RFC7170 - Page 70
   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.
Top   ToC   RFC7170 - Page 71
   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
Top   ToC   RFC7170 - Page 72
   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]
Top   ToC   RFC7170 - Page 73
   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
Top   ToC   RFC7170 - Page 74
   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                        482

8. 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.
Top   ToC   RFC7170 - Page 75

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.
Top   ToC   RFC7170 - Page 76

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.
Top   ToC   RFC7170 - Page 77
   [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.
Top   ToC   RFC7170 - Page 78
   [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.
Top   ToC   RFC7170 - Page 79

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.
Top   ToC   RFC7170 - Page 80

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.
Top   ToC   RFC7170 - Page 81

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.
Top   ToC   RFC7170 - Page 82

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.
Top   ToC   RFC7170 - Page 83

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)

Next Section