Subject: RE: Ticket extensions in Kerberos revisions

From: Matt Hur <[email-masked]>
Date: Tue, 25 Apr 2000 12:02:53 -0700

Doug,

You would do this by putting the X.509 extension into a ticket extension.
The ticket extension could be bound via a checksum in the authorization
field.

--Matt

> -----Original Message-----
> From: Douglas E. Engert [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2000 11:10 AM
> To: Theodore Y. Ts'o
> Cc: Clifford Neuman; [email-masked];
> [email-masked]
> Subject: Re: Ticket extensions in Kerberos revisions
> 
> 
> Ted,
> 
> Your comments below on the ASN.1 and X.509 extensions brings 
> up an interesting 
> question. What would it take to allow a Kerberos ticket to 
> have a copy of
> some x.509 extension? There might be some situations where 
> you might want 
> to have PK_INIT copy an extension, to the TGT or if you used 
> a Kerberos 
> ticket to get a certificate to copy the extension from the 
> ticket to the 
> certificate. Or possibly even with PK_INIT coping the 
> certificate chain 
> to the ticket. 
> 
> This might allow the authorization data to be transfered from 
> a certificate
> to a ticket.  
> 
> "Theodore Y. Ts'o" wrote:
> > 
> >    Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT)
> >    From: Clifford Neuman <[email-masked]>
> > 
> >    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 problem is the extensions which are placed in the 
> unencrypted part
> > of the ticket.  If I recall correctly, ASN.1 makes no 
> guarantees that
> > implementations which see unexpected fields will do 
> anything sane, and
> > in fact the best you can hope for is that implementations 
> will ignore
> > that which they do not understand.  The problem is that 
> when they then
> > re-encode the ticket, the new extended fields will get dropped, thus
> > breaking the crypto checksum on the ticket.  This causes some severe
> > interoperability issues.
> > 
> > If we had added type-length-value array from the beginning to handle
> > extensions, ala X.509, we would have been OK.  
> Unfortunately, we weren't
> > far-sighted enough to do this.  As a result, I don't think 
> we can put an
> > unencrpyted extension.
> > 
> > I think that recent MIT Krb5 implementations (although 
> someone from MIT
> > should check me on this) have been modified to not give a 
> parse failure
> > if they see an unknown/unexpected SEQUENCE OF element.  
> This means that
> > putting a new extended element inside the encrypted part of 
> the ticket
> > is far safer.  I understand this doesn't fully meet the 
> needs of some of
> > the uses for which you wanted to use the ticket extensions 
> field; but
> > I'm not sure what else is actually safe to do.
> > 
> > I believe ASN.1 has some special tag words that indicate 
> how unexpected
> > fields should be handled; I don't know if they existed in the older
> > versions of ASN.1, and we didn't use those keywords anyway.
> > 
> > As I've said before, "Friends don't let friends use ASN.1".   :-)
> > 
> >                                                 - Ted
> 
> -- 
> 
>  Douglas E. Engert  <[email-masked]>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439 
>  (630) 252-5444
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> 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]
>

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 25 Apr 2000 15:28:02 -0500

> Matt Hur wrote:
> 
> Doug,
> 
> You would do this by putting the X.509 extension into a ticket extension.  The ticket extension
> could be bound via a checksum in the authorization field.

The question was can current K5 implementations handle the ASN.1 used in X.509,
other then the UDP size problems. 

-- 

message body of "unsubscribe ietf-cat-wg" to [email-masked]