<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Nat,<div><br></div><div>The assertion with the identifier can be eavesdropped. </div><div><br></div><div>SP800-63 tends to be black and white on some of these things. </div><div><br></div><div>There is the sufficient mitigation of risk argument. That might have had some success if the profile precluded SREG and profiled AX to only use direct communications with mutual TLS.</div><div><br></div><div>To most peoples minds that wouldn't be openID as we know it. </div><div><br></div><div>There are 0 implementations capable of doing that today.</div><div><br></div><div>It is only one issue. </div><div><br></div><div>Once we get the initial launch phase out of the way we will be in a better position to have open discussions on how we would like to proceed with LoA 2.</div><div><br></div><div>John B.</div><div><br></div><div><br><div><div>On 13-Aug-09, at 4:33 AM, Nat Sakimura wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Aug 13, 2009 at 2:40 PM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Nat,<br> <br> Look at sec 8.1.2<br> Eavesdropping resistance: An authentication protocol is resistant to<br> eavesdropping attacks if an eavesdropper who records all the messages passing<br> between a claimant and a verifier or relying party finds that it is impractical to<br> learn the private key, secret key or password or to otherwise obtain information<br> that would allow the eavesdropper to impersonate the claimant. Eavesdropping<br> resistant protocols make it impractical3 for an attacker to carry out an off-line<br> attack where he/she records an authentication protocol run then analyses it on<br> his/her own system for an extended period, for example by systematically<br> attempting to try every password in a large dictionary, or by brute force<br> exhaustion.</blockquote><div><br>But this does not per se require encryption. <br>OpenID assertion is not carrying private key, secret key nor password, <br>and if done correctly, it is quite impractical to recover those from the <br> assertion itself. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> <br> Also Table 3 on page 39 Required Protections</blockquote><div><br>same as above. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> <br> Using AX update_url doesn't protect the authentication token.<br> It would send a unsolicited positive assertion to the RP return_to URL with a separate token.</blockquote><div><br>What is this? <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br> <br> Also 8.2.2.2.Assertions requires that the trusted entity(OP) authenticates to the RP using a secure protocol. As the OP is connecting to the RP in the AX case mutual TLS would be required.</blockquote><div><br>Indeed. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> <br> In AX the store message is a indirect message sorry. It is not relevant to the LoA 2 case</blockquote><div><br>It probably is, but then it is due only to the paragraph in Overview section and the requirement that extensions "piggybacks" on Authentication Protocols. <br> What about if we piggybacked on association request? <br><br>Well... I think we ought to change the Auth 2.0 really. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> in any event as LoA 2 requires protection against eavesdroppers on the reply.<br> <br> Honestly it is better to take LoA 1 now and work on LoA 2 with proper planning and spec cycle.</blockquote><div><br>Agreed. I wonder why it is standing still. <br>What can we do to push it forward? <br>It is sooooo damn hard to get the WG started here. <br> And from the point of view of the IPR safety, it is unwise to discuss any technical thing prior to the formation of the WG. Maybe we should get a Kantara WG with OIDF as designated standard body started instead (sarcasm here). That's easy and safe. <br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> <br> A lot of thought went into the decision not to hold up openID LoA 1 by trying to include LoA 2 in the same profile.<br> <br> We have only covered some of the issues. Password entropy, identity proofing, liability, and other issues all come into play at LoA 2.<br> <br> Getting LoA 1 approved was no cake walk itself.<br> <br> I have probably said too much as it is.<br> <br> I look forward to the GSA releasing the profile then people will have something more concrete to criticize. I will happily take the heat for that.<br> <br> John B.<div><div></div><div class="h5"><br> <br> On 12-Aug-09, at 8:48 PM, Nat Sakimura wrote:<br> <br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Yes. Go for Artifact Binding!<br> That happens to be the main road block for even writing CX.<br> If we had that, we could completely reuse the OpenID protocols already spec'ed out.<br> Unfortunately it is not the case.<br> <br> Current thinking is that CX sends the AX store message to OP Endpoint in direct communication, which sounds like a bit of stretch. Is that OK from AX stand point???<br> Hope so. See <a href="http://www.sakimura.org/en/modules/wordpress/index.php?p=89" target="_blank">http://www.sakimura.org/en/modules/wordpress/index.php?p=89</a> for details in Section 4, Protocol.<br> <br> On the assertion disclosure, I do not read that requirement on NIST SP800-63. It only requires "digitally signed by trusted entity" or direct communication. (Here, "digitally signed" means signed by public key cryptography. OpenID "sign" does not qualify).<br> <br> Which document are you referring to?<br> <br> To cope with "Digital Signature" issue, we can adopt it in OpenID 2.1. Alternatively, we can profile AX so that it carries rsa-sha256 signature.<br> <br> =nat<br> <br> On Thu, Aug 13, 2009 at 5:42 AM, Breno de Medeiros <<a href="mailto:breno@google.com" target="_blank">breno@google.com</a>> wrote:<br> Complexity could be minimally increased by defining an artifact profile.<br> <br> Encryption using artifact profile requires no specification, comes for<br> free by having OP SSL endpoints.<br> <br> Artifact profile would reduce the length of URLs, currently a problem<br> (not all implementations seem to handle POST very well, and POST can<br> be annoying on mobile devices or when changing from SSL to non-SSL<br> context). I think it would be more beneficial on that basis than even<br> from a security standpoint.<br> <br> Otherwise, I agree with John's assessment.<br> <br> On Wed, Aug 12, 2009 at 1:32 PM, John Bradley<<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>> wrote:<br> > Kids,<br> > The GSA is producing a profile of standards.<br> > OpenID 2.0, PAPE and AX are the only standards.<br> > Surprisingly SREG 1.1 is not a standard (I guess we just forgot in our<br> > enthusiasm for AX)<br> > The last thing the GSA wants (as I understand it) is to create new specs and<br> > impose them on the community. This includes picking winners and losers in<br> > proposed extensions.<br> > The GSA has not said that openID can never be LoA 2+ , only that given the<br> > existing specs available to profile it doesn't meet the criteria of SP800-63<br> > for LoA 2.<br> > The protocol MUST prevent assertion disclosure at LoA 2.<br> > That is the main roadblock.<br> > Other protocols encrypt the assertion to the RP or use a direct SSL<br> > connection (artifact binding)<br> > It is a tradeoff that openID community needs to consider carefully,<br> > security can be increased to meet LoA 2 but it will be at the cost of<br> > increased complexity.<br> > It may not be a good bargain. That however is a decision for the community<br> > to make and not the GSA or any other government.<br> > I don't believe that CX addresses this issue, it is intended to solve a<br> > different trust problem.<br> > Nat and I have discussed this.<br> > If there is a extension to openID or changes to the core spec that allow<br> > openID to be profiled at LoA 2+ then the GSA or whoever can revisit the<br> > profile.<br> > These things are not cast in stone.<br> > Some of the things in the TFAP are a challenge the Shibboleth community as<br> > well.<br> > If a bank wants to send your unencrypted data through a browser as a<br> > redirect, good for them.<br> > The GSA and OMB have to live within SP800-63, and given that I think the<br> > decision to profile openID for LoA 1 while the community sort out where it<br> > wants to go is reasonable.<br> > My opinions are my own as always, and not representative of any government<br> > or organization.<br> > Take a deep breath, relax it is all good.<br> > John B.<br> ><br> > Message: 5<br> > Date: Wed, 12 Aug 2009 12:25:45 -0700<br> > From: Peter Williams <<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><br> > Subject: Re: [OpenID] OpenID + Government<br> > To: Paul Madsen <<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>><br> > Cc: "<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>"<br> > <<a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a>><br> > Message-ID: <<a href="mailto:73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com" target="_blank">73608B74-40FB-419E-A4A5-94C8F0C9673B@rapattoni.com</a>><br> > Content-Type: text/plain; charset="us-ascii"<br> ><br> > Ok!<br> ><br> > So you did what myspace did: took the defined extension points and<br> > added value . They discarded the dh handshake, and use a vendor<br> > specific association protocol (apparently). Better strength and<br> > assurance hopefully... falling back to default (low) assurance ...<br> > when no better option can be found.<br> ><br> > In your case, I'll guess in the endpoint xrd that you advertise - per<br> > the model -additional extension handler names, so adding value via the<br> > extension framework. Presumably this offers something suiting banking<br> > frauds to only those endpoints wanting to rely on xri resolution ...<br> > for capability negotiation and address selection (which is the more<br> > openid way of doing things).<br> ><br> > This is all just like ssl, now, where folks up negotiate higher<br> > strength mechanisms and higher level operational assurances.<br> ><br> > But look at the difference In my tone and characterization, when<br> > discussing the assurance space.<br> ><br> > Let's tell the ssl story using a divisive characterization of<br> > assurances, now:<br> ><br> > Oh my god, netscapes 40bit rc4 ciphersuite with crappy pertabators in<br> > the kdf (broken by a French student) and verisign class 1 client certs<br> > means ALL of ssl3 is low assurance. Look! GSA confirms it. It's a<br> > fact! Folks must now switch to IPsec, for >loa1 assurance level when<br> > tunelling!<br> ><br> > No. Thats not how it was handled. Nsa/Dod comes along, puts in a missi<br> > ciphersuite, adjusts the handshake flow so missi-style key agreement<br> > can share the record layer with rsa handshakes, and dod office systems<br> > get all the additional strength of missi ciphers and missi assurances<br> > when talking amongst themselves (now featuring monthly changing user<br> > keying material, key comprise handling, flash authority removal,<br> > remote cac applet provisioning on gp smartcards...). They can still<br> > interwork with public sites using rsa, at low assurance, however.<br> ><br> > (I'm showing my out of dateness In federal systems. By now, missi will<br> > have been renamed 6 times...)<br> ><br> > What we want is Strong, professional security engineering, based on cc<br> > claims, STD protection profiles, evaluated cryptomodules, even formal<br> > methods proving the info flow properties of the strong type system,...<br> > And in grassroots centric openid, We want that all to be developed in<br> > and shown by common or garden programmers, not just defense<br> > contractors working for GSA-affiliated .gov sites<br> ><br> ><br> ><br> ><br> ><br> ><br> ><br> ><br> > On Aug 12, 2009, at 8:37 AM, "Paul Madsen" <<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>><br> > wrote:<br> ><br> > As you acknowledge ('custom extension albeit'), the application you<br> ><br> > are<br> ><br> > referring to supplemented OpenID's own security in order to meet the<br> ><br> > higher assurance requirements.<br> ><br> > With the standardization of that 'custom extension' continuing to<br> ><br> > progress in the OpenID community, perhaps the GSA will in the future<br> ><br> > reevaluate whether the combination can support higher assurance?<br> ><br> > The GSA have said (or will say soon I guess) only that OpenID 2.0, as<br> ><br> > profiled, tops out at LOA1 (for US Gov RPs). The profile doeesnt<br> ><br> > mention<br> ><br> > (I think at least, I havent read it) CX or any other extensions that<br> ><br> > might supplement assurance.<br> ><br> > paul<br> ><br> > p.s. I believe I am as suspicious of the realty industry as you are of<br> ><br> > Liberty<br> ><br> > Peter Williams wrote:<br> ><br> > So there i am in 2006 trying to let our 100k realtors use their rsa<br> ><br> > tokencodes at lots of other websites in the realty universe.<br> ><br> > Sounds simple, no?<br> ><br> > And I walk into this religion style war of words, of spin meistering,<br> ><br> > claim and counterclaim ...and a omnipresent culture of the putdown.<br> ><br> > Generally: an intense over sensitivity, in the saml camp. And it's<br> ><br> > not<br> ><br> > because realty is a hot new market for websso sales!<br> ><br> > As a lapsed security engineer, i love seeing the passion (and i also<br> ><br> > love the saml product we selected, which we use everyday at a cost of<br> ><br> > deployment now of about $2000 partner link (taking about 3 days, in<br> ><br> > most cases)). But the "edginess" I see displayed across not one but<br> ><br> > several companies is a real issue for going further with saml. I feel<br> ><br> > like I'm stepping across a precipice.<br> ><br> > And the edginess gets noticibly stronger the moment i talk about<br> ><br> > (also) using openid in our customers trust networks.<br> ><br> > Now you are a good person to challenge on the bretts topic of "GSA<br> ><br> > has<br> ><br> > declared openid as inherently unable to address more than loa1<br> ><br> > assurance requirements". A firm you associate with has been using<br> ><br> > openid (with a custom extension albeit) for banking transactions-<br> ><br> > which are not trivial transactions for which low assurance is<br> ><br> > appropriate.how can I reconcile those 2 statements?<br> ><br> > Now I feel I'm being spun to even more. Brett made, in literary<br> ><br> > analysis, a reaching for that "defining" gsa classification. And in<br> ><br> > that act of reaching underminded his case for being impartial. A good<br> ><br> > politician doesn't reach for the very classification device that<br> ><br> > devides folks. He or she enables (almost magically) a acceptable<br> ><br> > tradeoff.<br> ><br> > Is kantara going to formally disarm the samlista brigade and move<br> ><br> > forward, or have we just got a new name for the same old warhorse?<br> ><br> ><br> ><br> > Grudgingly, they acceptedn<br> ><br> ><br> ><br> ><br> > On Aug 12, 2009, at 4:10 AM, "Paul Madsen" <<a href="mailto:paulmadsen@rogers.com" target="_blank">paulmadsen@rogers.com</a>><br> ><br> > wrote:<br> ><br> > Peter, a good theory. But you forget to mention that NORAD<br> ><br> > intentionally<br> ><br> > scrambled the fighters late to allow the planes to get to the<br> ><br> > towers.<br> ><br> > Peter Williams wrote:<br> ><br> > My value- such as it is- is as an outsider.<br> ><br> > I measured 4 sources:<br> ><br> > Sun Micro rsa conference presentation on their openid pilot;<br> ><br> > rationales for never being an rp<br> ><br> > Ping identity factors gating speed of adoption of openid2 -<br> ><br> > privileged acess<br> ><br> > Scott cantors view on openid2 generally, and saml as used in xrd;<br> ><br> > raw opinion, shared freely<br> ><br> > How the uk jisc pilot of openid framed the basis for it's total<br> ><br> > adoption failure in uk academia. Was it geared to fail?<br> ><br> > Given these 4 inputs, I simply conjectured a link (liberty). I<br> ><br> > tested my conjecture by being a bit outlandish. CoMpared to the<br> ><br> > norm (fox news and msnbc), I was MILD in the imputations. Lots of<br> ><br> > Ifs, buts, shoulds, mays....that mature heads would recognize as<br> ><br> > method.<br> ><br> > Don't get upset. It's just an experiment.<br> ><br> > Little, powerless, clueless, skilless, informationless peter throws<br> ><br> > tiny word stone at mighty million dollar liberty standards lobbying<br> ><br> > machine ...and gets "over the top" reaction.<br> ><br> > Why? Why such sensitivity?<br> ><br> ><br> ><br> > On Aug 11, 2009, at 5:29 PM, "John Bradley"<br> ><br> > <<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a><mailto:<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>>> wrote:<br> ><br> > Peter, Brett<br> ><br> > As a member of Liberty, Kantara, ICF, and OIDF. I can say that I<br> ><br> > have never seen any indication of Liberty plotting against openID<br> ><br> > or info-card. (I do go to most of the secret meetings)<br> ><br> > The issue with physical access is more one of not trying to boil<br> ><br> > the ocean.<br> ><br> > There is real desire by real government RPs to use open<br> ><br> > technologies and work with commercial identity providers. There<br> ><br> > are RPs I am working with who want this yesterday.<br> ><br> > This first step is hard enough. Many people have been working hard<br> ><br> > for many months.<br> ><br> > One of the ways we have been able to make progress is by limiting<br> ><br> > the scope.<br> ><br> > We could have done physical access, LoA 4, p-cards and other<br> ><br> > things.<br> ><br> > The initial program by the GSA is a start not an end to the<br> ><br> > process.<br> ><br> > There will be changes to the initial profiles and additional<br> ><br> > profiles as time and requirements permit.<br> ><br> > This first step is a scary amount of work, give us time please.<br> ><br> > John B.<br> ><br> > On 11-Aug-09, at 5:04 PM, <mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a><br> ><br> > <a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a><mailto:<a href="mailto:openid-general-request@lists.openid.net" target="_blank">openid-general-request@lists.openid.net</a><br> ><br> > wrote:<br> ><br> > Date: Tue, 11 Aug 2009 13:43:29 -0700<br> ><br> > From: Peter Williams<br> ><br> > <<mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a>><a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com" target="_blank">pwilliams@rapattoni.com</a><br> ><br> > Subject: Re: [OpenID] OpenID + Government<br> ><br> > To: Brett McDowell<br> ><br> > <<mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a>><a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a><mailto:<a href="mailto:email@brettmcdowell.com" target="_blank">email@brettmcdowell.com</a><br> ><br> > Cc: OpenID List<br> > <<mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a>><a href="mailto:general@openid.net" target="_blank">general@openid.net</a><mailto:<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br> ><br> > Message-ID: <<mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><br> ><br> > <a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><mailto:<a href="mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com" target="_blank">7911DEBA-C04B-4CC7-8A4B-967626522E9A@rapattoni.com</a><br> ><br> > Content-Type: text/plain; charset="us-ascii"<br> ><br> > If the infocard stack is technically reputable, can you explain why<br> ><br> > an<br> ><br> > accredited provider would be excluded from using it (and openid)<br> ><br> > from<br> ><br> > making assertions of physical presence?<br> ><br> > _______________________________________________<br> ><br> > general mailing list<br> ><br> > <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><mailto:<a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a>><br> ><br> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br> ><br> > _______________________________________________<br> ><br> > general mailing list<br> ><br> > <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br> ><br> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br> ><br> ><br> ><br> ><br> > ------------------------------<br> ><br> > _______________________________________________<br> > general mailing list<br> > <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br> ><br> ><br> > End of general Digest, Vol 36, Issue 13<br> > ***************************************<br> ><br> ><br> > _______________________________________________<br> > general mailing list<br> > <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br> > <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br> ><br> ><br> <br> <br> <br> --<br> --Breno<br> <br> +1 (650) 214-1007 desk<br> +1 (408) 212-0135 (Grand Central)<br> MTV-41-3 : 383-A<br> PST (GMT-8) / PDT(GMT-7)<br> _______________________________________________<br> general mailing list<br> <a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br> <br> <br> <br> -- <br> Nat Sakimura (=nat)<br> <a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br> </blockquote> <br> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br></blockquote></div><br></div></body></html>