Kerberos Feature Request

[Henry B. Hotz]

At 11:05 AM -0500 2/11/04, Ken Hornstein wrote:
>  >Jeffrey Altman objects that I want an API, not an RFC, so IETF
>>shouldn't be involved, but I think the example I just gave would be
>>an RFC.  I'm trying to limit my care-about's though.  I just want a
>>general way to make use of the feature, which is currently pretty
>>inaccessible.
>
>I guess I don't understand why you need an RFC.  From a protocol
>standpoint (the main point of interest of the IETF), the work has, from
>my perspective, already been done.  How you transmit authorization data
>is completely defined within the protocol.  (And I will echo others:
>you should really read the clarifications document for the most current
>information on the handling of authorization data within the Kerberos
>protocol).

After being jumped on for mis-using the Microsoft term PAC when I 
meant the generic Kerberos term "authorization data" I went and 
RE-read the relevant sections of 1510 and the DRAFT clarifications 
(including the specific section of the latter that JA pointed at). 
As far as I can see there is nothing in them that addresses the KDC 
to (unspecified) authorization service interface that would be 
necessary in order for the KDC to acquire KDC-ISSUED authorization 
data.

If someone tells me that the IETF is interested and discussing the 
issue then I will join and participate as much as I can.  If some 
proposals that I'm writing now get funded then I will definitely join 
and might even lead the discussion if it still seems appropriate.

In the mean time I'm actually satisfied with JA's proposed callout as 
a solution to the issue I raised, and I agree that that solution is 
an "implementation issue" that does not call for a standard RFC.  The 
caveat is that it's not my solution unless multiple KDC 
implementations provide the same callout.

>Now, currently the authorization data is what you call "pretty
>inaccessible".  If you're speaking in terms of the GSSAPI, I would
>agree.  However, if you are using the MIT krb5 API, then I wouldn't
>agree, because you can get access to the authorization data on
>application servers via the MIT krb5 API (which is what you really
>care about from an application server perspective).  You can utilize
>this API feature no matter who's KDC you are using.

Doesn't the Kerberos FAQ recommend that you use GSSAPI in preference 
to the MIT API?  ;-)

>Now, it's true that currently an MIT KDC has no way of inserting
>authorization data into service tickets.  That, however, is purely an
>_implementation_ issue.  You could add such code today, and it wouldn't
>require a protocol change at all.  Where you get the authorization data
>from is completely up to you; the _protocol_ doesn't care, and the
>Kerberos RFC shouldn't require any modification.  This is, of course,
>assuming that I'm understanding what you're asking for.

I think I agree with you.  Note however that another possible 
solution would be a revision of RFC2307 that defines an LDAP place to 
put authorization data.

What wasn't perhaps clear is that my concerns are not with the 
protocol specifically, but with how an organization can implement 
single-sign-on authorization without being tied to a single vendor. 
A standardized relationship between Kerberos and LDAP for 
authorization data is probably how I have to solve the problem for 
JPL, but the audience I'm addressing needn't (and shouldn't and 
didn't) limit the solutions to that space.

As I said before I'm perfectly happy with a cross-KDC standard 
callout function.  It seems the fastest, simplest way to go.  I might 
also be happy with a new protocol for how a KDC might acquire 
authorization data, but no one (else) has suggested anything of that 
nature, yet.
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu