Subject: [eap] Issue 218: TLS example

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Feb 2004 09:40:41 -0800 (PST)

Issue 218: TLS example
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 2/2/2004
Reference:
Document: RFC 2284bis-08.l
Comment type: T
Priority: S
Section: 7.16
Rationale/Explanation of issue:

Discussion of EAP-TLS has resulted in additional insight that
should be reflected in the specification.

Change Section 7.16 from:

"7.16 Protected Result Indications

EAP Success and Failure packets are neither acknowledged nor
integrity protected. This creates a potential vulnerability to
spoofing, as well as lengthy timeouts.

To address this vulnerability, EAP methods may implement protected
result indications. Since protected result indications require use
of a key for per-packet authentication and integrity protection,
methods supporting protected result indications MUST also support the
"key derivation", "mutual authentication" "integrity protection" and
"replay protection" claims.

Result indications may be implicit or explicit. For example, a
method may use error messages in order to explicitly indicate a
failure, while the completion of mutual authentication and key
derivation without an error message implicitly indicates a successful
result.

For example, within EAP-TLS [RFC2716], the peer always authenticates
the server, and sends a TLS alert message in the event of an
authentication or authorization failure. If the server does not
receive a TLS alert message from the peer and the peer continues the
conversation to completion (e.g. sends a FINISHED message), then the
server can assume that the peer will accept access if granted it by
the server.

Similarly, the peer can assume that the server will grant access if
it does not receive a TLS alert message from the server, and the
server carries the conversation to completion (e.g. sends a FINISHED
message).

A server may use the "access denied" TLS alert after successfully
authenticating the peer to indicate that a valid certificate was
received from the peer, but when access control was applied, the
server decided not to proceed."

To:

"7.16 Protected Result Indications

EAP Success and Failure packets are neither acknowledged nor
integrity protected. This creates a potential vulnerability
to spoofing as well as denial of service attacks.

As described in Section 4.2.1, a peer silently discards a
Success packet received at a point where the method does not
explicitly permit this to be sent. Within a mutually authenticating
method, requiring that the server authenticate to the peer
before the peer will accept a Success packet prevents an attacker
from acting as a rogue authenticator.

However, it is possible for an attacker to forge a Success
packet at a point in a method where the server has
authenticated to the peer, but has not yet indicated that it
is willing to grant access. If the server were to
decide not to grant access, and a forged Success packet
were to be accepted by the peer, a timeout can
result. Where supported by the lower layer, this
can be remedied by having the authenticator provide a
lower layer failure indication to the peer. See
Section 7.12 for details.

If a server were to grant access prior to
determining whether the peer will accept it, then a
timeout can result. This can be remedied in lower layers
that allow the authenticator to sense the presence or
absence of the peer.

Method-specific success indications avoid these
issues. In a method suporting success indications,
a peer willing to accept access does not consider
the authentication successful until receives an
indication that the server is willing to
grant access.

In such a method, a server willing to
grant access does not consider the authentication
successful until it receives an indication that the
peer is willing to accept access.

Success indications may be explicit or implicit.
For example, where a method supports error messages,
a success indication may be defined as the completion
of the method in the absence of an error message.
Failure indications are typically explicit.

As described in Section 4.2.1, a peer silently
discards a Failure packet received at a point where
the method does not explicitly permit this to be sent.
For example, a method providing its own error
messages might require the peer to receive an
an error message prior to accepting a Failure packet.
While this may be useful for debugging purposes,
it will typically add a round-trip to the protocol.

Where result indications are authenticated,
integrity and replay protected, it is possible to
to address spoofing vulnerabilities. Since protected
result indications require use of a key for per-packet
authentication and integrity protection, methods supporting
protected result indications MUST also support the
"key derivation", "mutual authentication" "integrity protection"
and "replay protection" claims. However, since errors can
occur prior to key derivation, it is typically not possible
to protect all failure indications.

A protocol may provide protected result indications in some
circumstances, but not in others. For example, within
EAP-TLS [RFC2716], in the full handshake the peer intially authenticates
the server, and sends a TLS alert message in the event of an
authentication or authorization failure. If the server does not
receive a TLS alert message from the peer and the peer continues the
conversation to completion (e.g. sends a FINISHED message), then the
server can assume that the peer will accept access if granted it by
the server.

