[Top] [All Lists]


2008-03-18 17:27:04
FWIW, I agree with Glen's take here.  To avoid repeating myself, here
are pointers to emails that I sent in response to this thread on the
IETF list (for the benefit of those not on the list):

- Vidya

-----Original Message-----
From: hokey-bounces(_at_)ietf(_dot_)org 
On Behalf Of Glen Zorn
Sent: Tuesday, March 18, 2008 8:31 AM
To: Charles Clancy
Cc: ietf(_at_)ietf(_dot_)org; hokey(_at_)ietf(_dot_)org; Bernard Aboba
Subject: Re: [HOKEY] EMSK Issue

Charles Clancy <> scribbled on :


From Bernard's "walled garden" LC comments, I've created 
the following 
issue below in the issue tracker.

Some of us don't subscribe to the IETF list (due to the 
extremely poor S/N ratio).  Someone did forward me Bernard's 
original message & to me it appears to fall squarely into the 
N category (either that or it is an early April 1 RFC 
candidate).  I understand, though, that it is actually 
receiving serious discussion on the IETF list, so I'm happy 
that you are bringing some of that discussion to this forum.  
Of course, common courtesy would have required that the WG 
the work of which is being disparaged in outrageous fashion 
be included in the discussion but courtesy seems to be in 
short supply.
EMSK: applicability statement, scope

The EMSK document, as-is, allows (or more precisely does not
disallow) for broader use of keys than it should.  

That may be somebody's claim; however, RFC 3748 says:

   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least
      64 octets in length.  The EMSK is not shared with the
      authenticator or any other third party.  The EMSK is 
reserved for
      future uses that are not defined yet.

This doesn't appear to me to constrain the uses of the EMSK; 
furthermore, since Bernard is not just one of the authors of 
3748 but also a co-Chair of the working group that published 
it, it seems like the time & place to constrain the usage of 
the EMSK would have been during the drafting of the RFC and 
in the eap WG.  

There could
be interoperability issues if applications require 
EAP-generated keys, 
breaking the layering of the Internet protocol stack.

What does that mean?  How can _keys_ cause layer violations?

Some sort of statement regarding applicability and scoping 
of derived 
keys is necessary for this document.

t. charles clancy, ph.d.       
electrical & computer engineering, university of maryland 
HOKEY mailing list
HOKEY mailing list

IETF mailing list

<Prev in Thread] Current Thread [Next in Thread>