Subject: [eap] Re: EAP conversation model

From: [email-masked] (Bernard Aboba)
Date: Tue, 14 Jan 2003 11:26:57 -0800 (PST)

> Now *that's* a creative interpretation.  ;-}
>
> My understanding of Nak is that it means "I refuse to use that
> authentication type; please offer me another acceptable way to prove
> my identity to you."  Using it to mean "this type might possibly be
> valid a little later on, but it's not valid right at the moment
> because I was expecting you to say something else" seems pretty odd.
> It would likely lead to non-converging patterns (send Type A, send
> Type B, get Nak, go back to Type A ...).

Yes, I can see that. This is part of the complexity created by sequences.
The reason I suggested this "creative" interpretation was because that Nak
Response might be interpretted as innocuous by the authenticator in case
the Type B Request was spoofed by an attacker. If the Peer instead
responds with a Nak indicating no alternative (0), it's not clear to me
what the authenticator should do (assuming that it didn't send the Type B
Request).

> Not that it perhaps matters, but this new interpretation is also at
> odds with what "nak" means in the PPP context.

Can you expand on that?

> > Good point. I'd say the authenticator isn't "inside" a method until it
> > receives a Response with the same type as the initial Request.
>
> So, with that, I think you need language in the Nak to handle this
> case as well.  "An Authenticatee MUST NOT send Nak in response to any
> message other than the initial Request for a given method; a secondary
> Request within a single method MUST NOT elicit a Nak in response.  An
> Authenticator SHOULD ignore a Nak if received in response to any
> message other than the initial Request."
>
> This brings us to the odd position that, if you're doing sequences,
> then it's perfectly reasonable to get Nak on the third method of some
> longer sequence, but *not* in the middle of any one of the methods in
> the sequence.  Since you have to be able to handle one but not the
> other, that seems baroque and still quite unnecessary.
>
> (Yes, I'm just following you down this path.  I still don't agree with
> it.)

I think this is a logical implication of that path. Although since we now
have language discouraging sequences hopefully this will not be too
prevalent.

> > Because that allows an attacker to bring down the link by sending such a
> > packet.
>
> We can't fix that with the tools we're using.  EAP assumes some
> measure of security from the lower layer such that you already know
> that you're talking to *one* peer -- you just don't know *who* that
> peer might be.

In the case where the link isn't physically secure, the question is
whether that security is turned on yet. If the L2 ciphersuite is
dynamically keyed, per-packet integrity and authentication can't be
enabled until quite late in the conversation.

> It still doesn't make any sense to me.  Why continue sending Request
> messages if the peer has told you that he doesn't know what you're
> talking about?  Why not either (a) disconnect or (b) assume that the
> peer has an implementation bug in that method and try a different one.

I guess the difference is between an approach that says "bring the link
down if you detect that the other implemention is broken or you're under
attack" or "try to persevere anyway".

> > That has some undesirable DoS implications.
>
> I'm still lost on the DoS argument.  It seems to imply that the peers
> are either open to all attackers on a given link (i.e., 802.11 with no
> link security) or that the peer under attack but is unable to shut
> down the affected link.  If it's the former, then I think we're stuck
> because EAP just doesn't address that problem.  It rather strongly
> assumes that you're talking to exactly one peer.  If it's the latter,
> then that's an implementation bug -- if you're getting packets you
> don't like, then you should stop listening, and you really should not
> expect the protocol to save you from ruin.

Where EAP is used on wireless networks without L2 ciphersuites in place,
the peer is indeed open to attack from anyone within range. If an attacker
can cause the peer and authenticator to redo a complete authentication
exchange (including public key computations in some cases) by sending only
one packet, it seems to me that this provides a lot of leverage for the
attacker.

If one can assume that the EAP method MICs its own packets, then the
remaining forgery threats come from Identity, Notification, Nak, Success,
Failure and packets of other Types.

