Subject: Re: [HOKEY] RE: draft-ietf-hokey-emsk-hierarchy-02 is ready for WGLC

From: "Dan Harkins" <[email-masked]>
Date: Mon, 10 Dec 2007 09:57:42 -0800 (PST)

One issue I have is with "key naming". A one-way function is used to
compute a unique name for each key. The problem is that this makes one
key name space for every key in every key hierarchy. So if some server,
through the machinations of HOKEY, comes into possession of many keys
(let's say it's a AAA server for a particular domain and may also act as
a proxy for other domains) it will have many root keys and many derived
keys-- DSRK1, DSRK2, DSRK3, ..., DSUSRK1-1, DSUSRK1-2, ..., DSUSRK2-1,
DSUSRK2-2, ... DSUSRKn-1, DSUSRKn-2, etc.

  The problem is the names of all of these keys (those from the same
hierarchy as well as those from different hierarchies) come from the same
name space. So how does one quickly find the key whose name is, for example,
0x857812e608f1aad4? Through a linear search? Yuck.

  One alternative is assigning a key the name that is currently passed
to the one-way function. I'm sure there are others, but does anyone else
view the current approach as a problem?

  Dan.

On Mon, November 19, 2007 12:48 pm, Charles Clancy wrote:
> I'd like to have a document that addresses all the remaining contentious
> issues (whether the document is officially submitted, or not, given the
> deadline is passed) before moving to WGLC.  In the mean time, feel free to
> discuss those issues on the list. If they can be resolved before
> Vancouver, I'm happy to issue a WGLC ASAP.
>
> -----Original Message-----
> From: "Lakshminath Dondeti" <[email-masked]>
> To: "Charles Clancy" <[email-masked]>; [email-masked]
> Cc: [email-masked]; "Narayanan, Vidya" <[email-masked]>; "Nakhjiri
> Madjid-VXT746" <[email-masked]>; "Joseph Salowey (jsalowey)"
> <[email-masked]>
> Sent: 11/19/2007 3:35 PM
> Subject: draft-ietf-hokey-emsk-hierarchy-02 is ready for WGLC
>
> Hi Charles, Glen,
>
> As one of the authors of the "EMSK Root Key Derivation" draft, I think
> the draft is ready for WGLC.  We have been discussing this topic for a
> long time in the IETF with Joe and Pasi's work in the past and within
> the EAP WG.  Furthermore, the document now records the WG consensus on
> the EMSK, USRK and DSRK derivations and usage.
>
> We may have 1-2 issues that are still contentious, but they are in the
> same ballpark as the other discussions we have had in the past in
> advancing 4962 and currently in advancing the EAP keying framework I-D.
>   Let us have those discussions on this list, perhaps as part of LC
> comment resolution.  It's your call of course to have those discussions
> before or as part of WG LC :).
>
> best,
> Lakshminath
>
>
> _______________________________________________
> 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: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 19 Dec 2007 13:35:05 -0800

> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Monday, December 10, 2007 9:58 AM
> To: Charles Clancy
> Cc: [email-masked]; [email-masked]
> Subject: Re: [HOKEY] RE: draft-ietf-hokey-emsk-hierarchy-02 
> is ready for WGLC
> 
> 
>   One issue I have is with "key naming". A one-way function 
> is used to compute a unique name for each key. The problem is 
> that this makes one key name space for every key in every key 
> hierarchy. So if some server, through the machinations of 
> HOKEY, comes into possession of many keys (let's say it's a 
> AAA server for a particular domain and may also act as a 
> proxy for other domains) it will have many root keys and many derived
> keys-- DSRK1, DSRK2, DSRK3, ..., DSUSRK1-1, DSUSRK1-2, ..., 
> DSUSRK2-1, DSUSRK2-2, ... DSUSRKn-1, DSUSRKn-2, etc.
> 
>   The problem is the names of all of these keys (those from 
> the same hierarchy as well as those from different 
> hierarchies) come from the same name space. So how does one 
> quickly find the key whose name is, for example, 
>   One alternative is assigning a key the name that is 
> currently passed to the one-way function. I'm sure there are 
> others, but does anyone else view the current approach as a problem?
> 
[Joe] I'm not convinced the current approach is a problem, but there may
be better ones.  I'm not sure I follow your alternative.  The current
naming performs a oneway hash on the EAP session ID and the key label.
Are you suggesting to do away with this completely and just use the EAP
session ID?  

> > I'd like to have a document that addresses all the remaining 
> > contentious issues (whether the document is officially 
> submitted, or 
> > not, given the deadline is passed) before moving to WGLC.  
> In the mean 
> > time, feel free to discuss those issues on the list. If they can be 
> > resolved before Vancouver, I'm happy to issue a WGLC ASAP.
> >
> > Cc: [email-masked]; "Narayanan, Vidya" <[email-masked]>; 
> > "Nakhjiri Madjid-VXT746" <[email-masked]>; 
> "Joseph Salowey (jsalowey)"
> > <[email-masked]>
> > Sent: 11/19/2007 3:35 PM
> > comment resolution.  It's your call of course to have those 
> > discussions before or as part of WG LC :).
> >
> > best,
> > Lakshminath
> >
> >

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 19 Dec 2007 16:56:18 -0800 (PST)

Hi Joe,

  Thank you very much for responding to my email. Let me try to clarify
my concern.

  There may be many branches of a single key hierarchy, each having keys
