[533] in Kerberos
Re: A collection of suggested changes to Kerberos.
daemon@TELECOM.MIT.EDU (Kevin Fall)
Mon Nov 28 05:04:38 1988
From: kfall@OKEEFFE.BERKELEY.EDU (Kevin Fall)
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: Your message of Wed, 23 Nov 88 16:24:09 EDT.
> To: kerberos@ATHENA.MIT.EDU
> From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
> Subject: A collection of suggested changes to Kerberos.
> Date: Wed, 23 Nov 88 16:24:09 EDT
>
>
> 1) Ticket Lifetime (Temporary Hack).
>
It was pointed out by someone here that an appropriate place
to require re-authentication would be from 'screensaver'
type programs, which lock up your terminal after
some predetermined idle period. When you provide your
password on your return, this will re-establish your tickets.
I am somewhat concerned about the use of 'infinite' ticket
lifetimes. It seems to me self-defeating to even provide
for such a facility. If it is truly determined to be necessary,
however, it would be nice to have an option to ignore
infinite tickets (e.g. compile-time option).
I agree with the long term suggestion that explicit issue
and expiration timespamps are the right way to go.
Are there really any convincing arguments to use the UNIX
time encoding over the "Internet Standard Time" convention?
> 3) Realm naming conventions.
>
> We quickly agreed that, by convention, realm names should correspond
> to internet domain names.
This does seem the obvious conclusion to jump to, but as mentioned
below, there is already a problem with internet addresses restricting
Kerberos to a particular address family (not to mention the
multi-homed host problem). I think it is probably a mistake
to latch on to the internet naming conventions merely for
convenience. There are many installations with multi-address
family hosts (here we have Datakit, NS, and Internet).
> it would be better for Kerberos to avoid this can of worms by being case
> senstitive.
>
It is not suprising that Apollo would get abused for not being
case-sensitive for FILE NAMES. What I don't understand is
how you can suggest that realm names should correspond to inet domains
(case insensitive), and yet you want to make realm names case
sensitive.
I can't express how much of a pain it is in our environment
here where we must, because of old/buggy software which hasn't
been updated to be correctly case-insensitive, create .rhosts
files which look something like:
machine person
machine.berkeley.edu person
machine.Berkeley.EDU person
Yes, that's right. 3 entries in order to cover all the bases.
Needless to say, it would be nice to see this kind of stuff
go away.
>
> 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.
>
Are these listed publicly?
>
> 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.
>
Essentially this is like doing a simple encrypted checksum of some
cleartext to prevent non-tampering. It is important to note
that (given a publicly-available checksumming algorithm), it
may be possible to produce an identical checksum from a different
cleartext block (say by incrementing some dont-care byte).
To discourage this, part of the original cleartext block
should be included in the encrypted portion, not just
the checksum itself.
>
> 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.
>
Is it really unreasonable to suggest the abolition of instances?
Once you've received your ticket granting ticket, it is somewhat
natural to expect you will be issued tickets for whatever services
you request in your realm (and others if you're inter-realm
authenticated). Services should be thought of more like
the such-and-such service in the "foo" realm, rather than
the such-and-such service instance running on machine 'bar' in
realm "foo".
If you create some service which you think needs
to have separate tickets for each different instance, you are
probably not really talking about the *same* service anyway.
As for users as principals, Todd is correct in observing the
bit about 'user identity.' It is a particular service's job
to map user identification (provided by Kerberos) to access
rights (enforced by the service).
> 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.
>
There is some interesting possibilities if you are willing to
consider public-key encryption here. One could envision
a central repository of realms updated in a distributed manner
by administrators which posessed the correct private keys.
Updates could be sent to those interested, and signed with
the central authority's private key. This certainly requires
more thought but seems somewhat promising.
>
> 2) Library interface
>
>
> 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.
>
This POSIX standard makes mention of 'sessions'. The data structures
associated with sessions (in the kernel), we believe, may
be the place of choice for authentication info. such as tickets.
> 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.
>
If the effort is going to be made to isolate the OS-independent
layers, it would also be nice to isolate the network-independent
(or perhaps I should say Address Family-independent) portions
as well.
> 3) Implementation.
>
>
>
> 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.
>
Reliable, replicated, secure databases == research
Well, these are my initial comments to the proposed changes.
It is worth noting to this list that (if you haven't heard already)
Berkeley is considering distribution of Kerberos as part of
future BSD releases, which may very well help Kerberos to "win big"
as mentioned above.
We are very intereted in what changes are likely to be
seen in the basic system and when such changes are likely
to come about.
Comments/suggestions appreciated.
- Kevin
Kevin R. Fall
Department of Computer Science
571 Evans Hall
University of California, Berkeley
Berkeley, CA 94720
UUCP: ...!ucbvax!kfall
ARPA: kfall@ucbvax.Berkeley.EDU
AT&T: (415) 642-3979
