Subject: [Ietf-krb-wg] Thoughts on the Kerberos (and other) trust model and PACs/PADs

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Dec 2010 02:00:46 -0600

At last Friday's concall regarding Simo's proposal for a generic PAC
("PAD") we discussed trust model all too briefly.  Here are some
thoughts regarding the Kerberos trust model in the face of PACs.

1.  Some important questions we need to answer are:

    a) what are the responsibilities of KDCs along the path from a
       crealm to an srealm (inclusive of both)?

    b) what limits must services impose on what their KDCs (and others
       along the transit path from crealm to srealm, inclusive of both)?

2.  Consider a set of realms with bi-directional x-realm paths from any
    one realm to any other.  Now consider Kerberos without any kind of
    authorization data describing the cname.  A service might need to go
    do, say, LDAP searches to obtain authorization-relevant information
    about the cname.  Say all those LDAP searches involve the use of
    SASL/GSSAPI/Kebreros authentication of the service (acting as an
    LDAP client) to the LDAP servers.

    Well, the service's realm's KDCs (as well as others on the path to
    the realms of the LDAP servers) can mount MITM attacks on the LDAP
    client.  In other words, I'm restating the basic fact of Kerberos:
    KDCs are trusted third parties, meaning that if you want to use
    Kebreros, then you have to trust the KDCs.

    PKI has the same problem.  CAs are trusted third parties.  Any
    cryptographic protocol that has trusted parties will have this
    problem by definition, from the 'trusted' in "trusted third party.

3.  Now consider a set of realms where some realms only have
    uni-directional paths other realms.  (This is, I understand, one of
    the main problems that Simo is interested in addressing.)

    Here a service would not always be able to perform LDAP searches
    against a crealm's LDAP servers for lack of a path from the srealm
    to the crealm.  (The path from crealm to srealm exists, but the
    reverse might not, and in some cases will not.)  In which case what
    is the service to do in order to obtain authorization information
    related to the cname?

4.  Given the above, I think that short of introducing public key
    signatures for PACs (but don't get excited about those yet, see
    below), we should answer (1a) and (1b) as follows:

    1b. Services must perform a number of checks: a) that the crealm->
    srealm transit path is allowed by policy, b) that authorization-data
    elements make no assertions involving realms/ domains outside the
    transit path, c) that policy allows KDCs to make the remaining
    assertions.  (c) does not exist, but because of (2) it seems
    reasonable to say that the default policy for (c) should be the same
    as for (a).

    1a. KDCs must apply the same policy checks (though not necessarily
    with the same _policy_) to x-realm TGTs as services apply to service
    Tickets.  Services often lack transit policy; KDCs must not.
    However, per-RFC4120, KDCs must also issue the next Ticket even when
    the client x-realm TGT is out of policy, setting the transited-
    policy-checked Ticket flag if the policy checks pass.

We may want to add a PAC/PAD analog of the transited-policy-checked
Ticket flag.  IMO, we should.

5.  (3) is not that special a case.  If there are uni-directional
    x-realm paths, and the only way to get necessary authorization data
    is via a PAC addded by the crealm's KDCs, then the services have to
    either trust it or not -- there's no in between, nor any
    alternative.  Convenience dictates that they will trust it (modulo
    local policy).

6.  Distribution of policy to services is likely to be done by the same
    administrators as administer the services' realms.  Service-side
    policy checking as a way to constrain their KDCs seems like a very
    useful option, but also a constrained tool requiring case-by-case
    administration.

In other words, there's nothing really new here.

7.  KDC issued authorization data elements could be signed with public
    keys...  This would prevent tampering -- even removal, if done right
    -- and would solve the validation problem (no need to ask KDCs to
    validate their non-public key signatures) but it'd create new key
    management issues: how would services learn these keys without
    having to trust their own realms' KDCs?  The only decent answer to
    that is: PKI, which doesn't solve the trusted third party problem.

    Public key signatures would still be useful as a way to facilitate
    off-line authorization-data signature verification, but not really
    as a way to solve the trusted third party problem.

    By distributing realm certificates to services, for use as
    constrained trust anchors or pre-shared EE certificates, the
    services' (and transit) realms can be checked.  But this isn't
    scalable.  A leap-of-faith public key learning system would scale
    better, at the cost of some interaction (a no-no for services), such
    as when realms/KDCs are re-keyed.

