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 in which it may
not be desirable for
binding to be required. For example, the server may not
wish
to demonstrate binding, but may desire the client to do so.
Alternatively, the client may demand that the server demonstrate
binding.
As a result, some flexibility is required within the
binding facility.
Note that there are a number of choices as to how binding
might be
demonstrated:
a. Individual EAP methods may incorporate keys derived
from
previous methods in order to demonstrate not only possession
of a
shared secret, token or certificate, but possession of
previously derived
key(s) as well. However, this approach
has the disadvantage of requiring that
existing EAP methods
be modified to accomodate the binding facility. In many
cases
this will not be possible since those methods are already
developed
and deployed.
b. The binding facility can be provided within
individual
EAP methods. This has the advantage of not requiring
EAP
implementations to be upgraded, but has the disadvantage of
requiring
the same facility to be developed multiple times.
This would result in
overlapping effort as well as poor
interoperability among implementations.
c. The binding facility can be provided within EAP itself.
This has
the advantage of enabling widespread interoperability
between
implementations, and applicability to multiple EAP
methods. However, it has
the disadvantage of being harder
to deploy.
Suggested changes
Add Section 7.4:
7.4 Man-in-the-middle attacks
Where a sequence of methods is
utilized for authentication or is tunneled
within another protocol that
omits peer authentication, there exists a potential
vulnerability to
man-in-the-middle attack.
Where a sequence of EAP methods is utilized
for authentication, the peer might not have
proof that a single entity has
acted as the authenticator for all EAP methods within the
sequence. For
example, an authenticator might terminate one EAP method, then
forward the
next method in the sequence to another party without the peer's
knowlege or
consent. Similarly, the authenticator might not have proof that a
single
entity has acted as the peer for all EAP methods within the
sequence.
This enables an attack by a rogue EAP authenticator tunneling
EAP to a legitimate
server. Where the tunneling protocol is used for key
establishment but
does not require peer authentication, an attacker
convincing a legitimate peer
to connect to it will be able to tunnel EAP
packets to a legitimate
server, successfully authenticating and obtaining the
key. This allows the attacker
to successfully establish itself as a
man-in-the-middle, gaining access to the network,
as well as the ability to
decrypt data traffic between the legitimate peer and server.
This attack
may be mitigated by the following measures:
[a] Requiring mutual
authentication within EAP tunneling mechanisms.
[b] Requiring cryptographic
binding between EAP methods executed within a sequence or
between the EAP
tunneling protocol and the tunneled EAP methods.
[c] Limiting the EAP
methods authorized for use without protection based on peer
and authenticator
policy.
[d] Avoiding the use of sequences or tunnels when a single,
strong
method is available."
Proposed resolution: Accept
Issue 41: NAK of Extended Types
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: October 23, 2002
Reference:
Document: RFC2284bis-07
Comment
type: T
Priority: S
Section: 5.3
Rationale/Explanation of
issue:
Currently it is not possible to effectively NAK within the Extended EAP type
space.
For example, what happens when the authenticator proposes an
Extended or Vendor-Specific EAP
Type, and the client supports the Extended
type (255), but not the
vendorID or Extended Type that is being
proposed?
Here is the example Extended Type payload:
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=255
|
Vendor-Id
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Proposed
solution:
Change:
"Description
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.
Type-Data
This field MUST contain zero or more octets indicating the
desired
authentication Types, in order of preference, with the most
preferred
method first. In order to avoid an interminable negotiation, the
Peer
MUST only include Types that it is willing to accept."
To:
"Description
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
one
authentication Type desired by the peer. A Nak with no
authentication
Type 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.
Type-Data
Where the desired authentication Type is within the
original EAP Type
space (1-254), the Type-Data field, when present, MUST
contain a single octet
indicating the desired authentication
Type.
Where the desired
authentication Type is a method
within the extended EAP Type space
(Type=255), the Type-Data
field is formatted as follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
255
|
Vendor-Id
(optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type
(optional)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alternative resolution (from Paul Funk)
Date: Wed, 11 Dec 2002 20:20:58 -0500
From: Paul Funk
<paul@funk.com>
Subject: Proposed resolution of issue #41
Here
is a proposed resolution of issue 41 - Nak of extended types.
One thing I
learned while writing this proposal: the past tense of
Nak is "Nak'd", not
"Naked".
Interesting implications of this
proposal
---------------------------------------------------------
Note
that by using single-octet types and vendor-specific types
in an
interchangeable way, it is possible to extend EAP in all
kinds of ways
without breaking backward-compatibility. For example,
if the authenticator
starts the conversation with a vendor-specific
type (as indicated by the
first byte being 254), a legacy peer would
Nak but a new peer could respond
with a vendor-specific type
(possibly a v-s Nak). Once both parties are
talking vendor-specific,
anything is possible.
For example, the issue
of bi-directional success and failure packets
could be solved within this
context.
5.5.1 Vendor-Specific Nak
The Vendor-specific type
may be Nak'd in either of two ways: Legacy
Nak or Vendor-specific
Nak
5.5.1.1 Legacy Nak
The Legacy Nak, consisting of a single
octet of value 3, is used to
reject Vendor-specific requests entirely. This
type of Nak indicates
that the Vendor-specific type itself is unacceptable to
the peer.
This type of Nak provides backward compatibility for peers
that
implement RFC2284 or earlier.
Peer implementations that do
support the Vendor-specific type SHOULD
NOT use this type of Nak, even as a
shortcut to rejecting all possible
Vendor-specific methods at once. Future
specifications may depend on
an authenticator being able to recognize the
implementation level of
the peer, and eliciting a Nak may provide a means of
doing this.
5.5.1.2 Vendor-specific Nak
The Vendor-specific Nak is
a Nak within a Vendor-specific type with
Vendor-Id of 0, as shown
below:
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 = 254
|
Vendor-Id =
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type =
3
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Desired Types
...
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Desired
Types field contains zero or more Vendor-specific
Types, in order of
preference, with the most preferred method
first; each Type is In order to
avoid an interminable negotiation,
the Peer MUST only include Types that it
is willing to accept.
Each Type in the Desired Types field MUST be in the
form of a
Vendor-specific Type, even if it is a Type from the
original
namespace 1 - 255.
The Vendor-specific Nak allows individual
authentication methods
expressed as Vendor-specific Types to be Nak'd,
without rejecting
the Vendor-specific Type in general. In addition, it
permits the
peer to list any authentication type -- whether IETF- or
vendor-
defined -- as acceptable.
An example of a Vendor-specific Nak
indicating that MD5-Challenge
would be acceptable is shown
below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
254
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
3
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
4
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Paul
Funk
Funk Software, Inc.
617 497-6339
paul@funk.com
More Discussion [Response from Bernard Aboba]
Date: Sat, 14 Dec 2002 19:49:59 -0800 (PST)
From: Bernard Aboba
<aboba@internaut.com>
To: Paul Funk <paul@funk.com>
Cc:
eap@frascone.com
Subject: Re: Proposed resolution of issue #41
> 1
I changed 255 to 254, on the theory that experimental use of
> EAP using
type 255 is legacy behavior that should not be broken.
Good idea. We had
agreed at IETF 55 to add an experimental Type.
So 255 will be the
Experimental Type, and 254 will be for extended
Types.
> 2 The
original Vendor-specific type has everything after the
> Vendor-Type
immediately following (RADIUS-style). I changed that
> to make the format
uniform (Diameter-style), so all v-s types have
> a fixed format that
includes Vendor-Type and are thus interpretable
> by anyone.
This
is also a good idea -- the Vendor-Type field as a fixed format of 4
octets as
opposed to being of vendor-defined size.
> Since Vendor-type is used
as part of the protocol when
> Nak'ing, it's best to make sure everyone
uses it the same way. I
> don't believe this limits vendor
flexibility.
Yes.
> if the authenticator starts the
conversation with a vendor-specific
> type (as indicated by the first byte
being 254), a legacy peer would
> Nak but a new peer could respond with a
vendor-specific type
> (possibly a v-s Nak). Once both parties are talking
vendor-specific,
> anything is possible.
I assume that if the
authenticator begins with a V-S type (254), then the
legacy peer would NAK
with a single type within the standard space
(4-192).
The RFC 2284bis
Peer would respond with:
a. A list of extended types with a single
vendorid?
b. A mixture of extended types with different vendorids?
c. Some
mixture of standard and extended types?
I wasn't clear what you are
advocating in your proposal.
> 5.5.1.1 Legacy Nak
>
> The
Legacy Nak, consisting of a single octet of value 3, is used to
> reject
Vendor-specific requests entirely.
Type=3 is NAK. If you wanted to reject
Vendor-Specific requests, why
wouldn't the Legacy client NAK with the type of
the method it prefers?
> This type of Nak provides backward
compatibility for peers that
> implement RFC2284 or earlier.
RFC
2284 states:
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 the authentication Type desired by the peer.
So a NAK
with a Type=3 in the data field is not legal in a
legacy
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 = 254
|
Vendor-Id =
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type =
3
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Desired Types
...
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A
Vendor-Id = 0 is used to extend the "standard" type space. So presumably
this
example packet would only be able to indicate the desire to use
alternative
"standard" types, no? Why is a Vendor-Type=3 required to do
this? couldn't
the desired types (4 octets) each just be included in a
list fter the initial
4 octets?
> The Desired Types field contains zero or more
Vendor-specific
> Types, in order of preference, with the most preferred
method
> first
How can Vendor-Specific types be indicated if the
Vendor-Id is always = 0
(IETF standard extension space). Or can the Vendor-Id
field contain
another value, too? What if the client needs to indicate the
desire to do
some mixture of IETF standard and Vendor-Specific Types? Is
stacking
possible?
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
254
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
3
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
4
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Why
couldn't this be indicated by the following payload:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
254
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
And
as an example, could we indicate a preference for Vendor-Id=311, Type
= 15,
and then EAP-MD5 as follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
254
|
311
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
15
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
254
|
0
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
4
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Further discussion from Paul Funk]
>OK. Can the RFC 2248bis Peer respond with an extended Nak to an offer
of a
>standard (1-255) type from a legacy peer? I think the answer
is
>yes, since it is assumed that the legacy peer will ignore
everything
>except the first octet of the type-data (254). It will
either counter with
>another offer within the standard space, or
send an EAP Failure.
Actually, I think it can't. The extended Nak
starts with an 8-octet, not
a 1-octet, Nak. So the type of the packet looks
like 254 to the legacy
authenticator, and it won't understand it at
all.
If the 2284bis Peer gets a request in non-extended form, it doesn't
know if
the Authenticator is legacy or 2284bis. It should therefore Nak in
non-
extended form as well. If it supports authentication types in the
extended
space, it can include a 254 as a desired type. If the Authenticator
is
legacy, the 254 would be disregarded. If the Authenticator is 2284bis,
the
presence of 254 in a Nak (even if single-octet) indicates that the Peer
is
2284bis, so its next request can be in extended form. Once the Peer
receives the extended form request, it then Nak extended types
precisely, since it now knows the Authenticator is also 2284bis.
A
2284bis Authenticator could take the approach of always issuing an
extended
request first, even if the authentication method is a standard
one such as
MD5-Challenge. If the Peer is pre-2284bis it will issue a
legacy Nak and the
Authenticator will drop down to legacy operation. If
the Peer is 2284bis, it
can respond with an extended Nak. This approach
may cost a round trip when
the Peer is pre-2284bis, but when the Peer
is 2284bis it provides a cleanest
negotiation and may save a round trip.
>
>> Nak is
represented as an extended (vendor-specific) type: the
initial
>> 254 indicates that
>
>The
problem is that the state machine only allows an initial
Request
>(offer) of a given Type to be answered by a Response of
that same Type
>(offer acceptance) or a Nak (Type 3). Allowing it
to be answered by
>a Response of either Type 3 or 254 complicates
the state machine.
I would suggest that we don't consider 254 a
"type". It is really like an
escape character. So if we understand "type" to
be a code point in a
7-octet space composed of vendor-id and ordinal, and
that this code
point can be represented in either 1 octet or 8 octets (where
the 1 octet
version has limited span), I think the problem goes
away.
>
>> Your two examples are correct, except
for the omission of the extended Nak
>> type
itself.
>
>OK. So we're talking about whether a Type
of 254 or 3 is used for the NAK
>packet itself. Essentially, you
are defining a new NAK packet of Type 254,
>and I was talking about
extended the old NAK packet of Type
3.
Yes.
>
>> An example is shown below
of a Vendor-specific Nak indicating
>> the acceptability of two
authentication types: (1) MD5-Challenge,
>> and (2) a
hypothetical type 15 defined by a (not-so-hypothetical)
>>
vendor with id 311:
>>
>>
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
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
| 254
|
Vendor-Id = 0
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
|
Vendor-Type = 3
(Nak)
|
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
| 254
|
Vendor-Id = 0
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
|
Vendor-Type = 4 (MD5-Challenge)
|
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
| 254
|
Vendor-Id = 311
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
|
Vendor-Type =
15
|
>>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>Thanks.
>
>Question
-- are there things that you can do by defining a new NAK
packet
>that you couldn't do by extending the old one? In the case
given above the
>functionality is similar -- but I assume that the
added overhead is also
>meant to provide some additional
flexibility.
Actually, I don't think of this as defining a new Nak
packet, but extending
the interpretation of the Nak element.
The
purpose of the extended Nak packet is to provide backward
compatibility
while preserving equivalent functionality across the entire
spectrum of
types.
This could have be done in a number of ways; any mechanism would
have
to be examined to make sure there are no avenues for misinterpretation
due to different versions of the standard being supported on Peer and
Authenticator.
The mechanism of defining an extended type space that
comprises
the original type space seemed to me the least arbitrary, and
easily
verified to be harmless to existing implementations.
I think
any added flexibility it provides relates to the ability of a 2284bis
Peer
and 2284bis Authenticator to discover that they are both indeed 2284bis,
even if they are using a standard protocol such as MD5-Challenge. If we
want to add any new features to the protocol, such as Peer response
to
EAP-Success, this could be the avenue to do this without breaking
existing
implementations.
Paul
Paul Funk
Funk Software, Inc.
617
497-6339
paul@funk.com
[BA] -
At the risk of misunderstanding Paul's suggested fix once again, I
would
like to submit the following potential resolution of Issue 41.
This
involves replacing the current Section 5.3 with the
following:
5.3. Nak
5.3.1 Legacy Nak
Description
The
legacy Nak Type is valid only in Response messages. It is sent
in reply to a
Request where the desired authentication Type is
unacceptable. Authentication
Types are numbered 4 and above.
The Response contains one or more
authentication Types desired
by the Peer. Type zero (0) is used to indicate
that the sender
has no viable alternatives.
Since the legacy 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.
Code
2 for Response.
Identifier
The
Identifier field is one octet and aids in matching Responses
with Requests.
The Identifier field of a legacy Nak Response
MUST match the Identifier field
of the Request packet that it
is sent in response
to.
Length
>=6
Type
3
Type-Data
Where
any peer receives a Request for an unacceptable Type in the
range
(1-253,255), or a peer lacking support for expanded Types
receives a Request
for Type 254, a legacy Nak Response MUST be sent. The
Type-Data field of the
legacy Nak Response MUST contain one or more
octets indicating the desired
authentication Type(s), one octet per
Type, or the value zero (0) to indicate
no proposed alternative. A
peer supporting expanded Types that receives a
Request for an
unacceptable Type (1-253, 255) MAY include the value 254
in
the legacy Nak Response in order to indicate the desire for
an expanded
authentication Type. If the authenticator can accomodate
this preference, it
will respond with an expanded Type Request.
5.3.2 Expanded
Nak
Description
The expanded Nak Type is valid only in Response
messages. It MUST
be sent only in reply to a Request of Type 254 (expanded
Type)
where the authentication Type is unacceptable. The expanded Nak
Type
uses the expanded Type format itself, and the Response
contains one or more
authentication Types desired by the peer,
all in expanded Type format. Type
zero (0) is used to indicate
that the sender has no viable
alternatives.
Since the expanded 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.
Code
2 for Response.
Identifier
The
Identifier field is one octet and aids in matching Responses
with Requests.
The Identifier field of a expanded Nak Response
MUST match the Identifier
field of the Request packet that it
is sent in response
to.
Length
>=40
Type
254
Vendor-Id
0
(IETF)
Vendor-Type
3 (Nak)
Vendor-Data
The expanded
Nak Type is only sent when the Request contains an
expanded Type (254) as
defined in Section 5.7. The Vendor-Data
field of the Nak Response MUST
contain one or more authentication
Types (4 or greater), all in expanded
format, 8 octets per Type,
or the value zero (0), also in expanded Type
format, to indicate
no proposed alternative. The desired authentication Types
may
include a mixture of Vendor-Specific and IETF Types. For example,
an
expanded Nak Response indicating a preference for OTP (Type 5),
and an MIT
(Vendor-Id=20) Vendor-Specific Type of 6 would
appear as
follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
2 | Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=254
|
0
(IETF)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
3
(Nak)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=254
|
0
(IETF)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
5
(OTP)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=254
|
20
(MIT)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
6
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An
expanded Nak Response indicating a no desired alternative
would appear as
follows:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
2 | Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=254
|
0
(IETF)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
3
(Nak)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=254
|
0
(IETF)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
0 (No Alternative)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Date: Sun, 09 Feb 2003 19:26:14 -0500
From: Paul Funk
<paul@funk.com>
To: Bernard Aboba <aboba@internaut.com>,
eap@frascone.com
Subject: Re: Potential resolution of Issue 41: Expanded
Nak
Bernard,
Yes, this is exactly what I had in mind.
You
use the term "expanded type" to refer to 254, but section 5.7
defines
"vendor-specific type" to mean the same thing. I prefer
"expanded type" and
would suggest updating 5.7 with that term.
Paul
Recommended Resolution: Accept
Issue 42: EAP Enhancements
Submitter: Tena
Tsou
Submitter email address: tena@huawei.com
Date first submitted:
November 5, 2002
Reference:
Document: RFC2284bis-07, 802.1aa
D3
Comment type: T
Priority: S
Section:
Many
Rationale/Explanation of issue:
Supplementary Comment to IEEE P802.1aa
Add this section to the end of Section 8.4:
1.1.1. Handshaking mechanism
The Authenticator should be able to detect users’ abnormal disconnection and provide the online users and charging information as precise as possible. The Authenticator should support the handshaking mechanism with the Supplicant. During the handshaking, the controlled ports keep the authorized status, until the handshaking fails, then the controlled ports turn to the unauthorized status.
The Authenticator uses EAP-Request/Identity as the handshaking request packet, and the Supplicant uses EAP-Response/Identity as the handshaking response packet.
It is recommended to set the range allowed for the handshaking period (must be configurable) to 5-90s, and its default value to 15s. Moreover, the handshaking period should be less than the parameter value of authPeriod when the Supplicant PAE performs re-authentication for the timer authWhile (see IEEE std 802.1X-2001, 8.5), and the recommended parameter value of authPeriod is as twice as the handshaking period at least.
The maximum times of handshaking should be configurable and the recommended value is 3.
The requirements on 802.1X Supplicant:
The following should be added to the end of the Section 7.7.4 (see the red below):
EAP packet format
When the protocol field of the PPP frame (see IETF RFC 1661) indicates that the protocol type is C227 (PPP EAP), only one PPP EAP packet is encapsulated in the Information field of the frame in PPP data link layer. The format of EAP packet is shown in Figure A-1.Each field is transmitted from left to right one by one.
The Code field is one octet in length and identifies the type of EAP packet. EAP Codes are assigned as follows:
1 Request
2 Response
3 Success
4 Failure
The Identifier filed is one octet in length and allows matching of Response with Request. The Identifier field and System Port together uniquely identify an authentication exchange. Thus, the use of a single octet identifier field results in a restriction of 256 authentications per System Port.
The operation of the Authenticator PAE determines the value of Identifier used in the EAP-Request/Identify packets. The Supplicant PAE uses the same Identifiers in subsequent EAP-Request/Identify packets responding to that initial frame. The Authenticator PAE uses the same Identifier value in any re-transmissions of the same request.
The Length field is two octets in length and indicates the length of the EAP packet, including the Code, Identifier, Length, and Data fields.
The Data field is zero or more octets. The format of the Data field is determined by the Code field.
The Type field is one octet and mainly defines various authentication mechanisms. The Type values in ITEF RFC 2284 include the first six of the following. As required, the No. 7 and 8 Type values are added into this standard. The Type values 1~2, 4~7 and 13 apply to the Request and Response packet, the Type value 3 only applies to the Response packet and the Type value 8 only applies to the Failure packet.
1 Identity
2 Notification
3 Nak (Response only)
4 MD5-Challenge
5 One-Time Password (OTP) (RFC1938)
6 Generic Token Card
7 PAP
8 CauseCode
The Identity type is used to query the user’s status. Each Identity type of Request packet should correspond to an Identity type of Response packet.
A.1.6. Notification
The Notification type is used to send an on-screen message from the Authenticator to the Supplicant. The Supplicant should display the message for the users. If it can not be displayed, it should be recorded into the log.
Each Notification type of Request packet should correspond to a Notification type of Response packet.
A.1.7. Nak
The Nak type only applies to the Response packet. When the expected authentication mechanism in the Request packet is not accepted, the Nak type of Response packet should be sent.
A.1.8. MD5-Challenge
The MD5-Challenge type is similar to the MD5 in CHAP protocol (see IETF RFC 1994). The MD5-Challenge type of Request packet includes the Challenge message. Each MD5-Challenge type of Request packet should correspond to an MD5-Challenge type or a Nak type of Response packet.
A.1.9. One-Time Password
The One-Time Password type of Request packet includes an OTP Challenge. Each One-Time Password type of Request packet should correspond to a One-Time Password type or a Nak type of Response packet.
Refer to IETF RFC 1938 for more information about One-Time Password System.
A.1.10. Generic Token Card
The Generic Token Card type is defined for the users to enter various Token Card messages. The Generic Token Card type of Request packet includes an ASCII text message, and the corresponding Generic Card type of Response packet includes the necessary information related to the Token Card. Usually the information is read by the users from the Token Card device and is entered in ASCII text.
A.1.11. PAP
The PAP type is similar to the PPP PAP protocol. The difference is that the PPP PAP must be originated by the Supplicant, while the PAP in EAP can be originated by the Authenticator. In the Request packet, use the No.7 type value to originate the PAP authentication and request the password of the other party. The password is sent in plain text on the network. Each PAP type of Request packet should correspond to a PAP type or a Nak type of Response packet.
The CauseCode type is used to give the failure causes of authentication for the Supplicant. The CauseCode Values give the failure causes.
The CauseCode Values include the following eight types:
1 Name-Pwd-Failure Incorrect user name and the password
2 IdleCut Idle cut logoff
3 TimeCut Time restriction cut off
4 FlowCut Flow restriction cut off
5 Supplicant-Logoff Supplicant logoff actively
6 Supplicant-Restart Supplicant restarting
7 Reauthen-Failure Re-authentication failure
8 Other-Failure Other causes of failure
Tena Tsou
Signalling and Protocol
Department, R&D
Huawei Tech.
Tel:86-755-26516939
tena@huawei.com
Recommended Resolution: Reject
Detection of disconnection is the responsibility of the link layer
and is
not an appropriate function for EAP, which focusses on
authentication.
RFC 2284 does not include support for PAP, since this represents
an
unacceptable security risk. Not only would PAP result in potential
compromise
of the password when used within EAP, but since the
EAP-Message attribute is
not encrypted within RADIUS, it would also
expose the password between the
NAS and RADIUS server.
The Cause Code values can be accomodated within
EAP Notification
and therefore addition of another EAP method is not
required.
Issue 43: Security Claims
Submitter: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
November 25, 2002
Reference:
Document: RFC2284bis-07
Comment type:
T
Priority: S
Section: 6
Rationale/Explanation of issue:
RFC 2284bis does not include definitions of Security Claims or
guidance
as to how they are to be treated.
Proposed change:
Delete Section
7.2, and add the following sections to Section 6:
6.3. Security
claims
In order to clearly articulate the security provided by an EAP
method,
EAP method specifications accompanying a request for allocation of
a
Type code MUST include the following declarations:
[a] Intended use.
This includes a statement of whether the method is
intended for use over a
physically secure or insecure network, as
well as a statement of the
applicable media.
[b] Mechanism. This is a statement of the
authentication technology:
certificates, pre-shared keys, passwords, token
cards, etc.
[c] Security claims. This is a statement of the claimed
security
properties of the method, using terms defined in the next
section.
The Security Claims section SHOULD include references to proof,
or
the proof itself (preferrably in an Appendix).
[d] Key strength. If
the method derives keys, then the effective key
strength MUST be
provided.
[e] Description of key hierarchy. EAP methods deriving keys
MUST either
provide a reference to a key hierarchy specification, or
describe
how keys for authentication/integrity, encryption and IVs are to
be
derived from the provided keying material, and how
cryptographic
separation is maintained between keying material used for
different
purposes.
[f] Indication of vulnerabilities. In addition to
the security claims
that are made, the specification MUST indicate which of
the
security claims detailed in the next section are NOT being made,
and
discuss the security implications.
6.4. Security terms
Mutual
authentication
This refers to an EAP method in which, within an
interlocked
exchange, the authenticator authenticates the peer and
the
peer authenticates the authenticator. Two one-way
conversations,
running in opposite directions do not provide
mutual authentication as
defined here.
Integrity protection
This refers to per-packet
authentication and integrity
protection of EAP packets, including EAP
Requests and
Responses, and method-specific success and
failure
indications. When making this claim, a method specification
MUST
describe the fields within the EAP packet that are
protected.
Replay
protection
This refers to protection against replay of EAP
messages,
including EAP Requests and Responses, and
method-specific
success and failure
indications.
Confidentiality
This refers to encryption of EAP
messages, including EAP
Requests and Responses, and method-specific success
and
failure indications. A method making this claim MUST support
identity
protection.
Key derivation
This refers to the ability of the EAP
method to derive a
Master Key which is not exported, as well as a
ciphersuite-
independent Master Session Keys. Both the Master Key
and
Master Session Keys are used only for further key derivation,
not
directly for protection of the EAP conversation or
subsequent
data.
Key strength
This refers to the effective entropy of the derived
Master
Session Keys, independent of their physical length. For
example, a
128-bit key derived from a password might have an
effective entropy much less
than 128 bits.
Dictionary attack resistance
Where password
authentication is used, users are notoriously
prone to selection of poor
passwords. A method may be said to
be dictionary attack resistant if, when
there is a weak
password in the secret, the method does not allow an
attack
more efficient than brute force.
Fast reconnect
The ability,
in the case where a security association has been
previously established, to
create a new or refreshed security
association in a smaller number of
round-trips.
Man-in-the-Middle resistance
The ability for the peer to
demonstrate to the authenticator
that it has acted as the peer for each
method within a
sequence of methods or tunnel. Similarly, the
authenticator
demonstrates to the peer that it has acted as
the
authenticator for each method within the sequence or tunnel.
If this
is not possible, then the authentication sequence or
tunnel may be vulnerable
to a man-in-the-middle attack.
Acknowledged result indications
The
ability of the authenticator to provide the peer with an
indication of
whether the peer has successfully authenticated
to it, and for the peer to
acknowledge receipt, as well as
providing an indication of whether the
authenticator has
successfully authenticated to the peer. Since EAP Success
and
Failure packets are neither acknowledged nor integrity
protected, this
claim requires implementation of a method-
specific result exchange that is
integrity protected.
Issue 44: Peer-to-Peer Operation of
EAP
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: November 25,
2002
Reference:
Document: RFC2284bis-07
Comment type: T
Priority:
S
Section: 2
Rationale/Explanation of issue:
Since EAP is a peer-to-peer protocol, this should be added to
the
description of how the protocol operates.
Add the following text
to section 2:
"[7] Since EAP is a peer-to-peer protocol, after authentication in
one
direction is complete, the direction of authentication
MAY reverse,
with the endpoint previously serving as the Authenticator
assuming the Peer
role, and the former Peer now taking on the Authenticator
role. As with the
original conversation, the reversal is signaled by the
(new) Authenticator
sending a Request."
Issue 45: Addition of OTP and GTC
methods
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: November 25,
2002
Reference:
Document: RFC2284bis-07
Comment type: T
Priority:
S
Section: 2
Rationale/Explanation of issue:
Now that RFC 2284bis is merely recycling to Proposed Standard,
there is
no reason to separate out the OTP and GTC methods.
Also, the OTP
reference in RFC 2284 is now out of date.
Add the following
sections:
One-Time Password (OTP)
Description
The
One-Time Password system is defined in "A One-Time Password
System" [RFC2289]
and "OTP Extended Responses" [RFC 2243].
The Request contains a displayable
message
containing an OTP challenge.
A Response MUST be sent in reply
to
the Request. The Response MUST be of Type 5 (OTP) or Type 3
(Nak). The
Nak reply indicates the peer's desired authentication
mechanism
Type(s).
Type
5
Type-Data
The Type-Data field
contains the OTP "challenge" as a displayable
message in the Request. In the
Response, this field is used for
the 6 words from the OTP dictionary
[RFC2289]. The messages MUST not be
null terminated. The length of the field
is derived from the
Length field of the Request/Reply packet.
Security Claims
Intended use: Wired networks, including PPP, PPPOE, and
IEEE 802.
Use over the Internet or with
wireless only when protected.
Mechanism:
One-Time Password
Mutual auth: No
Integrity prot: No
Replay prot:
No
Confidentiality: No
Key Derivation: No
Key strength:
N/A
Dictionary attack prot: No
Key hierarchy: N/A
Fast reconnect:
No
MiTM resistance: No
Acknowledged S/F: No
Generic Token Card
(GTC)
Description
The Generic Token Card Type is defined for use
with various Token
Card implementations which require user input. The
Request
contains a displayable message and the Reply contains the
Token
Card information necessary for authentication. Typically, this
would
be information read by a user from the Token card device and
entered as ASCII
text.
Type
6
Type-Data
The Type-Data field in the
Request contains a displayable message
greater than zero octets in length.
The length of the message is
determined by Length field of the Request
packet. The message
MUST not be null terminated. A Response MUST be sent in
reply to
the Request with a Type field of 6 (Generic Token Card).
The
Response contains data from the Token Card required
for
authentication. The length is of the data is determined by the
Length
field of the Response packet.
Security Claims
Intended use: Wired networks, including PPP, PPPOE, and
IEEE 802. Use over
the Internet or with
wireless only when protected.
Mechanism: Hardware
token.
Mutual auth: No
Integrity prot: No
Replay prot:
No
Confidentiality: No
Key Derivation: No
Key strength:
N/A
Dictionary attack prot: No
Key hierarchy: N/A
Fast reconnect:
No
MiTM resistance: No
Acknowledged S/F: No
Issue 46: Passthrough
clarification
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: November 25,
2002
Reference:
Document: RFC2284bis-07
Comment type: T
Priority:
S
Section: 2
Rationale/Explanation of issue:
There is some confusion about whether a AAA Server is
always required for
use with EAP and whether an
Authenticator MUST be a "passthrough" for all
traffic
or no traffic.
Insert the following paragraph in Section
2:
"Since a backend authentication server is optional,
an
Authenticator MAY implement one or more authentication
methods locally in
order to authenticate local users.
An Authenticator MAY act as a "pass
through" for non-local
users and authentication methods it does not
implement,
while at the same time authenticating local users with native
methods."
Proposed resolution: Accept
Issue 47: Keying requirements not
specified
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: December 5,
2002
Reference:
Document: Keys-04
Comment type: T
Priority:
S
Section: Many
Rationale/Explanation of issue:
The document does not describe what an EAP method MUST do in
order to
provide satisfactory keys for various uses. For
example:
* What is the
expected length of keying material provided
in the Pairwise Master Key (PMK)
passed from the EAP method
to the EAP layer, and transferred across in the
AAA keying
attributes?
* What is the expected entropy of the keying
material?
* Is a nonce exchange required within the EAP method
in
order to guarantee sufficient entropy?
[Bernard Aboba] This problem is largely resolved in Issue 176. I
propose
to replace Section 4.2.1 with the following text taken from RFC
2284bis Section
7.10:
"It is possible for the peer and EAP server to
mutually
authenticate and derive keys. In order to provide
keying
material for use in a subsequently negotiated
ciphersuite, an EAP method
supporting key derivation MUST
export a Master Session Key (MSK) of at least
64 octets,
and an Extended Master Session Key (EMSK) of at least
64
octets. EAP Methods deriving keys MUST provide for mutual
authentication between the EAP peer and the EAP Server.
The MSK and
EMSK MUST NOT be used directly to protect data;
however, they are of
sufficient size to enable derivation
of a AAA-Key subsequently used to
derive Transient Session
Keys (TSKs) for use with the selected ciphersuite.
Each ciphersuite is responsible for specifying how to
derive the TSKs
from the AAA-Key.
The AAA-Key is derived from the keying material
exported by the
EAP method (MSK and EMSK). This derivation occurs on the AAA
server.
In many existing protocols that use EAP, the AAA-Key and MSK
are
equivalent, but more complicated mechanisms are possible
(see Appendix E for
details).
EAP methods SHOULD ensure the freshness of the MSK and EMSK
even in cases
where one party may not have a high quality random number
generator. A
RECOMMENDED method is for each party to provide a nonce of
at
least 128 bits, used in the derivation of the MSK and EMSK.
EAP
methods export the MSK and EMSK and not Transient
Session Keys so as to
allow EAP methods to be ciphersuite
and media independent. Keying material
exported by EAP
methods MUST be independent of the ciphersuite negotiated
to protect data.
Depending on the lower layer, EAP methods may
run
before or after ciphersuite negotiation, so that the
selected
ciphersuite may not be known to the EAP method.
By providing keying material
usable with any ciphersuite,
EAP methods can used with a wide range of
ciphersuites and
media.
It is
RECOMMENDED that methods providing
integrity protection of
EAP packets include coverage of all the EAP header
fields,
including the Code, Identifier, Length, Type and Type-Data
fields.
In order to preserve algorithm independence, EAP methods
deriving keys SHOULD support (and document) the protected
negotiation of
the ciphersuite used to protect the
EAP conversation between the peer and
server. This is
distinct from the ciphersuite negotiated between the peer
and
authenticator, used to protect data.
The strength of Transient
Session Keys (TSKs) used to protect
data is ultimately dependent on the
strength of keys generated
by the EAP method. If an EAP method cannot produce
keying material of
sufficient strength, then the TSKs may be subject to brute
force attack.
In order to enable deployments requiring strong keys, EAP
methods
supporting key derivation SHOULD be capable of generating an
MSK
and EMSK, each with an effective key strength of at least 128 bits.
Key
Strength issues are discussed in Section 6.1.
Methods supporting key
derivation MUST demonstrate
cryptographic separation between the MSK and
EMSK branches of the EAP key hierarchy. Without
violating a fundamental
cryptographic assumption
(such as the non-invertibility of a one-way
function)
an attacker recovering the MSK or EMSK MUST NOT
be able to
recover the other quantity with a level
of effort less than brute force.
Non-overlapping substrings of the MSK MUST be
cryptographically
separate from each other.
That is, knowledge of one substring
MUST NOT
help in recovering some other substring without
breaking some hard
cryptographic assumption. This is required
because some existing
ciphersuites form TSKs by simply
splitting the AAA-Key to pieces of
appropriate length.
Likewise, non-overlapping substrings of the EMSK MUST
be cryptographically separate from each other, and
from substrings of
the MSK.
The EMSK MUST remain on the EAP peer and EAP server
where it
is derived; it MUST NOT be transported to, or
shared with, additional
parties, or used to derive any other
keys.
Since EAP does not
provide for explicit key lifetime
negotiation, EAP peers, authenticators and
authentication
servers MUST be prepared for situations in which one or
parties discard key state which remains valid on another
party.
The development and validation of key derivation algorithms is
difficult,
and as a result EAP methods SHOULD reuse well established and
analyzed
mechanisms for key derivation (such as those specified in IKE
[RFC2409] or
TLS [RFC2246]), rather than inventing new ones. EAP methods
SHOULD also
utilize well established and analyzed mechanisms for MSK and
EMSK
derivation."
Proposed resolution: Accept
Issue 48: Role Reversal not
supported
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: December 5,
2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority:
S
Section: Many
Rationale/Explanation of issue:
EAP is a peer to peer protocol in which role reversal can occur,
but RFC
2869bis does not discuss this. For example, what happens
if a Client sends an
EAP-Request to a NAS? Does the NAS pass this
through in a RADIUS
Access-Request? What if the RADIUS server
doesn't support role reversal?
Issue 49: Spoofing of EAP
Success/Failure
Submitter: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: December 11,
2002
Reference:
Document: RFC2284bis-08
Comment type: T
Priority:
S
Section: 2.1
Rationale/Explanation of issue:
The text in section 2.1 does not provide protection against spoofing of EAP
Failure.
In Section 2.1, Change:
"Within EAP, success and
failure indications may be protected or
unprotected. Unless protected by an
underlying link layer ciphersuite,
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.
In the absence of a protected EAP
layer indication, unprotected 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. 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.
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."
To:
"4.2.1. Processing of success and
failure
Within EAP, success and failure indications consist of the EAP
Success
and Failure messages, as well as method-specific indications.
Within
EAP, these indications may be protected or unprotected.
EAP
Success and Failure packets are considered unprotected indications
which may
be spoofed, since as described in Section 4.2, they contain no
message
integrity check (MIC).
In order to provide additional protection against
tampering, EAP methods
MAY support a MIC that covers some or all of the EAP
packet, including
headers. In addition, such a MIC MAY include coverage of
previous
Request and Response messages, so as to enable protection of
other
packets to that do not contain MICs, such as Identity
Request/Response,
Notification Request/Response and Nak Response.
EAP
methods also MAY include support for method-specific acknowledged
success and
failure indications. This enables the authenticator to
indicate whether the
peer has successfully authenticated, as well as for
the peer to acknowledge
receipt of that indication, and respond with an
indication of whether the
authenticator has successfully authenticated
to the peer. If a key has
previously been derived, the result exchange
MAY be protected by a Message
Integrity Check (MIC), and if so, then
this success/failure indication is
considered protected.
In order to decrease vulnerability to spoofing of
success and failure
indications, the following processing rules are
recommended:
[a] Processing of protected success and failure indications.
Where a
method-specific protected success/failure indication has
been
received, the implementation MUST validate the EAP method MIC, with
a
MIC failure handled via silent discard, as specified in
Section
4.1.
[b] Receipt of EAP Success and Failure packets prior to
method
completion. A peer EAP implementation receiving an EAP
Success
packet prior to completion of the method in progress MUST
silently
discard it. This ensures that a rogue authenticator will not
be
able to bypass mutual authentication by sending an EAP Success
prior to
conclusion of the EAP method conversation. A peer EAP
implementation
receiving an EAP Failure packet prior to completion
of the method in progress
MAY silently discard it. When using EAP
methods that provide their own
(protected) error indications,
premature EAP Failure packets are unexpected,
so that this
technique may be more readily employed.
[c]
Authentication requirement. An EAP peer implementation that has
been
configured to require authentication MUST silently discard a
"canned" EAP
Success message (an EAP Success message sent
immediately upon
connection).
[d] Contradictory indications. Where protected and
unprotected result
indications are both available, protected indications
take
precedence. For example, where an EAP method provides a
protected
indication that authentication failure has occurred in
either
direction, the implementation MUST silently discard subsequent
EAP
Success packets. Similarly, where an EAP method provides a
protected
indication that authentication has succeeded in both
directions, the EAP
implementation MAY silently discard EAP Failure
packets.
[e]
Processing of EAP Success and Failure in the absence of
protected
indications. Subsequent to the completion of the EAP
authentication
method (Types 4 and greater), and in the absence of
protected
result indications, EAP Success and Failure packets MUST
be
accepted and processed by the EAP implementation."
Proposed
Resolution: Accept
Issue 50: Media requirements
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: December 11, 2002
Reference:
Document: RFC2284bis-08
Comment
type: T
Priority: S
Section: 3
Rationale/Explanation of
issue:
It has been pointed out that EAP methods such as EAP-TLS [RFC2716]
assume
reliability and non-duplication at the EAP layer, equivalent
to what is
provided by TCP or SCTP. As a result, MIC verification
errors are fatal in
EAP TLS. Therefore, if EAP is run
over media without a CRC, MIC verification
errors will be frequent
and performance will be suboptimal. Therefore, a
lower layer CRC or checksum
is implicitly assumed.
Change Section
3 to the following:
"3. Lower layer behavior
3.1. Lower layer requirements
EAP
makes the following assumptions about lower layers:
[1] Lower layer CRC
or checksum. In EAP, the authenticator retransmits
Requests that have not yet
received Responses, so that EAP does not
assume that lower layers are
reliable. Since EAP defines its own
retransmission behavior, when run over a
reliable lower layer, it
is possible (though undesirable) for retransmission
to occur both
in the lower layer and the EAP layer.
If lower layers
exhibit a high loss rate, then retransmissions are
likely, and since EAP
Success and Failure are not retransmitted,
timeouts are also likely to
result. EAP methods such as EAP TLS
[RFC2716] include a message integrity
check (MIC) and regard MIC
errors as fatal. Therefore if a checksum or CRC is
not provided by
the lower layer, then some methods may not behave
well.
[2] Lower layer data security. After EAP authentication is
complete,
the peer will typically transmit data to the network, through
the
authenticator. In order to provide assurance that the
peer
transmitting data is the one that successfully completed
EAP
authentication, it is necessary for the lower layer to provide
per-
packet integrity, authentication and replay protection that is
bound
to the original EAP authentication, or for the lower layer to
be physically
secure. Otherwise it is possible for subsequent data
traffic to be hijacked,
or replayed.
As a result of these considerations, EAP SHOULD be used
only when
lower layers provide physical security for data (e.g. wired PPP
or
IEEE 802 links), or for insecure links, where
per-packet
authentication, integrity and replay protection is provided.
Where
keying material for the lower layer ciphersuite is itself
provided
by EAP, typically the lower layer ciphersuite cannot be
enabled
until late in the EAP conversation, after key derivation
has
completed. Thus it may only be possible to use the lower
layer
ciphersuite to protect a portion of the EAP conversation, such
as
the EAP Success or Failure packet.
[3] Known MTU. The EAP layer
does not support fragmentation and
reassembly. However, EAP methods SHOULD be
capable of handling
fragmentation and reassembly. As a result, EAP is capable
of
functioning across a range of MTU sizes, as long as the MTU
is
known.
[4] Possible duplication. Where the lower layer is reliable,
it will
provide the EAP layer with a non-duplicated stream of
packets.
However, while it is desirable that lower layers provide for
non-
duplication, this is not a requirement. The Identifier field
provides
both the peer and authenticator with the ability to
detect
duplicates.
[5] Ordering guarantees. EAP does not require the
Identifier to be
monotonically increasing, and so is reliant on lower layer
ordering
guarantees for correct operation. Also, EAP was originally
defined
to run on PPP and [RFC1661] Section 1 has an ordering
requirement:
"The Point-to-Point Protocol is designed for simple links
which
transport packets between two peers. These links provide
full-
duplex simultaneous bi-directional operation, and are assumed
to
deliver packets in order."
Lower lower transports for EAP MUST
preserve ordering between a
source and destination, at a given priority level
(the level of
ordering guarantee provided by [IEEE802]).
3.2. EAP usage within PPP
In order to establish communications
over a point-to-point link, each
end of the PPP link must first send LCP
packets to configure the data
link during Link Establishment phase. After the
link has been
established, PPP provides for an optional Authentication phase
before
proceeding to the Network-Layer Protocol phase.
By default,
authentication is not mandatory. If authentication of the
link is desired, an
implementation MUST specify the Authentication-
Protocol Configuration Option
during Link Establishment phase.
The server can use the identification of
the connecting host or router
in the selection of options for network layer
negotiations.
When implemented within PPP, EAP does not select a
specific
authentication mechanism at PPP Link Control Phase, but rather
postpones
this until the Authentication Phase. This allows the authenticator
to
request more information before determining the specific
authentication
mechanism. This also permits the use of a "back-end" server
which
actually implements the various mechanisms while the PPP
authenticator
merely passes through the authentication exchange. The PPP
Link
Establishment and Authentication phases, and the
Authentication-Protocol
Configuration Option, are defined in The
Point-to-Point Protocol (PPP)
[RFC1661].
3.2.1. PPP Configuration
Option Format
A summary of the PPP Authentication-Protocol Configuration
Option format
to negotiate the EAP Authentication Protocol is shown below.
The fields
are transmitted from left to right.
Exactly one EAP packet
is encapsulated in the Information field of a PPP
Data Link Layer frame where
the protocol field indicates type hex C227
(PPP EAP).
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
| Length | Authentication-Protocol
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
4
Authentication-Protocol
C227
(Hex) for PPP Extensible Authentication Protocol (EAP)
3.3. EAP usage
within IEEE 802
The encapsulation of EAP over IEEE 802 link layers is
defined in
[IEEE8021X]. The IEEE 802 encapsulation of EAP does not involve
PPP,
and IEEE 802.1X does not include support for link or network
layer
negotiations. As a result, within IEEE 802.1X it is not possible
to
negotiate non-EAP authentication mechanisms, such as PAP or
CHAP
[RFC1994].
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, link layer success
indications MUST NOT result in an EAP
implementation concluding that
authentication has succeeded, since these
indications are typically
unauthenticated.
In PPP, link layer
indications are not authenticated and are therefore
subject to spoofing,
provided that the attacker can gain access to the
physical medium. This
includes LCP-Terminate (a link failure
indication), NCP (a link success
indication), and "link down" (a link
failure indication).
In 802.11,
control and management frames are not authenticated and an
attacker within
range can gain access to the physical medium. Link layer
indications include
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 or integrity protected, whereas
within
802.11, authentication and integrity protection 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 authenticated and
integrity
protected. In 802.11 a "link down" indication is an
unreliable
indication of link failure, since wireless signal strength can
come and
go and may be influenced by radio frequency interference generated
by an
attacker."
[Comments from James Carlson & Bernard Aboba on ordering requirements]:
Date: Mon, 6 Jan 2003 08:23:47 -0800 (PST)
From: Bernard Aboba
<aboba@internaut.com>
To: eap@frascone.com
Subject: Re: [Issue 50]
lower layer ordering requirement
> EAP was originally defined to run
on PPP and RFC 1661 has the
> necessary ordering
requirement:
>
> 1. Introduction
>
> The Point-to-Point
Protocol is designed for simple links which
> transport packets between
two peers. These links provide full-duplex
> simultaneous bi-directional
operation, and are assumed to deliver
> packets in order. It is intended
that PPP provide a common solution
>
> Any other transport of EAP
*must* respect the ordering requirements of
> PPP.
>
Since
both the PPP and IEEE 802 link layers provide ordering guarantees,
this issue
is not directly relevant to those encapsulations of EAP. But we
have seen
proposals for EAP over UDP or even ICMP, where ordering
guarantees would
*not* be provided. L2TP is OK, because it does provide
ordering
guarantees.
I had been under the impression that the ACK/NAK nature of
EAP provided
implicit ordered delivery, so that if the lower layer did *not*
provide
ordering guarantees, EAP could compensate.
Is this not the case? What bad things could happen in an EAP over
UDP
encapsulation, for example?
Resolution: Accept
Issue 51: Turnaround description
Submitter
name: James Carlson
Submitter email address: james.d.carlson@sun.com.
Date
first submitted: January 2, 2003
Document: RFC2284bis
Comment type:
T
Priority: S
Section: 2
Rationale/Explanation of issue:
This
problem seems to have been introduced with the resolution to
issue #48. The
description, though, is at odds with the original EAP
design and usage in
PPP. Despite the text, there is no requirement of
synchronization between the
independent authentication sessions in
each direction. The words "after" and
"complete" are misleading.
Requested change:
from:
[7]
Since EAP is a Peer-to-Peer protocol, after authentication in one
direction
is complete, the direction of authentication MAY reverse,
with the endpoint
previously serving as the Authenticator assuming
the Peer role, and the
former Peer now taking on the Authenticator
role. As with the original
conversation, the reversal is signalled
by the (new) Authenticator sending a
Request. Support for bi-
directional authentication requires that each
endpoint implement
both the Peer and Authenticator roles.
to:
[7]
Since EAP is a Peer-to-Peer protocol, an independent and
simultaneous
authentication may take place in the reverse
direction. Both peers may act as
authenticators and
authenticatees at the same time.
Resolution: Accept
Issue 52: Identity requery
Submitter name:
James Carlson
Submitter email address: james.d.carlson@sun.com.
Date first
submitted: January 2, 2003
Document: RFC2284bis
Comment type:
T
Priority: 1
Section: 5.1
Rationale/Explanation of issue:
The
restriction doesn't appear to be warranted. There's no visible
difference
between, for example, an authenticator suddenly deciding to
start
authentication over because the current method cannot proceed
(which should
be allowed), and sending an Identity message in the
"middle" of a method
(which has been proscribed). Since there's no
distinction, the requirements
can't be different.
Requested change:
from:
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 multiple times within a
sequence of methods. An Identity Request
MUST NOT be sent in the
middle of another method
conversation.
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 be sent at any time.
[BA Comment] -
Change the first paragraph of Section 5.1 to:
" The Identity Type is used to query the identity of the peer.
Generally,
the authenticator will issue this as the initial Request.
An optional
displayable message MAY be included to prompt the peer in
the case where
there expectation of interaction with a user. A
Response of Type 1 (Identity)
SHOULD be sent in Response to a Request
with a Type of 1 (Identity)"
The rest of this issue is handled in issue 87.
Proposed Resolution: Accept
Issue 53: NAK of Identity message
Submitter
name: James Carlson
Submitter email address: james.d.carlson@sun.com.
Date
first submitted: January 2, 2003
Document: RFC2284bis
Comment type:
T
Priority: S
Section: 5.1
Rationale/Explanation of issue:
The
change made in this draft breaks compatibility with the prior RFC,
and
doesn't appear to add any benefit. Worse, it means that there's
now a
completely undefined corner in the protocol: what do you do if
the peer sends
Nak for Identity anyway? Do you terminate? Try again?
This was once
well-defined (process as you would for any Nak), and is
now
undefined.
Requested change:
from:
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.
to:
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 with no known identity
to offer MAY send
Nak instead.
Response from Bernard Aboba:
"Here is the text in RFC 2284 that lead to the conclusion that
Identity
Requests (and Notification Requests) can't be NAK'd:
Section
3.3
"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."
Since
Identity is Type 1, and Notification is Type 2, the conclusion was
drawn that
NAKs cannot be sent in response to these requests.
Proposed Resolution: (from Bernard Aboba):
RFC 2284 appears to support the notion that a NAK may not be sent
in
Response to an Identity Request. However, this leaves open the question
of
what an authenticator does if a NAK is sent anyway. While it can be
argued
that Peer with an unknown identity can send a NULL Identity
Response,
there are other cases where the Peer might want to terminate
the
conversation. For example, if an 802.11 STA sends an Identity Request
to
an AP (EAP is a Peer to Peer protocol so this is legal), the AP
could
silently discard the packet, but this will just result in
a
retransmission. So there is a need for a packet that a Peer can send
that
says "I don't want to authenticate, please stop."
As a result,
the proposed resolution is not to prohibit the sending of a
NAK, but to make
clear that this is not the preferred way to say "I don't
have an
Identity".
Proposed Text for Identity Section 5.1:
"5.1.
Identity
Description
The Identity Type is used to
query the identity of the peer.
Generally, the authenticator
will issue this as the initial Request.
An optional displayable
message MAY be included to prompt the peer in
the case where
there expectation of interaction with a user. A
Response
of Type 1 (Identity) MUST be sent in Response to a Request
with
a Type of 1 (Identity). An Identity Request MUST NOT be sent
in
the middle of another method
conversation.
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.
Implementation Note: The
peer MAY obtain the Identity via user
input. It is suggested that the authenticator retry the
Identity
Request in the case of an invalid
Identity or authentication
failure to allow
for potential typos on the part of the user.
It
is suggested that the Identity Request be
retried a minimum of 3
times before
terminating the authentication phase with a
Failure
reply. The Notification Request
MAY be used to indicate an
invalid
authentication attempt prior to transmitting a
new
Identity Request (optionally, the failure
MAY be indicated within
the message of the new
Identity Request itself).
Type
1
Type-Data
This field MAY contain a displayable message in the
Request,
containing UTF-8 encoded 10646 characters
[RFC2279]. The Response
uses this field to return the
Identity. If the Identity is unknown,
this field should be
zero bytes in length. The field MUST NOT be
null
terminated. The length of this field is derived from the
Length
field of the Request/Response packet and hence a null is
not
required."
Proposed resolution: Accept
Issue 54: Problem with NAK type
Submitter
name: James Carlson
Submitter email address: james.d.carlson@sun.com.
Date
first submitted: January 2, 2003
Document: RFC2284bis
Comment type:
T
Priority: 1
Section: 5.3
Rationale/Explanation of issue:
This
also breaks RFC 2284 compatibility. In the original RFC, the
type field was
*required*. Systems implemented to RFC 2284 will
*discard* bogus Nak messages
that don't have a suggested type field.
Instead, if "Nak with no alternative"
is required (I don't think it
is), then I suggest either a reserved value
(e.g., 0) or (better yet)
using the value 1 (Identity) to tell the peer to
start over.
Requested change:
from:
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 one
authentication Type desired by the Peer. A Nak with no
authentication
Type indicates that the Peer does not wish to authenticate
using the
proposed method but is not proposing an
alternative.
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 a single
octet
authentication Type desired by the Peer. This value may be
1
(Identity) to indicate that the sender has no viable alternatives,
or
that the authentication attempt should be restarted.
More discussion from James Carlson:
Bernard Aboba writes:
> Section 2.2.1:
>
> When sending a
Nak in response to a
> Request, the peer MAY indicate an alternative
desired
> authentication Type which it supports.
I ways assumed
that meant "or might have non-working garbage such as
zero in this field,"
but you're right that it's lacking detail on what
was intended in the 'not'
case.
> 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 a
single octet
> authentication Type desired by the Peer. This value may be
1
> (Identity) to indicate that the sender has no viable
alternatives,
> or that the authentication attempt should be
restarted.
Actually, now that I've looked that over again, I'd like to
amend it
further by removing the word "initial." EAP as defined in RFC
2284
has no such concept as "method proposal." There's no reason that
I
can see to suppose that the first Request of a given Type is
somehow
special, beyond what the method definition itself
specifies.
More to the point: there's no apparent reason to prohibit
an
implementation from getting half way through an authentication
method
before saying "oops; I can't go on -- please use something
else."
(I think the "method proposal" language is another example of
the
implementation leaking into the protocol specification: the fact
that
any vendor's implementation internally presumes that it will run
one
method to completion and then signal another method to run has
nothing
to do with the definition of EAP itself. Especially because of
fast
rechallenge support in some methods, I think this needs to be left
to
the documentation of the individual methods. That is, *if*
the
authenticatee can presume anything at all from seeing a different
Type
in a Request [i.e., "discard state here"], then that needs to
be
documented.)
Proposed resolution: Accept
Issue 55: Header issues
Submitter name:
James Carlson
Submitter email address: james.d.carlson@sun.com.
Date first
submitted: January 2, 2003
Document: RFC2284bis
Comment type:
E
Priority: 2
Section: 0
Rationale/Explanation of issue:
Internet Drafts are not RFCs and must not use RFC language, such
as
"standards track" or "obsoletes." Document expiry must be
made
prominent.
Requested change:
from:
EAP Working
Group L. Blunk
INTERNET-DRAFT Merit Networks, Inc.
Category: Standards
Track J. Vollbrecht
<draft-ietf-pppext-rfc2284bis-08.txt> Interlink
Networks, Inc.
28 November 2002 Bernard Aboba
Obsoletes: RFC 2284
Microsoft
[...]
Blunk, Vollbrecht & Aboba Standards Track [Page
35]
INTERNET-DRAFT RFC2284bis 28 November
2002
[...]
to:
Network Working Group L. Blunk
INTERNET-DRAFT
Merit Networks, Inc.
Expires: June 2003 J. Vollbrecht
Interlink Networks,
Inc.
Bernard Aboba
Microsoft
[...]
Blunk, Vollbrecht & Aboba
Expires June 2003 [Page 35]
INTERNET-DRAFT RFC2284bis November
2002
[...]
Resolution: Accept
Issue 56: Expanded Type format
Submitter
name: Paul Funk
Submitter email address: paul@funk.com
Date first
submitted: December 10, 2002
Document: RFC2284bis-08
Comment type:
T
Priority: S
Section: 5.7
Rationale/Explanation of issue:
Out-of-scope changes
--------------------------------
I've taken some
liberties that go beyond the scope of this issue.
Feel free to change things
back to the way they were if there
are objections:
1 I changed 255 to
254, on the theory that experimental use of
EAP using type 255 is legacy
behavior that should not be broken.
2 The original Vendor-specific type
has everything after the
Vendor-Id defined by the vendor, with the suggested
format of
Vendor-Type immediately following (RADIUS-style). I changed
that
to make the format uniform (Diameter-style), so all v-s types have
a
fixed format that includes Vendor-Type and are thus interpretable
by anyone.
Since Vendor-type is used as part of the protocol when
Nak'ing, it's best to
make sure everyone uses it the same way. I
don't believe this limits vendor
flexibility.
Proposed Text
---------------------
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 is also used to expand the global Method
Type space beyond the original
255 values. A Vendor-Id of 0 maps the
original 255 possible types onto a
namespace of 2^32-1 possible types,
allowing for virtually unlimited
expansion. (Note that type 0 is
never used.)
An implementation that
supports the Vendor-specific attribute MUST
treat EAP types that are less
than 256 equivalently whether they
appear as a single octet or as the 32-bit
Vendor-Type within a
Vendor-specific type where Vendor-Id is 0. The single
exception
to this rule is the Nak type, as described below.
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
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor data
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
254 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.
Vendor-Type
The Vendor-Type field is four octets and
represents the vendor-
specific Method Type.
If Vendor-Id is zero, the
Vendor-Type field is an extension and
superset of the existing namespace for
EAP types. The first 256
types are reserved for compatibility with
single-octet EAP types
that have already been assigned or may be assigned in
the future.
Thus, EAP types from 0 through 255 are semantically
identical
whether they appear as single octet EAP types or as
Vendor-Types
when Vendor-Id is zero.
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 defined by
the IETF.
Resolution: Accept
Issue 57: Mutual vs. bi-direction
authentication
Submitter name: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: January 3, 2003
Document:
RFC2284bis-08
Comment type: T
Priority: S
Section: 2, pp.
5
Rationale/Explanation of issue:
Major Issues: Page 5 includes the text:
7. Since EAP is a Peer-to-Peer
protocol, after
authentication in one direction is complete, the
direction
of authentication MAY reverse, with the endpoint
previously
serving as the Authenticator assuming the Peer
role, and the former Peer now
taking on the Authenticator
role. As with the original conversation, the
reversal is
signaled by the (new) Authenticator sending a Request.
Support
for bi-directional authentication requires that
each endpoint implement both
the Peer and Authenticator
roles.
and page 31 continues in this theme
with
In EAP there is no requirement that authentication be full
duplex
or that the same protocol be used in both
directions. It is perfectly
acceptable for different
protocols to be used in each direction. This will,
of
course, depend on the specific protocols negotiated.
However, in
general, completing a single, mutual
authentication is preferable to two
one-way
authentications, one in each direction.
These two texts appear
to have been written under the misapprehension that
two unrelated unilateral
authentications glued together in arbitrary
undefined ways can result in
multual authentication. It does not and cannot;
in general the two unilateral
authentications remain simply unilateral
authentications. It is in general
not feasible to defeat man-in-the-middle
attacks--and hence in general it is
not feasible to rely on the unilateral
authentication for any useful
assertion--without relating the two
cryptographically in very specific ways.
Allowing reversal of roles is a
recipe for disaster unless very great care is
taken to relate the two
authentications, and there is no evidence such a task
is even feasible for
all but a few legacy unilateral authentication
mechanisms. We have already
seen a variant of this problem with PEAP and
TTLS, both of which are much
stronger than the construction this text seems
to sanction.
To correct this problems, I suggest adding text at the end
of that cited on
page 5 such as "In environments where man-in-the-middle
attacks are
possible, at least one of the two concrete Authentications MUST
rely on an
algorithm that performs a mutual authentication. This obviates the
need for
reversing the roles of Authenticator and Peer." To the end of the
text cited
from page 31, as text something like "This is because using
separate
authentications that are not bound cryptographically to demonstrate
they are
part of the same session are always subject to man-in-the-middle
attacks."
Or better yet, explicitly ban role reversal of the kind indicated
here. That
is simpler, and simplicity almost always leads to better
security.
Page 6: There is a sentence that begins
Unless protected by an
underlying link layer ciphersuite
In the case where the Authentication
Server is not the Authenticator, this
suffers from a similar problem. Relying
on a link layer ciphersuite between
the Authenticator and the Peer to protect
messages between the
Authentication Server and the Peer is subject to
man-in-the-middle abuses;
if the protections are not applied end-to-end, then
they cannot necessarily
be effective. I think what is really intended is that
the EAP messages be
protected by a ciphersuite associated with the concrete
authentication
method, and the text should be updated to reflect this.
-- Jesse
Proposed resolution: Accept
Issue 51 also deals with the
role-reversal issue.
I believe that the fix adopted for that issue also
resolves parts of Issue 57.
The section cited on page 6 requires a
complete rewrite,
so the best thing to do is probably to work on that
rather
than trying to patch up the current text. Note that RFC 2284bis
deals only with the protocol run between the authenticator and
peer;
security between the authenticator and authentication
server is the subject
of RFC 2869bis and Diameter EAP.
Here is the proposed text for section
7.8:
Change:
"In EAP there is no requirement that authentication
be full duplex or
that the same protocol be used in both directions. It is
perfectly
acceptable for different protocols to be used in each direction.
This
will, of course, depend on the specific protocols negotiated.
However,
in general, completing a single, mutual authentication is preferable
to
two one-way authentications, one in each direction."
To:
"In
EAP there is no requirement that authentication be full duplex or
that the
same protocol be used in both directions. It is perfectly
acceptable for
different protocols to be used in each direction. This
will, of course,
depend on the specific protocols negotiated. However,
in general, completing
a single, mutual authentication is preferable to
two one-way authentications,
one in each direction.
This is because separate authentications that are not
bound cryptographically to demonstrate they are part of the
same session
are subject to man-in-the-middle attacks."
Issue 58: Miscellaneous -08 NITs
Submitter
name: Jesse Walker
Submitter email address: jesse.walker@intel.com
Date
first submitted: January 3, 2003
Document: RFC2284bis-08
Comment type:
T,E
Priority: S
Section: Various
Rationale/Explanation of issue:
Pages 1 (Abstract), 3 (Introduction): The text still speaks of EAP as
an
"authentication protocol". It is not since in and of itself it performs
no
authentication. How about "authentication protocol transport"?
Page
3: In the definition of "Silently Discard, a sentence begins:
The
implementation SHOULD provide the capability of logging
the
error
There is an implicit assumption in this sentence that silently
discard
occurs only in response to an error. This should be made explicit or
else
the assumption removed.
Page 16: The phrase "and and"
appears.
Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym for
"IEEE 802
wired networks" Please clean this up.
Page 23 has the
language "application specific" which is not wrong per se
but does appear to
be misleading. Can we replace this with "vendor
specific", since that is what
the text is talking about?
Page 32 Clause 7.11 says that
This
specification does not provide guidance on how EAP
methods are to derive
keys.
I think it is possible to give some general but practical
guidelines:
a. the key MUST be a fresh, never-before used key, because
otherwise it is
in general infeasible to use the key to detect messages
replayed from prior
sessions.
b. there MUST be some way to name the
key, to determine whether it belongs
to this or to some other
session.
c. the key is an authorization token (use of the key
demonstrates
authorization to access the channel), so the relation of the key
to the
authentication that authorized this key MUST be made explicit to
understand
the security relationship of the key to the EAP
method.
d. in the case where more than authentication method is used (think of
PEAP
or TTLS, not the approach complained about on page 5 and 31) and more
than
one method derives keys, then the method description MUST indicate
which
keys are distributed for use by the Authenticator and Peer, and how.
For
instance, in the PEAP/TTLS case, the key derived by the inner method
could
be combined using a pseudo-random function with the TLS key
to
cryptographically bind the inner and outer keys, and this combined key
would
be used by the Authenticator and Peer.
I would also like to see
the following two additional guidelines, but they
may be more controversial,
so I will not insist:
e. When the purpose of the authentication is to
authorize use of the data
link channel between the Peer and the
Authenticator, to understand its
security one needs to know how the derived
key is bound to the channel, so
that (ab)use of it in other contexts can be
detected. It would be nice if
the method could (SHOULD?) provide guidance on
this issue, e.g., specify the
assumptions it makes about how this binding
occurs.
f. When the Authenticator and Authentication Server are not the
same party,
one needs to understand how the key is distributed to the
Authenticator (and
to the Peer, if it needs to be transported) to understand
the security
properties of the key. It would be nice if the method could
(SHOULD?)
provide guidance about this, e.g., specify the assumptions it makes
about
how key distribution is effected.
-- Jesse
Comments from Bernard Aboba:
Here are the proposed change to resolve this issue:
"protocol" to
"framework" in the Abstract and Section 1.
"error" to "event" in Section
1.2 under "silent discard"
Sentence involving "and and" has been struck
due to rewrite
of that section.
Change "IEEE 802" to "IEEE 802 wired
media" throughout the
document, where wired LANs are intended to be
referenced (many places).
Text involving "application specific" is
removed in -09, due
to rewrite of vendor specific section.
Add the
following text at the end of section 7.11:
However, some general
guidelines can be provided:
1. Master Session Keys and Transient Session
Keys MUST be a fresh.
Otherwise it is infeasible to detect messages replayed
from prior
sessions.
2. The Master Key is for use only by the EAP
authenticator and peer and MUST
NOT be exported by the EAP method or
provided to a third party.
3. Session keys used for different purposes
MUST be cryptographically
independent from each other so that if an attacker
obtains
one of the session keys, it will not have gained information
useful
in determining other ones.
4. There MUST be a way to determine
whether transient session keys belong
to this or to some other
session.
5. It is important that MSKs derived by EAP methods be bound to
the
peers as well as to the authentication method, so as to avoid a
man-in-the-middle attack (see Section 7.5).
Proposed Resolution: Accept
Issue 59: Failed authentication and EAP
Failure
Submitter name: Nick Petroni
Submitter email address:
npetroni@cs.umd.edu
Date first submitted: January 7, 2003
Document:
RFC2284bis-08
Reference:
http://mail.frascone.net/pipermail/eap/2003-January/000486.html
Comment type:
T
Priority: S
Section: 2
Rationale/Explanation of issue:
Section 2 says:
[6] The sequence of authentication methods proceeds
until either an
authentication method fails (in which case the Authenticator
sends
an EAP Failure packet to the Peer) or the final
authentication
method completes successfully, in which case the
Authenticator
sends an EAP Success packet to the Peer.
Is this always
true? Is it possible for a failed authentication to result
in a Success?
Maybe this has changed, but I thought prior
conversations ruled this out. I
have searched through the esteem doc and
the EAP issues, but I am having
trouble finding the resolution.
Comment from Bernard Aboba:
Here's what RFC 2284 has to say about this:
Section 2.2.2
"If
the authenticator cannot authenticate the peer (unacceptable
Responses to one
or more Requests) then the implementation MUST
transmit an EAP packet with
the Code field set to 4 (Failure). An
authenticator MAY wish to issue
multiple Requests before sending a
Failure response in order to allow for
human typing mistakes."
So while multiple Requests are possible, if the
authenticator cannot
authenticate the Peer, RFC 2284 doesn't leave much room
for interpretation
-- a Failure MUST be sent.
Discussion from James Carlson:
The RFC (rightly, in my opinion) doesn't distinguish between a
single
method returning failure and the *authenticator* itself
returning
failure. The two are not necessarily the same. Once
the
authenticator has determined that there is failure, I agree that
it
must send the Failure message. The question of how it
determines
"failure" (whether that's the failure of some crucial method,
the
joint failure of multiple methods, or even the success of a
"bad"
method) is not specified.
Wouldn't this be an internal implementation detail? Whether
the
authentication method itself has "failed" or not is known only to
the
authenticator; the only information that the authenticatee has
is
whether it has gotten the EAP Success or EAP Failure message.
I
don't think the document really needs to describe internal
implementation
details. The most obvious implementation is one in
which each method must
succeed ("logical AND") in order for the
authenticator to send a Success
message, but since this is entirely
determined by the implementation itself,
I don't see why other
possible choices should be excluded.
To the
extent that there's a state machine document, I think it ought
to restrict
itself to the items necessary to produce the messages on
the wire, and not
those that are quirks of policy.
One possible way out of the problem would be to define four outputs
from
the method:
- "Continue to next method, if any. Fail if no next
method."
- "Continue to next method, if any. Succeed if none left."
-
"Fail now."
- "Succeed now."
Obviously, this could get arbitrarily
complex ...
Proposed resolution by Bernard Aboba:
"[6] The sequence of authentication methods proceeds until
the
authenticator cannot authenticate the peer (unacceptable
Responses to
one or more Requests), in which case the
implementation MUST transmit an EAP
Failure.
Alternatively, the authentication sequence
can continue until
the authenticator determines
that successful authentication has occurred, in
which case the
authenticator MUST transmit an EAP Success."
Proposed Resolution: Accept
Issue 60: Ordering guarantees
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
first submitted: January 7, 2003
Document: RFC2284bis-08
Reference:
http://mail.frascone.net/pipermail/eap/2003-January/000493.html
Comment type:
T
Priority: S
Section: 3.1
Rationale/Explanation of issue:
As noted by James Carlson, there is an implicit ordering requirement in
EAP due to its PPP heritage. This is not recognized in the current draft.
Change Section 3.1 from:
"[4] Possible reordering. EAP provides
its own mechanisms to detect
reordering and so does
not assume that the lower layer provides
ordering
guarantees. EAP is a "lockstep" protocol, so that
the
Authenticator MUST NOT send a new Request until
a Response is
received to an outstanding Request.
Since the Peer should not
expect a new Request until
it has sent a Response, if it receives a
new Request
with a different Identifier before sending a
Response
to the outstanding Request, the new Request
MUST be silently
discarded. Similarly, if the
Authenticator receives a Response with
an Identifier
that does not match the Identifier in the
outstanding
Request, the Response MUST be silently
discarded.
"
To:
"Ordering guarantees. EAP does not require the
Identifier to be monotonically
increasing, and so is reliant on lower layer
ordering guarantees
for correct operation. Also, EAP was originally defined
to run on PPP and
[RFC1661] Section 1 has an ordering
requirement:
"The Point-to-Point Protocol is designed for simple links
which
transport packets between two peers. These links provide
full-duplex
simultaneous bi-directional operation, and are assumed to
deliver
packets in order."
Lower lower transports for EAP MUST
preserve
ordering between a source and destination, at a given
priority
level (the level of ordering guarantee provided by [IEEE802])."
Proposed Resolution: Accept
Issue 61: Support for EAP
Sequences
Submitter name: Hao Zhou
Submitter email address:
hzhou@cisco.com
Date first submitted: January 7, 2003
Document:
RFC2284bis-08
Reference:
http://mail.frascone.net/pipermail/eap/2003-January/000494.html
Comment type:
T
Priority: S
Section: 2
Rationale/Explanation of issue:
The current 2284bis doesn't distinguish FAILURE and SUCCESS from
individual
method and the final one from Authenticator, which makes it hard
to support
sequence of EAP methods.
I assume it is preferred that the
existing EAP methods will require no
change to be supported for sequences.
They currently send out EAP-SUCCESS
and EAP-FAILURE by themselves. On the
other end, authenticator sometimes
send out "canned " SUCCESS and FAILURE
messages after receiving
Accept/Reject from the server [IEEE8021X].
Obviously, we need to distinguish
those two types of success and failure to
continue the sequence.
I wonder if extending the EAP-SUCCESS and
EAP-FAILURE message to include a
EAP method type would solve
this.
There would be two types of EAP-SUCCESS and FAILURE:
1. The
current EAP-SUCCESS and EAP-FAILURE with no data to indicate final
success
and failure;
2. The extended EAP-SUCCESS and EAP-FAILURE include extra eap
method type to
indicate individual eap method success and failure. Without
requiring
changes in the existing individual methods to be used in the
sequence, they
would keep sending out EAP-SUCCESS and EAP-FAILURE messages.
The EAP layer
would append the EAP type to the success and failure packets if
the
individual methods are chained. Otherwise, send the message out
without
modifying it, which indicates final success and failure.
In
addition to above, an acknowledgment of receiving the success and
failure
message might be needed to support sequence. For example, after EAP
method 1
received EAP-SUCCESS, it sends out acknowledge to the backend
server, so
backend server can start EAP method 2. This is due to
unreliable
transmission of lower layer, success or failure message might not
reach the
client. Server should not start method 2 until peer acknowledges
that it
finishes with method 1.
Comment from James Carlson:
"Date: Tue, 7 Jan 2003 17:26:58 -0500
From: James Carlson
<james.d.carlson@east.sun.com>
To: Bernard Aboba
<aboba@internaut.com>
Cc: Hao Zhou <hzhou@cisco.com>,
eap@frascone.com
Subject: Re: [eap] Re: [Issue 61] Support for EAP
Sequences
Bernard Aboba writes:
> > The current 2284bis doesn't
distinguish FAILURE and SUCCESS from individual
> > method and the
final one from Authenticator, which makes it hard to support
> >
sequence of EAP methods.
>
> I think it's fair to say that RFC 2284
didn't anticipate use of sequences
> at all, other than Identity followed
by a method.
That's only roughly fair. RFC 2284 did anticipate the use,
but said
that it probably wasn't a good idea on the balance:
In
practice, within or associated with each PPP server, it is not
anticipated
that a particular named user would be authenticated by
multiple methods. This
would make the user vulnerable to attacks
which negotiate the least secure
method from among a set (such as PAP
rather than EAP). Instead, for each
named user there should be an
indication of exactly one method used to
authenticate that user name.
If a user needs to make use of different
authentication methods under
different circumstances, then distinct
identities SHOULD be employed,
each of which identifies exactly one
authentication method.
Is suspect that fear need not be true for an
implementation that was
exceedingly careful (that is, one that ran each
authentication method
regardless of the intermediate result of each, and then
sent Success
after *all* had been run only if all had passed). But given
the
tendency for mistakes, and the likely uselessness of the "feature,"
it
seems reasonable to suggest that it's not a good idea.
> > I assume it is preferred that the existing EAP methods will require
no
> > change to be supported for sequences. They currently send out
EAP-SUCCESS
> > and EAP-FAILURE by themselves.
>
> This
appears to be implementation specific. In some implementations they
> are
sent by the EAP layer, not by the method (Windows is an example).
As long
as the EAP implementation sends out EAP Success or EAP Failure
when it has
completely finished its authentication (rather than part
way through), it
doesn't matter how it's implemented internally.
> > Obviously, we
need to distinguish
> > those two types of success and failure to
continue the sequence.
>
> Are you saying that the current RFC
2284bis text would break an existing
> implementation? One of the mandates
of the EAP WG is to retain backwards
> compatibility if at all possible,
particularly if the change doesn't
> represent a "grey area" of RFC
2284.
Why is it obvious that this is needed at all?
What would the
authenticatee do if told the equivalent of "you've
passed two hurdles; now
just one more to go?" If nothing else, this
"method success" message would
clearly present serious security
problems, since it would allow divide and
conquer. It also doesn't
seem to help in the slightest because nobody has
identified a use for
them, other than perhaps as signaling *entirely*
internal to an
implementation with a particular EAP+method
architecture.
> How are the new messages to be sent? As new codes? A
new EAP type? How
> will backwards compatibility be maintained?
And
what would the peer do with them? They seem to be the protocol
equivalent of
having the peer say, "yes, yes, I see; do go on."
From John Vollbrecht:
"I think the idea of sequences is useful when doing something in addition
to
authentication. E.g. a method that negotiates QOS. Then the negotiation
for
authenication method can be done, and if that method succeeds, an
attempt to do
the QOS method can be made. If the peer accepts the method, it
will get to
negotiate - if not it gets some default settings.
This
concept was at least part of the thinking at the time the initial EAP
draft
was written.
> > > I assume it is preferred that the existing
EAP methods will require no
> > > change to be supported for
sequences. They currently send out
> EAP-SUCCESS
> > > and
EAP-FAILURE by themselves.
> >
> > This appears to be
implementation specific. In some implementations they
> > are sent by
the EAP layer, not by the method (Windows is an example).
>
> As
long as the EAP implementation sends out EAP Success or EAP Failure
> when
it has completely finished its authentication (rather than part
> way
through), it doesn't matter how it's implemented internally.
>
seems
true to me
> > > Obviously, we need to distinguish
> >
> those two types of success and failure to continue the sequence.
>
>
> > Are you saying that the current RFC 2284bis text would break
an existing
> > implementation? One of the mandates of the EAP WG is to
retain backwards
> > compatibility if at all possible, particularly if
the change doesn't
> > represent a "grey area" of RFC 2284.
>
> Why is it obvious that this is needed at all?
>
> What
would the authenticatee do if told the equivalent of "you've
> passed two
hurdles; now just one more to go?" If nothing else, this
> "method
success" message would clearly present serious security
> problems, since
it would allow divide and conquer. It also doesn't
> seem to help in the
slightest because nobody has identified a use for
> them, other than
perhaps as signaling *entirely* internal to an
> implementation with a
particular EAP+method architecture.
>
> > How are the new
messages to be sent? As new codes? A new EAP type? How
> > will
backwards compatibility be maintained?
>
> And what would the peer
do with them? They seem to be the protocol
> equivalent of having the peer
say, "yes, yes, I see; do go on."
>
I agree again. I think a
success or failure should end a sequence. If methods
are implemented to send
success or failure, then these implementations can't do
method sequences for
the reasons that James Carlson suggests.
John Vollbrecht
Proposed Resolution:
Add the following text as section 2.1:
"2.1. Support for sequences
An EAP conversation MAY utilize a sequence
of methods. A common example
of this is an Identity request followed by a
single EAP authentication
method such as an MD5-Challenge. However, within or
associated with
each EAP server, it is not anticipated that a particular
named peer will
utilize multiple authentication methods (Type 4 or greater),
either by
supporting a choice of methods or by using multiple methods in
sequence.
This would make the peer vulnerable to attacks that negotiate the
least
secure method from among a set (negotiation attacks, described in
Sec-
tion 7.9) or man-in-the-middle attacks (described in Section
7.5).
Instead, for each named peer there SHOULD be an indication of
exactly
one method used to authenticate that peer name. If a peer needs to
make
use of different authentication methods under different
circumstances,
then distinct identities SHOULD be employed, each of which
identifies
exactly one authentication method.
If additional
authentication methods are required beyond the initial
one, the authenticator
MAY send a Request packet for a subsequent
authentication method, or it MAY
send another Identity request. If the
peer does not support additional
authentication methods, after complet-
ing the last supported authentication
method, it SHOULD respond to a
subsequent Request with a Nak, indicating no
acceptable alternative, as
described in Section 5.3. However, peer
implementations MAY not respond
at all, in which case a timeout will result
and authentication will
fail. Since the authenticator presumably requires
successful completion
of the sequence in order to grant access,
authentication failure is the
correct result. Therefore, it is not necessary
for the authenticator to
determine that the peer supports sequences prior to
sending a Request
for a subsequent authentication method."
Proposed Resolution: Accept
Issue 62: Protected
success/failure
Submitter name: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: January 3, 2003
Document:
RFC2284bis-08
Comment type: T
Priority: S
Section:
Various
Rationale/Explanation of issue:
Page 6: "Protected success/failure" is never defined.
Page 6: There is
a sentence which says:
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.
This is a vacuous requirement, because there is
no definition of what it
means to "process" the "protected indication". At
the very least this should
indicate that "to process" means something like
(a) apply all the
protections of whatever ciphersuite that one believes to
have been applied
to the message to (b) extract a success/failure message,
which is then
handled according to the normal rules for EAP success/failure
messages, and
(c) received EAP success/failure messages that arrive
unprotected are
silently discarded if protection is expected.
Proposed resolution (from Bernard Aboba):
Insert a definition of a protected and unprotected indication in
Section
4.2.1:
"Within EAP, success and failure indications consist of
the
EAP Success and Failure messages, as well as method-specific
result
indications. These indications may be protected or
unprotected.
Where
a lower layer ciphersuite is in use that
provides per-packet integrity and
authentication protection,
or where the lower layer is considered physically
secure,
EAP may be considered secure from tampering, and
EAP Success and
Failure packets may qualify as protected
indications.
Otherwise, EAP
Success and Failure packets
are considered unprotected indications which may
be
spoofed, since they contain no embedded message integrity check.
Note
that Where EAP itself is used to provide the keys
for use with a lower layer
ciphersuite, protection may
not be enabled until key derivation is complete
so that
only a portion of the EAP conversation may be protected.
If the
lower layer ciphersuite is not enabled when the
EAP Success or Failure packet
is sent, then these indications
are considered unprotected."
Change:
"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."
To:
"[a] Processing of protected success and failure indications.
Where a
protected success/failure indication has been
received, the
implementation MUST validate the EAP method-specific
or lower layer MIC,
with a MIC failure handled via silent
discard, as specified in Section
4.1."
Recommended resolution: Accept
Issue 63: Identifier space advice
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
first submitted: January 8, 2003
Document: RFC2869bis-05
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of issue:
AAA protocols may not preserve ordering. For example, RADIUS
runs
over UDP, an unordered transport. Diameter runs over
reliable,
ordered transports, yet ordering may not be preserved in
the
event of failover.
Even though RFC 2284bis requires that EAP runs
over an ordered
transport, given possible AAA reordering, it is possible
for
retransmissions to be reordered in way that will confuse the
EAP
authenticator residing on the AAA server.
To fix this, the following
language needs to be inserted:
"AAA protocols may not preserve ordering.
For example, RADIUS runs
over UDP, an unordered transport. Even where a AAA
protocols runs
over reliable, ordered transports, ordering may not be
preserved
in the event of failover, where proxies are present.
As a
result, where the NAS does not eliminate duplicate responses,
and the EAP
Identifier space is not monotonically increasing,
it is possible for the
RADIUS server to incorrectly act upon a
duplicate EAP Response. To avoid
this, RADIUS servers acting as
EAP servers SHOULD implement a monotonically
increasing EAP
Identifier space, so as to be able to silently discard
EAP Responses that arrive out of order."
Comments by James Carlson & Bernard Aboba:
> As I've said in the meeting, I think this is sliding in exactly
the
> wrong direction.
>
> EAP has a perfectly good invalid
response (including duplication)
> detection mechanism on the
authenticator side (where the RADIUS
> connection would necessarily be;
RADIUS doesn't handle
> authenticatees). The EAP mechanism should be used.
As long as you
> can detect duplicates, the packets going from
authenticatee to
> authenticator have no problem.
The question was
whether the requirements on the authenticator apply to
the NAS when it
operates in passthrough, or to the AAA server. While IEEE
802.1X *does* do
duplicate elimination on the NAS, it is not clear whether
that is mandated by
the current RFC 2284bis text. If we can
require the NAS to fulfill the
obligations of an authenticator whether it
is doing pass-through or not, then
you are correct.
> The only remaining issue is that of generating
the duplicates in the
> first place. Perhaps one of the underlying
assumptions here might be
> that retransmission of EAP Request messages
would be driven by the
> RADIUS server.
No. RFC 2865 is very clear
that RADIUS retransmission is driven by the
NAS.
> Assuming the duplicates are generated in the same place (the NAS
>
sending and resending the same EAP Request over and over to provoke a
>
Response), I think the duplicates should be eliminated in the same
> place
so that the NAS presents a simple request/response interface to
> any
backend service.
Yes, I would agree. The question in my mind is whether
this is an RFC
2284bis obligation on an authenticator, or whether it is a AAA
client
obligation. My sense is that it is a AAA client obligation.
I'd
note that this is not the only case in which the obligations
of
"authenticators" are unclear. Another example is the obligation
to
implement the mandatory to implement method (EAP MD5). Is this
an
obligation of a NAS that always acts as a pass through or a AAA
server
obligation?
Discussion (from James Carlson):
"As I've said in the meeting, I think
this is sliding in exactly the
wrong direction.
EAP has a perfectly
good invalid response (including duplication)
detection mechanism on the
authenticator side (where the RADIUS
connection would necessarily be; RADIUS
doesn't handle
authenticatees). The EAP mechanism should be used. As long as
you
can detect duplicates, the packets going from authenticatee
to
authenticator have no problem.
The only remaining issue is that of
generating the duplicates in the
first place. Perhaps one of the underlying
assumptions here might be
that retransmission of EAP Request messages would
be driven by the
RADIUS server. I think that's a bad plan, because it's
unnecessary,
exposes the RADIUS server to retransmission timers based on a
EAP
peer-to-peer link about which it knows exactly nothing, exposes
the
RADIUS server to retransmission timers and duplicate elimination
that
draft-ietf-aaa-eap-00 doesn't discuss, increases network traffic,
and
doesn't seem to help solve any identifiable problem.
Assuming the
duplicates are generated in the same place (the NAS
sending and resending the
same EAP Request over and over to provoke a
Response), I think the duplicates
should be eliminated in the same
place so that the NAS presents a simple
request/response interface to
any backend service.
> Based on this,
authenticatee also needs additional rule for not
> accepting Requests with
non-monotonically increasing Identifier when
> the authenticator is
operating in monotonically increasing Identifier.
No, I don't think it
does. If the underlying layer does not reorder,
then there's only the
"current request" and a "new request." There's
no reason to require
this.
(Indeed, requiring this breaks compatibility with RFC 2284, which
does
*not* place restrictions on Identifier choice by the authenticator.
I
agree that this, along with some definiton of windowed ID
comparision,
is necessary if you allow reordering. 2284 didn't and I don't
think
we should or even can without writing essentially a new
protocol.)
> Then my concern is how the authenticatee and
authenticator can tell
> whether ordered delivery is provided over the
entire authentication
> path between the two entities or not, which seems
to me be a hard
> thing to do.
Agreed. So, you break it into two
components: there's the EAP
peer-to-peer (L2) connection, and the EAP
authenticator-to-AAA-server
connection. The EAP peer-to-peer connection
cannot result in
processing of duplicates, because the Identifier and
the
non-reordering requirement together don't allow that to
happen.
The EAP authenticator-to-AAA-server connection is just out of
scope.
There's clearly a requirement that a AAA protocol must
somehow
describe how it will support the EAP authentication "as if"
the
authenticator were a single integrated system (including
any
AAA-related ordering), but I don't see how that's an issue for
EAP
itself. The connection between these two isn't exactly EAP;
it's
encapsulated EAP messages within a AAA transport.
Proposed resolution: Discuss
Issue 64: Problem statement issues
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
first submitted: January 8, 2003
Document:
http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt
Reference:
http://mail.frascone.net/pipermail/eap/2002-December/000413.html
Comment
type: T
Priority: S
Section: Various
Rationale/Explanation of
issue:
This draft describes aspects of MiTM attacks that can be mounted
against
compound EAP methods. At IETF 55, there was consensus that this was
a
problem that needed more work. The first step in that direction is
to
complete the problem statement. This is the core of what this draft
is
trying to do, I think.
However, in reading through it, I think it
doesn't do a very good job in
several aspects:
a. Motivation for
compound methods. One obvious solution to the problem of
compound method
security is to say "don't use compound methods, use strong
simple methods
instead." So some justification for the use of compound
methods needs to be
included in the draft.
b. Discussing vulnerabilities of EAP method
sequences. Are the same
attacks launchable against sequences? In what
scenarios? The discussion is
mostly focussed on tunneling.
c.
Discussing the circumstances in which the attack can occur. For
example, can
the attack occur when the tunnel authentication is mutual? If
there is no
credential reuse? What role can policy play?
d. Discussing the
*incremental* vulnerabilities created by compound
methods. This is very
important in understand what problems are *created*
by compound methods, and
which problems are inherent in the scenarios
being discussed. For example,
when dealing with "legacy" methods (e.g.
methods which do one-way auth and
don't derive keys) and wired networks
(e.g. PPP and IEEE 802) there is an
inherent vulnerability to hijacking.
Therefore the scenario is inherently
insecure from the start -- and so the
question is not whether security is
present (it isn't) -- but how compound
methods make the situation
*worse*.
e. Discussing the requirements for a solution. What would a
"solution" to
the "problem" being defined look like? What should we expect
from a
"solution"? For example, would a solution prevent offline attacks
against
weak tunneled methods? Would it apply to all EAP methods, or just
some
subset? If it only applies to a subset, why does this subset benefit
from
tunneling?
Proposed Resolution: Discuss
Issue 65: Downgrade attacks
Submitter name:
Dan Simon
Submitter email address: dansimon@microsoft.com
Date first
submitted: January 8, 2003
Document:
http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt
Reference:
http://mail.frascone.net/pipermail/eap/2003-January/000485.html
Comment type:
T
Priority: S
Section: Various
Rationale/Explanation of
issue:
My main concern with the document is that it doesn't seem to
say
anything about the legacy/rollback issue. If both fixed and
legacy
"clients (authenticators) and "servers" (verifiers)
have to
interoperate with each other, then a
signaling mechanism *incorporated into,
and detectable in, legacy
instances* is necessary to allow fixed clients and
servers to recognize
each other and avoid a rollback. Moreover, this
signaling mechanism has
the additional advantage of solving the MITM problem
completely, all by
itself, since it can be used to distinguish tunnelled from
untunnelled
authentications.
Now, if one side of the authentication
can be assumed not to include
legacy instances (e.g., all servers being
upgraded simultaneously), then
a carefully designed fixed protocol may
suffice, without any signaling
(e.g., an extra MAC is thrown into the
protocol in both directions, and
the fixed client will detect an attempted
rollback attack when it
doesn't receive the expected returned MAC from the
fixed server). But
if both sides must interoperate with both fixed and legacy
counterparts,
then signaling within the legacy protocol must be used if
rollback is to
be prevented.
For example, if, say, a compound key
derivation solution is
used, then in the presence of both fixed and legacy
clients and servers,
some mechanism has to be found to negotiate whether to
use the "pure"
tunnel keys or compound keys. That mechanism needs to be such
that,
say, fixed clients' messages can't be fiddled with to make them
look
like legacy clients' messages, or the MITM can do the conversion
and
force the server to roll back to the legacy protocol. On the
other
hand, the fixed clients' messages must look enough like legacy
clients'
messages that legacy servers can accept and respond to them
according to
the legacy protocol. Hence the fixed clients' messages have to
be
legacy-compatible messages with an indelible "signal" in them that
a
fixed server will recognize as indicating a fixed client.
But the
presence of this signal also obviates the need for the compound
key
negotiation altogether; if fixed clients simply use the signal
whenever not
tunnelling, then a tunnelling protocol server can reject
all tunnelled
authentications containing the signal, thus protecting the
fixed client from
MITM attacks even without any other protocol change.
Do you agree that
the legacy problem is a real one? If so, then the
solution approach needs to
be changed, because the proposals presented
so far don't solve
it.
Thoughts?
Dan
Proposed Resolution: Discuss
Issue 66: Mandatory for who?
Submitter name: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
January 8, 2003
Document: RFC2284bis-08
Reference:
http://mail.frascone.net/pipermail/eap/2003-January/000514.html
Comment type:
T
Priority: S
Section: 3.4
Rationale/Explanation of
issue:
RFC 2284, Section 3.4 states:
"All EAP implementations MUST support
the MD5-Challenge mechanism."
Does this obligation extend to NASes
operating in passthrough mode?
For example, MUST they be able to
authenticate a local user via
EAP MD5?
Going further, do obligations
of authenticators (such as dropping
duplicate Requests) extend to NASes
operating in passthrough? Who
is the authenticator in this case? The NAS? The
AAA server?
Both?
Proposed fix:
In Section 1, add:
"Within this document, authenticator requirements
apply regardless of
whether the authenticator is operating as a pass-through.
Where the
requirement is meant to apply to either the authenticator
or
backend authentication server, depending on where the EAP
authentication
is terminated, the term "EAP server" will be used."
In
Section 1.2, add:
"EAP Server
The entity that terminates the EAP
authentication with the peer.
In the case where there is no backend
authentication server, this
term is synonymous with "authenticator". Where
the authenticator
operates in pass-through, it is synonymous with
"backend authentication server".
In Section 5.4, change:
"All
EAP implementations MUST support the MD5-Challenge mechanism."
To:
"EAP peer and EAP server implementations MUST support
the
MD5-Challenge mechanism. An authenticator that supports
only
pass-through MUST allow communication with a backend
authentication
server that is capable of supporting MD5-Challenge,
although the EAP
authenticator implementation need not support
MD5-Challenge itself. However,
if the EAP authenticator can be
configured to authenticate peers via any
non-pass-through
mechanism, then the requirement applies."
Add in
Section 4.1:
"These obligations apply regardless of whether
pass-through
is implemented. The EAP authenticator is responsible for
retransmitting Request messages. If the Request message is
obtained from
elsewhere (such as from a backend authentication
server), then the
authenticator will need to
save a copy of the Request in order to accomplish
this. The
authenticator is also responsible for discarding Response
messages
with the wrong Identifier value before acting on them in any
way,
including passing them on to the backend authentication server
for
verification. Similarly, the peer is responsible for detecting
and
handling duplicate Request messages before processing them in any
way,
including passing them on to an outside party."
More discussion by Bernard Aboba and James Carlson:
"> Not so hard for me -- the "EAP implementation" in this context
>
encompasses the NAS innards as well as the capabilities and issues of
>
the backend security system.
Maybe this use of "implementation" is a
special case where it refers to
the peer and EAP server implementations
(wherever the EAP server is
implemented).
Elsewhere in RFC 2284, where
the word is used, it seems to apply to the
peer and authenticator
alone:
"If authentication of
the link is desired, an implementation
MUST specify the
Authentication-Protocol Configuration Option during
Link
Establishment phase."
or
"silently discard
This means
the implementation discards the packet without
further processing. The
implementation SHOULD provide the
capability of logging the error, including
the contents of
the silently discarded packet, and SHOULD record the
event
in a statistics counter."
> unless it affects on the wire...
If you go down this road, then
it's hard to simultaneously argue that the
duplicate elimination problem can
be resolved by requiring the
authenticator to behave the same way regardless
of whether it is in
pass-through mode or not. After all, from an on-the-wire
perspective, the
conversation between peer and authenticator looks the same
either way,
right?"
Proposed Resolution: Accept
Issue 67: Lower layer security
requirement?
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: January 11, 2003
Document: RFC
2284bis-08
Comment type: T
Priority: S
Section:
3.1
Rationale/Explanation of issue:
Does EAP also require security from the lower layer in some form, such
as
physical security, or a lower layer ciphersuite? Given that the
Nak,
Identity, Notification, EAP Success and Failure packets are
not
protected, this seems reasonable.
Add the following to the lower
layer requirements:
"[2] Lower layer data security. After EAP
authentication is
complete, the peer will typically transmit data
to the
network, through the authenticator.
In order to provide assurance that the
peer transmitting
data is the one that successfully completed
EAP
authentication, it is necessary for the lower
layer to either provide
per-packet integrity and
authentication, or for the lower layer to be
physically secure. Otherwise it is possible for
subsequent data traffic
to be hijacked.
As a result of these considerations,
EAP SHOULD be
used only with lower layers that are either
physically secure (e.g. wired PPP
or IEEE 802 links), or
provide per-packet authentication and integrity
protection via a lower
layer ciphersuite. Note that where keying material for
the lower layer
ciphersuite is itself provided by EAP, it is possible to bind
the keys
derived as a result of EAP authentication to subsequent data,
protecting
against hijacking. However, typically the lower layer ciphersuite
cannot be
enabled until late in the EAP conversation, after key derivation
has completed.
Thus it may only be possible to use the lower layer
ciphersuite to
protect a portion of the EAP conversation, such as the
EAP
Success or Failure packet."
Issue 68: MIC
coverage?
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: January 11, 2003
Document: RFC
2284bis-08
Comment type: T
Priority: S
Section: 2.1,
3.1
Rationale/Explanation of issue:
In order to provide integrity
protection and authentication for the EAP
conversation, it may be desirable
to be able to calculate
a MIC on the EAP headers as well as the Type-Data
field, and perhaps even
previous EAP messages.
For example, in a
conversation including an Identity Request/Response,
a Request for EAP Type
X, a Nak Response offering alternative Y, and
then EAP Request/Response
messages of Type Y, it may be desirable
to be able to calculate a MIC of all
previous EAP messages,
including headers.
Is calculation of a MIC
constrained by the multiplexing model?
For example, if the MIC is calculated
by the EAP layer, rather
than the EAP method, then it could conceivably cover
the EAP
header as well -- but then, wouldn't the EAP layer need to
have
method-specific knowledge? This seems wrong somehow.
Similarly,
if only the Identity Response can assumed to be
available to the EAP method,
how could a method calculate a
MIC including data from other packets such as
Notification,
and Nak? If the MIC is calculated by the EAP layer, it
could
conceivably have access to those previous packets. But then
we have
to presume that there is a primitive that the EAP
method can call to ask the
EAP layer to calculate such a MIC
and return it. Such a MIC would not require
EAP-method specific
knowledge in the EAP layer.
Proposed fix: covered in the resolution of Issue 68.
Proposed resolution: Accept
Issue 69: Inconsistent language in
introduction/abstract
Submitter name: Nick Petroni
Submitter email
address: npetroni@cs.umd.edu
Date first submitted: January 14,
2003
Document: RFC2284bis-09
Comment type: E
Priority: S
Section:
Abstract and Intro (section 1)
Rationale/Explanation of issue:
Recent
changes to 2284bis have been made to state that link-layer media
must support
the same order requirements as PPP. The intro and abstract
are inconsistent
with this requirement.
Requested change:
Change
EAP
typically runs directly over the link layer without requiring
IP and
therefore includes its own support for in-order delivery, dupli-
cate
elimination and retransmission.
to
EAP typically runs directly
over the link layer without requiring
IP, but is reliant on lower layer
ordering guarantees as in
PPP. EAP does provide its own duplicate elimination
and retransmission.
Proposed resolution: Accept
Issue 70: Which PRF?
Submitter name: Bernard
Aboba
Submitter email address: aboba@internaut.com
Date first submitted:
January 23, 2003
Document: draft-puthenkulam-eap-binding-01.txt
Ref:
http://mail.frascone.net/pipermail/eap/2003-January/000613.html
Comment type:
T
Priority: S
Section: 4.1
Rationale/Explanation of issue:
I am
not clear whether a requirement for a solution is that it
work with every
tunnel encapsulation of EAP. Currently the
draft does say that this is a
requirement. I would like to
see the draft discuss the feasibility of a
general solution
within the Solution Requirements section.
There are
some sticky issues that would arise in attempting to
achieve a general
solution. One is that the PRFs vary between
encapsulations. A TLS
encapsulation (EAP TTLS, PEAP, POTLS)
will use the TLS PRF; an ISAKMP
encapsulation (PIC, IKE) will
use the IKE PRF, etc.
That means that
any means of calculating a compound MAC or compound
key that depends on a PRF
cannot be completely general, because
the question will arise: which PRF?
The question is whether it can be made "general enough".
One way to
do this would be to choose the IKE PRF as the generic one.
However, as I
understand the architectural model for a "solution",
it involves having the
EAP method export its MSK, and having this
"mixed" (probably via a PRF) with
the keying material derived
by the tunnel encapsulation.
Within this
model, tunnel encapsulation is effectively "receiving"
an exported EAP MSK,
and mixing this internally with its own tunnel
key, so that there is no
requirement that the tunnel key
(e.g. TLS master secret) be exported, which
in many cases is not
possible or desirable.
Choosing the IKE PRF as
the universal compound MAC/compound binding
PRF would imply that this PRF
would have to be universally available
to any tunnel encapsulation. I am not
clear whether this is a realistic
assumption or not.
If this
assumption cannot be made, or if there are other significant
encapsulations
with their own PRFs, then a generic EAP solution to
the problem is not
possible -- although a framework for a solution
could be put together that
could be customized for each usage.
Requested change:
Discuss the
issue of "generic" vs. "encapsulation specific" solutions
in the document, as
well as the impact of PRF choice. Also talk
about the architectural
assumptions regarding key export and import.
Issue 71: Key framework review
Submitter
name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first
submitted: January 26, 2003
Document:
draft-aboba-pppext-key-problem-05.txt
Comment type: T
Priority:
S
Section: various
Rationale/Explanation of issue:
Comments marked with "JARI:"
JARI: Overall comments: I think this looks pretty good at the moment. There are many places in the document where we have to be more precise than what the text currently says, however. The main worry that I have with this document is that I don't understand how big changes are required to provide what Jesse Walker (AAA issue 294) wanted to have for three-party participation. And I don't understand the role of NAS/client layer 2 and 3 addresses and what is required there. Finally, the document would beclearer if EAP ciphersuite and link ciphersuite issues were kept completely separate from each other.
These limitations can be overcome via negotiation of EAP methods such as EAP TLS [RFC2716] that support mutual authentication, as well as key derivation.
JARI: Right.
1.2. Terminology
This document frequently uses the following terms:
Client-Server Token (CS-Token)
The package within which the MSK is transported between the EAP Server and the EAP Client. The package MUST be integrity protected, authenticated and encrypted, so as to protect the MSK
JARI: Not replay protected?
from compromise. In addition to the MSK, the CS-Token MAY include one or more attributes providing information on MSK usage. Attributes may include the NAS layer 2 and layer 3 addresses, MSK
JARI: How would layer 3 addresses be available at this time? In PPP, NCPs run after authentication, right? And how would layer 2 addresses be possible to distribute in a manner independent from the actual link layer specifics?
Cryptographic binding
The demonstration of the EAP Client to the EAP Server that a single entity has acted as the EAP Client for all methods executed within a sequence or tunnel. Binding MAY also imply that the EAP Server demonstrates to the Client that a single entity has acted as the EAP Server for all methods executed within a sequence or tunnel. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities.
JARI: Add a reference to Valtteri Niemi et al paper or some other suitable source?
Master Session Key (MSK)
Keying material provided to the EAP Client and NAS by the AAA Server, acting as a Key Distribution Center (KDC). The MSK is used in derivation of Transient Session Keys for the ciphersuite negotiated between the EAP Client and NAS. So that the MSK is
usable with any ciphersuite, it is longer than necessary, and is truncated to fit.
JARI: This sounds a bit ad hoc. Why not require that (a) the MSK is long enough to have sufficient entropy and (b) provide an algorithm for deriving actual TSKs?
Note that an Authentication Server may simultaneously provide the EAP Client with MSKs suitable for use with multiple APs, so as to enable fast handoff. Similarly the AAA Server may send MSKs to multiple APs simultaneously. Note that where the AP supports transport of multiple MSK sets to the EAP Client and NASes, the MSKs MUST be kept cryptographically separate from each other.
JARI: Indentation of the above paragraph is wrong.
Within [IEEE80211i], the Enc-RECV-Key is also known as the Pairwise Master Key (PMK). IEEE 802.11 ciphersuites such as TKIP, WRAP and CCMP derive their Transient Session Keys (TSKs) solely from the PMK, whereas the WEP ciphersuite, when used with IEEE 802.1X-2002, derives its TSKs from both the Enc-RECV-Key and the Enc-SEND-Key.
JARI: Repeated text, see previous paragraph.
The MSK contained within the CS-Token and AN-Tokens is suitable for use with any negotiated ciphersuite, and therefore an EAP method MUST NOT directly use the MSK
JARI: s/, and therefore an/. An/
3.1. Two-party exchange
Figure 3 illustrates the two-party exchange, where the Client is authenticated locally by the NAS using a locally implemented authentication method. In this case, the EAP Master Key (EMK) is derived on the Client and the NAS, which acts as the EAP Server during the EAP authentication exchange, and the Client-Server token is transported by the NAS to the EAP Client. The Client and NAS then use the MSK contained with the CS-Token to derive the transient session keys used
JARI: Does this require the MSK to be actually sent? Wouldn't it be better to leave it to the methods, some methods can derive keys without actually sendin them encrypted over the channel?
If the authentication occurs with a method not implemented on the NAS, or involves a non-local user whose credentials the Server is unable to validate, then the NAS functions as a "pass-through". For pass-through authentication methods, instead of implementing the authentication method locally, the NAS delegates the authentication to an Authentication Server. The Authentication Server installs the desired EAP method, typically by interfacing with the operating system via an EAP API, such as that described in [EAPAPI].
JARI: Doesn't this go to the three-party exchange section?
JARI: Does the direction of sending the CS-Token have to be asymmetric?
Where key distribution is supported, the EAP Client and Authentication Server (EAP Server) MUST mutually authenticate via the negotiated EAP method, and derive keys only known between the EAP Client and Server, known as the EMK. During EAP authentication, the CS-Token MAY be transported from the EAP Server to the EAP Client, providing the Client with the MSK. Alternatively, the MSK MAY be derived from the EMK, via a one-way function. Whether the MSK is derived or transported, possession
JARI: Good that we allow CS-Token to be derived.
Utilizing the AAA protocol, the Authentication Server and NAS MUST mutually authenticate, and derive a protected channel which MUST provide per-packet integrity protection, authentication and confidentiality.
JARI: No replay protection? Wouldn't someone be able to inject a AN-token from an old session? But perhaps this is trivially handled by RADIUS/DIAMETER checking for a response matching a request it has sent.
AN-Token is distributed by the Authentication Server to the NAS over this channel. Where possible, the channel between the Authentication Server and NAS SHOULD be protected using a session key, as in [DiamEAP]
JARI: Reference Diameter base here instead?
During the (optional) TSK derivation step, the EAP Client and NAS MUST mutually authenticate by providing mutual posession of the portion of
JARI: s/providing/proving/?
JARI: Is the use of TSKs (derived using an algorithm) on both sides to send packets sufficient? To use an IP-layer example, would it OK to set up a manual IPsec SA pair with keys set to f(MSK)? Or is IKE needed?
If the Authentication Server and NAS do not mutually authenticate, then the the EAP Client will once again be vulnerable to rogue Authentication Servers, NASes or both. If there is no per-packet authentication, integrity and replay protection between the Authentication Server and
JARI: Not in line with what was said under figure 5. Replay protection wasn't included there, and confidentiality is not mentioned here. NAS, then the EAP conversation could be modified in transit, or packets can spoofed.
Since the EMK is uniquely held by the EAP Client and Server, and only mutually authenticating EAP methods may distribute keys, proof of possession of the EMK is proof of a completed mutual authentication. In order to ensure that the NAS does not possess the EMK, which could be used to impersonate the EAP Client or EAP Server, the EMK MUST NOT be provided to third parties such as the
JARI: This statement may have to be more precise. What does "used to impersonate mean"? Unless the EAP method is horribly broken, the rogue NAS does not appear to be able to perform a new authentication in some other place, claiming to be the client. Similarly, even if the EMK is not given to the NAS, the NAS will still be able to impersonate the client in the sense of being able to form payload packets that look like those coming from the client. And it can also claim that the client has sent packets it did not. So what do we really want to say here?
[b] Master Session Key (MSK) branch. The MSK is (optionally) distributed by the Authentication Server to the EAP Client within the CS-Token (or alternatively, derived from the EMK). It is
JARI: Maybe: "The MSK is (optionally) either derived from the EMK or distributed by the ..."
If the Authentication Server and NAS do not mutually authenticate, then the the EAP Client will once again be vulnerable to rogue Authentication Servers, NASes or both. If there is no per-packet authentication, integrity and replay protection between the Authentication Server and NAS, then the EAP conversation could be modified in transit, or packets can spoofed.
JARI: If there is no confidentiality, then ... what?
MSK hierarchy
For a ciphersuite to be suitable for use with dynamic keying via EAP a specification MUST be provided describing how TSKs are derived from the MSK.
JARI: Does this belong under 4.2? This is not an EAP protocol issue, and methods are not expected to know about ciphersuites.
Cryptographic Separation
Methods supporting key derivation MUST demonstrate cryptographic separation between the TEKs and TSKs. Also, it must be demonstrated that possession of the MSK does not provide information useful in determining the EMK.
JARI: Hmm... Isn't the following the hierarchy we are specifying here:
(some secret data) -> EMK -> TEK -> MSK -> TSK
If it is, it appears that the part that methods are responsible is that (a) TEKs do not reveal anything from EMK, (b) MSK does not reveal anything from EMK, (c) TEK and MSK are cryptographically separated. (Do we have a term for one-way cryptographic separation, we could use it for a and b above?) The TSK issue doesn't appear to belong to the responsibility of EAP methods. However, hopefully we have somewhere the right requirement for that i.e. (d) TSK does not reveal MSK. Luckily, since TEK and MSK are separated, a TSK generated in any manner from MSK is also separated from TEK, I think.
Session Uniqueness
In order to assure non-repetition of TSKs even in cases where one party may not have a high quality random number generator, the MSK derivation SHOULD include a two-way nonce exchange, using nonces of at least 128-bits. Note although the IEEE 802.11 RSN TSK derivation includes a nonce exchange, the TSK derivation step is link layer dependent, so that a link layer nonce exchange cannot be guaranteed to occur. As a result, a nonce exchange is still needed within the EAP method itself. A nonce exchange SHOULD also be included in the derivation of the TEKs from the EMK.
JARI: It might make sense to require either (a) nonce exchange or (b) high quality random number generation from at least one party.
TEK derivation
In order to establish a protected channel between the EAP Client and Server as part of the EAP exchange, a ciphersuite needs to be negotiated and keyed, using TEKs derived from the EMK. The ciphersuite used to protect the EAP exchange is distinct from the ciphersuite negotiated between the EAP client and NAS, used to protect data. Where a protected channel is established within the EAP method, the method specification MUST specify the mechanism by which the EAP ciphersuite is negotiated, as well as the algorithms for derivation of TEKs from the EMK during the EAP authentication exchange.
JARI: TEK is EAP-method issue only, right? I'm starting to think TEKs and the ciphersuite to protect EAP (as in EAP TLS ciphersuites) needs to have its own section, because it is easy to confuse it with the data protection ciphersuite.
Cryptographic separation
The TSKs derived from the MSK MUST be cryptographically separate from each other. Similarly, TEKs MUST be cryptographically separate from each other. In addition, the TSKs MUST be cryptographically separate from the TEKs.
JARI: Add that knowledge of TSK must not reveal anything from the MSK. The same for TEK->MSK.
[RFC2284bis] Blunk, L., Vollbrecht, J., Aboba, B., "Extensible Authentication Protocol (EAP)", Internet draft (work in progress), draft-ietf-pppext-rfc2284bis-08.txt, December 2002.
JARI: Author list on the above has changed, reference list needs an update.
Export -------->| Client| | Server| | Client| | Server|
Figure B-1 - TLS [RFC2246] Key Hierarchy
JARI: What's "Export"?
Within IEEE 802.11 RSN, the Pairwise Transient Key (PTK), a transient session key used to protect unicast traffic, is derived from the PMK (octets 0-31 of the MSK), otherwise known as the Peer to Authenticator Encryption Key. Within [RFC2548], the PMK is transported via the MS- MPPE-Recv-Key attribute. In IEEE 802.11 RSN, the PTK is derived from the PMK via the following formula:
PTK = EAPOL-PRF-X(PMK, "Pairwise key expansion" || Min(AA,SA) ||
Max(AA, SA) || Min(ANonce,SNonce) || Max(ANonce,SNonce))
Where:
PMK = MSK(0,31)
SA = Station MAC address
AA = AP MAC address
JARI: These are simply put in by the AP? They are not protected by the EAP method, and delivered from the server? How does this relate to Jesse Walker's issue for AAA key transport?
Issue 72: RFC 2869bis
review
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date first submitted: January 26, 2003
Document:
draft-aboba-radius-rfc2869bis-07.txt
Comment type: T
Priority:
S
Section: various
Rationale/Explanation of issue:
Comments marked with "JARI:"
JARI: I think we need a section on what has been updated since RFC 2869.
1. Introduction
[RFC2865] describes the RADIUS Protocol as it is implemented and deployed today, and [RFC2866] describes how Accounting can be performed with RADIUS.
JARI: Remove "as it is implemented and deployed today". I don't think RFC2865 talks about implementation or deployment.
In order to provide for support of EAP within RADIUS, two new
JARI: s/provide for support of/support/
Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. This will typically be an EAP-Request/Identity, although an EAP-Request for an alternate EAP method is possible. For example, a NAS might be
JARI: s/alternate/actual authentication/?
This could be usefulin cases where the identity is determined by another means (such as the Called-Station-Id or Calling-Station-Id), a single authentication method is required (so that the identity is not needed to determine the method), or where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up.
The peer responds with an EAP-Response, which the NAS encapsulates within EAP-Message attribute(s) within a RADIUS Access-Request packet, sent to the RADIUS server. For example, if an EAP-Request/Identity message is sent by the NAS as the first packet, the peer responds with an EAP-Response/Identity, and the NAS encapsulates the EAP-Response/Identity message within EAP-Message attribute(s), enclosed within an Access-Request sent to the RADIUS server.
JARI: In the above, we need a discussion of the possibility that the
NAS decides at this point to run a local method. Add: "Alternatively, the NAS may determine from the response that it should proceed with local authentication. Once the NAS has begun the use of RADIUS authentication for a particular session, it no longer can perform local authentication."
If the RADIUS server supports EAP, it MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS server does not support EAP, it MUST respond with an Access-Reject.
JARI: Support vs. wants to do vs. wants to do for this particular user?
EAP-Message attribute(s) encapsulate a single EAP packet which the NAS decapsulates and passes on to the authenticating peer. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received from the RADIUS server. Reception of an RADIUS Access-Reject packet MUST result in the NAS denying access to the authenticating peer. A RADIUS Access-Accept packet successfully ends the authentication phase.
JARI: This could my lack of knowledge in RADIUS, but what about the simultaneous bidir authentications? What does the Access-Accept signify in that case? Both end at that time, or can we open up a new RADIUS dialog for the other auth? And what happens if the NAS/RADIUS doesn't even want to authenticate the peer, but the peer insists on authenticating the NAS/RADIUS? Seems like the initiate-with-Id-Request -approach seems wrong in such a case.
Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and backend authentication Server, without needing to implement the EAP method used between them. Even where the NAS initiates the conversation by sending an EAP-Request, it is not required that the NAS fully implement the EAP method sent in the first packet. Depending on the method, it may be sufficient for the NAS to be configured with the initial packet to be sent to the peer, and for the NAS to act as a pass-through for subsequent messages.
JARI: The above is somewhat unclear. Do you or do you not require just the identity request to be sent by the NAS? Or do you require also a canned first message to be sent if no id request is needed? Besides, not all methods can have a canned first message, e.g. challenge-response...
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP- Response/Identity in the User-Name attribute in every subsequent Access-Request.
JARI: Only because of non-EAP aware proxies? What does the EAP-aware proxy use for routing the messages to the right direction, User-Name or contents of the EAP messages? I think the former... so its for the operation of all proxies, right?
JARI: I'm hoping the above "MUST copy" doesn't apply for an EAP Id req/resp pair appearing within a tunneled method or in a sequence... (the NAS might be able to see this message pair if it executed the first part itself and *then* let RADIUS handle the rest. Or did we prohibit such cases already?)
The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS server MUST include the User-Name attribute in subsequent Access-Challenge, Access-Accept or Access-Reject packets. Without the User-Name attribute, accounting and billing becomes difficult to manage. If the identity is determined by another means, such as the Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request, and the RADIUS server MUST copy these identifying attributes into subsequent Access-Challenge, Access-Accept or Access-Reject packets.
JARI: Uh.... so identity hiding breaks roaming completely? There seems to be two issues that we need to deal with:
1) How to route the request to the right place. Here it is hard for me to see any solutions. Or perhaps hiding just the user name but not the domain as was done in EAP SIM & AKA. But we don't have the general machinery in EAP for that.
2) How to associate the accounting records with the right user? Would the Class attribute be suitable in this situation? The records would carry the information, but only the home network can correlate them with the actual user.
Having the NAS send the initial EAP-Request packet has a number of advantages:
JARI: [3] Allowing for local authentication for some users.
In this case, the NAS MAY also send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. This allows the RADIUS server to take over the task of negotiating a more suitable method.
JARI: Question - does the NAS include the contents of the Nak and the request that led to it when sending this EAP-Start?
2.2. Role reversal
Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time.
Support for role reversal is optional on the RADIUS server, and requires
JARI: Why optional? How about mandatory to implement, optional to configure the server to actually do it? If we required mandatory support for this, would this increase the likelihood protection against rogue NASes? Or maybe we should require mutual auth support in EAP.
The RADIUS server then replies with an Access-Accept (in response to an EAP-Success) or an Access-Reject (in response to an EAP-Failure), containing no EAP-Message attribute.
JARI: May need to explain how the two RADIUS dialogs are independent, i.e. Access-Accept as a response to the above kind of Access-Request does *not* mean the other auth is complete and the user should be let in. Also, I'm uncertain what happens in the user is authenticated to the NAS/RADIUS first and an Access-Accept is returned, and *then* the user initiates EAP in another direction. Can this happen with PPP? 802.1X?
This can be accomplished by inclusion of Session-Timeout and Password-Retry attributes within the Access- Challenge packet.
JARI: I don't understand Password-Retry in this context. Wouldn't it be the RADIUS server that only is aware of an authentication failure, and would also need to send the new Requests to make possible the use of a new password?
If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout provides the NAS with the maximum number of seconds the NAS should wait for an EAP-Response before retransmitting the EAP-Request.
JARI: Please clarify whether this can be received multiple times, and what the semantics are. E.g. first you start PEAP and timeout is 5 s, then inside you'll be running token caard and timeout is 60 s, apparently the NAS takes the latest received timeout value, and starts counting from the time that it received this value from the NAS?
As described in [RFC2284], the EAP Success and Failure packets are not
JARI: Update refs to 2284bis?
Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. This behavior, originally mandated within [IEEE8021X], has since been deprecated.
JARI: So, what does it do then? MUST disconnect?
2.6.2. Priority
In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, the NAS SHOULD process EAP-Message attributes last.
JARI: We need more detail here. Say, Session-Timeout is one of these other attributes. What does 'process' mean? Look at the EAP message contained in the packet? Send that message to the peer and expect it to answer -- if so, the timeout setting would be handled too late.
It is possible that the chosen Identifier value will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. This would violate the requirement that the Identifier be unique within an EAP conversation.
JARI: And after this, its still a MAY? Backwards compatibility prevents us prohibiting it?
When used within an EAP conversation, a Reply-Message attribute received by the NAS MAY be translated to an EAP-Request/Notification sent to the peer. As a result, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification or Reply-Message attribute SHOULD NOT be included within an Access-Accept or Access-Reject packet representing the conclusion of an EAP conversation.
JARI: But this is in conflict in 2.6.3! Delete 2.6.3 and use this instead?
Value
The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user.
JARI: I must be missing something obvious again. What does the NAS do with this information? If it is running EAP and carrying it over to the RADIUS server, it doesn't appear to be able to tell whether the response messages from the peer used the right password or not. Nor can it resend Requests, there'd be Identifier conflicts, no?
RADIUS over IPsec, defined in [RFC3162] will eventually make this attribute obsolete, so it should be considered an interim measure.
JARI: When is the time to start requiring this? Or should new protocols just start using DIameter instead?
Vulnerabilities include:
Separation of EAP server and authenticator
Dictionary attacks
Known plaintext attacks
Replay protection
Connection hijacking
Man in the middle attacks
Multiple databases
Negotiation attacks
JARI: No DoS? Reading on...
For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service.
JARI: Per-service or per-connection? If its per-connection, what if the attacker causes a disconnect, then offers a weaker method? Ah, the explanation below clarifies this. Wouldn't the right name for this be "per-service"?
An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such CHAP or PAP.
JARI: s/such/such as/
wireless networks, the service advertisement itself may be spoof-able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network.
JARI: Ouch! So, per-service isn't very helpful either unless you support the same security level for all services.
EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user connecting at another location (and encountering an EAP-incapable proxy) might be consistently disconnected.
JARI: Ok, so to get back to the DoS issue... let's see: No, I can't think of any additional dos problems beyond those already present in EAP.
5. Normative references
JARI: I'm not sure why the above ones are normative. At least the first one should be informative?
Issue 73: Various RFC 2284bis
Comments
Submitter name: Henrik Levkowetz
Submitter email address:
henrik@levkowetz.com
Date first submitted: Feburary 3, 2003
Document:
RFC2284bis-10
Comment type: T
Priority: S
Section:
various
Rationale/Explanation of issue:
Hi,
Going over the 2284bis draft, I've come up with
some points I'd like
to raise as issues for discussion. My comments are
marked with HENRIK:
--------------------------------------
In
section 3.4:
In 802.11 a "link down" indication is an unreliable
indication of link
failure, since wireless signal strength can come and go
and may be
influenced by radio frequency interference generated by an
attacker. In
802.11, control and management frames are not authenticated and
an
attacker within range can gain access to the physical medium. Link
layer
indications include Disassociate and Deauthenticate frames (link
failure
indications), and Association and Reassociation Response frames
(link
success indications).
HENRIK: Very well, but what do we wish to
say with that? Is there a
conclusion here, or is this just
FYI
--------------------------------------
In section 4.1:
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.
HENRIK: (I assume the
state machine covers this? and also has other
timers to guarantee that the
protocol doesn't hang forever
waiting for an infinite timer to expire. How
much of this should
be described here? Should some text be removed, with
reference
to the state machine
document?)
--------------------------------------
In section
4.2.1:
[b] Receipt of EAP Success and Failure packets prior to
method
completion. A peer EAP implementation receiving an EAP
Success
packet prior to completion of the method in progress MUST
silently
discard it. This ensures that a rogue authenticator will not
be
able to bypass mutual authentication by sending an EAP Success
prior to
conclusion of the EAP method conversation. A peer EAP
implementation
receiving an EAP Failure packet prior to completion
of the method in progress
MAY silently discard it. When using EAP
methods that provide their own
(protected) error indications,
premature EAP Failure packets are unexpected,
so that this
technique may be more readily employed.
HENRIK: In view of
the possibility of inserting a false EAP Failure
packet in e.g. wireless
networks, maybe there should be a
RECOMMENDED discard of premature Failure
packets in the case of
insecure link in combination with EAP methods with
protected
error indications?
--------------------------------------
In section 7.:
HENRIK:
I believe I can see one security issue which has not
been discussed in this
section, but might be mentioned: If the
authenticator uses pass-through to a
backend authentication
server, it seems to me that the authenticator will
not
understand method-specific success and failure indications, and
are
dependent on seeing the final EAP Success (or Failure)
packet in order to
know the outcome of the authentication. This
means that the link between
authenticator and backend
authentication server needs to be secure against
injection of
false EAP Success or Failure indications. This is probably
the
case in most deployments, but might want mentioning for
completeness?
I can propose some text for your
consideration.
----------------------------------------------------------------
Comments
from Bernard Aboba:
"HENRIK: Very well, but what do we wish to say with
that? Is there a
conclusion here, or is this just FYI"
BA: There used
to be a conclusion there, but somehow it got lost :)
I think that the
point of this (if indeed there is one) was to clarify a
paragraph in RFC 2284
(has anyone implemented this?):
Implementation Note: Because the Success
and Failure packets
are not acknowledged, they may be potentially lost. A
peer
MUST allow for this circumstance. The peer can use a Network
Protocol
packet as an alternative indication of Success.
Likewise, the receipt of a
LCP Terminate-Request can be taken
as a Failure.
The idea of the new
text is to clarify that packets like LCP Terminate-Request
can cause a link
to go down, and therefore can cause EAP authentication to fail. But
packets
like NCP mentioned above do not cause EAP authentication to
succeed. New (and
hopefully more clear) text is included below.
-----------------------------------
HENRIK: (I assume the state
machine covers this? and also has other
timers to guarantee that the protocol
doesn't hang forever
waiting for an infinite timer to expire. How much of
this should
be described here? Should some text be removed, with
reference
to the state machine document?)
BA: I think that the state
machine should probably cover the various ways
in which the RTO timer can be
set. This includes [RFC2988] algorithms by
default; RFC 2869bis and 2284bis
already has text that state how the RTO can
be set via the Session-Timeout
attribute in RADIUS. So that same interface
can presumably be used by the
lower layer to manipulate the EAP RTO value.
But I don't think any RFC
2284bis changes are needed.
-----------------------------------
HENRIK: In
view of the possibility of inserting a false EAP Failure
packet in e.g.
wireless networks, maybe there should be a
RECOMMENDED discard of premature
Failure packets in the case of
insecure link in combination with EAP methods
with protected
error indications?
BA: I would argue that premature
Failure packets should always be
discarded. If the method isn't "complete"
then they are unexpected. This
isn't that much of a constraint, since methods
should probably terminate
via their own error messages, as opposed to by
sending an EAP Failure right
away. Another rewrite of Section 4.2.1 is
probably required.
-----------------------------------
HENRIK: I
believe I can see one security issue which has not
been discussed in this
section, but might be mentioned: If the
authenticator uses pass-through to a
backend authentication
server, it seems to me that the authenticator will
not
understand method-specific success and failure indications, and
are
dependent on seeing the final EAP Success (or Failure)
packet in order to
know the outcome of the authentication. This
means that the link between
authenticator and backend
authentication server needs to be secure against
injection of
false EAP Success or Failure indications. This is probably
the
case in most deployments, but might want mentioning for
completeness?
I can propose some text for your consideration.
BA: Actually, the
authenticator only looks for the AAA Accept/Reject and
does not peer into the
encapsulated EAP packet.
Nevertheless, injection of spoofed EAP packets
of any kind between the AAA
server and authenticator would be a bad thing.
This is discussed in the
Security Considerations section of RFC 2869bis, and
probably doesn't need to be repeated.
Here is a proposed rewrite of Section 3.4 to improve clarity:
---------------------------------------------------------------------
3.4.
Link layer indications
The reliability and security of link layer
indications is
dependent on the medium. Since EAP is media
independent,
the presence or absence of link layer security is not
taken
into account in the processing of EAP messages.
Link layer failure
indications provided to EAP by the link layer
MUST be processed and will
cause an EAP exchange
in progress to be aborted. However, link layer success
indications
MUST NOT affect EAP message processing so that an EAP
implementation
MUST NOT conclude that authentication has succeeded based on
those
indications. This ensures that an attacker spoofing link
layer
indications can at best succeed in a denial of service
attack.
Below is a discussion of some of the reliability and
security
issues with link layer indications in PPP, IEEE 802
wired
networks and IEEE 802.11 wireless LANs:
[1] PPP. In PPP, link layer indications such as
LCP-Terminate
(a link failure indication) and NCP (a link success indication)
are
not authenticated or integrity protected. They can therefore
be
spoofed by an attacker with access to the physical medium.
[2] IEEE
802 wired networks. On wired networks, IEEE 802.1X
messages are sent to a
non-forwardable multicast MAC address.
As a result, while the IEEE 802.1X
EAPOL-Start and
EAPOL-Logoff frames are not authenticated or integrity
protected,
only an attacker with access to the physical link can spoof
these
messages.
[3] IEEE 802.11 wireless LANs. In IEEE 802.11, link
layer
indications include Disassociate and Deauthenticate frames
(link
failure indications), and Association
and Reassociation Response frames (link
success indications).
These messages are not authenticated or integrity
protected,
and although they are not forwardable, they are spoofable by
an
attacker within range.
In IEEE 802.11, IEEE 802.1X data frames are sent
as Class 3
unicast data frames, are therefore forwardable. This
implies
that while EAPOL-Start and EAPOL-Logoff messages may
be
authenticated and integrity protected, they can be spoofed
by an
authenticated attacker far from the target
when "pre-authentication" is
enabled.
In IEEE 802.11 a "link down" indication is an
unreliable
indication of link failure, since wireless signal strength
can
come and go and may be influenced by radio frequency
interference generated
by an attacker. To avoid unnecessary
resets, it is advisable to damp these
indications,
rather than passing them directly to the EAP. Since EAP
supports
retransmission, it is robust against transient connectivity
losses.
On Sun, 9 Feb 2003, Henrik Levkowetz wrote:
> The
text looks good to me. However, I'd like to propose that we
> keep the
first two and the last proposed paragraph in 3.4, while the
> remaining
paragraphs are moved to Security Considerations, with
> a reference to
them in 3.4.
Proposed Resolution: Accept (with
modifications)
Issue 74: Concern on
invalid MIC
Submitter name: Yoshihiro Ohba
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: Feburary 3, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000852.html
Document:
RFC2284bis-10
Comment type: T
Priority: S
Section:
4.1
Rationale/Explanation of issue:
Section 4.1 says:
" If a Message Integrity Check (MIC) is employed
within an EAP method,
then implementations MUST silently discard
any message that fails
this check. 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')."
I'm sorry for discussing this issue again, but I am still not
sure
whether mandating silent discard of packets with invalid MIC is
always
good.
For example, EAP-TLS and PEAP haves its own fragmentation
mechanism
outside the TLS, in which each fragment is carried in a single
EAP
Request/Response packet. In this case, since TLS MIC validation
cannot
be performed before reassembling the fragmented packets, so an
attacker
Authenticator can send a fragment with broken MIC. The
packet will be
accepted by the Peer as long as it is valid except for
MIC, and EAP Requests
sent by legitimate Authenticator after the
attacker's attempt may be treated
just as a deplicate Request.
Finally, when all fragments are received by the
Peer, the Peer
reassembles a TLS record and will find invalid in terms of
MIC.
If this is a possible situation, how silently discarding the
packet
with invalid MIC can improve robustness againt the DoS attack
of
blindly injecting fragments?
I think the policy of silently discarding packets with
invalid MIC
also might not work as expected when a pass-through authenticator
is used.
Since the pass-through authenticator is not able to perform
integrity
check for EAP Response messages, when an attacker Peer sends an
EAP
Response with invalid MIC, the authenticator will pass it to
the
backend EAP server as long as it is valid except for MIC. Once
this
happens, an EAP Response message sent from the legitimate Peer will
be
treated as duplicate Response and thus silently discarded at
the
pass-through authenticator.
The policy of silently discarding
packets with invalid MIC does not
seem to work anything good for this type of
DoS attack, and this
problem seems to be common to all methods. It seems that
lower-layer
needs to be secure to EAP, or the EAP server might need to inform
the
pass-through authenticator whenever it finds an EAP Response
with
invalid MIC so that the authenticator can treat the already
forwarded
EAP Response as "invalid".
Yoshihiro Ohba
Comment from James Carlson:
It sounds like breakage in the EAP-TLS and PEAP
fragmentation
mechanisms, rather than a problem with EAP itself.
>
If this is a possible situation, how silently discarding the packet
> with
invalid MIC can improve robustness againt the DoS attack of
> blindly
injecting fragments?
If you're not doing a MIC per message, then it's
hard for me to see
what the value of the thing called a "MIC" might be.
Comment from Bernard Aboba:
I agree with James that it is best if the MIC applies to
individual
datagrams, but there are situations in which this is not possible.
For
example, unlike GSS-API, in EAP a key is not assumed available until it
is
derived later in the conversation. This means that the Identity and
Nak
messages cannot be authenticated when they are sent -- because
the
method hasn't run yet, there is no key with which to
authenticate
them.
However, as we've discussed, it is possible to
authenticate the
uncovered part of the conversation by including those
packets in a MIC
sent later on, after keys have been
derived.
Proposed Resolution:
Add as an Appendix:
"Appendix A - Method Specific
Behavior
A.1 Message Integrity Checks
Today, EAP methods commonly
define message integrity checks (MICs)
that cover more than one EAP packet.
For example,
EAP-TLS [RFC2716] defines a MIC
over a TLS record that could
be split into multiple fragments;
within the FINISHED message, the MIC is
computed over
previous messages. Where the MIC
covers more than one EAP
packet, a MIC validation failure
is typically considered a fatal
error.
If a per-packet MIC is employed within an EAP method,
then
peers, authentication servers, and authenticators
not operating in
pass-through mode MUST validate the MIC.
MIC validation failures SHOULD be
logged.
Whether a MIC validation failure is considered a fatal error
or
not is determined by the EAP method specification.
Within EAP-TLS
[RFC2716], a MIC validation failures is treated
as a fatal error, since that
is what is specified in TLS [RFC2246].
However, it is also possible to
develop EAP methods
that support per-packet MICs, and
respond to
verification failures by silently
discarding the offending packet.
In
this document, descriptions of EAP message handling
assume that per-packet
MIC validation, where it occurs,
is effectively performed as though it
occurs
before sending any responses or changing the state of the
host
which received the packet."
Recommended Resolution: Accept
Issue 75: Terminology wording
Submitter name: John
Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted:
Feburary 3, 2003
Document: RFC2284bis-10
Comment type:
Editorial
Priority: 1
Section: 1.2
Rationale/Explanation of
issue:
Item 1: authenticator description
Rationale:
EAP is a peer
to peer protocol, supporting methods that do mutual
authentication as well
as methods that authenticate the user or server
alone.
Change:
"authenticator
The end of the link requiring
the authentication. This
terminology is also used in [IEEE.802-1X.2001], and
has
the same meaning in this
document."
to:
"authenticator
The end of the EAP link
initiating the EAP authentication
methods. [Note: This terminology is also
used in
IEEE.802-1X.2001, and has the same meaning in this
document]."
---------------------------
Item 2: peer
description
Rationale:
same as above, plus I think it is unnecessary to
give examples of the
media in the peer. If needed, perhaps a separate
category could be created
to describe the "link". I personally don't think
that is necessary.
suggested change:
change:
"peer The
other end of the point-to-point link (PPP),
point-to-point LAN segment (IEEE
802 wired media) or 802.11
wireless link, which being authenticated by
the
authenticator. In [IEEE.802-1X.2001], this end is known as
the
Supplicant."
to:
"peer The end of the EAP Link that responds to
the
authenticator. [Note: In [IEEE.802-1X.2001], this end is known
as the
Supplicant."
---------------------------
Item 3: backend
authentication server
Rationale: the description is too wordy and implies
that the backend
server is required for EAP.
change:
"backend
authentication server
A backend authentication server is an entity that
provides
an authentication service to an authenticator. This
service
verifies from the credentials provided by the peer, the
claim of
identity made by the peer. This terminology is
also used in
[IEEE.802-1X.2001]."
to:
"backend authentication server
A
backend authentication server is an entity that provides
authentication
service to an authenticator. When used, this
server typically executes EAP
Methods for the authenticator.
[This terminology is also used in
[IEEE.802-1X.2001]."
Recommended Resolution: Accept
Issue 76: Multiple methods in a
sequence
Submitter name: John Vollbrecht
Submitter email address:
jrv@umich.edu
Date first submitted: Feburary 3, 2003
Document:
RFC2284bis-10
Comment type: Technical
Priority: 3
Section:
2.1
Rationale/Explanation of issue:
Multiple methods may be used in
sequence, some before and some after an
actual authentication method. Thus
an identity method may precede
authentication, and a QoS method may follow.
The wording in the RFC should
not indicate that this is unexpected
behaviour.
Also, the details on when a NAK can be sent and what responses
should occur
should be moved to a separate section, or should reference a
state machine
document (rfc or appendix)
Change:
" An EAP
conversation MAY utilize a sequence of methods. A common
example of this is
an Identity request followed by a single EAP
authentication method such as an
MD5-Challenge. However, within or
associated with each EAP server, it is not
anticipated that a
particular named peer will utilize multiple authentication
methods
(Type 4 or greater), either by supporting a choice of methods or
by
using multiple methods in sequence. This would make the peer
vulnerable
to attacks that negotiate the least secure method from
among a set
(negotiation attacks, described in Section 7.8) or
man-in-the-middle attacks
(described in Section 7.4). Instead, for
each named peer there SHOULD be an
indication of exactly one method
used to authenticate that peer name. If a
peer needs to make use of
different authentication methods under different
circumstances, then
distinct identities SHOULD be employed, each of which
identifies
exactly one authentication method. If additional
authentication
methods are required beyond the initial one, the authenticator
MAY
send a Request packet for a subsequent authentication method, or
it
MAY send another Identity request. If the peer does not
support
additional methods, it SHOULD respond with a Nak, indicating
no
acceptable alternative, as described in Section 5.3. However,
peer
implementations MAY not respond at all, in which case a timeout
will
result and authentication will fail. Since the
authenticator
presumably requires successful completion of the sequence in
order to
grant access, authentication failure is the correct
result.
Therefore, it is not necessary for the authenticator to
determine
that the peer supports sequences prior to sending a Request for
a
subsequent authentication method.
The above prescription also
applies in the situation where an
authenticator sends a message of a
different Type prior to completion
of the final round of a given method. If
the peer wishes to continue
authenticating with the method in progress, it
SHOULD send a Nak in
response to such a Request, indicating the Type in
progress as the
alternative. Otherwise it MAY send a Response with the same
Type as
the Request. Since an EAP packet with a different Type may be
sent
by an attacker, an authenticator receiving a Nak including
a
preference for the Type in progress SHOULD log the event, but
otherwise
not take any action.
Once a peer has sent a Response of the same Type as
a Request, some
existing peer implementations might expect the method to run
to
completion. As a result, these implementations silently discard
EAP
Requests of a Type different from the method in progress, despite
the
requirement for a Response in Section 4.1. For this reason,
EAP
authenticators that must interoperate with these peers are
discouraged
from switching methods before the final round of a given
method has
completed."
To:
"An EAP conversation MAY utilize a sequence of
methods. A common
example of this is an Identity request followed by a single
EAP
authentication method such as an MD5-Challenge. Another example
is an
authentication method followed by a method that negotiates QoS
parameters
with the user. In both cases only one authentication Method
is
used.
[Note: it is not considered good practice to allow the peer
to
"negotiate down" the EAP methods that do authentication. That
is,
trying a different authentication method after failing a method
SHOULD
not be allowed.]
Sequences are driven by the authenticator end
of the EAP connection.
The authenticator proposes a method by sending an EAP
request for that
Method. The Peer can accept the method by responding to the
request or
refuse the method by responding with a NAK.
On completion
of one method the authenticator may attempt to initiate
another method or may
signal completion by sending either a Success or
Failure message. Success or
Failure messages indicate to the peer that
the sequence is complete and that
the authenticator believes the
sequence has succeeded or failed.
Note
that each end of the EAP connection may independently decide whether
to
activate the connection, and in particular the peer may decide not to
activate the connection based on the results of its EAP
methods,
regardless of the Success or Failure from the authenticator. This
is
what allow mutual authentication to work.
Interactions between
authenticator and peer in cases where messages are
lost and retransmitted,
where unexpected NAKs or timeouts occur are
described in section (xxx or rfc
xxx state machine)."
Comment from Bernard Aboba:
I would like to recommend against this change. RFC 2284bis is
not a
greenfield protocol, and so an important consideration is
backward
compatibility with existing implementations. To my knowledge,
there
are no existing EAP implementations that support sequences.
In
discussion it was noted that some implementations would have
fundamental
problems in supporting sequences. Also James Carlson noted
that for his
implementation, he interpreted the original RFC 2284
language as discouraging
sequences:
In practice, within or associated with each PPP server, it is
not
anticipated that a particular named user would be authenticated
by
multiple methods. This would make the user vulnerable to attacks
which
negotiate the least secure method from among a set (such as PAP
rather than
EAP). Instead, for each named user there should be an
indication of exactly
one method used to authenticate that user name.
If a user needs to make use
of different authentication methods under
different circumstances, then
distinct identities SHOULD be employed,
each of which identifies exactly one
authentication method.
In terms of the suggested language here are some
issues:
"An EAP conversation MAY utilize a sequence of methods. A
common
example of this is an Identity request followed by a single
EAP
authentication method such as an MD5-Challenge. Another example
is an
authentication method followed by a method that negotiates QoS
parameters
with the user. In both cases only one authentication Method
is used."
[BA]
-- RFC 2284bis is focused on clarifying the existing specification
and
addressing interoperability issues, not adding major new functionality
such
as QoS negotiation.
[Note: it is not considered good practice to allow
the peer to
"negotiate down" the EAP methods that do authentication. That
is,
trying a different authentication method after failing a method
SHOULD
not be allowed.]
[BA] - this would introduce indeterminacy in
the state machine, I think.
Sequences are driven by the authenticator end
of the EAP connection.
The authenticator proposes a method by sending an EAP
request for that
Method. The Peer can accept the method by responding to the
request or
refuse the method by responding with a NAK.
On completion
of one method the authenticator may attempt to initiate
another method or may
signal completion by sending either a Success or
Failure message. Success or
Failure messages indicate to the peer that
the sequence is complete and that
the authenticator believes the
sequence has succeeded or failed.
Note
that each end of the EAP connection may independently decide whether
to
activate the connection, and in particular the peer may decide not
to
activate the connection based on the results of its EAP
methods,
regardless of the Success or Failure from the authenticator. This
is
what allow mutual authentication to work.
[BA] This seems like it
would create interoperability problems, and
potentially add some security
vulnerabilities as well.
Interactions between authenticator and peer in
cases where messages are
lost and retransmitted, where unexpected NAKs or
timeouts occur are
described in section (xxx or rfc xxx state
machine)."
[BA] RFC 2284bis is designed to be a standalone document and
should not
depend on the state machine document.
Recommended Resolution: Reject
Issue 77: Section 7.2 security
claim [f] excessive
Submitter name: Henrik Levkowetz
Submitter email
address: henrik@levkowetz.com
Date first submitted: Feburary 3,
2003
Document: RFC2284bis-10
Comment type: Technical
Priority:
1
Section: 7.2
Rationale/Explanation of issue:
2284bis itself does not adhere to item [f] of section 7.2. So
it seems
that this item may be an excessive requirement, and might be
removed
or reworded?
Discussion:
In section 7.2, item [f] says
about security claims for EAP methods:
[f] Indication of vulnerabilities.
In addition to the security claims
that are made, the specification MUST
indicate which of the
security claims detailed in Section 1.2 are NOT being
made, and
discuss the security implications.
However, for the methods
specified in this draft in sections 5.4,
5.5, 5.6, there is no discussion of
the security implications of
the security claims not made. Either this
requirement is excessive,
or we need to produce discussions of the security
implications made
and not made for the MD5-challenge, One Time Password and
Generic Token
Card methods.
Proposal:
The last part of Section 7.2
item [f] is removed, producing this text:
[f] Indication of
vulnerabilities. In addition to the security claims
that are made, the
specification MUST indicate which of the
security claims detailed in Section
1.2 are NOT being made.
Regards,
Henrik
Issue 78: More
Terminology
Submitter name: John Vollbrecht
Submitter email address:
jrv@umich.edu
Date first submitted: Feburary 3, 2003
Document:
RFC2284bis-10
Comment type: Technical
Priority: 1
Section:
1.2
Rationale/Explanation of issue:
Item-a: EAP server
description
Rationale:
The wording seems a bit
confusing.
Change:
"EAP server
The entity that terminates the
EAP authentication with the
peer. In the case where there is no backend
authentication
server, this term refers to the authenticator. Where
the
authenticator operates in pass-through, it refers to the
backend
authentication server."
To:
"EAP server
The entity that
supports EAP method exchanges with the
peer. This may be in the same device
as the authenticator or
it may be a backend authetication
server."
------------------------------
Item-b: Silently discard
description
Rationale:
Implementation suggestions should be marked as
notes. Probably should not
be protocol SHOULDs
Change:
"
Silently Discard
This means the implementation discards the packet
without
further processing. The implementation SHOULD provide
the
capability of logging the event, including the contents of
the
silently discarded packet, and SHOULD record the event
in a statistics
counter."
to:
" Silently Discard
This means the implementation
discards the packet without
further processing.
[Note: Good practice
indicates that implementations should
provide the capability of logging the
event, including the
contents of the silently discarded packet, and should
record
the event in a statistics counter."
[BA] -
The term "EAP server" was meant to be used to denote *either*
the
authenticator (when local authentication is occurring) *or*
the
authentication server (when authentication is occurring in
pass-through
mode).
The phrase "supports EAP method exchanges" seems
like it could apply to
*both* the authenticator and the authentication
server. So I'm not sure
that this is really a clarification.
With
respect to the definition of Silently Discard, this is the original
text from
RFC 2284. The intent here is to define auditable events; it is
common
practice in security specifications to make normative statements
about which
events are auditable in order to ensure that implementations
keep appropriate
logs, in order to be able to analyze attacks after the
fact. Therefore it
would seem that making these recommendations
non-normative would decrease
security.
Recommendation: Reject
Issue 79: Key Strength
Estimate
Submitter name: Henrik Levkowetz
Submitter email address:
henrik@levkowetz.com
Date first submitted: Feburary 3, 2003
Document:
RFC2284bis-10
Comment type: Technical
Priority: S
Section: 1.2,
7.2
Rationale/Explanation of issue:
[d] Key strength. If the method derives keys, then the
effective key
strength MUST be estimated.
HENRIK: How should the
estimated effective key strength be indicated?
Date: Wed, 12 Feb 2003
17:54:18 +0200
From: <Pasi.Eronen@nokia.com>
To:
<eap@frascone.com>
Subject: [eap] Proposed text for Issue 79 (Key
strength estimate)
Here's my shot at Issue 79:
[d] Key
strength. If the method derives keys, then the effective key
strength MUST be
estimated. This estimate is meant for potential users
of the method to
determine if the keys produced are strong enough for
the intended
application.
The effective key strength SHOULD be stated as number of
bits, defined
as follows: If the effective key strength is N bits, the
best
currently known methods to recover the key (with
non-negligible
probability) require an effort comparable to 2^N operations
of
a typical block cipher. The statement SHOULD be accompanied by a
short
rationale, explaining how this number was arrived at.
(Note: Although it
is difficult to define what "comparable effort" and
"typical block cipher"
exactly mean, reasonable approximations are
sufficient here. Refer to e.g.
[SILVERMAN] for more discussion.)
The key strength depends on the
methods used to derive the keys.
For instance, if keys are derived from a
shared secret (such as a
password or master key), and possibly some public
information
such as nonces, the effective key strength is limited by
the
entropy of the long-term secret (assuming that the
derivation
procedure is computationally simple). To take another example,
when
using public key algorithms, the strength of the symmetric
key
depends on the strength of the public keys used.
And add this to
"Informative References":
[SILVERMAN]
Robert D. Silverman: A
Cost-Based Security Analysis of Symmetric and
Asymmetric Key Lengths. RSA
Laboratories Bulletin 13, April 2000
(Revised November
2001).
http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html
(I
know that there are other papers about the same subject as
Silverman's, some
of which present somewhat different estimates
about how strong various key
lengths are, but for this purpose,
a rough estimate is probably good
enough)
Best regards,
Pasi
Date: Wed, 12 Feb 2003 11:47:19 -0800
From: Joe Salowey
<jsalowey@cisco.com>
To: Bernard Aboba <aboba@internaut.com>,
eap@frascone.com
Subject: RE: [eap] Re: Issue 79: Proposed text (Key strength
estimate)
Looks good. I think we need to expand upon the fact that for
many
mechanisms the entropy of generated keys is variable (based on
the
underlying secrets, passwords and asymmetric key parameters).
To
clarify this we could add the following
"The statement SHOULD be
accompanied by a short rationale, explaining
how this number was arrived at.
This explanation SHOULD include the
parameters required to achieve N bits of
entropy based on current
knowledge of the algorithms."
Comment from Bernard Aboba:
Also change the definition of Key Strength in Section 1.2
from:
" Key strength
This refers to the effective entropy of the
derived Master
Session Keys, independent of their physical length.
For
example, a 128-bit key derived from a password might have
an effective
entropy much less than 128 bits."
To:
" Key strength
If the
effective key strength is N bits, the best
currently known methods to recover
the key (with non-negligible
probability) require an effort comparable to 2^N
operations of
a typical block cipher."
Recommended Resolution: Accept (with proposed modifications)
Issue 80: Success
Indications
Submitter name: Nick Petroni
Submitter email address:
npetroni@cs.umd.edu
Date first submitted: February 10, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000853.html
Document:
EAP-00
Comment type: Technical
Priority: S
Section:
4.2.1
Rationale/Explanation of issue:
I am requesting some comments/clarification on the topic of
when the
success state can be reached by the peer.
Executive
summary:
-----------------
1. Is a satisfied policy enough for a peer
transition to the success
state, or is a SUCCESS packet required?
2.
Is the text in 4.2.1 contradicting the current EAP model, or do I have
an
incorrect understanding of the model? (these are not
mutually
exclusive)
Full
explanation:
----------------
Through conversation with the state machine
design team, I have come to
question the conditions for success of an EAP
conversation. All parties
seem to agree that a satisfied policy is necessary
for the peer to begin
using the link, but the question is whether or not the
condition is
sufficient. That is, if a SUCCESS message never comes, can the
peer
transition to the SUCCESS state? The "alternate indications" of
RFC2284
seem to imply that it can, however, section 3.4 of 2284bis
explicitly
warns against accepting link-layer indications (and for good
reason).
Since SUCCESS messages are neither acknowledged nor retransmitted,
it is
possible that SUCCESS messages could be lost causing an unneeded
timeout.
Assuming the link never goes down and the peer is satisfied, it may
be
acceptable to just begin using the link. If so, when should this
happen?
Presumably, it would be when a timeout has occurred and the policy
is
satisfied.
This problem is closely related to so-called "protected"
indications
discussed in section 4.2.1 (from resolved issue 49). Design
team
conversations have concluded that such method-specific indications
cannot
actually indicate the success/failure of the overall conversation,
but
just the method itself. Some of the text in 4.2.1 seems to contradict
this
paradigm. For example, [c] states,
"Contradictory indications.
Where protected and unprotected result
indications are both available,
protected indications take precedence. For
example, where an EAP method
provides a protected indication that
authentication failure has occurred in
either direction, the
implementation MUST silently discard subsequent EAP
Success packets.
Similarly, where an EAP method provides a protected
indication that
authentication has succeeded in both directions, the EAP
implementation
MAY silently discard EAP Failure packets."
I believe I
understand the spirit of this text, but I am not sure it fits
the current
model- are such indications really "contradictory", or has the
method just
said things are going well and the authenticator
decided
otherwise?
Note:
I believe I could make an equally
long-winded argument for saying this is
all just implementation detail
because I could implement EAP such that the
methods DO know the end result
and still fits the wire protocol.
Thanks for reading all the way through.
Comments welcome.
nick
[BA] Change the following text in Section 4.2
from:
"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. If
acknowledged
success and failure indications are desired, these
MAY be implemented within
individual EAP methods."
To:
"Implementation Note: Because the
Success and Failure packets are
not acknowledged, the authenticator cannot
know whether they have
been received. As a result, these packets are not
retransmitted by
the authenticator. If acknowledged success and failure
indications
are desired, these MAY be implemented within individual EAP
methods.
Since only a single EAP authentication method is supported
within
an EAP conversation, a peer that successfully authenticates
the
authenticator MAY, in the event that an EAP Success is not
received,
conclude that the EAP Success packet was lost and
enable the link."
Recommended Resolution: Accept
Issue 81: Auditable
Events
Submitter name: John Vollbrecht
Submitter email address:
jrv@umich.edu
Date first submitted: February 10, 2003
Document:
EAP-00
Comment type: Technical
Priority: S
Section:
Various
Rationale/Explanation of issue:
If it is required for auditability, then I think some
reference to the
requirement would be helpful. If it is an implementation
suggestion then
I would think it should be noted as such. This is not a
major problem
either way for me.
[Comment from BA] -- Let's replace this issue with specific
instances of
events that need to be audited.
Recommended Resolution: Reject
Issue 82: Response
handling
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: February 11, 2003
Document:
EAP-00
Comment type: Technical
Priority: S
Section:
4.1
Rationale/Explanation of issue:
Discussion on Issue 74 exposed a mistake in the
handling
of Responses in Section 4.1 Request and Response.
As a result, I would like
to propose a rewrite of the
Description text as follows:
"4.1 Request and Response
Description
The
Request packet (Code field set to 1) is sent by the
authenticator to the
peer. Each Request has a Type field which
serves to indicate what is being
requested. Additional Request
packets MUST be sent until a valid Response
packet is received,
or an optional retry counter expires.
Retransmitted Requests MUST be sent with the same Identifier
value
in order to distinguish them from new Requests.
The contents of the data
field is dependent on the
Request type. The peer MUST send a Response packet
in
reply to a valid Request packet. Responses MUST only be
sent in reply
to a valid Request and never retransmitted on a
timer.
The Identifier
field of the Response MUST match that of the
currently outstanding Request.
An authenticator receiving a
Response whose Identifier value does not match
that of
the currently outstanding Request MUST silently discard
the
Response. The Type field of a Response MUST either match
that of the
Request, or correspond to a legacy or expanded
Nak (see Section 5.3).
Implementation Note: The authenticator is responsible
for
retransmitting Request messages. If the Request message is
obtained
from elsewhere (such as from a backend authentication
server), then the
authenticator will need to save a copy of the
Request in order to accomplish
this. The peer is responsible
for detecting and handling duplicate Request
messages before
processing them in any way, including passing them on to an
outside party. The authenticator is also
responsible for discarding
Response messages with a non-matching
Identifier value before acting on them
in any way, including
passing them on to the backend authentication server
for
verification. Since the authenticator can retransmit before
receiving
a Response from the peer, the authenticator can
receive multiple Responses,
each with a matching Identifier.
Until a new Request is received by the
authenticator, the
Identifier value is not updated, so that the
authenticator
forwards Responses to the backend authentication server,
one at a time.
Because the authentication process will often involve
user input,
some care must be taken when deciding upon
retransmission
strategies and authentication timeouts. By default, where EAP
is
run over an unreliable lower layer, the EAP retransmission timer
SHOULD
be computed as described in [RFC2988]. This
includes use of Karn's algorithm
to filter RTT estimates resulting
from retransmissions. A maximum of 3-5
retransmissions is
suggested.
When run over a reliable lower layer
(e.g. EAP over ISAKMP/TCP, as
within [PIC]), the authenticator retransmission
timer SHOULD be set
to an infinite value, so that retransmissions do not
occur at the EAP
layer. Note that in this case the peer may still maintain
a
timeout value so as to avoid waiting indefinitely for a
Request.
Where the authentication process requires user input, the
measured
round trip times are largely 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)."
Recommended Resolution: Accept
Issue 83: Invalid packet
handling
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: February 13, 2003
Document:
RFC2869bis-12
Comment type: Technical
Priority: S
Section:
2.2
Rationale/Explanation of issue:
As part of the response to Issue 74, the following text
needs
to be added to RFC 2869bis:
"2.2. Invalid packets
While
acting as a pass-through, the NAS MUST validate the EAP header
fields (Code,
Identifier, Length) prior to forwarding an EAP packet to
or from the RADIUS
server. On receiving an EAP packet from the peer,
the NAS checks the Code (2)
and Length fields, and matches the
Identifier value against the current
Identifier, supplied by the RADIUS
server in the most recently validated
EAP-Request. On receiving an EAP
packet from the RADIUS server (encapsulated
within an Access-Challenge),
the NAS checks the Code (1) and Length fields,
then updates the current
Identifier value. Pending EAP Responses that do not
match the current
Identifier value are silently discarded.
Despite
these checks, since EAP method fields (Type, Type-Data) are
typically not
validated by a NAS operating as a pass-through, it is
possible for a NAS to
forward an invalid EAP packet to or from the
RADIUS server. A RADIUS server
receiving EAP-Message attribute(s) it
does not understand SHOULD make the
determination of whether the error
is fatal or non-fatal based on the EAP
Type. A RADIUS server determining
that a fatal error has occurred MUST send
an Access-Reject containing an
EAP-Message attribute encapsulating
EAP-Failure.
A RADIUS server determining that a non-fatal error has
occurred MAY send
an Access-Challenge to the NAS including an Error-Cause
attribute
[Dynauth] with value 202 (decimal), "Invalid EAP Packet (Ignored)".
The
Access-Challenge SHOULD encapsulate within EAP-Message attribute(s)
the
most recently sent EAP-Request packet (including the same
Identifier
value). On receiving such an Access-Challenge, a legacy
NAS
decapsulates the EAP-Request and sends it to the EAP peer, which
will
retransmit the EAP-Response.
A NAS compliant with this
specification, on receiving an Access-
Challenge with an Error-Cause
attribute of value 202 (decimal) SHOULD
discard the EAP-Response packet most
recently transmitted to the RADIUS
server and check whether additional
EAP-Response packets have been
received matching the current Identifier
value. If so, a new EAP-
Response packet, if available, MUST be sent to the
RADIUS server within
an Access-Request. If no EAP-Response packet is
available, then the
EAP-Request encapsulated within the Access-Challenge is
sent to the EAP
peer, and the retransmission timer is reset.
In order
to provide protection against Denial of Service (DoS) attacks,
it is
advisable for the NAS to allocate a finite buffer for EAP packets
received
from the peer, and to discard packets according to an
appropriate policy once
that buffer has been exceeded. Also, the RADIUS
server is advised to permit
only a modest number of invalid EAP packets
within a single session, prior to
terminating the session with an
Access-Reject."
Recommended Resolution: Accept
Issue 84: Miscellaneous
Nits
Submitter name: Steve Bellovin
Submitter email address:
smb@research.att.com
Date first submitted: February 13, 2003
Document:
RFC2869bis-09
Comment type: Technical
Priority: S
Section:
Various
Rationale/Explanation of issue:
Looks good. But the document should say why it's
Informational instead
of Proposed -- or something should.
Nit: 3.1
appears to have near-duplicate paragraphs starting "The NAS
places".
4.2 says " A typical IPsec policy for an IPsec-
capable
RADIUS client is "Initiate IPsec, from me to any, destination
port UDP 1812".
Shouldn't the destination be "RADIUS server"?
It should say "before enabling
an IKE-authenticated... the RADIUS server
*MUST* check". The same is even
more true for RADIUS clients.
--Steve Bellovin,
http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition
of "Firewalls" book)
Recommended Resolution: Accept
Issue 85: Minor editorial
comments
Submitter name: Pasi Eronen
Submitter email address:
pasi.eronen@nokia.com
Date first submitted: February 12, 2003
Document:
RFC2869bis-09
Comment type: Editorial
Priority: 2 (May fix)
Section:
Various
Rationale/Explanation of issue:
If we add a new "vendor-specific Nak" or "extended Nak"
type
to 2284bis, we probably have to make some minor editorial
changes in
2869bis as well.
2.1: s/in a a large/in a large/
3.2: s/The is
calculated/The Message-Authenticator is calculated/
4.3.1: s/To address this
vulnerabilities/To address these =
vulnerabilities/
4.3.7:
s/MD5/MD5-Challenge/
4.3.8: s/EAP methode-specific/EAP
method-specific/
Appendix A, 2nd example: last message sent by RADIUS
server
s:EAP-Message/EAP-Request/EAP-Success:EAP-Message/EAP-Success:
Appendix
A, 3rd, 4th and 7th, 9th examples: first message sent by RADIUS
=
server
s:EAP-Message/Identity:EAP-Message/EAP-Request/Identity:
The
informative references [MD5Attack] and [RFC2486] are
never cited anywhere in
the text, so maybe they are unnecessary.
Best regards,
Pasi
Recommended Resolution: Accept
Issue 86: Separation of EAP server
and authenticator
Submitter name: Henrik Levkowetz
Submitter email
address: henrik.levkowetz.com
Date first submitted: February 14,
2003
Document: EAP-00
Comment type: Technical
Priority: S
Section:
7.X
Rationale/Explanation of issue:
There's one section of the original Issue 73 which I feel we
may have
lost track of. We were talking about the injection of failure
or
success packets between the authenticator and the eap server, and
you
mentioned possibly stealing some text from 2869bis; I replied
something like
the following on Feb 7:
There is some text there, but as it is talking
about the RADIUS case,
not all is applicable, and it does not specifically
talk about the
case of the unprotected generic EAP Success and Failure
messages.
I propose a new section:
"7.xx Separation of EAP server and
authenticator
It is possible for the EAP peer and authenticator to
mutually
authenticate, and derive a Master Session Key (MSK) for a
ciphersuite
used to protect subsequent data traffic. This does not present
an
issue on the peer, since the peer and EAP client reside on the
same
machine; all that is required is for the EAP client module to
derive
and pass a Transient Session Key (TSK) to the ciphersuite
module.
However, in the case where the EAP server and authenticator
reside on
different machines, there are several implications for
security.
[a] Authentication will occur between the peer and the EAP
server,
not between the peer and the authenticator. This means that it
is
not possible for the peer to validate the identity of the NAS or
tunnel
server that it is speaking to, using EAP alone.
[b] As discussed in
[RFC2869bis], the authenticator is dependent
on the AAA protocol in order to
know the outcome of an
authentication conversation, and does not look at the
encapsulated
EAP packet (if one is present) to determine the outcome.
In
practice this means that the AAA protocol spoken between
the
authenticator and authentication server MUST support
per-packet
authentication, integrity and replay protection.
[c] A EAP
Master Session Key (MSK) negotiated between the peer and
EAP server will need
to be transmitted to the authenticator.
Therefore a mechanism needs to be
provided to transmit the MSK
from the EAP server to the authenticator or
tunnel server that
needs it. The specification of the key transport and
wrapping
mechanism is outside the scope of this
document.
"
Henrik
Recommended Resolution: Accept
Issue 87: Handling of EAP Type
change
Submitter name: James Carlson
Submitter email address:
james.d.carlson@sun.com.
Date first submitted: January 2, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000844.html
Document:
RFC2284bis-09
Comment type: Technical
Priority: S
Section:
5.1
Rationale/Explanation of issue:
Additional commentary by James Carlson:
Bernard Aboba writes:
> Question: Are you also asserting that a new
method can be started prior to
> completion of a previous method? I think
that the state machine
> document assumes that this is not possible (which
lead to the restriction
> on Identity, too).
I'm saying that
stating this as a restriction on the authenticator
doesn't make sense to me.
Suppose the authenticator wants to give up
on the currently running method
(due, perhaps, to compatibility
problems with the peer) and decides to try an
alternative method.
Does the authenticator need to provide any notification
to the
authenticatee that it wants to start over? Would that
notification
need to be anything more than a Request message with a new Type
value?
Or is the authenticator "forced" to continue with the current
method,
even if continuation is infeasible?
I'm not saying that it
makes sense to have multiple concurrent methods
running at one time. But it
also doesn't make sense to me to say that
the authenticator needs to be
limited in any way in its choice of
Request messages to send. The original
EAP model seemed much simpler
to me: the authenticator is the master, and the
authenticatee is a
slave. The authenticatee must respond to requests it gets
at best it
can, and can't be in the business of predicting the
future.
If there's some concern about fully documenting how to
*implement* an
authenticatee (though I don't think there should be), then
language
like this might work:
Other than Type 2 (Notification), which
is unrelated to the
operation of any authentication method, and Type 3
(Nak),
which is used in a session operating in the opposite
direction, an
authenticatee receiving any Type number that
differs from the previous Type
number may assume (e.g., for
purposes of allocating transient storage) that
the method
indicated by any previous Type number received has
concluded.
I don't think this is actually required for proper operation,
though.
[Comments by John Vollbrecht]:
As described in the current draft, the Authenticator can send a Request
for
a new method type before completing the current method. As described, the
peer would then NAK the Request with the data field containing the current
type.
while I thought this might work at one time, I am now convinced
that this
would be a bad idea for the following reasons:
1. sending a new
REQ in the middle of a method seems like it would be an
attempt to
"negotiate" after seeing how the method is going - seems like
bad security
practice.
2. if the peer and authenticator don't understand how to do a
method in the
same way, then probably this should just fail. It is badly
implemented or
badly designed.
3. if the intent is to avoid a DOS attack
the better way would be to have
the peer silently discard the unexpected Req
rather than NAK it. The
unexpected Request is treated as an invalid message,
which it is. this is
the way the current state machine treats it.
4. if
the intent is to allow parallel methods to operate, this doesn't do
it.
Proposal:
If the authenticator sends a message of a different Type prior
to
completion of the final round of a given method the peer SHOULD
silently
discard the Request. Since an EAP packet with a different Type may
be
sent by an attacker, this behaviour will allow the peer to continue
if
the authenticator sends additional Request for the current type. If
it
does not receive a request for the current type it will time out and
the
EAP conversation will fail.
[Comments by Pari Eronen]:
Both the current and proposed text (sort of) assume that EAP
methods
either have a single well-defined "final round", or they
have internal
mechanisms for signalling end of method (e.g. TLS
alert in EAP-TLS). I don't
think this applies to all methods;
and the correct action to take also
depends on the client's and
server's local policy (see below).
First,
not all methods have a well-defined final round: consider
a method that first
authenticates the client to the server, and
then the server to the client.
Suppose that the client
authentication fails (but the client doesn't know
this!), and
several more rounds are still left in the method.
What
should the server do, if the method does not have an
internal "failure"
message (which adds another round-trip
anyway), but the server's policy
allows trying other methods?
Clearly sending a new Request for the next
method type (or
Identity) seems reasonable in this case.
(Obviously,
if only a single method is supported by both
the client and the server, this
issue is quite trivial.)
When the client receives this Request (with new
Type), it
can silently discard it only if
1) the current method can only
fail after the last Response, or
2) the current method has an internal
"failure" message
(which should have been used instead, so the request
with
new type shouldn't have been sent), or
3) the client's policy allows
only a single EAP method, or
4) the client's policy says that if one method
has been started
(Response sent) and fails (either after final round or in
the
middle), the whole EAP conversation fails.
In cases 3 and 4, the
client can ignore the message hoping that
it was spoofed by the attacker (if
it was not, then the whole
conversation fails anyway); however, see below for
this DoS
point.
If none of these hold (method can fail in the middle
but no
internal failure message; multiple methods allowed; if one
method
fails, trying others is allowed), the client should either send
a
Response (if it permits the new method), or Nak it (so the server
can
propose something else), no matter if the previous method was
completed or
not.
Methods in which the server can discover failure before the
last
message, and which don't have any internal "failure end of
method"
message include at least EAP-SIM, EAP-AKA and EAP-SRP.
However, even if
the method has an internal failure mechanism,
silently discarding the message
(cases 3-4 above) doesn't change
the DoS situation significantly because the
internal failure
messages are not authenticated anyway in most cases
(e.g.
MS-CHAPv2, EAP-TLS alerts).
If the EAP state machine includes a concept
of "packet filter",
an EAP method could use it to specify rule "ignore all
other
messages except my messages, until I change this
otherwise"
(However, it seems that the state machine will end up
specifying
only a subset of behavior allowed by 2284bis anyway; I think
this
is sad, but getting the two to agree seems to require a lot
of
restrictions to 2284bis which weren't in RFC2284, and many people
seem
to oppose adding such restrictions on behavior?).
Best
regards,
Pasi
Proposed resolution:
Change Section 2.1 to the following:
"An EAP conversation MAY utilize a sequence of methods. A common
example
of this is an Identity request followed by a single EAP
authentication
method such as an MD5-Challenge. However, within or associated
with each
EAP server, a particular named peer SHOULD NOT
utilize multiple
authentication methods (Type 4 or greater), either by
supporting a choice of
methods or by using multiple methods in sequence.
This would make the peer
vulnerable to attacks that negotiate the least
secure method from among a set
(negotiation attacks, described in
Section 7.8) or man-in-the-middle attacks
(described in Section 7.4).
Instead, for each named peer there SHOULD be an
indication of exactly
one method used to authenticate that peer name. If a
peer needs to make
use of different authentication methods under different
circumstances,
then distinct identities SHOULD be employed, each of which
identifies
exactly one authentication method.
If additional
authentication methods are required beyond the initial
one, the authenticator
may send a Request packet for a subsequent
authentication method, or it MAY
send another Identity request. If the
peer does not support additional
methods, it SHOULD respond with a Nak,
indicating no acceptable alternative,
as described in Section 5.3.
However, peer implementations may not respond,
in which case a
timeout will result and authentication will fail. As a
result,
use of authentication sequences is likely to result in
interoperability
problems.
The above prescription also applies in the
situation where an
authenticator sends a message of a different Type prior to
completion of
the final round of a given method. If the peer wishes to
continue
authenticating with the method in progress, it SHOULD send a Nak
in
response to such a Request, indicating the Type in progress as
the
alternative. Otherwise it MAY send a Response with the same Type as
the
Request. Since an EAP packet with a different Type may be sent by
an
attacker, an authenticator receiving a Nak including a preference
for
the Type in progress SHOULD log the event, but otherwise not take
any
action.
Once a peer has sent a Response of the same Type as a
Request, some
existing peer implementations may expect the method to run
to
completion. These implementations silently discard EAP
Requests of a
Type different from the method in progress, despite the
requirement for a
Response in section 4.1. For this reason, EAP
authenticators SHOULD NOT
switch methods before the final
round of a given method has completed."
Recommended Resolution: Reject
Issue 88: Review of Binding-01
Submitter
name: Jukka Ylitalo
Submitter email address:
jukka.ylitalo@lmf.ericsson.se
Date first submitted: March 3,
2003
Document: Binding-01
Comment type: Technical
Priority:
S
Section: Various
Rationale/Explanation of issue:
Hi,
I have read the draft-puthenkulam-eap-binding-01.tx and I have a
question.
Currently, the outer protocol is used for (1) server
authentication and
(2) the session keys are derived on the basis of that
protocol. Therefore,
the protocol is also called network authentication
protocol.
On the other hand, the inner protocol is used to authenticate
the client
to the server. However, several inner protocols generate
keying
material (while some others do not). That keying material is currently
not
used to protect the network traffic.
Why we wouldn't solve the
case in the following way:
(1) The outer protocol should be used only for
server authentication
and to offer privacy for the client during
authentication. The keying
material produced by the outer protocol would not
be used anymore for
session protection.
(2) The session keys would be
derived on the basis of the inner protocol.
The outer protocol would
still have two roles. It is used for server
authentication and to guarantee
privacy for the client during
authentication.
Unfortunately, all inner
protocols do not generate keys. However, such
protocols are quite insecure
from the man-in-the-middle attacks point of
view anyway. The main problem
here is in attitudes. Can we use inner
authentication protocol for session
keying? All in all, I think we are
then doing very much the same thing as
with combound keys.
In some cases the client may not even want to know
the actual identity
of the server. The client only requires privacy for
authentication. In
such cases opportunistic server authentication can take
place without
being worried about the session security.
Any
opinions?
-- Jukka
Jukka Ylitalo Tel: +358 9 299
2622
NomadicLab, Ericsson Research Fax: +358 9 299 3535
Oy L M Ericsson Ab
Mobile: +358 400 615 821
FIN-02420 Jorvas, Finland E-mail: jukka.ylitalo@nomadiclab.com
[Comment from Jose]:
This is a possible solution, but then cryptographic binding can
provide
stronger keys than session keys generated by some inner methods like
EAP-SIM
or EAP-MSCHAPv2. Also tunnel keys afford the only protection for
non-key
deriving methods. So don't see why tunnel keys that are
typically
strong need to be avoided.
best
regards,
jose
[Comment from Jari Arkko]:
This is an interesting discussion! I'd like to understand more
about
exactly when Jukka's solution (inner keys), Jose's solution (compound
keys),
and the current tunneling solution (outer keys) can and should be
used. There's
a number of relevant cases:
* Non-key deriving methods:
here we have a choice of no keys at all,
or the keys from the outer method.
What are the tradeoffs? Or
perhaps there are only positive effects from the
use of the keys?
* Strong, modern methods that generate good keys: should
we only
rely on the inner keys here, or consider only the use of the
tunnel
keys or compound keys? Again, what are the tradeoffs? There
seems
to be at least some issues in exporting e.g. TLS keys from
the
tunnel and use them elsewhere. What are the advantages of the
compound
keys in this scenario?
* Methods that generate bad keys
;-)
Jari
Issue 89: Comments on Binding-01
Submitter
name: Jari Arkko
Submitter email address: jari.arkko@piuha.net
Date first
submitted: March 3, 2003
Document: Binding-01
Comment type:
Technical
Priority: S
Section: Various
Rationale/Explanation of
issue:
I have looked at the binding problem draft and I have some
questions and
comments. I've inserted these to the draft itself,
marked by "JARI:". The URL
is
http://www.piuha.net/~jarkko/publications/eap/binding_review.txt
Issue 90: Simplify Introduction
Submitter
name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first
submitted: March 3, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000833.html
Document:
EAP-01
Comment type: Technical
Priority: S
Section:
1
Rationale/Explanation for change:
change wording from middle of 3rd paragraph from:
"Rather than requiring
the authenticator to be updated to support each
new authentication method,
EAP permits the use of a backend
authentication server which may implement
some or all authentication
methods, with the authenticator acting as a
pass-through for some or
all methods and users.
Within this document,
authenticator requirements apply regardless of
whether the authenticator is
operating as a pass-through or not.
Where the requirement is meant to apply
to either the authenticator
or backend authentication server, depending on
where the EAP
authentication"
to:
"Rather than requiring the
authenticator to be updated to support each
new authentication method, EAP
permits the authenticator to use a
backend server to do the actual
authentication method."
Recommended Resolution: Reject
Issue 91: Definitions
Submitter name: John
Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted:
March 3, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000830.html
Document:
EAP-01
Comment type: Editorial
Priority: S
Section:
1.2
Rationale/Explanation of issue:
change:
"EAP server
The entity
that terminates the EAP authentication with the
peer. In the case where there
is no backend authentication
server, this term refers to the authenticator.
Where the
authenticator operates in pass-through, it refers to the
backend
authentication server."
to:
"EAP server
The entity that terminates the
EAP authentication method with
the peer. In the case where no backend
authentication
server is used the EAP server is part of the authenticator.
In the
case where the authenticator operates in pass through mode,
the
EAP server is located on the backend authentication server."
Change:
"Mutual authentication
This refers to an EAP method in which,
within an
interlocked exchange, the authenticator authenticates the
peer
and the peer authenticates the authenticator. Two
one-way conversations,
running in opposite directions do
not provide mutual authentication as
defined here."
To:
"Mutual authentication
This refers to an EAP method
in which, within an
interlocked exchange, the authenticator authenticates
the
peer and the peer authenticates the authenticator. Two
independent
one-way methods, running in opposite directions do
not provide mutual
authentication as defined here."
change :
Security claims terminology (see Section
7.2):
to:
Security claims terminology for EAP Methods (see Section
7.2)
Recommended Resolution: Accept
Issue 92: Integrity Protection
Submitter
name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first
submitted: March 3, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000831.html
Document:
EAP-01
Comment type: Technical
Priority: 2
Section: 1.2
change:
"Integrity protection
This refers to per-packet
authentication and integrity
protection of EAP packets, including EAP
Requests and
Responses, and method-specific success and failure
indications.
When making this claim, a method specification
MUST
describe the fields within the EAP packet that
are
protected."
to:
[Based on comments from Henrik, Nick, John and others]:
"Integrity protection
This refers to providing data origin authentication
and protection
against unauthorized modification of information for EAP
packets
(including EAP Requests and Responses). When making this claim,
a method specification MUST describe the EAP packets and fields
within
the EAP packet that are protected."
Proposed Resolution: Accept
Issue 93: Simplify Description
Submitter
name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first
submitted: March 3, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000832.html
Document:
EAP-01
Comment type: Editorial
Priority: 1
Section:
2
change:
"[1] The authenticator sends a Request to authenticate the peer.
The
Request has a type field to indicate what is being requested.
Examples
of Request types include Identity, MD5-challenge, etc.
The MD5-challenge type
corresponds closely to the CHAP
authentication protocol [RFC1994]. Typically,
the authenticator
will send an initial Identity Request; however, an
initial
Identity Request is not required, and MAY be bypassed.
For
example, the identity may not be required where it is determined
by
the port to which the peer has connected (leased lines,
dedicated switch or
dial-up ports); or where the identity is
obtained in another fashion (via
calling station identity or MAC
address, in the Name field of the
MD5-Challenge Response, etc.)."
to:
"[1] The authenticator sends a
Request to authenticate the peer. The
Request has a type field to indicate
what is being requested.
Examples of Request types include Identity,
MD5-challenge, etc.
Typically, the authenticator will send an initial
Identity Request.
[Note: an initial
Identity Request is not required,
and MAY be bypassed. For
example, the identity may not be required where it
is determined
by the port to which the peer has connected (leased
lines,
dedicated switch or dial-up ports); or where the identity
is
obtained in another fashion (via calling station identity or
MAC
address, in the Name field of the MD5-Challenge Response, etc.).]"
[Comment by Henrik Lefkowetz]:
Personally, I think the text reads better as-is, without breaking it
up.
With respect to removing the reference to CHAP, I'm indifferent.
Proposed Resolution: Reject
Issue 94: Is EAP a lockstep
protocol?
Submitter name: Pasi Eronen
Submitter email address:
pari.eronen@nokia.com
Date first submitted: March 4, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-January/000478.html
Document:
EAP-01
Comment type: Technical
Priority: 1
I know this issue has been discussed before (e.g. James Carlson's
email on
January 6th [1]), but since it has come up in PANA again (and
might cause
extra complexity there), I would like to see the issue
explictly clarified in
2284bis and/or 2869bis.
So, the question is: Is the Authenticator/EAP
Server allowed to send a
new Request (with different Identifier and contents)
before it has
received a Response to the previous outstanding Request? (that
is,
is EAP "lock-step" protocol or not?)
At least it seems that
2869bis does not support this kind of behavior
(since the authentication
server can send an Accept-Challenge only in
response to an Access-Request).
So, even if we allow "non-lock-step
behavior" in 2284bis, perhaps it should
be explicitly forbidden in
2869bis? (I don't think this is a problem, since
2869bis does not
support all EAP features anyway, like role
reversal).
I don't have a strong opinion on this one: allowing such
behavior
might increase complexity, but as James said, there was no
such
restriction in RFC2284 (or at least so it seems).
If we get some kind
of consensus on which option should be chosen
(allow non-lock-step behavior
in 2284bis but prohibit it in 2869bis,
or prohibit it in both), I can try to
propose some text. (Or, it
might be that the specs already say this, but I
can't find it :-)
(BTW, there are some parts in 2284bis which assume
lock-step behavior
and need changing if non-lock-step is allowed. For
example,
Section 4.1: "In order to avoid confusion between new
Requests
and retransmissions, the Identifier value chosen for each new
Request
need only be different from the previous Request, but need not
be
unique within the conversation.")
Best
regards,
Pasi
[Comment from John Vollbrecht]:
The state machine at least assumes that lock step is required. I believe
this was the consensus on an EAP-design group call, but I am not positive I
remember correctly, or that all who might disagree were on the
call.
I think the alternative is very hard to describe and implement at
the
detail level. Specifically, if one allows multiple Requests in parallel,
then each will need to have a separate id. each id will need to be unique.
If a Request is retransmitted, the peer may respond to both the original
and retransmitted request, or to only one of them. The authenticator will
not know whether the response is coming or not, so it won't be able to
reuse the id until a timeout. The assumption of ordering doesn't help this
since the authenticator can never be sure the peer won't send a
response.
Lock step makes it much simpler and more understandable. If a
response
comes that is not for the just send id, it can be dropped.
[BA Comment]: How about this?
In EAP-01, Section 2, change:
" [3] The authenticator sends an
additional Request packet, and the
peer replies with a Response. The sequence
of Requests and
Responses continues as long as
needed."
to:
" [3] The authenticator sends an additional
Request packet, and the
peer replies with a Response. The sequence of
Requests and
Responses continues as long as needed. EAP is a 'lock step'
protocol, so that other than the initial Request, a new Request
cannot
be sent prior to receiving a valid Response. The
Authenticator MUST NOT send
a Success or Failure packet as
a result of a timeout. After a suitable number
of timeouts
have elapsed, the Authenticator SHOULD end the EAP
conversation."
Recommended resolution: Accept
Issue 95: Sequences
Submitter name: John
Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted:
March 4, 2003
Reference:
http://mail.frascone.net/pipermail/public/eap/2003-March/000860.html
Document:
EAP-01
Comment type: Technical
Priority: S
Section:
2.1
Rationale/Explanation of issue:
Description implies that sequences are not
supported. The rationale for
this is security indications, and should be
in the security
section.
Requested change:
change:
An EAP conversation MAY
utilize a sequence of methods. A common
example of this is an Identity
request followed by a single EAP
authentication method such as an
MD5-Challenge. However, within or
associated with each EAP server, it is not
anticipated that a
particular named peer will utilize multiple authentication
methods
(Type 4 or greater), either by supporting a choice of methods or
by
using multiple methods in sequence. This would make the peer
vulnerable
to attacks that negotiate the least secure method from
among a set
(negotiation attacks, described in Section 7.8) or
man-in-the-middle attacks
(described in Section 7.4). Instead, for
each named peer there SHOULD be an
indication of exactly one method
used to authenticate that peer name. If a
peer needs to make use of
different authentication methods under different
circumstances, then
distinct identities SHOULD be employed, each of which
identifies
exactly one authentication method. If additional
authentication
methods are required beyond the initial one, the authenticator
MAY
send a Request packet for a subsequent authentication method, or
it
MAY send another Identity request. If the peer does not
support
additional methods, it SHOULD respond with a Nak, indicating
no
acceptable alternative, as described in Section 5.3. However,
peer
implementations MAY not respond at all, in which case a timeout
will
result and authentication will fail. Since the
authenticator
presumably requires successful completion of the sequence in
order to
grant access, authentication failure is the correct
result.
Therefore, it is not necessary for the authenticator to
determine
that the peer supports sequences prior to sending a Request for
a
subsequent authentication method.
to:
An EAP conversation MAY utilize a sequence of methods. A
common
example of this is an Identity request followed by a single
EAP
authentication method such as an MD5-Challenge. If
additional
authentication
methods are required beyond the initial one, the
authenticator MAY
send a Request packet for a subsequent authentication
method, or it
MAY send another Identity request. If the peer does not
support
additional methods, it SHOULD respond with a Nak, indicating
no
acceptable alternative, as described in Section 5.3. However,
peer
implementations MAY not respond at all, in which case a timeout
will
result and authentication will fail. Since the
authenticator
presumably requires successful completion of the sequence in
order to
grant access, authentication failure is the correct
result.
Therefore, it is not necessary for the authenticator to
determine
that the peer supports sequences prior to sending a Request for
a
subsequent authentication method.
and rewrite the following and add
to security section:
However, within or
associated with each EAP server,
it is not anticipated that a
particular named peer will utilize multiple
authentication methods
(Type 4 or greater), either by supporting a choice of
methods or by
using multiple methods in sequence. This would make the
peer
vulnerable to attacks that negotiate the least secure method
from
among a set (negotiation attacks, described in Section 7.8)
or
man-in-the-middle attacks (described in Section 7.4). Instead, for
each
named peer there SHOULD be an indication of exactly one method
used to
authenticate that peer name. If a peer needs to make use of
different
authentication methods under different circumstances, then
distinct
identities SHOULD be employed, each of which identifies
exactly one
authentication method.
[BA - This issue is really a duplicate of issue 87.]
Proposed Resolution: Reject
Issue 96: Notification
clarification
Submitter name: Yoshihiro Ohba
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: March 7, 2003
Reference:
Document: EAP-01
Comment type: Technical
Priority: S
Section:
5.2
Rationale/Explanation of issue:
I'd like to suggest the following change from:
"5.2
Notification
Description
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. The
peer MUST
respond to a Notification Request with a Notification Response;
a
Nak Response MUST NOT be sent."
to:
"5.2 Notification
Description
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 when there is
no outstanding Request. The peer MUST respond to a
Notification
Request with a Notification Response; a Nak Response MUST NOT
be
sent. If a Nak Response is received by the authenticator in
response
to a Notification Request it is silently discarded."
Issue 97: Strict interpretation
Submitter
name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date
first submitted: April 7, 2003
Reference:http://mail.frascone.net/pipermail/public/eap/2003-April/001018.html
Document:
EAP-01
Comment type: Technical
Priority: S
Section:
4.2.1
Rationale/Explanation of issue:
At IETF56 it was proposed to tighten the EAP state
machine so as to
preclude a number of possibilities,
including changing Type in the middle of
a method, and
sending an EAP Success or Failure before a method is
complete.
Change Section 4.2.1
"4.2.1 Processing of success and failure
Within EAP, success and
failure indications consist of the EAP
Success and Failure messages, as well
as method-specific indications.
Within EAP, these indications may be
protected or unprotected.
EAP Success and Failure packets are considered
unprotected
indications which may be spoofed, since as described in Section
4.2,
they contain no message integrity check (MIC).
In order to
provide additional protection against tampering, EAP
methods MAY support a
MIC that covers some or all of the EAP packet,
including headers. In
addition, such a MIC MAY include coverage of
previous Request and Response
messages, so as to enable protection of
other packets to that do not contain
MICs, such as Identity Request/
Response, Notification Request/Response and
Nak Response.
EAP methods also MAY include support for method-specific
acknowledged
success and failure indications. This enables the authenticator
to
indicate whether the peer has successfully authenticated, as well
as
for the peer to acknowledge receipt of that indication, and
respond
with an indication of whether the authenticator has
successfully
authenticated to the peer. If a key has previously been derived,
the
result exchange MAY be protected by a Message Integrity Check
(MIC),
and if so, then this success/failure indication is
considered
protected.
In order to decrease vulnerability to spoofing
of success and failure
indications, the following processing rules are
recommended:
[a] Processing of protected success and failure indications.
Where a
method-specific protected success/failure indication has
been
received, the implementation MUST validate the EAP method MIC,
with a
MIC failure handled via silent discard, as specified in
Section
4.1.
[b] Receipt of EAP Success and Failure packets prior to
method
completion. A peer EAP implementation receiving an EAP
Success
packet prior to completion of the method in progress MUST
silently
discard it. This ensures that a rogue authenticator will
not be able to
bypass mutual authentication by sending an EAP
Success prior to conclusion of
the EAP method conversation. A
peer EAP implementation receiving an EAP
Failure packet prior to
completion of the method in progress MAY silently
discard it.
When using EAP methods that provide their own (protected)
error
indications, premature EAP Failure packets are unexpected, so
that
this technique may be more readily employed.
[c] Authentication
requirement. An EAP peer implementation that has
been configured to require
authentication MUST silently discard a
"canned" EAP Success message (an EAP
Success message sent
immediately upon connection).
[d] Contradictory
indications. Where protected and unprotected result
indications are both
available, protected indications take
precedence. For example, where an EAP
method provides a
protected indication that authentication failure has
occurred in
either direction, the implementation MUST silently
discard
subsequent EAP Success packets. Similarly, where an EAP
method
provides a protected indication that authentication has
succeeded
in both directions, the EAP implementation MAY silently
discard
EAP Failure packets.
[e] Processing of EAP Success and Failure
in the absence of protected
indications. Subsequent to the completion of the
EAP
authentication method (Types 4 and greater), and in the absence
of
protected result indications, EAP Success and Failure packets
MUST be
accepted and processed by the EAP implementation."
To:
"4.2.1 Processing of Success and Failure
EAP Success or Failure
packets MUST NOT be sent by an authenticator
priorto completion of the final
round of a given method.
A peer EAP implementation receiving a Success or
Failure
packet prior to completion of the method in progress MUST
silently
discard it. By default, an EAP peer MUST silently discard a
"canned" EAP
Success message (an EAP Success message sent
immediately upon connection).
This ensures that a rogue authenticator will not be able
to bypass mutual
authentication by sending an EAP
Success prior to conclusion of the EAP
method conversation."
Also, add the following section to the Security Considerations Section
"7.X Strict Interpretation
An EAP method wishing to enforce tighter security
than is provided by the
packet processing rules of
Section 2.1 and 4.2.1 MAY indicate
within
their specification that they follow a
"strict interpretation" of EAP.
When requested by a method, "strict interpretation"
causes the EAP
implementation to impose inbound filter
rules from the point where an
initial Request is
answered with a Response of the same Type, until
the
method completes. "Strict interpretation" also
implies that on completion the
peer method will
indicate whether it succeeded (was able to
authenticate
the authenticator) or failed (did
not succeed in authenticating the
authenticator).
An EAP method making use of "strict interpretation"
must
include a definition of completion for both the peer
and
authenticator, and also must indicate the conditions
under which successful
completion will be indicated.
The filter rules are as follows:
[a]
On the peer, all EAP packets are silently discarded, except
for those with
Code=1 (Request) and Type=Method-Type.
This implies that methods supporting
"strict interpretation" do not
utilize Notification, but instead support
their own method-specific
error messages.
[b] On the peer, once the
method completes unsuccessfully,
the EAP conversation is terminated, the
link is not enabled and
Success packets are silently discarded. If the
conversation
completes successfully, then Failure packets are silently
discarded.
[c] On the EAP server, once the initial EAP Request is
responded
to with an EAP Response of the same Type, all EAP packets
are
silently discarded, except those with Code=2 (Response) and
Type=EAP-Method-Type.
Implementation note: While none of the methods
defined in
this document support strict interpretation, EAP-TLS
[RFC2716] implementations SHOULD support strict interpretation."
Proposed Resolution: Accept
Issue 98: State machine
issues
Submitter name: Jari Arkko
Submitter email address:
jari.arkko@piuha.net
Date first submitted: March 17, 2003
Reference:
Document: SM-01
Comment type: Technical
Priority: S
Section:
Various
Rationale/Explanation of issue:
Thanks for taking the effort to produce the new state
machine
document. I have a few comments and a number of
questions,
embedded inline in the URL below:
http://www.piuha.net/~jarkko/publications/eap/sm01_review.txt
[Jari Arkko, 5/14/03]:
Thank you for the new state machine document! This
version
(-02) is much better than the previous one.
I still have some comments,
though, and I will send
them as my review of the document
progresses.
The first comment is that I checked issue #98 that I
filed
earlier on the -01 document:
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2098
It
seems to be handled, but there's a few details left that
should perhaps be
fixed:
- Delete the paragraph from the abstract that
starts
with "This document is still a work in progress." Sure
it
is, all I-Ds are and we'd have to remove the
statement
anyway at some point...
- The text and the
state machine pictures are inconsistent in
the capitalization of
the ELSE label. Sometimes "ELSE", sometimes
"else".
- I
still didn't find any statement that would clarify the
role of
the state machine transitions vs. MAY/SHOULD/MUST
requirements
in 2284bis. I *think* your intention is that
any transition-like
requirements end up as transitions in
your document, regardless
of the strength of the keyword
possible associated with it in
some other document.
Suggested text to add in 3.2 or other
appropriate place:
"This document specifies the possible
transitions and
actions for EAP peers, authenticators, and
pass-through
authenticators. It does not attempt to characterize
the
RFC 2119 requirement levels (MAY, SHOULD, MUST, and
so
on) of these transitions."
- The "methodState = { SUCC
| CON_SUCC | ... }" notation has not
been explained.
- In
the text:
"Next, the method must decide whether to process
the packet or
silently discard it. If the packet looks
like it wasn't sent by the
legitimate authenticator (e.g.
it has invalid MIC, and this case
should never occur), the
method can set intCheck=FALSE. In this
case, the
method must not modify methodState, and it should not
modify its own method-specific state."
It is not 100% clear
that MICs are optional. Suggested rewrite:
"Next, the method
must decide whether to process the packet or
silently
discard it. Some methods may use MIC values in the
messages to ensure that the messages have been sent by the
legitimate authenticator. If the method can perform such
a
check, and finds that the MIC is invalid, it sets intCheck
to FALSE. In this case, the method must not modify
methodState,
and it should not modify its own
method-specific state."
Proposed resolution: Accept
Issue 99: Double
expansion
Submitter name: Bernard Aboba
Submitter email address:
aboba@internaut.com
Date first submitted: March 17, 2003
Reference:
Document: KeyFrame-06
Comment type: Technical
Priority: S
Section:
Various
Rationale/Explanation of issue:
The EAP keying framework typically involves a double
expansion:
a. The MSK is typically expanded from the MK.
b. In
802.11 the TSKs are expanded from the MSK.
The draft should include a
discussion of the risks associated
with this (somewhat dubious) practice.
[BA] The issue is not really double expansion, but
key
strength. If the keys are strong enough, double
expansion is not a problem.
Proposed resolution: Reject