Subject: enctype negotiation and GSS naming extensions

From: Nicolas Williams <[email-masked]>
Date: Thu, 31 Mar 2005 12:05:54 -0600

At MN I said I did not oppose Larry's Kerberos enctype negotiation
proposal.

I'm less sure now.

You may recall that at the interim meeting at Boulder we decided that
extensions would add a typed hole, distinct from authorization-data, to
the authenticator and AP-REP.  We'd argued over whether it was proper to
overload authorization-data and decided that it was not.

Larry's proposal overloads authorization-data by using it to transport a
client's enctype proposal to the server.

I am still inclined to agree that enctype negotiation is an allowable
overloading of authorization-data, but the GSS-API naming extensions
we're discussing at the KITTEN WG give me pause.

Basically, whenever we add an authorization-data type that isn't really
about authorization then all things that might interpret
authorization-data need to know what to make of them.

At the very least non-authorization AD types must be non-critical (i.e.,
must be in AD-IF-RELEVANT AD containers).  That's clear and surely we
all agree on that point.

But if there's a generic API to get at the authorization-data from an
authenticator or ticket, then how do we ensure that non-authorization-
related AD elements aren't passed to the application, particularly when
the API and the application both need to be able to deal with unknown AD
types?  Or is this not an issue?  That is, apps that make use of such
extended naming APIs should just ignore unknown, non-critical name
attributes?

And how would we design enctype negotiation if we could start with
extended Kerberos V, rather than rfc1510/clarifications Kerberos V?

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 31 Mar 2005 20:44:46 +0200

> extended naming APIs should just ignore unknown, non-critical name

Isn't that a reasonable interpretation of 'non-critical'; "If you don't
understand this you can safely ignore it" - completely analogous to the
way criticality is defined in X.509 extensions.

Any API would have to expose the 'criticality-bit'.

	MVH leifj

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 31 Mar 2005 13:53:56 -0600

> way criticality is defined in X.509 extensions.

I think it's certainly reasonable in a monolithic system.

> Any API would have to expose the 'criticality-bit'.

Yes.