[security] The potential benefits of HTTPS and SSL

[Dan Lyke]

After a cursory read of the OpenID 2.0-10 spec, I see three potential  
applications for SSL:

1. For the User to communicate with the Relying Party.
2. For the Relying Party to query the Claimed Identifier.
3. For the Relying Party to query the IdP Endpoint URL.

As others have mentioned, communication between the User and the  
Identity Provider is out of scope for the document, and while SSL  
SHOULD be used for user name and password communications between the  
User and the Identity Provider, there is no way for the spec to  
mandate this, and requiring it may block future enhancements which use  
more secure communications systems than SSL.

SSL provides two things:

I. A somewhat secure communications channel between two hosts.
II. The assurance of a Certificate Authority that the server is the  
server that the client wanted to connect to.

So for application #1, the potential exploits involve:

a. A Man-In-The-Middle attack between the User and the Relying Party.
b. Observation of messages between the User and the Relying Party.

I can't figure out anything that a Man-In-The-Middle attack would  
provide the potential cracker that observation of messages would, so I  
think we can reduce this to the user's trust of their communication  
channel. This seems to be between the User and the Relying Party.

For application #2, no secrets are involved, so the only exploit is a  
Man-In-The-Middle attack which would provide a false IdP Endpoint URL  
to the Relying Party. Since the Relying Party will soon pass the IdP  
Endpoint URL to the user as part of the authentication process, any  
exploit here would involve simultaneous DNS poisoning of both the  
Relying Party's DNS chain, and the User's DNS chain, and then  
convincing the user that they're actually using their Identity  
Provider, as in any other phishing exploit.

For application #3, the "nonce" prevents replay attacks, and the  
"association" prevents tampering with the IdP Endpoint URL after the  
Relying Party's first use of an IdP Endpoint URL.

So the two potential exploits are:

A. An attacker poisoning both the Relying Party's DNS *and*,  
simultaneously, the User's DNS. I believe this scenario to be unlikely.

B. An attacker poisoning the Relying Party's DNS, and hijacking the  
*initial* "association" for an IdP Endpoint URL, thereafter being able  
to artificially approve a User who specifies that IdP Endpoint URL.  
This would be much the same as using HTTPS with self-signed  
certificates, or, as we've discussed on the general mailing list, SSH  
without passing the server identity through a separate secure channel.

I believe that 3.B. is the only exploit that could reasonably result  
in damage to the User or the Relying Party, by allowing anyone to log  
in as a specific User, if a specific Identity Provider were targeted.

Where am I wrong?

Dan
(I also believe that if you're able to muck with a network enough to  
build a 3.B. style attack, then OpenID authentication is the least of  
your data center's worries.)