Re: [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

This leaves a opening for collusion that the user may not be aware

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"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>

To	higgins-dev@xxxxxxxxxxx
cc
Subject	Re: [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins

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>

To	<higgins-dev@xxxxxxxxxxx>
cc
Subject	[higgins-dev] Re: Redirecting Bandit STS efforts to Higgins

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