Subject: [eap] issue 121: failed auth & succeeded authz?

From: [email-masked] (Jari Arkko)
Date: Sun, 01 Jun 2003 23:56:25 +0300

Bernard, as a part of the writeup on issue 121, you wrote
the following:

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

Thinking more closely about this, I'm starting to doubt whether
this is possible.

The concern that I have relates to situations where EAP produces
keys for some purpose. If the authentication fails, there generally
aren't any keys available. So how would the peer and the NAS proceed
in an environment that requires the keys? Or is the intention that
you can only do this if you can proceed to access without keys? Or
you can only do this while inside a tunnel? And if you were inside
the tunnel, are there any mitm issues involved?

So, to me this is starting to sound very complicated.

Can you cite a practical case where this is needed? 802.11i
authentication with EAP, lack of credentials, downgrade to
good old webpage-based login? But does this happen as a part
of EAP or as a part of link-layer procedures?

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 1 Jun 2003 14:51:57 -0700 (PDT)

> Thinking more closely about this, I'm starting to doubt whether

It is one thing for the peer to assert that "I do not have a valid account
and credentials and would like to create them."  In such a case (which
might or might not involve EAP), the peer might want to verify the server
identity, but since it doesn't have a userid and credentials, the
server can't verify its identity.

It is another thing for the peer to assert "I have a valid account with a
userid and credentials" and then to fail to prove the validity of that
assertion.

> aren't any keys available.

In tunneled methods, keys can be derived without the peer needing to prove
its identity.  However I do think it is fair to say that the AAA server
should not be providing keys to a NAS in the event of a failed authentication.
In fact, the RFC 2548 keying AVPs are not valid within an Access-Reject message,
which I believe needs to be carried forward into Diameter.  RFC 2869bis
discourages situations where the EAP outcome and AAA outcome are
different, so that if the AAA outcome is a Reject, then the recommended
EAP packet enclosed is a Failure.  Based on this, even if the EAP peer and
AAA server were to derive keys, in the event that EAP authentication
fails, the NAS would not obtain keys and therefore they could not be used to
encrypt data between the peer and NAS.

> So how would the peer and the NAS proceed
> in an environment that requires the keys?

I'd argue that if EAP is being used in an environment that requires keys,
then EAP SHOULD be used to derive those keys, so that the result of the
authentication is tied to subsequent per-packet protection. Perhaps RFC
2284bis needs to state that explicitly. Given that an authentication
failure does not result in keys being present on both the peer and the
NAS, that would argue that the peer and NAS cannot proceed in such a
circumstance.

On the other hand, it may be true that keys are not required. However, in
that case ("open authentication") I'm not clear why EAP would be needed.

> the tunnel, are there any mitm issues involved?

I think what may be going on here is that you have a one-way
authentication exchange (server -> client) that derives keys, followed by
some kind of signup process that results in a user/password being created.
However, in that case, assuming that the account gets created (e.g.
credit card validation succeeds), then the authentication has been successful,
and the user can be allowed on, with the access presumably being billed to
the newly created account. So when examined more closely, this is really
just like a normal tunneled authentication exchange.

However, if the account creation fails, it seems undesirable to allow
access at that point -- this looks like any other tunnel method where the
inner authentication fails.  In such a case, the keys cannot be used to
encrypt data, since they don't correspond to an authenticated session.

> So, to me this is starting to sound very complicated.

Actually, I think it's quite simple :) There appears to be no
justification for allowing access in the case where authentication is
attempted and fails.

> Can you cite a practical case where this is needed?

It would appear possible to carry out the scenarios described without
requiring that access be provided in event of a failed authentication.
Given this, it seems hard to argue for "flexibility", particularly when
this could create a security problem.

---

From: [email-masked] (Jari Arkko)
Date: Mon, 02 Jun 2003 08:51:22 +0300

> justification for allowing access in the case where authentication is

Ok. Updated text suggestion below:

Add to the terminology section:

"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. Note that the authenticator's
decision typically involves both authentication and
authorization aspects; the peer may provide correct input
for the authentication method but not be allowed to access
due to policy reasons."

Change the following text in Section 4.2 from:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to conclusion
of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, the authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the authenticator. If acknowledged result indications
are desired, these MAY be implemented within individual EAP
methods. Since only a single EAP authentication method is
supported within an EAP conversation, a peer that successfully
authenticates the authenticator MAY, in the event that an EAP
Success is not received, conclude that the EAP Success packet was
lost and enable the link."

To:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to
conclusion of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, they are not retransmitted by the authenticator,
and may be potentially lost. A peer MUST allow for this circumstance.
If acknowledged result indications are desired, these MAY be
implemented within individual EAP methods.

On the peer, once the method completes unsuccessfully, the EAP
conversation is terminated, the link is disabled, and a Success
packet MUST be silently discarded by the peer. As a result,
loss of a Failure packet need not result in a timeout.

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. A peer that successfully
authenticates the authenticator MUST silently discard Failure packets
and MAY, in the event that an EAP Success is not received, conclude
that the EAP Success packet was lost and enable the link.

The authenticator MAY deny access even where the peer
authenticated successfully within the method. For instance, the
authenticated peer may not currently be authorized to
get access. However, this can result in lengthy timeouts unless
either the method provides authorization-related error messages or
a lower layer failure indication is provided. For example,
within EAP-TLS [RFC2716], the "access_denied" TLS alert can be
used to indicate that a valid certificate was received, but when
access control was applied, the authenticator decided not to proceed.
If a method provides such error messages, the authenticator SHOULD use
them and SHOULD provide information that agrees with the final
decision of the authenticator. Section 3.4 provides guidance
on the processing of lower layer success and failure indications.

The authenticator MUST NOT grant access if the authentication method
was unsuccessful."

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 2 Jun 2003 08:06:35 -0700 (PDT)

I've edited the suggested fix a bit. Does the following text maintain your
intent?

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 by the peer, and the
peer decides to use this access. The authenticator's
decision typically involves both authentication and
authorization aspects; the peer may successfully
authenticate to the authenticator but access may be denied
by the authenticator due to policy reasons."

To:

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. Within a
mutually authenticating method, if the authenticator fails
to authenticate to the peer, the peer terminates the
EAP conversation, disables the link and the peer MUST
silently discard a Success packet. As a result,
loss of a Failure packet need not result in a timeout.
A peer that successfully authenticates the authenticator MUST
silently discard Failure packets and MAY, in the event that
an EAP Success is not received, conclude that the EAP Success
packet was lost and enable the link.

The authenticator MUST NOT grant access if the authentication method
was unsuccessful. The authenticator MAY deny access even where the peer
authenticated successfully within the selected EAP method, since the
authenticated peer may not be authorized for network access.
However,  this can result in lengthy timeouts unless
either the method provides authorization-related error messages or
a lower layer failure indication is provided. For example,
within EAP-TLS [RFC2716], the "access_denied" TLS alert can be
used to indicate that a valid certificate was received, but when
access control was applied, the authenticator decided not to proceed.
If a method provides such error messages, the authenticator SHOULD use
them so as to ensure consistency with the final
decision of the authenticator. Section 3.4 provides guidance
on the processing of lower layer success and failure indications."

---

