Alan DeKok [mailto:al...@deployingradius.com] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto://al...@deployingradius.com] writes:
> ...
> >>   Prior to authentication, EAP is the only communications protocol
> >> between a supplicant and *anywhere* on the network.  It is therefore
> >> natural to overload it as a general purpose transport protocol.
> >
> > To transport what, exactly?
> 
>   The data discussed in the tunnel requirements draft, Section 3.6.

Since that section is the only one that specifically mentions support for 
network configuration control (I won't stoop to claiming that NEA has any 
relation to security) rather than authentication, perhaps it should be removed.

> Among others.

What others?

> 
> >>   I believe that is what is happening: authorization parameters are
> >> being exchanged in EAP.  This should be made clearer in the
> documents.
> >
> > Above you said ... by way of rationalizing
> 
>   "explaining"
> 
>   The two are very different.
> 
> > the use of EAP "as a general purpose transport protocol".  I could
> have
> > sworn that authorization _follows_ and is parameterized by
> authentication.
> 
>   I agree.  I haven't seen any proposal that contradicts this.
> 
> > So, please tell me again why EAP should be (further) bastardized for
> this purpose.
> 
>   People are proposing it because they find it useful.  This isn't mean
> it's a good idea, just that it's one that has real-world uses.
> 
>   My message about this topic was intended to foster discussion.  

Success!

> If
> there is strong objection to the idea, we can refuse to "bastardize"
> EAP.  If there is strong consensus that this is necessary, it's best to
> make it explicit in the documents.

More likely the creation of a new protocol, unless "convenience" (a word that 
is used often in the draft as (often the only) justification for bizarre 
additions to EAP) has taken precedence over engineering in this WG.

> 
>   Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to