<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML DIR=ltr><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"></HEAD><BODY><DIV><FONT face='Arial' color=#000000 size=2>
<DIV id=idOWAReplyText2091 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>We've been conducting an
internal security review of the OpenID 2.0 </FONT><FONT face=Arial
size=2>authentication protocol here at VeriSign and I wanted to share some
of </FONT><FONT face=Arial size=2>the findings with you. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Now, before I start, I understand there is
a draft in progress that is due any day now and that this draft
</FONT><FONT face=Arial size=2>might mitigate some of the concerns, but I still
want to bring these issues up, as I think some of them may warrant potential
wire-format changes to the current specified protocol.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>One main concern is the way the protocol mixes comparatively strong
mechanisms such as Diffie-Hellman key generation and HMAC-based signed
assertions with weaker options such as Clear-Test Association Sessions and
Stateless Mode. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>This can be solved by specify Open ID 2.0 protocol "security
profiles" and how to discover and negotiate these. The negotiation phase may
change the wire-format, since the idp and rp would need to communicate
reluctance, inabilities, and cryptographic errors when deciding specific
security profiles. (This is a potential wire-format change.)</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Such a security profile would specify whether discover
elements have to be digitally signed, and if so in what way; whether TLS/SSL (or
other<FONT size=2> secure channel) is needed for discovery transport. The
profile should also handle the current problem with
using ephemeral-ephemeral DH in the association exchange (specify how
to replace with ephemeral-static with certified public key, or how to
protect association establishment with TLS/SSL and X.509 cert checking.) Or
perhaps there is another authenticated key exchange mechanism.</FONT></DIV><FONT
size=2></FONT></DIV><FONT size=2></FONT></FONT></DIV>
<P><FONT face=Arial color=#000000 size=2><FONT size=2>Some other considerations
include </FONT></FONT></P>
<UL>
<LI><FONT face=Arial color=#000000 size=2><FONT size=2>how to deal with a
malicious rp redirecting the User-Agent to a malicious idp for
purposes of learning passwords, etc.</FONT></FONT></LI>
<LI><FONT face=Arial color=#000000 size=2><FONT size=2>having the rp
incorporate randomness into the MAC key</FONT></FONT></LI>
<LI><FONT face=Arial color=#000000 size=2><FONT size=2>c</FONT></FONT><FONT
face=Arial color=#000000 size=2><FONT size=2>ryptographically link and
sequence each authentication request-response pair with a MAC on the request,
as a better replay protection mechanism</FONT></FONT></LI>
<LI><FONT face=Arial color=#000000 size=2><FONT size=2>eliminating ability of
an IdP to downgrade to a clear-text association session or to a stateless mode
process.</FONT></LI></UL><FONT size=2></FONT>
<DIV dir=ltr>There are a few more, but I just wanted to post this as an
indication that there are some security issues within the protocol. We
should address these sooner rather than later. The major change
seems to be the establishment of security profiles, but the use of
these might force wire-format changes. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>To think about: </DIV>
<UL dir=ltr>
<LI>
<DIV>Are security profiles a usable concept? </DIV></LI>
<LI>
<DIV>How important is the protocol's capability to self-handle
such security profiles' negotiation (think TLS cipher suite negotiation)?
</DIV></LI>
<LI>
<DIV>Can the protocol "just die" if idp/rp have a profile mismatch?
</DIV></LI>
<LI>
<DIV>Once a profile is decided between user/rp/idp (implicit or explicit)
how should the protocolt gracefully handle (intentional or not) missteps?
</DIV></LI></UL>
<DIV dir=ltr>Let's see if we can work through some of these concerns. Obviously,
the less disruptive changes to existing code-bases the better!</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Thanks,</DIV>
<DIV dir=ltr>Hans Granqvist</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV></FONT></BODY></HTML>