Re: RP attack vector - why two identifiers are redundant
On 14-Oct-06, at 9:17 PM, Josh Hoyt wrote: > On 10/14/06, Dick Hardt <[EMAIL PROTECTED]> wrote: >> Since the request is not signed and flows through the user, the IdP >> does not know the request message has not been modified. If the IdP >> assumes the two identifiers are bound, then a malicious user can >> pretend to be a different user from the same IdP to the RP. This >> presumes the IdP is using an IdP identifier and the RP is using an RP >> identifier and the binding is assumed by sending both. >> >> Therefore, the IdP MUST make sure the two identifiers are linked, so >> sending both is redundant for the IdP. > > The relying party knows both identifiers from doing discovery, and it > must check to make sure they match what is in the assertion. Actually, the RP needs to bind the IdP to the presented_identifier. > Since the > relying party MUST make sure it matches, the IdP doesn't have to. I > would say that the IdP SHOULD check to make sure it's valid, but it's > not strictly required. The IdP needs to bind the user they have authenticated, to the presented_identifier. Per my other email, the display_identifier is just a hint and is not needed. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RP attack vector - why two identifiers are redundant
On 10/14/06, Dick Hardt <[EMAIL PROTECTED]> wrote: > Since the request is not signed and flows through the user, the IdP > does not know the request message has not been modified. If the IdP > assumes the two identifiers are bound, then a malicious user can > pretend to be a different user from the same IdP to the RP. This > presumes the IdP is using an IdP identifier and the RP is using an RP > identifier and the binding is assumed by sending both. > > Therefore, the IdP MUST make sure the two identifiers are linked, so > sending both is redundant for the IdP. The relying party knows both identifiers from doing discovery, and it must check to make sure they match what is in the assertion. Since the relying party MUST make sure it matches, the IdP doesn't have to. I would say that the IdP SHOULD check to make sure it's valid, but it's not strictly required. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: RP attack vector - why two identifiers are redundant
On 14-Oct-06, at 7:36 PM, Recordon, David wrote: > Dick, > While it is true that the IdP should still check that they are bound, > except in the case when it is directly authoritative for both, the RP > should provide the IdP with what the user entered as a hint to what > claim the End User is wishing to make. Just sending the non-portable > identifier, as is done today, means that "smart" IdPs will have to > prompt the user again for what they just typed into the RP. I think the RP should ALWAYS send a normalized version of what the user typed in. There is no need to send what got resolved, as both the IdP and the RP will need to resolve it. (I am almost caught up on list email, and will write up yet-another- identifier-email. :-) > > While the protocol certainly can work without both, I believe it is a > cleaner conceptual model to have the RP pass both to the IdP and then > the IdP verify as needed. If we run into the problem of an End > User not > wanting the IdP to know the portable identifier, then I think that > is a > great thing as it means we've wrapped up Auth 2.0 and a lot of people > are using it in many different ways! :) I thought we already had determined that the IdP will know the portable identifier? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: RP attack vector - why two identifiers are redundant
Dick, While it is true that the IdP should still check that they are bound, except in the case when it is directly authoritative for both, the RP should provide the IdP with what the user entered as a hint to what claim the End User is wishing to make. Just sending the non-portable identifier, as is done today, means that "smart" IdPs will have to prompt the user again for what they just typed into the RP. While the protocol certainly can work without both, I believe it is a cleaner conceptual model to have the RP pass both to the IdP and then the IdP verify as needed. If we run into the problem of an End User not wanting the IdP to know the portable identifier, then I think that is a great thing as it means we've wrapped up Auth 2.0 and a lot of people are using it in many different ways! :) --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Saturday, October 14, 2006 7:12 PM To: Drummond Reed Cc: specs@openid.net Subject: RP attack vector - why two identifiers are redundant On 13-Oct-06, at 7:45 PM, Drummond Reed wrote: >> And despite all the "but it can't be stateless without two!" >> noise, it >> actually can: you put the portable identifier in the return_to URL >> and >> verify it again when you get the signature back from the IdP. >> That is, >> verify the mapping from portable -> IdP-specific still holds. >> Because you >> can't just trust the 1 (or 2) values you get back from the IdP, >> otherwise the IdP (which could be malicious) could be fucking with >> you, asserting a portable identifier which it's not actually >> permitted to do, according to the portable identifer's >> YADIS//etc. > > Good point. I've never figured an attack vector for the RP to send the > wrong identifiers to the IdP, since the RP is just "fooling itself". > But I agree there can be one for a malicious IdP to return the wrong > ones to an RP. The attack vector is not that the RP sends the wrong identifiers, it is that a malicious user in between modifies the request that is sent to the IdP. Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same IdP to the RP. This presumes the IdP is using an IdP identifier and the RP is using an RP identifier and the binding is assumed by sending both. Therefore, the IdP MUST make sure the two identifiers are linked, so sending both is redundant for the IdP. As noted in other messages, the RP cannot trust the IdP binding, and needs to verify the binding themselves, so the sending the two parameters is redundant in the response as well. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RP attack vector - why two identifiers are redundant
On 13-Oct-06, at 7:45 PM, Drummond Reed wrote: >> And despite all the "but it can't be stateless without two!" >> noise, it >> actually can: you put the portable identifier in the return_to >> URL and >> verify it again when you get the signature back from the IdP. >> That is, >> verify the mapping from portable -> IdP-specific still holds. >> Because you >> can't just trust the 1 (or 2) values you get back from the IdP, >> otherwise >> the IdP (which could be malicious) could be fucking with you, >> asserting a >> portable identifier which it's not actually permitted to do, >> according to >> the portable identifer's YADIS//etc. > > Good point. I've never figured an attack vector for the RP to send > the wrong > identifiers to the IdP, since the RP is just "fooling itself". But > I agree > there can be one for a malicious IdP to return the wrong ones to an > RP. The attack vector is not that the RP sends the wrong identifiers, it is that a malicious user in between modifies the request that is sent to the IdP. Since the request is not signed and flows through the user, the IdP does not know the request message has not been modified. If the IdP assumes the two identifiers are bound, then a malicious user can pretend to be a different user from the same IdP to the RP. This presumes the IdP is using an IdP identifier and the RP is using an RP identifier and the binding is assumed by sending both. Therefore, the IdP MUST make sure the two identifiers are linked, so sending both is redundant for the IdP. As noted in other messages, the RP cannot trust the IdP binding, and needs to verify the binding themselves, so the sending the two parameters is redundant in the response as well. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
