Re: [Emu] EAP and authorization

["Glen Zorn" <glenzorn at comcast.net>]

Stephen Hanna [mailto:shanna at juniper.net] writes:

> Network Endpoint Assessment (NEA) messages can be considered
> authorization data. 

They can, in the broadest sense of authorization as policy enforcement.  It
has almost nothing to do with actual security, but that's OK, I guess.

> Certainly, they're not authentication.

Certainly not.

> They convey information about endpoint posture (like whether
> anti-virus software is installed and enabled). Yet they are
> carried in EAP messages every day, generally in tunnel methods.

So is the argument "Juniper (& presumably Cisco) have already bastardized
EAP, so we must rubberstamp it"?

> 
> I don't think there's anything wrong with this practice.
> In fact, it's the best way to ensure that a NEA assessment
> is performed before network access is granted.

Hmm.  Has another way been tried or is it the best way because it's the
easiest (or only) way we've tried?

> 
> I wouldn't say that EAP is becoming a "general purpose"
> transport protocol. EAP has many limitations that make
> it a poor choice for most situations that need a
> transport protocol. However, for some purposes it
> is a good match. NEA is one of those purposes.

Except for that whole pesky name & purpose thing -- you know, Extensible
_Authentication_ Protocol.
> 
> Thanks,
> 
> Steve
> 
> > -----Original Message-----
> > From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On
> > Behalf Of Alan DeKok
> > Sent: Tuesday, August 11, 2009 2:36 PM
> > To: Glen Zorn
> > Cc: emu at ietf.org
> > Subject: Re: [Emu] EAP and authorization
> >
> > Glen Zorn wrote:
> > > Alan DeKok [mailto://aland at 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.
> > Among 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.  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.
> >
> >   Alan DeKok.
> > _______________________________________________
> > Emu mailing list
> > Emu at ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
> >