Subject: [kitten] PKCROSS and philosophical tangents...

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 29 Jan 2014 19:01:31 +0000

Nico and company.

I hope this isn't out of line. I spend quite a lot of time thinking about this, as much of my job involves trying to collaborate with others.

Tangent #1: What is "authentication"?

I would like to propose that authentication is not sharing a secret with a KDC. In my organization, authentication is a background check by law enforcement. Once the paperwork has completed with a successful result, the CIO is then instructed to create an account for the authenticated user. Other organizations will have different processes, but the domain admins rarely authenticate users themselves. At the very least, HR and the employee's supervisor does that.

In a closed corporate/enterprise environment, this is the whole story. However, when you must collaborate with external partners, different authentication methods are introduced.

PKCROSS introduces a paradigm where entire foreign domains are authenticated by a certificate authority, to varying degrees of rigor. The essential characteristics of this paradigm are: 1] granular authentication: entire domains are accepted or rejected as an atomic unit; and 2] delegated authentication: the user's identity is only as certain as the policies and procedures employed to verify that identity prior to giving them an account. In this situation as with internal users, domain admins will probably not be afforded the discretion to choose which foreign domains will be cooperated with.

I would like to propose a third type of authentication: a "Sponsored external user". This paradigm assumes a home-user-driven need to cooperate with very specific groups of individuals from other institutions on specific activities. These external users are authenticated to the sponsor by the sponsor's ongoing observations of their actions during the execution of the project. Such projects usually occur because the sponsor interacts with the external user during the formulation of the project proposal, and there is usually some formal definition of project roles and distribution of money to the various participants. Some projects may be informal, and may not involve funds. However, it is almost certain that prior to sponsoring the external user, the individuals in question have been authenticated to the sponsor by some means other than their home domain's credentials. A human web of trust may be established, where the sponsor knows the leaders from the foreign institutions, and these leaders have requested that their support staff or graduate students be provided access to the project's resources.

Characteristics of the "sponsored external user" paradigm are: 1] fine-grained authentication: individuals are accepted or rejected; 2] delegated authentication: the "trust anchor" in this case is the sponsor, who may then delegate the choice of participants to leaders from other institutions; 3] accountability and responsibility: the buck stops with the sponsor; 4] human trust anchor aggregation: if several sponsors affirm several identities from the same foreign realm, confidence in that realm's identity should be high; 5] sponsored external users may or may not come from a foreign realm (e.g., the home realm may configure a "collaboration realm" to contain all the untrusted users and hosts as part of a larger effort to manage risk to the corporate systems.)

The bottom line is that cross-realm operation fragments the authentication process. More tools may be necessary to manage this fragmentation and reduce or distribute the administrative burden over the principals in the home realm. To reduce administrative burden, PKCROSS delegates authentication to a certificate authority and further delegates to the unspecified vetting process of the foreign institution. "Sponsored external users" keeps the trust anchors closer to home, focuses authentication decisions on a smaller group, and distributes rather than reduces the administrative burden.

I think what I would like to see in an RFC or draft is a general discussion of how to securely set up a collaborative environment using Kerberos, which then dives into specific, standardized technical solutions. I am certain that PKCROSS will play a large role, but I want to see such a document also handle the case where the external user does not have a home Kerberos realm. How does that user get injected into a Kerberized environment in a way that does not imply that any of the large Kerberized organizations are taking responsibility for them?

Ok, I'd better stop with tangent #1. ;) Thanks for your patience.

Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Jan 2014 17:56:38 -0600

On Wed, Jan 29, 2014 at 07:01:31PM +0000, Nordgren, Bryce L -FS wrote:
> I hope this isn't out of line. I spend quite a lot of time thinking
> about this, as much of my job involves trying to collaborate with
> others.

It's not only not out of line, it's very welcomed.

> Tangent #1: What is "authentication"?

That's a long topic.  For the sake of brevity, and to answer your more
concrete questions/proposals, I'll not go down this tangent :)

> PKCROSS introduces a paradigm where entire foreign domains are
> authenticated by a certificate authority, to varying degrees of rigor.

A "varying degree of rigor" (I like the phrase) is exactly it.

It's already the case in pretty much all distributed authentication
systems, including Kerberos w/o PKCROSS, including PKIX, and so on.

Grow your world of actual and potential peers large enough and any
assumption that "can authenticate" == "someone I can trust" evaporates.

> [...]

> I would like to propose a third type of authentication: a "Sponsored
> external user". This paradigm assumes a home-user-driven need to
> [...]

