[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins
|
higgins-dev-bounces@xxxxxxxxxxx wrote on 02/23/2007 07:44:45 PM:
> This leaves a opening for collusion that the user may not be aware
I am not sure the problem is collusion between IP/STS(s) but correlation
within a single IP/STS.
If a "subject" creates a personal card and uses it to authenticate to an
RP, every time the RP is accessed the RP is able to know it was the same
"subject".
When a managed card is created a credential is associated with it that is
sent to the IP/STS for authentication (wrt that credential the IP/STS can
be considered to be an RP).
Conceptually, nothing prevents a "subject" from creating multiple managed
cards, each associated with the same personal card. As long as each
managed card is serviced by a different IP/STS, there is no danger that
the IP/STS(s) can collude since a unique key pair/PPID is used for each RP
(which in this case is the IP/STS).
However, when more than one managed card is serviced by the same IP/STS,
the only way to prevent THAT IP/STS from detecting that "Mike's Card" and
"Michael's Card" are owned by the same "subject" is for me to use
different personal cards as the authentication credential (though I
suspect looking at my client IP address might do the trick).
I select the personal card to use as the credential when I ask the IP/STS
to generate each of my managed cards.
Therefore, I control and consent to whether or not I select the same
personal card or use different personal cards.
>From talking to Tony, I think he believes the unsophisticated user may not
realize that by selecting the same card they are enabling correlation
between managed cards owned by the same entity by the IP/STS.
I guess implementation realities are forcing us to look at the differences
and relationships between instances of IContext and instances of
IDigitalSubject.
Does an IContext CONTAIN many IDigitalSubject(s)? Based on how one uses
the current JNDI/LDAP CP implementation the answer to this questions is
seemingly yes.
Does a "card" represent an IContext or an IDigitalSubject? Again based on
usage, I suspect the answer is that it presents a specific IDigitalSubject
(in a specific IContext).
Should a "subject" be associatable with multiple IDigitalSubjects in the
same IContext?
Should a "subject" with access to a IDigitalSubject have same access to
all IDigitalSubjects in the containing IContext?
Depending on the answers to those questions we may have to change the way
we are doing things...
Thanks,
Mike
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> [image removed] "Daniel Sanders" <dsanders@xxxxxxxxxx>
>
>
> "Daniel Sanders" <dsanders@xxxxxxxxxx>
> Sent by: higgins-dev-bounces@xxxxxxxxxxx
> 02/23/2007 01:22 PM
>
> Please respond to
> "Higgins \(Trust Framework\) Project developer discussions"
> <higgins-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
> [image removed]
> higgins-dev@xxxxxxxxxxx
>
> [image removed]
> cc
>
> [image removed]
>
> [image removed]
> Subject
>
> [image removed]
> Re: [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins
>
> [image removed]
>
> [image removed]
>
>
> Tony,
>
> Could you be more specific about what you think the security issue
> is? -- Are you assuming that relying parties could somehow use
> managedCardId to collude? If so, that should not be a concern,
> because the managedCardId will not be sent to a relying party in a
> security token. Only the STS receives the managedCardId (it's
> actually part of the RST today). We are not talking about it as a
> claim for the RP, but only as part of the auth material for the STS.
>
> Daniel
>
> >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 2/23/2007 11:59 AM >>>
> Well the reason for this to make sure there is no spoofing, so I
> agree with the limitation that was put on this and opening this up
> is a security issue, so I'm aginst this
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> "Jim Sermersheim" <jimse@xxxxxxxxxx>
>
> "Jim Sermersheim" <jimse@xxxxxxxxxx>
> Sent by: higgins-dev-bounces@xxxxxxxxxxx
> 02/23/2007 11:50 AM
>
> Please respond to
> "Higgins \(Trust Framework\) Project developer discussions"
> <higgins-dev@xxxxxxxxxxx>
>
> [image removed]
> To
>
>
> <higgins-dev@xxxxxxxxxxx>
>
> [image removed]
> cc
>
> [image removed]
>
> [image removed]
> Subject
>
>
> [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins
>
> [image removed]
>
> [image removed]
>
>
> So, as far as I understand the use case, I'm for adding the
> managedCardID. The argument's I've heard against this say that if I
> want to have multiple managed cards backed by the same personal
> card, then those managed cards must represent the same identity in
> the backing store. And if there's a need to use a different identity
> in the backing store, then a different personal card should be used.
> While I agree that in practice this is likely the pattern that one
> should follow, but I don't like restricting the former possibility.
>
> Jim
>
> >>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 2/23/07 9:20 AM >>>
> Mike,
>
> I should have also replied about the following:
>
> I also am waiting for the change to the IdAS described here:
> http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01601.html
>
> This is the request that we allow
> managedCardID+PersonalCardPPID+modulus+exponent to be the auth
> material for a self-issued token. I had some reservations, which I
> expressed in followup e-mails. My 2nd-to-last email asked whether
> you meant managedCardID or managedCardPPID, and I pointed out
> problems with managedCardPPID. ... I guess I just wanted
> clarification that you really meant managedCardID, not
> managedCardPPID. ... I was under the impression that we still needed
> to have everyone accept the proposed idea. I'm not sure where Jim
> and Tom are on the idea -- I will discuss it with them today to see
> what they think. As I recall, they didn't chime in on the thread.
>
> Daniel
>
>
> >>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 2/23/2007 8:38 AM >>>
> Thanks Mike. -- I did have a followup question on #2 (PPID claim
> handling). This should be independent of SAML provider, so I'm not
> sure what you mean here. All providers should do it this way, should
> they not? Am I misunderstanding what you mean by SAML provider?
> Could you clarify this?
>
> I am also putting this particular e-mail out on the dev list - minus
> the other discussion about contributing to the STS.
>
> Thanks,
>
> Daniel
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/23/2007 8:22 AM >>>
> "Daniel Sanders" <dsanders@novellcom> wrote on 02/22/2007 03:45:49 PM:
>
> > The term "fully implemented" implies a lot more than you are
> > allowing for. It includes major and minor bug fixes, reliability
> > fixes, scalability fixes, etc., etc. It's stuff that benefits ALL
> > users of the STS. There is a lot of stuff in the STS that people
> > are VERY interested in, that ought to be in the STS, that is not
> > going to be specified in a high-level WS-Trust document. We need to
> > collaborate about these things, including submitting patches and/or
> > committing changes, bug fixes, etc. directly. We would like to be
> > able to help with these things. We would like a task list or to-do
> > list that everyone can help out with - as is common with most other
> > open source projects.
> >
> > Examples of things that have recently been requested are as follows:
> >
> > 1) Some restructuring of the code modules. See my e-mail, and
> > Mike's response - both out on the higgins-dev list if you are watching
> it:
> > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01607.html
>
> Allow 1 STS Core to be used by N STS Bindings - this is checked in today
> (you can now pass a configured STS instance into the binding configure
> method and get the configured STS instance from a binding).
>
> > 2) A change in how PPID claims are handled. See http://wiki.
> > eclipse.org/index.php/Milestone_0.7 under the heading "IIW Reference
> > Application Post Mortem"
>
> PPID handling - this has been how the SAML provider works since the F2F.
>
> > 1. The STS needs to give special handling to the
> > privatepersonalidentifier claim. The document, A Guide to
> > Integrating with Information Cards and Windows CardSpace v1.0, says
> > the following: "To enable an identity provider that supports the
> > PPID claim type to be able to always produce a consistent claim
> > value, Windows CardSpace includes the extension element ic:
> > ClientPseudonym/ic:PPID in the RST request. It contains the result
> > of applying a hash function to a relying party identity and optional
> > user-supplied entropy to produce an opaque yet consistent reference
> > for the relying party. If the issued token contains the PPID claim,
> > this value is to be used as the basis. The IP/STS may use this value
> > as is or as an input seed to a custom function to derive a value for
> > the PPID claim." The STS should look for this ClientPseudonym/PPID
> > element whenever the RST requests the personalprivateidentifier
> > claim, and at the very least, return that value for the claim.
> > 3) A change in how the STS determines what claims to ask for from
IdAS.
> See:
> > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01541.html.
>
> Ask for specific claims when calling getDigitalSubject - this is checked
> in today (I still feel that this is an LDAPism and would like to discuss
> whether getDigitalSubject is expected to provide dynamic read-write
access
> via an to the DigitalSubject or whether its expected to provide a static
> cached copy of the Digital Subject.
> >
> > Mike may have already worked on some of these, perhaps all of them.
> > I haven't checked for the past few days. I am just showing you that
> > there are things that need tweeking, adjusting, refactoring, etc. -
> > that have little or nothing to do with the high-level WS-Trust
> > architecture. These kinds of requests come up somewhat regularly,
> > and we anticipate that more will happen.
>
> I also am waiting for the change to the IdAS described here:
> http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01601.html
>
> > Daniel Sanders
>
> <snip rest of
discussion...>_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> [image removed] _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
