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.
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
