Subject: [eap] Proposed Resolution of Issue 217: Protected Result Indications

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Feb 2004 12:14:37 -0800 (PST)

Here is a proposed resolution to Issue 217.  Change the definition of
Protected Result Indications to:

"Protected Result Indications

A method provides result indications if under most conditions after the
method's last message is sent and received:

1) The peer is aware of whether it has authenticated the server, as well
as whether the server has authenticated it.

2) The server is aware of whether it has authenticated the peer, as
well as whether the peer has authenticated it.

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. An authenticated peer may be denied access due to lack of
authorization (e.g. session limit) or other reasons. Since the
EAP exchange is run between the peer and the server,
other nodes (such as AAA proxies) may also affect the authorization
decision. This is discussed in more detail in Section 7.16.

Result indications improve resilience to packet loss; see
Section 4.2 for discussion. They can also address some
Denial-of-Service vulnerabilities, though not all. See
Section 7.16 for details.

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Feb 2004 22:56:38 +0200

Looks good to me. One suggestion below.

> Section 7.16 for details.

Can we move the above reasons to the first paragraph, and add
"In some scenarios and types of EAP methods, " in front of "They"?
(See my last mail to the list.)

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 8 Feb 2004 13:36:22 -0800 (PST)

> (See my last mail to the list.)

Done.  See Issue 217 for the modified text.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Feb 2004 22:04:11 +0200

> Done.  See Issue 217 for the modified text.

Looks good. Thanks. I have nothing more on #217.

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 9 Feb 2004 15:42:48 -0800

I think this looks good, but I'm still not clear on what an implicit
indication is.  Does implicit mean there is no message called protected
success, but there is a message that serves this purpose or does
implicit mean that there may not be a message that servs the purpose of
protected success.

Thanks,

Joe

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jari Arkko
> Sent: Monday, February 09, 2004 12:04 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Proposed Resolution of Issue 217: 
> Protected Result Indications
> 
> 
> Bernard Aboba wrote:
> >>Can we move the above reasons to the first paragraph, and 
> add "In some 
> >>scenarios and types of EAP methods, " in front of "They"? 
> (See my last 
> >>mail to the list.)
> > 
> >

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Feb 2004 17:39:46 -0800 (PST)

> implicit mean that there may not be a message that servs the purpose of

At least in the 7.16 definition, an "implicit" success can occur due to
receipt of a defined message with no preceding error message.  The defined
message need not necessarily be an explicit "success" message. It could
just be part of the authentication exchange, sent only when previous
exchanges have completed successfully.

For example, typically an authentication exchange does not continue if
there has been an authentication failure along the line. This means that
continued evidence of progress can be interpretted as an indication that
previous exchanges were successful.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap