Subject: Device ID and MitM attacks

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 5 Nov 2002 23:07:34 -0800

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?

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 6 Nov 2002 15:55:24 -0500

> alter the DI information during PANA exchanges would not help 

But without protecting the DI in PANA message exchange, the legitimate
PaC will not be able to successfully establish a security association
for per-packet protection with EP.  So I think DI protection in PANA
message exchange is needed regardless of whether additional per-packet
protection is used or not.  If this is true, we could safely say that
per-packet protection is always out of the scope of PANA.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 6 Nov 2002 18:24:04 -0500

Let me post my intermediate summary of this thread.

Hope this helps,
Yoshihiro Ohba

-----
There is some case in which a man in the middle
can successfully gain access to the network with
his device identifier if there is no the device
identifier protection mechanism defined in PANA
message exchange.  

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

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.

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

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

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

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 6 Nov 2002 18:24:27 -0800

Thanks Yoshihiro, for sumamrizing the discussion.

My comment below...

>      per-packet DI protection is used or not.

What I'm trying to say is that there is a relation
between DI protection during PANA, and per-packet
authentication after PANA. Here's how...

- If DI is protected during PANA:
  - If PANA is followed by per-packet authentication:
    no threats
  - if PANA is NOT followed by per-packet authentication:
    attacker can spoof an authorized DI and transmit packets

- If DI is NOT protected during PANA:
  - If PANA is followed by per-packet authentication:
    Only the client with the right keying material can
    access the network using authorized DI. Just knowing
    the DI would not be sufficient. So the MitM attacker cannot
    gain network access. 
  - If PANA is NOT followed by per-packet authentication:
    Attacker can steal an authenticated session and be able
    to transmit and receive packets.
    
Based on this, can we drive this conclusion ??:
- if per-packet authentication will be enabled, we don't need to
  integrity protect DI during PANA.
- if per-packet authentication will not be enabled, it doesn't
  matter even if you protect DI because you'll still be open
  to attacks.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 7 Nov 2002 01:02:02 -0500

>     the DI would not be sufficient. So the MitM attacker cannot

But I think the attacker can still prevent the client from
establishing an security association (e.g., IPsec SA) for per-packet
protection (though this would be a DoS attack), since the PAA thinks
that the LSA created by using PANA and used for establishing the
per-packet SA would be mapped to the attacker's DI instead of the
legitimated PaC's DI.

>   integrity protect DI during PANA.

That depends on whether a mapping between "legitimate" DI and the LSA
needs to be created in PANA phase in order to enable per-packet
protection for the "legitimate" DI.  If the mapping is not necessarily
created in PANA phase but just an LSA needs to created, you are right.
Note that my current prototype implemtation that is tied with an open
source IKE implementation requires the mapping to be created in PANA
phase.

>   matter even if you protect DI because you'll still be open

I agree that it will still be open to some attacks.  But I think this
does not mean that DI protection in PANA phase without per-packet DI
protection is useless, if we consider replacing the current web-based
authentication in hot-spot network access with PANA.  DI protection in
authentication phase without per-packet DI protection has some
improvemennt than no DI protection at all.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 7 Nov 2002 18:47:59 -0800

> per-packet SA would be mapped to the attacker's DI instead of the

But even if we had used DI protection during PANA, couldn't attacker achieve
a
similar DoS attack? Based on the topology in the figure, attacker could
use IP address 'b' while talking to PaC, and use 'a' while talking
to PAA. So, it's effectively a pass-through (like a bridge). Once the
authentication concludes, now it can stop passing PaC's traffic.

This of course assumes that attacker can physically come in between
PaC and PAA.

If attacker cannot come in between two, I'd assume there better be
an EP in the network to prevent attacker from acting like a PAA
(i.e., responding to PAA discoveries). Othwerwise, attacker can
simply keep a PaC holding while the pretending like authenticating
the PaC. Hence, another type of DoS.

So, one can launch a DoS on the PaC even if we had protected the
DI during authentication.

> created in PANA phase but just an LSA needs to created, you are right.

I cannot think of having an LSA without DI.. I think DI is an
attribute of the LSA. But I don't see how this effects the discussion..

> authentication phase without per-packet DI protection

attacker can only transmit packets on the expense of the victim.
(it can even receive packets, if address resolution protocol is not
secured either)

> has some

attacker can transmit and receive packets on the expense of the victim.

As far as securing network access is concerned, these are pretty
close (bad) situations imo.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Nov 2002 10:27:06 -0500

> authentication concludes, now it can stop passing PaC's traffic.

In that case, the attacker is acutually not modifying the packets at
all but just start jamming or denying the communication after PANA
conversation.  The attack could happen even if per-packet protection
is used, and thus bringing this attack into the discussion here does
not make sense to me.

> attribute of the LSA. 

Yes, I think so, too.

> But I don't see how this effects the discussion..