Shorter version: there's no easy way to avoid trusted third parties in
Kerberos, PKI, nor, most likely, in other scalable, _distributed_
authentication systems.  There is the PGP web-of-trust mitigation, aside
from which the best that can be done is to constrain the set of entities
to trust, and thus the set of trust paths, on a service-by-service
basis.

IMO, support for service-side policies, including local policy, is
something that ought to be REQUIRED by distributed authentication system
standards.

Nico
-- 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 21 Dec 2010 11:22:13 -0500

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Nicolas Williams
> Sent: Tuesday, December 21, 2010 3:01 AM
> To: [email-masked]
> Subject: [Ietf-krb-wg] Thoughts on the Kerberos (and other) trust model
> and PACs/PADs
> 
> authentication systems.  There is the PGP web-of-trust mitigation,
> aside from which the best that can be done is to constrain the set of
> entities to trust, and thus the set of trust paths, on a service-by-
> service basis.

Thanks Nico.  Folks in the identity world are grappling with this right now in the form "Trust Frameworks" that allows for a more standardized contracts as well as a more automated contract-exchange process.

With regards to your excellent list of items abovem do we need to add any (all) of these to the re-charter of KRB WG?

If I had to add one more potential field to the PAC, it would be the LOA (Level of Assurance) field.  This would capture the "quality" of the authentication performed by the KDC, and would indicate such things as whether the client principal used a hardware token for the shared keys, hardware OTP dongles (versus software), smartcards, etc. etc.

/thomas/

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Dec 2010 11:01:43 -0600

On Tue, Dec 21, 2010 at 11:22:13AM -0500, Thomas Hardjono wrote:
> Thanks Nico.  Folks in the identity world are grappling with this
> right now in the form "Trust Frameworks" that allows for a more
> standardized contracts as well as a more automated contract-exchange
> process.

Note that bilateral contracts can amount to ad-hoc trust, and coupled
with distributed authentication systems they amount to local policy.
Bilateral contracts can also cover to the "service-side interaction"
that I mentioned.  I think it would be great if it turned out that for a
very large subset of the Internet a combination of ad-hoc trust and
distributed authentication could scale just fine.

> With regards to your excellent list of items abovem do we need to add
> any (all) of these to the re-charter of KRB WG?

I don't think so -- perhaps public key signatures for the PACs.  Mostly
I wanted to address Sam's concerns that we had a new trust problem --
IMO we do not, and the existing trust problem is only worse if you'd
have services that used to not do LDAP (or whatever) searches now rely
on PACs.

> If I had to add one more potential field to the PAC, it would be the
> LOA (Level of Assurance) field.  This would capture the "quality" of
> the authentication performed by the KDC, and would indicate such
> things as whether the client principal used a hardware token for the
> shared keys, hardware OTP dongles (versus software), smartcards, etc.
> etc.

Sure, but that's a different issue -- you'd still have to trust the KDC
to provide that LOA.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Dec 2010 16:57:47 -0600

One thing I left out is that transitive trust is problematic.  And we
have it in the off-line world too.  Contractual relationships help
address this (removing the trusted third party to a dispute resolution
role) in the off-line world.  An approximate analog in the online world
is, effectively, I think, leap-of-faith learning of public keys or
establishment of shared secrets with transitive trust (distributed
authentication) used to learn the keys or protect the key exchanges.

The best way to limit the scope of attack by trusted third parties is to
force them to be MITMs at very specific times, and, preferably also
always thereafter, or not at all.  This creates re-key problems, which
ultimately require either key rollover protocols, or interaction on the
service side (oops), or a willingness to re-do the leap-of-faith every
so often (thus widening the window of opportunity for dishonest trusted
third parties).

