Subject: [eap] Re: Issue 121: Document meaning of successful authentication

From: [email-masked] (Bernard Aboba)
Date: Tue, 6 May 2003 11:12:41 -0700 (PDT)

I do think that the suggested change is close to the correct meaning,
though some issues arise with the following paragraph:

"This definition differs from the usual definitions of
authentication (e.g. "verification of claimed identity"),
since the authenticator may decide to deny access even when
the identity of the peer is known and verified, or vice versa
(allow access when the identity of the peer is not verified)."

Even with the changes made in Issue 116, I think it is possible for an
authenticator to allow access to a peer which has failed to authenticate
to it. Presumably this would occur with restricted access, so that the
peer might have a chance to correct the deficiency (e.g. signup for an
account, send an email to get help, etc.). I think that would need to be
done with a method that either was one-way, or where the peer successfully
authenticated the authenticator. Might want to double check whether
there are any other "gotchas" in the draft bearing on this.

I do agree that the authenticator may decide to deny access even when the
identity of the peer is known and verified. However, I think that given
the changes we've made in Issue 116, it would be necessary for the EAP
method to indicate that an authentication failure has occurred for this to
work, and depending on the protocol this might or might not be supported.

For example, let's say that I am only allowed access from 8 AM to 5 PM
under my plan. I attempt to connect at 6 PM, and correctly input my
credentials. After examining the access policy, the AAA server will send
an Access Reject to the NAS. If it is not careful it could also send an
EAP Success encapsulated within that Access Accept. To avoid this, we
introduced language in RFC 2869bis to discourage such a contradictory
message. So the AAA server presumably now encapsulates an EAP Failure
within the Access Reject.

However, if the AAA server didn't examine the policy until after the EAP
method was complete, there can be trouble because the method presumably
completed successfully. As a result, the changes indicated in Issue 116
would cause the EAP Failure to be silently discarded since it doesn't
agree with the result of the EAP method authentication which was
successful.

One response to this problem is that the AAA server should examine the
policy early on and appropriately terminate the method, so that it's not a protocol
issue, but an implementation issue. I'm not sure I find this 100%
convincing however, because in some methods (EAP TLS, for example), there
may not be a method-specific error message that appropriately conveys an
"authenticated but not authorized" error. So if we're going to go down
this road, we probably need to add some advice in the method Appendix to
make sure that those messages are available.

----------------------------------------------------------
Issue 121: Document meaning of successful authentication
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: May 2, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-May/001115.html
Document: EAP-02
Comment type: T
Priority: 1
Section: 1.2 (and possibly others)
Rationale/Explanation of issue:

It seems that in EAP we're using the word "authentication"
in somewhat non-standard sense, and I feel we should document
it.

Here's a first draft of text for section 1.2 (terminology):

"Successful authentication

In the context of this document, "successful authentication"
is an exchange of EAP messages, as a result of which the
authenticator decides to allow access for the peer, and the
peer decides to use this access.

This definition differs from the usual definitions of
authentication (e.g. "verification of claimed identity"),
since the authenticator may decide to deny access even when
the identity of the peer is known and verified, or vice versa
(allow access when the identity of the peer is not verified).

Furthermore, even if the authenticator decides to allow access,
the peer may consider the exchange a failure if it has not
successfully verified that it is talking to the intended
authenticator."

Do you think this captures the meaning accurately?
(It might require some small changes somewhere else
in the document, I can try to find them...)

---

From: [email-masked] (John Vollbrecht)
Date: Wed, 07 May 2003 09:51:06 -0400

--On Tuesday, May 6, 2003 11:12 AM -0700 Bernard Aboba 
<[email-masked]> wrote:

> policy early on and appropriately terminate the method, so that it's not
> a protocol issue, but an implementation issue. I'm not sure I find this
> 100% convincing however, because in some methods (EAP TLS, for example),
> there may not be a method-specific error message that appropriately
> conveys an "authenticated but not authorized" error. So if we're going to
> go down this road, we probably need to add some advice in the method
> Appendix to make sure that those messages are available.
>
>

I think there are two points here.  First, a RADIUS Access Accept message 
may contain any EAP message, including and EAP-Failure.  This is confusing 
and SHOULD not happen.  We have allowed this because RADIUS is acting as a 
carrier of EAP, and it seemed inappropriate to limit what EAP can within 
RADIUS.  Perhaps this is a mistake, and we should make it a MUST NOT for 
RADIUS Access Accept to contain an EAP-Failure?

 Second, EAP conversations consist of a sequence of methods and policy 
c0nnecting them.  The allowed non tunnelled sequences are quite simple, 
usually consisting of Identity followed by a selected authentication 
method.  The selection/negotiation of the method may depend on policy.  In 
addition EAP itself want to include a policy which says that a user is 
allowed access only between 9 and 5.    While this could be included in 
every EAP method somehow, that seems unwieldy, requiring every method to 
support every type of policy.

