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 
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>

> 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>

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>

> 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>

<snip/>
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top