[485] in Kerberos_Protocol

home help back first fref pref prev next nref lref last post

One more proposal (was Re: Ticket extensions in Kerberos revisions)

daemon@ATHENA.MIT.EDU (Nicolas Williams)
Mon May 22 12:16:20 2000

Date: Mon, 22 May 2000 12:11:04 -0400
From: Nicolas Williams <Nicolas.Williams@ubsw.com>
To: Clifford Neuman <bcn@ISI.EDU>, ietf-cat-wg@lists.Stanford.EDU,
        krb-protocol@MIT.EDU
Message-Id: <20000522121103.B27366@sm2p1386swk.wdr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <200004190431.VAA10992@cayman-islands.isi.edu>


In this thread I proposed several technical approaches to extending
Kerberos in a way that would solve the problem that I think Microsoft
was trying to solve with it's PAC extension. Having seen Active Directory
in action now, I am more convinced than ever that MS really was trying
to make it possible to restrict or deny anonymous lookups of user
account information.

The second proposal I made was very skimpy on details because I hadn't
thought those details through. I wish to put this proposal to you once
more; it's a very generic one and, I think, fixes a number of problems,
not just the problem MS was trying to solve with its PAC extension.

Essentially I'm proposing a generic way of adding multiple extensions
onto a any ticket, with several predefined extensions, such as: TGT
restrictions (restrict what svc tkts a TGT may be used to get), embedded
forwarded TGT extension (possibly with TGT restrictions), "localname"
extension, LDAP access restriction extension, etc...

The TGT restriction extension by itself could obsoletes proxy tickets
and adds a large degree of flexibility to users and/or administrators
about how much authority to delegate to services.

The embedded ticket extension makes it possible for these extensions to
be used with no client modifications; administrators would set default
delegation policies.

And so on. Here then, is more detail:

1. Generic ticket extensions.

Tickets could have zero or more extensions included, on request of
clients or by administrative policy, by the KDC.

The format of these extensions might be:

 - Extension Name / Type (string)
 - Applicable Service Principals (list of applicable/not-applicable
   principal patterns)
 - Extension Data (possibly required to be parameter=value pairs;
   service specific extensions for proprietary services would be
   allowed to encode their data opaquely)

encoded in, say, ASN.1 (for consistency).

Clients of the TGS could request that some extensions be added.

The TGS could automatically add extensions as per administrative policy,
unless a client specifies otherwise.

When a TGT bearing extensions is used to request a service ticket the
TGS should copy all applicable extensions to the service ticket.

2. Some Extensions [To Be Standardized]

   a. TGT Restrictions Extension

      A list of allow/deny principal patterns. When a restricted TGT is
      used to request a service ticket from a TGS the TGS should attempt
      to match the requested service principal name with an allow
      principal pattern in this list; if no allow matches occur or if
      any deny matches occur, then the request should be denied.

      A restricted TGT could be used to request a cross-realm restricted
      TGT if the service principal's name is allowed by the pattern list
      and its realm is no that of the TGS handling the request. The TGS
      would copy ALL ticket extensions to the cross-realm TGT.

   b. Embedded Ticket Extension

      An embedded forwarded ticket. A service ticket may have this
      extension included by the TGS on request or by administrative
      policy; the embedded ticket would be for the target service
      principal of the containing ticket to use to impersonate the
      client principal requesting the service ticket.

      Embedded tickets may, of course, bear ticket extensions, such as
      TGT restrictions, say.

   c. Localname Extension

      A system username, a POSIX UID, a Windows domain SID and user
      RID and/or a specification for a name service query that will
      return a user's system credential profile.

   d. LDAP Restrictions Extension

      A list of LDAP object/container distinguished name (patterns?)
      that a ticket holder is allowed/not allowed to query and whether
      the ticket holder can modify any of those.

   e. Permission To Impersonate System Credentials

      Simply indicates to the a named system-specific service principal
      (say, LSA, for Windows 2000) that the service principal to which
      this ticket was forwarded has permission to locally impersonate
      the original user principal (i.e., the one that forwarded the
      ticket).

   f. Signature

      A service principal name and a checksum of the entire containing
      ticket, minus signature extensions, encrypted in the named
      principal's key (kvno should also be included).

   g. Generic File Services Restrictions Extension

      A list of generic restrictions to be applied to all remote
      filesystem protocols that can support them.

      One restriction might restrict the ticket holder to read-only
      operations for all of the original user's shared files.

      Another restriction might name some tags and permissions to be
      allowed to the ticket holder on any files of the original user
      that are so tagged.

      Another restriction might name a filesystem, a relative path
      from its root and a permissions mask such that the ticket holder
      can only operate with those permissions in the named directory
      (and sub-directories) of the named filesystem. I think such a
      restriction could be implemented even for NFS, though with some
      state on the server.

   h. Protocol-specific File Services Restrictions Extension

   i. Generic Naming Services Restrictions Extension

   j. Protocol-specific Naming Services Restrictions Extension

   k. Etcetera...


Principal patterns would look and be handled much like good old shell
globs. I've developed a simple algorithm for applying such patterns to a
service principal, though I've yet to commit it to paper (or bits). Some
examples: ldap/some.fqdn/*@*.SOME.REALM, ldap/*@SOME.REALM, ldap/*@*,
etc...

With such a framework of ticket extensions you can see how users and/or
administrators would have a far more fine grained choice over
credentials forwarding that plain ticket forwarding/proxying.

A TGS might know that some services require some forwarding of user
credentials and thus might include in all tickets for such services an
appropriate embedded forwarded ticket with appropriate restriction
extensions included.

The replacement of the MS PAC spec, with this proposal, then, is as easy
as: including embedded, forwarded TGTs in some service tickets with
restriction extensions such that the forwarded ticket allows the service
to query LDAP as the user. Such embedded TGTs may also include a
"permission to impersonate user locally" extension and a signature
signed with the key for the LSA principal on the same host as the
service principal.

This framework would also make it possible to define an extension that
explicitly includes most or all details of a user's system credential
profile, as in my first proposal. Only now this is not necessary nor is
it desirable, IMHO, except as an optimization.

This proposal, I think, solves several problems, including the riddle of
how to forward less than a TGT, but more than a single proxy ticket (a
restricted TGT could represent a huge number of individual proxy
tickets). This framework also makes it possible to take advantage of it
with zero client-side modifications to begin with and with service-side
modifications only where one wishes to take advantage of these
extensions. As a corollary, no modifications would need to be made to
any protocols that are already kerberized or GSS-API'ized. And for
replacing the MS PAC this system requires modifications only to some
DLLs on MS DCs and servers.

The fact that this proposed framework solves many problems might make it
enticing to Microsoft, should a standard be approved based on it. Though
this proposal would be useful regardless of what MS does with it.

Finally, it could be argued that the embedded ticket extension is
unnecessary, that protocols should be modified to support forwarding of
tickets. Fair enough, but the advantage of embedded forwarded tickets is
that they can be used with zero client-side code changes, and though
GSS-API is the place to deal with forwarding of tickets, I think there's
a fair chance that with Windows 2000 and Solaris 8 Kerberos will become
the dominant distributed secure authentication system, thus minimizing
the difference between using the embedded ticket extension and sending
forwarded tickets separately.


Toughts?


Nico
--


home help back first fref pref prev next nref lref last post