Subject: Re: Ticket extensions in Kerberos revisions

From: Nicolas Williams <[email-masked]>
Date: Mon, 1 May 2000 13:22:33 -0400

I think that authorization data in Kerberos tickets actually fixes a
real problem elegantly. As such I think it's worth keeping the idea,
and standardizing a universal, extensible format for the authorization
data.

If there is no user identification data in Kerberos tickets then the
name service in use must allow anonymous (or nearly-anonymous) lookups
of user information from any server which a user might access.

With user identification/authorization/profile data in Kerberos tickets
this problem is resolved. It also represents an optimization: the name
service lookups of user information need only be made at TGT-granting
time. I find this idea to be very elegant.

The problem is that Microsoft's approach is very platform-specific.
That and Microsoft is not seeking to make their approach an open
standard.

So, if the alternative is between officially making Microsoft's approach
a violation of the standard or standardizing a better design then the
answer seems clear to me. After all, I think it more likely that
Microsoft would adopt a better standard than that they would drop their
PAC-in-the-ticket system altogether.

All we need is a general standard for encoding of name-type-length-data
fields and then a standard for naming the fields and types. The kinds of
data that should be included in Kerberos tickets, IMNSHO, are:

 - POSIX system IDs (UID, primary GID, supplementary GIDs)
 - Windows system IDs (domain SID, user RID, primary group RID,
   supplementary group RIDs, other group SID/RIDs)
 - home directory server and share information
 - maybe some other items, such as policy group memberships (think
   netgroups)
 - a ticket or PAC signature: a checksum encrypted with the key of a
   host-specific service principal that should be used on each host to
   validate the signature
 - a ticket or PAC signature signed with the key of the target service

Nico

On Tue, 18 Apr 2000, Clifford Neuman <[email-masked]> wrote:
> 
> One of the few remaining issues to be resolved before Kerberos
> revisions goes to last call is the final disposition of the ticket
> extensions field.  
> 
> Such a field was not present in RFC1510, but it is present in the current
> draft Kerberos revisions.  Whether this field remains is a contentious
> issue.  The argument for the field are that it allows additional
> information logically associated with the ticket to be carried with the
> ticket.  One example of such an extension is used in the latest version of
> the PK-CROSS protocol.  Another is the use of external (integrity but not
> confidentiality protected) authorization data.
> 
> The arguments against such a field center on backwards compatibility when
> new fields are added in ASN.1 encodings of messages, and the danger that
> the field might be misused for extensions that detract from
> interoperability across implementations.
> 
> I would like to initiate discussion on the list in hopes of bringing this
> discussion to resolution.  This message is intended to solicit discussion
> on both sides of the issues.
> 
> Clifford Neuman
> 
> 
--

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: "Clifford Neuman" <[email-masked]>
Date: Mon, 1 May 2000 10:35:28 -0700

I agree that it is time for a standard for encoding this information in the
authorization data field, and I'm planning to define the structure of the
authorization data element to encode just the items you listed in the
Kerberos revisions.  I wasn't planning to do this as part of the revisions
originally, but given the onerous licensing language in Microsoft's
publication of their spec, I think its time.

Of course, this would mean that if I include it in the spec, that Microsofts
authorization extensions would no longer be compatible.  If this is of
concern to them, then if they would free up the IP they claim on their
formatting of their field (which I don't consider to be particularly
innovative - having originated in earlier works and in krb-protocol
discusions), then I'd certainly consider describing the authorization
element in a separate spec instead.

Clifford Neuman

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, May 01, 2000 10:23 AM
> To: [email-masked]; [email-masked]
> Subject: Re: Ticket extensions in Kerberos revisions
>
>
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 1 May 2000 13:56:13 -0400

> publication of their spec, I think its time.

Yes, it's hard to believe that one could publish a trade secret and
still claim it to be a secret. I believe that their publication of their
spec in EXE format is designed to trigger protections in the DMCA for
access control devices.

Thus I feel quite uneasy discussing details of their spec (would that be
akin to breaking a non-disclosure agreement under the DMCA?). I'm also
unwilling to discuss the security of MS's design; why be so generous?

> element in a separate spec instead.

Or they could adopt the new standard.

Anyways, MS says that they are considering opening their spec
altogether. I don't blame them for hesitating: when the government is
prosecuting you on anti-trust charges every weapon can be useful...
[rhetorical -- no need to answer]

Nico
--

---

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

