Subject: ["John Brezak" <[email-masked]>] RE: [extensibility 3a] Explanation of issues arrising when you have multiple implementations sharing ccache

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

Good point.

------- Start of forwarded message -------
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [extensibility 3a] Explanation of issues arrising when you have multiple implementations sharing ccache
Date: Thu, 6 Dec 2001 09:19:18 -0800
Message-ID: <[email-masked]>
From: "John Brezak" <[email-masked]>
To: "Sam Hartman" <[email-masked]>

Something else to consider. With the duplicate contents in the messages,
there is going to be a good chance these will not successfully fit
though a single non-fragmented UDP datagram. The TCP transport should
now be required.

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]=20
Sent: Thursday, December 06, 2001 8:38 AM
To: [email-masked]
Subject: [extensibility 3a] Explanation of issues arrising when you have
multiple implementations sharing ccache

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.

------- End of forwarded message -------

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Dec 2001 14:04:20 -0600

> though a single non-fragmented UDP datagram. The TCP transport should

We have already seen this with W2K generatesd UDP tickets, and AFS packets. 
We had a intrusion detector which did not check the UDP fragmentation correctly 
and was flaging these. So it might be a mute point, as Tickets are already being
framented. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 12:50:14 -0800 (PST)

> and was flaging these. So it might be a mute point, as Tickets are already being

Er, am I the only one who thinks this is fixing
the wrong problem? Kerberos ticket/authenticator
sizes are large, and that's a problem unto itself,
irrespective of MTU sizes. This is especially true
if the credentials are being buried in another
protocol like, oh say, SIP which allows for UDP.

Since paring down the tickets and authenticators
by changing the protocol is a non-starter, maybe
we should instead look at 3des-sha1-gzip crypto
transforms, or something like that. My bet is that
compression would do a fine job on all of those
text names and crufty ASN.1 structures.
   
		Mike

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 06 Dec 2001 16:58:52 -0500

>Those "crufty ASN.1 structures" are actually pretty well encoded.  There's
>a fair bit of similarity between messages of the same type, but not much
>redundancy within a single message.  And while text compresses well in the
>general case, I doubt the principal names in a Kerberos message are going
>to see all that much improvement.

In my discussions with SNMP people, they always lament that Kerberos uses
explicit sequence tagging rather than implicit tagging, which they claim
makes the resulting encoding under DER significantly bigger.  I admit
I haven't done any comparisons, but I thought Tom had looked at it.
I also thought I remember Tom saying something about fixing that in
new message types, so maybe new messages will be smaller ... or maybe
it won't matter.

--Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 6 Dec 2001 16:51:08 -0500 (EST)

I think the real answer here is to accept that Kerberos PDU's, like the
messages used by some other authentication mechanisms (think X.509 cert),
may not fit in a single UDP datagram.  That means you have to either deal
with fragmented UDP, or require KDC's that support the extensible messages
to also support TCP.  Of course, I think we're probably seeing the problem
today, without extensible messages.  After all, the extensible message
formats add very little to the overall length of the PDU.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 17:18:25 -0500

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    Ken> In my discussions with SNMP people, they always lament that
    Ken> Kerberos uses explicit sequence tagging rather than implicit
    Ken> tagging, which they claim makes the resulting encoding under
    Ken> DER significantly bigger.  I admit I haven't done any
    Ken> comparisons, but I thought Tom had looked at it.  I also
    Ken> thought I remember Tom saying something about fixing that in
    Ken> new message types, so maybe new messages will be smaller
    Ken> ... or maybe it won't matter.

True.  We could even fix this now (and now is really the only chance
we're likely to ever get to fix it).  IT will take significant time
and will guarantee you can't use common parsing paths.  As John said,
likely to be a non-starter.

---

From: Sam Hartman <[email-masked]>
Date: 06 Dec 2001 17:30:06 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael>    I think I disagree, but the only proof here would be
    Michael> some empirical hacking. I mainly wanted to bring up the
    Michael> possibility that the problem was not being looked at from
    Michael> the right perspective, namely that Size Matters.

We've considered what it would take to change that.  It would involve
radical ASN.1 protocol changes; the new and old protocols would not
share parsing or generation paths.  We don't believe that people would
find that change acceptable.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 14:26:07 -0800 (PST)

> to see all that much improvement.

   I think I disagree, but the only proof here would
   be some empirical hacking. I mainly wanted to bring
   up the possibility that the problem was not being
   looked at from the right perspective, namely that
   Size Matters.

 > may not fit in a single UDP datagram.  

   Sure, this has always been a possibility. PKinit may
   make it more of a possibility. I think it's worth finding
   out whether mitigating the likelihood is effective. 
   Since Kerberos doesn't define the AP-REQ/REP
   interface, it's not as simple as saying "throw
   TCP at the problem".

	  Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 14:37:14 -0800 (PST)

> find that change acceptable.

   Sam, what I was thinking is gzip-before-encrypt which is
   just a cipher suite change, not an encoding change. I've
   been trying to find some time to hack on this to see if
   my intuition is correct.

		Mike

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 6 Dec 2001 18:44:53 -0500 (EST)

>    been trying to find some time to hack on this to see if

I think it's worthwhile to include in kerberos-revisions a requirement
that all KDC's support TCP for KDC-REQ/KDC-REP exchanges.

I also think it would be a reasonable to submit a separate draft descrbing
a compress-before-encrypt crypto system as a way to make messages smaller.

---

From: Francois Leclerc <[email-masked]>
Date: Fri, 07 Dec 2001 14:28:02 -0600

Hello,

I wish KRB v5 be stable to find interoperability around 3DES, 
PK drafts ... with minimal changes and various implementations.

I wish KRB v6 addresses
	.UTF8
	.AES
	.new requirements for extensibility.
	.possible incompatibilities in protocol.
a bit like LDAP v2 & v3, S/MIME v2 and v3 did.

Regards,
--FL