[25] in Kerberos
Re: RVD authorization and Kerberos i
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:16:29 1987
From bcn@ATHENA.MIT.EDU Fri Jul 25 10:36:37 1986
From: Clifford Neuman <bcn@ATHENA.MIT.EDU>
Date: Fri, 25 Jul 86 10:33:48 EDT
To: Saltzer
Subject: Re: RVD authorization and Kerberos integration plan
Cc: kerberos, rvd-info
This is in response to your proposal on the RVD authorization and
Kerberos integration plan. Assuming the existence an access control
list server (ACLS), your proposal looks good.
I have problems with one point, though, which is more an issue in the
design of the ACLS. I do not see the authorization as being a name of a
Kerberos principal. This seem to muddy an already unclear concept. A
Kerberos principal should be someone at either end of a connection, such
as a user, or a service. It is more an authentication concept that an
authorization concept since each prinicpal has it's own key (although it
could be the same as the key for another principal). There are cases
where one user may have several instances. In this case, the user gets
to choose which principal he wants to be come when he "logs in".
I propose instead that the ACLS provide its own ticket to a user such
that the user can pass the ticket on to the service. This ticket is
distinct from a Kerberos ticket, and may contain different/additional
information that can be used by the end service. The authenticity of
this ticket can be checked using Kerberos. This can be accomplished as
follows:
The beginning of an ACLS ticket is a Kerberos authenticatior for
the end service issued to the ACLS. Note that this ticket is
encrypted in the services key, so the user who the ticket is
returned to can't read it.
The second part of the ACLS ticket contains the authorization
information to be provided to the end service.
There are two ways the authenticity of the second part of the ACLS
ticket can be checked. The Kerberos authenticator contains a checksum
of the authorization data or the authorization data is encrypted in the
session key from the ticket. Both these approches can be accomplished
without change to Kerberos. The tradeoff is speed in creating the ACLS
ticket, versus difficulty in modifying the authorization data. If you
encrypt the authorization data, you also get the additional side effect
(for better or worse) that only the end service can determine the
contents of the ACLS ticket.
~ Cliff