Similarly, the peer can assume that the server will grant access if
it does not receive a TLS alert message from the server, and the
server carries the conversation to completion (e.g. sends a FINISHED
message).

A server may use the "access denied" TLS alert after successfully
authenticating the peer to indicate that a valid certificate was
received from the peer, but when access control was applied, the
server decided not to proceed.

Since by the end of a successful full handshake both the peer and
server are aware of each other's access decision, this mode
of EAP-TLS provides for protected result indications.

In the session resumption handshake, the peer and server may
not be synchronized. After receiving the initial ClientHello
message, the server can check whether the sessionid sent by the
client is present in its cache. If so, it may check client
authorization and send a TLS alert (a failure indication)
if the client is not authorized. However, the client has not
yet authenticated to the server so that the server's
FINISHED message cannot be interpreted as a success indication.

Once the peer receives the server FINISHED message it can verify it
using the newly computed key and thereby authenticate the server.
If the client does not wish to accept access, a TLS alert may be sent.
Once the server receives the client FINISHED message, it verifies it
using the newly computed key. As a result, the client FINISHED
message can be considered a protected result indication.

Since the client never receives a method-specific result indication from
the server, as described in Section 4.2, if it has successfully
authenticated the server, then it waits for a Success or
Failure packet and must accept either of them. Of course, if
the server FINISHED message cannot be verified then accepting
a Success message is inappropriate. [BA - Does the language in
Section 4.2 needs to be modified?]. This means that an attacker
could forge a Success or Failure packet with impunity, although
this would only result in denial of service."

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 01:06:28 +0200

Hi Bernard, and thanks for the text. It looks good! I do have a
few proposed changes though, inline, and a summary of the situation

> Section 7.12 for details.

Yes.

> issues. In a method suporting success indications,

It may be an overstatement to say "... avoid this issues",
since it appears that such indications generally can not
handle all cases. Maybe "... help avoid some of these
issues"?

> of the method in the absence of an error message.

Yes. Can we add "In general, an implicit success indication
is the reception of a specific defined message without a
preceding error message."

> server can assume that the peer will accept access if granted it by

I may not understand EAP-TLS completely, but I think there is
something strange in the above, as it seems to imply that FINISHED
is sent after the ALERT. But Section 3.8 of RFC 2716 shows a
different order. But I may be missing something?

> this would only result in denial of service."

This looks correct. I also think 4.2 text looks sufficient in 08.n
version of the draft.

In summary, we have now a better understanding of what the indications
are, and to what extent example methods provide them. This is much better
than what we had before.

I see two remaining parts of this issue that need to be discussed:

1. Joe's example (proxy authz decision) shows a case where protected
    indications can not provide full protection against lengthy timeouts.
    I think we need to document that as a limitation. Here's an attempt
    at the text, to be placed at the end of Section 7.16:

       While protected indications can provide information between
       the peer and the server, it is important to realize that issues
       outside these nodes may affect the decision to grant access. As a
       result, the sole use of protected result indications does not guarantee
       syncronization of state between the peer and the authenticator,
       or that timeouts do not occur. For instance, a the EAP server
       may not be aware of the authorization decision performed by
       a AAA proxy between the authenticator and the server. Or
       access can be granted, but the authenticator may find itself
       unable to provide access due to temporary lack of resources.
       In general, only the lower layer could provide information
       about this type of situations.

2. In discussing issue 212, we agreed that the reception of the
    key attribute implies succesful authentication, not authorization.
    Still, the text above talks about authorization and access control.
    Since we have only the key attribute to communicate whether the
    result is sufficient for peer-to-peer operation, there may be
    an inconsistency here. Or perhaps this is just a part of what
    item 1 above is saying, i.e., that we can provide some though
    not necessarily all authz via EAP?

Comment or suggestions?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Feb 2004 17:38:17 -0800 (PST)

> handle all cases. Maybe "... help avoid some of these

OK.  Will incorporate.

> preceding error message."

OK.  Will incorporate.

> different order. But I may be missing something?

