eap Mailing List: RE: review of draft-salowey-eap-key-deriv-02.txt

[Joseph Salowey (jsalowey]

Hi Jari,

Thanks for the review, comments below:

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Saturday, November 08, 2003 3:49 PM
> To: Joe Salowey; Pasi Eronen
> Cc: eap [at] frascone.com
> Subject: review of draft-salowey-eap-key-deriv-02.txt
> 
> 
> 
> Joe, Pasi,
> 
> I took a look at your draft draft-salowey-eap-key-deriv-02.txt.
> It looks quite reasonable to me -- thanks for working on it! 
> -- though I do have some comments:
> 
> Substantial:
> 
> 1. The goal of the draft. Is there an intent that some of this
>     should be discussed in the eap-keying document? Or would this
>     be a later extension to that? Or just for our information?
> 
[Joe] I'll be submitting issues to incorporate most of the content into
the key framework document.


> 2. If the security ADs wanted us to name current keys generated
>     from EAP, I think its likely that they will require AMSKs
>     be named as well. A discussion of the naming is missing, though
>     the EMSK itself is named in the document.
> 
[Joe] Yes, more of a discussion of naming is needed.  


> 3. I'm not sure I like the idea of EMSK Name being derived from
>     KDF(EMSK), if there are alternatives. Would it be possible to
>     name the EMSK by the EAP SA Name defined in eap-keying (derived
>     from nonces), concanated with, say, "EMSK". Similarly, we could
>     name each AMSK as the name of the EMSK, concatenated with "AMSK"
>     and the key label and application data?

[Joe] I don't like the proposal either.  The problem is that the EAP SA
name is not concretely defined.  I'm not sure you can define this for
all methods in general.  We need to place a requirement on methods that
if they are going to generate additional keys they must also export an
EAP-SA name.

> 
> 4. Section 3.1, what is the unit of "O"? Bytes or bits?
>
[Joe] Should be bytes
 
> 5. Section 3.3 fails to discuss that if EMSK is going to be
>     useful, there's probably going to be some state kept in
>     the AAA server.
> 
[Joe] true

> Editorial:
> 
> 1. Section 1.2, last paragraph. Missing "." at the end.
> 
> 2. Section 2.1, s/MSUT/MUST/
> 
>