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

[Joseph Salowey (jsalowey]

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. 
> 

[Joe] In general I have issues with the format which I expressed previously.
In particular I don't think we should specify a particular format for the
name exported from an EAP-Mechanism.  How the name is formatted is up to the
EAP mechanism.  We can place requirements on uniqueness and give
recommendations on construction.  The EAP mechanism will know how best to
generate interoperable names based on its specification.  If we need to
specify additional names for keys etc. then we can make recommendations for
how applications should construct a name based on the exported name.  I
thought there was an issue open on this, I can open another one if the
current one is not appropriate.

> 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?) 
> 
>     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.
> 

[Joe] Yes we did have a discussion before.  I still think short names or IDs
are useful.  I think we will probably have to limit the length of names
anyway.  In particular I also think this is more of an issue for names
exported from the EAP mechanism rather than names for the AMSK.   


> --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."