Kerberos Feature Request

[Jeffrey Altman]

Henry B. Hotz wrote:

> 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.

Please see Clarifications Section 5.2.6.


>> 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 field is the place where you insert authorization data.  The 
contents of a specific authorization data type must be specified outside 
the Kerberos 5 Protocol Specification and be issued a registered 
auth-data type value.  Or the implementation can choose to not register 
the format and use a negative value for the auth-data type (this 
utilizes the private use name space.)

> 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.

The authorization data field is used both by DCE and Windows.

> 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.


How the KDC obtains authorization data from an external authorization 
service is outside the scope of the Kerberos protoocol.  What you are 
asking for is the specification of an API not a protocol.  APIs are 
outside the scope of an IETF working group in almost all cases.  The API 
you are looking for would be specified by the authorization service; not 
the KDC.  What the KDC has to implement is a hook:

    krb5kdc_get_authorization_data(krb5_context, principal_name, 
krb5_data *)

which allows a third party to define an implementation of the 
authorization data retrieval protocol specified by the authorization 
service.

Jeffrey Altman