Subject: RE: Ticket extensions in Kerberos revisions

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

Since the KRB spec has always said that that TGT pacdata is always copied
over to tickets, then clearly the dog feels authz data should be bundled. :)

DCE actually followed the letter and spirit: the authentication server was
separate from the privilege server. They were just bundled into a single
executable for efficiency.  Do a klist on a DCE system some time (if you can
find one :).

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.

More importantly, it makes sense. It seems arbitrary to me that
a ticket conveys just a stringname. My "identity" is not only my
name, but the groups and realms I belong to, etc. The problem becomes
obvious when you want to do this in a heterogeneous world, but it was
always there. Just now, you're requiring everyone to map to/from Posix (sic)
identities, not just stringnames to account names ([email-masked] vs Twenex
"dcb.tech" vs VMS salzr, etc), it becomes obvious that things are ugly.

There are many aspects to authorization, beyond securely knowing the client
identity. Knowing that "Jill Salz, BofA Teller" is who she says she is, says
nothing about whether she can cash a $100K check.

Those things will always very.  Who I am -- who you are -- hardly varies.
And certainly it rarely changes within a ticket lifetime.
	/r$
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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 16:07:50 -0700 (PDT)

- Well, from my point of view everything in this message
supports my point. If it's answering the question 

	"Who are you?" 

it's not authorization.

> over to tickets, then clearly the dog feels authz data should be bundled. :)

- I think the whole point of this debate is that the spec is
insufficient defined at this point to do anything with authorization 
data. The question is do we define it or just throw it out? 

> tickets (why should a server ever have to "log in" -- get

- Because it's secure and extensible and a much better model? 

- When this model was first suggested at Stanford I was a dubious
as anybody. I was definitely in the "why should a server ever have to
log in " camp, but after a few years of writing code and running
applications it's entirely clear to me that this is a MUCH better
model. 

> "dcb.tech" vs VMS salzr, etc), it becomes obvious that things are ugly.

- The krbname makes a great opaque key, I think you make my point with
this paragraph. How can we possibly come up with anything that makes
sense to put in a PAC in a heterogenous environment?  

> And certainly it rarely changes within a ticket lifetime.

- I think this is exactly my point. At best a PAC answers "who are
you?" it can never provide a good solution to the question "what can
you do?". I am totally convinced that the more you pull these two 
questions apart the better system you can build. The tighter you
bundle them the sooner you run into roadblocks. All I want kerberos
to give me is a secure unique identifier. Putting anything else in
the protocol is just so much useless baggage. 

- Booker C. Bense

---

From: Greg Hudson <[email-masked]>
Date: Wed, 03 May 2000 10:36:49 -0400

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

	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.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2000 11:24:56 -0400

> located in the authorization server's ticket.  No need for the server

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: Ken Hornstein <[email-masked]>
Date: Wed, 03 May 2000 12:23:29 -0400

>[...]

My problem with this scheme is that it requires a significant protocol
change.  Clients have to be made aware that there's this new authorization
server, have to get auth tickets from it, application protocols may have
to be changed to accomodate these extra auth tickets, etc etc.

It should really be all or nothing - either you include authorization
in the ticket, or have the server do everything.  Either way the clients
don't have to change (and since the servers need to change no matter
_what_ you do, if we can just get away with changing those, it would
be ideal).

--Ken

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 3 May 2000 09:25:54 -0700 (PDT)

> then we can get rid of the Kerberos extensions altogether.

- I think it's a mistake to put the authorization lookup in the
client. This scheme is workable, but the chances of it ever getting
deployed are minimal at best. As other's have said it's pretty much 
DCE and one of the big reasons DCE was a failure was that it required
the client to have all this extra code. Anything that requires extra 
code in the client is pretty much a non-starter. It's taken YEARS 
to even get vendors thinking about putting modular authentication
in their clients. Mention authorization and they start talking about
database ACL's, they just don't get it.    

- Despite your belief otherwise, it is possible to have an server
based authorization system with some level of privacy.  It does
require extra configuration and there is a bit of a chicken and egg
problem in that how you authorize the servers to read the
authorization data.

- I think you're taking unix account logins as a model application,
IMHO this problem is already solved well enough and doesn't really
have a wide enough application to expend much effort on it. The model
application I'm thinking of is not the problem of mapping krbnames to
local usernames, but web based access to various resources. This is
where we have used our model of using LDAP as an authorization server
to great success. This does have the advantage of a high ratio of
servers to clients and our setup has a very centralized set of
servers. 

- The problem is really caused by the split of the data needed to
make an authorization decision. Groups/roles/Grandfallons live on 
the central server, while the ACLS are kept locally. It's up to
the server software to compare the two and make a decision.

- It would be possible to totally preserve the privacy of user data if
you put both the role and acl info in the server. Under this scheme
the service would present a triple of 

	username,servicename,action

to the authz service and it would return a yes/no answer. I have seem
some preliminary work in this area, but the reference escapes me at
the moment. The hard part here is figuring out how to manage the 
ACL's and roles. It has to be remotely manageable and dead easy to
configure if it is to gain acceptance.

- Booker C. Bense

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2000 12:40:38 -0400

> database ACL's, they just don't get it.    

