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

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 27 Jun 2006 15:07:03 -0700

Hi Bernard,

Thanks for the update, comments inline below: 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, June 24, 2006 6:51 PM
> To: [email-masked]
> Subject: [Emu] Partial Proposed Resolution to RFC 2716bis Review
> 
> 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."
> 

[Joe] I think this is a step in the right direction. I'm not sure that
Server-ID is the only thing you may check for a particular deployment.  

> 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.
> 
[Joe] OK

> 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.
> 
[Joe] OK I think this is good.  How does 1.1 and 1.2 impact backwards
compatibility?

> 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."
> 

[Joe] OK, I think perhaps the Session ID should start with 0x0D?

> 
> 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.
> 

[Joe] OK, but we may want to also include security considerations for
the case of EAP-TLS.  When EAP-TLS is negotiated the ciphersuite that
will be chosen is not known, so it is possible that the TLS negotiation
may result is a weaker authentication method than was intended when
EAP-TLS was negotiated through EAP.  Implementations should take this
into account when negotiating TLS ciphersuites. 

> 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.
> 
[Joe] RFC4346 allows you define an application profile so we wouldn't
necessarily have to make this ciphersuite mandatory. 

>    In addition, EAP-TLS servers SHOULD support and be able to 
> negotiate
>    all of the following TLS ciphersuites:
> 
[Joe] what do you mean support and be able to negotiate?  Why not just
support?

>        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."
> 

[Joe] Section looks good. 

> 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.
> 
> 
[Joe] OK, I think in the sample text for section 2.5 you used 0x0c
instead of 0x0d.

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

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Jun 2006 18:28:48 -0700

>[Joe] OK I think this is good.  How does 1.1 and 1.2 impact backwards 

I don't think we know yet.   To get clarity, we need to do some tests. It is 
possible that only a subset of the problems that Y. Pettersen describes in 
his draft afflict TLS-based EAP methods:
http://www.watersprings.org/pub/id/draft-pettersen-tls-interop-experience-00.txt

BTW, I have verified some ciphersuite interoperability problems with 
existing implementations.  For example, it appears that 3DES ciphersuites do 
not interoperate (though they can be negotiated).

>[Joe] OK, I think perhaps the Session ID should start with 0x0D?

Oops.  Typo :(

>into account when negotiating TLS ciphersuites.

It is definitely important to have policy in place.  This is required in 
EAP-TLS implementations seeking FIPS 140-2 certification -- only 
FIPS-approved ciphersuites (e.g. 3DES, AES, HMAC-SHA1) can be negotiated, 
not RC4 or MD5.

I'll add a section on this in the next rev.

>necessarily have to make this ciphersuite mandatory.

Just found some interoperability issues with this ciphersuite,  so making it 
mandatory could be problematic :(

Maybe we should stick with RC4 as mandatory, and add AES as a SHOULD?  RC4 
definitely interoperates.

>[Joe] what do you mean support and be able to negotiate?  Why not just 

Support should be sufficient.  In some situations, not every supported 
ciphersuite will be negotiable (e.g. in FIPS mode, RC4 ciphersuites will not 
be negotiable).

>[Joe] OK, I think in the sample text for section 2.5 you used 0x0c

Yup.  Typo :(