I'm not sure that the example in Section 3.8 is correct here.  Once the
server sends its FINISHED message, I believe that EAP TLS is complete on
the server side.  So an alert would typically be sent after
change_cipher_spec and prior to the FINISHED message.

>        about this type of situations.

I'll add this text.

>     not necessarily all authz via EAP?

The peer-to-peer issue was about whether both sides had sufficient
knowledge to avoid two one-way auths if their policies enabled that to
occur.  In a mutually authenticating method, the peer would know whether
the server was authenticated to it, and the server would know if
the peer authenticated to it.  When the authenticator receives an
Accept with a key attribute it knows that both sides authenticated each
other and that it is to provide access to the peer.

Based on the authenticator policy it could decide that this is sufficient
for it not to initiate an authentication in the other direction by sending
an EAPOL-Start to the peer.  This is really about whether the
authenticator feels that it needs to confirm that the peer will authorize
access on its end.

On the peer side, it knows that the authenticator offered access and
whether it will accept that access or not.  It could decide that it needs
to initiate authentication in the other direction, perhaps because there
is insufficient authorization.  In this case it can send an
EAP-Request/Identity in the other direction.

So in the end, I think this is more about authorization and policy than it
is about protected result indications.  I've looked at the text in section
2.4 and I don't think it is affected by these discussions.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Feb 2004 19:58:42 -0800 (PST)

Here's some revised text with your suggestions incorporated:

Method-specific success indications help avoid these

In such a method, a server willing to grant access
does not consider the authentication successful
until it receives an indication that the
peer is willing to accept access.

Success indications may be explicit or implicit.
For example, where a method supports error messages,
an implicit success indication may be defined as the
reception of a specific message without a
preceding error message. Failure indications
are typically explicit.

it will typically add a round-trip to the method.

While protected result indications may enable synchronization between
the peer and the server, this does not guarantee that the
peer and authenticator will be synchronized or that timeouts
will not occur. For example, the EAP server may not be
aware of an authorization decision made by a AAA proxy; or
the EAP server may grant access, but the authenticator may be
unable to provide it due to a temporary lack of resources.
In these situations, synchronization can only be achieved
via lower layer result indications.

An EAP method may provide protected result indications in some
circumstances, but not in others.  For example, within
EAP-TLS [RFC2716], in the full handshake the peer initially authenticates
the server, and sends a TLS alert message in the event of an
authentication or authorization failure.  If the server does not
receive a TLS alert message from the peer and the peer continues the
conversation to completion, then the server can assume that the peer will
accept access if granted it by the server.

a Success message is inappropriate. This means that an attacker

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 19:13:30 +0200

> change_cipher_spec and prior to the FINISHED message.

It worries me that the RFC may not be clear on this. If its not,
there can be implementations that do it in another manner than
you assume. I agree it would make sense to do it as you explain,
but maybe the implementor has read Section 3.8... Anyway, this
is not a 2284bis issue. But we should keep that in mind for a
possible future update of the EAP-TLS RFC or in discussions
of what protection exists in EAP.

> EAP-Request/Identity in the other direction.

I agree about all this, as long as we realize that an EAP layer access
authorization may not be the whole story. But the text already describes
this, so this part of the issue is now done.

> 2.4 and I don't think it is affected by these discussions.

Ok.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 19:13:41 +0200

Looks good. A few nits inline.

> Method-specific success indications help avoid these

s/these/some of these/?

> issues. In a method suporting success indications,

s/suporting/supporting/

Ok.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 4 Feb 2004 09:33:23 -0800

Hi Bernard,

I think this is better.  I still don't like the linking of successful
authentication with granting access since this is an implementation
specific behavior.  Successful authentication is generally required, but
not sufficient for authorization to grant access.  Additional comments
in-line below.

Joe

[email-masked] wrote:
> explicitly permit this to be sent. Within a mutually
> authenticating method, requiring that the server authenticate
> to the peer before the peer will accept a Success packet
> prevents an attacker from acting as a rogue authenticator.
> 
> is willing to grant access. If the server were to decide not
> to grant access, and a forged Success packet were to be
> accepted by the peer, a timeout can result. Where supported
> by the lower layer, this can be remedied by having the
> authenticator provide a lower layer failure indication to the
> peer. See Section 7.12 for details.
> 
[Joe] The two previous paragraphs require the authentication method to
perform full authorization in order to implement method-specific success
indications.  Protected result indications for authentication methods
should synchronize the result of authentication.

