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-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
> Behalf Of Dave Nelson
> Sent: Wednesday, August 12, 2009 9:33 AM
> To: emu@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@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
