Subject: [Emu] Partial Proposed Resolution to RFC 2716bis Review

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 24 Jun 2006 18:51:06 -0700

Find enclosed below some review questions from Joe Salowey.  I still am 
researching the answers to questions 1A and 1B, so I have not included a 
proposal for these yet.

--------------------------------------------------------------------------------------------------------------------------
C. This document should probably reference RFC 3280.

[BA] DONE.

D. I think the last paragraph might not be quite correct:

"... Please note that in the case where the EAP authentication is remoted 
that
   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 CA controlling the intended destination
   and whether the EAP server exists within a target sub-domain."

I'm not quite sure what the is meant by "target sub-domain."  In any
case it is important that the peer be able to authorize the server as an
EAP-Server that can authorize the authenticator the peer is connecting
to. This is more than being issued by an organizational CA since that
particular CA may issue certificates for many purposes. There either
needs to be something in the certificate or the peer must have
configuration to be able to perform the authorization.

[BA] How about this?

"  The peer MUST 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.  For
   example, just because a server certificate can chain to a trust
   anchor does not necessarily imply that it is valid for connection to
   a particular network.  As a result, the peer may also want to test
   whether the EAP server certificate is signed by a CA controlling the
   destination network and whether the Server-Id matches the format
   expected for that network.  For example, an EAP peer connecting to
   the "EXAMPLE" SSID may wish to check whether the Server-Id matches
   the regular expression "*.example.com", in addition to checking
   wehther the server certificate chains to the example.com CA."

2. Section 2.5 Key Hierarchy

A.  Why is the EMSK broken into two halves?  It should not be as this
implies a particular usage for the EMSK.  It should just be one 64 byte
value.

[BA] Right.  I've removed the mateiral on the "halves" of the EMSK.

B. Does this section tie the implementation of the PRF to 2246?  What if
TLS 1.2 supports a different PRF?

[BA] I've removed the RFC 2246 reference here and also replaced other 2246 
references with
RFC 4346 since that obsoletes 2246.

C. This section shows the TLS key hierarchy, shouldn't it show the
EAP-TLS key hierarchy?

[BA]  How about this?

"   In EAP-TLS, the MSK, EMSK and IV are derived from the TLS master
   secret via a one-way function.  This ensures that the TLS master
   secret cannot be derived from the MSK, EMSK or IV unless the one-way
   function (TLS PRF) is broken.  Since the MSK and EMSK are derived
   from the TLS master secret, if the TLS master secret is compromised
   then the MSK and EMSK are also compromised.

   The MSK is divided into two halves, corresponding to the "Peer to
   Authenticator Encryption Key" (Enc- RECV-Key, 32 octets) and
   "Authenticator to Peer Encryption Key" (Enc- SEND-Key, 32 octets).

   The IV is a 64 octet quantity that is a known value; octets 0-31 are
   known as the "Peer to Authenticator IV" or RECV-IV, and Octets 32-63
   are known as the "Authenticator to Peer IV", or SEND-IV.

   EAP-TLS derives exported keying material and parameters as follows:

   MSK(0,63)   = TLS-PRF-64(TMS, "client EAP encryption",
                    client.random || server.random)
   EMSK(0,63)  = second 64 octets of:
                 TLS-PRF-128(TMS, "client EAP encryption",
                    client.random || server.random)
   IV(0,63)    = TLS-PRF-64("", "client EAP encryption",
                    client.random || server.random)

   MSK(0,31)   = Peer to Authenticator Encryption Key (Enc-RECV-Key)
                 (MS-MPPE-Recv-Key in [RFC2548]).  Also known as the
                 PMK in [IEEE-802.11i].
   MSK(32,63)  = Authenticator to Peer Encryption Key (Enc-SEND-Key)
                 (MS-MPPE-Send-Key in [RFC2548])
   IV(0,31)    = Peer to Authenticator Initialization Vector (RECV-IV)
   IV(32,63)   = Authenticator to Peer Initialization vector (SEND-IV)
   Session-Id  = 0x0C || client.random || server.random

   Where:

   IV(W,Z)       = Octets W through Z inclusive of the IV.
   MSK(W,Z)      = Octets W through Z inclusive of the MSK.
   EMSK(W,Z)     = Octets W through Z inclusive of the EMSK.
   TMS           = TLS master_secret
   TLS-PRF-X     = TLS PRF function computed to X octets
   client.random = Nonce generated by the TLS client.
   server.random = Nonce generated by the TLS server.

         |                       | pre_master_secret       |
   server|                       |                         | client
   Random|                       V                         | Random
         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
         |     |                                     |     |
         +---->|             master_secret           |<----+
         |     |               (TMS)                 |     |
         |     |                                     |     |
         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
         |                       |                         |
         V                       V                         V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                         |
   |                        MSK, EMSK                        |
   |               label == "client EAP encryption"          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             |             |
     | MSK(0,31)   | MSK(32,63)  | EMSK(0,63)
     |             |             |
     |             |             |
     V             V             V

      Figure 2 - EAP-TLS Key Hierarchy

   The use of these keys is specific to the lower layer, as described in
   [KEYFRAME] Section 2.1."

