security-services message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: SessionIndex and Privacy Text
- From: Paul Madsen <p.madsen@entrust.com>
- To: "'security-services@lists.oasis-open.org'" <security-services@lists.oasis-open.org>
- Date: Wed, 25 Aug 2004 15:26:25 -0400
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
p: 613-270-2632
c: 613-799-2632
Entrust
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]