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 in <dss></dss>.

>>> Michael McIntosh <mikemci@xxxxxxxxxx> 1/8/2007 1:13 PM >>>
higgins-dev-bounces@xxxxxxxxxxx wrote on 01/08/2007 02:46:06 PM:

> I agree with you that it is probably a good idea for a Named STS
> that returns SAML tokens to do exactly as you said - generate a
> unique subject public key for every RP+subject combination.  It
> seems that the SAML specifications may have left a security hole if
> they did not address this issue.  I don't know if we are free to
> make our own interpretation here or not.  Would we be straying from
> the intended/expected usages here? -- In any case, I think that

The SAML specification is silent on the issue.

> should be treated as an issue independent of PPID.  I think there
> are still at least two good reasons for having a PPID claim that is
> independent of subject public key.
>
> First, not all security tokens are going to be SAML tokens - we
> cannot expect that a subject public key be present in all types of
> security tokens.  Defining the concept of a PPID claim is very
> useful - it gives an RP a simple standard way to request a client
> pseudonym, regardless of token type, that has the desired properties
> of uniqueness per RP and anonymity for the user.

The only known Tokens (SAML, Kerberos, X.509, Username) that support PPID
are SAML Tokens.
 
<dss>
It sounds to me like you are talking about the format that CardSpace currently uses to send credentials inside of the RST to a named STS.  I have not looked at the RST format in detail - I am assuming from what you said that those four types of credentials are embedded/carried in a SAML token that is embedded in the RST.  But that is a very specific use case - CardSpace sending an RST to an STS.  It implies nothing about the token format that can be used between an STS and an RP.  It is very clear that token formats are not intended to be limited to SAML.  CardSpace is deliberately neutral on that point - any format that the RP and STS agree on is acceptable - including proprietary formats.  Whatever format is used, I presume that a PPID claim would be supported in the same way as other claims are in that format.
 
Kerberos and X.509 are their own formats independent of SAML - I fully expect Microsoft to have an STS that issues tokens in the Kerberos format without embedding them in SAML.
</dss>

> Second, even when the token type is SAML, there is no guarantee that
> a subject public key will be present.  In fact, if the it turns out
> that the semantics for subject public key are not what we think they
> should be (i.e., that it should be unique per RP+Subject), an STS
> may choose to deliberately leave it out of the security token it
> returns in order to prevent RP collusion.  Even if the semantics are
> what we want, for many RPs there is not an easy way to specify that
> it must have a SAML token that includes a subject public key.  If
> you are an RP that just wants to use the simple <OBJECT> mechanism
> to specify your security policy, you can specify that you must have
> a SAML token, but you cannot specify that it must include subject public
key.

Yes, you are correct. A SAML Token can have a confirmation method of
bearer instead of holder-of-key.
But in that case you would obviously not be able to identify the owner
based on the PPID/Public Key combo, in which case you might just as well
use the Subject NameIdentifier.
 
<dss>
Whatever PPID can identifiy, PPID <concat> SomeConstant can also identify.  PPID+PublicKey is enough to identify a user, even if it is the same public key all the time.  It is not better than PPID by itself, but it is certainly no worse.  If the card happens to be a personal card, PPID+Public Key is actually better, because the combination is more unique than PPID by itself.
 
We are talking about two uses cases here, and we keep mixing them it seems to me.
 
Use Case 1: An RP needs the functionality of a PPID whether the card is managed or personal.  Public key does not provide the needed functionality - it is not guaranteed to be unique per RP - hence, the invention of PPID.
 
Use Case 2: A managed card uses a personal card as its UserCredential.  In this case, the combination of PPID+Public Key is a stronger credential (harder to hack) than just PPID alone.  Nobody is saying that they "must" be used together, it's just that you can - because you are guaranteed to always have them since they come from a personal card.  Combining them in this particular case seems to me to be a very good suggestion.  This use case, which is only applicable to personal cards used as the UserCredential for managed cards, does not in any way negate the value of Use Case 1.
 
Given these use cases, it makes perfect sense to me that PPID and public key need to be separate and distinct concepts.  Sometimes they are useful together, sometimes they are not.
</dss>

> BTW: Theoretically, the RP can tell who the issuer of the token was,
> and therefore whether it was self-issued - there is a special URL
> for self-issued tokens.  I suppose that some STS could issue a token
> where it poses as the "self-issued" URL, but in my mind that is a
> different problem - why would we be trusting an STS that does that?

There is a difference between the EPR used to locate the STS, and the URI
used to Identify the Issuer.
Why would an RP ever trust a self signed token? The RP won't know the
difference between one issued by a Local STS or a Named STS.
Hopefully trust is based on verification of the signature and validation
of the issuer's key, if anything the issuer uri should be used only to
look up the correct key.
 
<dss>
I agree completely that when an RP receives a token, it should verify the signature and validate the key.  However, that is not necessarily sufficient basis for trusting the issuer.  It is certainly a prerequisite, but even after I have verified the signature and validated the key, I may still choose to not accept tokens from certain issuers - based on the URI that I see, or any other criteria I choose to examine.  It may not be a matter of "trust" - as in "trusting that I am not being deceived" - it may simply be a matter of "I no longer do business that way - I deal exclusively with certain issuers."  That is not a statement that you believe the issuer is dishonest.
 
If an STS is not sending honest information in its URI, yes, the RP can be deceived into thinking that the token came from someone it didn't come from - including the local STS or anyone else.  Nothing we can do about that.  I'm not talking about trust as an issue of "honesty" - there are other dimensions of trust that have nothing to do with honesty.
</dss>

>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 1/8/2007 9:41 AM >>>
> Michael McIntosh
> Java and Web Services Security Group
> Security, Privacy, and Extensible Technologies Department
> IBM Research
>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 01/08/2007 09:50:53 AM:
>
> > The concept of a PPID is still needed if you are using a managed
> > card.  The public key is associated with the token issuer (the STS),
> > not so much the card.  For personal cards, the STS is the internal
> > CardSpace STS, and it uses a different public key for each RP the
> > card is used with.  For managed cards, the public key comes from
> > whatever STS the card is associated with - and it will likely be the
> > same for every RP and every user.  This means that the public key
> > cannot be used to identify a particular user - so there is no way to
> > use it for collusion between RPs. -- Because the public key cannot
> > be relied on as a means to anonymously identify a user for all
> > cards, the notion of PPID was invented -- as a means for allowing
> > the user to remain anonymous - a client pseudonym.  Although it's
> > use is superfluous for personal cards (because public key happens to
> > be unique per user/RP), it is still needed for managed cards.  For
> > the sake of clarity and consistency, it is provided for both managed
> > and personal cards.  An RP can elect to ignore the PPID and simply
> > use the public key to identify the user if it knows that the token
> > was self-issued (personal card, CardSpace STS), but a wiser course
> > would be to use PPID and public key together - enhancing the
> > security of the client pseudonym when the card happens to be a
personal
> card.
>
>
> Each SAML Token, at least conceptually, is associated with two public
> keys:
> a) the Issuer Key which is used to verify the signature over the SAML
> Token, and
> b) the Subject Key which is later used to verify signatures created by
the
> Subject Private Key,
> thereby proving the signer and Token Subject are the same.
>
> For a Self Signed Token both keys are the same, for a Provider Signed
> Token they are different.
> In either case the Subject Public Key identifies the User.
>
> A Personal Card is always used to ask for a Token issued by the Local
STS
> (only MSFT knows how the Local STS is found and the protocol used).
> A Managed Card is always used to ask for a Token issued by a Named STS
at
> a one of a set of endpoints listed in the card.
> (For clarity I'll refer to these as Personal STS and Local STS)
> When generating a SAML Token, an STS decides which keys to use for
Issuer
> and Subject.
> The local Microsoft STS always uses the same key for Issuer and Subject.
> Other STSs may also use the same key for Issuer and Subject, or they may

> use different keys.
>
> For a Named STS, the Issuer Public Key would likely be the same for
every
> issued SAML Token targeted to a specific RP, since it would be expected
> that any RP would want to establish trust in that STS thru its Issuer
> Public Key (either by prior knowledge or some heirarchical trust). An
STS
> could establish a separate Issuer Public Key for each RP or use the same

> Issuer Public Key for all RPs.
>
> However, in order to prevent tracking of users between RPs, any STS
would
> need to use a separate Subject Public Key for each Subject/RP pair. So,
> for all of the same reasons the Local STS generates a separate Subject
> Public Key for each RP, a Named STS would also need to do the same.
>
> Finally, an RP cannot tell whether a Self Signed Token was issued by a
> Local STS or a Named STS, and therefore cannot react differently.
>
>
> >
> > >>> Michael McIntosh <mikemci@xxxxxxxxxx> 1/7/2007 9:20 AM >>>
> > 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
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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

Back to the top