| Re: [higgins-dev] Using self-issued card as AuthN method for managed card |
|
Mike,
I found some further information about the PPID and public key that are associated with information cards in CardSpace. It turns out that just as the PPID is different for every relying party the card is used with, so is the public key. This link:
contains the following explanation:
"If there were only one public key used for all interactions [with a particular information card], it would be impossible to maintain anonymity across relying parties. If those parties had no scruples, they could use your public key as an identifier and easily correlate all the claims you gave each of them to create a shared dossier of information about you. This is clearly a scenario that should be avoided!"
This is basically the same thing you were saying - what does it matter if PPID is different for every RP if the public key is the same. He continues his explanation:
"[The PPID is] essentially a hash of various bits of information that comes from the relationship between a particular information card and a particular relying party. You can use the same information card with 10 different relying parties and each relying party will see a different PPID .... Well, the self-issuing security token service generates RSA key pairs in a similar way. Each of those 10 relying parties will see a different public key, even if you use the same information card. This helps keep the user in control of her identity."
Does this satisfy the concerns you raised below about public key?
Daniel
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 12/21/2006 2:08 PM >>> higgins-dev-bounces@xxxxxxxxxxx wrote on 12/21/2006 02:23:23 PM: > My comments bracketed by <dss></dss> > > > >>> Michael McIntosh <mikemci@xxxxxxxxxx> 12/21/2006 7:59 AM >>> > More comments/questions ... > > higgins-dev-bounces@xxxxxxxxxxx wrote on 12/20/2006 05:38:21 PM: > > <snip/> > > > 1) The <UserCredential> element in the managed card contains a > > <SelfIssuedCredential> child element, which in turn has a > > <PrivatePersonalIdentifier> child element that holds a PPID. The > > PPID references an unmanaged card. Recall that PPID is "site- > > specific." In this case, the "site" (or relying party) is the STS > > pointed to by the managed card. Thus, the PPID should be the one > > that is generated for the unmanaged card as if the STS were the > > relying party. That makes perfect sense, because the STS is, in > > fact, the relying party that will receive authentication material - > > the PPID of the unmanaged card. It is as if the STS requested a > > PPID claim and the user selected the unmanaged card to satisfy that > claim. > > The XML in the managed card looks like this: > > <ic:UserCredential> > > <ic:SelfIssuedCredential> > > <ic:PrivatePersonalIdentifier>base 64 PPID</ic: > > PrivatePersonalIdentifier> > > </ic:SelfIssuedCredential> > > </ic:UserCredential> > > There seems to be a contradiction in this: > a) A PPID value is generated based on information specific to the RP. > b) The specific RP is not known when a Card is generated. > c) A card contains a PPID value when it is generated. > Please tell me what I am missing? > > <dss> > No contradiction. A card does NOT contain a PPID when it is > generated. The PPID referred to above is the PPID of the card > generated with respect to a particular STS - the STS being the RP. > In this case, the specific RP (the STS) is known when the managed > card is generated, so it makes perfect sense to put that PPID into > the managed card definition - I think of it as sort of a "reference" > or "pointer" to a personal card + a very specific RP (the STS). > </dss> OK, I missed the important fact that this construct (ic:SelfIssuedCredential) was only in the ManagedCard. So this is used to link the Managed Card to the one and only Personal Card that can be used with it. > > 2) When the managed card is selected by a user, the unmanaged card's > > PPID and public key is sent to the STS in the RST as the > > authentication material. > > I guess I find it awkward to think of the PPID as belonging to the Card - > I think a PPID is a claim in the Token that might be generated by > selecting a Card for access to a specific RP. In our case the Managed > Provider STS is the RP. > > <dss> > A PPID is, in fact, associated with one and only one card, and one > and only one RP. Given that, it seems perfectly logical to say it > "belongs" to a card. It cannot be associated with any other card or > any other RP - so it uniquely identifies, associates with, belongs > to - whatever term you choose to use - a single card. > </dss> The problem I have with that is a Card has a 1:M relationship to RPs, and therefore a 1:M relationship to PPIDs. I think it is more accurate to say that the PPID identifies a 1:1 relationship between a Card and an RP. A Card does not contain its PPID nor is its PPID stored. The exception (from above) is where a Managed Card "M" is issued by an STS "A" and associated with Personal Card "P". In that case M contains the PPID that identifies the relationship between P and A. > I guess in response to one of the questions I sent in previous email - how > come the public key can't be used to track a Subject across RPs? > Perhaps a separate public key pair is generated for each RP using the > Master Key and RP information as entropy? This would allow a Sbject to > consistently generate the same key pair each time it generated a token for > an RP, while allowing different key pairs for each RP. Although the > underlying question for me remains: since an RP can identify a Subject > across visits by its Public Key, what value does the PPID provide? > It almost seems as though the PPID serve the purpose of being the one > claim (a psuedonym at that) in an otherwise claimless token where the real > identifier is the Public Key used to sign the Token. > > <dss> > Good questions. In a previous email I stated that I wasn't sure the > public key was sent to the RP in the security token - only to the > STS in the RST. In thinking about that, however, I think it has to > be sent, because at some point the STS has to act as a real RP and > get a security token for the personal card that is the managed > card's SelfIssuedCredential. This is because it needs to store the > personal card's PPID+public key somewhere so it can be looked up > later when it receives an RST on the managed card that is using the > personal card. Hmmm..... > </dss> For any SAML Assertion/Token, there MUST be an Issuer Signature. For any Signature, the Public Key (either as certificate or modulus/exponent) MUST be included for verification. For any "bearer" Assertion, there MAY be a Subject Public Key in the Assertion. For any "holder-of-key" Assertion, there MUST be a Subject Public Key in the Assertion. For any Self Signed SAML Assertion, the Issuer and Subject are the same - therefore the Issuer/Subject Public Key MUST be in the Assertion/Token. > > 3) The STS uses the PPID+public key to "lookup" the user account and > > request the attributes needed to create a security token that will > > be sent back to the relying party. -- This is the part that we need > > to figure out how to do in our LDAP CP. > > If my previous hypotheses about how this works are correct (RP can't > create a PPID from RP DN and Subject Public Key), the only way I can see > this working would be as follows: > a) Subject generates Personal Card > b) Subject visits Managed Card Provider STS Registration Page which > requires a Self Signed Token for sign on. > c) Managed Card Provider STS Registration Page generates a Managed Card > which it associates with the Self Signed Token used for sign on (by PPID, > Public Key, or both: my feeling is the PPID is not secure enough, Public > Key is secure enough, and both is no more secure than Public Key). > > <dss> > Good observations. We need to have another discussion with Micrsoft. > </dss> > _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |