Subject: [Emu] Channel Binding: EAP Success handling

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Feb 2012 11:37:15 -0500

Hi.

EAP has a complex history of success indications over the years.
Some methods have protected success indications; some don't.

Especially as channel bindings are being initially deployed it's going
to be common to want to send channel bindings and possibly fail if they
do not match but not  to require the server to support them.
So, bidding down attacks are a real concern.

First, if you are using an EAP method where success indications are not
protected then you have a kind of hopeless situation.  I'm not entirely
sure how things are defined, but that might be incompatible with
providing mutual authentication as a security claim.  Channel bindings
already does require mutual authentication out of the method.

But there's another issue. Howe carefully does the client look at this.
>From a state machine standpoint is' really important that  your client
not just accept an eap success packet  as success if the method does
have an internal success indication.
If a client does accept an eap success packet then a malicious NAS could
inject such a packet.

The value of the attack may be limited by a couple of factors:

1) The client may be expecting keying material.
It's probably possible with some methods to get the client its keying
material

2) If the NAS interrupts the conversation with the server, then it
probably doesn't get its copy of the keying material.

However form things that don't really use the keying material, this may
be an issue.

I think it's worth writing up a security consideration that clients
implementing channel binding should be careful about their state machine
in this regard.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 06 Feb 2012 10:27:16 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> Hi.

    Sam> EAP has a complex history of success indications over the
    Sam> years.  Some methods have protected success indications; some
    Sam> don't.

    Sam> Especially as channel bindings are being initially deployed
    Sam> it's going to be common to want to send channel bindings and
    Sam> possibly fail if they do not match but not to require the
    Sam> server to support them.  So, bidding down attacks are a real
    Sam> concern.
    Sam> But there's another issue. Howe carefully does the client look
    Sam> at this.  From a state machine standpoint is' really important
    Sam> that your client not just accept an eap success packet as
    Sam> success if the method does have an internal success indication.
    Sam> If a client does accept an eap success packet then a malicious
    Sam> NAS could inject such a packet.

Hi.  As we're starting to gain implementation experience, it looks like
this is a real problem with a lot of implementations out there.  The
server we're looking at just sends back an EAP success packet
(unencrypted) as soon as it's sure that you've reached a success state.
It's actually being a bit tricky to convince the server to send a
channel binding reply.  So, putting it mildly, I suspect a lot of
clients will be fairly liberal in accepting unprotected success.

This is kind of serious if you want to work with old servers, but it
definitely is something we're going to want to document somewhere and
discuss the implications.

Obviously, we're going to want to define our standards-track tunnel
method not to have these issues.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 07 Feb 2012 10:08:36 +0100

> (unencrypted) as soon as it's sure that you've reached a success state.

  I would imagine many implementations have similar behaviors.  An EAP
success means... send success, right?  There are unlikely to be
provisions in the EAP state machine for "success, but not really" cases.

> clients will be fairly liberal in accepting unprotected success.

  I agree.

  Alan DeKok.