Re: [higgins-dev] Using self-issued card as AuthN method for managed car

[Michael McIntosh <mikemci@xxxxxxxxxx>]

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