OpenID Security

[McGovern, James F (HTSC, IT)]

-----Original Message-----
From: Peter Watkins [mailto:peterw at tux.org]
Sent: Friday, February 06, 2009 8:29 PM
To: McGovern, James F (HTSC, IT)
Cc: specs at openid.net
Subject: Re: OpenID Security

>> What do you mean, "the" implementation? There is no "the"
implementation.

>> Are you arguing that for the OpenID *protocol* to succeed, every
>> *implementation* has to be "secure"? That sounds like a marketing
problem to me, and it's one you solve by having math/crypto experts
ensure the
>> *protocol* is good. Period. When someone finds a bug in Postfix, we
don't say SMTP is broken and run away from email; we say Postfix version
such->>>>and->> such is broken, Wietse fixes it, and we go on.

Sometimes, the implementation is busted where a consumer (albeit a
technical one) can tell the library and version. SMTP makes it easy by
responding to HELO. Is there an OpenID equivalent?

Likewise, the protocol can be defined as weak where someone may apply
additive security on top of it. Kinda like doing SMTP over TLS and/or
S/MIME. A relay can have additional logic to determine how to respond to
<<insecure>> interactions. At times, the SMTP protocol has morphed
without breaking backward compatibility.

I suppose you could argue for protocol compliance tools as part of
protecting the OpenID image -- at least that might allow OpenID
proponents to disown any insecure library that happened to fail the
protocol tests.
But I wouldn't expect too much from that, either. Automated testing is
good for finding obvious problems, but it's no replacement for good,
smart programming, and not a cure for bad code. I'd feel more
comfortable with software that passed some long-running fuzzing tests,
but you really don't want to be vouching for the "security" of specific
implementations. That's just asking for trouble.

The way that you achieve protocol compliance can be done through complex
and public interoperability demonstrations (Think Burton Group times
two), basic automated test harnesses (Think Java/J2EE compatibility
testkit) and review by disinterested parties.  


-Peter



************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090209/57dc930d/attachment-0001.htm>