Subject: [kitten] draft-williams-kitten-krb5-pkcross-01 Comments

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 13 Aug 2013 11:05:24 -0700

First, this draft comes close to just describing how to use existing protocols rather than describing an actual protocol itself.  I would argue that is a feature, but I can imagine some reviewers might argue that the IETF shouldn't publish mere policy documents.

Second, I would welcome comments from the authors of the earlier PKCROSS draft.  Perhaps it's only historical curiosity.

Third, details:

Step 2 of the protocol is redundant with step 3, since only the public key is sent to the KCA in the current kx509.  When I get to doing kx509bis, *it* will specify when/how to do the CSR, so step 2 will still be redundant.  (And yes, I intend to put the id-pkinit-san in the CSR to support proper cryptographic binding.)

Section 2.1:  As an administrator, I would prefer to just configure the cert directly, rather than a fingerprint, for any specifically trusted relationships.  As a NASA contractor I would want to limit any trusted CAs to exclude those run by hostile foreign governments, even if they do pass other auditing requirements.  I don't believe the TRANSIT-POLICY-CHECKED flag should ever be set unless a human has OK'ed the trust, but maybe that's too restrictive for the draft.

Section 3:  This section seems a bit terse to me and might benefit from some expansion.  I mentally reversed home/destination when I first read it.  As a specific point, the recommended (normal) practice is to put the original principal name in the kx509-issued cert, but I see that doesn't break the property you were actually advertising.  Maybe this is just me.  

I will say that it's a useful property if a user doesn't want the Calif DMV to know he/she's shopping at porn-stars-r-us, but does want to use a valid Calif ID for purchases.

Section 4:  This section raises issues that need discussion in the Security Considerations.  It sounds like you are changing the default value of an authentication from something reliable to something anonymous in trustability.  I'm tempted to require something like ssh's "never seen this guy before, are you sure" prompt, but I think that's simplistic, and probably out-of-scope as well.

Cross-realm authentication is already inherently less secure/trustable than same-realm authentication.  It's just rare enough that we don't pay attention, and it hasn't affected our expectations.  While I'm all for making cross-realm relationships easier to set up and use, I'm afraid of violating the principle of least surprise.

I think you're on the right track with the transited-policy discussions (modulo comment re 2.1).  Do existing application services actually pay attention to that flag?  If not, then PKCROSS might be dangerous to deploy in practice.  Remember that a lot of applications thoughtlessly strip the realm name and pretend they have a UID.  We need to break that behavior, and I doubt we can.

We need to have a way to phase this into the wild that doesn't generate horrific anecdotes.  I'm nattering on because I'm not sure of the solution.

Section 6:  Like the idea.  Obviously needs expanding.  SHOULD only be used if all the appropriate DNS PKI stuff is deployed to support it at the required trust level.
------------------------------------------------------
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, 13 Aug 2013 12:08:15 -0700

On Aug 13, 2013, at 11:05 AM, "Henry B. Hotz" <[email-masked]> wrote:

> SHOULD only be used if all the appropriate DNS PKI stuff

PK, not PKI.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Aug 2013 14:12:42 -0500

On Tue, Aug 13, 2013 at 1:05 PM, Henry B. Hotz <[email-masked]> wrote:

Thanks for your review comments!

> First, this draft comes close to just describing how to use existing protocols rather than describing an actual protocol itself.  I would argue that is a feature, but I can imagine some reviewers m…

