Subject: [eap] Proposed Resolution to Issue 58: Accept

From: [email-masked] (Bernard Aboba)
Date: Wed, 8 Jan 2003 03:34:13 -0800 (PST)

Here are the proposed changes to resolve Issue 58: Miscellaneous -08 NITs:

"protocol" to "framework" in the Abstract and Section 1.

"error" to "event" in Section 1.2 under "silent discard"

Sentence involving "and and" has been struck due to rewrite
of that section.

Change "IEEE 802" to "IEEE 802 wired media" throughout the
document, where wired LANs are intended to be referenced (many places).

Text involving "application specific" is removed in -09, due
to rewrite of vendor specific section.

Add the following text at the end of section 7.11:

However, some general guidelines can be provided:

1. Master Session Keys and Transient Session Keys MUST be a fresh.
Otherwise it is infeasible to detect messages replayed from prior
sessions.

2. The Master Key is for use only by the EAP authenticator and peer and
MUST NOT be exported by the EAP method or provided to a third party.

3. Session keys used for different purposes MUST be cryptographically
independent from each other so that if an attacker obtains
one of the session keys, it will not have gained information useful
in determining other ones.

4. There MUST be a way to determine whether transient session keys belong
to this or to some other session.

5. It is important that MSKs derived by EAP methods be bound to the
peers as well as to the authentication method, so as to avoid a
man-in-the-middle attack (see Section 7.5).

----------------------------------------------------------------
Issue 58: Miscellaneous -08 NITs
Submitter name: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: January 3, 2003
Document: RFC2284bis-08
Comment type: T,E
Priority: S
Section: Various
Rationale/Explanation of issue:
Pages 1 (Abstract), 3 (Introduction): The text still speaks of EAP as an
"authentication protocol". It is not since in and of itself it performs no
authentication. How about "authentication protocol transport"?

Page 3: In the definition of "Silently Discard, a sentence begins:

The implementation SHOULD provide the capability of logging
the error

There is an implicit assumption in this sentence that silently discard
occurs only in response to an error. This should be made explicit or else
the assumption removed.

Page 16: The phrase "and and" appears.
Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym for "IEEE 802
wired networks" Please clean this up.

Page 23 has the language "application specific" which is not wrong per se
but does appear to be misleading. Can we replace this with "vendor
specific", since that is what the text is talking about?

Page 32 Clause 7.11 says that

This specification does not provide guidance on how EAP
methods are to derive keys.

I think it is possible to give some general but practical guidelines:

a. the key MUST be a fresh, never-before used key, because otherwise it is
in general infeasible to use the key to detect messages replayed from
prior sessions.

b. there MUST be some way to name the key, to determine whether it belongs
to this or to some other session.

c. the key is an authorization token (use of the key demonstrates
authorization to access the channel), so the relation of the key to the
authentication that authorized this key MUST be made explicit to
understand the security relationship of the key to the EAP method.

d. in the case where more than authentication method is used (think of
PEAP or TTLS, not the approach complained about on page 5 and 31) and more
than one method derives keys, then the method description MUST indicate
which keys are distributed for use by the Authenticator and Peer, and how.
For instance, in the PEAP/TTLS case, the key derived by the inner method
could be combined using a pseudo-random function with the TLS key to
cryptographically bind the inner and outer keys, and this combined key
would be used by the Authenticator and Peer.

I would also like to see the following two additional guidelines, but they
may be more controversial, so I will not insist:

e. When the purpose of the authentication is to authorize use of the data
link channel between the Peer and the Authenticator, to understand its
security one needs to know how the derived key is bound to the channel, so
that (ab)use of it in other contexts can be detected. It would be nice if
the method could (SHOULD?) provide guidance on this issue, e.g., specify
the assumptions it makes about how this binding occurs.

f. When the Authenticator and Authentication Server are not the same
party, one needs to understand how the key is distributed to the
Authenticator (and to the Peer, if it needs to be transported) to
understand the security properties of the key. It would be nice if the
method could (SHOULD?) provide guidance about this, e.g., specify the
assumptions it makes about how key distribution is effected.

-- Jesse