Paul Madsen wrote on 8/31/2004, 9:14 AM:
The
requirements of uniqueness as set out in Section 1.2.4 for the ID
attribute wouldn't ensure privacy as the IDP could reuse id values to
different SPs for the same user.
so, whether its
SessionIndex or Assertion ID, if and when privacy matters, we need to
make clear that the IDP MUST use unique values to different SPs.
It's kind of
useless to protect SessionIndex if you don't protecte Assertion ID, so
we need that protection on the Assertion ID in any case, so as long as
we get it right there, we can use that protection for the session index.
Conor
paul
-----Original Message-----
From: Conor P. Cahill [mailto:]
Sent: Tuesday, August 31, 2004 8:44 AM
To: Mishra, Prateek
Cc: Paul Madsen; ''
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:]
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