"does not consider the authentication successful until it receives and
indication that the [peer/server] successfully completed
authentication."

> protected result indications MUST also support the "key
> derivation", "mutual authentication" "integrity protection"
> While protected result indications may enable synchronization
> between the peer and the server, this does not guarantee that
> the peer and authenticator will be synchronized or that
> timeouts will not occur. For example, the EAP server may not
> be aware of an authorization decision made by a AAA proxy; or
> unable to provide it due to a temporary lack of resources. In
> these situations, synchronization can only be achieved via
> lower layer result indications.
> 
[Joe] "Protected protected result indications may enable synchronization
of the authentication result between the peer and the server, this does
not guarantee that the that the peer and the authenticator will be
synchronized to authorize access."

> An EAP method may provide protected result indications in
> some circumstances, but not in others.  For example, within
> EAP-TLS [RFC2716], in the full handshake the peer initially
> authenticates the server, and sends a TLS alert message in
> the event of an authentication or authorization failure.  If
> the server does not receive a TLS alert message from the peer
> and the peer continues the conversation to completion, then
> the server can assume that the peer will accept access if
> granted it by the server.
> 
> Similarly, the peer can assume that the server will grant
> access if it does not receive a TLS alert message from the
> server, and the server carries the conversation to completion
> (e.g. sends a FINISHED message).
> 
> A server may use the "access denied" TLS alert after
> successfully authenticating the peer to indicate that a valid
> certificate was received from the peer, but when access
> control was applied, the server decided not to proceed.
> 
> Since by the end of a successful full handshake both the peer
> and server are aware of each other's access decision, this
> mode of EAP-TLS provides for protected result indications.
> 
> message, the server can check whether the sessionid sent by
> the client is present in its cache. If so, it may check
> client authorization and send a TLS alert (a failure
> indication) if the client is not authorized. However, the
> client has not yet authenticated to the server so that the
> server's FINISHED message cannot be interpreted as a success
> indication. 
> 
> Once the peer receives the server FINISHED message it can
> verify it using the newly computed key and thereby
> authenticate the server. If the client does not wish to
> accept access, a TLS alert may be sent. Once the server
> receives the client FINISHED message, it verifies it using
> the newly computed key. As a result, the client FINISHED
> Since the client never receives a method-specific result
> indication from the server, as described in Section 4.2, if
> it has successfully authenticated the server, then it waits
> for a Success or Failure packet and must accept either of
> them. Of course, if the server FINISHED message cannot be
> verified then accepting a Success message is inappropriate.
> This means that an attacker could forge a Success or Failure
> packet with impunity, although this would only result in
> denial of service." _______________________________________________
> eap mailing list [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 20:22:22 +0200

> indication that the [peer/server] successfully completed

I think your version is the absolute minimum that can be/is
provided by these indications. Bernard's version on the other
hand is the absolute maximum that can ever be provided. I think
the truth lies somewhere in between...  We are also walking a
fine line between not requiring impossible things from
implementations but still making it possible to use EAP
in a reasonable manner in the peer-to-peer case.

How about this: "...until it receives an indication that the
peer/server successfully completed authentication. When
sending such indications, the sender SHOULD verify that
sufficient authorization exists for granting access, though
as discussed below this is not always possible."

> synchronized to authorize access."

Yes, better. Thanks.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 4 Feb 2004 10:47:23 -0800

Jari Arkko wrote:
>> [Joe] The two previous paragraphs require the authentication method
>> to perform full authorization in order to implement method-specific
>> success indications.  Protected result indications for authentication
>> methods should synchronize the result of authentication.
>> 
>> "does not consider the authentication successful until it receives
>> and indication that the [peer/server] successfully completed
>> authentication."
> 
> hand is the absolute maximum that can ever be provided. I
> think the truth lies somewhere in between...  We are also
> walking a fine line between not requiring impossible things
> from implementations but still making it possible to use EAP
[Joe] The SHOULD here is really not appropriate. We are talking about an
authentication protocol. How about 

"...until it receives an indication that the
peer/server successfully completed authentication. When
sending such indications, it is often desirable to verify that
sufficient authorization exists for granting access, though
as discussed below this is not always possible."

>>> an implicit success indication may be defined as the reception of a
>>> specific message without a preceding error message. Failure
>>> indications are typically explicit.
>>> 
>>> derivation", "mutual authentication" "integrity protection" and
>>> "replay protection" claims. However, since errors can occur prior
>>> to key derivation, it is typically not possible to protect all
>>> failure indications. 
>>> 
>>> between the peer and the server, this does not guarantee that the
>>> peer and authenticator will be synchronized or that timeouts will
>>> not occur. For example, the EAP server may not be aware of an
>>> authorization decision made by a AAA proxy; or the EAP server may
>>> grant access, but the authenticator may be unable to provide it due
>>> to a temporary lack of resources. In these situations,
>>> synchronization can only be achieved via lower layer result
>>> indications. 
>>> 
>> 
>> [Joe] "Protected protected result indications may enable
>> synchronization of the authentication result between the peer and the
>> server, this does not guarantee that the that the peer and the
>> authenticator will be synchronized to authorize access."
> 
> Yes, better. Thanks.
> 
> --Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 21:45:01 +0200

> as discussed below this is not always possible."

Ok for me. Bernard, others?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Feb 2004 12:41:07 -0800 (PST)

> of what protection exists in EAP.

I've checked the TLS RFC, and there is no problem with ending a TLS alert
at any point after data transmission has commenced.  So the example in RFC
2716 is ok.  An alert can be sent before or after the server FINISHED
message, and could even be sent by the client in response to the server
FINISHED message (as opposed to the null packet illustrated).  SSL/TLS
APIs typically enable alerts to be sent at any time, too.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2004 00:05:51 +0200

> I've checked the TLS RFC, and there is no problem with ending a TLS alert

Thanks for digging into this.

> APIs typically enable alerts to be sent at any time, too.

Well, that's good for RFC 2716 because then its example is
correct. Its also good that APIs have the capability, because
then implementations can provide the alerts at the
most appropriate time.

But I wonder if this is good or bad for the discussion
on EAP protected indications. If the alerts can be sent at
any time, then we do not have a guarantee that they
are sent before FINISHED, as our current proposed text
says. * **

Here's a proposed fix. Replace

with

   A protocol may provide protected result indications in some
   circumstances, but not in others. For example, within
   EAP-TLS [RFC2716], in the full handshake the peer intially authenticates
   the server, and sends a TLS alert message in the event of an
   authentication or authorization failure. If the server does not
   receive a TLS alert message from the peer and the peer continues the
   conversation to completion, then the server can assume that the
   peer will accept access if granted it by the server.

--Jari

*) In fact, looking at Section 3.8 of RFC 2716, it
seems that in the examples, the alerts are sent at a
position where you would expect either Success, an
empty EAP-TLS packet, or an alert. Since both Success
and empty EAP-TLS packets can be spoofed, attackers can
spoof the lack of an alert, leading to DoS. Or am I
reading the draft wrong? What does this mean:

                            <- PPP EAP-Request/
                            EAP-Type=EAP-TLS

