Subject: [kitten] PKCROSS comments

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Tue, 28 Oct 2014 22:21:05 +0000

Me likey. Congrats on a much evolved draft!

Section 2.1: "in with" should be "with":
A Kerberos client in with a ticket-granting ticket (TGT) for any one
   source realm (usually but not necessarily the client's own realm)

Section 2.2:

"it allows participation by clients that do not

   support client-driven PKCROSS (or whose PKCROSS requests are rejected

   by the target)."

Why would a target realm reject a client but issue an ITGT to a TGS from the same realm? Isn't it more or less the realm which is being evaluated for trust? Clients can't vouch for themselves.

Section 2.2.1 (mis-spelled Authenticator)

Section 2.6: for symmetry's sake, should there be a mechanism for a target KDC to hint to the source KDC that constantly requesting an ITGT is annoying and permanent long term keys are going to be required (for them)?

Section 3.2: add PARENT : "...pair-wise trust PARENT and "child" realms."

Section 5.2: Do we pass the transit path policy from KDC to KDC? I'm not convinced that a common policy language is useful except for such a case. Why would a target KDC want to know a foreign site's advertised policy? Why would target KDC trust that the foreign site applied the policy as written? Transit paths, at least, are constructed in such a way that you can't edit yourself out.

If PKCROSS really succeeds, the main function of a KDC will be to act as an "identity firewall". It handles the coarse-grained, realm wide decisions about which identity sources are made available to local services. Firewalls don't try and share their configuration information with each other. They just drop the connection. The KDC probably should too. Too much sharing can be bad.

Section 5.3:

A] do routing algorithms for network addresses take into account "one-way connections"? I can easily see a KDC in an organization's DMZ accepting PKCROSS, and having manually keyed cross-realm TGT from the internal realm to the DMZ realm. The effect would be to donate institutional users to the global Kerberos ecosystem without allowing external users access to internal services.

B] It seems likely that connecting to an external organization will either be a one-hop affair via PKCROSS or completely impossible. (e.g., it seems weird to permit manual keying of cross realm principals from a realm that can PKCROSS, but not allow PKCROSS yourself.) What would a trust router do?

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: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Oct 2014 18:32:11 -0400 (EDT)

On Tue, 28 Oct 2014, Nordgren, Bryce L -FS wrote:

> B] It seems likely that connecting to an external organization will
> either be a one-hop affair via PKCROSS or completely impossible. (e.g.,
> it seems weird to permit manual keying of cross realm principals from a
> realm that can PKCROSS, but not allow PKCROSS yourself.) What would a
> trust router do?

Some discussion a couple years ago about federation for the Zephyr instant
messaging protocol proposed a scheme where the GRAND.CENTRAL.ORG kerberos
realm could be a central hub for cross-realm traffic, in that it would
freely peer with ~anyone, for the asking.  I don't necessarily think that
exactly that will happen, but it seems at least vaguely plausible that
smaller versions could happen, wherein, say, EXAMPLE.EDU would actively
initiate pkcross for a shared key with INTERNET2.EDU but wouldn't accept
incoming pkcross from EXAMPLE.COM.  But, maybe INTERNET2.EDU would accept
that pkcross from EXAMPLE.COM, and act as a hub for cross-realm traffic.

Just some idle speculation...

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 18:05:11 -0500

On Tue, Oct 28, 2014 at 10:21:05PM +0000, Nordgren, Bryce L -FS wrote:
> Why would a target realm reject a client but issue an ITGT to a TGS
> from the same realm? Isn't it more or less the realm which is being
> evaluated for trust? Clients can't vouch for themselves.

Perhaps because it wants to minimize PK operations.

Let's say we have realms A and B, with clients in A trying to talk to B
using PKCROSS.  If the number of clients in A wishing to talk to
services at B exceeds the number of KDCs in A, then it's a win to force
A clients to use TGS-driven PKCROSS.

B's KDCs might decide this heuristically even ("huh, 1,000 PKCROSS
requests from FOO.EXAMPLE in the last hour; they should use TGS-driven
PKCROSS").

I should have explained this, yes.

> Section 2.6: for symmetry's sake, should there be a mechanism for a
> target KDC to hint to the source KDC that constantly requesting an
> ITGT is annoying and permanent long term keys are going to be required
> (for them)?

Maybe!  But long-term symmetric keying of cross-realm principals on
demand can also be a DoS, so for now I'm thinking symmetrically keying
x-realm principals should still involve some manual process, though the
actual keying be automatic.

Presumably the ITGT burden wouldn't be too great.  Even if you have 100
KDCs, if you issue 24hr ITGTs then that's only about 4 requests
per-hour.  Even if multiple threads in the KDCs race to do this, since
the KDCs can keep track of which ITGTs are actively used, they can
refresh them before having to race to get fresh ones.

