[1807] in Kerberos
Re: Questions about Kerberos Version 5: Attn: Ted T'so
daemon@ATHENA.MIT.EDU (Joe Pato)
Fri Mar 13 14:50:52 1992
From: pato@apollo.hp.com (Joe Pato)
Date: Fri, 13 Mar 92 13:55:56 EST
To: lorrayne@smiley.mitre.org (Lorrayne Schaefer)
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: lorrayne@smiley.mitre.org (Lorrayne Schaefer), fri, 13 mar 92 11:04:42
I'll leave it to Ted T'so or someone at MIT to address the scheduling issues of
the MIT code.
Now for some slightly more difficult questions:
3. How does one remove a person's privileges from authorization data?
What if a principal who currently does not have access (or permission)
to file Y on system X (this is recorded as authorization data on the
principal's ticket) who later will have permission to access file Y on
system X? How is this reflected in the authorization data if no
authorization data is omitted when transferring authorization data
from the existing TGT to a new TGT?
This issue is really beyond the scope of kerberos. This addresses the
authorization model used by a system - kerberos is simply providing the I/A
component and a hook for authorization.
In Rev 5 of the RFC a new optional field was added an authenticator which
allows the initiator to transmit additional authorization data. (data that is
not sealed/signed by the KDC). This allows an initiator to limit privileges
that might exist in a ticket, which helps deal with appropriate privilege and
some delegation issues, but is not appropriate for the kind of rights
revocation you are looking for.
In the OSF DCE, the security component includes an authorization model.
Revocation of privileges is handled by setting the per cell (realm) policy that
controls the timeout of a privilege ticket. By default this timeout is
relatively short (2 hours).
Applications can choose to verify the privileges that are sealed in the
authorization data field of a ticket before granting access. This allows that
application to take advantage of immediate revocation of access. In the DCE
this is currently feasible since privileges are limited to identity and group
membership and the target application can test the privileges via calls to the
user registration component of the security service.
4. In all of the papers I have read there is a description of a
three-way step towards authenticating a principal to a server. But,
there is no description of how the principal (let's say a server)
receives the private key or how Kerberos even knows that the server
exists or that the server even knows who the Kerberos server is. I
guess this should be called step zero: Establishing a private key.
Is the establishment of a private key done manually? by mail? face to
face? etc? I assume this is a system administration function where it
is done manually.
This is not part of the kerberos protocol. You are right that this is "step 0"
- it is the administrative activity that must occur to register a new principal
in the realm. This activity differs in different implementations of a kerberos
environment (e.g., the DCE implementation provides a user registration facility
that is used to create new principals. This utility is a remote tool that will
send RPCs to the security server to manipulate the database. Creation and
manipulation of nodes in this database is controlled by ACLs attached to each
node in the database.) You can obtain documentation on how this is done in the
DCE from the OSF:
OSF DCE 1.0 Administration Guide, Volume 2, Module 5 "Security Service"
-- Joe Pato
Cooperative Object Computing Division / East
Hewlett-Packard Company
pato@apollo.hp.com
-------