Nicolas Williams <[email-masked]> writes:

> real problem elegantly. As such I think it's worth keeping the idea, and
> standardizing a universal, extensible format for the authorization data.

I've never seen the intermingling of an authorization system with an
authentication system cause anything other than severe pain.  cf DCE.

> of user information from any server which a user might access.

Why would this require authorization rather than just authentication?
Kerberos tickets have authentication information:  principal and realm.

>  - maybe some other items, such as policy group memberships (think

All you need for this sort of thing is an authorization system that can be
queried in a secure fashion using the server's Kerberos principal for
authentication and takes a Kerberos principal as a key.  Sounds like an
excellent application for LDAP to me, using Kerberos to authenticate the
query.

We're currently using straight NIS for this because the above isn't
particularly sensitive information, but for additional security and
reliability, LDAP would be the first place I'd look.  It seems to be the
place Microsoft looked too, with Active Directory.  They just didn't clean
up the separation and play well with the rest of the world.

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

---

From: Rich Salz <[email-masked]>
Date: Tue, 2 May 2000 09:57:11 -0400 (EDT)

> Kerberos tickets have authentication information:  principal and realm.

You're drawing a distinction between authn and authz that I don't understand.
How is "use KRB authn info to query ldap" any different from authorization
where the principal (and perhaps realm) name are used as the credentials?
(In fact, I thought the phrase name-based authorization came from KRB,
not DCE.)
	/r$

---

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

> You're drawing a distinction between authn and authz that I don't understand.

- Nobody does. I have yet to meet a vendor that grasps the idea that
they should be seperate services. Who you are doesn't change, but 
what you can do often needs to change very quickly. Embedding that 
info in a static ticket seems to cut off alot of the possible uses
of authorization. 

> where the principal (and perhaps realm) name are used as the credentials?

- Because one works fairly well and the other is an abysmal failure. 
Putting authorization into the authentication protocol only works if 
you have a clear underlying model for HOW you are going to do
authorization now, next week and for the forseeable future. 

- Frankly, I would rather see the auth pack data removed from the
protocol entirely unless it's going to be fully supported via a
standardized API and data model. One of the great benefits of putting
authorization data in LDAP is that you have to sit down and plan out
the schema in advance.

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

- Kerberos should stick to authentication, which it does quite well
and leave authorization to another service. I don't think LDAP is 
the final word in this debate, but it's a good first step. Seperating
authentication and authorization creates a very powerful and flexible
environment. Joining them hasn't been successful in the past and I
don't know why that should change in the future. 

- Booker C. Bense

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 May 2000 12:11:03 -0400

> authentication system cause anything other than severe pain.  cf DCE.

But it's a reality with Windows 2000. I think Windows 2000 is here to
stay. Oh, and I have had no experience with DCE, so it's hard for me to
decide wether to agree with you or not.

> Kerberos tickets have authentication information:  principal and realm.

Because, see, if you don't put this information in the ticket, then
every server a user could log into must be able to look up that user's
login info. But this means, in practice, that any user can lookup up any
other user's login info (oh, you can make it really hard for this to
happen, but still). This is what I meant by semi-anonymous, because with
such a scheme you can never tell the identity of the user on whose
behalf a service is performing the lookup.

I think MS has taken quite a bit of heat over the fact that anonymous
users can enumerate NT4 SAM databases. With Windows 2000 and Active
Directory this is need no longer be the case: it's up to the
administrators and how they setup the relevant ACLs in AD.

The only ways that I can see to achieve this effect are:

1) put the login info in the tickets;

or

2) forward a proxied ticket to the service that a user is connecting to
   that would allow the service to lookup the user's login info on the
   user's behalf.

Microsoft chose the former. Note also that with the former the lookup
for the login info need only be done ONCE, when the user logs in (i.e.,
when the system she logs into requests a TGT for the user).

I find this to be elegant. And I can't see how it causes headaches,
though I can see that once a TGT has been issued to a user then the
associated login info cannot be changed for that session, nor can the
ticket be revoked, but that is a feature of Kerberos, so the situation
is not worsened by putting login info in the tickets.

I think that there is some confusion between "authorization data", which
is what we've been calling the MS PAC, and what it really is: system
credential information associated with the Kerberos principal + some
satellite data. I wouldn't call a POSIX UID "authorization data": it's
just a system credential.

Once one has made this distinction between authorization data and system
credentials then perhaps the concept should not sound so scary. I
believe system credential information should be distributed with
tickets, but only minimal authorization information should be included.
E.g., no info related to which servers a user can access belongs in
TGTs, but policy group membership information for the user _does_.

> excellent application for LDAP to me, using Kerberos to authenticate the

See above. BTW, this is the approach that Sun is using; checkout the man
pages for gssd(1M) via http://www.docs.sun.com/.

> up the separation and play well with the rest of the world.

Well, I think that MS indeed didn't play nice, but the concept they
chose is superior to the one that you're peddling, IMNSHO :)

I wasn't particularly interested in Kerberos at the time that MS started
considering their PAC-in-the-ticket approach, so I don't really know
what happened. Perhaps someone else can tell us if it was MS that didn't
play nice or the standards community or both. Or perhaps we can drop the
finger pointing, make up a new standard we can all live with and move
on.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 2 May 2000 19:03:06 +0200 (METDST)

>  - a ticket or PAC signature signed with the key of the target service

I haven't seen Microsoft's spec for the authorization data,
but I think it is not so easy to get it right and I'm wondering
whether Microsoft got it right in their design.

The only reason why systems like to carry around a POSIX-style userid
and group memberships is so that the authorization checks can be
performed by the trusted computing base (TCB) on the server side.

In order for the TCB to perform ACL checks for the clients privileges,
the server needs to "run in the context of the client" somehow.
In the Microsoft world, this is called "impersonation".

On W2K, the LSA performs the client authentication, retrieves the
PAC from inside the service ticket, verifies the signature on the PAC
somehow and then creates an access token that is made available to
the server process.  The server process can switch between its own
access token an the access token of the impersonated client whenever
it likes to.

Remember that with Kerberos, service tickets are (a) cached and therefore
reused, (b) have a limited lifetime, and (b) can be "forged" by the service
itself when it knows its own key (which is usually the case).

Now the questions that come to my mind:

(1) is the lifetime of the PAC limited in the same fashion as the
    service ticket.  It may be a security problem if a service can open
    incoming service tickets and save away PACs for unlimited future use
    in forged service tickets?

(2) is the PAC tied to the particular service/target, or could an
    arbitrary service use the PAC in a forged ticket to have an
    access token created?

(3) is the PAC limited to a particular target host, or can the PAC
    be reused in a forged ticket on a different host?

Keep in mind that impersonation is the default with Microsoft's SSPI,
so whenever a domain admin touches Microsoft services on a remote
machine in the domain, his PAC will be unconditionally handed to
this machine.  Therefore if you have accidental or intentional
admin access on one machine of the domain you may be able to
collect PACs and eventually use them on other machines of the
domain where you have access, but no admin access yet...

So whatever you plan to do in the authorization are, be very careful
of the security implications.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 May 2000 14:10:43 -0400

> whether Microsoft got it right in their design.

Good question. I have seen the spec, but have not read it too
thouroughly. See below.

> performed by the trusted computing base (TCB) on the server side.

Agreed.

> In the Microsoft world, this is called "impersonation".

Yup.

> access token an the access token of the impersonated client whenever

The KDC signature is only verified when the service that is trying to
impersonate the remote user is NOT a system service. In Unix-speak a
system service is akin to a daemon that runs as root. System services
obviously can impersonate [locally] any user they know about.

The service signature is to be verified by each service.

I remember seeing a public MS doc (from Usenix?) that explains that the
KDC signature is validated through a NetLogon MSRPC call. I would think
that if the signature were made with the LSA host service principal's
key then there would be no need for the NetLogon validation call.

[All of the above can be derived from various public MS docs on this
 topic.]

> itself when it knows its own key (which is usually the case).

Agreed.

>     in forged service tickets?

Good question. I should probably consult with a lawyer before publically
discussing MS's spec, as the onerous language under which it is licensed
might make me liable for civil penalties should I reveal any of its
contents publically.

;^)

Oh, and, I'm not sure I want to contribute to a free-of-charge analysis
of a spec so licensed.

>     arbitrary service use the PAC in a forged ticket to have an

Same answer as (1).

>     be reused in a forged ticket on a different host?

Same answer as (1).

> of the security implications.

Indeed.

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 02 May 2000 15:31:18 -0400

>key then there would be no need for the NetLogon validation call.

Hm, okay, I think I see the confusion here.

