[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] PPID generation
|
Michael McIntosh wrote:
No. There is no master key associated with a managed card. Only personal
cards have master keys, for personal cards the master key is generated
when the car dis created).
This was certainly my understanding as well, but now that I re-read
4.3.4.1 of "A Technical Reference for the Information Card Profile V1.0"
it sounds like ic:HashSalt and ic:MasterKey are required for a managed
card. This wouldn't be the first inconsistency in that doc, though...
According to the CardSpace Tech Ref, this is the algorithm for PPID
calculation (note the absense of master key, which is used for self
signing key pair generation):
What version of the tech ref are you looking at? Mine (v1.0 of December
2006) has this as section 7.5.2, not 7.4.2. In any case, however, this
is the calculation used by CardSpace for self-issued cards, not managed
cards (Section 7 is the "Simple Identity Provider Profile").
my question is this, can a rp be tricked by someone trying to
generate a PPID for someone elses card. Is it all dependent on the
unique cardid ? it seems like this algorithem could easily
replicate a PPID if you know the RP you are going to, and the cardid
naming scheme used by the users card provider. I must be wrong...
If we're talking about self-issued cards, the ic:CardId should be
unpredictable. For managed cards, you'd (obviously) need the IdP's
cooperation.
If you have a CardId and an RP SSL Certificate (or RP Identifier), you
have all that you need to compute the PPID for that Card::RP pair.
So the right questions are:
1) Can a Client trick an IdP into generating a Token containing ANY
arbitrary PPID?
Yes.
As you mention later in your message, Mike, that's really a conditional
"Yes." The correct answer is: Yes if the card's ic:RequireAppliesTo
element is absent or has the Optional attribute set to "true" and the RP
doesn't include wsp:AppliesTo in its sp:RequestSecurityTokenTemplate.
Alleviating the trickery problem by giving the IdP "token scope
information" has significant drawbacks for RPs, not the least of which
is that they are subject to selective impersonation attacks: an insider
at the IdP can pretend to be any of its users. Add to that the fact
that RPs lose their autonomy w.r.t. the IdP (bad for user privacy as
well). Makes you think there must be a better way, huh?
--
Greg Thompson
Credentica
