Multi-round trip extension

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Multi-round trip extension

Nico Williams

It'd be nice if the AP / mech protocol could recover from various
failures by doing one more round-trip, such as:

 - skew too great

 - wrong kvno (why force users to kinit?! this is a huge pain-point for
   users!)

 - replay cache avoidance (server doesn't want it; challenge/response)

 - replay cache false positive (if the server is using a probabilistic
   rcache data structure)

Protocol-wise we just need an Authenticator flag by which the client/
initiator can tell the server that it is willing to engage in one
more round trip.  The server/acceptor needs a way to indicate the
same in a KRB-ERROR (or through an extended AP-REP, maybe? when the
server can decrypt the Ticket).

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.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Multi-round trip extension

Simo Sorce-3
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:
>
>  - skew too great
>
>  - wrong kvno (why force users to kinit?! this is a huge pain-point for
>    users!)
>
>  - replay cache avoidance (server doesn't want it; challenge/response)
>
>  - replay cache false positive (if the server is using a probabilistic
>    rcache data structure)
>
> Protocol-wise we just need an Authenticator flag by which the client/
> initiator can tell the server that it is willing to engage in one
> more round trip.  The server/acceptor needs a way to indicate the
> same in a KRB-ERROR (or through an extended AP-REP, maybe? when the
> server can decrypt the Ticket).
>
> 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).

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Multi-round trip extension

Nico Williams
On Mon, Sep 1, 2014 at 7:35 PM, Simo Sorce <[hidden email]> 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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Multi-round trip extension

Simo Sorce-3
On Mon, 2014-09-01 at 21:46 -0500, Nico Williams wrote:

> On Mon, Sep 1, 2014 at 7:35 PM, Simo Sorce <[hidden email]> 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.

Well, it depends, my mod_auth_gssapi supports keeping auth tied to a
connection, and both Internet Explorer and Firefox oblige and keep the
whole exchange on the same connection. In fact NTLMSSP authentication (2
full roundtrips) works in this mode.

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

It is not too hard to set a cookie and keep state (export partially
established context and store it in some local cache) in the server
either, though sending the state to the client might make it work across
balancing servers that do not keep a client connected to the same server
between any 2 exchanges, not sure it is worth dealing with those cases
though. I haven't yet fully investigated the case of proxies.

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

In MIT code exporting partially established context works in recent
versions.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Multi-round trip extension

Nico Williams
On Tue, Sep 2, 2014 at 7:39 AM, Simo Sorce <[hidden email]> wrote:
> Well, it depends, my mod_auth_gssapi supports keeping auth tied to a
> connection, and both Internet Explorer and Firefox oblige and keep the
> whole exchange on the same connection. In fact NTLMSSP authentication (2
> full roundtrips) works in this mode.

Sure.  But what about proxies?  What about many other HTTP clients and
servers?  (libcurl? nginx? node this or that, various Java classes,
...).

> It is not too hard to set a cookie and keep state (export partially
> established context and store it in some local cache) in the server
> either, though sending the state to the client might make it work across
> balancing servers that do not keep a client connected to the same server
> between any 2 exchanges, not sure it is worth dealing with those cases
> though. I haven't yet fully investigated the case of proxies.

Cookies are not required to implement by clients.  To maximize interop
a server would have to be prepared to use both, cookies and
per-connection state.

> In MIT code exporting partially established context works in recent
> versions.

Which is good.  I mentioned the non-standard aspect of this because
that's come up a lot before.

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev