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 method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| ! | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| 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:
"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.
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| 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 | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | | | | | ! |
|EAP !Layer| | EAP Layer | EAP Layer | |EAP !Layer|
| ! | | +-----+-----+ | | ! |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|Lower!Layer| |Lower!Layer| AAA ! /IP | | AAA ! /IP |
| ! | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-!-+-+-+-+-+-!-+-+-+ +-+-+-!-+-+-+
! ! ! !
! ! ! !
+-------->-----+ +------->------+
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