Subject: RE: Ticket extensions in Kerberos revisions

From: [email-masked]
Date: Tue, 2 May 2000 13:37:18 -0400

> - Groups, roles, grandfallons... It doesn't matter what you call it,
> it's still the same idea. The difference is fine, but there is one
> between these two : 
> 
> 	Hi, I'm Booker Bense and I'm in grandfallon Beta... 

I think you mean "Hi, I'm Booker Bense and here's a blob of data sealed by
somebody we both trust that should prove to you that I'm in grandfallon
Beta."

> 	Hello Booker Bense, wait moment while I check if you're in
> 	grandfallon Beta... 
> 
> - I wish I could explain it better, but it's taken me 5 years of work
> to really grok the difference and I haven't found a good way to
> explain it. Perhaps the best way is the one scales to any size,
> and the first can only get so big before it becomes unwieldy.

I hope you're not suggesting that it's more scalable to have servers do
online checks at each credential presentation than it is to have the info
stuffed into a PAC at the beginning of a user's session.

The PAC option only becomes unwieldy when you (1) make the decision of what
groups/roles to include in the PAC without respect to the actual end use of
the PAC, and (2) tie it so tightly with authentication that the info has to
go even to services that won't use it.

(1) can be solved by having the client drive the PAC contents in its
request, and (2) can be solved by separating the PAC and the TGT (clients
present the PAC only to servers that will use it).

> > Embedding ALL permissions in a PAC is a Bad Idea.  (As a simple example:
> > What happens when you add a new securable object to the system?  Oops!)
> 
> - How do you pick and choose then? I'd object less if I saw a more
> concrete answer to this question. 

You pick and choose by having no permissions in a PAC, just role (/group)
info.

> - Clearly you can solve some of these problems by having the kdc
> query the authz service and imbed that in the PAC, but what's the 
> point? What's the advantage of the KDC doing a static fixed query
> that won't provide a complete solution? Seperating these functions
> has so many advantages, whereas joining them doesn't seem
> to present any clear advantages to me and the disadvantages are
> obvious.

I don't intend to get into a long discussion about these sorts of issues,
but DCE solved it the other way around: the client contacts the authz
service (PTGS) and requests a PTGT (privilege TGT); the PTGS constructs a
PAC and gets a TGT for itself with the relevant PAC attached (not embedded)
in it, and hands this proxied TGT back to the client as a PTGT.

There are some bad things about the DCE (one immediate one that comes to
mind is that there was no way to separate the TGS, the PTGS and the security
database, so you couldn't let the PTGS use an MIT KDC for tickets and LDAP
for account info, for example), but IMnsHO, the PAC system wasn't one of
them.

(Note that I am not defending Microsoft's choice to embed the PAC in the
TGT; I am only defending the abstract notion of a PAC.)

-- Ben
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: "Booker C. Bense" <[email-masked]>
Date: Tue, 2 May 2000 11:40:34 -0700 (PDT)

> stuffed into a PAC at the beginning of a user's session.

- Yes it is. We've been using such a system for years and it works 
just fine... Everyone has this fixed notion that it "just can't work". 
I know I did when we started, but in practice it works. It's scalable
in terms of people and sysadmin time. It's infinitely more scalable in
terms of programmer time. These are our limited resources, CPU and 
bandwidth are trivally cheap in comparision. People get more expensive
and computers get cheaper everyday.  

> present the PAC only to servers that will use it).

- You're talking about imbedding a real authorization service inside
the kerberos protocol. How does the client know what authorization
data to request in each service ticket? Why should it even HAVE to 
know?

> You pick and choose by having no permissions in a PAC, just role (/group)

- Okay, which roles go in the PAC ? I guess I'm not being clear, I
wasn't suggesting that you had to put explict ACL's in a PAC, even
just putting all the groups in a PAC is problematic. 

[stuff about how DCE works deleted]

> TGT; I am only defending the abstract notion of a PAC.)

- I simply don't agree. There are some advantages of a PAC in 
a fixed monolithic environment such as DCE or Win2k, but in a more
general open environment, I think it causes more problems that it
solves. To my mind a PAC doesn't answer the question "What can you
do?", it's a more elaborate answer to the question "Who are you?". 
To my mind, kerberos does this quite well already.

- Since the available resources to work on this stuff are so limited
I would rather see them focused on a more complete solution to the
authorization problem.

- Booker C. Bense

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 02 May 2000 14:51:35 -0400

>just fine... Everyone has this fixed notion that it "just can't work". 

Well, crack out the source code, then! :-)

>data to request in each service ticket? Why should it even HAVE to 

(Playing devil's advocate) - certainly the KDC could figure out what needs
to go in every ticket.

--Ken

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 2 May 2000 12:13:46 -0700 (PDT)

On Tue, 2 May 2000 [email-masked] wrote:

> I hope you're not suggesting that it's more scalable to have servers
> do online checks at each credential presentation than it is to have
> the info stuffed into a PAC at the beginning of a user's session.
> 
> The PAC option only becomes unwieldy when you (1) make the decision of
> what groups/roles to include in the PAC without respect to the actual
> end use of the PAC, and (2) tie it so tightly with authentication that
> the info has to go even to services that won't use it.
> 
> request, 

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?

In practice, to my knowledge, systems that use PACs send all the user's
privilege attributes in a lump when initiating a session to any service.  
If there's a system that works otherwise (maybe SESAME) I'd be fascinated
to learn how the client decides which attributes to send.  So, in
practice, every server finds out all details about every user, which is a
privacy problem, as well as a scaling problem as group membership
increases (not to mention the nested-groups problem).

I think that work on PKI-based attribute cert schemes (eg KeyNote, SPKI)
has led in the direction of negotiation between client and server about
which attributes the server needs to make an access control decision, but
this is still very much in the research stage as far as I know.

 - RL "Bob"

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 May 2000 15:24:18 -0400

> (Playing devil's advocate) - certainly the KDC could figure out what needs

Indeed! If the KDC knows what kind of service the target service of an
AS_REQ or TGS_REQ is, then it can put whatever data is appropriate in
the ticket. This just moves around responsibility, but if you're looking
to protect the database that holds that data from anonymous or
nearly-anonymous lookups, then this is the best way to accomplish that.

Note that the KDC could either embed the user login data in the ticket,
or it could embed a token in the ticket that the service can use to
lookup the data on its own. The token could simply be a ticket for that
service to access the database records in question on behalf of the
user.

> --Ken

Nico
--