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

[Simo Sorce <[e-mail]>]

On Tue, 2023-02-07 at 10:48 +0000, Rick van Rein wrote:
> Hello Russ,
> 
> > I think this would work theoretically (at least I don't see why it
> > wouldn't), but I'm very curious about how widely this has been tested in
> > HTTP scenarios involving round-robin load-balancing.
> 
> No, this has not been tested yet.  Not sure it adds much though; if the
> mechanism allows a stateless HTTP server then jumping from one to another
> does not matter.  On another note, other layers tend to face this same
> problem and seem to solve it by a consistent client/server connection,
> and only use the round-robin part as an initiation rite.
> 
> > Making the client
> > replay the state provides enough of a theoretical hook to allow moving an
> > in-progress authentication session from one backend server to another, but
> > has this been done in practice with Cyrus SASL and similar SASL libraries?
> 
> 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.

Although possible, in many cases this is simply not available,
especially when hardware tokens (HSMs, SmartCards, TPMs) are used to
deal with the cryptography.

(PKCS#11 defines a pair of functions to export/import state but most
tokens don't implement it, even software tokens).

> > 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?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc