security

[Martin Atkins]

Recordon, David wrote:
> Alaric,
> I think both you and Dick are right.  Don't get me wrong, security is
> very important to see anything like OpenID be adopted.  I think the
> point Dick is trying to make is that security needs to scale depending
> on context, or at least that is the point I'd try to make.
> 
> Starting with 2.0, or 1.2 whatever we end up calling it, I personally
> would not use an Identity Provider which does not both host my
> identifier and it's server endpoint via a valid SSL certificate.  There
> are however use cases where SSL is not required, running OpenID solely
> on an intranet for example, but for the majority of cases SSL is highly
> recommended which I think the spec makes clear.  If it doesn't, please
> let us know!
> 
> So I don't think security is binary, IMHO what is important is that the
> spec makes it clear where the weaknesses are, how to protect them, and
> recommends the use of things like valid SSL certificates for the entire
> protocol flow.
> 

In order to aid the discussion I've made a diagram of the flow of 
information between parties during a "smart mode" authentication request:

http://i13.tinypic.com/2w3ch7b.png   [1]

("Dumb mode" is not much different; the RP -> IdP interaction just moves 
about a bit.)

This shows the various information passed between the four involved 
parties. I have omitted messages that are merely requests for 
information for the sake of brevity. The arrows show whether this 
information is flowing from client to server or server to client.

The bright red arrows show information that would be 
spoofable/interceptable if the RP doesn't have an SSL. The dark red 
arrow shows information that would be spoofable/interceptable if the 
Identifier URL (and, by implication, the host of the Yadis document) 
isn't a HTTPS URL. I assume that the IdP has an SSL server and all 
requests to it are therefore encrypted and certified.

----------------------------------

I think the most notable thing to take away from this diagram is that 
there is really no pressing need for your average RP to run an SSL 
server. The only two OpenID-related items passed over this channel are:
   * The user's claimed_identity, which is public information anyway.
   * The signature from the IdP, which is protected from spoofing using 
a shared secret previously negotiated over an SSL link, is RP-specific, 
and is valid only once.

Of course, the RP MUST be an SSL-able *client*, in order that it can 
talk to the IdPs and Identifier URLs on SSL servers.

My current views on SSL requirements in the spec, then:

Party                Client     Server
------------------------------------------
RP                   MUST     unspecified [2]
IdP                  -          MUST
Browser              MUST         -
Identifier URL       SHOULD       -

The IdP MUST be an SSL server [3] because at this point I see no good 
reason not to require this for version 2.0: there's no advantage to a 
low barrier of entry for IdPs, since we need the majority of IdPs to be 
dedicated to doing things *properly* or OpenID's reputation will suffer.

The Identifier URL is only a SHOULD as a compromise for adoption's sake. 
Early adopters with their vanity URLs are unlikely to be able/willing to 
use SSL, but I find that acceptable because early adopters are 
presumably knowledgeable enough to evaluate the risks and take 
responsibility for any consequences. Moving forward, your average user 
will have his identifier hosted by a trustworthy IdP that will hopefully 
be able to sort out certificates. Relying Parties MAY refuse to accept 
identifiers that are not SSL-hosted.

The above represents my vote on the subject.


[1] Feel free to copy this image to somewhere more permanent if you 
think it'd be useful.

[2] RP as server is unspecified because as far as pure OpenID is 
concerned there is no risk to RP being on an unsecure link. The RP is 
free to decide for itself whether to use SSL; the OpenID spec does not 
need to say anything on this subject.

[3] OpenID 1.1 servers will, of course, still be allowed to be on 
non-SSL links. However, there are relatively few IdPs in comparison to 
the number of RPs, so getting all of the mainstream 1.1 IdPs upgraded to 
2.0+SSL will hopefully not be to arduous a task.