Subject: [eap] EAP key naming

From: [email-masked] (Walker, Jesse)
Date: Thu, 10 Jul 2003 08:47:54 -0700

Bob

> Here is what I am working up as the key name:
> 
> KeyID = Truncate-128(SHA1(NAI || EAP Method Type || Key || 
> Called-Station-Id || Calling-Station-Id || "The name is the game"))
>
> And for 'Key' you can substitute:
> 
> MK
> MSK
> EMSK
> PMK
> 
> Not all of these may need Ids, but the option should be there.

I wonder whether the naming scheme should reflect the hierarchy. Bernard has already objected to insertion of the key into the naming scheme. Also, Bernard's original note indicated a desire to have the naming hierarchy explicitly visible, presumably so that the key names are intelligible to the poor souls who have to trouble-shoot problems in the network. On the other hand, a lot of protocols (like 802.11i) could really use "more efficient" names, so having both human readable key names and machine manipulatable key ids might be better. Something like

	MK Name = Peer NAI | Server NAI | EAP Method | Session Discriminator

	MKID = Truncate-128(SHA1(MK Name))

	EMSK Name = MK Name | 0x00

	EMSKID = Truncate-128(SHA1(EMSKID))

	MSK Name = MK Name | NAS NAI

	MSKID = Truncate-128(SHA1(MSK Name))

	etc.

would seem to better meet these constraints.

> Which NAI?  The method 'knows' and should provide that going 
> outward.  E.G. 
> PEAP/MSCHAPv2, it is the NAI in the MSCHAPv2 part.

I think the naming scheme should include the names of any relevent parties.

> Which EAP Method Type?  What would you use for PEAP/MSCHAPv2 
> compared to 
> PEAP/TLS?  I don't have the answer to that one.

The "right" answer is probably some standard encoding of the registered EAP method identifier.

---

From: [email-masked] (Walker, Jesse)
Date: Thu, 10 Jul 2003 13:56:02 -0700

Pasi,

Nice analysis. I have some comments at the end.

> I'm not sure if Russ actually intended his slides to be 
> used as a "checklist" (especially since it's not at all
> obvious what some of the items mean), but at least
> the list seems bring up some rather interesting 
> problems--here are my 0.02 euros on this :-)
> 
> I haven't completely grasped this "key naming" issue yet,
> but I think it might be related to the "authenticate
> all parties" item?  Authentication between peer<->server
> and AP<->server is well understood (some EAP method,
> and e.g. TLS when using Diameter), but the "third leg"
> between peer and AP seems to be quite different.
> 
> So, I was thinking that actually the "key naming" tries to
> accomplish this, by authenticating the MAC addresses of the 
> peer and AP. (The four-way handshake includes the MAC
> addresses, but it does not authenticate them--since both 
> parties can freely put whatever they want as their own address).
> 
> 
> 
> Suppose for a moment that the peer knows the MAC address of 
> the AP it wants to connect to.  Currently any other AP can
> simply change its MAC address to this; the EAP conversation will 
> work just fine, and this rogue AP will get the MSK from the server.
> (Note that this basically requires that an authorized AP is
> compromised or turns evil--it can't be done by a total
> outsider).
> 
> Jesse Walker's idea of including the AP's MAC address inside the
> EAP method (as done in EAP-Archie) seems to prevent this _if_
> the server can authenticate the AP's MAC when delivering the 
> key (just comparing it with Called-Station-Id doesn't work). 
> If APs use e.g. Diameter-over-TLS to talk to the server, 
> the AP's MAC address could be maybe included in the 
> certificate or something.
> 
> When the AP now proves that it knows the PMK in the four-way
> handshake, the peer knows that it is really talking to AP
> with the desired MAC address. So, it would be correct to
> say that the AP has authenticated this identity to the peer 
> (with help from a third party trusted by both of them).
> 
> 
> 
> This doesn't give us authentication of the peer MAC address to
> the AP yet. A valid peer can change the WLAN card's address
> to VICTIM_MAC, authenticate as usual, and after a while, the AP 
> starts to use a key known to the attacker for encrypting traffic 
> to VICTIM_MAC.
> 
> Including the peer's MAC address inside the EAP method, and
> comparing this with Calling-Station-Id doesn't help here.  The
> server would need to know which user has which MAC address.
> This might be difficult (it could be included in a certificate,
> for instance, but I don't think this is likely?).
> 
> I think that one difficulty here is that the identities that are
> currently authenticated are not the ones used to select which
> key to use (and "route" the packets). It seems that there might
> a similar issue present at one layer above; maybe this would
> give some insight? (or then again, maybe not--I'm not
> quite sure on this)
> 
> Suppose that a client with IP 1.2.3.4 uses IKE to connect to
> some other host, and authenticates itself with a certificate
> (this might involve some back-end authentication server, but
> it's not visible to the client). If the client authenticates 
> as "[email-masked]", the responder will certainly _not_ set up 
> an SA that says "encrypt all traffic to 1.2.3.4 with this key".   
> It will require either a local database that says "[email-masked]
> has IP 1.2.3.4" or a certificate that contains 1.2.3.4 (an
> iPAddress subjectAltName). Or, in the case of "road warrior 
> gateway", it assigns a new IP address to the client (often 
> needed for sane routing anyway).
> 
> 
> 
> Thus, to meet all of Russ's requirements, we would need to
> authenticate the MAC addresses or assign new MAC addresses
> after authentication? Oh <deleted>, this does not look
> good... at least there'll be an interesting discussion
> in Vienna :-) 
> 
> (Unfortunately I'll miss that one, since it's on Thursday...
> but if somebody's interested in a having "bar BOF" about 
> this Saturday..Tuesday, count me in!)

