[532] in Kerberos
A collection of suggested changes to Kerberos.
daemon@TELECOM.MIT.EDU (Bill Sommerfeld)
Wed Nov 23 15:31:52 1988
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kerberos@ATHENA.MIT.EDU
On November 16th, there was a meeting in Apollo's headquarters in
Chelmsford of representatives of several sites, to discuss concerns
with the existing Kerberos protocol and implementation, and to suggest
changes which should be made and areas where further development is
necessary. This was intended as a preliminary meeting; as yet, there
is no committment from athena to include any or all of the suggested
changes, or address any of these issues, in a future release of
Kerberos.
[A number of discussions of some of these issues since the meeting
have uncovered problems with some of the suggested changes; comments
of this nature are enclosed in square brackets]
The following people attended:
John Kohl (MIT Athena/DEC) <jtkohl@athena.mit.edu>
Jennifer Steiner (MIT Athena) <steiner@athena.mit.edu>
Bill Sommerfeld (MIT Athena/Apollo) <wesommer@athena.mit.edu>
Joe Pato (Apollo) <pato@apollo.com>
Paul Leach (Apollo) <pjl@apollo.com>
Mike Kazar (CMU/ITC) <kazar+@andrew.cmu.edu>
Ted Anderson (CMU/ITC) <ota+@andrew.cmu.edu>
Todd Smith (IBM Austin) (no address available at this time).
Alex Rauous (UMich/CAEN) <rauous@caen.engin.umich.edu>
Paul Anderson (UMich/CAEN) <pha@caen.engin.umich.edu>
A large number of suggested changes were discussed. Some of these
changes are simple technical improvements (i.e., "hardening" the
ticket format better against tampering), while others represent
attempts to make Kerberos (both protocol and implementation) more
flexible and policy-free, which was viewed as necessary for acceptance
outside Athena. Many of these changes, if utilized by a site,
conceivably reduce security, but it was felt that the existing
Kerberos was too constrained and restrictive for acceptance (most
notably in the area of ticket lifetimes).
Issues for change were separated into "short term" and "long term".
Short term was defined as things which were practical to add in a
month or two of development (CMU and others want this in the next
release), while long term issues were things which had to be addressed
to get things right eventually.
It was felt that it would be a waste of effort to make several
incremental protocol changes, so it was agreed that any issue which
required a protocol change wasn't a short term issue. Ticket lifetime
was felt to be so important that it was suggested that it be finessed
in the short term by changing the interpretation of the lifetime
field, and fixed in the long term by expanding the field size.
Short term:
It should be noted that most of the short-term issues are really
clarifications.
1) Ticket Lifetime (Temporary Hack).
Consensus was that 5 * 255 minutes was too short a maximum lifetime
for tickets. CMU/ITC has promised their user community lifetimes of
at least 72 hours; they have to deliver this in a matter of months.
Currently, lifetime is encoded as a single byte which is [or was]
treated as signed (-128..127) in some parts of the code; fortunately,
only values up to 96 (8 hours) are actually in use at Athena. . The
proposal is to keep the meaning of the values 0 to 0x7f, while using a
lookup table for the values from 0x80 to 0xbf; the lookup table would
contain values exponentially distributed between 5*128 minutes and 30
days. In addition, a lifetime of 0xff would be "infinite". Mike
Kazar has already computed the table and sent it to the attendees of
the meeting.
It was felt that the default lifetime should be configurable on a
per-site basis; CMU would likely use 25 hours as its default (for
backwards compatibility). In the short term, making it configurable
at compile time would probably be OK.
2) Bounded name lengths.
The protocol does not define maximum name lengths; instead, all
character strings are null-terminated. However, the current
implementation does impose limits (40 characters per name component)
which are pervasive in the implementation and not well documented.
A realm size of 40 characters was not considered long enough, since
domain names can be up to 255 characters+1 null long. Since domain
names can also show up in server names, it was proposed that the
principal and instance parts of the name combined take up at most 254
characters+2 nulls.
This does impact binary compatibility between old object files and new
libraries.
3) Realm naming conventions.
We quickly agreed that, by convention, realm names should correspond
to internet domain names. We then discussed case correctness issues
(i.e, case insensitive vs. case sensitive). In the past, Apollo has
been beaten up fairly badly for being non-unix-like by having
case-insensitive file names, and recently changed its OS to be fully
case sensitive; as a result of this horror story, it was felt that it
would be better for Kerberos to avoid this can of worms by being case
senstitive.
We then agreed that by convention, realm names should all be in one
case; in the absence of convincing arguments on either side, we
flipped a coin about whether it should be upper case or lower case.
MIT won the toss and elected to use upper case (for backwards
compatibility reasons).
4) RPC interface for Administrative protocol.
Ted Anderson showed a proposed RPC interface to the "edit" side of the
authentication server [which was essentially identical to one we were
kicking around at MIT, with the exception that it lacked certain
operations which were idiosyncratic to the way user registration works
at Athena]. It was found to be mostly OK, with a few minor changes
which Ted agreed to. He will likely post the improved spec to the
Kerberos mailing list for further comments.
Joe Pato requested that the interface be general enough to allow the
interface to be used in the presence of a complex authorization model.
The specific examples he cited included allowing KDC implementations
which allowed mutually suspicious account administrators sharing one
KDC, (it is assumed that they all trust whoever runs the KDC), and
having accounts which were locked out of being able to change their
own password. It should be noted that this is not a request for
requiring this in the KDC code shipped by Athena; all this appears to
require is that the administrative calls be able to fail gracefully
with a "permission denied" message.
It was agreed that Sun RPC was not appropriate to use for the
administrative protocol, as it does not provide at-most-once
semantics. Either CMU's RX or Apollo's NCS could be used; sentiment
appeared to be split between the two (MIT and CMU seemed to be in
favor of RX since it may be in the public domain shortly, apollo and
UMich in favor of NCS; IBM has both, so it could use either).
5) No new byte orders in existing protocol.
CMU wanted an assurance that there won't be a new byte order flag for
twisted byte order machines (non-big, non-little endian).
6) Specification of exactly what characters are legal in
authentication names.
Ted wants this to be nailed down; there wasn't any discussion of the
exact answer.
[It might be offensive to Europeans with accents in their names to
limit the legal characters to 7-bit ASCII; anyone got an ISO Latin 1
chart?]
Long term:
1) Protocol changes.
There are a number of proposed protocol changes which, when taken
together, seem to result in smaller tickets on average, implying less
encryption overhead.
1.1) Use of network byte order for integer formats.
Ted Anderson seemed to think that "reciever makes it right"
complicated programming more than converting to a canonical byte
order.. essentially, the programming environment already has "ntohl"
and "htonl" and similar functions, while there isn't a generic "swap
longword" or "swap short".
1.2) Use of checksum instead of depending on pcbc encryption.
It was determined (experimentally) that PCBC encryption does not
protect against swapped cyphertext blocks. It was suggested that a
checksum (probably something like a 32 bit CRC) be added to the
ticket to make it "safe" against tampering.
Todd Smith suggested checksumming the cyphertext and then encrypting
the checksum.
1.3) Ticket Lifetime, done right.
Instead of an issue date and a duration, explicit issue and expiration
timestamps. [The exact format of the timestamps was not discussed;
either UNIX format or Internet standard time format might be
appropriate.]
1.4) Post-dated tickets.
CMU requested this; it is wanted so that you can run batch jobs in an
authenticated environment, and not have the authentication start
before the batch job does. [There may be a policy issue of how far in
the future you can post-date the tickets]. In the presence of
arbitrarily long lifetime tickets, it should be noted that if this
feature was not provided, users would just make the tickets live long
enough, reducing security.
1.5) Order of fields in tickets.
In order to prevent known-plaintext attacks, it was thought that the
ticket should start with the session key, which is essentially random
data; this makes life somewhat harder on the attacker.
1.6) IP address in tickets
It was pointed out that the current use of including an IP address in
the ticket doesn't work in the presence of multi-homed hosts. This
doesn't affect things at athena, but elsewhere, there tend to be
clients used as multi-homed hosts.
In addition, in the presence of multiple address families, it doesn't
make sense to only check IP addresses. A proposal was made which
would be to replace the current IP address with a variable number of
variable-length addresses, tagged with an address family, and to allow
several to coexist in a packet. This was felt to be too complex.
It was then pointed out that having the network address in the packet
doesn't provide a _significant_ amount of security in an internetwork,
or even just on a single ethernet, and it was felt that it would be
better to just remove the address.
1.7) Discourage dictionary attacks.
Only the session key, not the ticket, should be encrypted in the key
(either the person's full key or the TGT session key) used to get the
ticket.
[Jeff Schiller pointed out that this does not absolutely prevent
dictionary attacks in the case where the attacker is registered with
the realm or any realm which interoperates with the target realm; he
also asserted that preventing dictionary attacks is very hard to do in
the general case, and that this change weakens security in other ways]
1.8) Remove service name and instance from the ticket.
The presence of the service name and instance in the ticket does not
provide any significant redundancy that a checksum wouldn't provide.
It would be more efficient to include a (say) 32-bit CRC, which can be
computed very quickly, than to encrypt the ~10-15 bytes needed to
include the server name.
1.9) merging principal and instance fields into one field.
Under this proposal, the new names would look like "name@realm"; for
server names, the "name" part would be "service.machinename" or
whatever convention the service decided on.
It was thought that there aren't enough semantics attached to
instances to make a difference between having separate name,instance
fields and having the two fields attached to each other using a naming
convention (name.instance). It is currently not thought to be clean
to make access checks on a "*.instance" or "name.*" basis, so the
structure doesn't really help there either. The confusion of
authentication and authorization in names has been a source of
confusion in the past; perhaps it might be possible to end the common
confusion that certain instances are somehow "special" by getting rid
of them and making it explicit that it is merely a naming convention.
In addition, it was thought that the name,instance separation appeared
to be an attempt to impose a fixed structure on the concept of a "user
identity" which is really open-ended; for example (using an example
proposed by Todd Smith), the "user identity" in a secure system
typically includes a bunch of other things besides the name (like
security level and category codes), and that rather than trying to
extend the naming scheme to include them, it might be more
appropriate to simplify it and allow different systems to use that
information as a hint as to which identity the user wanted to
assume.
Also, there should be a simple "one word" syntax for Kerberos names;
the currently used convention (user.instance@realm) conflicts with
systems which want to have `.' characters in usernames (for example,
apollo's registry uses a "name.group.organization" naming syntax).
[After the meeting Jon Rochlis pointed out that instances were
intended to be generated on the fly by users, so that they could (for
example) come up with a less- or differently-privileged version of
their identity.]
1.10) support for multiple encryption algorithms (perpendicular to
protocol versions).
John Kohl pointed out that certain countries (Australia) didn't allow
the _import_ of DES, so other encryption algorithms would have to be
used there instead; Mike Kazar mumbled something about ISO probably
coming up with an encryption standard which was subtly different from
DES.
1.11) Use different keys in each direction for interrealm access.
Instead of the same key being used for both directions of an intercell
ticket exchange, it was though that it might be better to allow
different keys in each direction.
(This followed a discussion about automatically changing server keys;
see the "new functionality section for details.)
This allows you to set up inter-realm trust unidirectionally.
1.12) Having the null realm in a ticket imply local realm.
Ted Anderson suggested a "normal case optimization", which was that,
in the case where the client realm and server realm were the same, the
client realm should be replaced with the null string; this will
typically shave about 15 bytes (about two DES cypher blocks) out of
the ticket, saving a noticeable amount of time in encryption.
2) Library interface
2.1) RPC interface for ticket granting protocol.
This was suggested but not really accepted by the people present; it
was thought that it might not offer much over a normal UDP message
exchange, and adds significant complexity to low-end clients (i.e.,
PC's).
2.2) Replaceable ticket cache code.
There was general dissatisfaction with the use of a file in /tmp to
store tickets. CMU is planning to implement code which will keep
tickets in the kernel; vendors of diskless machines will likely want
to do something special to keep the tickets off the wire.
2.3) export interface to just get ticket (not authenticator).
CMU wants to do its own flavor of authenticators (using a
challenge-response mechanism rather than synchonized clocks) because
it makes replay detection easier. There's not really an official
interface for just getting the ticket.
2.4) OS Independant layer.
Todd Smith and Alex Ranous both reported difficulties getting the code
to run on System V. In addition, apollo wants to use the code with
NCS, which is currently portable to MS-DOS and VMS in addition to
several UNIX variants.
It was felt that it might be appropriate to define an OS-independant
layer which the Kerberos code is layered on top of; the Kerberos
library itself could then be written to make very few assumptions
about what it was running on top of.
3) Implementation.
3.1) Master/slave issue of scaling.
There were two aspects to scaling:
a) what do you do for very large realms (100k+ workstations/users)?
UMich doesn't think it will scale to 20k workstations, particularly
for bulk updates at the start of the term; Joe Pato (from experience
at apollo) and Bill Sommerfeld (from experience with kerberos/SMS; SMS
is the real bottleneck) dispute this.
b) how do you avoid the n-squared "introductions" problem for large
numbers of realms?
One idea mentioned briefly was to have a "realm of realms" to allow
administrators to only have to manually exchange one key with this
centralized service. This was deferred as being something a research
issue, and also as a problem which will only show up if Kerberos "wins
big".
3.2) Use some simple distributed database technology.
CMU doesn't like the answer of "change your password and wait an hour
for it to propagate to all slaves". Both CMU and Apollo have some
replicated database technology which lets them reliably run replicated
servers.
3.3) Better random number generator.
.. perhaps using DES encryption.
3.4) Make sure library can deal with multiple outstanding key
versions gracefully.
4) Misc:
4.1) Setting up interrealm communications was documented poorly.
Todd Smith and Alex Ranous both said that it could be better
documented. It may also be useful to have a program/protocol which
could be used to help administrators exchange the shared secrets
necessary.
In addition, tools for automatically changing inter-realm keys (once a
pair of keys was set up) were desired.
4.2) Validation suite for kerberos library
IBM wanted this; checking things like maximum length usernames, etc.
4.3) Better validation suite for DES library
This should be automatic, not manual as it is now.
4.4) Cleanup so it builds on SysV.
(this means makefile cleanups and filenames < 14 characters, including
removing #include <mit-copyright.h> everwhere, because it's 15 chars).
4.5) String_to_key stuff.
It was felt that the string_to_key algorithm should be "seeded" by the
realm name so that if someone uses the same password in two realms,
disclosure of one realm's key doesn't compromise the user in the other
realm.
For backwards compatibility with old databases (both MIT and CMU have
_large_ databases already) it was felt that it might be appropriate to
tag kerberos database entries with the version of the string_to_key
algorithm which was used to produce the key, and include that in the
reply to an initial ticket request.
5) New functionality
5.1) admin protocol for setting up srvtabs.
A need was expressed for a program an administrator can run on a "new"
server to extract the srvtab securely.
5.2) protocol for getting realm given server.
A need was expressed for a common mechanism for securely finding out
the realm, or possibly even the entire name, of a server given just
its network name or address. Just taking the server's word for it is
not sufficient.
To a certain extent, this is application protocol specific, but
experience with systems applications using Kerberos (for example, the
Brunhoff RFS or the rlogin/rsh suite) shows that it's hard for
applications writers to get right, which implies that support for this
in the Kerberos library may be appropriate.
5.3) better support for converting authentication names to local names.
Right now, the support routine is a stub (it only maps
"user@local-realm" into "user"). The problem has also been dismissed
as an applications protocol issue, but it is clear that better
interoperation between realms requires a standard way to do this.
This is also essentially operating-systems dependant, but it was
thought that "doing it right for UNIX" might be enough for a starter.
5.4) tools to automatically change service, interrealm keys.
There was demand for tools to periodically generate and install new
versions of server keys; having this done without manual intervention
was felt to increase security.
5.5) Replay checking.
The document makes reference to support necessary to handle full
replay checking; this was never implemented.
It was felt that really high volume servers (Kazar mentioned AFS
servers doing 30 transactions/second as an example) might have to use
a large amount of memory to retain the state necessary to do full
replay detection; Mike suggested, and others agreed, that some systems
would want to use a challenge-response style protocol so that they
could avoid having to keep replay information if the server could
guarantee that each challenge would be unique.
---
This is not intended to be a completely exhaustive list of issues with
the current kerberos protocol or implementation; instead, it is hoped
that this will provoke discussion about the future of kerberos.
Bill Sommerfeld
John Kohl
Jennifer Steiner
