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

[Nico Williams <[e-mail]>]

On Tue, Feb 07, 2023 at 03:03:46PM -0500, Simo Sorce wrote:
> On Tue, 2023-02-07 at 10:48 +0000, Rick van Rein wrote:
> > To do this well, Cyrus SASL leaves a few things to be desired, actually;
> > namely, a state export/import facility.  This is indeed a conflict that we
> > are aware of -- SASL is stateful and HTTP is stateless.  This is the reason
> > that an earlier attempt to HTTP-SASL did not make it.  There is much more
> > clarity now, with the HTTP Authentication framework being written, and the
> > answer is bouncing the "s2s" value to allow for a fully stateless server.
> 
> 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)).

It will never really be the case that symmetric _session_ keys are
stored on hardware tokens for the fairly obvious reasons that: a) that's
just too slow, b) the plaintext of the sessions necessarily ends up
available outside the HW token anyways, and c) it's session keys --
meaning that they lose their value when the session is closed and they
have no value before the session is opened.  Compromised session keys
can be used to decrypt previously recorded ciphertext for the
corresponding sessions, but then, an attacker that can recover session
keys can probably do much worse things without bothering to use those
keys.

Also, SASL session keys will not be used in the HTTP w/ SASL proposal
because the SL part of SASL won't be used either.  That means all the
concerns about [partially- or fully-]established security context export
w/ HW tokens are non-issues as described above.

Still, for more general cases there are two options for dealing with
session keys in HW tokens:

 - for some tokens there may be a way to export the state wrapped in a
   token-local secret key (e.g., TPMs can do this), with the wrapping
   key possibly shared to other cluster members' tokens

 - where that's not possible one can use an authenticated index into a
   table of open token object handles

The second option doesn't play well with clustered servers because then
if you resume at some server other than the one that created the state
then the other server will have to call on the first to complete the
exchange, but that's workable, and there's always the option to use a
hardware token type that can export state wrapped in a key shared with
the other cluster members' hardware tokens.

But again, none of this is ever going to be needed because the HW token
keys will be asymmetric keys used once each during a context token
exchange.

This is really a non-concern.

> > > My first reaction is that this is asking a lot of the SASL library on the
> > > server side to be able to reconstitute and continue a halfway-constructed
> > > SASL session that was negotiated by a different server, but maybe that
> > > first reaction is erroneous.
> > 
> > You are right, this is a new design aspect, and this is why we did not test
> > on round-robin HTTP servers.  I am not sure if it is so difficult to build
> > into a simpler library that has collected less history, though.  SASL can
> > come along, but some implementations are bound to make an easier link to
> > HTTP than others.
> 
> It seem you have a few uses cases in mind, do they all work in a
> distributed/load balanced environment?

There's no proposal here to use the SL part of SASL -- there couldn't be
as otherwise each HTTP request would require setting up a brand new SASL
context due to the fact that SASL's SLs are octet streams.  So the only
concern is multi-round trip context establishment w/ HW tokens being
involved, which is addressed above.

Nico
--