The requirements for a solution are the EAP Server must attest to the proper binding of the MSK to both the EAP Peer and the NAS. This cannot be solved exclusively within EAP, because EAP does not require the NAS to understand any of the contents of the messages exchanged.

The EAP server needs to craft messages

	Server -> NAS:	Attest to the binding <Peer-ID, NAS-ID, MSK-ID>

	Server -> Peer:	Attest to the binding <Peer-ID, NAS-ID, MSK-ID>

where Peer-ID and NAS-ID are identifiers from the "right" address family (802 MAC addresses in your example), and MSK-ID identifies the MSK distributed to the NAS to protect this <Peer, NAS> session. Attest means that the Server is guaranteeing that this binding is correct, so Peer-ID and NAS-ID can be used as identifiers to mutually authenticate using the MSK.

In this protocol, the EAP Server would use the MK (or some key derived from the MK) it established with the EAP Peer to form a MIC of the information returned. The EAP Server would presumably establish an analogous MK with the NAS when the two establish contact after rebooting, and the EAP Server would use this MK (or rather an authentication and a key encryption key derived from it) to protect the binding and to distribute the MSK to  the NAS.

This kind of mechansim solves the problem you discuss; it could be used, for example, to turn the 802.11i 4-way handshake into a genuine authentication instead of just key proof-of-possession. In this case, the mobile STA is the EAP Peer, and it "authenticates" the identity NAS-ID, which is the AP's BSSID; similarly, the AP becomes the NAS, and it "authenticates" the STA's MAC address, which is the right Peer-ID value. The reason why this is authentication instead of mere key confirmation is the EAP Server has authoritatively told both the AP and the mobile STA that the BSSID and STA MAC address are the entity identifiers bound to the MSK.

Presumably the new message to the Peer would be in an EAP message, and this EAP message would be forwarded to the NAS in the same message that returns the attestation to the NAS (e.g., as a new TLV in the same RADIUS Access-Challenge returning the new EAP message).

There are at least two ways by which the EAP Server could obtain the correct binding information.

1. For each device, the EAP server can maintain the pairing <Device NAI, Device-ID> in its database. This is not very flexible and requires configuration, but it would certainly be the simplest solution in terms of protocol.

