Subject: Re: [HOKEY] Key Management domain

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Jan 2008 21:19:43 -0800 (PST)

Hi Charles,

  There is another option: get rid of the key hierarchy. Since the
peer will do a full EAP authentication upon obtaining initial service
from this "domain" there is no need to make domain-specific keys. The
peer is only going to be using that key with this "domain" anyway.

  Furthermore, we're now embracing the use of AAA proxies and saying
there is no problem with moving keys around inside this "domain". We
just stated that there is no security risk with sharing keys so there
is even less need for having a key hierarchy.

  There is no problem I can see that's being solved by having a key
hierarchy (now that AAA proxies are hunky-dory). Let's just do away with
the added complexity. Or maybe someone can explain what problem this
complexity is solving (remember all entities are now trusted by definition).

  Dan.

On Sat, December 29, 2007 10:11 am, Charles Clancy wrote:
> We've created the term DSRK, for which the "D" stands for "domain".  We
> either need to define what a domain is (in terms of key scope), or
> rename the DSRK (among other keys).  The idea of a key management domain
> defines what the "D" is in "DSRK".  I don't think it's circular --
> whenever we say "domain" we specifically mean "key management domain",
> and the definition of a key management domain is "X".
>
> In the interest of getting this document done, I strongly recommend we
> add the definition proposed to the list to the EMSK keying doc and be
> done with it.
>
> Joe, can you send an updated version of the key management domain
> definition, based on the comments received, to the list?
>
> --
> t. charles clancy, ph.d.                 eng.umd.edu/~tcc
> electrical & computer engineering, university of maryland
>
>
> Nakhjiri Madjid-VXT746 wrote:
>> Why don't we just use "Key scope" as Russ and Bernard defined in their
>> RFC?
>>
>> Introducing "domain" as in "key management domain" while we are
>> frequently talking about domain specific root keys (DSRK) is confusing
>> and goes in circles.
>>
>> Madjid
>>
>> -----Original Message-----
>> From: Glen Zorn [mailto:[email-masked]]
>> Sent: Saturday, December 22, 2007 3:58 PM
>> To: 'Charles Clancy'; 'Yoshihiro Ohba'
>> Cc: [email-masked]
>> Subject: RE: [HOKEY] Key Management domain
>>
>>> - In "(3) distribute key materials to other systems", are "other
>>  > systems" in the same key management domain or in any domains?
>>
>> Same key management domain.  Devices can't re-scope keys, only narrow
>> the scope.
>>
>>
>> [gwz]
>> Maybe we should add that to the definition for clarification:
>>
>> "Key Management Domain
>>
>> A key management domain is specified by the scope of a given root key.
>> The scope is the collection of systems authorized to access key material
>> derived from that key. Systems within a key management domain may be
>> authorized to (1) derive key materials, (2) use key materials, or (3)
>> distribute key materials to other systems in the same domain.  A derived
>> key's scope is constrained to a subset of the scope of the key from
>> which it
>> is derived."
>>
>> [/gwz]
>>
>> ...
>>
>>
>> _______________________________________________
>> HOKEY mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/hokey
>
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
>

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

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 2 Jan 2008 14:52:01 -0800

...

[gwz] 
I think that a more fruitful discussion might be elicited by taking a little
more nuanced attitude toward trust.  All entitis are _not_ trusted by
definition, at least not completely; it might be useful to come up with a
description of what AAA proxies are & are not trusted to do with the keying
material.
[/gwz]

...

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 2 Jan 2008 17:28:11 -0800 (PST)

Glen,

  The problem with that approach is that this thread will become
a discussion about proxies and not about the utility of the key
hierarchy. I'd really like to know what problem is being solved
by adding this complexity.

  The subject of proxies will appear because it is my contention
that any problem that the key hierarchy was supposed to address is
officially no longer a problem given our new understanding about
why proxies are OK.

  So can anyone out there in HOKEY-land tell me what problem is
being solved by the key hierarchy?

  Dan.

---

From: "Nakhjiri Madjid-VXT746" <[email-masked]>
Date: Fri, 4 Jan 2008 20:55:21 -0500

Madjid>>The RFC says: 
"Limit key scope

         Following the principle of least privilege, parties MUST NOT
         have access to keying material that is not needed to perform
         their role.  A party has access to a particular key if it has
         access to all of the secret information needed to derive it.

         Any protocol that is used to establish session keys MUST
         specify the scope for session keys, clearly identifying the
         parties to whom the session key is available."

Which implies the following definition for scope:

"Key scope: consists of all the parties that have access to a particular
key or all the material needed to the derive the key"

And I am not a rocket scientist, mind you.

The current definition of key management domain does not go well with
USRK versus DSRK distinction. So we should either adopt "key scope", or
simply drop the notion of DSRK all together based on the conflict I
described below. 
The D in DSRK was marketed to mean administrative domain. It was claimed
to handle the roaming scenarios, I for one always questioned which
operator would let an EAP based session key to fall into the hands of
another operator to do whatever with it. But I must be too far into the
real world. Now the domain in DSRK does not mean that, so I am not sure
what the latest justification for D is.

