Subject: [eap] Re: Issue 80: Success Indications

From: [email-masked] (John Vollbrecht)
Date: Wed, 12 Feb 2003 16:28:38 -0500

I suggest that we restructure this to move the MIC sections to a security 
considerations appendix.  That moves paragraphs 3 and 4 and rule a to an 
appendix.

The remainder deals with the fact that success and failure messages are not 
protected and can be spoofed, and with the possibility of "alternative 
indications".

My other comments are inline

--On Wednesday, February 12, 2003 6:25 AM -0800 Bernard Aboba 
<[email-masked]> wrote:

> I'd like to propose a rewrite of Section 4.2.1 to address some of these
> concerns:
>
> "4.2.1 Processing of success and failure
>
>    Within EAP, success and failure indications consist of the EAP
>    Success and Failure messages, as well as method-specific indications.
>    Within EAP, these indications may be protected or unprotected.
>
I don't see how these can be protected within EAP.  Within an EAP method 
perhaps.  Within 802.1x perhaps.  But EAP doesn't seem to provide a way to 
protect them.   If it is only method specific indications I think these 
should be dealt with as method issues, not EAP.  Am I missing something?

>    EAP Success and Failure packets are considered unprotected
>    indications which may be spoofed, since as described in Section 4.2,
>    they contain no message integrity check (MIC).
>
I agree - and this is the issue to be clarified here - how to deal with the 
possible spoofing of unprotected Success and Failure Messages.

>    In order to provide additional protection against tampering, EAP
>    methods MAY support a MIC that covers some or all of the EAP packet,
>    including headers. In addition, such a MIC MAY include coverage of
>    previous Request and Response messages, so as to enable protection of
>    other packets to that do not contain MICs, such as Identity Request/
>    Response, Notification Request/Response and Nak Response.
>
>    EAP methods also MAY include support for method-specific acknowledged
>    success and failure indications. This enables the authenticator to
>    indicate whether the peer has successfully authenticated, as well as
>    for the peer to acknowledge receipt of that indication, and respond
>    with an indication of whether the authenticator has successfully
>    authenticated to the peer. If a key has previously been derived, the
>    result exchange MAY be protected by a Message Integrity Check (MIC),
>    and if so, then this success/failure indication is considered
>    protected.
>
These are good paragraphs which should be in an appendix.  I am not sure 
however that method specific success/failure carries through to the 
sequence as a whole.

>    In order to decrease vulnerability to spoofing of success and failure
>    indications, the following processing rules are recommended:
>
>    [a] Processing of protected success and failure indications. Where a
>        method-specific protected success/failure indication has been
>        received, the implementation MUST validate the EAP method MIC,
>        as discussed in Section 4.1.
>
good - but for appendix

>    [b] Receipt of EAP Success and Failure packets prior to method
>        completion. A peer EAP implementation receiving an EAP Success
>        packet prior to completion of the method in progress MUST
>        silently discard it. This ensures that a rogue authenticator will
>        not be able to bypass mutual authentication by sending an EAP
>        Success prior to conclusion of the EAP method conversation.  A
>        peer EAP implementation receiving an EAP Failure packet prior to
>        completion of the method in progress MAY silently discard it.
>        When using EAP methods that provide their own (protected) error
>        indications, premature EAP Failure packets are unexpected, so
>        that this technique may be more easily employed.
>

This is good.  I would prefer something with a positive statement that peer 
EAP MUST determine when it is satisfied and not just take success from the 
authenticator as an indication that it should be happy.

>    [c] Authentication requirement. An EAP peer implementation that has
>        been configured to require authentication MUST silently discard a
>        "canned" EAP Success message (an EAP Success message sent
>        immediately upon connection).
>
this seems a subset of rule b.

>    [d] Contradictory indications. Where an authenticator provides a
>        protected indication that peer authentication has failed, or
>        (where a method supporting mutual authentication is supported)
>        the authenticator fails to authenticate to the peer,
>        the peer implementation MUST silently discard subsequent
>        EAP Success packets.
>
ok
>    [e] Processing of EAP Success and Failure in the absence of protected
>        indications. Subsequent to the completion of the EAP
>        authentication method (Types 4 and greater), and in the absence
>        of protected result indications, EAP Success and Failure packets
>        MUST be accepted and processed by the EAP implementation."
>
I still don't know what a protected indication means at this level.  Is is 
something the method passes on?  Is the assumption that there are no 
sequences?

