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 protected]
https://www1.ietf.org/mailman/listinfo/emu
