tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7170

 
 
 

Tunnel Extensible Authentication Protocol (TEAP) Version 1

Part 3 of 4, p. 58 to 83
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 58 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part