security

[Martin Atkins]

Chris Drake wrote:
> 
> Leave out SSL between the RP and IdP, and users can't get security,
> not even if they do put SSL on their vanity domain.
> 
> Am I the only one who thinks this is a ridiculous discussion?  All
> IdPs will have SSL to start with, and it's a no-brainer to set up for
> RP's, and there's a gazillion benefits - so there really is NO excuse
> trying to argue against SSL, both from a technical *and* a marketing
> **and** an ethics point of view.
> 

I don't think anyone's arguing anymore that IdPs should use SSL, which 
then secures all communication between the RP and the IdP, since the IdP 
is always a server and never a client.

However, I'm still missing these gazillion benefits of SSL servers for 
RPs. As I've repeated several times in messages in this discussion, the 
only two items in the auth protocol that are passed with the RP acting 
as a HTTP server are:
     * The claimed_identifier, which is public knowledge anyway.
     * The IdP's confirmation signature, which is already 
cryptographically protected by other means, is RP-specific and is 
non-replayable.

So the only attack facilitated by a non-SSL server on the RP is a 
man-in-the-middle between the browser and the RP when passing the 
signature, allowing the attacker to intercept the sig and authenticate 
in the stead of the intended user. This attack must be performed in real 
time as the legitimate user logs into the relying party. This is far 
less severe than the attacks that result from an insecure identity URL, 
which can be performed at any time without any interaction from the 
legitimate user.

The upshot of this is that a user can choose to use an un-secured RP, 
which may put them at risk of being impersonated ON THAT SITE, but only 
if they themselves use that site. This is completely avoidable by simply 
NOT using the RP in question.

I put it to you then that it is actually *more* critical for an identity 
URL to be secured than an RP, that the repercussions of the above attack 
are in many cases not worth the effort to prevent it, and that in any 
case users can decide for themselves whether they want to take this risk 
on an RP-by-RP basis.