Subject: [Ietf-krb-wg] What are KDCs trusted to say?

From: Sam Hartman <[email-masked]>
Date: Wed, 26 Jan 2011 15:32:40 -0500

Nico,  thanks for some excellent thoughts on trust.

I agree that under your analysis there's nothing new here.  I definitely
think you've done a great job of characterizing the basic problem.

I've been focusing on one issue that you brought up and then glossed
over: What statements do we permit the KDCs to make?

That's where I think introducing a PAC into the standardization space
requires the IETF to consider issues it has not grappled with before.

Today, from a standards viewpoint, Kerberos authentications a possibly
anonymous identifier.
The server absolutely has to trust all the KDCs in the transited path to
make any acceptable statement.
That is, say there's a servers@D. This server gets an
authentication from 1@A, transiting B and C.

s@D can either decide to trust D to speak about 1@A or to not accept
authentications via this service key for that principal.
That is, s could say that 1 needs to log in via some none-Kerberos
mechanism or if s is registered in more than just D, use a path not
going through D  in order to log in. However, if there is every a
circumstance when s will accept authentication as 1@A through D, then it
has to trust D to make this statement whenever D chooses to make the
statement.

Similarly, D has to trust C, C has to trust B, and B has to trust A.

However, each of these KDCs may decide to limit what statements can ever
be made across a cross-realm link.

We talked a lot in the Kerberos Consortium conference back in October
about the role of the KDC in the cloud as a central point of policy
enforcement. In that model, the KDC will be getting authentication and
attribute statements from entities outside the organization. It seems
fairly clear that significant filtering of what statements are permitted
and thus what trust is given to these organizations is desirable.  It
wasn't clear whether in expected the incoming statements to be in the
form of Kerberos tickets. For simplicity's sake, let's assume that they
are.  I think it would be entirely reasonable (and probably even
required) for such a KDC not to trust any KDC outside the organization
to claim that a particular principal was part of the
enterprise/domain/realm administrators' group in any PAC.  Any PAC
making such a claim should be filtered or not resigned.

This is very much a question about trust model and is an example where
we are choosing not to trust a KDC outside the organization absolutely.

You can argue that this is nothing new: we already have this issue when
discussing whether to trust a KDC for a given principal authentication.
I argue that additional attributes to consider besides just principal
name adds new elements. First, the principal name follows the realm
name; the claimed issuing realm is explicit as is the asserting
(service) realm.
Also, all KDCs understand principal name.
Having attributes that some KDCs do not understand  adds a new element.

I've been thinking about trust from a number of standpoints lately: the
ABFAB federation architecture, the Microsoft forest, and also thinking
about the minimal trust implications for the referrals draft.
Let me present the first two to start a discussion.

PAC/forest model: KDCs are trusted. When administrators establish a
trust relationship they are making a fairly strong statement that a
particular KDC can be trusted to make any (or almost any statement.) I
believe that SID filtering may permit some limits but I'm not entirely
sure. Here, deployment of new features is more important than trust
limitations; unknown attributes should be permitted.

ABFAB model: authentication happens between a relying party and identity
provider in different organizations. There is a specific federation in
place dictating some attributes that can be trusted and some guarantees
that can be relied on. However there are very likely to be statements
within the relying party organization that are not permitted to be made
as part of the federation.  In this case, some entity needs to make some
policy determinations.
The relying party infrastructure can be trusted to label statements
coming from the federation as coming from the federation.  

However it seems like the behavior of some component in the system needs
to be different in these two situations. In the PAC model, we want
services to generally trust statements they receive. Unknown attributes
are probably OK, and we generally assume that parties are permitted to
make the statements they make.

In the ABFAB model, someone within the relying party organization needs
to understand and vouch for any attribute and to explicitly vouch for
that attribute being permitted from the source. Also, the labeling of
the source is more important in this model.

So, because I think we want the behavior of actors in the system to
depend on some of these assumptions, I think that we want to make
statements about trust in the protocol specification.  I actually think
that adopting the PAC model or something close for the PAD proposal is
the right direction.  I think that whenever we are dealing with
statements like those from ABFAB, the right way to handle them might be
to wrap them in a don't entirely trust me container.