Note that Kerberos KDCs are always in the loop, which means that
defeating them requires additional steps not currently built into
Kerberos.  PACs/PADs will serve to further force KDCs into the loop[*],
so that the only way to limit trust in the case of PACs/PADs is to have
issuers sign them with public keys, then have services learn those
public keys as mentioned above (and earlier).

[*]  Imagine apps that can use TLS, with server _and_ client certs,
     SASL/GS2/Kerberos, and channel binding, and that the client and
     server both learn each other's certificates such that subsequent
     communications between them can elide the use of Kerberos.  Now
     imagine that the server application wants a PAC/PAD...  that means
     that Kerberos is needed even after TLS certs are learned.  Now, the
     server could turn around and do the LDAP searches it might need,
     but a) that's inefficient, b) it requires bi-directional trust[**].

[**] Have I mentioned that I'm no fan of uni-directional trust?  I
     realize that it's commonly used, but ISTM that it's often used as a
     very large [effective, and easy-to-use] authorization hammer.  But
     it creates problems that other ways of expressing policy do not.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Dec 2010 17:09:29 -0800

> If I had to add one more potential field to the PAC, it would be the LOA (Level of Assurance) field.  This would capture the "quality" of the authentication performed by the KDC, and would indicate…

The name has a very US/FIPS connotation.  While that's certainly a useful application, I think what makes sense for IETF is what you go on to say:  something that indicates the original authentication method.  Maybe an attribute with the PA-DATA type.

Does anyone else have a (simple!) use case calling for more?  I know people can come up with fancy authorization systems that need more;  I'm wondering if someone needs to e.g. distinguish PIV, vice PIV-compatible, vice PIV-interoperable smart cards as a for instance.

---

I'm in favor of the field, but I think it's out of the declared scope of a PAD that's only supposed to provide POSIX information.  Anyone want to write a really simple and short RFC for just the one item?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 21 Dec 2010 17:33:57 -0800

I am generically uncomfortable with the complexity of PAD attestation in the general cross-realm case.  Seems like a problem waiting to happen.

I'm particularly uncomfortable with the idea of using PKI to sign PAD's.  Sounds like a deployment nightmare.  The whole point of putting authorization data in the ticket in the first place is to leverage the same crypto that was used to guarantee the client authentication.  Seems like we've convinced ourselves that isn't good enough.  

I'm questioning if the need is great enough to justify all the resulting complexity, attack surface, and risk of misunderstandings.  (Especially the last.)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Dec 2010 20:05:46 -0600

On Tue, Dec 21, 2010 at 05:33:57PM -0800, Henry B. Hotz wrote:
> I am generically uncomfortable with the complexity of PAD attestation
> in the general cross-realm case.  Seems like a problem waiting to
> happen.
> 
> I'm particularly uncomfortable with the idea of using PKI to sign
> PAD's.  Sounds like a deployment nightmare.  The whole point of
> putting authorization data in the ticket in the first place is to
> leverage the same crypto that was used to guarantee the client
> authentication.  Seems like we've convinced ourselves that isn't good
> enough.  

Attestation could be done without PKI, and, in fact, that's what I had
in mind.  But I also wasn't proposing that.  I was exploring Sam's
comments on Friday regarding trust.  My aim was to establish whether or
not we had a new problem.  We would have a new problem IF applications
did (or could) do leap-of-faith public key learning mediated by
Kerberos.  They don't today, but they could if we tried.  So we do have
a new problem, potentially.  The solution is to either not bother with
PACs/PADs, or to sign them with public keys (again, not necessarily PKIX
certificates).

> I'm questioning if the need is great enough to justify all the
> resulting complexity, attack surface, and risk of misunderstandings.
> (Especially the last.)

Well, it all depends on how much transitive trust you can handle.
Perhaps you can trust your realm's KDCs, but, can you trust all realms
that might be needed to transit to yours?

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Dec 2010 00:52:55 -0600

