Subject: RE: [Mipshop] RE: Review of draft-yegin-hmip-sa-00

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Aug 2006 00:20:38 +0300

> > > I don't think the NAS should be involved in the
> > > key delivery.  My (limited) understanding of 4140
> > > tells me that the MAP is deeper in the network
> > > than a typical NAS
> >
> >In my understanding, MAP is part of the "access network", not the "home
> >network." For that, putting aside the physical and topological aspects,
> from
> >"administrative domain" aspect NAS and MAP are the part of the same
> network.
> 
> NAS is an edge entity and thus vulnerable to compromise, more so than
> say the MAP or a AAA server (yes, I am keeping in mind the visited
> domain AAA server and the home AAA server).  MAP is deeper in the
> network and would probably be harder to even get physical access
> to.  So, if the NAS were to be compromised, a key shared by an MN and
> MAP will be compromised, right?

Yes. Much like all the NAS ports (e.g., base stations) and any data and
signaling that is not end2end secured are compromised. For that, NAS
compromise is not a trivial event that operators can live with and defend
reactively. I mean, no one would say "my NAS and hundreds of subscriber
sessions on it are compromised but luckily one or few of those subscribers
who are using MAPx are still able to use that MAP."

> There might be practical aspects as well.  I am wondering if the NAS
> is engaging in key delivery, does it have to be a AAA server?  In the
> EAP model the NAS is a AAA client, AFAIK.

There is always key delivery from NAS to NAS ports when the two are running
on separate nodes.

> 
> 
> > > I am fine with the notion of using a key from the
> > > EAP keying hierarchy for IKEv2
> > > authentication.  However, I don't think we should
> > > use the MSK for the key derivation.  Instead a
> > > key from the EMSK hierarchy might be used.   We
> > > can discuss the specifics in detail if you want.
> >
> >Why do you think so?
> >
> >We proposed use of MSK because we assume MAP and NAS are part of the same
> >administrative domain. NAS can generate the HMIP-SA and pass it to the
> MAP.
> >Use of EMSK would have been more appropriate if MAP were part of the home
> >network along with the HAAA server.
> 
> So, the MSK, or portions thereof are used as the PMK and other keys
> (e.g., R0-Key in TGr).  Your proposal suggests to use the same key
> for HMIP key derivation.  This is against the cryptographic principle
> that the same key must not be used for different purposes.

Two separate keys can be derived from the same key. This should not be a
practical problem, otherwise we cannot really generate so many keys from
just one key (the so-called "master key".)

Alper

> 
> If we can turn back the clock on the MSK usage and define a MSK
> hierarchy where keys for purposes other than access can be derived,
> that might have been an alternative.  However, that is generally
> deemed not practical.
> 
> There is a way to use the EMSK even in the visited domain
> scenario.  Vidya and I wrote about this briefly in draft-dondeti-eapext-
> ps-00.
> 
> regards,
> Lakshminath
> 
> 
> >Alper
> >
> >
> >
> >
> >_______________________________________________
> >Mipshop mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 02 Aug 2006 15:15:36 -0700

Hi Alper,

Thanks for your response.  Please see inline:

>who are using MAPx are still able to use that MAP."

Without getting into the impact of the NAS compromise, the whole 
point here is that once an MN moves away from a NAS, compromise of 
that NAS should not have any disruption to MN's mobility services.

>There is always key delivery from NAS to NAS ports when the two are running

Sure, isn't that different as NAS to NAS ports is downstream (or 
within the same box even); the key delivery at least in the IETF 
happens via CAPWAP; NAS to upstream communication is a whole another matter.

>just one key (the so-called "master key".)

Sure, generally speaking if we have a "fresh" key, we can derive keys 
from that key, within limit.  However, what we have is an MSK which 
has some usage rules already.  It is not practical to introduce a key 
hierarchy on the MSK.

Hope that clarifies my take on this.

regards,
Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Aug 2006 02:12:46 +0300

> happens via CAPWAP; NAS to upstream communication is a whole another

