Subject: [eap] Purpose of the eap-keying document: a straw poll?

From: Florent Bersani <[email-masked]>
Date: Mon, 04 Oct 2004 16:16:54 +0200

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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Oct 2004 23:37:09 +0300

First, thanks Florent for your extensive review and
observations!

Then to the specific issues: I think you raised
an important point about the normative status of
some of the parts of this document. This needs to be
discussed. As for the split vs. keep it all together:
one of the things that this document contributes is supposed
to be a system level security analysis of how the whole thing
works securely, something that isn't readily available elsewhere.
So I personally believe there's some value in keeping it in
one place.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 4 Oct 2004 20:59:58 -0700

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

[email-masked] wrote:
> AAA-key naming scheme 3) EAP handoffs - informational (this would
> reseparate this 
> section back
> draft-aboba-context-802 IIRC) 4) EAP's place in protocol suites -
> informational 5) EAP usage in multiparty scenarios - informational
> 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