that are all named using a one-way function, and there may be many key
hierarchies that have more branches and more keys all named using the
same one-way function. The current practice of using a one-way function
to generate a key name puts every possible key from every potential
key hierarchy into the same name space.

  If these names really are significant then there must be a need to do
some action with them like look up a key given a name. What would you do
with a query of "how many minutes are left in the lifetime of key named
0x857812e608f1aad4?" Since the one-way function has destroyed any
discriminating information all you're left with is a linear search. That
is very inefficient, especially if the query is made to a server who,
thorough the machinations of HOKEY, comes into possession of many keys.

  It looks like the input to the one-way function uniquely identifies the
key and retains discriminating information (like EAP session ID). If we
did away with the one-way function the query would be along the lines of
"how many minutes are left in the lifetime of the key named
<session-id>-<label>?" and one could use a hash table to rapidly look
something up. Hash of <session-id> produces index into hash table and
<label> produces unique state to locate from hash table index.

  The one-way function randomizes the name and makes efficient lookup
using a hash table problematic. Does this make sense?

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 19 Dec 2007 17:38:28 -0800

Hi Dan,

One reason for taking the hash of the <session-ID>-<label> is that
hashing it makes into a fixed length that is more easily inserted into
protocols.  I'm not sure that indexing by session ID helps you much
since it often contains nonces etc so it may suffer from the same look
up problems.  It seems that when storing and looking up a key that a
server would know the context of the request and therefore, can
determine the label or some other quantity to use to organize the keys
in different groups to make look up more efficient.   I think this is
pretty close to what you are saying, its just that the label is
understood from the context of a request instead of being explicitly
part of the key name.  

An alternative would be to just name the EMSK and assume that the
context of all requests are known so the keys can be differentiated by
context.  I'm not sure if that would make things easier.  

My mindset is to have a unique name for each key and also make sure the
context know for each request so any cache can be efficiently organized.
This should be explained in the document.

Cheers,

Joe

> Sent: Wednesday, December 19, 2007 4:56 PM
> To: Joseph Salowey (jsalowey)
> Cc: Dan Harkins; Charles Clancy; [email-masked]; [email-masked]
> Subject: RE: [HOKEY] RE: draft-ietf-hokey-emsk-hierarchy-02 
> is ready for WGLC
> 
> 
>   Hi Joe,
> 
>   Thank you very much for responding to my email. Let me try 
> to clarify my concern.
> 
>   There may be many branches of a single key hierarchy, each 
> having keys that are all named using a one-way function, and 
> there may be many key hierarchies that have more branches and 
> more keys all named using the same one-way function. The 
> current practice of using a one-way function to generate a 
> key name puts every possible key from every potential key 
> hierarchy into the same name space.
> 
>   If these names really are significant then there must be a 
> need to do some action with them like look up a key given a 
> name. What would you do with a query of "how many minutes are 
> left in the lifetime of key named 0x857812e608f1aad4?" Since 
> the one-way function has destroyed any discriminating 
> information all you're left with is a linear search. That is 
> very inefficient, especially if the query is made to a server 
> who, thorough the machinations of HOKEY, comes into 
> possession of many keys.
> 
>   It looks like the input to the one-way function uniquely 
> identifies the key and retains discriminating information 
> (like EAP session ID). If we did away with the one-way 
> function the query would be along the lines of "how many 
> minutes are left in the lifetime of the key named 
> <session-id>-<label>?" and one could use a hash table to 
> rapidly look something up. Hash of <session-id> produces 
> index into hash table and <label> produces unique state to 
> locate from hash table index.
> 
>   The one-way function randomizes the name and makes 
> efficient lookup using a hash table problematic. Does this make sense?
> 
>   Dan.
> 
> >>   One issue I have is with "key naming". A one-way 
> function is used 
> >> to compute a unique name for each key. The problem is that 
> this makes 
> >> one key name space for every key in every key hierarchy. 
> So if some 
> >> server, through the machinations of HOKEY, comes into 
> possession of 
> >> many keys (let's say it's a AAA server for a particular domain and 
> >> may also act as a proxy for other domains) it will have many root 
> >> keys and many derived
> >> hierarchy as well as those from different
> >> hierarchies) come from the same name space. So how does 
> one quickly 
> >> find the key whose name is, for example, 
> >>   One alternative is assigning a key the name that is currently 
> >> passed to the one-way function. I'm sure there are others, 
> but does 
> >> anyone else view the current approach as a problem?
> >>
> > [Joe] I'm not convinced the current approach is a problem, 
> but there 
> > may be better ones.  I'm not sure I follow your alternative.  The 
> > current naming performs a oneway hash on the EAP session ID 
> and the key label.
> > Are you suggesting to do away with this completely and just use the 
> > EAP session ID?
> >
> >
> >>   Dan.
> >>

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 21 Dec 2007 12:12:33 -0800 (PST)

Hi Joe,

  How would one administratively delete all keys for a given peer?
That seems like an important task. Even if you knew the hashed
identifier for a given peer's key you could delete that but there's
no way to find other keys in the hierarchy from that hash identifier.
An implementation could do things to enable deletion of an entire
hierarchy but I can't see how it could use these hashed identifiers.
In fact, can't see a practical use for these hashed identifiers, hence
the following question:

  Do you think these hashed identifiers are Normative or Informative?
If Normative then why?

  Dan.