I should note separately what I noted in my reply to Henry, that there
is a way in which PACs change the trust model: without public key
signatures of PACs by their issuers there is no way to check the degree
to which one must trust KDCs, as there is no way to limit the
circumstances in which one must trust them.  Of course, existing
Kerberos applications do not attempt to limit the extent to which they
trust KDCs beyond transit path checking, so the change does appear to be
superficial, but I am starting to think that it's more obnoxious than
I'd like.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 22 Dec 2010 14:48:43 -0800

> that might be needed to transit to yours?

Framed that way, you make it sound like a deployment question rather than a crypto/protocol question.  Whatever crypto/protocol solutions we provide should, in the end, provide a "clean" enough promise of data validity that most deployers are not surprised.

On further reflection, I conclude that authorization is a different problem from authentication.  (Duh!)  And that the signatures/attestation/whatever needed are therefore fundamentally different.

Not sure if this email is useful, but I'm sending it as a partial retraction of earlier comments.  Still believe reusing existing cross-realm stuff is desirable, but no longer convinced it's possible.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 23 Dec 2010 17:53:05 -0600

On Wed, Dec 22, 2010 at 02:48:43PM -0800, Henry B. Hotz wrote:
> >> resulting complexity, attack surface, and risk of
> >> misunderstandings.  (Especially the last.)
> > 
> > Perhaps you can trust your realm's KDCs, but, can you trust all
> > realms that might be needed to transit to yours?
> 
> Framed that way, you make it sound like a deployment question rather
> than a crypto/protocol question.  Whatever crypto/protocol solutions
> we provide should, in the end, provide a "clean" enough promise of
> data validity that most deployers are not surprised.

The protocol question is about what choices we have for both,
implementation and deployment.  For example, though I know of no
existing applications that use Kerberos to authenticate and then learn
TLS client and server certs, it would be possible to implement such
apps.  Thus implementors and users could choose to deploy Kerberos for
authentication and LDAP (or whatever) for resolving authorization
context in such a way as to limit the opportunities for KDCs to be
undetected MITMs.

But if there's uni-directional x-realm trusts and unsigned PACs, then
the only choices implementors (and users) have are to either trust or
not trust the KDCs -- there'd be no choice to limit the KDCs'
opportunities to be MITMs.  Losing that choice is bad, even if we never
exercise it today.

> On further reflection, I conclude that authorization is a different
> problem from authentication.  (Duh!)  And that the
> signatures/attestation/whatever needed are therefore fundamentally
> different.

They are different, but that's not the issue here.  The issue is how
what I call "authorization context" (information about a peer principal
needed for making authz decisions) is obtained and authenticated.

Authentication _is_ the issue in this thread, and the _only_ issue at
that.

> Not sure if this email is useful, but I'm sending it as a partial
> retraction of earlier comments.  Still believe reusing existing
> cross-realm stuff is desirable, but no longer convinced it's possible.

It's possible, and even desirable.  The issue for me is that we should
not prevent the use of Kerberos for pair-wise trust bootstrapping.

I started out believing that there was no new trust problem here.  I
still believe that, but I believe I've shown that without public key (or
secret key, with a protocol for verification) signatures of the PACs
("attestations") we'd lose a choice that we have today that is not worth
losing.

I've said this before, several times, in IETF contexts: transitive trust
is mostly useful for bootstrapping pair-wise trust -- it's the only way
to scale transitive trust systems to global (Internet) scale, and also
the only way to scale pair-wise trust that same scale.

"Transitive trust" here refers to any authentication system involving
trusted third parties.  You trust one peer, "A", because another peer,
"B" you trust tells you how to authenticate "A".  Add in long transit
paths and the set of entities one has to eventually trust becomes too
large for comfort.