But sure, a hint about this would be nice.  (Yet another reason to
extend EncKDCRepPart..., since that's where the hint would have to go.)

It might even be possible for KDCs in a realm to share ITGTs with each
other, thus further reducing load from the marginal to the utterly
insignificant.

> Section 5.2: Do we pass the transit path policy from KDC to KDC? I'm
> not convinced that a common policy language is useful except for such
> a case. Why would a target KDC want to know a foreign site's
> advertised policy? Why would target KDC trust that the foreign site
> applied the policy as written? Transit paths, at least, are
> constructed in such a way that you can't edit yourself out.

That made more sense before I split out 5.3.  In the world of MIT krb5
and Heimdal we have that dreaded [capaths] section of krb5.conf.  It is
used for *both*, routing and transit path validation.  And yes, it needs
to be kept in sync -- not that a realm admin has to accept other realms'
_policy_, but that: a) multi-realm transit paths result for various
reasons and it's often useful to know about a peer realm's paths to
others, b) you still need to distribute your realm's [capaths] to its
clients and services.

Separating policy from routing would be handy.  Being able to specify
routing differently from the client principal's _realm_'s perspective,
rather than the client host's, would be handy.  Having something better
than [capaths] would be very nice.

> If PKCROSS really succeeds, the main function of a KDC will be to act
> as an "identity firewall". It handles the coarse-grained, realm wide
> decisions about which identity sources are made available to local
> services. Firewalls don't try and share their configuration
> information with each other. They just drop the connection. The KDC
> probably should too. Too much sharing can be bad.

Well, it _could_.  It could also just let any client in its realm(s)
talk to any remote realms.  And it couldn't stop clients from using the
client-driven PKCROSS protocol anyways.

But with TGS-driven PKCROSS there's the ability to use PAC/CAMMAC for
selective disclosure of identifying information, as well as anonymous
tickets (to prevent disclosure of the client's cname, but not crealm).

I'm leaving this out of scope for now.  The KDC can apply policy without
an I-D telling it.  So can the client (e.g., ask for an anon ticket, ask
to include specific authz-data).  It's only where the client can ask for
KDC-issued/signed/vouched authz-data that we'd have a protocol to
describe.

> Section 5.3:
> 
> A] do routing algorithms for network addresses take into account
> "one-way connections"? I can easily see a KDC in an organization's DMZ
> accepting PKCROSS, and having manually keyed cross-realm TGT from the
> internal realm to the DMZ realm. The effect would be to donate
> institutional users to the global Kerberos ecosystem without allowing
> external users access to internal services.

If they don't then it can be added into the "address" scheme.  The point
here was that trust paths could be constructed using OSPF and similar
(I've got code lying around somewhere that applies SPF to simpified
capaths data, but a protocol would be nice).

IIRC ABFAB has a trust routing protocol.

Active Directory has a trust router (and protocol: the information is
exchanged via the AD global catalog).

> either be a one-hop affair via PKCROSS or completely impossible.

Yes (not counting the DNSSEC "hops"), which tends to lessen the need for
this.  I pointed that out.  But it doesn't eliminate it completely,
since there will remain non-fully-PKCROSS environments for a long time.

> (e.g., it seems weird to permit manual keying of cross realm
> principals from a realm that can PKCROSS, but not allow PKCROSS
> yourself.) [...]

What's weird?  Asymmetry?  Or something else?

>      [...] What would a trust router do?

A trust router would be used to exchange information about x-realm
principals *not* including PKCROSS *but* including information about
which realms can do TGS-driven PKCROSS.  The router would then use this
and local policy (e.g., don't traverse any realms through realm FOO) to
compute a path from a crealm to an srealm.

I'm expecting that in the beginning existing sites will generally prefer
to continue with whatever capaths mess they might have for policy
reasons (even if they later automatically re-key their x-realm
principals), with trust paths reflecting internal organization, say.
But there's no reason to make this a heavily manual process other
than... that's what it is and has been.

Glad you liked this iteration of the I-D, and thanks for the comments,

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Oct 2014 18:10:28 -0500

> Just some idle speculation...

I don't think it's all that idle :)

For one, a realm's KDCs might not support PKCROSS for a long time, not
even kx509 or similar.  One could setup a realm just to handle PKCROSS
to [the world] as a method of coping with the main realm's lack of
support.

But also, a local realm to funnel PKCROSS through could function as a
"identity firewall" as Bryce mentions, and this too might be a
workaround other realms' KDCs lack of "identity firewall" functionality.

Nico
--