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

[Rick van Rein <[e-mail]>]

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.

>> DANE and its complex relationships with DNSSEC and cache timing makes
>> it a beast to operate, so simpler is better.
> 
> I don't follow this either.  What cache timing?  There's no complex
> relationship between DANE and DNSSEC.  DNSSEC might be complex, but DANE
> is simple.

…except in practice.  DANE stored in DNS (that is, if not stapled) deals
with DNS cache expirations, and the operational side of controlling
proper rollover with different timinig requirements for DNS and the
service is rather confusing — as soon as you take into account that
this may span multiple managing parties.  At least, that’s been our
conclusion at SURFnet.  DANE is only simple if you control all the
parts, and if you’re willing to carefully handle the DNS TTL stuff,
prepare your certificate rollovers in ample time, and if you don’t forget
to (request) cleanup after DNS has rolled over.

>> In 2.1 and 2.2, you might want to say that DH should be used for
>> PKINIT.  It is rather interesting here, because the switch is likely
>> to crossover to other operational control, and the source realm should
>> not be able to continue to tap traffic.  (KRB5-KDH will enable this
>> too, of course, but then the retrieved identity has been leaked
>> already.)
> 
> The source realm is trusted by the client, and will be able to continue
> to impersonate the user, but will not be able to mount a passive attack
> on the user talking to the destination in the client-driven PKCROSS
> case regardless of whether the client uses DH in PINIT or not.

I agree this is not a “MUST”, in light of the trust relation between client
and KDC.

> 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”.

>> 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?

> 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…

> 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.

>> 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.

>> 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.

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.

> (One might want to publish a CA policy as to max cert life in DNS too,
> and staple that as well.)

After having co-authored
https://dnssec.surfnet.nl/?p=771
I’m not so sure DNSSEC needs more timing parameters ;-)

>> In 2.5, care should be taken that some parties may have an interest in
>> cutting this path short, to make it look nicer / more reliable.
> 
> 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?

> In either of the two likely cases (with and w/o gateway realms) you have
> only realms involved that necessarily must be trusted.  There's no
> security consideration here that isn't already in RFC4120.

Pfew, that’s a relief.

> (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 :-(

>> (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.

>>           [...].  In fact, a bit of counting could make the KDC learn
>> about long-term relationships.
> 
> Indeed.  (But beware DoS attacks.)

Yep.  Counting properly authenticated requests could help to combat
DoS attacks I suppose.  But this is a general problem indeed.

Thanks,
 -Rick