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

[Jari Arkko (jari.arkko]

Salowey, Joe wrote:

> 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).
>  
I think it is a simplifying assumption that at least for
me clarifies what the situation is when parties utilize
the link for data traffic. But let me turn this around:
can you cite an example where it would be useful to
NOT assume this?

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

> Section 2.5
>
> - I thought we were deprecating IV, should we mention it here?
>  
Yes.

> - 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.
>  
I think we converged earlier on "lifetime is a system
default". I'd rather not reopen that discussion.

> - Is methodID defined elsewhere?  Is it a value exported by the EAP
> method that uniquely identifies a particular execution of the EAP
> method?
>  
Appendix B.

--Jari