eap Mailing List: RE: Re: Rewrite of Section 2 of the EAP Key Management Framework

[Salowey, Joe (jsalowey]

Hi Bernard,

I think in general this looks pretty good.  I have some comments and
questions:

Section 2.3

- In paragraph 4 it states 

"In either case, it can be assumed that the parties do not utilize the
link to exchange data traffic unless their authentication requirements
have been met." 

Is there a reason why it is useful to assume this?  I'm not sure that it
needs to be true (although I agree that it often is).

- in paragraph 6 

It should also state that successful EAP authentication and key
derivation does not necessarily mean that the peer will be granted
access.  There is typically authorization and resource allocation which
also must happen can could fail.  This may be handled (or not handled)
differently by different lower layers. 

Section 2.4 

- is [3] related to capabilities in the discovery phase?

- What is meant by "more than one set of exported EAP parameters" in [4]

Section 2.5

- I thought we were deprecating IV, should we mention it here?
- Do we discuss key lifetime elsewhere in the document?  I think it
needs more discussion and I'm not really crazy about exporting a value
called key lifetime from a mechanism, perhaps maximum-key-lifetime would
be better although I have reservations about that too since a key
lifetime may depend upon how it is used.
- Is methodID defined elsewhere?  Is it a value exported by the EAP
method that uniquely identifies a particular execution of the EAP
method?

Section 2.6

- I am not sure that a lower layer MUST NOT export keys passed down by
EAP methods to other lower layers.  It should at least be possible for a
lower layer to export keys derived from keys passed down by EAP methods
to other lower layers.

- The EMSK MUST NOT be exported to a lower layer.  AMSKs derived form
the EMSK may be exported. 

Section 2.7

-  I don't quite understand the goal of this section.  It is called
naming, but the section talks about securely verifying names which is
somewhat different.  What is this section trying to accomplish?

Section 2.8 

- paragraph 8 - the last sentence " As demonstrated in
   [I-D.ietf-roamops-cert], in this case it is still possible to support
   roaming between providers, using certificate-based authentication."
seems out of context.  

Joe