ISTR that the way this is going to be handled is by the use of the new
AD-KDCIssued authorization data typed.  This is protected by a keyed
checksum (the same key used to protect the rest of the ticket).  I
_thought_ that the only verification of the authorization ticket done
was verifying that this checksum is correct.  But given that you're
going to do _that_, I believe there is a valid trust chain between
the KDC and server, so no additional verification would be needed.

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 May 2000 16:09:20 -0400

> the KDC and server, so no additional verification would be needed.

The second signature, the one signed with the KDC's key, is there so
that non-system services (services that don't have local priviledges to
start with, i.e., services which "don't run as root") can ask the OS to
let them assume the credentials of the remote user. In such cases the OS
has to check a PAC signature that the service itself couldn't fake.

This is the reason for the second signature.

I think this problem could be handled differently, as I've said before,
which would not require that NetLogon RPC call. But I do think that the
second signature is indeed needed.

Nico
--

---

From: Russ Allbery <[email-masked]>
Date: 02 May 2000 15:20:19 -0700

> stay.

That's what people said about DCE too.  And we're hardly the only site
that tried to go to DCE and then decided that was a really bad idea and
changed *back*.  Admittedly, Microsoft has a lot of marketing muscle, but
under the hood it looks like the same bad ideas.

> login info.

I have a few reactions to that.

First of all, login information is not historically secret, and I'm not
sure how much you're actually gaining except in some specific
circumstances by making it so.  But it does fall under the category of
something that you don't necessarily have to allow, so for paranoia's sake
it may be better to cut off access to it.

Second, while it may be difficult to do so, it's quite *possible* to
require that the user give you permission to look up their login data
before you can do so.  This could require some thought as to how to
integrate this with how Kerberos functions, and it could be difficult to
do so cleanly.  On the other hand, the same thing applies to embedding
authorization data in the ticket.

I would *much* rather see general support for external authorization
systems using Kerberos than see Kerberos be turned into an all-signing,
all-dancing protocol that attempts to do everything.  To me, this is basic
system design; do what you know how to do well and rather than try to do
other things that you don't know how to do well, provide a well-defined
way to plug in another system that does only that other thing.  Monolithic
systems are inherently bad.

Booker's point is key here:  The lifetime of authorization data and the
lifetime of authentication data are frequently *completely* different.
Kerberos answers the question "who are you?".  It was not designed to
answer the question "what can you do?", and that's a *completely*
different question.  It's also not designed to be a generic network
database of information about a user, which is what doing things like
embedding home directory information and the like into the ticket would
try to turn it into.

Basically, what I'm hearing is a proposal to turn Kerberos into
essentially a "super NIS."  I think this is a very bad idea.  One of the
strengths of Kerberos is that it's exclusively an authentication protocol
and leaves network distribution of account attributes and authorization
information up to other protocols, thus allowing it to be easily used with
NIS, Hesiod, LDAP, and other protocols that were *designed* to be the
network accessible database that Kerberos isn't.

> But this means, in practice, that any user can lookup up any other
> user's login info (oh, you can make it really hard for this to happen,
> but still). This is what I meant by semi-anonymous, because with such a
> scheme you can never tell the identity of the user on whose behalf a
> service is performing the lookup.

So do you not believe this to be a fixable problem?

Let's take a step back.  What is the problem that we're trying to solve?
It seems to me that what people want is a database which maps the pair
(server identity, user identity) to a set of data about the user, possibly
including authorization information.  Different server identities may be
able to get different amounts of information.

We've already implemented precisely this at Stanford, and I know other
people have done the same thing elsewhere.  We used LDAP.  A server
identity queries an LDAP server for entries matching a user identity and
gets back various information about their account, including in some cases
authorization information.

What we haven't done, and what you seem to be wanting, is a way to prevent
an authorized server identity from enumerating the user space.  While I'm
iffy as to how serious of a security risk that really is, I can understand
that desire.  Rather than try to solve this problem by mushing together
two separate systems, how can we provide the authorization service
sufficient information to implement that security policy?

I think that would be a much more productive question to answer, and would
lead to a better overall design.

> I find this to be elegant.

