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

From: Rick van Rein <[email-masked]>
Date: Thu, 6 Nov 2014 16:07:27 +0100

Hello Nico,

Thanks for writing draft-williams-kitten-krb5-pkcross-05

In 1 Abstract and 1, is it worth emphasising that hitherto unrelated realms may be connected on-the-fly with PKCROSS?

In 2.1, the “source” and “destination” are not immediately clear; might “client” and “server” or “user” and “service” be better?  Note you used “target” for “destination” in 2.2.
In 2.1, you might want to make remarks about the validity of the kx509 certificate and the impact that this has on the validity of the krbtgt.
In 2.1, although clear, examples with realm names could be helpful.

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; DANE and its complex relationships with DNSSEC and cache timing makes it a beast to operate, so simpler is better.

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

In 2.2, you might want to make explicit that multiple SAN element id-pkinit-san, and that these then serve as alternatives.  This can be used for sites that support multiple realms.  The consequence of defining it as OR is that the zero element (no id-pkinit-san available) conforms to a FALSE outcome, which is algebraically sane (and more importantly, it avoids programming errors).

In 2.2, there is probably a lifetime for the cross-realm shared secret.  It is important to define this.  There may even be a need to allow some spare time to deal with distributed clock drift.  A question to answer is when crossover tickets expire and until when they may be renewed; are they constrained by the ITGT?

In 2.2, the result of the exchange is a-symmetric, right?  Clients in one realm can use services in another realm, but the reverse is not possible without a similar exchange in the opposite direction.  That is the most flexible / general model.  It might be good to make that explicit.

In 2.2.1, I cannot make out why the TGT is made to look different from “normal” ones.  Any difference means that the client must have PKCROSS support built in, even for this TGS mode.  The reach of the mechanism would greatly improve if “normal” TGTs can be sent from KDC to clients.  Can you explain why you need to divert here?  I imagine I would do more work in the KDC than proposed here, is that perhaps not possible?

In 2.3, could it help to redirect to TCP?  I don’t know if a procedure exists to do that from the KDC, but if so, TCP establishes a connection and the client does not have to rely on timeouts as with UDP.  It is more likely to work.  Alternatively, since the problem is “softer” than a full failure, it may not be too bad to rely on clients to handle this cleverly.

In 2.4, perhaps emphasise that this MUST be an operator choice, so a setting on the software.  Some will accept self-signed X.509 if it is found in DANE, others will require DANE on top of X.509 and yet others may not be willing to setup DANE/DNSSEC for its operational complexity.

In 2.4, why does a client not have to validate as well as a KDC if it uses Client-driven PKCROSS?

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?

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.  Parties that could have such an interest should not be empowered to do so.  The reason for these paths is to document reliably how far a client went to get to a service, right?  This is currently missing from the documentation.

Anchor4 —> the reason to want this could be back-and-forth translation paths between PKIX and KRB5.  It might suffice to avoid this by requiring only one hop, and inserting the right checks before releasing credentials.  In the end, a user wants to contact a service, and that may require a direct path, with only one PKCROSS hop in between.

In 2.5, it may be meaningless to know that “some other” KDC approves of a path, if I don’t know that KDC’s policy.  What handles do you imagine a relying KDC could use to come to a judgement on that?

In 2.6, an alternative could be regularly refreshed keys that a KDC keeps track of.  This would reduce the risk of stored session keys.  (Avoiding this completely may not be possible, since a KDC might crash while a relying KDC still holds a krbtgt against the crashing one.)  Such long-term keys could be requested in time to avoid the “impatient client” problem.  In fact, a bit of counting could make the KDC learn about long-term relationships.

In 3.2.2, is the domain “.” a suitable high-up domain to trust?

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Thu, 6 Nov 2014 17:01:39 +0100

Hi Nico,

It seemed to me that the TGS-Driven PKCROSS approach is more complex than it needs to be.  Perhaps you started out as I did, but if not it may be interesting to consider the following as an alternative.

## AS-driven PKCROSS

