One document matched: draft-ietf-eap-esteem-01.txt
Differences from draft-ietf-eap-esteem-00.txt
EAP Working Group B. Aboba, Editor
INTERNET-DRAFT Microsoft
Category: Informational
<draft-ietf-eap-esteem-01.txt>
9 January 2003
Eap STate machinE dEsign teaM (ESTEEM) Discussions
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes the deliberations of the EAP STate MachinE
DEsign TeaM (ESTEEM). This includes minutes of meetings, as well as
position papers.
Esteem Informational [Page 1]
INTERNET-DRAFT ESTEEM 9 January 2003
1. Key Issues for Resolution in RFC 2284bis
Nick Petroni
October 14, 2002
I see three major areas at first glance. This is not
comprehensive, just off the top of my head.
a. EAP MUX/method and method/method interaction.
It seems most people have settled into the MUX paradigm and some of the
details have been decided such as:
- MUX and not methods sending Success/Fail
- Methods cannot be interrupted (one method at a time)
- Identity is a special kind of method (can't be NAK'd, etc.)
but other details don't seem clearly defined. In particular
- How does information get passed from method to method? through the
MUX? directly between methods? not at all? Since Methods can send Id
REQ themselves, is it assumed all methods have access to this info?
- How does the MUX know a method has begun/finished? This is
particularly important in terms of success/failure only being
allowed at specific times. We have discussed authMethodSuccess and
Fail indications, but I don't think these have been set in stone.
- How is order determined? Is this standardized, or just blanketed by
policy? Do methods get to pick "I want to be followed by X and will
only go after Y"? Is it enough to say something such as "MD5 before
TLS" and
what does that mean for cases where the same auth method could be
run twice, e.g. "MD5 TLS MD5". I don't see why one would want to do
this, but should the protocol allow it? Since there could be
multiple back-end servers involved, it seems more likely than I
would hope. Is it significant which MD5 goes first?
- how are methods with specific requirements like being the last
method run handled? Does the method tell the MUX this or is it part
of policy? Packet filters have been discussed here, but how/when are
these specified by the method?
b. Policy specification
- If order is part of policy, how is it specified?
- it seems that any method can update policy (as shown in the state
machine draft) and only the MUX can determine if the whole policy
has been satisfied. how does this work for encapsulated methods such
as PEAP? do they have their own policy with the outer policy just
requiring "PEAP with policy x" to be successful?
- can general policy rules such as "any protocol providing successful
mutual authentication"? how are these specified?
- are there limitations/specifications for how a method interacts with
policy? For example, will statements such as "All methods must
Esteem Informational [Page 2]
INTERNET-DRAFT ESTEEM 9 January 2003
update policy variable X" be added to the bis?
c. Error handling
Conversations have ranged from adding a new message to modifying an
existing one or just punting on errors all together. This could go any
direction, but all would affect the state machine.
2. Meeting minutes
2.1. September 25, 2002 Minutes
EAP Design Team Meeting Minutes
Scribe: Paul Congdon, HP
09/25/02
Yoshi's Paper
a. Issue 1 - How to handle notational conventions within state
diagrams. There is also an issue relating to handling of the timing.
Suggest two solutions - use an already defined convention (e.g.
IEEE 802.1X) or use other current and more formal conventions. Chuck
believes current format is less formal and unclear on how steps within a
state are executed and whether they are atomic or not. Paul suggests
adding words from 802 documents that clarify. Other believe that real
events should be noted in the transitions not just variables.
Bernard raises a question about sub-machine interactions and the
entrance points. Unclear what information is available to methods. For
example, is information in an Identity exchange available to the method?
What about NAK? Notification? Wording can be added to clarify entry
points.
Do methods need to know about one another? If so, how is
communication facilitated? We don't want to allow this to be an exercise
for the reader. Perhaps RFC2284bis needs an abstract API to allow this?
The concept of an EAP mux helps clarify how the state machines
interact.
Seems to be some agreement that we can slightly deviate from the
802 machine format, but keep the spirit intact such that it is obvious to
the reader. This makes it easier to synch the EAP and 802.1X state
machines.
b. Issue 2 - Identity exchange is optional, but the authenticator
machine doesn't really support it well.
Some would prefer to see ID exchange as simply one of the methods.
However, would the ID method ever occur without other methods invoked?
Esteem Informational [Page 3]
INTERNET-DRAFT ESTEEM 9 January 2003
Not likely, but certainly multiple IDs exchanges could be possible.
Methods can't interrupt other methods. There is an assumption that a
variable exists that controls the authenticator to send or not the ID.
This variable is not specified in 802.1X or the EAP state machine
document.
>From the Radius server's point of view, the ID exchange starts out
as a method, but RADIUS servers often receive the Access Request after the
ID Request has been sent by the Authenticator, answered with an ID
Response from the Supplicant, and the Identity placed in a User-Name
attribute. So the RADIUS server typically does not request an Identity
exchange.
There is a need for a needID variable that drives the backend
state machine as well. It actually describes what the first step is for
each method. How is this variable controlled when multiple methods are
changed. For example, if needID is set then the Authenticator starts out
by sending an Identity Request. If not, then it sends an Access-Request to
the RADIUS server (which can't contain a User-Name attribute because the
identity isn't known yet).
Consensus that a needID is needed, but unclear how it is
controlled still. Still unclear if ID exchange should be thought of as a
method. If it is a method, do we still need needID? If it is a method,
it should fold into the current proposed machines without significant
disruption. No conclusion yet if ID exchange is a method.
c. Issue 3 - Inconsistency when processing NAK.
Can't a NAK break the in-progress EAP method? Typically this
means the Supplicant doesn't want to run this method, so he NAKs with
alternatives. It is up to the authenticator to decide what method will
run next if any.
It appears that currently the NAK can be sent anytime, so perhaps
it should be its own machine. It can be sent in the middle of a method to
abort is, but some don't like this behavior, because it allows an attacker
to stop an authentication in progress. The objective of the NAK message
is to negotiate a method (it has also been used for negotiation of a
sub-method within the method, but not clear it is appropriate for that),
but should it be used to abort the method? The NAK as an abort doesn't
fully describe why the abort is taking place, so perhaps an error or abort
message needs to be created. There is no notification message from the
peer to the authenticator. Sending anything in the middle of an exchange
could be an issue anyway from a security point of view. If you simply
stop responding to the exchange in the middle, it will timeout eventually
and another method proposal will come along. This could be NAK'd at that
time.
Esteem Informational [Page 4]
INTERNET-DRAFT ESTEEM 9 January 2003
There seems to be consensus that NAK should only be used for
method negotiation. For aborting we should do something different.
Choices include keep it the same, timeout, new message, NAK with
parameter, etc. These choices need to be explored further.
It was noted that the method really starts with the first message
and the NAK is a response to the first message of the method, so reception
of the NAK is really just a condition of the method. However, each method
really needs to start out in a proposal phase where NAK is one possible
response. How does the mux know what is going on here? Does the mux
keep state, and know when the proposal phase has ended (after which NAK is
no longer allowed)?
Another topic to discuss is acknowledgements of success and
failure messages. This isn't possible in RFC 2284, but perhaps a new
message is needed?
Timer events in the state machines aren't described. This is
tricky because user input changes all the timing.
Another issue raised is how much constraint can we put on all EAP
methods? Is the EAP method state machine a black box or must it conform
to some more specific guidelines or some specific required states. For
example, is there an abstract API that describes how an EAP method
interacts with the mux and the EAP state machine? For example, are there
variables set within the method that influence behavior of the mux? For
example, the method might tell the mux whether authentication had
succeeded or failed, etc.
Yoshihiro Ohba's Minutes
EAP Design Team Tele-conference Minutes
Date: 11am-12pm, September 25, 2002
Participants: Bernard Aboba, Jari Arkko, Paul Congdon*,
Robert Moskowitz, Yoshihiro Ohba*+, Bryan Payne,
Nick Petroni, John Vollbrecht
*Minutes takers
+Minutes taker of this memo
(Please point out if your name is missing or you were not
participated in the conference call.)
Minutes:
All participants agreed on the proposed approach based on two position
Esteem Informational [Page 5]
INTERNET-DRAFT ESTEEM 9 January 2003
papers, one for reviewing 802.11a (topic a) and the other for reviewing
the EAP state machine draft (topic b). Both position papers include
comparison with the RFC2284bis draft.
The following issues related to topic b were discussed (the issues are
described in a write-up posted on the EAP design team mailing list by
Yoshihiro Ohba):
o Notational conventions for state diagrams
o Optional identity support
o NAK message handling
a. Notational conventions for state diagrams
Precise definition for notational conventions is required for the
state machine. It was agreed that using the conventions used in the
IEEE 802.1X specification with allowing some augmentation is better
for the following reasons:
- 802.1X conventions are precise
- By using 802.1X conventions, EAP state machine
would be better aligned with 802.1X state machine.
- On the other hand, boolean variable-based event transition
defined in 802.1X might not be useful if we consider simplicity
for the state machine description. So some augmentation by
allowing "real-event" based state transition would be better.
It is pointed out that in the Authenticator SM (State Machine) there
are multiple entrance points from a sub-SM (i.e., Method Authenticator
SM) and there is a question that the sub-SM behavior may depend on
which entrance point is used. However, in the case of EAP, the
sub-state machine behavior should not depend on where the transition
came from, meaning that some additional convention for describing each
method SM (e.g., every method SM starts from a single initialization
state) might be necessary.
There is another issue on what information is available from each
method SM (e.g., each method SM may require Identity information).
This might be an issue of EAP abstract API.
b. Optional identity support
The RFC2284bis draft describes that Identity message exchange
is an option, but the EAP state machine is not sufficient
to support the option.
Esteem Informational [Page 6]
INTERNET-DRAFT ESTEEM 9 January 2003
A flag variable "NeedID" is needed to indicate whether identity
exchange is required or not. The variable is initialized within
initPolicy(). It is also necessary to be able to change the value of
this flag in the mid of authentication (at the beginning of each
method) when multi-authentication is used, since some methods in a
multi-authentication session may require identity exchange while
others may not.
There is an open issue on whether the state for handling Identity
exchange should be defined in a distinct method SM or in the
multiplexer SMs (i.e., outside of any method SM, as described in the
current state machine draft).
c. NAK message handling
There is an issue on where to define the state for handling NAK
message.
A NAK message MUST NOT be used for "aborting" the current method in
the mid of the method and should be used for the first EAP Request
message of the current method only.
There are two approaches to achieve this:
- define a state for handling NAK message outside of each method SM,
perhaps with defining a global variable that indicates whether the
NAK message can be processed or not (the value of the variable can
be set by each method SM).
- define a state for handling NAK message in each method SM.
d. Candidate issues to be discussed in the next tele-conference:
o Remaining issues described in the write-up by Yoshihiro Ohba
o Position paper from UMD
o EAP multiplexer issues posted by John Vollbrecht
o Any discussion on topic a.
2.2. October 2, 2002 Minutes
Minutes EAP State Machine Design Team
-------------------------------------
Date: 10/2/2002 11am-12:15 EDT
Esteem Informational [Page 7]
INTERNET-DRAFT ESTEEM 9 January 2003
This week's meeting completed discussion of
Yoshihiro Ohba's (yohba@tari.toshiba.com) position paper on
the EAP state machine draft (topic b).
* last week we discussed issues 1,2,3, this week begin with issue 4
* Issue 4: Support for multiple authentication methods in a single session
Yoshihiro's Position: We should define policy parameters common to all
EAP methods that provide for multiple authentication methods.
Discussion: the conversation ranged over a variety of subjects
relating to the interaction between multiple methods, when
notifications should be allowed, the nature of special "protected"
methods, protected success and failure messages, and when success
and failure are valid.
Some key points from the discussion:
-- Some methods run as a protection of other methods. These
methods appear to the MUX as a single method, but may have
special requirements such as being the last method run and
disregarding ALL unprotected messages, including
Notifications. The discussion thus turned to when
notifications should be allowed and whether methods are
currently using notifications or whether these are messages
that should be handled at the MUX layer. The decision was made
to separate these issues from the current discussion.
* A survey would be sent to the EAP list to determine current
usage of notification messages
* Position papers would be accepted on whether or not a
method should be implementable such that it is only the
last method and, if so, how that method interacts with the
MUX. Some felt that it should be left to policy to disallow
other methods after methods like PEAP and not the method itself.
-- The group discussed the nature of method-specific success and
failure and how they interact with EAP success/failure.
-- The group discussed and agreed that Success messages should
only be sent at the end of a sequence and not after each
individual method succeeds. This implies that it is the MUX who
controls sending success messages. This issue is revisited in
issue 5 below.
-- The group discussed the role of policy in deciding method
order and concluded that policy can be responsible for
Esteem Informational [Page 8]
INTERNET-DRAFT ESTEEM 9 January 2003
specifying method order, but that a default peer policy should be
defined that provides for the allowed methods to be
accepted in any order. There was additional discussion on
the implications of peer and authenticator disagreeing about
order since there is no synchronized schema between the two.
* Issue 5: Pass-through EAP authenticator state machine
Yoshihiro's position: Should define special state machine for
pass-through
Discussion: The conversation lead primarily down two paths-
(a) the differences in 1x and PPP with respect to last message
delivery and the necessity to generalize for media
independence. At this point the sending of a success message by the
MUX was revisited considering both the 1x and PPP case
(b) the nature of Identity messages including the ability for
either Authenticator or Auth Server to request ID, the possibility
for different auth servers to be used depending on the ID response,
and the authenticator's desire to always know auth replies for
accounting/audit purposes.
Additional discussion brought up that a number of new mediums are
being discussed, thereby illustrating the need for a single unified
protocol definition
Next week will continue with the remaining item b position papers.
2.3. October 9, 2002 Minutes
Minutes of the EAP state machine Design Team conference call
Date: October 9th, 2002, 18:00-19:00 EET
a. Agenda
- Report on 802.1aa (Bob Moskowitz)
- University of Maryland position paper
- Bernard's position paper
- Jari's position paper
b. Report on 802.1aa
Bob was the only one present in the 802.1aa meeting, but
he wasn't present in the conference call.
Esteem Informational [Page 9]
INTERNET-DRAFT ESTEEM 9 January 2003
c. Jari's position paper
This position paper studied whether the proposed EAP state
machine has (message, state) pairs for which no actions have
been defined. Several such pairs were found. Some of these
pair are missing on purpose, while others are either mistakes
or under-specification. The paper classified the issues around
the following main problems:
- When can Failure come?
- When can NAK come?
- When can Identity Request come?
- When can Notification come?
- Should 2nd, 3rd, ... internal method requests be modeled in the
main state machine?
- Should we treat protocol errors in the
state machine or not?
o Failure:
- The issue is whether peer should accept Failure only after
a method execution, or also in the unauthenticated state
before any methods.
- DECISION: Peer should accept Failure in unauthenticated state.
- There was a discussion of whether such failures can be based
on the NAI given in an Identity Response. There are security
issues around exposing valid / invalid user names. It was
unclear whether there are similar issues in exposing domains
for which the authenticator is unable to perform authentication.
- DECISION: We should document the security considerations
about this, but not prevent / mandate any specific behavior.
- Bernard: Filters may prevent failure messages if the method
is protected and wants a protected failure report. Methods
may install such filters.
o NAK:
- We decided to talk about this in more general manner
in the context of protocol errors.
o Identity request:
- The issue is whether Identity Request can be NAK'd,
whether Identity Request can be repeated, whether it
can come during the execution of a method or only in between.
- Also, can a method ask for an identity request to be sent?
- Can a method get the information from an identity response?
- John asked whether the state machine goes through the unauthenticated
state as it moves from one method to another. The answer is yes.
- Bernard said that we should avoid having to give policy for
EAP nodes; this is usually a sign of a lack of specification.
Esteem Informational [Page 10]
INTERNET-DRAFT ESTEEM 9 January 2003
Sequences of methods, different combinations can create problems
and lots of NAKking if policies dictate too much.
- Is identity a method? Can you NAK identity? RFC says no, and some
implementations are known to not be able to process such NAKs.
- Bernard: RFC set Identity Requests to be optional, but 802.1x made
it mandatory. This is a conflict. What if both sides don't want it?
- Bernard: Perhaps we should request 802.1x to make it optional also.
This may not be easily adopted by 802.1aa, however. One issue is that
they would like to have a solution from the IETF that works without
configuration.
- Jari: There is a danger that if we don't allow NAKs, we will soon
develop a convention where an empty NAI implies that the identity
does not exist or we don't want to give it.
- DECISION: Identity request/response can only appear between methods
- DECISION: Our preference is that identity requests be optional. (And
we are leaning towards making NAK disallowed.)
- DECISION: Work on the text on the list.
- DECISION: Talk with 802.1aa about the situation.
o Notification:
- DECISION: Discussion elsewhere appears to lead to allowing
Notification in all states.
- DECISION: Can not be NAK'd.
o 2nd, 3rd messages
- John: Multiplexor model will make this clearer
- Can we execute methods in parallel, 1st message
from 1st method, 1st message from 2nd method, ...
2nd message from the 1st method, 2nd message from
the 2nd method, ...?
- DECISION: No. Methods must be done one at a time.
- There must be a concept of activating and deactivating
a method.
- Bernard: Acceptance locks you to the method
- Jari: Do we need to model this in state machine?
- John: yes
o Protocol errors:
- The issue is whether the state machine should say
something about what to do when invalid EAP messages
arrive. This may be necessary for recovery etc. purposes.
- Bernard: There's certainly errors in individual methods.
- Not all protocol errors need the same treatment
- Bernard: Its a reasonable question to ask what to do in a protocol
error situation, if the spec says something is that
- Should silent discard be used?
- We should avoid making Denial-of-Service attacks too easy
- John would like to have positive confirmation of a failure
Esteem Informational [Page 11]
INTERNET-DRAFT ESTEEM 9 January 2003
rather than stubbornly trying and timing out later
- Servers could send a Notification
- There is a usability tradeoff: failure report quickly vs better
Denial-of-Service resistance
- John: Could we send a NAK with a message?
- Bernard: Implementation backwards compatibility prevents NAK changes
- Is there a need for a new message?
- Jari: We have the following options to deal with
unexpected protocol messages:
1) Silent discard and wait for proper message; this often
leads to a timeout if the discarded message really was
from the authenticator.
2) Immediately abort everything and exit from EAP.
This provides a quick indication to the user,
but is very fragile wrt Denial-of-Service attacks.
3) Provide a new abort message with support for authenticating
that the other side really sent the offending message.
It is unclear how complicated this is.
4) A new notification message could be design for peer=>authenticator
direction. This would allow implementations to report problems,
without making the protocol very vulnerable to Denial-of-Service.
- DECISION: We need separate discussion on errors.
- Jari: I will write something about it.
d. Concluding remarks
- Other two position papers will be dealt with later.
- John: We've made a lot of progress lately in the issues.
The main remaining issues are policy issues and dealing
with protocol errors.
- Jari: We will continue with the conference calls, but probably
need also to do e-mail reviews of the position papers.
2.4. October 23, 2002 Minutes
Present: Bob Moskowitz, Nick Petroni, Jari Arkko, Yoshihiro Ohba, Glen
Zorn, John Vollbrecht, Paul Congdon, Joseph Salowey
Scribe: Jari Arkko
1. John's position paper.
- Was submitted, but bounced the list.
He started to do state tables which
assumes the methods can also provide
information to the EAP mux. Clearly needs
more work, but he'd be happy to pursue it.
- There's a couple of main things:
- It would be possible to map this back to the states
Esteem Informational [Page 12]
INTERNET-DRAFT ESTEEM 9 January 2003
that are in the state machine now. Though it doesn't
make any distinction about methods, even identity
is seen as a method.
- Assumes policing. Some of the actions assume
that policies will dictate certain things.
- Starts to imply things about the API.
- Bernard: This is fairly complete.
- Bernard: There are two cases when you receive
method X request. One, we are done and should
change state. Two, we need further requests.
In addition, there are error situations.
- Bernard: If within a method, you receive
another method, is this NAK'd or silently
discarded.
- DECISION: NAK is better than silent discard.
- Question: Is a failure of a method terminal?
We could either terminate EAP, or allow
continuation with another method per policy?
- John thinks we should allow the latter.
- Jari thinks we should not.
- Question: is the treatment of final success
or fail dependent on whether the previous method
failed or succeeded?
- Proposal: We need a new state for this.
- Question: is there a global state, what has
happened on all methods, useful maybe for
re-authentication? How can re-authentication
- Answer: Good question.
- Jari: Why is not authenticated vs. no current
methods there?
- Jari: Reformulated question: is Success / Fail
illegal at the beginning?
- Bernard: Maybe this is policy?
- Jari: If we can avoid policy, we should.
2. Moving Forward
o Drafts:
- Bernard: I encourage John to write up this
state machine with this draft.
- Jari: Should we have an individual draft by
Esteem Informational [Page 13]
INTERNET-DRAFT ESTEEM 9 January 2003
John, or merge drafts to WG draft status.
- DECISION: Too early now.
- Bernard: It would be better if Brian and Nick
could do another revision of their draft as well.
- DECISION: Priorities are: 1) follow decisions 2) be complete 3) follow 802
format.
- Jari: Need to capture current decisions. Bernard: We are tracking
the issues.
- Bernard: One of the open issues is described above
- Yoshihiro: We also need to consider the pass-through state machine.
- Jari: That can also be done as a separate draft.
- DECISION: By the I-D deadlines, we will have the following:
- 2-3 state machines
- rfc2248 updated to -07
- some solved issues
- many unsolved issues
- position papers and minutes will also be published
o IETF-55 and where do we go from there
- We will have a total of 4.5 hours and 2 slots.
- On the first day, state machine is important
and the issues are important
- Second day is still unclear
- What kind of method discussion we can have
is under discussion.
- John: Method discussion is key for EAP.
- Bernard: We need to try to discuss issues in the methods,
see if they are affected by state machine modifications etc.
- Process for evaluating methods.
Drafts solicited. Luca, Glen are writing something
about this.
- Glen: Cart is pushing the horse. Compatibility
with 802.1x is not so important. Bernard: Tony Jeffrey
views the 802 state machine as a way to shuffle
EAP packets around. The job of the IETF state
machine is to decide what to do with the packets.
Because the IETF state machine is link layer
independent, it is at a higher abstraction
layer. We will use similar format, but it
is not the intention to force this state
machine to comply with 802 state machine.
o Continue with dt meetings after initial I-D deadline?
Esteem Informational [Page 14]
INTERNET-DRAFT ESTEEM 9 January 2003
- John: Not available next week.
- Jari: We should continue.
- DECISION: Meetings continue and next week we will go
over the open issues.
2.5. October 30, 2002 Minutes
EAP Design Team meeting, Wednesday October 30th, 2002.
Minutes taker: Jari Arkko
o Agenda
Discussion of unresolved EAP issues:
http://www.drizzle.com/~aboba/EAP/eapissues.html
Discussion of cryptographic binding problems:
http://www.drizzle.com/~aboba/EAP/draft-puthenkulam-eap-binding-01.txt
http://www.saunalahti.fi/~asokan/research/mitm.html
Latest RFC 2284bis draft:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-07.txt
o Issue 2: Alternative indications
- Should these be kept or not?
- Are protected success and failure a form of alternative
indications
- Can the 802.1X messages be considered alternative indications
- Proposal: rate of loss is low enough, not a problem. Bernard: But
PANA folks are expecting to run this on GPRS!
- Question: what is the right thing to do from a security point of
view? Bob: we should require a success. Jari: depends on whether
the indication is protected. Bernard proposes that if a protected
indication is available, no alternative indications should be
listened.
- Is link up and down an alternative indication? Bernard thinks its
a different issue. In PPP, you would get back to LCP.
- EAPOL logoff, is it an indication or not? What if there's link
layer security? Will it help?
- Bernard: We probably need to listen to these alternative forms of
failure indication. This will open a DoS attack. Jari: The
Esteem Informational [Page 15]
INTERNET-DRAFT ESTEEM 9 January 2003
question is if this makes the situation any worse, there may be
other equivalent attacks already.
- Bernard: I don't like the argument but I can't argue much about
it. Let's look at EAPOL logoff as an example. Attacker sends
unencrypted EAPOL logoff messages to a multicast address. The
access point will have to relay those to all devices on the
wireless media, or even to the wired media. Debate whether peer
will act on this? Bernard: it doesn't matter, we can get mac
addresses and send unicast messages.
- Proposal (Bernard): Lots of ways to do these DoS attacks. Doesn't
seem possible to ignore these indications.
- Bob: we will see link ups and downs all the time anyway, we need
to ignore them in case the link comes back online soon. Bernard:
Agree.
- Bernard: This is like IPsec and ICMP; most implementations don't
believe ICMP but rather wait for an IKE timeout.
- Jari: the action depends on link layer, e.g. l2tp vs. physical
link. Bob: this should go to the link layer specific specs.
- DECISION Bernard & Jari: if an authenticated indication exists,
should not believe alternative indications (unless have to, like
the link really went away). In the absence of authenticated
indication, alternative failure indications may be accepted if the
lower layer specs say so. Success indication should not be
believed.
- Jari: I'm still unsure about this. What if I have successfully and
mutually authenticated the other side? Why would I not believe an
alternative success indication. Jari promises to write something
about this later.
o Issue 7: How to run multiple methods one after another
- Bob: What would a non-supported peer do if it get another method
and was expecting success or failure? Bernard: This ties to the
last issue. If it gets a packet it can't make any assumption about
the state. In Windows, authentication will time out. In a later
version with support, how would you know if the peer supports
sequences or not? Invent a new method to signal that you support
them or have it written in the specification that the methods
always support sequencing. Or negotiate? Bernard doesn't want to
add a round-trip for negotiation.
Esteem Informational [Page 16]
INTERNET-DRAFT ESTEEM 9 January 2003
- Bernard: We also need to discuss whether the end points have to be
the same all the time.
- Questions: 1) How to do sequences? 2) how to prevent mitm attacks?
- Question: Could we add a continuation flag to the header in a
backwards compatible way? (Bernard go look at the header.)
- Question: Can we send a NAK? Bob: In the Windows version it just
sits there and can't even NAK after having executed a method. So
we can't rely on NAK. The same applies to a new Command. So
the end result is in any case a timeout. The good news is that
all the latency is at the end.
- Yoshihiro says that if this results in a failure it is not a
problem. This is because if the authenticator wanted to do
multiple methods, the authentication will fail anyway.
- Bernard: Can we change the identity request to specify
if the peer can do multiple methods? Or we could have
this as a part of the user data base.
- DECISION (Jari): Its better to take the timeout at the
end for the people who will fail, than spend negotiation
time for everyone at the beginning.
o Issue 10: Lack of authenticated success and failure indications
- Bob: Security people want to have one point where success or
failure is indicated.
- Bernard: Can we require authenticated indications in some
situations, such as for sequences or tunnels? Probably we can't
mandate it for existing clients and the basic EAP situation.
- Bernard: Can't have authentication until keys are generated. Bob:
We can always do a Chap-like request-response which authenticates
an indication.
We could have an acknowledge-accept approach, and have it
mandatory for some new places where EAP is used, such as
GPRS or PANA EAP-over-IP.
- Jari: One idea is that if someone supports sequences,
they could use a protected success -method as the last
one in the sequence.
- Question: Is it sufficient to protect tunneled
Esteem Informational [Page 17]
INTERNET-DRAFT ESTEEM 9 January 2003
indications, or do we really have to support
also secure indications in sequences? (No opinion)
- DECISION: We can't put this in situations where
there are no sequences or tunnels. The rest of
the discussion has to be taken in IETF #55.
o Issue 13: Identifier usage not specified?
- Can we specify it to start from 0? It appears
more important to specify how it increases and
how ordering / duplicates are detected.
- Seems like the existing text is quite appropriate.
Does not mandate too much, but specifies enough.
- DECISION: Existing text is OK for #13 & #18.
o Issue 23: Contents of identity request payload
- The problem is if we have enough information in Identity Request
to be able to answer? In most cases we have some lower layer
information, such as the dialed phone number that tells you which
identity to use. Do we need something like this in the Identity
Request message?
- Bernard: Should the authenticator tell its NAI? Jari: Isn't this
a chicken and egg problem, how can the authenticator know what to
tell before it knows from which roaming ISP this user is from?
Bernard: There's methods out-of-band to EAP for knowing e.g. that
we clicked the AOL icon so we are looking to give AOL identity.
- Bob: I'm working on an extension to give a list of NAIs in the
identity request (or in the response). The request contents are
treated just as an advertisement. Bernard: This sounds good.
o Next meeting
- We will have a meeting next week (the last meeting
before IEEE and IETF)
2.6. December 11, 2002 Minutes
Date: Wednesday, December 11, 2002
Time: 8 AM PDT
Present: Bernard Aboba, Jari Arkko, Bob Moskowitz, John Vollbrecht,
Paul Congdon, Glen Zorn, ?
Scribe: Jari Arkko
Esteem Informational [Page 18]
INTERNET-DRAFT ESTEEM 9 January 2003
1. Preliminary discussion
This was the first meeting after IETF 55.
Based on looking at the state machine drafts, they look good but not
all design team decisions are yet adopted in them. The two drafts
are being merged into one and some more issues are resolved in them
at the same time.
IEEE 802.1aa ballot may affect state machine. We encourage people to
read the document and comment.
2. Discussion of EAP issues
http://www.drizzle.com/~aboba/EAP/eapissues.html
- 43: Security properties
Jari: Worry about requiring proofs. Bernard: Yes, it may not be
desirable. DECISION: We should encourage people to include
references to proofs and other analysis, but not require
proofs. Jari to write alternative text.
Bernard: Is the text on dictionary attack sufficient? Glen: Does
not sound too good yet. Bernard: Even liveness doesn't prove
resistance. Glen: Last part makes sense. Jari: I would just put
in that the spec must describe whether you are vulnerable to
dictionary attacks. Glen: There is a difference between dictionary
attack to a weak password vs. a method. DECISION: The following
text can be used: Assuming
there is a weak password in the secret, does the method allow a
an attack better than brute force? John: There is a further
distinction between off-line and on-line attacks. DECISION:
Let's not describe different variants of dictionary attacks,
instead reference text books on the subject.
Key strength determination: How do we count key strength, do we
count clear text nonces during EAP TLS negotiation to the
entropy? There is some counter-intuitive input on this subject
from known cryptographers. It is unclear if adding a PRF
function will create additional entropy or not. DECISION:
Bernard will ask the cfrg IRTF group what a good definition of
key strength is, but we will not give a full definition in the
specification.
- 2 Alternative indications
Bernard has new text on the issue site. Question: If after
Esteem Informational [Page 19]
INTERNET-DRAFT ESTEEM 9 January 2003
receiving a protected success indication within a method, do you
accept unprotected failure after the method has completed?
Bernard: The current text prevents you only from spoofing a
success. If the method has not completed, you will throw both
failure and success indications away. How all this is handled
must be described in the state machines.
Also, within a tunnel are the state machines separate or joined?
Bernard: We should think them as a single state
machine. Bernard: There are two issues here: whether the methods
are completed or not, and whether the methods have sent their
success/failure indications to the other side.
DECISION: If the method hasn't told the EAP mux layer that its
done, the failure/success indications will be thrown
away. Bernard: A method will just tell the mux when it is
done. It may not know exactly about its success, but it
indicates that it has completed successfully. If a method says
success (e.g. within PEAP) and after that an unprotected failure
comes, what then? Jari: It is enough with the current text and
protecting the success. Protecting the failure may not make
sense as there are other DoS attacks in any case, e.g., on the
methods.
Bernard: Is the primitive for completion just for my own
success, or do we indicate also the other side's success? If we
indicate the peer's success, then we could avoid spoofed
failures. Jari: However, if we are running a sequence of
methods, then it is no longer clear when a failure can be
accepted. One possible semantics is that the protected
indication applies only to what follows the protected method
immediately -- but not what happens after the method. However,
an attacker who can inject messages can always cause DoS by
sending random messages, sending only the first message of a
method etc.
DECISION: We will provide an indication from a method for both our
own completion as well as the peer's completion.
- 25: Spoofing and duplicate detection
This attack is like attacking TLS TCP, but easier since the
sequence number space is smaller in EAP.
Is there a difference in EAP methods as to how they want to
receive their messages, either letting the Mux handle the
sequencing or doing it by themselves using some kind of
integrity protection to avoid these attacks. This is analogous
Esteem Informational [Page 20]
INTERNET-DRAFT ESTEEM 9 January 2003
to the TLS over TCP vs. IKE situation.
Should we have a primitive from the method to the mux which
says 'take me back to the previous sequence number'? This is
also related to retransmission of broken packets. DECISION:
We should have a primitive for tossing out messages that
fail integrity protection.
There's also a timing issue: What if the real message arrives
during the integrity verification? DECISION: The state machine
must act in a lock-step; the EAP mux will not handle any new
messages before the method processing has indicates that the
previous message has been either processed or thrown away.
- 41: NAK of extended types
This is has proven to be complicated if you mix regular and
extended types. Bernard proposes that we only allow one kind of
types in NAK.DECISION: We will allow NAK of 1 or more regular
types OR a NAK of one vendor.
2.7. December 18, 2002 Minutes
EAP Design Team Notes 12/18/02 Scribe: Paul Congdon
802.1aa discussion
[1] In Paul's ballot comments for 802.1aa/D4.1 he brought up some
issues between the interface of 802.1X and the EAP layer. There
have been many new checks put into the EAP layer and subsequent EAP
Methods that may cause silent discards or state changes the 802.1X
layer may need to know about. The current 802.1aa draft always
assumes it sends a response to every request, so this doesn't
support silent discards. The two machines need to be looked at
side-by-side to assure a proper interface exists for the expected
behavior.
[2] It was agreed to prepare a reconciliation between the two layers
and present at the 802.1aa interim meeting in Vancouver (1/6 -
1/10). Paul to send mail to Tony to request a specific time for
the AA meeting. John and Bernard to suggest times when they could
possibly attend the 802.1aa meeting to schedule this particular
aspect.
[3] Discussing the interface between media layers and EAP layers. It
should be simple handshakes and should avoid putting media into
particular modes or states if possible. Something that simply
acknowledges the receipt of EAP frames from the media layer.
Esteem Informational [Page 21]
INTERNET-DRAFT ESTEEM 9 January 2003
EAP state machine discussions
[1] We need to consider EAP DoS attacks that can come from the wired
side as well now that pre-auth is part of 802.11i. With Pre-
authentication, an attacker can authenticate to an AP, and then
attack another AP within the same ESS. This means that EAP attacks
do not have to be local, as would a DoS attack on an 802.11 cipher
such as TKIP.
[2] In the proposed state machine if any method in a sequence fails,
the authentication fails.
[3] There is a question about what happens on the peer when it
perceives the authentication to have failed. For example, say the
authenticator failed to authenticate to the peer, or it send a
protected failure indication to the peer. Does the peer have to
wait until receipt of an EAP-Failure? Or can it transition to
another state immediately? What if the Authenticator thinks that
the method is still ongoing and keeps retransmitting? How does the
Peer terminate the conversation? There is a need for the peer to
be able to signal termination of the authentication. A way to know
that the peer has "hung up", so to speak. This is media specific,
since not all media may have this ability. For example, with PPP,
an LCP-Terminate can be sent; in IEEE 802.11, you can send a
Dissociate or De-authenticate. But what do you do on an Ethernet?
Lower carrier?
[4] Some methods may support protected success/failure indications. In
such a method, the authenticator will tell the peer that
authentication has failed, and perhaps the Peer can respond,
ACK'ing that assessment. In this case, assuming the exchange is
completed, then both sides are in synch as to the outcome.
[5] Retransmissions need to be checked by the EAP layer and tossed if
necessary. How will you know the frame is truly a retransmission?
John: All the bits must be checked to know this and the EAP layer
isn't currently doing that. You can't just check the identifier.
Bernard: Do you really want to require a comparison between a
received frame and previously received frames for that identifier?
Wouldn't this be creating a significant amount of work that would
make a DoS attack easier? Remember, the underlying media is assumed
to have a CRC check -- both PPP and IEEE 802 have this. If the CRC
check fails, then the EAP packet isn't even processed by the EAP
layer, it is discarded.
[6] One possible approach here is for the EAP layer to queue packets
for the method and then pass queued Requests up to the method, one
Esteem Informational [Page 22]
INTERNET-DRAFT ESTEEM 9 January 2003
at a time. If the EAP method replies with a Response, the EAP layer
should empty the queue since there should not be any additional
packets in flight. If the Authenticator retransmit timer is off, it
may have retransmitted earlier before receiving a Response, but
that is not of concern to the Peer - clearing those packets from
the queue has no ill effects. The Peer sends its Response; if a
retransmission comes in after that, it can respond again; if not,
it can handle the next Request. Clearing the queue is a DoS attack
optimization.
[7] If the EAP method didn't like the request it got (presumably
because it failed an integrity check) it would tell the EAP layer
"packet not accepted" and then the EAP layer will hand the next
packet in the queue to the EAP method. Alternatively, the method
could abort because it doesn't know how to handle integrity check
failures (EAP TLS).
[9] This implies that the EAP layer only does some basic checks: given
the state of the method, is the Peer accepting packets other than
Requests? Is the Type field acceptable? Is the length of the packet
appropriate? There is no duplicate checking per se - the EAP layer
just maintains a queue that is cleared after a Response is sent.
This seems consistent with the behavior desired by Token Card
methods. It could take a while for a person to enter in a Response
- and if there is a retransmission during that time, you don't want
to prompt the user again. You let them type in their Response, send
it, clear the queue and then see if a retransmission occurs after
that.
[10] Some methods may not be able to survive an integrity check failure.
For example, Yoshi pointed out that TLS cannot survive a MAC
failure, so that presumably EAP TLS cannot survive this either.
Bernard agreed to check on this.
[11] Notification is handled differently than other methods. A
Notification Request can be sent at any time, a Response is sent
automatically by the EAP layer, and there is no state change
resulting from this (other than perhaps Identifier state). John V
was under the impression that Notification Request cannot occur in
the middle of the method, but this was agreed upon in a previous
Design Team meeting. In the ESTEEM draft we found the previous
discussion that indicates the Notification Requests can be sent at
any time and can't be NAK'd. We will stick to this decision, and
John agreed to update the state machine document to reflect this.
On the peer side it is fairly easy to just respond to the Notify,
but on the authenticator, you must process the Notification Request
like any other packet, wait for a response and retransmit as
necessary, etc.
Esteem Informational [Page 23]
INTERNET-DRAFT ESTEEM 9 January 2003
[12] John would like to re-visit this issue before making the changes.
Could we meet on the 27th in the early afternoon or the 30th (the
following Monday). Paul will get a phone line for the 30th to
close this issue unless Bernard can secure the Microsoft line.
3. Position papers
3.1. Issues with the EAP State Machine Paper
By Yoshihiro Ohba (yohba@tari.toshiba.com)
Date: September 23, 2002
-------------------------------------------------
Issue 1: Need for detailed notational conventions
for state diagrams.
-------------------------------------------------
I think more work on the notational conventions of the current EAP
State Machine is needed. For example, there is an ambiguity about the
timing when the action defined in each state is executed. There are
two possibilities:
a) The action defined in a state is executed immediately after
the state machine enters the state.
b) The action defined in a state is executed immediately before
the state machine leaves the state (and after testing
branching conditions.)
It seems that the EAP state machine document assumes case a), but
it is not clear.
In addition, although a state machine has a sub-state machine, it is
not clear whether a sub-state machine's behavior depends on the
entrance point from which the sub-state machine is entered when there
are multiple entrance points.
Discussion:
Is it better to use the same conventions defined in section 8.5 "EAPOL
state machines" of IEEE 802.1X specification (EAPOL state machines
always uses case a), in which changes in boolean state variables are
used as state transition events? Or is it better to use and improve the
current conventions?
----------------------------------
Issue 2: Optional Identity support
Esteem Informational [Page 24]
INTERNET-DRAFT ESTEEM 9 January 2003
----------------------------------
The current EAP Authenticator State Machine is not sufficient
to support optional Identity exchange.
Suggestion:
a. Define a variable "needID" which is initialized within initPolicy().
b. Add a text tag "isSet(needID) to the arrow connecting
"Unauthenticated" state and "Peer Identification" state.
c. Add a text tag "! isSet(needID)" to the arrow connecting
"Unauthenticated" state and "EAP Method Authenticator State Machine"
state.
-----------------------------
Issue 3: NAK message handling
-----------------------------
In the current EAP Authenticator State Machine, a state transition
from "Unauthenticated" state to "EAP Method Authenticator State Machine"
occurs when the Authenticator receives a NAK message.
Since both NAK and Identity messages are Native EAP type, it is better
to have a distinct state for handling NAK reception events like the
one used for handling Identity message.
Suggestion:
a. Remove the transition arrow connected between "Unauthenticated"
state and "EAP Method Authenticator State Machine". Also remove
the text tag "Rec(NAK)" associated with the arrow.
b. Add a new state "NAKReceived" and connect it to other
states as follows (only the related states and transitions
are shown for simplicity):
------------------- Rec(NAK) -------------------
| Unauthenticated |----------------->| NAKReceived |
|===================| |===================|
|authMethodSucc = 0 |<-----------------| updatePolicy() |
|authMethodFail = 0 |policySatisfied() | idCount = 0 |
------------------- -------------------
!policySatisfied() |
|
V
-------------------
Esteem Informational [Page 25]
INTERNET-DRAFT ESTEEM 9 January 2003
| Failure |
|===================|
| Send(Failure) |
-------------------
Figure 1. A Part of EAP Authenticator State Machine
-----------------------------------------------------
Issue 4: Support for multiple authentication methods
in a single session
-----------------------------------------------------
In order to support multiple authentication methods in a single
session, it would be better to define policy parameters to support the
functionality. Also, it would be better to define a primitive set of
policy parameters which is common to all EAP methods. The policy
parameters handling for multiple authentication methods can be included
in the primitive policy set. Additional policy parameters can be
defined in addition to the primitive policy set. All policy
parameters including the primitive policy set are initialized when
initPolicy() is called and dynamically modified when updatePolicy() is
called.
Suggestion:
Define the following parameters for the primitive policy set:
EAPMultiAuthPolicy
A list of AuthPolicyElement's, where each AuthPolicyElement
consists of the following entries:
- EAPMethodType
Contains an EAP Method Type used for the current round of
authentication.
- SuccessPolicy
Contains a pointer to an AuthPolicyElement to be used for the next
round of authentication when the current authentication round
succeeds. If the value is null, the entire rounds of EAP
authentication end with Success message.
- FailurePolicy:
Contains a pointer to an AuthPolicyElement to be used for the next
round of authentication when the current authentication round
fails. If the is null, the entire rounds of EAP authentication
Esteem Informational [Page 26]
INTERNET-DRAFT ESTEEM 9 January 2003
end with Failure message.
CurrentAuthPolicy:
Contains a pointer to the AuthPolicyElement used for the current
authentication round. The pointer is updated to the value contained
in either SuccessPolicy or FailurePolicy of the current
authentication round, depending on the result of the current
authentication round. An optimization is possible when a NAK is
received with non-null Type-Data. In that case, the
CurrentAuthPolicy is updated by traversing the FailurePolicy side of
each AuthPolicyElement until the pointer points to an
AuthPolicyElement that has an EAPMethodType listed in the Type-Data
of the NAK message.
Note:
The following variables can also be included in the primitive policy
set.
idCountMax
This variable is already defined in the EAP state machine document.
needID
A flag to indicate whether Identity exchange is needed or not (see
Issue 1).
------------------------------------------------------
Issue 5: Pass-Through EAP Authenticator State Machine
------------------------------------------------------
It would be useful to define a special EAP Method Authenticator State
Machine used for pass-through mode Authenticator. By defining this,
the same state machine definition can be used for Authenticator and
authentication server, except that authentication server will not use
the "Pass-Through" Method Authenticator State Machine.
The "Pass-Through" Method Authenticator State Machine is defined as
follows:
Variables:
initialize
Esteem Informational [Page 27]
INTERNET-DRAFT ESTEEM 9 January 2003
A variable that is set to TRUE when this state machine is created.
enterMethod
A variable that is assumed to be set to TRUE by the Authenticator
State Machine when this state machine needs to be entered.
rxAuthReply
A variable that is set to TRUE when an authentication reply
message is received from the backend authentication server.
rxAuthAccept
A variable that is set to TRUE when an authentication accept
message from the backend authentication server.
rxAuthReject
A variable that is set to TRUE when an authentication reject
message is received from the backend authentication server.
rxEAPResponse
A variable that is set to TRUE when an EAP Response message on
this EAP method is received from the Peer.
error
A variable that is set to TRUE when an errornous event occurs,
e.g., failure to send/receive message, etc. (Timeout event is
excluded based on the convention described in the Introduction
section of the state machine draft.)
Procedures:
txAuthRequest
send an authentication request message to the backend
authentication server.
txEAPRequest
send an EAP Request message on this EAP method to the Peer.
States:
INITIALIZED
Esteem Informational [Page 28]
INTERNET-DRAFT ESTEEM 9 January 2003
This state is entered when this state machine is created
or the method-specific authentication ends.
AUTH_REQUEST_SENT
This state is entered when the Authenticator sent an
authentication request to the backend authentication server and
is waiting a response from the authentication server.
EAP_REQUEST_SENT
This state is entered when the Authenticator sent an
EAP Request message on this authentication method
to the Peer and is waiting an EAP Response message
from the authentication server.
SUCCESS
This state is entered when the Authenticator receives
an authentication accept message from the backend authentication
server.
FAILURE
This state is entered when the Authenticator receives
an authentication reject message from the backend authentication
server.
|
| initialize
v
---------------------
UCT | INITIALIZED | UCT
+---------------->|=====================|<------------+
| | | |
| --------------------- |
| | |
| | enterMethod |
| v |
| -------------------- rxAuthReject |
| rxAuthAccept | AUTH_REQUEST_SENT | || error |
| +----------|====================|-------+ |
| | | txAuthRequest | | |
| | -------------------- | |
| | ^ | | |
| | | |rxAuthReply | |
| v | | v |
Esteem Informational [Page 29]
INTERNET-DRAFT ESTEEM 9 January 2003
---------------------- | | ---------------------
| SUCCESS | | | | FAILURE |
|======================| | | |=====================|
| authMethodSucc = 1 | | | | authMethodFail = 1 |
---------------------- | | ---------------------
| | ^
rxEAPResponse | v |
------------------------- |
| EAP_REQUEST_SENT | |
|=========================|-------+
| txEAPRequest | error
-------------------------
Figure 2. Pass-Through Method Authenticator State Machine
Note:
This diagram uses the notation conventions follows the ones used for
the EAPOL state machines.
3.2. Comparison of EAP state machines with RFC 2284bis
Authors:
Bryan D. Payne (bdpayne@cs.umd.edu)
Nick L. Petroni, Jr. (npetroni@cs.umd.edu)
Date:
22 September 2002
References:
EAP State Machine Draft
http://www.ietf.org/internet-drafts/draft-payne-eap-sm-00.txt
RFC 2284bis
http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt
----------------------------------------
INTRODUCTION
This paper outlines inconsistencies between the EAP state machine draft and
the most recent revision of the EAP RFC. Suggestions are made for
correcting any issues that are presented. In addition to inconsistencies,
some typographic corrections and clarifications for the state machine draft
are presented at the end of this paper.
INCONSISTENCIES
Esteem Informational [Page 30]
INTERNET-DRAFT ESTEEM 9 January 2003
Below is a listing of the current known inconsistencies between the state
machine draft and the EAP RFC:
Issue #1: The authenticator state machine is too restrictive in how an ID
request may be used. Specifically, the state machines require each ID
request to be followed by an Auth request, while the EAP RFC does not
make this restriction.
Resolution #1: The authenticator state machine should be updated to
transition from the Peer Identification state to the Unauthenticated
state, instead of directly sending an Auth request.
Issue #2: The authenticator state machine does not provide any
compatibility with RFC 2869bis. Specifically, there is no transition
from the authenticator's unauthenticated state directly to the success
and failure states due to receipt of a message from the back-end server.
Resolution #2: We do not propose a resolution for this issue at this time
due to the complexity of the issues involved. However, we would like to
leave this idea open to discussion.
Issue #3: The peer and authenticator state machines do not depict the
re-authentication scenario. Instead, the state machines have a "dead
end" at the authenticated states.
Resolution #3: Create a state transition from authenticated to
initialization in both the peer and authenticator state machines.
Indicate that this transition is to be used for re-authentication.
Issue #4: The state machine draft provides incorrect information
regarding retransmission of messages (see Introduction, paragraph 4)
Resolution #4: Reword the discussion of retransmissions to indicate that
the peer will never retransmit messages. In addition, note that the
authenticator is allowed to retransmit up to a pre-specified number of
times. Finally, note that both the peer and authenticator must return
to the initialization state after "timing out" in any other state. Note
that the definition of a time out is not provided in the EAP RFC.
Therefore, this is implementation dependent, but should be a predefined
amount of time with no activity.
Note that this is independent of the situation where the authenticator
is permitted to retransmit messages after receiving invalid ID replies.
Also, note that the authenticator must never retransmit a success or
failure message, per the RFC.
CLARIFICATIONS & TYPOGRAPHICAL CORRECTIONS
Esteem Informational [Page 31]
INTERNET-DRAFT ESTEEM 9 January 2003
Below is a listing of topics that are viewed as correct in the current
state machine draft, but that require additional clarification in the
text of the draft to alleviate confusion or require a simple typographical
correction.
Clarification #1: The state machines implicitly support the concept of a
silent discard of the SUCCESS message. This is because the peer will not
transition into an authenticated state unless its policy is satisfied and
because messages that arrive at the peer, but are not handled by the
current state must be dropped (see Introduction, paragraph 2).
While this support is present, it should be made more explicit due to the
importance of the concept.
Clarification #2: In the peer state machine diagram, the lower arrow
between the Peer Identification and the Unauthenticated states is
pointing in the wrong direction.
Clarification #3: The definition of the authMethodSuccess variable in
the peer state machine should be made more clear.
PROTOCOL LIMITATIONS
In the course of reviewing the state machine work, we were reminded of a
protocol issue with EAP that should be understood by all. Unfortunately,
this is not something that can be resolved by the state machine, so we only
present it here for completeness.
The idea of doing a silent discard of success messages on the peer results
in a bit of a problem. For example, let's say that the authenticator sends
a success message, but the peer isn't ready to declare success. The
authenticator will consider itself to be done, while the peer will have
discarded the success message. Now what happens? The peer has no power
(per the protocol) to send a request message...it must instead just wait
for the authenticator to send one. So the peer has no way of indicating
that it is unhappy with the situation.
There is a variable (authMethodSuccess) in the peer state machine to
address this, but it is not an actual solution. It simply allows the peer to
re-init if it isn't happy with the result of the auth method. However,
since there is no way for the peer to tell the authenticator that it is
unhappy, this could still leave the authenticator and the peer believing
that the protocol has had different outcomes. This problem is touched on in
EAP issue 10 ([1]).
Currently, we do not see any resolution to this problem. However, people
should be aware that it exists.
Esteem Informational [Page 32]
INTERNET-DRAFT ESTEEM 9 January 2003
SUMMARY
We have made several recommendations for corrections and clarifications
to the state machine draft. We now encourage peer review of this work
and are open to comments.
REFERENCES
[1] http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2010
3.3. Completeness review
EAP State Machine Completeness
Position Paper, Oct 1, 2002
Jari Arkko, Ericsson Research NomadicLab
A. INTRODUCTION
The completeness of the state machine from draft-payne-eap-sm-00.txt
was analyzed. By completeness, we mean that the state machine contains
a description of what to do for all possible events in all states.
Note that in some cases we may well ignore an event, but this
should be done on purpose and we should document it clearly.
If not, we often tend to forget some events that should have
been handled with something else than silent discard. We
have already debated a number of issues which are specific
examples of the current under-specification that the original
RFCs as well as the state machine proposals have, such as
when can NAKs come.
B. EVENTS
The events that can come to a peer are:
- ID Request
- Method Request (many types and subtypes)
- Notification
- Success
- Failure
- Protocol error (i.e. anything else, such as a NAK
sent to the client -- this could be debatable
whether we need to deal with this. But some
protocols make a state transition e.g. close
connection upon getting these.)
The events that can come to an authenticator are:
Esteem Informational [Page 33]
INTERNET-DRAFT ESTEEM 9 January 2003
- ID response
- Methods response
- Notification ack
- NAK
- Protocol error
C. PEER STATE MACHINE
Some states in this state machine are just temporary transitions,
such as the peer identification state, where we simply respond
with an identity response and return back to unauthenticated state:
- Initialized
- Peer identification
- Invalid request
- Authenticated
The states on which some waiting of events occur are as follows:
- Unauthenticated
- Method state machine
We will study these two states in detail. We note that the Unauthenticated
state does not handle the Failure, Notification, or protocol error events.
The method state machine state does not handle Identity request, Method
request (perhaps this is thought to be on a lower level at the specific
method state machine), Notification, and protocol error events.
D. AUTHENTICATOR STATE MACHINE
Again, the states which aren't real states in the usual definition
of the term are:
- Initialization
- Failure
- Authenticated
The real states which we will study are:
- Unauthenticated
- Peer identification
- Method state machine
The Unauthenticated state does not handle Notification Response,
NAK, and protocol error events (we suspect the right action
in these cases would be silent discard).
Esteem Informational [Page 34]
INTERNET-DRAFT ESTEEM 9 January 2003
The Peer identification state does not handle
Method response, NAK, Notification, or protocol error
events. Note that we have already discussed the situation
where NAK might be used to signal that we don't want to
give an identity.
The Method state machine state does not handle Notification response,
Identity response, or protocol error events. It also doesn't
really handle Method response event, but again we suspect this
was expected to be done at the lower layer, in the specific
method state machine.
E. FURTHER WORK
It is necessary to ensure that the state machines are complete and
we have knowingly decided to ignore the events that currently are
ignored. We have already begun to debate some of the individual
issues around this, such as when can NAKs come.
In the above analysis, we have not yet taken a final stand
on whether the right action in some of these cases is something
else than silent discard. If the right action is silent discard,
then everything is currently OK.
It is also necessary to take a similar look at the 802.1aa D3
state machines.
3.4. When can packets be sent?
Bernard Aboba
Date: 10/2/02
When can a NAK be sent?
The authenticator proposes a method. The peer can accept the proposal (by
replying with an EAP method of the same type), or NAK the proposal. Once
the proposal is accepted, a NAK cannot be sent by the peer until a new
method has been proposed. NAKs are never sent by the authenticator, nor
are they sent by the peer in response to a method whose proposal has
already been accepted.
When can a Notification be sent?
EAP Notification is *not* an error message, and so sending or receiving
Notification Request/Responses does not change the state of the peer or
authenticator. The peer MUST send a Notification Response to a
Notification Request sent by the authenticator.
Esteem Informational [Page 35]
INTERNET-DRAFT ESTEEM 9 January 2003
An EAP Notification Request may be sent at the behest of an EAP method
running on the Authenticator, as part of the method. This implies that a
Notification Request may only be sent after a method has been proposed
by the authenticator and accepted by the peer.
Use of EAP Notification messages MUST be described as part of the method
specification. Since the EAP Response does not contain any data, and no state changes
result from receipt of a Notification message, it should not be assumed that the
Notification Request message is processed by the EAP method on the peer; the
Notification Response is sent automatically.
When can an Identity Request be sent and accepted?
The rules for sending an Identity Request are the same as with any other
method. An Identity Request may be sent multiple times within a single EAP
conversation, as is the case for any other method.
When are Success or Failure message sent?
EAP Success or Failure messages are sent by the authenticator EAP
layer. When it completes, an EAP method indicates the result of the
authentication to the EAP layer, by setting the Result=Success or Failure.
If the method is the last in a sequence of methods, then the authenticator
EAP layer will send the corresponding EAP Success or Failure message to the
peer. If the method is not the final in the sequence, then the
authenticator EAP layer will propose another EAP method to the peer.
Note that in order for a method to be usable within a sequence of methods,
the final message sent within the method (prior to transmission of an EAP
Failure or Success) MUST be an EAP Response. Otherwise, since EAP is an
ACK/NAK protocol, there would be no way for the authenticator to send an
EAP Request proposing another method.
When can a Success or Failure message be accepted?
EAP methods may include their own (protected) success and failure
indications. Since EAP does not provide support for error messages, several methods
have implemented method-specific error message capabilities. For example,
TLS-based methods utilize TLS alerts, which are protected within the TLS channel,
in order to transmit error messages.
Similarly, methods also implement method-specific success indications. For
example, a method supporting mutual authentication will expect the
authenticator to complete authentication prior to completion of the method.
As a result, a method specification may indicate that the method only
expects to receive clear text EAP Failure and Success messages under
certain conditions. For example, a clear text Success message is only expected
Esteem Informational [Page 36]
INTERNET-DRAFT ESTEEM 9 January 2003
once mutual authentication has been completed, or a clear text Failure
message is only expected after receipt of a protected failure
indication such as a TLS alert.
These directives can be indicated via a filter interface between the
method and the EAP layer. An EAP method can install a filter in the EAP
layer, requesting it to discard EAP packets not meeting the filter
criteria prior to completion of the EAP method. The operation of the filter
MUST be described in detail within the EAP method specification, to enable
interoperability. Filters installed by methods are automatically removed
once the method completes.
For example, an EAP method can negotiate a key early on, and after that,
may want to require that all EAP packets be protected using the derived
key until a protected success/failure indication is received. To achieve
this, the method on the peer may install the following filter within the
EAP layer:
(1) ACCEPT: Code = Request, Type=MyMethod
(2) DENY: all
This will cause the peer EAP layer to silently discard messages of types
Identity, Notification, Success and Failure until the filter is removed or
the method completes. Once a protected Success indication is received
(e.g. the authenticator completes mutual authentication), the filter list
can be changed to:
(1) ACCEPT: Code = Request, Type=MyMethod
(2) ACCEPT: Code = Success
(3) DENY: all
Similarly, once a protected failure message is received, a filter can be
plumbed enabling the reception of an EAP Failure:
(1) ACCEPT: Code = Request, Type=MyMethod
(2) ACCEPT: Code = Failure
(3) DENY: all
3.5. EAP method layer primitives
Communication between the Method and EAP layer
Bernard Aboba
October 15, 2002
One of the major issues that has arisen in the EAP Design Team discussion
is the communication that occurs between EAP methods and the EAP layer,
and what this enables.
Esteem Informational [Page 37]
INTERNET-DRAFT ESTEEM 9 January 2003
Find below a strawman diagram of the EAP stack:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | |
| EAP method| EAP method| Native | | EAP method| EAP method| Native |
| Type = X | Type = Y | Methods | | Type = X | Type = Y | Methods |
| | | (MD5) | | | | (MD5) |
| ! | | | | ^ | | |
| ! | | | | ! | | |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! | | ! |
| ! EAP | | ! EAP |
| (NAK, ! Success,Failure,Notif.,Id) | | (NAK, ! Success,Failure,Notif.,Id) |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ! | | ! |
| ! Link Layer | | ! Link Layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
! !
+----------------------->----------------+
As discussed in earlier conversations, methods require the following primitives:
a. EAP-Method.GET_IDENTITY (Peer and Authenticator)
Obtains access to the EAP Identity Response(s) that were sent prior to
method invocation, if one is available. This is important so that the method
can know the identity in cases where it does not itself have a method-specific
identity exchange.
b. EAP-Method.SEND_IDENTITY (Authenticator)
This primitive requests that the EAP layer send an Identity Request to the
peer. This is important so that the Authenticator can obtain the Identity if
it has not already been requested.
c. EAP-Method.COMPLETE (Authenticator and Peer)
This primitive indicates to the EAP layer that the method considers itself to have
completed EAP authentication, and if so, the result. This is important so that the
EAP layer can know whether it is appropriate to accept or discard illegal messages.
This includes Identity, NAK, Success or Failure messages sent in the middle of an
EAP conversation, or messages of another EAP Type. The EAP-Method.COMPLETE primitive
also results in the removal of filters installed by the EAP method, if any.
Esteem Informational [Page 38]
INTERNET-DRAFT ESTEEM 9 January 2003
d. EAP-Method.REQUEST_KEYS (Authenticator and Peer)
This primitive requests that the EAP layer provide the method with the keys
derived by previous methods in the EAP conversation. This is important to enable
cryptographic binding between methods in a sequence of methods or within a tunnel.
This enables the endpoints to know that the entity in
method #N is the same one that they were talking to in method #i where i=1,N-1. For
example, if method #1 derives a key, then method #2 should demonstrate mutual knowledge
of this key, in addition to deriving its own key, which subsequent methods can utilize
to prove their binding. Without this binding, EAP tunneling or sequences of EAP methods is
subject to man-in-the-middle attack.
e. EAP-Method.PROVIDE_KEYS (Authenticator, Peer)
This primitive provides keying material from the EAP method to the EAP layer.
This is needed in order to allow the AAA server to communicate keying material to
the NAS device.
f. EAP-Method.INSTALL_FILTER (Authenticator, Peer)
This primitive requests that the EAP layer install a filter.
This allows the EAP layer to reject additional packets in addition to the built-in
filters. For example, the method could choose to reject notification messages
while it is running, even though these don't change the state.
g. EAP-Method.REMOVE_FILTER (Authenticator, Peer)
This primitive requests that the EAP layer remove a filter. This allows the filter
to be removed prior to completion of the EAP method. EAP filters are always removed
on completion.
h. EAP-Method.SEND_PACKET (Authenticator, Peer)
This primitive requests that the EAP layer send an EAP packet.
i. EAP-Method.RECEIVE_PACKET (Authenticator, Peer)
This primitive requests that the EAP method receive an EAP packet from the EAP layer.
j. EAP-Method.SEND_NOTIFICATION (Authenticator)
This primitive requests that the EAP layer send a Notification request.
3.6. EAP State Machine Position paper
The following is my proposal for changes to the state machine to support
enhanced protection against DOS attacks.
Esteem Informational [Page 39]
INTERNET-DRAFT ESTEEM 9 January 2003
State Machine changes
This note describes changes to the Peer state machine. The major intent
is to protect it from a attacks that send EAP messages with the intent
of creating an sequencing error. If this approach seems reasonable I
can make corresponding changes to the authenticator state machine.
As a simplification of my earlier state machine I have also changed the
state machine to assume that a method failure terminates the EAP
exchange. Methods may sequence, and selection of the sequence may be
negotiated with NAKs of requests, but once a method is negotiated it
must succeed or the sequence fails and stops. Note: This puts a burden
on EAP method implementers: a failure noted by the peer must be
communicated to the authenticator, and the authenticator method must
also signal failure.
The state machine assumes that the peer EAP Switch gets inputs from the
remote Authenticator EAP Switch in the form of EAP
Requests/Success/Failure messages. It gets inputs from EAP methods via
an API which allows the method to pass EAP response and a signal about
the state of the method.
As of the conversation at the last 12/11/2002 EAP Design Team call, my
understanding is that it is worthwhile to expect additional information
from the method. The method will provide the following signals
(including 2 new signals as noted) to the the EAP Switch when finished
processing a Request.
1. Continuing - Method expects additional requests in order to
successfully complete
2. Integrity-Check-Failure - Method did not recognize the Request. Treat
as a NoOp [new]
2. Done - Method is done. It does not expect more Requests for this
method
2.1 Method accepts authenticator
2.2 Method fails authenticator
2.3 Method accepts authenticator and authenticator accepts peer [new]
The reason for adding 2.3 is to encourage writing methods where each end
knows that it is accepted by the other without having to send an EAP
Success. The method can do this in a protected way, and if it does the
information can be used to protect against DOS attacks. In the
following state machine if a method signals the mutual acceptance (2.3)
then it will not accept an EAP fail, and on timeout it assumes that the
EAP success was lost in transit and acts accordingly.
Esteem Informational [Page 40]
INTERNET-DRAFT ESTEEM 9 January 2003
Each of the signals noted above can be supported by a different state
and each of the states has a set of "expected" messages and silently
discards unexpected messages. This means that an unexpected request
would be discarded rather than NAK'd. This is safer from DOS point of
view, but perhaps less desirable if one wants a "positive indication of
failure" in operation.
Retransmissions
In addition to the new signals we discussed dealing with retransmissions
in the presence of attacks that insert random EAP requests. Note that
the Peer does not retransmit, it has to sort out retransmitted requests
from original or bogus requests. It's timer signal means it has waited
for as long as it thinks reasonable for the authenticator to retry.
In what follows I assume that the EAP Switch will catch the "obvious"
retransmissions. That is it will track the current method/seq and not
present it twice. Since EAP is a REQ/REPL protocol it needs to be track
that the req it just received is not a duplicate of one just processed.
I assume this is done by the EAP Switch prior to passing it to the state
machine.
Messages which seem valid to the EAP Switch may not seem valid to the
method itself. The method is the authority and should do integrity
checks on incoming messages. If a message fails an integrity check then
the method signals this failure to the Switch and the Switch treats this
as a no-op. This is actually a problem because no-op means that the
Switch must keep not only its current state but its previous state.
Getting an integrity check message causes it to go back to the previous
state.
Paul Congdon has suggested an alternative to the method proposed here.
As I understand it, his suggestion is to leave all the handling of
retransmissions to the method. This is an interesting approach and
worth considering. The problem I see with it is that the method can be
done and still have to deal with follow on messages. However, since the
method must make this check anyway, it does not seem unreasonable to
have it also deal with the how retransmissions. I have not worked out
how this would work in this state machine, but it does not seem an
insuperable problem - it is worth more discussion to work out which way
is better.
To tie this all together, the following is a revised description of the
Peer EAP Switch State Machine, section 5 in the draft/internet-draft
emailed to the group before the last IETF meeting.
Peer EAP State Machine
Esteem Informational [Page 41]
INTERNET-DRAFT ESTEEM 9 January 2003
Peer EAP States
The peer EAP switch has the following states:
1.inactive/not authenticated - waiting for an EAP request
2.active/waiting-method1 - waiting for 1st method response
3.active/waiting-methodc - waiting for ongoing method resp
4.active/method=x - waiting for next EAP request
5.active/method-ok - waiting for method/Success/Fail
6.active/method-succeeds - waiting for method/Success
7.active/failed method - waiting for EAP Fail
8.inactive/authenticated - authenticated; reauth possible
The typical sequence for a successful authentication is as follows. The
Peer receives an EAP request from the Authenticator, going to state 2
and forwarding the request to the appropriate method. It receives a
response from the method, going to state 4 and sending the EAP response
to the Authenticator. It receives the next EAP Req from the
Authenticator and goes to state 3, forwarding the Req to the method. It
receives a "final" response from the method and goes to state 5 (or 6)
and sends the Response to the authenticator. It then receives an EAP
Success from the authenticator and goes to state 8, authenticated.
Peer EAP Events
Events recognized by the peer EAP switch are listed below. Some Switch
policy is implied in the events; e.g. EAP-Req/ok implies that the policy
evaluated the Req as ok at this point.
>From Authenticator
1. EAP-req/meth=x - EAP req for method x
2. EAP-req/notok - req for method not allowed by policy
3. EAP Success
4. EAP- Fail
>From Method
5. Method-resp.done.ok - peer accepts authenticator
6. Method-resp.done.scs - peer and authenticator mutually ok
7. Method-resp.done.fai - failure termination from method
8. Method-resp-cont - continuing response from method
9. Method-resp-IC - Integrity Check failed
Other
10. Timeout
Peer EAP Actions
Esteem Informational [Page 42]
INTERNET-DRAFT ESTEEM 9 January 2003
Actions initiated by the peer EAP layer are:
To Authenticator
1. Send EAP-NAK
2. Send EAP-Resp
To Method
3. Forward EAP-req to method
4. Send method terminate to method
To System
5. Signal accept or reject to system
Other
6. Silent Discard
EAP Peer State Table
State Event Next State Action Action2
inactv/unauth EAP-rq/meth=x actv/wtng-mth1 EAP-rq to mth
EAP-rq/notok not-actv/auth snd NAK
EAP-Scess/ok inactv/auth Signal - acpt
EAP-Scess/notok not-actv/auth Signal-rej
actv/wtng-mth1 mth-rsp.done.ok actv/no mth snd EAP rsp
mth-rsp.done.fail actv/failed-mth snd EAP rsp
mth-rsp.done.sccs actv/sccs-mth snd EAP rsp
mth-rsp-cont actv/mth=x snd EAP rsp
mth-rsp-IC prev-state
tmout not-actv/auth term to mth=x
* actv/wtng-mth silent discard
actv/wtng-mthc mth-rsp.done.ok actv/no mth snd EAP rsp
mth-rsp.done.fail actv/failed-mth snd EAP rsp
mth-rsp.done.sccs actv/sccs-mth snd EAP rsp
mth-rsp-cont actv/mth=x snd EAP rsp
mth-rsp-IC prev-state
tmout not-actv/auth term to mth=x
* actv/wtng-mth silent discard
actv/mth=x EAP-rq/mth=x actv/wtng-mth EAP-rq to mth
EAP-rq/not mth=x actv/mth=x Silent Discard
EAP-Scess actv/mth=x Silent Discard
Esteem Informational [Page 43]
INTERNET-DRAFT ESTEEM 9 January 2003
EAP-Fail actv/mth=x Silent Discard
tmout inactv/unauth Signal-rej term-mth
* actv/mth=x silent discard
actv/mth-ok EAP-rq/meth=x actv/mth-ok Silent Discard
EAP-rq/notok actv/mth-ok Silent Discard
EAP-Scess inactv/auth Signal - acpt
EAP-Fail inactv/unauth Signal-rej
tmout inactv/unauth Signal-rej
* actv/no mth Silent Discard
actv/sccs-mth EAP-rq/meth=y actv/wtg-mth1 EAP-rq to mth
EAP-rq/notok actv/mth-ok snd NAK
EAP-Scess inactv/auth Signal - acpt
EAP-Fail inactv/unauth Silent Discard
tmout inactv/auth Signal-acpt
* actv/no mth Silent Discard
actv/fail-mth EAP-rq/mth=x actv/failed-mth snd NAK
EAP-rq/notok actv/failed-mth snd NAK
EAP-Fail not-actv/auth Signal-rej
EAP-Scess actv/fail-mth Silent discard
tmout inactv/auth Signal-rej
* actv/failed-mth silent discard
inactv/auth EAP-rq/ok actv/mth=x EAP-rq to mth
EAP-rq/notok inactv/auth snd NAK
* inactv/auth silent discard
4. Surveys
4.1. NAK Survey
Date: Sun, 6 Oct 2002 02:37:28 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: eap@frascone.com
Subject: NAK survey
During the last EAP design team meeting, there were also questions about
the NAK Type (see issues #35 and 36).
Please answer the following questions relating to the operation of your
implementation:
a. May the NAK be sent by the peer in response to any EAP request? For
example, may it be sent in the middle of an EAP method? OR
Esteem Informational [Page 44]
INTERNET-DRAFT ESTEEM 9 January 2003
b. May the NAK be sent by the peer only in response to a method proposal
(e.g. the first EAP Request for a given Type)?
c. Does your implementation tolerate sending more than one Type within a
NAK (e.g. may not recognize additional Types, but doesn't blow up)?
d. Does your implementation permit a NAK to be sent in response to an
Identity Request? If so, what does it do if a NAK is sent?
Date: Mon, 7 Oct 2002 07:13:34 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: eap@frascone.com
Subject: Re: [eap] NAK survey
Bernard Aboba writes:
> During the last EAP design team meeting, there were also questions about
> the NAK Type (see issues #35 and 36).
>
> Please answer the following questions relating to the operation of your
> implementation:
ftp://playground.sun.com/pub/eap/index.html
> a. May the NAK be sent by the peer in response to any EAP request? For
> example, may it be sent in the middle of an EAP method? OR
Yes, it can be sent at any time.
> b. May the NAK be sent by the peer only in response to a method proposal
> (e.g. the first EAP Request for a given Type)?
No, at any time. I don't see how it could be otherwise -- for a
multi-stage method, it's entirely possible to get part way down an
authentication attempt only to discover that some required feature is
missing in the peer and that some other mechanism is necessary.
> c. Does your implementation tolerate sending more than one Type within a
> NAK (e.g. may not recognize additional Types, but doesn't blow up)?
It ignores any additional Types included in a NAK and uses only the
first one. (If *no* suggested Type is included with the message, then
it logs this fact, and treats it as a failure of the current message.)
No, it doesn't "blow up," even though including multiple Types (or any
other data) would be a violation of RFC 2284. ;-}
> d. Does your implementation permit a NAK to be sent in response to an
Esteem Informational [Page 45]
INTERNET-DRAFT ESTEEM 9 January 2003
> Identity Request? If so, what does it do if a NAK is sent?
If the identity of the peer was supplied by explicit configuration,
then it accepts the NAK and continues with authentication using the
suggested Type (if permitted).
If the identity was not supplied by explicit configuration, then it
treats this case as authentication failure, sends EAP Failure, and
shuts down the link.
There's one other case that your survey didn't cover (perhaps it's not
a bone of contention?): what do you do when you get a NAK Type that
isn't one that you want to deal with (either by administrative
configuration or because you don't recognize it)? I examine my
current state and ask for the "next" possible method on the list,
returning to Identify if I fall off the end.
--
James Carlson, Solaris Networking <james.d.carlson@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Date: Mon, 7 Oct 2002 10:22:28 -0700
From: Sachin Sheth <sachins@windows.microsoft.com>
To: aboba@internaut.com
Subject: RE: NAK survey (fwd)
a. May the NAK be sent by the peer in response to any EAP request? For
example, may it be sent in the middle of an EAP method? OR
EAP will send out only in the first packet after the EAP-Resp/Id. It
will not be sent out at any other time.
b. May the NAK be sent by the peer only in response to a method proposal
(e.g. the first EAP Request for a given Type)?
Yes
c. Does your implementation tolerate sending more than one Type within a
NAK (e.g. may not recognize additional Types, but doesn't blow up)?
There is no way to program this. EAP will only send out one EAP-type
in the NAK packet.
d. Does your implementation permit a NAK to be sent in response to an
Identity Request? If so, what does it do if a NAK is sent?
Esteem Informational [Page 46]
INTERNET-DRAFT ESTEEM 9 January 2003
The NAK is sent out only after the EAP-Req/Identity is sent out.
Date: Mon, 7 Oct 2002 14:12:42 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: eap@frascone.com
Subject: Re: [eap] RE: NAK survey
Bernard Aboba writes:
> For what it's worth, here's what Microsoft Windows XP does:
>
> a. May the NAK be sent by the peer in response to any EAP request? For
> example, may it be sent in the middle of an EAP method? OR
>
> Windows XP peer will send a NAK only for the first packet after the
> EAP-Response/Identity is sent. It does not NAK an EAP-Request/Identity.
Interesting question here: was the question above about what you'd
*accept* or about what you'd possibly *send*?
It looks like I read the question as the former (because "sent by the
peer" implies "received by the local system" to me), and you might
have read it as the latter. If it's intended as the latter, then I'd
say this: I never send NAK in response to an Identity message, but I
*do* send NAK in response to *any* message that is malformed for the
method in use. In other words, if the method specifies a 16 octet
message for the given message subtype, and you send me fewer than 16
octets, then I assume that you're running some new or different
version of the protocol, and I send NAK to suggest a different
authentication protocol since we're not going to converge.
--
James Carlson, Solaris Networking <james.d.carlson@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
4.2. Notification Survey
Based on the survey results (see below), we propose the
following conclusions. Comments welcome.
a. EAP Notification Requests may be sent at any time by the authenticator.
For example, they may arrive in the middle of a method exchange. An
EAP Notification Request cannot be NAK'd.
b. An EAP Notification Response MUST be sent by the peer in response to
an EAP Notification Request. The Response is sent automatically by
the peer and confirms receipt, but does not indicate whether the user
took any action in response to the message, or even whether the message
Esteem Informational [Page 47]
INTERNET-DRAFT ESTEEM 9 January 2003
was displayed to the user at all (e.g. it may be consumed by an
embedded device).
c. EAP Notification Requests SHOULD be displayed or logged by the peer.
It cannot be assumed that Notification Requests are available for
processing by the running method.
d. EAP Notification Requests or Responses do not result in a state
change.
e. EAP Notification is *not* an error indication.
Below find the original survey and posted responses.
Date: Wed, 2 Oct 2002 12:22:42 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: eap@frascone.com
Subject: [eap] Notification survey
In the EAP Design team meeting today, we discussed the use of EAP
Notification. The question arose as to what people are using this for
today, and why. If you have implemented EAP Notification in your method
(or your EAP implementation), can you let us know:
a. Whether you are using Notification as part of the method (e.g.
Notification Request is delivered to the method)
b. Whether you allow Notification to be sent at any time (in the middle of
a method exchange)
c. Whether Notification results in a state change within the EAP state
machine or not
d. Whether you would be affected if EAP Notification were to be eliminated
or deprecated, and why this would be bad (or good)
--__--__--
Date: Wed, 02 Oct 2002 23:02:10 +0200
To: Bernard Aboba <aboba@internaut.com>
From: Jacques Caron <Jacques.Caron@IPsector.com>
Subject: Re: [eap] Notification survey
Cc: eap@frascone.com
Hi,
I don't use it (yet), but:
a. I definitely believe a method on the client side shouldn't expect any
such messages (there should be a generic method handler for it that will
Esteem Informational [Page 48]
INTERNET-DRAFT ESTEEM 9 January 2003
just display the message to the user - a bit like there should be a generic
identity method handler that just returns the identity).
b. It should be possible to possible to send this nearly at any time:
- there should be only one outstanding request (i.e. not possible to send a
Notification request just after some other method request before the
response came back)
- at the very least it should be possible to use it between two requests
from different methods, not necessarily in the middle of the exchanges of
one given method.
c. Receiving a Notification request should prompt a Notification response,
and then return to the same state. If the message is displayed via some
kind of alert/dialog box (that requires user action), the question of
whether the response is sent immediately or once the user acknowledges the
dialog box remains open (in that last case there would be an intermediate
state, I guess).
d. I believe it's useful to be able to send clear-text messages to the
client, in the following (non-exhaustive list of) cases:
- an authentication method failed, and the method wants to give the user
more information about why
- a method (maybe not an authentication one, more an authorization one) got
a NAK back, and the method wants to tell something to the user anyway (e.g.
connection cost)
Of course the problem of the authenticity of the message is present, but
that's a more general problem of EAP messages...
An important point is that one should just not consider that the message
will actually be seen and/or interpreted by anyone, it's purely informative.
Just my 0.02 EUR.
Jacques.
--__--__--
Date: Thu, 03 Oct 2002 13:00:01 +0300
From: Preeti Vinayakray <preetida.vinayakray-jani@nokia.com>
Organization: Nokia Research Centere
To: ext Bernard Aboba <aboba@internaut.com>
CC: eap@frascone.com
Subject: Re: [eap] Notification survey
Hello:
Following ans. relevant to my EAP implementation
ext Bernard Aboba wrote:
Esteem Informational [Page 49]
INTERNET-DRAFT ESTEEM 9 January 2003
> In the EAP Design team meeting today, we discussed the use of EAP
> Notification. The question arose as to what people are using this for
> today, and why. If you have implemented EAP Notification in your method
> (or your EAP implementation), can you let us know:
>
> a. Whether you are using Notification as part of the method (e.g.
> Notification Request is delivered to the method)
>
Yes, it is used as a part of the method
>
> b. Whether you allow Notification to be sent at any time (in the middle of
> a method exchange)
>
No,
>
> c. Whether Notification results in a state change within the EAP state
> machine or not
>
No
>
> d. Whether you would be affected if EAP Notification were to be eliminated
> or deprecated, and why this would be bad (or good)
>
This very much depends on how implementation is done. In terms of my
implementation I consider it is 'good 'as a part of methods I have
supported, But it does not change any state info for client/peer. It just
provides some line display. So elimination of this not going to affect.
-Preeti
>From carlsonj@phorcys.east.sun.com Fri Oct 4 09:53:16 2002
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [eap] Notification survey
I have this implementation:
ftp://playground.sun.com/pub/eap/index.html
and I'm working on updating it and integrating it into 'pppd' (since
I'm now one of the maintainers of that software) for the next release.
Esteem Informational [Page 50]
INTERNET-DRAFT ESTEEM 9 January 2003
> a. Whether you are using Notification as part of the method (e.g.
> Notification Request is delivered to the method)
No, it's not part of the method.
> b. Whether you allow Notification to be sent at any time (in the middle of
> a method exchange)
Sure.
> c. Whether Notification results in a state change within the EAP state
> machine or not
No. Nothing in the RFC describes it being used that way ...
> d. Whether you would be affected if EAP Notification were to be eliminated
> or deprecated, and why this would be bad (or good)
I wouldn't be affected. I never send them, and I just log them if
received (and of course send ack).
I don't think it would be good to remove this message. I like having
a "I think this is interesting for you to log" message for debug and
deployment reasons. If, however, we fixed 'Success' and 'Failure' to
be able to include a debug text message (as I think they ought to have
from the start), then I'd be somewhat happier with losing
Notification. (Not perfect, but good enough.)
(I also think that the possible i18n concerns and the spamming
concerns are misplaced -- the receiver can do anything it likes with
these, including discarding the text.)
--
James Carlson, Solaris Networking <james.d.carlson@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Date: Thu, 3 Oct 2002 09:54:36 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: eap@frascone.com
Subject: [eap] RE: Notification survey
For what it's worth, here are some details on how Windows implements
Notification:
- EAP-Notification is out-of-band. The EAP layer automatically sends a
Notification Response; the Notification Request is not passed to the
currently running method.
Esteem Informational [Page 51]
INTERNET-DRAFT ESTEEM 9 January 2003
- EAP-Notification can be sent at any time. There are no checks done when
the EAP-Notification arrives.
- Since EAP-Notification is not passed to the method, it does not result
in a state change.
- EAP Notification does not have support for internationalization. The
lack of language support means that there is no easy way to display a
message to the user in a language that they can be guaranteed to
understand.
- EAP-Notification does not result in a display to the user at present.
--__--__--
5. Normative references
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode
and ISO 10646", RFC 2044, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.]
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2434] Alvestrand, H. and Narten, T., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
Esteem Informational [Page 52]
INTERNET-DRAFT ESTEEM 9 January 2003
6. Informative references
[DECEPTION] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995.
[RFC1510] Kohl, J., Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, November 1998.
[RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier",
RFC 2486, January 1999.
[RFC2401] Atkinson, R., Kent, S., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J.,
"Internet Security Association and Key Management
Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2433] Zorn, G., Cobb, S., "Microsoft PPP CHAP Extensions", RFC
2433, October 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and Palter, B., "Layer Two Tunneling Protocol L2TP",
RFC 2661, August 1999.
[RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos Password
Security", Stanford University Computer Science
Department, http://theory.stanford.edu/~tjw/krbpass.html
[KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos
authentication system", Proceedings of the 1991 Winter
USENIX Conference, pp. 253-267, 1991.
[KERB4WEAK] Dole, B., Lodin, S., and Spafford, E., "Misplaced trust:
Kerberos 4 session keys", Proceedings of the Internet
Society Network and Distributed System Security
Symposium, pp. 60-70, March 1997.
[PIC] Sheffer, Y., Krawczyk, H., Aboba, B., "PIC, A Pre-IKE
Credential Provisioning Protocol", Internet draft (work
in progress), draft-ietf-ipsra-pic-05.txt, February 2002.
Esteem Informational [Page 53]
INTERNET-DRAFT ESTEEM 9 January 2003
[PPTPv1] Schneier, B, Mudge, "Cryptanalysis of Microsoft's Point-
to- Point Tunneling Protocol", Proceedings of the 5th ACM
Conference on Communications and Computer Security, ACM
Press, November 1998.
[IEEE8023] ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 3: Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
1996), 1996.
[IEEE80211] Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, IEEE Std.
802.11-1997, 1997.
Acknowledgments
Many thanks to the volunteers of the EAP Design team.
Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
Esteem Informational [Page 54]
INTERNET-DRAFT ESTEEM 9 January 2003
languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Esteem Informational [Page 55]
INTERNET-DRAFT ESTEEM 9 January 2003
Open issues
Open issues relating to this specification are tracked on the following
web site:
http://www.drizzle.com/~aboba/EAP/eapissues.html
Expiration Date
This memo is filed as <draft-ietf-eap-esteem-01.txt>, and expires July
24, 2003.
Esteem Informational [Page 56]
| PAFTECH AB 2003-2026 | 2026-04-22 20:59:19 |