I don't see why that should be a problem here..  I do think this is
really specifying how combinations of a) existing protocols, b) new
policies, c) some additional sub-protocols (to create symmetric key
pairings, for example, or something like ABFAB's trust router). That's
not only OK, it's great: we're *reusing* specifications, which is
exactly as it should be (except, of course if they were
broken/obsolete, which they are not).

> Second, I would welcome comments from the authors of the earlier PKCROSS draft.  Perhaps it's only historical curiosity.

Indeed.

> Step 2 of the protocol is redundant with step 3, since only the public key is sent to the KCA in the current kx509.  When I get to doing kx509bis, *it* will specify when/how to do the CSR, so step…

Sure, step 2 and 3 are really sub-steps of the same step.

> Section 2.1:  As an administrator, I would prefer to just configure the cert directly, rather than a fingerprint, for any specifically trusted relationships.  As a NASA contractor I would want to l…

Agreed.  Though I don't want to specify *how* admins are to verify CA
certs, whether using fingerprints, whether using a real PKI -- this is
all local policy.

> Section 3:  This section seems a bit terse to me and might benefit from some expansion.  I mentally reversed home/destination when I first read it.  As a specific point, the recommended (normal) pr…

Right, it doesn't break that.  The privacy feature here is relative to
the user's home realm, which doesn't get to find what realms the user
is transiting to/through.

A minor feature, in the grand scheme of things, but it's OK.

Privacy relative to eavesdroppers can be had using FAST.

Privacy relative to the destination realms can be had by using
anonymous authentication with user certs providing pseudonymity
(again, this involves local policy at the client/user-agent side and
the realms traversed).

> I will say that it's a useful property if a user doesn't want the Calif DMV to know he/she's shopping at porn-stars-r-us, but does want to use a valid Calif ID for purchases.

Right.  Also, I think it's a feature ABFAB has, and they have strong
justifications for such features that would apply here too.

> Section 4:  This section raises issues that need discussion in the Security Considerations.  It sounds like you are changing the default value of an authentication from something reliable to someth…

Yes.  I just hadn't gotten to fleshing out the security considerations
section.  The whole I-D will discuss security considerations
throughout too (and does).

As for prompting, well, we have a lot of experience in the SSH world
with that.  We should recommend prompting, but there may be other ways
to indicate trust/lack of trust and push decisions higher up the
stack.  For example, one might make the display form of the name such
as to indicate the lack of trust path, or one might express it using
naming attributes, and so on.  But in order to trust for subsequent
uses the user must be involved, just not necessarily with a prompt
(again, maybe we ask users to recognize public key fingerprints,
because maybe the user/app OK with pseudonyms and wants only
continuity, not any real information about the peer).

> Cross-realm authentication is already inherently less secure/trustable than same-realm authentication.  It's just rare enough that we don't pay attention, and it hasn't affected our expectations.…

The principle of least surprise is not to be violated, and nothing in
the proposal requires it to be violated.  Existing implementations may
need new APIs, and in order to operate correctly with old apps they
may make principal name representations "safe" (see above) as a
fail-safe such that no existing apps should accidentally get untrusted
transit paths.

> I think you're on the right track with the transited-policy discussions (modulo comment re 2.1).  Do existing application services actually pay attention to that flag?  If not, then PKCROSS might b…

See above.

> We need to have a way to phase this into the wild that doesn't generate horrific anecdotes.  I'm nattering on because I'm not sure of the solution.

See above.

> Section 6:  Like the idea.  Obviously needs expanding.  SHOULD only be used if all the appropriate DNS PKI stuff is deployed to support it at the required trust level.

Well, section 6 is empty right now; did you mean section 5, the DANE
stuff?  Yes, it's a nice idea, but it's really just one of many ways
to establish a trust transit path, and it's perfectly legitimate, and
it has its own security considerations, namely: that you're trusting
the DNSSEC PKI, and all the security considerations associated with
that.  DANE is way better than the TLS server PKI, so there's that.

At the end of the day all of these all about convenience/security/cost
trade-offs involved in all the different trust bootstrap choices -- we
shouldn't REQUIRE any one of these to be *used*, but we should REQUIRE
at least one of these to be *implemented*.  This is to be discussed.

Clearly *manual* validation/pre-sharing of public keys/certs should be
REQUIRED to implement (and it's the easiest thing to implement).
Given that we are referencing PKIX it's also trivial enough to REQUIRE
that the use of locally-configured trust anchors be implemented.
Beyond that I a) would NOT want to REQUIRE TOFU/LoF to be implemented,
b) I would want to RECOMMEND -possibly require- that DANE be
implemented.  At some point we'll have an in-depth discussion about
this, but I think the preceding is roughly on target.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 13 Aug 2013 13:03:09 -0700

> On Tue, Aug 13, 2013 at 1:05 PM, Henry B. Hotz <[email-masked]> wrote:

[snipping stuff we agree on]

> certs, whether using fingerprints, whether using a real PKI -- this is

