Multi-round trip extension

[Nico Williams]

On Mon, Sep 1, 2014 at 7:35 PM, Simo Sorce <simo at redhat.com> wrote:
> On Mon, 2014-09-01 at 16:49 -0500, Nico Williams wrote:
>> It'd be nice if the AP / mech protocol could recover from various
>> failures by doing one more round-trip, such as:
>>
>> [...]
>> Discovering HTTP/Negotiate apps that can't deal with more than one
>> round trip will. be. fun.  We may have to exempt the HTTP service in
>> some cases.
>
> In my experience most will fail, either in the client or in the server,
> as you need connection bound state in the server (or complicated session
> management even before authentication is completed).

That's about what I expect.  HTTP/1.x is simply not compatible with
any authentication method that requires connection state.

We could add encrypted exported security contexts[*] to HTTP/Negotiate
to make it separate GSS state from the connection.  But that's a lot
easier said than done: there are a great many
libraries/servlets/plugins/modules/... that would have to be fixed to
make that work.

Still, suppose a client fails to connect the first time because of
KRB_AP_ERR_BADKEYVER or some such, and then the initiator mechanism
deletes the old service ticket from the ccache as a result.  The app
might fail when presented with GSS_S_CONTINUE_NEEDED, but at least
recovery won't require running kinit!  The user might have to restart
the app, but not run kinit first.  That's still a major improvement!

[*] Technically this is not supported for partially established
contexts, but there's no reason it couldn't be.  Even where it isn't,
a bit of IPC and a small integer index into a table of contexts should
suffice.