(GSS naming extensions doesn't deal great with this sort of thing.  I
suspect we'll be improving that API over time as we get more
experience.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Jan 2011 23:50:03 +0100 (MET)

Sam Hartman wrote:
> 
> I think it would be entirely reasonable (and probably even

Personally, I find the use of the word "trust" in this context
confusing, to the point that I find it actually wrong.

If all one is doing is authenticating identities, then it is both
easy to configure "trust" in a fashion that I trust "KDC of realm B"
to make an assertion that some user is Joe@B.  If I'm an admin of
realm A in a different organization, I'm probably less inclined
to believe claims of KDC of realm B that some user is Joe@A.

The problem you're facing is when you're not limiting yourself
to trust assertions of _identity_, but instead inter-mixing an
offshoring of your ACL management into the assertion of identity.

If an authentication scheme provides only proof of identity
(no attributes, nor groups), then one has to maintain ACLs on
each an every object, resource and service seperately, and in
order to grant or revoke access, modify/adjust all relevant
ACLs.  In order to cut down on the ACL management work,
centrally maintained group memberships / authorization attributes
have been invented, so that on many of the ACLs of your resources
you have only group memberships, and on your central server,
you maintain which users are members of which groups.

If you want to revoke certain privileges for a user, you no longer
have to revoke his entire identity credentials, but only update
his group memberships on a central server.

Now the problem with this is, as soon as you start doing this,
any of the "trust in assertion of identity" by other organizations
becomes pretty useless, because being someone no longer means anything
to (most of) your resources.

Since most of the time you will not want to trust other organizations
to issue themselves whatever "privileges" they want, much like you
don't want them to assert identities within your own administrative realm.

But in many cases that will mean that you have to maintain the
privileges of everyone from those other domain in your own groups
before they will be able to access some of your resources.

Trusting other realms to assert privileges is close to trusting
them in asserting names of your own realm (because what counts is
the effect this has on ACL checks when accessing resources).

Trying to maintain privileges for users@B to resources of A in B's
directory instead of A's doesn't make any simpler, but A will loose
control and auditing capabilites over all resources in A where
access is controlled based on privileges/group memberships rather
than identity.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 26 Jan 2011 18:11:25 -0600

> to wrap them in a don't entirely trust me container.

We must certainly state assumptions, and make their implications clear.

There are several distinct issues to address:

 - Whether or not we want to do anything to help principals keep KDCs
   honest.  (To do so would mean using public keys and public key
   signatures, which seems unlikely to be acceptable to the WG, but we
   should at least consider such an approach on the way to rejecting
   it.)

   As it is Kerberos is a trusted third party system.  As such, parties
   that rely on it depend enormously on KDCs being honest.

   And if so:

    - How to deal with KDCs whose policies require removing statements
      made by earlier KDCs?  (This is the privacy protection / ABFAB
      aspect.)

 - Whether we want to depart from the traditional Kerberos model that
   _services_ are responsible for implementing and enforcing policy,
   with KDCs beign able to _optionally_ check policy.

   And if so:

    - Extensibility -- how to add new kinds of attributes?  If so, how
      can KDCs check policy regarding attributes they don't know?  (This
      is something you brought up that I'd missed.)

    - Whether we want to know "who said what".  If not, how can services
      check policy?

 - API issues.

> suspect we'll be improving that API over time as we get more

The GSS naming extensions proposal at one time had an "issuer" name for
each extension.  That would help, but the problem is that an extension
might well be a container that contains lots of statements "issued" by
different entities.  So, yes, the API issue is definitely there.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 26 Jan 2011 18:17:07 -0600

> confusing, to the point that I find it actually wrong.

The word "trust" has been much abused, to the point where it's potential
meaning in any case is quite broad.  For a discussion like this, where
we're trying to nail down the semantics that we _want_ (or need) such
broad scope makes the word a useful one to start with.  Sadly, I don't
know what better words there are when we get into very specific
semantics.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Jan 2011 09:48:26 -0600

> to believe claims of KDC of realm B that some user is Joe@A.

Indeed, limiting what statements any KDC can get away with making is
critical here.

But, of course, KDCs (let's say, in realm B) can mint tickets not only
for any client principals in their realm, but for any client principals
in any realm that want to talk to services in their realm (B).  Worse,
they can mint tickets for any client principal in any realm where the
KDC's realm (B) must be transited by the potential victims.

So a realm A that trusts B and allows transit paths through B is
trusting B for far more than just naming principals in B.

> offshoring of your ACL management into the assertion of identity.

No, that's not the problem.  To be absolutely clear: authentication
without the ability to make authorization decisions based on
authenticated identies is rather useless.  If we have authenticated
identities, we'll have authorization.

As you say next, it's possible, and desirable, to map certain kinds of
identities asserted by remote realms' KDCs and map them to other forms
so as to make certain operations, such as renames and revocation, easier
to manage.  Or the identities supported by the mechanism might be in a
suitable form already (e.g., SIDs, where one assumes that RIDs are not
reused and that domain SIDs do not collide within a forest).

> to (most of) your resources.

I don't see how you get there.  A KDC's assertion of identity does still
result in authorization being granted or denied, thus a KDC can still
gain something important by lying about authenticated identities.
Mapping identities does not change the rogue KDC problem one bit.

> don't want them to assert identities within your own administrative realm.

The word "privilege" has very specific meaning to me, particularly in
the context of operating systems: the specific meaning that we use in
Solaris, which matches up closely enough with what Linux calls
"capabilities".  Indeed, I'd not allow KDCs to grant more privilege to
users than some set (though they should be allowed to assert fewer
privileges).  But if you locally grant any users additional access then
the KDCs that can pretend to be those users can still gain that access.

You seem to be conflating group memberships with privileges.  But there
is a difference: realm A can refuse to allow realm B ot make statements
about users' memberships in realm A's groups, whereas there's no such
thing as realm A's privileges (in the sense that I use that word).

Thus there's no difference in saying "realm A does not allow realm B to
authenticate users in realm A" and "realm A does not allow realm B to
assert membership in groups in realm A"...

..._as long as_ there is a way to name groups such that we can determine
their realms from their names.  SIDs do just that.  So do NFSv4-style
group names.

> before they will be able to access some of your resources.

Doesn't change the rogue KDC problem.

> access is controlled based on privileges/group memberships rather

Indeed, but no one is proposing such a thing.  You're either defeating
your own straw man, or confused.

Nico