> --------------------------------------------------------------
> Issue 80: Success Indications
> Submitter name: Nick Petroni
> Submitter email address: [email-masked]
> Date first submitted: February 10, 2003
> Document: EAP-00
> Comment type: Technical
> Priority: S
> Section: 4.2.1
> Rationale/Explanation of issue:
> I am requesting some comments/clarification on the topic of when the
> success state can be reached by the peer.
>
> Executive summary:
> -----------------
> 1. Is a satisfied policy enough for a peer transition to the success
> state, or is a SUCCESS packet required?
>
> 2. Is the text in 4.2.1 contradicting the current EAP model, or do I have
> an incorrect understanding of the model? (these are not mutually
> exclusive)
>
>
> Full explanation:
> ----------------
> Through conversation with the state machine design team, I have come to
> question the conditions for success of an EAP conversation. All parties
> seem to agree that a satisfied policy is necessary for the peer to begin
> using the link, but the question is whether or not the condition is
> sufficient. That is, if a SUCCESS message never comes, can the peer
> transition to the SUCCESS state? The "alternate indications" of RFC2284
> seem to imply that it can, however, section 3.4 of 2284bis explicitly
> warns against accepting link-layer indications (and for good reason).
> Since SUCCESS messages are neither acknowledged nor retransmitted, it is
> possible that SUCCESS messages could be lost causing an unneeded timeout.
> Assuming the link never goes down and the peer is satisfied, it may be
> acceptable to just begin using the link. If so, when should this happen?
> Presumably, it would be when a timeout has occurred and the policy is
> satisfied.
>
> This problem is closely related to so-called "protected" indications
> discussed in section 4.2.1 (from resolved issue 49). Design team
> conversations have concluded that such method-specific indications cannot
> actually indicate the success/failure of the overall conversation, but
> just the method itself. Some of the text in 4.2.1 seems to contradict this
> paradigm. For example, [c] states,
>
> "Contradictory indications. Where protected and unprotected result
> indications are both available, protected indications take precedence. For
> example, where an EAP method provides a protected indication that
> authentication failure has occurred in either direction, the
> implementation MUST silently discard subsequent EAP Success packets.
> Similarly, where an EAP method provides a protected indication that
> authentication has succeeded in both directions, the EAP implementation
> MAY silently discard EAP Failure packets."
>
> I believe I understand the spirit of this text, but I am not sure it fits
> the current model- are such indications really "contradictory", or has the
> method just said things are going well and the authenticator decided
> otherwise?
>
> Note:
> I believe I could make an equally long-winded argument for saying this is
> all just implementation detail because I could implement EAP such that the
> methods DO know the end result and still fits the wire protocol.
>
> Thanks for reading all the way through. Comments welcome.
>
> nick
>
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 12 Feb 2003 12:36:36 -0800 (PST)

> should be dealt with as method issues, not EAP.  Am I missing something?

Removed "Within EAP"

> however that method specific success/failure carries through to the

I would argue that authentication cannot succeed if method authentication
fails. Otherwise, we open a vulnerability to rogue authenticators.

> good - but for appendix

Moved into text for Issue 74 (a new section).

> authenticator as an indication that it should be happy.

Any text to suggest?

> this seems a subset of rule b.

I think so. Will consolidate.

> something the method passes on?  Is the assumption that there are no

It's something the method passing on. Sequences can be supported -- but
if an authentication method fails, the sequence cannot continue.

Is this better?

Within EAP, success and failure indications consist of the EAP
Success and Failure messages, as well as method-specific indications.
EAP Success and Failure packets may be spoofed, since as described in
Section 4.2, they contain no message integrity check (MIC). They are
therefore considered unprotected.

(see Section 7.13) and if so, then these success/failure indications are
considered protected.

[a] Handling of EAP Success and Failure packets prior to method
completion. A peer EAP implementation receiving an EAP Success
packet prior to completion of the method in progress MUST
silently discard it. This ensures that a rogue authenticator will
not be able to bypass mutual authentication by sending an EAP
Success prior to conclusion of the EAP method conversation. A
peer EAP implementation receiving an EAP Failure packet prior to
completion of the method in progress MAY silently discard it.
When using EAP methods that provide their own error
indications, premature EAP Failure packets are unexpected, so
that this technique may be easily employed.

[b] Authentication requirement. Where mutual authentication
is required, and the authenticator fails to authenticate
successfully to the peer, the peer implementation
MUST NOT consider authentication to be successful
even upon receipt of an EAP Success packet.
Instead, the peer MUST terminate the authentication
conversation and refuse to enable the link.

This implies, for an example, that a peer configured to
require mutual authentication will not consider
authentication to be successful on receipt of a "canned"
EAP Success message (an EAP Success message sent
immediately upon connection).

[c] Contradictory indications. Where an authenticator provides a
protected method-specific indication that peer authentication has failed
the peer implementation MUST NOT consider authentication
to be successful even upon receipt of an EAP Success packet.
Instead, the peer MUST terminate the authentication
conversation and refuse to enable the link.

[d] Processing of EAP Success and Failure in the absence of
method-specific indications. Subsequent to the completion of the EAP
authentication method (Types 4 and greater), and in the absence
of method-specific indications, EAP Success and Failure packets
MUST be accepted and processed by the EAP implementation."

---

From: [email-masked] (James Carlson)
Date: Thu, 13 Feb 2003 10:53:14 -0500

> completion of the method in progress MAY silently discard it.

I disagree with that bit of wording because I see no particular value
in it.

I realize that what you're concerned about here is the DoS attack by
someone who can generate EAP Failure messages towards the
authenticatee, but this recommendation isn't sufficient to solve the
problem (it merely means that the DoS attacker needs to flood the
authenticatee with EAP Failure messages -- so that the timing will
work out right, and one of the messages will hit at the "end" of a
method), and it clearly is incompatible with 2284.

If DoS or other message injection is a problem in some particular
usage of EAP, then there needs to be a real solution to this, rather
than minor and distributed tweaks to EAP message handling.

In general, I think that any references in the EAP base document
itself to methods being "incomplete" in some way is incorrect.  If
some method wants to define such behavior, that's a problem for that
method document, but I don't see it as a basic feature of EAP itself.

-- 
James Carlson, Solaris Networking         <[email-masked]>
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

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 08:10:27 -0800 (PST)

> method), and it clearly is incompatible with 2284.

I'm curious why you say it is incomptible with RFC 2284. The problem of
forged Success and Failure messages was noted in the University of
Maryland state machine analysis, and as a result the behavior described is
exhibited by several implementations.

> than minor and distributed tweaks to EAP message handling.

What would a "real" solution be? EAP provides basic transport over which
"real" security protocols (IKE, Kerberos, TLS, etc.) can be run. Those
protocols have been well analyzed, but sandwiching them between unsecured
EAP messages (Nak, Identity Request/Respose, Success/Failure) or allowing
unsecured messages to intercede (allowing random Type codes to abort the
exchange) creates vulnerabilities that didn't exist in those original
protocols.

