[467] in Kerberos
Re: New Kerberos ticket proposal
daemon@TELECOM.MIT.EDU (Steve Miller)
Thu Jul 28 18:53:28 1988
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
Re: Ted Anderson's questions and proposal-
I am quite pleased to see this interest in the evolution of Kerberos.
Steve
-------------------------------------------------------------------
...text deleted...
>First several questions.
>
>The purpose of the kvno is not explained. The paper uses kvno as a subscript
>on keys which are used for encrypting tickets. From this, and some later
>discussion about changing master passwords, I gather it serves to distinguish
>between tickets encrypted with an old password and those encrypted with the new
>password. Is this right? Is this the only use envisioned for this field?
Yes, it is for orderly transition when keys change. If a principal changes
its key, as it should do routinely, there will be tickets outstanding with
both the old and the new keys. The tickets with the old keys would
otherwise be valid until they expire, so if the server (receiver really)
isn't worried about having compromised its old key, it can honor either
the old or the new for some period of time, after which all tickets should
have the new key.
>What is the flags field used for? I found one place in the Kerberos document
>revision history that suggested it was used to specify the byte order of the
>ticket granter. Is this still true? Are any of the other bits used for
>anything?
It is used to define byte ordering of multi-octet integer fields that appear
in a few places in different protocol messages. I don't think any of
the other bits were used.
>The current definition appears to allow for a zero length principal name. Is
>this intentional or useful?
Probably an accident. Don't think it is particularly useful.
>What is the purpose of including the server's name/instance in the ticket?
>These are potentially lengthy strings which could contribute significantly to
>the encryption/decryption time and contain very minimal information. Surely a
>server with the correct key would know its own name. The only thing I can
>think of that that it would provide a final check against a ticket that had
>been tampered with. It seems an expensive way of accomplishing this. Am I
>missing something?
We went around on this a few times. It serves two purposes, each of which
could be served better. The first is that it disambiguates the ticket if
different instances of a principal or even entirely different principals use
the same key. Otherwise a ticket for one principal could be used for a
different one. Second, given the modified cbc crypto mode used, and its
position at the tail of the ticket, it guarantees that any modifications to
the ticket will be detected, resulting in invalid server name, instance.
... deleted text...
>Here is an alternative ticket proposal:
I don't have the time to go through the proposal in detail right now,
but will offer some generic suggestions.
>I propose limiting principal names to upper and lower case letters, digits,
>underscore, apostrophe, and hyphen. The length must be between 1 and 63
>characters plus a trailing null...
> ...(text deleted)
Conventions on the principal et al. names are a good idea. I don't have
any idea what the right conventions are.
>I suggest using network byte order for constructing tickets and that the bits
>of the flags field be reserved for future use and set to zero by current
>implementations...
> (text deleted)
While this is probably a good idea in theory, if it ain't broke, don't fix
it. At this point in time, what does it buy?
>I suggest that kvno be used by the server to identify the key needed to decrypt
>a ticket.
>... (text deleted)...
This is already the case, at least in the protocol design. I thought the
interfaces already support this.
>The use of both a start time and end time provides the most flexible means for
>controlling ticket lifetimes.
> ... text deleted...
There are two questions here: what is the maximum ticket lifetime, and
how is it encoded. First, the easy question about encoding -- use the
densest encoding possible to minimize the size of the encrypted data. So that
probably points to using a start time plus offset encoding. Second, the
hard question, is what should the architected maximum lifetime be? My views
on this were and still are that it needs to be reasonably bounded, otherwise
the whole authentication serves no purpose. I would also point out that the
people who have found the current lifetime too short have gone beyond the
original design goal and tied the authentication lifetime exactly to the
authorization lifetime, e.g. files service access. Not to belabor the point,
if there is pressure to extend the field, extend it, but not by too much.
>From a cryptographic standpoint, putting the most random part of the ticket at
>the beginning makes attempts to decrypt it more difficult because of the use of
>cipher-block-chaining during encryption.
>... text deleted...
First, we never worried about cryptanalysis, but we were concerned about
detecting active modification attacks. The layout of the ticket was not
arbitrary, but planned to put values at the end that would detect modification.
This interacted well with the modified cbc mode, in that if a single bit
was modified anywhere in the ticket, about 50% of the bits in the last block,
containing the server name and instance, would change. A similar effect can
be achieved by including a known constant at the end of the cleartext, but
it is not necesary because there are enough other fields that would almost
certainly cause problems if modified.
>This ticket proposal eliminates the name and instance of the server from the
>ticket. This should provide a substantial reduction in the length, and
>corresponding encryption and decryption times, of tickets.
> ... text deleted...
This is a good direction to pursue, but I would not eliminate it entirely,
rather use a condensed signature function of it instead. This signature
could even be used on the principal name, moving the actual name into the
cleartext part of the ticket. Of course, a signature will sacrifice some
security since multiple inputs will produce the same signature. Unfortunately,
the good signatures -- crypto MACs, require the same amount of
computation as encrypting the whole thing. The quad_cksum (signature)
in Kerberos is computationally inexpensive, though probably
not terribly secure. I had proposed an alternative protocol along these lines
when we were first starting to use Kerberos.
>Using the server's name and instance as the ticket's label is also
>questionable. To detect decryption errors I suggest, in addition to
>reasonability checks on all the fields in the ticket, padding the end with a
>constant string.
>... text deleted ...
If you look at the properties of DES in the CBC mode, a single bit error
anywhere will cause about 50% of all the subsequent bits to change. So
if the ticket ends with a value that has a small valid range, you will
have a very good integrity check. So for the purposes of Kerberos, I don't
think anything else is necessary.
Steve.
