eap Mailing List: RE: Issue 213: Cleanup issues

[Bernard Aboba (aboba]

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

   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.

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?