[Freeipa-devel] Summary of Session discussion

[Simo Sorce]

On Thu, 2011-05-26 at 14:19 -0400, Dmitri Pal wrote:
> 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 ?
> 
> Cookie can be stored on the home directory of the user and user home
> directory can be NFS mounted so if we save anything important in the
> cookie the NFS root would be able to impersonate the user. It assumes
> that TGTs are not stored on the NFS in this case so replacing the TGT
> auth with fast session cookie auth would be a security issue.
> I hope I understand the issue correctly.

We can store the the cookie in the ccache, so that we have it in the
same place the TGT is. We shouldn't save it in the home, as it is
insecure indeed.

> >>  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.
> 
> NFS root?

if by "NFS root" you mean the root user on the NFS server serving out
your home directories the answer is no. As the ccache is stored in files
local to the system.

> >>   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 ? :)
> 
> We are not going to try to avoid kerberos renegotiation on every request.

Why not ?
Unless you have other concerns the one expressed above are all
non-issues.

> Hm should we consider something like Oauth in this case?

It would have exactly the same issues except it will be more complex to
implement, so if you can do one you can do the other.

> >> 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.
> >
> 
> In any case if we cache the ldap ticket we need to get it from the cache
> before finishing the request.

EPARSE.

> The question came up: is the python-kerberos/krbV packages provide the
> interface to the CC to get the ticket.

If python-krbV doesn't yet it should be relatively easy to add,l I
expect no more than a couple days work to add enough functionality if it
is not there.

> >>      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.
> >
> 
> We can do it in the XML-RPC/JSON outside of kerberos but is it worth it?

No, we do not want to get in the business of forwarding credential
caches outside of the standard protocols, *that* is asking for trouble.

> We need to extract the ticket first.

You do not have direct access to the credential cache from within the
browser so you wouldn't be able to do that for the WebUI anyway.

Building a whole mechanism like that just to optimized the CLI when we
can do a much better job server side looks like a waste, plus it would
force third party implementations that want to use the XML-RPC channel
to do things they may possible not be able to do either, forcing them to
the less efficient way. Not good.

> >> 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 ?
> 
> Entitlements

I guess I miss too many details to understand this point, but given it
doesn't seem to be relevant to the security aspect I think I'll just
ignore for now.

> >> 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.
> 
> You can limit it to have one cursor open per session at a time so you
> can use it as session global.

Dangerous.

> You do not need to have to queries paginated at the same time from UI so
> there is no need to keep more than one cursor.

We might not do that now, not sure in future.

We should at least have a key/cursor pair to allow UIs to keep multiple
cursors. It's easy to do (just a hash table).

Simo.

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