Hi Bernard, Thanks for the update, comments inline below:
> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 24, 2006 6:51 PM > To: [email protected] > 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 protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
