Status of the proposed EAP WG?

Hello Bernard.

After the EAP BOF in Minneapolis not much has been said about what
happens next. 

Given that the results of the BOF were not that clear, at least to me,
in terms of what we agreed on for the charter, does anybody have any
news on what is going to happen next? Is there going to be an EAP BOF-2
in Yokohama?

Thanks
Luca

EAP Status Update

EAP BOF REPORT

The minutes of the EAP BOF at IETF 53 have been posted at:

http://www.drizzle.com/~aboba/EAP/eapbof.txt
http://www.drizzle.com/~aboba/EAP/presentations.zip

As noted in the BOF minutes, there was widespread agreement that an EAP WG
should be formed. Discussion relating to the strawman charter (see
below) occurred both during the EAP BOF, and to some extent, afterwards,
as individuals have posted their views on the charter to the ADs. We can
continue that discussion on this list, so as to get closer to agreement on
it.

PROGRESS REPORT ON RFC 2284bis and RFC 2869bis

The latest drafts are available here:

http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-04.txt
http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-01.txt
http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-01.txt

Current issues with RFC 2284bis are tracked here:

http://www.drizzle.com/~aboba/EAP/eapissues.html

In terms of progress on RFC 2284bis and RFC 2869bis, we seem to be moving
along at a reasonable pace. As noted in the RFC 2284bis issues list, the
open issues include:

Issue #21: Editorial issues in RFC 2284bis-04

Issue 21: Editorial issues with RFC 2284bis-04
Submitter: Jesse Walker
Submitter email address: jesse.walker <at> intel.com
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-04
Comment type: E
Priority: S
Section: 2, 2.1, 4.2, 9.1, 9.8
Rationale/Explanation of issue:

Section 2, page 5 says under "Advantages":

The EAP protocol can support multiple authentication mechanisms
without having to pre-negotiate a particular one.

Certain devices (e.g. a NAS, switch or access point) do not
necessarily have to understand each request type and may be able to
simply act as a pass-through agent for a "back-end" server on a host.
The device only need look for the success/failure code to terminate
the authentication phase.

A third advantage of EAP might be noted. The separation of authentication
from the point of access simplifies credentials management and policy
decision making.

Section 2, page 5 also says under "Disadvantage":

For use in PPP, EAP does require the addition of a new authentication
type to PPP LCP and thus PPP implementations will need to be modified

questions/comments on draft-walker-aaa-key-distribution-00.txt

Editorial nit: the first page headers seem misaligned (in my copy).

Section 2, paragraph 2 says "The purpose of NASREQ key distribution is to 
securely establish a  session key between the NAS and the NAS 
client."  While this true in a general way, a more precise characterization 
might be that the purpose is to securely _inform_ the NAS of session keys 
which have been derived without its knowledge, possibly as a side-effect of 
a successful EAP authentication.

Section 2, paragraph 3 seems to come to some reasonable conclusions, but 
for the wrong reasons.  For example, it says: "[NASREQ] allows the AAA 
server to distribute a key to the NAS client using EAP, but does not 
specify how this is accomplished."  Actually, this is a mistake in the 
NASREQ draft: instead of saying (in Section 2.1.2) "The keys MAY be 
distributed to the user as part of an EAP authentication exchange." it 
should actually say nothing at all, or maybe something like "The means by 
which the user obtains the keys is outside the scope of this document.", 
because it is.

Paragraph 3 continues: "EAP fails to specify mechanisms.  As a result, all 
mechanisms assume that the AAA server and the NAS client already share a 
key that may be used directly to protect the link between the NAS and the 
NAS client, and so it is unnecessary to distribute any key to the NAS 
client.  Since no specified instances of EAP key distribution to the NAS 
client exist, the implicit assumption has to be that such mechanisms are 
unimportant...".  Actually, the is another assumption possible, though not 
particularly implicit: that EAP types which offer key derivation will 
provide it in a fashion that makes distribution to the NAS client 
unnecessary.  In fact, that's just what has happened: virtually all EAP 
types that provide for key derivation do so in a such a way that only the 