I was just responding to your "key delivery" question, without any regard to
the directions. I don't think a given key hierarchy implies a physical
layout.

> has some usage rules already.  It is not practical to introduce a key

Are these rules documented anywhere? Again, there is almost always a key
hierarchy taking MSK as the root (and descending towards the NAS ports).

Alper

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 02 Aug 2006 22:35:06 -0700

Alper,

We may be talking past each other.  Here are the two points I am making:

First, compromise of an edge entity is more likely than compromise of 
an entity deeper in the network, for the simple reasons that edge 
entities are numerous and they are easy to get physical access to for 
adversaries.

NASs do engage in key distribution, but in all the real-world 
examples I can think of, the key distribution is to other "edge" 
entities, for instance, from an AC to WTP in the CAPWAP model, and 
generally from the NAS to an EP (enforcement point).

The second point is one that I had been making consistently in the 
context of the EAPext work and elsewhere.  The MSK after being 
transported to a NAS is used in various different ways in various L2 
technologies.  802.11 uses the first 256 bits as the PMK and the last 
256 bits as the R0-Key in the 11r context.  Likewise, 802.16e in one 
of the modes uses 320 bits.  IKEv2 uses the 512 bits for authentication.

Given that background, it doesn't seem practical to impose a common 
hierarchy on the MSK.

Now, if you find any factual errors in the above, I would be happy to 
correct myself.

I will reiterate too that I think the overall AAA based model for 
HMIPv6 security that you set out to solve is practical in most 
networks I am aware of.  The disagreement is on how best to arrive at 
the solution.

thanks,
Lakshminath

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 3 Aug 2006 11:32:58 +0200

Hi all,

 just a quick comment,

> entities are numerous and they are easy to get physical access to for 

 I'm not sure that we can say that ALL NASes are easy to get physical
 access to for adversaries. Some NASes may be easy to get access to.
 Some other NAS not.

 Just my 2 cents,

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 03 Aug 2006 09:23:56 -0700

>  access to for adversaries. Some NASes may be easy to get access to.

Absolutely true.  Thanks.  I have been meaning to say this.  However, 
I would add the note that when we design protocols, we should take 
into consideration the generalized deployment model and design for 
the case of NASes being vulnerable.

Lakshminath

> > >> > > >We proposed use of MSK because we assume MAP and NAS are 
> part of the
> > >> same
> > >> > > >Use of EMSK would have been more appropriate if MAP were 
> part of the
> > >> home

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 3 Aug 2006 18:37:47 +0200

Hi,

> the case of NASes being vulnerable.

 well, maybe that's not the appropriate list to discuss that but it
 could be interesting to understand in which deployment NASes should be considered as
 vulnerable or not.  

 Julien

> >> >I was just responding to your "key delivery" question, without any 
> >regard
> >> >to
> >> >> > > >administrative domain. NAS can generate the HMIP-SA and pass it 
> >to
> >> >> the
> >> >> > > MAP.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 3 Aug 2006 23:21:49 +0300

> entities are numerous and they are easy to get physical access to for

That's somewhat true. But that's not the only factor in designing key
derivation and distribution mechanisms. If it were, we'd have been sending
the keys directly from the AAA server to the BSes (not to the NAS), since it
is easier to compromise a NAS than the AAA server.

> generally from the NAS to an EP (enforcement point).

Again, your observation is true. But there is no inherent conflict with the
key hierarchy going against the physical topology. It has more to do with
the "boundaries of administrative domains" than with the direction of how
data flows.

> of the modes uses 320 bits.  IKEv2 uses the 512 bits for authentication.

This observation is correct.

> Given that background, it doesn't seem practical to impose a common

I am not so sure that the situation is not that unmanageable, to the extent
that we give up on MSK and rely on a workaround (EMSK). 

> networks I am aware of.  The disagreement is on how best to arrive at

I understand.

Alper

> > > > > >We proposed use of MSK because we assume MAP and NAS are part of
> the
> > > same
> > > > > >Use of EMSK would have been more appropriate if MAP were part of
> the
> > > home