Well, then this leaves the second approach I suggested several posts
back, namely that, instead of including the system credential data in a
PAC in Kerberos ticket, a token should be included in every service
ticket that allows the service to lookup the user's login data.

This token can be nothing more complicated that a Kerberos ticket for
the service to access the name service as well as the key(s) being
authorized for lookup against the name service.

I think it gets a bit more complicated, but not much more. This scales
well because the ticket sizes are only pretty much doubled from the
current ticket sizes independent of how much system credential data
there is to associate with any given user.

> problem in that how you authorize the servers to read the

This can always be abused, and, at any rate, I don't mind
nearly-anonymous user login lookups. I'm speculating that MS does and
that any alternative that we propose to their spec needs to take this
into consideration, otherwise how can we entice MS to use the open
standard? (No, I won't endorse anti-trust actions/remedies, though some
of you may see them as another alternative).

[...]

> the server software to compare the two and make a decision.

I agree fully. There is no argument here.

> configure if it is to gain acceptance.

This won't do as a replacement of file ACLs.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2000 13:00:29 -0400

Date: Wed, 03 May 2000 12:23:29 -0400
From: Ken Hornstein <[email-masked]>

> _what_ you do, if we can just get away with changing those, it would

At the risk of repeating myself :) there is one more alternative:
include a token that in the ticket that the target service can use to
perform the user login info lookup. This way clients need no changes and
yet there is no need to include users' complete system profile in the
tickets.

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 3 May 2000 10:05:48 -0700 (PDT)

> of you may see them as another alternative).

- It's pointless to design a protocol for MS to adopt. It just isn't 
going to happen. That horse has already left the barn, MS has made it 
abundantly clear that you are always going to have to use MS servers 
to support MS clients regardless of the protocols they claim to 
support. 
 
- We should design something that solves our problems well and 
let the justice department and the marketplace deal with MS. 

> This won't do as a replacement of file ACLs.

- sure it will, I just wasn't clear that action includes an object 
(in the grammatical sense ) as well as a verb. i.e. 

	READ /etc/passwd

would be a perfectly acceptable action. Or you could even send
something like 

READ /etc/passwd -r--r--r--  root     sys

- In effect keeping the ACL locally and passing it up to the server
to make the decision. Hmm, I like that idea even better, but it could
get unwieldy pretty fast.  

- Booker C. Bense

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2000 13:17:29 -0400

> to support MS clients regardless of the protocols they claim to 

I'm not so sure. At any rate, it won't be long before there are products
available to can support the Windows 2000 extensions _only in tickets
for win2k services that expect them_. Or something like that.

> let the justice department and the marketplace deal with MS. 

I think it's very hard to predict what may happen in a situation that
involves appeals all the way to the Supreme Court, politics (will the
next President's Justice Dept. drop the matter?), the markets in general
and so much more. Heck, Even if MS loses all the way, the end result
might still be that MS is allowed to continue their use of their
Kerberos extensions; then what?

And it's hard to predict the markets as well.

I wouldn't endorse the anti-trust actions against MS anyways, so I
wouldn't rely on any possible outcome where MS loses. This is a wholly
personal opinion, but I think it's still rather dangerous to rely on any
particular outcome of the case, regardless of what your personal views
of the case might be.

> get unwieldy pretty fast.  

I think such a scheme would, indeed, "get unwieldy pretty fast".

Each service needs to evaluate locally stored ACLs locally. All that's
needed is to make all the necessary user system credential information
available to the services that need it.

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 03 May 2000 14:16:19 -0400

>servers to clients and our setup has a very centralized set of

This sounds interesting; two questions: 

- Is access to the LDAP directory authenticated?
- Where is the source code? :-)

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 03 May 2000 14:18:57 -0400

>yet there is no need to include users' complete system profile in the

This token already exists - it's called "the client principal".  You
shouldn't need anything else.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2000 14:43:33 -0400

> shouldn't need anything else.

For that to be enough you must allow all servers to lookup any user's
login data.

I'm postulating that MS wanted to avoid this.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 May 2000 14:43:58 -0400

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 3 May 2000 12:15:48 -0700 (PDT)

> - Is access to the LDAP directory authenticated?

- Yes, via the umich kerberos 4 hack, which I would really like to 
replace with a true SASL method. 

> - Where is the source code? :-)

- Often we don't even know... %-)! The project is called WebAuth and
it's implemented as an Apache Module. There are various other bits and
pieces all over the place. It uses that horrible S/Ident software to
do the user authentication. I think if you search www.stanford.edu
with webauth as the topic you'll find at least a user's guide and
maybe even some design documents.

- Booker C. Bense

---

From: Russ Allbery <[email-masked]>
Date: 03 May 2000 17:10:23 -0700

Booker C Bense <[email-masked]> writes:

> pieces all over the place. It uses that horrible S/Ident software to do
> the user authentication. I think if you search www.stanford.edu with
> webauth as the topic you'll find at least a user's guide and maybe even
> some design documents.

And if what you find is interesting enough that you'd like to investigate
further, I think I know where most of the separate pieces are and can try
to hunt them down.  At some point, packaging it up would be good, but we
haven't had anywhere close to enough time to think about that.  :/

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>