2. We could invent an Otway-Rees or 3PKD style protocol by which the EAP Peer and the NAS report whom they think they are conversing with:

	1. Peer -> NAS:	EAP-Response(Peer NAI, NAS NAI, Peer-ID, NAS-ID)

	2. NAS -> Server:	EAP-Response(Peer NAI, NAS NAI, Peer-ID, NAS-ID),
					Peer NAI, NAS NAI, Peer-ID, NAS-ID

	...
	Server checks:	EAP-Response IDs match those from NAS' part of the message

	3. Server -> NAS:	EAP-Request(Peer-ID, NAS-ID, MSK-ID, MIC1),
					Peer-ID, NAS-ID, MSK-ID, E-MSK, MIC2

	NAS checks:		Peer-ID and NAS-ID received from Server were in request
				MIC2 is valid

	4. NAS -> Peer:	EAP-Request(Peer-ID, NAS-ID, MSK-ID, MIC1)
	Peer checks:	Peer-ID in EAP-Request match identifers in EAP-Response
				MIC1 is valid

Here MIC1 is a message authentication code protecting Peer-ID, NAS-ID, and MSK-ID, computed using MK (or some key derived from it). MIC2 is a message authentication code protecting Peer-ID, NAS-ID, MSK-ID, and E-MSK. E-MSK denotes the encrypted MSK. We would need to identify the key used to protect the parameters meant for the NAS in message 3.

This approach permits the parties to specify the identifiers they happen to be using during this instance of the EAP method, so does not require as much configuration and is more flexible. This does not work unless both the NAS and the Peer check that the EAP Server attests to the values they suggested, and the EAP Server checks that both the NAS and the Peer have requested the same identifiers.

A full protocol definition obviously requires further refinement (e.g., binding the EAP messages between the Server and Peer to the AAA messages between the NAS and Server), but I think there is enough here to indicate that a solution ought to be with reach. If we agreed on such an approach, much of it is outside the scope of EAP; we might have to define a chained EAP binding procedure as Joe has suggested, and we would need to define additional messages in, e.g., the AAA EAP application; the EAP key document might be an appropriate place to document how all the pieces get glued together.

-- Jesse

---

From: [email-masked] ([email-masked])
Date: Fri, 11 Jul 2003 16:33:53 +0300

Jesse,

Thanks for your response! I'm beginning to get the feeling
that we have actually several different problems we are
trying to solve, and maybe not all of them can be solved
easily...

> The requirements for a solution are the EAP Server must=20
> attest to the proper binding of the MSK to both the EAP Peer=20
> and the NAS.=20

Yes, but I think this is not the same as binding the MSK to=20
their MAC addresses!=20

In both of the attacks in my previous e-mail, both the peer and
the access point will have the same (peer_mac,ap_mac,msk)
triplet.  The problem was that this triplet was in "wrong" access
point (in the first case; the AP was malicious) or "wrong" peer
node (in the second case; the peer was malicious).

This happens because a compromised AP can freely choose the value=20
of ap_mac (including a value "belonging" to someone else), and=20
likewise the peer can choose peer_mac freely.

> 1. For each device, the EAP server can maintain the pairing <Device
> NAI, Device-ID> in its database. This is not very flexible and
> requires configuration, but it would certainly be the simplest
> solution in terms of protocol.

I agree, this would solve the problem presented above, but it's
probably not feasible in terms of configuration.

> 2. We could invent an Otway-Rees or 3PKD style protocol by which=20
> the EAP Peer and the NAS report whom they think they are=20
> conversing with:
>=20
> Server checks: EAP-Response IDs match those from NAS' part of the=20
> message
>

I think this protocol is roughly what the current EAP-Archie
protocol combined with Diameter-EAP-over-TLS (or RADIUS-over-IPsec)
does already? For instance, Peer-ID and NAS-ID are transmitted in=20
RADIUS/Diameter Calling-Station-Id and Called-Station-Id attributes,=20
and so on.

The only thing missing from the current protocol is the NAS NAI
(which is sort of strange anyway; NAIs identify users, not
devices--and how the peer knows what the NAS NAI is, when
sending the first message?)

