security

[Martin Atkins]

Eddy Nigg (StartCom Ltd.) wrote:
 >
> Too bad, now anybody can point an http sniffer to your IDP server and 
> wait patiently for the user/pass pair...However I suspect, that you mix 
> up the IDP and RP here....The above looks more like an IDP ;-)
 >

The more I read your replies the more I get the impression that you 
don't really understand the OpenID protocol flow. In particular, thue 
"username/password pair" is OUT OF SCOPE FOR OPENID. How the IdP 
authenticates the user, whether by username/password, a cookie, SSL 
client cert, or even just "I know this client is on the same LAN as me", 
is NOT SPECIFIED by OpenID. What *is* specified by OpenID is how the IdP 
communicates the positive assertion back to the RP.

In a separate message I posted the following diagram showing the flow of 
information in a "smart mode" OpenID transaction:

     <http://i13.tinypic.com/2w3ch7b.png>

The arrows shown in bright red are those which could be theoretically 
compromised if the RP doesn't use SSL. The dark red arrow shows what 
could be theoretically compromised if the identity URL does not use SSL.

As you can see:
  * A username/password pair does not feature anywhere in the protocol
  * A cleartext RP is compromising only:
     * The claimed_identifier (public knowledge)
     * The authentication signature, which is already cryptographically
      protected using a shared secret exchanged over a secure link
      between the RP and the IdP. It is also RP-specific and non-
      replayable.
  * A cleartext identity URL may allow an attacker to spoof the URL of
   the IdP and the IdP Token.

My take-away from this is that:
  * The IdP MUST run an SSL server.
  * The RP MAY run an SSL server, but OpenID doesn't care either way
  * The identity URL SHOULD be on an SSL server, but due to real-world
   adoption problems early adopters will probably not use SSL. Moving
   forward, reputable IdPs could begin offering SSL-secured identity
   URLs for a fee, which would cover costs of supplying a dedicated
   IP address to the user, the extra computing power required to do SSL,
   and perhaps a bundled SSL certificate. However, we are not yet at
   the point where we can get away with mandating this.