Kerberos Feature Request

[Henry B. Hotz]

At 3:34 PM -0500 2/10/04, Jeffrey Altman wrote:
>I agree that there should be an optional way of adding arbitrary 
>authorization data to Kerberos tickets. 
>I agree with Sam that this is not something that should be 
>standardized by the IETF because it is outside the realm of a 
>protocol definition.  The Kerberos 5 standard already describes how 
>authorization is placed within a ticket.

Where does it describe that?

I see stuff in the RFCs about how to forward the data and how to add 
to it, but nothing about how the KDC should/might put a mandatory 
initial set of stuff in it.

>Authorization data is often highly site specific.  The MIT (and 
>other KDC implementations) could support (they do not at present) a 
>plug-in architecture allowing an authorization system to feed an 
>opaque blob of data for inclusion in the ticket.  The contents of 
>this opaque blob would not be known to the KDC nor to the Kerberos 
>client.  Just as the Microsoft PAC is unknown to both.  All that is 
>required is that there be an interface allowing the blob to be 
>inserted to a ticket when issued and extracted from the ticket when 
>received by the service.

I'm not asking for standardization of the content of the 
authorization data field, just for how the KDC gets/inserts that 
(opaque) data into the initial ticket.  As a practical matter it may 
be difficult to do that across platforms, but that is a different 
issue.  It may also be difficult to do across KDC implementations, 
but that's still a different issue.  It's not impossible and it's 
useful.  I think that's the issue.

As things stand in 1510 the field is just a "someday we'll think 
about it".  Absent any way to access the field like I'm asking, my 
opinion is that the clarifications should have deprecated the field 
altogether.  Just my opinion.

The authorization data field *is* being used (by Microsoft if nobody 
else).  Given it's being used, MIT is deciding how easy or hard it is 
for people to use the field with their code base, and gaining or 
loosing customers as a result.

Speaking for myself, this feature is not yet important.  However I 
may need to add it to the list of core code patches necessary if I am 
to use the MIT code base in the future.
-- 
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