This section defines an alternative to Client-driven PKCROSS, and it is
designed to encapsulate the logic within a KDC.  It works by setting up a
PKINIT exchange, establish a shared secret for one-way trust between two
KDC's, and install the resulting key as a manually installed key would be.

Such automatically installed keys expire at some point, and must then be
refreshed.  This can be done on demand when a client requests access to an
unknown remote realm, or the KDC can continuously refresh certificates for
realms that it knows are regularly needed.  The distinction across this
choice dimension is a local matter of the KDC and its operational staff,
because the protocols do not change on account of it.

When TGS request is made for access to a realm that is not locally
known to the KDC, the following protocol is initiated:

 * The user's KDC connects to a service's KDC, using PKINIT.

 * Both KDCs use their PKINIT server key to authenticate their use of certificates.

 * The KDCs mutually authenticate through DANE-with-DNSSEC and/or through PKIX validation.

 * During the exchange, a Diffie-Hellman key exchange forms the shared secret for the realm crossover.

 * Based on the shared secret, both inject a ticket for realm crossover from the user's KDC to the service's KDC in their key repositories.

 * This crossover ticket has an expiration time, as set by the service's KDC.  It is advised to permit somewhat elongated times for this.

 * Based on this realm-crossover ticket, the KDC's can now proceed as for manually configured shared keys.

Tickets provided on the basis of a realm crossover ticket MUST expire before or at the expiration of the crossover ticket.  If a client KDC considers the remaining duration too brief, it may request a fresh crossover ticket instead.

A restart of the KDC service MAY lead to loss of a crossover ticket.  When a client KDC has lost a crossover ticket, it may simply request a fresh one; when a service KDC has lost a crossover ticket the client KDC would notice that the key is unknown, and it would know to request a fresh ticket and then to try again.

The result of this lenient handling of loss of crossover keys is that no sessions keys need to be stored persistently.  This may help to improve the security of the KDC service.

I hope this is useful!
 -Rick

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Nov 2014 11:53:36 -0600

On Thu, Nov 06, 2014 at 04:07:27PM +0100, Rick van Rein wrote:
> In 1 Abstract and 1, is it worth emphasising that hitherto unrelated
> realms may be connected on-the-fly with PKCROSS?

I thought that was implied in the part about scalability.

> In 2.1, the “source” and “destination” are not immediately clear;
> might “client” and “server” or “user” and “service” be better?  Note
> you used “target” for “destination” in 2.2.

I think "client" and "server" would be more confusing.  The source realm
need not be the user's realm, nor must the destination realm be the
client application's target service's realm either.

Speaking of "source" and "target" or "destination" realms seems more
appropriate.

> In 2.1, you might want to make remarks about the validity of the kx509
> certificate and the impact that this has on the validity of the
> krbtgt.

Did you mean the validity time period?  Sure, that's a good point.

> In 2.1, although clear, examples with realm names could be helpful.

OK.

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

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

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

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.

> In 2.2, you might want to make explicit that multiple SAN element
> id-pkinit-san, and that these then serve as alternatives.  This can be
> used for sites that support multiple realms.  The consequence of
> defining it as OR is that the zero element (no id-pkinit-san
> available) conforms to a FALSE outcome, which is algebraically sane
> (and more importantly, it avoids programming errors).

Well, the KDC-REQ body's cname/crealm have to match one id-pkinit-san
SAN, and that should be the one mentioned in 2.2 (I should say this
about the KDC-REQ).  It doesn't matter if there are multiple
id-pkinit-san SANs.

> In 2.2, there is probably a lifetime for the cross-realm shared
> secret.  It is important to define this.  There may even be a need to
> allow some spare time to deal with distributed clock drift.  A
> question to answer is when crossover tickets expire and until when
> they may be renewed; are they constrained by the ITGT?

It *is* the lifetime of the ITGT.  It couldn't be otherwise.

> In 2.2, the result of the exchange is a-symmetric, right?  Clients in

The trust is asymmetric, yes.  (The ITGT's session key is symmetric.)

> one realm can use services in another realm, but the reverse is not
> possible without a similar exchange in the opposite direction.  That
> is the most flexible / general model.  It might be good to make that
> explicit.

Yes.  I'll make it more explicit.

> In 2.2.1, I cannot make out why the TGT is made to look different from
> “normal” ones.  Any difference means that the client must have PKCROSS
> support built in, even for this TGS mode.  The reach of the mechanism
> would greatly improve if “normal” TGTs can be sent from KDC to
> clients.  Can you explain why you need to divert here?  I imagine I
> would do more work in the KDC than proposed here, is that perhaps not
> possible?

Cross-realm tickets issued *to clients* this way can't be Ticket PDUs
since there's no long-term symmetric key for the cross-realm krbtgt
principal.  They must have a different form.  My choice was to use
AP-REQ (from the issuing source realm KDC to the target realm), using
the ITGT from the previous step.

Clients CANNOT decrypt Tickets (except when they are also the target
principal of the Ticket).  Therefore clients CANNOT tell the difference.

As far as clients are concerned, the KDC-driven PKCROSS case is
completely transparent, with the only observable difference being in
timing (and only occasionally, when the KDC doesn't already have the
necessary ITGT; once a KDC has that ITGT, the clients will observe not
even a difference in timing).

> In 2.3, could it help to redirect to TCP?  I don’t know if a procedure
> exists to do that from the KDC, but if so, TCP establishes a
> connection and the client does not have to rely on timeouts as with
> UDP.  It is more likely to work.  Alternatively, since the problem is
> “softer” than a full failure, it may not be too bad to rely on clients
> to handle this cleverly.

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.

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.

> In 2.4, perhaps emphasise that this MUST be an operator choice, so a
> setting on the software.  Some will accept self-signed X.509 if it is
> found in DANE, others will require DANE on top of X.509 and yet others
> may not be willing to setup DANE/DNSSEC for its operational
> complexity.

Sure.  By not using RFC2119 language as to this choice I thought this
was implicit.

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

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

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

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

Even in a network with [locally-trusted] gateway outbound/inbound realms for routing
PKCROSS to the world through... the typical path will transit not more
than two Kerberos realms and the (DNSSEC) hierarchical path from the
PKCROSS source realm to the root.

In the more likely (long-term) common case with no gateway realms there
will be no Kerberos realms in the transit path, just the domains from
the source realm to the root.

None of the DNSSEC hierarchical path elements (domainnames) will be
"transited" in the sense of having had KDCs visited.  Therefore they
can't "edit" the path.

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.

> Parties that could have such an interest should not be empowered to do
> so.  The reason for these paths is to document reliably how far a
> client went to get to a service, right?  This is currently missing
> from the documentation.

We're already making the situation much better than for RFC4120 just by
shortening the real transit path (to zero realms).  KDCs already can
lie, and nothing we can do here can change that.

The thing to do is to encourage policies whereby target realms refuse
PKCROSS with the crealm not being the same as the issuing TGS's.

Oh, incidentally, the KDC-driven PKCROSS case needs an Authenticator
authorization-data element for conveying the transit path taken by the
client reaching the PKCROSS source realm!  I'd missed that completely.

> Anchor4 —> the reason to want this could be back-and-forth translation
> paths between PKIX and KRB5.  It might suffice to avoid this by
> requiring only one hop, and inserting the right checks before
> releasing credentials.  In the end, a user wants to contact a service,
> and that may require a direct path, with only one PKCROSS hop in
> between.

Right, but I was alluding to the problem is that PKIX DNs can't be
reliably represented as strings, but that's what Realms are (strings).

(That's kinda shocking the first time you hear about it...  See RFC4514
for a more complete treatment of this.)

I'm expecting the answer here to be "no, that's ETOOHARD for too little
value -- none in the DANE case".  But in the no-DANE case aliasing of
PKIX issuer names could be problematic (though I expect that it won't
be any more problematic than the WebPKI already is in itself, and that
it won't be at all problematic in proper non-WebPKI PKIs that use naming
constraints).

> In 2.5, it may be meaningless to know that “some other” KDC approves
> of a path, if I don’t know that KDC’s policy.  What handles do you
> imagine a relying KDC could use to come to a judgement on that?

See RFC4120.  This is about the service's realm's KDCs' policy.

> In 2.6, an alternative could be regularly refreshed keys that a KDC
> keeps track of.  This would reduce the risk of stored session keys.

Sure.  Once the x-realm krbtgt principal has long-term keys, they can be
changed.

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

> Such long-term keys could be requested in time to avoid the “impatient
> client” problem.  I[...]

Yes, when you know you'll need it, of course.

>            [...].  In fact, a bit of counting could make the KDC learn
> about long-term relationships.

Indeed.  (But beware DoS attacks.)

> In 3.2.2, is the domain “.” a suitable high-up domain to trust?

Yes, though it can't be representated in a Kerberos transit path.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Nov 2014 11:57:19 -0600

On Thu, Nov 06, 2014 at 05:01:39PM +0100, Rick van Rein wrote:
> It seemed to me that the TGS-Driven PKCROSS approach is more complex
> than it needs to be.  Perhaps you started out as I did, but if not it
> may be interesting to consider the following as an alternative.

I thought it was simple and elegant, particularly the part about the
Ticket enc-part's "ciphertext" being actually an AP-REQ.

> ## AS-driven PKCROSS
> 
> This section defines an alternative to Client-driven PKCROSS, and it
> is designed to encapsulate the logic within a KDC.  It works by
> setting up a PKINIT exchange, establish a shared secret for one-way
> trust between two KDC's, and install the resulting key as a manually
> installed key would be.

The problem with this is that it requires synchronization and
replication (if it were only replication it might not be so bad), and
that on both sides.  That is pretty much a fatal problem for this
approach.

I had considered it.  Perhaps I should have said something about why it
can't work and use that as motivation for the ITGT/AP-REQ-as-Ticket
concept, which avoids the sync/replication problem altogether.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Nov 2014 14:13:59 -0500 (EST)

> I thought that was implied in the part about scalability.

I think it would be good to mention it explicitly, regardless.

> concept, which avoids the sync/replication problem altogether.

That could be useful.  If it's too long, maybe put it in an appendix?

-Ben

---

From: Rick van Rein <[email-masked]>
Date: Thu, 6 Nov 2014 21:05:06 +0100

Hi Nico,

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

> relationship between DANE and DNSSEC.  DNSSEC might be complex, but DANE

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

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

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

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

> still apply a timeout in the TCP case though, but they might apply a

O…r…   s…e…n…d…   o…n…e…   b…y…t…e…   a…t…   a…   t…i…m…e…

> its timeout is too short and none of the KDCs it talks to already have

Yes.  Although keys are usually shared, but you don’t want to rely on
that replicating *that* fast.

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

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

> 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 ;-)

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

> security consideration here that isn't already in RFC4120.

Pfew, that’s a relief.

> for a more complete treatment of this.)

That hurts… I had assumed that the mapping from DN to text is a bijection :-(

> entry before the source realm starts using it.  This is an existing

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.

> 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

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Nov 2014 14:47:34 -0600

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

> KDC.  Again, I said “should not” rather than “MUST NOT”.

Ah, good point.

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

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

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

> unless you do include the entire DNSSEC chain as well — which IMHO

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

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

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

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

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Nov 2014 14:49:02 -0600

I should add that my hope is that client timeout issues turn out to be
non-issues or easily addressed so that the ITGT approach is the most
sensible.  Operationally the ITGT approach would be the best as it would
be completely automatic.

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Nov 2014 18:13:58 -0600

Oh, it occurs that sending KRB_ERR_RESPONSE_TOO_BIG in time for the
typical client timeout might actually be a way to effectively double
the amount of time the KDC has to complete the KDC-driven PKCROSS
work.