Subject: [eap] EAP key naming

From: [email-masked] (Walker, Jesse)
Date: Thu, 10 Jul 2003 07:55:24 -0700

Bernard,

> > There is (at least) one missing requirement: a key deriving 
> EAP method must,
> > if it completes successfully, leave the EAP Server and EAP Peer with
> > synchronized session state. At the very least the EAP Server and EAP
> > Peer must believe that the same NAIs have been 
> authenticated, must share the
> > same session key, and must have the same name for the 
> session key. This
> > does not follow necessarily from the other requirements.
> 
> That seems reasonable, although I am not clear that 
> synchronization can be
> maintained beyond the initial exchange, since either the peer or EAP
> server can age out key state and there is no EAP "delete" message to
> ensure synchronization.

While this is true, the EAP method is responsible only for establishing synchronization, not maintaining it. If the EAP method, however, does not meet the synchronization requirement, then any keying material it derives is not meaningful. If the peers have a different view of the respective peer NAIs, or if they derive different keys, or different names for the keys, then a man-in-the-middle has violated security. The syncrhonization requirement is something that a key-deriving EAP method must meet.

The discussion of maintaining synchronization, and the discussion in your original note, together imply that there is a lot more work to do if we want to support keying. In particular, we need to expand the document to discuss security association maintenance. Maybe each EAP method needs companion session termination and session updates as well. Or perhaps we can define these functions once in a way that applies to all methods. I haven't thought about it.

> > This misconstrues IEEE 802.11's request. The observation is 
> that the base EAP
> > document requires IEEE 802.11 systems with 802.1X Supplicants to
> > implement MD5 Challenge, when in fact it should expressly 
> prohibit their
> > use in this context. Mandating its implementation without 
> prohibiting
> > its use in certain contexts demands that users decide for 
> themselves in many
> > contexts, and many users are not equipped to make this decision.
> 
> It seems reasonable to indicate that MD5 Challenge is inappropriate in
> some circumstances.  Would you care to file an issue 
> indicating what text
> you'd like to add?

Here is strawman language:

	Unprotected MD5 Challenge is not suitable for some environments, such
	as IEEE 802.11 WLANs or across the unprotected Internet, because the
	protocol is not immune to man-in-the-middle attacks. It SHOULD never
	be used in such environments, and implementations SHOULD not expose
	this choice in such environments.

> > The mandatory-to-implement method either should be safe in 
> all environments,
> > or else there should be no mandatory-to-implement method. 
> The line of
> > reasoning you make above suggests you would support removing MD5
> > Challenge as mandatory-to-implement. That would probably be an
> > acceptable resolution. However, the status quo is not acceptable.
> 
> I don't think that having no mandatory-to-implement method is an
> acceptable alternative. As noted in Erik Nordmark's 
> presentation at IETF
> 56, we can add text to RFC 2284bis indicating the minimum 
> requirements for
> various circumstances, and the security claims language should make it
> clear what methods meet those requirements (no methods defined in RFC
> 2284bis are appropriate for use with 802.11).
>
> There are lots of examples of mandatory-to-implement methods in IETF
> protocols that can be used inappropriately or may not work in all
> circumstances. So I'm not sure that it's necessary (or even 
> possible) to
> create a single method that would be suitable for all 
> potential uses of
> EAP.

Ok; fair enough. If we have to have a mandatory-to-implement method, then let's change the one we have. There are a number that might be acceptable. My impression is that most folks prefer a method based on a pre-shared key. I suggest EAP-Archie as a starting point, but then I'm biased.

> That's part of the problem -- getting agreement on what the mandatory
> method should be would probably require a formal beauty 
> contest that could
> consume up to a year of the WG's time.  As Erik suggested at 
> IETF 56, our
> time would probably be better spent reviewing and publishing 
> a variety of
> methods, and making sure their security properties were well
> understood and letting the market decide.

This is a fair comment. We should get a number of methods reviewed and published as our first priority. However, the mandatory-to-implement problem still exists, and it would be worthwhile trying to address it as a secondary goal. If we can't, then we can't, but we should at least try, given that the existing mandatory-to-implement method is not right.

> > > Issue #6 requires mutual auth in all three legs -- EAP, 
> AAA, and the
> > > secure association protocol. AAA protocols already do mutual
> > > authentication -- both RADIUS & Diameter handle this.  So I
> > > think we need
> > > a requirement that EAP key deriving methods and secure association
> > > protocols support mutual authentication, and Issue #6 is handled.
> 
> Russ's requirements apply to the system as a whole, so it 
> probably makes
> sense to describe the requirements for each piece.  I don't 
> think we can
> punt on this particular issue.

Ok, punt was definitely the wrong word. We need to talk about this being a system requirement, but it is pretty clear that neither EAP nor EAP methods can address this without changing in their fundamental natures.

> > This almost but not quite right. Such a naming scheme does not
> > distinguish names across sessions between the same EAP Peer and EAP
> > Server. Think of the case where there is key roll-over due to
> > reauthentication. Does the name refer to the old or to the 
> new key? It
> > refers to both, the scheme does not unambiguously identify 
> the key, and
> > the parties will not be able to tell which to use (they will not
> > necessarily share the same notion of which one is current). 
> There does
> > not seem to be any choice but to (a) mandate that key-deriving EAP
> > methods exchange nonces and (b) the nonces are part of the name.
> 
> I agree that the EAP peer and EAP server names do not 
> uniquely define the
> EAP SA. However, EAP method such as EAP-TLS often have a 
> session-id or its
> equivalent.  Certainly a nonce exchange can help, and since 
> we are going
> to require that, perhaps your suggestions a) and b) are a way 
> to guarantee
> that the requirements are satisfied.

Then the requirement is that key-deriving EAP methods must define session discriminators that uniquely distinguish one session from another. We can give examples such as the EAP-TLS session id and EAP-Archie's NonceP and NonceS.
 
> > Since the MSK and ESMK are wholly compromised from the EAP 
> Peer's perspective
> > if either is ever shared with more than one NAS, we know 
> that such key
> > sharing cannot be allowed
> 
> The EMSK is compromised if it is known by *any* NAS.  The MSK is
> compromised if it is shared by more than one NAS.

Agreed.

> > so it is safe to use the NAS name as part of
> > the MSK name; indeed, it would be rather odd if this were 
> not the case.
> 
> So you're saying that the MSK name is different from the EAP SA
> name? Is this solely because the EAP SA is not "bound" to a 
> NAS while the
> MSK is bound?  What about the EMSK?  This is not "bound" to a 
> particular
> NAS -- so is it's name the same as the EAP SA name? What 
> about quantities
> derived from the EMSK?  How do we name those?

If there are different keys, we need to name each differently. Since the EMSK is an attribute of a session between the EAP Peer and EAP Server, and not an attribute of any NAS, it needs to be named independently of any NAS. It seems like the right way to name the EMSK is

	<Peer NAI, Server NAI, Method-specific Session Discriminator, tag>

where tag is some arbitrary label.

> So the first 4 quantities are the EAP SA name, and the MSK 
> name is the EAP
> SA name + the NAS NAI.  Is it fair to say that the EMSK name 
> is the same
> as the EAP SA name?

I am getting confused. Let me try to dig out, and you tell me if I what I write seems right. All the keys need distinct names. I thought the root session key is the MK. So it should be named

	MKID = <Peer NAI, Server NAI, Method-specific Session Discrimnator>

It needs the Peer NAI as part of the name, because the MK is an attribute of the EAP Peer's session. It needs the Server NAI as part of the name, because the MK is an attribute of the EAP Server's session. It needs some EAP method-specific session discriminator, to distinguish this session between this Peer and Server from all other sessions between the same peer. Perhaps we should include the method discriminator as well, but anything that makes a reasonable method specific session discriminator will have enough randomness to make it unlikely that two session disriminators will collide.

The MSK and EMSK names are derived from the MKID. The MSK is NAS-specific, but the EMSK is not. So these two keys should be named

	MSKID = <Peer NAI, Server NAI, Method-specific Session Discrimnator, NAS NAI>

	EMSKID = <Peer NAI, Server NAI, Method-specific Session Discrimnator, 0x00>

where I have chosen 0x00 as the tag; since the tag value is arbitrary, replace it with anything you want if you don't like 0x00.

If you derive something from the MSK, then that something is named

	SOMETHINGID =
		<Peer NAI, Server NAI, Method-specific Session Discrimnator, NAS NAI,
		 something-specific discriminator>

Or at least that is how I think of the naming.

-- Jesse