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

[Florent Bersani (florent.bersani]

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