Re: [kitten] [EXTERNAL] Re: Windows Intent to revive and implement IAKerb draft-ietf-kitten-iakerb-03

[Nico Williams <[e-mail]>]

On Sat, Feb 18, 2023 at 04:56:24AM +0000, Steve Syfuhs (AP) wrote:
> Ah, I think I follow the failure case now Nico. I'll have to think
> about this in the generic case. In Windows our implementation [...]
>                                                          [...]. This
> doesn't help with non-Windows clients though.

We can do a non-generic thing if need be, and we can find a way to stash
the information we need in a way that related mechanisms can see, much
like what you're doing.

> For single shot I just mean encapsulation protocols that can't
> round-trip. [...]

Right.  About that.  There's two important sub-cases:

 - mechanisms that can generate session keys for wrap/unwrap ("security
   layers" in SASL speak),

 - and ones that can't.

For the latter the JWT pattern is practically canonical -- we could do
PKIX-oriented variations and who knows what, but at the end of the day
we get a bearer token of some sort that can be validated and which
carries metadata we want (e.g., the presenter's name, claims, etc.).

For the former the common patterns are:

 - Kerberos -- we're all familiar with it here

 - mech_dh

In mech_dh the initiator looks up the target's public [EC]DH key in a
directory, then it computes a shared key given the initiator's private
key and the target's public key, then it constructs an authenticator
(like the one in AP-REQ) and sends that and stuff that lets the target
know and validate the initiator's public key.

mech_dh looks and feels a lot like Kerberos, except it's actually dead.
mech_dh has a "single-shot" mode, and a mutual mode just like Kerberos.

JWT enriched with an ECDH public key for the user and a way for the
client to find the audience's public key would... look a lot like
mech_dh: you get to have a session key if you want it, but also you
don't have to use it if you don't want it, and you get to do it with a
half round trip (single shot).  You can even do channel binding in a
half round trip mechanism since there's always a way for the server to
reject auth.

Enrich that further with Kerberos style names and what not (PAC,
whatever) (for backwards-compatibility), and you have something that can
function as a drop-in replacement for Kerberos.

(Mind you, the PAC should be replaced with a URI for the PAC.  Ticket
bloat is a serious problem.)

Things about Kerberos that are fairly good and worth keeping

 - naming

 - in a PQ world, maybe, Needham-Schroeder as an optimization for
   expensive PQ PK

Things about Kerberos that suck:

 - that the client has to have heavy, bloaty libraries

   (Well, I have implemented a Negotiate-token-issuer service, so it's
   possible to do Kerberos with dumber clients that don't even implement
   a single Kerberos enctype.  But this would have to become widely
   used.)

 - that the claims are encrypted (in the Ticket)

   This is both awesome for security (servers can't fail to validate the
   token) and terrible (hard to observe for diagnostics, etc.).

   (Confidentiality of the ticket/token contents is not that important
   in a world where every application protocol runs over TLS, so I don't
   count that feature as a win.)

   I've also build an HTTP-based service for fetching keytabs, and a
   feature where service principals in a namespace can exist no matter
   what, with their keys being derived from the namespace's keys, the
   principal's name, and the "current epoch".  Servers have to keep
   fetching keytabs the way they also have to keep fetching JWKs for
   validating JWTs.  So Kerberos can be easier to deal with than it
   usually is, but few if any sites make it as easy to deal with as JWT.

 - that it's not JSON-based

   It's not that I love JSON, but the thing is that even with
   now-defined GSS functions for accessing authorization data: it's a
   lot of work just even to _use_ those functions, and even more work to
   implement them.  With JSON there's nothing special to do besides
   define bits of schema.

   It's not that DER is awful -- it is, but protocol buffers is also a
   TLV encoding, so that's not the issue.  _All_ TLV encoding are
   terrible, of course, but the real issue is that ASN.1/DER tooling
   does not exist for _every_ programming language.

   Practically every language has at least one JSON library.  Where a
   language doesn't then the average programmer can figure out how to
   build or port one -- as dangerous as that can be, doing the same for
   DER is far more dangerous and a far larger cognitive load.

> You have captured the exact problem with unknown names. We can extend
> the protocol to solicit an SPN, and it turns out if you're willing to
> look the other way on good protocol manners, this can work today
> within spec. We just lose server auth. This *is* a net-win for
> security still, just not much of one.

Makes me wince hard.  You can mitigate the problems with this by having
the client tell the KDC that it's doing this so that the KDC can refuse
if the target is not trusted for this.

Eventually you'll have to break apps that do the insecure thing.

> One other thing I was thinking about. We came across a fun
> fragmentation bug in SPNego that's probably been around forever. When
> one party has a limited buffer size and we aren't allowed to allocate,
> we will fragment the message, where the other party sends an empty
> message to indicate gimme-more until full. The client->server flow has
> always worked, but the server->client flow was never implemented (when
> is the REP ever bigger than the REQ? Now any time it's not an AP). The

Ooof.  You can also have large replies when doing user-to-user auth.
Also if we had a reverse mode mechanism, or if we had some sort of more
symmetric mechanism (where the reply to an AP-REQ is also an AP-REQ so
both peers can see each other's PAC).

> bug, aside from lack of implementation, is that callers tend to assume
> responses with continuation are not empty and fail if they are. I've
> fixed it by always sending a specific value to indicate more is
> requested, but who knows how that plays with interop. Frankly I
> haven't done my research within all the RFCs to see if there's already
> an answer for this, but figured I'd include it here if folks have
> thoughts.

The fragmentation thing is a hack, but oddly it's a hack that Heimdal
has too (in master).

Nico
--