Subject: [eap] Re: Issue 80, Success Indications

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 10:34:20 -0800 (PST)

> When the peer determines it is "ok" to connect to the authenticator, it
> could enable its end of the connection.  One reason NOT to do that would be
> if the authenticator has not completed its sequence of methods.

Assuming we allow sequences, the peer can't know this until a Success or
Failure is sent, no?

> case subsequent EAP methods might be sent out both the controlled and
> uncontrolled port (in 802.1x PAE model).

Does IEEE 802.1aa now support this?

> A reason FOR permitting this would be to allow a link to be enabled in the
> face of loss of a EAP Success message.  This would seem to be advantageous
> only if we expect high packet losses.  I think that 802.11 may have higher
> loss rate than other media, and it is a primary target for EAP.

IEEE 802.11 does include its own retransmission support. But of course a
STA can wander out of range.

> Both of the have some problems, so the alternative indication is
> introduced. If the peer is in a state where it would accept a "Success" (it
> is "ok" to connect to the authenticator) and it gets some link layer
> indication that the authenticator believes it has sent a Success and has
> turned on its controlled port (in 802.1x case), then the peer could take
> this as a "virtual Success" and enable the port.

The problem is defining what this "success" state would be on the peer.
With sequences, even if all methods up to that point had concluded
successfully, the peer cannot conclude that authentication has been
successful. As a result, while I believe that the peer can enter a
"failure" state based on method outcomes alone, I am not sure that it can
enter a "success" state that way.

> It is this recognition
> that is the "alternative" indication, and is probably different for
> different media layers.

Yes, those indications are now discussion in Section 7.12. The problem of
course is that most of them are unprotected.

> My suggestion is that the peer not enable the link until it gets either a
> Success or an "alternative indication" from the authenticator.  Alternative
> indications are from the lower layer, but EAP must allow for them.  --
> Discussion?

So far, section 3.4 enables link layer failure indications to be acted
upon, but not link layer success indications. Your requirement that the
peer be in a "success" state before acting on them makes it a bit more
palatable to consider acting on these alternative success indications.

The problem I think comes in defining exactly what they are, and also in
determining whether such a "success" state can exist prior to receiving an
EAP Success. If Sequences were prohibited, I would feel more comfortable
talking about this, because then method Success = EAP success.

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 18:53:13 -0500

--On Tuesday, February 11, 2003 10:34 AM -0800 Bernard Aboba 
<[email-masked]> wrote:

> > could enable its end of the connection.  One reason NOT to do that
> > would be if the authenticator has not completed its sequence of methods.
>
I think the peer can know if it would enable the link if it recieved a 
Success at that instant.   This may or may not be enough -- but I think it 
is - because the peer will have some minimum requirement for content of 
sequence.  Once it is satisfied, it is the authenticatior that will also 
have to be satisfied, and perhaps determine QoS or other information with 
additional sequences.  If the sequences don't happen, the default values 
would be applied.  Comments?

> Does IEEE 802.1aa now support this?

I am not sure what you mean support this.  Both ends are PAEs and each have 
controlled and uncontrolled ports - at least in principal.  Not all 
applications support this.   In the current state machine I believe the 
peer/supplicant will just not go to authenticated state.  The point is that 
each end determines whether to enable its end.  The success/failure 
indicates to the peer that the authenticator thinks it succeeded or failed. 

Certainly if it thinks it succeeded and the peer thinks it failed, the peer 
will not enable to link.  If the peer thinks it succeeded and the 
authenticator sends a Failure, then it doesn't really matter what the peer 
does because the authenticator will not enable the link.

>
> > A reason FOR permitting this would be to allow a link to be enabled in
> > the face of loss of a EAP Success message.  This would seem to be
> > advantageous only if we expect high packet losses.  I think that 802.11
> > may have higher loss rate than other media, and it is a primary target
> > for EAP.
>
> > introduced. If the peer is in a state where it would accept a "Success"
> > (it is "ok" to connect to the authenticator) and it gets some link layer
I am not sure why protection is an issue here?   If a Success can be faked 
(and since it is not protected it certainly can) why would a lower layer 
indication worse?

> > My suggestion is that the peer not enable the link until it gets either
> > a Success or an "alternative indication" from the authenticator.
> > Alternative indications are from the lower layer, but EAP must allow
> > for them.  -- Discussion?
>

My contention is that an alternative indication and a Success could be 
equivalent in the state machine.  If I can handle a success in a sequence, 
I can handle an alternative indication.

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

---

From: [email-masked] (Nick Petroni)
Date: Tue, 11 Feb 2003 19:23:11 -0500 (EST)

> would be applied.  Comments?
By if it doesn't happen, do you mean if it times out and hasn't received
another request (or Success)? What is the actual even that leads to the
success state? once you are there, presumably you won't be handling more
requests.

> I can handle an alternative indication.
I think I agree with these two points. Is there a case when you could fake
a lower-layer indication and not a Success?

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 21:50:39 -0500

These are hard conversations to have without pictures. :)

--On Tuesday, February 11, 2003 7:23 PM -0500 Nick Petroni 
<[email-masked]> wrote:

> > > Assuming we allow sequences, the peer can't know this until a Success
> > > or Failure is sent, no?
> > Success at that instant.   This may or may not be enough -- but I think
> > it is - because the peer will have some minimum requirement for content
> > of sequence.  Once it is satisfied, it is the authenticatior that will
> > also have to be satisfied, and perhaps determine QoS or other
> > information with additional sequences.  If the sequences don't happen,
> > the default values would be applied.  Comments?
What I mean is that the authenticator is the "driver" of sequences.  If it 
decides not to initiate more methods, it stops, sends success or failure 
and enables its end of the link (or not).  The peer doesn't know what the 
authenticator is going to do.  It may have its own policy that expects a 
particular sequence, or it may have a policy that it will do any methods it 
understands after doing an approved authentication method.

Since the peer needs to be able to respond to an success or failure at any 
time, it can treat the alternative success (knowing the other end enabled 
its end of the link) as a success.

Whether there is a reasonable chance that such an indication exists is a 
question I have started to wonder about.

> > I am not sure why protection is an issue here?   If a Success can be
> > faked (and since it is not protected it certainly can) why would a
> > lower layer indication worse?
>
> > equivalent in the state machine.  If I can handle a success in a
> > sequence, I can handle an alternative indication.

---

From: [email-masked] (James Carlson)
Date: Thu, 13 Feb 2003 10:57:17 -0500

> a lower-layer indication and not a Success?

Only if you believe in MICs for EAP.

I agree that alternative indications are no more or less secure than
EAP Success and that (for PPP at least), they're a helpful robustness
feature.  I would not like to see them disallowed by an update to
2284.

If we simply must have special documentation features for MICs, then
we need to say that, for implementations that have some sort of MIC,
the alternative indication can be accepted only if it has the same MIC
guarantees as the EAP Success message would have had.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677