This smells to me more like authorization than authentication, but it
can be seen either way, and it really depends on what operational
details you'd like to have involved.  If "sponsorship" means that the
sponsor has to provide a KDC-/CA-/IdP-like infrastructure for sponsees,
then it's really authentication, but also a pain.  If what you have in
mind is more like writing down somewhere that a sponsee [whose identity
must be possible to establish in roughly the same way every time,
perhaps every time after the first] can do this or that, then it's more
like authorization, and much easier to manage.

Treating this as authorization is much easier, but it does require that
you be able to demand repeatability from authentication of the sponsee.

You may not care who a peer's IdP/CA/KDC is, as long as it stays the
same and the trust path for authenticating the IdP/CA/KDC stays the
same.  If you can see to this then it's easier to view this as
authorization.

> 4] human trust anchor aggregation: if several sponsors affirm several
> identities from the same foreign realm, confidence in that realm's
> identity should be high;

You still get this if you treat this as delegated authorization, again,
provided that you have a way to authenticate the "several identities'"
[presumably] common credential issuer reliably.

Nico
--

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Thu, 30 Jan 2014 05:30:00 +0000

New comment
---
PKCROSS seems to me to be about providing agility while preserving accurate identification. It seems that a section on distributed CA schemes may be warranted, if only to put the full PKI scheme in context. OTOH: Is it worthwhile to allow implementers to provide alternative methods of evaluating trust in certificates? Omar, 2009 gives an overview that I found helpful. I put some references below which may be useful for the draft.
---

Response
---
This is another long post, but it can be summed up as "agile is good", "the whole world is not Kerberos", "let users induct their pals into the Kerberos universe" and "share the load".  The various axioms and corollarys below are the main points I'd want to see given technical expression.

> -----Original Message-----

Sorry for the lengthy post. I need to hammer out a solid conceptual framework before working out technical issues (which then need to tie back into the conceptual framework pretty directly).

> A "varying degree of rigor" (I like the phrase) is exactly it.

:)

> assumption that "can authenticate" == "someone I can trust" evaporates.

Ahh, axiom #1: Accurate identification does not equal trustworthiness (e.g., I've known him all his life; he's still a jerk)

> This smells to me more like authorization than authentication, but it can be
> seen either way, and it really depends on what operational details you'd like
> to have involved.  If "sponsorship" means that the sponsor has to provide a
> KDC-/CA-/IdP-like infrastructure for sponsees, then it's really authentication,
> but also a pain.  If what you have in mind is more like writing down
> somewhere that a sponsee [whose identity must be possible to establish in
> roughly the same way every time, perhaps every time after the first] can do
> this or that, then it's more like authorization, and much easier to manage.

My conceptual model is an agile, Kerberized, collaborative environment. I expect that some partners may not have Kerberos identities in any realm. (Perhaps they are a contractor working out of their home.) A conceptual mechanism is needed to induct these poor wayward souls into the realm of "The Identified" so that everyone can play in the same sandbox.

Those who work for big organizations with Kerberos infrastructure have been "sponsored" by the organization. This relationship is made explicit by the fact that their credentials are principals in the mother organization's realm.

When credentialed individuals sponsor a wayward, non-Kerberized soul, I think this also needs to be explicit....and of course distinct from the "organizationally sponsored users". And since the topic is cross-domain trusts, the KDCs need to be able to communicate this distinction to each other. It can be simple, like creating principles in a subdomain with a standard name ([email-masked]). Or perhaps using the sponsor's complete principal ID as the instance (contractor_c/[email-masked] @ EXAMPLE.COM). Or a combination of both. Or something else.

Axiom #2: Can't be authorized until you're authenticated.
Corrolary: Authentication involves identifying both you and your sponsor...

> You may not care who a peer's IdP/CA/KDC is, as long as it stays the same
> and the trust path for authenticating the IdP/CA/KDC stays the same.  If you
> can see to this then it's easier to view this as authorization.

