Subject: RE: Device ID and MitM attacks

From: <[email-masked]>
Date: Wed, 6 Nov 2002 19:01:40 +0200

Alper,

Comments inline.

> -----Original Message-----
> From: ext Alper E. YEGIN [mailto:[email-masked]]
> Sent: 06 November, 2002 09:08
> To: Pana (E-mail)
> Subject: Device ID and MitM attacks
> 
> 
> 
> Some thoughts on device ID and man-in-the-middle attacks.
> 
> In the requirements draft, we had stated that device id (DI)
> must be integrity protected against MitM attacks (req 4.1.1).
> 
> When PANA is used in networks where underlying layers are 
> secured (see sections 4.1, 4.2 of usage scenarios draft), 
> protection of DI should not be an issue. Assumption is that
> there cannot be a MitM on the link to alter DI information.
> 
> But, when there is no lower layer security at all (see section 4.3
> of usage scenarios draft), it seems like we have to make sure
> DI is integrity protected. But, having the right DI should not
> be sufficient for a client to gain access once it's authenticated. 
> Since these are unprotected links, nothing prevents an attacker
> from spoofing DI of an already authenticated client for 
> gaining network 
> access. A complete solution would require this DI to be used with 
> per-packet authentication, e.g., by using IPsec. So, being able to 
> alter the DI information during PANA exchanges would not help 
> an attacker.

That's right, but wasn't this out of the scope of PANA.

Let's say IPSec is bootstrapped after PANA and PANA provides key material to IPSec. The network should in this point know what DI (=IP address in this case) is bound to this specific IPSec Security Association. DI acts as a key to the SA and thus, should be protected?
 
> As long as per-packet authentication is based on a security 
> association that was bootstraped using a shared secret that was
> a by-product of the EAP authentication method, that should work.

This implies a requirement for the EAP method: strong enough security association and a shared secret as the result (session key?). I think password methods wount pass this requirement. They may be weak with the MitM attack too (not enough key material to defense against dictionary based attacks).

> Comments?
> alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 6 Nov 2002 12:19:06 -0800

Dan,

> That's right, but wasn't this out of the scope of PANA.

Per-packet authentication is outside the scope, you are right.
But I'm talking about it in the context of DI, which we have
some requirements on...

>
> Let's say IPSec is bootstrapped after PANA and PANA provides key material
to IPSec. The network should in this point know what DI (=IP address in this
case) is bound to this specific IPSec Security Association. DI acts as a key
to the SA and thus, should be protected?

Yes.

> This implies a requirement for the EAP method: strong enough security
association and a shared secret as the result (session key?). I think
password methods wount pass this requirement. They may be weak with the MitM
attack too (not enough key material to defense against dictionary based
attacks).

This shows the importance of using the right EAP method depending
on the environment.

alper