Subject: Re: [kitten] ID-Action: draft-williams-kitten-krb5-pkcross-01

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Aug 2013 14:00:53 -0400 (EDT)

[again no in-reply-to, sorry]

I've looked over this document, though I did not do a full-depth review of 
it.

The scheme is intellectually appealing, or at least amusing, and on paper 
it seems to help with the issues related to cross-realm trusts.  I just 
can't shake the feeling that it won't be adopted in the real world, 
though, and I'm not sure why.  This makes me reluctant to spend much time 
trying to move it forward without some indication that it would gain 
traction.

Another reason for reluctance is that the propsal wants one of the 
relatively-scarce KDCOptions flag bits.

It looks like USE-SESSION-KEY-AS-REALM-KEY will only do one direction of 
trust (at a time)?  So a bidirectional trust would still require 
initiation from both sides (as it should).  It might be worth mentioning 
that explicitly, even though it follows directly from the directions of 
trust having different principal names.

In section 2.1, I don't really understand the motivation for (d).

Section 3 makes me wonder if there is some discussion to be had about 
the KDC allowing/disallowing itself of making signatures of users' PKCROSS 
certificates when there does exist a symmetric key between the realms. 
That is, allowing new certs to be signed would preserve the privacy 
property, but requires more work (?) and reduces auditability.

In section 4, there might be something to be said about setting 
TRANSITED-POLICY-CHECKED for a cached/post-LoF trust, after some threshold 
has passed (wall time without changed cert, or number of successful 
requests, or something).

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Aug 2013 14:03:04 -0400 (EDT)

Forgot to note: you cite draft-hotz-kx509-06, but it is RFC 6717, now.

On Fri, 9 Aug 2013, Benjamin Kaduk wrote:

> The scheme is intellectually appealing, or at least amusing, and on paper it 
> seems to help with the issues related to cross-realm trusts.  I just can't 
> shake the feeling that it won't be adopted in the real world, though, and I'm 
> not sure why.  This makes me reluctant to spend much time trying to move it 
> forward without some indication that it would gain traction.
>
> trust (at a time)?  So a bidirectional trust would still require initiation 
> from both sides (as it should).  It might be worth mentioning that 
> explicitly, even though it follows directly from the directions of trust 
> having different principal names.
>
> Section 3 makes me wonder if there is some discussion to be had about the KDC 
> allowing/disallowing itself of making signatures of users' PKCROSS 
> certificates when there does exist a symmetric key between the realms. That 
> is, allowing new certs to be signed would preserve the privacy property, but 
> requires more work (?) and reduces auditability.
>
> has passed (wall time without changed cert, or number of successful requests, 
> or something).
>
> -Ben
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Aug 2013 14:36:42 -0500

> I've looked over this document, though I did not do a full-depth review of

Thanks.

> shake the feeling that it won't be adopted in the real world, though, and
> I'm not sure why.  This makes me reluctant to spend much time trying to move
> it forward without some indication that it would gain traction.

Running code is the key.  I don't see why this wouldn't be adopted
except for lack of running code.  I don't know when I'll be able to
implement.

However, I would say that the manual cross-realm principal keying
problem is a brutal problem, and you should ask people who are still
migrating from 1DES about it.  Clearly solving this would be very
nice.

> relatively-scarce KDCOptions flag bits.

I can use something else.  But remember, these are BIT STRING (SIZE
32..MAX).  In theory we can add bits.  And it'd better be so.  (IIRC
MIT's current ASN.1 decoder will accept longer bit strings but will
ignore any bits beyond the first 32, which is... exactly as it should
be.  I'd have to check but I believe Heimdal does the same.  I
wouldn't know about other implementations, and, technically, shouldn't
have to.)

> having different principal names.

Correct, and it does follow.  I could add a section describing
cross-realm trust setup procedures.

> In section 2.1, I don't really understand the motivation for (d).

The key is that if you have a very large PKI but don't want symmetric
trust keys exchanged for all possible realms, then you might want to
set a max as a DoS counter-measure, along with the others.  But you're
right, a throttle should suffice, so I'll just remove (d).

> Section 3 makes me wonder if there is some discussion to be had about the
> KDC allowing/disallowing itself of making signatures of users' PKCROSS

Good point.  A realm might want such a policy and the protocol should
allow its KDCs to tell clients to use symmetrically keyed x-realm.
There's still the privacy protection rationale to allow this, but
that's just gravy.

> has passed (wall time without changed cert, or number of successful

Yes, once a TOFU/LoF key has been accepted and marked as valid then
the KDC can validate the transit path and it can set that flag.
Non-TGS services won't get the key material to validate, but they have
to trust their realms' KDCs anyways w.r.t. all cross-realm keying
anyways.

Nico
--