I have the exact opposite position; I find the second to be more elegant,
if complex.  (I don't really find either to be truly elegant.)  Although
proxy tickets aren't the entire solution to the problem; the key point is
that the server's authentication to the authorization service is the
*combination* of the server and user identity.

The first solution is pure brute force.  In essence, it's solving the
problem of defining a clean API by combining two separate systems so as to
try to avoid needing an API.  What you end up with as a result is an
ungodly incestuous mess where both parts of the system know way too much
about the internals of the other, and down the road when you want to do
authorization via some completely separate database, you have to figure
out how to integrate that database into Kerberos and deal with all the
interaction issues.

> And I can't see how it causes headaches, though I can see that once a
> TGT has been issued to a user then the associated login info cannot be
> changed for that session,

This is a problem.

> nor can the ticket be revoked, but that is a feature of Kerberos, so the
> situation is not worsened by putting login info in the tickets.

No, you're missing the fundamental shift in how everything works once you
go beyond an authentication system into an authorization system.  Kerberos
establishes your *identity*.  In that realm, it makes sense to not worry
too much about your identity changing, because your identity will very
rarely ever change.  If I want to stop you from doing something, say
creating a new user principal, I remove you from the ACL (the
authorization service) and that change takes place immediately.  I don't
have to revoke your identity and wait for your active tickets to expire.

If you embed that authorization data into the ticket, I can't just remove
you from the ACL.  I have to tell Kerberos to not generate a ticket that
says "this user can create new users," and then I have to wait for all of
your existing tickets to expire.

This is a serious problem.  Privileges need to be revocable on a faster
time scale than ticket expiration.  By tying authorization to
authentication, you force people to revoke someone's *identity* to revoke
their *privileges*, which is a fundamentally broken model.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 May 2000 19:20:21 -0400

> under the hood it looks like the same bad ideas.

Marketing and the like make a big difference.

> authorization data in the ticket.

Yes. This was my thought as to a possible alternative to the DCE/MS
approach.

> Kerberos answers the question "who are you?".

Agreed. But it doesn't answer that question very well. You still need to
map the Kerberos principals to platform-specific usernames, where
possible.

>                                                It was not designed to

No, I don't want Kerberos to answer "what can you do?".

> network accessible database that Kerberos isn't.

Ok.

> So do you not believe this to be a fixable problem?

Not unless one of the two approaches I suggested below is used.

> able to get different amounts of information.

Ok.

> sufficient information to implement that security policy?

Right. As I said, I think MS chose to consider anonymous lookups of
login info to be a problem because it got a lot of heat about it. For a
recent reference, see Luke Kenneth Casson Leighton's book on reverse
engineering the MS Windows NT domain protocols. Actually, I'm
speculating as to why MS chose this approach, but I can see no other
reason, and after reading various parts of the Windows 2000 server
resource kit where the point is emphasized that with AD you can disallow
anonymous enumeration of you user info, I am very certain that this was
at least one of MS's motivations for pursuing the PAC-in-the-ticket
approach.

> *combination* of the server and user identity.

Yes. I agree about the latter and I think that the second approach I
suggested is a very general and open approach. (1) could be as well, if
standardized and desgined well. (1) allows the lookup to be done once,
(2) scales better (because the ticket size stays constant, regardless of
the amount of data that would otherwise be associated with a ticket
under (1)).

It's a tradeoff. I'd be glad with either.

> out how to integrate that database into Kerberos and deal with all the

I suggested a clean approach, not the current mess MS chose to foist on
the world.

> > changed for that session,

So? Whenever you add a user to a group that she needed to be a member of
you have to tell the user that they must log out and then log in again
for the change to become effective. This is true of Windows and Unix
platforms in general TODAY.

Thus this problem is not new and will likely never go away. So adding
system credential information to Kerberos tickets does not make the
current situation _any worse_.

> rarely ever change.  If I want to stop you from doinneed to be revocable on a faster

No. I'm not missing the point. I'm only arguing for the presence of
platform-specific system credential information in Kerberos tickets,
encoded in a general, open, extensible, sensible way and with verifiable
ticket signatures to prevent forging.

And I'm arguing, in general, for (1) or (2) primarily because something
must be done about Microsoft's extensions without forcing MS to allow
anonymous lookups of their directory, otherwise the chances of MS going
along with the new standard will be very small, nill even.

Moreover, I still think that either (1) or (2) would be an improvement
over what we have now. If we give proprietary vendors an open solution
that fulfills their needs then we're giving them an incentive to
implement the open standard.

Nico
--

---

From: Russ Allbery <[email-masked]>
Date: 02 May 2000 16:55:43 -0700

> ticket signatures to prevent forging.

Right, I think I'm following better now.  Thanks for the clarifications.

I think part of the question we're debating is what constitutes an
identity and how much application-specific information about an identity
should Kerberos be tasked with providing.  Currently, Kerberos provides
just a principal and realm, and leaves derivation of any further identity
information to the application.

I'm pretty strongly of the opinion that the groups or roles that a person
has are authorization information, fundamentally, and not identity
information, but then I have a pretty strict notion of what I consider to
be identity information.  To me, an identity is fundamentally a one-to-one
mapping, not a one-to-many mapping; in other words, you act as only one
identity at any given time, which is fundamentally incompatible with
having group membership be considered identity information.

The reason for this stance, at least for me, comes from how people use
groups and roles once they exist.  If you provide group information, that
information is used as-is for authorization purposes, even if it wasn't
intended to be used that way.  We have enough problems dealing with
applications that use the mere existence of a Kerberos identity for
authorization purposes, and in an ideal world all of those would also go
away.

If you have a role group, such as "humanities and sciences" to pick an
example relevant to our particular situation, and incorporate that
information in Kerberos tickets, I guarantee that the first thing that
someone who is trying to restrict logins on a server to just H&S
affiliates will do is allow logins for anyone who has that group
membership in their ticket.  Instantly, this information that may have
originally been perceived as identity information has become authorization
information, with all of the lifetime problems inherent in that.

Those of you who have been here can predict what happens next.  Some H&S
student abuses the system, or just shouldn't have access to it for some
reason, and the authorization model for logins to that system is now
tightly coupled with this identity information.  So the H&S folks ask the
Kerberos folks to remove this person from the H&S group so that they can't
log on to that server.  And now you've got a collision between identity
information and authorization information (the person *is* affiliated with
H&S), plus you're now making changes to the authentication database to
effect authorization changes.

I argue that this is the place you don't want to be.  Once you've ended up
here, you have fundamental design problems with your authorization model
that will be painful to work around and painful to fix.

> along with the new standard will be very small, nill even.

The chances of MS going along with anything that provides open standards
for something that they're attempting to market as a special feature of
their particular environment seem slim to me.  I don't have any good
solutions here either, but it seriously galls me to be considering moving
towards a model not really on the grounds that it's a superior solution
but on the grounds that MS will force it on us with marketing.

> implement the open standard.

Doing the authorization queries against an external database using the
Kerberos identity information as the key works.  We've widely deployed it
and related systems at Stanford for a variety of different applications,
and in fact using LDAP for this seems to scale even better than a standard
Kerberos server setup.  LDAP has real-time replication, something akin to
commits and rollbacks, changelogs that can be replayed, and lots of other
protocol infrastructure aimed at solving the distribution, scaling, and
replication problems even better than Kerberos's support for multiple
authentication servers.

Unsurprisingly, I agree strongly with Booker:  having the server obtain
its own identity and query an external server using that identity works
fairly reliably, is fairly easy to maintain, reduces the burden on the
Kerberos administrators significantly, and just doesn't involve that much
processing time for the servers.

---

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

On Wed, May 03, 2000 at 02:14:40PM -0400, Ken Hornstein wrote:
> Maybe this is a MS thing - but explain to me again why the non-system service
> needs the ability to become the remote user?

So that you can install and run third party software without full
priviledges but which can nevertheless obtain priviledges properly
delegated to it.

Or so I figure.

Nico
--

---

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

>priviledges but which can nevertheless obtain priviledges properly

Uhh ... what?

If you're talking about "delegation", that's handled _completely_
differently.  That's already been standardized, and everyone knows how
to do that.

--Ken

---

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

--Ken

---

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

--Ken

---

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

> differently.  That's already been standardized, and everyone knows how

Not just delegation of Kerberos tickets.

How does a Unix daemon become some user on behalf of which it needs to
perform some service when the service itself does not run as that user
or as root?

The answer is run the server as root.

In Windows 2000 you don't have to do that. I think it's security
advantage not to have to run services with priviledges, though it's not
a perfect solution wrt untrusted software.

Nico
--

---

From: Rich Salz <[email-masked]>
Date: Wed, 3 May 2000 22:07:00 -0400 (EDT)

> needs the ability to become the remote user?

So that it can be a non-system service. :)

