Subject: [eap] RE: Some ideas for keying framework

From: <[email-masked]>
Date: Fri, 15 Aug 2003 15:40:51 +0300

Bernard Aboba wrote:

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

Yes. I included this just to show that the protocol is 
actually initiated by the client. The EAPOL-Start is converted 
to a RADIUS/Diameter EAP-Start between the access point and S.

> > 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]"
> >
> >            (EAP Identity Response.)
> 
> 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.

I guess all mutually authenticating EAP methods have some 
mechanisms for protecting the identity exchange. After all, 
if after a successful authentication the user thinks he has 
authenticated as X and the server thinks the user is Y, 
the method doesn't provide much authentication.

Based on a quick look, at least EAP-TLS, Archie, EAP-SIM and
EAP-AKA seem to protect the identity being authenticated
(which is not necessarily the same as the contents of the
Identity Response). MSCHAPv2 doesn't protect the whole
identity, just the username part (not domain).

BTW, it seems that no EAP method currently protects the contents 
of the Identity Request; the assumption probably was that it 
doesn't contain anything important. Thus, if it includes
some data after a NUL, it could be modified by an attacker. 
I'm not sure if any of the data currently included counts 
as "important" or not, but it's worth keeping in mind...

> > 3:  C<--S: Prove that you know the shared secret (K_S-C).
> > 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.
> 
> 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.

I think that to protect against compromised NASes, the MAC
addresses have to be taken into account ("bound") in the 
AAA-Key(s) contained in the ticket(s) sent from AAA server to 
access point(s). Doing it in the 4-way handshake phase is 
probably too late.

EAP Archie does this by including the MAC addresses explicitly 
in the messages. Another possibility would be that when the AAA 
server sends the ticket(s), it calculates the key to be included 
as f(EMSK,AP_MAC,STA_MAC). The proactive key distribution proposal 
by Mishra et al. did something like this, if I recall correctly.

BTW, it just occured to me that actually the MAC addresses 
(C' and W) are always sent in this message, even in EAP methods
other than Archie (they're in the EAPOL headers and Diameter
AVPs). Archie is just the only one that includes them when
calculating the MACs!

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

Is any subsequent information actually necessary? If the 
PMK is derived e.g. as f(EMSK,AP_MAC,STA_MAC), the client 
already has all the necessary information to construct it 
for any access point.

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

I think the implicit inclusion works here. If we choose to do 
proactive key distribution (initiated by the AAA server),
then that message has to include them explicitly.

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

I checked what the specs actually say about Authorization-Lifetime 
and Session-Timeout, and I think that the Base text makes sense.
But the text in NASREQ is confusing and contradicts Base
in some cases. (I'll send something about this to the AAA list
in a separate message; in the following I'll assume Base is 
correct, since it makes more sense.)

Deriving a new AAA-Key (==PMK in 802.11i) for an access point 
requires a new EAP conversation, right? (This may be a "fast" 
reauth if the EAP method supports it) This could be done 
with Authorization-Lifetime + Re-Auth-Request-Type set to
AUTHORIZE_AUTHENTICATE.

On the other hand, re-checking the authorization ("is this 
user's account still ok?") makes sense without deriving 
a new key. This could be done with Authorization-Lifetime 
AVP + Re-Auth-Request-Type AVP set to AUTHORIZE_ONLY.

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

Thanks for pointing out this change. I hadn't noticed it because 
it's not included in Section 8.5.3.1 (which says Key Data field 
of the first msesage is always empty, contradicting the text 
in Section 8.5.2). 

(BTW, I think it should be called something else than KEYID,
because it's too easy to confuse that with the "Key ID" field
in the same message, which is something completely different.)

Otherwise the change seems OK. In effect, the PMKIDs are 
"ticket identifiers"; in Kerberos, they would not be needed 
because the client sends the ticket to the server, so it knows 
what ticket it has sent (if it has several).

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

Should these "bindings" be included in all EAP methods, not 
just Archie? (Or since the data is actually sent in all EAP
methods, I guess the correct question is that should they
by protected with a MAC/whatever in all EAP methods?)

(BTW, are the MAC addresses enough, or should we also 
include SSID?)
 
> > 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!
> 
> As described in RFC 3579, AAA has limited capabilities of detecting
> impersonation.  Some of this can be done in EAP as in Archie.
> 
> > 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.
> 
> 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.

Yes, it could do this. If it does this, and the MAC addresses are 
also included in deriving the keys contained in tickets (either 
explicitly as in Archie, or implicitly as PMK=f(EMSK,MACs) or 
something), then we should get the traditional expected result 
of an authentication protocol with a trusted third party.

(Roughly speaking, if two honest parties C and W attempt to 
communicate, then an attacker can't do anything worse than DoS 
unless he compromises S. Compromise of any other parties C2,C3,...,
W2,W3,... doesn't change this. Well, actually in 802.11i this 
would be "compromise of any other W2,W3,..." that are not 
in the same Distribution System, i.e. Ethernet segment.)".

But if the check is not done (seems quite likely), or the 
addresses are not included in MACs or key derivation (all 
current EAP methods except Archie), then the bets are off. 
Since this is likely to be the case, maybe it should be 
described separately somewhere... 

<snip>

> 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?

Secure neighbor discovery can prove that you're allowed to use 
some particular IPv6 address, but it can't do the inverse: 
prove that you're allowed to use some particular MAC address.

I don't see any feasible way how this could be done... 
(except by getting rid of permanent globally unique MAC 
addresses, but that would be a radical change to all 802.* 
stuff).

<snip>

> > 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.
> 
> Yes, because the security is not end-to-end.

Well, end-to-end is not the whole truth... if we would have 
C=C' and W=W', it would protect against other authenticated
users in the same WLAN (but not the access point). This would 
be especially useful if combined with something like Secure
Neighbor Discovery.

<snip>
> > (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!)
> 
> Yes, I would say so.  Text solicited ;)