From: [email-masked] (Joseph Salowey)
Date: Mon, 2 Jun 2003 09:31:19 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jari Arkko
> Sent: Sunday, June 01, 2003 10:51 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: [eap] Re: issue 121: failed auth & succeeded authz?
> 
> 
> Bernard Aboba wrote:
> 
> peer decides to use this access. Note that the 
> authenticator's decision typically involves both 
> authentication and authorization aspects; the peer may 
> provide correct input for the authentication method but not 
> be allowed to access due to policy reasons."
> 
> "EAP Success or Failure packets MUST NOT be sent by an EAP 
> server prior to completion of the final round of a given 
> method. A peer EAP implementation receiving a Success or 
> Failure packet prior to completion of the method in progress 
> MUST silently discard it. By default, an EAP peer MUST 
> silently discard a "canned" EAP Success message (an EAP 
> Success message sent immediately upon connection). This 
> ensures that a rogue authenticator will not be able to bypass 
> Implementation Note: Because the Success and Failure packets 
> are not acknowledged, the authenticator cannot know whether 
> they have been received. As a result, these packets are not 
> retransmitted by the authenticator. If acknowledged result 
> indications are desired, these MAY be implemented within 
> individual EAP methods. Since only a single EAP 
> authentication method is supported within an EAP 
> conversation, a peer that successfully authenticates the 
> authenticator MAY, in the event that an EAP Success is not 
> received, conclude that the EAP Success packet was lost and 
> enable the link."
> 
> To:
> 
> "EAP Success or Failure packets MUST NOT be sent by an EAP 
> server prior to completion of the final round of a given 
> method. A peer EAP implementation receiving a Success or 
> Failure packet prior to completion of the method in progress 
> MUST silently discard it. By default, an EAP peer MUST 
> silently discard a "canned" EAP Success message (an EAP 
> Success message sent immediately upon connection). This 
> ensures that a rogue authenticator will not be able to bypass 
> Implementation Note: Because the Success and Failure packets 
> are not acknowledged, they are not retransmitted by the 
> authenticator, and may be potentially lost. A peer MUST allow 
> for this circumstance. If acknowledged result indications are 
> desired, these MAY be implemented within individual EAP methods.
> 
> On the peer, once the method completes unsuccessfully, the 
> EAP conversation is terminated, the link is disabled, and a 
> Success packet MUST be silently discarded by the peer. As a 
> result, loss of a Failure packet need not result in a timeout.
> 
> As described in Section 2.1, only a single EAP authentication 
> method is allowed within an EAP conversation. A peer that 
> successfully authenticates the authenticator MUST silently 
> discard Failure packets and MAY, in the event that an EAP 
> Success is not received, conclude that the EAP Success packet 
> was lost and enable the link.
> 
> authenticated successfully within the method. For instance, 
> the authenticated peer may not currently be authorized to get 
> access. However, this can result in lengthy timeouts unless 
> either the method provides authorization-related error 
> messages or a lower layer failure indication is provided. For 
> example, within EAP-TLS [RFC2716], the "access_denied" TLS 
> alert can be used to indicate that a valid certificate was 
> received, but when access control was applied, the 
> authenticator decided not to proceed. If a method provides 
> such error messages, the authenticator SHOULD use them and 
> SHOULD provide information that agrees with the final 
> The authenticator MUST NOT grant access if the authentication 
> method was unsuccessful."
> 

[Joe] Hmmm.. What does it mean that an authenticaiton method was
unsuccessful?  Is it that the Peer or authenticator could not be
identified?  Is it that the key exchange failed?  It is possible for one
to succeed without the other.  Access is not necessarily a binary
decision.  It is possible to grant limited access even if the peer could
not be identified.  I think I agree that if key exchange was required
and failed that this may cause a fundamental problem is some systems,
but not all.  

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

---

From: [email-masked] (Jari Arkko)
Date: Mon, 02 Jun 2003 20:59:40 +0300

> to succeed without the other.  Access is not necessarily a binary

This is largely a method specific issue. In some methods everything
happens in one go, and you can't fail key exchange if user
authentication as such succeeded.

> and failed that this may cause a fundamental problem is some systems,

In earlier e-mails on the list we started to get a sense that
while it would be technically possible to allow EAP to continue after
an authentication failure, this appears unnecessary. Better
schemes exist, such as tunneled server auth + credit card "auth"
inside the tunnel. With these better schemes we do not need
to continue after an authentication failure. I get a better
feeling from that ;-)

--Jari

---

From: [email-masked] (Jari Arkko)
Date: Mon, 02 Jun 2003 20:40:19 +0300

> I've edited the suggested fix a bit. Does the following text maintain your

Yes. Looks better. --Jari

---

From: [email-masked] (Joseph Salowey)
Date: Mon, 2 Jun 2003 11:49:58 -0700

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, June 02, 2003 11:00 AM
> To: Joseph Salowey
> Cc: [email-masked]; 'Bernard Aboba'; [email-masked]
> Subject: Re: [eap] Re: issue 121: failed auth & succeeded authz?
> 
> 
> Joseph Salowey wrote:
> 
> > identified?  Is it that the key exchange failed?  It is 
> possible for 
> > one to succeed without the other.  Access is not 
> necessarily a binary
> 
> This is largely a method specific issue. In some methods 
> everything happens in one go, and you can't fail key exchange 
> if user authentication as such succeeded.
> 
> > decision.  It is possible to grant limited access even if the peer 
> > could not be identified.  I think I agree that if key exchange was 
> > required and failed that this may cause a fundamental 
> problem is some 
> > systems, but not all.
> 
> while it would be technically possible to allow EAP to 
> continue after an authentication failure, this appears 
> unnecessary. Better schemes exist, such as tunneled server 
> auth + credit card "auth" inside the tunnel. With these 
> better schemes we do not need to continue after an 
> authentication failure. I get a better feeling from that ;-)