So it seems to me that if we either allow the unsecured messages to be
ommitted (optional Identity), cover them with a MIC, ignore them when
the protected exchanges contradict, and don't allow the exchange to be
aborted in the middle, we've recovered the security of the original
protocols.

> method document, but I don't see it as a basic feature of EAP itself.

Most security protocols have well defined states that describe when the
exchange has finished successfully or not. That is not an EAP concept.

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 13 Feb 2003 13:35:39 -0500

Thanks for the feedback.  there is a lot of info here.  I have some 
questions in line.

> exhibited by several implementations.

so does the analysis actually say what should be done to resolve the 
problems?   Is the analysis posted somewhere?

> aborted in the middle, we've recovered the security of the original
Would doing these things make the protocol more secure?  Is so then there 
is a stronger reason that just eliminating DOS attacks for some of the 
state machine things we have talked about.

> exchange has finished successfully or not. That is not an EAP concept.

is this "end" necessary for eap or just for methods?  what would eapv2 look 
like?

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 13 Feb 2003 13:43:26 -0500

> method), and it clearly is incompatible with 2284.
true - we need to define what DOS attacks we think are worth defending.

> method document, but I don't see it as a basic feature of EAP itself.
I disagree about needing to know about method state.  I don't think it is 
possible to make a decision about whether a sequence is valid without 
knowing which methods have completed successfully.  That would seem to mean 
you would need to know if they were incomplete as well.

---

From: [email-masked] (Nick Petroni)
Date: Thu, 13 Feb 2003 13:49:59 -0500 (EST)

> problems?   Is the analysis posted somewhere?
The paper can be found at http://www.cs.umd.edu/~waa/pubs/1x.pdf, but it
does not actually address DoS specifically (at least to the best of my
recollection). The problem described has to
do with binding problems when not using WEP, as well as the ability to
forge SUCCESS. DoS by forged FAILURE follows easily.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 10:24:53 -0800 (PST)

> problems?   Is the analysis posted somewhere?

Here's a pointer to the original paper:

http://www.cs.umd.edu/~waa/1x.pdf

> state machine things we have talked about.

Doing those things would ensure that EAP would not add security
vulnerabilities to existing security protocols.

> is this "end" necessary for eap or just for methods?  what would eapv2 look

Methods indicate when they're "done" and the result (Failure/Success). If
they're not done, then you can't receive Failure/Success/Another
Type.

Also, if there are no sequences, then presumably the result of the single
method authentication is identical to the EAP result. At that point, the
Failure/Success packet becomes completely vestigial.

Note that it is necessary for the final packet to go from Server to
Client, if only because that is the direction of the final RADIUS message.
So that final message cannot be ACK'd because there is no RADIUS
conversation possible after that point. So there's no reason to believe
that EAPv2 could do any better.

---

From: [email-masked] (James Carlson)
Date: Thu, 13 Feb 2003 14:50:40 -0500

Bernard Aboba writes:
> I'm curious why you say it is incomptible with RFC 2284.

The authentication phase ends when EAP Success or Failure is received:

   3. The authenticator ends the authentication phase with a Success or
      Failure packet.

This proposed change is now saying that the authentication phase can
continue along if (in one peer's opinion?  both?  the method's
judgement?  EAP itself?  how do we know?) the Failure is somehow
deemed as "unacceptable."

This is new in comparison to 2284, and looks to me to be hard to
implement in an interoperable manner, because it requires that
everyone always agrees on which precise timing is "valid," and
differing interpretations will cause hangs.  It's still not clear to
me precisely when one is "in the middle of" a method, and when one is
not.  If I'm in the middle of a multi-method sequence (however
unlikely), but between methods, am I vulnerable to unexpected EAP
Failure?

> The problem of

I think the problem there is at a much higher level.  If you get EAP
Success and you're not happy about the current state FOR ANY REASON,
then by all means, drop the link.  It makes no sense to open the
floodgates before *YOUR* side of the connection is satisfied with the
progress.  This isn't really a protocol issue.  It's an implementation
error that doesn't quite need to be enshrined in a specification
(except, perhaps, as offhand advice).

Moreover, I think it makes no sense to mandate things that some
implementations may be unable or unwilling to do.  If I'm a dial-up
PPP implementation, and my security model is the commonly-used one (I
prove my identity to my ISP, and he proves *nothing* to me), then I
really don't care what the EAP progress looks like.  If I get Success,
then I'm really quite happy.  My criteria have been satisfied, and I'm
not expecting anything else.

> exchange) creates vulnerabilities that didn't exist in those original

Agreed, and that's the problem.  The problem is in the transport
mechanism that EAP is using.  That transport violates the assumptions
made by EAP -- in particular, that it's a point-to-point link, and
thus has no possibility of any sort of interception or injection.

> aborted in the middle, we've recovered the security of the original

If we do that, then I think we need to push this down lower: the MIC
needs to occur at a sublayer between EAP and the next level down.  It
needs to protect EAP against the sort of corruption you're describing.
Trying to build it into EAP, when EAP was *not* designed to do this,
just leads to trouble.

> exchange has finished successfully or not. That is not an EAP concept.

Right; that's what I'm saying.  It's a problem for the method, not for
EAP.

> state machine things we have talked about.

Yes, if we had a MIC that protected all of the EAP messages, then it
would be more secure.

> you would need to know if they were incomplete as well.

The requirement flows the other direction, in my estimation.  In other
words, EAP doesn't need to care about this.  For methods that have
multiple rounds, *AND* where the security model of the method requires
for the authenticatee that all the rounds are completed (i.e., mutual
authentication), then it makes sense to say that EAP Success before
that point is really a failure indication.  Otherwise, the "in the
middle" definition is not useful, and serves only to create new
complexity and corner cases that weren't present in 2284.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Thu, 13 Feb 2003 14:57:42 -0500