It means that the server-writer doesn't have to emulate all the permission
checks that the operating system would normally do. That kind of thing
is error-prone and risky.
	/r$

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 04 May 2000 00:25:17 -0400

>replication problems even better than Kerberos's support for multiple

I feel I must point out that this is technically _not_ a feature of LDAP
per se, but the LDAP implementations.  You could do the same things with
Kerberos, and some of the commercial versions have done that; it's just
that no one has (yet) spent the time & energy in the freeware Kerberos
versions that are out there.

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 04 May 2000 00:19:04 -0400

>a perfect solution wrt untrusted software.

You're forgetting one thing - Kerberos was designed to authenticate
principals _across a network_, not through a third party on the same
machine.  If it's on the same machine, it's explicitly outside of the
Kerberos design criteria.

(It makes me wonder why the third-party app couldn't pass ticket +
authenticator to a system service, where _he_ could verify it and give
the appropriate privs to the third-party app).

--Ken

---

From: Russ Allbery <[email-masked]>
Date: 03 May 2000 21:41:14 -0700

Ken Hornstein <[email-masked]> writes:

>> Kerberos identity information as the key works.  We've widely deployed
>> it and related systems at Stanford for a variety of different
>> applications, and in fact using LDAP for this seems to scale even
>> better than a standard Kerberos server setup.  LDAP has real-time
>> replication, something akin to commits and rollbacks, changelogs that
>> can be replayed, and lots of other protocol infrastructure aimed at
>> solving the distribution, scaling, and replication problems even better
>> than Kerberos's support for multiple authentication servers.