[Joe] I don't think what authenticaiton failure means is at all clear.
What happens if the authe schem inside the tunnel fails, is that an
authenticaiton failure or not?

---

From: [email-masked] (Jari Arkko)
Date: Tue, 03 Jun 2003 07:22:11 +0300

Joseph Salowey wrote:

> I don't think what authenticaiton failure means is at all clear.

I guess the tunnel method specification should take
some standpoint on that ;-)

But I do see your point that an authentication failure may
not be precisely defined. I just think that perhaps this
is something that is defined by the methods.

--Jari

---

From: [email-masked] (Joseph Salowey)
Date: Mon, 2 Jun 2003 22:36:57 -0700

If you're not going to define authenticaiton failure in the EAP document
then I don't think you should be defining MUST NOTs around it.

Joe

> Sent: Monday, June 02, 2003 9:22 PM
> To: Joseph Salowey
> Cc: 'Bernard Aboba'; [email-masked]
> > I don't think what authenticaiton failure means is at all 
> clear. What 
> > happens if the authe schem inside the tunnel fails, is that an

---

From: [email-masked] (Joseph Salowey)
Date: Tue, 3 Jun 2003 10:25:23 -0700

So, if we define failed authenticaiton as the condition in which a
method will result in sending and EAP-Failure  I think things are okay.
Just so long as this is not a circular definition. An EAP-Success may or
may not indicate that a particular entity was authenticated
successfully. 

Joe

---

From: [email-masked] (Robert Moskowitz)
Date: Wed, 04 Jun 2003 16:23:16 -0400

One thing of interest that surfaced in the NSA/NIST WLAN Protection Profile 
Workshop last month was the requirement to show the WLAN AUP before 
permitting authentication.

Yet I have not seen an EAP method that supports this, nor is there a way to 
transmit an AUP in 802.1x.

So how can this be done?  As text in the EAP-Identity-Request (which limits 
the size of the AUP).

Robert Moskowitz
TruSecure Corporation
Security Interest EMail: [email-masked]

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 4 Jun 2003 13:27:48 -0700

Couldn't EAP-Notificaiton be used for this?

> On Behalf Of Robert Moskowitz
> Sent: Wednesday, June 04, 2003 1:23 PM
> To: [email-masked]
> Subject: [eap] How would you do AUP?
> 
>

---

From: [email-masked] (Robert Moskowitz)
Date: Wed, 04 Jun 2003 16:51:06 -0400

>Couldn't EAP-Notificaiton be used for this?

Isn't that too late?  It has to be before the challenge/response for the 
method.

Robert Moskowitz
TruSecure Corporation

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 4 Jun 2003 13:58:53 -0700

I don't think it is a problem to send a notification request as your
first request.  However most implementaitons are hard coded to start
with an identity request.  The notificaiton could happen after the
identity request but before the actual authenticaiton method request.  

> From: Robert Moskowitz [mailto:[email-masked]] 
> Sent: Wednesday, June 04, 2003 1:51 PM
> To: Joseph Salowey; [email-masked]
> Subject: RE: [eap] How would you do AUP?
> 
> 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Robert Moskowitz
> > > One thing of interest that surfaced in the NSA/NIST WLAN 
> Protection 
> > > Profile Workshop last month was the requirement to show 
> the WLAN AUP 
> > > before permitting authentication.
> > >
> > > Yet I have not seen an EAP method that supports this, nor 
> is there a 
> > > way to transmit an AUP in 802.1x.
> > >
> > > So how can this be done?  As text in the 
> EAP-Identity-Request (which 
> > > limits the size of the AUP).
> > >
> > >
> > > Robert Moskowitz
> > > TruSecure Corporation
> > > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > >
> 
> Robert Moskowitz
> TruSecure Corporation

---

From: [email-masked] (Alper Yegin)
Date: Thu, 05 Jun 2003 17:02:59 -0700

> justification for allowing access in the case where authentication is

How about this case:

I have a laptop that is configured with a single set of credentials from an
Internet service provider (e.g., [email-masked]). The shopping mall allows
roaming clients from a bunch of other ISPs but not ISP1. It provides premium
service (secure, highly available, etc.) to authenticated clients, and
willing to provide limited access to anyone else. If I walk into this
shopping mall, my laptop will make an attempt to get authenticated, but it
will fail, right? But the network is willing to provide limited access to my
laptop.

