[PROPOSAL] Removing SIGNALL From Draft 10

Granqvist, Hans 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.
> 
> Thoughts?
> 
> --David
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 



More information about the specs mailing list