Subject: Re: Please review: http gss authentication mech

From: Martin Rex <[email-masked]>
Date: Tue, 14 Nov 2006 20:20:31 +0100 (MET)

Lisa Dusseault wrote:
> 
> HTTP pipelining does make the use of server-issued tokens difficult  
> unless the tokens have a certain lifetime beyond just one request.

I don't think it is a problem with pipelining.  There might be a problem
with page caching of a web browser depending on how it is implemented
(or configured).

In case that you're referring to HTTP/1.1 rfc2616 secion 8.1.2.2,
then a client that attempts pipelining will already have to deal
gracefully with every situation where the server does not behave
in the expected fashion or wants to close the reason for whatever
server-internal reasons.

A client, that sends out 10 requests on a new connection to a server
that expects authentication according to rfc4559, might receive 10
401 Unauthorized in a row -- or, not unlikely experience connection
closure when the second or third (pipelined) request still doesn't
contain a reaction to the initial 401 Unauthorized server response.

Connection: keep-alive is also not a sticky characteristic,
it may be cancelled with every new response from the server,
invalidating any request that might have optimistically been
sent in advance.

In the normal course of action, a web browser does not start
out requesting more than a single URL from a new server.
It starts with a single URL, which initiates the authentication
handshake.  Once the initial reply is received, it may contain
frames and lots of embedded objects, for which the request
paralellization is started.  Pipelining will work on the
initial persistent connection, but newly created parallel
connections will be forced through the same authentication
handshake in the rfc4559 model, where the authentication is
strictly bound to the persistent communication channel.

If a session re-authentication token is issued (e.g. by the application
layer as a result of a successful rfc4559 authentication) and sent
to the client as a non-persistent cookie, then the client may
re-use this cookie even on parallel and later communication channels.

The drawback of the "session re-authentication token" is that it
is something like a lifetime-limited disclosing authentication,
and it could be stolen an replayed.  Checking the client-IP-Address
on new requests does not necessarily help (middle-boxes!),
might inconvenience clients in certain mobile environments even
without middle-boxes.  Checking the SSL/TLS session id might
not be possible (again: SSL-terminating middle-boxes, like
reverse proxies, SSL-accellerators, load-balancers).

HTTP and Web-Browsers are a pretty bad foundation for building
stateful (state-heavy) client-server applications.  However, it will
likely take some more years before top-level management accepts
this, gets off the hype and agrees to go back to dedicated
persistent communication channels and real interactive communication
protocols instead of HTTP.

The better the band-aids that we produce for the existing flawed
approaches, the longer will our pain and suffering last.  :-\

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Tue, 14 Nov 2006 15:10:04 -0500

Note that delegation could become a problem if session re-authentication
tokens are used. If a request wants to initiate auth with another tier
(e.g. a database) and use a delegated credential established in a previous
request you would need to save the delegated credential somewhere which
is a potential security hazard on an HTTP server (e.g. someone could
put something in their cgi-bin that impersonates someone else).

Mike

---

From: Michael B Allen <[email-masked]>
Date: Tue, 14 Nov 2006 15:13:13 -0500

Note that there is a different place where considerable performance
improvements could be attained.

If clients know, based on previous experience with the server, that the
server will require authentication they could preemtively submit a token
and eliminate one round trip per authenticated request. So each request
would still be authenticated but eliminating redundant requests would
improve performance more than eliminating redundant authentications
since the former involves relatively slow network communication.

IE actually sort of does this now. If you do a POST request and IE
has previously determined that authentication is required, it will
preemptively submit an authentication token (it may also, leave out the
POST data but it may only do this for NTLM, I don't recall if the POST
data is left out if a pre-emptive Kerberos token is sent).

There is one problem with IE's implementation of this preemptive behavior
however. Once it determines that the server requires authentication it
preemtively authenticates for ALL paths. This is undesireable if you
only want to protect part of your content.

Therefore, it would be desireable for the response token to include a
flag that indicates authentication was not necessary. In this way clients
could preemtively authenticate but then stop when told it was unnecessary.

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Nov 2006 21:17:31 +0100 (MET)

> put something in their cgi-bin that impersonates someone else).

That is a problem of credential-delegation within a gss-api authentication.
A session-reauthentication token is nothing more like a session ID
that contains enough cryptographic random bits to make it non-predictable.

Whether the application on the server side attaches a gssapi context
handle or a delegated credential to that server side state is
entirely independent from the use of a session reauthentication token.

*I* always thought that credential delegation and impersonation are
dangerously flawed concepts, and in the last 10 years I have not
heard convincing arguments for their use/existence.

(I consider credential forwarding on explicit request of the user
 something entirely different than credential delegation).

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Nov 2006 21:25:14 +0100

> put something in their cgi-bin that impersonates someone else).
I'll make a note of that for the security considerations section.

       Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 17 Nov 2006 11:18:18 -0600

> That is a problem of credential-delegation within a gss-api authentication.

The problem is NOT specific to the GSS-API, it's general.  See below.

> heard convincing arguments for their use/existence.

The flaw lies in violating the end-to-end principle.  But,

a) You can always build credential delegation and impersonation above
   the security mechanism if you are in control of the app layers
   between the client and proxy and proxy and service.  See above :)

b) This ship has sailed.  Many deployments exist where edge services
   rely on core services.  In such environments the edge services are
   either all-powerful w.r.t. the core services, or they rely on
   credential delegation and user impersonation to access core service.

Nico
--