> versions that are out there.

I was under the impression that the protocols for doing replication were
standardized, as was the import/export format (or at least being actively
worked on within the IETF).  I don't follow LDAP standardization closely,
though, so my apologies if I'm mistaken.

I certainly agree that this is possible in Kerberos (and Transarc has been
doing it with AFS's Kerberos implementation for a while), but developing a
client/server replication protocol would IMO be the first step of doing
that generally and with interoperability.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 04 May 2000 00:57:34 -0400

>though, so my apologies if I'm mistaken.

Certainly there is the LDUP working group, and they have a number of
Internet-Drafts out (but no RFCs AFAIK).  But AFAIK, none of it is
required to be implemented (please don't think I'm beating on the
LDAP guys, because they're certainly ahead of Kerberos in this
regard).

>that generally and with interoperability.

I'm not sure I can see a whole lot of value in being interoperable with
other vendors Kerberos servers; the database format tends to be very
server implementation-specific.  That's not a problem with LDAP, of
course :-)

--Ken

---

From: Martin Rex <[email-masked]>
Date: Thu, 4 May 2000 10:16:38 +0200 (METDST)

> Kerberos design criteria.

I strongly doubt that there ever was a design requirement in Kerberos
that prohibited performing the authentication within the TCB.

Anyway, this is how all authentication systems with POSIX-style
access control in the TCB make it (DCE, SESAME, Microsoft SSP).

> the appropriate privs to the third-party app).

That's exactly what happens.

Maybe you didn't read my original mail on this, it already contained
all the information:  Windows NT works with POSIX-style access control
that is enforced by the trusted computing base (TCB), and not by
any application code.  Therefore the authentication of the user
is performed by a system service (the LSA), which will also create
an access token for the service that will permit the service to
run "in the context of the client".  When running in the client
context, then the TCB performs access control against the client's
privileges instead of the server's privileges.

Microsoft calls this model "Impersonation", it is described in detail
in the Online Help of Visual Studio.  All Microsoft applications
use this access control model, and MS recommends all application
writers to use it (so that there is a homogeneous ACL structure
on MS platforms).

The end result is that you can run the service under any account that
you want, it will still get access tokens with the client's privileges
created by the LSA.

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 04 May 2000 11:47:35 -0400

>Because the third-party app has to have access to its service principal
>key and so can forge tickets to itself.

So give only the system service access to the principal key (and I'm
confused right now; according to Martin Rex, what I described _is_ the
way it works.  Who's right?)

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 May 2000 11:39:16 -0400

Date: Thu, 04 May 2000 00:19:04 -0400
From: Ken Hornstein <[email-masked]>

> Kerberos design criteria.

This is the reason for that KDC PAC signature in the MS spec. I propose
that it be done differently, but either way it doesn't cost much at
all (signatures are small).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 May 2000 12:22:18 -0400

> way it works.  Who's right?)

Ok, that'd work.

So what should be done with that ticket extension field in the draft?

I would still endorse a new standard along the lines of what MS did or
my other proposal. But I'm not convinced anymore that it's absolutely
necessary.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 May 2000 12:11:04 -0400

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/[email-masked], 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
--