Subject: [eap] Issue 213: Cleanup issues

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Jan 2004 18:13:46 -0800 (PST)

Issue 213: Cleanup issues
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: 1/20/2004
Reference:
Document: RFC 2284bis-08.l
Comment type: T
Priority: S
Section: 3.1, 7.2.1
Rationale/Explanation of issue:

This is a generic issue to cleanup the text of -08.l as reflected in
WG discussions.

In Section 2.4 change:

"The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated and
authorized the server."

To:

"The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated
the server."

In Section 7.2.1, change:

"   Protected result indications
             A method provides result indications if after the method
             has finished (1) if the peer is willing to use the access
             provided by the authenticator, it knows whether the
             authenticator will grant access (that is, only either an
             EAP-Success or EAP-Failure will be accepted, no more method
             specific messages are expected), and (2) if the
             authenticator decides to grant access, it knows whether the
             peer will accept it.  Result indications improve resilience
             to packet loss; see Section 4.2 for discussion. Depending
             on the method and circumstances, result indications can be
             spoofable by an attacker.  A method is said to provide
             protected result indications if it supports result
             indications as well as the "integrity protection" and
             "replay protection" claims.  A method claiming to support
             protected result indications MUST indicate which result
             indications are protected, and which are not.  See Section
             7.16 for details."
To:

Protected result indications
A method provides result indications if after the
method has finished:

1) When peer is willing to accept access to the network, it knows whether
the authenticator will grant access.

2) When the peer decides to grant access, it knows
whether the peer will accept it.

Result indications improve resilience to packet loss,
and prevent long timeouts; see Section 4.2 for discussion.
Depending on the method design and circumstances, result
indications may be vulnerable to spoofing or replay by an attacker.

A method is said to provide protected result indications if
it supports result indications as well as the
"integrity protection" and "replay protection" claims.
A method claiming to support protected result indications
MUST indicate which result indications are protected, and
which are not. See Section 7.16 for details."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 20 Jan 2004 21:03:33 -0800

Bernard Aboba wrote:
<snip>
>              peer will accept it.  Result indications improve
>              resilience to packet loss; see Section 4.2 for
>              discussion. Depending on the method and circumstances,
> result 
> indications can be
> 1) When peer is willing to accept access to the network, it
> knows whether the authenticator will grant access.
> 

[Joe] Here again we have a mix of authentication and authorization.  It
would be better to qualify the above statement.

"Protected result indications
A method provides result indications if after the
method has finished:

1) When peer successfully completes the authentication, it
knows whether the authenticator has successfully completed the
authentication.

2) When the authenticator successfully completes the authentication, it
knows
whether the peer has successfully completed the authentication.

In the case where successful authentication is sufficient to authorize
access then the peer and authenticator will also know if the other party
is willing to provide or accept access.  This may not always be the
case."

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Jan 2004 19:52:15 -0800 (PST)

>Then, I am anxious that if attacker sends bogus Failure in case of
>authentication Success in network, legitimate peer can never get access
>of network. It is DoS attack by sending bogus authentication result.
>As a result, any peer cannot get access of network in case of bogus
>Failure sent by attacker.

I think there may be multiple issues lurking here.  These include:

1.  DoS attacks due to forged Failure packets.
2.  Man-in-the-middle attacks due to forged Success packets.
3.  Timeouts caused by loss of Success and failure packets.

Let me try to review what RFC 2284bis-08 says about these issues, so that
we can understand if it makes sense.

First, there is Section 4.2:

"  Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.  A peer EAP implementation
   receiving a Success or Failure packet where sending one is not
   explicitly permitted MUST silently discard it.  By default, an EAP
   peer MUST silently discard a "canned" Success packet (a Success
   packet sent immediately upon connection).  This ensures that a rogue
   authenticator will not be able to bypass mutual authentication by
   sending a Success packet prior to conclusion of the EAP method
   conversation."

To my mind this paragraph targets problems 2&3. For example, in a
mutually authenticating method, a Success packet sent prior to completion
of the mutual authentication (e.g. in EAP-TLS, before receipt of the
FINISHED message from the server) would be silently discarded by the peer.
Since a successful mutual authentication results in derivation of a key,
protection against a forged Success can rely on mutual proof of possession
of the derived key.  This proof of possession can at the same time ensure
synchronized peer and server state.  The end result is that the peer
authenticates the server, and also receives an indication that the server
will grant access.  The server authenticates the peer and receives an
indication from the peer that it will accept the granted access.
Note that this is really only the definition of a protected SUCCESS
indication.

The issue of forged Success packets was first raised by the University of
Maryland, and much of the state machine, 802.1X-REV and RFC 2284bis effort
has been oriented toward resolving this.

