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

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 8 Jan 2004 12:40:57 -0800

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, January 08, 2004 11:34 AM
> To: Joseph Salowey
> Cc: [email-masked]
> Subject: RE: [eap] Proposed resolution of Issue 212: 
> Protected Result Indications
> 
> 
> > > The client isn't ready to accept an EAP-Success until it receives 
> > > the FINISHED message from the server, so I don't think 
> that's right 
> > > in this case.  It's really the joint receipt of the 
> FINISHED message 
> > > without receiving a TLS alert prior to that which is the success 
> > > indication.
> >
> > [Joe] Not in the case of TLS resume.
> 
> Do you have some text to suggest that will clarify this issue 
> in the suggested resolution of Issue 212?
I thought the text you had proposed was good.  It is just that integrity
protection of the indicators is required but not sufficient.  
 
How about

"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 supports result indications as
well as the "integrity protection" and "replay protection" claims. 7.16
for details."

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

---

From: <[email-masked]>
Date: Thu, 8 Jan 2004 18:56:43 +0200

> > I'd say that result indications are protected if they can't
> > be spoofed, and unprotected otherwise (since if we don't have
> > a "result exchange", speaking of integrity protecting is
> > somewhat confusing).  It also seems the revised definition
> > of "result indication" covers only things that occur after
> > key derivation...
> 
> We already have "integrity protection" and "replay protection" claims
> so perhaps it is easiest to piggyback on these.  I don't 
> think we have to specify exactly which result indications are 
> protected and which aren't; the method specification can clarify that.
> 
> So perhaps the right definition is:
> 
> 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, whether it will send an EAP Success or Failure
> packet), 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 supports 
> result indications as well as the "integrity protection" and 
> "replay protection" claims. See Section 7.16 for details."

Is a method allowed to make this claim if it protects only some of
the possible cases, but not all?

Hmm.. is integrity & replay protection actually enough to prevent
an attacker from changing result indications? For instance, in EAP-TLS 
the server sends the "client authorization failed" TLS alert after the 
change_cipher_spec messages, so it is integrity and replay protected. 
However, at this point the client is in a state where it will also 
accept EAP Success (so the "result indication" here was a _lack_ of
TLS alert message, and that could be spoofed)...

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2004 09:35:14 -0800 (PST)

> the possible cases, but not all?

Yes, I think so, since it is impossible to protect all the cases (e.g.
before a key is derived, there's nothing to protect it with).  All that
should be required is that the method specification state what is
protected and what isn't.

> TLS alert message, and that could be spoofed)...

The client isn't ready to accept an EAP-Success until it receives the
FINISHED message from the server, so I don't think that's right in this
case.  It's really the joint receipt of the FINISHED message without
receiving a TLS alert prior to that which is the success indication.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2004 13:15:44 -0800 (PST)

> well as the "integrity protection" and "replay protection" claims. 7.16

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.
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."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 8 Jan 2004 09:39:56 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Thursday, January 08, 2004 9:35 AM
> To: [email-masked]
> Cc: [email-masked]
> > Is a method allowed to make this claim if it protects only 
> some of the 
> > possible cases, but not all?
> 
> Yes, I think so, since it is impossible to protect all the 
> cases (e.g. before a key is derived, there's nothing to 
> protect it with).  All that should be required is that the 
> method specification state what is protected and what isn't.
> 
> > Hmm.. is integrity & replay protection actually enough to 
> prevent an 
> > attacker from changing result indications? For instance, in EAP-TLS 
> The client isn't ready to accept an EAP-Success until it 
> receives the FINISHED message from the server, so I don't 
> think that's right in this case.  It's really the joint 
> receipt of the FINISHED message without receiving a TLS alert 
> prior to that which is the success indication.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2004 11:33:31 -0800 (PST)

> [Joe] Not in the case of TLS resume.

Do you have some text to suggest that will clarify this issue in the
suggested resolution of Issue 212?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jan 2004 03:16:18 +0200

Hi Bernard,

I have a question...

> Section 7.16 for details."

My example method is EAP AKA, which sends an authenticated challenge
from the server in its first message. Before this challenge is sent,
the server already knows the identity of the peer.

Here's the question: Lets assume the method specification required that
the challenge be sent if and only if authz check for the peer is
successful. Would this be sufficient for satisfying condition 1 above?
Can you see such practise on shared key methods as sensible?

--Jari