Subject: [eap] Issue 71: Key framework review

From: [email-masked] (Bernard Aboba)
Date: Mon, 27 Jan 2003 05:14:32 -0800 (PST)

Issue 71: Key framework review
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: January 26, 2003
Document: draft-aboba-pppext-key-problem-05.txt
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:

Comments marked with "JARI:"
JARI: Overall comments: I think this looks pretty good at the moment.
There are many places in the document where we have to be more precise
than what the text currently says, however. The main worry that I have
with this document is that I don't understand how big changes are required
to provide what Jesse Walker (AAA issue 294) wanted to have for
three-party participation. And I don't understand the role of NAS/client
layer 2 and 3 addresses and what is required there. Finally, the document
would beclearer if EAP ciphersuite and link ciphersuite issues were kept
completely separate from each other.
These limitations can be overcome via negotiation of EAP methods such as
EAP TLS [RFC2716] that support mutual authentication, as well as key
derivation.
JARI: Right.
1.2. Terminology
This document frequently uses the following terms:
Client-Server Token (CS-Token)
The package within which the MSK is transported between the EAP Server and
the EAP Client. The package MUST be integrity protected, authenticated and
encrypted, so as to protect the MSK
JARI: Not replay protected?
from compromise. In addition to the MSK, the CS-Token MAY include one or
more attributes providing information on MSK usage. Attributes may include
the NAS layer 2 and layer 3 addresses, MSK
JARI: How would layer 3 addresses be available at this time? In PPP, NCPs
run after authentication, right? And how would layer 2 addresses be
possible to distribute in a manner independent from the actual link layer
specifics?
Cryptographic binding
The demonstration of the EAP Client to the EAP Server that a single entity
has acted as the EAP Client for all methods executed within a sequence or
tunnel. Binding MAY also imply that the EAP Server demonstrates to the
Client that a single entity has acted as the EAP Server for all methods
executed within a sequence or tunnel. If executed correctly, binding
serves to mitigate man-in-the-middle vulnerabilities.
JARI: Add a reference to Valtteri Niemi et al paper or some other suitable
source?
Master Session Key (MSK)
Keying material provided to the EAP Client and NAS by the AAA Server,
acting as a Key Distribution Center (KDC). The MSK is used in derivation
of Transient Session Keys for the ciphersuite negotiated between the EAP
Client and NAS. So that the MSK is
usable with any ciphersuite, it is longer than necessary, and is truncated
to fit.
JARI: This sounds a bit ad hoc. Why not require that (a) the MSK is long
enough to have sufficient entropy and (b) provide an algorithm for
deriving actual TSKs?
Note that an Authentication Server may simultaneously provide the EAP
Client with MSKs suitable for use with multiple APs, so as to enable fast
handoff. Similarly the AAA Server may send MSKs to multiple APs
simultaneously. Note that where the AP supports transport of multiple MSK
sets to the EAP Client and NASes, the MSKs MUST be kept cryptographically
separate from each other.
JARI: Indentation of the above paragraph is wrong.
Within [IEEE80211i], the Enc-RECV-Key is also known as the Pairwise Master
Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and CCMP derive
their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP
ciphersuite, when used with IEEE 802.1X-2002, derives its TSKs from both
the Enc-RECV-Key and the Enc-SEND-Key.
JARI: Repeated text, see previous paragraph.
The MSK contained within the CS-Token and AN-Tokens is suitable for use
with any negotiated ciphersuite, and therefore an EAP method MUST NOT
directly use the MSK
JARI: s/, and therefore an/. An/
3.1. Two-party exchange
Figure 3 illustrates the two-party exchange, where the Client is
authenticated locally by the NAS using a locally implemented
authentication method. In this case, the EAP Master Key (EMK) is derived
on the Client and the NAS, which acts as the EAP Server during the EAP
authentication exchange, and the Client-Server token is transported by the
NAS to the EAP Client. The Client and NAS then use the MSK contained with
the CS-Token to derive the transient session keys used
JARI: Does this require the MSK to be actually sent? Wouldn't it be better
to leave it to the methods, some methods can derive keys without actually
sendin them encrypted over the channel?
If the authentication occurs with a method not implemented on the NAS, or
involves a non-local user whose credentials the Server is unable to
validate, then the NAS functions as a "pass-through". For pass-through
authentication methods, instead of implementing the authentication method
locally, the NAS delegates the authentication to an Authentication Server.
The Authentication Server installs the desired EAP method, typically by
interfacing with the operating system via an EAP API, such as that
described in [EAPAPI].
JARI: Doesn't this go to the three-party exchange section?
JARI: Does the direction of sending the CS-Token have to be asymmetric?
Where key distribution is supported, the EAP Client and Authentication
Server (EAP Server) MUST mutually authenticate via the negotiated EAP
method, and derive keys only known between the EAP Client and Server,
known as the EMK. During EAP authentication, the CS-Token MAY be
transported from the EAP Server to the EAP Client, providing the Client
with the MSK. Alternatively, the MSK MAY be derived from the EMK, via a
one-way function. Whether the MSK is derived or transported, possession
JARI: Good that we allow CS-Token to be derived.
Utilizing the AAA protocol, the Authentication Server and NAS MUST
mutually authenticate, and derive a protected channel which MUST provide
per-packet integrity protection, authentication and confidentiality.
JARI: No replay protection? Wouldn't someone be able to inject a AN-token
from an old session? But perhaps this is trivially handled by
RADIUS/DIAMETER checking for a response matching a request it has sent.
AN-Token is distributed by the Authentication Server to the NAS over this
channel. Where possible, the channel between the Authentication Server and
NAS SHOULD be protected using a session key, as in [DiamEAP]
JARI: Reference Diameter base here instead?
During the (optional) TSK derivation step, the EAP Client and NAS MUST
mutually authenticate by providing mutual posession of the portion of
JARI: s/providing/proving/?
JARI: Is the use of TSKs (derived using an algorithm) on both sides to
send packets sufficient? To use an IP-layer example, would it OK to set up
a manual IPsec SA pair with keys set to f(MSK)? Or is IKE needed?
If the Authentication Server and NAS do not mutually authenticate, then
the the EAP Client will once again be vulnerable to rogue Authentication
Servers, NASes or both. If there is no per-packet authentication,
integrity and replay protection between the Authentication Server and
JARI: Not in line with what was said under figure 5. Replay protection
wasn't included there, and confidentiality is not mentioned here. NAS,
then the EAP conversation could be modified in transit, or packets can
spoofed.
Since the EMK is uniquely held by the EAP Client and Server, and only
mutually authenticating EAP methods may distribute keys, proof of
possession of the EMK is proof of a completed mutual authentication. In
order to ensure that the NAS does not possess the EMK, which could be used
to impersonate the EAP Client or EAP Server, the EMK MUST NOT be provided
to third parties such as the
JARI: This statement may have to be more precise. What does "used to
impersonate mean"? Unless the EAP method is horribly broken, the rogue NAS
does not appear to be able to perform a new authentication in some other
place, claiming to be the client. Similarly, even if the EMK is not given
to the NAS, the NAS will still be able to impersonate the client in the
sense of being able to form payload packets that look like those coming
from the client. And it can also claim that the client has sent packets it
did not. So what do we really want to say here?
[b] Master Session Key (MSK) branch. The MSK is (optionally) distributed
by the Authentication Server to the EAP Client within the CS-Token (or
alternatively, derived from the EMK). It is
JARI: Maybe: "The MSK is (optionally) either derived from the EMK or
distributed by the ..."
If the Authentication Server and NAS do not mutually authenticate, then
the the EAP Client will once again be vulnerable to rogue Authentication
Servers, NASes or both. If there is no per-packet authentication,
integrity and replay protection between the Authentication Server and NAS,
then the EAP conversation could be modified in transit, or packets can
spoofed.
JARI: If there is no confidentiality, then ... what?
MSK hierarchy
For a ciphersuite to be suitable for use with dynamic keying via EAP a
specification MUST be provided describing how TSKs are derived from the
MSK.
JARI: Does this belong under 4.2? This is not an EAP protocol issue, and
methods are not expected to know about ciphersuites.
Cryptographic Separation
Methods supporting key derivation MUST demonstrate cryptographic
separation between the TEKs and TSKs. Also, it must be demonstrated that
possession of the MSK does not provide information useful in determining
the EMK.
JARI: Hmm... Isn't the following the hierarchy we are specifying here:
(some secret data) -> EMK -> TEK -> MSK -> TSK
If it is, it appears that the part that methods are responsible is that
(a) TEKs do not reveal anything from EMK, (b) MSK does not reveal anything
from EMK, (c) TEK and MSK are cryptographically separated. (Do we have a
term for one-way cryptographic separation, we could use it for a and b
above?) The TSK issue doesn't appear to belong to the responsibility of
EAP methods. However, hopefully we have somewhere the right requirement
for that i.e. (d) TSK does not reveal MSK. Luckily, since TEK and MSK are
separated, a TSK generated in any manner from MSK is also separated from
TEK, I think.
Session Uniqueness
In order to assure non-repetition of TSKs even in cases where one party
may not have a high quality random number generator, the MSK derivation
SHOULD include a two-way nonce exchange, using nonces of at least
128-bits. Note although the IEEE 802.11 RSN TSK derivation includes a
nonce exchange, the TSK derivation step is link layer dependent, so that a
link layer nonce exchange cannot be guaranteed to occur. As a result, a
nonce exchange is still needed within the EAP method itself. A nonce
exchange SHOULD also be included in the derivation of the TEKs from the
EMK.
JARI: It might make sense to require either (a) nonce exchange or (b) high
quality random number generation from at least one party.
TEK derivation
In order to establish a protected channel between the EAP Client and
Server as part of the EAP exchange, a ciphersuite needs to be negotiated
and keyed, using TEKs derived from the EMK. The ciphersuite used to
protect the EAP exchange is distinct from the ciphersuite negotiated
between the EAP client and NAS, used to protect data. Where a protected
channel is established within the EAP method, the method specification
MUST specify the mechanism by which the EAP ciphersuite is negotiated, as
well as the algorithms for derivation of TEKs from the EMK during the EAP
authentication exchange.
JARI: TEK is EAP-method issue only, right? I'm starting to think TEKs and
the ciphersuite to protect EAP (as in EAP TLS ciphersuites) needs to have
its own section, because it is easy to confuse it with the data protection
ciphersuite.
Cryptographic separation
The TSKs derived from the MSK MUST be cryptographically separate from each
other. Similarly, TEKs MUST be cryptographically separate from each other.
In addition, the TSKs MUST be cryptographically separate from the TEKs.
JARI: Add that knowledge of TSK must not reveal anything from the MSK. The
same for TEK->MSK.
[RFC2284bis] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible
Authentication Protocol (EAP)", Internet draft (work in progress),
draft-ietf-pppext-rfc2284bis-08.txt, December 2002.
JARI: Author list on the above has changed, reference list needs an
update.
Export -------->| Client| | Server| | Client| | Server|
Figure B-1 - TLS [RFC2246] Key Hierarchy
JARI: What's "Export"?
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient
session key used to protect unicast traffic, is derived from the PMK
(octets 0-31 of the MSK), otherwise known as the Peer to Authenticator
Encryption Key. Within [RFC2548], the PMK is transported via the MS-
MPPE-Recv-Key attribute. In IEEE 802.11 RSN, the PTK is derived from the
PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion" || Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
Where:
PMK = MSK(0,31)
SA = Station MAC address
AA = AP MAC address
JARI: These are simply put in by the AP? They are not protected by the EAP
method, and delivered from the server? How does this relate to Jesse
Walker's issue for AAA key transport?

---

From: [email-masked] (Jari Arkko)
Date: Mon, 27 Jan 2003 11:47:48 +0200

Hello,

Given that there were many comments to different
parts of the documents, the comments may be easier
to read from the following URLs:

   http://www.piuha.net/~jarkko/publications/eap/keyingframework_review.txt
   http://www.piuha.net/~jarkko/publications/eap/rfc2869bis_review.txt

Jari