[
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
|
The PPID does not have to unique (no requirements set forward) and the PPID is specific to a RP, so this actually can case issues of duplicate PPIDs
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
![Inactive hide details for "Daniel Sanders" <dsanders@xxxxxxxxxx>]()
"Daniel Sanders" <dsanders@xxxxxxxxxx>
"Daniel Sanders" <dsanders@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
01/08/2007 01:46 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
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 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.
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.
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?
>>> 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