Is it a an empty EAP-TLS packet without TLS record inside,
TLS Message Length set to 0? Or an EAP-TLS packet with
an empty TLS record inside?

**) Another EAP-TLS question: if you compare examples in 2 and
3 in Section 3.8, the parts that happens after the server sends
a FINISHED message are very similar. In both cases the peer sends
an empty TLS record. In example 2 the server responds with EAP
Success, and in example 3 the server responds with an alert.
The peer must then be prepared to receive either a protected
alert or an unprotected success, or?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 6 Feb 2004 14:16:29 -0800 (PST)

Here's another shot at the proposed text:

As described in Section 4.2, a peer silently discards a

However, it is possible for an attacker to forge a Success
packet after the server has authenticated to the peer, but before
the server has indicated to the peer whether it will grant access.
If the peer were to accept the forged Success packet and attempt
to access the network but the server did not grant access, a
successful denial of service attack could be mounted against the peer.
Where supported by the lower layer, the authenticator can remedy this
by providing a lower layer failure indication to the peer.  See
Section 7.12 for details.

If a server were to grant access prior to determining whether the peer
will accept it, then an idle timeout can occur.  Where supported by
the lower layer,  an authenticator sensing the absence of the peer can
remedy this by disconnecting and freeing resources.

Method-specific success indications help avoid some of these
issues.  In a method supporting success indications,
a peer willing to accept access does not consider
the authentication successful until
it receives an indication that the
server successfully completed authentication.
Similarly, a server willing to grant access does not
consider the authentication successful until it receives
an indication that the peer has authenticated the server.
In order to avoid synchronization problems, prior to sending a
method-specific success indication,
it is desirable for the sender to verify that sufficient
authorization exists for granting access, though as
discussed below this is not always possible.

As described in Section 4.2, a peer silently

While method-specific result indications may enable synchronization
of the authentication result between the peer and server, this does
not guarantee that the peer and authenticator will be sychronized to
authorize access or that timeouts will not occur.
For example, the EAP server may not be
aware of an authorization decision made by a AAA proxy; or
the EAP server may grant access, but the authenticator may be
unable to provide it due to a temporary lack of resources.
In these situations, synchronization can only be achieved
via lower layer result indications.

Per-packet authentication, integrity and replay protection of
result indications protects against spoofing.  Since protected
result indications require use of a key for per-packet
authentication and integrity protection, methods supporting
protected result indications MUST also support the
"key derivation", "mutual authentication" "integrity protection"
and "replay protection" claims.

An EAP method may provide protected result indications in some
circumstances, but not in others.  Since errors can occur prior to
key derivation, it may not be possible to protect all
failure indications.

It is also possible that synchronization may not be achieved in
all possible exchanges.  For example, within EAP-TLS [RFC2716], in the
full handshake the peer initially authenticates the server, and may send a
TLS alert message to the server in the event of an
authentication or authorization failure.  If the server does not
receive a TLS alert message from the peer and the peer continues the
conversation to completion, then the server can assume that the peer will
accept access if granted it by the server.

Similarly, the peer can assume that the server will grant access if
it does not receive a TLS alert message from the server, and the
server carries the conversation to completion.

However, in the session resumption handshake, the peer and server may
not be synchronized.  After receiving the initial ClientHello
message, the server can check whether the session_id sent by the
peer is present in its cache.  If so, it may check peer
authorization and send a TLS alert message
if the peer is not authorized.  However, the peer has not
yet authenticated to the server so that the server's
Finished message cannot be interpreted as a success indication.

Once the peer receives the server Finished message it can verify it
using the newly computed key and authenticate the server.
If the peer does not wish to accept access, a TLS alert may be sent.
Once the server receives the peer Finished message, it verifies it
using the newly computed key. As a result, the peer Finished
message, once verified, can be interpreted as a success indication by the
server.

Since the peer never receives an indication of whether the server has
authenticated it,  if the peer has successfully authenticated the server,
as described in Section 4.2, it waits for a Success or Failure packet and
must accept either of them.  Of course, if the server Finished
message cannot be verified then it is inappropriate for the peer
to accept a Success message.  This implies that an attacker
could forge a Success or Failure packet with impunity, although
this would only result in denial of service."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Feb 2004 00:45:28 -0800 (PST)

> Ok for me. Bernard, others?

This works for me.  Here is the complete text of the proposed resolution
of Issue 218:

Result indications address some denial-of-service vulnerabilities with EAP
Success and Failure packets. These packets are neither acknowledged
nor integrity protected. Within a mutually authenticating method,
requiring that the server authenticate to the peer before the peer
will accept a Success packet prevents an attacker from acting as a
rogue authenticator.

Result indications help avoid some of these
issues. In a method supporting result indications,
a peer willing to accept access does not consider
the authentication successful until it receives an indication that the
server successfully completed authentication.
Similarly, a server willing to grant access does not
consider the authentication successful until it receives
an indication that the peer has authenticated the server.
In order to avoid synchronization problems, prior to sending a
method-specific success indication,
it is desirable for the sender to verify that sufficient
authorization exists for granting access, though as
discussed below this is not always possible.

