Subject: RE: Intermediate summary [Re: Device ID and MitM attacks]

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 8 Nov 2002 11:30:28 -0800

Yoshihiro,

Some questions below..
 
> 
> 
> <An example attack>
> 
> Let a and b be the IP addresses of the legitimate
> PaC and PAA, respectively.  Let x be the IP
> address of the attacker in the middle.
> 
> 
> PaC          attacker          PAA
>  a ------------- x ------------ b
> 
> 
> 1.  The attacker intercepts all PANA messages sent
>     from the PaC, rewrites the source IP address
>     field to be x, and fowards them to the PAA.
> 
> 2.  The attacker also intercepts all PANA messages
>     sent from the PAA, rewrites the destination IP
>     address field to be a, and fowards them to the
>     PaC.
> 
> 3.  Finally, when the PAA sucessfully
>     authenticates the PaC, the IP address x will
>     be authorized for network access instead of IP
>     address a.
> 
> In this attack, the PaC thinks that it is
> communicating with the PAA of IP address b and the
> PAA thinks that it is communicating with a PaC of
> IP address x (not a).
> 
> 
> <The required functionality to prevent the attack>
> 
> 1.  Establish an secure communication channel
>     between the PaC and PAA.
> 
What do we mean by secure channel ? If the server is the one
that is authenticated in phase I (most of the schemes just do
this), to establish a secure channel, all the client needs to do
is learn a valid device identifier (see more on this below)
to gain the access. Is the assumption that the attacker does not
know the valid device identifier i.e one should not be able to learn
this
by eavesdropping etc. ?

> 2.  The PaC sends its device identifier to the PAA
>     over the secure channel.
> 
> 3.  The PAA checks the validity of the device
>     identifier and authorize it for network access
>     if the device identifier is valid and the PaC 
>     is successfully authenticated.
> 
what do you mean by "device identifier is valid" ? 
What prevents me from using somebody else's device identifier ?

> 
> <Issues>
> 
> - Is it always necessary?  If not, in which case
>   DI protection can be optional?
> 
>   -> It can be optional at least in the case where
>      it is assumed that the attacker cannot be in
>      the middle of PaC and PAA.
> 
you never know whether the attacker is in the middle
or not.

> - What about per-packet DI protection?  
> 
>   -> Per-packet DI protection is a separate issue.
>      DI protection in PANA message exchange is
>      needed in general regardless of whether
>      per-packet DI protection is used or not.
> 
Yes. If you don't even get successful access into the
network because of the above MiTM attack, there is
no per-packet DI to talk about.

> - Are there any requirements on when the secure
>   channel between the PaC and PAA should be
>   established, i.e., before or after the PaC is
>   authenticated?  
> 
I did not get this. You establish a secure channel in the process
of authentication i.e you derive keys as a result of successful
authentication.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Nov 2002 15:20:41 -0500

> know the valid device identifier i.e one should not be able to learn

Perhaps secure communication is not a good wording, and 
let me rephrase as:

1.  Establish a local security association (LSA) between the PaC and PAA.

(device identifier is not significant information in this phase.)

> > 2.  The PaC sends its device identifier to the PAA

And let me rephrase as:

2.  The PaC sends the PAA its device identifier that is 
    integrity protected by using the established LSA.

> What prevents me from using somebody else's device identifier ?

Device identifier would be valid if the device identifier carried in
2) is integrity valid and is the same as the one appeared in the IP
header.

> you never know whether the attacker is in the middle

That's why I use the word "assumed" :)

> no per-packet DI to talk about.

Agreed.

> of authentication i.e you derive keys as a result of successful

There are some protocols (i.e., PIC, PANA over TLS, etc.) that 
establishes a secure channel between client and NAS before successfully 
authenticating the client.

> -mohan

Yoshihiro Ohba