> aborted in the middle, we've recovered the security of the original

If we omit the Identity, it would work only for limited environments
where the authenticator and EAP server is co-located or there is only
one EAP server.  So omitting optional Identity increases security at
the cost of limiting the coverage of the protocol usage.  Covering
multiple unprotected EAP messages with a MIC is vulnerable to a DoS
attack which can be launched easier than a DoS attack to the original
protocol.  It seems to me that we have not fully recovered.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 11:34:32 -0800 (PST)

> one EAP server.

Not really. If the default method can be terminated on a proxy, it can be
used even in roaming scenarios. For example, you could create a method
that does a DH, then exchanges identities, and potentially then does an
auth exchange.

> So omitting optional Identity increases security at

Existing EAP methods already do this. EAP TLS includes a finished message
that MICs previous messasges. So it really isn't an EAP issue at all.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Thu, 13 Feb 2003 16:13:59 -0500

> that does a DH, then exchanges identities, and potentially then does an

Is the proxy also applicable to EAP TLS?

> that MICs previous messasges. So it really isn't an EAP issue at all.

What about fragmentated PEAP messages that may be exchanged after TLS
handshake?

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 13:11:52 -0800 (PST)

> Is the proxy also applicable to EAP TLS?

Sure. In fact with EAP TLS there is no need to go back to the
authentication server at all. See:

http://www.drizzle.com/~aboba/IEEE/draft-ietf-roamops-cert-02.txt

> What about fragmentated PEAP messages that may be exchanged after TLS

You won't normally see fragmentation unless a cert-based protocol is being
run within the tunnel -- and there's no reason to run such a protocol.

---

From: [email-masked] (John Vollbrecht)
Date: Thu, 13 Feb 2003 17:33:35 -0500

Thanks for the pointer.

Sounds like the paper doesn't give a reason (pro or con) to implement the 
DOS mitigation steps, so we have to decide based on DOS/ efficiency reasons.

--On Thursday, February 13, 2003 1:49 PM -0500 Nick Petroni 
<[email-masked]> wrote:

> > > I'm curious why you say it is incomptible with RFC 2284. The problem
> > > of forged Success and Failure messages was noted in the University of
> > > Maryland state machine analysis, and as a result the behavior
> > > described is exhibited by several implementations.
> > >
> >

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 13:31:10 -0800 (PST)

>    3. The authenticator ends the authentication phase with a Success or

Sure. The authenticator ends the conversation -- this doesn't say that the
peer has to enable the link based on such an indication.

> deemed as "unacceptable."

I would agree that it is necessary to act on the Failure after the method
is complete, if only because of sequences. But if the method fails at any
point, then the peer can disconnect at will - whether or not an EAP Success is received.

> differing interpretations will cause hangs.

A method that has its own mechanisms for completing unsuccessfully will
not send an EAP Failure prior to method completion. If the client knows
that it is using such a method, then it also knows that an EAP Failure is
not an allowable packet until the state machine reaches a terminal state,
and can discard such a packet if received.

> It's still not clear to

We're only talking about "in the middle of" a single method. Sequences are
another issue, and I agree that there is a vulnerability to unexpected
EAP Failure where sequences can be used.

> progress.

Sure.

> This isn't really a protocol issue.  It's an implementation

Implementation advice is fine.

> not expecting anything else.

Sure.

> thus has no possibility of any sort of interception or injection.

But if you look at the protocol, it really wouldn't be different in many
respects if the transport were UDP. There are no keys at the start, so you
couldn't MIC the Identity or Nak. About the only thing you could do differently is to
MIC the Failure (if you have a key) or the Success. If you had to support
methods that only did one-way auth, you couldn't even guarantee that you'd
be able to do that, because you might not have a key. So it seems to me
that the "assumptions" of EAP are largely derivable from the basic
scenario of network access authentication.

> Trying to build it into EAP, when EAP was *not* designed to do this,

That's like saying that a MIC needs to be built into IP in order to be
used in protocols like IPsec. IPsec ESP or AH are built as shims on top of
IP, yet they can cover portions of the IP header directly (AH) or
indirectly (ESP through the TCP/UDP pseudo-header). Similarly, you could
build an EAP method with a per-packet MIC in each packet without having to
change EAP at all.

> Right; that's what I'm saying.  It's a problem for the method, not for

Sure -- but it affects how implementations should process Success packets
(maybe not Failure packets for the reasons you state).

> Yes, if we had a MIC that protected all of the EAP messages, then it

You can't do that because you don't have keys to calculate such a MIC
until they are derived later. The only EAP packet that could benefit
from such a field would be Success (for some methods) and Failure (some of
the time, for some methods).

> complexity and corner cases that weren't present in 2284.

Since the peer can't know what methods are going to be run, it is hard to
apply this in practice. However, the peer *can* know whether the EAP
method it is currently running is complete or not, and whether Failure or
Success is expected.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 13:44:24 -0800 (PST)

Let's see if we can streamline the proposed resolution to Issue 80 a bit:

How does this look?

EAP methods also MAY include support for acknowledged success and
failure indications. This enables the authenticator to
indicate whether the peer has successfully authenticated to it,
as well as for the peer to acknowledge receipt of
that indication, and respond with an indication of whether the
authenticator has successfully authenticated to the peer.
If a key has previously been derived, the result exchange MAY
be protected by a Message Integrity Check (MIC), (see Section 7.13)
and if so, then these success/failure indications are
considered protected.

In order to decrease vulnerability to spoofing of success and failure
indications, the following implementation advice is provided:

