Subject: [eap] Some ideas for keying framework

From: <[email-masked]>
Date: Thu, 14 Aug 2003 15:39:32 +0300

Hi,

EAP and 802.11i has been compared with IKE Phase 1 and 2,
and this lead me to think that maybe a comparing it to a 
protocol that actually has three parties could add some 
value... 

So, here's my attempt to interpret the combination of EAP 
(with Archie-like shared-secret based EAP method), 802.11i, 
and Diameter EAP as a Kerberos-like three-party protocol.
The message sequence below shows a typical exchange, with
each message described using ideas from Kerberos. 

Surprisingly, the two match quite well, and the parts that don't
match illustrate the (already known) weak parts.  Also, the 
interpretation seems to suggest that some parts don't actually 
provide much additional security.

The general idea is to think that the AAA server combines the
functionality of the Kerberos Authentication Service (AS) and 
Ticket Granting Service (TGS). Below there is no separate Ticket 
Granting Ticket (TGT); an EAP method that stores something for
fast reauthentication might be considered similar to TGT.
For a basic shared-secret protocol presented below that isn't
necessary (it probably wouldn't reduce roundtrips).

(Notation: C=Client, S=AAA server, and W=WLAN access point.

0:  C-->S: Hello! 
           
           (This is transmitted as 802.11 association request and 
           Diameter EAP-Start. Since the NAS does not really 
           do anything except route these messages, I'm leaving
           protocol layers and fields used only for routing 
           (802 stuff and Diameter) out. After all, we don't 
           usually show IP routers and Ethernet headers when 
           describing Kerberos either.)
           
1:  C<--S: Hello. Who are you?

           (EAP Identity Request.)

2:  C-->S: I'm C="[email-masked]"

           (EAP Identity Response.)

3:  C<--S: Prove that you know the shared secret (K_S-C). 

           (This corresponds to some Archie-like EAP method based
           on a shared secret. The details of the EAP method  
           are not important for this exercise. I'm assuming
           the EAP method is "good enough" so that an attacker
           who does not know K_S-C can't modify these messages
           without detection, or replay them later.) 

4:  C-->S: Here's proof. Could you prove that you know K_S-C too?

5:  C<--S: Here's my proof.

6:  C-->S: Ok, I'm convinced that you really are the AAA server.
           Could you give me a ticket for accessing WLAN AP
           W="11:22:33:44:55:66"? My MAC address is 
           C'="99.88:77:66:55:44". Actually, send the ticket 
           directly to W so I don't have to.

           (This is nothing else than the "binding" field in EAP Archie,
           though in Archie this is already in message #4.) 

7:  C<--S: Ok, I have sent the ticket. You can calculate the 
           session key from our shared secret and the messages 
           exchanged here. 

           (This is just an unusual way of considering the
           EAP Success packet)

8:  S-->W: Here's a ticket for you. The ticket contains:
           - C in User-Name AVP
           - W implicitly in earlier message's Called-Station-Id AVP
           - C' implicitly in earlier message's Calling-Station-Id AVP
           - W' in Destination-Host AVP
           - session key (MSK)
           - expiration time in Authorization-Lifetime AVP

           (This corresponds to Access-Accept or successful 
           Diameter-EAP-Answer message. I'm assuming the access 
           point and AAA server communicate directly, without
           any Diameter proxies.

           The ticket is encrypted and integrity protected with 
           K_S-W', where W'="ap1234.example.com", using TLS or 
           IPsec. More about this below. 

           In Kerberos, the ticket would contain only C and W--the 
           optional "caddr" field does not provide any security
           against attackers who control all network links. Also,
           the validity start time is not needed because ticket
           replay is prevented by other means.)

9:  C<--W: Hi C', this is W. I got your ticket. 
           I support these ciphers: (list)

           (This corresponds to beacon message and 1st message
           of four-way handshake. I'm assuming that this and
           the next two messages contain appropriate protection  
           so that an attacker who does not know MSK/PMK can't
           modify them without detection, or replay them later.)

10: C-->W: I'd like to use (selected cipher).

11: C<--W: Ok. Reset replay protection counters and derive 
           a fresh encryption/MAC keys using PMK and various
           nonces from these messages.

12: C-->W: Ok.

In Kerberos, C==C' and W==W'. After some handshake maybe a bit 
like 9..12 (perhaps not even needed if ciphers are not negotiated), 
W can know that 

  - Data MAC'd with these keys came from C.
  - When sending data to C, only C can read (decrypt) it

(And vice versa for C.)

The crucial difference in EAP/802.11i/Diameter case seems to be 
that C != C' and W != W'. IEEE 802.11i-D5 says something related
to this: "The protocol [4-way handshake] also assumes that the 
AS delivers the correct PMK to the AP with IEEE 802 address AA, 
and that the non-AP STA with IEEE 802 address AP hosts the 
Supplicant that negotiated the PMK with the AS." 

It continues that "None of the protocols defined by IEEE 802.11 and
IEEE 802.1X permit the AS, the Authenticator, the Supplicant, or
either STA to verify these assumptions." I guess the assumption here
is that these would be handled by EAP and Diameter/RADIUS, but
it seems that this is not usually the case!

When sending the encrypted ticket (message #8), a Kerberos server
would look up the key based on W. Here, W' simply claims that "I'm
actually W too" (in Diameter-EAP-Request), and the server believes
whatever W' says. Similarly, in message #6, C says that "I'm actually
C' too", and the server believes whatever C says.

Thus, it seems that an honest access point W can know that:

  - Data MAC'd with these keys came from C.
  - When sending data to C', only C can read it
    (Unfortunately, we don't know that C and C' are 
    the same entity; C certainly claims so, but that is all.)

And an honest user C can know that:

  - Data MAC'd with these came from W'. 
    (But C does not even know who W' is. C knows that W' claims
    it's the same entity as W, and W' is a valid access
    point according to S.)
  - When sending data to W, only W' can decrypt it.

I guess my conclusions from this is that the current 
combination of EAP, 802.11i and Diameter/RADIUS does not 
provide the properties traditionally expected of protocols 
for setting up a secure channel between two parties.

It can protect against non-authenticated users, and it can
protect the integrity of volume-based charging.  However, it 
does not protect the integrity and confidentiality of user 
traffic from other authenticated users in the same WLAN. 
Also, a compromised access point can "hijack" traffic even 
when the user tries to access some non-compromised access 
point.

(BTW, a colleague more familiar with 802.11 and 3GPP said 
that this conclusion is nothing new and is widely known, 
at least in some circles. Even if it is, it's certainly
important to mention it in some security considerations!)

Another interesting point is that several parts of the 
protocols don't appear to provide any additional security, 
at least if we assume an attacker who controls all communication 
links.  For instance, the EAP messages are encrypted and 
integrity-protected between the NAS and the AAA server, 
but it seems that this is not necessary.

Similarly, it seems that the MAC address "binding" in EAP Archie 
does not prevent any attacks unless S can verify that W and W'
correspond to the same entity. It does allow more reliable
auditing at S, though, so tracing any attacks might be easier
(so having the "bindings" is better than not having them,
certainly).

Ok, I have to admit that many details are omitted here, and 
I'm not that familiar with Kerberos. The description intentionally 
ties the "three legs" together, since I don't think that any of 
them is actually totally independent of the others. For instance, 
Archie's "ticket request field" (called "binding" in Archie) 
certainly isn't totally "media independent".

Maybe this provides some ideas for the EAP keying framework
document? Or some as-yet-nonexistant document to document
the "system security considerations"?

Best regards,
Pasi
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Aug 2003 07:12:23 -0700 (PDT)

Thanks for your comments, Pasi.  I think that it is useful to go through
an EAP conversation step-by-step to understand the security properties.
Comments below.

> 0:  C-->S: Hello!

I think this would correspond to a non-EAP packet, such as the 802.1X
EAPOL-Start.  This packet is typically unprotected, because it is
lower-layer packet.

> 1:  C<--S: Hello. Who are you?

This is the first EAP-Request, typically an Identity, but could be the
first method packet.  This is unprotected because there is no key yet
negotiated between the parties, not just because this is EAP.

> 2:  C-->S: I'm C="[email-masked]"

This packet is also unprotected. Its function may be duplicated by
subsequent method packets (should a protected identity exchange be a
requirement?), in which case it is only used for routing and a forgery can
be subsequently detected.

>            directly to W so I don't have to.

In this particular method, a ticket is requested to a particular AP
port and is bound to a particular port on the peer, within EAP. The issue
that arises is if the peer wants to subsequently bypass EAP authentication
in a fast handoff to another AP.  Its ticket (and underlying
MSK/EMSK) should not be good to access another AP, since it has already
been bound to specific ports.  That is I think one of the arguments for
the "late binding" of the 4-way handshake.

>            session key from our shared secret and the messages

I think we've come to understand that the statement is more like:

"I have given you keying material (MSK, EMSK) and you will subsequently be
told how to use this material to construct the AAA-Key for this and
subsequent APs."

The 4-way handshake could include an algorithm negotiation
that could indicate a key name and algorithm used to calculate
the appropriate AAA-Key.  As an example, the default is
currently that the AAA-Key=MSK, but in fast-handoff that is not
necessarily the case. Again, I think we have a case of "late binding"
here.

> 8:  S-->W: Here's a ticket for you. The ticket contains:

Yes, I buy the idea that the AAA message is effectively a ticket, which is
why we call it the AAA-Token.  Note that the AAA-Key is not always the
MSK; the NAS/AP just takes it for granted, but it needs the key
name/algorithm to use in the subsequent secure association exchange in
order to make sure it is in sync with the peer.

>            - expiration time in Authorization-Lifetime AVP

Does it make a differernce that W and C' are implicit rather than
explicit?  I've wondered whether we shouldn't be including these in the
Accept packet.

The "expiration time" is the maximum time that the "ticket" can be cached,
no? Essentially I think we are saying that the keying material and the
authorizations expire at the same time.  However, this is somewhat
contradictory, since an "authorization only" exchange cannot refresh
keying material (since there is no re-authentication exchange to go with
it).  That's one reason why the Authorization-Lifetime AVP has never made
much sense to me.

 8.5  C-->W: Hi, I have the following list of keys I can use.

In 802.11i D5 the client includes a list of PMKIDs that the AP can select
from.  We also have been discussing whether the client needs to get a list
of algorithms before this so that it can winnow the potentially acceptable
PMKIDs.

> 9:  C<--W: Hi C', this is W. I got your ticket.

In D5 this message is also used by the AP to select a PMKID (and
algorithm?) to use in the exchange.

> Supplicant that negotiated the PMK with the AS."

As noted in RFC 3579, it is possible for the AS to do some checking of the
NAS-Identifier, and NAS-IP-Address. It can also check the
Called-Station-Id in the Access-Request against the known L2 addresses of
the NAS identified by the NAS Identification attributes.  However, it
cannot know whether the AP identified itself to the STA with the claimed
Called-Station-Id or whether it used another address in the BSSID instead,
unless it verifies this in the EAP exchange (as Archie does).
It also can't know if the AP is lying about the client Calling-Station-Id,
unless it verifies this within the EAP exchange (as Archie does).

These impersonation issues are discussed in RFC 3579, and are in the
keying framework doc to some extent as well.

> it seems that this is not usually the case!

As described in RFC 3579, AAA has limited capabilities of detecting
impersonation.  Some of this can be done in EAP as in Archie.

> C' too", and the server believes whatever C says.

The AS has the ability to check the W' - W binding and also the C' - C
binding if it wants to.  For example, it could only allow the user to
access the network from a particular Calling-Station-Id or could check the
Called-Station-Id against the NAS identification attributes.

>     the same entity; C certainly claims so, but that is all.)

One question is when the C - C' binding occurs. For example, can a STA
complete an EAP exchange on one port and then do a 4-way handshake on
another port using the keying material derived in the first exchange? This
would require "late binding".

> for setting up a secure channel between two parties.

I think that the issue here is the W-W' binding from C's point of view.
Wouldn't something like secure neighbor discovery (with an inverse option)
address this?

> traffic from other authenticated users in the same WLAN.

Yes, because the security is not end-to-end.

> when the user tries to access some non-compromised access

The compromised AP can masquerade as another AP by stealing its BSSID, for
example. It can then lie about the BSSID it is using by including a
different address in the Called-Station-Id. The AS will not be the wiser.

I think this implies that the architecture trusts the AP to a certain
extent, but we need to be very clear about exactly what that trust extends
to.

A compromised AP can do a lot of things.  For example, if several APs are
plugged into a hub, a compromised AP can actually see cleartext traffic
from other APs, equivalent to obtaining the sessions keys of all STAs
attached to those other APs!

> important to mention it in some security considerations!)

Yes, I would say so.  Text solicited ;)

> but it seems that this is not necessary.

Sure. EAP protection only adds value between the STA and NAS/AP.

> correspond to the same entity.

Maybe it could do this via secure neighbor discovery?

> It does allow more reliable

Yes.

> document?

Yes, I think it's very helpful for identifying areas which need more
explanation.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap