Subject: [kitten] kx509 update/redesign (Re: PKCROSS)

From: Nico Williams <[email-masked]>
Date: Fri, 12 Jul 2013 00:27:52 -0500

On Thu, Jul 11, 2013 at 11:59 PM, Russ Allbery <[email-masked]> wrote:
>> Ah.  OK.  How much change do you think it needs?  Some?  Or are we
>> 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.

True.  Actually, Kerberos itself is like that... (ah no, let's not
discuss GSS pre-auth in this thread :)

Anyways, if this PKCROSS design is to go anywhere it will need a
Standards-Track kx509.

If we'd need kx509 to allow for stateless server operation then GSS
would be, once more, a bit of an odd-duck, as in KDC exchanges.  The
same solution (export context, encrypt in local key, send back as
state cookie) would work, provided we don't need replay protection,
but the obviously easy thing to do is to... use raw AP exchanges.

Is it so weird, that kx509 uses AP-REQs instead of GSS, then?  Yes,
but not quite too weird:

If I had to design this and *not* use GSS I'd... start with the
thought of shoving a CSR in to an authorization-data element of the
Authenticator, sending an AP-REQ, and expecting back an AP-REP +
KRB-PRIV in the same reply.  Why privacy?  Because I might be trying
to hide my principal name, but then I'd want something like FAST so I
could use an anon PKINIT ticket as an armor ticket.  By which point
the whole thing really begins to look like a repeat of the existing
KDC exchanges, so maybe we should do just that, sending a CSR as
authz-data in a KDC-REQ for the kx509 service principal, and re-using
the whole FAST machinery.

If I had to design this and use GSS, not raw Kerberos, I'd probably do
the encrypted state cookies thing and use timestamps and clocks to
reduce the window for replays and a small table of extant, unexpired
state nonces -- think TCP SYN cookies.  Or accept state and set a
timer on each partially established security context and its
corresponding TCP connection (after all, the web runs on HTTPS on TCP,
if they can deal, so can we, and this is a service that can expect
much lower load than a normal KDC).  Either way privacy protection
would be implemented by tunneling GSS in GSS.

If we can re-use the FAST machinery of existing FAST clients and KDCs
then I think it becomes quite tempting to do so.  OTOH, the beauty of
using GSS is that the CA could then work with any GSS authentication
mechanism that can provide at least integrity protection to the CSR
(e.g., via channel binding), and that's not something I'd want to give
up on.

If we can rely on Alejandro and Rafa finishing GSS pre-auth, then FAST
seems like the way to go.  No?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Jul 2013 14:36:58 -0500

Having thought about this a bit, I'd like to note one thing and
propose a design.

The note: there's not much difference between issuing a Ticket and a
Certificate, nor, for that matter, is there much difference between
asking for a Ticket or a Certificate.  In either case we need
machinery *like* the machinery we already have for KDC exchanges.

The proposed design:

 - add a new type derived from KDC-REQ and KDC-REP, call it KCA-REQ and KCA-REP
 - a KCA-REQ would be like a TGS-REQ in that it would carry a PA-TGS-REQ
 - a KCA-REQ would also carry a PA-KCA-SUBJECT-PUBLIC-KEY or PA-KCA-CSR
 - a KCA-REQ would also carry a PA-KCA-REQ beaing a signature with
that key of the rest of the KDC-REQ (including the other PAs, but
excluding, obviously, the PA-KCA-REQ)

 - the KCA-REP would be like any other KDC-REP, but instead of bearing
a Ticket it would bear an OCTET STRING containing a Certificate, and
while we're at it, the cert should be in the enc-part of the reply,
and while we're at it, might as well include a SEQUENCE OF octet
strings containing OCSP Responses for the cert, the KCA's cert, -- the
trust path.

 - use a different RRSet naming for KCA than for KDCs so as to enable
isolation, but otherwise default to port 88 and the same hosts as KDCs
(they can still isolate the KCA functionality and key material using
IPC after all)

Rationale:

 - there's little difference between issuing a ticket and a cert ->
reuse the ticket issuance machinery as much as possible

 - we'll want FAST for KCA for the same reasons as we did for the AS and TGS

Cons:

 - doesn't use GSS

   But that's OK: we'll just have to finish GSS pre-auth.

Nico
--