I'll do you one better. I don't care who a peer's IdP/CA/KDC is ever. I also don't care if they don't have one at all. ;) If I tell a cooperator to connect to my system and they can't because a trust path isn't configured right...well, I want a way to assert to the system that the credentials presented are indeed valid even if they're self-signed (for a small-potatoes KDC)...or that new Kerberos credentials should be allocated with me as the sponsor (for someone who doesn't want to stand up their own KDC). And then I expect the system to get out of the way. :) It's trust path is me.

Axiom #3: Users will form collaborations without regard to the compatibility of the partner organizations' infrastructure.
Corollary: It should be possible to distribute the extra administrative overhead of technologically ill-conceived collaborations.
Corollary: Friends don't make friends learn Kerberos. :)

> You still get this if you treat this as delegated authorization, again, provided
> that you have a way to authenticate the "several identities'"

I brought this up because my spidey senses are tingling. Too early to say for sure, but ... well, currently, KDCs act as central points of control over some sphere of influence. It seems that if the peons within that sphere of influence start making decisions about who they choose to trust, KDCs could also act as a concentrator for trust related information...In my world we call such things "Decision Support Systems" and we pay big money to develop them. There is probably value here...somehow...

Bryce

Some references :
Naranjo, J. A. M., F. Cores, L. G. Casado, and F. Guirado. "Fully Distributed Authentication with Locality Exploitation for the CoDiP2P Peer-to-Peer Computing Platform." The Journal of Supercomputing 65, no. 3 (December 5, 2012): 1037-1049. doi:10.1007/s11227-012-0842-2. http://www.cs.georgetown.edu/~clay/classes/spring2013/papers/Fully_distributed_authentication_with_locality_exploitation_for_the_CoDiP2P_peer-to-peer_computing_platform.pdf

Omar, Mawloud, Yacine Challal, and Abdelmadjid Bouabdallah. "Reliable and Fully Distributed Trust Model for Mobile Ad Hoc Networks." Computers & Security 28, no. 3-4 (May 2009): 199-214. doi:10.1016/j.cose.2008.11.009.
http://hal.archives-ouvertes.fr/docs/00/38/90/20/PDF/net-trust-19-02-08.pdf

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 31 Jan 2014 12:50:32 -0500

>PKCROSS seems to me to be about providing agility while preserving
>accurate identification. It seems that a section on distributed CA
>schemes may be warranted, if only to put the full PKI scheme in
>context. OTOH: Is it worthwhile to allow implementers to provide
>alternative methods of evaluating trust in certificates? Omar, 2009
>gives an overview that I found helpful. I put some references below
>which may be useful for the draft.

I come from a relatively flexible universe where we do a lot of
cross-realm, so I've thought a significant amount of this (also, we
have a lot of users who aren't part of our organization).  Here are
my thoughts:

- I personally am not a fan of the term "agile" in this context, because
  it's too vague (what, exactly, do you mean by that?).
- PKCROSS seems to me to want to give you the ability to do regular old
  Kerberos cross-realm without having to actually set up symmetric
  cross-realm keys ... and I've done that a lot, and I can testify that
  it's a huge pain.  But it's still Kerberos aside from that.
- If you need Kerberos to access your site's resources, then you have two
  choices: either a) do cross-realm with some place they do have a principal
  with, or b) give them a principal on your KDC.  That's all backended by
  tedious paperwork and ACL settings, but I think in terms of actual
  technology that's what your choices are.
- In my experience the TECHNICAL issues are relatively straightforward; it's
  dealing with management that's the challenge.

I looked at the papers you posted; they seem interesting, but if the goal
is to use one of those systems to get a Kerberos TGT ... well, I'd wonder
what the advantage would be compared to one of the existing systems.

--Ken

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Fri, 31 Jan 2014 19:05:56 +0000

Good to hear from someone who's done it. I haven't, so I mainly have questions instead of answers. Perhaps I should "briefback" my understanding of the motivation of PKCROSS by rephrasing the intro section:

Axiom: Successful large-scale Kerberos deployments authorize users to maintain their own authentication tokens. (e.g., I can change my own password)
Corollary: The lack of the ability for principals (KDC admins) to update their own tokens in a foreign KDC has inhibited the formation of Kerberos federations, and requires manual coordination between admins which is cumbersome and causes downtime.

In this light, I understand PKCROSS to be a means of automatically keying your KDC's credentials in a foreign system. However, it is unclear to me how these credentials get updated when they inevitably expire (or are stolen). Is that section TBD or am I just dense? I took the draft to say that the initial certificate must stay the same forever or else risk being rejected as a MITM attack. I'm willing to be persuaded, but I'm not quite seeing how the draft addresses the deficiencies it identifies.

PKCROSS to initially key your principal, plus a means to subsequently maintain the authentication tokens for your principal? Well, that addresses the problem statement.

It's possible that account maintenance could be facilitated with a series of recommendations and the corresponding security analyses. Expose your password-changing interface to the wide world and advertise which set of admin tools (MIT/heimdal/MS) are compatible? Stand up a web app which lets you log in and manage your credentials? Extend the base standard with a  "principal management" message exchange? Dunno. It's probably important to specify that sites wishing to support federation SHOULD do certain things, one of which is to ensure that offsite (outside firewall), non-home-realm principals have the means to manage their credentials.

