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

[Nico Williams <[e-mail]>]

On Sat, Jan 28, 2023 at 04:20:42PM -0800, Russ Allbery wrote:
> Russ Allbery <[e-mail]> writes:
> > I was curious after reading the initial message how this new proposal
> > planned to deal with the multi-step authentication negotiation process
> > in HTTP.  Maybe that's being discussed on the other list?
> 
> I've now looked at the spec, and it looks like this is being handled with
> 401 or 407 responses plus embedding the server state in the response and
> expecting the client to reflect it on subsequent requests.
> 
> 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.  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?
> 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.

Certainly the state should be encrypted, but this does create replay
attacks, and whether a SASL mechanism is vulnerable or not may vary.

Also, this implies that there is something in SASL like
GSS_Export_sec_context() that works with partially established contexts.
That function would have to have direct support for encrypting the state
so that if the mechanism were vulnerable to replays then it wouldn't
implement the encrypted state functionality.

Nico
--