security

[Dan Lyke]

On Tue, 24 Oct 2006 19:52:54 -0700, Eddy Nigg (StartCom Ltd.) wrote:
> No it's absolutely not! Because any RP is going to rely on that login
> facility!

Right. But limiting how the Identity Provider offers that login  
facility to me to HTTPS stands in the way of potential further  
enhancements. You didn't, for instance, address my method of  
communicating with my server once my server becomes more than just my  
LID Identity Provider.

> 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 ;-)

Yes. That's a Claimed Identifier (per section 8.3.1) from which the  
Relying Party can derive the IDP Endpoint URL.

That's the only information that the User needs to give the Relying  
Party in order for the Relying Party to authenticate that User with  
the Identity Provider. If that information is spoofable, then the user  
can be given  an other IDP Endpoint URL to complete the transaction,  
and since it's pretty easy to get a certificate from a payphone with a  
stolen credit card, then we're into simple phishing.

> The fears are the same fears that any bank, credit card company,  
> online shop or about anybody else running secured servers, has...

That's not what I asked. I asked about specific vulnerabilities within  
the protocol where DNS spoofing or sniffing could enable exploits, and  
I wanted to know what those exploits were.

"Be afraid, be very very afraid" is not a fear specific enough to be  
written into a spec.

I've got a good idea of some of those exploits, but I haven't read  
anything from you that indicates that you're coming from an  
understanding of the OpenID 2.0 spec rather than an "HTTPS will solve  
everything" perspective.

> Wrong...An IDP will install a wild card certificate for the user  
> area,
> i.e. CN=*.pip.verisignlabs.com

And for users who, for instance, use LiveJournal with their own domain  
names? (There are lots of those)

For regular LiveJournal URLs, LJ could presumably redirect any  
accesses which weren't queries for OpenID information (I'm not sure  
how it'd tell this, but...) to the HTTP versions to save on compute  
costs. And the OpenID spec could mandate that all Claimed Identifiers  
be transformed into HTTPS URLs.

We're down to the point where to continue this discussion we need to  
be talking in very concrete specifics. You've convinced me that with  
the exploits you see the Claimed Identifier would need to be HTTPS,  
and that it's actually less important that the IDP Endpoint URL be  
HTTPS than the Claimed Identifier.

Now it's time to look at the feasibility of implementing HTTPS Claimed  
Identifiers. That means wildcard subdomains or individual IP addresses  
for vanity domains, right?

Personally, I'm thinking that some sort of private key and a cache so  
that an RP can verify that it's retrieving information from the same  
IdP it did before is much more likely to actually get deployed.

Dan