3. Section 2.6 Ciphersuite negotiation

A. At the SAAG meeting in IETF 65 Sam brought up an issue with multiple
layers of negotiation with EAP-TLS.  Is there a vulnerability introduced
by multiple levels of negotiation?  Is it possible that an peer or
server will negotiate a weaker authentication method though the
negotiation of TLS ciphersuites than it would through EAP negotiation?

[BA] The recommended ciphersuites are addressed in [B] below.  The major 
vulnerability is a "Type Code" replacement attack which could enable an 
attacker to force negotiation of one TLS-based EAP method instead of 
another. This could lead to a downgrade attack where the TLS ciphersuite 
policies were not uniform (e.g. EAP-TLS requires 2048-bit RSA, whereas PEAP 
will allow 1024).  I will add some text on this vulnerablity, which is 
enabled because some TLS-based methods share the same key-derivation 
formula.

B. The draft does not seem to specify which ciphersuites it is intended
to be used with.  Should it?

[BA] RFC 4346 specifies a mandatory-to-implement ciphersuite in the absence 
of guidance (e.g. RFC 2716 didn't say anything about ciphersuites).  How 
about this?

"2.6.  Ciphersuite and Compression Negotiation

   EAP-TLS implementations need not necessarily support all TLS
   ciphersuites listed in [RFC4346].  Not all TLS ciphersuites are
   supported by available TLS tool kits and licenses may be required in
   some cases.

   To ensure interoperability, EAP-TLS peers and servers MUST support
   the TLS [RFC4346] mandatory-to-implement ciphersuite:

       TLS_RSA_WITH_3DES_EDE_CBC_SHA.

   In addition, EAP-TLS servers SHOULD support and be able to negotiate
   all of the following TLS ciphersuites:

       TLS_RSA_WITH_RC4_128_MD5
       TLS_RSA_WITH_RC4_128_SHA
       TLS_RSA_WITH_AES_128_CBC_SHA

   In addition, EAP-TLS peers SHOULD support at least one of the
   following TLS ciphersuites:

       TLS_RSA_WITH_RC4_128_MD5
       TLS_RSA_WITH_RC4_128_SHA
       TLS_RSA_WITH_AES_128_CBC_SHA

   Since TLS supports ciphersuite negotiation, peers completing the TLS
   negotiation will also have selected a ciphersuite, which includes
   encryption and hashing methods.  Since the ciphersuite negotiated
   within EAP-TLS applies only to the EAP conversation, TLS ciphersuite
   negotiation SHOULD NOT be used to negotiate the ciphersuites used to
   secure data.

   TLS also supports compression as well as ciphersuite negotiation.
   Therefore during the EAP-TLS conversation the endpoints MAY request
   or negotiate TLS compression.  Since compression negotiated within
   EAP-TLS applies only to the EAP conversation, TLS compression
   negotiation MUST NOT be used to negotiate compression mechanisms to
   be applied to data."

4. General

The document should define a Method-ID (for computing session-ID and key
names).  The method ID could be as simple as the concatenation of the
server and client Finished messages. (these hashes contain the Client
and Hello Random's as well as the identities exchanged in the
certificates).

[BA] Here is the text on Session-Id included in 
draft-ietf-eap-keying-14.txt:

"The EAP-TLS Session-Id is the concatenation of the Expanded EAP Type Code 
(including the Type,
Vendor-Id and Vendor-Type fields defined in [RFC3748] Section 5.7) with the 
peer and server nonces."

My recommendation is to add the following text to Section 2.5:

"Session-Id = 0x0D || client.random || server.random"

I don't think it necessary makes sense to add the additional zeroes for 
Vendor-Id and Vendor-Type in this case, since EAP-TLS is allocated from the 
standard type space, the Session-Id should be unique.

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 24 Jun 2006 19:24:58 -0700

>I will add some text on this vulnerablity, which is enabled because some 
>TLS-based methods share the same key-derivation formula.

How about this?

"4.6.  Packet Modification Attacks

   The integrity protection of EAP-TLS packets does not extend to the
   EAP header fields (Code, Identifier, Length) or the Type or Flags
   fields.  As a result, these fields may be modified by attacker.

   In most cases modification of the Code or Identifier fields will only
   result in a denial of service attack.  However, it may be possible
   for an attacker to add additional data to an EAP-TLS packet so as to
   cause it to be longer than implied by the Length field.  An
   implementation that does not check for this could be vulnerable to a
   buffer overrun.

   It is also possible for an attacker to modify the Type or Flags
   fields.  By modifying the Type field, an attacker could cause one
   TLS-based EAP method to be negotiated instead of another.  For
   example, the EAP-TLS Type field (13) could be changed to indicate
   another TLS-based EAP method.  Unless the alternative TLS-based EAP
   method utilizes a different key derivation formula, it is possible
   that an EAP method conversation altered by a man-in-the-middle could
   run all the way to completion without detection.  Unless the
   ciphersuite selection policies are identical for all TLS-based EAP
   methods utilizing the same key derivation formula, it may be possible
   for an attacker to mount a successful downgrade attack, causing the
   peer to utilize an inferior ciphersuite or TLS-based EAP method."