Kerberos Feature Request

[Nicolas Williams]

On Thu, Feb 12, 2004 at 11:01:32AM +0100, Daniel Kouril wrote:
> On Wed, Feb 11, 2004 at 12:49:37PM -0500, Derek Atkins wrote:
> > > I'm not sure if I'm not missing something but could you tell me why
> > > KDC should do that? If I'm not mistaken, the user can put into the
> > > AS-REQ message any authorization data she wants and the KDC just copy
> > > them to the ticket, am I right? If so, then the client can propagate
> > > to the ticket all authorization data she needs without any
> > > intervention of KDC. I think this is very useful solution in a world
> > > of multiple authorization mechanisms, which can use very different
> > > formats of representations of the authorization attributes. It also
> > > allows users to build authorization data according their current needs.
> > 
> > Cool, I can assert "this user is god and should have full access to
> > all services" into the PAC data and the KDC will just pass it along..
> 
> What's wrong here? I don't think that any reasnable end application would
> accept such an assesrtion (which is not certified by an AuthZ service)

Right.  See AD-KDC-ISSUED.  Clarifications already has the relevant
text, so there's no issue here.

BTW, client-asserted authz-data can be useful -- think of proxied/
forwarded tickets, and think of the authz-data field in the
authenticator.

> > Seriously, there needs to be an "Authorization Service" (AuthN) that
> > sits along-side the "Authentication Service" (AuthZ).  I'm not saying
> > whether or not these services are combined or separate, but the AuthZ
> > service needs to be just as secure as the AuthN service.  You can't
> > just ask the user to present the AuthZ data to the KDC to be signed.

Right, but we don't need to argue this since we've already addressed
this through the AD-KDC-ISSUED authz-data container (and if there are
additional concerns or if additional PK signatures are desired then we
can always extend the AD-KDC-ISSUED model).

> I don't want the AuthZ data to be signed by the KDC. I think the KDC should
> just passed on the data, which is already "signed" by an independent AuthZ
> service (e.g. in the form of an attribute certificate) and sent to the KDC
> by the client. I don't like mixing of AuthN and AuthZ mechs, you can't
> expect your KDC will know every AuthZ services used by the user.

The KDC has to indicate that it added a given authz-data element and it
must prove it.  That's what the AD-KDC-ISSUED authz-data container is
all about.

Nico
--