RE: Two Identifiers - no caching advantage
> * Protocol has two distinct identifiers: public and IdP-local. Relying > party manages delegation. IdP does not even know that the delegation has > taken place and has no way to stop it happening [1]. RP now has to do > more work, but identifier portability now comes for free. I'm much more in favor of that, though see the value in having the IdP know the public identifier so that it can correctly prompt the user. I think one identifier, with the IdP managing the entire relationship is too much of an architectural jump from 1.1. Take LiveJournal for example, somehow I doubt we'd see delegation support in this case anytime soon. I think what is important is keeping the simplicity of delegation in 1.1, while cleaning up the metaphor and making it more user-friendly at the same time. Perfection is the enemy of the good. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Sunday, October 22, 2006 1:34 PM To: specs@openid.net Subject: Re: Two Identifiers - no caching advantage Dick Hardt wrote: > On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: > >> On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> 2) the RP does not verify the binding between the portable >>> identifier and the IdP-specific identifier in the response. >>> to the one the attacker controls and the IdP has mapped >> This is the part where I think you're wrong. The RP MUST verify that >> binding, whether it is by keeping state, self-signing the request >> (which gets passed through to the response) or doing discovery again. > > I agree the RP SHOULD do that. The proposal does not specify that. > I thought we had that conversation. I have not looked at the patch > that you sent. Perhaps you address the issue there. > > My point though is: why have the RP bind the IdP-specific identifier > and the public identifier? Why not let the IdP be responsible for this? > > In 1.x when the IdP was not aware of the public identifier, then the > RP had to do the binding. Now that the IdP is aware of the public > identifier, it would be simpler and logical for the IdP to be > responsible for the binding. It is doing it anyway. > > All the RP wants is which public identifier is the user, and is the > IdP authoritative for it. > If "delegation" is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP "IdP-tastic" can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the "binding" as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP "premium" feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
Dick Hardt wrote: > On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: > >> On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >>> 2) the RP does not verify the binding between the portable >>> identifier and the IdP-specific identifier in the response. >>> to the one the attacker controls and the IdP has mapped >> This is the part where I think you're wrong. The RP MUST verify that >> binding, whether it is by keeping state, self-signing the request >> (which gets passed through to the response) or doing discovery again. > > I agree the RP SHOULD do that. The proposal does not specify that. > I thought we had that conversation. I have not looked at the patch > that you sent. Perhaps you address the issue there. > > My point though is: why have the RP bind the IdP-specific identifier > and the public identifier? Why not let the IdP be responsible for this? > > In 1.x when the IdP was not aware of the public identifier, then the > RP had to do the binding. Now that the IdP is aware of the public > identifier, it would be simpler and logical for the IdP to be > responsible for the binding. It is doing it anyway. > > All the RP wants is which public identifier is the user, and is the > IdP authoritative for it. > If "delegation" is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP "IdP-tastic" can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the "binding" as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP "premium" feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: > On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> 2) the RP does not verify the binding between the portable >> identifier and the IdP-specific identifier in the response. >> to the one the attacker controls and the IdP has mapped > > This is the part where I think you're wrong. The RP MUST verify that > binding, whether it is by keeping state, self-signing the request > (which gets passed through to the response) or doing discovery again. I agree the RP SHOULD do that. The proposal does not specify that. I thought we had that conversation. I have not looked at the patch that you sent. Perhaps you address the issue there. My point though is: why have the RP bind the IdP-specific identifier and the public identifier? Why not let the IdP be responsible for this? In 1.x when the IdP was not aware of the public identifier, then the RP had to do the binding. Now that the IdP is aware of the public identifier, it would be simpler and logical for the IdP to be responsible for the binding. It is doing it anyway. All the RP wants is which public identifier is the user, and is the IdP authoritative for it. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/21/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > 2) the RP does not verify the binding between the portable > identifier and the IdP-specific identifier in the response. > to the one the attacker controls and the IdP has mapped This is the part where I think you're wrong. The RP MUST verify that binding, whether it is by keeping state, self-signing the request (which gets passed through to the response) or doing discovery again. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 19-Oct-06, at 11:12 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> > Your attack fails. >> >> reread the attack. The portable identifier and the IdP do >> match. > > No the identifiers do not. They do. The attacker goes to the RP and enters my blog URL. The attacker changes the request from the RP so that the IdP-specific identifier is what the attacker used in the past. The IdP has an incorrect mapping between the attackers IdP-specific identifier and the public identifier. The response then has the portable identifier (my blog URL) and the attackers IdP-specific identifier. The RP verifies (per the spec) that the portable identifier is bound to the IdP, and the attacker has successfully logged in as me. There are two issues here: 1) the IdP did not verify the binding between the portable identifier and the IdP-specific identifier 2) the RP does not verify the binding between the portable identifier and the IdP-specific identifier in the response. to the one the attacker controls and the IdP has mapped The logic presented previously was that the RP is doing discovery and that it can save the IdP work. Unfortunately, the discovery the RP does of the binding between the portable identifier and the IdP specific identifier is useless to the IdP since the message can be modified. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > If you want that to happen, then you have to spec out that the RP is > verifying the IdP-specific identifier and portable identifier binding > when it receives it. That is not in the current proposal. If that is not in there, then the proposal *is* worse than one-identifier and needs to be fixed. I guess I need to read it more closely. The primary reason that I prefer two-identifier is that the relying party is more strict about what it's accepting. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 19-Oct-06, at 11:18 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> reread the attack. The portable identifier and the IdP do >> match. > > In fact, this makes me think of an attack that *would* succeed if the > IdP-specific identifer was not in the response: > > when she has control, she initiates a log-in, but traps the response > (it's valid, but never gets submitted to the relying party). The trapped response would only be valid for a short period of time since the RP checks that the response is not stale by looking at the nonce, otherwise this attack could be used in many other places. > > After you regain control, she has a valid response for your identifier > and you have no way to invalidate it. If the IdP-specific identifier > was in the response, changing that would invalidate the response. If you want that to happen, then you have to spec out that the RP is verifying the IdP-specific identifier and portable identifier binding when it receives it. That is not in the current proposal. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Josh Hoyt <[EMAIL PROTECTED]> wrote: > when she has control Sorry that I didn't put this all in one message, but: I think it's worthwhile to be aware of what might happen in scenarios where your identifier has been stolen, but it should not have much bearing on which proposal gets accepted, since the attacker will have been able to inflict much greater harm elsewhere. I doubt that the protocol can offer much protection if someone actually gets control of your identifier. For instance, some RPs will offer a way to transition an account from one identifier to another (for e.g. domain names expiring). The attacker can just transition those accounts to an identifier of hers. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > reread the attack. The portable identifier and the IdP do match. In fact, this makes me think of an attack that *would* succeed if the IdP-specific identifer was not in the response: when she has control, she initiates a log-in, but traps the response (it's valid, but never gets submitted to the relying party). After you regain control, she has a valid response for your identifier and you have no way to invalidate it. If the IdP-specific identifier was in the response, changing that would invalidate the response. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 19-Oct-06, at 10:40 AM, Josh Hoyt wrote: > On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> My head is a little moreclear this morning, so let me clarify. >> >> My key point is that the IdP cannot trust the discovery done by the >> RP since what the request is unsigned and may have been modified >> between the RP and the IdP. > > The IdP shouldn't trust the message from RP. It doesn't need to trust > the message from the RP. Trusting the message from the RP would be a > mistake, because the relying party is not the authority for the > information provided. Signing the request has no effect on this issue. > > The IdP does not need to trust the portable identifier given. An RP > will not honor a claim about an identifier whose discovery information > does not match, since it *must* check to make sure it matches *in any > case*. Even if bad information was sent in the request *and the IdP > did not verify it*, the relying party will reject the (bogus) > assertion from the IdP because it does not match the discovered > information for the portable identifier. > > Your attack fails. reread the attack. The portable identifier and the IdP do match. > >> I was showing a potential attack vector where even though I think I >> have resolved the issue, it is not resolved. > > I can't figure out what this means. Who has resolved which issue? > and how? Sorry. I was referring to the attack. I have discovered that someone has hacked my blog (not an uncommon thing for some people) and have fixed it. The IdP has a stale map between the portable identifier and the malicious user's IdP-specific identifier, so even though I have recovered control of my blog, the malicious user can still pretend to be my portable identifier. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > My head is a little moreclear this morning, so let me clarify. > > My key point is that the IdP cannot trust the discovery done by the > RP since what the request is unsigned and may have been modified > between the RP and the IdP. The IdP shouldn't trust the message from RP. It doesn't need to trust the message from the RP. Trusting the message from the RP would be a mistake, because the relying party is not the authority for the information provided. Signing the request has no effect on this issue. The IdP does not need to trust the portable identifier given. An RP will not honor a claim about an identifier whose discovery information does not match, since it *must* check to make sure it matches *in any case*. Even if bad information was sent in the request *and the IdP did not verify it*, the relying party will reject the (bogus) assertion from the IdP because it does not match the discovered information for the portable identifier. Your attack fails. > I was showing a potential attack vector where even though I think I > have resolved the issue, it is not resolved. I can't figure out what this means. Who has resolved which issue? and how? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
Dick Hardt wrote: My key point is that the IdP cannot trust the discovery done by the RP since what the request is unsigned and may have been modified between the RP and the IdP. Yep. Though trusting RPs for _anything_ is a bad idea. Users necessarily need to trust IdP's, the IdP's should protect them from the RPs. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > > Your attack fails. > > reread the attack. The portable identifier and the IdP do match. No the identifiers do not. It did at one time, but not at the time that the attack takes place. While she has control of your blog, she has control of your identifier. If you regain control (change it back), the RP will no longer let her log in, regardless of whether she can get an assertion from the RP. The relying party needs to verify the discovered information when it gets a response. Your attack fails. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
My head is a little moreclear this morning, so let me clarify. My key point is that the IdP cannot trust the discovery done by the RP since what the request is unsigned and may have been modified between the RP and the IdP. I was showing a potential attack vector where even though I think I have resolved the issue, it is not resolved. -- Dick On 19-Oct-06, at 8:27 AM, Drummond Reed wrote: > I don't have time this second to go into more detail, but a quick > high-level > observation about Dick's Cached Discovery Attack: if your blog (or the > target page of any portable OpenID identifier) can be hacked, > you've already > lost your identity. All the hacker has to do is point the link tag > at their > own XRDS file and their off to the races. They can spoof your portable > OpenID identifier anywhere and everywhere you've used it, because > from the > standpoint of an RP, all it looks like is that you've changed IdPs... > > ...which of course is the whole point of portable OpenID > identifiers ;-) > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > Of Dick Hardt > Sent: Thursday, October 19, 2006 12:13 AM > To: specs@openid.net > Subject: Two Identifiers - no caching advantage > > After reading though: > > http://www.lifewiki.net/openid/ConsolidatedDelegationProposal > > I have concluded there is no caching advantage > > Specifically if you look at these two sections: > > > > RP Rules for Identifier Parameters > > Case 3: URL WITH IdP-Specific Identifier > > If Portable Identifier is a URL that DOES map to a IdP-Specific > Identifier, the values are: > > openid.identity = IdP-Specific Identifier > openid.portable = Portable Identifier > > IdP Rules for Identifier Parameters > > 3. If openid.identity = Portable Identifier that IdP does not > recognize, IdP MUST to discovery to obtain the IdP-Specific > Identifier. > > > > I conclude the following: > > *** Given IdP Rule 3, the IdP must bind the IdP-Specific Identifier > and the Portable Identifier, so the RP sending both does may save the > IdP effort, but leaves a potential security issue. (see Cached > Discovery Attack below) > > *** the RP is using the Portable Identifier to identify the user, and > does nothing with the IdP-Specific Identifier, so there is no value > in the IdP sending both the Portable Identifier and the IdP-Specific > Identifier. Note that the RP either maintains state that the IdP is > bound to the Portable Identifier, or needs to do discover again. > > => The only reason for the RP to send the openid.identity to the IdP > is for backward compatibility with OpenID 1.x, similarly the only > reason for the IdP to send openid.identity to the RP is for OpenID > 1.x compatibility. There are no caching advantages. > > > > Cached Discovery Attack: > > A malicious user takes over my blog, opens an account at the same IdP > I use, inserts her IdP-Specific Identifier into my blog, and then > uses my blog URL. The IdP will see the blog URL and the IdP-Specific > Identifier don't match, do discovery on the blog URL, and then map my > blog URL (Portable Identifier) to her IdP-Specific Identifier. > > I discover that my blog URL has been hacked, and restore my IdP- > Specific Identifier. > > The malicious user goes to an RP, that providing her blog URL that > contains her IdP-Specific Identifier. She captures the message from > the RP, and changes the Portable Identifier to be my blog URL. The > IdP still thinks the Portable Identifier is mapped to her IdP- > Specific Identifier, and allows her to login to the RP as me. > > Solutions: > > 1) The IdP does discovery on the blog URL each time it is used. > 2) The IdP has complex logic to ... > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Two Identifiers - no caching advantage
I don't have time this second to go into more detail, but a quick high-level observation about Dick's Cached Discovery Attack: if your blog (or the target page of any portable OpenID identifier) can be hacked, you've already lost your identity. All the hacker has to do is point the link tag at their own XRDS file and their off to the races. They can spoof your portable OpenID identifier anywhere and everywhere you've used it, because from the standpoint of an RP, all it looks like is that you've changed IdPs... ...which of course is the whole point of portable OpenID identifiers ;-) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:13 AM To: specs@openid.net Subject: Two Identifiers - no caching advantage After reading though: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal I have concluded there is no caching advantage Specifically if you look at these two sections: RP Rules for Identifier Parameters Case 3: URL WITH IdP-Specific Identifier If Portable Identifier is a URL that DOES map to a IdP-Specific Identifier, the values are: openid.identity = IdP-Specific Identifier openid.portable = Portable Identifier IdP Rules for Identifier Parameters 3. If openid.identity = Portable Identifier that IdP does not recognize, IdP MUST to discovery to obtain the IdP-Specific Identifier. I conclude the following: *** Given IdP Rule 3, the IdP must bind the IdP-Specific Identifier and the Portable Identifier, so the RP sending both does may save the IdP effort, but leaves a potential security issue. (see Cached Discovery Attack below) *** the RP is using the Portable Identifier to identify the user, and does nothing with the IdP-Specific Identifier, so there is no value in the IdP sending both the Portable Identifier and the IdP-Specific Identifier. Note that the RP either maintains state that the IdP is bound to the Portable Identifier, or needs to do discover again. => The only reason for the RP to send the openid.identity to the IdP is for backward compatibility with OpenID 1.x, similarly the only reason for the IdP to send openid.identity to the RP is for OpenID 1.x compatibility. There are no caching advantages. Cached Discovery Attack: A malicious user takes over my blog, opens an account at the same IdP I use, inserts her IdP-Specific Identifier into my blog, and then uses my blog URL. The IdP will see the blog URL and the IdP-Specific Identifier don't match, do discovery on the blog URL, and then map my blog URL (Portable Identifier) to her IdP-Specific Identifier. I discover that my blog URL has been hacked, and restore my IdP- Specific Identifier. The malicious user goes to an RP, that providing her blog URL that contains her IdP-Specific Identifier. She captures the message from the RP, and changes the Portable Identifier to be my blog URL. The IdP still thinks the Portable Identifier is mapped to her IdP- Specific Identifier, and allows her to login to the RP as me. Solutions: 1) The IdP does discovery on the blog URL each time it is used. 2) The IdP has complex logic to ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