I'm just saying what I (as an admin) want to tell the KDC.  Alternatives are OK, and an admin will do whatever they think reasonable to get the cert in the first place.

> justifications for such features that would apply here too.

Do they have something that could be referenced?

> the proposal requires it to be violated.  

I'll agree it doesn't seem to require it to be violated.  I think we also agree that more stuff is needed to do it right.

> Existing implementations may

I'm concerned that we get something that doesn't violate the principle of least surprise when deployed with existing code bases that ignore transited-policy.

Are you proposing that your PKCROSS by default "breaks" unless the cross-realm trust passes the transited-policy requirement?

> stuff?  

Errr.  Yeah.

> Yes, it's a nice idea, but it's really just one of many ways

Yes!  (The trust model for a web browser verifying it's really www.amazon-wannabe.com are very different from PKINIT.)

> this, but I think the preceding is roughly on target.

Agree.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Aug 2013 14:13:43 -0500

>> SHOULD only be used if all the appropriate DNS PKI stuff

DNSSEC *is* a PKI -- not a PKIX one, but a PKI nonetheless :)

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Aug 2013 15:27:39 -0500

> Do they have something that could be referenced?

I'd have to check; it'd be easier to ask Sam, which I'll do in a bit.

> I'll agree it doesn't seem to require it to be violated.  I think we also agree that more stuff is needed to do it right.

Well, we do need to say a bit about how to express things in a) the
GSS-API, b) non-standard APIs (abstractly).  I'll add text for this,
including GSS naming attributes and so on.

> I'm concerned that we get something that doesn't violate the principle of least surprise when deployed with existing code bases that ignore transited-policy.

The protocol itself does no such thing and requires no such thing.
Implementations could get it wrong and end up causing harm, so we'll
have some implementor guidance, but as with all implementation bugs...
 Anyways, I'll also add text specifically addressing the view of
TOFU/LoF from GSS.

Ignoring TOFU/LoF for the moment, there's really only one way to end
up violating the principle of least surprise: if, say, the trust
anchors for the TLS server PKI were accidentally and unintentionally
used for PKCROSS.  If there's a trust path it's because admins put it
there, intentionally or otherwise.  That's how it has to be.  For
TOFU/LoF the key is to end up with strongly pseudonymous names (e.g.,
use public key fingerprints as the actual principal names).

> Are you proposing that your PKCROSS by default "breaks" unless the cross-realm trust passes the transited-policy requirement?

Absolutely, with the caveat that transit policy is intended to be
applied (and applicable) by all Kerberos services, including TGSes and
non-TGSes.  Where implementations fail to check transit paths... any
increase in the x-realm cloud size tends to increase those
implementations' vulnerability, and there's not much that can be done
about that.

That's another thing: we need better policy for evaluating the value
of a transit path.  I've some ideas for that, but I think they belong
in a different document as they are independent of *how* the transit
paths' x-realm principals get keyed, as well as because such policy
has always been left as a local policy matter.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Aug 2013 18:38:12 -0500

I've submitted a new I-D, FYI.

http://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross-02

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Aug 2013 18:39:02 -0500

I forgot to add this, per-Ben's comments:

+2.2.  Indication of Preference for/ Required Use of Symmetrically-Keyed
+      Cross-Realm Principals
+
+   A KDC MAY reject a PKINIT/PKCROSS request with a KRB-ERROR indicating
+   that the use of a symmetrically-keyed cross-realm relation is
+   required.  This is done using the following error code: <TBD>.  The
+   following e-data TD type is used to hold a SEQUENCE OF Realm: <TBD>.
+
+   A KDC MAY accept a PKINIT/PKCROSS request but indicate to the client
+   that a symmetrically-keyed cross-realm relation is preferred.  The
+   KDC does this by including a PA-DATA containing a SEQUENCE OF Realm,
+   with the following pa-type: <TBD>.
+
+   [[anchor1: Add an ASN.1 module, even though it will contain only one
+   untagged type consisting of a SEQUENCE OF Realm, and the IANA-
+   assigned values for error code, e-data TD type, and pa-type, plus the
+   import of the RFC4120 module (to get the Realm type).]]
+

This will be in the next version.