But as you pointed out, the peer and NAS can freely choose
the values of Peer-ID and NAS-ID--so this protocol does
not solve the "problem" presented above.  The protocol
does "make sense", though--so maybe there is more than
one problem to be solved, and this solves something else?

(I need some time to think this through--especially the word
"binding" seems to be quite dangerous, since it's sometimes
difficult to see what attacks would be possible if such=20
"binding" was not present).

Best regards,
Pasi

---

From: [email-masked] ([email-masked])
Date: Fri, 11 Jul 2003 17:21:52 +0300

Hi Bernard,

Thanks for your comments; see my replies inline.

> I think of the "third leg" of the exchange as having many of
> the same properties as IKEv1 phase 2 -- it provides secure
> negotiation of the security parameters, including ciphersuite
> and modes (if relevant), provides freshness for transient
> session keys, proves possession of the keying material derived
> in Phase 1 (EAP), handles key activation/deletion/re-key. =20
> For this to work there has to be a binding between the Phase=20
> 2 SA and the Phase 1 (EAP) SA.

There are many similarities, but the "third leg" is not exactly
IKEv1 phase 2 either... in IKEv1, there are only two parties,=20
and many of the complexity here comes from having three (or=20
more) parties, and having to deal with the case where some
trusted parties might be malicious.

(If we can assume that all trusted APs and home servers are
indeed trustworthy, then this whole issue becomes rather
trivial--we need to consider only the interface between
the peer and "the network".)

<snip>
> I think this doesn't help much because the AAA server can check=20
> the Called-Station-Id anyway, and the threat you outlined is=20
> about the NAS lying to the EAP peer.

Well, presumably the AAA server would then have a database of=20
<NAS-name-in-certificate,MAC address> pairs, and having
this information in the certificate accomplish the same goal..

> > with the desired MAC address.
>=20
> Not really. The AP can tell the AAA server and EAP peer different=20
> MAC addresses, and the 4-way handshake works just fine.

It can in most existing EAP methods, but not if the peer
includes the NAS MAC address inside the EAP messages=20
(like EAP-Archie does), right?

> I don't think there's anything that can prevent an EAP peer=20
> from changing their L2 address. Similarly, there's nothing that=20
> prevents an IKE Initiator from stealing another hosts's IP address,=20
> and initiating an IKE exchange using it.

You're quite right in that nothing prevents someone from=20
stealing an IP address and initiating an IKE exchange (and from
successfully completing phase 1). But the attacker still can't=20
set up a "phase 2" SA for that stolen IP address (unless the=20
responder's IKE policy is seriously misconfigured--you seem to=20
suggest below that this would actually be a common configuration?)

<snip>
> Actually, I think the identities are different during each=20
> phase. In EAP (Phase 1), the relevant identities are those of the=20
> EAP peer and EAP server. Since EAP SAs aren't bound to L2 addresses,=20
> those aren't relevant.=20

Actually, in EAP-Archie, the EAP SA is bound to the L2 addresses--but
it isn't a problem, because the EAP SA isn't long-lived (it's
destroyed immediately after sending the EAP Success message).