Without DI protection in PANA conversation, it is possible that an
attacker's DI becomes an attribute of the LSA.  If this happens,
succeeding process of per-packet SA establishment will be meaningless.

> close (bad) situations imo.

The two attacks you mentioned above are DoS attacks, and I agree that
those DoS attacks are close.  But the "improvement" I mentioned is
actually different (please see below).

- Someone is interfering with your traffic (DoS).
- Someone is free-riding with your account (MiTM).

Both DoS and MiTM are possible if there is no DI protection at all.
MiTM can be avoided if there is DI protection in PANA conversion, 
and this is the improvement I mentioned.

Preventing DoS is a tough issue, since there are a variety of 
DoS attacks in addition to the two attacks you mentioned above.
If we need to eliminate all kinds of DoS attacks for achieving 
super secure network access, we will end up with requiring 
L1 security, L2 security and L3 security altogether.  But in the 
real world, we have some assumption or compromize on what kind of 
DoS attack is significant or not, depending on the usage scenarios.
I mean that requirement on DoS attack is a variable requirement.

But MiTM is different.  MiTM should be avoided regardless of what
level of DoS attacks are accepted or not.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Sat, 9 Nov 2002 14:30:41 -0800

Yoshihiro,

>  DI protection in

Even if DI is protected during PANA, but there is no per-packet
protection, attacker can transmit packets by spoofing an authorized
DI. And this is "free riding", not DoS.

> and this is the improvement I mentioned.

OK, if we are looking at "MitM attacks for service theft", DI protection
during PANA is not sufficient, as I illustrated (see above). What is
absolutely needed is per-packet protection after PANA. And once we have
that, protecting the DI during PANA becomes moot, as DI is only one
component of the LSA, and other component (a secret) cannot be obtained
or altered by the attacker.

Let's also look at 802.1x. MitM is prevented if client and network are
mutually authenticated, and per-packet security is enabled. Please see:
http://www.cisco.com/warp/public/cc/pd/witc/ao350ap/prodlit/1680_pp.htm
And as far as I know, 802.1x does not require mac address to be protected 
during the authentication.

> level of DoS attacks are accepted or not.

Yes, but MitM cannot be avoided unless per-packet protection is enabled.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 11 Nov 2002 11:35:11 -0500

Speaking of 802.1X, some 802.1X usage requires mac address protection
in EAPOL-Key message exchange.  A typical example is SSN (Safe
Security Network; this name may be obsolete) which is being developed
in Wi-Fi Alliance as a subset of 802.11i.  The MIC field of the
EAPOL-Key message is calculated by using a part of Pairwise Transient
Key which is calculated from master key, a pair of MAC addresses, a
pair of random numbers.  This means that DI is not only a component of
the LSA but also cryptographically bound to the LSA in the case of
SSN.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 20 Nov 2002 19:07:13 -0800

My initial concern was due to the following requirement:

   When the DI is carried explicitly as part of the PANA payload, the
   authentication computation MUST also include this field to provide
   integrity protection for the DI. When the DI is carried implicitly
   as the source of the PANA message, the protocol has to make sure
   that the DI's integrity is protected by some other means (e.g.,
   physical verification of incoming port number of the PANA message in
   the case of switch port number as a DI and PAA co-located with the
   link-layer access device). Protecting PaCs against DI theft is
   outside the scope of PANA.

Not all usage cases of PANA can carry DI and protect its integrity.
DI protection requires presence of cryptographic keys between PaC and PAA,
which can be distributed or derived. But not all EAP methods can provide
that.
For example, using EAP-MD5/EAP/PANA over DSL networks.

On the other hand, this kind of protection is not needed in all cases,
either. As we discussed, it helps with MitM attacks, and when there is
physical protection (e.g., DSL networks) we are not concerned about
this threat.

So, how about this replacement text:

  PANA MUST be able to explicitly carry and provide integrity protection
  for the DI. This protection is needed for preventing certain
man-in-the-middle
  attacks [SECTHREATS]. Using this feature requires cryptographic keys
between
  PaC and PAA. Availability of these keys depends on the authentication
methods used.
  Furthermore, this protection may not be needed when the man-in-the-middle
  threat is mitigated by other means, such as running PANA over physically
  secured networks. Therefore, while the protocol MUST provide this
capability,
  its use is optional. Additionally, protecting PaCs against DI theft after
the
  successful authentication is outside the scope of PANA.

Comments?

alper

----- Original Message -----
From: "Yoshihiro Ohba" <[email-masked]>
To: "Alper E. YEGIN" <[email-masked]>
Cc: "Yoshihiro Ohba" <[email-masked]>; "Pana (E-mail)"
<[email-masked]>
Sent: Monday, November 11, 2002 8:35 AM
Subject: Re: Intermediate summary [Re: Device ID and MitM attacks]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Nov 2002 07:55:41 -0500

I think the text well covers the recent discussion on DI protection
and I agree on the replacement text.

Thanks,
Yoshihiro Ohba