More likely it will be enforced independently by "EAP-policy".  A policy 
rule could be enforced before or after a method is run.  The 9-5 rule, for 
example, could be checked before or after the authentication method.  If it 
is checked before, the authentication method does not have to run if the 
policy fails.  If it runs after, the EAP conversation may fail even if the 
method succeeded.  In most cases this can be avoided, but there may be 
policy that depends on the output of a method as input to the policy.  If 
the output is binary (success/failure) only, it is hard to imagine a policy 
that could not be run before the method, allowing the method to execute 
only if method success means dialog success.  I a method can create other 
output [for example group membership] that can be checked, the issue is not 
as easy.

My suggestion is that we indicate strongly that the CON_ACC output of a 
method MUST be followed by an EAP-Success, and that it SHOULD only be used 
with protected Tunnelled methods, such as PEAP.

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

---

From: [email-masked] ([email-masked])
Date: Wed, 7 May 2003 17:45:04 +0300

Bernard Aboba wrote:

> It might be ok for the authenticator to be willing to grant
> access, and the peer to be unwilling to use the link, because
> the peer would then disconnect, which the authenticator could
> detect. However, I do not think it is ok for the authenticator
> to refuse to grant access and the peer to be unaware of this,
> because the peer will continue to attempt to use the link,
> with no success, unaware of what it needs to do in order to
> authenticate.

Sorry, I guess my explanation was a bit misleading in this case.
Yes, clearly the situation described above is undesirable, but
it should not happen.

>> The server's decision is communicated using a
>> Success or Failure packet (both are allowed)
>=20
> The problem is that you previously indicated that this message was
> silently discarded by the peer -- so how is it "communicated"?

I intended to say that in the current state machine draft, there
are two different ways for the server to communicate its
decision to the client.

In some EAP methods, the server's decision is communicated
inside the method using some method-specific messages
(e.g. Success/Failure inside PEAP tunnel). For these methods,=20
if the client has received a "confirmed success" from the=20
method, it will silently discard any Failure packets.

In other EAP methods, the same information (yes/no) is
communicated using EAP Success and Failure packets (and=20
thus neither of them can be discarded).

In both cases, the client will know what the server's decision
is, and can make its own decision ("is this the server I want to
talk to"). These are then combined with "AND" (meaning that the
end result will be "yes" only if both decisions were "yes").

Thus, if the server says "no" (using "confirmed failure" or
ordinary Failure message), the end result will be "no", and the
client won't have to wait for any timeout to discover this.

Best regards,
Pasi

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 13 May 2003 21:51:38 -0400

I am not able to join the conversation tomorrow.  I am having a medical 
problem this week - hopefully I will be better by Thursday and getting 
email.  I am pretty happy with 2284 and 2869 bis and with the stqte 
machine.  I have one major concern with both 2284bis and with the state 
machine - and that is that tunnelled methods will not be able to do 
sequences of methods.

Another concern is that the keying material information be taken from 2284 
and put in its own section, if possible.  I think keying is not always 
necessqry so putting it in its own section is important.

Sorry I can't join you tomorrow --

John

--On Thursday, May 8, 2003 2:29 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> > I think the problem is not with EAP, or AAA. The problem is with the EAP
> > lower layers, such as PPP and 802.1X. If they had a way to carry
> > authorization results, this problem wouldn't exist. In PANA, we carry
> > PANA result so this wouldn't be a problem.
>
> 802.1X considered, and rejected the carriage of authorization results. It
> was simpler to just recommend that the AAA result and EAP results agree.
>
> > I see rfc2869bis says (2) and (3) must agree. On the other hand, now we
> > are discovering that (1) and (2) must agree too.
>
> This is not a "discovery" -- it is an implication of the proposed state
> machine.
>
> > So, when an authentication
> > method succeeds, but authorization fails, should the authenticatin
> > server go back and flip the authentication method to "failed" so that
> > the results are all aligned?
>
> If the authentication method supports an authorization failure error
> message, it can send that and there is no problem. Alternatively, the AAA
> server can send a Reject/EAP Failure. If this does not agree with the EAP
> method, which completed successfully, then the peer may silently discard
> the EAP Failure. Again there is no issue, as long as the NAS sends a lower
> layer failure indication such as an LCP-Terminate or 802.11
> Deauthenticate/Disassociate.
>
> Why doesn't this address the problem?
>
> > We could make (1) and (2) the same, and keep (3) independent. But the
> > problem is there is no equivalent of (3) for the last hop when PPP or
> > 802.1X is used.
>
> That seems needlessly complex -- given that our goal is to improve
> interoperability.
>