Subject: [eap] EAP-TLS fast reconnect case

From: Bernard Aboba <[email-masked]>
Date: Sun, 1 Feb 2004 23:10:53 -0800 (PST)

In reviewing the EAP-TLS fast reconnect sequence, it would appear to me
that:

a.  The server does not know whether the client has authenticated at the
time it sends its FINISHED message, since all it has gotten from the
client is the client.random, not any proof of authenticity.  So the
sending of the server FINISHED message is not an indication that the
server has authenticated the client.

b. However, once the server verifies that the sessionid is present in the
cache,  it knows the presumed client identity and can check authorization. If the
client was not authorized (e.g. time of day is outside prescribed limits),
once the server chooses server.random the new key can be derived and the
server could send a protected TLS "unauthorized" alert.  So if the server
sends the FINISHED message instead with no alert, this indicates that the
client will be authorized *if* the server can subsequently authenticate
it.

c. After the client receives server.RANDOM it can compute the new key,
verify the server FINISHED MAC and then send its own FINISHED
message.  If the server FINISHED message fails to verify, the client can
send a TLS alert, protected with the new key.  If the FINISHED message can
be verified, then the client has authenticated the server,
but does not know whether the server has authenticated it.  This implies
that the client FINISHED message allows the server both to verify
authentication as well as the client desire to access the network.

d. The server receives the client FINISHED mesage and checks it.  If the
client FINISHED MAC is verified then the server has authenticated the
client and an EAP Success is sent in reply.  If the client FINISHED MAC
fails to verify, the server is not able to send a TLS alert message,
since the negotiation has completed.  All that the server can do is send
an EAP-Failure message.

e.  As a result of a-d, it appears to me that in a TLS fast reconnect
that an attacker can forge a Success or Failure message and the client has
to accept either one.  In the case of a forged Success, the peer will
attempt to send data using an incorrect key and the data will be discarded
by the authenticator;  eventually the peer will tiemout.  In the case of a
forged Failure, presumably the client will disconnect.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 2 Feb 2004 09:00:00 -0800

Hi Bernard,

This is along the lines of my understanding as well.

[email-masked] wrote:
> a.  The server does not know whether the client has
> authenticated at the time it sends its FINISHED message,
> since all it has gotten from the client is the client.random,
> not any proof of authenticity.  So the sending of the server
> FINISHED message is not an indication that the server has
> authenticated the client. 
> 
> b. However, once the server verifies that the sessionid is
> present in the cache,  it knows the presumed client identity
> and can check authorization. If the client was not authorized
> (e.g. time of day is outside prescribed limits), once the
> server chooses server.random the new key can be derived and
> the server could send a protected TLS "unauthorized" alert.
> So if the server sends the FINISHED message instead with no
> alert, this indicates that the client will be authorized *if*
> the server can subsequently authenticate it.
> 
[Joe] I believe it is possible to have cases where authorization fails
even though session resume completes successfully.  

> c. After the client receives server.RANDOM it can compute the
> new key, verify the server FINISHED MAC and then send its own
> FINISHED message.  If the server FINISHED message fails to
> verify, the client can send a TLS alert, protected with the
> new key.  If the FINISHED message can be verified, then the
> client has authenticated the server, but does not know
> whether the server has authenticated it.  This implies that
> the client FINISHED message allows the server both to verify
[Joe] In most client implementations this is probably true that the
client will grant access.  I'm not sure that this must be true in all
cases.

> d. The server receives the client FINISHED mesage and checks
> it.  If the client FINISHED MAC is verified then the server
> has authenticated the client and an EAP Success is sent in
> reply.  If the client FINISHED MAC fails to verify, the
> server is not able to send a TLS alert message, since the
> negotiation has completed.  All that the server can do is
> send an EAP-Failure message.
> 
> e.  As a result of a-d, it appears to me that in a TLS fast
> reconnect that an attacker can forge a Success or Failure
> message and the client has to accept either one.  In the case
> of a forged Success, the peer will attempt to send data using
> an incorrect key and the data will be discarded by the
> authenticator;  eventually the peer will tiemout.  In the
> case of a forged Failure, presumably the client will disconnect.
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Feb 2004 19:23:19 +0200

Hi Bernard,

> server has authenticated the client.

Right.

> client will be authorized *if* the server can subsequently authenticate

I agree that we can do this, but does the above describe what we should
do, what current implementations do, or what the existing RFCs say?
I think we have a general weakness in most methods definitions with
respect to the authorization issues. For instance, the word "authorization"
does not appear in RFC 2716... and even more recent method specifications
could be a lot more explicit about these issues. I'm hoping the implementors
have gotten the checks right, however. The issue is similar to what we
discussed ealier on fast handoff: authentication and AAA does more than
pure authentication, and whatever you do, you always have to check for
various authorizations.

> authentication as well as the client desire to access the network.

Yes, and the client needs to make this decision before sending the
FINISHED message. (I think Joe may be saying that it does not always
happen.)

> forged Failure, presumably the client will disconnect.

Yes.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 Feb 2004 11:17:51 -0800 (PST)

> even though session resume completes successfully.

Essentially the session resume protocol requires that authorization be
checked by the server before the server authenticates the client. If this
is not possible for some reason (e.g. server doesn't want to leak
authorization info to an unauthenticated client) then authorization can
fail after a successful resume.

In any case, the client has authenticated the server but doesn't know if
the server has successfully authenticated it.  So the client could be
willing to accept access on that basis, but this is not a good idea,
because it could bring up the interface and attempt unsuccessfully to
obtain IP configuration because the authenticator denied access. As a
result, the client has to accept a Failure packet if sent, and act on it.

On the other hand, if the server fails to authenticate to the client, then
the client won't access the network, and it won't accept a Success.

The end result of this is that:

a. An attacker can spoof an EAP Failure without fear of detection.
b. An attacker can spoof an EAP Success; however, this will only fool the
peer into accessing the network if it has successfully authenticated the
server.  If for some reason the real authenticator wasn't happy, the
result will be a nasty timeout on the client.

In both cases, the end result is a denial of service, nothing more.

> client will grant access.  I'm not sure that this must be true in all

The client does have the ability to send a TLS alert if it doesn't want to
access the network for some reason, even though it has succesfully
authenticated the server.  So I think that this case is less likely.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Feb 2004 21:33:17 +0200

> In both cases, the end result is a denial of service, nothing more.

It seems that we are primarily using protected indications
as a mechanism to inform the other side, not as a means to
prevent attacks.

Some possible PI designs appear rather weak, if you
were to use them against attacks. For instance, if at
any point you can accept either a Success or a method specific
failure indication, attackers can spoof Success messages.
Another design would have a mandatory result indication in
any case, which would protect better against denial of service.
Then again, the opportunities for denial of service are quite
excellent in the messages prior to the establishment of keys,
that it may not be worth the trouble.

A third design integrates as many functions as possible, handling
both auth & authz with the same messages. This may not be possible
on all methods, however, if the necessary information is not available
at the right time.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 02 Feb 2004 12:07:40 -0800

> that it may not be worth the trouble.

We are currently investigating a possibility for adding result
indication in fast reconnect functionarity in EAP-IKEv2.  Since
EAP-IKEv2 is robuster than EAP-TLS against the DoS, including the
messages prior to the establishment of keys, I think that adding
result indication for EAP-IKEv2 fast reconnection might be worth doing
(though it requires one additional roundtrip).  So I think whether
adding result indication is worth the trouble depends on EAP methods
in use (in the case of TLS I agree with you.)

Yoshihiro Ohba