eap Mailing List: RE: Purpose of the eap-keying document: a straw poll?

[Joseph Salowey (jsalowey]

I agree that splitting the document might be useful, however I'm not sure
that 6 documents will be more useful.  I think it would be useful to have a
normative document and informative as you indicate.  The normative document
just describes the basic expectations of EAP methods, EMSK usage and naming.
Then the informative documents would talk about EAP internals, PMK and how
it fits together in various scenarios.  

Joe

eap-admin [at] frascone.com wrote:
> Hi all,
> 
>  The more I think about eap-keying and the more items I add
> to my "issue
> laundry list" (BTW, many thanks to Bernard for the tracking
> he's doing),
> the more I get the feeling that we should perhaps get a broader view
> (and the more I fear that people will put filters on their
> mail clients
> ;-)).
> 
> Namely, what is the point in the eap-keying document?
> 
> My view is that it has the potential to be an excellent and
> useful piece
> of work... but IMHO:
> * It is quite long to read (73 pages)
> * It is challenging technically (potential readers should better be
> versed in EAP, EAP methods, IEEE 802.11i, RADIUS, etc.)
> * It deals with many different topics
> 
> I, for myself, distinguish between the following parts:
> 
> * key naming - i.e. how to unambiguously refer to the
> numerous keys that
> have to do with EAP - this is very important and should be
> normative text
> 
> * EMSK usage - i.e. the AMSK scheme - this is very important
> and should
> be normative text
> 
> * EAP's place in protocol suites used to secure communications - i.e.
> somehow section 3 that says that EAP is an authenticated key exchange
> framework and that it is complemented by discovery and security
> associations protocols - this is rather informative
> 
> * EAP usage in multiparty scenarios - i.e. how to fix the
> mess that was
> created by using a two-party protocol (EAP) in a three-party scenario
> (supplicant, authenticator and authentication server),
> somehow section 5
> - this is rather informative
> 
> * EAP handoffs - i.e. how to leverage the hooks that EAP may provide,
> namely fast reconnect and EMSK, to perform handoffs and how to do
> context transfer, somehow section 4 - this is a hot topic (see IEEE
> 802.11r for related work) but rather informative
> 
> * EAP key lifetime - here, we probably want to discuss things
> a little
> bit more, as things are quite challenging in that area (IKEv2
> has chosen
> not to deal with key lifetimes). The two questions, I'd start
> with: what
> do we want to with key lifetimes? Deal properly with them or
> not? If it
> is the first option, then we should probably make sure to specify a
> functional and correct way to do so (vague recommendations will IMO
> equal the second option in the end)
> 
> I think that to maximize the benefits of the great work that has been
> done on eap keying, we could split the current document in as
> many as 6
> documents, for instance (by chronological order of expected
> publication) 
> 
> 1) EMSK usage - normative, i.e. standards track
> 2) Naming EAP keys - normative, i.e. standards track, would recap the
> EMSK/AMSK naming scheme explained in 1 and would specify the MSK and
> AAA-key naming scheme 3) EAP handoffs - informational (this would
> reseparate this 
> section back
> to an independent document, which is how it was originally submitted
> draft-aboba-context-802 IIRC) 4) EAP's place in protocol suites -
> informational 5) EAP usage in multiparty scenarios - informational
> 6) EAP key lifetimes - informational or normative TBD
> 
> Thus, we would improve the overall readability and be able to
> focus on
> priority parts.
> My fear is that few people will actually read and use the
> eap-keying as
> is - and that given the little number of reviews it may have got, its
> final quality will not reflect all the excellent ideas
> 
> Bernard, Jari, could we make a straw poll on:
> 1) how many people have read (more than a few pages of ) the actual
> eap-keying document 2) how many people think that splitting it could
> improve its usefulness and the way we get the work done
> 
> Florent, hope this helps
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap