Subject: [kitten] PKCROSS

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 16:40:02 -0500

I note this text in the current charter:

  Prepare a standards-track protocol to solve the use cases addressed
        by draft-hotz-kx509-01 including new support for digital
        signatures.

The thought occurs that Kerberos + kx509 + PKINIT can be a sort of
PKCROSS.  That makes me very interested.  It shouldn't be very
difficult to build that almost entirely out of off-the-shelf protocol
pieces.  It's not trival though: we'd definitely need policy for
handling PKIX trust paths, and it wouldn't minimize the need for PK
crypto.

PKCROSS -or similar- is not in-charter at this time.

Just a thought,

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 11 Jul 2013 15:54:45 -0700

>        by draft-hotz-kx509-01 including new support for digital

Yeah, I really, really need to get back to this.

> PKCROSS.  

Please elaborate?

The reason *I* would combine kx509 with PKINIT would be the use case of someone needing X.509 credentials on multiple client computers at once.  This is a real use case for us.

I was thinking of PKCROSS the other day as a possible solution to a rather specialized problem:  our realm-name conflict between Unix and AD kerberos.  You might think that for one-way trusts from another realm (like a smart-card-only realm) it would be OK to have both of them trust the other one.  Trouble is that with symmetric crypto if someone hacked the AD realm they could use the one-way trust key to forge other-realm cross-realm authentications to the Unix realm.  (Not picking on Microsoft.  The problem is symmetric.) I suspect that PKCROSS might allow a solution to that, though I have not read the draft to make sure.  I also suspect that it's too specialized a use case to justify the standards effort that would be required.

> That makes me very interested.  It shouldn't be very
> handling PKIX trust paths,

I've lost a lot of interest in PKIX, per-se.  The overall revocation system is architecturally broken, and I can't tell if the co-chairs even understand the issues.  Instead we have vapor-ware like SCVP and TAMP.

> and it wouldn't minimize the need for PK
> crypto.
> 

If we can address use cases which PKIX doesn't, then it sounds valuable.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 18:14:13 -0500

>> The thought occurs that Kerberos + kx509 + PKINIT can be a sort of

Assume:

 - I have a TGT for realm FOO.EXAMPLE.
 - I want to talk to a service in BAR.EXAMPLE.
 - I have no credentials for any principal in BAR.EXAMPLE.
 - I can find no all-Kerberos trust path between FOO.EXAMPLE and BAR.EXAMPLE.
 - I can get a certificate for my client principal name using a kx509
service run by FOO.EXAMPLE.

Then maybe:

 - BAR.EXAMPLE accepts my use of that certificate (and private key)
with PKINIT and issues me a Ticket with [email-masked] for the
requested service at BAR.EXAMPLE (likely
krbtgt/[email-masked]).

Here BAR.EXAMPLE's KDC will have to build and validate a trust path
for my certificate's trust., extract the krb5 SAN, decide whether to
accept it, and if it does, issue a Ticket for that SAN.

The transit path recorded in the Ticket should be FOO.EXAMPLE-><cert
path>->BAR.EXAMPLE.  It so happens that Kerberos can represent x.500
naming in transit paths -- how convenient!  I'm not sure that
implementations actually exist of x.500 realm naming in Kerberos, but,
hey.

> The reason *I* would combine kx509 with PKINIT would be the use case of someone needing X.509 credentials on multiple client computers at once.  This is a real use case for us.

Presumably all from different realms?  Would that be the same as
described above?

> I was thinking of PKCROSS the other day as a possible solution to a rather specialized problem:  our realm-name conflict between Unix and AD kerberos.  You might think that for one-way trusts from…

All trusted-third-party protocols have this problem in the end.  What
can you do?  You have to trust all your KDCs, for all those realms
that you care about.

You might address this partially by havig Tickets bear the
certificates used by the clients as KDC-issued authorization-data, so
that applications could perform PKIX validation, including cert
revocation checking, apply various policies, ...

> I've lost a lot of interest in PKIX, per-se.  The overall revocation system is architecturally broken, and I can't tell if the co-chairs even understand the issues.  Instead we have vapor-ware like…

Oh, it's not PKIX I care about.  I just want something that scales
better than symmetrically keyed Kerberos cross-realm principals, and
with better security policies (e.g., sysadmins do not have to exchange
passwords from which the x-realm keys are derived; they might exchange
passwords to authenticate the key exchange, but the sysadmins should
not learn the keys as a result, or they might exchange certificate
fingerprints, ...).

