Subject: [eap] issue 218

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2004 16:03:00 +0200

Folks,

We are trying to close issue 218 which was about the TLS
example and other text in Section 7.16. Any final comments?
(I have one comment at the end of this e-mail).

The current text reads as:

7.16 Protected Result Indications

    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 synchronize state with the
    peer 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
    free 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.

    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.

My comment was that we should probably insert a disclaimer into
the beginning, describing when PRIs are useful. Suggested text,
to be inserted after the first sentence in 7.16:

    "Protected Result Indications 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)"

Does this make sense?

--Jari

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 12 Feb 2004 16:45:53 +0100

> (I have one comment at the end of this e-mail).
... [snip current proposal]

Going over the text for section 7.16,  I'd like to propose some small
changes to make it read better - at least in my view.  The changes are
in the second and third paragraph of the current proposal for 7.16 text:

Old:
   "However, it is possible for an attacker to forge a Success packet

   free resources."

New:
   "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 when it had
   not yet successfully authenticated to the server, denial of service
   attacks could be mounted against the peer.  (After such an attack, if
   the lower layer supports failure indications, the authenticator can
   synchronize state with the peer by providing a lower layer failure
   indication.  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 if the authenticator is not
   authenticated by the peer.  (Where supported by the lower layer, an
   authenticator sensing the absence of the peer can free resources.)"

[Jari]
>      authentication has succeeded (module change of bits en

I'm not sure I understand your use of the word "module" here.

Also, if we insert this after the first sentence, the current
second sentence will need some trivial rewriting - I can fix
that once it's agreed to include something like this disclaimer.

	Henrik

-- 
  A mathematician is a machine for converting coffee into theorems. 
    -- Paul Erdös

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 12 Feb 2004 08:27:04 -0800

[email-masked] wrote:
>     service attack could be mounted against the peer.  Where
>     supported by the lower layer, the authenticator can synchronize
>     state with the peer by providing a lower layer failure indication
> to the 
> peer.  See
>     indication, it is desirable for the sender to verify that
>     sufficient authorization exists for granting access, though as
> discussed below
>     integrity protection, methods supporting protected result
>     indications MUST also support the "key derivation", "mutual
>     authentication" "integrity protection" and "replay protection"
> claims. 
> 
> My comment was that we should probably insert a disclaimer
> into the beginning, describing when PRIs are useful.
> Suggested text, to be inserted after the first sentence in 7.16:
> 

[Joe] I don't think this is quite right.  I think "Protected result
indicators are useful when lower layer result indications or lower layer
protection is not available."  

I think they are equally useful in the case where the method does
authorization or when it does not. Also the second qualification seems a
little circular, it seems to say it is useful to provide PRI if you
method doesn't provide PRI.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2004 19:30:25 +0200

> in the second and third paragraph of the current proposal for 7.16 text:

Looks good, thanks!

> I'm not sure I understand your use of the word "module" here.

Should have been "modulo".

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2004 22:33:45 +0200

> protection is not available."  

This text is good.

> authorization or when it does not. Also the second qualification seems a

This is the issue that I was trying to express: it seems to me that
in some cases the methods provide an inherent PRI for the auth part,
and in that case additional PRIs are only useful if you do authz
as well.

In any case, perhaps the text that you provided is sufficient,
particularly when 7.2.1 already has good disclaimers. What do
others think?

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Feb 2004 12:49:19 -0800

I am fine with Joe's text.

Yoshihiro Ohba