[a] Handling of EAP Success and Failure packets prior to method
completion. It is recommended that a peer EAP implementation
receiving an EAP Success packet prior to method completion
silently discard it. This ensures that a rogue authenticator will
not be able to bypass mutual authentication by sending an EAP
Success prior to conclusion of the EAP method conversation. For
methods that provide their own error indications prior to termination,
an EAP Failure packet prior to completion is unexpected, so
that it also can be disregarded.

[b] Authentication requirement. Where mutual authentication
is required, and the authenticator fails to authenticate
successfully to the peer, it is recommended that the peer
not enable the link as a result of receiving an EAP
Success packet. Instead, termination of the authentication
conversation is recommended.

[c] Contradictory indications. It is recommended that the peer
terminate authentication after failure of an authentication
method, even if an EAP Success packet is received.

[d] Processing of EAP Success and Failure. With the exception
of the above cases, EAP Success and Failure packets are
accepted and processed by the EAP implementation."

---

From: [email-masked] (Yoshihiro Ohba)
Date: Thu, 13 Feb 2003 18:21:17 -0500

> http://www.drizzle.com/~aboba/IEEE/draft-ietf-roamops-cert-02.txt

Thank you for sending the URL.  I'll read it.

> run within the tunnel -- and there's no reason to run such a protocol.

Some authentication might require machine certficiate and user
certificate.

Even a non-cert-based authentication method may generate large-sized
authentication data.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 13 Feb 2003 16:13:01 -0800 (PST)

> Even a non-cert-based authentication method may generate large-sized

I'm not aware of any EAP method not involving certs that supports
fragmentation.

---

From: [email-masked] (James Carlson)
Date: Fri, 14 Feb 2003 08:56:57 -0500

> peer has to enable the link based on such an indication.

I think that's perhaps missing the point.  I wasn't talking about EAP
Success.

We were talking about whether it was legitimate to add language to the
draft that allows an implementation to ignore EAP Failure under some
circumstances.  I don't believe that's a valid choice.

> point, then the peer can disconnect at will - whether or not an EAP Success is received.

If you're expecting some sort of interoperability to occur here, I
think you need to specify how you want EAP Failure to be treated.  The
default today is that EAP Failure ends the authentication session.  If
we change this such that EAP Failure sometimes does *not* end the
authentication session, then I think that all we've achieved is to add
new ways that implementations can fail to interoperate in a reasonable
manner.  That is, if an authenticatee ignores EAP Failure, but the
message itself was perfectly valid, then the authenticatee will have
to wait until some internal timeout to give up on the non-converging
session, and the failure reported will likely be wrong.  This seems
like a bad thing to me, especially so since the functionality proposed
doesn't appear to address the DoS problem in a complete way.

> and can discard such a packet if received.

How about for methods that do *NOT* have such mechanisms, and yet have
multiple rounds?

Are we now requiring that all methods that require multiple rounds
MUST define a "protected failure" message?

I suppose I would have less trouble with this if it were described in
a method document.  That is, if some wacky method decided to say
something like, "EAP Failure can't occur between messages A and B, so
if one is received, it should be ignored," then I'd have less trouble
with it.  I do have trouble with putting such a thing in the base
document.

I suspect that an underlying issue here is that you might be trying to
document the actual implementation details, such as APIs used for
method/EAP interfaces, and thus you want to be able to document all
the quirks that might be possible here.  I don't think that's a good
idea at all.

> EAP Failure where sequences can be used.

So, then, what's the point?  All I have to do is flood the
authenticatee with EAP Failure messages, and one of them is bound to
make it there after the last (or only) method is complete but before
the legitimate server has issued EAP Success.

I don't see that this language has actually fixed anything.

> respects if the transport were UDP.

I strongly disagree with that.  First of all, if it were UDP, then
reordering and duplication would need to be considered and handled,
and they're not.  Additionally, if it were UDP, one would have to
consider man-in-the-middle and message injection cases, and they're
not.

I think part of the problem is that we're not distinguishing among two
very different things: EAP as the PPP-derived signaling mechanism,
replete with Identifiers and retransmission, and EAP as the method-
related messaging system.  The two are already different -- EAP on the
wire is not the same protocol as EAP encapsulated in AAA.  I suggest
that the former is of much lower importance, and might be made medium-
specific, and that the latter is of very high importance, and is the
area where "preserving the existing implementation base" is a key
concern.

> There are no keys at the start, so you

That doesn't look right to me for two reasons.

First, let's suppose you do have some sort of EAP mechanism that
defines a MIC.  If you have that, then there's clearly some point in
the exchange at which MIC is enabled and un-MIC'd messages are no
longer allowed.  Once that point is reached, from EAP's point of view,
there's no such thing as *ANY* message that doesn't have a valid MIC.
It's exactly the same as a CRC.  You don't have to write language into
the EAP draft to say specifically that EAP Failure messages with a bad
CRC are ignored, and you thus don't have to write language into the
draft that says that messages with a bad or missing MIC are ignored.
For that reason, I think that any language that attempts to describe
the handling of MIC'd and un-MIC'd messages is flawed because it
provides the incorrect idea that (somehow) there are cases where MIC
becomes "optional" after being enabled.

Yes, I'm specifically saying that burying the MIC into the method
itself, and failing to protect all other subsequent EAP messages with
it, is a design mistake.

Second, I disagree that what you're suggesting is really impossible.
Let's suppose we design a new transport for EAP to be used on non-
point-to-point media.  One part of that transport could be the
generation of a session context and a key exchange *before* any EAP
messages are used.  It looks like a walk off into certificate-land,
but someone who needs to handle arbitrary multi-access cases needs
that anyway.

