[Freeipa-devel] [PATCH 61] Cache authentication in session

[Endi Sukma Dewata]

On 2/15/2012 2:51 AM, Dmitri Pal wrote:
> On 02/14/2012 01:01 PM, Endi Sukma Dewata wrote:
>>
>> If someone already has a session then changes to another principal,
>> will he get a new session and then reauthenticate against the login
>> URL? Or will he use the same session but just reauthenticate?
>
> AFAIU the session ID will be (should be) lost when you switch the
> principal and new ID returned to the browser.
> The old session is still valid for 20 min if you did not log out but it
> should not be accessible.

I looked at the code briefly, if I understand correctly it looks like 
the server will get the session ID from the cookie and use it to find 
the existing session data from memcached. So if someone does a kinit to 
change principal, the browser will still send the same session ID 
because it doesn't know about the change, so the server will continue to 
use the old session with the old credentials until the session expires 
(which could be a long time if the server keeps resetting the expiration 
time).

Previously without sessions the UI will detect the change as soon as the 
user executes another operation in the UI.

> It seems that everything depends on what is the key for the internal
> cache. I would think that the key should be principal+session ID and
> session ID is long and strong. We said in one of the earlier discussions
> that it should be at least 128 bits of entropy. Was that done? If not
> please log a ticket.

Assuming the principal will be stored in the cookie, it might not work 
because the browser will not know about the principal change so it's 
still sending the same principal.

> So am I right that the key is principal+session ID? If it is just
> principal then yes the session can be resurrected but I do not think we
> want this. If the key is just the ID there is a potential of the
> privilege escalation if one principal tries to guess the ID for another
> active session. Very unlikely but it seems that it is safer to have it
> as a composit key. May be we should file an RFE on this.

Right now the key is just a 48-bit ID.

>> What if he then changes back to the previous principal, will he reuse
>> the old session? If so will he be required to authenticate again?
>
> Old session should not be accessible.

The question assumes that if the user changes principal he will get a 
new session, which doesn't seem to be the case. But suppose that issue 
is fixed, I agree that we need to make sure the old session is destroyed.

>> Would it be possible for someone from another machine to randomly
>> guess a session ID and then take over an existing authenticated session?
>>
> Then we need to make ID even longer.

I believe John is going to make it 128-bit in the next patch.

-- 
Endi S. Dewata