Subject: RE: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues

From: <[email-masked]>
Date: Fri, 21 Nov 2003 14:34:28 +0200

John Vollbrecht wrote:
>
> > Proposed resolution to issue 198: Other EAP Peer SM issues
> >
> > - Remove all references to EapTunnelled (it does not adequately
> >   define behavior of existing tunneled methods, and we don't even
> >   need to describe their behavior in this document).
>
> I like all the changes except the removing of EapTunnelled.  It is
> set if EAP is running in tunnelled mode and hence allowed to do
> method sequencing.  I think this is a marker that says that
> sequences are not allowed on unprotected connections, but are (or
> are not forbidden) in protected connections.  I see no reason to
> take this out.  EAP is not constrained to run in an unprotected
> mode, and this indicates that everything should be the same in
> protected mode, except that method sequences are possible.

Ashwin Palekar thought that there actually are other differences, 
and the current SM (with the EapTunnelled flag) doesn't correctly 
describe the behavior of existing tunneled methods (and Yoshihiro 
seemed to agree with him).

I think they're right... there are some tricky issues relating to
e.g. interrupting a method that hasn't yet finished and dealing 
with methods that have protected result indications.

2284bis does _not_ specify how to handle these issues, so I 
think the state machine document should not specify them either.

Best regards,
Pasi

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Nov 2003 16:38:54 +0200

> with methods that have protected result indications.

Not to mention the *very* tricky issues such as the
AND/OR success schemes provided by PEAP. If I understood
it correctly, you get to choose either requiring all
methods in the sequence to be succesful, or just one
one of them.

I'm not quite sure, however, because like John I had
trouble understanding the big picture in the PEAP
document. That document also needs a state machine...
and that state machine can then deal with issues such
as the eapTunneled variable ;-)

> think the state machine document should not specify them either.

I agree.

--Jari

---

From: Nick Petroni <[email-masked]>
Date: Fri, 21 Nov 2003 09:49:11 -0500 (EST)

> > think the state machine document should not specify them either.
for what it's worth, I think this is the key factor. The other arguments
are convincing as well. I vote keep it out.

Regards,
nick

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Nov 2003 08:24:25 -0800 (PST)

> think the state machine document should not specify them either.

Yes. I believe that PEAPv2, EAP-TTLS and EAP-IKEv2 behave somewhat
differently in terms of their state machines, so that a single
eapTunnelled flag doesn't adequately describe the behavior of all
tunnelled methods.

I support removing the eapTunnelled variable.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Nov 2003 09:04:01 -0800

I agree.

Yoshihiro Ohba

---

From: John Vollbrecht <[email-masked]>
Date: Fri, 21 Nov 2003 14:36:27 -0500

> with methods that have protected result indications.

I agree that some tricky tunnelling issues may exist when tunnelling, but 
in principal a method that runs on outside a tunnell should run inside.  If 
we are saying that one does something different inside a tunnel then it 
seems that tunnelled EAP and EAP are quite different, and then we should 
wait to get tunnelled EAP sorted out before doing methods.

If there are reasons for not including this, I would at least like to know 
some specifics.  I would think we could have something now that is 
restrictive and expand later in a draft for tunnelled EAP to support 
expanded issues like interrupted methods and handling protected results.

> think the state machine document should not specify them either.

I agree.  The tunnelled attribute limits what can be done untunnelled.  It 
doesn't add anything.

What do you think?

-- John

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 21 Nov 2003 11:50:48 -0800

> > Ashwin Palekar thought that there actually are other 
> differences, and 
> > the current SM (with the EapTunnelled flag) doesn't 
> correctly describe 
> > the behavior of existing tunneled methods (and Yoshihiro seemed to 
> > agree with him).
> >
> > I think they're right... there are some tricky issues 
> relating to e.g. 
> > interrupting a method that hasn't yet finished and dealing with 
> > methods that have protected result indications.
> >
> 
[Joe] I don't think the problem is methods behaving differently inside
and outside the tunnel, but rather in how the tunnels behave themselves.

> expanded issues like interrupted methods and handling 
[Joe] There are several issues to consider: how inner authenticaiton is
bound to the tunneling layer, how the peer and server maintain
synchronicity of state, and there are probably others. I think that
having something now that is restrictive is not good.  I think it would
be very worthwile to explore these issues outside of the SM and 2284bis.

> think the 
> > state machine document should not specify them either.
> >
>