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:]
Sent: Wednesday,
August 25, 2004
3:26 PM
To: ''
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: 613-270-2632
c: 613-799-2632
Entrust
