[534] in Kerberos
Re: A collection of suggested changes to Kerberos.
daemon@TELECOM.MIT.EDU (Bill Sommerfeld)
Mon Nov 28 13:32:25 1988
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: kfall@OKEEFFE.BERKELEY.EDU
Cc: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>, kerberos@ATHENA.MIT.EDU
In-Reply-To: Kevin Fall's message of Mon, 28 Nov 88 01:59:54 PST,
Thanks for the comments; I'll answer a few.
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.
"Useful but not sufficient". This doesn't work for long term,
unattended "batch" jobs.
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).
Noted; I would argue that there should be a per-site or per-realm
configurable option for the maximum lifetime. For flexibility, it
should probably be a run-time configurable option for the KDC.
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?
Not really, since both formats are a 32 bit count of seconds since
some start time; in one case, 1/1/1900, and in the other 1/1/1970.
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).
Note the use of the word "conventions". Nothing in the protocol or
implementation should prohibit or impede the use of other forms of
realm name, but it was felt that some kind of naming convention
_should_ exist, just for consistancy among connected Internet sites.
Are these [protocol changes] listed publicly?
I think you misunderstood the message; the list which follows (1.1 ..
1.12) is the list of suggested protocol changes.
>
> 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.
We seem not to agree on terminology here.
By "service", do you mean "rlogin" or do you mean "rlogin into host
A"?
I definitely want separate services for each different host; if host A
is compromised, I should not be able to use that information to
compromise host B.
There can be mutually suspicious system administrators within a realm,
as long as they all trust the system administrator(s) for the machines
running the KDC.
Reliable, replicated, secure databases == research
Maybe this was the case a few years ago, and it may still be the case
for "general purpose" databases, but at the level of replicated data
needed for Kerberos, I am told that it is currently more like
"development". For example, there's Apollo's user accounts registry
system (which has shipped to customers). It appears to be reliable
(at least from my experience), is replicated, and uses a shared-key
authentication scheme for security. It is a master-slave system as
opposed to a more symmetric system; maybe this doesn't fit your
definition of "distributed database".
Mike Kazar has also been working on a system called "ubik"; I don't
know about it in detail.
- Bill