To some extent this paragraph helps with problem 1, but only partially. A
method-specific failure indication can only be protected if it is sent
after key derivation.  If the method gets as far as allowing both sides to
mutually authenticate and derive a key, the failure message is almost by
definition an "authorization failure" message.  That is, if the key is
derived and used to protect the error message, and the peer can
successfully verify the MIC, then authentication has succeeded.
This kind of protected error message is definitely useful because it
prevents what otherwise might be a long timeout on the peer side.  But it
does not address the DoS vulnerability because forged messages can be sent
at many points prior to key derivation that would successfully disrupt the
method exchange.

In reading the currently proposed definition of "Protected Result
Indication" I don't think that it covers this case -- a protected FAILURE
indication.

Back to the text of Section 4.2:

      Implementation Note: Because the Success and Failure packets are
      not acknowledged, they are not retransmitted by the authenticator,
      and may be potentially lost.  A peer MUST allow for this
      circumstance as described in this note.  See also Section 3.4 for
      guidance on the processing of lower layer success and failure
      indications.

Hmm.  Clearly the text seems to imply that a peer MUST do something to
handle the loss of Success and Failure packets, but I think the text could
be more clear on what an implementation needs to do to be compliant.  I
think there is an implication that the peer needs to implement the
recommendations in Section 3.4.  Or perhaps the requirement has to do with
the interface between the EAP layer and lower layer? Section 3.4 only has
a single normative word (a "MAY") so one searches in vain for requirements
there.

      As described in Section 2.1, only a single EAP authentication
      method is allowed within an EAP conversation. EAP methods MAY
      implement protected result indications. After the authenticator
      sends a method-specific failure indication to the peer, regardless
      of the response from the peer, it MUST subsequently send a Failure
      packet.  After the authenticator sends a method-specific success
      indication to the peer, and receives a method-specific success
      indication from the peer, it MUST subsequently send a Success
      packet.

This paragraph talks about something that an EAP method MAY do.  However,
the actions to be taken here don't depend on whether the method-specific
indication is protected or not.  So perhaps the word "protected" should be
removed from the second sentence.

      On the peer, once the method completes unsuccessfully (that is,
      either the authenticator sends a method-specific failure
      indication, or the peer decides that it does want to continue the
      conversation, possibly after sending a method-specific failure
      indication), the peer MUST terminate the conversation and indicate
      failure to the lower layer.  The peer MUST silently discard
      Success packets and MAY silently discard Failure packets.  As a
      result, loss of a Failure packet need not result in a timeout.

I think we have a typo here.  Shouldn't "it does want" be "it does not
want"?

      On the peer, after protected successful result indications have
      been exchanged by both sides, a Failure packet MUST be silently
      discarded.  The peer MAY, in the event that an EAP Success is not
      received, conclude that the EAP Success packet was lost and that
      authentication concluded successfully.

      If the authenticator has not sent a method-specific result
      indication, and the peer is willing to continue the conversation,
      once the method completes the peer waits for a Success or Failure
      packet and MUST NOT silently discard either of them.  In the event
      that neither a Success nor Failure packet is received, the peer
      SHOULD terminate the conversation to avoid lengthy timeouts in
      case the lost packet was an EAP Failure.

      If the peer attempts to authenticate to the authenticator and
      fails to do so, the authenticator MUST send a Failure packet and
      MUST NOT grant access by sending a Success packet.  However, an
      authenticator MAY omit having the peer authenticate to it in
      situations where limited access is offered (e.g., guest access).
      In this case the authenticator MUST send a Success packet.

      Where the peer authenticates successfully to the authenticator,
      but the authenticator does not send a method-specific result
      indication the authenticator MAY deny access by sending a Failure
      packet where the peer is not currently authorized for network
      access.

These paragraphs seem OK to me.

Next we have the infamous "protected result indications" definition in
Section 7.2.1:

             7.16 for details.

It occurs to me reading this again that the definition of result indications
really only applies to a method-specific SUCCESS indication, not to a
FAILURE indication.  A method provides a method-specific failure
indication if it supports error messages of any kind.  So perhaps the the
first sentence should start "A method provides failure result
indications if it supports error messages sent by both
the peer and server.  A method provides a success result indications if..."

Last but not least we have Section 7.16:

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.

This paragraph seems ok, other than perhaps the "may implement" could be
changed to a "MAY implement".

   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.

On rereading this, it occurs to me that it is only SUCCESS result
indications that can be implicit;  FAILURE indications need to be explicit.
So this is not so clear.

   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.

