Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Using self-issued card as AuthN method for managed card

higgins-dev-bounces@xxxxxxxxxxx wrote on 01/05/2007 04:11:32 PM:

> 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:
> 
> http://msdn.microsoft.com/msdnmag/issues/06/10/SecurityBriefs/
> 
> 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?

I still don't understand the value the PPID provides. The Public Key is a 
value that allows the RP to identify a DS (Digital Subject) between 
visits. So what additional value does the PPID provide?

> 
> 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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top