eap Mailing List: Issue 274: Naming of AMSKs

[Bernard Aboba (aboba]

Do we have a proposal for text to resolve this issue?

Personally, I'm ok with specifying a particular hash (preferrably one that
is FIPS approved) so as to provide a fixed length name.

Also, would it make sense to make a RECOMMENDATION on the naming scheme
(e.g. the scheme described to date) but also indicate that the name is
exported by the EAP method (which it has to be, I think) and that the EAP
method may do something different if it needs to (to handle cases like no
EAP server identification), but if it does this then it needs to define
the name within the EAP method specification?

---------------------------------------------------------------------------
Issue 274: Naming of AMSKs
Submitter name: Florent Bersani
Submitter email address: florent.bersani [at] rd.francetelecom.fr
Date first submitted: 10/4/2004
Reference: http://mail.frascone.com/pipermail/eap/2004-October/002849.html
Document: Keying-03
Comment type: E
Priority: 1
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."

[Jari Arkko] I agree with the suggested resolution.

[Joe Salowey]
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).

[Jari Arkko]
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.

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.

[Florent Bersani]
>    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 something
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?

[Jari Arkko] OK.

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

[Jari Arkko]
> 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.

Fine with me!

[Joe Salowey]
>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.

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