Re: [kitten] PKCROSS I-D updated: drop LoF/TOFU/pseudonymity business

[Nico Williams <[e-mail]>]

On Thu, Nov 06, 2014 at 09:05:06PM +0100, Rick van Rein wrote:
> Hi Nico,
> 
> >> In 2.2, I have been playing with the idea of using the server key for
> >> the KDC also for the client side.  This is not likely to cause
> >> problems, and it will simplify management of certificates in DANE;
> >> 
> > I'm lost here.  What server key?
> 
> During PKINIT, the KDC uses a “server” certificate/key to authenticate.
> This cert/key may also be used as a PKINIT client cert/key — possibly
> with a Key Usage added.  This could reduce the bookkeeping in DANE,
> which greatly simplifies that management responsibility.

Right, I thought that wouldn't need mentioning.  The KDC may have one or
two certs -- that's an operational detail with little relevance here.
The key is to not preclude the use a singular cert for this; I don't
think the use of the id-pkcross-issuer EKU does that.

...

Let's leave DNSSEC operational matters to the DNS crowd.  They are aware
of the problems w.r.t. child->parent zone admin communication and they
are working on them.

> > The source realm will be able to mount passive attacks on the users
> > talking to destination realms with the KDC-driven PKCROSS protocol, and
> > this is just a consequence of the Needham-Schroeder protocol, and is
> > true even if the source realm's KDCs use DH in PKINIT.
> 
> I am talking of DH between the client and target KDC.  The key setup
> during that exchange should not be passively observed by the client
> KDC.  Again, I said “should not” rather than “MUST NOT”.

Ah, good point.

> >> In 2.2.1, I cannot make out why the TGT is made to look different from
> >> “normal” ones.
> 
> Thanks for explaining.  The I-D wording was a little to dry for me to
> get it.  You need another TGS-handler then?  And you might get in
> trouble with timing and repeats of the AP-REQ?

No, thre's no special "handler", and there's no replay issues either.
Clock skew issues are no different than in the pure RFC4120 case.

> > Oh, KRB_ERR_RESPONSE_TOO_BIG.  Yes, that's an interesting idea.  Clients
> > still apply a timeout in the TCP case though, but they might apply a
> > longer timeout.
> 
> O…r…   s…e…n…d…   o…n…e…   b…y…t…e…   a…t…   a…   t…i…m…e…

Heh, but timeouts might apply to the whole reply, and sending one byte
at a time is problematic for various implementation reasons.

> > But anyways, if a client times out and moves on to another KDC it's not
> > that big a deal.  The real problem is that it might fail altogether if
> > its timeout is too short and none of the KDCs it talks to already have
> > the required ITGT.
> 
> Yes.  Although keys are usually shared, but you don’t want to rely on
> that replicating *that* fast.

These keys won't be shared.  (They could be, but that would require a
replication protocol just for them, which seems unlikely.)

Let's gain some deployment experience and see.  We might find that
there's no real problem, or we might find that changing client-side
timeout handling is easier than other options.

> >> In 2.4, why does a client not have to validate as well as a KDC if it
> >> uses Client-driven PKCROSS?
> > 
> > Good point.  I was also assuming that the client could do the DANE
> > lookups for the target realm, but we might want a PKINIT extension by
> > which the KDC can staple DANE to its replies.
> 
> Mind you, it has me worried.  Clients behind crummy routers that
> claim to offer DNS but that cut off “funny extensions” such as RRSIG
> makes DNSSEC unavailable to some.  This might mean that a local
> resolver is required to have an implementation of proper authentication,
> unless you do include the entire DNSSEC chain as well — which IMHO
> would be possible.

That and IAKERB.  You're right of course; stapling has to be in both
directions.

> >> In 2.5, stapling DANE onto X.509 may lead to differences in TTL for
> >> DNS and kx509 certificates; what to do when DNS expires after an hour?
> > 
> > The two things are different.  DNS RR TTLs are for caching; they aren't
> > hard expirations.  If a kx509 CA wants to issue certificates much longer
> > than its DANE RR TTLs, so be it.  I see no need to connect the two.
> 
> Yes, the TTL is meaningless when asserting a certificate for instant use.
> One might have (possibly unpractical) concerns about the use of a
> certificate after the TTL has expired.  Normally, one wants to rely on
> the removal of a certificate from existence when it has gone from DANE.

One shouldn't have such concerns.  The two things are simply not linked.
One should re-lookup RRs not in the cache (because the entries in the
cache are older than the TTL).

> I don’t know if the browser world is caching DANE validations for periods
> that exceed the TTL; I always imagined it is an instant check.

The browsers are not yet using DANE.  But anyways, with stapled DANE
there's no question of caching.

> > There won't be very many parties involved in the common case.
> 
> Do you think there is a need for the not-so-common-case, and the
> brain-startling corner cases that it causes?

I think the best thing to do may be to drop encoding of PKIX issuers
into the transit path altogether, then let just the DANE path (when DANE
is used) and the remainder of the normal Kerberos transit path be
sufficient.

In a world of highly scalable x-realm paths one might require
enhancements to transit policy language to set limits on what length
transit paths are accepted from certain realms, or what subset of the
universe of realms is permitted / not permitted to be reached through
certain realms.

In practice I think a policy like listing some of the known long-term keyed
trust principals to list acceptable transit paths, then saying all other
transit paths must have at most one non-hierarchical transit... should
suffice.  Some variant of that will suffice for most if not all uses.

> > (That's kinda shocking the first time you hear about it...  See RFC4514
> > for a more complete treatment of this.)
> 
> That hurts… I had assumed that the mapping from DN to text is a bijection :-(

When I found out about that (years ago) I was shocked.

This is just one of the ways that the x.500 model of naming is a
disaster.  It is probably the most startling one.  Why design a naming
system that has no reliable, unambiguous representation for UIs other
than GUIs?  And even with GUIs, it seems to me that the x.500 model of
naming is still too complicated in all the glory of all its detail.

> >> (Avoiding this completely may not be possible, since a KDC might crash
> >> while a relying KDC still holds a krbtgt against the crashing one.)
> > 
> > The target realm has to commit and replicate the x-realm krbtgt KDB
> > entry before the source realm starts using it.  This is an existing
> > problem.
> 
> Or… you handle the loss by setting up a new pair, and you gain a system
> that is less reliant on storing those keys persistently.

There's no graceful way to do this other than holding back on the source
side until the destination has completed replication.

(Re-keying x-realm krbtgt principals is fraught with peril.  For one
major implementation there's no way to do it without outages, and all
you can hope to do is reduce the x-realm TGT lifetime as much as
tolerable before the change is made.)

Nico
--