Issue 22: Issues with mandatory to implement method

Issue 22: Issues with mandatory to implement method
Submitter: Jesse Walker
Submitter email address: jesse.walker <at> intel.com
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-04
Comment type: T
Priority: S
Section: 5.4
Rationale/Explanation of issue:

Here is an example where we should note that using EAP unchanged
can be a more of a danger than a help in some new environments. Section
5.4 says of MD5-Challenge on page 16:

All EAP implementations MUST support the MD5-Challenge mechanism.

While this might make sense for legacy dial-in environments (does it
really? how many times have you seen someone cable their PC modem to their
cell-phone in an airport?), it does not for wireless LANs in particular,
where MD5-Challenge is simply a credentials publication mechanism when a
password is used, and always subject to man-in-the-middle attacks, even if
a key rather than a password is somehow used. These problems should be
explicitly noted, and we need to develop wide understanding of the
problem.

Issue 23: Contents of Identity Request Payload

Issue 23: Contents of Identity Request Payload
Submitter: Jesse Walker
Submitter email address: jesse.walker <at> intel.com
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-04
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:

Section 5.1 page 13 describes the Identity Type thusly:

The Identity Type is used to query the identity of the peer.
Generally, the Authenticator will issue this as the initial Request.
An optional displayable message MAY be included to prompt the Peer in
the case where there expectation of interaction with a user. A
Response MUST be sent to this Request with a Type of 1 (Identity).

This language is good as far as it goes, but I wonder if more formal rules
should be specified to enable the more mobile enviroments where EAP is
being applied? What I have in mind is that it is likely that many (most?)
users/devices will have different sets of credentials for many of the
security domains they visit. Each of these credentials will assign to the
user/device a different artificial and arbitrary "identity".

In the wireless roaming case, it is likely that a user will sometimes
cross domain boundaries without even knowing it, so the commonly cited
industry goal of "seamless" roaming would imply that the Identity Request
from the Authenticator should provide some hint as to which "identity" it

Issue 24: EAP and ciphersuite negotiation

Issue 24: EAP and ciphersuite negotiation
Submitter: Jesse Walker
Submitter email address: jesse.walker <at> intel.com
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

Issue 25: Spoofing and duplicate detection

Issue 25: Spoofing and duplicate detection
Submitter: Jesse Walker
Submitter email address: jesse.walker <at> intel.com
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-04
Comment type: T
Priority: S
Section: 9.3
Rationale/Explanation of issue:
Section 9.3 page 23, point 1 says:

Silent discard. Since only a single EAP Request can be in progress
between an Authenticator and a Peer at a given time, if a Peer
receives a new Request before sending a Response, the new Request
can be silently discarded. This increases resilience against
spoofed Requests. Similarly, an Authenticator can silently discard
Responses with Identifiers that do not correspond to the Identifier
included in the last Request, or that represent duplicate
Responses.

This advice seems effective only if both the Authenticator and the Peer
respond significantly more rapidly than does the active attacker, or their
responses are delivered more expeditiously than the attacker's, i.e., you
can't depend on it. The Success and Negotiate messages in particular
require their own protection. I suggest noting this method does not work
except in very constrained environments because of the race conditions
cited.

Extensible Authentication Protocol State Machine (fwd)

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Extensible Authentication Protocol State Machine
	Author(s)	: B. Payne, N. Petroni
	Filename	: draft-payne-eap-sm-00.txt
	Pages		: 11
	Date		: 09-May-02
	
The specification for the Extensible Authentication Protocol (EAP) [2]
omits a state machine description.  This omission has led to ambiguity
in the specification and potential security problems in EAP
implementations.  This document outlines a state machine to be
integrated into the next revision of the EAP RFC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt

[Question] Is there an EAP method type for EAPOL Key descriptor?