Subject: RE: Ticket extensions in Kerberos revisions

From: [email-masked]
Date: Tue, 2 May 2000 12:14:29 -0400

Booker C. Bense wrote:
> - The schema I've seen so far ( basically Groups ) is just a extension
> of answering the question "Who are you?". If you are going to truly

See "groups", think "roles".

> answer the question "What can you do?" that auth pack is going to have
> to be fairly large since it has to contain ALL of your permissions
> apriori. In this area, an incomplete inflexible solution is worse than
> no solution at all.

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!)

I have yet to be convinced that embedding role information in a PAC is a bad
idea.  The only drawback I've seen to it is that the information can't
change as frequently as you might like it to.  To me, that seems a
reasonable tradeoff for the benefit of servers not needing to contact an
online authorization service to find out the info in realtime every time a
client's credentials are presented.

-- 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 10:04:30 -0700 (PDT)

> See "groups", think "roles".

- 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... 

	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.

> 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. 

> client's credentials are presented.

- This is a false optimization. Solving only part of the problem
actually causes more work in the long run. How does this data get into
the kerberos PAC in the first place? If you can't solve all your
authorization needs with it, you'll need a second system. How do 
you keep the data in sync? 

- 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. 

- Booker C. Bense

---

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

>to present any clear advantages to me and the disadvantages are

There _is_ one advantage to including the authorization into the ticket -
applications aren't required to do any (extra) work to make authorization
decisions.  Since they've already got the ticket, they can simply
look inside of it to find out the authorization information without
having to contact another service (this presumes that the information
in the ticket is complete enough to not require lookup in _another_
directory service).  This is, in my mind, a incredibly seductive reason
to want to do it; you get to save a _whole_ lot of complexity in your
application servers, and you don't have to invent a new protocol (okay,
you could use LDAP, but you'd still need to put that in your application
server).

However ... even given all that, I'm not sure that's the right way
to go.  As people have pointed out, "what you can do" generally changes
a _lot_ more often than "who are you", and using the model that
Kerberos uses for authorization may not make sense.  However, don't
ask me what the _right_ thing to do is - I'm not sure.

Though in defense of DCE, I don't believe the PAC stuff that DCE used
was really all that bad.

--Ken

---

From: "Booker C. Bense" <[email-masked]>
Date: Tue, 2 May 2000 12:08:45 -0700 (PDT)

On Tue, 2 May 2000, Ken Hornstein wrote:

> >that won't provide a complete solution? Separating these functions

- This is only an advantage if you have a pretty firm grasp on what's
in that bit of authorization info. Unless everybody is playing on the
same field it becomes a quagmire pretty quickly. It's always tempting
to grasp at the quick & cheap solution, but you pay for it in the long
run[1]. Of course I fully expect that my track record in these matters
will continue ( I've been 100% on the losing side of every protocol
debate I've ever bothered with. )

> ask me what the _right_ thing to do is - I'm not sure.

- Well, I'm not sure what the answer is either. In fact, in classic
fashion I think we've gotten totally sidetracked from the real
question. 

	How do we close the loophole MS has used in the kerberos
protocol? 

- As I see it there are only two choices: 

A. Declare the auth dat field null and void. 

B. Write a complete specification of the data and use of it. 

MS will ignore both since it's already deployed, in fact I'm not 
sure we can do B legally given the "license" agreement of MS's
protocol specification. 

- Booker C. Bense 

[1] - See the long tortured history of the http protocol.