preceding error message.

Failures are typically indicated explicitly.

While result indications may enable synchronization
of the authentication result between the peer and server, this does
not guarantee that the peer and authenticator will be sychronized to
authorize access or that timeouts will not occur.

EAP methods can typically provide protected result indications only
in some circumstances, but not in others. For example, errors can
occur prior to key derivation, and so it may not be possible to
protect all failure indications.

It is also possible that synchronization may not be achieved in
all possible modes of operation. For example, within EAP-TLS [RFC2716],
both the peer and server provide success result indications within the
full handshake, whereas in the session resumption handshake only the
peer provides a success result indication."

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Feb 2004 10:46:35 -0800 (PST)

I've cleaned up the resolution to 218 a bit to address some of the
authentication vs. authorization issues.  Here is the revised text:

Protected result indications address some denial-of-service
vulnerabilities with EAP Success and Failure packets. These packets
are neither acknowledged nor integrity protected.  Within a mutually
authenticating method, requiring that the server authenticate to the peer
before the peer will accept a Success packet prevents an attacker from
acting as a rogue authenticator.

However, it is possible for an attacker to forge a Success
packet after the server has authenticated to the peer, but before
the peer has authenticated to the server.  If the peer were to accept the
forged Success packet and attempt to access the network but the peer had
not yet successfully authenticated to the server, a denial of service
attack could be mounted against the peer.  Where supported by the lower layer,
the authenticator can remedy this by providing a lower layer failure
indication to the peer.  See Section 7.12 for details.

If a server were to authenticate the peer and send a Success packet
prior to determining whether the peer has authenticated the authenticator,
an idle timeout can occur.  Where supported by the lower layer, an
authenticator sensing the absence of the peer can remedy this by freeing
resources.

Result indications help avoid some of these issues. In a method supporting
result indications, a peer that has authenticated the server does not
consider the authentication successful until it receives an indication
that the server successfully authenticated it.

Similarly, a server that has successfully authenticated the peer does not
consider the authentication successful until it receives an indication
that the peer has authenticated the server.  In order to avoid
synchronization problems, prior to sending a success result indication,
it is desirable for the sender to verify that sufficient authorization exists
for granting access, though as discussed below this is not always possible.

Success indications may be explicit or implicit.  For example, where a
method supports error messages, an implicit success indication may be
defined as the reception of a specific message without a preceding error
message.

Failures are typically indicated explicitly.  As described in Section 4.2,
a peer silently discards a Failure packet received at a point where  the
method does not explicitly permit this to be sent. For example, a method
providing its own error messages might require the peer to receive an
an error message prior to accepting a Failure packet.

While result indications may enable synchronization of the authentication
result between the peer and server, this does not guarantee that the peer
and authenticator will be synchronized to authorize access or that
timeouts will not occur.  For example, the EAP server may not be
aware of an authorization decision made by a AAA proxy; the AAA server may
check authorization only after authentication has completed successfully,
only to discover that authorization cannot be granted; or the AAA server
may grant access but the authenticator may be unable to provide it due to
a temporary lack of resources.  In these situations, synchronization can
only be achieved via lower layer result indications.

Per-packet authentication, integrity and replay protection of result
indications protects against spoofing.  Since protected result
indications require use of a key for per-packet authentication and
integrity protection, methods supporting protected result indications MUST
also support the "key derivation", "mutual authentication" "integrity
protection" and "replay protection" claims.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Feb 2004 21:55:13 +0200

Hi Bernard, and thanks for the updated resolution. I think
we are now in agreement about the most of this, e.g. the
TLS description. There's also a right balance imho between the
auth and authz issues.

However, I still wonder about the first part where we describe
the vulnerabilities addressed by PRIs.

