[PROPOSAL] Removing SIGNALL From Draft 10
hgranqvist at verisign.com
Fri Sep 29 18:47:51 UTC 2006
+1 on removing SIGNALL
There are significant security risks with "signing unseen data",
which SIGNALL in effect allows. Such chosen plaintext attacks can
be devastating to protocols.
> -----Original Message-----
> From: specs-bounces at openid.net
> [mailto:specs-bounces at openid.net] On Behalf Of Recordon, David
> Sent: Friday, September 29, 2006 11:39 AM
> To: specs at openid.net
> Subject: [PROPOSAL] Removing SIGNALL From Draft 10
> While I know this was added in draft 9, I'd like to readdress
> it as I'm concerned from a technical perspective. My
> understanding of the motivation was to allow a Relying Party
> pass arbitrary key/value pairs to an IdP and have them passed
> back in the signature. I believe that this, minus the
> parameters in the response being signed, can be achieved via
> the "return_to" parameter. This is a URL generated by the
> Relying Party for where the Identity Provider should redirect
> the End User upon authentication. It thus can be used by the
> Relying Party to maintain state between requests.
> My concerns:
> 1. There is no manifest for the fields that get signed, which
> makes it more vulnerable to certain kinds of attacks, if
> weaknesses are found in the MAC generation algorithm. This
> could be corrected by using a signed list that used full keys
> instead of leaving off the "openid.", but see (2).
> 2. The entire query becomes part of the OpenID message,
> rather than just the prefixed fields. As I remember it, the
> original motivation for using prefixed parameters was to
> avoid collision with existing parameters of any applications.
> Signing these parameters mixes them in with the
> authentication request or response. One of the nice things
> about OpenID 1.x is that it's really clear which parts of the
> HTTP messages are OpenID-specific; I'd like to preserve that.
> specs mailing list
> specs at openid.net
More information about the specs