RE: [security-services] SessionIndex and Privacy Text

["Conor P. Cahill" <concahill@aol.com>]

Thomas Wisniewski wrote on 8/31/2004, 9:01 AM:

When I read thru the Liberty specs, it seem to imply that the session index was a way to represent different sessions for a single user. For example, a user using 2 machines/browsers to log in. Consider the case where a user only logs in once at an IDP (assume it gets assigned session index value of 1), and then uses that authentication/session at the IDP to authenticate to various other SPs. My take from the Liberty specs was that the session index for all the SPs could be set to 1. In general if thousands of users log in from a single machine/browser only, their session index would have a value 1.

Liberty didn't
require this, but this is what was intended and what many entities
implemented (although I think they used a 0 rather than a 1 as the base
:-).

 

Eventually, there might be some users that log in from a second machine to an IDP (that session index gets the value of 2). From there, they use that authentication to get into other SPs (perhaps the same ones as the other session or perhaps new SPs -- that is irrelevant). The session index value of 2 would be used during an authentication response by the IDP for this case. In general you might have hundreds of users logged in twice.

That case was the
main reason we added session index (the fact that the the user could
start multiple independent sessions, typically on different computers).

So my question is, if we use the same session index value for all SPs (if the authentication is based on the same IDP session) why is privacy an issue. In general, an SP site would see thousands of 1's, hundreds of 2's, tens of 3's, etc... And because users can go to arbitrary SPs, it is extremely unlikely that you can match up these session indexes.

This discussion is
about the mechanism used to identify the different sessions.  The
method you mention (index) is one that makes sense, although the use of
a random number in a small sequence of small integers will be a bit
more safe than using ordered numbers as even you point out that there
may just be tens of users with a 3 making it muc more likely that they
can be correlated.

From the Liberty specs and from a technical perspective, I took the need for a session index as a requirement to be able to logout users on a per machine/browser basis. So if the original user browser session above is being logged out (session index value of 1), the other session (value of 2), should not be affected.

We definately want
to identifiy a session.  The model you have described here is the model
that Liberty first implemented and it can work.  The alternatve model
of using the actual asseriton ID is a different approach that meets the
same needs and may be easily implemented while meeting the same needs.

Conor

 

Thanks, Tom.

-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: Tuesday, August 31, 2004 8:44 AM
To: Mishra, Prateek
Cc: Paul Madsen; 'security-services@lists.oasis-open.org'
Subject: RE: [security-services] SessionIndex and Privacy Text

I think it would be useful to document the two common mechanisms used in liberty solutions for this index:

        a) small integer (which we have in paul's suggested text)
and   b)  the assertion ID itself is stored in the session index.

The second seems to have issues with the "MUST NOT be a unique..." requirement although it doesn not violate privacy.

So, my recommended verbage:

When privacy is a concen, care must be taken to ensure that the SessionIndex element does not invalidate other privacy mechanisms - the value MUST NOT be usable to correlate sessions across different SPs  Two recommended solutions are provided below: 

• The authority uses small positive integers (or reoccurring constants in a list) for the SessionIndex, then it SHOULD choose the range of values such that the cardinality of any one integer will be sufficiently high to prevent a particular user's actions from being correlated across multiple service providers. The authority SHOULD choose values for SessionIndex randomly from within this range (except when required to ensure unique values for subsequent AuthnStatements to the same service provider).
• The authority uses the Assertion ID value in the Session Index element. 
  

Hmm... Thinking about this, we could just move to using the assertion ID since storing that value at the SP is little different than storing the session index and for the IDP, they probably keep track of the assertion IDs that they have issued at least for the lifetime of the assertion.

If we did use the Assertion ID, we could simply get rid of the session index.

Thoughts?

Conor
Mishra, Prateek wrote on 8/30/2004, 4:32 PM:

+1. We just finished puzzling over the “small integer” suggestion. In any case, as the proposed text suggests, this issue is relevant only when privacy is a concern (admittedly often).

- prateek

---

From: Paul Madsen [mailto:p.madsen@entrust.com]
Sent: Wednesday, August 25, 2004 3:26 PM
To: 'security-services@lists.oasis-open.org'
Subject: [security-services] SessionIndex and Privacy Text

Hi, some comments on Lines 977-981 in Core

1) its not clear to me whether this requirement is normative on all deployments or only on those for which privacy is a issue. The preface 'For privacy reasons' somewhat gives the impression that this is a general requirement. This contrasted to potential alternative text e.g. '*When* privacy is a concern ...'

2) when combined with the previous 'SHOULD be a small, positive integer', the 'MUST NOT be reused in subsequent assertions
given to different relying parties about the same principal' seems contradictory

    a) if small integers are used for SessionIndex, then for any reasonable number of simultaneously logged in users, the high cardinality of the individual SessionIndex values will prevent their use by rogue SPs for collusion, i.e. there will so be many users all with SessionIndex of '3' that no two SPs will be able to use this value to pinpoint a particular user. This is acknowledged by the last sentence of the para, 'MAY be a small integer value that is used in assertions issued on behalf of many different subjects at the same time'. Consequently, the restriction against reuse seems overconstraining.

I imagine that the MUST NOT reuse rule is motivated by the potential for the SessionIndex value to be something other than a small integer. We could differentiate these cases given their different aspects.

    b) if rogue SPs know that the IDP MUST NOT reuse SessionIndex values, this actually gives them more information than if the IDP were to simply insert random values (possibly within some defined range) for the SessionIndex. For instance, if two SPs are comparing logs for a bunch of users they know were simultaneously logged in at IDP, <AuthnStatement>s with the same SessionIndex can only be for different users and so can be discarded.  A bonus would be that the IDP would no longer  need to keep track of which SessionIndex's were used inter-SP (it would still need to intra-SP)

My proposed replacement text

When privacy is a concen, care must be taken to ensure that the SessionIndex element does not invalidate other privacy mechanisms - the value MUST NOT be a unique value identifying a principal's session at the authority. 

If the authority uses small positive integers (or reoccurring constants in a list) for the SessionIndex, then it SHOULD choose the range of values such that the cardinality of any one integer will be sufficiently high to prevent a particular user's actions from being correlated across multiple service providers. The authority SHOULD choose values for SessionIndex randomly from within this range (except when required to ensure unique values for subsequent AuthnStatements to the same service provider).

if the authority uses some other scheme for the SessionIndex attribute, it SHOULD choose values for SessionIndex randomly.

 

Paul 

-----------------------------------------------------------------

Paul Madsen

e:  p.madsen@entrust.com

p:  613-270-2632

c:  613-799-2632

Entrust

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.