<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hi Hans<DIV><BR class="khtml-block-placeholder"></DIV><DIV>Good points. Do you have a suggestion on the security profiles? Do the following make sense?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>HTTP - HTTP is used in one of more requests</DIV><DIV>HTTPS - HTTPS is used in all requests</DIV><DIV>PKI - public key is used for ??? (not used for anything now except HTTPS)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In your comments below you appear concerned about clear-text association and stateless mode. Assuming the rest of the protocol is using HTTPS, what are the issues with clear-text association or stateless mode when used with HTTPS?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-- Dick</DIV><DIV><BR><DIV><DIV>On 23-Aug-06, at 6:04 AM, Granqvist, Hans wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><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></FONT></LI><FONT face="Arial" color="#000000" size="2"></FONT></UL><FONT face="Arial" color="#000000" size="2"><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></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>