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 01:55:59 PM:

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

All that I am currently concerned with is the RST that goes to the managed 
card provider STS. The Self Signed Token is provided with this RST in the 
Security header. 
The security token is signed (contains an enveloped signature) with the 
private key, and the associated public key is provided (in the keyinfo of 
the signature) so the signature can be verified.
I am not 100% sure but I'd venture to guess that the RST is also signed 
using the same key.
While in this case the Managed Card Provider STS is essentially an RP wrt 
the Self Signed Token, this is a SOAP scenario and not a browser scenario 
and therefore the Token is not encrypted with the public key from the SSL 
certificate of 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
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev