Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list

[Nico Williams <[e-mail]>]

On Tue, Feb 07, 2023 at 03:16:27PM -0600, Nico Williams wrote:
> > This requires, in some cases, that the crypto state is fully
> > exportable.
> 
> It is almost invariably the case that the context is software-only.
> Even when it's not, it still can be as explained below.
> 
> > Although possible, in many cases this is simply not available,
> > especially when hardware tokens (HSMs, SmartCards, TPMs) are used to
> > deal with the cryptography.
> 
> Most HW token resident keys will be asymmetric keys that a mechanism
> will use just once per-context.  Even on a clustered server it is
> possible to have either the same key shared to all the cluster members'
> tokens, or different-but-equivalent keys (e.g., N keys each with
> certificates for the same name(s)).

I'd like to expand on that a bit.

First we might like to have a precise definition of what mechanism
design feature can make it difficult to implement with non-session keys
stored in HW tokens.  Then we could use that to analyze whether we have
any security mechanisms for which there would be an incompatibility
between partially-established security context export and HW tokens.

Here's my first attempt at a precise definition of security mechanism
design points that lead to special considerations regarding HW tokens:

 - for each non-session key used in security context establishment:

    - if any of the following is true, then using the mechanism with
      non-session keys stored in HW tokens will have some complications:

       - condition #0:

          - the client/initiator knows and uses the public keys of the
            server/acceptor a priori

            (mech_dh has this)

       - condition #1:

          - that key is used in the consumption of more than one
            security context token

         and

          - that key is used in the production of more than one security
            context token

         and

          - that key cannot change during the time that a security
            context is being established

       - condition #2:

          - that key is used in the consumption of one security context
            token

         and

          - that _same_ key must be used in the construction of another
            security context token which is not the immediate reply
            token to the first one

For all those conditions it suffices to be able to duplicate the
relevant keys to all the HW tokens of the members of the server cluster,
though other ways exist to handle the problem (see previous post).

The PKI-based GSS/SASL mechanisms I know about:

 - SChannel (i.e., TLS as a GSS-API mechanism)
 - PKU2U
 - the never-really-finished SPKM
 - the never-standardized mech_dh

Of these, TLS 1.3 w/ ESNI meets condition #0 for the ESNI key, but
neither condition #1 nor condition #2.  For ESNI keys there is the
obvious workaround mentioned above.  The ESNI keys are not as important
as the other keys, so I suspect that duplicating ESNI keys to the tokens
of all cluster members is a non-issue.

TLS 1.3 w/o ESNI meets none of the above conditions.

mech_dh has condition #0.  That's sad, but there's the above-described
workaround.

Neither PKU2U nor SPKM meet any of the above conditions.

I don't know of any _other_ GSS or SASL mechanisms that use PKs,
therefore I don't know of any GSS or SASL mechanisms that use PKs in
ways that would be incompatible with the [wrapped] export of security
contexts on account of those keys being in HW tokens.

I believe the TLS 1.3 ESNI condition #0 case is a non-issue.  We can
dismiss mech_dh (it's dead, though it is interesting) or accept the
mentioned workarounds as sufficient.

That leaves mechanisms where a symmetric key is used in context
establishment, mechanisms like:

 - SCRAM, DIGEST
 - Kerberos
 - various PAKEs

I believe none of SCRAM, DIGEST, or Kerberos meet any of the design
conditions I listed above, therefore these mechanisms also have no
special concerns regarding non-session keys stored in HW tokens.

That leaves the PAKEs to consider.  All the client-initiated PAKEs I'm
familiar with (which is not the CFRG PAKEs) do not meet any of the
conditions listed above, therefore there should be no special
considerations for those PAKEs w/ HW tokens except the obvious one: that
the shared secret (the password) -or verifier for it for augmented
PAKEs- has to be duplicated to all the HW tokens for servers that need
to be able to use it.  We should check that this is also true of the
CFRG PAKEs.

Unless I missed something, that fully disposes of the concerns w.r.t.
non-session keys in HW tokens.

GSS-API specifically rejects exporting of partially established security
contexts, and that appears to be motivated by the HW token concerns
we're discussing (and Martin Rex has chimed in in the past about that),
but I think that's just because in the early 90s it wasn't clear that
all mechanisms could and would be built in such a way that these are
non-concerns.

GSS-API _does_ specifically allow exporting of fully-established
security contexts, which implies that no one in the early 90s imagined
wanting to use HW tokens to store _session_ keys.  I think that is still
the case for the reasons I gave in a previous post.

And with that I think we can say that there are really no concerns at
all regarding keys that live on HW tokens.  Except one concern: maybe we
ought to have an RFC saying "don't design security mechanisms that have
any of the conditions [listed above]"!

Nico
--