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 ?
> 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.
> 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
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 Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list