[
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