[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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 <mailto:concahill@aol.com>
]
Sent: Tuesday, August 31, 2004 8:44 AM
To: Mishra, Prateek
Cc: Paul Madsen; ' security-services@lists.oasis-open.org
<mailto: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
<mailto:p.madsen@entrust.com> ]
Sent: Wednesday, August 25, 2004 3:26 PM
To: ' security-services@lists.oasis-open.org
<mailto: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: <mailto:p.madsen@entrust.com> 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
<http://www.oasis-open.org/apps/org/workgroup/security-services/members/leav
e_workgroup.php> .
------_=_NextPart_001_01C48F61.73C4FE8A
Content-Type: text/html;
charset="UTF-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
<TITLE></TITLE>
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff size=2>Conor,
from your response you seem to be suggesting that my course of implementation
(be it indexed 0, 1, 2, ... or indexed via a small random number), is
satisfactory. Note that my comments suggest these values CAN be the same for
different SPs (when the authentication occurs based on the same IDP session). I
perceive the above as meaning that subsequent assertions have been issued by the
IDP to each of the SPs based on the user's single authentication/session into
the IDP.</FONT></SPAN></DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff size=2>This
is in direct conflict with the Core specs (977-981) which states that the
session index "... MUST NOT be reused in subsequent assertions given to
different relying parties about the same principal."</FONT></SPAN></DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff size=2>So
either </FONT></SPAN></DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff size=2>(a) my
views below are not satisfactory to comply with the spec.</FONT></SPAN></DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff size=2>(b)
the spec statements needs to be altered.</FONT></SPAN></DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff size=2>(c) my
interpretation of "subsequent assertions" is incorrect and what it means is
assertions that are based on different IDP authentications/sessions (multiple
user sessions). And that any assertions issued for the same IDP
authentication/session are NOT considered subsequent assertions (but the same
assertions).</FONT></SPAN></DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=644212913-31082004><FONT face=Arial color=#0000ff
size=2>Thanks, Tom.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Conor P. Cahill
[mailto:concahill@aol.com]<BR><B>Sent:</B> Tuesday, August 31, 2004 9:23
AM<BR><B>To:</B> Thomas Wisniewski<BR><B>Cc:</B> Mishra, Prateek; Paul Madsen;
'security-services@lists.oasis-open.org'<BR><B>Subject:</B> RE:
[security-services] SessionIndex and Privacy Text<BR><BR></FONT></DIV><FONT
face="Comic Sans MS,sans-serif"><FONT size=2><BR><BR><SPAN type="cite">Thomas
Wisniewski wrote on 8/31/2004, 9:01 AM:</SPAN> </FONT></FONT>
<P><FONT face="Comic Sans MS,sans-serif" size=2></FONT></P>
<BLOCKQUOTE
style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid"
type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=2><FONT
face="Comic Sans MS,sans-serif">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 :-).</FONT></FONT><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid"
type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004></SPAN></FONT> </DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=2><FONT
face="Comic Sans MS,sans-serif">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).</FONT></FONT><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid"
type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT><FONT
face="Comic Sans MS,sans-serif" size=2></FONT><FONT
face="Comic Sans MS,sans-serif" size=2></FONT><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT size=2><FONT
face="Comic Sans MS,sans-serif">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.</FONT></FONT><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid"
type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></FONT></DIV></BLOCKQUOTE><FONT
size=2><FONT face="Comic Sans MS,sans-serif">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.<BR><BR>Conor<BR></FONT></FONT>
<BLOCKQUOTE
style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid"
type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004></SPAN></FONT> </DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2><SPAN
class=593583912-31082004><FONT face=Arial color=#0000ff size=2>Thanks,
Tom.</FONT></SPAN></FONT></DIV><FONT face="Comic Sans MS,sans-serif"
size=2></FONT>
<BLOCKQUOTE><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Conor P. Cahill [<A
class=moz-txt-link-freetext
href="mailto:concahill@aol.com";>mailto:concahill@aol.com</A>]<BR><B>Sent:</B>
Tuesday, August 31, 2004 8:44 AM<BR><B>To:</B> Mishra,
Prateek<BR><B>Cc:</B> Paul Madsen; '<A class=moz-txt-link-abbreviated
href="mailto:security-services@lists.oasis-open.org";>security-services@lists.oasis-open.org</A>'<BR><B>Subject:</B>
RE: [security-services] SessionIndex and Privacy
Text<BR><BR></FONT></DIV><FONT face="Comic Sans MS,sans-serif"
size=2><FONT size=2><BR>I think it would be useful to document the two
common mechanisms used in liberty solutions for this
index:<BR><BR> a) small integer
(which we have in paul's suggested text)<BR>and b) the
assertion ID itself is stored in the session index.<BR><BR>The second
seems to have issues with the "MUST NOT be a unique..." requirement
although it doesn not violate privacy.<BR><BR>So, my recommended
verbage:<BR></FONT></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><EM><I><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>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: </FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><FONT
size=3><O:P></O:P></FONT></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<UL>
<LI><FONT face="Comic Sans MS,sans-serif" size=2><EM><I><FONT
face="Century Gothic" size=2><FONT face="Century Gothic"><FONT
size=2>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).</FONT></FONT></FONT></I></EM></FONT><FONT
face="Comic Sans MS,sans-serif" size=2> </FONT>
<LI><FONT face="Comic Sans MS,sans-serif" size=2><I><FONT
face="Century Gothic" size=2><FONT face="Century Gothic"><FONT
size=2>The authority uses the Assertion ID value in the Session Index
element.
<BR><EM></EM></FONT></FONT></FONT></I></FONT></LI></UL><FONT
face="Comic Sans MS,sans-serif" size=2><EM></EM><O:P></O:P></FONT>
<UL>
<LI><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><EM></EM><O:P></O:P></FONT></P></LI></UL></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><FONT size=2><BR>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.<BR><BR>If we did
use the Assertion ID, we could simply get rid of the session
index.<BR><BR>Thoughts?<BR><BR>Conor<BR><SPAN type="cite">Mishra, Prateek
wrote on 8/30/2004, 4:32 PM:</SPAN> </FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<BLOCKQUOTE
style="PADDING-LEFT: 10px; MARGIN-LEFT: 0pt; BORDER-LEFT: blue thin solid"
type="cite"><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV class=Section1><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face=Arial color=blue size=3><FONT
face=Arial><FONT size=3><FONT color=blue><FONT color=blue>+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).<O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face=Arial color=blue size=3><FONT
face=Arial><FONT size=3><FONT color=blue><FONT
color=blue><O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face=Arial color=blue size=3><FONT
face=Arial><FONT size=3><FONT color=blue><FONT color=blue>-
prateek<O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face=Arial color=blue size=3><FONT
face=Arial><FONT size=3><FONT color=blue><FONT
color=blue><O:P></O:P></FONT></FONT></FONT></FONT></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT
face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt">
<HR tabIndex=-1 align=center width="100%" SIZE=2>
</SPAN></FONT></DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif" size=2><B><FONT
face=Tahoma size=2><FONT face=Tahoma><FONT
size=2>From:</FONT></FONT></FONT></B></FONT><FONT face=Tahoma
size=2><FONT face=Tahoma><FONT size=2> Paul Madsen [<A
class=moz-txt-link-freetext
href="mailto:p.madsen@entrust.com";>mailto:p.madsen@entrust.com</A>]
<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday,
August 25, 2004 3:26 PM<BR><B><SPAN
style="FONT-WEIGHT: bold">To:</SPAN></B> <ST1:PERSONNAME w:st="on">'<A
class=moz-txt-link-abbreviated
href="mailto:security-services@lists.oasis-open.org";>security-services@lists.oasis-open.org</A>'</ST1:PERSONNAME><BR><B><SPAN
style="FONT-WEIGHT: bold">Subject:</SPAN></B> [security-services]
SessionIndex and Privacy Text</FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>Hi, some comments on Lines
977-981 in Core</FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>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
...'</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif"
size=2><O:P></O:P></FONT></P></DIV><FONT face="Comic Sans MS,sans-serif"
size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>2) when combined with the previous
'</FONT></FONT></FONT><FONT face=ArialMT size=2><FONT face=ArialMT><FONT
size=2>SHOULD be a small, positive integer', </FONT></FONT></FONT><FONT
face="Century Gothic" size=2><FONT face="Century Gothic"><FONT
size=2>the 'MUST NOT be reused in subsequent assertions<BR>given to
different relying parties about the same principal' seems
contradictory</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif"
size=2><O:P></O:P></FONT></P></DIV><FONT face="Comic Sans MS,sans-serif"
size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2> 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.</FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>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.</FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2> 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)</FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>My proposed replacement
text</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif"
size=2><O:P></O:P></FONT></P></DIV><FONT face="Comic Sans MS,sans-serif"
size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><EM><I><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>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. </FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><EM><I><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>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).</FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><EM><I><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>if the authority uses some
other scheme for the SessionIndex attribute, it SHOULD choose
values for SessionIndex
randomly.</FONT></FONT></FONT></I></EM><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2><BR></FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif"
size=2> <O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Century Gothic" size=2><FONT
face="Century Gothic"><FONT size=2>Paul </FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><STRONG><B><FONT face=Arial size=2><FONT face=Arial><FONT
size=2>-----------------------------------------------------------------</FONT></FONT></FONT></B></STRONG><O:P></O:P></FONT></P><FONT
face="Comic Sans MS,sans-serif" size=2><FONTT size="2"
face="Comic Sans MS,sans-serif"></FONTT></FONT></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Comic Sans MS,sans-serif"
size=2><STRONG><B><FONT face="Bookman Old Style" size=2><FONT
face="Bookman Old Style"><FONT size=2>Paul
Madsen</FONT></FONT></FONT></B></STRONG><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT
face="Bookman Old Style"><FONT size=2>e:
</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif" size=2><A
href="mailto:p.madsen@entrust.com";><FONT face="Bookman Old Style"
size=2><FONT face="Bookman Old Style"><FONT
size=2>p.madsen@entrust.com</FONT></FONT></FONT></A><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT
face="Bookman Old Style"><FONT size=2>p:
613-270-2632</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif"
size=2><O:P></O:P></FONT></P></DIV><FONT face="Comic Sans MS,sans-serif"
size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT
face="Bookman Old Style"><FONT size=2>c:
613-799-2632</FONT></FONT></FONT><FONT face="Comic Sans MS,sans-serif"
size=2><O:P></O:P></FONT></P></DIV><FONT face="Comic Sans MS,sans-serif"
size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Bookman Old Style" size=2><FONT
face="Bookman Old Style"><FONT size=2>Entrust</FONT></FONT></FONT><FONT
face="Comic Sans MS,sans-serif" size=2><O:P></O:P></FONT></P></DIV><FONT
face="Comic Sans MS,sans-serif" size=2></FONT>
<DIV><FONT face="Comic Sans MS,sans-serif" size=2></FONT>
<P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN
style="FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE><FONT
face="Comic Sans MS,sans-serif" size=2>To unsubscribe from this mailing
list (and be removed from the roster of the OASIS TC), go to <A
class=moz-txt-link-freetext
href="http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php";>http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php</A>.
</FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C48F61.73C4FE8A--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]