eap Mailing List: Proposed Resolution to Issue 277: Organization of Keying Draft

[Bernard Aboba (aboba]

While the organization of the keying draft has improved somewhat in -05,
some fundamental problems still exist.  In particular:

* The -05 draft mixes discussion of existing technology with analysis of
potential future extensions.  This results in confusion about how
current implementations behave.  For example, existing AAA servers do not
cache exported EAP keying material, nor do they create any long term EAP
security associations.  In addition they do not calculate AMSKs.  Yet
these topics are covered without clarifying what applications they apply
to.

* The -05 draft, while talking vaguely about potential extensions,
does not thoroughly analyze them.  This is problematic because it may
create confusion about the proposals themselves, retarding progress; also,
it does not satisfy the original intent behind the keying framework
document, which was to demonstrate the security properties of EAP usage.

In order to address these issues, I would like to propose that we split
the Keying Framework into two separate documents, each with different
objectives:

1. A Key Management Framework document focussed on explaining and
analyzing current technology.  This would focus on usage within existing
applications, such as Diameter EAP, 802.11i, etc.  The guideline here is
that if something is not done by existing EAP peers, servers and
authenticators then it needs to be removed.  Another goal of the document
is to explain clearly the behavior of existing implementations and analyze
the security implications.

2. An additional document on EAP Key Management extensions.  This document
would take as input material supplied by other IETF WGs and SDOs
(such as 802.11r).  The goal would be to clearly define extensions
meeting the needs of the other WGs and SDOs, as well as demonstrating that
the extensions satisfy the security requirements outlined by the security
ADs.  Among other things, this document would include the definition of
the AMSK.

Assuming this split makes sense to the WG, we can proceed to work through
in more detail what portions of -05 would go into which document.  We will
also need to think more about the process by which we solicit input from
other WGs and SDOs for inclusion in extension document.