Multi-round trip extension
nico at cryptonector.com
Mon Sep 1 22:46:19 EDT 2014
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
More information about the krbdev