Re: [Emu] EAP and authorization

[Stephen Hanna <shanna at juniper.net>]

There are various definitions of authentication. One could
argue for the broad definition included in RFC 4949:

   $ authentication
      (I) The process of verifying a claim that a system entity or
      system resource has a certain attribute value.

Password change, channel bindings, and NEA assessments could be
included in that definition.

However, I agree that it would be better to get IESG clarification
that carrying authorization data in EAP is permissible. As Alan
suggested, the first step is probably to have a WG consensus
check to verify that we have rough consensus that this should
be permitted. After that, maybe we would ask the IESG for a
clarification of the applicability statement for EAP.

I will note that the IESG has already approved a change to the
EMU charter to add a work item for channel bindings. So they
have already indicated their support for that effort.

Thanks,

Steve

> -----Original Message-----
> From: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On 
> Behalf Of Dave Nelson
> Sent: Wednesday, August 12, 2009 9:33 AM
> To: emu at ietf.org
> Subject: Re: [Emu] EAP and authorization
> 
> Stephen Hanna writes...
> 
> > I suppose that my basic argument is a practical one. Password
> > change, channel bindings, and NEA assessments are useful things
> > to do during the EAP exchange.
> 
> That much I think most of us would agree with.  EAP is a 
> convenient protocol
> to use for exchanging that kind of information, even if it's 
> stretching the
> original purpose of EAP.  Remember, EAP was to be used during the
> authentication phase of PPP.
> 
> > They are relevant to the authentication process and the server's
> > decision about whether to grant network access. 
> 
> I really hate to have to agree with Glen's position on this, 
> but I do.  I
> firmly believe that you, and others, are conflating elements of
> authorization into the meaning of authentication.  
> Authentication is about
> proof of identity.  I can be authenticated as Dave Nelson, by 
> various means.
> I'm still Dave Nelson whether I'm a good guy or a bad guy.  
> If I'm a bad
> guy, you may not want to grant me access to your home.  If 
> I'm a good guy,
> but an active carrier for Swine Flue, you still may not want 
> to grant me
> access to your home.  In any case I'm still Dave Nelson, and 
> none of the
> other "access control" considerations affect my proof of 
> identity.  All
> those other considerations are authorization considerations, not
> authentication considerations.
> 
> I agree that using words clearly and with their exact meaning 
> is important.
> 
> However, it appears that the real point of this semantic 
> debate is whether
> the "domain of applicability" for EAP will admit the 
> introduction on very
> useful, but clearly non-authentication, data elements.  It's 
> quite possible
> for the WG to have consensus to do so and at the same time be 
> in apparent
> conflict with the "domain of applicability" for EAP.  Of 
> course, maybe the
> WG has within its charter the authority to revise the "domain of
> applicability" for EAP.
> 
> > There is no harm in doing them as part of the EAP exchange. 
> And there
> > is no better way to implement them. 
> 
> Assuming that's true -- and it may well be -- then EMU ought 
> to expand the
> definition of EAP to explicitly include authorization related 
> data, rather
> than making semantic, re-definitional, arguments that the 
> authorization data
> is really authentication data.
> 
> 
> _______________________________________________
> Emu mailing list
> Emu at ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>