Notification doesn't change state, so we can probably ignore it. We can
restrict Nak forgeries to particular times in the conversation; Success
and Failure forgeries are discussed in Section 4.2.1. Identity can be
checked against message-specific identity exchanges (such as certs). So
we're left with packets from wrong Types. If we can limit the
opportunities for forgery here, we have a narrowed the potential forgery
threats somewhat, I'd think.

---

From: [email-masked] (James Carlson)
Date: Tue, 14 Jan 2003 16:31:40 -0500

> what the authenticator should do (assuming that it didn't send the Type B

It's not different from getting any other Type value in a Nak that you
don't recognize, support, or allow: if you don't like the peer's
suggestion, then you at least know that the peer doesn't implement,
support, or allow the Type you're currently using, but you know
nothing else.  A robust implementation would scratch the current Type
off the list of possible ways to authenticate this client and try the
next permitted one in the hope that, although the peer didn't suggest
this particular Type as the "right" one to use, we have nothing to
lose by trying.

> > odds with what "nak" means in the PPP context.

Configure-Nak in PPP means "I don't like the option you gave me, but
if you try it this other way, I might possibly respond."  You
specifically MUST NOT send it to mean "try again later."  "Try again
later" is implemented as discard because "Configure-Nak" carries with
it the implication that the current value is itself unacceptable --
"please don't try this again."

> enabled until quite late in the conversation.

Why isn't that just a design error?

> attack" or "try to persevere anyway".

Yes.  As we've noted several times, the simple way the EAP exchange
works does *not* lend itself to detecting attacks.  I think you'd need
to integrate peer-to-peer security into EAP itself to do that, and
you'd end up with a different protocol at that point.  Maybe IKE.

> one packet, it seems to me that this provides a lot of leverage for the

I see.  So what stops an attacker from beating the legitimate client
to the punch and sending the initial Identity Response message?

	EAP Authenticator	Legit Authenticatee	Attacker
	EAP Identity Request ->
			     <------------------------- EAP Identity Response
			     <- EAP Identity Response

If that happens, then the legitimate guy loses out -- and the exchange
is vulnerable to DoS attacks.  Period.

I still don't see the DoS issue that EAP can actually be expected to
handle in some reasonable way.  If you don't have an acceptable level
of security on the link such that you know there's at most one peer
out there from the moment of the first EAP message, I think you're
simply not in any position to fix this problem.

Trying to defend against "some" DoS attacks while leaving obvious
other ones wide open is just a way of rearranging the deck chairs.
The ship is still on its way down.

> threats somewhat, I'd think.

I don't think so.  Attackers can inject these messages at _any_ point,
and the result is the same.  Let's suppose that we have the new "no
new mid-stream horses" language in the draft.  An effective DoS attack
would be to watch for carrier from new clients and shove EAP Request
messages down the client's craw before the NAP can get the first
"real" one out.  Even a replayed EAP Request will do the job here, and
since the attacker doesn't have to do any difficult numeric conjuring,
it's likely that he has time to spare in this effort.  If this is
done, and the client responds, then you're stuck.  The NAP isn't
allowed to "change type" in the middle of the conversation, and the
attacker isn't really going to authenticate the client.

The there are two answers that make sense to me with EAP (and it's
likely that the second is just a possible implementation of the
first):

	1.  Assume that the link has an acceptable level of security
	    first.  How you achieve that in practice is a topic for
	    the "EAP on Foo" drafts and the administrators of access
	    devices, not the base EAP document.  For a wireless
	    application, I'd expect the L2 link to do an anonymous key
	    exchange of some sort first.

	2.  Write a method draft for insecure links that intentionally
            redefines parts of EAP -- disallowing Identity and Nak,
            using an initial Request/Response exchange to set up a
            shared key, defining MIC behavior, and so forth.  Nothing
            stops a method draft from rewriting history.  (I don't
            think it's necessarily a good idea, but it's clearly not
            without precedent.)

I don't see why any of that would constitute issues for the base
document, unless we're planning to redefine EAP to include a protected
key exchange before any "real" data are sent.

-- 
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