Alper

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 5 Jun 2003 16:58:45 -0700 (PDT)

> will fail, right? But the network is willing to provide limited access to my

This scenario is typically handled in IEEE 802.11 by support of multiple
Virtual networks.  That is, there is a "GUEST" SSID for guests,
providing limited access (e.g. separate VLAN) and another SSID for the
authenticated network. Similar facilities can be provided in other link
technologies that support a discovery facility (such as PPPOE).

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 5 Jun 2003 17:02:55 -0700 (PDT)

> will fail, right? But the network is willing to provide limited access to my

In this case, the authenticator will also fail to authenticate to the
peer, so the peer can't trust that it isn't a rogue network masquerading
as another one.  So even if the authenticator would choose to allow
access, the peer will disable its side of the link, so it does no good.

It makes more sense for the authenticator to advertise a separate limited
network with a different authentication policy ("open") and let the peer
connect to that instead.

---

From: [email-masked] (Alper Yegin)
Date: Thu, 05 Jun 2003 17:51:28 -0700

> technologies that support a discovery facility (such as PPPOE).

I'd like to understand the details a bit more. What is the order of events
that leads to aforementioned client receiving limited access service? (does
it have to somehow conclude that it is a GUEST before making attempt to get
authenticated [if so, how?], or does it fail first auth attempt and realize
it is a GUEST and make a second attempt, etc...)

Alper

---

From: [email-masked] (Alper Yegin)
Date: Thu, 05 Jun 2003 18:22:38 -0700

> access, the peer will disable its side of the link, so it does no good.

It does not always have to... For example, I'm willing to access free but
insecure networks. 

> network with a different authentication policy ("open") and let the peer

Yes, this makes sense. But I suspect my client will fail at least once
before it falls back to this separate network.

Alper

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 5 Jun 2003 18:01:40 -0700 (PDT)

> it is a GUEST and make a second attempt, etc...)

In networks with a discovery service, the peer determines that multiple
networks are available on the same wire. The peer can then attempt to
connect to any of those networks.  Depending on the link technology, it
may even be possible to connect to multiple networks at the same time.

Typically, a host has some reason to decide to connect to a network. For
example, it has signed up for an account with a particular network, and
when it discovers the presence of that network, it has reason to believe
that it has credentials valid for use with that network.

In your example, if the user only has an account with ISP1, that ISP could
provide the user with information on the roaming relationships.  For
example, in the case of dialup, a dialer is typically configured with all
the available phone numbers, some of which represent ISP1's facilities,
and others of which represent other ISPs with whom ISP1 has established a
roaming relationship.

In the case of IEEE 802.11 or PPPOE link technologies, multiple networks
can be advertised, so that the availability of ISP1's network can be made
known to the peer. If ISP1 is not available, then the facilities of
networks that are available can be advertised.

Depending on the discovery facility, it may be possible to advertise the
same network with multiple access mechanisms, as well as different
networks with different access mechanisms. So in this case, the ISP could
advertise a GUEST network with open access, and another network requiring
EAP authentication (e.g. WPA).

The peer, upon discovering these networks can choose which network to
attempt to connect to.  Typically, the peer will not automatically attempt
to connect to networks with which it has no pre-existing relationship, and
among those networks with which a pre-existing relationship exists, there
may be a preference list.

In this particular case, the user might have the GUEST network in its
preference list, since such a network is commonly used to indicate the
availability of (potentially restricted) open access. So upon not
recognizing any other configured network, the peer will choose to connect
to the GUEST network, rather than attempting to authenticate to another
network that it does not recognize. If the ISP1 network had been
advertised, then presumably the peer would attempt to authenticate to that
network, since the peer is configured with appropriate credentials and as
a result, has an expectation that the authentication will be successful.

Some more information on Virtual Networks and the implications for network
access is available here:

http://www.drizzle.com/~aboba/IEEE/virtual-APs.ppt
http://www.drizzle.com/~aboba/IEEE/11-03-154r1-I-Virtual-Access-Points.doc

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 5 Jun 2003 18:04:02 -0700 (PDT)

> It does not always have to... For example, I'm willing to access free but

That's fine -- but then there's no need to use EAP.

> before it falls back to this separate network.

