Subject: RE: [eap] Proposed resolution of Issue 212: Protected Result Indications

From: <[email-masked]>
Date: Fri, 16 Jan 2004 12:33:57 +0200

Bernard Aboba wrote:

> OK.  Here's the complete current text:
> 
> "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.  

I think the explanation "(that is, only either...)" is too
strict. To avoid problems with packet loss, it's enough that 
at no point both EAP-Success and EAP-Failure are possible.  

For instance, the authenticator could send a method-specific
failure message (e.g. TLS Alert) only when e.g. authorization
fails, but EAP-Success otherwise (this saves one roundtrip in
the successful case).

So, I propose we change the text inside parenthesis to 
"(that is, at no point both EAP-Success and EAP-Failure 
are acceptable)".

> 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."

I still haven't seen any scenario which actually benefits from
having _protected_ result indications. It also seems that most
methods will protect only some result indications, not all.

Given that "protected result indications" is listed as one 
of the "security claims" for methods, I think Section 7.16 
should offer some more guidance about what security implications 
having them, not having them, or protecting only some indications 
has.

(If the only security implication is "very minor improvement
to DoS resistance", I think we should probably leave them
out... after all, there dozens of other ways an attacker could
spoof or modify some packet to cause DoS, and we don't list
those in "security claims" either.)

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 16 Jan 2004 11:31:30 -0800

I agree with Pasi that I'm not sure I see the value of protected result
indicators.  Especially given that they seem very difficult if not
impoissible to implement in the real world.  Even if the EAP method
supports it authorization along the NAS-proxy path may take into account
information that is not avaiable to process performing the EAP
authentication. 

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Friday, January 16, 2004 2:34 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [eap] Proposed resolution of Issue 212: 
> Protected Result Indications
> 
> 
> Bernard Aboba wrote:
> 
> > 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."
> 
> I still haven't seen any scenario which actually benefits 
> from having _protected_ result indications. It also seems 
> that most methods will protect only some result indications, not all.
> 
> out... after all, there dozens of other ways an attacker 
> could spoof or modify some packet to cause DoS, and we don't 
> list those in "security claims" either.)
> 
> Best regards,
> Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 Jan 2004 12:50:40 -0800 (PST)

Protected Result indications provide for synchronized state between the
client and server.  The lack of synchronized state was one of the
issues brought up in research at the University of Maryland.  This in
turn lead to the work on the EAP state machine and RFC 2284bis.

As demonstrated in the University of Maryland work,
synchronized state is achievable in EAP methods that are designed
carefully, and the improved resistance to rogue APs and DoS attacks is
worth the effort.

Of course, not every result indication can be protected, but that's not
required for this to be useful.

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 16 Jan 2004 15:45:04 -0800

Bernard Aboba wrote:
> Protected Result indications provide for synchronized state
> between the client and server.  The lack of synchronized
> state was one of the issues brought up in research at the
> University of Maryland.  This in turn lead to the work on the
> EAP state machine and RFC 2284bis.
> 
[Joe] I agree that synchronization is good EAP is good.  Synchronization
in EAP does not translate directly to synchronization of authorized
state between peer and authenticator.   Authorization may rely upon
other factors outside of authentication. 

> synchronized state is achievable in EAP methods that are
> designed carefully, and the improved resistance to rogue APs
> and DoS attacks is worth the effort.
> 
[Joe] Perhaps in a very constrained environment.  If you assume that the
EAP is the only authorization mechanism then I can see this working.  

> Of course, not every result indication can be protected, but
> that's not required for this to be useful.
> 
[Joe] I agree with this.  Synchronized state between EAP-Peer and
EAP-Server is in general good.  I do not think that this translates
directly to synchronization between EAP-Peer and EAP-Authenticator
authorization.  I think this synchronization is achieved best by a
mechanism outside of EAP.

>> I agree with Pasi that I'm not sure I see the value of protected
>> result indicators.  Especially given that they seem very difficult if
>> not impoissible to implement in the real world.  Even if the EAP
>> method supports it authorization along the NAS-proxy path may take
>> into account information that is not avaiable to process performing
>> the EAP authentication. 
>> 
>> Joe

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 16:09:32 -0800

> mechanism outside of EAP.

I agree with Joe.  As an example of an outside mechanism, the PANA
protocol has a mechanism to carry EAP-Success/Failure message with
acknowledged, and protected if key is available.  Even when some AAA
proxy finally denies an accept decision once has been made by the
server, the pass-through authenticator can send a EAP-Failure which is
carried by PANA with protected by using the established key, and the
peer can interpret EAP-Failure as "authentication succeeded but
authorization was finally rejected".

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 16 Jan 2004 16:28:25 -0800

Sorry for self-replying:

> authorization was finally rejected".

"EAP-Success/Failure" should read as "PANA result indication".

Yoshihiro Ohba

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 19 Jan 2004 15:06:35 -0500

> mechanism outside of EAP.
I think Joe's point that there may be authorization outside EAP is pretty 
strong.  In some environments it may be possible for an EAP method to 
succeed but the authenticated user may be refused.  Thus it would seem to 
be possible to get an Access Reject and an EAP Success.  I think what this 
means is that the Access Point pass the EAP Success, but the AP will also 
refuse to turn on the port.  If this is the case, then I think that the EAP 
method is used to authenticate the request, but it may be refused for other 
reasons.

The fact that an EAP method can succeed while the authorization fails seems 
ok to me.  It means that one port may be turned on while the other is not. 
For 802.1X this may cause llong timeouts.   My thinking right now at least 
is that this is a problem with 802.1X because it does not have a way to 
tell the other side that it failed.  Perhaps I am missing something?

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 19 Jan 2004 16:16:32 -0800

> <[email-masked]> wrote: 

<snip>

> tell the other side that it failed.  Perhaps I am missing something?

[Joe] I think so it appears that 802.1X does not have this
functionality.  I am worried about the current wording of 2284bis
section 2.4 

"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."

Which is equating EAP Authentication with authorization.  I think this
is bad. 

>>>> result indicators.  Especially given that they seem very difficult
>>>> if not impoissible to implement in the real world.  Even if the EAP
>>>> into account information that is not avaiable to process
>>>> performing the EAP authentication. 
>>>> 
>>>> Joe
>> 
>> [email-masked] http://mail.frascone.com/mailman/listinfo/eap