Subject: RE: Device ID and MitM attacks

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 6 Nov 2002 19:14:20 +0100

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

=> If IPsec is used then all communication will be done 
via the EP. On a shared link this will be problematic when
nodes are communicating directly to each other. You would need
all nodes to put filters that will only accept packets from 
EPs that they have SAs with. So I think this will work only 
for packets whose destination is outside the link. 
That could be ab acceptable tradeoff since the EP is only 
effective for those packets anyway.

Hesham

  > alper

---

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

> EPs that they have SAs with. 

Yes.

> So I think this will work only 

No, even for on-link destinations, client would have to send
packets through EP. Otherwise, local traffic bypasses
enforcement procedures.

> effective for those packets anyway.

Not necessarily. see above.

alper