[Freeipa-devel] Summary of Session discussion

[Simo Sorce]

On Thu, 2011-05-26 at 12:53 -0400, Adam Young wrote:
> There are four cases where we've discussed using sessions for 
> optimizations.  During today's phone discussion we analysed them.
> 
> 1.  Avoiding the negotiate round trip.
> 
> Requesting a page protected by Kerberos requires two round trips to the 
> server:  1 for the initializ request, which gets denied with the 
> negotiate challenge, and one for the negotiate response.  mod_auth_kerb 
> can fall back to userid/password.  THe suggestion was t hat we allow 
> mod_auth_kerb to set a session cookie after a successful negotiate 
> request.  Future requests can use that cookie to bypass the negotiate 
> handshake.  The problem with this approach is NFS home directories,

Can you expand the reasoning about NFS home directories ?

>  and 
> root users being able to get  access to the session cookies, allowing a 
> replay attack.

Root can simply steal your TGT, that is not a concern we have any reason
to raise here.

>   Note that this is a problem with the userid/password 
> fall-back as well.  We are not going to pursue this right now.

We are not going to pursue using sessions ? Or concerning ourselves with
these issues ? :)

> 2.  Caching the service ticket.  Once the http request has gone through, 
> the ipa web server needs to request a service ticket for LDAP.  If the 
> session contained the service ticket, the could be bypassed for 
> additional requests.  Since the request has to be validated by Kerberos 
> for the initial negotiate call, there is no additional loss of security 
> in caching the ticket.

Indeed.

>      A potential alternative to server side caching is for the client to 
> request the service ticket and send it in the negotiate handshake.  
> There is some question as to whether the web server would be able to 
> acces this ticket, and also whether the client can somehow request a 
> ticket that the server can use, and still comply with the Kerberos 
> standards.

This should be possible, but there is no client that can do that right
now, and changing clients is simply out of our reach in most cases.

> 3.  File Upload.  Session time out provides a means to automate the 
> clean up of files that might otherwise be orphaned.

What kind of files ?

> 4.  Windowing search results.  the 'find' APIs as implemented by LDAP 
> limit the responses to 200 records by default.  One request we've had is 
> to provide sorting and windowing.  Windowing here is defined as, for a 
> sorted response, return a delimited number of records starting at an 
> offset greater than 0. The LDAP implementation requires the equivalent 
> of a cursor from the requester, in this case the Apache server.  To 
> maintain association between the user and the cursor, the cursor 
> identifier would be stored in the session.   Implementing this correctly 
> will require further design.  It will likely be done in the future.

The cursor need also to be associated to a specific query, cannot be
just a session-global variable.

> In summary, the caching of the service ticket alone provides a 
> compelling reason to implement sessions.  File upload will take 
> advantage of them.  Other uses may be found over time.

Very good, thanks for taking up on this analysis task.

Simo.

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