> If we can address use cases which PKIX doesn't, then it sounds valuable.

The use case that PKIX doesn't address is where you've deployed
Kerberos widely and you want to either a) scale it up mode widely
(e.g., in the EDU world), and/or b) remove the manual symmetric key
exchange, and/or c) not have to worry about cross-realm key rollover
(or enctype changes, e.g., to go to stronger enctypes as they become
available).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 20:31:28 -0500

>>> The thought occurs that Kerberos + kx509 + PKINIT can be a sort of

There are some downsides to this approach:

 - it requires kx509 (not a big deal, but, it is one more piece)

 - it requires PK for every x-realm TGT obtained when there's no
symmetrically-keyed x-realm principals available

 - the client realm doesn't find out about the client's interest in
talking to the target realm

The originally-envisioned PKCROSS protocol, IIUC, also had the first
two problems.  The third might be considered a feature (privacy!), and
probably justifies the first problem.  The second problem can be cured
by having realms proactively use this same protocol as part of
exchanging symmetric cross-realm principal keys.

On the plus side, it'd get us exactly what we want from PKCROSS:

 - PKI or manual trust anchor exchange for x-realm trust setup

Note too that leap-of-faith is also possible, both on the client side
and on the target side: the target realm's KDCs could accept *any* PKI
trust path, record it in the transit path, and NOT set the
TRANSIT-POLICY-CHECKED ticket flag.

With this and DNS (and DNSSEC) we can scale Kerberos cross-realm.

The cross-realm symmetric key exchange protocol would be trivial:

 - use a cert with a krbtgt/REALM@REALM id-pkinit-san to get a Ticket
(with PKINIT) for the target's krbtgt/TARGET@TARGET

 - use a new KDCOptions flag to indicate that the above Ticket's
session key is to become the long-term key for krbtgt/TARGET@REALM

which TARGET's KDCs could reject for reasons such as: not supported,
couldn't validate the source realm's PKIX trust path, ...

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 23:06:35 -0500

> Yeah, I really, really need to get back to this.

Oh.  You were being sarcastic.  The RFC issued (and I missed that).  Har.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 11 Jul 2013 21:34:12 -0700

> Oh.  You were being sarcastic.  The RFC issued (and I missed that).  Har.

No, I don't think he was being sarcastic.  The RFC that was published
documents the existing protocol, which is kind of broken.  I'm pretty sure
this charter action is about *revising* that protocol and making it more
sane.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 23:54:55 -0500

> this charter action is about *revising* that protocol and making it more

Ah.  OK.  How much change do you think it needs?  Some?  Or are we
talking about a complete re-write?

---

From: Russ Allbery <[email-masked]>
Date: Thu, 11 Jul 2013 21:59:13 -0700

>> documents the existing protocol, which is kind of broken.  I'm pretty
>> sure this charter action is about *revising* that protocol and making
>> it more sane.

> talking about a complete re-write?

The current protocol is pretty weird.  One obvious point is that it uses
raw AP-REQs instead of GSS-API.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 12 Jul 2013 20:34:48 -0700

> implementations actually exist of x.500 realm naming in Kerberos, but,

So the short version would be that we use a kx509-issued cert as a stand-in for a cross-realm relationship.  

I recall a bunch of jokes about that while writing the RFC.  However Doug Engert actually proposed that use case for Globus.  It's arguably a minor extension of the existing SLCS policies.  The security considerations just say "here there be [policy] dragons". ;-)

Since it's up to the kdc to decide how X.509 cert's are related to principals, I don't think you actually need anything except a convention (which your assumptions imply) for when the client should try this approach.  

Strict need aside, I can see some value in being able to provide information about how a foreign principal was validated.  Putting an X.509 name into a transited field doesn't strike me as a bad way to do it, especially since it gives you a legacy-compatible way for the KDC to flag policy issues.  Another less-compatible way to do it would be to just issue an X500 principal tgt directly.

Formal modeling of Kerberos says "here there be dragons" about cross-realm.  It would be nice if an explicit extension to support X.509 certs for cross-realm could be restricted in a way which allowed proof of the desired properties.

> Presumably all from different realms?  Would that be the same as

Nah.  Just a user can only have one PIV card, but they may need to use more than one computer at a time.  Using kx509-issued certs instead of the originals on the card gives you a way to cache your authentications.  It's also faster to set up than waiting through multiple cycles on an RSA token.

> revocation checking, apply various policies, …
> 
> fingerprints, …).

We're less concerned with the "insider threat" than most.  

I agree public-key better models the trust relationship of 1-way cross realm than symmetric key.  Also agree that configuring those relationships has a lot of practical issues.  If it's explicitly configured, then I don't think PKIX adds any value.  Just use asymmetric encryption instead of symmetric.  (Maybe issue a symmetric tgt to make subsequent tgs requests more efficient?)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sun, 14 Jul 2013 18:54:43 -0700

> talking about a complete re-write?

The current RFC has a bunch of comments scattered through it about changes to be made in a "future incompatible upgrade".  One specific point that multiple people complained about is it uses SHA1, and ought to use the Kerberos checksum for whatever enctype is in use.

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Jul 2013 11:47:28 -0500

> So the short version would be that we use a kx509-issued cert as a stand-in for a cross-realm relationship.

Yes.  Well, the kx509-issued cert (or, really, any cert, but generally
it'd be a kx509-issued cert) and its cert validation path.

> I recall a bunch of jokes about that while writing the RFC.  However Doug Engert actually proposed that use case for Globus.  It's arguably a minor extension of the existing SLCS policies.  The sec…

There's only three dragons, one of which has always existed, and
another of which existed in theory but we had no way to exercise:

 - apps must validate transit paths (pre-existing dragon)
 - apps and TGSes must know how to handle X.500 naming in transit
paths (pre-existing but mostly unexercised dragon)
 - Leap-of-Faith / Trust on First Use / pseudonymous authentication
(which should fail safe because apps should validate transit paths)

Also, when using the new PKCROSS system, if the KDC can validate the
PK trust path and is happy with it, it can set the
TRANSIT-POLICY-CHECKED bit, so that you can have non-LoF/TOFU interop
out of the box.

> Since it's up to the kdc to decide how X.509 cert's are related to principals, I don't think you actually need anything except a convention (which your assumptions imply) for when the client should…

The client should try this approach when:

 - it can find no non-PKCROSS trust path to the target realm

 - it's configured to do so

and/or

 - it wants privacy relative to its home realm (this could be a flag in an API)

> Strict need aside, I can see some value in being able to provide information about how a foreign principal was validated.  Putting an X.509 name into a transited field doesn't strike me as a bad wa…

We already have x.500 naming for transit paths, which should support
x.509 naming (but it's hard to tell as RFC4120 doesn't give a
reference for X.500 naming!  neither does RFC1510).

> Formal modeling of Kerberos says "here there be dragons" about cross-realm.  It would be nice if an explicit extension to support X.509 certs for cross-realm could be restricted in a way which allo…

There's already dragons.  And I want the new LoF/TOFU dragon option.

Some dragons are cute/snuggly/wuggly.

> Nah.  Just a user can only have one PIV card, but they may need to use more than one computer at a time.  Using kx509-issued certs instead of the originals on the card gives you a way to cache your…

Ahhh, credential delegation, effectively.

> We're less concerned with the "insider threat" than most.

That's nice, for you :)  But you should care about it.  And we should
care about: a) making sysadmins' lives easier, b) removing the need
for them to know sensitive secret keys, c) scalability (see (a)), d)
removing the need for manual key rollover and outages during key
rollover.  We might agree that we don't need e) LoF/TOFU, but I think
ABFAB is proof that we need something like it, and also, for a very
large Internet I think LoF/TOFU makes some sense, and indeed we see
some of that in TLS server PKI specifications like key/CA pinning, and
in browser plugins like CertPatrol.

Anyone who's had to deal with a 1DES migration in a complex
multi-realm environment will appreciate (d).

> I agree public-key better models the trust relationship of 1-way cross realm than symmetric key.  Also agree that configuring those relationships has a lot of practical issues.  If it's explicitly…

I don't care if PK better models the trust relationship of a 1-way
cross-realm trust than symmetric keys :) though it does -- I don't
care because we already have addressed the impedance mismatch of
symmetric keying of asymmetric relations (via naming conventions).
What matters to me is the features listed above.

Nico
--