It seems that in order for the PRIs to be useful, either
one of the two conditions below MUST be present:

   1. EAP is being used to provide authz check AND
      this check is done in the protocol AFTER
      authentication.

   2. The server and peer authentications are independent
      in the sense that if one authenticates the other
      then it does not necessarily follow that reverse holds.
      For instance, I might authenticate you since I trust
      both the Ericsson and Microsoft CAs, but you would
      not authenticate me if you trusted just the latter.

      However, I suspect this does not happen in shared
      key methods. One party sends its message first,
      and the other one checks this based on the key and
      responds.

      Of course, bits can change en route, but this is true
      also of PRIs.

Is this correct or am I missing something?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Feb 2004 12:26:32 -0800 (PST)

>       this check is done in the protocol AFTER

Typically the authz check is done after auth since doing it before could
leak information to an attacker.  For example in TLS an alert can be sent
at any time, but in the resume handshake it might not make sense for the
server to check authz prior to sending its Finished message, even though
it knows the client identity from the session_id specified in the
ClientHello.  If the server did authz first, then an attacker could try
various session_ids and get info on what their authorization rights were.

Note also that a result indication can't be "integrity protected"
until after key derivation and can't be authenticated prior to
authentication.

>       Of course, bits can change en route, but this is true

Well, typically in an authentication protocol if one side fails, the other
side does not continue.  For example, in TLS the server doesn't attempt to
authenticate the client if the client indicates that the server cert is
unacceptable. This yields synchronization in that the server gets and
error message, knows the client has not authenticated it, and does not
attempt to authenticate the client.

This can hold true for a shared key method in that if the side proving
authenticity first fails to do so, the conversation typically ends. That
also ensures against leakage of information.

BTW, I've added some "weasel words" (e.g. most of the time) to the
proposed resolution of Issue 217.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Feb 2004 22:40:58 +0200

Bernard Aboba wrote:

> leak information to an attacker.

I see your point. But still you have to have the authz for this to
make sense, even if it seems reasonable that its typically afterwards.

> also ensures against leakage of information.

Yes. What you describe above is failure indications. These can be
either authz related which we already agreed above is one reason to
do PRIs, or auth related. But in the latter case you can not protect
the PFI. Or at most you can "protect" it using ephemeral keys in
the IKEv2 style.

However, for success indications, it seems that there are two ways
to reach them, either they have to be explicitly communicated, or
they have follow mathematically from an earlier message. (Clarification:
By explicit communication I would include both a separate message and
the lack of a separate message -- which you called implicit.)

Can we get some disclaimer at the beginning of 7.16? For instance:

"PRIs address some denial ... PRIs are useful when authorization
checks are being performed within EAP, or with methods where the peer
authentication can fail in a method even when server authentication
has succeeded (module change of bits en route)."

> proposed resolution of Issue 217.

I noticed ;-)

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Feb 2004 13:30:54 -0800 (PST)

> the PRI. Or at most you can "protect" it using ephemeral keys in
> the IKEv2 style.

Right.

> they have follow mathematically from an earlier message.

TLS appears to use the "implicit" style, at least in the full handshake.
The server sends its cert and server.random, the client verifies it and
then sends its key exchange message.  When the server receives this
message, it knows the client has authenticated it, but it hasn't yet
authenticated the client.  It accomplishes this by requesting the client
cert and verifying it.

> (Clarification:

Hmm. Where does TLS fit in this?  Or does that not fit in the
"mathematical" style of PRI?

> has succeeded (module change of bits en route)."

By "peer authentication" do you mean "peer authentication to the server"
and by "server authentication" do you mean "server authentication to the
peer"?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Feb 2004 22:30:35 +0200

> "mathematical" style of PRI?

In my terminology, TLS is still "explicit", even if communicated via
a lack of an error message. (Do not change the terms in the draft; they
are fine. We are just having this conversion to figure out exactly
how PRIs can be provided.)

What I meant with the "mathematical" style was that you could
reach a point in the protocol where you may not have performed
all tasks yet (such as peer's auth to the server), but where
this can no longer fail unless someone changes bits on the wire.
(And if that would happen, it could happen for PRIs as well.)

For instance, you may have already authenticated the server and
exchanged all parameters. Now, if the server's MAC was OK and the
peer implements the protocol correctly, the peer's MAC will be
OK too.

Or am I missing something?

Yes.

--Jari