Subject: RE: Ticket extensions in Kerberos revisions

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 May 2000 15:42:16 -0400

It's hard to see how delegation and "least privilege" can be implemented
without putting the credentials into the ticket.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked]
Date: Tue, 2 May 2000 15:37:55 -0400

RL "Bob" Morgan writes:
> So, the client has to know which of its many privilege 
> attributes to put into the PAC that it sends to a
> particular service.  This would require the client to
> know the contents of ACLs on resources managed by that
> service, since those ACLs might contain references to
> groups that the user is in (and group membership is
> mostly what's in the PAC).  How can this possibly work?

Or the client and the server could negotiate, or a client designed to work
with a particular service could know a set of predefined roles for that
service, or it could be in configuration info available to clients of that
service (say, maybe co-located with the information that the client used to
find the service to start with!).

-- Ben

---

From: [email-masked]
Date: Wed, 3 May 2000 11:47:44 -0400

This is within INCHES of how DCE does it.  The difference is that the
"bundle" is a proxied TGT with attached authz data.

Now, if we could only invent some sort of device that we could attach to
vehicles that would allow them to be conveyed smoothly along roads, we'd be
in business!  :/

-- Ben

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Wednesday, May 03, 2000 11:25 AM
> To: Booker C. Bense
> Cc: [email-masked]; [email-masked]
> Subject: Re: Ticket extensions in Kerberos revisions
> 
> [snip]
> > Here is an example:
> > 
> >         1. User gets TGT (containing no auth data)
> >         2. User contacts authorization server and presents a ticket
> >            and authenticator, and asks for authorization data for
> >            "fooservice".
> >         3. Authorization server gets credentials for "fooservice".
> >         4. Authorization server sends to user its ticket (not the
> >            session key, of course) and sends the authorization data
> >            sealed using its session key.
> >         5. User contacts "fooservice" and presents its normal
> >            ticket and authenticator, plus the bundle it got from the
> >            authorization server.
> > 
> > The server can now verify the authorization data using the session key
> > located in the authorization server's ticket.  No need for the server
> > to go off and check.
> 
> Hey, that's pretty good. This would solve the problem of anonymous user
> login info lookups as well. So if such a system could be standardized
> then we can get rid of the Kerberos extensions altogether.
> 
> Nico
> --

---

From: Joe Salowey <[email-masked]>
Date: Wed, 3 May 2000 09:07:44 -0700

There is also a better chance that using this method a client would know
what task it wants to perform and the authorization server know what
privileges the task requires. The client can request to be authorized for
the task and the authorization server then can assign the least privilege in
the authorization ticket to perform the task.  

This requires the authorization server to know the policy for particular
applications and a common way to represent that policy and the associated
privileges.

Joe

> Sent: Wednesday, May 03, 2000 8:25 AM
> To: Booker C. Bense
> Cc: [email-masked]; [email-masked]
> On Wed, 03 May 2000, Greg Hudson <[email-masked]> wrote:
> > >> As Ken pointed out, it is significant to save apps the 
> extra work,
> > >> the extra tickets (why should a server ever have to "log 
> in" -- get
> > >> a TGT?), etc.
> > 
> > > - Because it's secure and extensible and a much better model? 
> > 
> > Separating out authorization database from the KDC database does not
> > implicitly require the servers (other than the authorization server)
> > to "log in."
> > 
> > Here is an example:
> >

---

From: "John Brezak" <[email-masked]>
Date: Wed, 3 May 2000 10:53:24 -0700

When a Windows 2000 KDC gets a TGS-REQ with a TGT without Windows 2000
authzdata - such as a TGT from a trusted Kerberos realm, it will use the
cname in the ticket to locate an account in the Windows 2000 domain that
will be used to construct the authzdata and insert the authzdata into
the ticket. This is referred to as the cross-realm scenario, where the
Kerberos realm has a trust with the Windows 2000 forest.

The Kerberos realm is acting as the authentication service (issues TGTs
for users) and the Windows 2000 domain is acting as the authorization
service (decorates service tickets with the needed authzdata) to access
Windows 2000 services that are using the Windows 2000 domain security
model for access control.

In the end the ticket's authzdata is used to construct an access token
for the service. 

In the case where Windows 2000 systems are not a member of any domain, a
Kerberos realm can be used for authentication, but authorization is
based on establishing mappings between the cname in the ticket with a
local (SAM) account on the computer. The mapping is used to create the
access token. This is very similar to the mapping mechanism between
Kerberos principal names and /etc/passwd names on Unix systems to
establish a local uid for access checking.