It shouldn't because there's no reason for a client to be configured to
automatically connect to unrecognized networks in preference to recognized
ones (including a GUEST network).

---

From: [email-masked] (Joseph Salowey)
Date: Thu, 5 Jun 2003 20:21:31 -0700

> On Behalf Of Bernard Aboba
> Sent: Thursday, June 05, 2003 4:59 PM
> To: Alper Yegin
> Cc: Jari Arkko; [email-masked]
> > I have a laptop that is configured with a single set of credentials 
> > from an Internet service provider (e.g., [email-masked]). The 
> shopping 
> > mall allows roaming clients from a bunch of other ISPs but 
> not ISP1. 
> > It provides premium service (secure, highly available, etc.) to 
> > authenticated clients, and willing to provide limited 
> access to anyone 
> > else. If I walk into this shopping mall, my laptop will make an 
> > attempt to get authenticated, but it will fail, right? But 
> the network 
> > is willing to provide limited access to my laptop.
> 
> This scenario is typically handled in IEEE 802.11 by support 
> of multiple Virtual networks.  That is, there is a "GUEST" 
> SSID for guests, providing limited access (e.g. separate 
> VLAN) and another SSID for the authenticated network. Similar 
> facilities can be provided in other link technologies that 
> support a discovery facility (such as PPPOE).
> 

So is it a requirement that EAP be run over a link layer that supports a
"discovery facility"?

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 5 Jun 2003 20:08:43 -0700 (PDT)

> So is it a requirement that EAP be run over a link layer that supports a

Every known link layer supporting EAP either supports a discovery facility
or negotiation of EAP/non-EAP authentication methods.

For example, in PPP if an alternative authentication mechanism (or even no
authentication) is desired, it can be negotiated and EAP can be bypassed.

So it is not clear why it would be necessary to use EAP authentication in
situations in which there is no known trust relationship and therefore
authentication would be likely to fail.

---

From: [email-masked] (Joseph Salowey)
Date: Thu, 5 Jun 2003 21:18:56 -0700

I'm still confused about the meaning of authentication failure (I'm not
sure who I'm agreeing with).  Currently I look at it as follows:

Authentication policies are determined by the mechanism.  Some
mechanisms may be very strict in what they determine is a failure to
authenticate a peer. Others may allow a peer to go unauthenticated and
still call the authentication a success (however the entity may receive
different authorizations based on the result of the authentication).  

Authentication fails in one of two cases

1) In cases where key derivation is required and it fails there is
authentication failure

2) In cases where the mechanism indicates EAP-Failure there is
authentication failure

I agree that if either of the above two cases are true there should be
no change in access given to peer.  

Determining what is acceptable authentication policy is up to the
mechanism implementation.

Does this match up with anyone's view?

Joe

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, June 05, 2003 8:09 PM
> To: Joseph Salowey
> Cc: 'Alper Yegin'; 'Jari Arkko'; [email-masked]
> Subject: RE: [eap] Re: issue 121: failed auth & succeeded authz?
> 
> 
> > So is it a requirement that EAP be run over a link layer 
> that supports 
> > a "discovery facility"?
> 
> Every known link layer supporting EAP either supports a 
> discovery facility or negotiation of EAP/non-EAP 
> authentication methods.
> 
> So it is not clear why it would be necessary to use EAP 
> authentication in situations in which there is no known trust 
> relationship and therefore authentication would be likely to fail.
>

---

From: [email-masked] (Jari Arkko)
Date: Fri, 06 Jun 2003 09:03:07 +0300

> 2) In cases where the mechanism indicates EAP-Failure there is

If we look at the root causes of EAP authentication failure, I think
we have the following:

- Method authentication message somehow invalid (e.g. MAC)
- Method key generation somehow failed and keys needed
- Method-specific failure indication
- Insufficient authorization
- Protocol error, timeout, ...

--Jari

---

From: [email-masked] (Alper Yegin)
Date: Tue, 10 Jun 2003 18:32:03 -0700

Thanks Bernard, for elaborating the discovery service model.

> or negotiation of EAP/non-EAP authentication methods.

This assumption seems like impacting the EAP design. It might be already
available in existing lower-layers, but I think we should explicitly include
this in the draft for the new lower layers (if we want to maintain this
assumption/requirement).

> authentication would be likely to fail.

This assumes that the peer can fully and positively determine if the network
can surely authenticate it before they are engaged in EAP.

Alper