One alternative is to limit transit path length (think PKCROSS).  But I
don't think that's as practical as bootstrapping pair-wise trust via
transitive trust (realms' KDCs still need to find a way to learn each
others' public keys, and PKI is not a very good answer for that).
(Perhaps we could have a way to bootstrap PKCROSS via hierarchical, all-
symmetric key Kerberos.  Then this transit path length limitation
alternative might be realistic.)

Another alternative is to avoid PACs/PADs and uni-directional x-realm
trusts altogether.  Then implementors (and users) could still exercise
the choice of learning public keys of Kerberos-authenticated peers.

What I'm really getting at is that I'd like public key signatures for
PACs/PADs, plus a protocol (possibly also an authorization data element)
by which the public keys (certificates, really) can be learned.

Also, another observation about uni-directional x-realm trusts: in any
large set of realms, very few realms have the choice of being trusted by
the others, but not trusting them back.  Uni-directional x-realm trusts
don't scale -- they are a tool abused as a big authorization hammer, and
nothing more.  I'd rather declare uni-directional x-realm trusts to not
be supported.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 23 Dec 2010 18:30:29 -0800

Need to digest your reply (and this whole thread) better.  May take a while.

Season's greetings everyone.

> nothing more.  I'd rather declare uni-directional x-realm trusts to not

This doesn't qualify as "large", but if you split users and services into different realms, then there doesn't appear to be any need for a two-way trust.  Suppose you have three ways for users to authenticate (password, OTP, and smart card) and 2-3 different DNS domains with all your machines in them.  Every class in that list has it's own realm.  Maybe machines in the different DNS domains need to authenticate to each other, but I think the use case of a machine authenticating to a user is pretty obscure.

I can think of several other scenarios that would be driven by organizational trust issues rather than technology.  I have a moderately important demo that I was only able to do because I only needed 1-way trust with two untrusting production realms.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 24 Dec 2010 00:53:57 -0600

> Season's greetings everyone.

Yes, happy holidays to one and all.

> This doesn't qualify as "large", but if you split users and services
> into different realms, then there doesn't appear to be any need for a
> two-way trust.  Suppose you have three ways for users to authenticate
> (password, OTP, and smart card) and 2-3 different DNS domains with all
> your machines in them.  Every class in that list has it's own realm.
> Maybe machines in the different DNS domains need to authenticate to
> each other, but I think the use case of a machine authenticating to a
> user is pretty obscure.

The conventions needed to name realms and discover configuration for
such setups do not exist, much less are they coded.  That makes
deploying such setups difficult.  Not impossible, mind you, but a royal
PITA.  Interoperating in a large (many realms) environment where every
few realms are like a Picasso etching (unique, different, ...) is bound
to be difficult.  Note though that if you're willing to do strange
things then you could also make it so those services can perform the
LDAP searches they need to in order to obtain user principal's
authorization context data.  PACs are just an optimization in that
model, and they might as well be added to the Tickets by the services'
realms' KDCs... besides since such deployments are likely to be small
(in terms of number of realms) trust in KDCs is likely not an issue and
no PAC public key signatures are necessary.

Are you proposing that we standardize such conventions?  Whose?  If not,
then how are implementors to know what users will require?

And what value do such conventions yield?  Why does one need uni-
directional x-realm trust instead of policy (service principals can't
get issued Tickets with user principals as snames)??  Is it so difficult
to configure and enforce such policies??

> I can think of several other scenarios that would be driven by
> organizational trust issues rather than technology.  I have a
> moderately important demo that I was only able to do because I only
> needed 1-way trust with two untrusting production realms.

"Organizational trust" != "Kerberos cross-realm trust" -- there's a
relationship between the two, but they are not the same.  Indeed, I'd
recommend against per-OU realms: they make IT support much less dynamic
in the face of changing business organizations, thus raising the cost of
re-organization.  Business executives should not be constrained in their
organizational decisions by poor IT planning.  Realms, like DNS domains,
should be associated only relatively coarsely with organizational
structure.  Nor should a single, company-wide realm imply that
administration privileges cannot be finely constrained.

The problem here lies partly in the use and abuse of the word "trust".
X-realm trust does not, should not, and must not imply any further
trust, right to logon or access any resources.  Sadly, uni-directional
x-realm trust immediate disables certain [kerberized! and only
kerberized] operations without need for any additional policy, and that
fact proves too tempting, but I do think it's an error to overuse
uni-directional trust in that manner.

Cheers,

Nico