Subject: Ticket extensions in Kerberos revisions

From: Clifford Neuman <[email-masked]>
Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT)

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]

---

From: David Margrave <[email-masked]>
Date: Wed, 19 Apr 2000 18:03:12 -0700

I think the cows have already left the barn, so to speak, with regard to
proprietary extensions!  I can't imagine a scenario where ticket extensions
would do any more harm to interoperability than has already been done with
other things that are here to stay, say like proprietary authz-data or etypes
based on patented-protected cryptographic algorithms.  If anyone thinks I'm
wrong, feel free to straighten me out.

So speaking as a user, other than earlier krb implementations' ASN.1 code
puking on the extra member in the sequence, I wouldn't have any objections to
the ticket extension field.  It would be great to get this nailed down and
see working PK-CROSS implementations at some point.  If anyone has a concrete
example of an older implementation that croaks on ticket extensions, please
share it.

Dave

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 20 Apr 2000 16:04:41 -0400

Date: Tue, 18 Apr 2000 21:31:23 -0700 (PDT)
   From: Clifford Neuman <[email-masked]>

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

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 20 Apr 2000 13:16:47 -0700

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

---

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

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.  

-- 

 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: Ken Raeburn <[email-masked]>
Date: 25 Apr 2000 14:57:15 -0400

> breaking the crypto checksum on the ticket.  This causes some severe

If an ASN.1 implementation does something "insane" when parsing what
it might consider "corrupted" input, it's absolutely not suitable for
security software.  But that should be an implementation issue, not an
ASN.1 specification issue.

As far as interoperability goes, haven't we already lost in some ways
because of sender addresses becoming optional?  If an application
protocol using Kerberos doesn't specify the presence or absence of the
address (i.e., which version of Kerberos 5 protocol to use), the only
safe approach is to always include it -- and likewise, always omit
ticket extensions.

Most direct uses of Kerberos that I've seen don't have the flexibility
to try once with the new protocol rev, then if it fails, try again in
backwards-compatibility mode.  With GSSAPI or SASL applications it may
be possible, but that'd essentially be by treating new-Kerberos-5 and
old-Kerberos-5 as two different mechanisms under the same name.

> I'm not sure what else is actually safe to do.

Tom did this because a DCE server was adding extra stuff to a
sequence.  (I don't remember which sequence though.)
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Ken Hornstein <[email-masked]>
Date: Tue, 25 Apr 2000 15:44:57 -0400

>ASN.1 specification issue.

I have been thinking for a while that an interoperability report
w.r.t ticket extensions would be _really_ nice to see (then we could
determine what will really all break).

>old-Kerberos-5 as two different mechanisms under the same name.

Well, when I last stared at the MIT Kerberos GSSAPI mechanism, it
still uses the "old" mechanism OID
(iso.org.dod.internet.security.kerberosv5).  You could simply say that
"new" Kerberos is everything that uses the "new" mechanism OID
(iso.member-body.US.mit.infosys.gssapi.krb5).  You'd probably want
SPNEGO for that, though (and I'm not sure what happens when both
sides don't support SPNEGO).

--Ken