EAP Issues

Issue 100: User-Name in Access-Challenge and Access-Reject
Submitter name: Jo Hermans
Submitter email address: johan.rh.hermans@alcatel.be
Date first submitted: March 26, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000954.html
Document: RFC2869bis-10
Comment type: Technical
Priority: S
Section: 2.1
Rationale/Explanation of issue:

Paragraph 2.1 (Protocol Overview) mentions the attributes that should be
present in acces-challenges and access-rejects :

>The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in
>the Access-Request packet, and either NAS-Identifier or NAS-IP-Address
>attributes MUST be included. In order to permit forwarding of the
>Access-Reply by EAP-unaware proxies, if a User-Name attribute was
>included in an Access-Request, the RADIUS server MUST include the User-
>Name attribute in subsequent Access-Challenge, Access-Accept or Access-
>Reject packets. Without the User-Name attribute, accounting and billing
>becomes difficult to manage. If the identity is determined by another
>means, such as the Calling-Station-Id, the NAS MUST include these
>identifying attributes in every Access-Request, and the RADIUS server
>MUST copy these identifying attributes into subsequent Access-Challenge,
>Access-Accept or Access-Reject packets.
>
But table 3.3 doesn't allow User-Name in access-challenges and
access-rejects. That would be in violation of RFC2865 too.

>Request Accept Reject Challenge # Attribute
>0-1 0-1 0 0 1 User-Name
>
>
Requested change:

Either change paragraph 2.1 to :

The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in
the Access-Request packet, and either NAS-Identifier or NAS-IP-Address
attributes MUST be included. In order to permit forwarding of the
Access-Reply by EAP-unaware proxies, if a User-Name attribute was
included in an Access-Request, the RADIUS Server MUST include the
User-Name attribute in subsequent Access-Accept packets. Without the
User-Name attribute, accounting and billing becomes very difficult to
manage. If the identity is determined by another means, such as the
Calling-Station-Id, the NAS MUST include these identifying attributes in
every Access-Request, and the RADIUS server MUST copy these identifying
attributes into subsequent Access-Accept packets.

or change table 3.3 to :

Request Accept Reject Challenge # Attribute
0-1 0-1 0-1 0-1 1 User-Name

--
Jo Hermans

[BA] -- We'll prohibit User-Name in Access-Challenge and Access-Reject in RFC2869bis-11.

Issue 101: EAP Identifier Conflict
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: April 4th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001000.html
Document: RFC 2869bis-11
Comment type: T
Priority: S
Section: 2.1 and others?
Rationale/Explanation of issue:

There seems to be a potential issue with EAP packet Identifiers
in 2869bis.

Suppose that the EAP conversations is started by NAS
(e.g. Identity request, possible followed by something else)
and then continues as pass-through. When sending its first
EAP Request, the RADIUS server must choose an Identifier value
different from the previous packet sent by the NAS (otherwise
the client will simply retransmit).

If the first Access-Request sent by NAS contains an EAP
Response, the AAA server can look at that packet's identifier
and choose a different one. However, if it only contains
EAP-Start, a conflict can occur (if the NAS already sent
something to the client).

This can happen, e.g. "The NAS also MAY send an Access-Request
packet containing an EAP-Start if, after sending an initial
Request for an authentication Type, the peer responds with a
Nak" (2869bis-11, section 2.1).

I see several possible ways how this could be resolved:

- Specify some way for the NAS to transmit its previous
Identifier value to RADIUS server.
- Allocate Identifier space so that conflicts don't occur (e.g.
NAS uses only values 0-127, RADIUS server starts with >128).
- Always compare whole packets, not just Identifiers (a big
change to RFC 2284, so probably not feasible).

There might be other solutions, too. The second one looks
the simplest to me, but is it a reasonable change?

Best regards,
Pasi

[BA] RFC 2284bis-12 will incorporate approach #1 (send EAP-Response/Nak)

Recommended resolution: Accept

Issue 102: Fragmentation: RADIUS obligation to Framed-MTU
Submitter name: Tom Bonacci
Submitter email address: bonacci@ascend.com
Date first submitted: April 4th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001005.html
Document: RFC 2869bis-11
Comment type: Technical
Priority: S
Section: 2.4
Rationale/Explanation of issue:

The "Fragmentation" section, 2.4, reads in relevant part:
"... the Framed-MTU attribute may be included in an
Access-Request packet containing an EAP-Message
attribute so as to provide the RADIUS server with this
information."

Does this (or should this) imply any obligation on the part of the
RADIUS server to observe the value forwarded by the NAS? The current
wording indicates the NAS MAY provide this information but is silent on
how the RADIUS server is to properly react upon its receipt in an
Access-Request packet.

Possible resolution:
Augment the above with
"... the Framed-MTU attribute MAY be included in an
Access-Request packet containing an EAP-Message
attribute so as to provide the RADIUS server with this
information. A RADIUS server having received a Framed-MTU
attribute in an Access-Request packet MUST NOT send any
subsequent packet in this EAP conversation containing
EAP-Message attributes whose values, when concatenated,
exceed the length specified by the Framed-MTU value."

The above wording implies strict obligation on the part of the RADIUS
server to observe the Framed-MTU value. If strict obligation is not
what's intended or desired, then the wording may be modified accordingly.

regards,
-tom

Recommended resolution: Accept

Issue 103: Timeouts
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: April 7th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001010.html
Document: RFC 2869bis-13
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:

We've been working on pass-through/back-end state diagrams
with John, Nick, and Yoshiro, and I noticed one more issue
in 2869bis that at least needs clarification:

Section 2.1 says that "Success and Failure packets MUST
NOT be sent as the result of a timeout."

Does this mean that as the result of a timeout, the NAS
must not "manufacture" an EAP Failure packet, but simply end
the conversation, right? And "timeout" here applies to both
peer<->NAS and NAS<->RADIUS server communication?

(In the case of peer<->NAS timeout, it probably does not make
sense to send Failure since most likely it will be lost, too,
but in NAS<->RADIUS timeout it could make sense.)

If my interpretation was correct, maybe this could be rephrased
something like "The NAS MUST NOT "manufacture" a Success or Failure
packet as a result of a timeout. After a suitable number of timeouts has
elapse, the NAS SHOULD simply end the EAP conversation."

Best regards,
Pasi

Proposed Resolution: Accept

Issue 104: Sequence Prohibition
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 14th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001017.html
Document: EAP-01
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:

At IETF 56, it was proposed that sequences of EAP methods MUST NOT be
supported (with an exception for tunneled EAP methods). The following text
changes support that proposal.

Change Section 2.1 from:

" 2.1 Support for sequences

An EAP conversation MAY utilize a sequence of methods. A common
example of this is an Identity request followed by a single EAP
authentication method such as an MD5-Challenge. However, within or
associated with each EAP server, it is not anticipated that a
particular named peer will utilize multiple authentication methods
(Type 4 or greater), either by supporting a choice of methods or by
using multiple methods in sequence. This would make the peer
vulnerable to attacks that negotiate the least secure method from
among a set (negotiation attacks, described in Section 7.8) or
man-in-the-middle attacks (described in Section 7.4). Instead, for
each named peer there SHOULD be an indication of exactly one method
used to authenticate that peer name. If a peer needs to make use of
different authentication methods under different circumstances, then
distinct identities SHOULD be employed, each of which identifies
exactly one authentication method. If additional authentication
methods are required beyond the initial one, the authenticator MAY
send a Request packet for a subsequent authentication method, or it
MAY send another Identity request. If the peer does not support
additional methods, it SHOULD respond with a Nak, indicating no
acceptable alternative, as described in Section 5.3. However, peer
implementations MAY not respond at all, in which case a timeout will
result and authentication will fail. Since the authenticator
presumably requires successful completion of the sequence in order to
grant access, authentication failure is the correct result.
Therefore, it is not necessary for the authenticator to determine
that the peer supports sequences prior to sending a Request for a
subsequent authentication method.

The above prescription also applies in the situation where an
authenticator sends a message of a different Type prior to completion
of the final round of a given method. If the peer wishes to continue
authenticating with the method in progress, it SHOULD send a Nak in
response to such a Request, indicating the Type in progress as the
alternative. Otherwise it MAY send a Response with the same Type as
the Request. Since an EAP packet with a different Type may be sent
by an attacker, an authenticator receiving a Nak including a
preference for the Type in progress SHOULD log the event, but
otherwise not take any action.

Once a peer has sent a Response of the same Type as a Request, some
existing peer implementations might expect the method to run to
completion. As a result, these implementations silently discard EAP
Requests of a Type different from the method in progress, despite the
requirement for a Response in Section 4.1. For this reason, EAP
authenticators that must interoperate with these peers are
discouraged from switching methods before the final round of a given
method has completed."

To:

"2.1 Support for sequences

An EAP conversation MAY utilize a sequence of methods. A common example of this is an Identity request followed by a single EAP authentication method such as an MD5-Challenge. However the peer and authenticator MUST utilize only one authentication method (Type 4 or greater) within an EAP conversation, after which the authenticator MUST send a Success or Failure packet.

Once a peer has sent a Response of the same Type as the initial Request, an authenticator MUST NOT send a Request of a different Type prior to completion of the final round of a given method (with the exception of a Notification-Request) and MUST NOT send a Request for an additional method of any Type after completion of the initial authentication method; a peer receiving such Requests MUST treat them as invalid, and
silently discard them. As a result, Identity Requery is not supported.

Supporting multiple authentication methods within an EAP conversation would add complexity to the EAP protocol, would enable man-in-the-middle attacks (see Section 7.4), and would result in interoperability problems, since existing EAP implementations typically do not support multiple authentication methods.

A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request, after an initial non-Nak Response has been sent. Since spoofed EAP Request packets may be sent by an attacker, an an authenticator receiving an unexpected Nak SHOULD silently discard it and log the event.

Where a single EAP authentication method is utilized, but other methods are run within it (a "tunneled" method) the prohibition against multiple authentication methods does not apply. Such "tunneled" methods appear as a single authentication method to EAP. Backward compatibility can be provided, since a peer not supporting a "tunneled" method can reply to the initial EAP-Request with a Nak (legacy or expanded). To address security vulnerabilities, "tunneled" methods MUST support protection against man-in-the-middle attacks.

Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods. This would make the peer vulnerable to attacks that negotiate the least secure method from among a set (negotiation attacks, described in Section 7.8). Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name. If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. "

Proposed Resolution: Accept

Issue 105: Multiplexing Clarification
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 17th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001028.html
Document: EAP-01
Comment type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:

Section 2.2 does not describe how EAP packets are
forwarded by a pass-through authenticator. This is
an area where there are known interoperability
problems (e.g. pass-through authenticators that
cannot handle any EAP method).

Change:

"2.2 EAP multiplexing model

Conceptually, EAP implementations consist of the following
components:

[a] Lower layer. The lower layer is responsible for transmitting and
receiving EAP frames between the peer and authenticator. EAP has
been run over a variety of lower layers including PPP; wired IEEE
802 LANs [IEEE.802-1X.2001]; IEEE 802.11 wireless LANs
[IEEE.802-11.1999]; UDP (L2TP [RFC2661] and ISAKMP [PIC]); and
TCP [PIC]. Lower layer behavior is discussed in Section 3.

[b] EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements the EAP state machine, and delivers
and receives EAP messages to and from EAP methods.

[c] EAP method. EAP methods implement the authentication algorithms
and receive and transmit EAP messages via the EAP layer. Since
fragmentation support is not provided by EAP itself, this is the
responsibility of EAP methods, which are discussed in Section 5.

The EAP multiplexing model is illustrated in figure 1 below. Note
that there is no requirement that an implementation conform to this
model, as long as the on-the-wire behavior is consistent with it.

Within EAP, the Type field functions much like a port number in UDP
or TCP. With the exception of Types handled by the EAP layer, it is
assumed that the EAP layer multiplexes incoming EAP packets according
to their Type, and delivers them only to the EAP method corresponding
to that Type code, with one exception.

Since EAP methods may wish to access the Identity, the Identity
Response can be assumed to be stored within the EAP layer so as to be
available to methods of Types other than 1 (Identity). The Identity
Type is discussed in Section 5.1.

+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+

| | | | | |

| ! | | | ^ | |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| EAP ! Layer | | EAP ! Layer |

| ! | | ! |

| (Nak, ! Success, | | (Nak, ! Success, |

| ! Failure, | | ! Failure, |

| ! Notification, | | ! Notification, |

| ! Identity) | | ! Identity) |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| Lower ! Layer | | Lower ! Layer |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

! !

+------------>-------------+

Figure 1: EAP Multiplexing Model

A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2.

The Nak method is utilized for the purposes of method negotiation.
Peers MUST respond to an EAP Request for an unacceptable Type with a
Nak Response. It cannot be assumed that the contents of the Nak
Response is available to another method. The Nak Type is discussed
in Section 5.3.

EAP packets with codes of Success or Failure do not include a Type,
and therefore are not delivered to an EAP method. Success and Failure
are discussed in Section 4.2.

Given these considerations, the Success, Failure, Nak Response and
Notification Request/Response messages MUST NOT used to carry data
destined for delivery to EAP authentication Types (4 or greater)."

To:

+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+

| | | | | |

| V | | | ^ | |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| EAP ! Layer | | EAP ! Layer |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| Lower ! Layer | | Lower ! Layer |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

! !

! Peer ! Authenticator

+------------>-------------+

Figure 1: EAP Multiplexing Model

Within EAP, the Type field functions much like a port number in UDP
or TCP. With the exception of Types handled by the EAP layer, it is
assumed that the EAP layer multiplexes incoming EAP packets according
to their Type, and delivers them only to the EAP method corresponding
to that Type code, with one exception.

Since EAP methods may wish to access the Identity, the Identity
Response can be assumed to be stored within the EAP layer so as to be
available to methods of Types other than 1 (Identity). The Identity
Type is discussed in Section 5.1.

A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2.

The Nak method is utilized for the purposes of method negotiation.
Peers MUST respond to an EAP Request for an unacceptable Type with
a Nak Response (legacy or expanded). It cannot be assumed that
the contents of the Nak Response is available to another method.
The Nak Type is discussed in Section 5.3.

EAP packets with codes of Success or Failure do not include a Type,
and therefore are not delivered to an EAP method. Success and Failure
are discussed in Section 4.2.

Given these considerations, the Success, Failure, Nak Response and
Notification Request/Response messages MUST NOT be used to carry data
destined for delivery to other EAP methods.

Where a pass-through authenticator is present, it forwards
packets back and forth between the peer and a backend authentication
server, based on the EAP layer header fields (Code, Identifier,
Length). Since pass-through authenticators rely on a backend
authenticator server to implement methods, the EAP method
layerheader fields (Type, Type-Data) are not examined as part of
the forwarding decision. The forwarding model is illustrated
in Figure 2. Compliant pass-through authenticator implementations
MUST by default be capable of forwarding packets from any EAP method.

Peer Pass-through Authenticator Authentication

Server

+-+-+-+-+-+-+ +-+-+-+-+-+-+

| | | |

|EAP method | |EAP method |

| Layer | | Layer |

| V | | ^ |

+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+

| ! | | | | | ! |

| ! | | +-----+-----+ | | ! |

| ! | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+

| ! | | ! | ! | | ! |

| ! | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+

! ! ! !

+-------->-----+ +------->------+

Figure 2: Pass-through Authenticator"

Proposed Resolution: Accept

Issue 106: No Changes Appendix
Submitter name: Henrik Lefkowetz
Submitter email address: henrik@lefkowetz.com
Date first submitted: April 24th, 2003
Reference:
Document: EAP-01
Comment type: E
Priority: S
Section: Appendix B
Rationale/Explanation of issue:

It is customary for a bis document to list the changes made from
the original.

Add the following text as Appendix B:

" This section lists the major changes between [RFC2284] and this
document. Minor changes, including style, grammar, spelling and
editorial changes are not mentioned here.

o The Terminology section (Section 1.2) has been expanded, defining
more concepts and giving more exact definitions.

o In Section 2, it is explicitly specified that EAP supports
sequences of methods, but not multiple authentication methods
within a single conversation. This is specified in Section 2.1.

o Also in Section 2, some requirements on the authenticator when
acting in pass-through mode have been made explicit.

o An EAP multiplexing model (Section 2.2) has been added, to
illustrate a typical implementation of EAP. There is no
requirement that an implementation conform to this model, as long
as the on-the-wire behavior is consistent with it.

o As EAP is now in use with a variety of lower layers, not just PPP
for which it was first designed, Section 3 on lower layer behavior
has been added.

o In the description of the EAP Request and Response interaction
(Section 4.1), it has been more exactly specified when packets
should be silently discarded, and also the behavior on receiving
duplicate requests. The implementation notes in this section has
been substantially expanded.

o In Section 4.2, it has been clarified that Success and Failure
packets must not contain additional data, and the implementation
note has been expanded. A subsection providing requirements on
processing of Success and Failure packets has been added.

o Section 5 on EAP Request/Response Types lists two new type values:
the Expanded type (Section 5.7), which is used to expand the type
value number space, and the Experimental type. In the Expanded
type number space, the new Expanded Nak (Section 5.3.2) Type has
been added. Clarifications have been made in the description of
most of the existing types. Security claims summaries have been
added for authentication methods.

o An IANA Considerations section (Section 6) has been added, giving
registration policies for the numbering spaces defined for EAP.

o The Security Considerations (Section 7) have been greatly
expanded, aiming at giving a much more comprehensive coverage of
possible threats and other security considerations."

Proposed Resolution: Accept

Issue 107: Missing definition of Experimental Type
Submitter name: Henrik Lefkowetz
Submitter email address: henrik@lefkowetz.com
Date first submitted: April 24th, 2003
Reference:
Document: EAP-01
Comment type: T
Priority: S
Section: 5.8
Rationale/Explanation of issue:

The Experimental Type is not defined. Add the following section:

" 5.8 Experimental

Description

The Experimental Type has no fixed format or content. It is
intended for use when experimenting with new EAP types. This type
MUST NOT be used for regular deployment of draft features.

Type

255

Type-Data

Undefined"

Proposed Resolution: Accept

Issue 108: Downgrade attacks on lower layer ciphersuite negotiation
Submitter name: Benoit de Boursetty
Submitter email address: benoit.deboursetty@francetelecom.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001045.html
Document: EAP-01
Comment type: T
Priority: 1
Section: 7.1 and 7.11
Rationale/Explanation of issue:

In section 3.1 on lower layer requirements, requirement 2 indicates a
need for physically insecure links to be used with per-packet integrity,
authentication and replay protection.

Although the problem of downgrading attack on EAP method negotiation is
identified in 7.8, I cannot find word about the issue of downgrading
attacks on ciphersuite negotiation for the lower layer ciphersuite.
However there is mention of weak lower-layer ciphersuites being a threat
to security, at least in section 7.1 #8 and in section 7.11.

I understand that in actual cases deployed now, there is no or little
lower layer ciphersuite negotiation. But to take an example,
self-admittedly PPP's MPPE is currently vulnerable to downgrading
attacks (cf. par. 2, section 9 of RFC 3078) and there is no proposed
workaround (apart from explicit client configuration).

Another way to function is that parts of the keying material resulting
from EAP can be used by the link layer to authenticate a negotiation
handshake afterwards (I would have thought Auth-RECV-Key and
Auth-SEND-Key, but according to the new Keying Framework draft I'm not
so sure).

In the short term, I suggest mentioning the issue in the Security
Considerations section, as well as the workaround of using EAP-provided
keying material to enable negotiation integrity protection ex-post.

In the longer term, it could be desirable that the lower-layer
handshakes be integrity-verified during EAP authentication, as a
"handshake integrity checking service" offered by some EAP methods --
just as they can provide now mutual authentication, keying material
generation etc. This is left to the consideration of the EAP charter.

In the meantime:

Suggested changes:

Section 7.1: adding point 9 following point 8:
"[9]. An attacker may attempt to perform downgrading attacks on
link-level ciphersuite negotiation in order to ensure that a weaker
ciphersuite is used subsequently to EAP authentication."

Section 7.11: adding following paragraph at the end of the section:
"Additionally, if the lower layer performs ciphersuite negotiation, it
should be understood that EAP does not provide by itself integrity
protection of that negotiation. Therefore, in order to avoid downgrading
attacks which would lead to weaker ciphersuites being used, clients
implementing lower layer ciphersuite negotiation SHOULD protect against
negotiation downgrading.

This can be done by enabling users to configure which are the acceptable
ciphersuites as a matter of security policy; or, the ciphersuite
negotiation MAY be authenticated using keying material derived from the
EAP authentication and a MAC algorithm agreed upon in advance by
lower-layer peers."

Proposed Resolution: Accept

Issue 109: Attacker or Adversary?
Submitter name: Benoit de Boursetty
Submitter email address: benoit.deboursetty@francetelecom.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001046.html
Document: EAP-01
Comment type: E
Priority: 1
Section: 7.1
Rationale/Explanation of issue:

In section 7.1, the word "adversary" and "attacker" are both used to
talk about the same kind of person. It is the only place in the draft
where "adversary" is used, every where else the word "attacker" is used.

Also all issues are "[attacker|adversary] may" but number 4 is a "might"
(offline attacks). Does it really seem less likely than other attacks?

Suggested Change:
Unless the above is a subtlety beyond my grasping of the English
language:
s/adversary/attacker/
s/might/may/ in issue 4

Proposed Resolution: Accept

Issue 110: Miscellaneous NITs
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001052.html
Document: EAP-02
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue:

Throughout the document:

EAP Methods => EAP methods
Method Type => method Type
type => Type
local users => local peers
pass through => pass-through
expanded Type => Expanded Type
method- specific => method-specific
Authenticator => authenticator

First page:
Expiration and submission dates are wrong. should be
April 2003 submission and October 2003 expiration. Please
change in the header and Status of this Memo sections.

Abstract is somewhat awkward. Change to:

"This document defines the Extensible Authentication Protocol
(EAP), an authentication framework which supports multiple
authentication methods. EAP typically runs directly over data link
layers such as PPP or IEEE 802, without requiring IP. EAP
provides its own support for duplicate elimination and retransmission,
but is reliant on lower layer ordering guarantees. Fragmentation
is not supported within EAP itself; however, individual EAP
methods may support this.

This document obsoletes RFC 2284. A summary of the changes between
this document and RFC 2284 is available in Appendix B."

Rewrite the first paragraph of Section 1 to:

"This document defines the Extensible Authentication Protocol
(EAP), an authentication framework which supports multiple
authentication methods. EAP typically runs directly over data link
layers such as PPP or IEEE 802, without requiring IP. EAP
provides its own support for duplicate elimination and retransmission,
but is reliant on lower layer ordering guarantees. Fragmentation
is not supported within EAP itself; however, individual EAP
methods may support this."

In third paragraph of section 1:
"specific authenticaiton mechanism(s) to be used" =>
"specific authentication method to be used"

"some or all methods and users" => "some or all methods and peers"

Section 1.2

Move Security Claims Terminology to its own Section 1.3.

Section 2

"Devices (e.g. a NAS, switch or access point) do not have
to understand each authentication method and MAY act as
a pass-through agent"

To:

Network Access Server (NAS) devices (e.g. a switch or access point)
do not have to understand each authentication method and
MAY act as a pass-through agent"

Last paragraph of Section 2.1 "Without or associated..." should be
moved to section 7.8 after the last paragraph there. See Issue 113.

Section 3.2

"Authentication- Protocol" => "Authentication Protocol"
"back- end server" => "backend authentication server"

Section 3.2.1

"the EAP Authentication Protocol" => "EAP"

"PPP Extensible Authentication Protocol" => "Extensible Authentication Protocol"

Section 3.4

"link layer" => "lower layer"

medium => "lower layer"

Last paragraph "In IEEE 802.11 a..." should be moved to after the last paragraph of 7.12. See Issue 113.

Section 2.2, figure 2:

The "!" symbols are not aligned correctly -- they need to be moved to the right 3 spaces.

Section 4.1:

Change

"However, there is
also a Nak Response Type for indicating that a Request type is
unacceptable to the peer. An initial specification of Types
follows in a later section of this document."

To:

"However, there are
also Nak Response Types for indicating that a Request Type is
unacceptable to the peer (see Section 5.3). An initial specification of Types
follows in Section 5 of this document."

Section 4.2.1:

"Processing of success and failure" should be "Processing of Success and Failure"

Section 5

"where there expectation" => "where there is an expectation"

Section 5.3.2 under Identifier

"a Expanded Nak Response" => "an Expanded Nak Response"

In Section 5.4, 5.5, and 5.6, change

"or Type 3 (Nak)" => "Nak (Type 3) or Expanded Nak (Type 254)"

Section 5.7, under "Vendor-Type"

"If Vendor-Id is zero" => "If the Vendor-Id is zero"

Section 8:

Please change to the following:

"This protocol derives much of its inspiration from Dave Carrel's AHA
draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback
was provided by Yoshihiro Ohba of Toshiba America Research, Jari
Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco
Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan Payne
of the University of Maryland, Steve Bellovin of AT&T Research,
Paul Funk of Funk Software and Pasi Eronen of Nokia."

Informative References

[RFC2869] version is now 20, date is April 2003.

Appendix A.1

"a fatal error.." => "a fatal error."

"a MIC validation failures" => "a MIC validation failure"

Appendix B, please add the following paragraphs:

"o In Section 5.5, support for OTP Extended Responses [RFC2243] has been
added to EAP OTP.

o Appendix A has been added on method-specific behavior, providing
guidance on how EAP method-specific integrity checks should be
processed."

Proposed Resolution: Accept

Issue 111: Lower Layer Requirements
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001053.html
Document: EAP-02
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:

This section says that a a lower layer CRC or checksum is not necessary,
but if it is absent there will be problems. Rewrite the section to the
following:

"3.1 Lower layer requirements

EAP makes the following assumptions about lower layers:

[1] Unreliable transport. In EAP, the authenticator
retransmits Requests that have not yet received Responses, so
that EAP does not assume that lower layers are reliable. Since
EAP defines it own retransmission behavior, when run over a
reliable lower layer, it is possible (though undesirable) for
retransmission to occur both in the lower layer and the EAP
layer.

Note that EAP Success and Failure packets are not retransmitted.
Without a reliable lower layer, and a non-negligible
error rate, these packets can be lost, resulting in timeouts.
It is therefore desirable for implementations to improve
their resilience to loss of EAP Success or Failure packets,
as described in Section 4.2.

[2] Lower layer error detection. While EAP does not assume that the
lower layer is reliable, it does rely on lower layer error detection
(e.g. CRC, Checksum, MIC, etc.). EAP methods may not include a MIC,
or if theydo, it may not be computed over all the fields in the EAP packet,
such as the Code, Identifier, Length or Type fields. As a result,
without lower layer error detection, undetected errors could
creep into the EAP layer or EAP method layer header fields,
resulting in authentication failures.

For example, EAP TLS [RFC2716], which computes its MIC
over the Type-Data field only, regards MIC validation failures
as a fatal error. Without lower layer error detection, this
method and others like it will not perform reliably.

[3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g. wired PPP or IEEE
802 links) or support per-packet authentication, integrity
and replay protection. EAP SHOULD NOT be used on
physically insecure links (e.g. wireless or the Internet)
where subsequently protected data is not protected by
per-packet authentication, integrity and replay protection.

After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order
to provide assurance that the peer transmitting data is the
same entity that successfully completed EAP
authentication, the lower layer needs to bind per-packet
integrity, authentication and replay protection to the
original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for
subsequent data traffic to be hijacked, or replayed.

Where keying material for the lower layer ciphersuite is itself
provided by EAP, typically the lower layer ciphersuite cannot be
enabled until late in the EAP conversation, after key derivation
has completed. Thus it may be possible to use the lower
layer ciphersuite only to protect a portion of the EAP
conversation, such as the EAP Success or Failure packet.

[4] MTU known a-priori. The EAP layer does not support fragmentation and
reassembly. However, EAP methods SHOULD be capable of handling
fragmentation and reassembly. As a result, EAP is capable of
functioning across a range of MTU sizes, as long as the MTU is
known a-priori. EAP does not support path MTU discovery.

[5] Possible duplication. Where the lower layer is reliable, it will
provide the EAP layer with a non-duplicated stream of packets.
However, while it is desirable that lower layers provide for
non-duplication, this is not a requirement. The Identifier field
provides both the peer and authenticator with the ability to
detect duplicates.

[6] Ordering guarantees. EAP does not require the Identifier to be
monotonically increasing, and so is reliant on lower layer
ordering guarantees for correct operation. EAP was
originally defined to run on PPP, and [RFC1661] Section 1 has an
ordering requirement:

"The Point-to-Point Protocol is designed for simple links which
transport packets between two peers. These links provide full-
duplex simultaneous bi-directional operation, and are assumed to
deliver packets in order."

Lower lower transports for EAP MUST preserve ordering between a
source and destination, at a given priority level (the
ordering guarantee provided by [IEEE.802.1990])."

Proposed Resolution: Accept

Issue 112: Rewrite of IANA Considerations
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001054.html
Document: EAP-02
Comment type: T
Priority: S
Section: 6.2
Rationale/Explanation of issue:

It is desirable to require a published RFC for EAP methods,
if possible. Rewrite Section 6.2 to the following:

"For registration requests where a Designated Expert should be consulted,
the responsible IESG area director should appoint the Designated Expert.
The intention is that any allocation will be accompanied by a published
RFC. But in order to allow for the allocation of values prior to the
RFC being approved for publication, the Designated Expert can approve
allocations once it seems clear that an RFC will be published
(e.g. on addition to the RFC Editor queue).

The Designated expert will post a request to the EAP WG mailing
list (or a successor designated by the Area Director) for comment
and review, including an Internet-Draft. Before a period of 30 days
has passed, the Designated Expert will either
approve or deny the registration request and publish a notice of the
decision to the EAP WG mailing list or its successor, as well as
informing IANA. A denial notice must be justified by an explanation
and, in the cases where it is possible, concrete suggestions on
how the request can be modified so as to become acceptable.

Packet Codes have a range from 1 to 255, of which 1-4 have been
allocated. Because a new Packet Code has considerable impact on
interoperability, a new Packet Code requires Standards Action, and
should be allocated starting at 5.

The original EAP method Type space has a range from 1 to 255, and is
the scarcest resource in EAP, and thus must be allocated with care.
method Types 1-41 have been allocated, with 20 available for re-use.
Method Types 42-191 may be allocated on the advice of a Designated
Expert, with Specification Required.

Allocation of blocks of method Types (more than one for a given
purpose) should require IETF Consensus. EAP Type Values 192-253 are
reserved and allocation requires Standards Action.

Method Type 254 is allocated for the Expanded Type. Where the
Vendor-Id field is non-zero, the Expanded Type is used for functions
specific only to one vendor's implementation of EAP, where no
interoperability is deemed useful. When used with a Vendor-Id of
zero, method Type 254 can also be used to provide for an expanded
IETF method Type space. Method Type values 256-4294967295 may be
allocated after Type values 1-191 have been allocated.

Method Type 255 is allocated for Experimental use, such as testing of
new EAP methods before a permanent Type code is allocated."

[Jari Arkko]:

"Seems clear" does not seem clear to me ;-) That is, I'm not sure
how the DE evaluates this condition. Can we be more specific?
An allocation is approved if the DE approves the method, and
the method description has been submitted as an Internet Draft?
Or has been submitted to the RFC Editor / IESG for publication?
Or WG / IETF LC started / finished?

(Specification Required might fit our requirements otherwise
well, but I think we wanted to get allocations slightly earlier
than it would mean. Then again RFC 2434 doesn't explicitly say
in which order things will happen.)

Proposed Resolution: Accept

Issue 113: Rewrite of Security Considerations Section
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001055.html
Document: EAP-02
Comment type: T
Priority: 1
Section: 7
Rationale/Explanation of issue:

Rewrite Section 7 to:

"7. Security Considerations

EAP was designed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE.802.1990] in
[IEEE.802-1X.2001]. On these networks, an attacker would need to
gain physical access to the telephone or switch infrastructure in
order to mount an attack. While such attacks have been documented,
such as in [DECEPTION], they are assumed to be rare.

However, subsequently EAP has been proposed for use on wireless
networks, and over the Internet, where physical security cannot be
assumed. On such networks, the security vulnerabilities are greater,
as are the requirements for EAP security.

This section defines the threat model and security terms and
describes the security claims section required in EAP method
specifications. We then discuss threat mitigation.

7.1 Threat model

On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:

[1] An attacker may try to discover user identities by snooping
authentication traffic.

[2] An attacker may try to modify or spoof EAP packets.

[3] An attacker may launch denial of service attacks by spoofing
lower layer indications or Success/Failure packets; by
replaying EAP packets; or by generating packets with overlapping
Identifiers.

[4] An attacker may attempt to recover the pass-phrase by mounting
an offline dictionary attack.

[5] An attacker may attempt to convince the peer to connect to an
untrusted network, by mounting a man-in-the-middle attack.

[6] An adversary may attempt to disrupt the EAP negotiation in order
cause a weak authentication method to be selected.

[7] An attacker may attempt to recover keys by taking advantage of
weak key derivation techniques used within EAP methods.

[8] An attacker may attempt to take advantage of weak ciphersuites
subsequently used after the EAP conversation is complete.

[9]. An attacker may attempt to perform downgrade attacks on the
lower layer ciphersuite negotiation in order to ensure that a weaker
ciphersuite is used subsequently to EAP authentication.

Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g. pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers. Where EAP is used
over the Internet, attacks may be carried out at an even greater
distance.

7.2 Security claims

In order to clearly articulate the security provided by an EAP
method, EAP method specifications MUST include a Security Claims
section including the following declarations:

[a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers.

[b] Mechanism. This is a statement of the authentication technology:
certificates, pre-shared keys, passwords, token cards, etc.

[c] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 1.2:
mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack
resistance, fast reconnect, man-in-the-middle resistance,
acknowledged result indications. The Security Claims section of
an EAP method specification SHOULD provide justification for the
claims that are made. This can be accomplished by including a
proof in an Appendix, or including a reference to a proof.

[d] Key strength. If the method derives keys, then the effective key
strength MUST be estimated. This estimate is meant for potential
users of the method to determine if the keys produced are strong
enough for the intended application.

The effective key strength SHOULD be stated as number of bits,
defined as follows: If the effective key strength is N bits, the
best currently known methods to recover the key (with
non-negligible probability) require an effort comparable to 2^N
operations of a typical block cipher. The statement SHOULD be
accompanied by a short rationale, explaining how this number was
arrived at. This explanation SHOULD include the parameters
required to achieve the stated key strength based on current knowledge
of the algorithms.

(Note: Although it is difficult to define what "comparable
effort" and "typical block cipher" exactly mean, reasonable
approximations are sufficient here. Refer to e.g. [SILVERMAN] for
more discussion.)

The key strength depends on the methods used to derive the keys.
For instance, if keys are derived from a shared secret (such as a
password or a long-term secret), and possibly some public information
such as nonces, the effective key strength is limited by the
strength of the long-term secret (assuming that the derivation
procedure is computationally simple). To take another example,
when using public key algorithms, the strength of the symmetric
key depends on the strength of the public keys used.

[e] Description of key hierarchy. EAP methods deriving keys MUST
either provide a reference to a key hierarchy specification, or
describe how Master Session Keys (MSKs) and Extended Master
Session Keys (EMSKs) are to be derived.

[f] Indication of vulnerabilities. In addition to the security claims
that are made, the specification MUST indicate which of the
security claims detailed in Section 1.2 are NOT being made.

7.3 Identity protection

An Identity exchange is optional within the EAP conversation.
Therefore, it is possible to omit the Identity exchange entirely, or
to use a method-specific identity exchange once a protected
channel has been established.

However, where roaming is supported as described in [RFC2607], it may
be necessary to locate the appropriate backend authentication server
before the authentication conversation can proceed. The realm
portion of the Network Access Identifier (NAI) [RFC2486] is typically
included within the Identity-Response in order to enable the
authentication exchange to be routed to the appropriate backend
authentication server. Therefore while the peer-name portion of the
NAI may be omitted in the Identity- Response, where proxies or relays
are present, the realm portion may be required.

7.4 Man-in-the-middle attacks

Where EAP is tunneled within another protocol that omits peer authentication,
there exists a potential vulnerability to man-in-the-middle attack.

As noted in Section 2.1, EAP does not permit sequences of
authentication methods. Were a sequence of EAP authentication
methods to be permitted, the peer might not have proof that
a single entity has acted as the authenticator for all
EAP methods within the sequence. For example,
an authenticator might terminate one EAP method, then forward the
next method in the sequence to another party without the peer's
knowledge or consent. Similarly, the authenticator might not have
proof that a single entity has acted as the peer for all EAP methods
within the sequence.

This enables an attack by a rogue EAP authenticator tunneling EAP to
a legitimate server. Where the tunneling protocol is used for key
establishment but does not require peer authentication, an attacker
convincing a legitimate peer to connect to it will be able to tunnel
EAP packets to a legitimate server, successfully authenticating and
obtaining the key. This allows the attacker to successfully establish
itself as a man-in-the-middle, gaining access to the network, as well
as the ability to decrypt data traffic between the legitimate peer
and server.

This attack may be mitigated by the following measures:

[a] Requiring mutual authentication within EAP tunneling mechanisms.

[b] Requiring cryptographic binding between the EAP tunneling protocol and the
tunneled EAP methods. Where cryptographic binding is supported, a
mechanism is also needed to protect against downgrade attacks
that would bypass it.

[c] Limiting the EAP methods authorized for use without protection,
based on peer and authenticator policy.

[d] Avoiding the use of tunnels when a single, strong method is available.

7.5 Packet modification attacks

While EAP methods may support per-packet data origin
authentication, integrity and replay protection, support is not provided
within the EAP layer.

Since the Identifier is only a single octet, it is easy to guess,
allowing an attacker to successfully inject or replay EAP packets.
An attacker may also modify EAP headers within EAP packets where the
header is unprotected. This could cause packets to be inappropriately
discarded or misinterpreted.

In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet (such as within
protocols supporting PPP, EAP or Ethernet Tunneling), this assumption
is no longer valid and the vulnerability to attack is greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used. Method-specific MICs may be used to provide
protection. Since EAP messages of Types Identity, Notification, and
Nak do not include their own MIC, it may be desirable for the EAP
method MIC to cover information contained within these messages, as
well as the header of each EAP message. For details, see Appendix A.

To provide protection, EAP also may be encapsulated within a protected
channel created by protocols such as ISAKMP [RFC2408] as is done in
[PIC] or within TLS [RFC2246]. However, as noted in Section 7.4,
EAP tunneling may result in a man-in-the-middle vulnerability.

7.6 Dictionary attacks

Password authentication algorithms such as EAP-MD5, MS-CHAPv1
[RFC2433] and Kerberos V [RFC1510] are known to be vulnerable to
dictionary attacks. MS-CHAPv1 vulnerabilities are documented in
[PPTPv1]; Kerberos vulnerabilities are described in [KRBATTACK],
[KRBLIM], and [KERB4WEAK].

Where EAP runs over lower layers which are not physically secure,
in order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 1.3)
SHOULD be used.

If an authentication algorithm is used that is known to be vulnerable
to dictionary attack, then the conversation may be tunneled within a
protected channel, in order to provide additional protection.
However, as noted in Section 7.4, EAP tunneling may result in a
man-in-the-middle vulnerability, and therefore dictionary attack
resistant methods are preferred.

7.7 Connection to an untrusted network

With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower layer
is not physically secure (such as where EAP runs over wireless media
or the Internet), the peer is vulnerable to a rogue authenticator. As
a result, where the lower layer is not physically secure, a method
supporting mutual authentication is RECOMMENDED.

In EAP there is no requirement that authentication be full duplex or
that the same protocol be used in both directions. It is perfectly
acceptable for different protocols to be used in each direction.
This will, of course, depend on the specific protocols negotiated.
However, in general, completing a single unitary mutual
authentication is preferable to two one-way authentications, one in
each direction. This is because separate authentications that are
not bound cryptographically so as to demonstrate they are part of the
same session are subject to man-in-the-middle attacks, as discussed
in Section 7.4.

7.8 Negotiation attacks

In a negotiation attack, the attacker attempts to convince the peer
and authenticator to negotiate a less secure EAP method. EAP does not
provide protection for Nak Response packets, although it is possible for a
method to include coverage of Nak Responses within a method-specific
MIC.

Within or associated with each authenticator, it is not anticipated
that a particular named peer will support a choice of methods. This
would make the peer vulnerable to attacks that negotiate the least
secure method from among a set. Instead, for each named peer there
SHOULD be an indication of exactly one method used to authenticate
that peer name. If a peer needs to make use of different authentication
methods under different circumstances, then distinct identities
SHOULD be employed, each of which identifies exactly one
authentication method.

7.9 Implementation idiosyncrasies

The interaction of EAP with lower layers such as PPP and
IEEE 802 are highly implementation dependent.

For example, upon failure of authentication, some PPP implementations
do not terminate the link, instead limiting traffic in Network-Layer
Protocols to a filtered subset, which in turn allows the peer the
opportunity to update secrets or send mail to the network
administrator indicating a problem. Similarly, while in [IEEE802.1X]
an authentication failure will result in denied access to the
controlled port, limited traffic may be permitted on the uncontrolled
port.

In EAP there is no provision for retries of failed authentication.
However, in PPP the LCP state machine can renegotiate the
authentication protocol at any time, thus allowing a new attempt.
Similarly, in IEEE 802.1X the Supplicant or Authenticator can
re-authenticate at any time. It is recommended that any counters used
for authentication failure not be reset until after successful
authentication, or subsequent termination of the failed link.

7.10 Key derivation

It is possible for the peer and EAP server to mutually
authenticate, and derive keys. In order to provide keying
material for use in a subsequently negotiated ciphersuite, an
EAP method supporting key derivation MUST export a
Master Session Key (MSK) of at least 64 octets, and
an Extended Master Session Key (EMSK) of at least 64 octets.

TheMSK and EMSK are not used directly to protect data;
however, they are of sufficient size to enable subsequent
derivation of Transient Session Keys (TSKs) for use with the
selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the MSK.
The EAP method is also responsible for the derivation of Transient
EAP Keys (TEKs) used for protection of the EAP conversation itself.

EAP methods provide Master Session Keys and not Transient
Session Keys so as to allow EAP methods to be ciphersuite and
media independent. Depending on the lower layer, EAP methods may
run before or after ciphersuite negotiation, so that the
selected ciphersuite may not be known to the EAP method. By
providing keying material usable with any ciphersuite, EAP
methods can used with a wide range of ciphersuites and media.

Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other. This is required because some
existing ciphersuites form TSKs by simply splitting the MSK to
pieces of appropriate length. Likewise, non-overlapping
substrings of EMSK MUST be cryptographically separate from
each other, and from substrings of the MSK.

The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to
derive any other keys. (This restriction will be relaxed in a
future document that specifies how the EMSK can be used.)

This specification does not provide detailed guidance on how EAP
methods are to derive the MSK, EMSK and TEKs, or how the TSKs are
to be derived from the MSK. Key derivation is an
art that is best practiced by professionals; rather than
inventing new key derivation algorithms, reuse of existing
algorithms such as those specified in IKE [RFC2409], or TLS
[RFC2246] is recommended.

Further details on EAP Key Derivation are provided within [KeyFrame].

[BA] Add the following reference to the Informative references:

Aboba, B. and D. Simon, "EAP Keying Framework",
draft-aboba-pppext-key-problem-07.txt
Internet draft (work in progress), May 2003.

7.11 Weak ciphersuites

If after the initial EAP authentication, data packets are sent
without per-packet authentication, integrity and replay protection,
an attacker with access to the media can inject packets, "flip bits"
within existing packets, replay packets, or even hijack the session
completely. Without per-packet confidentiality, it is possible to
snoop data packets.

As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended.

Additionally, if the lower layer performs ciphersuite negotiation, it
should be understood that EAP does not provide by itself integrity
protection of that negotiation. Therefore, in order to avoid downgrading
attacks which would lead to weaker ciphersuites being used, clients
implementing lower layer ciphersuite negotiation SHOULD protect against
negotiation downgrading.

This can be done by enabling users to configure which are the acceptable
ciphersuites as a matter of security policy; or, the ciphersuite
negotiation MAY be authenticated using keying material derived from the
EAP authentication and a MAC algorithm agreed upon in advance by
lower-layer peers.

7.12 Link layer

There exists a number of reliability and security issues with link
layer indications in PPP, IEEE 802 wired networks and IEEE 802.11
wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the physical medium.

[b] IEEE 802 wired networks. On wired networks, IEEE 802.1X messages
are sent to a non-forwardable multicast MAC address. As a result,
while the IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not
authenticated or integrity protected, only an attacker with
access to the physical link can spoof these messages.

[c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer indications
include Disassociate and Deauthenticate frames (link failure
indications), and Association and Reassociation Response frames
(link success indications). These messages are not authenticated
or integrity protected, and although they are not forwardable,
they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies that
while EAPOL-Start and EAPOL-Logoff messages may be authenticated
and integrity protected, they can be spoofed by an authenticated
attacker far from the target when "pre-authentication" is
enabled.

In IEEE 802.11 a "link down" indication is an unreliable indication
of link failure, since wireless signal strength can come and go and
may be influenced by radio frequency interference generated by an
attacker. To avoid unnecessary resets, it is advisable to damp these
indications, rather than passing them directly to the EAP. Since EAP
supports retransmission, it is robust against transient connectivity
losses.

7.13 Separation of authenticator and backend authentication server

It is possible for the EAP peer and authenticator to mutually
authenticate, and derive a Master Session Key (MSK) for a ciphersuite
used to protect subsequent data traffic. This does not present an
issue on the peer, since the peer and EAP client reside on the same
machine; all that is required is for the EAP client module to derive
and pass a Transient Session Key (TSK) to the ciphersuite module.

However, in the case where the authenticator and authentication server reside on
different machines, there are several implications for security.

[a] Authentication will occur between the peer and the authentication server,
not between the peer and the authenticator. This means that it is
not possible for the peer to validate the identity of the authenticator
that it is speaking to, using EAP alone.

[b] As discussed in [RFC2869bis], the authenticator is dependent on
the AAA protocol in order to know the outcome of an
authentication conversation, and does not look at the
encapsulated EAP packet (if one is present) to determine the
outcome. In practice this means that the AAA protocol spoken
between the authenticator and authentication server MUST support
per-packet authentication, integrity and replay protection.

[c] Where EAP is used over lower
layers which are not physically secure, subsequent to completion of
the EAP conversation, a subsequent protocol SHOULD be run
between the peer and authentication in order to mutually
authenticate the peer and authenticator; guarantee liveness
of the TSKs; provide protected ciphersuite and capabilities
negotiation; and provide for synchronized key usage.

[d] An EAP Master Session Key (MSK) negotiated
between the peer and authentication server MAY be
transmitted to the authenticator. Therefore a mechanism needs
to be provided to transmit the MSK from the authentication
server to the authenticator that needs it. The specification
of the key transport and wrapping mechanism is outside the
scope of this document.

7.14 Strict Interpretation

An EAP method wishing to enforce tighter security than is provided by
the packet processing rules of Section 2.1 and Section 4.2.1 MAY
indicate within their specification that they follow a "strict
interpretation" of EAP.

When requested by a method, "strict interpretation" causes the EAP
implementation to impose inbound filter rules from the point where an
initial Request is answered with a Response of the same Type, until
the method completes. "Strict interpretation" also implies that on
completion the peer method will indicate whether it succeeded (was
able to authenticate the authenticator) or failed (did not succeed in
authenticating the authenticator).

An EAP method making use of "strict interpretation" should include a
definition of completion for both the peer and authenticator, and
also should indicate the conditions under which successful completion
will be indicated.

The filter rules are as follows:

[a] On the peer, all EAP packets MUST be silently discarded, except for
those with Code=1 (Request) and Type=Method-Type. This implies
that methods supporting "strict interpretation" do not utilize
Notification, but instead support their own method-specific error
messages.

[b] On the peer, once the method completes unsuccessfully, the EAP
conversation is terminated, the link is disabled and Success
packets MUST be silently discarded. If the conversation completes
successfully, then Failure packets MUST be silently discarded.

[c] On the EAP server, once the initial EAP Request is responded to
with an EAP Response of the same Type, all EAP packets MUST be
silently discarded, except those with Code=2 (Response) and
Type=EAP-Method-Type.

Implementation note: While none of the methods defined in this
document support strict interpretation, EAP-TLS [RFC2716]
implementations SHOULD support strict interpretation."

Proposed Resolution: Discuss

Issue 114: Terminology fixes
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001056.html
Document: EAP-02
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:

Some terms aren't defined in the terminology section and there some minor
cleanup to do.

Change:

"authenticator
The end of the EAP link initiating the EAP authentication
methods. [Note: This terminology is also used in
[IEEE.802-1X.2001], and has the same meaning in this
document].

peer
The end of the EAP Link that responds to the authenticator.
[Note:In [IEEE.802-1X.2001], this end is known as the
Supplicant.]

backend authentication server
A backend authentication server is an entity that provides
an authentication service to an authenticator. When used,
this server typically executes EAP Methods for the
authenticator. [This terminology is also used in
[IEEE.802-1X.2001].]
"

To:

" authenticator
The end of the EAP link initiating EAP authentication.
The term Authenticator is used in
[IEEE.802-1X.2001], and has the same meaning in this
document.

peer
The end of the EAP Link that responds to the authenticator.
In [IEEE.802-1X.2001], this end is known as the
Supplicant.

backend authentication server
A backend authentication server is an entity that provides
an authentication service to an authenticator. When used,
this server typically executes EAP methods for the
authenticator. This terminology is also used in
[IEEE.802-1X.2001]."

Change:

" Key derivation
This refers to the ability of the EAP method to derive a
Master Key which is not exported, as well as a ciphersuite-
independent Master Session Keys. Both the Master Key and
Master Session Keys are used only for further key
derivation, not directly for protection of the EAP
conversation or subsequent data."

To:

" Key derivation
This refers to the ability of the EAP method to derive
exportable keying material such as the Master Session Key
(MSK), and Extended Master Session Key (EMSK).

The MSK is used only for further key
derivation, not directly for protection of the EAP
conversation or subsequent data. Use of the EMSK
is reserved."

Change:

"Man-in-the-Middle resistance
The ability for the peer to demonstrate to the
authenticator that it has acted as the peer for each method
within the conversation. Similarly, the authenticator
demonstrates to the peer that it has acted as the
authenticator for each method within the conversation. If
this is not possible, then the authentication sequence or
tunnel may be vulnerable to a man-in-the-middle attack."

To:

"Man-in-the-Middle resistance
The ability for the peer to demonstrate to the
authenticator that it has acted as the peer for each
authentication method within the conversation. Similarly,
the authenticator demonstrates to the peer that it has
acted as the authenticator for each authentication method
within the conversation. If this is not possible, then
the authentication sequence or tunnel may be vulnerable
to a man-in-the-middle attack."

Change:

" Acknowledged result indications
The ability of the authenticator to provide the peer with
an indication of whether the peer has successfully
authenticated to it, and for the peer to acknowledge
receipt, as well as providing an indication of whether the
authenticator has successfully authenticated to the peer.
Since EAP Success and Failure packets are neither
acknowledged nor integrity protected, this claim requires
implementation of a method- specific result exchange that
is integrity protected."

To:

"Acknowledged result indications
The ability of the authenticator to provide the peer with
an indication of whether the peer has successfully
authenticated to it, and for the peer to acknowledge
receipt, as well as providing an indication of whether the
authenticator has successfully authenticated to the peer.
Since EAP Success and Failure packets are neither
acknowledged nor integrity protected, this claim requires
implementation of a method-specific result exchange that
is authenticated, integrity and replay protected on a
per-packet basis."

Add the following definitions:

"Message Integrity Check (MIC)
A keyed hash function used for authentication and integrity
protection of data. This is usually called a Message Authentication
Code (MAC), but IEEE 802 specifications (and this document) use the
acronym MIC to avoid confusion with Medium Access Control.

Cryptographic binding
The demonstration of the EAP peer to the EAP server that a single
entity has acted as the EAP peer for all methods executed within a
sequence or tunnel. Binding MAY also imply that the EAP server
demonstrates to the peer that a single entity has acted as the EAP
server for all methods executed within a sequence or tunnel. If
executed correctly, binding serves to mitigate man-in-the-middle
vulnerabilities.

Cryptographic separation
Two keys (x and y) are "cryptographically separate" if an adversary
that knows all messages exchanged in the protocol cannot compute x
from y or y from x without "breaking" some cryptographic
assumption. In particular, this definition allows that the
adversary has the knowledge of all nonces sent in cleartext as well
as all predictable counter values used in the protocol. Breaking a
cryptographic assumption would typically require inverting a one-
way function or predicting the outcome of a cryptographic pseudo-
random number generator without knowledge of the secret state. In
other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x, but the work an
adversary must do to perform this computation is equivalent to
performing exhaustive search for the secret state value."

EAP Master key (MK)
A key derived between the EAP client and server during the EAP
authentication process that is purely local to the EAP method. The
MK MUST NOT be exported from the EAP method or be made available to
a third party. Since derivation of the MK is a residue of the
successful completion of the EAP authentication exchange, proof of
MK possession may be used to shorten future EAP exchanges between
the same EAP client and server, a technique known as "fast resume".

Master Session Key (MSK)
Keying material that is derived between the EAP client
and server. The MSK is used in the derivation of Transient Session
Keys (TSKs) for the ciphersuite negotiated between the EAP peer and
authenticator. Where a backend authentication server is present,
acting as an EAP server, it will typically transport the MSK to the
authenticator.

The MSK differs from the MK in that it not assumed to remain local
to the EAP method, and is known by all parties in the EAP exchange:
the peer, authenticator and the authentication server (if present).
The MSK MAY be derived from the MK via a one-way function, or it
may be an independent quantity. However possession of the MSK MUST
NOT provide any information useful in determining the MK.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP
client and server that is exported by the EAP
method. However, unlike the MSK, the EMSK is known only to the EAP
peer and EAP server and MUST NOT be provided to a third party. The
EMSK therefore MUST NOT be transported by the backend
authentication server to the authenticator. The EMSK is reserved
for future uses that are not defined yet. For example, it could be
used to derive additional keying material for purposes such as fast
handoff, man-in-the-middle vulnerability protection, etc. "

Proposed Resolution: Accept

Issue 115: EAP multiplexing fixes
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001057.html
Document: EAP-02
Comment type: T
Priority: S
Section: 2.2
Rationale/Explanation of issue:

It is necessary to clarify what aspects of on the wire behavior are
determined by the EAP layer versus other layers. Also, the sharing of
Identity Request as well as Response info could be made more clear.
Finally it is somewhat confusing to talk about method implemented in the
EAP layer.

Change:

" [b] EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements the EAP state machine, and delivers
and receives EAP messages to and from EAP methods."

To:

" [b] EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements duplicate detection and retransmission
and delivers and receives EAP messages to and from EAP methods."

Change:

"Within EAP, the Type field functions much like a port number in UDP
or TCP. With the exception of Types handled by the EAP layer, it is
assumed that the EAP layer multiplexes incoming EAP packets according
to their Type, and delivers them only to the EAP method corresponding
to that Type code, with one exception.

Since EAP methods may wish to access the Identity, the Identity
Response can be assumed to be stored within the EAP layer so as to be
available to methods of Types other than 1 (Identity). The Identity
Type is discussed in Section 5.1.

A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2.

The Nak method is utilized for the purposes of method negotiation.
Peers MUST respond to an EAP Request for an unacceptable Type with a
Nak Response (legacy or expanded). It cannot be assumed that the
contents of the Nak Response is available to another method. The Nak
Type is discussed in Section 5.3.

EAP packets with codes of Success or Failure do not include a Type,
and therefore are not delivered to an EAP method. Success and Failure
are discussed in Section 4.2.

Given these considerations, the Success, Failure, Nak Response and
Notification Request/Response messages MUST NOT be used to carry data
destined for delivery to other EAP methods.

Where a pass-through authenticator is present, it forwards packets
back and forth between the peer and a backend authentication server,
based on the EAP layer header fields (Code, Identifier, Length).
Since pass-through authenticators rely on a backend authenticator
server to implement methods, the EAP method layer header fields
(Type, Type-Data) are not examined as part of the forwarding
decision. The forwarding model is illustrated in Figure 2. Compliant
pass-through authenticator implementations MUST by default be capable
of forwarding packets from any EAP method."

To:

"Within EAP, the Type field functions much like a port number in UDP
or TCP. It is assumed that the EAP layer multiplexes incoming EAP
packets according to their Type, and delivers them only to the
EAP method corresponding to that Type code.

Since EAP authentication methods may wish to access the Identity,
the Identity Request and Response can be assumed to be
accessible to authentication methods (Types 4 or greater) in addition
to the Identity method. The Identity Type is discussed in Section 5.1.

A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2.

The Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes of method negotiation.
Peers respond to an initial EAP Request for an unacceptable Type with a
Nak Response (Type 3) or Expanded Nak Response (Type 254). It cannot be assumed that the
contents of the Nak Response(s) are available to another method. The Nak
Type(s) are discussed in Section 5.3.

EAP packets with codes of Success or Failure do not include a Type,
and therefore are not delivered to an EAP method. Success and Failure
are discussed in Section 4.2.

Given these considerations, the Success, Failure, Nak Response(s) and
Notification Request/Response messages MUST NOT be used to carry data
destined for delivery to other EAP methods.

Where an authenticator operates as a pass-through, it forwards packets
back and forth between the peer and a backend authentication server,
based on the EAP layer header fields (Code, Identifier, Length).
Since pass-through authenticators rely on a backend authenticator
server to implement methods, the EAP method layer header fields
(Type, Type-Data) are not examined as part of the forwarding
decision. The forwarding model is illustrated in Figure 2. Compliant
pass-through authenticator implementations MUST by default be capable
of forwarding packets from any EAP method."

Proposed Resolution: Accept

Issue 116: Success and Failure fixes
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001058.html
Document: EAP-02
Comment type: T
Priority: S
Section: 4.2, 4.2.1
Rationale/Explanation of issue:

Delete Section 4.2.1 and change Section 4.2 from:

4.2 Success and Failure

The Success packet is sent by the authenticator to the peer to
acknowledge successful authentication. The authenticator MUST
transmit an EAP packet with the Code field set to 3 (Success). If
the authenticator cannot authenticate the peer (unacceptable
Responses to one or more Requests) then the implementation MUST
transmit an EAP packet with the Code field set to 4 (Failure). An
authenticator MAY wish to issue multiple Requests before sending a
Failure response in order to allow for human typing mistakes. Success
and Failure packets MUST NOT contain additional data.

Implementation Note: Because the Success and Failure packets are
not acknowledged, the authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the authenticator. If acknowledged success and failure indications
are desired, these MAY be implemented within individual EAP
methods. Since only a single EAP authentication method is
supported within an EAP conversation, a peer that successfully
authenticates the authenticator MAY, in the event that an EAP
Success is not received, conclude that the EAP Success packet was
lost and enable the link.

A summary of the Success and Failure packet format is shown below.
The fields are transmitted from left to right.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

3 for Success
4 for Failure

Identifier

The Identifier field is one octet and aids in matching replies to
Responses. The Identifier field MUST match the Identifier field
of the Response packet that it is sent in response to.

Length

4"

To:

"4.2 Success and Failure

The Success packet is sent by the authenticator to the peer
after completion of an EAP authentication method
(Type 4 or greater), to indicate that the peer has authenticated
successfully to the authenticator. The authenticator MUST
transmit an EAP packet with the Code field set to 3 (Success). If
the authenticator cannot authenticate the peer (unacceptable
Responses to one or more Requests) then after unsuccessful
completion of the EAP method in progress, the implementation MUST
transmit an EAP packet with the Code field set to 4 (Failure). An
authenticator MAY wish to issue multiple Requests before sending a
Failure response in order to allow for human typing mistakes. Success
and Failure packets MUST NOT contain additional data.

EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to conclusion
of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, the authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the authenticator. If acknowledged result indications
are desired, these MAY be implemented within individual EAP
methods. Since only a single EAP authentication method is
supported within an EAP conversation, a peer that successfully
authenticates the authenticator MAY, in the event that an EAP
Success is not received, conclude that the EAP Success packet was
lost and enable the link.

A summary of the Success and Failure packet format is shown below.
The fields are transmitted from left to right.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

3 for Success
4 for Failure

Identifier

The Identifier field is one octet and aids in matching replies to
Responses. The Identifier field MUST match the Identifier field
of the Response packet that it is sent in response to.

Length

4"

Proposed Resolution: Accept

Issue 117: Miscellaneous technical Nits
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: April 25th, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001059.html
Document: EAP-02
Comment type: T
Priority: S
Section: 4.1, 5, 5.2, 5.3.1, Appendix B
Rationale/Explanation of issue:

Section 4.1, third paragraph, add to the end:

"An EAP server receiving a Response not meeting this requirement MUST
silently discard it."

Section 5, second paragraph. Change:

" The remaining Types define authentication exchanges. The Nak Type is
valid only for Response packets, it MUST NOT be sent in a Request.
The Nak Type MUST only be sent in response to a Request which uses an
authentication Type code (i.e., Type of 4 or greater)."

To:

"The remaining Types define authentication exchanges. The Nak
(Type 3) or Expanded Nak (Type 254) are valid only for Response packets, they
MUST NOT be sent in a Request."

Section 5.2, first paragraph.

Change:

"An authenticator MAY send a Notification Request to the peer at any time
when there is no outstanding Request."

To:

"An authenticator MAY send a Notification Request to the peer at any time
when there is no outstanding Request, prior to completion of an EAP
authentication method."

Section 5.3.1

Change:

"Where any peer receives a Request for an unacceptable Type in the
range (1-253,255), or a peer lacking support for Expanded Types
receives a Request for Type 254, a legacy Nak Response MUST be
sent. The Type-Data field of the legacy Nak Response MUST contain
one or more octets indicating the desired authentication Type(s),
one octet per Type, or the value zero (0) to indicate no proposed
alternative. A peer supporting Expanded Types that receives a
Request for an unacceptable Type (1-253, 255) MAY include the
value 254 in the legacy Nak Response in order to indicate the
desire for an Expanded authentication Type. If the authenticator
can accomodate this preference, it will respond with an Expanded
Type Request."

To:

"Where a peer receives a Request for an unacceptable authentication
Type (4-253,255), or a peer lacking support for Expanded Types
receives a Request for Type 254, a Nak Response (Type 3) MUST be
sent. The Type-Data field of the Nak Response (Type 3) MUST contain
one or more octets indicating the desired authentication Type(s),
one octet per Type, or the value zero (0) to indicate no proposed
alternative. A peer supporting Expanded Types that receives a
Request for an unacceptable authentication Type (4-253, 255)
MAY include the value 254 in the Nak Response (Type 3) in order to
indicate the desire for an Expanded authentication Type. If
the authenticator can accommodate this preference, it will respond
with an Expanded Type Request (Type 254)."

Appendix B

Add the following sentence to the next to last paragraph:

"Where possible it is desirable for a method-specific MIC to be computed over
the entire EAP packet, including the EAP layer header (Code, Identifier, Length)
and EAP method layer header (Type, Type-Data)."

Proposed Resolution: Accept

Issue 118: Mutual Authentication
Submitter name: Dror Caspi
Submitter email address: dror_caspi@atrica.com
Date first submitted: April 21, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: 2
Section: Various
Rationale/Explanation of issue:

Having looked at the drafts of RFC2284bis, EAP-Archie and IEEE-802.1aa,
it seems that most of the attention is given to systems where there is a
distinction between an authenticator and a peer/supplicant. This
distinction still exists even where mutual authentication is proposed
(e.g., EAP-Archie).

But what happens when both parties are peers (e.g., two bridge devices)?
The possibility of role reversal is mentioned (i.e., run a session
where one system is Authenticator and the other Peer, and then reverse
the role). However it seems quite cumbersome; a single session of a
protocol such as EAP-Archie would seem to provide the required
authentication - yet there needs to be a mechanism to (randomly?) decide
which party plays which role.

Probably some of the above is misunderstanding on my part. However
there seems to be a need for some explanatory text in the standards, if
not for actual changes to accommodate peer-to-peer mutual authentication.

Requested change:

Add explanatory text about peer-to-peer mutual authentication. Modify
the standards if required.

Proposed Resolution: Reject

Issue 119: EAP Inappropriate for use in peer-to-peer
Submitter name: Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first submitted: April 30, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

In my opinion (emprical data amply demonstrates that no one has to agree
;-) the EAP framework is inappropriate in general for peer-to-peer
operation. If you think through the model specified for peer-to-peer
operation, you get into a mire of problems that raise the issue of whether
EAP as constituted today is appropriately matched to the problem.

The first problem requires a solution outside (and way outside at that) of
EAP. Authentication presupposes a notion of a community with a common set
of credentials. It does not make sense to allow anyone to use any
credential in any context, because by definition all members of the
community must be able to somehow recognize one another as being
legitimate members of **THIS** community. In all systems I am aware of
this is accomplished through a common policy to utilize a common set of
credentials. In particular, a community corresponds to some common
credentialing or enrollment function, where each credential identifies its
bearer as a member of the community in some uniform way, and also implies
an access control (membership in the community) that is universally
recognized by all other members of the community. So point number one is
it is not feasible to establish a peer-to-peer network without first
establishing a notion of a network or community, and doing so is not EAP's
problem to solve.

The second problem is a special case of this. There are only three basic
trust models. The first is direct bilateral trust, where two parties
authenticate each other directly and make up a key shared only between
themselves. This model essentially works only in networks of two parties,
so is not a general solution; there is no way to enforce that all members
of a larger group will authenticate and establish their session keys in
exactly the same way. The second model is to rely on an on-line trusted
third party. This is the model used by 802.1X and Kerberos. All members of
the group are enrolled with the on-line trusted third party, and the
on-line trusted third party provides some mechanism for distributing
pairwise keys to any pair of communicating parties within the community.
In the peer-to-peer model one can imagine communities ranging from those
with one such on-line trusted third party (completely centralized
admission control) to those where every group member becomes an on-line
trusted third party (completely distributed admission control). However,
by definition, one and only one on-line trusted third party can mediate
any particular session between two members of the community, because it is
only one session. The third model relies on an off-line trusted third
party. TLS is an example that exploits this model. This model relies on
public/private key technology, as proof-of-possesion of the private key
pair is the ultimate basis for electronic identity. In this
model, since possession of a private key is assumed to establish identity,
the use of such a key by another member can be used to attest to the
membership of another party. This is a model that scales, because the
community member making an attestation need not be within communication
range when the access control decision is being made.

In my mind a general-purpose secure peer-to-peer model would need to
support all three approaches. The impression I get is that people are
thinking almost exclusively of the bilateral case, and they are struggling
to wedge the on-line trusted third party model that EAP is based on to fit
this, and this can't be done elegantly. If this impression is correct (and
I'm not claiming that is is, but rather only that it is my impression),
then the current approach is technically flawed in two dimensions: the
on-line trusted third party model is not the same as the bilateral model
that people are thinking of, and EAP should be expanded to support all
three models instead of just one. Oh, sure, any model can be used to
emulate any other model, but emulation costs MIPs, and my employer is
eternally grateful ("Sell more Pentiums") for each. Emulation abandons
many otherwise fine applications (e.g., the secure wireless lightbulb)
because of cost constraints.

The third problem centers around limitations of the security of data links
like 802.11. In particular, the security associations in this class of
networks use the **SAME** key for both directions of traffic flow between
two peers. This implies that the two peers must somehow agree on what this
key is. This is a much trickier problem than first appears, and EAP's
structure does not help solve it. I've pointed out this problem before: it
is essential to cryptographically relate the two independent
authentications. In particular, a cyrptographically sound authentication
method will establish a notion of a session that can be distinguish
**THIS** session from every other session between the **SAME** peers, so
one can figure out **WHICH** session key to use during **THIS** session.
Temproality of messages by themselves does nothing to establish this.
Indeed, protocols like TLS and AKEP and Archie establish session identity
by exchanging random nonces and mutually authenticating. For instance,
when EAP-TLS is used, clientHello.random and serverHello.random together
with the authentication information identify **THIS** session. But there
is nothing in EAP that can be used to accomplish this function. The EAP
Identifier field is the only possible candidate for the nonce space, but
the size of the Identifier field is way too small to provide anything
meaningful, and there are no native EAP cryptographic protections to
protect this field anyway. Identifying each session requires restricting
the authentication protocol to those that already come with all the
necessary bells and whisteles.

But this is not enough, because, to solve the 802.11 keying problem, one
still has to identify that the sessions established by each direction of
authentication are both extant between the same peers at the same time.
One can imagine, for instance, some sort of meta-EAP protocol that relies
on the larger nonce space when specificly restricted to protocols like
TLS or Archie; one could, for instance, make up rules that say in
peer-to-peer mode, if one receives an authenticate request from a peer to
whom one has an outstanding request, you must use the same nonce that you
have outstanding, etc. But this feels uncomfortably like trying to pound
a round peg into a square hole, and one has to struggle to suppress the
observation that we are really, really reaching here, and that there has
to be a better and easier and cheaper way.

The fourth problem is easy is some cases, if the other problems can be
solved. And that is how to pick out the session key to use. If you **CAN**
identify the two sessions in each direction, and **CAN** authoritatively
establish that both are indeed between the same pair of parties, then any
arbitrary scheme can be used to select one of the two session keys to use
to protect the underlying link, e.g., picking the smaller of two MAC
addresses in the 802 case.

So I am deeply skeptical about extending the current instantiation of EAP
to cover peer-to-peer; the intellectual spadework has not been done, and
the tiny bit I may have contributed in this missive tends to indicate, at
least to me, that EAP does not have the right shape. This strikes me as a
case, as the adage says, everything looks like a nail to someone who only
has a hammer. For whatever it is worth, that's my two cents.

[BA, Responding to Jesse Walker]:

> While this is true, it is irrelevant, because it diverts attention from
> the issue. The EAP model is clearly client-server, not peer-to-peer.
> This is not wrong or bad; security association establishment protocols
> (at least the ones that work :-) seem to be inherently client/server.

What makes EAP "inherently client-server"? There are a few things about
the protocol that are asymmetric, such as retransmission behavior (handled
by the authenticator), and the sending of Success/Failure (the
authenticator sends this to the peer). However, with the recent decisions
to only allow a single EAP authentication method per conversation, the
Success/Failure packets can be viewed as largely vestigial within a
mutually authenticating method, and Bob Moskowitz has submitted a change
to IEEE 802.1aa to include the notion of "controlled/uncontrolled ports"
on both the supplicant and authenticator.

While many of the original EAP methods are client-server protocols (e.g.
TLS), we have examples of peer-to-peer authentication technologies being
proposed for use with EAP. An example is EAP-ARCHIE, which is a
peer-to-peer protocol (no distinction made between Initiator and Responder
with respect to say, authentication modes) -- yet it is being proposed to
encapsulate this within EAP, without requiring any changes to EAP.

> My point is that the current peer-to-peer direction does not appear
> sound or even properly thought through.

I think we need to make a distinction between peer-to-peer usage as
envisaged in RFC 2284 and IEEE 802.1aa, and the "adhoc" or "mesh
networking" scenarios being contemplated in IEEE 802.11.

The "adhoc" or "mesh networking" scenarios in IEEE 802.11 are indeed
considerably more complex. In garden variety peer-to-peer between say,
two Bridges on a wired network, the Bridges are stationary and
typically within the same administrative domain. In that situation
there are certainly credential provisioning issues, but given some
"tie breaker" functionality, an appropriate EAP method
supporting peer-to-peer authentication, and sufficient intestinal
fortitude on the part of administrators, it can be made to work.

However, in the "adhoc" or "mesh networking" scenarios contemplated in
IEEE 802.11, we have mobile stations that can potentially be continually
bringing up and tearing down security associations where there is no
inherent trust model. Just as using OSPF for mesh network routing isn't
advisable in these situations, without some care it is likely that
stations will be unable to authenticate at all, or if they can, will spend
much of their time authenticating and very little time communicating.
However, I'm not clear to what extent use of EAP makes this problem worse.

I'd also note that IEEE 802.11i is running two authentications, one in
each direction, deriving two sets of keys, and *then* running a
tie-breaker. This seems wasteful, particularly when we are talking
about providing keying material for a ciphersuite that uses the same keys
in both directions.

> It will take a lot of infrastructure outside
> of 802.1aa or EAP to make peer-to-peer work

If by peer-to-peer you mean "IEEE 802.11 ahoc or mesh networking", I would
agree. However, the scenarios contemplated in IEEE 802.1aa are
considerably simpler than this.

> My suspcion is neither does so because we as a community
> still don't comprehend the issues involved. I know I don't, but the
> discussion thus far has blithely tiptoed along without any recognition
> that this is the middle of a mine field.

Since mesh network security is an active research area, I'd agree that
this is not something that is sufficiently well understood. We could
certainly put in a section that describes some of the issues when
attempting to apply EAP to those problems.

> This is not a problem in a protocol
> like IPsec, because there are separate security associations in each
> direction of the conversation, so each can be keyed by an independent
> security association establishment.

I'm curious as to why IKEv1 can be used for independent security
association establishment, whereas EAP-IKEv1 could not be. What is it
about the EAP transport that somehow changes the security properties of an
existing protocol?

> constructions like 802.11i, however, because there is only one security
> association per link.

That seems like an 802.11 problem to me. There are certainly situations
where EAP can be used with more than one security association per link. An
example of this is PPPOE, where it is possible to have a single host
bringing up multiple PPP sessions to different ISPs, all operating over
the same link. Where EAP is used for authentication and key management, it
is possible to use PPPOE today to bring up multiple security associations
per link. So this isn't an EAP issue -- it's a link layer issue.

> It is hard enough to get one authentication right let alone two.

I would agree that the decision of IEEE 802.11i to do two authentications
*then* do election seems odd. But I'm not sure why this decision was
forced by the use of EAP.

In general, I'd observe that in situations where problem requirements are
poorly understood it is best to gain clarity *before* introducing
potential solutions. There are quite a few situations where conventional
EAP methods will not work well, but that's different from saying that
*some* EAP method cannot be made to work.

> Hence it appears to be a work item that can be deferred until EAP2 (or
> whatever it is called this week).

Since this problem is neither caused by, or solved by EAP, creating a new
protocol is unlikely to add either to the clarity of the problem
statement, or to the value of a solution.

> If EAP and 802.1aa continue on their present courses, here are some
> constraints I'd suggest: both parties MUST use the same concrete
> authentication method with the same credentials for both
> authentications;

Why? RFC 2284 explicitly states that this is *not* a constraint.

> the authentication method MUST exchange random nonces;

For a mutually authenticating method this is sound advice and we should
add this. For a one-way method, it doesn't seem necessary though.

> the authentication method MUST protect the nonces from modification;

Seems reasonable.

> each authentication MUST detect replay and man-in-the-middle attack in
> BOTH directions;

Seems reasonable.

> if the two peers initiate their separate authentications simultaneously,
> then they MUST reuse the nonce they supplied for the authentication
> they initiated in the authentication to which they are responding;

Since we're already saying that two separate authentications is not
equivalent to one mutual one, I'm not sure why we should try to mandate
that they be interlinked. If the intent is to do something like this, why
do two separate authentications in the first place, why not just do a
single mutual auth?

> if the peers do not initiate simultaneously, then the peer that has not
> initiated should fall back to the client-server model if it receives an
> authentication initiated by the peer

It seems reasonable to suggest some sort of tie breaking behavior in the
case where a single mutually authenticating conversation is desired.

> More constraints may be needed, and some of these proposed constraints
> may not be right, because, like I said, I don't claim I understand the
> problem, but if you remove any one of these constraints, then I think it
> is possible to construct attacks that can compromise at least an 802.11i
> protected link.

Such an attack, if feasible, would derive from allowing two
non-interlinked authentications, one in each direction. This isn't an EAP
problem per say -- though we can certainly insert additional language
advising against this.

> The discussion thus far has treated the peer-to-peer case as mechanical.
> I hope that people agree with me that it is not, and much more toil is
> required.

I would certainly agree that IEEE 802.11 "adhoc" or "mesh networking"
requires more thought. But few of the issues you've brought up so far
apply to the simple Bridge-Bridge cases discussed in IEEE 802.1aa.

[BA] Here are the proposed fixes for the EAP Keying Framework document.

Add the following requirements to Section 4.1:

Liveness

Methods deriving keys SHOULD exchange random nonces, and
SHOULD protect the nonces from modification.

Man-in-the-middle and replay protection

Methods deriving keys SHOULD detect replay and man-in-the-middle
attacks in either direction.

[BA] Here is the proposed resolution for RFC 2284bis:

In Section 2, delete:

"Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both peers may act as
authenticators and authenticatees at the same time. For a discussion
of security issues in peer-to-peer operation, see Section 7.7."

Add section 2.4:

"2.4 Peer-to-Peer Operation

Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both peers may act as
authenticators and authenticatees at the same time.

Although EAP supports peer-to-peer operation, selected EAP methods,
AAA protocols and link layers may not support this. For example,
EAP-TLS [RFC2716] is a client-server protocol requiring a different
certificate profile for the client and server. This implies that
a host supporting both the EAP-TLS peer and authenticator roles
would need to be provisioned with two distinct certificates, one
appropriate for each role.

Some EAP methods may support asymmetric authentication, with one
type of credential being required for the peer and another type
for the authenticator. Hosts supporting peer-to-peer operation
with such a method would need to be provisioned with both
types of credentials.

AAA protocols such as RADIUS/EAP [RFC3579] and
Diameter EAP [DiamEAP] only support "passthrough"
operation on behalf of an authenticator, not a peer.
For example, as noted in [RFC3579] Section 2.6.2,
a RADIUS server responds to an Access-Request
encapsulating an EAP-Request with an Access-Reject.

Link layers such as IEEE 802.11 may only support
uni-directional derivation and transport of transient
session keys. For example, the group-key handshake defined in
[IEEE802.11i] is uni-directional, since in IEEE 802.11 only
the Access Point (AP) sends multicast traffic. This means
that in adhoc operation where either peer may send multicast
traffic, two uni-directional group-key exchanges
are required. Due to constraints imposed by the 4-way
unicast key handshake state machine, this also implies
two 4-way handshake and EAP method exchanges.

Link layers such as IEEE 802.11 adhoc also do not support
"tie breaking" wherein two hosts initiating authentication
with each other will only go forward with a single
authentication. This implies that even if 802.11 were to
support a bi-directional group-key handshake, then two
authentications, one in each direction, might still occur."

Proposed Resolution: Accept

Issue 120: Passphrases in EAP
Submitter name: Lauri Tarkkala
Submitter email address: ltarkkal@ssh.com
Date first submitted: April 30, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001107.html
Document: EAP-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

Several of the PPP/EAP authentication protocols
are in essence "password authentication protocols"
(PAP, CHAP, EAP-MD5). This means that the shared
secret is in essence a string in some alphabet
(most often US-ASCII), as opposed to the more
low-level view of a bitstring.

Currently the specifications of these protocols
define the shared secret as an arbitrary string
of octets. This has caused in practice a serious
interoperability problem, leaving implementations
free to define the following:

- Alphabet the password is defined in.

- Derivation of shared secret from password.

As an example some implementations assume CHAP to
encode the password as US-ASCII (or Latin-1 or
some other 8-bit alphabet) and MS-CHAPv2 to
encode the password as UCS-2.

This leads to obvious problems. If the user
actually has characters in his/her password not expressible
in US-ASCII. He/she/it should have sufficient know-how
to be able to disable CHAP when negotiating an authentication
protocol. An implementation also might have to guess
the alphabet to use. These settings might also
differ from system to system. In some cases one could
try to deduce an intelligent guess based on some
(e.g. out-of-band) vendor identification for the peer.

These pitfalls should be avoided in the future.
I propose that the working group standardize the
following functions:

a) If an authentication protocol is keyed by a "passphrase",
then the algorithm used to derive a representation
of a shared secret. If any cryptography is involved,
the protection of the shared secret (if performed)
should still be left to the individual EAP method.

b) The alphabet to be used for this (assuming the WG feels
that a superset alphabet exists), or if the WG feels
that it is not prudent to specify a superset alphabet
at this point in time, a tagging mechanism in the protocol
to denote the alphabet used in mapping a passphrase to a
bitstring. The current draft specifies that the UTF-8
is used to represent all human-readable data.

An acceptable solution would be to state, that ALL
human readable data in ALL EAP methods (except methods
specified before xx.yy.zzzz) must be represented using
UTF-8. This would include passphrases. Also the
alphabsets used in methods before xx.yy.zzzz should
be defined, by a poll checking current implementations.

This would require introduction of two EAP-MD5 methods.

[Pasi Eronen]:

Hmm, good point; we already specify that displayable messages
use UTF-8, but the same problem also applies to input data.
While I'm not so sure that we should try to force all existing
EAP methods to use UTF-8, we probably should at least recommend
something for methods specified in 2284bis.

[Lauri Tarkkala]:

Your proposed solution is IMHO not satisfactory, for the
simple reason that the alphabet used to represent the passphrase
is a parameter in selecting the acceptable authentication method
(or the used authentication method is a parameter in choosing the
passphrase).

A simple example:

- Client wishes to authenticate with EAP using a shared-secret scheme
to Server, where server assumes alphabet Y for on-the-wire
representation.

- Client holds passphrase expressible in alphabet X, but not alphabet Y.

- Authentication will not succeed. Interoperability would require
that the user know the EAP methods used before he/she chooses
his/her password!

A requirement for an acceptable solution IMHO is that the
character set used for the passphrase SHOULD NOT be related
to an EAP method (with the possible exception of some legacy
methods).

A user should not need to know that
"if my password contains the Japanese Kanji <x> I can
only authenticate using the EAP method xyzzy".

I do agree with you, that forcing all EAP methods into the
same alphabet is not wise. I also think that interoperability
with existing EAP-MD5/etc implementations is important (otherwise
implementors would still have to sniff out, based on some indidcators
about the peer vendor, what encoding to use).

I feel that a better solution would be to classify EAP methods
according to the key-type used into "passphrase-keyed methods"
and "binary-keyed methods". Ideally, each method would have
an instance in both classifications. This could be achieved
by reserving a bit in the type field of a method (with the
obvious consequence of halving the namespace), e.g. assuming
"passphrase-keying" is indicated by bit 6:

- EAP-MD5 keyed by a binary string would be method 0x05.
- EAP-MD5 keyed by a passphrase in UTF-8 would be method 0x45.

The bit would have the following semantics:

- If the passphrase-keying bit is set by the authenticator, then it
means "authenticator supports passphrase-keying".

- If the passphrase-keying bit is set by the authenticatee, then it
means "that key used is a passphrase in UTF-8 encoding".

Any opinions?

Any ideas on some better place to find bits for this indication?

[Pasi Eronen] Here is updated text:

Add to Section 5:

"EAP methods MAY support authentication based on
shared secrets. If the shared secret is a passphrase entered by the user,
implementations MAY support entering passphrases with non-ASCII
characters. In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in
octets using UTF-8 encoding [RFC2279]. A possible
registered stringprep profile is specified in [SASLPREP]."

Add to 5.4 (MD5-Challenge), before Type:

"Note: [RFC1994] treats the shared secret as an octet string,
and does not specify how it is entered into the system (or if it
is handled by the user at all).
EAP MD5-Challenge implementations MAY support entering passphrases with
non-ASCII characters. See Section 5 for instructions
how the input should be processed and encoded into octets."

Add to 5.5 (OTP), before Security Claims:

"Note: [RFC2289] does not specify how the secret pass-phrase is
entered by the user, or how the pass-phrase is converted into
octets. EAP OTP implementations MAY support entering
passphrases with non-ASCII characters. See Section 5 for
instructions how the input should be processed and encoded
into octets."

Add to 5.6 (GTC), before Security Claims:

"EAP GTC implementations MAY support entering a response with non-ASCII
characters. See Section 5 for instructions how the input should
be processed and encoded into octets."

Add to informative references:

[RFC3454]
Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454, December 2002.

[SASLPREP]
Zeilenga, K.D., "SASLprep: Stringprep profile for user names and
passwords", draft-ietf-sasl-saslprep-01 (work in progress), May 2003.

[BA]

With respect to UTF-8, we have added the following to the terminology
section in RFC 2284bis:

Displayable Message
This is interpreted to be a human readable string of
characters, and MUST NOT affect operation of the protocol.
The message encoding MUST follow the UTF-8 transformation
format [RFC2279].

Also, Section 5.1 states that the EAP-Request/Identity is encoded as UTF-8
if it contains a displayable message. Section 5.2 says that Notification
Requests are encoded as UTF-8.

Given all of this, it strikes me that encoding passphrases as UTF-8 is in
keeping with the general direction of RFC 2284bis, and so Pasi's
suggestions seem reasonable to me.

If there are EAP implementations that would be broken by the proposed
fixes, now would be a good time to step forward.

[Pasi Eronen]

Lauri Tarkkala wrote:

> We must make the following decision:
>
> D1) Specify our own stringprep profile.
> D2) Wait till the SASLprep one makes RFC status, and then cite it.
> D3) Leave the issue to be resolved later.
>
> Pasi's wording above seems to imply decision "D2" (an RFC will
> probably not get accepted by the IESG if it references an I-D,
> as all probably know).

A standards-track RFC can't contain a normative reference to an
I-D, but informative references are OK. I think we could write
this so that the reference to SASLPREP would be considered
informative (see below).

I don't think D1 is an option.

> No WG member has made explicit statements regarding the following:
>
> A. Is it OK, that passphraseses MAY NOT be inter-operable between
> passphrase-keyed EAP methods?

Depends. Certainly we should try to minimize any
interoperability problems, but 2284bis may not be the
appropriate place to do it.

> B. Is it OK, that the only mandatory EAP method, does not
> exactly specify how it should be used in Unicode environments?

Yes, for some levels of "exactness" :-)

We can't exactly define the behavior without a stringprep
profile, and we certainly don't want to wait for SASLPREP to
become RFC.

I think we could say something like "Behavior for non-ASCII
characters is undefined, and will be clarified in a future
revision of this document. Our guess is that it will resemble
SASLPREP followed by UTF-8.".

Something like that would provide enough information to build
interoperable implementations, yet make the reference
informative. (Though I'm not sure if IESG will allow leaving
the behavior undefined in standards-track RFC?)

> If the WG feels that the answer to question "A" is NO (as I do),
> then I would recommend adding the following note to the draft:
>
> Add to section "2" after point [4].
>
> "[5] If the EAP method is keyed by a human-readable passphrase,
> then it MUST be possible to provide that passphrase in Unicode,
> which is transformed using stringprep [RFC3454] profile XXX
> [RFCXXX] before it is input into the EAP authentication method.
> This SHOULD be the default mode of operation."

I don't think we should add such a requirement here. Certainly
an EAP method should be able to define that it uses a shared
secret that MUST contain only ASCII characters (or only
characters A-Z except Q, or whatever).

Also, no implementation will ever support entering ALL
characters defined in Unicode. Implementations will support
entering some subset of Unicode characters, and I don't think
2284bis is an appropriate place to specify what that
subset should be.

[BA]

Lauri Tarkkala wrote:

"Pasi's wording above seems to imply decision "D2" (an RFC will
probably not get accepted by the IESG if it references an I-D,
as all probably know)."

In this particular case, the reference applies to a SHOULD so it
might be hard to argue that it is non-normative. This would result in a
Reference Hold in the RFC Editor queue until the normative reference is
resolved. We're trying to avoid this fate for RFC 2284bis if at all
possible.

The possible options are either to remove the SHOULD (such as demoting it
to a should or may), or to make it clear that the SASLprep document is
only one possible solution and that there might be others.

Proposed resolution: Accept

Issue 121: Document meaning of successful authentication
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: May 2, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001115.html
Document: EAP-02
Comment type: T
Priority: 1
Section: 1.2 (and possibly others)
Rationale/Explanation of issue:

It seems that in EAP we're using the word "authentication"
in somewhat non-standard sense, and I feel we should document
it.

Here's a first draft of text for section 1.2 (terminology):

"Successful authentication

In the context of this document, "successful authentication"
is an exchange of EAP messages, as a result of which the
authenticator decides to allow access for the peer, and the
peer decides to use this access.

This definition differs from the usual definitions of
authentication (e.g. "verification of claimed identity"),
since the authenticator may decide to deny access even when
the identity of the peer is known and verified, or vice versa
(allow access when the identity of the peer is not verified).

Furthermore, even if the authenticator decides to allow access,
the peer may consider the exchange a failure if it has not
successfully verified that it is talking to the intended
authenticator."

Do you think this captures the meaning accurately?
(It might require some small changes somewhere else
in the document, I can try to find them...)

[BA]

I do think that the suggested change is close to the correct meaning,
though some issues arise with the following paragraph:

"This definition differs from the usual definitions of
authentication (e.g. "verification of claimed identity"),
since the authenticator may decide to deny access even when
the identity of the peer is known and verified, or vice versa
(allow access when the identity of the peer is not verified)."

Even with the changes made in Issue 116, I think it is possible for an
authenticator to allow access to a peer which has failed to authenticate
to it. Presumably this would occur with restricted access, so that the
peer might have a chance to correct the deficiency (e.g. signup for an
account, send an email to get help, etc.). I think that would need to be
done with a method that either was one-way, or where the peer successfully
authenticated the authenticator. Might want to double check whether
there are any other "gotchas" in the draft bearing on this.

I do agree that the authenticator may decide to deny access even when the
identity of the peer is known and verified. However, I think that given
the changes we've made in Issue 116, it would be necessary for the EAP
method to indicate that an authentication failure has occurred for this to
work, and depending on the protocol this might or might not be supported.

For example, let's say that I am only allowed access from 8 AM to 5 PM
under my plan. I attempt to connect at 6 PM, and correctly input my
credentials. After examining the access policy, the AAA server will send
an Access Reject to the NAS. If it is not careful it could also send an
EAP Success encapsulated within that Access Accept. To avoid this, we
introduced language in RFC 2869bis to discourage such a contradictory
message. So the AAA server presumably now encapsulates an EAP Failure
within the Access Reject.

However, if the AAA server didn't examine the policy until after the EAP
method was complete, there can be trouble because the method presumably
completed successfully. As a result, the changes indicated in Issue 116
would cause the EAP Failure to be silently discarded since it doesn't
agree with the result of the EAP method authentication which was
successful.

One response to this problem is that the AAA server should examine the
policy early on and appropriately terminate the method, so that it's not a protocol
issue, but an implementation issue. I'm not sure I find this 100%
convincing however, because in some methods (EAP TLS, for example), there
may not be a method-specific error message that appropriately conveys an
"authenticated but not authorized" error. So if we're going to go down
this road, we probably need to add some advice in the method Appendix to
make sure that those messages are available.

Here are the proposed fixes:

Add to the terminology section:

"Successful authentication

In the context of this document, "successful authentication"
is an exchange of EAP messages, as a result of which the
authenticator decides to allow access for the peer, and the
peer decides to use this access."

Change the following text in Section 4.2 from:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to conclusion
of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, the authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the authenticator. If acknowledged result indications
are desired, these MAY be implemented within individual EAP
methods. Since only a single EAP authentication method is
supported within an EAP conversation, a peer that successfully
authenticates the authenticator MAY, in the event that an EAP
Success is not received, conclude that the EAP Success packet was
lost and enable the link."

To:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to
conclusion of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, they are not retransmitted by the authenticator,
and may be potentially lost. A peer MUST allow for this circumstance.
If acknowledged result indications are desired, these MAY be
implemented within individual EAP methods.

On the peer, once the method completes unsuccessfully, the EAP
conversation is terminated, the link is disabled, and a Success
packet MUST be silently discarded by the peer. As a result,
loss of a Failure packet need not result in a timeout.

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. A peer that successfully
authenticates the authenticator MUST silently discard Failure packets
and MAY, in the event that an EAP Success is not received, conclude
that the EAP Success packet was lost and enable the link.

Where the authenticator wishes to deny access even where the peer
authenticated successfully (e.g. where the peer may not be authorized
for reasons of policy), this can result in lengthy timeouts unless
either the method provides authorization-related error messages or
a lower layer failure indication is provided. For example,
within EAP-TLS [RFC2716], the "access_denied" TLS alert can be
used to indicate that a valid certificate was received, but when
access control was applied, the authenticator decided not to proceed.
Section 3.4 provides guidance on the processing of lower layer
success and failure indications."

[Pasi Eronen] How about this?

   "Implementation Note: Because the Success and Failure packets
   are not acknowledged, they are not retransmitted by the
   authenticator, and may be potentially lost. A peer MUST allow
   for this circumstance. If acknowledged result indications
   are desired, these MAY be implemented within individual EAP
   methods.

   On the peer, an EAP method can conclude with three different
   end results.

   [1] Failure: Either the authenticator has indicated that it
       will not allow access to the peer, or the peer does not wish
       to use this access (for instance, the peer has not
       successfully verified the server's identity, but its security
       policy requires this).

       In this case, the EAP conversation is terminated, and the
       link is disabled. As a result, loss of a Failure packet
       need not result in a timeout, and a Success packet MUST
       be silently discarded by the peer.

   [2] Unconditional success: The authenticator has indicated that
       it will allow access to the peer, and the peer wishes
       to use this access.

       The peer SHOULD, in the event that an EAP Success is not
       received, conclude that the EAP Success packet was lost
       and enable the link. Failure packets MUST be silently
       discarded by the peer.

   [3] Conditional success: The peer wishes to use the access,
       but it does not know if the authenticator will allow access
       or not.

       The peer MAY, in the event that an EAP Success is not
       received, conclude that the EAP Success packet was lost
       and enable the link. Failure packets MAY be silently
       discarded, but this can result in lengthy timeouts unless
       a lower layer failure indication is provided."

[Pasi Eronen]

Bernard Aboba wrote:

> This isn't a RADIUS issue -- the problem can also occur in any AAA
> protocol, including Diameter.
> Typically the problem occurs because the implementation applies policy
> after the authentication/authorization decision is made, and
> therefore the result of the EAP method/EAP Success or Failure
> message/AAA result may not agree.
>
> The question is whether this is just an implementation issue -
> and therefore whether the implementations should be fixed so that
> it doesn't occur. That was the judgement of IEEE 802.1aa, and
> that is what is reflected in RFC 2869bis.

I very much agree with you on this. Making the authorization
decision *is* IMHO same as applying policy, and an
implementation should behave consistently in this. If
the implementation signals (using some EAP method internal
mechanism) that "yes, I give you access", then it must
not change that decision later and send an EAP Failure.

(From implementation point of view, if the policy is stored
in some "RADIUS server or EAP mux module", then the "EAP method
module" has to communicate with this module. But this is purely
an implementation issue; the behavior observable to outside
has to be consistent).

However, this should not be confused with the peer knowing
that "yes, the authenticator has verified who I am" message.
In this case, either authorization decision is consistent
behavior for the server, and I think that it is reasonable
to make the authorization decision (apply the policy)
after verifying who the peer is (which may be before an
EAP method has concluded, or after!).

It seems that EAP methods that can signal the authorization
decision have one "extra round" in them: before sending
the last Request, the server has already made its decision
whether to allow access or not.

In many methods, the server won't make the final decision until
it has received the last Response from the peer; and in those
methods, the only way to signal the authorizion decision
is an EAP Success/Failure message (and thus the server
can freely choose either of them).

[Jari Arkko]: Here are the proposed fixes:

Add to the terminology section:

"Successful authentication

In the context of this document, "successful authentication"
is an exchange of EAP messages, as a result of which the
authenticator decides to allow access by the peer, and the
peer decides to use this access. The authenticator's
decision typically involves both authentication and
authorization aspects; the peer may successfully
authenticate to the authenticator but access may be denied
by the authenticator due to policy reasons."

Change the following text in Section 4.2 from:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to conclusion
of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, the authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the authenticator. If acknowledged result indications
are desired, these MAY be implemented within individual EAP
methods. Since only a single EAP authentication method is
supported within an EAP conversation, a peer that successfully
authenticates the authenticator MAY, in the event that a Success
packet is not received, conclude that the Success packet was
lost and subsequently enable the link."

To:

"Success or Failure packets MUST NOT be sent by an EAP authenticator
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" Success
packet (a Success packet sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending a Success packet prior to
conclusion of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are not
acknowledged, they are not retransmitted by the authenticator, and may
be potentially lost. A peer MUST allow for this circumstance as
described in this note. See also Section 3.4 for guidance on the
processing of lower layer success and failure indications.

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. EAP methods MAY
implement acknowledged result indications.
After the authenticator sends a method-specific failure indication
to the peer, regardless of the response from the peer, it MUST
subsequently send a Failure packet. After the authenticator
sends a method-specific success indication to the peer, and
receives a method-specific success indication from the peer,
it MUST subsequently send a Success packet.

On the peer, once the method completes unsuccessfully (that is, either
the authenticator sends a method-specific failure indication, or the
peer decides that it does want to continue the conversation, possiblyafter sending a method-specific failure indication), the
peer MUST terminate the conversation and avoid sending data on the
link. The peer MUST silently discard Success packets and MAY
silently discard Failure packets. As a result,
loss of a Failure packet need not result in a timeout.

On the peer, after successful acknowledged result indications
are exchanged by both sides, a Failure packet MUST be silently
discarded by the peer. The peer MAY, in the event that an EAP Success is not
received, conclude that the EAP Success packet was lost and
that authentication concluded successfully.

A mutually authenticating method (such as EAP-TLS [RFC2716])
that provides authorization error messages provides
acknowledged result indications for the purpose
of this specification. Within EAP-TLS, the peer always
authenticates the authenticator, and may send a TLS-alert message
in the event of an authentication failure. An authenticator
after successfully authenticating the peer may use the "access denied"
TLS aert to indicate that a valid
certificate was received from the peer, but when
access control was applied, the authenticator decided not to proceed.
If a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts.

If the authenticator has not sent a method-specific result
indication, and the peer is willing to continue the conversation,
once the method completes the peer waits for a Success or Failure
packet and MUST NOT silently discard either of them. In the event that
neither a Success nor Failure packet is received, the peer SHOULD
terminate the conversation to avoid lengthy timeouts in case the
lost packet was an EAP Failure.

If the peer attempts to authenticate to the authenticator and fails
to do so, the authenticator MUST send a Failure packet and MUST NOT
grant access by sending a Success packet. However, an authenticator
MAY not require that the peer authenticate to it in situations where
limited access is offered (e.g. guest access). In this case the
authenticator MUST send a Success packet.

Where the peer authenticates successfully to the authenticator, but
the authenticator does not send a method-specific result indication
the authenticatorMAY deny access by sending a Failure packet where the peer is not
currently authorized for network access."

Proposed resolution: Accept

Issue 122: Clarification of LL requirements
Submitter name: Mohan Parthasarathy
Submitter email address: mohanp@tahoenetworks.com
Date first submitted: May 2, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001121.html
Document: EAP-02
Comment type: T
Priority: S
Section: 3.1
Rationale/Explanation of issue:

In section 3.1, Lower layer requirements,

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g. wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.
Where keying material for the lower layer ciphersuite is itself
provided by EAP, typically the lower layer ciphersuite cannot be
enabled until late in the EAP conversation, after key derivation
has completed. Thus it may only be possible to use the lower
layer ciphersuite to protect a portion of the EAP conversation,
such as the EAP Success or Failure packet.

I have couple of questions.

1) How do you delay the EAP success packet so that it can be
protected ? For example, if you are using ECP, you should have
reached the IPCP negotiation phase. But IPCP has not begun until EAP success
packet is transmitted. right ? what am I missing ?

2) Under what conditions the EAP failure packet can be protected ?
Doesn't failure imply that key has not been derived ?

[Pasi Eronen]

I think the draft is misleading here: as far as I know (please correct
me if I'm wrong :), existing lower layers that use EAP transmit the
EAP success packet unprotected, and enable the ciphersuite only after
that.

If this is indeed the case, I suggest we the text to:

"... When keying material for the lower layer ciphersuite is itself
provided by EAP, typically the lower layer ciphersuite is enabled
only after the EAP conversion has concluded. Thus, the EAP conversation
itself is usually not protected."

[BA]

Mohan is correct that not all link layers can
permit protection of EAP packets within an
initial authentication. In PPP, ECP
can only begin after authentication has completed
so protection of EAP packets is only possible for
re-authentication.

It would be possible for an EAP Failure to be
protected in re-authentication, or pre-authentication,
where lower layer protection is already in place.
However, for an initial authentication,
given the changes made in Issue 116,
it is now expected that the Success/Failure
packet will match the outcome of the single
authentication method that is run. As a result,
a Failure could only be protected if a key were
derived *and* somehow the peer failed to
authenticate to the authenticator. This could
happen in a protocol such as PEAP.

Suggest changing the text to:

"As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g. wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.

Where keying material for the lower layer ciphersuite is itself
provided by EAP, ciphersuite negotiation and key activation is
controlled by the lower layer. In PPP, ciphersuites are negotiated
within ECP so that it is not possible to use keys derived from
EAP authentication until the completion of ECP. Therefore an
initial EAP exchange cannot protected by a PPP ciphersuite,
although EAP re-authentication can be protected.

In IEEE 802 media, key activation also typically occurs after
completion of EAP authentication. Therefore an initial EAP exchange
typically cannot be protected by lower layer ciphersuite, although an EAP
re-authentication or pre-authentication exchange can be protected."

Proposed resolution: Accept

Issue 123: Non key-generating methods and binding
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: April 23, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001121.html
Document: Binding-01
Comment type: T
Priority: S
Section: 3.2
Rationale/Explanation of issue:

Bernard and I were discussing potential solutions for the binding
problem with the "worst case" legacy EAP methods. These methods are
such which don't generate session keys. During this discussion, it
became apparent that draft-puthenkulam-eap-binding-02.txt could perhaps
be improved by adding more details about this case.

Specifically, Section 3.2 rule S2 states the following:

Guarantee that the same peer credential is never usable inside and
outside a tunnel using server and client policy. This prevents
condition CC-A.

This solution actually works for all methods, but is sometimes hard
to deploy, due to legacy deployments, and since clients and servers
need to be synchronized for proper policy enforcement. An
additional problem with this solution is the manageability issues
due to the multiple credentials that have to be managed by the same
client and server.

and then later:

S2 is realizable just using policy techniques on the client and server
ends.

In Section 3.3 the non-key generating method issue is expanded a bit:

[1] Providing separate credentials for a user identity supported inside
and outside tunnels.

...

[2] Enforce client and server policy to always use authentication
methods inside tunnels.

...

For non-key deriving methods, if they are modifiable, then using a
signal to indicate when they are running inside a tunnel would
also prevent the attack. This works because the server is able to
distinguish between an attacker diverting a method into a tunnel
versus a client method intentionally initiated inside a
tunnel. However such signals need protection from spoofing.

The case of non-key deriving methods is an important one. Both PIC and
IKEv2 have large user groups interested in running existing
password-based methods.

Our concern is that the above description does not fully describe the
possibilities available for these users. Namely, the problem is that
there has been some confusion about exactly what it means to support
"legacy authentication". For example, are we trying to support

1. "Password authentication" i.e. the use of existing passwords
in a new context?

or

2. Are we trying to support existing methods, e.g. CHAP?

It seems that the main interest is *not* supporting legacy
authentication methods, since today EAP support is available on
virtually all shipping servers, including FreeRADIUS. Therefore, all
devices will be able to support EAP, and intermediate devices will be
able to support any method.

We believe that the issue is rather supporting legacy credentials,
such as passwords or token cards.

If so, it may be possible to keep the credentials as they are but
replace the existing method with a modified one when running inside a
tunnel (or within EAP). When running outside tunnels, use the existing
method as-is.

There appears to be key generating variants available for many of the
popular legacy credentials. For instance, the existing passwords for
dial-in PPP MSCHAPv2 could be used as-is when running EAP MSCHAPv2,
which can generate keys. The choice between the variant is easy
as long as both the authentication method and the tunnel endpoints
are in the same nodes, because then both nodes know whether a tunnel
is being used.

Similarly, the same credentials could be used inside the tunnel even
without key generation if the authentication method is changed
slightly. For instance, using "password" as the password outside the
tunnel and SHA1("password") as the password inside the tunnel. This
would appear to prevent the man-in-the-middle attack.

These types of solutions may be necessary in order to deal with legacy
credentials that currently don't generate keys, and with tunneling
protocols that can't be changed easily. As an example of the latter,
changing HTTP/TLS to take in account compound keys may be hard but the
"password"/SHA("password") trick may be easier to do within HTTP Digest
running inside HTTP/TLS.

Does this make sense?

If yes, perhaps some of the aspects from the above should be discussed
in the draft.

Issue 124: Identity Protection
Submitter name: Mark Schurman
Submitter email address: mschur@microsoft.com
Date first submitted: May 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001183.html
Document: EAP-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I had a few comments on this doc, with regards to identity protection:

Page 4: When the term Confidentiality is defined, it includes the sentence "A method making this claim MUST support identity protection." However, "identity protection" is not defined in this list, and is not seen until page 29. This list should include a quick description for the term.

Page 5, heading 2, point 1: This paragraph mentions that the initial Identity Request is optional, and gives a few scenarios as examples. I'd suggest adding identity protection in this list as well. (Knowing that some implementations can determine it from other information is somewhat useful, but it seems more useful to me to state that, even if the identity can't be determined yet, delaying the identity request could be desirable from a security standpoint.)

Page 29: Heading "Identity Protection", paragraph 1: Should we provide more details on this? One question I had was whether a complete identity response could be delayed only at the EAP server's discretion (by delaying the identity request), or if the EAP peer (client) could unilaterally choose to delay the complete identity response. For example, if the client were configured to perform an EAP type that supports identity protection (like PEAP), which of the following statements is appropriate, or do we want to leave this unspecified in the draft?

A) The EAP peer MUST always respond to an identity request with complete identity information. [The next paragraph in the draft qualifies this, describing different requirements for the peer-name portion vs. the realm portion of the identity response.]
B) In cases where the EAP peer is performing an EAP type that supports identity protection, the EAP peer {SHOULD, MAY} respond to an identity request with {complete, complete or partial} identity information.
C) In cases where the EAP peer is performing an EAP type that supports identity protection, the EAP peer MAY disregard the initial (cleartext) identity request, providing an incomplete [or blank?] response. However, the EAP peer {SHOULD, MUST} provide complete identity information to the protected identity request.

…or some other permutation. Is this information / behavior that we want to require/restrict, allow/disallow, or leave unspecified?

I also have one comment on page 10. The first sentence in this paragraph and the last sentence in the paragraph seem to contradict - may be we need to remove the first sentence completely.

Lower layer CRC or checksum is not necessary. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines its own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer.
If lower layers exhibit a high loss rate, then retransmissions are likely, and since EAP Success and Failure are not retransmitted, timeouts are also likely to result. EAP methods such as EAP TLS [RFC2716] include a message integrity check (MIC) and regard MIC errors as fatal. Therefore if a checksum or CRC is not provided by the lower layer, then some methods may not behave well.

[jari arkko]:

> Page 29: Heading "Identity Protection", paragraph 1: Should we provide
> more details on this? One question I had was whether a complete identity
> response could be delayed only at the EAP server's discretion (by delaying
> the identity request), or if the EAP peer (client) could unilaterally
> choose to delay the complete identity response. For example, if the client
> were configured to perform an EAP type that supports identity protection
> (like PEAP), which of the following statements is appropriate, or do we
> want to leave this unspecified in the draft?
>
> A) The EAP peer MUST always respond to an identity request with complete
> identity information. [The next paragraph in the draft qualifies this,
> describing different requirements for the peer-name portion vs. the realm
> portion of the identity response.]

This may be the best we can do. But the current draft sections 7.3 and
5.1 appear incomplete with regards to how you actually leave the username
portion out. Should I send "@foo.com" or "foo.com" or perhaps even
"dummy@foo.com"? This does not appear to have been specified anywhere.

> B) In cases where the EAP peer is performing an EAP type that supports
> identity protection, the EAP peer {SHOULD, MAY} respond to an identity
> request with {complete, complete or partial} identity information.

The peer may support many things, but how does it know what the
authenticator is going to ask it to do?

> C) In cases where the EAP peer is performing an EAP type that supports
> identity protection, the EAP peer MAY disregard the initial (cleartext)
> identity request, providing an incomplete [or blank?] response. However,
> the EAP peer {SHOULD, MUST} provide complete identity information to the
> protected identity request.

Again, it is unclear to me what the order of events is. Assuming the
peer supports M1, M2, and M3 where only M1 supports identity
protection, does this mean that the peer never provides a good
enough identity response for M2 & M3? If yes, the introduction of the first
identity-protecting method would disable all other methods...
This appears to be a problem for all alternatives A-C, assuming
the 7.3 approach is considered a part of A.

Policy would be one way of fixing this problem. Policy could say
that now we will use identity protection. In general, I'm
not too happy about introducing new policy knobs, however.
Perhaps we could say that if all the methods you are prepared
to accept (in terms of policy and availability of credentials)
support identity privacy, then you don't send full identity
information?

[BA] Here are some proposed fixes:

Change text in Section 5.1 from:

To:

"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 of Type 1 (Identity) SHOULD be sent in Response
to a Request with a Type of 1 (Identity).

Since Identity Requests and Responses are not protected, from a
privacy perspective, it may be preferable for protected
method-specific Identity exchanges to be used instead.
Where the peer is configured to only accept authentication
methods supporting protected identity exchanges, the peer
MAY provide an abbreviated Identity Response (such as
omitting the peer-name portion of the NAI [RFC2486]). For
further discussion of identity protection, see Section 7.3."

Proposed resolution: Accept

Issue 125: Retransmission Issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 10, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001186.html
Document: RFC2869bis-20
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

RADIUS [RFC2865] does not define retransmission behavior. However we
have seen situations (such as a network-wide reboot) where RADIUS
storms can occur, swamping the RADIUS server(s). In these situations
it would be preferrable for RADIUS clients to support exponential
backoff and a more conservative initial RTO estimate, as in TCP.

Change Section 2.3 from:

"2.3. Retransmission

As noted in [RFC2284], if an EAP packet is lost in transit between the
authenticating peer and the NAS (or vice versa), the NAS will
retransmit. In RADIUS [RFC2865], the RADIUS client (NAS) is responsible
for retransmission of packets between the RADIUS client and the RADIUS
server.

It may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token
card is used additional time may be required to allow the user to find
the card and enter the token. Since the NAS will typically not have
knowledge of the required parameters, these need to be provided by the
RADIUS server. This can be accomplished by inclusion of Session-Timeout
attribute within the Access-Challenge packet.

If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout is used to set
the EAP retransmission timer for that EAP Request, and that Request
alone. Once the EAP-Request has been sent, the NAS sets the
retransmission timer, and if it expires without having received an EAP-
Response corresponding to the Request, then the EAP-Request is
retransmitted."

To:

"2.3. Retransmission

As noted in [RFC2284], if an EAP packet is lost in transit between the
authenticating peer and the NAS (or vice versa), the NAS will
retransmit. In RADIUS [RFC2865], the RADIUS client (NAS) is responsible
for retransmission of packets between the RADIUS client and the RADIUS
server.

It may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token
card is used additional time may be required to allow the user to find
the card and enter the token. Since the NAS will typically not have
knowledge of the required parameters, these need to be provided by the
RADIUS server. This can be accomplished by inclusion of Session-Timeout
attribute within the Access-Challenge packet.

If Session-Timeout is present in an Access-Challenge packet that also
contains an EAP-Message, the value of the Session-Timeout is used to set
the EAP retransmission timer for that EAP Request, and that Request
alone. Once the EAP-Request has been sent, the NAS sets the
retransmission timer, and if it expires without having received an EAP-
Response corresponding to the Request, then the EAP-Request is
retransmitted.

In RADIUS [RFC2865], the RADIUS client is responsible for retransmission
of RADIUS packets. RADIUS/EAP client implementations SHOULD support dynamic
estimation of the RADIUS retransmission timeout, using the algorithms specified
in [RFC2988]. Since RADIUS Access-Requests may be routed to the RADIUS server
based on the Network Access Identifier (NAI) realm [RFC2486],
retransmission timeout estimates SHOULD be maintained on a per-EAP session basis."

[Glen Zorn]

draft-aboba-radius-rfc2869bis-21.txt says in section 2.3:

"In RADIUS [RFC2865], the RADIUS client is responsible for
retransmission
of RADIUS packets. RADIUS/EAP client implementations SHOULD support
dynamic estimation of the RADIUS retransmission timeout, using the
algorithms specified in [RFC2988]."

The reasoning behind this modification to the RADIUS retransmission
strategy is that "... we have seen situations (such as a network-wide
reboot) where RADIUS storms can occur, swamping the RADIUS server(s). In
these situations it would be preferrable for RADIUS clients to support
exponential backoff and a more conservative initial RTO estimate, as in
TCP." However, the TCP RTO algorithms are designed to prevent network congestion, which
(though it may occur) is not the problem we're trying to solve here,
which I think might be better modeled as a server resource contention
problem. Furthermore, the problem is not specific to EAP-over-RADIUS;
in the situation mentioned above, the same behavior would be observed
regardless of the authentication protocol in use. This fact suggests
that a solution to the problem (presupposing that a protocol-based
solution is reasonable) should be published as an update to RFC 2865,
rather than RFC 2869.

There are other reasons why the RFC 2998 algorithms are inappropriate
for use with RADIUS. Some are mentioned in RFC 2865 (section 2.4);
others include an initial TMO that is likely to be too short in
situations where one or more RADIUS proxies are traversed, the large
granularity of the timers specified and the deterministic nature of the
algorithms used which in the worst case could result in all the clients
firing repeated salvos of requests in lockstep (not a good way to reduce
instantaneous server loading!).

[BA] Overall, I agree with Glen's comments and would therefore recommend that
the paragraph in question be removed from RFC 2869bis, and that a separate
document be developed to specify RADIUS retransmission behavior in more detail.

> the TCP RTO algorithms are designed to prevent network congestion, which
> (though it may occur) is not the problem we're trying to solve here,
> which I think might be better modeled as a server resource contention
> problem.

The basic principle embodied in the TCP RTO algorithms is "conservation of
packets" -- that a new packet should not enter the network until there is
reason to believe that another packet has left it. Both a server resource
contention problem and congestion manifest themselves in terms of increased
delays and packet loss, and so it seems to me that the principle applies
in both cases -- and can be addressed dynamic timeout estimation, backoff
and jittering.

> Furthermore, the problem is not specific to EAP-over-RADIUS;
> in the situation mentioned above, the same behavior would be observed
> regardless of the authentication protocol in use. This fact suggests
> that a solution to the problem (presupposing that a protocol-based
> solution is reasonable) should be published as an update to RFC 2865,
> rather than RFC 2869.

I agree with Glen that the problem can occur with any RADIUS
usage (authentication or accounting), and therefore is not specific to
RADIUS/EAP. It therefore would be best to handle this as a separate
document.

> There are other reasons why the RFC 2998 algorithms are inappropriate
> for use with RADIUS. Some are mentioned in RFC 2865 (section 2.4);

Section 2.4 mentions that TCP is too aggressive in terms of
retransmission. However in practice we are seeing RADIUS client
implementations that are much *more* aggressive than TCP. For
example, one RADIUS client from a well known vendor has a default RTO of 1
second with no backoff. Several thousand of these clients recently
caused a service outage on our network after a network-wide password
reset resulted in a RADIUS server overload. Since the clients did not back off
(or jitter) the result was extremely high load as clients kept retrying
EAP authentication without success, hammering the servers until we had to
change the network-wide configuration to bring the network online again.

The other thing mentioned in section 2.4 is that faster failover is
desired than what TCP would provide. It seems to me that RTO
estimation and failover are orthogonal issues so that doing dynamic RTO
estimation and backoff need not adversely affect failover algorithms.

> others include an initial TMO that is likely to be too short in
> situations where one or more RADIUS proxies are traversed, the large
> granularity of the timers specified and the deterministic nature of the
> algorithms used which in the worst case could result in all the clients
> firing repeated salvos of requests in lockstep (not a good way to reduce
> instantaneous server loading!).

I agree that jitter is required here, and that the initial RTO might be
set to a higher value (say, 5 seconds).

Proposed resolution: Reject

Issue 126: Miscellaneous NITs
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 10, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001191.html
Document: EAP-03f
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

A few minor editorial nits that should probably be handled somehow:

> 1.2
> authenticator
> The end of the EAP link initiating EAP authentication. The
> term authenticator is used in [IEEE.802.1X], and has the
> same meaning in this document.
>
> peer
> The end of the EAP Link that responds to the authenticator.
> In [IEEE.802.1X], this end is known as the Supplicant.

Just wondering about the capitalization. Does IEEE 802.1X really
call something "authenticator" and something else "Supplicant"?

[BA] -
It uses Authenticator and Supplicant. The definition of authenticator
should be:

authenticator
The end of the EAP link initiating EAP authentication. The
term Authenticator is used in [IEEE.802.1X], and
authenticator has the same meaning in this document.

> 1.3 Security claims terminology for EAP methods
>
> These terms are used in particular in Section 7.2:

s/in particular in Section 7.2/to described the security
properties of EAP methods/

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

Propose to use a slightly different formatting here, maybe
the XML2RFC style='symbol' lists?

> 2. ...
>
> For sessions in which the authenticator acts as a pass-through, it
> MUST determine the outcome of the authentication solely based on
> the Accept/Reject indication sent by the backend authentication
> server; the outcome MUST NOT be determined by the contents of an
> EAP packet sent along with the Accept/Reject indication, or the
> absence of such an encapsulated EAP packet.

This normative language should be moved somewhere else, it
seems a bit out of place in the advantages list. Maybe Section
2.2?

> 2.1. ...
> Supporting multiple authentication methods within an EAP conversation
> would add complexity to the EAP protocol, would enable
> man-in-the-middle attacks (see Section 7.4), and would result in
> interoperability problems, since existing EAP implementations
> typically do not support multiple authentication methods.

The above text seems a bit out of place, its like a statement of
the consensus in the wg and why we have done something.
Suggested rewrite: "Multiple authentication methods within an
EAP conversation are not supported due to their vulnerability to
man-in-the-middle attacks (see Section 7.4) and incompatibility
with existing implementations.", and move this text to be the
lead-in for the last paragraph.

> 6.1 Definition of Terms

Remove the 6.1 heading, I believe the reader will find it
easier to go to the right place in the document if the
structure of the IANA section is "6.1. Packet Codes" and
"6.2. Method Types". Merge the below paragraphs in the above
text, after the first paragraph in 6.

> 6.2 Recommended Registration Policies

Paragraph 2 goes to new 6.1, rest to 6.2.

> Length
>
> The Length field is two octets and indicates the length of the EAP
> packet including the Code, Identifier, Length and Data fields.

I'd prefer "The Length field is two octets. It indicates the number of
octets in the EAP packet including the Code, Identifier, Length, and Data
fields."

[BA] This could be conceived of including MAC headers too, so I'd prefer
we leave it as it is.

Also, Section 4 and 4.1 have duplicate text for the description of
the Length field. Suggest cutting the first text shorter, maybe
"The Length field is two octets and indicates the length of the
complete EAP packet."

> 4.1 ...
>
> Retransmitted Requests MUST be sent with the same Identifier value
> in order to distinguish them from new Requests. The contents of
> the data field is dependent on the Request Type. The peer MUST

"are dependent" ?

> 5. Initial EAP Request/Response Types
>
> All EAP implementations MUST support Types 1-4, which are defined in
> this document, and SHOULD support Type 254. Follow-on RFCs MAY define
> additional EAP Types.

MAY in the last sentence does not appear to be an implementation
requirement. Replace with "Implementations MAY support other
Types defined here or in future RFCs."

> 5.7 Expanded Types
>
> Description
>
> Due to EAP's popularity, the original method Type space, which
> only provides for 255 values, is being allocated at a pace which
> if continued would result in exhaustion within a few years.

This is an interesting status report, but may not be very useful in
a protocol specification. In any case, the text that comes after this
explains the purpose of the scheme. Suggestion: delete the first
sentence.

> 7.11. ...
>
> This can be done by enabling users to configure which are the
> acceptable ciphersuites as a matter of security policy; or, the
> ciphersuite negotiation MAY be authenticated using keying material
> derived from the EAP authentication and a MAC algorithm agreed upon
> in advance by lower-layer peers.

s/MAC/MIC/

Proposed resolution: Accept

Issue 127: Security Terms
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 12, 2003
Reference:
Document: EAP-02
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

I have a few question marks related to specific
security issues:

> Replay protection
> This refers to protection against replay of EAP messages,
> including EAP Requests and Responses, and method-specific
> success and failure indications.

Question: Is it always so that replay protection of messages
implies replay protection of the full method? I could imagine a
broken method which initializes the replay protection (e.g.
client gives a counter) in a way which makes it possible for
someone to replay the whole method? Suggest s/EAP messages
including EAP requests and responses, and/ an EAP method or its
messages, including/

> Man-in-the-Middle resistance
> The ability for the peer to demonstrate to the
> authenticator that it has acted as the peer for each
> authentication method within the conversation. Similarly,
> the authenticator demonstrates to the peer that it has
> acted as the authenticator for each authentication method
> within the conversation. If this is not possible, then the
> authentication sequence or tunnel may be vulnerable to a
> man-in-the-middle attack.

This applies only for tunnels and sequences, but the text
could be clearer about it. Replace last sentence with "If
this is not possible, then there may be a vulnerability to
a man-in-the-middle attack." Add a new sentence at the
beginning: "This property applies only for the use of
multiple methods in a combination, such as in authentication
sequences or tunnels.".

> MiTM resistance: No

(In many places.) I believe this should really be a "N/A"
instead, because an individual method can do little to
protect against MitM even if its perfect. Unless the
method is a tunnel method, of course, in which case it can do or
not do much for MitM...

> Since EAP is a peer-to-peer protocol, an independent and simultaneous
> authentication may take place in the reverse direction. Both peers
> may act as authenticators and authenticatees at the same time.

Perhaps add a reference to Section 7.7 which talks about the
limitations of two simultaneous authentications.

[BA] "For a discussion of security issues in peer-to-peer
operation, see Section 7.7."

Proposed resolution: Accept

Issue 128: Encapsulation reference
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 12, 2003
Reference:
Document: EAP-03.f
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

> 1. Introduction
>
> EAP may be used on dedicated links as well as switched circuits, and
> wired as well as wireless links. To date, EAP has been implemented
> with hosts and routers that connect via switched circuits or dial-up
> lines using PPP [RFC1661]. It has also been implemented with switches
> and access points using IEEE 802 [IEEE.802.1990]. EAP encapsulation
> on IEEE 802 wired media is described in [IEEE.802.1X].

Add wireless LANs to this list: "EAP encapsulation on IEEE
wireless LANs is described in [IEEE.802-11.1999].

[BA] -

Ah, but it isn't defined there. It *will* be defined in
IEEE 802.11i, but the encapsulation could be different
from that specified in IEEE 802.1X-2001. For example, it
has been suggested that EAP be encapsulated within
IEEE 802.11 Authenticate frames instead of data frames.

So I would suggest that we add a reference to IEEE 802.11i (a work in
progress) instead.

Proposed resolution: Accept (with modifications)

Issue 129: More NITs
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 12, 2003
Reference:
Document: EAP-03.f
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

From the terms section:

> Displayable Message
> This is interpreted to be a human readable string of
> characters, and MUST NOT affect operation of the protocol.
> The message encoding MUST follow the UTF-8 transformation
> format [RFC2279].

First, I'm not too happy to have keyword behaviour in the terms
section. Secondly, in Section 5.5 this term is used
for the OTP challenge, which I believe contains machine
readable sequence numbers and seeds. That would seem
to affect the behaviour of the protocol! Suggested rewrite:
move the MUST-NOT-affect-operation requirement to the
relevant sections where the term is referred to. Keep the
UTF-8 requirement here. Consider replacing 5.5 "displayable
message" with simply a reference to the OTP RFC format.

> 3.4 Lower layer indications
>
> Lower layer failure indications provided to EAP by the lower layer
> MUST be processed and will cause an EAP exchange in progress to be
> aborted. However, lower layer success indications MUST NOT affect EAP
> message processing so that an EAP implementation MUST NOT conclude
> that authentication has succeeded based on those indications.

The last sentence has too many NOTs, I think. How about "However, lower
layer success indications MUST NOT affect EAP message processing so
that the EAP implementation would conclude ..."

> 4.1 Request and Response
>
> Description
>
> The Request packet (Code field set to 1) is sent by the
> authenticator to the peer. Each Request has a Type field which
> serves to indicate what is being requested. Additional Request
> packets MUST be sent until a valid Response packet is received, or
> an optional retry counter expires.

Retry counter? This seems to be the only place we talk about retry
counters. Perhaps a timeout is assumed instead? If so, "..., or
until a timeout expires."

[BA] This section is trying to indicate that Requests are retransmitted
until a maximum retry counter expires. The goal is not to give up just
because a single retransmission attempt timed out.

> 7.14.
>
> [a] On the peer, all EAP packets MUST be silently discarded, except
> for those with Code=1 (Request) and Type=Method-Type. This
> implies that methods supporting "strict interpretation" do not
> utilize Notification, but instead support their own
> method-specific error messages.

Hmm... perhaps they don't use notification at all and just want
to avoid getting them? Suggested rewrite: "... do not utilize Notification
or support their own method-specific notification messages."

> Where an authenticator operates as a pass-through, it forwards
> packets back and forth between the peer and a backend authentication
> server, based on the EAP layer header fields (Code, Identifier,
> Length). Since pass-through authenticators rely on a backend
> authenticator server to implement methods, the EAP method layer
> header fields (Type, Type-Data) are not examined as part of the
> forwarding decision. The forwarding model is illustrated in Figure 2.
> Compliant pass-through authenticator implementations MUST by default
> be capable of forwarding packets from any EAP method.

This specification is insufficient for me to implement a
passthrough: it doesn't do some things per above, but
what does it do then? I do realize that the proper
specification depends on the AAA protocol translation
for instance, so maybe we shouldn't expect to have a
full specification here. Perhaps reference 2869bis?
Or should we list the actions that the forwarding decision
must make?

[BA] Here are the proposed fixes:

Change the text in Section 1.2 from:

"Displayable Message
This is interpreted to be a human readable string of
characters, and MUST NOT affect operation of the protocol.
The message encoding MUST follow the UTF-8 transformation
format [RFC2279]."

To:

Displayable Message
This is interpreted to be a human readable string of
characters. The message encoding MUST follow the
UTF-8 transformation format [RFC2279].

Change the text in Section 3.4 from:

"Lower layer failure indications provided to EAP by the lower layer
MUST be processed and will cause an EAP exchange in progress to be
aborted. However, lower layer success indications MUST NOT affect EAP
message processing so that an EAP implementation MUST NOT conclude
that authentication has succeeded based on those indications."

To:

"Lower layer failure indications provided to EAP by the lower layer
MUST be processed and will cause an EAP exchange in progress to be
aborted. However, lower layer success indications MUST NOT affect EAP
message processing; an EAP implementation cannot conclude
that authentication has succeeded based on those indications."

[Jari Arkko]:

In Section 5.5 change:

"The Request contains a displayable message containing an OTP challenge."

To:

"The Request contains an OTP challenge in the format described
in [RFC2289]."

Change the text in Section 7.14 from:

"[a] On the peer, all EAP packets MUST be silently discarded, except
for those with Code=1 (Request) and Type=Method-Type. This
implies that methods supporting "strict interpretation" do not
utilize Notification, but instead support their own
method-specific error messages."

To:

"[a] On the peer, all EAP packets MUST be silently discarded, except
for those with Code=1 (Request) and Type=Method-Type. This
implies that methods supporting "strict interpretation" do not
send or expect to receive Notification-Requests but instead support their own
method-specific error messages."

Change:

"Where an authenticator operates as a pass-through, it forwards
packets back and forth between the peer and a backend authentication
server, based on the EAP layer header fields (Code, Identifier,
Length). Since pass-through authenticators rely on a backend
authenticator server to implement methods, the EAP method layer
header fields (Type, Type-Data) are not examined as part of the
forwarding decision. The forwarding model is illustrated in Figure 2.
Compliant pass-through authenticator implementations MUST by default
be capable of forwarding packets from any EAP method."

To:

"Where an authenticator operates as a pass-through, it forwards
packets back and forth between the peer and a backend authentication
server, based on the EAP layer header fields (Code, Identifier,
Length). This includes performing validity checks on the Code, Identifer and
Length fields, as described in Section 4.1.

Since pass-through authenticators rely on a backend
authenticator server to implement methods, the EAP method layer
header fields (Type, Type-Data) are not examined as part of the
forwarding decision. The forwarding model is illustrated in Figure 2.
Compliant pass-through authenticator implementations MUST by default
be capable of forwarding packets from any EAP method. The use of
the RADIUS protocol for encapsulation of EAP in pass-through
operation is described in [RFC2869bis]."

Proposed resolution: Accept

Issue 130: Potential Deadlock
Submitter name: Lauri Tarkkala
Submitter email address: ltarkkal@ssh.com
Date first submitted: May 13, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

There exist a couple of deadlocks currently in the proposed EAP
protocol as used in e.g. PPP. I do not recall it being discussed
earlier.

Assume we have two PPP peers (A and B) negotating LCP, and both
desire to authenticate each other with EAP. A authenticates B
with EAP and B authenticates A with EAP.

Now assume that both EAP Success messages are "lost" after the
authentication rounds are completed, and since both parties
now have an EAP authentication pending, they will not
start negotiating a NCP (e.g. IPCP) for the link. The
system is effectively in deadlock.

There are some solutions:

1) Require that Success messages are ACK'd.

2) Require authenticatee to retransmit last message untill it
receives a final (Success/Failure) response from the client.

Neither of these is backwards compatible. Currently the only
sensible solution for a PPP implementation is to initiate
an NCP when it "guesses" that an EAP client has completed
(after a suitable timeout) to avoid the above deadlock. This
is of course against the current recommendation of this WG, but
that recommendation means very little if it causes a deadlock.

Note that the lack of an explicit ACK of success means that
it is difficult in this case to distinguish between
"sequential authentication" where several methods are
applied after each other and a dropped EAP-Success.

I do not propose a fix in this submission, because this
interplays with other issues currently under discussion,
but I wanted a separate issue up on this, so it does
not get forgotten.

Lauri

[Pasi Eronen]:

Lauri Tarkkala wrote:

> Assume we have two PPP peers (A and B) negotating LCP, and both
> desire to authenticate each other with EAP. A authenticates B
> with EAP and B authenticates A with EAP.
>
> Now assume that both EAP Success messages are "lost" after the
> authentication rounds are completed, and since both parties
> now have an EAP authentication pending, they will not
> start negotiating a NCP (e.g. IPCP) for the link. The
> system is effectively in deadlock.

I think this situation is not any different from the one-way
case. 2284bis already mentions that Success and Failure packets
are not acknowledged, and thus timeouts are possible if the link
has high error rate.

Consider a single EAP conversation where the Success packet is
lost. This results in a timeout for the peer. If the peer is
happy with the overall situation (e.g. it would enable the link
if it received a Success packet), it may enable the link anyway
(initiate NCP in case of PPP).

In case of two simultaneous EAP conversations, the PPP
connection will succeed if both parties follow this
behavior. Also, the party that has longer timeout may consider
a NCP packet as "lower layer success indication", and process
it appropriately (if we allow lower layer success indications,
as I proposed in my previous message).

(The EAP implementations are not in a true deadlock, because
on both parties, one of the EAP conversations has already
ended, and the conversation instance that is "dangling" is
not waiting for anything from the other "dangling" instance).

[Jari Arkko]:

Pasi.Eronen@nokia.com wrote:

> I think this situation is not any different from the one-way
> case. 2284bis already mentions that Success and Failure packets
> are not acknowledged, and thus timeouts are possible if the link
> has high error rate.
...
> (The EAP implementations are not in a true deadlock, because
> on both parties, one of the EAP conversations has already
> ended, and the conversation instance that is "dangling" is
> not waiting for anything from the other "dangling" instance).

Yes, I think that is right.

Lauri Tarkkala wrote:

> Note that the lack of an explicit ACK of success means that
> it is difficult in this case to distinguish between
> "sequential authentication" where several methods are
> applied after each other and a dropped EAP-Success.

That's right, but we've discouraged the use of sequences.
So I don't think this is an issue.

Proposed Resolution: Reject

Issue 131: Lower layer success indications
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: May 13, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 3.4
Rationale/Explanation of issue:

Lower layer success indications could (or even
should) be processed in some circumstances (when the peer would
be willing to accept an EAP Success message).

How about this?

In Section 3.4, Change:

To:

   "If a peer receives a lower layer success indication when it
   would be willing to accept an EAP Success message, it MAY
   conclude that the Success message was lost, and behave as it
   had received a Success message. In all other circumstances,
   lower layer success indications MUST NOT affect EAP message
   processing."

(Or should that MAY be a SHOULD?)

[Discussion on 5/14/03 Conference Call]:

Issues 121 and 131
------------------

While nobody currently implements lower layer indications, they
could be useful in some circumstances to avoid long timeouts.
However, we want to avoid the situation where the peer enables
the link but the authenticator does not.

Thus, I think the agreement was roughly:
- The peer may process lower layer success indications if
it would be willing to accept an EAP Success packet at that point.
- If the peer has not received a method-specific success
message OR a lower layer success indication, if it times out
when waiting for Success, it does not enable the link
(even if it has authenticated the authenticator).
- We need some text describing the limitations of lower
layer indications. E.g. depending on the link layer,
they may get lost; and they should not have naturally
occuring "false positives".

These lower layer indications could be less well protected than
EAP Success, but it seems that an attacker who spoofs a lower
layer indication can't actually achieve anything, because at
that point the peer is anyway satisfied (e.g. has authenticated
the authenticator, if using a mutually authenticating method).
And if the environment contains active attackers, we are
presumably deriving keys anyway.

In 802.*, EAPOL-Key message is sort-of lower layer success
indication (since the server would not send it unless it had
succeeded). Certainly after the four-way handshake is concluded,
you know that you received access.

We also discussed if Finished message in EAP-TLS is a
method-specific success message. Each method can define
whatever it wants, but in this case it probably is: since
the peer's last response does not contain anything useful,
the authenticator can make its decision before sending Finished
(and if the decision is no, send Alert).

[Jari Arkko]:

>    o What to do if we get a timeout, Policy.isSatisfied() is TRUE, but
>       methodState is not CON_ACC? Issue: can peer go into authenticated
>       state without getting a Success -either internal to the method
>       (Con_ACC) or and EAP Success?

IMHO, no. (But perhaps you have discussed this as a part of the Success
thread; I didn't check.)

>    o What to do if we get an altAccept, Policy.isSatisfied() is TRUE,
>       but methodState is not CON_ACC? Issue: same as above

As above.

[BA] In Issue 121 we have defined the circumstances in
which the peer may eventually conclude that a Success packet
has been lost. In those same circumstances, the proposed
change in Issue 131 allows the peer to conclude that a Success packet
has been lost, without having to wait the full timeout period.
It therefore represents an optimization.

Here are the proposed fixes:

In Section 3.4, Change:

"Lower layer failure indications provided to EAP by the lower layer
MUST be processed and will cause an EAP exchange in progress to be
aborted. However, lower layer success indications MUST NOT affect EAP
message processing so that an EAP implementation MUST NOT conclude
that authentication has succeeded based on those indications."

To:

"Section 4.2 defines the circumstances in which a peer,
having concluded an EAP method with successful acknowledged
result indications, may conclude that a Success packet has
been lost after expiration of a timeout. In those same
circumstances, if a peer receives a lower layer success
indication as defined in Section 7.12, it MAY conclude that
a Success packet has been lost without waiting for a timeout."

In Section 7.12, change:

" [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and Association and Reassociation Response
frames (link success indications). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range."

To:

" [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way handshake
(link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range."

Proposed resolution: Accept

Issue 132: Redundancy of Section 7.14
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: May 13, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 7.14
Rationale/Explanation of issue:

I think we don't need Section 7.14 anymore. The
"strict interpretation" was very useful when it was possible
to switch from one method to another (and it was possible that
successful authorization result would require more than one
successful EAP method).

Now sequences are forbidden, and the "usual" ("non-strict")
processing rules specify the same behavior. E.g. 2.1 says that
the peer must silently discard requests for other types, and 4.2
deals with Success/Failure.

The only thing left is Notifications. I think this could be
dealt with in Section 5.2 by adding the following after the first
paragraph.

   "An EAP method MAY indicate within its specification that
   Notification messages must not be sent during that method.
   In this case, the peer MUST silently discard Notification
   Requests from the point where an initial Request for
   that Type is answered with a Response of the same Type."

(and by removing 7.14)

[Yoshihiro Ohba]:

This additional text would require a change in section 5.2 from:

"The peer MUST respond to a Notification Request with a
Notification Response; a Nak Response MUST NOT be sent."

To:

"The peer MUST respond to a Notification Request with a Notification
Response unless the EAP authentication method specification prohibits
the use of Notification message. In any case, a Nak Response MUST NOT
be sent in response to a Notification Request."

Proposed Resolution: Accept

Issue 133: IESG Comments on RFC 2869bis
Submitter name: Russ Housley
Submitter email address: housley@vigilsec.com
Date first submitted: May 15, 2003
Reference:
Document: RFC2869bis-21
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 4.1 says:

RADIUS/EAP is used in order to provide authentication and authorization
for network access. As a result, both the RADIUS and EAP portions of
the conversation are open to attack.

Does "open to attack" mean likely target of attack? If so, please use
these words. If not, please clarify.

Section 4.2 says:

When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the
encryption transform, and per-packet authentication, integrity and
replay protection MUST be used. A typical IPsec policy for an IPsec-
capable RADIUS client is "Initiate IPsec, from me to any destination
port UDP 1812".

This causes an IPsec SA to be set up by the RADIUS client prior to
sending RADIUS traffic. If some RADIUS servers contacted by the client
do not support IPsec, then a more granular policy will be required:
"Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
port UDP 1812".

I agree that DES-CBC should not be used; however, we ought to tell the
implementors what algorithm ought to be used for
interoperability. Further, the text requires integrity protection, but no
integrity mechanisms are discussed. Also, the discussion of IPsec policy
should not be split between these two paragraphs.

I propose the following:

When IPsec ESP is used with RADIUS, per-packet authentication,
integrity and replay protection MUST be used. AES-CBC SHOULD be
used as the encryption transform, and HMAC-SHA1-96 SHOULD be used
as the authentication function. DES-CBC SHOULD NOT be used as the
encryption transform.

A typical IPsec policy for an IPsec-capable RADIUS client is
"Initiate IPsec, from me to any destination port UDP 1812". This
IPsec policy causes an IPsec SA to be set up by the RADIUS client
prior to sending RADIUS traffic. If some RADIUS servers contacted
by the client do not support IPsec, then a more granular policy
will be required: "Initiate IPsec, from me to
IPsec-Capable-RADIUS-Server, destination port UDP 1812".

Later in section 4.2, the text says: "... it is important that trust be
demonstrated ..." In this context, "trust" is very ambiguous. Please
reword. I think that the paragraph should discuss "authentication" and
"authorization."

Later in section 4.2, change "Certificate Authority (CA)" to
"Certification Authority (CA)."

In section 4.3.1, please add an informative reference for ARP.

In section 4.3.2, please add a pointer to Section 4.2 in the very last
sentence.

In section 4.3.8, please change "even where IPsec is utilized for
transmission layer security" to "even where IPsec is used."

In section 4.3.9, the text says: "As described in Section 4 ..." Since
this text appears in a subsection of section 4 and there is no text
following the single digit heading, a more precise pointer is appropriate.

In section 4.3.9, the last paragraph should tell what security services
are expected from the "wrapping mechanism." I believe that they are
confidentiality, integrity, and data origin authentication.

Proposed Resolution: Accept

Issue 134: EAP transport issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 15, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 4.1, 4.3
Rationale/Explanation of issue:

RFC 2988 doesn't include support for jittering, and includes a good deal of
material that doesn't relate to EAP. As a result, more specific guidance
is required in order to make it clear how dynamic retransmission timeout
estimation is to be applied.

In Section 4.1, delete

"Because the authentication process will often involve user
input, some care must be taken when deciding upon
retransmission strategies and authentication timeouts. By
default, where EAP is run over an unreliable lower layer, the
EAP retransmission timer SHOULD be computed as described in
[RFC2988]. This includes use of Karn's algorithm to filter RTT
estimates resulting from retransmissions. A maximum of 3-5
retransmissions is suggested.

When run over a reliable lower layer (e.g., EAP over ISAKMP/
TCP, as within [PIC]), the authenticator retransmission timer
SHOULD be set to an infinite value, so that retransmissions do
not occur at the EAP layer. Note that in this case the peer
may still maintain a timeout value so as to avoid waiting
indefinitely for a Request.

Where the authentication process requires user input, the
measured round trip times are largely determined by user
responsiveness rather than network characteristics, so that RTO
estimation is not helpful. Instead, the retransmission timer
SHOULD be set so as to provide sufficient time for the user to
respond, with longer timeouts required in certain cases, such
as where Token Cards (see Section 5.6) are involved.

In order to provide the EAP authenticator with guidance as to
the appropriate timeout value, a hint can be communicated to
the authenticator by the backend authentication server (such as
via the RADIUS Session-Timeout attribute)."

Add Section 4.3:

"4.3 Retransmission Behavior

Because the authentication process will often involve user
input, some care must be taken when deciding upon
retransmission strategies and authentication timeouts. By
default, where EAP is run over an unreliable lower layer, the
EAP retransmission timer SHOULD be dynamically estimated.
A maximum of 3-5 retransmissions is suggested.

When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP
as within [PIC]), the authenticator retransmission timer
SHOULD be set to an infinite value, so that retransmissions do
not occur at the EAP layer. The peer may still maintain a
timeout value so as to avoid waiting indefinitely for a Request.

Where the authentication process requires user input, the
measured round trip times may be determined by user
responsiveness rather than network characteristics, so that dynamic
RTO estimation may not be helpful. Instead, the retransmission timer
SHOULD be set so as to provide sufficient time for the user to
respond, with longer timeouts required in certain cases, such
as where Token Cards (see Section 5.6) are involved.

In order to provide the EAP authenticator with guidance as to
the appropriate timeout value, a hint can be communicated to
the authenticator by the backend authentication server (such as
via the RADIUS Session-Timeout attribute).

In order to dynamically estimate the EAP retransmission timer,
the algorithms for estimation of SRTT, RTTVAR and RTO described
in [RFC2988] are RECOMMENDED, including use of Karn's algorithm,
with the following potential modifications:

a) In order to avoid synchronization behaviors that can occur with
fixed timers among distributed systems, each time the retransmission timer
is calculated with a jitter by using the RTO value and
randomly adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative
calculations to create jitter MAY be used. These MUST be pseudo-
random, generated by a PRNG seeded as per [RFC1750].

b) When EAP is transported over a single link (as
opposed to over the Internet), smaller values of RTOinitial,
RTOmin and RTOmax MAY be used. Recommended values are
RTOinitial=1 second, RTOmin=200ms, RTOmax=20 seconds.

c) When EAP is transported over a single link (as opposed
to over the Internet), estimates MAY be done on a
per-authenticator basis, rather than a per-session
basis. This enables the retransmission estimate to make the
most use of information on link-layer behavior

d) An EAP implementation MAY clear SRTT and RTTVAR after
backing off the timer multiple times as it is likely that the
current SRTT and RTTVAR are bogus in this situation. Once SRTT and
RTTVAR are cleared they should be initialized with the next RTT
sample taken as described in [RFC2988] equation 2.2."

Proposed resolution: Accept

Issue 135: SSID in PRF
Submitter name: Bob Moskowitz
Submitter email address: rgm@trusecure.com
Date first submitted: May 15, 2003
Reference:
Document: KeyFramework-06
Comment type: T
Priority: S
Section: Appendix F
Rationale/Explanation of issue:

In appendix F, I might think that the SSID should be included in the PRF.

[BA] The notion of an SSID is media specific, but
EAP is media independent, so that inclusion of the
SSID is not appropriate.

Proposed resolution: Reject

Issue 136: SM-02 NITs
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 14, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001217.html
Document: SM-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

1. Abstract is too long, appears to be more of an introduction than
a brief abstract. Suggested rewrite:

   "This document describes informational state machines for the
    participants in the Extensible Authentication Protocol (EAP).
    State machines are given for the EAP peers and authenticators,
    the passthrough method, and for the backend adapter. The
    state machine for the EAP authenticator can operate with
    local authentication or through a backend authentication
    server connected via an Authentication, Authorization,
    and Accounting (AAA) protocol. The state machines have
    been described using the EAP multiplexing model, which
    divides the events and actions to those handled by the
    EAP multiplexer and those handled by the EAP methods."

2. Isn't it customary to expand abbreviations in the
title? Perhaps this document could be called "State Machines
for the Extensible Authentication Protocol (EAP)"?

3. Can we synchronize the figures in Section 2.2 of RFC
2284bis-03, and Section 2 of the SM draft? At the same
time, it might make sense to call Section 2 "Introduction",
and treat the above additional subjects:

    - Document authority (take text from 3.2)

Also, it might make sense to combine the format text
in the first and last paragraphs of section 2 in one
place.

4. In 3.2, perhaps replace the last sentence with
"If there are any discrepancies between this document
and [RFC2284bis], [RFC2869bis], the latter two take
precedence."

5. In 4.2, perhaps the notation in "IN: eapReqData, (reqId)"
could be clarified. I suppose the paranthesis mean optional
or out-of-scope information? Or do they mean parameters to
a function?

6. Spelling: Passtrhough, peerto.

7. References to be split to normative and non-normative.
For this document, I believe the normative ones are 2119,
2284bis, and 2869bis. IEEE documents are non-normative.

8. It might make sense to refer to just 2284bis, not 2284.

>    o Do we need a new variable to signal the lower layer that keying
>       material is available (in eapKey), or is it enough that the lower
>       layer checks if eapKey!=NONE after getting eapSuccess?

I think it may be more readable to just use one variable.

Proposed resolution: Accept

Issue 137: Authenticator Timeout Failure Issue
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 14, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001218.html
Document: SM-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

2284bis-03.f:

    The authenticator MUST NOT send a Success or Failure packet as a
    result of a timeout. After a suitable number of timeouts have
    elapsed, the authenticator SHOULD end the EAP conversation.

sm-02 authenticator:

    From the figure we can see that when aWhile goes to zero,
    you will go to RETRANSMIT, possibly retransmit a few times,
    and eventually go to FAILURE, and set eapReqData.

I have three issues with the above:

1) 2284bis could be clearer, imho, that even after a number
    of timeouts you don't send a Failure. Suggested rewrite:
    "The authenticator is responsible for retransmitting requests
     as described in Section 4.1. After a suitable number of
     retransmissions, the authenticator SHOULD end the EAP
     conversation. The authenticator MUST NOT send a Success
     or Failure packet when retransmitting or when it fails
     to get a response from the peer."

2) The FAILURE state constructs a Failure response,
    but 2284bis forbids this to be sent when the
    failure is due to a timeout (I think).

3) You could say perhaps that the Failure response
    is not really sent, and is only internally
    constructed, because eapReq is not set. However,
    if this is true then FAILURE and SUCCESS states
    both have an issue when used in other cases:
    they don't set eapReq either.

    Suggested fix: set eapReq in FAILURE and SUCCESS.
    Provide a different state for timeout-based
    failures, which does nothing.

[Pasi Eronen]:

This issue was listed in Appendix A of sm-02 draft
as a "known inconsistency" between 2284bis and SM
(the Failure response is actually sent although
eapReq is not set; see Section 5.1 of sm-02 draft).

Here's an updated diagram that fixes this, and also
attempts to show how timeouts are calculated
(changes to -02 version are shown in blue).

http://www.cs.hut.fi/~peronen/eap/eap_authenticator_14052003.png

(Does the handling of timeouts look ok? The idea is that
if a method has some idea what the timeout should be, it
sets methodTimeout. eapRttEstimate comes from the lower
layer)

Proposed resolution: Accept

Issue 138: Miscellaneous -03 issues
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 14, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: 2, 4
Rationale/Explanation of issue:

The description of the Length field in Section 4 is as follows:

The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length and Data fields.
Octets outside the range of the Length field should be treated as
Data Link Layer padding and should be ignored on reception.

What happens if the Length field indicates a length greater than
the received number of octets? Perhaps this should also be specified:

A message with the Length field set to a value larger than the
number of received octets MUST be silently discarded.

Also, perhaps change "should be ignored" to "MUST be ignored".

2284bis-03.f:

The authenticator MUST NOT send a Success or Failure packet as a
result of a timeout. After a suitable number of timeouts have
elapsed, the authenticator SHOULD end the EAP conversation.

2284bis could be clearer, imho, that even after a number
of timeouts you don't send a Failure. Suggested rewrite:

"The authenticator is responsible for retransmitting requests
as described in Section 4.1. After a suitable number of
retransmissions, the authenticator SHOULD end the EAP
conversation. The authenticator MUST NOT send a Success
or Failure packet when retransmitting or when it fails
to get a response from the peer."

[BA] Here are the fixes:

In Section 2, change:

"The authenticator MUST NOT send a Success or Failure packet as a
result of a timeout. After a suitable number of timeouts have
elapsed, the authenticator SHOULD end the EAP conversation."

To:

"The authenticator is responsible for retransmitting requests
as described in Section 4.1. After a suitable number of
retransmissions, the authenticator SHOULD end the EAP
conversation. The authenticator MUST NOT send a Success
or Failure packet when retransmitting or when it fails
to get a response from the peer."

In Section 4, change:

To:

" The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length and Data fields.
Octets outside the range of the Length field should be treated as
Data Link Layer padding and MUST be ignored on reception.
A message with the Length field set to a value larger than the
number of received octets MUST be silently discarded."

Proposed resolution: Accept

Issue 139: Response to duplicate requests
Submitter name: Nick Petroni
Submitter email address: npetroni@cs.umd.edu
Date first submitted: May 14, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

"If a peer receives a duplicate Request before it has
sent a Response, but after it has determined the initial Request
to be valid (i.e. it is waiting for user input), it MUST silently
discard the duplicate Request. "

Seems like the peer should
be able to send as many responses as it gets requests for the same
id. It may not send a response for prior id after it has sent a
response to current id. This is how the state machine works, and
hopefully the wording in 2284bis will be modified to match.

[BA] Here are the proposed fixes:

Change:

"If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response. If
a peer receives a duplicate Request before it has sent a Response,
but after it has determined the initial Request to be valid (i.e.,
it is waiting for user input), it MUST silently discard the
duplicate Request. An EAP message may be found invalid for a
variety of reasons: failed lower layer CRC or checksum, malformed
EAP packet, EAP method MIC failure, etc."

To:

"If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response
without reprocessing the Request. Requests MUST be processed
in the order that they are received, and MUST be processed
to their completion before inspecting the next Request."

Proposed resolution: Accept

Issue 140: SM incompatibilities with RFC 2284bis
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: May 14, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-May/001222.html
Document: SM-02
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I'm trying to go through and check the state machine against the
2284bis document, to see if they are consistent and that neither
one lacks anything. Below I'll treat each individual state in the
peer state machine and discuss whether the corresponding
funtionality exists in 2284bis. The summary is that there
specifications are pretty well in sync, but a few issues
may need to be worked on.

DISABLED: OK -- not covered in 2284bis

INITIALIZE: OK -- more detail in sm
   - I think this is inline with Section 2.1,
     though 2284bis does not explicitly talk
     about this

DISCARD: OK (with a nit) -- 2284bis has more detail
   - Section 4 has a silent discard for other Code values
   - I also recently sent e-mail about whether Length >=
     received PDU should
     cause a silent discard. This too might be something
     that parseEapReq does, though it isn't specified in
     detail.
   - Perhaps there should be a "logEvent" call, as is
     required in 2284bis in the silent discard definition?

RETRANSMIT: OK (but one open issue) -- same level of detail
   - Section 4:
       If a peer receives a valid duplicate Request for which it has
       already sent a Response, it MUST resend its original Response.
   - But note the open issue listed in the sm document about
     multiple responses to the same retransmitted request while
     waiting for user input

NOTIFICATION: OK -- same level of detail
    - I think the state machine is in line with Section 2.1

SEND_RESPONSE: OK -- this is just an abstraction in the sm

GET_METHOD: NOT OK -- same level of detail, one nit and one problem
    - Incoming arrow valid according to Section 2.1 and Section 4
    - First if branch valid according to Section 2.1
    - Second if branch valid, but note that it would be imho
      clearer if setting the methodState to NORMAL in METHOD
      would also result in setting currentMethod to NONE.
      Then we could remove "resetCurrentMethod"? On the other
      hand, you appear to rely on currentMethod to stay intact
      for forbidding sequences... right?
    - The third if branch appears unclear or perhaps incorrect. Section 2.1:
       "A peer MUST NOT send a Nak (legacy or expanded) in reply to a
        Request, after an initial non-Nak Response has been sent. Since
        spoofed EAP Request packets may be sent by an attacker, an an
        authenticator receiving an unexpected Nak SHOULD silently discard it
        and log the event."
       And here we send a Nak (even if we were in the middle of
       another method). The spec talks about it being invalid for
       the authenticator to send other types while already doing
       one authentication method. We also talk about the strict
       mode, where such requests would be silently discarded.
       But I didn't find a place that says what we should do
       outside the strict mode for such requests. So should we
       respond with a Nak, as the sm does? Or silent discard?
       If silent discard, we need to split the third if branch
       into two, one dealing with currentmethod = NONE and
       one with the other case.

METHOD: NOT OK -- one nit and one small error
    - Aligned with A.1 in general, but:
    - Perhaps there should be a call to logEvent, to show the
      SHOULD requirement in A.1?
    - A.1 allows MIC failure to be a fatal error. This does
      not appear to be handled by the sm.

The following MUST requirement from 2284bis don't appear to
be handled:

    Nak (Type 3) or
    Expanded Nak (Type 254) are valid only for Response packets, they
    MUST NOT be sent in a Request.

(I'm assuming this can be interpreted on the peer side as silent
discard...)

I didn't look at FAILURE and SUCCESS, because alternative indications
were being discussed on the list. Also, the other state machines
remain to be checked...

[Pasi Eronen]:

Big thanks for reviewing the state machine document!
We've spent so much time on those diagrams what we're
probably blind to any problems in it by now :-)

> DISCARD: OK (with a nit) -- 2284bis has more detail
>   - Section 4 has a silent discard for other Code values
>   - I also recently sent e-mail about whether Length >=
>     received PDU should
>     cause a silent discard. This too might be something
>     that parseEapReq does, though it isn't specified in
>     detail.

Yes, parseEapReq is supposed to do this: if the PDU has
invalid length or code, it doesn't set rxReq (which results
in silenty discard).

>   - Perhaps there should be a "logEvent" call, as is
>     required in 2284bis in the silent discard definition?

We discussed this, but decided not to show any logging calls
here. Real implementations will probably log many events not
explicitly mentioned for logging in 2284bis (such as success
and failure!), and logging does not change the behavior of the
change machine.

(For the same reason, we didn't include any "statistics"
variables that would not change the operation of the state
machine, but could be interesting to show in some authenticator
management interface)

> GET_METHOD: NOT OK -- same level of detail, one nit and one problem
>    - Incoming arrow valid according to Section 2.1 and Section 4
>    - First if branch valid according to Section 2.1
>    - Second if branch valid, but note that it would be imho
>      clearer if setting the methodState to NORMAL in METHOD
>      would also result in setting currentMethod to NONE.
>      Then we could remove "resetCurrentMethod"? On the other
>      hand, you appear to rely on currentMethod to stay intact
>      for forbidding sequences... right?

There's a new version of the peer diagram that has simplified
this state and METHOD state considerably. You may want to review
that one instead (although we don't have yet the explanatory
text for it).

It's available at:
http://www.cs.hut.fi/~peronen/eap/eap_peer_13052003.png

Regarding your question: Setting methodState to NORMAL can't
reset currentMethod, because NORMAL is used for two different
purposes: when the method has ended, and when the method can
either continue or end (this is one of the things handled
differently in 13052003 version).

> - The third if branch appears unclear or perhaps incorrect. Section 2.1:
>    "A peer MUST NOT send a Nak (legacy or expanded) in reply to a
>     Request, after an initial non-Nak Response has been sent. Since
>     spoofed EAP Request packets may be sent by an attacker, an an
>     authenticator receiving an unexpected Nak SHOULD silently discard
>     it and log the event."
>
>     And here we send a Nak (even if we were in the middle of
>     another method). The spec talks about it being invalid for
>     the authenticator to send other types while already doing
>     one authentication method. We also talk about the strict
>     mode, where such requests would be silently discarded.
>     But I didn't find a place that says what we should do
>     outside the strict mode for such requests. So should we
>     respond with a Nak, as the sm does? Or silent discard?
>     If silent discard, we need to split the third if branch
>     into two, one dealing with currentmethod =NONE and
>     one with the other case.

Again, this is handled quite differently in 13052003 version,
but the basic principle is correct in sm-02 version as well: the
third branch (that sends the Nak) is reached only if
currentMethod is NONE or IDENTITY (assuming we're not inside a
tunnel, something removed in 13052003 version completely).
So we are not in the middle of a method, and haven't sent any
responses for Types >=4 yet.

> METHOD: NOT OK -- one nit and one small error
>     - Aligned with A.1 in general, but:
>     - Perhaps there should be a call to logEvent, to show the
>      SHOULD requirement in A.1?
>    - A.1 allows MIC failure to be a fatal error. This does
>      not appear to be handled by the sm.

As an unintended consequence of other changes, the last
item seems to be better handled in 13052003 version :-)

Proposed resolution: Discuss

Issue 141: Minor NITs
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: May 19, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

- Section 5: "In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A possible registered stringprep profile
is specified in [SASLPREP]."

SASLPREP is not (yet) a registered stringprep profile. Proposed
text: "A preliminary version of a possible stringprep
profile is described in [SASLPREP]."

- Section 1.3: I think it would be simpler if the terminology section
only defined the terms, but would not specify any requirements
for EAP implementations. At least, unnecessary duplication
of those requirements should be avoided. Here are some
proposed changes that would simplify 1.3 somewhat:

- Master Session Key (MSK): delete second paragraph (similar text
was already deleted from 7.10)
- Delete "EAP Master key (MK)": no longer necessary since
the term is not used anywhere.
- Key derivation: Delete the last two sentences (unnecessary
duplication)
- Key strength: Delete (unnecessary duplication, since it's
already specified in main text)
- Extended Master Session Key (EMSK): Proposed replacement:
"Additional keying material that is derived between the EAP
client and server, reserved for future use."
- Cryptographic separation: delete. Instead, add to section 7.10,
4th paragraph, after the first sentence: "That is, knowledge
of one substring MUST NOT help in recovering some other
substring without breaking some hard cryptographic assumption."

[Jari Arkko] - In general I agree with what has been
stated in http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20141
and support the proposed changes. However, I think the term "cryptographic
separation" should stay in the document, because the definition
is more precise than the suggested replacement.

Also, regarding the MSK and EMSK, should we instead
move the normative language to the main body, not
delete it completely?

[BA] Here are the proposed fixes:

In Section 5, change:

"In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A possible registered stringprep profile
is specified in [SASLPREP]."

To:

"In this case, the input should be processed using an
appropriate stringprep [RFC3454] profile, and encoded in octets using
UTF-8 encoding [RFC2279]. A preliminary version of a possible
stringprep profile is described in [SASLPREP]."

In Section 1.3, change:

"EAP Master key (MK)
A key derived between the EAP client and server during the
EAP authentication process that is purely local to the EAP
method. The MK MUST NOT be exported from the EAP method or
be made available to a third party. Since derivation of
the MK is a residue of the successful completion of the EAP
authentication exchange, proof of MK possession may be used
to shorten future EAP exchanges between the same EAP client
and server, a technique known as "fast resume".

Master Session Key (MSK)
Keying material that is derived between the EAP client and
server. The MSK is used in the derivation of Transient
Session Keys (TSKs) for the ciphersuite negotiated between
the EAP peer and authenticator. Where a backend
authentication server is present, acting as an EAP server,
it will typically transport the MSK to the authenticator.

The MSK differs from the MK in that it not assumed to
remain local to the EAP method, and is known by all parties
in the EAP exchange: the peer, authenticator and the
authentication server (if present). The MSK MAY be derived
from the MK via a one-way function, or it may be an
independent quantity. However possession of the MSK MUST
NOT provide any information useful in determining the MK.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. However,
unlike the MSK, the EMSK is known only to the EAP peer and
EAP server and MUST NOT be provided to a third party. The
EMSK therefore MUST NOT be transported by the backend
authentication server to the authenticator. The EMSK is
reserved for future uses that are not defined yet. For
example, it could be used to derive additional keying
material for purposes such as fast handoff,
man-in-the-middle vulnerability protection, etc."

To:

"Master Session Key (MSK)
Keying material that is derived between the EAP client and
server. The MSK is used in the derivation of Transient
Session Keys (TSKs) for the ciphersuite negotiated between
the EAP peer and authenticator. Where a backend
authentication server is present, acting as an EAP server,
it will typically transport the MSK to the authenticator,
so that in this case, the MSK is available to the peer,
authenticator and authentication server.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. Unlike
the MSK, the EMSK is known only to the EAP peer and
EAP server and is not provided to a third party. The EMSK is
reserved for future uses that are not defined yet. For
example, it could be used to derive additional keying
material for purposes such as fast handoff,
man-in-the-middle vulnerability protection, etc."

In Section 7.10, change:

" Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other. This is required because some existing
ciphersuites form TSKs by simply splitting the MSK to pieces of
appropriate length. Likewise, non-overlapping substrings of EMSK
MUST be cryptographically separate from each other, and from
substrings of the MSK."

To:

" Non-overlapping substrings of the MSK MUST be cryptographically
separate from each other, as defined in Section 1.3. That is, knowledge
of one substring MUST NOT help in recovering some other substring without
breaking some hard cryptographic assumption. This is required because
some existing ciphersuites form TSKs by simply splitting the MSK to pieces of
appropriate length. Likewise, non-overlapping substrings of the EMSK
MUST be cryptographically separate from each other, and from
substrings of the MSK."

Proposed resolution: Accept

Issue 142: Contents of EAP-Request/Identity
Submitter name: Tim Moore
Submitter email address: timmoore@microsoft.com
Date first submitted: June 9, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: 5.1, Appendix A
Rationale/Explanation of issue:

In Section 5.1, change:

"This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. The
Response uses this field to return the Identity. If the Identity
is unknown, this field should be zero bytes in length. The field
MUST NOT be null terminated. The length of this field is derived
from the Length field of the Request/Response packet and hence a
null is not required."

To:

"This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where
the Request contains a null, only the portion of the field prior to
the null is displayed, with portion after the null used as a hint to the
peer as to the identity to be provided in the Response, as described
in Appendix A.2. If the Identity is unknown, the Identity Response
field should be zero bytes in length. The Identity Response field
MUST NOT be null terminated. In all cases, the length of the
Type-Data field is derived from the Length field of the
Request/Response packet."

Add to Appendix A:

"A.2 Contents of the EAP Request/Identity Type-Data field

In addition to providing a displayable message to the peer, the authenticator may wish to provide a
hint as to the appropriate identity to place in the Type-Data field of the
EAP-Response/Identity.

To allow for both a displayable message as well as potential hints, the
EAP-Request/Identity message is formatted as follows:

<display-string>\0networkid=<network-name>,nasid=<nas-name>,portid=<port-id>

Where:

network-name: Name(s) of the network(s) to which the authenticator connects.
For 802.11, this will typically correspond to the SSID.

nas-name: Name or address of the NAS.

port-id: port that the EAP session is on.

The EAP peer should display display-string before the null termination (\0)"

[Jari Arkko]:

Several issues relate to this problem. One issue is that
there's existing deployment where the nul character is
used to separate a message and a some other information
in EAP Identity Request.

Another issue is how to represent AUPs.

A third issue is how to represent parameters to the
peer, and if such parameters are needed in the first
place.

Given that we have a deployed protocol, I'd suggest
the following approach:

1. We need to document that there can be a nul character
in the data part of EAP Identity Request, and that
the message should only be displayed until the nul.

2. Perhaps we should not say too much about the
use of the field after the nul. Certainly no
normative text.

I don't think appendix A is the right place for
this text. I would try to cut the text down and
just place it as a note in the place where the
EAP Identity REquest is discussed. Like this,
for example:

Note: Some existing implementations are known to
pass parameters after the nul character. Support
for such parameters is implementation specific,
but where used their format SHOULD be a comma
separated list of parameter=value assignments.

3. Lets not claim anything about the AUP in the text.
I agree that its probably best done at the link layer,
but this may not always be possible. If it isn't
possible then the message in the identity request
may be used for that purpose. However, I wouldn't
write that down in the spec as I don't think that
would the recommended practice.

[BA] I am concerned that the material proposed for Appendix A.2 is
currently not specified well enough, and would require considerable
additional work in order to complete, delaying RFC 2284bis. What we need is:

a) An ABNF describing the grammar for the parameters and values;
b) IANA considerations for allocation of parameters and values.

This material is likely to require enough work (and be large enough)
to warrant a separate document on the subject. Therefore my recommendation
is that we only take the changes to Section 5.1 at this point, and
examine whether there is sufficient WG consensus to start work on
a separate document to handle a) and b).

Here are the proposed fixes:

Proposed Resolution: Accept

Issue 143: EAP-04 Editorial Nits
Submitter name: Henrik Levkowetz
Submitter email address: henrik@levkowetz.com
Date first submitted: June 18, 2003
Reference:
Document: EAP-04
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue:

Section 1.3:

"Acknowledged result indications
The ability of the authenticator to provide the peer with
an indication of whether the peer has successfully
authenticated to it, and for the peer to acknowledge
receipt, as well as providing an indication of whether the
authenticator has successfully authenticated to the peer.
Since EAP Success and Failure packets are neither
acknowledged nor integrity protected, this claim requires
implementation of a method-specific result exchange that is
authenticated, integrity and replay protected on a
per-packet basis."

s/authenticated, /authenticated and/

Section 2.2:

"EAP packets with codes of Success or Failure do not include a Type,
and therefore are not delivered to an EAP method. Success and
Failure are discussed in Section 4.2."

s/and therefore/and/

(- I don't see an immediate logic, so I'd rather just state the rule here.)

Section 3.1:

"[1] Unreliable transport. In EAP, the authenticator retransmits
Requests that have not yet received Responses, so that EAP does
not assume that lower layers are reliable. Since EAP defines it
own retransmission behavior, when run over a reliable lower
layer, it is possible (though undesirable) for retransmission to
occur both in the lower layer and the EAP layer."

Awkward. Rewrite last part to: "Since EAP defines its
own retransmission behavior, it is possible (though undesirable)
for retransmission to occur both in the lower layer and the EAP
layer when EAP is run over a reliable lower layer."

...

"After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same
entity that successfully completed EAP authentication, the lower
layer needs to bind per-packet integrity, authentication and
replay protection to the original EAP authentication, using keys
derived during EAP authentication. Alternatively, the lower
layer needs to be physically secure. Otherwise it is possible
for subsequent data traffic to be hijacked, or replayed."

s/hijacked,/hijacked/
...

"In IEEE 802 media, key activation also typically occurs after
completion of EAP authentication. Therefore an initial EAP
exchange typically cannot be protected by lower layer
ciphersuite, although an EAP re-authentication or
pre-authentication exchange can be protected."

s/by lower layer/by the lower layer/

Section 4.1:

"Retransmitted Requests MUST be sent with the same Identifier value
in order to distinguish them from new Requests. The contents of
the data field are dependent on the Request Type. The peer MUST
send a Response packet in reply to a valid Request packet.
Responses MUST only be sent in reply to a valid Request and never
retransmitted on a timer."

s/The contents of the data field are/The content of the data field is/

Section 5.3.2:

"Length

>=40"

Is my math off today? I count the length to 20 octets or more, not 40 or more.

s/40/20/

...

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (OTP) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 20 (MIT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

s/Length/Length=28/

An Expanded Nak Response indicating a no desired alternative would
appear as follows:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Nak) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=254 | 0 (IETF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (No alternative) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

s/Length/Length=20/

Section 5.7:

"The Expanded Type is also used to expand the global Method Type
space beyond the original 255 values. A Vendor-Id of 0 maps the
original 255 possible Types onto a namespace of 2^32-1 possible
Types, allowing for virtually unlimited expansion. (Type 0 is only
used in a Nak Response, to indicate no acceptable alternative)"

s/namespace/number space/

s/, allowing for virtually unlimited expansion//

(the last part of the sentence, while true, is maybe too much elaborating the obvious?)


Section 7.4 Man-in-the-middle attacks: 

"As noted in Section 2.1, EAP does not permit sequences of
authentication methods. Were a sequence of EAP authentication
methods to be permitted, the peer might not have proof that a single
entity has acted as the authenticator for all EAP methods within the
sequence. For example, an authenticator might terminate one EAP
method, then forward the next method in the sequence to another party
without the peer's knowledge or consent. Similarly, the
authenticator might not have proof that a single entity has acted as
the peer for all EAP methods within the sequence.

This enables an attack by a rogue EAP authenticator tunneling EAP to

..."

s/This enables/Tunnelling EAP within another protocol enables/

Section 7.6:

"Where EAP runs over lower layers which are not physically secure, in
order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used."

Rewrite as: 

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not
physically secure."


"If an authentication algorithm is used that is known to be vulnerable
to dictionary attack, then the conversation may be tunneled within a
protected channel, in order to provide additional protection.
However, as noted in Section 7.4, EAP tunneling may result in a
man-in-the-middle vulnerability, and therefore dictionary attack
resistant methods are preferred."

s/channel,/channel/

Section Appendix B. Changes from RFC 2284:

Add: 

"o In sections 5, 5.1 and 5.2, requirements has been added
that fields with displayable messages should contain UTF-8
encoded ISO 10646 characters."

Proposed Resolution: Accept

Issue 144: Use of Zero in a Nak
Submitter name: Henrik Levkowetz
Submitter email address: henrik@levkowetz.com
Date first submitted: June 18, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 1
Section: 5.3
Rationale/Explanation of issue:

There is various text on the use of zero in a NAK, for instance,
Section 5.3.1 says:

      "The legacy Nak Type is valid only in Response messages. It is
      sent in reply to a Request where the desired authentication Type
      is unacceptable. Authentication Types are numbered 4 and above.
      The Response contains one or more authentication Types desired by
      the Peer. Type zero (0) is used to indicate that the sender has
      no viable alternatives."

Reading this, I wondered: When is the value zero used in a NAK? When the
peer doesn't want to *disclose* alternatives, or when there are none
left? May the authenticator continue probing after receiving a zero NAK?

[Jari Arkko]

The text seems to say that the peer has no alternatives. Still,
I wonder if zero is used for other purposes as well. Has it been
used for implementations that can't tell what methods might be
appropriate?

If not, I'd rather say SHOULD NOT probe after receiving
a zero NAK.

[BA] Here is the proposed fix:

In Section 5.3.1, change:

"Type zero (0) is used to indicate that the sender
has no viable alternatives."

To:

"Type zero (0) is used to indicate that the sender
has no viable alternatives, and therefore the
authenticator SHOULD NOT send another Request
after receiving a Nak Response containing a zero
value."

Proposed Resolution: Accept

Issue 145: Terminology: Man-in-the-Middle Resistance
Submitter name: Henrik Levkowetz
Submitter email address: henrik@levkowetz.com
Date first submitted: June 18, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: S
Section: Terminology and throughout
Rationale/Explanation of issue:

"Man-in-the-Middle resistance".

I don't really feel comfortable with the use of this term. From what I
know, Man-in-the-middle attacks have a well established existing
meaning, while here we are defining something related which applies only
to sequences or tunnelled methods. If a reader skips lightly over the
definitions, and doesn't catch the limited meaning of this term, the
classification of MitM resistance: N/A for the basic authentication
methods will not make sense, or in the worst case be misleading.

If I understand the issues correctly, all the basic authentication
methods (MD5, OTP, GTC) *are* vulnerable to classic MitM attacks -
but our MitM resistance term describes something else, and I'd
therefore prefer to call it something else.

[Jari Arkko]

I agree. MITM is too general term.

"Compound authentication Man-in-the-Middle attack resistance"?

Shorter name would be useful..

[BA] In Issue 156, we proposed to delete the definition of Man-in-the-Middle
attack resistance and replace it with "Cryptographic binding" since the two
definitions are roughly equivalent and the latter is more accurate. So the
proposal is to replace usage of MITM with "Cryptographic binding". Since I
think that Issue 156 takes care of this, I'd propose to resolve this issue
as a Reject.

Proposed Resolution: Reject

Issue 146: Multiplexing Model Requirements
Submitter name: Henrik Levkowetz
Submitter email address: henrik@levkowetz.com
Date first submitted: June 18, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 1
Section: 2.2
Rationale/Explanation of issue:

The draft says:

   "Since EAP authentication methods may wish to access the Identity, the
   Identity Request and Response can be assumed to be accessible to
   authentication methods (Types 4 or greater) in addition to the
   Identity method. The Identity Type is discussed in Section 5.1."

There's a requirement on an implementation here, I think.
Maybe we should say that the Identity Request and Response
SHOULD or MUST be made accessible to authentication methods?

[Jari Arkko]

Yes. ... esponse SHOULD be accessible to ....?

[BA] Here is the proposed fix:

In Section 2.2, change:

" Since EAP authentication methods may wish to access the Identity, the
Identity Request and Response can be assumed to be accessible to
authentication methods (Types 4 or greater) in addition to the
Identity method. The Identity Type is discussed in Section 5.1."

to:

" Since EAP authentication methods may wish to access the Identity,
implementations SHOULD make the Identity Request and Response
accessible to authentication methods (Types 4 or greater) in
addition to the Identity method. The Identity Type is discussed
in Section 5.1."

Proposed Resolution: Accept

Issue 147: Initial Key Activation
Submitter name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted: June 16, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 2
Section: 3.1 paragraph 5
Rationale/Explanation of issue:

802 key activation may be prolonged by authentication as well as initiated. The text here
applies to initial authentication.

Requested change: insert the word ", initial" between "media" and "key
activation"

[Jari Arkko]

I think this is right.

[BA] In Section 3.1, change:

"       In IEEE 802 media, key activation also typically occurs after
       completion of EAP authentication. Therefore an initial EAP
       exchange typically cannot be protected by lower layer
       ciphersuite, although an EAP re-authentication or
       pre-authentication exchange can be protected."

To:

"       In IEEE 802 media, initial key activation also typically occurs after
       completion of EAP authentication. Therefore an initial EAP
       exchange typically cannot be protected by lower layer
       ciphersuite, although an EAP re-authentication or
       pre-authentication exchange can be protected."

Proposed Resolution: Accept

Issue 148: Sequences
Submitter name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted: June 16, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 2
Section: 7.4 paragraph 2
Rationale/Explanation of issue:

Security issues addressed in this section
seem to address only what happens in an unprotected EAP method. Section
2.1 indicates that within a tunnel sequences may be used.

Requested change: add the word "untunnelled" between the words "permit" and
"sequences".

[Jari Arkko]: Agree

Proposed Resolution: Accept

Issue 149: Peer Policy
Submitter name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted: June 16, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 2
Section: 7.8 Paragraph 2
Rationale/Explanation of issue:

Peers may include policy, especially when
connecting subnets. Additionally the same identity may have different
permissions at different Access Points.

Requested change: In paragraph 2 make the following 2 changes noted in
quotes below -

Within or associated with each authenticator, it is not anticipated that a
particular named peer will support a choice of methods "for a given
connection". This would make the peer vulnerable to attacks that negotiate
the least secure method from among a set. Instead, for each named peer
there SHOULD be an indication of exactly one method used to authenticate
that peer name "at an access point". If a peer needs to make use of
different authentication methods under different circumstances, then
distinct identities SHOULD be employed, each of which identifies exactly
one authentication method.

[Jari Arkko]

Hmm... I don't have a warm and fuzzy feeling about this.
What if the attacker spoofs the name of the access point
to get the bidding down attack started?

[JRV]

This is where policy must be involved. if the attacker AP bids up, the
authentication should go up. If the attacker AP bids down, the
authentication and also the rights should go down.

Additional info may be involved, depending whether the AP is wireless or
wired. Wireless may require Keys and a different authentication method
than wired.

I think the idea that there should be only one id for each authentication
method is too restrictive. The same user should be able to get on in
different places, with different rights, using different authentication
methods. The user could have different ids for each authentication method
and try to match the id to the access type, geographic location, etc. - but
this seems unlikely in practice.

[Jari Arkko]

I can see your argument.

But I'm still worried that without a specific model
for what policies are possible, there'll be bidding down
problems. For instance, the AP identity does not appear to be
a good source for the policy, but link type (wired/wireless)
might be slightly better.

So, I'd rather err on the safe side and not allow such
flexibility. The downside is that it might make things
hard for some cases. But I'm not sure how typical the
per-AP or per-link type credential policies are. Do
you have any information on that? Compared to the SSID
and other information presented by the authenticator?

Proposed Resolution: Reject

Issue 150: Lower Layer Behavior for Limited Access
Submitter name: Yoshihiro Ohba
Submitter email address: yohba@tari.toshiba.com
Date first submitted: June 18, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: 1
Section: 4.2
Rationale/Explanation of issue:

Text in section 7.9 allows limited access for peer after completion of
EAP authentication with failure, with stating that the interaction of
EAP with lower layers are highly implementation dependent.

On the other hand, the following text in section 4.2 contains
some wording that does not seem to consistent with section 7.9.

"On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure indication,
or the peer decides that it does want to continue the conversation,
possibly after sending a method-specific failure indication), the peer
MUST terminate the conversation and avoid sending data on the link."

I think whether the peer avoids sending data on the link is a sort of
thing that should be described in each lower-layer protocol that
carries EAP, since this is heavily lower-layer dependent as described
in section 7.9. In fact, if the peer avoids sending data on the link,
limited access scenario cannot be realized (though it might depend on
the definition of "link"). In sectioni 4.2, it is described that a
backend EAP server can send EAP Success when it does not need to
authenticate the peer, but how it can determine it does not need to
authenticate the peer in a roaming environment where it might be
difficult for the EAP server to know the network access policy on the
remote NAS? I know this issue was recently discussed and section 4.2
was updated to reflect the discussion, but I still find an
inconsistency that should be resolved.

Requested change:

Remove "and avoid sending data on the link".

[BA] I don't think that the intent of section 7.9 is to make the interpretation
of EAP Failure implementation dependent -- this is the kind of thing that
needs to be standardized in order for the protocol to be interoperable.

Allowing the peer to activate the link after receiving an indication
that the authenticator is not granting access seems dangerous because it
would be likely to either open the door to rogue authenticators or to
timeouts where the peer would attempt to obtain an IP address and fail,
leaving the user in limbo.

[Jari Arkko] The issue that Yoshi raised is mainly related to the interpretation
of the word "link". In some cases its an on/off kind of thing, but
as the PANA example shows, there can be a (limited) link outside the
EAP authentication process. The original text talks about not pretending
that things are OK when they really are not. Simply allowing
data to be sent anyway would be dangerous. But I think John's new
formulation makes sure that the link layer does not by accident
send you important packets over an unauthenticated channel. But it
still allows e.g. PANA local communications.

So I agree with John's formulation.

[BA] Proposed Resolution:

In Section 4.2, change:

"On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure indication,
or the peer decides that it does want to continue the conversation,
possibly after sending a method-specific failure indication), the peer
MUST terminate the conversation and avoid sending data on the link."

To:

"On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a method-specific failure indication,
or the peer decides that it does want to continue the conversation,
possibly after sending a method-specific failure indication), the peer
MUST terminate the conversation and indicate failure to the lower layer."

Proposed Resolution: Accept

Issue 151: EAP-04 comments
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001412.html
Document: EAP-04
Comment type: T
Priority: 1
Section: Various
Rationale/Explanation of issue:

Overall, the draft looks fine, and it seems that we're finally
close to getting it finished! In hindsight, there are a couple
of things that might have been clearer if organized differently,
but it probably doesn't make sense to do such changes at this
point.
---

(Section 2) "Since EAP is a peer-to-peer protocol, an
independent and simultaneous authentication may take place in
the reverse direction. Both peers may act as authenticators
and authenticatees at the same time. For a discussion of
security issues in peer-to-peer operation, see Section 7.7.

I think this does not apply to all lower layers. Perhaps it
should be rephrased to something like "Some lower layers for
carrying EAP, such as PPP, may support peer-to-peer operation,
in which an independent and...".

[Jari Arkko]

Yes. [Alternative re-formulation: "Since EAP is a peer-to-peer
protocol, an independent and simultaneous authentication may take
place in the reverse direction (depending on the capabilities
of the lower layer)."]
---

(Section 4.2) "Success or Failure packets MUST NOT be sent by
an EAP authenticator prior to completion of the final round
of a given method. A peer EAP implementation receiving a
Success or Failure packet prior to completion of the method
in progress MUST silently discard it."

I think there are several EAP methods where the number of rounds
varies (so the phrase "the final round" is not well defined),
depending on many issues, including whether the method is
going to succeed or not.

Perhaps this would better take that into account?

"Success and Failure packets MUST NOT be sent by an EAP
authenticator if the specification of the given method does not
allow the method to finish at that point. A peer EAP
implementation receiving a Success or Failure packet where
sending one is not allowed MUST silently discard it."

[Jari Arkko] Sounds good!
---

(Section 4.2) "If the peer attempts to authenticate to the
authenticator and fails to do so, the authenticator MUST send a
Failure packet and MUST NOT grant access by sending a Success
packet."

I know that this was beaten to death already :-) But since
we have not defined what "failing to authenticate to the
authenticator" means, does this actually impose any
requirements for EAP implementations?

(The problem is that "failing to authenticate" could be thought
as "not successfully authenticating"; but according to the
definition of "successful authentication" in Section 1.2, the
above requirement does not make much sense.)

Perhaps this would capture the intent?

"If the peer attempts to authenticate to the authenticator using
a method that provides key derivation, the authenticator SHOULD
NOT grant access by sending a Success packet if the key
derivation has failed for some reason."

[Jari Arkko] Works for me. Maybe delete "for some reason".
---

(Section 5.7) "EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero."

(Section 5.7) "An implementation that supports the Expanded
attribute MUST treat EAP Types that are less than 256
equivalently whether they appear as a single octet or as the
32-bit Vendor-Type within a Expanded Type where Vendor-Id is
0." and

Otherwise fine, but Expanded Nak packets have a different format
than Legacy Nak packets, so they are not treated exactly
identically.

Perhaps we should add something like "There is one exception to
this rule: Expanded Nak and Legacy Nak packets share the same
code, but must be treated differently because they have a
different format." (an alternative would be to change the
code of Expanded Naks to something else, but probably
this is easier?)

[Jari Arkko] Yes.
---
Appendix B: Two significant changes to RFC 2284 are not
mentioned: mutual authentication and key derivation
(RFC 2284 did not even mention either of them).

[Jari Arkko] Ok.
----
References: There are newer versions of RFC2869bis and SASLPREP
drafts available (Ok, RFC editor will probably handle these...)

[Jari Arkko] Better update them now, just for consistency.
----
References: PIC is most likely dead and superceded by IKEv2, so
maybe we should remove references to PIC and add a pointer to
IKEv2?

[Jari Arkko] Yes, that can be done. (Both the IKEv2 and PANA references
would be non-normative, by the way, so that we don't have
to wait for either one to complete.)

[BA] Here are the proposed fixes:

In Section 2, change:

"ince EAP is a peer-to-peer protocol, an
independent and simultaneous authentication may take place in
the reverse direction."

To:

"Since EAP is a peer-to-peer protocol, an independent and
simultaneous authentication may take place in the reverse
direction (depending on the capabilities of the lower layer)."

In Section 4.2, change:

"Success or Failure packets MUST NOT be sent by
an EAP authenticator prior to completion of the final round
of a given method. A peer EAP implementation receiving a
Success or Failure packet prior to completion of the method
in progress MUST silently discard it."

To:

"Success and Failure packets MUST NOT be sent by an EAP
authenticator if the specification of the given method does not
explicitly permit the method to finish at that point. A peer EAP
implementation receiving a Success or Failure packet where
sending one is not explicitly permitted MUST silently discard it."

In Section 5.7, change:

"EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero."

To:

"EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero. There is one exception to
this rule: Expanded Nak and Legacy Nak packets share the same
code, but must be treated differently because they have a
different format."

In Appendix B, add "Support for mutual authentication and key derivation."

In the reference section, update the references to RFC 2869bis (should
obtain an RFC number soon) and SASLPREP.

Also, change references to PIC to a reference to IKEv2.

Recommended resolution: Accept

Issue 152: Lower layer indications
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001413.html
Document: EAP-04
Comment type: T
Priority: 1
Section: 3.4
Rationale/Explanation of issue:

Section 3.4 says that

   "Section 4.2 defines the circumstances in which a peer,
   having concluded an EAP method with successful acknowledged
   result indications, may conclude that a Success packet has
   been lost after expiration of a timeout. In those same
   circumstances, if a peer receives a lower layer success
   indication as defined in Section 7.2, it MAY conclude that a
   Success packet has been lost without waiting for a
   timeout. This ensures that an attacker spoofing lower layer
   indications can at best succeed in a denial of service
   attack."

This is not exactly what the current state machine does...

The current text says that "if you are in a situation where a
timeout would lead to success (that is, you have received a
method-specific success indication), also lower-layer success
indication does."

What the current state mechine does is "if you are in a
situation where receiving an EAP Success packet would lead to
success, also lower-layer success indication does." Or in other
words, the effect of receiving a lower-layer success indication
is identical to receiving an EAP Success: if an EAP Success
packet would be silently discarded, so is the lower-layer
success indication.

Both are IMHO quite reasonable approaches, and I just
wanted to clarify which one we really want to use?

[Jari Arkko] Hmm... if we get a method specific success indication, shouldn't
we enable then in all three cases below:
(a) Success received
(b) Lower-layer success indication
(c) Timeout?

[Pasi Eronen] You're right, and that happens in both approaches. The only
difference is in what to do when we don't have a method specific
indication. In this case,

- both approaches enable the link if Success is received
- both approaches fail on timeout
- the current state machine enables the link if lower-layer
success indication is received, while 2284bis-04 says that
the lower-layer success indication must be ignored
(presumably leading to failure in timeout later).

Which approach do you think we should use?

A second issue: Earlier versions of the draft also mentioned
lower-layer failure indications (e.g. "Lower layer failure
indications provided to EAP by the lower layer MUST be processed
and will cause an EAP exchange in progress to be aborted." in
-03 version). This seems to be missing from -04, and I think
the old text still applies?

[BA] I think the major difference between the two
approaches is for one-way methods such as EAP-MD5 Challenge.

With one-way methods a peer is ready to accept an EAP Success
after sending its Response. Since the peer does not
authenticate the authenticator it is willing to access
any network that indicates it is willing to grant access.

In this case the proposed change is for a lower layer success
indication to cause the peer to conclude that it has been granted
access, even though it had no indication from EAP that the
authenticator was willing to grant access.

This doesn't really create any new security vulnerabilities since a
one-way method is vulnerable to a spoofed EAP Success anyway. On the
other hand, one-way methods are really only appropriate for physically
secure wired media in which the loss rate should be very low, so that I
don't think there is that much benefit to be provided.

So that the peer doesn't encounter a timeout, it probably makes sense to
have some assurance that the link is actually providing IP connectivity or
is likely to do so.

So I think we might need to revise the definition of a
"lower layer success indication" so that it is likely to
be indicative of IP connectivity (e.g. PPP NCP or IP packets)
rather than just a layer 2 frame (e.g. Reassociation Response).

If we take these factors into account, I think the change is ok, although
it is not all that beneficial.

Of course, one issue with lower layer success indications
in general is that I don't believe there are any EAP implementations
that incorporate them. If that remains true then if
and when EAP goes to Draft Standard, we would need to
remove this functionality from RFC 2284bis.

As far as lower layer failure indications are concerned, I think we
concluded that they would translate into "link down" indications in which
case the EAP conversation would abort anyway. Therefore there was no need
to discuss them explicitly.

[BA] Proposed fix:

In Section 3.4, change:

"Section 4.2 defines the circumstances in which a peer,
having concluded an EAP method with successful acknowledged
result indications, may conclude that a Success packet has
been lost after expiration of a timeout. In those same
circumstances, if a peer receives a lower layer success
indication as defined in Section 7.2, it MAY conclude that a
Success packet has been lost without waiting for a
timeout. This ensures that an attacker spoofing lower layer
indications can at best succeed in a denial of service
attack."

To:

"To improve reliability, if a peer receives a lower layer
success indication as defined in Section 7.12, it MAY conclude
that a Success packet has been lost, and behave as it had
actually received a Success packet. This includes choosing to
ignore the Success in some circumstances as described in Section 4.2."

Recommended resolution: Accept

Issue 153: EAP OTP Replay Protection
Submitter name: Joe Salowey
Submitter email address:mailto:jsalowey@cisco.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001417.html
Document: EAP-04
Comment type: T
Priority: S
Section: 5.5
Rationale/Explanation of issue:

Does EAP-OTP provide replay protection?

2284bis-04 says no, but it seems that it should.

[BA] Here is the fix:

In Section 5.5, change:

" Replay protection: No"

To:

" Replay protection: Yes"

Recommended resolution: Accept

Issue 154: Identity Response Mismatch
Submitter name: Joe Salowey
Submitter email address:mailto:jsalowey@cisco.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001418.html
Document: EAP-04
Comment type: T
Priority: 1
Section: 7.3
Rationale/Explanation of issue:

I could not find a place in the draft where it covers the possiblity
that the Identity response differs from the identity that is
authenticated by the EAP method.

Requested change:

Perhaps the following should be added to the security considerations
section:

"It is possible for the identity in the identity response to be
different from the identity authenticated by the EAP method. This may
be intentional in the case of identity privacy. An EAP method SHOULD
use the authenticated identity when making access control decisions. A

[Jari Arkko] Fine so far...

method MAY allow the use of the identity in the identity response if it
is an authorized alias for the authenticated identity."

[Jari Arkko] This part I don't understand. Are you still talking about the case
where the id resp != some method internal identity?

[Joe Salowey] Yes, It should probably say

"If the identity in the Identity Response is an authorized alias of the
authenticated identity the alias MAY use this identity for making access
control decisions."

Alternatively we could just say that the authenticated identity always
takes precedence over the identity in the identity response when they
differ.

[BA] Here is the proposed fix:

In Section 7.3, add the following paragraph:

"It is possible for the identity in the identity response to be
different from the identity authenticated by the EAP method. This may
be intentional in the case of identity privacy. An EAP method SHOULD
use the authenticated identity when making access control decisions."

Recommended resolution: Accept

Issue 155: EAP-SM review
Submitter name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-June/001393.html
Document: EAP-SM-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I'm reviewing the state machine draft version 03
(http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps).
The authenticator state machine in Section 5 appears to be in
very good shape, I like it!

I have a few nits and question marks, however:

1) The three calls to Policy.update have different
    argument lists. It would help the reader if the
    state machine explicitly defined what input goes
    to this function. Looks like it is given eapRespData
    (either in a method or in a NAK), as well as the flags
    that the authenticator has already calculated, e.g.,
    was the response valid. How about

      Policy.update(currentMethod, eapRespData, intCheck)

2) Can't find calculateTimeout from 5.3.

3) I'd rather not see a "..." in the calculateTimeout
    argument list. Can we be more specific? See also
    item 1 above.

4) I'm not sure if the m.buildSuccFail in the diagram
    (state METHOD) and 2284bis Section 4.2 requirements
    are aligned. The latter seems to require that after
    a method specific indication, we still must send
    a Success or Failure. But maybe I'm just confused
    by what "m.buildSuccFail" means since I haven't
    read the passthrough part of the document yet.

5) Similarly, I'm not sure the state machine prevents
    the sending of a canned Success. These seem to be
    forbidden by 2284bis Section 4.2.

6) Should there be initializations of all variables
    in the DISABLED and BACKEND_DISABLED states? Variables
    such as eapFail do not appear to get an initial
    value, at least not in the diagram. The text says
    it is initialized by the lower layer, but why? Wouldn't
    it be easier to treat this variable as an EAP layer
    variable which is only read by the lower layer, not set?

7) Section 5.1.1 s/outside/Outside/

8) Section 5.2 indentation looks funny.

9) Can you explain why BACKEND_DISABLED and DISABLED
    have to be separate states? It looks like they
    could be combined, and the EapBackend variable
    could be checked before branching on to the next
    states. But perhaps this has something to do with
    the IEEE lower layer state machine interface?

10) Why not use the same substructure in 5.2 as is used
     in 5.1? Variables from method->eap layer, eap layer->
     method, etc. Then you could also group 5.4 contents into
     its appropriate place in 5.1/5.2/5.3.

Additional comments on the state machine draft version 03
(http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps).
Overall, I like the way that you have represented the passthrough
and direct/AAA authenticators. The separation of the state machines
to small pieces in nicely organized layers is very good design --
thanks!

I do have some comments, though:

1) In the overview figure in Section 6.2, if I have understood
    correctly the two authenticator state machines have been
    instantiated with a different EapBackend value. Perhaps
    this could be shown in the figure.

2) It would be very useful to have the same kind of
    variable and interface descriptions following the passthrough
    and backend state machines as were given for the authenticator.

3) I don't understand why Policy.update needs to be called
    in the AAA_FAILURE state of the passthrough state machine.
    If this happen, we fail completely, right?

4) Similarly, I'm not sure I understand what the policy updates
    do in AAA_REJECT and AAA_ACCEPT. Can you clarify?

5) In state AAA_REQUEST, maybe change
      if (isIdentity(eapRespData))
    to
      if (respId == currentId)
    unless I'm missing something...

6) The passthrough state machine does not appear to contain
    all processing required by RFC 2869bis. For instance,
    Section 2.6.3 about conflicting messages is not described.
    This may be fine, but at least there should be an
    explanation of the scope of the state machine.

7) References need to be split to normative and non-normative.
    I'd say 2284bis and 2869bis are normative along with RFC 2119.
    IEEE is non-normative.

8) Are these all references? I suspect at least the keying
    framework needs to be referenced.

9) The format used for describing the state machine and
    the actions. Do you have a possibility for feeding this
    into a state machine tool for analysis?

    Also,http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt
    mentions that you can use languages such as C. However, the IESG
    statement said that it must be clear whether you just use
    some pseudo code that just looks like C or the language itself.
    I think we have the former case. This should be stated.

    Finally, the IESG statement requires a normative reference
    to the used language or format. In this case I don't think
    we have it, or? If not, maybe we should be more strict in
    defining the language used for the actions, say with BNF,
    including semantics defined in English?

Issue 156: Terminology reorganization
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001427.html
Document: EAP-04
Comment type: T
Priority: S
Section: 1.2, 1.3, 7.2.1
Rationale/Explanation of issue:

The security claims terminology is best left with the rest of the security claims section 7.2.
Also, the definitions of Man-in-the-Middle resistance and Cryptographic binding appear to overlap.

Change Section 1.2 to the following:

"1.2 Terminology

This document frequently uses the following terms:

authenticator
The end of the link initiating EAP authentication. The
term Authenticator is used in [IEEE-802.1X], and
authenticator has the same meaning in this document.

peer
The end of the link that responds to the authenticator.
In [IEEE-802.1X], this end is known as the Supplicant.

backend authentication server
A backend authentication server is an entity that provides
an authentication service to an authenticator. When used,
this server typically executes EAP methods for the
authenticator. This terminology is also used in
[IEEE-802.1X].

Displayable Message
This is interpreted to be a human readable string of
characters. The message encoding MUST follow the UTF-8
transformation format [RFC2279].

EAP server
The entity that terminates the EAP authentication method
with the peer. In the case where no backend authentication
server is used, the EAP server is part of the authenticator.
In the case where the authenticator operates in
pass-through mode, the EAP server is located on the backend
authentication server.

Silently Discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the event, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.

Successful authentication
In the context of this document, "successful
authentication" is an exchange of EAP messages, as a result
of which the authenticator decides to allow access by the
peer, and the peer decides to use this access. The
authenticator's decision typically involves both
authentication and authorization aspects; the peer may
successfully authenticate to the authenticator but access
may be denied by the authenticator due to policy reasons.

Message Integrity Check (MIC)
A keyed hash function used for authentication and integrity
protection of data. This is usually called a Message
Authentication Code (MAC), but IEEE 802 specifications (and
this document) use the acronym MIC to avoid confusion with
Medium Access Control.

Cryptographic separation
Two keys (x and y) are "cryptographically separate" if an
adversary that knows all messages exchanged in the protocol
cannot compute x from y or y from x without "breaking" some
cryptographic assumption. In particular, this definition
allows that the adversary has the knowledge of all nonces
sent in cleartext as well as all predictable counter values
used in the protocol. Breaking a cryptographic assumption
would typically require inverting a one-way function or
predicting the outcome of a cryptographic pseudo-random
number generator without knowledge of the secret state. In
other words, if the keys are cryptographically separate,
there is no shortcut to compute x from y or y from x, but
the work an adversary must do to perform this computation
is equivalent to performing exhaustive search for the
secret state value.

Master Session Key (MSK)
Keying material that is derived between the EAP peer and
server and exported by the EAP method. The MSK is used
in the derivation of Transient Session Keys (TSKs) for
the ciphersuite negotiated between
the EAP peer and authenticator. Where a backend
authentication server is present, acting as an EAP server,
it will typically transport the MSK to the authenticator,
so that in this case, the MSK is available to the peer,
authenticator and authentication server.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. Unlike the
MSK, the EMSK is known only to the EAP peer and EAP server
and is not provided to a third party. The EMSK is reserved
for future uses that are not defined yet. For example, it
could be used to derive additional keying material for
purposes such as fast handoff, cryptographic binding, etc."

Delete Section 1.3.

Add Section 7.2.1:

"7.2.1 Security claims terminology for EAP methods

These terms are used to described the security properties of EAP
methods:

Mutual authentication
This refers to an EAP method in which, within an
interlocked exchange, the authenticator authenticates the
peer and the peer authenticates the authenticator. Two
independent one-way methods, running in opposite directions
do not provide mutual authentication as defined here.

Integrity protection
This refers to providing data origin authentication and
protection against unauthorized modification of information
for EAP packets (including EAP Requests and Responses).
When making this claim, a method specification MUST
describe the EAP packets and fields within the EAP packet
that are protected.

Replay protection
This refers to protection against replay of an EAP method
or its messages, including method-specific success and
failure indications.

Confidentiality
This refers to encryption of EAP messages, including EAP
Requests and Responses, and method-specific success and
failure indications. A method making this claim MUST
support identity protection (see Section 7.3).

Key derivation
This refers to the ability of the EAP method to derive
exportable keying material such as the Master Session Key
(MSK), and Extended Master Session Key (EMSK). The MSK is
used only for further key derivation, not directly for
protection of the EAP conversation or subsequent data. Use
of the EMSK is reserved.

Key strength
If the effective key strength is N bits, the best currently
known methods to recover the key (with non-negligible
probability) require an effort comparable to 2^N operations
of a typical block cipher.

Dictionary attack protection
Where password authentication is used, passwords are
commonly selected from a small set (as compared to a set of N-bit keys),
which raises a concern about dictionary attacks.
A method may be said to provide protection against dictionary attacks if,
when it uses a password as a secret, the method does not allow
an offline attack that has a work factor based on
the number of passwords in an attacker's dictionary.

Fast reconnect
The ability, in the case where a security association has
been previously established, to create a new or refreshed
security association in a smaller number of round-trips.

Cryptographic binding
The demonstration of the EAP peer to the EAP server that a
single entity has acted as the EAP peer for all methods
executed within a tunnel method. Binding MAY also
imply that the EAP server demonstrates to the peer that a
single entity has acted as the EAP server for all methods
executed within a tunnel method. If executed
correctly, binding serves to mitigate man-in-the-middle
vulnerabilities.

Acknowledged result indications
The ability within a method for the authenticator to indicate
to the peer whether it has successfully authenticated to it, and
for the peer to acknowledge receipt of that indication as well
as indicating to the authenticator whether it has successfully
authenticated to the peer. Since EAP Success and Failure packets
are neither acknowledged nor integrity protected, this claim requires
implementation of a method-specific result exchange that is
authenticated, integrity and replay protected on a
per-packet basis."

Proposed Resolution: Accept

Issue 157: Order of attribute processing
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001429.html
Document: RFC 2869bis-22
Comment type: T
Priority: S
Section: 2.6.4, 3, Appendix B
Rationale/Explanation of issue:

Existing implementations process EAP-Message attributes first, and
changing the processing order will cause backward compatibility issues as
well as problems with operation of IEEE 802.11i. If approved, this change
will be made in Author 48 hours, since the draft has already been approved
for publication as an RFC.

In Section 2.6.4, change:

"Reject or Access-Challenge, the NAS SHOULD process other attributes
first, then decapsulate EAP-Message attribute(s), reconstitute the EAP
packet and send it to the peer."

To:

"Reject or Access-Challenge, the NAS SHOULD first decapsulate EAP-Message
attribute(s), reconstitute the EAP packet and send it to the peer, then
process other attributes."

In Section 3 , change:

"difficult to manage."

To:

"difficult to manage. The User-Name attribute within the Access-Accept
packet need not be the same as the User-Name attribute in the Access-
Request."

In Appendix B , change:

"EAP-Message attributes are processed last (Section 2.6.4)."

To:

"EAP-Message attributes are processed first (Section 2.6.4)."

[Pasi Eronen]: Maybe the best way to handle the order of attribute
processing is to allow this to be defined in the link layer specification
(e.g. IEEE 802.1X). That provides the most flexibility.

[BA]: I think that makes sense. However, we do need to make sure that
the attributes get processed before the Accept/Reject indication. For
example, when receiving Access-Reject with EAP-Failure the EAP-Failure
needs to be sent before the port goes down or elese the EAP peer won't
receive the EAP-Failure and could hang.

[John Vollbrecht]: I believe that the User-Name in the Access-Accept
MUST be the same as the one in the Access-Request.

[BA] RFC 2865 indicates that the User-Name in the Access-Accept can
be different than the one in the Access-Request. For example,
the text below from Section 5.1 would have no purpose if they were required to
be the same:

" It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session. If the Access-
Accept includes Service-Type = Rlogin and the User-Name attribute,
a NAS MAY use the returned User-Name when performing the Rlogin
function."

Proposed fix:

Change Section 2.6.4 to:

"A RADIUS Access-Accept or Access-Reject packet may contain
EAP-Message attribute(s). In order to ensure
the correct processing of RADIUS packets, the NAS
MUST first process the attributes, including the
EAP-Message attribute(s), prior to processing the
Accept/Reject indication."

In Section 3 , change:

"difficult to manage."

To:

"difficult to manage. The User-Name attribute within the Access-Accept
packet need not be the same as the User-Name attribute in the Access-
Request."

In Appendix B , delete:
"EAP-Message attributes are processed last (Section 2.6.4)."

Recommended resolution: Accept

Issue 158: Miscellaneous Nits
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: July 6, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001430.html
Document: EAP-04
Comment type: E
Priority: S
Section: 3.1, 5, 7.2, 7.3, 7.5, A.1
Rationale/Explanation of issue:

In Section 3.1, move the following text to section 3.4:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same
entity that successfully completed EAP authentication, the lower
layer needs to bind per-packet integrity, authentication and
replay protection to the original EAP authentication, using keys
derived during EAP authentication. Alternatively, the lower
layer needs to be physically secure. Otherwise it is possible
for subsequent data traffic to be hijacked, or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP
or IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided.

Where keying material for the lower layer ciphersuite is itself
provided by EAP, ciphersuite negotiation and key activation is
controlled by the lower layer. In PPP, ciphersuites are
negotiated within ECP so that it is not possible to use keys
derived from EAP authentication until the completion of ECP.
Therefore an initial EAP exchange cannot protected by a PPP
ciphersuite, although EAP re-authentication can be protected.

In IEEE 802 media, key activation also typically occurs after
completion of EAP authentication. Therefore an initial EAP
exchange typically cannot be protected by lower layer
ciphersuite, although an EAP re-authentication or
pre-authentication exchange can be protected."

In Section 3.1, indent the following paragraph:

"The Point-to-Point Protocol is designed for simple links which
transport packets between two peers. These links provide
full-duplex simultaneous bi-directional operation, and are
assumed to deliver packets in order."

In Section 5, change "MITM resistance:" to "Crypt. binding:" (Since we no
longer have a definition of Man-in-the-Middle resistance)

In Section 7.2, change "man-in-the-middle resistance" to "cryptographic binding"

In Section 7.3, Change "Identity-Response" to "EAP-Response/Identity" (two times)

Delete Section A.1, and change Section 7.5 to the following:

"7.5 Packet modification attacks

While EAP methods may support per-packet data origin authentication,
integrity and replay protection, support is not provided within the
EAP layer.

Since the Identifier is only a single octet, it is easy to guess,
allowing an attacker to successfully inject or replay EAP packets. An
attacker may also modify EAP headers (Code, Identifier, Length, Type)
within EAP packets where the header is unprotected. This could cause
packets to be inappropriately discarded or misinterpreted.

In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used.

Method-specific MICs may be used to provide protection.
If a per-packet MIC is employed within an EAP method, then peers,
authentication servers, and authenticators not operating in
pass-through mode MUST validate the MIC. MIC validation failures
SHOULD be logged. Whether a MIC validation failure is considered a
fatal error or not is determined by the EAP method specification.

Since EAP messages of Types Identity, Notification, and
Nak do not include their own MIC, it may be desirable for the EAP
method MIC to cover information contained within these messages, as
well as the header of each EAP message. For details, see Appendix A.

To provide protection, EAP also may be encapsulated within a
protected channel created by protocols such as ISAKMP [RFC2408] as is
done in [IKEv2] or within TLS [RFC2246]. However, as noted in Section
7.4, EAP tunneling may result in a man-in-the-middle vulnerability.

Existing EAP methods define message integrity checks (MICs)
that cover more than one EAP packet. For example, EAP-TLS [RFC2716]
defines a MIC over a TLS record that could be split into multiple
fragments; within the FINISHED message, the MIC is computed over
previous messages. Where the MIC covers more than one EAP packet, a
MIC validation failure is typically considered a fatal error.

Within EAP-TLS [RFC2716] a MIC validation failure is treated as a
fatal error, since that is what is specified in TLS [RFC2246].
However, it is also possible to develop EAP methods that support
per-packet MICs, and respond to verification failures by silently
discarding the offending packet.

In this document, descriptions of EAP message handling assume that
per-packet MIC validation, where it occurs, is effectively performed
as though it occurs before sending any responses or changing the
state of the host which received the packet."

Recommended resolution: Accept

Issue 159: Organization Issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: July 9, 2003
Reference:
Document: EAP-04
Comment type: E
Priority: 1
Section: 2.2, 4.1
Rationale/Explanation of issue:

The organization of section 2.2 and 4.1 could be improved.

Proposed changes:

Delete the following text from Section 2.2:

Paragraphs from "Where an authenticator operates as a pass-through..."
to the end of the section (all material relating to pass-through
operation).

Add the following text to Section 2.3:

"2.3 Pass-through behavior

Where an authenticator operates as a pass-through, it forwards
packets back and forth between the peer and a backend authentication
server, based on the EAP layer header fields (Code, Identifier,
Length). This includes performing validity checks on the Code,
Identifer and Length fields, as described in Section 4.1.

Since pass-through authenticators rely on a backend authenticator
server to implement methods, the EAP method layer header fields
(Type, Type-Data) are not examined as part of the forwarding
decision. The forwarding model is illustrated in Figure 2. Compliant
pass-through authenticator implementations MUST by default be capable
of forwarding packets from any EAP method. The use of the RADIUS
protocol for encapsulation of EAP in pass-through operation is
described in [RFC2869bis].

Peer Pass-through Authenticator Authentication

Server

+-+-+-+-+-+-+ +-+-+-+-+-+-+

| | | |

|EAP method | |EAP method |

| V | | ^ |

+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+

| ! | | | | | ! |

| ! | | +-----+-----+ | | ! |

| ! | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+

| ! | | ! | ! | | ! |

| ! | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+

! ! ! !

+-------->-----+ +------->------+

Figure 2: Pass-through Authenticator

For sessions in which the authenticator acts as a pass-through, it
MUST determine the outcome of the authentication solely based on the
Accept/Reject indication sent by the backend authentication server;
the outcome MUST NOT be determined by the contents of an EAP packet
sent along with the Accept/Reject indication, or the absence of such
an encapsulated EAP packet."

Replace Section 4.1 with the following:

"4.1 Request and Response

Description

The Request packet (Code field set to 1) is sent by the
authenticator to the peer. Each Request has a Type field which
serves to indicate what is being requested. Additional Request
packets MUST be sent until a valid Response packet is received, or
an optional retry counter expires.

Retransmitted Requests MUST be sent with the same Identifier value
in order to distinguish them from new Requests. The contents of
the data field are dependent on the Request Type. The peer MUST
send a Response packet in reply to a valid Request packet.
Responses MUST only be sent in reply to a valid Request and never
retransmitted on a timer.

If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response
without reprocessing the Request. Requests MUST be processed in
the order that they are received, and MUST be processed to their
completion before inspecting the next Request.

A summary of the Request and Response packet format is shown below.
The fields are transmitted from left to right.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |   Identifier |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Code

1 for Request
2 for Response

Identifier

The Identifier field is one octet. The Identifier field MUST be
the same if a Request packet is retransmitted due to a timeout
while waiting for a Response. Any new (non-retransmission)
Requests MUST modify the Identifier field.

The Identifier field of the Response MUST match that of the
currently outstanding Request. An authenticator receiving a
Response whose Identifier value does not match that of the
currently outstanding Request MUST silently discard the Response.

In order to avoid confusion between new Requests and retransmissions,
the Identifier value chosen for each new Request need only be
different from the previous Request, but need not be unique within
the conversation. One way to achieve this is to start the Identifier
at an initial value and increment it for each new Request. Initializing
the first Identifier with a random number rather than starting from
zero is recommended, since it makes sequence attacks somewhat
harder.

Since the Identifier space is unique to each session,
authenticators are not restricted to only 256 simultaneous
authentication conversations. Similarly, with re-authentication,
an EAP conversation might continue over a long period of time, and
is not limited to only 256 roundtrips.

Implementation Note: The authenticator is responsible for
retransmitting Request messages. If the Request message is
obtained from elsewhere (such as from a backend authentication
server), then the authenticator will need to save a copy of the
Request in order to accomplish this. The peer is responsible
for detecting and handling duplicate Request messages before
processing them in any way, including passing them on to an
outside party. The authenticator is also responsible for
discarding Response messages with a non-matching Identifier
value before acting on them in any way, including passing them
on to the backend authentication server for verification.
Since the authenticator can retransmit before receiving a
Response from the peer, the authenticator can receive multiple
Responses, each with a matching Identifier. Until a new Request
is received by the authenticator, the Identifier value is not
updated, so that the authenticator forwards Responses to the
backend authentication server, one at a time.

Length

The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, and Type-Data
fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and MUST be ignored on
reception. A message with the Length field set to a value larger
than the number of received octets MUST be silently discarded.

Type

The Type field is one octet. This field indicates the Type of
Request or Response. A single Type MUST be specified for each EAP
Request or Response. An initial specification of Types follows
in Section 5 of this document.

The Type field of a Response MUST either match that of the
Request, or correspond to a legacy or Expanded Nak (see
Section 5.3) indicating that a Request Type is unacceptable
to the peer. A peer MUST NOT send a Nak (legacy or expanded)
in response to a Request, after an initial non-Nak Response has
been sent. An EAP server receiving a Response not meeting these
requirements MUST silently discard it.

Type-Data

The Type-Data field varies with the Type of Request and the
associated Response."

Recommended resolution: Accept

Issue 160: Network Selection Assistance
Submitter name: Farid Adrangi
Submitter email address: farid.adrangi@intel.com
Date first submitted: July 11, 2003
Reference:
Document: EAP-04
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Currently there may be a requirement for providing
information on network selection within EAP. RFC 2284bis
does not provide guidance on how to do this, in particular
whether it is appropriate to Use EAP Notification or
EAP Identity Request/Response messages, and if so,
what is the recommended way to do this. This problem
also came up in the discussion of Issue 142.

[Bernard Aboba] This outside RFC 3748. Why don't you write a separate draft on this issue?

Recommended resolution: Reject

Issue 161: State Machine demultiplexing
Submitter name: Florent Bersani
Submitter email address:mailto:florent.bersani@francetelecom.com
Date first submitted: July 21, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001504.html
Document: SM-04
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

When two peers simultaneously perform EAP authentications (that is to say A
acts as a peer in dialog #1 with B which acts as an authenticator and, at
the same time, A acts as an authenticator in dialog #2 with B which acts as
a peer) the EAP dialogs have to get demultiplexed: this can easily be done
according to the EAP code field (responses go to the authenticator and other
codes - requests, success and failure - go to the peer).

The question is : who does this demultiplexing ? Should it be the lower
layer (which then would have to read and understand the EAP layer) or the
EAP state machine (which then should be modified, I think) ?

[Pasi Eronen]

I think the demultiplexing should be done by the lower layer.
The state machine doc should probably be updated to say
this, and describe how the demultiplexing is done (it
should work the way you proposed).

This way we don't have to unnecessarily complicate the state
machines with this detail (bidirectional authentication
with two conversations is anyway an obsolete feature that's
probably not used anywhere, right?).

Add to state machine doc, section 2, before the last paragraph:

   Some environments where EAP is used, such as PPP, may support
   peer-to-peer operation. That is, both parties act as peers and
   authenticators at the same time, in two simultaneous and
   independent EAP conversations. In this case, the lower layer to at
   each node has to perform demultiplexing of incoming EAP packets.=20
   EAP packets with Code set to Response are delivered to the=20
   Authenticator state machine, and all other EAP packets are=20
   delivered to the Peer state machine.

[Bernard Aboba]

What are the link layer requirements for support of EAP peer-to-peer
operation? I ask this because there is nothing in RFC 2248bis Section
2.4 or 3.1 that discusses these requirements.

For example, if there a requirement for the link layer to be able to
demultiplex the EAP conversations in each direction, wouldn't that imply
the need for a field in the link layer header with which to do this
demultiplexing? For example, IPv4/IPv6 packets are demultiplexed by
different EtherType values, not really by the IP version number.

In Section 3.2.1 of RFC 2284bis the PPP Authentication Protocol format is
defined. EAP packets are encapsulated with an Authentication Protocol
value of C227 (Hex). Similarly, in IEEE 802.1X an Ethertype is assigned
to 802.1X packets. Neither of these encapsulations can demultiplex EAP
conversations occurring in different directions. For example, there is no
different Authentication Protocol value or Ethertype for this.

Since neither of these encapsulations demultiplexes EAP conversations in
either direction, and the link layer does not look at frames deeper in the
packet, such as the EAP Code or Type fields, I don't think that this
explanation can be correct. If there is demultiplexing, then this would
need to occur in the EAP layer, not in the link layer, no?

[Pasi Eronen

I agree with you in that the demultiplexing can't (or at least
shouldn't) be done at the link layer in e.g. PPP, since it would
need to look inside the EAP packets (to check the Code field).=20

More likely it's done by "something" between the link layer and
EAP state machines. Would simply changing "lower layer" to
"implementation" be sufficient?

[Bernard Aboba]

I think this is sufficient for the State Machine spec. But I think we may
also need to change some text and possibly a figure in RFC 2284bis to
make it more clear.

For example, if multiplexing occurs on the "Code" field then it implies
that an "EAP peer" listener within an EAP implementation will not receive
EAP packets with Code=2 (Response) (but packets for all other Codes,
including 1, 3, 4). Similarly, the "EAP server" listener will only
recieve EAP packets with Code=2 (Request). The implementation behavior
therefore differs based on whether there is an "EAP peer" or "EAP server"
listener present, or both.

This is a bit different than the behavior implied by RFC 2284bis as
where it is implied that an "EAP peer" will silently discard a
received EAP-Response packet. If there is no "EAP server" listener
on the receiving host, or if there is but the EAP method only supports
"EAP peer" functionality, then silent discard will occur. However if
there is an "EAP server" listener, and an EAP method registered with "EAP
server" functionality, then the EAP-Response might be processed.

There is therefore some implied multiplexing that occurs based on the Code
field, prior to the Type multiplexing which occurs later. This is not
shown on the diagrams.

[Bernard Aboba]

Here is the proposed revised text of Sections 2.2-2.4:

"2.2 EAP multiplexing model

Conceptually, EAP implementations consist of the following
components:

[a] Lower layer. The lower layer is responsible for transmitting and
receiving EAP frames between the peer and authenticator. EAP has
been run over a variety of lower layers including PPP; wired IEEE
802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11];
UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower
layer behavior is discussed in Section 3.

[b] EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements duplicate detection and
retransmission, and delivers and receives EAP messages to and
from the EAP peer and authenticator layers.

[c] EAP peer and authenticator layers. Based on the Code field, the
EAP layer demultiplexes incoming EAP packets to the EAP peer and
authenticator layers. Typically an EAP implementation on a given
host will support either peer or authenticator functionality, but
it is possible for a host to act as both an EAP peer and
authenticator. In such an implementation both EAP peer and
authenticator layers will be present.

[d] EAP method layers. EAP methods implement the authentication
algorithms and receive and transmit EAP messages via the EAP peer
and authenticator layers. Since fragmentation support is not
provided by EAP itself, this is the responsibility of EAP methods,
which are discussed in Section 5.

The EAP multiplexing model is illustrated in Figure 1 below. Note
that there is no requirement that an implementation conform to this
model, as long as the on-the-wire behavior is consistent with it.

+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+

| | | | | |

| V | | | ^ | |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| EAP ! Peer layer | | EAP ! Auth. layer |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| EAP ! layer | | EAP ! layer |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

| ! | | ! |

| Lower ! layer | | Lower ! layer |

| ! | | ! |

+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+

! !

! Peer ! Authenticator

+------------>-------------+

Figure 1: EAP Multiplexing Model

Within EAP, the Code field functions much like a protocol number in
IP. It is assumed that the EAP layer demultiplexes incoming EAP
packets according to the Code field. Received EAP packets
with Code=1 (Request), 3 (Success) and 4 (Failure) are
delivered by the EAP layer to the EAP peer listener, if
present. EAP packets with Code=2 (Response) are delivered
to the EAP authenticator listener, if present.

Within EAP, the Type field functions much like a port number in UDP
or TCP. It is assumed that the EAP peer and authenticator layers
demultiplex incoming EAP packets according to their Type, and deliver
them only to the EAP method corresponding to that Type. An
EAP method implementation on a host may register to receive
packets from the peer or authenticator listener, or both.

Since EAP authentication methods may wish to access the Identity,
implementations SHOULD make the Identity Request and Response
accessible to authentication methods (Types 4 or greater) in addition
to the Identity method. The Identity Type is discussed in Section
5.1.

A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2.

Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes
of method negotiation. Peers respond to an initial EAP Request for
an unacceptable Type with a Nak Response (Type 3) or Expanded Nak
Response (Type 254). It cannot be assumed that the contents of the
Nak Response(s) are available to another method. The Nak Type(s) are
discussed in Section 5.3.

EAP packets with codes of Success or Failure do not include a Type
field, and are not delivered to an EAP method. Success and Failure are
discussed in Section 4.2.

Given these considerations, the Success, Failure, Nak Response(s) and
Notification Request/Response messages MUST NOT be used to carry data
destined for delivery to other EAP methods.

2.3 Pass-through behavior

When operating as a "pass-through authenticator", an
authenticator performs checks on the Code, Identifier and
Length fields as described in Section 4.1. It
forwards EAP packets received from the peer and
destined to its authenticator listener to the backend
authentication server; packets received from the
backend authentication server destined to the peer
are forwarded to it.

The forwarding decision is based on examination of the
Code, Identifier and Length fields. Since a "pass-through
authenticator" only forwards to the backend authentication
server EAP packets received from the peer and destined for its
authenticator listener, pass-through authenticator
implementations MUST be capable of forwarding to the
backend authentication server EAP packet received from
the peer with Code=2 (Response). They also MUST be capable
of receiving EAP packets from the backend authentication
server and forwarding EAP packets of Code=1 (Request),
Code=3 (Success), and Code=4 (Failure) to the peer.

Since pass-through authenticators rely on a backend authenticator
server to implement methods, the EAP method layer header fields
(Type, Type-Data) are not examined as part of the forwarding
decision, except where the authenticator implements one or more
authentication methods locally. In this case, the authenticator
may examine the Type field to determine whether to act on the
packet itself or forward it. Compliant pass-through
authenticator implementations MUST be default forward EAP
packets of any Type. The forwarding model is illustrated
in Figure 2.

Since EAP packets received with Code=1 (Request), Code=3 (Success),
and Code=4 (Failure) are demultiplexed by the EAP layer and
delivered to the peer listener, unless a host implements
an EAP peer listener, these packets will be silently
discarded. The behavior of a "pass-through peer" is
undefined within this specification, and is unsupported by
AAA protocols such as RADIUS [RFC3579] and
Diameter [DiamEAP].

Peer Pass-through Authenticator Authentication

Server

+-+-+-+-+-+-+ +-+-+-+-+-+-+

| | | |

|EAP method | |EAP method |

| V | | ^ |

+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+

| ! | |EAP | EAP | | | ! |

| ! | | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+

| ! | | ! | ! | | ! |

| ! | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+

| ! | | ! | ! | | ! |

| ! | | ! | ! | | ! |

+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+

! ! ! !

+-------->--------+ +--------->-------+

Figure 2: Pass-through Authenticator

For sessions in which the authenticator acts as a pass-through, it
MUST determine the outcome of the authentication solely based on the
Accept/Reject indication sent by the backend authentication server;
the outcome MUST NOT be determined by the contents of an EAP packet
sent along with the Accept/Reject indication, or the absence of such
an encapsulated EAP packet.

2.4 Peer-to-Peer Operation

Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both peers may act as
authenticators and authenticatees at the same time; in this case it
is necessary to both peers to implement both EAP authenticator and
peer listeners. In addition, the EAP method implementations on
both peers must support both authenticator and peer functionality.

Although EAP supports peer-to-peer operation, some EAP
implementations, methods, AAA protocols and link layers may not
support this. For example, EAP-TLS [RFC2716] is a client-server
protocol requiring a different certificate profile for the client and
server. This implies that a host supporting both the EAP-TLS peer and
authenticator roles would need to implement both peer and
authenticator listeners; would need to support both the peer and
authenticator roles in the EAP-TLS implementation; would need to be
provisioned with two distinct certificates, one appropriate for each
role.

Some EAP methods may support asymmetric authentication, with one type
of credential being required for the peer and another type for the
authenticator. Hosts supporting peer-to-peer operation with such a
method would need to be provisioned with both types of credentials.

AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
[DIAM-EAP] only support "passthrough authenticator" operation.
As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an
Access-Request encapsulating an EAP-Request, Success or Failure
packet with an Access-Reject. There is therefore no support for
"passthrough peer" operation.

Link layers such as IEEE 802.11 may only support uni-directional
derivation and transport of transient session keys. For example, the
group-key handshake defined in [IEEE-802.11i] is uni-directional,
since in IEEE 802.11 only the Access Point (AP) sends multicast
traffic. This means that in ad-hoc operation where either peer may
send multicast traffic, two uni-directional group-key exchanges are
required. Due to constraints imposed by the 4-way unicast key
handshake state machine, this also implies two 4-way handshake and
EAP method exchanges.

Link layers such as IEEE 802.11 adhoc also do not support "tie
breaking" wherein two hosts initiating authentication with each other
will only go forward with a single authentication. This implies that
even if 802.11 were to support a bi-directional group-key handshake,
then two authentications, one in each direction, might still occur."

Proposed Resolution: Accept

Issue 162: Minimum MTU Not Defined
Submitter name: Lauri Tarkkala
Submitter email address: ltarkkal@ssh.com
Date first submitted: July 21, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001507.html
Document: EAP-04
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

The current RFC2284bis draft does not define a minimum MTU that EAP
methods can rely on. At least the following EAP methods do not
do fragmenting:
- Identity
- Notification
- MD5-Challenge
- .. etc
(- and Nak, which is not a method, but anyway)

Currently the "minimum MTU" is "inherited" from PPP (1500 bytes),
but all uses of EAP do not conform to this (e.g. PPPoe).
A minimum MTU must be defined such that embeddings of EAP into
other protocols will be such that implementations of these
methods will always operate correctly. There are also
the implied architectural limitations, which will cut
across any system architecture which contains EAP:

- Maximum identity length (unfragmented MTU - headers bytes -
maximum length of piggy-backed option settings)
- Maximum notification length

The defined minimum MTU should be defined to be as large
as possible, due to the lossage implied when doing
fragmentation/reassembly in a lock-step
protocol. Note also that the composite protocol
architecture may be doing fragmentation/reasembly
in both the EAP transport and the EAP method, if
the usage is improper.

The proposed solution is in a nutshell:
- Define that minimum frame size that can be sent/received unfragmented
by EAP as X bytes.
- State the maximum notification length as X - headers.
- State the maximum identity req/resp lengths as
Y = X - headers - possible options
- State that because EAP is a lock-step protocol and if latency
is important and methods with large frames are used, the
EAP transport protocol SHOULD provide fragmentation and
reassembly services for frames upto 2^16 bytes.
- Initial proposal of X as 1400 bytes. If somebody knows any protocols
that use EAP with MTU's then I'm sure we'd all like to hear about it.

Hopefully somebody has the relevant experience from all EAP implementations
to specify better values for X and Y than in the text below (1400 and
1024 respectively).

Requested change:

In section 3.1 ("Lower layer requirements") add below.

"[4] MTU known a-priori. The EAP layer does not support
fragmentation and reassembly. However, EAP methods SHOULD be capable of
handling fragmentation and reassembly. As a result, EAP is
capable of functioning across a range of MTU sizes, as long as
the MTU is known a-priori. EAP does not support path MTU discovery."

to

"[5] Minimum MTU. The EAP layer, the EAP Identity method,
EAP Notification method and the NAK responses do NOT support
fragmentation and reassembly. EAP methods designed originally
for use within PPP (where a 1500 byte MTU is guaranteed for
control frames [RFC1661]) also lack fragmentation and reassembly features.
The lower layer transporting EAP MUST therefore be capable of carrying
EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a
lock-step protocol, which implies a certain inefficiency when doing
fragmentation and reassembly. The lower layer therefore SHOULD
provide fragmentation and reassembly services."

... and Change the numbering of the following items from [5] -> [6] and
[6] -> [7].

After the first paragraph in "Section 5.1" add:

"Some implementations of EAP tend to piggy-back into an Identity
Request or Response various options after a NUL-character. An EAP
implementation SHOULD NOT assume that usernames or displayable messages
over 1024 bytes in Identity Requests or Responses will work in all
environments."

Add to first paragraph in "Section 5.2" the sentences:

"Note that the maximum length of a notification messages that can be used
reliably in all EAP implementations is 1400 bytes. The length
of the human readable message SHOULD therefore be at most 1395 bytes."

--
Lauri Tarkkala
SSH Communications Security Corp
http://www.ssh.com/

[BA] Here are my comments:

"Minimum MTU. The EAP layer, the EAP Identity method,
EAP Notification method and the NAK responses do NOT support
fragmentation and reassembly. "

[BA] Recommend adding EAP OTP, GTC and Challenge-MD5 to this list.

EAP methods designed originally
for use within PPP (where a 1500 byte MTU is guaranteed for
control frames [RFC1661]) also lack fragmentation and reassembly features.

[BA] It is true that the methods defined in RFC 2284 do not support
fragmentation and reassembly. But since we don't have specifications for
many methods that have been allocated type codes, it is hard to
say whether the statement above is true or not. Certainly EAP TLS [RFC
2716] does support fragmentation.

Question: Is a 1500 byte MTU really guaranteed for control frames? I seem
to recall situations where only a 576 octet MTU was available. My
suggestion is that the above sentence be changed to "may lack
fragmentation and reassembly features".

"The lower layer transporting EAP MUST therefore be capable of carrying
EAP frames of up to 1400 bytes unfragmented. Note also that EAP is a
lock-step protocol, which implies a certain inefficiency when doing
fragmentation and reassembly. The lower layer therefore SHOULD
provide fragmentation and reassembly services."

[BA] I don't know that we can impose this requirement on lower layers
necessarily. After all, the lower layers are what they are. Suggest that
the MUST be changed to a SHOULD. Recommend that the last sentence be
deleted. Lower layers typically don't provide fragmentation and
reassembly services, since that's an IP layer function.

"Some implementations of EAP tend to piggy-back into an Identity
Request or Response various options after a NUL-character. An EAP
implementation SHOULD NOT assume that usernames or displayable messages
over 1024 bytes in Identity Requests or Responses will work in all
environments."

[BA] Why is the limit only 1024 octets for Identity and a different number
for other requests?

Overall, my comment is that I'd prefer to recommend that methods assume a
certain minimum MTU and that they MUST support fragmentation and
reassembly if it is possible that frames can exceed this minimum MTU size.
My overall impression was that we might have to live with a minimum MTU as
low as 576 octets.

[BA] Here are the proposed fixes:

In section 3.1, Change:

"[4] MTU known a-priori. The EAP layer does not support
fragmentation and reassembly. However, EAP methods SHOULD be capable of
handling fragmentation and reassembly. As a result, EAP is
capable of functioning across a range of MTU sizes, as long as
the MTU is known a-priori. EAP does not support path MTU discovery."

To:

"[4] Minimum MTU. EAP is capable of functioning on lower
layers that provide an EAP MTU size of 1020 octets or greater.

EAP does not support path MTU discovery, and fragmentation and
reassembly is not supported by EAP, nor by the methods
defined in this specification: the Identity (1),
Notification (2), Nak Response (3), MD5-Challenge (4),
One Time Password (5), Generic Token Card (6)
and expanded Nak Response (254) Types.

Typically, the EAP peer obtains information on the EAP MTU from the
lower layers and sets the EAP frame size to an appropriate value.
Where the authenticator operates in pass-through mode, the
authentication server does not have a direct way of determining
the EAP MTU, and therefore relies on the authenticator to provide
it with this information, such as via the Framed-MTU attribute,
as described in [RFC3579], Section 2.4.

While methods such as EAP-TLS [RFC2716] support fragmentation
and reassembly, EAP methods originally designed for use within PPP
where a 1500 octet MTU is guaranteed for control frames
(see [RFC1661], Section 6.1) may lack fragmentation and reassembly features.

EAP methods can assume a minimum EAP MTU of 1020 octets, in the
absence of other information. EAP methods SHOULD
include support for fragmentation and reassembly if their payloads
can be larger than this minimum EAP MTU.

EAP is a lock-step protocol, which implies a certain inefficiency
when handling fragmentation and reassembly. Therefore if the
lower layer supports fragmentation and reassembly
(such as where EAP is transported over IP), it may be
preferrable for fragmentation and reasembly to occur in the
lower layer rather than in EAP. This can be accomplished by
providing an artificially large EAP MTU to
EAP, causing fragmentation and reassembly to be handled within the
lower layer."

After the first paragraph in Section 5.1, add:

"Some EAP implementations piggy-back various options into the Identity
Request after a NUL-character. By default an EAP implementation SHOULD NOT assume
that an Identity Request or Response can be larger than 1020 octets."

Add to the first paragraph in Section 5.2, the sentences:

"Note that the default maximum length of a Notification Request is 1020 octets. By default,
this leaves at most 1015 octets for the human readable message."

References: Add informative reference to RFC 3579, RADIUS/EAP.

Change

Proposed Resolution: Accept

Issue 163: Minor Editorial Nit
Submitter name: Lauri Tarkkala
Submitter email address:ltarkkal@ssh.com
Date first submitted: July 21, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-July/001508.html
Document: EAP-04
Comment type: E
Priority: 2
Section: 2.1
Rationale/Explanation of issue:

Third paragraph in Section 2.1 states

"A peer MUST NOT send a Nak (legacy or expanded) in reply to a
Request, after an initial non-Nak Response has been sent. Since
spoofed EAP Request packets may be sent by an attacker, an
authenticator receiving an unexpected Nak SHOULD silently
discard it and log the event."

and in Section 1.2 we have the definition of silently discard:

"This means the implementation discards the packet
without further processing. The implementation
SHOULD provide the capability of logging the
event, including the contents of the silently discarded packet,
and SHOULD record the event in a statistics counter."

Recommended change:

In section 2.1 change the third paragraph quoted above to
read:

"A peer MUST NOT send a Nak (legacy or expanded) in reply to a
Request, after an initial non-Nak Response has been sent. Since
spoofed EAP Request packets may be sent by an attacker, an
authenticator receiving an unexpected NAK SHOULD
discard it and log the event."

(e.g. remove the "silently", at first read I found this
a bit confusing).

Proposed Resolution: Accept

Issue 164: Conflicting Implementation Note
Submitter name: Joe Salowey
Submitter email address: jsalowey@cisco.com
Date first submitted: 7/29/2003
Reference:
Document: RFC2284bis
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:

In section 2 [3] there is the following text
"After a suitable number of
       retransmissions, the authenticator SHOULD end the EAP
       conversation. The authenticator MUST NOT send a Success or
       Failure packet when retransmitting or when it fails to get a
       response from the peer."

In section 5.1 there is the following text in the implementation note:

"It is suggested that the Identity Request be
retried a minimum of 3 times before terminating the
authentication phase with a Failure reply."

This seems contradictory.

Requested change:

Section 5.1

"It is suggested that the Identity Request be
retried a minimum of 3 times before terminating the
authentication."

Recommended Resolution: Accept

Issue 165: Applicability Statement
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 8/2/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-August/001524.html
Document: RFC2284bis
Comment type: T
Priority: S
Section: 1.4
Rationale/Explanation of issue:

EAP needs an applicability statement so that it is clear when it is appropriate and inappropriate to use it.

Insert the following section:

1.4 Applicability

EAP is an authentication framework primarily for use in situations
such as network access, in which IP layer connectivity may not be available.

Since the goal of EAP is to support authentication without requiring
IP connectivity, it provides just enough support for the
reliable transport of authentication protocols, and no more.
EAP is a lock-step protocol and does not support an efficient
reliable transport service as in TCP [RFC793] or SCTP [RFC2960].
While EAP provides support for retransmission, it assumes ordering
guarantees provided by the lower layer, so that out of order reception
is not supported.

As noted in Section 3.1, EAP does not support fragmentation
and reassembly as in IP, although EAP methods may provide support
for this. As a result, authentication protocols generating payloads larger
than the EAP MTU will need to be modified in order to provide
fragmentation support.

EAP authentication is initiated by the authenticator, whereas
many authentication protocols are initiated by the client (peer). As a
result, it may be necessary for an algorithm to add 0.5 - 1 additional
roundtrips between the client and authenticator in order to run over EAP.

As a result, an authentication algorithm will typically
require more round-trips when run over EAP than when run directly over IP.
Additionally, certificate-based authentication
algorithms using long certificate chains can result in many
round-trips due to fragmentation.

Where EAP runs over a lower layer in which significant packet loss
is experienced, or where the connection between
the authenticator and authentication server experiences significant
packet loss, EAP methods requiring many round-trips may
experience difficulties. In these situations, use of EAP
methods with fewer round trips is advisable.

Where transport efficiency is a consideration, and IP
transport is available, it may be preferable to expose an
artificially high EAP MTU to EAP and allow fragmentation to take
place in IP. Alternatively, it is possible to choose other
security mechanisms such as TLS [RFC2246] or IKE [RFC2409] or
an alternative authentication framework such as SASL [RFC2222] or
GSS-API [RFC2743].

References (Informative)

[RFC2246]
[RFC2409]
[RFC2743]
Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2743, January 2000.

[RFC2222]
Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

Recommended Resolution: Accept

Issue 166: Message Authenticator String Needs Clarification
Submitter name: Brian Burch
Submitter email address: Brian@PingToo.com
Date first submitted: 8/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-August/001576.html
Document: RFC2869bis
Comment type: T
Priority: 1
Section: 3.2
Rationale/Explanation of issue:

I realise this section has NOT changed significantly between the published RFC and the draft. However, I'm currently working in this area and I cannot derive an unambiguous
interpretation of the section from rfc2689bis-22.
Length description of problem:
There's a semi-recursive problem with this attribute. The EAP Message Authenticator is supposed to digitally sign an entire Radius/EAP packet, but so is the Radius Authenticator. Given that Radius is being used
as a "transport mechanism" for EAP, it follows that the Radius Authenticator MUST be the last field computed. In other words, the EAP Message Authenticator MUST be computed over the Radius packet BEFORE
the Radius Authenticator is known. Therefore, the EAP Message Authenticator must be computed over an all-zero's Radius Authenticator. This could be stated more clearly.

Now, we have the same question about the EAP Message Authenticator itself. Do we compute over an all-zero's EAP Message Authenticator, or do we compute over just the Radius Packet BEFORE the Message
Authenticator is added? I don't know and I can't tell from the RFC. My guess is the process is as follows:

1. Put the EAP Message attribute into the Radius Packet.
2. Put an all-zero's EAP Message Authenticator into the Radius Packet.
3. Compute the HMAC-MD5 digest for the entire Radius packet, i.e. {RadiusType;RadiusIdentifier;RadiusLength;RadiusRequestAuthenticator;Non-EAPRadiusAttributes;EAP-MSG;EAP-Zero-Auth}
4. Put the new HMAC-MD5 digest into the string value of the (currently zero) EAP-MessageAuthenticator attribute.
5. Compute the RadiusAuthenticator over the entire RadiusPacket (as normal).

I'm not certain whether my understanding is correct, but a description of this kind is less ambiguous. It would also make the sentence that describes "the message integrity check" much clearer.

I have the same kind of problem understanding the description of the EAP Message Authenticator within Access-Challenge, etc. Does it mean that I should perform the same process as described above (for a
RadiusRequest), but instead of using the all-zero's EAP Message Authenticator, substitute the digest from the original RadiusRequest EAP Message Authenticator? I don't think so, because the RFC says
"using the Request-Authenticator" and that means the Radius Authenticator, not the EAP Authenticator. It seems to me that the EAP and Radius Authenticators are being "tangled together" - if true, then logic
reponsible for EAP processing would also need to have access to the original Radius packet. This seems to be architecturally undesirable and deserves explanantion if unavoidable.

I apologise if my email is hard to understand. This is the first time I've tried to contribute to a draft RFC and I am not familiar with the process. If you need more information from me, I'll be pleased to continue the
discussion by private email with any interested parties.

Requested change:
1. new preamble/philosphy paragraph.
2. reworded RadiusRequest creation paragraph.
3. reworded RadiusRequest message integrity check paragraph.
4. reworded RadiusResponse/AccessChallenge/RadiusReject creation paragraph.
5. reworded RadiusResponse/AccessChallenge/RadiusReject message integrity check paragraph.

[Pasi Eronen]:

There's no ambiguity or circularity because in RADIUS, the Request
Authenticator is just a random number--not a keyed hash over the
packet contents. Thus, when calculating Message-Authenticator for
Access-Requests, we can include it without any circularity problems.

The Response Authenticator (in Access-Challenge/Accept/Reject)
is a keyed hash, but it's not included when calculating the
Message-Authenticator for responses (the HMAC-MD5 is not
calculated over "the entire RADIUS packet"; check the
definition in 2869bis). If it were included, then we would
have some circularity problems, and would have to set
the field to zero before calculating.

Recommended Resolution: Reject

Issue 167: Cleartext Passwords in EAP
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 8/14/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-August/001599.html
Document: RFC2284bis
Comment type: T
Priority: S
Section: 5.5, 5.6
Rationale/Explanation of issue:

Reading Section 5.5 and 5.6, it is not made crystal clear that the EAP OTP and GTC methods
are not intended to provide support for cleartexst passwords.

In Section 5.5, add to the end of the "Description" paragraph:

"The EAP OTP method is intended for use with the One-Time Password system
only, and MUST NOT be used to provide support for cleartext passwords."

In Section 5.6, add to the end of the "Description" paragraph:

"The EAP GTC method is intended for use with the Token Cards supporting
challenge/response authentication and MUST NOT be used to provide support
for cleartext passwords."

[Pasi Eronen]

Hi,

GTC can also be used with PEAP/TTLS to support password
databases that store a one-way hash of the password.
When used this way, it's not that insecure either (not
worse than e.g. SSH). This use is mentioned e.g. in
http://www.ilabs.interop.net/WLAN_Sec/Inner_Auth-lv03.pdf

I think it's safe to assume that in the absence of some
other solution, people will use GTC for this with IKEv2
as well.

This is probably not such a bad idea in many cases,
since the alternative is to store the password (or
password-equivalent) in clear (deploying SRP or
something similar doesn't seem realistic any time soon).

So, perhaps something like "The EAP GTC method MUST NOT
be used to provide support for cleartext passwords in the
absence of a protected tunnel with server authentication,
such as PEAP or IKEv2." would be sufficient?

[BA] Several problems with this:

a. On the AAA server side, protocols such as RADIUS do not mandate
confidentiality, and there is no support for "hiding" of the EAP-Message
attribute in the way that the User-Password attribute is hidden. That
means that any cleartext password sent via an EAP method will be exposed
on the wire from the NAS to the RADIUS server. Since protocols such as
EAP TTLS support "early termination" where the tunnel is terminated on a
different server (e.g. a proxy) than the final exchange, this results in a
cleartext password sent over a portion of the path.

[Joe Salowey] Even worse the intemediaries/NAS know the password. However it is
possible to deploy PEAP and TTLS so the protection is all the way to the
validating server.

b. Even if the RADIUS User-Password attribute is used, this creates a
number of vulnerabilities, including known plaintext attacks. If the
Request Authenticator repeats on any NAS with the same shared secret an
attacker would potentially be able to crack the User-Password attribute,
which is encrypted with a stream cipher dependent only on the shared
secret and the RA.

[Joe Salowey] I completely agree.

The introduction of cleartext passwords into EAP therefore represents a
substantial security vulnerability -- and one which was purposefully left
out of RFC 2284.

[Joe Salowey] While I would rather not see cleartext passwords, I'm not sure
that this represent a substantial security vulnerability if deployed
properly. In this case that would be in a server side authenticated
tunnel such as (TTLS/PEAP) that extends all the way to the EAP server
validating the password. This was not available when 2284 was concieved.

If you are going to advocate the use of passwords you're protected tunel
must be server authenticated and extend all the way to the AAA that does
the password validation. Intermediaries/NASes should never see the
password. Specifing that EAP-OTP and EAP-GTC should not be used for
cleartext passwords is good because they can be used without PEAP/TTLS.

I think it is up to PEAP/TTLS to define how and if clear text passwords
may be used within these tunnels and can define specific mechanisms to
do this. If they do allow this then they should specify that the that
the protected tunnel MUST extend all the way to the EAP-Server that
validates the passwords and authenticates this server to the client.
Tunnel client MUST NOT send a cleartext password unless it has
authenticated the EAP-Server and has determined that it is authorized to
receive the password.

[BA]

If the password is completely protected end-to-end via a tunnel, it's not
really a "cleartext password". Perhaps we need some language to make that
clear?

Proposed fix:

In Section 5.5, add to the end of the "Description" paragraph:

"The EAP OTP method is intended for use with the One-Time Password system
only, and MUST NOT be used to provide support for cleartext passwords."

In Section 5.6, add to the end of the "Description" paragraph:

"The EAP GTC method is intended for use with the Token Cards supporting
challenge/response authentication and MUST NOT be used to provide support
for cleartext passwords in the absence of a protected tunnel with server authentication."

Add Section 7.14

7.14 Cleartext Passwords

EAP does not support cleartext password authentication. This
omission is intentional. Where EAP is carried over physically
insecure lower layers, including wireless LANs [IEEE80211] or
the Internet, use of cleartext passwords would allow the password
to be captured by an attacker with access to the lower layer.

Since protocols encapsulating EAP, such as RADIUS [RFC3579],
may not provide confidentiality, even where the lower layer
is physically secure, EAP frames may be subsequently
encapsulated for transport over the Internet where they
may be captured by an attacker.

As a result, cleartext passwords cannot be securely used
within EAP, except where encapsulated within a protected
tunnel with server authentication. Some of the same risks
apply to EAP methods without dictionary attack resistance,
as defined in Section 7.2.1. For details, see Section 7.6.

Recommended Resolution: Accept

Issue 168: Peer link usage
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 8/22/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-August/001613.html
Document: RFC2284bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I have recently looked at EAP authentication traces where the
peer is sending data packets before and interspersed with,
EAP authentication. The peer had been previously attached to
another authenticator and was sending high-rate UDP traffic (video).
This is not a re-authentication -- it represents the authentication of a
peer to a new Authenticator (AP) after a roam.

After it connects to the new Authenticator, the peer continues to
empty the queue onto the new link.

Of course, the new Authenticator silently discards the traffic, but the
EAP traffic is trapped in the queue (e.g. is not prioritized), and so
it can take seconds to be sent by the peer. The result is
retransmission by the Authenticator -- and horrendous EAP
authentication latencies.

I would also note that this problem is not rare -- it has shown up in
quite a few implementations that we have tested.

It occurs to me that perhaps we need some explicit language in RFC 2284bis
to make it clear that this is nonsensical behavior. For example, that the
peer should not be sending outbound data or receiving
inbound data (e.g. non-EAP or 802.1X) traffic prior to the link being
usable.

[BA] It has been pointed out that the specific conditions under which data
frames may be sent are specific to the lower layer. For example, in PPP
it is not possible to send data until after NCP completes. In IEEE 802.11,
data frames cannot be sent except in State 3. So it is probably best
to leave this issue to the lower layer.

Recommended Resolution: Reject

Issue 169: Review of Key Framework-07
Submitter name: Dan Simon
Submitter email address: dansimon@microsoft.com
Date first submitted: 8/24/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-August/001615.html
Document: Key-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

p. 7, 1st para.:

"exhaustive search" is not the best terminology, since some algorithms
(notably number-theoretic ones) are attackable by means other than
brute force. "Breaking a cryptographic assumption", which you use
earlier in the paragraph, is a better phrasing.

p. 8, last para.:

"Key management" is often used as a synonym for "key distribution",
so the question of whether EAP itself is a key management protocol
should be thought of primarily in terms of whether it's EAP or
individual EAP methods that handle key distribution (i.e., key exchange).
I'll leave it to you to decide which way you like to think of it.

p. 13, first para.:

the IV must not be used by itself in computation of any quantity that
needs to remain secret. Obviously, it can be used in combination
with secret keys to derive other secret keys.

p. 21, 1st para.:

removing an SA based on a (single) failed authentication suggests an
easy targeted DoS attack (although, granted, a strictly local one, and
hence not that much of a concern). In any event, rate-limiting
authentication attempts should suffice, especially when strong keys
are being used.

p. 21, 3rd para.: You mean 802.11, not 820.11, right?

p. 22, 4th para.: See comment on p. 21, 1st para., above.

p. 24, last para.: I don't think you mean "perfect forward secrecy"
here so much as "key separation". None of the keys are being
"rolled forward" over time; rather, the MSK is being kept
cryptographically separated from the keys needed to impersonate
the backend server or peer.

p. 25, 2nd last para.: "between the peer and server",
not "between the peer and authenticator". (Right?)

p. 29, "Cryptographic separation": see first comment, on p. 7, above.

p. 30, "Key Strength" and "Freshness": I have no fundamental objection to
the 128-bit requirement, but I also would have no objection if it were weakened
somewhat (e.g., to 96 bits), and I wouldn't want to see an otherwise
reasonable future EAP method proposal get shot down over key-length paranoia.
On the other hand, if you're confident that this won't be a problem (i.e.,
that nobody will ever have trouble meeting the 128-bit requirement within
their method), I'll accept your judgment.

General: I was wondering if it might be a good idea to have a "DoS attack"
section in the security considerations section, spelling out what makes a DoS
attack worthy or unworthy of concern. One thought that came to mind as
I was reading the doc, for instance: you mention a peer having multiple SAs
with the same authenticator--might that allow a client to start establishing
SAs with the authenticator (e.g., an AP) until the latter "blows up" or maxes
out, then move on to the next authenticator and do the same? Again, if it
only disables the authenticator while the client is around, then the attack
could be dismissed as "microwave-oven-equivalent"--but could the request for
multiple SAs conceivably cause the authenticator to freeze up for a longer
period while it holds huge amounts of SA state for the single client,
waiting for it to return?

[BA] The proposed fixes are as follows:

In Section 1.2, change:

"In other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x, but the work an
adversary must do to perform this computation is equivalent to
performing exhaustive search for the secret state value."

To:

"In other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x."

In Section 1.3, change:

"While EAP methods may be based on key management protocols, EAP itself
is not a key management protocol. Thus, while EAP may provide for
mutual authentication and derivation of keying material, it does not
provide for the derivation or naming of transient session keys, the
selection of traffic modes such as transport or tunnel mode, the secure
negotiation of capabilities such as ciphersuites or filters, or support
for key activation. As a result, where EAP is used for key derivation,
a secure association protocol (phase 2) should be provided, supporting
the creation and deletion of unicast (phase 2a) and multicast (phase 2b)
security associations used for the protection of data."

To:

"EAP methods may mutually authenticate and derive keys. However
a distinct secure association exchange is required in order to
manage the creation and deletion of unicast (phase 2a) and multicast (phase 2b)
security associations between the EAP peer and authenticator."

In Section 1.3.3, change:

"[4] Mutual proof of possession of the keying material generated during
EAP authentication (phase 1). By requiring a mutual proof of
possession of the AAA-Key, the secure association protocol
demonstrates that both the EAP peer and authenticator have been
authenticated and authorized by the AAA server. Note that mutual
proof of possession is not the same thing as mutual authentication.
For example, as a result of a secure association protocol exchange,
the EAP peer may not be able to confirm the identity of the
authenticator."

To:

"[4] Mutual proof of possession of the AAA-Key. This
demonstrates that both the EAP peer and authenticator have been
authenticated and authorized by the AAA server. Since mutual
proof of possession is not the same as mutual authentication,
the EAP peer cannot verify authenticator assertions (including
the authenticator identity) as a result of this exchange."

In Section 2.2, change:

"Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the EAP client
and server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716] it cannot be used in computation of any quantity that
needs to remain secret, and is not used with any known ciphersuite.
As a result, its use has been deprecated and EAP methods are not
required to generate it."

To:

"Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the EAP client
and server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716] it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it."

In Section 3.3, change:

"A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA. Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA. However, the failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) is grounds for removal of a
AAA-Key SA by both parties."

To:

"A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA. Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA. Failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) need not be grounds for removal
of a AAA-Key SA by both parties; rate-limiting unicast secure association
exchanges should suffice to prevent a brute force attack."

In Section 3.3, change:

"820.11" to "802.11"

In Section 3.4, change:

"Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA. However, the failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) is grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs."

To:

"Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA. Failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) need not be grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs;
rate-limiting unicast secure association
exchanges should suffice to prevent a brute force attack."

In Section 3.5, change:

"In order to securely bind the EAP security association (phase 1) to its
child phase 2 security association, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the EAP (phase 1) keying material derived during the EAP
exchange (phase 1). In order to avoid confusion in the case where an
EAP peer has more than one EAP security association (phase 1) applicable
to establishment of a given phase 2 security association, the secure
association protocol (phase 2) supports key naming so that the
appropriate phase 1 keying material can be utilized by both parties in
the secure association protocol exchange."

To:

"In order to securely bind the AAA-Key security association (phase 1b) to its
child phase 2 security associations, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the AAA-Key. In order to avoid confusion in the case where an
EAP peer has more than one AAA-Key (phase 1b) applicable
to establishment of a phase 2 security association, it is necessary
for the secure association protocol (phase 2) to support key selection,
so that the appropriate phase 1b keying material can be utilized by
both parties in the secure association protocol exchange."

In Section 6.2, change:

"Where an untrusted AAA intermediary is present (such as a RADIUS proxy
or a Diameter agent), and data object security is not used, the MSK may
be recovered by an attacker in control of the untrusted intermediary.
Possession of the MSK enables decryption of data traffic sent between
the peer and a specific authenticator; however where Perfect Forward
Secrecy (PFS) is implemented, compromise of the MSK does enable an
attacker to impersonate the peer to another authenticator, since that
requires possession of the MK or EMSK, which are not transported by the
AAA protocol. This vulnerability may be mitigated by implementation of
redirect functionality, as provided in [DiamBASE]."

To:

"Where an untrusted AAA intermediary is present (such as a RADIUS proxy
or a Diameter agent), and data object security is not used, the AAA-Key may
be recovered by an attacker in control of the untrusted intermediary.
Possession of the AAA-Key enables decryption of data traffic sent between
the peer and a specific authenticator; however where key separation
is implemented, compromise of the AAA-Key does not enable an
attacker to impersonate the peer to another authenticator, since that
requires possession of the MK or EMSK, which are not transported by the
AAA protocol. This vulnerability may be mitigated by implementation of
redirect functionality, as provided in [DiamBASE]."

In Section 6.3, change:

"In order to prevent these attacks, [MiTM] recommends derivation of a
compound key by which the EAP peer and authenticator can prove that they
have participated in the entire EAP exchange."

To:

"In order to prevent these attacks, [MiTM] recommends derivation of a
compound key by which the EAP peer and server can prove that they
have participated in the entire EAP exchange."

Add Section 6.5:

"6.5 Denial of Service Attacks

The caching of security associations may result in vulnerability to
denial of service attacks. Since an EAP peer may derive multiple
EAP SAs with a given EAP server, and creation of a new EAP SA does
not implicitly delete a previous EAP SA, EAP methods that result in
creation of persistant state may be vulnerable to denial of
service attacks by a rogue EAP peer.

As a result, EAP methods creating persistent state may wish to
limit the number of cached EAP SAs (Phase 1a) corresponding to an EAP
peer. For example, an EAP server may choose to only retain
a few EAP SAs for each peer. This prevents a rogue peer from
denying access to other peers.

Similarly, an authenticator may have multiple AAA-Key SAs
corresponding to a given EAP peer; to conserve resources an
authenticator may choose to limit the number of cached
AAA-Key (Phase 1 b) SAs for each peer.

Depending on the media, creation of a new unicast secure
association SA may or may not imply deletion of a previous
unicast secure association SA. Where there is no implied
deletion, the authenticator may choose to limit
Phase 2 (unicast and multicast) secure association SAs
for each peer."

Recommended Resolution: Accept

Issue 170: Terminology
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001653.html
Document: EAP-05
Comment type: T
Priority: S
Section: 1.2
Rationale/Explanation of issue:

For the purposes of RFC 2284bis, it is not necessary to delve into the
uses of the MSK/EMSK -- it's just enough to say that they must be produced
and exported. Let's leave discussion of uses to the Key Framework
document.

In Section 1.2, change:

" Master Session Key (MSK)
Keying material that is derived between the EAP peer and
server and exported by the EAP method. The MSK is used in
the derivation of Transient Session Keys (TSKs) for the
ciphersuite negotiated between the EAP peer and
authenticator. Where a backend authentication server is
present, acting as an EAP server, it will typically
transport the MSK to the authenticator, so that in this
case, the MSK is available to the peer, authenticator and
authentication server.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. Unlike the
MSK, the EMSK is known only to the EAP peer and EAP server
and is not provided to a third party. The EMSK is reserved
for future uses that are not defined yet. For example, it
could be used to derive additional keying material for
purposes such as fast handoff, cryptographic binding, etc."

To:

" Master Session Key (MSK)
Keying material that is derived between the EAP peer and
server and exported by the EAP method. The MSK is at
least 64 octets in length. In existing implementations
a AAA server acting as an EAP server transports the MSK
to the authenticator.

Extended Master Session Key (EMSK)
Additional keying material derived between the EAP client
and server that is exported by the EAP method. The EMSK
is at least 64 octets in length. The EMSK is reserved
for future uses that are not defined yet and is not
provided to a third party."

Proposed Resolution: Accept

Issue 171: IKEv2 over TCP
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001654.html
Document: EAP-05
Comment type: T
Priority: S
Section: 2.2, 4.3
Rationale/Explanation of issue:

IKEv2 runs over UDP, not TCP as implied in Sections 2.2 and 4.3.

In Section 2.2, change:

"ISAKMP [IKEv2]); and TCP [IKEv2]"

to:

"IKEv2 [IKEv2]; and TCP [PIC]".

In Section 4.3, change:

" When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
within [IKEv2]), the authenticator retransmission timer SHOULD be set
to an infinite value, so that retransmissions do not occur at the EAP
layer. The peer may still maintain a timeout value so as to avoid
waiting indefinitely for a Request."

To:

" When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
within [PIC]), the authenticator retransmission timer MAY be set
to an artificially high value, so that retransmissions do not occur
at the EAP layer. The peer may still maintain a timeout value so
as to avoid waiting indefinitely for a Request."

Proposed Resolution: Accept

Issue 172: Miscellaneous NITs
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001655.html
Document: EAP-05
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

In Section 1.2, add:

"AAA
Authentication, Authorization and Accounting. AAA protocols with EAP support
include RADIUS [RFC3579] and Diameter [Diam-EAP]. In this
document, the terms "AAA server" and "backend authentication
server are used interchangeably."

In Section 2.2, Figure 1, page 11, change "Layer" to "layer"

In Section 3.4, change:

" To improve reliability, if a peer receives a lower layer success
indication as defined in Section 7.2, it MAY conclude that a Success
packet has been lost, and behave as it had actually received a
Success packet. This includes choosing to ignore the Success in some
circumstances as described in Section 4.2."

To:

" To improve reliability, if a peer receives a lower layer success
indication as defined in Section 7.2, it MAY conclude that a Success
packet has been lost, and behave as if it had actually received a
Success packet. This includes choosing to ignore the Success in some
circumstances as described in Section 4.2."

Proposed Resolution: Accept

Issue 173: RFC 2284bis method issues
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001656.html
Document: EAP-05
Comment type: E
Priority: S
Section: 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, 7.2.1
Rationale/Explanation of issue:
There are no security claims for the Identity (5.1),
Notification (5.2), and NAK (legacy, 5.3.1 or expanded, 5.3.2) methods. For each
of these methods, insert the following claims:

Security Claims (see Section 7.2):

Intended use: Physically secure lower layers;
vulnerable to attack when used
with wireless or over the Internet.
Fragmentation: No
Auth. Mechanism: None
Ciphersuite Negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key Derivation: No
Key strength: N/A
Dictionary attack prot: N/A
Key hierarchy: N/A
Fast reconnect: No
Crypt. binding: N/A
Acknowledged S/F: No

Other than a statement in Section 3.1, there is no
explicit statement about whether the methods defined
in RFC 2284bis support fragmentation. This should be
stated explicitly, and added as a required claim.

Add:

"Fragmentation: No
Auth. Mechanism: None
Ciphersuite Negotiation: No"

to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6

Also, change "Mechanism:" To "Auth. Mechanism:" in these
sections.

Add the following to Section 7.2.1:

"Protected Ciphersuite negotiation
This refers to the ability of an EAP method to
negotiate the ciphersuite used to protect the
EAP conversation, as well as to integrity protect the
negotiation. It does not refer to the ability to
negotiate the ciphersuite used to protect data.

Fragmentation
This refers to whether an EAP method supports fragmentation
and reassembly. As noted in Section 3.1, EAP methods
should support fragmentation and reassembly if EAP packets
can exceed the minimum MTU of 1020 octets."

Proposed Resolution: Accept

Issue 174: Mandatory to Implement
Submitter name: Dorothy Stanley
Submitter email address: dstanley@agere.com
Date first submitted: 9/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001657.html
Document: EAP-05
Comment type: T
Priority: S
Section: 5, 5.4
Rationale/Explanation of issue:
It seems wasteful to require an EAP peer to implement the
EAP MD5-Challenge method, even in situations (such as
IEEE 802.11i) where mutual authentication is required. Can
we relax this requirement?

In Section 5, change:

"All EAP implementations MUST support Types 1-4, which are defined in
this document, and SHOULD support Type 254. Implementations MAY
support other Types defined here or in future RFCs."

To:

"All EAP server implementations MUST support Types 1-4, which are defined in
this document, and SHOULD support Type 254. EAP peer implementations which
support physically secure lower layers MUST support types 1-4, and SHOULD
support Type 254. EAP Peer implementations which only support physically
insecure lower layers requiring mutual authentication MAY NOT support
Type 4 (EAP MD5-Challenge). An authenticator that supports only
pass-through MUST allow communication with a backend
authentication server that is capable of supporting Type 4 (MD5-Challenge),
although the implementation need not support MD5-Challenge
itself. However, if the EAP authenticator can be
configured to authenticate peers locally (e.g., not operate in
pass-through), then it MUST support Type 4 (MD5-Challenge).
Implementations MAY support other Types defined
here or in future RFCs."

Delete the following from Section 5.4:

"EAP peer and EAP server implementations MUST support the
MD5-Challenge mechanism. An authenticator that supports only
pass-through MUST allow communication with a backend
authentication server that is capable of supporting MD5-Challenge,
although the EAP authenticator implementation need not support
MD5-Challenge itself. However, if the EAP authenticator can be
configured to authenticate peers locally (e.g., not operate in
pass-through), then the requirement for support of the
MD5-Challenge mechanism applies."

Proposed resolution: Reject

Issue 175: Rewrite of Section 7.13
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/11/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001658.html
Document: EAP-05
Comment type: T
Priority: S
Section: 7.13
Rationale/Explanation of issue:

This section needs to be updated to avoid conflict with the Key Framework Document.

Change Section 7.13 to:

"7.13 Separation of authenticator and backend authentication server

It is possible for the EAP peer and EAP server to mutually
authenticate and derive a AAA-Key for a ciphersuite
used to protect subsequent data traffic. This does not present an
issue on the peer, since the peer and EAP client reside on the same
machine; all that is required is for the client to derive the AAA-Key
from the MSK and EMSK exported by the EAP method, and
to subsequently pass a Transient Session Key (TSK) to the ciphersuite module.

However, in the case where the authenticator and authentication
server reside on different machines, there are several implications
for security.

[a] Authentication will occur between the peer and the authentication
server, not between the peer and the authenticator. This means
that it is not possible for the peer to validate the identity of
the authenticator that it is speaking to, using EAP alone.

[b] As discussed in [RFC3579], the authenticator is dependent on the
AAA protocol in order to know the outcome of an authentication
conversation, and does not look at the encapsulated EAP packet
(if one is present) to determine the outcome. In practice this
implies that the AAA protocol spoken between the authenticator and
authentication server MUST support per-packet authentication,
integrity and replay protection.

[c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a
secure association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;guarantee liveness of the TSKs; provide protected
ciphersuite and capabilities negotiation;
synchronize key usage.

[d] A AAA-Key derived from the MSK and/or EMSK negotiated between
the peer and authentication server MAY be transmitted to the authenticator.
Therefore a mechanism needs to be provided to transmit the AAA-Key
from the authentication server to the authenticator that needs
it. The specification of the AAA-key derivation, transport and wrapping
mechanisms is outside the scope of this document. Further details on
AAA-Key Derivation are provided within [KEYFRAME]."

Proposed resolution: Accept

Issue 176: Sync on key framework reqts
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/22/2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-September/001702.html
Document: EAP-05
Comment type: T
Priority: S
Section: 7.2.1, 7.10
Rationale/Explanation of issue:

Since the EAP Key Framework document is informational,
all normative statements in it relating to EAP or
EAP methods (see Section 4.2.1) either need to be
included in RFC 2284bis or removed.

Add to Section 7.2.1:

Session independence
The demonstration that passive attacks (such as capture of the
EAP conversation) or active attacks (including compromise of the
MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent
or prior MSKs, EMSKs, TSKs or TEKs.

Add:

"Session indep.: N/A"

to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6

Change Section 7.10 to:

"It is possible for the peer and EAP server to mutually
authenticate and derive keys. In order to provide
keying material for use in a subsequently negotiated
ciphersuite, an EAP method supporting key derivation MUST
export a Master Session Key (MSK) of at least 64 octets,
and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server.

The MSK and EMSK MUST NOT be used directly to protect data;
however, they are of sufficient size to enable derivation
of a AAA-Key subsequently used to derive Transient Session
Keys (TSKs) for use with the selected ciphersuite.
Each ciphersuite is responsible for specifying how to
derive the TSKs from the AAA-Key.

In order to ensure freshness of Transient Session Keys
(TSKs) even in cases where one party may not have a high
quality random number generator, EAP methods generating
keys MUST support a two-nonce exchange in the derivation
of the MSK and EMSK, using nonces of at least 128-bits.

EAP methods export the MSK and EMSK and not Transient
Session Keys so as to allow EAP methods to be ciphersuite
and media independent. Keying material exported by EAP
methods MUST be independent of the ciphersuite negotiated
to protect data.

Depending on the lower layer, EAP methods may run
before or after ciphersuite negotiation, so that the
selected ciphersuite may not be known to the EAP method.
By providing keying material usable with any ciphersuite,
EAP methods can used with a wide range of ciphersuites and
media.

An EAP method deriving keys MUST specify how to derive
Transient EAP Keys (TEKs), used for protection of the EAP
conversation. TEKs MUST remain local to the EAP method
and MUST NOT be exported or provided to third parties. It is
RECOMMENDED that methods providing integrity protection of
EAP packets include coverage of all the EAP header fields,
including the Code, Identifier, Length, Type and Type-Data
fields.

In order to preserve algorithm independence, EAP methods
deriving keys SHOULD support (and document) the protected
negotiation of the ciphersuite used to protect the
EAP conversation between the peer and server. This is
distinct from the ciphersuite negotiated between the peer and
authenticator, used to protect data.

The strength of Transient Session Keys (TSKs) and
Transient EAP Keys (TEKs) used to protect data is
ultimately dependent on the strength of keys generated
by the EAP method. If an EAP method does not produce keying
material of sufficient strength, then the TSKs and TEKs
may be subject to brute force attack. EAP methods
supporting key derivation MUST be capable of generating
an MSK and EMSK, each with an effective key strength
of at least 128 bits.

Methods supporting key derivation MUST demonstrate
cryptographic separation between the TEK, MSK and
EMSK branches of the EAP key hierarchy. Without
violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function)
an attacker recovering the TEKs, MSK or EMSK MUST NOT
be able to recover the other quantities with a level
of effort less than brute force. Since Transient
Session Keys (TSKs) are derived from the MSK, if
branch independence holds, then it is also true that the
TSKs are cryptographically separate from the EMSK and TEKs.

Non-overlapping substrings of the MSK MUST be
cryptographically separate from each other, as defined
in Section 7.2.1. That is, knowledge of one substring
MUST NOT help in recovering some other substring without
breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply
splitting the AAA-Key to pieces of appropriate length.
Likewise, non-overlapping substrings of the EMSK MUST
be cryptographically separate from each other, and
from substrings of the MSK.

The EMSK is reserved for future use and MUST remain on
the EAP peer and EAP server where it is derived; it
MUST NOT be transported to, or shared with, additional
parties, or used to derive any other keys. (This restriction
will be relaxed in a future document that specifies how the
EMSK can be used.)

Since EAP does not provide for explicit key lifetime
negotiation, EAP peers, authenticators and authentication
servers MUST be prepared for situations in which one or
parties discard key state which remains valid on another
party.

This specification does not provide detailed guidance
on how EAP methods derive the MSK, EMSK and TEKs;
how the AAA-Key is derived from the MSK and/or EMSK;
or how the TSKs are be derived from the AAA-Key.

The development and validation of key derivation
algorithms is difficult, and as a result EAP methods
SHOULD reuse existing key derivation algorithms
(such as those specified in IKE [RFC2409], or TLS [RFC2246]),
rather than inventing new ones. EAP methods requesting
publication as an RFC MUST provide citations to
literature justifying the security of the chosen algorithms.
EAP methods SHOULD also utilize well established and analyzed
mechanisms for MSK, EMSK, TSK and TEK derivation.

Further details on EAP Key Derivation are provided within [KEYFRAME]."

[Pasi Eronen]

Hi,

I have a couple of comments to your proposed text:

> Add to Section 7.2.1:
> > Session independence
> The demonstration that passive attacks (such as capture of the
> EAP conversation) or active attacks (including compromise of the
> MSK, EMSK, TSKs or TEKs) does not enable compromise of subsequent
> or prior MSKs, EMSKs, TSKs or TEKs.
Currently 2284bis doesn't specify what a TEK is, and I fear that specifying it would unnecessarily rule out perfectly ok key agreement protocols. But if we haven't defined what a TEK is, we probably shouldn't have requirements about it! So, I propose that we remove the TEKs from the paragraph above (and all other references to them); IMHO they're an internal protocol detail, and not all protocols will have similar internal structure--if they did, we wouldn't need this Extensibility thing in the first place :-) <snip> > The MSK and EMSK MUST NOT be used directly to protect data;
> however, they are of sufficient size to enable derivation
> of a AAA-Key subsequently used to derive Transient Session
> Keys (TSKs) for use with the selected ciphersuite.
> Each ciphersuite is responsible for specifying how to
> derive the TSKs from the AAA-Key.

BTW, currently the text doesn't say who exactly is
responsible for specifying how to derive the AAA-Key from
the MSK. This should probably be clarified.

> In order to ensure freshness of Transient Session Keys
> (TSKs) even in cases where one party may not have a high
> quality random number generator, EAP methods generating
> keys MUST support a two-nonce exchange in the derivation
> of the MSK and EMSK, using nonces of at least 128-bits.

I think this is an unnecessary implementation detail; there
are other perfectly valid ways to ensure that your keys are
fresh. Besides, some algorithms simply can't be made to work
without both parties having good RNGs (e.g. EAP-TLS/PEAP
when used with DHE_DSS ciphersuites).

We might leave it there with a "SHOULD" or "RECOMMENDED"
text, though. In addition, the text probably should refer to
freshness of MSK/EMSK, since e.g. in 802.11i the TSKs are
always fresh even when the MSK isn't. Proposed replacement:

  "EAP methods SHOULD ensure the freshness of MSK and EMSK
  even in cases where one party may not have a high quality
  random number generator. A RECOMMENDED method is to include
  a two-nonce exchange in the derivation of the MSK and EMSK,
  using nonces of at least 128 bits."

<snip>

> The strength of Transient Session Keys (TSKs) and
> Transient EAP Keys (TEKs) used to protect data is
> ultimately dependent on the strength of keys generated
> by the EAP method. If an EAP method does not produce keying
> material of sufficient strength, then the TSKs and TEKs
> may be subject to brute force attack. EAP methods
> supporting key derivation MUST be capable of generating
> an MSK and EMSK, each with an effective key strength
> of at least 128 bits.

Appropriate key strength is IMHO a deployment issue, not
something that needs to be fixed here. I think it's enough
to require methods to disclose their effective key strength
(as is already required), and let the administrators
decide what is an acceptable length for their environment.

For instance, to fullfill the above requirement, EAP-TLS
and PEAP would have to prohibit the use of 1024-bit RSA
keys--something quite common today, and definitely
"secure enough" for this purpose.

Proposed replacement: delete the whole paragraph (we already
have a requirement to disclose key strength elsewhere).

<snip>

> The development and validation of key derivation algorithms is
> difficult, and as a result EAP methods SHOULD reuse existing key
> derivation algorithms (such as those specified in IKE [RFC2409], or
> TLS [RFC2246]), rather than inventing new ones.  EAP methods
> requesting publication as an RFC MUST provide citations to
> literature justifying the security of the chosen algorithms.  EAP
> methods SHOULD also utilize well established and analyzed mechanisms
> for MSK, EMSK, TSK and TEK derivation."

While I can't disagree about the recommendation to reuse existing
work as much as possible, why are we adding a new "MUST" level
requirement here? What exactly is the existing literature required
to justify?

For instance, just pointing out that e.g. some particular PRF
or encryption algorithm is OK doesn't guarantee that a protocol
composed from them is OK. Similarly, just pointing out that
TLS itself is OK doesn't guarantee that an EAP method using
TLS is ok (like we saw with the MitM attack against PEAP
and EAP-TTLS).

I'm also a bit worried that we might be placing unnecessary burden
on authors of EAP methods. IMHO it's better to see the methods
published at IETF than not published all (and the process of
getting something published at IETF is slow enough as it is).

Best regards,
Pasi

[Bernard Aboba]

> So, I propose that we remove the TEKs from the paragraph above
> (and all other references to them); IMHO they're an internal
> protocol detail, and not all protocols will have similar internal
> structure--if they did, we wouldn't need this Extensibility thing
> in the first place :-)

OK.

> > The MSK and EMSK MUST NOT be used directly to protect data;
> > however, they are of sufficient size to enable derivation
> > of a AAA-Key subsequently used to derive Transient Session
> > Keys (TSKs) for use with the selected ciphersuite.
> > Each ciphersuite is responsible for specifying how to
> > derive the TSKs from the AAA-Key.
>
> BTW, currently the text doesn't say who exactly is
> responsible for specifying how to derive the AAA-Key from
> the MSK. This should probably be clarified.

Yes.  How about:

"The AAA-Key is derived from the keying material exported by the EAP
method (MSK and EMSK).  This derivation occurs on the AAA server.  For
details, see [KEYFRAME]."

> > In order to ensure freshness of Transient Session Keys
> > (TSKs) even in cases where one party may not have a high
> > quality random number generator, EAP methods generating
> > keys MUST support a two-nonce exchange in the derivation
> > of the MSK and EMSK, using nonces of at least 128-bits.
>
> I think this is an unnecessary implementation detail; there
> are other perfectly valid ways to ensure that your keys are
> fresh. Besides, some algorithms simply can't be made to work
> without both parties having good RNGs (e.g. EAP-TLS/PEAP
> when used with DHE_DSS ciphersuites).
>
> We might leave it there with a "SHOULD" or "RECOMMENDED"
> text, though. In addition, the text probably should refer to
> freshness of MSK/EMSK, since e.g. in 802.11i the TSKs are
> always fresh even when the MSK isn't. Proposed replacement:
>
>   "EAP methods SHOULD ensure the freshness of MSK and EMSK
>   even in cases where one party may not have a high quality
>   random number generator. A RECOMMENDED method is to include
>   a two-nonce exchange in the derivation of the MSK and EMSK,
>   using nonces of at least 128 bits."

Another concern that motivated this reqts was  EAP SA naming. For that
purpose I'm not sure that a two-nonce exchange is required, just a
quantity from each side that together are very likely to be
temporally unique.  So maybe it is:

"EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases
where one party may not have a high quality random number generator. A
RECOMMENDED method is for each party to provide a nonce of at
least 128 bits, used in the derivation of the MSK and EMSK.  The
combination of the peer and server nonce uniquely identifies the
exchange."

[Joe] Is this the only way we are specifying names?  It seems that this
should be up to the EAP-method to define how an identifier is derived
for the exchange.

[Bernard] I don't think this paragraph should be talking about naming (since there
is no other discussion in RFC 2284bis about this.  Maybe just delete the
last sentence.

> > The strength of Transient Session Keys (TSKs) and
> > Transient EAP Keys (TEKs) used to protect data is
> > ultimately dependent on the strength of keys generated
> > by the EAP method. If an EAP method does not produce keying
> > material of sufficient strength, then the TSKs and TEKs
> > may be subject to brute force attack. EAP methods
> > supporting key derivation MUST be capable of generating
> > an MSK and EMSK, each with an effective key strength
> > of at least 128 bits.
>
> Appropriate key strength is IMHO a deployment issue, not
> something that needs to be fixed here. I think it's enough
> to require methods to disclose their effective key strength
> (as is already required), and let the administrators
> decide what is an acceptable length for their environment.

I think this requirement is about being capable of generating a strong key
if it is desired.  If it is desired to deploy using a strong key, then the
method needs to support that mode of operation.  So perhaps this should
be:

"The strength of Transient Session Keys (TSKs) used to protect
data is ultimately dependent on the strength of keys generated
by the EAP method.  If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force attack.
In order to enable deployments requiring strong keys,  EAP methods
supporting key derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key strength of at least 128 bits."

> For instance, to fullfill the above requirement, EAP-TLS
> and PEAP would have to prohibit the use of 1024-bit RSA
> keys--something quite common today, and definitely
> "secure enough" for this purpose.

This requirement is about what should be implemented not what should be used.

> > The development and validation of key derivation algorithms is
> > difficult, and as a result EAP methods SHOULD reuse existing key
> > derivation algorithms (such as those specified in IKE [RFC2409], or
> > TLS [RFC2246]), rather than inventing new ones.  EAP methods
> > requesting publication as an RFC MUST provide citations to
> > literature justifying the security of the chosen algorithms.  EAP
> > methods SHOULD also utilize well established and analyzed mechanisms
> > for MSK, EMSK, TSK and TEK derivation."
>
> While I can't disagree about the recommendation to reuse existing
> work as much as possible, why are we adding a new "MUST" level
> requirement here? What exactly is the existing literature required
> to justify?

If a mechanism is well established and analyzed, presumably literature
citations are not an issue.  So I think this is redundant.  Also,
EAP methods do not derive TSKs.  Perhaps it should be:

"The development and validation of key derivation algorithms is difficult,
and as a result EAP methods SHOULD reuse well established and analyzed
mechanisms for key derivation (such as those specified in IKE [RFC2409] or
TLS [RFC2246]), rather than inventing new ones.  EAP methods SHOULD also
utilize well established and analyzed mechanisms for MSK and EMSK
derivation."

> For instance, just pointing out that e.g. some particular PRF
> or encryption algorithm is OK doesn't guarantee that a protocol
> composed from them is OK. Similarly, just pointing out that
> TLS itself is OK doesn't guarantee that an EAP method using
> TLS is ok (like we saw with the MitM attack against PEAP
> and EAP-TTLS).

Yes, that's definitely true. Do you have any text to recommend?

> I'm also a bit worried that we might be placing unnecessary burden
> on authors of EAP methods. IMHO it's better to see the methods
> published at IETF than not published all (and the process of
> getting something published at IETF is slow enough as it is).

I'd agree.

[Pasi Eronen]

Bernard Aboba wrote:
> > BTW, currently the text doesn't say who exactly is
> > responsible for specifying how to derive the AAA-Key from
> > the MSK. This should probably be clarified.
> > Yes. How about:
> > "The AAA-Key is derived from the keying material exported by the EAP
> method (MSK and EMSK). This derivation occurs on the AAA server.
> For details, see [KEYFRAME]."
Hmm, does this create a dependency to the keying framework? I'm not sure; but it's not possible to actually implement a working system without knowing how this derivation is done... Also, since many deployed systems just use AAA-Key=MSK, this certainly should be documented somewhere... how about this?

[Jari] Yes, this is important.

"The AAA-Key is derived from the keying material exported by the
EAP method (MSK and EMSK). This derivation occurs on the AAA server.
In many existing protocols that use EAP, the AAA-Key and MSK
are equivalent, but more complicated mechanisms are possible
(see [KEYFRAME] for details)."

[Jari] Works for me.


> Another concern that motivated this reqts was EAP SA naming. For
> that purpose I'm not sure that a two-nonce exchange is required,
> just a quantity from each side that together are very likely to
> be temporally unique.  So maybe it is:
>
> "EAP methods SHOULD ensure the freshness of the MSK and EMSK
> even in cases where one party may not have a high quality
> random number generator. A RECOMMENDED method is for each party
> to provide a nonce of at least 128 bits, used in the derivation
> of the MSK and EMSK.  The combination of the peer and server
> nonce uniquely identifies the exchange."

This works for me (except that I'm not sure if the
last sentence is actually necessary).

<snip>

> I think this requirement is about being capable of generating
> a strong key if it is desired.  If it is desired to deploy using
> a strong key, then the method needs to support that mode of
> operation.  So perhaps this should be:
>
> "The strength of Transient Session Keys (TSKs) used to protect
> data is ultimately dependent on the strength of keys generated
> by the EAP method.  If an EAP method cannot produce keying material of
> of sufficient strength, then the TSKs may be subject to brute
> force attack. In order to enable deployments requiring strong
> keys,  EAP methods supporting key derivation SHOULD be capable
> of generating an MSK and EMSK, each with an effective key
> strength of at least 128 bits."

Looks ok!
<snip>

> > While I can't disagree about the recommendation to reuse existing
> > work as much as possible, why are we adding a new "MUST" level
> > requirement here? What exactly is the existing literature required
> > to justify?
>
> If a mechanism is well established and analyzed, presumably
> literature citations are not an issue.  So I think this is
> redundant.  Also, EAP methods do not derive TSKs.  Perhaps it
> should be:
>
> "The development and validation of key derivation algorithms
> is difficult, and as a result EAP methods SHOULD reuse well
> established and analyzed mechanisms for key derivation (such as
> those specified in IKE [RFC2409] or TLS [RFC2246]), rather than
> inventing new ones.  EAP methods SHOULD also utilize well
> established and analyzed mechanisms for MSK and EMSK derivation."

Ok.

> > For instance, just pointing out that e.g. some particular PRF
> > or encryption algorithm is OK doesn't guarantee that a protocol
> > composed from them is OK. Similarly, just pointing out that
> > TLS itself is OK doesn't guarantee that an EAP method using
> > TLS is ok (like we saw with the MitM attack against PEAP
> > and EAP-TTLS).
>
> Yes, that's definitely true. Do you have any text to recommend

Hmm... I'm not sure if we actually need any text about this.
Presumably the "security considerations" section for the EAP
method should discuss any known weaknesses, and the yet-unknown
weaknesses we by definition don't about yet :-) And I really
wouldn't like to see a requirement saying that "EAP methods
must have formal security proofs" or anything like that.

[Jari] Agree.


So, the recommendation to reuse existing work as
much as possible might be sufficient here?


Best regards,
Pasi

[Bernard Aboba] How about this?

Add to Section 7.2.1:


Session independence
The demonstration that passive attacks (such as capture of the

EAP conversation) or active attacks (including compromise of the
MSK, EMSK, TSKs) does not enable compromise of subsequent

or prior MSKs, EMSKs, or TSKs.

Add:

"Session indep.: N/A"

to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6

Change Section 7.10 to the following:

"It is possible for the peer and EAP server to mutually
authenticate and derive keys. In order to provide
keying material for use in a subsequently negotiated
ciphersuite, an EAP method supporting key derivation MUST
export a Master Session Key (MSK) of at least 64 octets,
and an Extended Master Session Key (EMSK) of at least 64
octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server.

The MSK and EMSK MUST NOT be used directly to protect data;
however, they are of sufficient size to enable derivation
of a AAA-Key subsequently used to derive Transient Session
Keys (TSKs) for use with the selected ciphersuite.
Each ciphersuite is responsible for specifying how to
derive the TSKs from the AAA-Key.

The AAA-Key is derived from the keying material exported by the
EAP method (MSK and EMSK). This derivation occurs on the AAA server.
In many existing protocols that use EAP, the AAA-Key and MSK
are equivalent, but more complicated mechanisms are possible
(see [KEYFRAME] for details).

EAP methods SHOULD ensure the freshness of the MSK and EMSK even in cases
where one party may not have a high quality random number generator. A
RECOMMENDED method is for each party to provide a nonce of at
least 128 bits, used in the derivation of the MSK and EMSK.

EAP methods export the MSK and EMSK and not Transient
Session Keys so as to allow EAP methods to be ciphersuite
and media independent. Keying material exported by EAP
methods MUST be independent of the ciphersuite negotiated
to protect data.

Depending on the lower layer, EAP methods may run
before or after ciphersuite negotiation, so that the
selected ciphersuite may not be known to the EAP method.
By providing keying material usable with any ciphersuite,
EAP methods can used with a wide range of ciphersuites and
media.

It is
RECOMMENDED that methods providing integrity protection of
EAP packets include coverage of all the EAP header fields,
including the Code, Identifier, Length, Type and Type-Data
fields.

In order to preserve algorithm independence, EAP methods
deriving keys SHOULD support (and document) the protected
negotiation of the ciphersuite used to protect the
EAP conversation between the peer and server. This is
distinct from the ciphersuite negotiated between the peer and
authenticator, used to protect data.

The strength of Transient Session Keys (TSKs) used to protect
data is ultimately dependent on the strength of keys generated
by the EAP method. If an EAP method cannot produce keying material of
sufficient strength, then the TSKs may be subject to brute force attack.
In order to enable deployments requiring strong keys, EAP methods
supporting key derivation SHOULD be capable of generating an
MSK and EMSK, each with an effective key strength of at least 128 bits.

Methods supporting key derivation MUST demonstrate
cryptographic separation between the MSK and
EMSK branches of the EAP key hierarchy. Without
violating a fundamental cryptographic assumption
(such as the non-invertibility of a one-way function)
an attacker recovering the MSK or EMSK MUST NOT
be able to recover the other quantity with a level
of effort less than brute force.

Non-overlapping substrings of the MSK MUST be
cryptographically separate from each other, as defined
in Section 7.2.1. That is, knowledge of one substring
MUST NOT help in recovering some other substring without
breaking some hard cryptographic assumption. This is required
because some existing ciphersuites form TSKs by simply
splitting the AAA-Key to pieces of appropriate length.
Likewise, non-overlapping substrings of the EMSK MUST
be cryptographically separate from each other, and
from substrings of the MSK.

The EMSK is reserved for future use and MUST remain on
the EAP peer and EAP server where it is derived; it
MUST NOT be transported to, or shared with, additional
parties, or used to derive any other keys. (This restriction
will be relaxed in a future document that specifies how the
EMSK can be used.)

Since EAP does not provide for explicit key lifetime
negotiation, EAP peers, authenticators and authentication
servers MUST be prepared for situations in which one or
parties discard key state which remains valid on another
party.

This specification does not provide detailed guidance
on how EAP methods derive the MSK and EMSK;
how the AAA-Key is derived from the MSK and/or EMSK;
or how the TSKs are be derived from the AAA-Key.

The development and validation of key derivation algorithms is difficult,
and as a result EAP methods SHOULD reuse well established and analyzed
mechanisms for key derivation (such as those specified in IKE [RFC2409] or
TLS [RFC2246]), rather than inventing new ones. EAP methods SHOULD also
utilize well established and analyzed mechanisms for MSK and EMSK
derivation.
Further details on EAP Key Derivation are provided within [KEYFRAME]."

Proposed resolution: Accept

Issue 177: Rewrite of SA sections
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: 9/25/2003
Reference:
Document: Keyframe-07
Comment type: T
Priority: S
Section: 3.1-3.5
Rationale/Explanation of issue:

The SA discussion needs to be revised given recent Key Design team discussions. Change sections 3.1-3.5 to:

"3.1 EAP SA

An EAP SA exists between the EAP peer and server. It includes:

   the EAP peer identity
   the EAP server identity
   the EAP method type
   the EAP peer and server nonces
   the Transient EAP Keys (TEKs)
   the Master Session Key (MSK)
   the Extended Master Session Key (EMSK)

The EAP SA is not explicitly bound to a particular port on the EAP peer.
An EAP peer with multiple ports may create an EAP SA on one port and
then choose to use that SA to subsequently create a phase 2 SA on
another port.

It cannot be assumed that the EAP SA expires after the EAP
authentication and key derivation is complete. Some methods may be
support "fast resume" by caching EAP SA state on the EAP peer and
server.

EAP does not support SA lifetime negotiation or an SA "delete"
operation, although some EAP methods may support this. Either the EAP
peer or EAP server may delete an EAP SA at any time, and methods which
allow an EAP SA to persist need to permit the EAP peer and server to
recognize when they have gotten out of sync with respect to the EAP SA
state.

For example, EAP TLS [RFC 2716] supports "fast resume" (TLS session
resumption), which assumes that both the EAP peer and server cache EAP
master keys (the TLS master secret). An EAP peer attempting a fast
resume provides the session-id identifying the session that it wishes to
resume. If the EAP server retains the master key corresponding to this
session in its cache, then the "fast resume" can proceed; otherwise a
full TLS exchange ensues.

An EAP peer may negotiate EAP SAs with one or more EAP servers as the
result of pre-authentication or AAA load balancing and failover effects.
For example, an EAP peer may pre-authenticate to one or more EAP
servers, or may be directed to more than one EAP server as the result of
an authentication server becoming unreachable. In general, EAP servers
cannot be assumed to be synchronized with respect to EAP SA state,
particularly since they may not exist within the same administrative
domain. Since an EAP SA is typically created prior to secure
association, the EAP SA is not bound to a particular target network.

3.2. AAA-Key SA

An AAA-Key SA exists between the authenticator and authentication
server. It includes:

   the EAP peer name
   the NAS/authenticator name
   the AAA-Key
   the AAA-Key maximum lifetime (if known)
   the AAA attributes sent in the Access-Accept

The AAA-Key SA is created as the result of the transport of the AAA-
Token from the authentication server to the NAS/authenticator. The AAA-
Key SA is more specific than the EAP SA in that it is bound to a
particular authenticator, as defined by the NAS identification attributes
included in the AAA request.

For example, within RADIUS the NAS is identified by the NAS-Identifier,
NAS-IP-Address and NAS-IPv6-Address attributes. Unless the attributes
providing explicit scoping are providing, it is assumed that the AAA-Key
is usable by the NAS to which it is delivered, without restriction.

Since the AAA-Key SA is bound to the NAS identified in the AAA Request, a
NAS/authenticator that operates on a shared use network will share the
AAA-Key SA between multiple virtual NAS devices. Since these virtual NAS
devices might appear to the peer to be different NASes, a mechanism is
needed for the EAP peer to differentiate them, so that the peer can
determine which devices a AAA-Key can be used with.

In the case of IEEE 802.11, it has been proposed that a "Group Identifier"
be added to the Beacon and Probe Response messages, containing a MAC
address uniquely identifying a particular Access Point. Such a "Group
Identifier" could be included in the NAS-Identifier attribute so as to
uniquely identify a particular NAS to the AAA server.

Since a AAA-Key SA may be shared between virtual NASes, it is possible for
an EAP peer to successfully complete a fast handoff between virtual NASes
operating on the same physical NAS. Since the virtual NASes may have
access to different networks or even exist within different administrative
domains, this creates a security problem unless the AAA attributes are
applied to the new session.

For example, an EAP peer authenticating to a GUEST network could
successfully complete a fast handoff to the CORPORATE network. This would
be harmless if it only resulted in the peer receiving the GUEST service,
without obtaining additional time on the network.

Existing RADIUS attributes may not be adequate to this task. For example,
today there are no standard attributes usable to indicate:

a. Which SSIDs a peer is authorized to attach to.
b. The absolute time at which a session is to end (as opposed to the
   Session-Time attribute which is relative)
c. The times of day during which access is allowed
d. The Calling-Station-Ids from which a client may access the network
e. Whether fast handoff is permitted.

Attribute a) is useful so that when a client attempts a fast handoff to
the CORPORATE network from the GUEST network, the NAS checking the AAA
attributes will discover that the peer is only authorized for GUEST, not
CORPORATE. As a result, the fast handoff attempt will fail.

Attribute b) can be used to prevent a peer attempting a fast handoff
between the GUEST network and another network from obtaining additional
session time.

Attribute c) can be used to prevent a peer from accessing the
network outside of authorized hours.

Attribute d) can be used to ensure that a peer is accessing the network
only from an administrator-authorized NIC. This might be important in
high security installations.

Attribute e) might be useful in situations where the administrator desires
to limit deployment of fast handoff.

In fast handoff, a single EAP SA may be used to establish multiple AAA-
Key SAs (see Appendix E for details). Although a AAA-Key SA may not
persist longer than the maximum SA lifetime negotiated for an EAP SA
(for methods that support such a negotiation), if an EAP SA is deleted
by an EAP peer or authenticator, this does not necessarily imply
deletion of the child AAA-Key SA. For example, fast handoff keying
material provided by an authentication server may continue to be cached
by NASes/authenticators after the corresponding EAP SA has been deleted
by the authentication server and/or peer.

3.3. Unicast Secure Association SA

The unicast secure association SA exists between the EAP peer and
authenticator. It includes:

   the peer port identifier (Calling-Station-Id)
   the NAS port identifier (Called-Station-Id)
   the unicast Transient Session Keys (TSKs)
   the unicast secure association peer nonce
   the unicast secure association authenticator nonce
   the negotiated unicast capabilities and unicast ciphersuite.

During the phase 2a exchange, the EAP peer and authenticator demonstrate
mutual possession of the AAA-Key derived and transported in phase 1;
securely negotiate the session capabilities (including unicast
ciphersuites), and derive fresh unicast transient session keys. The
AAA-Key SA (phase 1b) is therefore used to create the unicast secure
association SA (phase 2a), and in the process the phase 2a unicast
secure association SA is bound to ports on the EAP peer and
authenticator. However in order for a phase 2a security association to
be established, it is not necessary for the phase 1a exchange to be
rerun each time. This enables the EAP exchange to be bypassed when fast
handoff support is desired.

Since both peer and authenticator nonces are used in the creation of the
unicast secure association SA, the transient session keys (TSKs) are
guaranteed to be fresh, even if the AAA-Key is not. As a result one or
more unicast secure association SAs (phase 2a) may be derived from a
single AAA-Key SA (phase 1b). The phase 2a security associations may
utilize the same security parameters (e.g. mode, ciphersuite, etc.) or
they may utilize different parameters.

A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA. Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA. However, the failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) is grounds for removal of a
AAA-Key SA by both parties.

An EAP peer may be able to negotiate multiple phase 2a SAs with a single
EAP authenticator, or may be able to maintain multiple phase 2a SAs with
multiple authenticators, based on a single EAP SA derived in phase 1a.
For example, during a re-key of the secure association protocol SA, it
is possible for two phase 2a SAs to exist during the period between when
the new phase 2a SA parameters (such as the TSKs) are calculated and
when they are installed. Except where explicitly specified by the
semantics of the unicast secure association protocol, it should not be
assumed that the installation of a new phase 2a SA necessarily implies
deletion of the old phase 2a SA.

On some media (e.g. 802.11) a port on an EAP peer may only establish
phase 2a and 2b SAs with a single port of an authenticator within a
given Local Area Network (LAN). This implies that the successful
negotiation of phase 2a and/or 2b SAs between an EAP peer port and a new
authentiator port within a given LAN implies the deletion of existing
phase 2a and 2b SAs with authenticators offering access to that Local
Area Network (LAN). However, since a given IEEE 820.11 SSID may be
comprised of multiple LANs, this does not imply an implicit binding of
phase 2a and 2b SAs to an SSID.

3.4. Multicast Secure Association SA

The multicast secure association SA includes:

   the multicast Transient Session Keys
   the direction vector (for a uni-directional SA)
   the negotiated multicast capabilities and multicast ciphersuite

It is possible for more than one multicast secure association SA to be
derived from a single unicast secure association SA.   However, a
multicast secure association SA is bound to a single EAP SA and a single
AAA-Key SA.

During a re-key of the multicast secure association protocol SA, it is
possible for two phase 2b SAs to exist during the period between when
the new phase 2b SA parameters (such as the multicast TSKs) are
calculated and when they are installed. Except where explicitly
specified by the semantics of the multicast secure association protocol,
it should not be assumed that the installation of a new phase 2b SA
necessarily implies deletion of the old phase 2b SA.

A multicast secure association SA (phase 2b) may not persist longer than
the maximum lifetime of its parent AAA-Key or unicast secure association
SA. However, the deletion of a parent EAP, AAA-Key or unicast secure
association SA does not necessarily imply deletion of the corresponding
multicast secure association SA. For example, a unicast secure
association SA may be rekeyed without implying a rekey of the multicast
secure association SA.

Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA. However, the failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) is grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs.

3.5. Key Naming

In order to support the correct processing of phase 2 security
associations, the secure association (phase 2) protocol supports the
naming of phase 2 security associations and associated transient session
keys, so that the correct set of transient session keys can be
identified for processing a given packet. Explicit creation and
deletion operations are also typically supported so that establishment
and re-establishment of transient session keys can be synchronized
between the parties.

In order to securely bind the EAP security association (phase 1) to its
child phase 2 security association, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the EAP (phase 1) keying material derived during the EAP
exchange (phase 1). In order to avoid confusion in the case where an
EAP peer has more than one EAP security association (phase 1) applicable
to establishment of a given phase 2 security association, the secure
association protocol (phase 2) supports key naming so that the
appropriate phase 1 keying material can be utilized by both parties in
the secure association protocol exchange.

As noted earlier, the discovery phase (phase 0) may be insecure so that
in order to prevent spoofing of discovery packets, the secure
association (phase 2) protocol should support the secure verification of
discovered capabilities, including ciphersuites and other security
parameters. This is more scalable than attempting to configure the
supported capabilities on each peer and authenticator and more secure
than unprotected capabilities negotiation.

For example, a peer might be pre-configured with policy indicating the
ciphersuite to be used in communicating with a given authenticator.
Within PPP, the ciphersuite is negotiated within the Encryption Control
Protocol (ECP), after EAP authentication is completed. Within
[IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe
Responses, and are securely verified during a 4-way exchange after EAP
authentication has completed.

As part of the secure association protocol (phase 2), it is necessary to
bind the Transient Session Keys (TSKs) to the keying material provided
in the AAA-Token. This ensures that the EAP peer and authenticator are
both clear about what key to use to provide mutual proof of possession.
Keys within the EAP key hierarchy are named as follows:

EAP SA name
     The EAP security association is negotiated between the EAP peer and
     EAP server, and is uniquely named as follows <EAP peer name, EAP
     server name, EAP Method Type, EAP peer nonce, EAP server nonce>.
     Here the EAP peer name and EAP server name are the identifiers
     securely exchanged within the EAP method. Since multiple EAP SAs
     may exist between an EAP peer and EAP server, the EAP peer nonce
     and EAP server nonce allow EAP SAs to be differentiated. The
     inclusion of the Method Type in the EAP SA name ensures that each
     EAP method has a distinct EAP SA space.

MK Name
     The EAP Master Key, if supported by an EAP method, is named by the
     concatenation of the EAP SA name and a method-specific session-id.

AAA-Key Name
     The AAA-Key is named by the concatenation of the EAP SA name,
     "AAA-Key" and the authenticator name, since the AAA-Key is bound
     to a particular authenticator. For the purpose of identification,
     the NAS-Identifier attribute is recommended. In order to ensure that
     all parties can agree on the NAS name this requires the NAS to
     advertise its name (typically using a media-specific mechanism,
     such as the 802.11 Beacon/Probe Response)."

Proposed resolution: Discuss

Issue 178: Review of Key Framework Document
Submitter name: Tschofenig Hannes
Submitter email address: hannes.tschofenig@siemens.com
Date first submitted: 9/29/2003
Reference: http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes:
Document: Keyframe-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I have compiled some comments for the eap key management framework draft.
you find the comments at:

http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes:

[BA] Proposed fixes are as follows:

In Section 1, change:

"Since in EAP keying material is generated by EAP
methods, transported by AAA protocols, transformed into session keys by
secure association protocols and used by link layer ciphersuites, it is"

To:

"Since in EAP keying material is generated by EAP
methods, transported by AAA protocols, transformed into session keys by
secure association protocols and used by lower layer ciphersuites, it is"

In Section 1, delete:

"The document is organized as follows:

Section 1 provides an introduction and defines terminology.
Section 2 describes the EAP key hierarchy and exchanges.
Section 3 describes EAP security associations and key naming.
Section 4 describes the threat model and security requirements.
Section 5 describes the IANA considerations.
Section 6 describes security considerations.
Section 7 provides references.
Appendix A summarizes the keying requirements for link layer ciphersuites.
Appendix B provides an example transient EAP key (TEK) hierarchy.
Appendix C provides an example MSK and EMSK hierarchy.
Appendix D provides an example Transient Session Key (TSK) derivation.
Appendix E describes AAA-Key derivation, including fast handoff."

In Section 1.2, delete:

"For example, attributes might include the peer layer 2
address (Calling-Station-Id), the authenticator layer 2 address
(Called-Station-Id) and IP address (NAS-IP-Address), the key name,
etc."

In Section 1.2, change:

"The format and wrapping of the AAA-Token, which is intended
to be accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol."

To:

"The format and wrapping of the AAA-Token, which is intended
to be accessible only to the backend authentication server and
authenticator, is defined by the AAA protocol. Examples
include RADIUS [RFC2548], and Diameter [DiamEAP]."

In Section 1.2, delete:

"Key derivation
This refers to the ability of the EAP method to export a
ciphersuite-independent Master Session Key (MSK), Extended Master
Session Key (EMSK), and (optionally) an Initialization Vector (IV)."

In Section 1.2, add:

"AAA-Key
A key derived by the EAP peer and EAP server and transported to
the authenticator. In 802.11 terminology, the first 32 octets of
the AAA-Key is known as the Pairwise Master Key (PMK)."

In Section 1.3, change:

"Once the EAP peer and authenticator discover each other, they
authenticate using EAP (phase 1a)."

To:

"Once the EAP peer and authenticator discover each other, EAP
authentication may begin (phase 1a)."

In Section 1.3, delete:

"In 802.11 terminology, the first
32 octets of the AAA-Key is known as the Pairwise Master Key (PMK)."

In Section 1.3, change:

" <--------------------------------
AAA-Key transport (phase 1b)"

to:

" <--------------------------------
AAA-Key transport (optional; phase 1b)"

In Section 1.3, change:

" <----------------------------->
Multicast Secure association (phase 2b)"

To:

" <----------------------------->
Multicast Secure association (optional; phase 2b)"

In Section 1.3.2, change:

"Once the EAP peer and authenticator discover each other, they
authenticate using EAP (phase 1a)."

To:

"Once the EAP peer and authenticator discover each other, they
exchange EAP packets."

In Section 1.3.2, change:

"EAP supports either one-way authentication (in which the peer
authenticates to the EAP server), or mutual authentication (in which the
peer and EAP server mutually authenticate)."

To:

"Some EAP methods exist which only support one-way
authentication; however, EAP methods deriving keys
are required to support mutual authentication."

In Section 1.3.3, delete:

"While EAP methods may be based on key management protocols, EAP itself
is not a protocol for negotiation of security associations. While EAP
methods supporting key derivation provide for mutual authentication and
creation of EAP (phase 1) security associations, in order to preserve
media independence, they typically do not support generation of
transient session keys or negotiation of ciphersuites used in the
protection of data. As a result, where EAP is used for key derivation,
a secure association protocol (phase 2) should be provided, supporting
the creation and deletion of phase 2 security associations used for the
protection of data."

In Section 1.3.3, change:

" [2] Generation of fresh transient session keys. This is typically
accomplished via the exchange of nonces within the secure
association protocol, and includes generation of both unicast
(phase 2a) and multicast (phase 2b) session keys. While multicast
traffic may only pass in one direction in certain cases (such as in
IEEE 802.11 infrastructure mode, where only the Access Point sends
multicast traffic), in other cases (such as IEEE 802.11 adhoc
mode), both endpoints may send multicast traffic. By not using the
AAA-Key directly to protect data, the secure association protocol
protects against compromise of the AAA-Key, and by guaranteeing the
freshness of transient session key, assures that session keys are
not reused."

to:

" [2] Generation of fresh transient session keys. This is typically
accomplished via the exchange of nonces within the secure
association protocol, and includes generation of both unicast
(phase 2a) and multicast (phase 2b) session keys. By not using the
AAA-Key directly to protect data, the secure association protocol
protects against compromise of the AAA-Key, and by guaranteeing the
freshness of transient session key, assures that session keys are
not reused."

In Section 2.1.1 add to the end:

"As a result, EAP methods should not utilize identifiers associated
with a particular usage environment (e.g. MAC addresses)."

In Section 2.1.3, change:

"Ciphersuite negotiation
In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated between the peer and
authenticator."

To:

"Knowledge of capabilities
In practice, an EAP method may not have knowledge of the
ciphersuite that has been negotiated between the peer and
authenticator."

In Section 2.2, change:

"EAP Master key (MK)
A key derived between the EAP client and server during the EAP
authentication process, and that is kept local to the EAP method
and not exported or made available to a third party. Since the MK
is a residue of a successful EAP authentication exchange, it is
possible to shorten future EAP exchanges between an EAP peer and
server by providing proof of MK possesion, a technique known as
"fast resume".

Master Session Key (MSK)
Keying material (at least 64 octets) that is derived between the
EAP client and server and exported by the EAP method. Whenever a
full EAP authentication is performed (not fast handoff), the MSK is
chosen as the AAA-Key (see Appendix E for details)."

To:

"EAP Master key (MK)
A key derived between the EAP client and server during the EAP
authentication process, and that is kept local to the EAP method
and not exported or made available to a third party."

Master Session Key (MSK)
Keying material (at least 64 octets) that is derived between the
EAP client and server and exported by the EAP method."

In Section 2.2, change:

"Extended Master Session Key (EMSK)
Additional keying material (64 octets) derived between the EAP
client and server that is exported by the EAP method. Unlike the
MSK which is transported from the authentication server to the
authenticator, the EMSK is known only to the EAP peer and server
and is not provided to a third party. The EMSK therefore is not
transported by the backend authentication server to the
authenticator, although quantities derived from it may be used as
the AAA-Key in situations in which EAP authentication is bypassed
(e.g. fast handoff).

Currently the EMSK is reserved for future uses that are not defined
yet. For example, it could be used to derive additional keying
material for purposes such as fast handoff, man-in-the-middle
vulnerability protection, etc."

to:

"Extended Master Session Key (EMSK)
Additional keying material (64 octets) derived between the EAP
client and server that is exported by the EAP method. The
EMSK is known only to the EAP peer and server and is not
provided to a third party."

In Section 3.5, delete:

"As noted earlier, the discovery phase (phase 0) may be insecure so that
in order to prevent spoofing of discovery packets, the secure
association (phase 2) protocol should support the secure verification of
discovered capabilities, including ciphersuites and other security
parameters. This is more scalable than attempting to configure the
supported capabilities on each peer and authenticator and more secure
than unprotected capabilities negotiation."

Move the contents of Section 2.4 to the beginning of Section 4.1.

In Section 4.1, delete:

"If the authenticator and backend authentication server do not mutually
authenticate, then the peer will be vulnerable to rogue backend
authentication servers, authenticators, or both. If there is no per-
packet authentication, integrity and replay protection between the
authenticator and backend authentication server, then an attacker can
spoof or modify packets in transit."

In Section 4.2.2, change:

"Session Keys
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use session keys, as in Diameter EAP
[DiamEAP] and RADIUS over IPsec [RFC3579], rather than using a
static key, as originally defined in RADIUS [RFC2865]."

To:

"Session Keys
AAA protocols used for transport of EAP keying material MUST
implement and SHOULD use dynamic key management in order to
derive fresh session keys, as in Diameter EAP [DiamEAP] and
RADIUS over IPsec [RFC3579], rather than using a
static key, as originally defined in RADIUS [RFC2865]."

In Section 4.2.2, change:

"Forgery protection
AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators."

To:

"Authorization
AAA protocols used for transport of EAP keying material SHOULD
provide protection against rogue authenticators masquerading as
other authenticators."

In Section 7.1, change:

"[RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol
(EAP)", Internet draft (work in progress), draft-ietf-
eap-rfc2284bis-04.txt, June 2003."

To:

"[RFC2284bis] Blunk, L., et al. "Extensible Authentication Protocol
(EAP)", Internet draft (work in progress), draft-ietf-
eap-rfc2284bis-06.txt, October 2003."

In Section 7.2, delete:

"[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998."

(already listed in Section 7.1)

In Section 7.2, change:

"[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", Internet
draft (work in progress), draft-ietf-aaa-diameter-17.txt,
December 2002."

To:

"[DiamBASE] Calhoun, P., et al., "Diameter Base Protocol", RFC 3588,
September 2003."

In Section 7.2, change:

"[IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD
FOR Telecommunications and Information Exchange between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Specification for Enhanced
Security", August 2003."

to:

"[IEEE80211i] IEEE Draft 802.11I/D6.1, "Draft Supplement to STANDARD
FOR Telecommunications and Information Exchange between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical layer
(PHY) specifications: Specification for Enhanced
Security", August 2003."

Proposed Resolution: Accept

Issue 179: EAP PRF
Submitter name: Uri Blumenthal
Submitter email address: uri@bell-labs.com
Date first submitted: 3/21/2003
Reference:
Document: Keyframe-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Bernard,

I've been told that the issue of pseudo-random function
came up at yesterday's EAP WG, and people were leaning
towards 3DES.

Let me offer a better pseudo-random function - which I
am proposing for IKEv2 as well. It's designed for AES.
3DES would be OK too - though I'd be reluctant to use
a cipher with 64-bit block...

IMHO this pseudo random function is provably secure.

Please let me know what you think.

Thank you!

regards,
Uri.

P.S. I've posted this yesterday to IPsec mailing list,
and after discussion with Matt Blaze and some night
sleep, edited it a little.

This proposal is IPR-free.

PROPOSAL: AES-BASED PSEUDO RANDOM FUNCTION FOR IKEv2.

PRF(S, N)

The goal is to produce requested amount of pseudo
random bits, using AES (or other block cipher) and
variable-length input for both parameters: the secret
one (e.g. DH output) and the one publicly known (e.g.
concatenation of nonces). Should work with variable
key length, preferably support different block sizes.
Preferably, the construct is provably secure.

The following idea is strongly based on Rijndael
Submission Paper to NIST, in particular on their
recommendation for using AES as Pseudo Random
Function. It is assumed that AES is the block
cipher that will be used, but the construct is
generic enough to accomodate other block ciphers.

ALGORITHM: PRF(S, N)

S is secret, N may be known. No assumption on the quality
of randomness is made for either parameter. No limitation
on size of S, N.

Outputs pseudo-random stream of bits in cipher blocksize
chunks (128-bit for AES). Bu default - outputs the number
of bits equal to blocksize. Optionally the amount of
output bits can be specified.

Block cipher is assumed, with key-buffer for key, and
data-buffer for plaintext. AES is a natural choice.

Algorithm:

1. Fill the key-buffer with S. If S is shorter than
the key-buffer, pad the key buffer with zeroes.

2. If any bits of S are left after step (1), place
them in the data-buffer. Append parameter N to
the data-buffer. Pad the data-buffer with zeroes
if necessary, to make it multiple of cipher block
size, and at least as long as key-buffer.

3. Encrypt as many blocks of data-buffer as necessary
to fill key-buffer.

4. Take the output of (3) and fill the key-buffer.
Continue (3) and (4) for the reminder of the
data-buffer.

5. At this point the encryption engine is ready to produce
Pseudo-Random stream. Now run the encryption engine in
OFB mode (starting with input buffer filled with zeroes)
using the full block size, until the desired amount of
output bits is produced.

RATIONALE.

a. Encryption engine is keyed with secret parameter because
all the theory of block cipher security is based on the
assumption that it is the key which is unknown to the
attacker. No analysis exists (as far as I know) for the
case when the key is known, but the plaintext and/or
ciphertext aren't.

b. Changing the key at step (4) mitigates the Related Keys
attack.

c. OFB mode in step (5) allows producing [practically] any
amount of output bits, much larger than the cipher block
size.

SECURITY PROPERTIES.

A block cipher being a Pseudo Random Permutation, if the
S parameter is secret, the following hold true:

- output of (3) is pseudo-random.
- output of (5) is pseudo-random.

CONSIDERATIONS.

Security of this PRF is based on two assumptions: (a) block
cipher used is not broken, and (b) the secret parameter is
unknown to the attacker. However if a weak secret - such
as a short passwod - is used for parameter S, then it
is possible to break this algorithm by dictionary
attack. Note that this vulnerability exists in
HMAC as well, and is unavoidable (unless one
uses protocols such as PAK, EKE/SPEKE, etc).

DESIGN ALTERNATIVE.

Instead of zeroizing the data-buffer in the step (5),
one can leave it as is, effectively filled with the
new key. Cryptographic property of this is one-way-ness,
as it is impossible to invert E{K}K not knowing the key.
Whether this is a desired property, is left for the
discussion.

[Florent Bersani] Browsing through the list of open issues on the EAP Keying Framework, I
came across yours about the proposed AES-based EAP PRF.

Taking into account the discussions on the IPsec mailing list (see
http://www.sandelman.ottawa.on.ca/ipsec/2003/03/msg00294.html for the
beginning of the thread) and the CFRG mailing list (see
http://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00161.html
for the beginning of the thread) where renowned cryptographers (Hugo
Krawczyk and Dave Wagner) made some good points IMO, I suggest this
issue be rejected for two reasons:

First, it is not for now IMHO within the scope of the EAP Keying
Framework to define such a mechanism ("Algorithms for key derivation or
mechanisms for key transport are not specified in this document." as of
version 02b);

Second, as stated above, your proposal did not (yet ;-)) reach
consensus within the cryptographic community.

P.S: I absolutely do not mean that such a proposal is not interesting:
on the contrary, I think it very valuable to suggest secure key
derivation functions (or PRNGs) based on frequent primitives (such as
AES)... Indeed, I am currently working on a survey/further analysis of
the existing schemes. If you want to follow this discussion off-line or
on the CFRG (I do not think it belongs to the EAP mailing list), you
are most welcome!

Proposed resolution: Reject

Issue 180: Conversation Overview
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: October 14, 2003
Reference:
Document: Keying framework
Comment type: T
Priority: 1
Section: 1.3, 1.4
Rationale/Explanation of issue:

Here is a proposed replacement for section 1.3 of the
keying framework (note that this will most likely be
revised during/after the interim meeting).

1.3. Conversation Overview

   Where EAP key derivation is supported, EAP authentication is
   typically a component of a four phase exchange:

      Discovery (phase 0)
      EAP authentication (phase 1a)
      Access authorization (phase 1b)
      Service authentication (phase 2)

   In the discovery phase (phase 0), the parties locate and
   contact each, and then exchange some information about the
   service to be provided. For instance, one of the parties may
   indicate its willingness to provide a service (and to perform
   the EAP authenticator role), and the other party requests
   access to that service (assuming the EAP peer role).

   Next, the EAP peer and backend authentication server
   authenticate each other (phase 1a) and derive a shared
   session key (later called Authorization Key). In this phase,
   the authenticator just forwards EAP packets between the peer
   and backend authentication server (note that in some cases,
   the authenticator and backend authentication server can be
   colocated in the same physical node). This feature of EAP
   enables deployment of new authentication methods without
   requiring development of new code on the authenticator.

   Partially overlapping with this exchange is a second exchange
   (phase 1b), between the authenticator and the backend
   authentication server. In this exchange, the authenticator
   and backend authentication server authenticate each other
   (using some other mechanism than EAP), and authenticator
   sends information about the service requested by the peer
   (typically inside some AAA protocol attributes). When the
   phase 1a has finished, the backend authentication server
   sends the authenticator information about whether the service
   should be provided or not, a key for protecting service
   communication (Authorization Key), and optionally more detailed
   instructions about the service to be provided.

   After both phases 1a and 1b are complete, the authenticator
   signals the peer it will allow access to the service (phase
   2). Next, the peer and authenticator typically exchange more
   parameters about the service to be provided (most likely some
   were already exchanged during phase 0), protect at least some
   of these parameters using the Authorization Key, and agree
   about keys used to protect subsequent communication. The goal
   is to ensure that an attacker not knowing the Authorization
   Key cannot modify the protected parameters or calculate the
   keys that will be subsequently used.

   The phases and the relationship between the parties is
   illustrated below.

   EAP peer                 Authenticator              Auth. Server
   --------                 -------------              ------------
     <---------------------------->
          Discovery (phase 0)
     <------------------------------------------------------>
                     EAP authentication (phase 1a)
                                  <------------------------->
                                Access authorization (phase 1b)
     <---------------------------->
     Service authentication (phase 2)

1.3.1 A concrete example: IEEE 802.11i ESS

   (Details to be added; this is just a sketch)

   o Phase 0: Typically, the client (peer) discovers the access
      point (authenticator) by listening to Beacon messages, and
      requests access by sending an Assocation Request
      message. The service parameters exchanged in phase 0
      include the SSID, data rates, supported ciphersuites, hop
      patterns (and other PHY parameters).

      The AP initiates phase 1a by sending an EAP Identity
      Request, encapsulated inside an EAPOL frame (though in
      some cases, the AP requests the backend authentication
      server to send this).

   o In phase 1a, the client and backend authentication server
      authenticate each other. For instance, if EAP-TLS is used,
      they both exchange certificates, verify that the certificates
      are valid and belong to the expected party, and prove
      that they know the corresponding private keys. This exchange
      also generates a shared key between them.

   o Phase 1b typically uses RADIUS. The RADIUS packets are
      authenticated either with RADIUS's own shared secret
      mechanism (Message-Authenticator), or IPsec. The access
      point sends an Access-Request message containing various
      service parameters (such as Service-Type,
      Calling-Station-Id, and Called-Station-Id). When phase 1a
      has finished, the backend authentication server gives
      permission for the service (Access-Accept), and sends
      e.g. Authorization Key and Session-Timeout.

   o Phase 2 includes the four-way handshake and group key
      handshake. These exchanges protect various service parameters
      (MAC addresses, RSN IE, selected ciphersuite) and produce
      keys for encrypting the actual traffic.

   After phase 2, the parties protect the 802.11 data frames
   with TKIP or CCMP (basically, encryption and MAC using the
   keys negotiated in phase 2, and sequence numbers for replay
   protection).

1.3.2 Second example: IKEv2/IPsec

   This example assumes a "road warrior VPN gateway" type
   situation where the IKEv2 SA is authenticated solely using
   EAP (no certificates are necessary).

   o Phase 0: IKEv2 doesn't usually use "discovery" in strict
      sense; instead, the client (initiator) is configured with
      the IPsec gateway's address or DNS name. The client
      contacts the gateway and they exchange Diffie-Hellman
      parameters, nonces and select an IKEv2 ciphersuite. The
      client also indicates the willingness to use EAP by
      leaving out the AUTH payload from the third message.

   o Phase 1a is similar as above (although it is likely
      that some other EAP method than EAP-TLS would be used).

   o Phase 1b is also very similar. Although no "RADIUS
      guidelines for IKEv2" document exists yet, RADIUS could be
      used with very small modifications (perhaps a new value
      for Service-Type and agreement about what to put in
      Calling-Station-Id/Called-Station-Id attributes).

   o Phase 2: In this phase, the client and the gateway
      authenticate the IKEv2 SA by using Authorization Key to
      compute a MAC of the Diffie-Hellman parameters and nonces
      (and some other information) exchanged in phase 0. This
      implicitly protects other parameters and the rest of the
      conversation as well. The service parameters negotiated
      next include details about client IP addresses, what IP
      traffic will be protected, what ciphersuites will be used,
      and so on.

   After this, the traffic is typically protected with ESP or AH.

1.3.3 Repeating the conversation

   There are several reasons why a service might require new
   phase 1a/1b conversation.

   o The service may require periodic reauthentication (and
      reauthorization): A new phase 1a/1b is used to check that
      the client still has the correct credentials, and the
      authorization granted by the backend authentication server
      is still valid.

   o Service parameters may have changed in a way that requires
      new authorization granted by the backend authentication
      server.

      For instance, suppose that the peer is allowed WLAN access
      with 802.11g physical layer; is the user allowed to switch
      to 802.11b? In this case, the answer is most likely
      yes--the backend authentication server isn't concerned
      with such small details. The peer and authenticator can
      negotiate this change in service parameters without having
      a new phase 1a/1b exchange.

      However, if the user is accessing SSID "Joe's HotSpot",
      does this authorization also give access to SSID "Example
      Inc. Intranet"? Most likely no--this is a detail the
      backend authentication server would like to know about.

      Depending on the service, there are service parameters
      between these two extremes: some of them matter when
      authorizing access, some are small details that can be
      negotiated freely between the peer and the authenticator.
      See Section X.X for more discussion about the authorization