(BTW, what does "naming" the EAP SA accomplish for methods that=20
don't store any state for "fast reconnect" or similar?)

<snip>
> Given all of this, I'm not sure exactly what it means to=20
> "authenticate" the <Called-Station-Id, Calling-Station-Id> tuple.=20
> Are we trying to prove that an EAP peer or NAS has the right to that=20
> MAC address?  This would require some sort of certification from an=20
> authority (the IEEE), which seems somewhat impractical. Plus one of=20
> the major advantages of EAP is that the entities do *not* need to=20
> identified via their L2 addresses, which is an administrative =
headache.

Yes, I was sort of trying to prove the right to that MAC address.
In this case it does not require certificates from IEEE, though:
certificates from the home server (trusted by both users and
NASes) is enough. I agree that this is not practical from
administrative point of view, at least for users (it might be
almost possible for NASes).

<snip>
> Actually, quite a few implementations will do this.

Hmm, do they? In what kind of circumstances would this make sense?=20
(I'm not exactly an IPsec expert...)
=20
> > iPAddress subjectAltName).
>=20
> In practice, the IPAddress is not placed in the subjectAltName;=20
> that is where [email-masked] goes.  This issue does arise more=20
> seriously in MIPv6 where there is a need to bind the Home Address=20
> to the IKE Identity-Payload.

Well, the certificate might have two subjectAltNames, one for
IPAddress and another for [email-masked]. Or can IP addresses
appear in the Subject field (or is it always a Distinguished
Name)?

Best regards,
Pasi

---

From: [email-masked] (Walker, Jesse)
Date: Fri, 11 Jul 2003 08:57:11 -0700

Pasi,

> > The requirements for a solution are the EAP Server must 
> > attest to the proper binding of the MSK to both the EAP Peer 
> > and the NAS. 
> 
> Yes, but I think this is not the same as binding the MSK to 
> their MAC addresses! 
> 

I am not sure the assurance you want is entirely feasible, unless the EAP server knows all of the aliases that will be used by all of the systems, both EAP Peers and NASes, and also knows a priori which alias will map to which NAI.

There seem to be two ways to think about this problem. Either this information can be configured, or each system, when it makes initial contact with the EAP server, registers the aliases it intends to use, and the server maintaining the registration database that the EAP Server consults is responsible for checking that none of the aliases are already registered to another system. In cases like MAC addresses, the latter is normally a benign requirement, because a MAC address ought not change in ordinary operation. In the case of a more dynamic alias, such as an IP address, it is not clear how to make this work.

-- Jesse

---

From: [email-masked] ([email-masked])
Date: Fri, 11 Jul 2003 19:36:56 +0300

Jesse Walker wrote:
> I am not sure the assurance you want is entirely feasible,=20
> unless the EAP server knows all of the aliases that will be=20
> used by all of the systems, both EAP Peers and NASes, and=20
> also knows a priori which alias will map to which NAI.

I think you're probably right in that this might not be=20
feasible--but this might also mean that satisfying all the=20
requirements of "ideal and perfect key exchange protocol" in=20
Russ's slides is not feasible! And I have a gut feeling that=20
the effects of this are not limited to just one of the=20
items listed there, but have wider consequences...

If this is indeed the case, I think we should work hard to identify=20
what exactly is feasible and what is not--and hopefully not try to=20
convince ourselves that the requirements are met (I fear this might=20
happen if we start adding some protocol features that are=20
so complex that we can't really tell if they work or not :-)

(I'm not saying that the "key names", "EAP SA names" and
"bindings" discussed here recently don't work--just that it=20
requires more work to see what they actually achieve. =20
And if it would turn out that, e.g., having "key names"=20
does not prevent any attacks or enable any new features,=20
well, then we at least understand the system much better.)

> There seem to be two ways to think about this problem. Either=20
> this information can be configured, or each system, when it=20
> makes initial contact with the EAP server, registers the=20
> aliases it intends to use, and the server maintaining the=20
> registration database that the EAP Server consults is=20
> responsible for checking that none of the aliases are already=20
> registered to another system. In cases like MAC addresses,=20
> the latter is normally a benign requirement, because a MAC=20
> address ought not change in ordinary operation. In the case=20
> of a more dynamic alias, such as an IP address, it is not=20
> clear how to make this work.

Hmm, requiring that the EAP server knows the MAC addresses
of all NASes might be almost feasible, but certainly this
does not apply to peers.  There is one possible way this might=20
work (similar to the one used in "road warrior" IPsec gateways):=20
assign a new MAC address after authentication.  But I guess
this would require non-trivial changes to 802.11...

(BTW, this could also help in solving some other problems with=20
globally unique and permanent MAC addresses: they have
privacy problems, and help attackers in targeting a particular
user's traffic. Henry Haverinen said that something like this=20
had actually been suggested at IEEE years ago, but rejected...)

-Pasi