[Freeipa-devel] Summary of Session discussion

[Adam Young]

On 05/26/2011 02:01 PM, Simo Sorce wrote:
> 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 ?

As Stephen Gallagher points out, Secure cookies are held in memory, not 
on disk.  However, the ipa client is a complete process, and it would 
need to be able to store the cookie somewhere for CLI to use.

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

I might have root on a machine that can mount via NFS, and thus allow me 
to su to your account, and get read access to your home directory.  I 
don't need root on your machine.  BBut again, only an issue if the 
session cookie got written to disk, which shouldn't happen with session 
cookies.
>>    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 ? :)

I think we are not going to pursue the mod_auth_kerb streamlining I 
outline, at least not in the short term.  An additional issue is getting 
the update to mod_auth_kerb accepted.  I'd say we can purse this in 
parallel, as I think it will be a valuable performance optimisation, but 
it does not have to be part of the IPA work per-se.

>> 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.
Yes, and thus we are not going to pursue that approach.

>> 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 ?
Certificates and automount maps are the two we've discussed recently.

>> 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.
Agreed.  It means that subsequent API calls can reuse a specific 
query.    But we want it to be optional, or there would be significant 
overhead, and thus we'll postpone this approach for now.


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