Subject: [eap] RE: EAP key naming

From: [email-masked] ([email-masked])
Date: Thu, 10 Jul 2003 18:42:31 +0300

Hi,

I'm not sure if Russ actually intended his slides to be=20
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=20
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=20
peer and AP. (The four-way handshake includes the MAC
addresses, but it does not authenticate them--since both=20
parties can freely put whatever they want as their own address).

Suppose for a moment that the peer knows the MAC address of=20
the AP it wants to connect to.  Currently any other AP can
simply change its MAC address to this; the EAP conversation will=20
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=20
key (just comparing it with Called-Station-Id doesn't work).=20
If APs use e.g. Diameter-over-TLS to talk to the server,=20
the AP's MAC address could be maybe included in the=20
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=20
(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=20
starts to use a key known to the attacker for encrypting traffic=20
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=20
as "[email-masked]", the responder will certainly _not_ set up=20
an SA that says "encrypt all traffic to 1.2.3.4 with this key".  =20
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=20
gateway", it assigns a new IP address to the client (often=20
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 :-)=20

(Unfortunately I'll miss that one, since it's on Thursday...
but if somebody's interested in a having "bar BOF" about=20
this Saturday..Tuesday, count me in!)

Best regards,
Pasi

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: Thursday, July 10, 2003 2:42 PM
> To: Joseph Salowey
> Cc: 'Walker, Jesse'; [email-masked]
> Subject: RE: [eap] EAP key naming
>=20
>=20
> > >In the case of 802.11, what is important is the right key
> > gets delivered to the right AP, and never to any other party
> > whatsoever. Vis-a-vis the binding discussion, this translates
> > into a requirement for the EAP Server to be able assert that
> > the key is bound to the pair <STA MAC Address, AP MAC
> > Address>, because that is the only meaningful key identifier
> > at the MAC layer.
>=20
> I'm not clear that the MSK is bound to the Calling-Station-Id. As
> we discussed previously, the MSK name is based on the <Peer=20
> name, AS name, NAS Name> tuple. That implies that the MSK is=20
> bound to the Peer, not to a particular interface.  The question=20
> is whether a peer with multiple 802.11 interfaces could use=20
> an MSK derived through one interface on another interface.=20
> Intrinsically, I don't see anything wrong with this, although
> it does seem to imply that we have "late binding" -- the TSKs=20
> are bound to the pair <Calling-Station-Id, Called-Station-Id>=20
> but the the MSK is not.
>

<rest of original message deleted>

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 10 Jul 2003 09:41:18 -0700 (PDT)

> Authentication between peer<->server

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.  For this to work there has to be a binding
between the Phase 2 SA and the Phase 1 (EAP) SA.

> accomplish this, by authenticating the MAC addresses of the
> peer and AP.

Key naming and authentication are orthogonal issues.

> (The four-way handshake includes the MAC
> addresses, but it does not authenticate them--since both

In effect, Phase 2 "binds" the TSKs to the Called-Station-Id and
Calling-Station-Id. If an EAP SA is named by the peer name and EAP server
name as well as the nonces, then it is not bound to an L2 address -- and
in fact the same EAP SA could be used on multiple interfaces.
The MSK name is the EAP SA name + the  NAS Address (L2, L3), since the
same MSK cannot be reused on multiple NASes.

The Phase 2 Exchange produces TSKs which are named by the
<Called-Station-Id, Calling-Station-Id, SAID> tuple.  As a result, Phase 2
is where the binding occurs, not EAP (Phase 1).

> Suppose for a moment that the peer knows the MAC address of
> simply change its MAC address to this; the EAP conversation will

Only an AP that is trusted by the AAA server can do this -- otherwise a
mutually authenticating EAP method would fail. The NAS can not only lie
about the Called-Station-Id, it can also lie about the NAS-IP-Address, the
NAS-Identifier and the Calling-Station-Id.  This is discussed in RFC
2869bis.

There are ways for AAA proxies or servers to check for a forged
NAS-Identifier or NAS-IP-Address, and at the same time they could check
for a forged Called-Station-Id (e.g. it has to correspond to a non-forged
NAS-Identifier or NAS-IP-Address).  The Calling-Station-Id is harder since
there is no way for the AAA server to verify that. Also, a NAS could
communicate with the EAP peer using a different L2 address than it puts
into the Called-Station-Id attribute sent to the AAA server.

> compromised or turns evil--it can't be done by a total

Yes. It's not totally out of the realm of possibility for a NAS to get a
virus, for example.

> the server can authenticate the AP's MAC when delivering the
> key (just comparing it with Called-Station-Id doesn't work).

Yes, because the NAS can tell the AAA server and EAP peer different
things.

> If APs use e.g. Diameter-over-TLS to talk to the server,
> the AP's MAC address could be maybe included in the

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

> with the desired MAC address.

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

> for instance, but I don't think this is likely?).

I don't think there's anything that can prevent an EAP peer from changing
their L2 address. Similarly, there's nothing that prevents an IKE
Initiator from stealing another hosts's IP address, and initiating an IKE
exchange using it.  The only question is what the various keys are bound
to and whether changing the L2 address invalidates the binding.

> key to use (and "route" the packets).

Actually, I think the identities are different during each phase. In EAP
(Phase 1), the relevant identities are those of the EAP peer and EAP
server.  Since EAP SAs aren't bound to L2 addresses, those aren't
relevant. The MSK is bound to the EAP SA and NAS name, and it would appear
that the Called-Station-Id is the only reliable surrogate for the NAS
name. I think that the EMSK name is the EAP SA name + an additional
identifier ("EMSK"?).

Then the TSKs are bound to the <Called-Station-Id, Calling-Station-Id>
tuple in the exchange "proving possession"  of the MSK.

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

> 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".

Actually, quite a few implementations will do this.

> iPAddress subjectAltName).

In practice, the IPAddress is not placed in the subjectAltName; that is
where [email-masked] goes.  This issue does arise more seriously in MIPv6
where there is a need to bind the Home Address to the IKE
Identity-Payload.