As a result of the discussion we had on the operation of TLS session
resume, I went back and looked at RFC 2246 as well as E. Rescorla's SSL
and TLS book.  I think these paragraphs are correct as written and apply
to session resume.  Or am I missing something?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Sun, 25 Jan 2004 22:20:17 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Thursday, January 22, 2004 7:52 PM
> To: [email-masked]
> Subject: RE: [eap] Issue 213: Cleanup issues
> 
> 
> >of network. It is DoS attack by sending bogus authentication 
> result. As 
> >a result, any peer cannot get access of network in case of bogus 
> Let me try to review what RFC 2284bis-08 says about these 
> issues, so that we can understand if it makes sense.
> 
> To my mind this paragraph targets problems 2&3. For example, 
> in a mutually authenticating method, a Success packet sent 
> prior to completion of the mutual authentication (e.g. in 
> EAP-TLS, before receipt of the FINISHED message from the 
> server) would be silently discarded by the peer. Since a 
> successful mutual authentication results in derivation of a 
> key, protection against a forged Success can rely on mutual 
> proof of possession of the derived key.  This proof of 
> possession can at the same time ensure synchronized peer and 
> server state.  The end result is that the peer authenticates 
> the server, and also receives an indication that the server 
> will grant access.  The server authenticates the peer and 
> receives an indication from the peer that it will accept the 
> granted access. Note that this is really only the definition 
> of a protected SUCCESS indication.
> 
> The issue of forged Success packets was first raised by the 
> University of Maryland, and much of the state machine, 
> 802.1X-REV and RFC 2284bis effort has been oriented toward 
> resolving this.
> 
> To some extent this paragraph helps with problem 1, but only 
> partially. A method-specific failure indication can only be 
> protected if it is sent after key derivation.  If the method 
> gets as far as allowing both sides to mutually authenticate 
> and derive a key, the failure message is almost by definition 
> an "authorization failure" message.  That is, if the key is 
> derived and used to protect the error message, and the peer 
> can successfully verify the MIC, then authentication has 
> succeeded. This kind of protected error message is definitely 
> useful because it prevents what otherwise might be a long 
> timeout on the peer side.  But it does not address the DoS 
> vulnerability because forged messages can be sent at many 
> points prior to key derivation that would successfully 
> disrupt the method exchange.
> 
> In reading the currently proposed definition of "Protected 
> Result Indication" I don't think that it covers this case -- 
> a protected FAILURE indication.
> 
> Hmm.  Clearly the text seems to imply that a peer MUST do 
> something to handle the loss of Success and Failure packets, 
> but I think the text could be more clear on what an 
> implementation needs to do to be compliant.  I think there is 
> an implication that the peer needs to implement the 
> recommendations in Section 3.4.  Or perhaps the requirement 
> has to do with the interface between the EAP layer and lower 
> layer? Section 3.4 only has a single normative word (a "MAY") 
> so one searches in vain for requirements there.
> 
> This paragraph talks about something that an EAP method MAY 
> do.  However, the actions to be taken here don't depend on 
> whether the method-specific indication is protected or not.  
> So perhaps the word "protected" should be removed from the 
> second sentence.
> 
> I think we have a typo here.  Shouldn't "it does want" be "it 
> does not want"?
> 
> Next we have the infamous "protected result indications" 
> definition in Section 7.2.1:
> 
> resilience
> It occurs to me reading this again that the definition of 
> result indications really only applies to a method-specific 
> SUCCESS indication, not to a FAILURE indication.  A method 
> provides a method-specific failure indication if it supports 
> error messages of any kind.  So perhaps the the first 
> sentence should start "A method provides failure result 
> indications if it supports error messages sent by both the 
> peer and server.  A method provides a success result 
> indications if..."
> 
> This paragraph seems ok, other than perhaps the "may 
> implement" could be changed to a "MAY implement".
> 
> On rereading this, it occurs to me that it is only SUCCESS 
> result indications that can be implicit;  FAILURE indications 
> need to be explicit. So this is not so clear.
> 
> As a result of the discussion we had on the operation of TLS 
> session resume, I went back and looked at RFC 2246 as well as 
> E. Rescorla's SSL and TLS book.  I think these paragraphs are 
> correct as written and apply to session resume.  Or am I 
> missing something? 

[Joe] I haven't quite parsed your entire message yet, but here is the
issue I was looking at:

From 2246 the abbreviated handshake looks like this:

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->
	Application Data              <------->     Application Data

In this case the client does not receive an indication that the server
accepted the authentication.  Since the server finished message comes
first it is possible that the Client's finished message is rejected by
the server.  At this point a failure or success is possible. Although
the protocol authentication is not considered complete until all the
finished messages have been correclty verified, I suppose that it is
very unlikely that the client would successfully verify the server's
finished message and respond with a bad finished message if it were a
valid client.  I don't think there is a very big problem here.  However
I do think we should change 

"server can assume that the peer will accept access if granted it by the
server." 
to 
" server can assume that the peer has authenticated the server."

And