Re: Please review: http gss authentication mech

[Martin Rex <martin.rex at sap.com>]

RL 'Bob' Morgan wrote:
> More significantly, draft-nystrom-http-sasl-12.txt only works when 
> persistent connections are used, which is a showstopper.

Microsoft's implementation (rfc4559) also support only persistent
connections.  The request-reply is basically half-duplex until
the security context is established, and after that it becomes
regular HTTP/1.1 connection: keep-alive.  In none of the successive
requests on the persistent channel is it visible that there was
a GSS-API based authentication in the beginning.

Every new communication channel requires a new gss/spnego
authentication handhshake.

A gss-api based authentication is fairly expensive and requires
at least two tokens (under spnego), so a full authentication of
every request would be prohibitively expensive.

On the server-side, binding the lifetime of the gssapi security
context to the socket of the persistent connection is IMHO quite
sensible.


There is a certain problem of such a communication scheme with
reverse proxies, ssl accellerators and load balancers, which may have
difficulties providing persistent connections.
"Request pooling/aggregation" between the (server-side) middle-box
and the backend might be difficult.


> Hence the 
> text in http-gss:
> 
>     session.  Instead opaque identifiers in the GSS challenge option
>     field are optionally used together with channel bindings to provide a
>     way to share a security context over several HTTP connections.

I don't really understand what you mean by that, but it really doesn't
sound right.


Channel bindings are IMHO a broken concept (I know Nico doesn't agree,
because his CCM mechanism desperately needs them).  (Traditional)
channel bindings break many architectures in a horrible fashion because
they link characteristics from entirely seperate communication layers
and fail with the addition of the first middle-box to the communication
path (proxy,app-level gateway,firewall).


A much better approach to "forking" sessions that were authenticated
in rfc4559-style is that the application issues a (cryptgraphically strong)
session re-authentication token which the client needs to re-send with
*every* new request.

The existing rfc4559 with SPNEGO&Kerberos uses a 2-token security
context establishment, so if the application issues a session
re-authentication token which the client adds to every request,
then this scheme works even with servers-side reverse proxies
and load-balancers that pool&aggregate requests over a small
number of connections between the middle-box and the backend.


Traditional Web-Browsers have only limited functionality to replicate
session authentication tokens in successor requests.
 - basic authentication credentials
 - cookies
however only cookies can be set on request of the server.

It would have been a good idea to have the browser replicate
a server-issued (crypgraphically strong) token on a www-authenticate:
header field for every successive request after a gss/spnego handshake,
but it appears the designers of the rfc4559 authentication scheme forgot to
specify this, so right now, the use of non-persistent cookies and
a preference or requirement of an SSL/TLS protected communication channel
is probably the most portable design approach (with the least impact
on the creative features of middle-boxes).  If reverse proxies with
load balacing to the backend are involved, the session re-authentication
token must contain enough plaintext information for the reverse proxy
to find the backend server that created this session for repeated
or new network connections.


-Martin

_______________________________________________
Kitten mailing list
Kitten at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten