Subject: [eap] Issue 24: EAP and ciphersuite negotiation

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 May 2002 17:58:47 -0700 (PDT)

Issue 24: EAP and ciphersuite negotiation
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-04
Comment type: T
Priority: S
Section: 9.8
Rationale/Explanation of issue:

The seventh paragraph of Section 9.8 says:

However, EAP methods deriving keys SHOULD provide keying material
that can be used with any ciphersuite, since EAP methods cannot be
assumed to provide protected ciphersuite negotiation and the
negotiated ciphersuite may not be known beforehand.

I think what this is really trying to say is that if EAP distributes any
keys, the distributed keys should be master keys, used only for further
key derivation, independent of the cipher suite, because it is
unreasonable for the Authenticator to know the details for deriving keys
for every cipher suite. This is a reasonable requirement.

However, this is not what the text says. It says that we shouldn't use EAP
for cipher suite negotiation. This position undercuts the Authenticator's
role as the policy decision point, i.e., it undercuts EAP's own rationale.

An architecture using EAP could include cipher suite registration with the
Authenticator. If this were done, there is no reason why it an EAP method
cannot negotiate the cipher suites to be used with a key, and if it does,
why the Authenticator cannot specify the "best" cipher suite to use on the
basis of the capabilities of the communicating peers that best match each
other and local policy; in fact, this seems like a desirable property, to
allow the Authenticator to deny service when an acceptable cipher suite
conforming to policy cannot be found. The Authenticator could delegate
this task the NAS, but again this complicates the security analysis and
increases the total number of assumptions needed about the system.