> indirectly (ESP through the TCP/UDP pseudo-header).

I don't think the analogy holds up very well.  When you're using IPsec
(by coincidence, I actually am right now ;-}), the MIC really is built
into IP, because, by policy, all unprotected messages are discarded.
The fact that the implementation is realized as a shim header is
really an artifact of the way IP was designed, not of how the MIC
works.

TCP doesn't have and doesn't need language to describe what you do
with AH'd and non-AH'd segments.

> Similarly, you could

The problem is that you're still allowing some of EAP to be
unprotected.  To make the analogy with IPsec work, you need to have a
way to protect all the messages.  (And EAP doesn't have a mechanism to
insert shim headers.)

> method it is currently running is complete or not, and whether Failure or

Right.  Thus, as I suggest, it would make some sense to treat an
unexpected EAP Success as though it were EAP Failure.  It's the
"Error: peer is an idiot" case, and, as noted many times, either peer
can disconnect at any time for any reason.  Idiocy on the peer's part
is a darned good reason to disconnect.  However, simply discarding
either EAP message makes no sense, and is contrary to the intent of
2284.

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 14 Feb 2003 06:49:29 -0800 (PST)

To start off, I should say that I agree that discarding EAP Failure
messages can be problematic, and that we should probably stop at trying to
avoid spoofing of EAP Success. But I couldn't resist replying to your
message anyway :)

> How about for methods that do *NOT* have such mechanisms, and yet have

Then EAP Failure needs to be accepted and processed, as stated in the
proposed text.

> MUST define a "protected failure" message?

No.

> with it.  I do have trouble with putting such a thing in the base

Since in many implementations EAP Failure messages are not sent to the
method, this is typically not something that the method can control.

> the quirks that might be possible here.  I don't think that's a good

I'd agree that documenting APIs is a bad idea. But documenting on the wire
behavior seems reasonable. And some implementations do things along the
lines of what 4.2.1 describes (though perhaps we should hear more about
exactly what their behavior is).

> the legitimate server has issued EAP Success.

I agree that adding support for sequences creates a security vulnerability
of this kind.

> I don't see that this language has actually fixed anything.

It may not have.

> and they're not.

UDP doesn't provide any support for reordering or duplicate elimination.
It's all the responsibility of the application. What is it about EAP
that makes these services impossible for an EAP method to provide?

> Additionally, if it were UDP, one would have to

UDP doesn't provide any support for man-in-the-middle or message injection
detection. This is all done in the upper layers -- look at IKE [RFC2409].
So again, I'm not clear what services UDP provides that EAP does not that
makes this possible for UDP applications, but somehow impossible for EAP
methods.

> The two are already different -- EAP on the

In practice, it would be very difficult to write methods that would
operate on all media if EAP itself were media dependent. This would
require the NAS to act as an "EAP translation gateway", wouldn't it?

> draft that says that messages with a bad or missing MIC are ignored.

If we had EAP Success and Failure messages with an embedded MIC field,
it would operate as you say. Note that the MIC could only be verified by
the peer, because the NAS never receives the keys used in generation of
EAP MICs, only the MSK, which is crytographically independent of any of
the EAP method transient session keys.

The question is: what happens if the EAP Failure packet fails the
MIC? Since EAP Failure is not retransmitted, the only response the peer
can have is "silent discard" -- and so an attacker could send a peer
an EAP Failure with a bad MIC and end the conversation, just as if the
MIC wasn't here at all. That means that in practice a MIC'd
EAP Failure, without adding retransmission, would accomplish nothing.
In practice, I think a three way handshake is probably required, and
then we are really talking about a Success/Failure method --
which would require sequence support.

> becomes "optional" after being enabled.

That is true. It's not optional.

> itself, and failing to protect all other subsequent EAP messages with

This is also true -- but the question is whether it is possible to
introduce MIC'd success and failure indications and maintain backward
compatibility.

> One part of that transport could be the
> messages are used.

How is that different than introduction of an EAP method that does the
same thing? You can write an EAP method today that does DH, and then
tunnels EAP methods. In fact, this is exactly what EAP TTLS and PEAP do,
when they negotiate DH key exchange within TLS.

If that method were to run with no initial identity exchange, and in a
situation where both parties mandated its use, the wire exchanges could be
made to look very similar.

> into IP, because, by policy, all unprotected messages are discarded.

That depends on the IPsec policy.

> really an artifact of the way IP was designed, not of how the MIC

IPv6 was designed to require IPsec support, and yet IPsec functionality
wasn't folded into the IPv6 header. So it seems more like a layering
decision than an artifact of IPv4's design.

> with AH'd and non-AH'd segments.

Yes.

