eap Mailing List: Re: Issue on eap-keying: naming of AMSks

Joe, Jari
Jari Arkko wrote:
First, I agree with Florent's suggested change.
But the issue you bring up Joe seems indeed a separate one,
or maybe even multiple ones:
o  We can require support of a specific naming scheme in EAP, but
   does this imply that the keys can only be referred to these names
   in other protocols, or are those protocols free to choose what
   they want? Other candidate naming schemes the protocols could used
   include a hash of the EAP defined name, a hash of the key itself,
   time of day when the key was created, and user's shoe size.
   Tentative suggestion: It seems sufficient that EAP provides keys
   and key names with the specified format and that applications can
   use this information or some other identifiers as best suits that
   particular application.

I agree. Perhaps we capture that in eap-keying. By including sth in the 
key naming section, saying that:

"It is RECOMMENDED that Applications use the key names defined in this 
document to refer to specific EAP Keying material, however applications 
may very well use their own naming scheme to refer to this keys"

Does that sound good?

o  String concatenation names vs. hash results. Should we have short
   or long names, or possibly both? (Didn't we discuss this at one time?
   Or was it about the use of the keys themselves as a basis for the
   names?)

IIRC, the latter. It was feared that using some hash of the key to name 
it would lead to some vulnerability (e.g. brute force/dictionary attack).

I don't recall any definite conclusion on this one. My two cents: while 
their may be correct ways to do this (OWF), it is true that from an 
information theoretic PoV, there is some leakage, which probably 
accounts for this option not being conservative (if the hash function's 
one-wayness is in trouble then the key naming scheme is in great trouble).

I'll take this to the CFRG to get educated advice

   Tentative suggestion 1: We could require the support and delivery of
   the specified long names from EAP point of view, but allow application
   protocols to perform a hash to shorten the name, if appropriate.
   Tentative suggestion 2: Specify that names are hashes of the currently

   defined strings. It seems that the issue of deciding which hash 
function

   to use is not a problem, because we have already chosen a particular

   function for the AMSK generation.

I'd favor #2

If we don't provide usable names. Applications will either define their 
own ones from scratch or hash ours (and make possibly some mistake here).

So I'd favor a 128 or 160 bit key name.

--Jari
It seems that the definition of the AMSK name may be up to the 
application

that is using the key.  I suppose it is fine to define a name, but 
I'm not

sure it is good to expect application to use that name.  This brings up

another topic.  I think in many cases a fixed length name may be more 
useful

(perhaps this is an ID, who knows).   The current naming schemes can 
lead to

long variable length names.  I would rather (or also) like to see 
schemes

that result in a fixed length name (or ID).
eap-admin [at] frascone.com wrote:
   Description of issue: should AMSK naming be mandatory?
   Submitter name: Florent Bersani
   Submitter email address: florent.bersani [at] francetelecom.com
   Date first submitted: 10/04/2004
   Document: Keying Framework
   Comment type: 'E'ditorial
   Priority: 1 should fix
   Section: 2.4
   Rationale/Explanation of issue:
section 2.4 reads:  "AMSK Name
      AMSKs, if any, may be named by the concatenation of the string
      "AMSK", key label, application data (see Appendix F), and EMSK
Name."
However, I think it is sound practice to name keys. Since
AMSK are new,
we shouldn't be bothered with legacy reasons. Hence, why not
make this
AMSK naming "mandatory"

Requested change
Replace the previous text by
"AMSK Name
AMSKs, if any, are named by concatenating the string

      "AMSK", key label, application data (see Appendix F), and EMSK

Name." 

Re: Issue on eap-keying: naming of AMSks	<– Date –> <– Thread –>
From: Florent Bersani (florent.bersanird.francetelecom.fr)
Date: Tue, 5 Oct 2004 10:29:57 -0400 (EDT)

eap Mailing List
View Index by: Date - Thread - Author