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

["Daniel Sanders" <dsanders@xxxxxxxxxx>]

a) I don't know the algorithm - it is Microsoft's.  They do store the public/private key once it is generated from the master key.  The master key is also used to generate the PPID.

b) The master key is used to generate the PPID.  I don't know the algorithm - again it is Microsoft's.

c) PPID+Public Key is what Microsoft contact recommended.  That is apparently what will be sent to the STS for credentials when the authentication method is SelfIssuedCredential.  That is sent in the RST.  I think in our discussion it is important to remember that we are talking about two different messages: 1) the RST that goes to the STS, and 2) the security token than goes to the RP.  The RST contains a PPID+public key.  To my knowledge the security token only contains a PPID, not the public key - thus there would be no opportunity for collusion based on public key.  I thought that a "one-time" symmetric key was generated for encrypting/signing the security token that goes to the RP.

That is my understanding of things - but my understanding may be faulty.

Daniel

>>> Michael McIntosh <mikemci@xxxxxxxxxx> 12/20/2006 4:55 PM >>>
I have to admit that I am a bit confused - I think I understand some of 
this - allow me to repeat what I think I understand from what you said - 
along with some questions. (also please try to be consistent wrt 
differences between cards vs. tokens).

a) For Personal Cards, a master key is used to provide entropy for the 
generation of a public/private key pair.
How (algorithm?) is this done?
Why not just store public/private key pair?

b) One of the claims that an RP can require in a Token from a Subject is a 
PPID. In order to prevent tracking of Subjects by collusion between 
multiple RPs, a different PPID is generated for each RP based on 
information contained within the RP's SSL Certificate (Subject DN) and 
either the master key or the private key or the public key associated with 
the card.
Which key is used?
How (algorithm?) is this done?

c) Since Personal Cards are used to generate Self Signed Tokens, the 
signer/Issuer/Subject are all the same and presumably an adversarial one 
could generate a Self Signed Token containing any PPID (attempting to 
spoof another Subject) and therefore an RP must treat the pair of PPID and 
Public Key (which was used to sign the Token) as the unique identifier for 
the Subject rather than only the PPID.
Since presumably the Public Key is unique and consistent for a Subject 
across RPs couldn't it be used to track a Subject across RPs? (rendering 
the PPID useless)

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 12/20/2006 05:38:21 PM:

> Jim,  I think the lookup should be on PPID + public key.  That is 
> what our MicroSoft contact suggested - seems to make it more 
> difficult to hack.
> 
> Daniel
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 12/20/2006 11:39 AM >>>
> For a simple proof of concept, we were thinking of configuring the 
> STS/CP to do the following when dealing with a card of this nature:
> 
> - STS uses a configured "super-user" identity to open the context.
> - STS uses IContext.search(filter) to locate the DS which matches 
> for PPID=<ppid value of the ClientPseudonym in the RST>.   Remember 
> that this PPID was generated for the unmanaged card as if the STS 
> were the relying party.
> - Using this DS, the STS continues as it previously has.
> 
> This is just one way of doing it, but it seems like a fairly simple 
> first step.
> 
> Jim
> 
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 12/20/06 11:28 AM >>>
> All, Daniel put this together before leaving on Christmas break. 
> It's full of very useful information.   We also have talked about a 
> fairly simple solution in terms of integration with the LDAP CP for 
> an initial proof of concept implementation.  Daniel has also added a
> way at the bottom of https://wag.bandit-project.org/index.php? 
> option=createinfocard&action=createinfocardform to create a managed 
> card using the ppid of a self-issued card for AuthN.
> Jim
> 
> >>> Daniel Sanders 12/15/06 9:39 AM >>>
> All,
> 
> I said I would write up my understanding of PPIDs 
> (privatepersonalidentifier) and how it works with CardSpace.  Here 
> is my attempt at it.
> 
> General Information About PPID
> 
> When a card (either managed or unmanaged) is created in CardSpace, a
> "master key" is associated with the card.  The master key is simply 
> random bits - entropy.  The master key has several purposes: 1) it 
> is used to generate a public/private key pair for the card, and 2) 
> it is used in the generation of a PPID for the card whenever one is 
requested.
> 
> A card's PPID is "site-specific."  It is computed as needed.  It 
> will be different for every relying party the card is selected for. 
> When a relying party requests PPID in its claims, CardSpace uses the
> subject name in the certficate presented by the relying party to 
> construct the PPID.  More precisely, the identifier is computed as a
> function of the organization name ("O") and any optional location 
> ("L", "S", "C", and "DC") attributes present in the subject name of 
> the certificate.
> 
> PPID is intended to represent a pseudonym for a user at a given 
> relying party.  It has the privacy characteristic that the PPID for 
> a user at two different relying parties is guaranteed to be 
> different such that they cannot be used as the basis for collusion.
> 
> For unmanaged cards, the PPID is generated by the STS that is 
> internal to CardSpace.  For managed cards, the external STS the card
> points to must be able to generate the PPID claim with the same 
> privacy characteristic.  Data will be passed to the STS in the RST 
> (Request for Security Token) that will allow the STS to generate an 
> appropriate PPID value.
> 
> To enable an STS that supports the PPID claim to be able to always 
> produce a consistent claim value, Windows CardSpace includes the 
> extension element ic:ClientPseudonym/ic:PPID in the RST request, 
> illustrated below:
>    <wst:RequestSecurityToken>
>       <ic:ClientPseudonym>
>          <ic:PPID>MIIEZzCCA9CgAwIBAgIQEmtJZc0=</ic:PPID>
>       </ic:ClientPseudonym>
>       ...
>    </wst:RequestSecurityToken>
> The <ic:PPID> element contains the result of applying a hash 
> function to a relying party identity and optional user-supplied 
> entropy to produce an opaque, yet consistent, reference for the 
> relying party.  This value must be used as the basis for generating 
> a PPID claim that is sent back to the RP in the security token.  The
> STS may use this value as is or as an input seed to a custom 
> function to derive a value for the PPID claim.
> 
> Using An Unmanaged (Self-Issued) Card As The Authentication Method 
> For a Managed Card
> 
> A managed card may specify one of four authentication methods - or 
> types of user credentials - for authenticating to the IdP.  These 
> are: 1) Username/password, 2) Kerberos v5 Credential, 3) Smartcard 
> based X.509 Certificate Credential, and 4) Self-issued Token 
> Credential.  When a card is selected, the appropriate authentication
> materials are sent to the STS in the RST.  For username/password, 
> the user will be prompted to enter a username and password before 
> sending the RST.
> 
> The reasons we are interested in the Self-issued Token Credential 
> are because it does not require the user to enter any credential 
> information, which would allow us to support single sign-on (SSO). 
> The Kerberos credential and the X.509 Credential may or may not 
> require the user to enter information - we don't know exactly how 
> they work at this point.  Of the three, self-issued token credential
> seems to be the simplest in concept to implement, and perhaps the 
> easiest for a user to work with.  It works as follows:
> 
> 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>
> 
> 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.
> 
> 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.
> 
> Well, I think that is all I am going to write up for now.  I will 
> attempt to do a drawing and send that out later.
> 
> Daniel
> _______________________________________________
> 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