> way to protect all the messages.  (And EAP doesn't have a mechanism to

The Identity exchange is optional, so this can be ommitted entirely. If
the method is made mandatory and is supported on both sides, there is no
Nak Response. That means that the only messages (other than
Notification which doesn't change state) that are unprotected are the
EAP Success and Failure messages. As I argued previously, merely adding a
MIC to those messages wouldn't help without also adding support for
retransmission.

As for shim headers, several EAP methods implement them already. This is
what EAP TTLS and PEAP do. They can't be inserted in Identity, and Nak
messages, but I'd argue that since there are no keys when those messages
are typically sent, including a shim in those messages would do no good
anyway.

---

From: [email-masked] (James Carlson)
Date: Tue, 18 Feb 2003 09:29:01 -0500

> method, this is typically not something that the method can control.

I think this confuses specification and implementation.  I
specifically said "method document" -- not in the method itself, but
in a document describing how that method works and is to be used.
This could look like:

	"When using FooBar Authentication, it is not possible for the
	peer to report failure until after the Blah Message has been
	sent.  Therefore, EAP implementations employing FooBar
	Authentication MUST discard any received EAP Failure or EAP
	Success message until Blah has been sent at least once."

Now whether this is really a good thing or not is perhaps an issue to
discuss when FooBar is proposed, but I don't see why it's a relevant
issue for the EAP base document.  The base document doesn't define
exactly how these things work, so it shouldn't be defining how to
handle them either.

> I agree that adding support for sequences creates a security vulnerability

The vulnerability is there even without sequences.  All I need is have
sufficient access to the medium used to transport EAP messages, and I
can flood the authenticatee with EAP Failure messages, and this attack
is effective even when the EAP session has only one Request/Response
exchange and no "sequences" or other fluff at all.

	Authenticatee		Authenticator		Bad Guy
			<-	EAP Request
	EAP Response	->
			<------------------------	EAP Failure
			<-	EAP Success

Note that proper processing of EAP Response (checking for validity and
such) is always harder and more time-consuming than blindly sending
EAP Failure.  The authenticator is thus at a permanent disadvantage to
the Bad Guy.

Note that there are no sequences at all above.  There's not even an
Identity exchange (which, I would argue, is a simple example of a
sequence).  Are you suggesting that having multiple rounds solves the
problem?  Try:

	Authenticatee		Authenticator		Bad Guy
			<-	EAP Request 1
	EAP Response 1	->
	(ignored)	<------------------------	EAP Failure
			<-	EAP Request 2
	EAP Response 2	->
			<------------------------	EAP Failure
			<-	EAP Success

That seems to work just as well.  Once the method is "done," there's
still a hole into which the attacker can insert a Failure message.

(Depending on the linkage to the L2, EAP Failure *before* the first
EAP Request is also a possibility.)

> that makes these services impossible for an EAP method to provide?

I don't understand that response.  We're clearly talking about
different things here.

EAP doesn't have reordering and duplication protection in its handling
of Identification numbers, and it relies on the underlying transport
for this.  UDP can reorder and duplicate messages.  Therefore, running
2284 EAP over UDP isn't possible.  It won't work because UDP is an
unsuitable transport for EAP.

Are you proposing that this basic design feature of EAP (assuming
point-to-point links) is to be fixed via clever method
implementations?  I fail to see how that would be a good thing to
pursue.  It doesn't seem likely given the way Identification numbers
are handled.

> makes this possible for UDP applications, but somehow impossible for EAP

I'm not comparing UDP and EAP.  I'm comparing UDP and other possible
transports for carrying EAP around (such as PPP).  Here's the original

  > respects if the transport were UDP.

Yes, it would be quite different if the underlying transport for EAP
were UDP.  You'd have windowing on the Identification numbers, and
you'd have to consider the many different ways in which modified or
inserted messages could corrupt the negotiation state (or you'd have
to [effectively] mandate the use of IPsec to avoid the problem, a la
L2TP).  EAP in 2284 doesn't have any of that.

What I think you're saying is that we could have EAP methods that
provide protection to the exchange in a manner similar to IPsec.
However, that proposal falls apart unless there's specific support in
EAP or in the lower layers, because, unlike UDP, EAP is quite
stateful.  The Identification numbers provide a state mechanism that's
plainly outside of any sort of protection, and therefore breakable.

It seems to me that the options are:

	(1) Add a way to carry MIC in all EAP messages -- add it as
            part of the base 2284bis document.  This seems like a
            mostly good idea, though I'd like to see how it could be
            done in a reasonably compatible manner.

	(2) Describe a new mechanism to carry EAP messages on media
            where the problem exists (i.e., my EAPv2 proposal-in-cheek
            that I made to PANA).

> require the NAS to act as an "EAP translation gateway", wouldn't it?

It does already.  On PPP, you have to retransmit Request messages.  On
802.1X, you do not.  On AAA, it's backwards, with the Response
messages driving the authentication progress (rather than Requests),
and retransmission of the EAP Responses, not Requests.  It seems to me
to be a fundamental aspect of the protocol that it *already* appears
different on different media, and a NAS *does* act as a translating
gateway.

The fact that it doesn't have to look at the contents of the messages
in some cases seems to be a minor detail -- the behavior itself is
quite different on all these interfaces.

I don't see how that's a problem.

> the EAP method transient session keys.

I'm suggesting that you don't really have MICs unless you have EAP
Success and Failure with an embedded MIC field.

> MIC?

Why is that a special question with a different answer from what you
do when EAP Success, EAP Request, or EAP Response fails MIC?

> Since EAP Failure is not retransmitted, the only response the peer

... or a different way of carrying EAP around on media where such
concerns are valid.

> introduce MIC'd success and failure indications and maintain backward

It doesn't appear that this is so.  Nor is it possible to protect
Identification, Nak, and Notification, nor is any message's
Identification number protected in any way.

> same thing?

There are at least two ways that it is different:

	(1) before this exchange, no EAP messages are possible, and
            after the exchange, all are protected from tampering, so
            there are no holes.

	(2) it doesn't require any change to any part of the base EAP
            protocol to support it; Failure and Success handling
            remain the same.

> You can write an EAP method today that does DH, and then

They're still vulnerable to someone who wants to attack the weak
points: EAP Nak, EAP Notification, EAP Success, EAP Failure, and the
Identification numbers.

> made to look very similar.

Except that EAP Nak is still a possible and unprotected response from
the authenticatee, and except that EAP Notification, Success, and
Failure are possible unprotected messages from the authenticator.  I
think you have to outlaw quite a bit of EAP in order to make this
work.

Even if all that were worked out somehow, pass-through is a problem.
The lack of Identification number protection means that arbitrary
messages to the AAA server can be injected.

> That depends on the IPsec policy.

True, but the point is that we can have reasonable IPsec policies that
don't harm the protocol.  I don't see that the same is true for EAP.

> decision than an artifact of IPv4's design.

Uh ... maybe.  Everything in IPv6 was fobbed off onto extension
headers.  I think I'd say that the artifact was just made larger,
though reasonable people might disagree.  (Is a fragmentation header
part of the transport?  How about routing headers?  Why consider just
IPsec to be layered above and not these other extension headers?)

> Notification which doesn't change state)

Notification does change some state -- it changes the Identification
number.  It also likely involves activity outside of EAP (logging,
pop-up messages, and so forth) that *CERTAINLY* requires
authentication in this context -- if any EAP message needs it, then
Notification should as well.  Why ignore this?

> that are unprotected are the

I'm arguing that this (the lack of keys at the needed point) is a root
cause of the problem, not an unsolvable issue.

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 18 Feb 2003 10:04:22 -0800 (PST)

> 	Success message until Blah has been sent at least once."

This seems like a reasonable approach. I will try to add something like
this to the Appendix text.

> exactly how these things work, so it shouldn't be defining how to

It could perhaps say that some behaviors are possible.

> exchange and no "sequences" or other fluff at all.

Yes. As you say, it depends on the method.

> EAP Failure *before* the first EAP Request is also a possibility.)

Yes, if the peer is configured to support such "canned" responses that
will work too.

> unsuitable transport for EAP.

Yes, I agree with this.

> The Identification numbers provide a state mechanism that's

I think that depends on exactly how the Id and MIC are processed. If one
assumes that the MIC is processed as though the validation occurs first
(your suggestion), and the MIC covers the Id, then I'm not sure.
Otherwise, I think you're right.

>             done in a reasonably compatible manner.

That's the trick. So far we've discussed a Success/Failure method (such as
EAP TLV) The issue with that was that it would not function correctly on an
implementation not supporting sequences. We also talked about a new Code
-- but that would be ignored completely on existing implementations.

> 802.1X, you do not.

Actually, we were recently reminded by the 802.1X folks that they *do*
retransmit Requests. It's just that retransmission logic isn't in the
state machine. That error is fixed in -01.

> Success and Failure with an embedded MIC field.

I would agree, although you might need a three-way exchange to make it
reliable.

> do when EAP Success, EAP Request, or EAP Response fails MIC?

Only because Success/Failure are not retransmitted. Otherwise, no
difference.

>From where we sit now, I agree with this. Though I'd claim that the lack
of protection of Identity, Nak and Notification is intrinsic to the
problem.

> points: EAP Nak, EAP Notification, EAP Success, EAP Failure, and the

If only one method is permissible, then a spoofed Nak results in a DoS
attack at best. Notification doesn't change state other than IDs. So we're
left with Success/Failure spoofing and the IDs.

> messages to the AAA server can be injected.

In general, an attacker can modify any portion of the EAP header,
including the Ids. It's probably worth mentioning this in the security
considerations section.

> Notification should as well.  Why ignore this?

Notification is a weak mechanism as you say. RFC 2284 indicates
that Notification shouldn't be required in most cases, and there's no
support for localization. It's probably better for methods to include
their own (protected) error message support instead.

> cause of the problem, not an unsolvable issue.

It's definitely a root cause -- and if a DH is done first, they can be
available after the first round-trip.

---

From: [email-masked] (James Carlson)
Date: Tue, 18 Feb 2003 14:57:43 -0500

> Otherwise, I think you're right.

When we had that conversation, I thought that we were talking about
MICs in general, and not MICs with reference to some EAP-method-only
implementation.  For MICs in general, I think the principle still
holds, but for method-related ones, I'm much less sure.  It seems to
me that the existence of un-MIC'd and un-MIC-able EAP messages means
that implementing it solely within the method is a losing proposition.

(In other words, what I was assuming was something more radical than
what was perhaps proposed: a method that actually changed either EAP
itself or the underlying transport.  Since you couldn't implement such
a thing without appropriate changes to the EAP server, and thus it can
be assumed that such a server must already be privy to the game, it
would be feasible.)

> -- but that would be ignored completely on existing implementations.

Right.  We might as well have a meaning for length > 4 in
Success/Failure.

> state machine. That error is fixed in -01.

Hmm.  OK.  The statement about AAA does stand, though.  It carries EAP
messages but is backwards in definition from RFC 2284 EAP.  For what
it's worth, I see no problem in having slightly different semantics
when EAP is run over different transports, so long as the overall
behavior can be mapped appropriately.  One of the keys to getting that
right will be to *exclude* complications, such as varying the behavior
of messages depending on context.

> left with Success/Failure spoofing and the IDs.

I'm not so sure.  The intent of Notification is to provide a means to
tell the (presumably human) user about some event of significance.  If
delivery to a human is reasonably feasible (not all implementations
have users or user interfaces), then it should be done.  The problem
is that this provides a way for an attacker to pop up undesired
messages as well, and there appears to be no good way to avoid this in
EAP, other than carving out yet another exception.

> including the Ids. It's probably worth mentioning this in the security

The special problem that I'm referring to here is that if an attacker
sends forged Response messages, he can trick the EAP server into
DoSing the AAA server.

> their own (protected) error message support instead.

So should Notification be deprecated?

> available after the first round-trip.

The problem I'm having with this whole line of investigation and
documentation is that it's based on what seems to me to be a bad
premise.  In particular: how can EAP cope if one of the main
assumptions about the underlying layer (it's point-to-point -- there's
no more than one peer out there) is violated?

Since you end up needing to protect the subsequent network data
against the same threats, doesn't this end up being a new IKE?