> I looked at the papers you posted; they seem interesting, but if the goal is to
> use one of those systems to get a Kerberos TGT ... well, I'd wonder what the
> advantage would be compared to one of the existing systems.

My purpose in bringing up those papers was not so much to propose a means of getting a TGT as to ask about alternative means of trust evaluation for the CA which signed the foreign KDCs certificate. Does the standard need to specify how trust is evaluated? Should it narrow the field to a handful of identifiable algorithms? Should it start simple but allow for growth?

Thanks for your time!
Bryce

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 31 Jan 2014 14:31:34 -0500

>Axiom: Successful large-scale Kerberos deployments authorize users to
>maintain their own authentication tokens. (e.g., I can change my own
>password)

So, that gets sort of complicated.  I'll explain what we did.

There are two general levels of access we have to our systems.
"Interactive", and "Everything else" (they don't really have these sort
of formal names, but that's what it ended up being).

"Interactive" is an interactive login.  In other words, you login in with
Kerberos rlogin/ssh/whatever and get an interactive shell to do stuff
(obviously this is all Unix based).

"Everything else" is sort of vague, but in general it refers to stuff
that doesn't require an interactive login or something that looks like
that (consider it things that don't require a Unix user account).  This
could be things like web pages or filesystem access.

We only accept interactive logins from a relatively small number of
Kerberos realms (when I say "relatively" I mean "relative to the total
number of KDCs we cross realm with").  We control the mapping from a
particular foreign-realm principal to local Unix account.  That mapping
only happens after a formal account process has been completed.  That
federated group of KDCs all have the same policies, so there's no issue
there in terms of someone not meeting your security policies.  All of the
people in this federation receive funding from the same source, which helped
generated a uniform security policy.

"Everything else" users have a lot lower access, and generally only get
used for a few things.  But it's valuable to have that ability.

>Corollary: The lack of the ability for principals (KDC admins)
>to update their own tokens in a foreign KDC has inhibited the formation
>of Kerberos federations, and requires manual coordination between admins
>which is cumbersome and causes downtime.

When you say "update their own tokens in a foreign KDC", do you mean the
cross-realm principals?  Because that is not true; we rekey our cross-realm
principals on a regular schedule.  Okay, it may be cumbersome and require
manual admin intervention, but it does not require downtime.  And actually,
you COULD rekey cross-realm principals automatically with some programming;
it's one of those things that's on my list to do.

>In this light, I understand PKCROSS to be a means of automatically
>keying your KDC's credentials in a foreign system. However, it is
>unclear to me how these credentials get updated when they inevitably
>expire (or are stolen). Is that section TBD or am I just dense? I
>took the draft to say that the initial certificate must stay the same
>forever or else risk being rejected as a MITM attack. I'm willing to
>be persuaded, but I'm not quite seeing how the draft addresses the
>deficiencies it identifies.

Assuming we're talking about draft-williams-kitten-krb5-pkcross-02.txt ...
as I read it, expiration/stolen principals are dealt with the same way
you'd deal with other stolen credentials in Kerberos.  Generally tickets
expire in a relatively short timeframe, and you'd need to do a new
PKCROSS exchange every time you get a new ticket.  Same issues you have
with Kerberos.

>It's possible that account maintenance could be facilitated
>with a series of recommendations and the corresponding security
>analyses. Expose your password-changing interface to the wide
>world and advertise which set of admin tools (MIT/heimdal/MS) are
>compatible?

Well, we already expose our password changing interface to the world,
because otherwise how are users going to change their passwords?

>My purpose in bringing up those papers was not so much to propose a
>means of getting a TGT as to ask about alternative means of trust
>evaluation for the CA which signed the foreign KDCs certificate. Does
>the standard need to specify how trust is evaluated? Should it narrow
>the field to a handful of identifiable algorithms? Should it start
>simple but allow for growth?

Hmmm ... my opinion is how trust should be evaluated is out of scope for
a document like PKCROSS.  That should be done on a site-by-site basis.

--Ken

---

From: Russ Allbery <[email-masked]>
Date: Fri, 31 Jan 2014 12:18:15 -0800

"Nordgren, Bryce L -FS" <[email-masked]> writes:

> It's possible that account maintenance could be facilitated with a
> series of recommendations and the corresponding security
> analyses. Expose your password-changing interface to the wide world and
> advertise which set of admin tools (MIT/heimdal/MS) are compatible?

Password changes are interoperable provided that they're limited to
operations that can be performed via the kpasswd protocol (and provided
you can deal with the kpasswd protocol, which is rather broken, but
usually workable in practice provided everyone understands the required
assumptions).

You only have to care about the different admin protocols if you need to
support operations other than password change.

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