Subject: RE: Ticket extensions in Kerberos revisions

From: Matt Hur <[email-masked]>
Date: Thu, 20 Apr 2000 13:35:14 -0700

The only clients that may be affected are those that decode the ticket
rather than just stash the ticket from the KDC-REP.
There are many deployed, commercial clients that, without modification, will
pass on the ticket extensions.

We should not require changes to the client in order to use ticket
extensions.  A client could pass a tag to the KDC in the AS-REQ to indicate
that it supports ticket extensions.  The KDC could then make a decision
based on its policy (it could flag principals in the database that do not
support ticket extensions) and on the information in the AS-REQ.

--Matt

> -----Original Message-----
> From: Jonathan Trostle [mailto:[email-masked]]
> Sent: Thursday, April 20, 2000 1:17 PM
> To: Clifford Neuman; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Ticket extensions in Kerberos revisions
> 
> 
> One approach to backwards compatibility would be for clients 
> that support ticket extensions to indicate this to the KDC in 
> the AS_REQ message, by setting a bit in the kdc-options 
> field. KDC's would not use the ticket extensions field if the 
> client does not set the bit. The bit would cause a ticket 
> flag to be set, so this would allow pkcross to be used for 
> clients that support ticket extensions. I'm not sure if the 
> ticket flag in the TGT needs to carry into derived tickets.
> 
> If the KDC doesn't support the new kdc-options bit, it should 
> reply with error 13. If clients are upgraded before KDC's, 
> the cost is one extra round trip at logon time. So this 
> approach is optimal if KDC's are upgraded first. 
> 
> Jonathan
> 
> 
> At 09:31 PM 4/18/00 -0700, Clifford Neuman wrote:
> >One of the few remaining issues to be resolved before Kerberos
> >revisions goes to last call is the final disposition of the ticket
> >extensions field.  
> >
> >Such a field was not present in RFC1510, but it is present 
> in the current
> >draft Kerberos revisions.  Whether this field remains is a 
> contentious
> >issue.  The argument for the field are that it allows additional
> >information logically associated with the ticket to be 
> carried with the
> >ticket.  One example of such an extension is used in the 
> latest version of
> >the PK-CROSS protocol.  Another is the use of external 
> (integrity but not
> >confidentiality protected) authorization data.
> >
> >The arguments against such a field center on backwards 
> compatibility when
> >new fields are added in ASN.1 encodings of messages, and the 
> danger that
> >the field might be misused for extensions that detract from
> >interoperability across implementations.
> >
> >I would like to initiate discussion on the list in hopes of 
> bringing this
> >discussion to resolution.  This message is intended to 
> solicit discussion
> >on both sides of the issues.
> >
> >Clifford Neuman
> >-++**==--++**==--++**==--++**==--++**==--++**==--++**==
> >This message was posted through the Stanford campus mailing list
> >server.  If you wish to unsubscribe from this mailing list, send the
> >message body of "unsubscribe ietf-cat-wg" to 
> [email-masked]
> >
> 
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> This message was posted through the Stanford campus mailing list
> server.  If you wish to unsubscribe from this mailing list, send the
> message body of "unsubscribe ietf-cat-wg" to 
> [email-masked]
>