I'll see if I can come up with something, but I'm not promising 
anything; a "Security considerations for 802.11i wireless LAN 
authentication" sounds like a huge document :)

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Aug 2003 07:25:26 -0700 (PDT)

> to a RADIUS/Diameter EAP-Start between the access point and S.

Good point. We might want to mention in RFC 2284bis that while EAP itself
is initiated by the authenticator, that the exchange can be kick-started
by the lower layer.

> the method doesn't provide much authentication.

Yes.

> identity, just the username part (not domain).

Maybe we should add "Method-specific Identity" as a disclosure
requirement for EAP methods?

> as "important" or not, but it's worth keeping in mind...

We should probably add some text about that.

> access point(s). Doing it in the 4-way handshake phase is

I think this only protects against some types of compromise.  For example,
a NAS could lie about its NAS-Identifier, NAS-IPv6-Address or
NAS-IP-address, impersonating another NAS.  It can also lie about the
Called-Station-Id and Calling-Station-Id.

The AAA server/proxy can check the NAS-Identifier, NAS-IPv6-Address and
NAS-IP-Address against the source IP address, and it could also check the
Called-Station-Id against a table of NAS/Called-Station-Id mappings.  It
could also check the User-Name/Calling-Station-Id binding but in most
cases that isn't worth the effort because users can change their NIC or
home phone number.

Binding these parameters in the AAA-Token doesn't really do
much to improve security if the destination is the same NAS that is lying.
Binding the parameters in a message sent to the *peer* would help
because then the peer could compare the parameters to those that the NAS
is claiming.

> by Mishra et al. did something like this, if I recall correctly.

Yes.  This "binds" the parameters in a way that guarantees that the AP
cannot lie or communication will not occur, since the keys won't match.
Really, the above formula is f(EMSK, Called-Station-Id,
Calling-Station-Id), where the Called-Station-Id and Calling-Station-Id
are the parameters provided by the NAS.

In many ways, I like this scheme because it does not require anything
special in the EAP method itself, but if it is only used for
fast-handoff, it would seem that there is a gap.  For example, one could
conceive of the AAA-Key being calculated as f(MSK, Called-Station-Id,
Calling-Station-Id) in the non-fast-handoff case as well, which would fix
the problem generally.

> AVPs). Archie is just the only one that includes them when

Ah. So you're suggesting that a AAA server could calculate a
method-specific MAC based on a "pseudo header" comprised of
parameters obtained from the NAS, such as Called-Station-Id and
Calling-Station-Id?

This would certainly work but would only "fix" those EAP methods that
incorporated it.

> already has all the necessary information to construct it

The problem is that there may be multiple active EAP SAs that could
have generated the EMSK used in the above formula.

> then that message has to include them explicitly.

Yes, that is definitely true, and we should discuss this somewhere.

> correct, since it makes more sense.)

Thanks.

> with Authorization-Lifetime + Re-Auth-Request-Type set to

Yes. Actually the PMK is just the first 32 octets of the AAA-Key.

> AVP + Re-Auth-Request-Type AVP set to AUTHORIZE_ONLY.

OK.  Is there a way of requesting another 4-way handshake without a
re-authentication?

> what ticket it has sent (if it has several).

Yes.  I think the issue occurs where there might be multiple algorithms in
use for calculating the keys;  in that case the client might have to
calculate potential keys from multiple EAP SAs using multiple algorithms.

> (BTW, are the MAC addresses enough, or should we also

I think it is a question of changing methods (many of which are already
shpping) versus changing the lower layer implementation (which is in the
process of being standardized).  If the "bindings" are implicit within the
key calculation, then it is possible to solve the problem without
requiring methods to do anything.

> of an authentication protocol with a trusted third party.

Yes, this is nice -- and brings up the question whether AAA-Key=f(MSK,
Called-Station-Id, Calling-Station-Id) wouldn't make sense as well.

> described separately somewhere...

Yes.