This page contains the list of open and resolved EAP Issues. Current status of EAP WG drafts is as follows:
IETF Last Call
RFC2869bis (Ends 3-11-03)
EAP WG Work Items
Individual submissions not yet approved as WG work items
Compound Binding Problem Draft
Related work
http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt
http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf (userid: p8021, password: go_wildcats)
Issues List
A description in red implies that no issue has been submitted (if you are the owner of such a message, please send Bernard Aboba an issue). An asterix following an Issue number (e.g. Issue #666*) means that the issue entry is not up to date, and the author is expect to send additional text to Bernard Aboba .
To submit a new issue, send an e-mail to the EAP Mailing List, using the following template:
Description of issue
Submitter name: Your_Name_Here
Submitter email address: Your_Email_Address_Here
Date first submitted: Insert_Date_Here
Reference: URL to e-mail describing problem, if available
Document: Document Requiring change [RFC2284bis, RFC 2869bis, Keying Framework, EAP Binding, State Machine]
Comment type: ['T'echnical | 'E'ditorial]
Priority: ['S' Must fix | '1' Should fix | '2' May fix ]
Section: Insert_Section_Number_Here
Rationale/Explanation of issue:
Length description of problem
Requested change:
Proposal
For open issues, the following values are used in the Status Field:
Text Proposed - Text has been proposed on the list, and no consensus has been reached
Accepted - Text has been proposed, consensus has been reached, but the fix hasn't been included in a specification yet.
Pending - Discussion is on-going, no proposed text has been proposed
No Discussion - No discussion has been initiated on this issue.
Clarifying Text Required - The issue can be closed if additional clarifying text is added to the draft
Possible Reject - Issue will be rejected unless objections occur.
| RFC2284bis Open Issues Issue Number |
Status | Description | Owner |
| Issue 74 | EAP-02 | Concern on invalid MIC | Yoshihiro Ohba |
| Issue 80 | Pending | Success Indications | Nick Petroni |
| Issue 87 | Text Proposed | Handling of EAP Type Change | James Carlson |
| Issue 91 | EAP-02 | Definitions | John Vollbrecht |
| Issue 92 | EAP-02 | Integrity Protection | John Vollbrecht |
| Issue 94 | EAP-02 | Is EAP a lock-step protocol? | Pasi Eronen |
| Issue 96 | EAP-02 | Notification Clarification | Yoshihiro Obha |
| Issue 97 | Text Proposed | Strict interpretation | Bernard Aboba |
| EAP State machine Issue Number |
Status | Description | Owner |
| Issue 3 | Pending | EAP needs a state machine | Bryan Payne |
| Issue 98 | No Discussion | State machine issues | Jari Arkko |
| EAP Keying Framework Issue Number |
Status | Description | Owner |
| Issue 15 | Pending | NASREQ Key Distribution insecure | Jesse Walker |
| Issue 47 | No Discussion | Keying requirements not specified | Bernard Aboba |
| Issue 71 | Key Frame-06 | Key framework review | Jari Arkko |
| Issue 99 | No Discussion | Double Expansion | Bernard Aboba |
| RFC2869 Open Issues Issue Number |
Status | Description | Owner |
| Issue 83 | Text Proposed | Invalid packet handling | Bernard Aboba |
| Issue 84 | RFC2869bis-10 | Miscellaneous Nits | Steve Bellovin |
| Issue 85 | RFC2869bis-10 | Minor editorial comments | Pasi Eronen |
| EAP Binding Issues Issue Number |
Status | Description | Owner |
| Issue 64 | No Discussion | Problem statement issues | Bernard Aboba |
| Issue 65 | No Discussion | Downgrade attacks | Dan Simon |
| Issue 70 | No Discussion | Which PRF? | Bernard Aboba |
| Issue 88 | No Discussion | Review of Binding-01 | Jukka Ylitalo |
| Issue 89 | No Discussion | Comments on Binding-01 | Jari Arkko |
| EAP Extensions Open Issues Issue Number |
Status | Description | Owner |
| Issue 10 | Pending | No support for acknowledged Success or Failure | Simon Blake-Wilson |
| Issue 17 | Pending | EAP Negotiation Method | Caron |
| Issue 26 | Pending | Unprotected Success and Failure | Jesse Walker |
| Issue 38 | Pending | Language negotiation | Bernard Aboba |
The following table contains the issues that have already been resolved, and the fix included in a revision of the specification.
The following are the long form versions of the issues:
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.com/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.com/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.
Resolution: Accept
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.
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.
Resolution: Accept
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."
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.com/pipermail/eap/2002-February/000015.html
http://mail.frascone.com/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.
Resolution: Accept
Security considerations section rewritten in RFC2284bis-04.
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.
Resolution: Accept
UTF-8 now required in displayable messages (RFC2284bis-04)
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/issues.html#Issue #294
Document: RFC2548
Comment type: T
Priority: S
Section: 2.4.2, 2.4.3
Rationale/Explanation of issue:
This is a placeholder for an issue under consideration in the AAA WG.
Resolution: Discuss
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 #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.com/pipermail/eap/2002-February/000046.html
http://mail.frascone.com/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=20
discard EAP packets based on an incorrect ICV.=20
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=20
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=20
"same" packet and kind of "fork" separate states for each=20
processed packet. The spoofed states should later be detected
and removed, but if the valid packets were processed separately,=20
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=20
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."
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?
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.com/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.com/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.com/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.com/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?
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.com/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
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.com/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.com/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.com/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 methods such as EAP-TLS [RFC2716] define a MIC
covering an extended PDU that could be split
into multiple fragments, or that can cover portions of earlier
messages (FINISHED message). Where the MIC
covers more than one EAP packet, a 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.com/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
Recommended Resolution: Discuss
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-09
Comment type: Technical
Priority: S
Section: 2.5
Rationale/Explanation of issue:
As part of the response to
Issue 74, the following text needs
to be added to RFC 2869bis:
"2.5 Invalid packets
A RADIUS server receiving EAP-Message attribute(s) it does not understand
MAY return an Access-Reject. In order for the RADIUS server to
communicate that an invalid EAP packet has been received, but
that the problem is non-fatal, an Access-Challenge containing a
Service-Type=Packet-Reject MAY be sent. In some cases, the EAP method may
make the determination of whether the error is fatal or non-fatal.
A NAS compliant with this specification, on receiving an
Access-Challenge with a Service-Type=Packet-Reject,
SHOULD discard the current EAP packet, and check whether
it has received additional EAP Response packets with an
Identifier matching that of the last Request. If so,
a new EAP Response packet, if available, MUST be sent to the RADIUS server
within an Access-Request packet. In order to provide protection
against Denial of Service (DoS) attacks, it is advisable for
the authenticator to allocate a finite Response buffer,
and to discard packets according to an appropriate policy once
that buffer has been exceeded.
Once the RADIUS server responds with a packet containing a
non-null EAP-Message attribute, the NAS updates the
Identifier value, and any pending Responses that do
not match this value can be discarded. If another EAP Response
packet is not available, then the retransmission timer is
reset and the NAS retransmits the outstanding Request to the peer.
A NAS that does not support Service-Type=Packet-Reject behaves
as specified in [RFC2865], Section 5.6:
"A NAS is not required to implement all of these service types,
and MUST treat unknown or unsupported Service-Types as though
an Access-Reject had been received instead."
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=20
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=20
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.com/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;=20
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: Accept
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.com/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.com/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.com/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:
"Integrity protection
This refers to per-packet authentication of all EAP packets,
including EAP Requests and Responses. When making this claim,
a method specification MUST describe the fields within the EAP
packet that are authenticated."
[Based on comments from Henrik, Nick, John and others]:
Revise to:
"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 (with modifications)
Issue 93: Simplify Description
Submitter name: John Vollbrecht
Submitter email address: jrv@umich.edu
Date first submitted: March 3, 2003
Reference: http://mail.frascone.com/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.com/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. Success
and Failure packets MUST NOT be sent as the result of a timeout."
In RFC 2869bis, add the following text to Section 2.1:
"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. Success
and Failure packets MUST NOT be sent as the result of a timeout."
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.com/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."
Issue 97: Strict interpretation
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 7, 2003
Reference:
Document: EAP-01
Comment type: Technical
Priority: S
Section: 4.2.1
Rationale/Explanation of issue:
John Vollbrecht has proposed tightening of 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 message is
complete.
As an alternative to that approach, a method-specific
notion of "strict interpretation" is offered here.
Proposed resolution (rewrite of Section 4.2.1):
"4.2.1 Strict Interpretation
In order to decrease vulnerability to spoofing of EAP packets,
including Success packets, EAP methods 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).
Unsuccessful method completion results in
termination of EAP authentication and silent
discard of EAP Success packets.
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=EAP-Method-Type.
Therefore when "strict interpretation" is in effect,
Identity requery or Notification cannot be supported.
[b] On the authentication server (pass-through) or
authenticator (non-pass-through), all EAP packets are
silently discarded, except those with Code=2 (Response)
and Type=EAP-Method-Type.
[c] When "strict
interpretation" is in effect, a peer MUST NOT
send a Nak (legacy or expanded) in reply to a Request, after
an initial non-Nak Response has been sent.
Implementation note: None of the methods defined in
this document support strict interpretation.
Authenticators operating in pass-through mode
cannot support "strict interpretation",
since this would require that the authenticator be
upgraded to support new methods."
Proposed Resolution: Discuss
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
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.