Subject: [eap] Re: Issue 212: Protected Result Indications

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jan 2004 09:52:13 -0800 (PST)

I've gone ahead and split out the discussion on Protected Result
Indications into Issue 212.

To help focus the discussion, it might be helpful to take a step back to
look at how we got into this discussion.

Russ noted that the text relating to implied result indications and error
messages was difficult to understand.  Separately,  Yoshi suggested that
there was no need for a separate attribute to tell the pass-through
authenticator that the peer had authenticated the server, because the key
attribute provided all the required information.

We then discussed under what conditions the authenticator could
conclude that the peer had authenticated the server, and would accept
access granted to it by the authenticator, based on possession
of a key attribute.

The Accept/Reject indication in AAA tells the authenticator whether it
should provide access or not.  So the authenticator receiving an Accept
knows that it will be granting access.  If a key attribute is provided
with the Accept (it cannot be provided within a Reject), the question is
whether this implies that the peer is willing to accept the access
offered it by the authenticator.

If the method gets as far as key derivation, and an Access-Accept with a
key attribute is sent, then by the requirements in 7.10, mutual
authentication MUST have occurred.  Then question is then whether there
can be a reason why the peer would not accept access offered by the
authenticator, even though mutual authentication had occurred.

This got us on the subject of error messages.  If the client successfully
authenticates the server, and the EAP method supports error messages,
then the peer has the ability to indicate to the server that a
problem exists even though mutual authentication occurred and a key was
successfully derived.  If the peer does not provide an error message
indicating lack of authorization, yet it completes the method, then an
implicit success result indication has been sent.

By this logic, all that matters in terms of using the key attribute as an
indication of peer acceptance is EAP method support for key
derivation, mutual authentication and a client result indication (e.g.
client error messages).
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap