Subject: [eap] Review: draft-puthenkulam-eap-binding-01.txt

From: [email-masked] ([email-masked])
Date: Mon, 3 Mar 2003 20:55:22 +0200 (EET)

Hi,

I have read the draft-puthenkulam-eap-binding-01.tx and I have a question.

Currently, the outer protocol is used for (1) server authentication and
(2) the session keys are derived on the basis of that protocol. Therefore,
the protocol is also called network authentication protocol.

On the other hand, the inner protocol is used to authenticate the client
to the server. However, several inner protocols generate keying
material (while some others do not). That keying material is currently not
used to protect the network traffic.

Why we wouldn't solve the case in the following way:

(1) The outer protocol should be used only for server authentication
    and to offer privacy for the client during authentication. The keying
    material produced by the outer protocol would not be used anymore for
    session protection.
(2) The session keys would be derived on the basis of the inner protocol.

The outer protocol would still have two roles. It is used for server
authentication and to guarantee privacy for the client during
authentication.

Unfortunately, all inner protocols do not generate keys. However, such
protocols are quite insecure from the man-in-the-middle attacks point of
view anyway. The main problem here is in attitudes. Can we use inner
authentication protocol for session keying? All in all, I think we are
then doing very much the same thing as with combound keys.

In some cases the client may not even want to know the actual identity
of the server. The client only requires privacy for authentication. In
such cases opportunistic server authentication can take place without
being worried about the session security.

Any opinions?

-- Jukka

Jukka Ylitalo                      Tel: +358 9 299 2622
NomadicLab, Ericsson Research      Fax: +358 9 299 3535
Oy L M Ericsson Ab                 Mobile: +358 400 615 821
FIN-02420 Jorvas, Finland          E-mail: [email-masked]

---

From: [email-masked] ([email-masked])
Date: Fri, 7 Mar 2003 12:09:46 +0200

See comments inline.

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: Friday, March 07, 2003 10:16 AM
> To: Eronen Pasi (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt
>=20
> [email-masked] wrote:
>=20
>> keys are weak, or MS-CHAPv2 keys are vulnerable to dictionary =
attacks,
>> if they are used together with the tunnel keys. Even if the tunneling
>> does not perform server authentication, the attacker would have to
>> break the "weak" keys in real-time, and also perform =
man-in-the-middle
>> attack for the EAP conversation. This is much more difficult than
>> simply recording some WLAN traffic and attacking it off-line.
>=20
> Could you break this down a bit? I see that dictionary attacks
> could be a problem. But then again, you don't actually have to
> *break* the method in-real time. You just have to act as a mitm
> long enough to see what the parties exchange, and *then* you
> go off-line to perform the dictionary attack. So what is added
> here is the need to be a mitm. But I don't see how this adds
> the need to do things in real-time.
>=20
> Secondly, isn't there a distinction between weak keys and
> dictionary attacks? In the dictionary attack case you acquire
> the permanent credentials and can afterwards freely use the
> victim's account. This is valuable, even if you'd have to spend
> some time off-line first. But the weak key case appears somewhat
> different. You still have to do the attack fast if your intention
> is to gain access; once the user logs out or re-authenticates
> the attack is no longer possible. Of course, if you succeed
> in breaking the keys, this might give you an ability to read
> the packets that were exchanged. However, it isn't clear to
> me if the four-way handshake in 802.11i would prevent these
> attacks. Does it do Diffie-Hellman?

You're right, I wasn't thinking clearly: there is an important
distinction between weak long-term secrets and weak sessions keys
produced by some methods. (In all cases, I'm assuming that the
conversation is protected by an anonymous tunnel which does not=20
do server authentication).

For weak long-term secrets,
- If the inner protocol derives session keys from the long-term secret
  without PFS (e.g. MS-CHAPv2), and we use only the inner protocol=20
  keys, even a passive attacker can mount a dictionary attack
  to get the long-term secret (he then also gets the session keys=20
  since there is no PFS).
- If combined keys are used, the attacker has to do a MitM attack
  on the tunnel (which is possible, since the tunnel is not =20
  authenticated), but can do the dictionary attack against
  the long-term secret off-line (however, he doesn't get the
  session keys for this session).

For strong long-term secrets but weak sessions keys,=20
- If we use only inner protocol keys, a passive attacker can do an
  off-line attack to get the session keys (but not the long-term =
secret).
- If we use combined keys, the attacker has to do a MiTM attack=20
  on the tunnel (again, possible) AND break the keys in real-time
  (difficult) to get the session keys.

The last case is relevant for e.g. EAP-SIM; the long-term Ki key can
be assumed to be strong, but the Kc keys are (kind of) weak if the
same SIM is also used for GSM. So, it seems that using combined keys=20
makes the attacker's work more difficult in all cases.

The four-way handshake in 802.11i basically binds the keys to MAC
addresses, and it does not do Diffie-Hellman (and so doesn't=20
provide PFS).

>> So, provided that the keys are combined properly, compound keys
>> from both inner and outer methods is probably the best choice.
>=20
> Ok. But are there any downsides to making the combination? Does
> it add a requirement to access generated master secrets from
> either the inner or outer method?

It requires access to some secret material from both inner
and outer methods.  But, in case of e.g. PEAP, it does not have=20
to be the TLS master secret; it could be output from the PRF=20
keyed with the master secret instead.

Best regards,
Pasi

---

From: [email-masked] ([email-masked])
Date: Fri, 7 Mar 2003 12:27:14 +0200

see comment inline

> Sent: 07 March, 2003 10:16
> > keys are weak, or MS-CHAPv2 keys are vulnerable to 
> dictionary attacks,
> > break the "weak" keys in real-time, and also perform 
> man-in-the-middle

As per IEEE802.11i Std. a 4 way key exchange handshake between AP and STA not only mutually authenticates one another but also validates the capabilities and ciphersuites - TKIP , AES etc. in a secure manner. Supporting mutual authentication with improved privacy algorithms like TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM attack.
 
Preeti

---

From: [email-masked] (Puthenkulam, Jose P)
Date: Fri, 7 Mar 2003 07:16:34 -0800

>As per IEEE802.11i Std. a 4 way key exchange handshake between AP and STA
>not only mutually authenticates one another but also validates the 
>capabilities and ciphersuites - TKIP , AES etc. in a secure manner. 
>Supporting mutual authentication with improved privacy algorithms like 
>TKIP (IV with 48bit to reduce rekeying) AES in AP can prevent MitM 
>attack.
I'm not sure this is true. As the Mitm attack we are talking about is
performed before the 802.11i layer gets keys, though it determines what keys
it gets. So I don't see how the attack can be prevented by 802.11i. However
I do agree that one may not be able to perform a Mitm attack at the link
layer due to the reasons you describe.

best regards,
jose

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, March 07, 2003 2:27 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [eap] RE: Review: draft-puthenkulam-eap-binding-01.txt

see comment inline

> attacks. Does it do Diffie-Hellman?

As per IEEE802.11i Std. a 4 way key exchange handshake between AP and STA
not only mutually authenticates one another but also validates the
capabilities and ciphersuites - TKIP , AES etc. in a secure manner.
Supporting mutual authentication with improved privacy algorithms like TKIP
(IV with 48bit to reduce rekeying) AES in AP can prevent MitM attack.
 
Preeti
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] ([email-masked])
Date: Tue, 11 Mar 2003 11:13:59 +0200

> layer due to the reasons you describe.

In my understanding - EAP usage within 802.11i does not show any strong notion of STA-AS binding. And perhaps in order do so binding as well as authentication must have some well established method.

The reason I responded in previous message beca's discussion was referring to 4 way handshake. 4 way handshake takes place between STA and AP where messages 2 and 3 responds with PTK as well as indicates that there is no man in the middle. However during 4 way handshake one has to assume that AS is trusted 3rd party.

So have I missed something or overlooked. If so then pl. let me know. 

Regds,
Preeti

> From: ext Puthenkulam, Jose P [mailto:[email-masked]]
> Sent: 07 March, 2003 17:17
> To: Vinayakray-Jani Preetida (NRC/Helsinki); [email-masked]';
> Eronen Pasi (NRC/Helsinki)
> Cc: [email-masked]'

---

From: [email-masked] (Puthenkulam, Jose P)
Date: Tue, 11 Mar 2003 06:22:41 -0800

>In my understanding - EAP usage within 802.11i does not show any strong
notion of STA-AS binding. And perhaps in order do >so binding as well as
authentication must have some well established method.

I guess you may want to look at the IEEE 802.1X spec that defines usage of
EAP for 802.11. EAP only provides STA-AS binding by virtue of authentication
thru an EAP method.

Hope this helps, 

best regards,
jose

> Sent: Tuesday, March 11, 2003 1:14 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> In my understanding - EAP usage within 802.11i does not show 
> any strong notion of STA-AS binding. And perhaps in order do 
> so binding as well as authentication must have some well 
> established method.
> 
> The reason I responded in previous message beca's discussion 
> was referring to 4 way handshake. 4 way handshake takes place 
> between STA and AP where messages 2 and 3 responds with PTK 
> as well as indicates that there is no man in the middle. 
> However during 4 way handshake one has to assume that AS is 
> trusted 3rd party.
>