Subject: [extensibility 3a] Explanation of issues arrising when you have multiple implementations sharing ccache

From: Sam Hartman <[email-masked]>
Date: Thu, 6 Dec 2001 11:37:37 -0500 (EST)

The problem is that if you use the new AS-REQ request type you get a
different tagged ASN.1 structure back (ticket2) instead of the current
ticket1.  Old clients probably don't know what to do with a ticket2.
In principle a client may actually just treat the ticket encoding as a
blob, so for some implementations even old clients may be able to use
ticket2.  We don't believe the MIT client is such an implementation; I
think our certainty is high, but we have not yet looked at code to
confirm.

Why might you have an old and new MIT implementation on the same
machine?  Well, if you can get away with it you probably want Mac OS9
to remain an old implementation.  You might be running the Kerberos
that comes with Oracle, or the one used internally by Java.  You might
have static binaries.

So you want your new implementation to make it possible for your old
implementation to work.  There are two ways of doing this.  First,
your new implementation could send a request to get an old and new
style TGT using the same password.  It could store both.  The other
option is to allow a client to convert a ticket2 into a ticket1.

---

From: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 12:57:22 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> If MIT krb5 -current stores tickets' enc parts +
    Nicolas> sname/srealm + session key in the ccaches, how can new
    Nicolas> tickets break the current use of ccaches, other than wrt
    Nicolas> UTF-8 sname/srealms?

ticket extensions?  Other fields added to ticket?  The checksum of the
ticket?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 Dec 2001 12:52:46 -0500

If MIT krb5 -current stores tickets' enc parts + sname/srealm + session
key in the ccaches, how can new tickets break the current use of
ccaches, other than wrt UTF-8 sname/srealms?

Nico

--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.