Including the name of the domain in D does not handle what I described
below. An administrative domain derives EMSK, you can derive a USRK from
there and then use it to derive root keys per AAA domain, per
authentication domain, per BS, whatever using relevant IDs, and none of
these are DSRK as it was advertised.

Madjid

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Saturday, December 29, 2007 12:26 PM
To: Nakhjiri Madjid-VXT746
Cc: 'Yoshihiro Ohba'; [email-masked]; 'Charles Clancy'; 'Joseph Salowey
(jsalowey)'

This discussion is getting to the point of ad-nauseam.
The "scope" is already defined,
[gwz]
RFC 4962 never actually defines "scope" or "key scope" -- it just uses
the terms, perhaps assuming that the meaning is obvious.
[/gwz]

the term "domain" is over-stressed,
having AAA domains and administrative domains and authentication domains
(WiMAX), mobility domains (802.11) out there.

[gwz]
Are you saying you consider the term "domain" in "Domain-Specific Root
Key"
to be defined by the environment in which it is used?  
[/gwz]

...

If domain is the
same key management domain and DSRK, then any key is DSRK, including
USRK which was supposed to be domain independent.
 
[gwz]
That's a good point: "key management domain" actually _does_ help define
the scope of the key, but it doesn't help much in its derivation: if the
name of the "domain" is included in the key derivation (to make the key
"domain-specific"), what is that name?  If it's not a hostname or DNS
domain name, what?
[/gwz]

Madjid

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]]
Sent: Saturday, December 29, 2007 10:12 AM
To: Nakhjiri Madjid-VXT746
Cc: Glen Zorn; Yoshihiro Ohba; [email-masked]
Subject: Re: [HOKEY] Key Management domain

> The scope is the collection of systems authorized to access key 
> material derived from that key. Systems within a key management domain

> may be authorized to (1) derive key materials, (2) use key materials, 
> or (3) distribute key materials to other systems in the same domain.
> A derived key's scope is constrained to a subset of the scope of the 
> key from which it is derived."
> 
> [/gwz]
> 
> ...
> 
>

---

From: "Nakhjiri Madjid-VXT746" <[email-masked]>
Date: Fri, 11 Jan 2008 01:23:28 -0500

Ah, Dan, you are getting me out my rat hole, even though I no longer
live on hokey-land, thanks god, but just like Southern California fires,
I see the smoke as the mail goes into its own folder..
 
You want to know why the key hierarchy was suggested in the first place,
you should probably look at BOF or even dry-bar-BOF material from
Vancouver 05/Dallas. The real world problem (with emphasis on real) we
were planning on solving was the problem WiMAX was dealing with:

A bunch of Base stations under a gateway acting as EAP authenticator
needed their own master keys to establish session keys with a mobile
node as the mobile moved between base stations. MSK could not be used,
since different base stations should not have known about each other's
keys. One level up, i.e. handover between authenticators would have the
same issue: MSK was shipped to the first authenticator, so moving to the
second authenticator you were out of luck. Some clever people suggested
some smart algorithm that did not require key hierarchy, but creating a
hierarchy that would let you skip going back to AAA server for every BS
handover (by as you say in your other email) storing the key in the
local authenticator/server) was desired since those clever people got
tired of hokey and left. 

The inter-BS handover went quickly out the door, since IETF does not
like the word BS, even though it is an IP capable node. And thus
handover keying has not been bastardized into re-authentication, without
dealing with any of the handover delay issues. The only think re-auth
solves is the number of Rats to AAA and that can be solved with any
secret shared between peer and server (look at EAP-AKA).

And yes, the initial idea was wrapping the key in a manner that is not
exposed to proxies, because you were dealing with very specific
networks.

The inter-domain roaming was never the intention. I cannot possibly
think of two operator wanting to deal with sharing keys off a EAP
hierarchy and thereby opening all their network to you just because you
authenticated to a rival operator. The pre-authentication was supposed
to deal with that.

Madjid

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Wednesday, January 02, 2008 5:28 PM
To: Glen Zorn
Cc: [email-masked]
Subject: RE: [HOKEY] Key Management domain

  Glen,

  The problem with that approach is that this thread will become a
discussion about proxies and not about the utility of the key hierarchy.
I'd really like to know what problem is being solved by adding this
complexity.

  The subject of proxies will appear because it is my contention that
any problem that the key hierarchy was supposed to address is officially
no longer a problem given our new understanding about why proxies are
OK.

  So can anyone out there in HOKEY-land tell me what problem is being
solved by the key hierarchy?

  Dan.

On Wed, January 2, 2008 2:52 pm, Glen Zorn wrote:
> hierarchy (now that AAA proxies are hunky-dory). Let's just do away 
> with the added complexity. Or maybe someone can explain what problem 
> this complexity is solving (remember all entities are now trusted by 
> definition).
>
> [gwz]
> I think that a more fruitful discussion might be elicited by taking a 
> little more nuanced attitude toward trust.  All entitis are _not_ 
> trusted by definition, at least not completely; it might be useful to 
> come up with a description of what AAA proxies are & are not trusted 
> to do with the keying material.
> [/gwz]
>
> ...
>
>