Issue 1: EAP NAK Allows only one alternative
method
Submitter: David Reeder
Submitter email address:
dreeder@flarion.com
Date first submitted: March 7, 2002
Reference:
http://mail.frascone.net/pipermail/eap/2002-March/000076.html
Document:
RFC2284bis-02
Comment type: T
Priority: 2
Section:
5.3
Rationale/Explanation of issue:
David Reeder notes:
"Would it be conveient for the NAK (Section 5.3) to return an
ordered list of authentication types, instead of just one? Thus
both the Peer and Authenticator have more choice as the list of
authentication types grows. The list might provide an indicator
of
security/access policy -- eg, specify a list such as: #1 IKE, #2
OTP, #3 MD5-Challenge. The Authenticator could
immediately
downgrade to #3 if it is too busy and SLA with the Peer
allows it."
Bernard Aboba notes:
If the server supports a large number of methods, then it may take a long time to converge on a method that the client can also support. Convergence will be quicker if the client can NAK with a list of methods that it supports, so that the server can pick one.
Note: before making this change, it will be necessary to determine whether existing EAP implementations are backwards compatible with the change. This should be true if the implementations only look at the first type within the NAK, but are "liberal in what they accept" and don't drop the NAK entirely due to its being too large.
Change:
"Length
5 or 6
.... This field MUST contain a single octet indicating the
desired
authentication type."
To:
"Length
>=5
...This field contains zero or more octets indicating the acceptable authentication types, in order of preference."
[BA]
This change seems simple enough on its face, but it adds
significant
complexity when combined with Type Extension (see Issue 41).. For
example, within a
NAK it would be necessary to support a mixture of Extended
and non-Extended
Types. As a result, the recommended resolution to Issue 41
includes a reversal of this change.
Issue 2: Alternative indications not well
defined
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 25,
2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority:
S
Section: 2.1, 3.2.1, 3.3.1, 3.3.2, 4.2
Rationale/Explanation of
issue:
The EAP Implementation Survey results disclose that alternative indications are not being implemented. In addition, alternative indications are not described in enough detail to be interoperable. What is an alternative indication, exactly? It would appear that alternative indications are not available on every media, and also that they increase the ability of an attacker to spoof packets.
[BA] Question - are method-specific success and failure indications "alternative indications" in this context? If so, how do existing implementations process them?
Changes:
Delete sections 3.2.1, 3.3.1 and 3.3.2. Change the following text in section 4.2 from:
"Implementation Note: Because the Success and Failure packets are
not
acknowledged, they may be potentially lost. A peer SHOULD
allow for this
circumstance, by taking alternate indications of
Success and Failure into
account. The alternate indications are
media-specific, and are described in
section 3."
To:
"Implementation Note: Because the Success and Failure packets are
not
acknowledged, they may be potentially lost."
Recommendation of EAP Design Team, 10/30/02:
EAP needs to deal with link-specific failure and success
indications.
Depending on the medium, link-specific
indications may be subject to
spoofing, or
protected by a link layer ciphersuite.
In PPP, the
following indications are subject to spoofing:
LCP-Terminate (a failure
indication) and NCP
(a success indication). In PPP, "link down" is
considered reliable.
In 802.11, the following are failure indications
which can be spoofed:
Disassociate, Deauthenticate. In
802.1X,
EAPOL-Logoff constitutes a spoofable failure indication.
In
802.11, "link down" is unreliable unless damped,
since wireless signal
strength can come and go.
Within EAP, success and failure indications
may
be protected or unprotected. EAP Success and Failure are
unprotected
indications. Issue 26 deals with protected success/failure
indications..
The recommendation is as follows:
Where a protected
success/failure indication has been received
an EAP peer MUST accept and
process the protected indication.
Subsequent unprotected indications MUST be
silently discarded
if they contradict the protected indication.
The
reliability and security of link layer indications is
dependent on the
medium. Link layer indications provided
to EAP MUST be processed.
In
the absence of a protected indication, unprotected failure
indications MAY
be accepted and processed by the
EAP implementation. This can result in a
denial of service
attack.
Unprotected success indications are only
accepted and processed
once methods have completed successfully.
Insert Section 2.1:
"Success and failure indications
Within EAP, success and failure
indications may
be protected or unprotected. EAP Success and Failure messages
are unprotected indications which may be spoofed, since they are sent in
cleartext and
contain no embedded message integrity check. However,
individual
EAP methods may include support for acknowledged and protected
success and failure indications.
Where a protected success/failure
indication
has been received at the EAP layer by an EAP peer,
it MUST
accept and process the protected indication.
Subsequent unprotected success
or failure EAP layer
indications MUST be silently discarded by the peer if
they
contradict the protected indication.
For example, if the Peer is
configured to require an EAP method providing
mutual authentication, then it
MUST silently discard a Success packet
sent by the Authenticator, prior to
the conclusion of mutual authentication.
In the absence of a protected
EAP layer indication, unprotected
EAP layer failure indications MAY be
accepted and processed by the
EAP implementation. This can result in a denial
of service
attack.
Unprotected EAP layer success indications are only accepted and
processed
once methods have completed successfully.
Whether
authentication is mandatory is determined by the
Authenticator and Peer
configurations. If authentication
is not required by the Authenticator, or if
the identity of the Peer is verified
by another mechanism (e.g.
Calling-Station-ID or MAC address),
then the Authenticator MAY send a
"canned" Success message.
However, the Peer may be configured to
require
the Authenticator to authenticate itself prior to
being willing to process a
Success message."
Insert Section 3.4 :
Link layer indications
The reliability and security of link layer
indications is
dependent on the medium. Link layer failure indications
accepted by
the link layer and provided to EAP MUST be processed. However,
as
described in Section 2.1, only
EAP layer success/failure indications
(not link layer
success indications) can cause
an EAP implementation to
conclude that authentication has succeeded.
In PPP, link layer
indications are not authenticated.
They are therefore subject
to
spoofing. This includes LCP-Terminate (a link failure indication)
and
NCP (a link success indication). In PPP, a "link down" indication
is
considered a reliable indication of link failure.
In 802.11, control and
management frames are not authenticated
and are therefore subject to
spoofing. This includes Disassociate
and Deauthenticate frames (link failure
indications), and
Association and Reassociation Response frames (link
success
indications).
In IEEE 802 wired networks, the IEEE 802.1X
EAPOL-Start and
EAPOL-Logoff frames are not authenticated,
whereas
within 802.11, authentication is possible depending on when
they are sent and
the ciphersuite that has been negotiated.
Therefore, depending on the
circumstances, EAPOL-Start and
EAPOL-Logoff frames may or may not be subject
to spoofing.
In 802.11 a "link down" signal is considered an unreliable
indication
of link failure, since wireless signal strength can come and
go."
Issue 3: EAP needs a formal state
machine
Submitter: Brian Payne
Submitter email address:
bdpayne@cs.umd.edu
Date first submitted: March 13, 2002
Reference:
http://mail.frascone.net/pipermail/eap/2002-March/000080.html
Document:
RFC2284bis-02
Comment type: T
Priority: S
Section:
2.1
Rationale/Explanation of issue:
RFC 2284 does not include a state machine description. This makes it difficult to understand how the protocol works.
Brian Payne notes:
"One thing is worth noting, the extensible part of EAP is a tricky thing
to
capture in a state machine. I think that we've found a decent way
to
represent this, but we are open to comments."
Resolution: Discuss
Requested change:
Incorporate the state machine described in
http://www.cs.umd.edu/~bdpayne/papers/eap.txt
Issue 4: EAP multiplexing model not
described
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 25,
2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority:
S
Section: 5
Rationale/Explanation of issue:
Several EAP methods have attempted to send data to an EAP method using Identity, NAK, Notification, Success or Failure messages. This won't work because EAP multiplexing only delivers data to an EAP method if an EAP Type field is included within the message, and Type=X where X is the type of the method to which the message is addressed.
Resolution: Accept
Add the following text to Section 2.1:
"Within EAP, the Type functions much like a port number in UDP or TCP.
EAP
implementations multiplex incoming EAP messages according to their Type,
and
deliver them to the appropriate EAP method. EAP Requests addressed to a
Type
that is not installed on the peer elicit a NAK message in response.
EAP
Responses sent to a Type that is not installed on the server are
silently
discarded by the server. EAP messages sent with command codes of
Success or
Failure are processed by the EAP implementation; these messages
cannot carry
data, so they are not delivered to an EAP method. Similarly,
EAP messages of
Types Identity, NAK, and Notification are assumed to be
handled by code within
the EAP implementation that is specific to those
Types. As a result, these messages
MUST NOT be used to carry data destined
for delivery to other EAP methods."
Issue 5: Editorial changes to section
4.2
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 25,
2002
Reference:
Document: RFC2284bis-02
Comment type: E
Priority:
S
Section: 4.2
Rationale/Explanation of issue:
The format of the Success packet is not described.
Resolution: Accept
Change:
"A summary of the Failure packet format is shown below. "
To:
A summary of the Success and Failure packet formats is shown below."
Issue 6: No IANA considerations
section
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 2,
2002
Reference:
Document: RFC2284bis-01
Comment type: T
Priority:
S
Section: 6
Rationale/Explanation of issue:
RFC 2284 does not have an IANA considerations section.
Resolution: Accept
Section 6 added to RFC 2284bis-02.
Issue 7: Ability to authenticate with multiple
methods one after another not specified
Submitter: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
March 2, 2002
Reference:
Document: RFC2284bis-01
Comment type:
T
Priority: S
Section: 2
Rationale/Explanation of issue:
RFC 2284 does not explain how to authenticate with multiple authentication methods one after another.
Resolution: Discuss
RFC 2284 does not explain how to authenticate with multiple
authentication methods one after another, and what restrictions
this
imposes on the EAP methods and implementations.
Existing EAP methods do
not support authentication sequences
so that if a server requests a sequence
of methods,
authentication will fail. Since EAP does not have a
version
field, it is not clear how a server can determine that the
client
supports sequences. Therefore it would appear that
sequences cannot be
enabled by default.
Also, sequences introduce vulnerabilities to
man-in-the-middle
attacks, so that it is necessary to demonstrate that the
endpoints have remained the same throughout the conversation.
Add
the following text to Section 2:
"An Authenticator MAY authenticate the
Peer using a sequence of methods,
only if it can determine that the Peer
supports sequences. Since
existing EAP implementations do not support
authentication sequences,
they can be enabled by the Authenticator only when
it can be determined
that the Peer supports this features. Sequences MUST NOT
be enabled by default.
To execute an authentication sequence, the
Authenticator and Peer first
complete an EAP exchange involving the initial
method, with a matching
EAP type field included in both Request and Response
packets.
If the initial authentication method completes unsuccessfully,
then the
Authenticator sends a Failure packet to the peer. If it
completes
successfully, and additional authentication methods are required,
the
Authenticator will send a Request packet for a
subsequent
authentication method. The Peer will then respond with a Response
packet
containing a type field matching the Request.
The sequence of
authentication methods proceeds until either an
authentication method fails
(in which case the Authenticator sends a
Failure packet to the peer) or the
final authentication method completes
successfully, in which case the
Authenticator sends a Success packet to
the peer.
Note that not all
methods are suitable to being run within a sequence.
In order to allow
another method to be run after it, a method MUST
conclude with an EAP
Response packet. This is necessary because EAP
is an ACK/NAK protocol, and an
EAP Request will be sent to begin the
next method; without an previous EAP
Response this is not possible.
In addition, in order to prevent
man-in-the-middle attacks, it is
necessary to provide assurance that the
endpoints have remained the
same during the conversation. This can
be
demonstrated by exchange of a compound MAC and derivation of a
compound encryption key."
Comment by Bryan Payne:
> > The
state machine allows the authenticator to send a new ID request before
>
> each Auth request if it wants to. This is because each auth request
may
> > be associated with a different identity.
>
> Only
if the Type code changes, right?
Ahh yes, I'm glad that you brought this
up. I can't find anything about
this in the RFC. The closest thing that I can
find is in "step 1" of
section 2 (2284bis-03) where it is giving an overview
of the protocol.
So the answer to your question is "I don't know". There
is no mention of
the ID request only being allowed at this point in time. As
I read the
RFC, the authenticator could send identity requests over and over.
Yes,
this would be pointless...and that's why Nick and I drew the state
machine
to at least require ID, Auth, ID, Auth requests or Auth, Auth, ID,
Auth,
etc (because ID, ID, ID just doesn't make sense). Basically, I think
that
it makes sense to say that all ID requests will be followed by an
auth
request...and that ID requests are not required. I feel that this
is
captured in the state machine pretty well.
Perhaps the RFC should
be more specific in dealing with this issue?
-bryan
Notes from Bernard Aboba:
Yet another question has arisen as to what
happens when, in
the middle of one EAP method, a Peer receives a Request
for
a completely different EAP method. Does it silently discard
the
packet? Call the new EAP method while leaving the
old one suspended? Nak the
new method with the Type of
the previous one? Is this illegal?
Also, are
there some methods which must be the last method
in a sequence? For example,
what if the last packet sent
within a method is not an EAP Success/Failure,
but an
EAP Request (say, encapsulating an encrypted Success/Failure).
How
can another method come after that one, since there will
be no EAP Response
to continue the conversation? And how
can a final EAP Success/Failure ever be
sent?
Recommendation of EAP Design Team, 10/30/02:
It is feasible to add support for sequences to EAP without
worrying about
backward compatibility, assuming that
an Authenticator requires that the peer
execute a sequence of
EAP methods in order to be authenticated. If the peer
cannot
successfully execute that sequence, it will not be
authenticated.
If this can be assumed, then the Authenticator
can
prompt the peer for the sequence of EAP methods without
first determining
that the peer supports sequences. If the
peer does not support sequences,
then it will either respond
with a NAK (the preferred behavior) or will not
respond to
subsequent methods in the sequence, and authentication will
timeout.
Therefore it is not necessary to negotiate sequence usage
in the
beginning of the conversation, since that would add a
round-trip
both where the peer supports sequences, and
when it does not.
Simply
allowing the Authenticator to request a sequence does
not add a round-trip in
the case where the Peer supports
sequences.
Add the following text to section 2:
"If the Peer does not support sequences, it SHOULD
respond to the
additional Request with a Nak, and no alternative method.
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 authentication sequence in order to grant
access,
authentication failure is the intended result. Therefore, it is
not
necessary for the Authenticator to determine that the peer
supports
sequences prior to prompting for an additional
authentication method."
Issue 8: Support for Vendor-Specific
Types
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 2,
2002
Reference:
Document: RFC2284bis-01
Comment type: T
Priority:
S
Section: 5.5
Rationale/Explanation of issue:
RFC 2284 does not support vendor-specific EAP types.
Add the following text to Section 5.5:
"5.5. Vendor-specific
Description
Due to EAP's popularity, the
original Method Type space, which only
provides for 255 values, is being
allocated at a pace, which if
continued, would result in exhaustion within a
few years. Since many
of the existing uses of EAP are vendor-specific, the
Vendor-Specific
Method Type is available to allow vendors to support their
own
extended Types not suitable for general usage. The
Vendor-specific
Type may also be used to expand the global Method Type space
beyond
the original 255 values.
Peers not equipped to interpret the
Vendor-specific Type MUST send a
NAK, and negotiate a more suitable
authentication method.
A summary of the Vendor-specific Type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Vendor-Id
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
255
for Vendor-specific
Vendor-Id
The Vendor-Id is 3 octets and
represents the SMI Network Management
Private Enterprise Code of the Vendor
in network byte order, as
allocated by IANA. A Vendor-Id of zero is reserved
for use by the
IETF in providing an expanded global EAP Type
space.
String
The String field is one or more octets. The actual
format of the
information is site or application specific, and a
robust
implementation SHOULD support the field as undistinguished
octets.
The codification of the range of allowed usage of this field
is
outside the scope of this specification.
It SHOULD be encoded as
follows. The Vendor-Specific field is
dependent on the vendor's definition of
that attribute. An example
encoding of the Vendor-Specific attribute using
this method follows.
Example Implementation
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Vendor-Id
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
The
Vendor-Type field is four octets and represents the vendor-
specific Method
Type. Where a Vendor-Id of zero is present, the
Vendor-Type field provides an
expanded global EAP Type space,
beginning with EAP Type values of
256.
Vendor-Specific
The Vendor-Specific field is dependent on the
vendor's definition of
that attribute. Where a Vendor-Id of zero is present,
the Vendor-
Specific field will be used for transporting the contents of
EAP
Methods of Types 256 or greater.
Resolution: Accept
Issue 9: Support for Method Type
Expansion
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 2,
2002
Reference:
Document: RFC2284bis-01
Comment type: T
Priority:
2
Section: 6.2
Rationale/Explanation of issue:
RFC 2284 only has 255 method types available. Expanded Type space support would be useful.
Add the following text to section 6.2:
"When used with a Vendor-Id of zero, Method Type 255 can also be used
to
provide for an expanded Method Type space. Expanded Method Type
values
256-4294967295 may be allocated after Type values 1-191 have
been
allocated."
Resolution: Accept
Issue 10: No support for Acknowledged Success and
Failure
Submitter: Simon Blake-Wilson
Submitter email address:
sblakewilson@certicom.com
Date first submitted: February 21,
2002
References:
http://mail.frascone.net/pipermail/eap/2002-February/000015.html
http://mail.frascone.net/pipermail/eap/2002-February/000025.html
http://www.ietf.org/internet-drafts/draft-hiller-eap-tlv-00.txt
Document:
RFC2284bis-02
Comment type: T
Priority: S
Section:
5
Rationale/Explanation of issue:
"Specifically, since EAP-Success is not
ACK'ed, how can it be relied upon to indicate
things like "auth successful,
go ahead and send packets"? It seems to me that the
NAS has to tell the
client that auth is successful via some other method ... at
the moment the
status quo seems to be to use a timer and start sending packets
if you don't
see EAP-Success before the timer expires, or watch for packets to
arrive and
decide auth must have been successful if you see packets. As EAP gets
used
for more stuff, I think this needs to get pinned down. If I remember correctly,
802.1x makes a mistake like this and relies on EAP-Success being delivered
successfully in several of the state machines."
-- Simon Blake-Wilson
Additional discussion:
Date: Thu, 28 Mar 2002 00:48:13 -0500 (EST)
From: Bryan D. Payne
<bdpayne@cs.umd.edu>
To: Bernard Aboba
<aboba@internaut.com>
Cc: eap@frascone.com
Subject: Re: [eap] Issue
#3: No state machine
> > Issue #10 doesn't indicate what happens if
the peer replies with a failed
> > outcome message. What state does
this leave the authenticator in? And,
> > if it just restarts the
process, then what guarentees that we don't just
> > cycle through over
and over?
>
> Well, since you raised the issue at the EAP BOF, do
you want to hazard a
> guess about what should happen?
Ok, a couple
of comments on that:
* Making the Acknowledged Termination simply another
type of
request/response will make it very difficult to depict properly in
the
state machine. I feel that this implies some ambiguity that should
be
avoided. For this reason, I suggest that we create an additional
EAP
packet type (in Section 4 of 2284bis-03) for these
ackknowledged
terminations...
* Assuming the above, when the
authenticator sends an acknowledged
termination packet it can move into a
success or failure state in
accordance with the data in it's packet.
*
If the peer's reply agrees with the authenticator, then all is well.
The peer
moves into the appropriate state and the authenticator stays
where it
was.
* If the peer's reply does not agree with the authenticator, then
everyone
should move back to the unauthenticated state (I propose this
instead of
initialization state b/c the policy should not be re-initialized
at this
point). The authenticator and peer should then try to complete
the
protocol from there.
The main problem with the above (that I see
right now) is that the server
an authenticator could have policies that would
never result in an
authentication that both parties are happy with (e.g., the
authenticator
uses a "canned success" and the peer wants mutual auth). For
this reason,
we will need a counter to ensure that the peer and authenticator
don't
loop forever. If the counter expires, then everyone should return to
the
initialization state.
I'm open to ideas / changes / etc. This is
just my first thoughts on this
matter..."'
Comment from Bernard Aboba:
"The problem with new packet types is that they will be silently discarded
by
existing implementations, whereas a new method can be NAK'd by those
that
don't understand it, enabling backwards compatibility.
Since the
Peer will discard an EAP packet with a Command Code it doesn't
recognize, the
NAS will not transmit another Access-Request to the AAA
server. Since in
RADIUS the AAA server can't initiate messages on its own,
this means that the
conversation stalls; there is no way for the server
to just send an EAP
Success/Failure after a timeout. As a result, I don't
think that the new
Command Code approach can work."
Recommendation of EAP Design Team, 10/30/02:
Acknowledged success and failure indications, where implemented
as an EAP
method, require support for sequences. As discussed in
Issue 7, it is not
recommended that sequence negotiation be
added to EAP. Therefore if an
Acknowledged Success/Failure
indication is sent to a client that does not
support it, it
is likely that the client will either NAK or not respond,
causing a timeout.
Therefore, in order to maintain backward
compatibility,
acknowledged success and failure indications may only
be
sent by the Authenticator when the Peer is known to
support them. This
occurs where a sequence of methods has
already been completed or where a
method has been
negotiated that supports acknowledged success and
failure
indications.
Issue 11: No threat model
Submitter: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
March 25, 2002
Reference:
Document: RFC2284bis-02
Comment type:
T
Priority: S
Section: 9
Rationale/Explanation of issue:
The RFC 2284bis does not include a threat model in the security considerations section.
Security considerations section rewritten in RFC2284bis-04.
Resolution: Accept
Issue 12: No support for
localization
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 25,
2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority:
2
Section:
Rationale/Explanation of issue:
RFC 2284bis does not include support for localization.
UTF-8 now required in displayable messages (RFC2284bis-04)
Resolution: Accept
Issue 13: Identifier usage not
specified
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 25,
2002
Reference:
Document: RFC2284bis-02
Comment type: T
Priority:
1
Section: 4.1
Rationale/Explanation of issue:
RFC 2284 specifies only that retransmitted EAP-Requests MUST contain the same Identifier value. It does not provide any guidance on whether the Identifier value can repeat within an EAP conversation.
Resolution: Discuss
Change:
"Retransmitted Requests MUST be sent with the same Identifier value
in
order to distinguish them from new Requests. Note that the
Identifier
field need only be unique on a per-port basis, so that
Authenticators
are not restricted to only 255 simultaneous
authentication
conversations."
To:
"Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. In order to avoid confusion between new requests and retransmissions, the Identifier value chosen for each new Request MUST be unique within the EAP conversation. If the Authenticator receives an EAP-Response with an Identifier different from the one within the last EAP-Response that it sent on that port, then the messages is silently discarded. Note that the Identifier field need only be unique on a per-port basis, so that Authenticators are not restricted to only 255 simultaneous authentication conversations."
Notes from Bernard Aboba:
Still more to do here, I think. Does the Identifer start at 0? Is it incremented with each new Request? Is duplicate elimination done before or after packet validation?
Recommendation of EAP Design Team, 10/30/02:
The recommended text does not mandate too much, but specifies enough. Leave it alone.
Issue 14: EAP transport behavior not
specified
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 25,
2002
Reference:
Document: RFC2284bis
Comment type: T
Priority:
1
Section: 4.1
Rationale/Explanation of issue:
RFC 2284 does not adequately specify EAP's transport behavior. The EAP implementation survey results indicate that implementations do not use the default retransmission timer of 6 seconds as specified in RFC 2284. In fact, much lower values are often used, sometimes so low that the EAP-Request can be retransmitted prior to arrival of the EAP-Response. This causes problems if the NAS sends a duplicate AAA Request as a result. Similarly, when EAP is run over reliable transport (such as within PIC, which can run over ISKAMP/TCP), it is possible for retransmissions to occur at multiple layers of the stack.
Resolution: Accept
Change:
"Implementation Note: Because the authentication process will
often
involve user input, some care must be taken when deciding
upon
retransmission strategies and authentication timeouts. For use
in
PPP, it is suggested a retransmission timer of 6 seconds with a
maximum
of 10 retransmissions be used as default. One may wish to
make these timeouts
longer in certain cases (e.g. where Token
Cards are involved). Additionally,
the Peer must be prepared to
silently discard received retransmissions while
waiting for user
input."
To:
" Implementation Note: Because the authentication process will
often
involve user input, some care must be taken when deciding
upon
retransmission strategies and authentication timeouts.
By
default, where EAP is run over an unreliable lower layer,
the EAP
retransmission timer (EAP_RTO) SHOULD be computed as
described in [RFC2988].
A maximum of 3-5 retransmissions is suggested.
When run over a reliable
lower layer
(e.g. EAP over ISAKMP/TCP, as within [PIC]), the EAP
retransmission timer
SHOULD be set to an infinite value, so that
retransmissions do not occur
at the EAP layer.
Where the
authentication process requires user input,
the measured round trip times are
largely be determined by user
responsiveness rather than network
characteristics,
so that RTO estimation is not helpful.
Instead, the
retransmission timers SHOULD be set so as to provide
sufficient time for the
user to respond, with longer timeouts
required in certain cases, such as
where Token Cards are involved.
In order to provide the EAP authenticator
with guidance as to the
appropriate timeout value, a hint can be communicated
to the
Authenticator by the backend authentication server (such as via the
RADIUS Session-Timeout attribute).
Additionally, the Peer MUST be
prepared to
silently discard received retransmissions while waiting for user
input,
so as to mitigate the ill effects of a too small retransmission
timer."
[BA] Is discarding duplicate EAP-Responses such as good idea? Presumably
with RTO set as above, there should not be many of those. If the NAS
only
checks the Identifier value to determine whether a packet is a
duplicate,
then an attacker spraying Responses at the AP will be able
to prevent
forwarding of a legitimate Response on to the backend
server. Assuming that a
cryptographically protected EAP method
is being used (PEAP, TTLS, etc.) the
backend server will then be
able to determine that the packet is forged and
silently discard
it.
Answer: duplicate Response elimination is ok.
Issue 15: Key Distribution
Insecure
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: March 2, 2002
Reference: http://www.drizzle.com/~aboba/AAA/issues3.html#Issue%20294
Document:
Key-Frame-01
Comment type: T
Priority: S
Section: 2.4.2,
2.4.3
Rationale/Explanation of issue:
This issue relates to binding and scope restriction.
[BA] The proposed resolution is as follows:
Add Sections 6.6 and 6.7:
"6.6 Channel binding
It is possible for a compromised or poorly
implemented EAP
authenticator to communicate incorrect information to the EAP
peer
and/or server. This may enable an authenticator to
impersonate
another authenticator or communicate incorrect information
via
out-of-band mechanisms (such as via a AAA or lower layer
protocol).
Where EAP is used in pass-through mode, the EAP peer typically
does
not verify the identity of the pass-through authenticator, it
only
verifies that the pass-through authenticator is trusted by the
EAP
server. This creates a potential security vulnerability, described
in
Section 7.15 of [RFC2284bis].
Section 4.3.7 of [RFC3579] describes how
an EAP pass-through
authenticator acting as a AAA client can be detected if
it attempts
to impersonate another authenticator (such by sending
incorrect
NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865]
or
NAS-IPv6-Address [RFC3162] attributes via the AAA protocol).
However,
it is possible for a pass-through authenticator acting as a
AAA client to
provide correct information to the AAA server while
communicating misleading
information to the EAP peer via a lower
layer protocol.
For example,
it is possible for a compromised authenticator to
utilize another
authenticator's Called-Station-Id or NAS-Identifier
in communicating with the
EAP peer via a lower layer protocol, or for
a pass-through authenticator
acting as a AAA client to provide an
incorrect peer Calling-Station-Id
[RFC2865][RFC3580] to the AAA
server via the AAA protocol.
As noted in
Section 7.15 of [RFC2284bis] this vulnerability can
be addressed by use of
EAP methods that support a
protected exchange of channel properties such as
endpoint
identifiers, including (but not limited to):
Called-Station-Id
[RFC2865][RFC3580], Calling-Station-Id
[RFC2865][RFC3580],
NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865],
and
NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is
possible to match the channel
properties provided by the authenticator via
out-of-band mechanisms
against those exchanged within the EAP
method.
6.7 Key Scoping
A AAA-Key provided by the authentication
server to the
authenticator, is for use only by that authenticator.
While
AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support
mutual authentication between the AAA client and
server, the authentication
is based on the claimed identity
of the AAA client. In the case of RADIUS,
the shared secret
used for authentication is determined by the source
address
of the RADIUS packet. As noted in [RFC3579] Section 4.3.7,
it is
highly desirable that the source address be checked
against one or more NAS
identification attributes so as to
detect and prevent impersonation attacks.
A wide variety of authenticator designs are possible,
including
authenticators comprising a small or large number of virtual or
actual ports;
authenticators supporting multiple
"virtual authenticators"; authenticators
with multiple CPUs
utilizing symmetric multi-processing; clustered
authenticators
supporting load balancing or failover, etc.
Similarly,
a wide variety of peer designs are possible,
including peers supporting
multiple interfaces; clustered
peers, etc.
AAA protocols merely
mutually authenticate the AAA client
and server but do not distinguish
between different authenticator
architectures. By default, the AAA-Key
provided by the AAA server
may be used on an unrestricted basis solely by
the authenticator
receiving the AAA-Key.
This may have some
unexpected consequences. For example,
where a single physical authenticator
can act as multiple
"virtual authenticators", unless each "virtual
authenticator"
identifies itself distinctly to the AAA server, then
a
AAA-Key provided by the AAA server is for use by any
of the "virtual
authenticators".
This enables potential security vulnerabilities.
For
example, an EAP peer could authenticate with the "guest"
"virtual
authenticator" and negotiate a AAA-Key. The
peer could then attempt to use
that AAA-Key to
do a fast handoff to the "Corporate Intranet"
virtual
authenticator within the same physical
authenticator. If the virtual
authenticators do not
identify themselves distinctly to the AAA server,
then
the key cache will be shared in common and the
fast handoff attempt
will be successful.
In order to address this vulnerability,
authenticators
need to cache not only the AAA-Keys, but also the
associated authorizations. This ensures that an
attacker could not obtain
elevated privileges even
if they could authenticate successfully to
another
"virtual authenticator" hosted within the same physical
chassis.
If further protection is required, it is advisable for
the AAA server
to explicitly restrict the AAA-Key
scope by including additional scope
restriction
attributes within the AAA-Token. Examples of
scope restriction
attributesw include:
* Virtual authenticator restrictions.
In the
case of 802.11, this could
involve including a list of authorized
Called-Station-Ids or SSIDs for which the
AAA-Key is valid.
*
Peer restrictions. In the case of 802.11,
this could involve including a list
of
authorized Calling-Station-Ids for which
the AAA-Key is
valid.
Note that in restricting the use of the AAA-Key it
is important
to ensure that the EAP peer can be
made aware of the restriction so that the
peer and
authenticator can behave consistently."
Resolution: Accept
Issue 16: EAP corner conditions
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: March 5, 2002
Reference: http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#300
Document: RFC2869bis
Comment type: T
Priority: S
Section:
2.3
Rationale/Explanation of issue:
This is a placeholder for an issue under consideration in the AAA WG.
Resolution: Discuss
Issue 17: EAP negotiation method
Submitter:
Jacques Carron
Submitter email address: jacques_m_caron@yahoo.com
Date
first submitted: February 24, 2002
Reference:http://mail.frascone.net/pipermail/eap/2002-February/000046.html
http://mail.frascone.net/pipermail/eap/2002-February/000047.html
Document: RFC2284bis-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
There is a need to be able to negotiate capabilities within EAP. It would appear that one way to accomplish this is by creating a new method whose goal is to negotiate capabilities. Capabilities that may be worth negotiating:
a. Language support
b. Protected ciphersuite negotiation
Proposed Resolution: Reject within RFC 2284bis (consider as an Extension)
This should be considered as an extension, not part of RFC 2284bis.
Issue 18: Identifier behavior
details
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 26, 2002
Reference:
http://www.cs.umd.edu/~bdpayne/papers/eap.txt
Document:
RFC2284bis-04
Comment type: T
Priority: S
Section:
4.1
Rationale/Explanation of issue:
The state machine sets the initial Identifier to zero and increments it on each subsequent new Request. Shouldn't RFC 2284bis mandate this behavior?
Resolution: Discuss
Change:
" Retransmitted Requests MUST be sent with the same Identifier value
in
order to distinguish them from new Requests. In order to
avoid
confusion between new requests and retransmissions, the
Identifier
value chosen for each new Request MUST be unique within the
EAP
conversation. If the Authenticator receives an EAP-Response with
an
Identifier different from the one within the last EAP-Response that
it
sent on that port, then the messages is silently discarded. Note
that the
Identifier field need only be unique on a per-port basis, so
that
Authenticators are not restricted to only 255 simultaneous
authentication
conversations."
To:
" Retransmitted Requests MUST be sent with the same Identifier value
in
order to distinguish them from new Requests. In order to
avoid
confusion between new requests and retransmissions, the
Identifier
value chosen for each new Request MUST be unique within the
EAP
conversation. This can be accomplished by setting the initial
Identifier value to zero, and incrementing the Identifier for
each new
Request. If the Authenticator receives an EAP-Response with an
Identifier
different from the one within the last EAP-Response that
it sent on that
port, then the messages is silently discarded. Note
that the Identifier field
need only be unique on a per-port basis, so
that Authenticators are not
restricted to only 255 simultaneous
authentication conversations."
Comment from Bryan:
"...however, the state machine does not do anything with the
initial
Identifier. Furthermore, I'm indifferent on this topic. It seems
like
more of an implementation issue than a state machine issue. If there's
a
reason that the identifier should be included in the state machine,
please
let me know and we can discuss it."
Recommendation of EAP Design Team, 10/30/02:
The recommended text does not mandate too much, but specifies enough. Leave it alone.
Issue 19: User-Name in EAP-RADIUS
Submitter:
Tom Bonacci
Submitter email address: bonacci@ascend.com
Date first
submitted: April 12, 2002
Reference:
Document: RFC2869bis-01
Comment
type: T
Priority: S
Section:
Rationale/Explanation of issue:
Please help clear up an ambiguity:
from RFC 2869:
> In order to
permit non-EAP aware RADIUS proxies to forward the
> Access-Request
packet, if the NAS sends the EAP-Request/Identity, the
> NAS MUST copy the
contents of the EAP-Response/Identity into the
> User-Name attribute and
MUST include the EAP-Response/Identity in the
> User-Name attribute in
every subsequent Access-Request.
1) Is the EAP-Response/Identity (as
concerns 2869), which is required to
be placed into the User-Name attribute,
the entire EAP-Response/Identity
packet including Code, Identifier, Length,
Type, and Type-Data or is it
simply the Type-Data? (If the latter is true,
2869 might more carefully
have been written: "...the NAS MUST copy the
contents of Type-Data from
the EAP-Response/Identity packet into the
User-Name attribute...")
2) RFC 2865 defines the User-Name attribute to
be the triple:
> User-Name (0x01), Length (>3), and String...
RFC
2284 makes no demands upon the contents of Type-Data contained in
an
EAP-Response/Identity. RFC 2284 would seem to allow any data,
including
embedded 0x00's (and, in fact, this might be thought useful by some
EAP
authentication schemes). Does EAP interoperation with RADIUS,
as
defined in 2869, presuppose that the contents of Type-Data within
an
EAP-Response/Identity packet be somewhat well-behaved (i.e. -
a
reasonable string)?
Thanks for any responses.
regards,
Tom
Bonacci
Lucent Technologies/Bell Labs Innovations
Resolution: Accept
Issue 20: Reply-Message or
EAP-Request/Notification attribute within Access-Accept or
Access-Reject
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: April 14, 2002
Reference:
Document: RFC2869bis-01
Comment type: T
Priority: S
Section:
2.5
Rationale/Explanation of issue:
If an EAP-Message/EAP-Request/Notification attribute is sent within an Access-Accept or Access-Reject, then the Peer is likely to reply with an EAP-Response/Notification, and the NAS will pass this back to the RADIUS server as an Access-Request/EAP-Message/EAP-Response/Notification. Since an Access-Accept or Access-Reject terminates the RADIUS conversation, this will be unexpected. The same thing is true of a Reply-Message attribute sent within the Access-Accept or Access-Reject, assuming that we allow a NAS to translate this to an EAP-Request/Notification.
Resolution: Accept
Change:
Add the following text to section 2.5:
The Reply-Message attribute, defined in section 5.18 of [RFC2865],
indicates text which MAY be displayed to the user. This is similar
in
concept to the EAP Notification Type, defined in [RFC2284bis].
However,
during an EAP conversation, the RADIUS server SHOULD encapsulate
displayable
messages within an EAP-Message/EAP-Request/Notification, rather than
within a
Reply-Message attribute.
While a NAS receiving a Reply-Message attribute
within an EAP conversation
MAY copy the value of the Reply-Message attribute
into the Type-Data of an EAP-Request/Notification
and send this to the Peer,
several issues may arise from this:
[1] Unexpected Responses. On receiving an EAP-Request/Notification,
the
EAP Peer will send an EAP-Response/Notification, and the NAS will pass
this
on to the RADIUS server, encapsulated within an EAP-Message
attribute.
However, the RADIUS server may not be expecting an Access-Request
containing
an EAP-Message/EAP-Response/Notification attribute.
For example, consider what happens when a Reply-Message is included
within
an Access-Accept or Access-Reject packet with no EAP-Message
attribute present.
If the value of the Reply-Message attribute is copied into
the Type-Data of an
EAP-Request/Notification and sent to the peer, this will
result in an
Access-Request containing an
EAP-Message/EAP-Response/Notification attribute
being sent by the NAS to the
RADIUS server. Since an Access-Accept or
Access-Reject packet terminates the
RADIUS conversation, such an Access-Request
would not be
expected.
[2] Identifier conflicts. While the EAP-Request/Notification contains
an
an Identifier, a Reply-Message attribute does
not. As a result, a NAS
receiving a Reply-Message and wishing to
translate this to an
EAP-Request/Notification will need to make up an
Identifier. Since the NAS
cannot make assumptions about
how the RADIUS server chooses Identifiers, it
is
possible that the chosen Identifier will conflict with
a value chosen
by the RADIUS server for another
packet within the EAP conversation. As noted
in [RFC2284bis] this
would violate the requirement that Identifier values be
unique within an
EAP conversation.
Multiple EAP-Message
attributes
An Access-Challenge, Access-Accept, Access-Reject
or Access-Request
message MAY contain zero or more EAP-Message
attributes. However, where more
than one EAP-Message attribute
is included, it is assumed that the attributes
are to be
concatenated to to form a single EAP packet. Since EAP
is a
"lockstep" protocol, a new EAP-Request cannot be sent until
an EAP-Response
is received to an outstanding request and
only a single Request can be
outstanding at a given time.
As a result, multiple EAP packets MUST NOT be
encoded within
EAP-Message attributes contained within a single
Access-Challenge, Access-Accept, Access-Reject or
Access-Request
message.
Within an EAP conversation a Reply-Message attribute
MAY be
translated to an EAP-Request/Notification. As a result,
a Reply-Message
attribute MUST NOT be included in a RADIUS message
containing an EAP-Message
attribute. EAP-Message/EAP-Request/Notification
or Reply-Message attributes
SHOULD NOT be included within an Access-Accept or
Access-Reject packet
representing the conclusion of an EAP conversation.
Issue 21: Editorial issues with RFC
2284bis-04
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: E
Priority: S
Section: 2,
2.1, 4.2, 9.1, 9.8
Rationale/Explanation of issue:
Resolution: Accept
Section 2, page 5 says under "Advantages":
The EAP protocol can
support multiple authentication mechanisms
without having to pre-negotiate a
particular one.
Certain devices (e.g. a NAS, switch or access point) do
not
necessarily have to understand each request type and may be able
to
simply act as a pass-through agent for a "back-end" server on a
host.
The device only need look for the success/failure code to
terminate
the authentication phase.
A third advantage of EAP might be
noted. The separation of authentication
from the point of access simplifies
credentials management and policy
decision making.
Section 2, page 5
also says under "Disadvantage":
For use in PPP, EAP does require the
addition of a new authentication
type to PPP LCP and thus PPP implementations
will need to be modified
to use it. It also strays from the previous PPP
authentication model
of negotiating a specific authentication mechanism
during LCP.
Similarly, switch or access point implementations need to
support
[IEEE8021X] in order to use EAP.
A second disadvantage might
be noted. The separation of authentication from
the point of access
complicates the security analysis and, if it is needed,
key
distribution.
This dichotomy between better management and more fragile
security is a
property of all schemes that separate the policy decision point
from the
policy enforcement point, and it would be worthwhile for the text
to
document it, so that the tradeoffs facing us are clear.
Section 2.1
page 6, point (a) has a minor grammar error,
"receives a EAP response"
instead of "an EAP response." I'd love to produce
a document someday that has
only a single grammatical error.
Section 4.2 page 12 has an
implementation note saying
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, and if they are lost, the Peer will timeout
and
retry the authentication.
Sorry for being so obtuse, but I can't
fathom what this is trying to tell
me. I find this text confusing, since the
pages preceeding it carefully
explain that EAP does not permit the Peer to
retry anything, but only to
respond to the EAP Authenticator.
The only
conclusion I can draw is it constitutes a reference to some
unidentified
entity outside of EAP, thus coupling the correct behavior of
EAP to the
containing environment behaving correctly. This sort of coupling
always
deserves examination, especially within a scheme allegedly related
to
authentication.
If that is the correct conclusion, this points to a
design problem within
EAP that we will want to think about more in the long
term, as it could
imply that misbehaving environments (e.g., those partially
controlled by
attackers) might be able to subvert the protocol, regardless of
the quality
of the concrete authentication method. If my surmise is instead
incorrect,
then please help me understand the intended meaning of the
language.
Section 9.1 page 22 spells "omitted" as "ommitted."
The
fifth paragraph of Section 9.8 says:
the session key negotiated between
the Peer and EAP server will
need to be transmitted to the
Authenticator.
The EAP method might very well have to transmit the key
the Peer as well, so
this should be noted.
Issue 22: Issues with mandatory to implement
method
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section:
5.4
Rationale/Explanation of issue:
Here is an example where we should note that using EAP unchanged
can be a
more of a danger than a help in some new environments. Section 5.4
says of
MD5-Challenge on page 16:
All EAP implementations MUST support the
MD5-Challenge mechanism.
While this might make sense for legacy dial-in
environments (does it really?
how many times have you seen someone cable
their PC modem to their
cell-phone in an airport?), it does not for wireless
LANs in particular,
where MD5-Challenge is simply a credentials publication
mechanism when a
password is used, and always subject to man-in-the-middle
attacks, even if a
key rather than a password is somehow used. These problems
should be
explicitly noted, and we need to develop wide understanding of the
problem.
Resolution: Accept
[BA] - While MD-5 is mandatory-to-implement, this doesn't mean it
is
appropriate to use in all circumstances. The security considerations
section
has been rewritten to describe how the operational model for
wireless or IP
networks differs from that for physically secure
networks.
Issue 23: Contents of Identity Request
Payload
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section:
5.1
Rationale/Explanation of issue:
Section 5.1 page 13 describes the Identity Type thusly:
The Identity
Type is used to query the identity of the peer.
Generally, the Authenticator
will issue this as the initial Request.
An optional displayable message MAY
be included to prompt the Peer in
the case where there expectation of
interaction with a user. A
Response MUST be sent to this Request with a Type
of 1 (Identity).
This language is good as far as it goes, but I wonder if
more formal rules
should be specified to enable the more mobile enviroments
where EAP is being
applied? What I have in mind is that it is likely that
many (most?)
users/devices will have different sets of credentials for many
of the
security domains they visit. Each of these credentials will assign to
the
user/device a different artificial and arbitrary "identity".
In
the wireless roaming case, it is likely that a user will sometimes
cross
domain boundaries without even knowing it, so the commonly cited
industry
goal of "seamless" roaming would imply that the Identity Request
from the
Authenticator should provide some hint as to which "identity" it
is
expecting, i.e., which domain is in use. While the cited language above
does
not preclude this, it does not specify any interoperable way
of
accomplishing this goal.
The obvious suggestion would be to insert
the domain name portion of the NAI
of the Authenticator in some standard way
into the Identity Request. The
Peer could parse and then attempt to map this
to the credentials it should
present to this particular Authenticator.
[BA]
In RFC 2284, Section 3.1, it says:
"An
optional displayable message MAY be included to
prompt the peer in the case
where there expectation of interaction
with a
user."
and
"optionally, the failure MAY be indicated within the
message of
the new Identity Request itself"
I read this as indicating
that the primary purpose of the Identity Request
is for user display, and
that it is treated as undistinguished octets,
rather than interpreted by the
protocol itself.
I think that there are a number of issues here:
1. How the Supplicant
knows what NAI to present to the Authenticator,
if more than one is
available.
2. What certificate the Supplicant presents when queried by the
Authenticator.
3. How to route the authentication itself,
particularly
if EAP pre-authentication is used.
Knowing the NAI of
the Authenticator may not by itself
help answer these questions. In the case
of wireless, the AP is
also typically advertising its characteristics, which
in the
case of 802.11 can include the SSID. Similar advertisements
have
also been discussed in SEAMOBY.
So at the point at which EAP
authentication occurs, the Supplicant
may have learned information about the
AP, based on the L2 or
L3 advertisements.
So the question is how
information to be added in the EAP
Identity-Request adds to (or possibly
conflicts) with the
information in the advertisements.
For example,
in 802.11 advertisements contain SSIDs, which
represent the networks to which
the AP connects, and which may be
more useful than the NAI of the
Authenticator itself.
For example, a single AP may advertise a roaming
consortia SSID,
a WISP SSID, and maybe the SSID for a secure network. Each
of
these SSIDs correspond to a different VLAN and access network.
Date: Sun, 6 Oct 2002 08:21:52 -0700
(PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Jari Arkko
<jari.arkko@piuha.net>
Cc: eap@frascone.com
Subject: Re: [eap] Issue
23: Content of the Identity Request Payload
> I have a few background
questions before I can understand this
> issue:
>
> 1) Are we
sure that the NAI in the Identity *Response* is not
> sufficient to handle
these situations? Assuming all the
> domains you visit are still within
the same roaming
> group, this should work.
I think the issue
arises if the user has multiple identities, and if
insufficient information
is available on the authenticator network to make
a decision on which
Identity to use or credentials to present.
I am not sure that this is an
issue for the NAI, so much as for
credentials (such as
certificates).
I think it is reasonable to expect that prior to use of
EAP, some
out-of-band information is available on the network to which
the
authenticator connects. In the case of PPP, there is typically an
ISP
phone book that was installed beforehand. In the case of 802.11 there
are
the 802.11 Beacons and Probe Responses, which include the SSID. So
if
the user's machine has a list of potential networks and the
corresponding
NAIs to login to those networks, I think that is enough,
without adding
hints in the Identity Request.
> 2) How are EAP
peers expected to treat multiple identity
> requests? Presumably, these
could be made for retransmission
> purposes or because the authenticator
doesn't have any
> information about the given identity.
One can
conceive of several identities being used in a single
authentication -- for
example, a machine identity followed by
authentication, then a user identity
request followed by another
authentication. I'm not sure how the peer knows
which identity is being
requested, though.
Distinguishing
retransmissions from new requests can be
handled via the
Identifier.
> 3) If need to solve this issue, would be better to work
on
> advertisements or re-trials with other identities?
I think
that advertisements handle some of it (NAI selection). However,
it's not
clear to me how a peer determines which cert to use unless there
is an SSID
or other field in the cert providing a hint.
See:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-02.txt
>
4) In a roaming group, what network domain should be advertised?
> The
user is unlikely to know the local domain, but we can't
> list all the
domains involved in the group. Are roaming groups
> always associated with
a domain?
In 802.11, it is possible for an AP to advertise multiple
SSIDs, one for
each network that it connects to. If it does this using
multiple BSSIDs,
the "virtual APs" are indistinguishable from real APs.
However, the SSID
is limited to 32 octets, so it cannot represent an
arbitrary FQDN or
"realm" in the RFC 2486 sense.
> 5) When
certificates need to be presented, how are the currently
> available
cert-based methods handling the domain issue? Does
> TLS allow you to
specify the root for which you need the cert?
The TLS certificate request
payload includes acceptable certificate types
and CAs. However, it is still
possible that this guidance will not
uniquely point to a client
certificate.
Discussion of the EAP Design Team, 10/30/02
The question is whether we have enough
information in the
Identity Request to be able to answer with the
appropriate NAI
in the Identity Response.
It can be assumed that the
peer has obtained information about
the capabilities of the NAS in some way
prior to the EAP exchange.
In PPP, this comes from the dialup client; in
802.11 it comes
from the Beacon/Probe Response; in PPPOE, it could come from
the
network advertisement; in PANA, from CAR discovery. 802.1 also
has its
own discovery protocol. So do we need more information
in the Identity
Request as well?
In addition to this information it could be useful
for
the Authenticator to provide a list of supported realms.
This is
considered a hint, which can be ignored by the peer.
Question: in the
case of a shared use NAS, what realms should
be provided? In the case of
802.11 is this dependent on SSID?
What about pre-auth?
Disposition recommendation
This
issue was discussed in depth within the EAP State Machine design team
and
consensus was not reached.
In most cases (though not all), EAP is used in
situations where the
network to which the peer is connecting is known,
either because it is
preconfigured (PPP, L2TP, PIC), or due to an
advertisement that is
received out-of-band (PPPOE, 802.11, 802.1ad,
CARD).
A possible exception to this is IEEE 802 wired networks where
there
is currently no advertisement/discovery mechanism. However, one is
under
development, so that it is possible that it too may provide the peer
with
indication of what network it is connected to.
Another possible
exception is IEEE 802.1X pre-authentication which occurs
prior to
association. Where multiple SSIDs are advertised, each with the
same BSSID,
it may not be possible to know which network is being
pre-authenticated to.
However, advertising multiple SSIDs with a single
BSSID does not work
reliably today anyway, due to station limitations and
if each SSID has its
own BSSID then the problem goes away.
Given that it already appears that
a solution exists without adding
functionality to EAP, the case for adding
this to the
EAP-Request/Identity message cannot be
made.
Proposed Resolution: Reject
Issue 24: EAP and ciphersuite
negotiation
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section:
9.8
Rationale/Explanation of issue:
The seventh paragraph of Section 9.8 says:
However, EAP methods
deriving keys SHOULD provide keying material
that can be used with any
ciphersuite, since EAP methods cannot be
assumed to provide protected
ciphersuite negotiation and the
negotiated ciphersuite may not be known
beforehand.
I think what this is really trying to say is that if EAP
distributes any
keys, the distributed keys should be master session keys,
used only for further key
derivation, independent of the cipher suite,
because it is unreasonable for
the Authenticator to know the details for
deriving keys for every cipher
suite. This is a reasonable
requirement.
However, this is not what the text says. It says that we
shouldn't use EAP
for cipher suite negotiation. This position undercuts the
Authenticator's
role as the policy decision point, i.e., it undercuts EAP's
own rationale.
An architecture using EAP could include cipher suite
registration with the
Authenticator. If this were done, there is no reason
why it an EAP method
cannot negotiate the cipher suites to be used with a
key, and if it does,
why the Authenticator cannot specify the "best" cipher
suite to use on the
basis of the capabilities of the communicating peers that
best match each
other and local policy; in fact, this seems like a desirable
property, to
allow the Authenticator to deny service when an acceptable
cipher suite
conforming to policy cannot be found. The Authenticator could
delegate this
task the NAS, but again this complicates the security analysis
and increases
the total number of assumptions needed about the system.
Resolution: Accept
[BA] Some EAP methods may wish to support
secure ciphersuite negotiation
and this should not be
discouraged. The text has been changed to the
following:
"However, where EAP methods derive keys, the distributed
keys
SHOULD be master keys, used only for further key
derivation,
independent of the ciphersuite. This eliminates the need
for
an EAP method to understand how to derive keys for
every
ciphersuite."
Issue 25: Spoofing and duplicate
detection
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 2.2,
7.7
Rationale/Explanation of issue:
Section 7.7, point 1 says:
Silent discard. Since only a single EAP
Request can be in progress
between an Authenticator and a Peer at a given
time, if a Peer
receives a new Request before sending a Response, the new
Request
can be silently discarded. This increases resilience
against
spoofed Requests. Similarly, an Authenticator can silently
discard
Responses with Identifiers that do not correspond to the
Identifier
included in the last Request, or that represent
duplicate
Responses.
This advice seems effective only if both the
Authenticator and the Peer
respond significantly more rapidly than does the
active attacker, or their
responses are delivered more expeditiously than the
attacker's, i.e., you
can't depend on it. The Success and Negotiate messages
in particular require
their own protection. I suggest noting this method does
not work except in
very constrained environments because of the race
conditions cited.
Resolution: Discuss
[BA] For a new Request, that arrives before the Response
is sent, it seems
to me that the proposed
behavior is appropriate.
Since a compliant
Authenticator will never send a
new Request before receiving a Response, if
the
Supplicant sees this, it either implies that the
Request has been
spoofed, or that a Response was
spoofed that caused the new Request to be
sent.
This behavior cannot be caused merely by a poor
RTO estimator since
EAP is an ACK/NAK protocol.
If the method is protected, then presumably
a
spoofed Response is not possible. If the Request
is spoofed, then silent
discard is appropriate.
For a Response that does not match the
Identifier
of the Request the indicated behavior also
appears
correct.
Assuming that we have a compliant EAP client,
this
can happen in high latency networks where the
Response is sent in
answer to a retransmitted Request,
with the original Response arriving after
the
Request is retransmitted. If the original Response
was invalid, then a
new Request would not have been
sent, so that discarding the duplicate
Response has
no ill effect.
If Requests are being spoofed, and the EAP
method
is not protected, then the EAP client
may Respond to the bogus
Requests, causing the
observed behavior. By discarding Responses to
bogus
Requests, the Authenticator can avoid becoming
confused, but the outlook on
the client is less
sanguine; it seems likely that authentication
will
fail.
So it seems that in this case the specified
behavior
does not harm, although it may not do much good either.
Recommendation of the EAP Design Team, 11/6/02:
Delete Section 7.7.
Add the following text to Section 2.2:
"The EAP layer provides sequencing and duplicate elimination
to EAP
methods. During the period after an
EAP Peer receives an EAP-Request, but has
not yet sent an
EAP-Response, the Peer EAP layer MUST silently
discard
additional EAP packets upon reception, rather
than providing them to the EAP
method. This occurs whether
the received packet is a duplicate (same
Identifier) or
not (different Identifier).
This provides an
opportunity for a denial of service attack:
an attacker can swamp a Peer with
EAP Requests,
preventing valid EAP Requests from being processed.
Addressing this requires an EAP method to be able
to indicate to the EAP
layer that it wants to handle
duplicate elimination and packet validation
itself, which
is not supported."
More discussion (From Henry Haverinen and Bernard Aboba)
Re: Survey: handling of retransmissions
It is common for early
messages within an EAP method to not
contain a message integrity check,
because a key has not yet
been negotiated.
This problem occurs in TLS
[RFC2246], for which the solution
is to include all the handshake messages
within the MIC included
in the Finished message. If we can assume that the
EAP conversation
is available to a method, then this could work, although it
would
not address the DoS issue.
I think what you are saying is that
some EAP methods may wish to
process packets themselves (e.g. they want a
"UDP" transport)
while others might want a reliable transport. This makes
some
sense to me -- but I am still trying to figure out exactly
what
transport service RFC 2284 had in mind.
For example, RFC 2284bis
talks about not passing duplicate
Requests to the EAP method in the case of a
token card, so I
think that it supports duplicate elimination of a sort.
However,
once the Response is sent it could be lost, and so the Peer
EAP
method can receive the same Request again. In that case,
I think that RFC
2284 implies that the duplicate Request is
passed to the EAP method, which is
presumed to have kept state
and therefore can resend the previous Response.
If that is true,
then duplicate elimination is sometimes the responsibility
of the
EAP layer (when a Response is pending) and sometimes not (when
a
Response is not pending).
This is not the service that a reliable,
non-duplicating
transport provides -- and protocols like TLS do assume that
they
run over such a service.
If someone has a different reading of
RFC 2284, please speak up.
On December 20, 2002 Henry Haverinen said
this:
Hello,
EAP SIM and EAP AKA are examples of methods that can
silently
discard EAP packets based on an incorrect ICV.
It is also
conceivable that an EAP method could delay the
processing of some unprotected
packet, say a method-specific
notification. If another packet with a correct
ICV is received
during the delay, then the unprotected packet may be
silently
discarded. If no other packets are received, the method
may
decide to process the unprotected packet. This could also
happen in
EAP SIM, where ICV can only be included once
keys have been derived, so in
the very first packets there
is no ICV.
If we further consider EAP SIM
as an example, the fact
that the very first packets are not MAC'd makes it
easy
to spoof packets. Of course spoofing will later be detected,
but if
only the first received packet is processed, then it is
quite easy to mount a
DoS attack. So it makes me wonder if
some method implementations could
process several copies of the
"same" packet and kind of "fork" separate
states for each
processed packet. The spoofed states should later be
detected
and removed, but if the valid packets were processed
separately,
the authentication could still succeed.
Based on these
examples, I'm inclined to think that the
EAP layer should simply pass all EAP
packets of a certain
type to the appropriate method, and let the
method
decide how to process the packets. The EAP layer should
not act as
a "flip-flop" by keeping track of requests
and corresponding responses or by
flushing the packet queue.
This would make the software interface between EAP
layer
and methods simple while allowing sophisticated processing
of EAP
packets.
I don't know about any implementations that would work
like
this, so I didn't answer the survey
below.
Regards,
Henry
Resolution: Insert the following text in section 3.1:
"If a Message Integrity Check (MIC) is employed within an
EAP method, then
implementations are REQUIRED to discard
any message that fails this check
silently. In this
document, the descriptions of EAP message handling assume
that
MIC validation is effectively performed as though it occurs
before
examining any of the EAP message fields (such as 'Code')."
Proposed resolution: Accept
Issue 26: Unprotected Success and Failure
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section:
4.2
Rationale/Explanation of issue:
Section 4.2 page 12 begins:
"The Success packet is sent by the
Authenticator to the Peer to
acknowledge successful completion of an
authentication method.
The Authenticator MUST transmit an EAP packet with the
Code
field set to 3 (Success)."
We know from the 802.11 experience
that the Success message as formulated
today has no reliable meaning within
that context. The solution de jour
802.11 has proposed is to use 802.11 link
level protections for the Success
message. This feels unsatisfactory,
because it does not protect the Success
message the entire length of the
channel between the EAP Authenticator and
the EAP Peer. It seems we will not
arrive at a satisfactory solution until we
find a way to protect the Success
message end-to-end across this entire
channel.
If this observation is
valid, it would imply we need a cryptographic key to
protect the Success
message, and the EAP architecture cannot be considered
complete until it
deals with this problem (or else make devices that can use
EAP in
environments like 802.11 non-conformant, which no one wants to do). To
be
useful, such a key can only come as a bi-product of the authentication,
and
it can be either a static key identified by the authentication or an
ephemeral key constructed as a bi-product of the authentication protocol
carried by EAP.
I might be wrong, but I haven't convinced myself it
is sufficient to simply
"tunnel" the EAP Success message through TLS or
IPsec or the like; it seems
like it is necessary to insert data orgin
authentication fields the Success
packet itself to guarantee that some
entity other than the Authenticator has
not forged the Success message; this
is an application layer function, and
lower level security will not address
the concern. It also feels like an
abuse to protect the Success via an
underlying tunneling protocol, because
the EAP exchange exists to establish
the trust that is assumed by any such
protocol. This suggest either
extending the format of the existing Success
message, or introducing a new
one that has all the necessary bells and
whistles for environments like
802.11. An alternate approach might be to
require use of a key distribution
message in lieu of the Success in these
environments.
To prevent all
kinds of forgeries, it is also necessary to deny replayed
Success messages
between the same two Peers. For this to work, it is
necessary to tie the
Success message to the packets conveyed by EAP during
this particular
authentication. A typical hueristic that accomplishes this is
to use the key
to hash all the information elements in all the packets we
care about, as
well as the important fields of the Success message itself,
and the Success
carries the hash to the Peer for verification; the Peer
verification will
fail if the messages it exchanged differ. This hueristic
applies if the
packets contain unguessable data; otherwise, some sort of
nonces will have
to be introduced into the Request/Reply exchange, or we
would need to
discover a new way to guarantee a live Success, or ban EAP
methods that
don't introduce any session-specific material.
So the requirements for
making the Success message generally meaningful is
that there must be some
way to authenticate it, that the authentication key
used to do this has to
stem from the authentication itself, that the Success
must be tied to the
messages exchanged in this particular authentication
session, and that the
authentication has to include information by which the
Peer can determine
liveness and authenticity of the Success. It appears to me
today that the
Success message itself should carry the protections, although
I might have
this wrong about this.
I am not suggesting that 2284bis address this
problem, since this kind of
change is out of scope of the document intent.
Rather the issue and the
requirements for its solution should be noted
somewhere, so that we have a
starting point if we are ever chartered to
extend EAP.
Proposed Resolution: Reject within RFC 2284bis (consider as an Extension)
[BA] I agree that it is important for EAP to
be extended to support
acknowledged (and protected)
success and failure indications, and that
this
is a requirement for secure operation on networks
where physical
security cannot be assumed. However,
it is not clear that this needs to be
added to
added to RFC 2284bis, as opposed to an EAP
Extension, possibly
along with the cryptographic
binding issue (#40), and acknowledged
success/failure (#10).
Issue 27: Peer timeout and retry
Submitter:
Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first
submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment
type: T
Priority: S
Section: 4.2
Rationale/Explanation of issue:
Section 4.2 page 12 has an implementation note saying
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, and if they are lost, the
Peer will timeout and
retry the authentication.
Sorry for being so
obtuse, but I can't fathom what this is trying to tell me.
I find this text
confusing, since the preceeding few pages have carefully
explained that EAP
does not permit the Peer to retry anything, but only to
respond to the EAP
Authenticator.
The only conclusion I can draw is it constitutes a
reference to some
unidentified entity outside of EAP, thus coupling the
correct behavior of EAP
to the containing environment behaving correctly.
This sort of coupling is
always dubious, especially within a scheme
allegedly related to
authentication.
If that is the correct
conclusion, this points to a design flaw within EAP
that we will want to
address in the long term, as it implies that misbehaving
environments (e.g.,
those partially controlled by attackers) might be able to
subvert the
protocol, regardless of the quality of the concrete
authentication method.
In this case, my suggestion is to document this as the
only existing work
around (but also as only partially effective) until
appropriate EAP
extensions can be defined in another document, assuming the
WG could get
chartered to do this work.
If this conclusion is incorrect, then please
help me understand the intended
meaning of the language.
Resolution: Accept
[BA] You are correct that in EAP the Peer does not
retry. This was
referring to the Peer timing out and
sending an EAPOL-Start to authenticate
again. However, that is a feature
of 802.1X not EAP, so that it is not
appropriate to
refer to it in this document. The phrase
"retry the
authentication" has been deleted.
Issue 28: Per-Packet Integrity
Protection
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 5.2,
9.3, 9.6
Rationale/Explanation of issue:
Section 9.6 page 24 says in the second paragraph that
For use on
wireless media such as 802.11 [IEEE80211], or over the
Internet, where
physical security can no longer be assumed, the EAP
conversation SHOULD be
authenticated, replay and integrity protected on
a per-packet
basis.
It would be worth emphasizing that it is the conversation and not
necessarily
each packet individually that is protected, because it is in
general
infeasible to prove liveness of the first packet during an initial
contact
exchange.
Section 9.3:
Where the EAP conversation is protected via per-packet
data
origin authentication, integrity and replay protection, spoofing
or
data modification attacks can be detected.
I have argued above that
using an underlying transport to secure the EAP
packets themselves feels
dubious, because the goal of the underlying
protections is to protect data
and not to establish the trust these protocols
rely on a priori. Instead, it
appears necessary that we introduce data
integrity into at least some of the
EAP packets themselves. It is evident it
is infeasible to do this directly
in any packets sent or received before the
concrete authentication protocol
being transported by EAP establishes a key,
but it seems quite reasonable we
can extend packets sent or received after
key establishment, and we can use
a backward hashing technique of the
previous packets from this session to
identify when we received malicious
packets.
Section 5.2 "Notification." This simply does not work unless the
negotiation exchange is integrity protected or the channel between the Peer
and the Authenticator is assumed a priori secure from packet forgeries. This
should be documented.
In the case where forgeries are possible,
hueristics for how to protect the
negotiation exchange are well understood:
the Peer and Authenticator must
somehow establish a key, and then in some
later exchange (after a key has
been established), they should hash over the
negotiation messages sent by
both. This fits well with the discussion of the
Success message above, but
other approaches might also work.
Another
approach might be to mandate that each domain use only a single
method that
is not subject to negotiation until a secure channel is
established (I see
that Section 9.6 advocates this position). I don't like
such a scheme,
because it imposes deployment constraints, something customers
never like.
Even worse, it shifts the burden of getting things right from the
protocol
specification process onto the final end users. In case you haven't
noticed,
they will almost never get it right, and the industry will get a
black(er)
eye as a result. This sort of scheme also becomes another mechanism
to drive
the amount of configuration required, as well as overall GUI
complexity.
I think this problem and the failure of the Success
message to provide any
meaningful semantics in some environments demonstrate
that it is not feasible
to move the EAP architecture unchanged into some new
environments like
wireless, at least not without compromising the security
guarantees ESP
allegedly helps establish. I think EAP seems to need its own
native security
mechanism for at least a few packets, to guarantee liveness
and authenticity.
I suspect that attacks like Mishra-Arbaugh will always be
feasible until we
address this, as today we use any security provided by the
concrete
authentication method to protect EAP itself (if at all) in a naive
way. What
the EAP design intends to do is compose an intentionally
non-secure protocol
(EAP) with a possibly secure one, and then asserts the
larger system secure.
Composition in security in general is very hard to get
right; the
Mishra-Arbaugh attack indicates that the EAP composition is
subtler than
might first appear, and we should therefore expect further,
perhaps even
devastating attacks, if we do not take action.
The first
attempt to use EAP in an wireless environment failed for the
problems
enumerated in Section 9 of the draft, so TTLS and PEAP have been
defined as
wrappers to ameliorate or at least mask the EAP's most glaring
deficiencies
when used in this new environment. I have argued above that some
of the
tactics used to address the existing problems appear dubious.
Keying and
authentication is the critical part of the entire enterprise, and
the
security of wireless systems falls apart just as surely as with
original,
vanilla WEP if we get these wrong. Is it within scope to write a
new EAP
extensions document defining a more satisfying long term solution? I
am
willing to drive this.
Resolution: Accept
[BA] The issue here is protection of the Identity,
Nak and Notification
exchanges as well as Success/Failure indications.
While work on mechanisms to
achieve this are not within the
scope of the current EAP WG charter, it is
appropriate to indicate the requirement
for this when physical security
cannot be assumed. I take this comment to
imply that you agree with the
importance of protecting these messages, and
feel that this should be
required where physical security cannot be assumed.
The security
considerations section has been rewritten in order to underline
this
point.
Issue 29: Security Considerations
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section:
9.2
Rationale/Explanation of issue:
Section 9.2 page 22 concludes with
As a result, when EAP is used with
wireless media or over IP, the EAP
conversation SHOULD be authenticated,
integrity and replay protected, on
a per-packet basis. This can be
accomplished using mechanisms such as
ISAKMP [RFC2408], as is done in PIC
[PIC], or using TLS [RFC2246].
This statement is saying “yes, our
protocol is broken, but we will appeal to
unspecified external mechanisms to
save us, and heaven help us if someone
doesn't glue things together just so,
or if the external mechanism we depend
on is subverted.
While the
honesty is refreshing, the prescription is a bit misleading for the
new
environments, where the security problems arise. The EAP-TLS exchange
used
in 802.11, for instance, is not protected in the fashion described
above,
nor can it be; 802.11 specifies that TLS run over EAP and not the
other way
around. Of course the TLS handshake can take care of itself (but
reference
the Mishra-Arbough attack to demonstrate the synchronization
between state
machines or layer or something is not yet quite right). I think
the proper
advice is to suggest that the entire sequence rather than invidual
packets be
authenticated, because by definition those exchanged prior to key
establishment cannot be directly authenticated.
The proper thing to
do in a clarification document like 2284bis is to note
that the existing
work arounds of relying on TLS or PIC or ISAKMP or 802.11
security are not
ideal, but do reduce the risk over running EAP in the clear.
When using EAP
with 802 LANs, however, the risks with the existing
precautions are not
negligible, but they are the best we can do without some
EAP extensions.
Resolution: Accept
[BA] EAP was developed for use on links that could be assumed to
be
physically secure, such as PPP dialup links and IEEE 802 wired
networks. One
of the goals of RFC 2284bis is to describe the additional
security
vulnerabilities and requirements that arise from use of
EAP over the
Internet and wireless networks, where the physical
security assumption is no
longer valid. As part of this, the security
considerations section is to
include requirements useful in evaluating
future EAP extensions or methods
to address the security threats
which are identified. Just as IP was
extended to support IPsec so
as to add security to UDP or TCP packets that
would otherwise be
vulnerable to attack, so too might it be possible to
provide
additional security mechanisms to protect EAP where
physical
security cannot be assumed. So far, where EAP has been
proposed
for use over the Internet (such as in PIC or L2TP/IPsec), the
EAP
conversation has been protected (in PIC, by ISAKMP; in
L2TP/IPsec, by IPsec
ESP w/non-null transform w/auth). However,
at this point, the goal for RFC
2284bis is to develop requirements
for this additional functionality, not to
propose or
evaluate it. This will then lay the groundwork for future
work
to be chartered relating to proposed solutions.
In this spirit, I am
assuming that your comment
indicates that you agree with the importance of
protecting all
EAP messages including the Identity, Nak, Notification, and
Success/Failure indications, where physical security cannot be
assumed.
A separate issue is whether it is necessary to protect
the EAP header
itself. These issues are now noted in the
security considerations section.
Issue 30: Negotiation Attacks
Submitter:
Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first
submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment
type: T
Priority: S
Section: 9.6
Rationale/Explanation of issue:
Section 9.6 page 24 begins by declaring that
Vulnerability to
negotiation attacks is particularly acute where EAP
runs over wireless media
or IP since EAP method negotiation is
unprotected.
That is, the text
admits that EAP has a certifiable security weakness when it
is used in
environments such as wireless communications. This raises a
political
question. The IESG has sent back for rework drafts with a lot less
grevious
security errors. However, rework is outside the charter scope. It
seems like
we either need the charter extended to allow us to address this
sort of
question (hopefully in a separate document, because we don't want EAP
to
recycle), or else we need a new charter for a new WG to address it, since
no
one wants to delcare that implementations using EAP in wireless
environments
are non-conformant.
Resolution: Accept
[BA] The intent was to indicate the need for a higher standard
of security
where EAP is run over wireless or IP, as opposed to
situations in which the
network may be assumed to be physically secure.
Just as IPsec can be used to
protect UDP packets from a variety of
threats, so presumably can future EAP
methods and extensions be used
to protect EAP conversations from the threats
described in the security
considerations section. Assuming that the EAP WG
completes the threat
analysis and operational models, then future work may
be chartered to
address the issues that have been identified. The goal of
RFC 2284bis
is just to point out the issues and the requirements for their
solution.
Your comment is taken to imply that you agree with the assessed
vulnerability
to negotiation attacks, as described in the security
considerations section,
and request that solution of this issue be a
requirement. This will be added
to the security considerations section.
Issue 31: PEP and PDP separation
Submitter:
Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first
submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment
type: T
Priority: S
Section: 9.8
Rationale/Explanation of issue:
Regarding key establishment, the second paragraph of Section 9.8
page 25
write of the separation between the policy decision point and policy
enforcement point:
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 pass the session key to the link layer security
module.
I don't understand why this is true. It does seem like an issue
for the Peer,
because the Authenticator and the policy enforcement point
(e.g., a NAS) may
not reside on the same machine, and this separation
provides structural
opportunities for both the Peer and the NAS to cheat and
use the key in
contexts for which it was not intended, as well as
opportunities for an
attacker to masquerade as one or both of the parties if
the key distribution
is not handled with great care. The history of key
establishment is littered
with the ruins of protocols that failed to solve
this particular problem, so
please help me understand what is special in the
EAP architecture that
prevents this from being a problem, or else remove or
modify the language
that it is not an issue for the Peer.
Resolution: Accept
The text has been changed to:
"It is possible for the EAP endpoints to
mutually authenticate,
negotiate a ciphersuite, and derive session key(s) for
subsequent use
with per-packet authentication, integrity protection and
encryption.
Since the Peer and EAP client reside on the same machine,
the
EAP client module passes the derived session key to the link layer
security
module."
Issue 32: Keying confirmation
Submitter:
Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first
submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment
type: T
Priority: S
Section: 9.8
Rationale/Explanation of issue:
Section 9.8 continues on page 24 at the end of its paragraph 4:
This
means that it is not possible for the Peer to validate
the identity of the
Authenticator.
Actually, this is not necessarily true, either. Many
reasonable keying
schemes require a key confirmation handshake, whereby the
handshake confers
to the Peer assurances concerning some version of the
Authenticator’s
identity. What it does imply is that the entire keying
mechanism cannot be
contained within EAP, nor within AAA nor NASREQ, nor
within the media
specification. The distribution of symmetric keys is one of
those perverse
things that does not and cannot follow our normal
partitioning of network
communication problems, which is why people nearly
always make a complete
hash of it. I suggest adding the words "within EAP
alone" to the quoted
sentence.
Proposed Resolution: Accept
Issue 33: Encoding of Identity
Response
Submitter: Mark Wodrich
Submitter email address:
markwo@microsoft.com
Date first submitted: August 12, 2002
Reference:
Document: RFC2284bis-05
Comment type: T
Priority: S
Section:
5.2
Rationale/Explanation of issue:
Displayable messages are to be encoded in UTF-8. The Identity Request
MAY
contain a displayable message, and if so, that is UTF-8 encoded.
But what
about an Identity Response? Is that UTF-8 encoded? Does
RFC 2486 allow this?
Please clarify in the text.
Resolution: Reject
[BA] The contents of the Identity
Response is not constrained
by the EAP protocol specification -- although
other specs may
constrain usage in particular cases.
For example, the
Identity Response may contain an NAI, in which
case the NAI grammar described
in RFC 2486 would apply to it.
However, it is also possible for the
Identity Response to only
contain a realm name, which is not a legal NAI, and
which
would need to conform to the Internationalized Domain
Name
requirements -- which is *not* the same as UTF-8 encoding.
Similarly, in a particular usage, the Identity Response might
contain
a UTF-8 encoded userID string.
In general, the Identity Response should
not be thought of as a
"displayable message" since it is sent by the peer to
the
authenticator."
Issue 34: Notification Usage
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment
type: T
Priority: S
Section: 5.2
Rationale/Explanation of issue:
RFC 2284bis doesn't answer basic questions about Notification, such as:
a.
Whether you are Notification is part of the method (e.g. Notification Request is
delivered to the method)
b. Whether Notification can be sent at any time
(e.g. in the middle of a method exchange)
c. Whether Notification results in
a state change within the EAP state machine or not.
Resolution: Accept
Change:
" The Notification Type is optionally used to convey a
displayable
message from the Authenticator to the peer. The Peer
SHOULD display
this message to the user or log it if it cannot
be displayed. It is
intended to provide an acknowledged
notification of some imperative
nature. Examples include a
password with an expiration time that is
about to expire, an OTP
sequence integer which is nearing 0, an
authentication failure
warning, etc. In most circumstances,
notification
should not be required."
To:
" The Notification Type is optionally used to convey a displayable
message
from the authenticator to the peer. An authenticator MAY
send a Notification
Request to the peer at any time, including
in the middle of an ongoing method
conversation. The peer MUST
respond to a Notification Request with a
Notification Response;
a NAK Response MUST NOT be sent. A Notification
Response is
typically generated automatically by the EAP layer; therefore the
contents of a Notification
Request MUST NOT be delivered to a peer method
other than Notification.
The Peer SHOULD display this message to the
user or log it if it
cannot be displayed. The Notification Type is intended
to provide
an acknowledged notification of some imperative nature, but it
is
not an error indication, and therefore does not change the state
of the
peer. Examples include a
password with an expiration time that is about to
expire,
an OTP sequence integer which is nearing 0, an authentication
failure warning, etc. In most circumstances, notification should
not be
required."
Issue 35: NAK'ing an Identity
Request
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: 2
Section:
5.1
Rationale/Explanation of issue:
RFC 2284bis doesn't state whether an Identity request can be NAK'd.
Change:
"The Identity Type is used to query the identity of the peer.
The
Authenticator will typically issue this as the initial
Request. An
optional displayable message MAY be included
to prompt the Peer in
the case where there is an expectation of
interaction with a user. A
Response MUST be sent to this
Request with a Type of 1 (Identity)."
To:
"The Identity Type is used to query the identity of the peer.
The
Authenticator will typically issue this as the initial Request.
An
optional displayable message MAY be included to prompt the Peer in
the
case where there is an expectation of interaction with a user.
A peer MAY
respond to an Identity Request with a NAK if it does not
wish to reveal its
identity. Otherwise, the peer MUST send an
Identity Response in response to
an Identity Request."
Resolution: Reject
Based on NAK survey responses, it
appears that existing implementations will terminate the
conversation on
receiving a NAK to an Identity Request. Therefore this change would not
be
backward compatible.
A better approach is to allow the Identity to
remain optional, so that an Identity Request
need not be sent. If it is sent,
and the peer doesn't want to provide the Identity, then
it can provide a null
response.
Issue 36: When may a NAK be sent?
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment
type: T
Priority: 1
Section: 5.3
Rationale/Explanation of issue:
RFC 2284bis doesn't state when a NAK can be sent, and when not. For
example:
a. Whether a NAK may only be sent in response to a method
proposal or
b. Whether NAK can be sent at any time (e.g. in the middle of a
method exchange)
Resolution: Accept
Change:
" The Nak Type is valid only in Response messages. It is
sent in reply
to a Request where the desired authentication Type
is unacceptable.
Authentication Types are numbered 4 and
above. The Response contains
zero or more authentication
Types desired by the peer. A Nak with no
authentication Type(s)
indicates that the Peer does not wish to
authenticate using the
proposed method but is not proposing an
alternative.
Since the Nak Type is only valid in Responses
and has very limited
functionality, it MUST NOT be used as a
general purpose error
indication, such as for communication of
error messages, or
negotiation of parameters specific to a
particular EAP method."
To:
" The Nak Type is valid only in Response messages. It is sent in reply
to
a method proposal (the initial EAP Request for a given Type)
where the
desired authentication Type is unacceptable.
Authentication Types are
numbered 4 and above. The Response contains
zero or more authentication Types
desired by the peer. A Nak with no
authentication Type(s) indicates that the
Peer does not wish to
authenticate using the proposed method but is not
proposing an
alternative.
Since the Nak Type is only valid in Responses and has very
limited
functionality, it MUST NOT be used as a general purpose
error
indication, such as for communication of error messages,
or
negotiation of parameters specific to a particular EAP method.
As a
result, a NAK is only sent in response to a method proposal and
MUST NOT be
sent in the middle of an EAP method conversation."
Issue 37: EAP stack
representation
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: 1
Section:
2.1
Rationale/Explanation of issue:
RFC 2284bis needs an explanation for how EAP multiplexing works.
Resolution: Accept
Here is a proposal for material to be
added to section 2.1:
"The EAP layer provides sequencing and duplicate
elimination
to EAP methods. During the period after an
EAP Peer receives
an EAP-Request, but has not yet sent an
EAP-Response, the Peer EAP layer MUST
silently
discard additional EAP packets upon reception, rather
than
providing them to the EAP method. This occurs whether
the received packet is
a duplicate (same Identifier) or
not (different Identifier). Similarly,
during the period after
an EAP Authenticator receives an EAP-Response, but
has not
yet sent an EAP-Request, the Authenticator
EAP layer MUST silently
discard additional EAP packets
upon reception, rather than providing them to
the EAP method.
This provides an opportunity for a denial of service
attack:
an attacker can swamp a Peer with EAP Requests,
preventing valid
EAP Requests from being processed.
Addressing this requires an EAP method to
be able
to indicate to the EAP layer that it wants to handle
duplicate
elimination and packet validation itself. This
is not
supported.
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
Request and Response can be assumed 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. 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 other EAP methods.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
| EAP method| EAP method| Native | | EAP method| EAP method| Native |
| Type = X | Type = Y | EAP | | Type = X | Type = Y | EAP |
| | | Methods | | | | Methods |
| ! | | (MD5) | | ^ | | (MD5) |
| ! | | | | ! | | |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! | | ! |
| ! EAP | | ! EAP |
| (Nak, ! Success,Failure,Notif.,Id) | | (Nak, ! Success,Failure,Notif.,Id) |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! | | ! |
| ! Link Layer | | ! Link Layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! !
+----------------------->----------------+
Figure 1. EAP Multiplexing Model
Issue 38: Language Negotiation
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: October 5, 2002
Reference:
Document: RFC2284bis-06
Comment
type: T
Priority: 1
Section: N/A
Rationale/Explanation of
issue:
Currently there is no way to make sure that displayable
messages
(such as Notifications) are sent in a language that the user
understands.
Some ideas on how this might be accomplished:
a. Add language type to
the first octets of the Notification Request AND
allow a Notification
Response to encode an alternate language. However,
the Notification Response
is of zero length, so there is a question of
whether this would break
existing implementations.
b. Encode the proposed language type in the
Identity Request, and allow
the Identity Response to encode an alternate
language.
Proposed Resolution: Reject within RFC 2284bis (consider as an Extension)
[Glen Zorn]
I find both the options above unsatifactory. For example,
the Identity
Request is for all intents optional, so overloading it
with
language/charset negotiation seems inappropriate, and breaking
existing implementations by overloading the Notification Response
doesn't seem right either. OTOH, this seems to be a case where
it would
be harmless (modulo appropriate defaults)
for an implementation to ignore or
NAK an unknown Type, so I would suggest
that language/char set negotiation be
done in a new type. This could be
done via a preference-ordered set of TLVs
sent by the server,
w/the response containing a single TLV representing the
client's choice.
Issue 39: When can an Identity Request be
sent?
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: October 9,
2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority:
S
Section: 5.1
Rationale/Explanation of issue:
From Jari's position paper:
"- Identity request: In theory one might
think of a method that
requires a second identity
to be sent during its progress. However, I
think
this would complicate the protocol too much. Let's
just forbid
identity request in all other states than
Unauthenticated."
Resolution: Accept
Change:
" The Identity Type is used to query the identity of the
peer. The
Authenticator will typically issue this as the
initial Request. An
optional displayable message MAY be
included to prompt the Peer in
the case where there is an
expectation of interaction with a user. A
Response MUST be
sent to this Request with a Type of 1 (Identity)."
To:
"The Identity Type is used to query the identity of the peer.
The
Authenticator will typically issue this as the initial
Request;
however, an Identity Request MAY also be sent after completion
of
another method, and MAY be sent multiples times within a sequence
of
method. An Identity Request MUST NOT be sent in the middle of
another method
conversation.
An optional displayable message MAY be included within an
Identity
Request, to prompt the Peer in the case where there is an
expectation of interaction with a user. An Identity Response
MUST be
sent to an Identity Request. A peer MUST NOT respond
to an Identity Request
with a NAK.
Any executing method on the authenticator can be assumed to
have access
to the Identity Response(s) returned by the peer, even though
those
messages have Type = 1 (Identity). Since the Identity Request
is
often sent automatically by the authenticator, the Identity method
may
be thought of as residing within the EAP layer and providing
services to the
method layer.
Since Identity Requests and Responses are not protected,
from
a security perspective, it may be preferable for protected
method-specific Identity exchanges to be used instead.
Since sending of
Identity Requests by authenticators is optional,
implementations SHOULD
provide a way to configure the authenticator
so that Identity Requests are
not sent. However, it is possible that
a method residing on the authenticator
may depend on the Identity
Response, and and so authenticator implementations
SHOULD provide
a way for a method to invoke sending of the Identity Request,
in
case no method-specific identity exchange is supported, and a claim
of
identity is required."
Issue 40: Man-in-the-middle attacks on EAP method
sequences and tunnels
Submitter: Bernard Aboba
Submitter email
address: aboba@internaut.com
Date first submitted: October 21,
2002
Reference:
http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt
Document:
RFC2284bis-07
Comment type: T
Priority: S
Section:
7.4
Rationale/Explanation of issue:
When EAP methods are used as part of a sequence or within a
tunnel, RFC
2284 does not provide a mechanism to cryptographically
bind subsequent
authentication methods together.
The result of this is that neither side
of the conversation
has any assurance that they are talking to the same
endpoint
throughout the conversation, making EAP
implementations
vulnerable to a man-in-the-middle attack.
The problem
occurs on the peer, where a rogue NAS could
fool a peer into authenticating
to it, while acting as a
man-in-the-middle, and tunneling the peer's
authentication
to another authenticator.
The vulnerability also
exists on the server, where a proxy
can handle a portion of an authentication
sequence while
routing other portions to other servers.
With EAP being increasingly adopted across multiple media,
including
cellular, IEEE 802, and PPP, the need for such
a binding facility has become
critical.
Binding requires both sides to demonstrate that they
acted
as the endpoint for the sequence of authentication methods.
On the
peer, this implies that the same entity acted as
the peer in each of the
sequence of authentication mechanisms.
Similarly, on the authenticator,
binding implies that the
same entity acted as the authenticator in each
method within
the sequence.
There may be situations i