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