[OpenID] OpenID + Government

Wed Aug 12 23:57:34 UTC 2009

Peter,

Direct communications are only supported in openID 2.0 for associations.

Passing assertions to the RP are always done via GET or POST through  
the client browser.

The entire assertion including the identifier must be protected from  
interception at LoA 2.

Yes things could be done, but that would require making up entirely  
new parts of the protocol.

The GSA, and more importantly I am not willing to do that.

The profile is of the approved spec and extensions, not what people  
may wish we had as a spec.

XRI resolution is an option but not a requirement for OPs.

The goal as you may imagine, was to create a profile that could be  
implemented by existing OPs in a reasonable amount of time, that meets  
LoA 1 without inventing anything new.

We have done that. (I hope)

If wishes were horses we would have a pony and perhaps a LoA 2  
approved version of openID.

However in the real world the openID community has more real spec and  
deployment work to do before we get our pony.

John B.

On 12-Aug-09, at 3:51 PM, Peter Williams wrote:

>
> I'll disclose that I have not read NIST LOA classes for websso, in a  
> while. (Its not been exactly important; and I know I only quickly  
> scan read the general structure, originally).
>
> But can someone explain in detail the GSA team _found_ openid2 to be  
> unable to support in their profile, if LOA#2 is fundamentally about  
> "encrypted assertion passing" to "an intended recipient"?
>
> a) openid2.0 already allows direct (vs indirect) communications,  
> between RP website and OP website.
>
> b) OPs already have the saml quivalent of an audience restriction -  
> its called the consumer realm
> c) Ops are already obligated to test the metadata of the RP prior to  
> assertion release, to ensure the realm is authorized by the  
> communication's control plane (the XRDs)
> d) Any OP using the XRI proxy top get the RP's XRD can - by mere  
> configuration of the proxy discovery requests - require trusted  
> resolution (according to the existing XRI spec). The proxy can thus  
> apply full power PKI controls to validate that a trusted authority  
> affirms the XRD/metadata is itself authoritative and integral
>
>
> If you assume that b c and d satisfy the rules of a confidentiality  
> service (vs a mere SSL "encryption" service) because they implement  
> hte "intended recipient" controls of any confidentiality security  
> service, one needs now only analyze (a).
>
> If the RP initiates (as it must) a DIRECT https connection to the OP  
> to request an assertion (or in openid-speak, to seek "identity  
> verification"), the OP initially always has the SSL server role.
>
> The party with the SSL server role in SSL defines AND CONTROLS the  
> effective cipersuites of the various connections, and of course  
> always controls the security context on its own write-channel of any  
> individual connection - over which it returns the assertion  
> encrypted by the SSL2 record layer protocol under the write-enc-key
>
> Assuming an already evaluated SSL stack on the OP, if the SSL3  
> server role is show to be held by the OP and the code furthermore  
> shows that an assertion can only be released by a party holding the  
> SSL server role, such implementation evidence when shown to a TOE  
> evalutor would normally be sufficient to claim that: code+config  
> only allows encrypted communication of an "assertion" value to using  
> a given SSL3 ciphersuite.
>
>
> If you now construct the claim of confidentiality (control of  
> intended recipient) with the claim of mandatory channel encryption  
> for the sensitive value in the type system (using the SSL write  
> channel), Ill guess one will satisfy the LOA#2 requirement.
>
> Of course, depending on the implementation assurance requirements,  
> an implementation may need to show that one cannot seperate the  
> intended recipient controls from and channel encryption controls.  
> Since Google has Ben Laurie, the quickest way to do that would be to  
> actually implemement SSL in user space.
>
> Its possible that LOA#2 PP may have assurance elements that mandate  
> kernel-based implementations of ssl3/TLS. One would have to study  
> the pp carefully.
>
>
> ________________________________________
> From: openid-general-bounces at lists.openid.net [openid-general-bounces at lists.openid.net 
> ] On Behalf Of John Bradley [john.bradley at wingaa.com]
> Sent: Wednesday, August 12, 2009 2:13 PM
> To: Breno de Medeiros
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] OpenID + Government
>
> Breno,
>
> There are a number of options for dealing with encryption, we also
> need to decide if we are going to LoA 3 that requires non-repudiation.
> That also impacts the choices we may make.
>
> Artifact binding is one option.  Using POST and encrypting with the
> RP's SSL Public key is another.
>
> Perhaps we need to start work on openID 2.1 :)
>
> The point is that they are our choices.  Once we make them the GSA can
> profile them.
>
> John B.
>
> On 12-Aug-09, at 1:42 PM, Breno de Medeiros wrote:
>
>> Complexity could be minimally increased by defining an artifact
>> profile.
>>
>> Encryption using artifact profile requires no specification, comes  
>> for
>> free by having OP SSL endpoints.
>>
>> Artifact profile would reduce the length of URLs, currently a problem
>> (not all implementations seem to handle POST very well, and POST can
>> be annoying on mobile devices or when changing from SSL to non-SSL
>> context). I think it would be more beneficial on that basis than even
>> from a security standpoint.
>>
>> Otherwise, I agree with John's assessment.
>>
>> On Wed, Aug 12, 2009 at 1:32 PM, John
>> Bradley<john.bradley at wingaa.com> wrote:
>>> Kids,
>>> The GSA is producing a profile of standards.
>>> OpenID 2.0,  PAPE and AX are the only standards.
>>> Surprisingly SREG 1.1 is not a standard (I guess we just forgot in
>>> our
>>> enthusiasm for AX)
>>> The last thing the GSA wants (as I understand it) is to create new
>>> specs and
>>> impose them on the community.    This includes picking winners and
>>> losers in
>>> proposed extensions.
>>> The GSA has not said that openID can never be LoA 2+ , only that
>>> given the
>>> existing specs available to profile it doesn't meet the criteria of
>>> SP800-63
>>> for LoA 2.
>>> The protocol MUST prevent assertion disclosure at LoA 2.
>>> That is the main roadblock.
>>> Other protocols encrypt the assertion to the RP or use a direct SSL
>>> connection (artifact binding)
>>> It is a tradeoff that openID community needs to consider carefully,
>>> security can be increased to meet LoA 2 but it will be at the cost
>>> of
>>> increased complexity.
>>> It may not be a good bargain.  That however is a decision for the
>>> community
>>> to make and not the GSA or any other government.
>>> I don't believe that CX addresses this issue,  it is intended to
>>> solve a
>>> different trust problem.
>>> Nat and I have discussed this.
>>> If there is a extension to openID or changes to the core spec that
>>> allow
>>> openID to be profiled at LoA 2+ then the GSA or whoever can revisit
>>> the
>>> profile.
>>> These things are not cast in stone.
>>> Some of the things in the TFAP are a challenge the Shibboleth
>>> community as
>>> well.
>>> If a bank wants to send your unencrypted data through a browser as a
>>> redirect, good for them.
>>> The GSA and OMB  have to live within SP800-63,  and given that I
>>> think the
>>> decision to profile openID for LoA 1 while the community sort out
>>> where it
>>> wants to go is reasonable.
>>> My opinions are my own as always, and not representative of any
>>> government
>>> or organization.
>>> Take a deep breath,  relax it is all good.
>>> John B.
>>>
>>> Message: 5
>>> Date: Wed, 12 Aug 2009 12:25:45 -0700
>>> From: Peter Williams <pwilliams at rapattoni.com>
>>> Subject: Re: [OpenID] OpenID + Government
>>> To: Paul Madsen <paulmadsen at rogers.com>
>>> Cc: "openid-general at lists.openid.net"
>>> <openid-general at lists.openid.net>
>>> Message-ID: <73608B74-40FB-419E-A4A5-94C8F0C9673B at rapattoni.com>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Ok!
>>>
>>> So you did what myspace did: took the defined extension points and
>>> added value . They discarded the dh handshake, and use a vendor
>>> specific association protocol (apparently). Better strength and
>>> assurance hopefully... falling back to default (low) assurance ...
>>> when no better option can be found.
>>>
>>> In your case, I'll guess in the endpoint xrd that you advertise -  
>>> per
>>> the model -additional extension handler names, so adding value via
>>> the
>>> extension framework. Presumably this offers something suiting  
>>> banking
>>> frauds to only those endpoints wanting to rely on xri resolution ...
>>> for capability negotiation and address selection (which is the more
>>> openid way of doing things).
>>>
>>> This is all just like ssl, now, where folks up negotiate higher
>>> strength mechanisms and higher level operational assurances.
>>>
>>> But look at the difference In my tone and characterization, when
>>> discussing the assurance space.
>>>
>>> Let's tell the ssl story using a divisive characterization of
>>> assurances, now:
>>>
>>> Oh my god, netscapes 40bit rc4 ciphersuite with crappy pertabators  
>>> in
>>> the kdf (broken by a French student) and verisign class 1 client
>>> certs
>>> means ALL of ssl3 is low assurance. Look! GSA confirms it. It's a
>>> fact! Folks must now switch to IPsec, for >loa1 assurance level when
>>> tunelling!
>>>
>>> No. Thats not how it was handled. Nsa/Dod comes along, puts in a
>>> missi
>>> ciphersuite, adjusts the handshake flow so missi-style key agreement
>>> can share the record layer with rsa handshakes, and dod office
>>> systems
>>> get all the additional strength of missi ciphers and missi  
>>> assurances
>>> when talking amongst themselves (now featuring monthly changing user
>>> keying material, key comprise handling, flash authority removal,
>>> remote cac applet provisioning on gp smartcards...). They can still
>>> interwork with public sites using rsa, at low assurance, however.
>>>
>>> (I'm showing my out of dateness In federal systems. By now, missi
>>> will
>>> have been renamed 6 times...)
>>>
>>> What we want is Strong, professional security engineering, based on
>>> cc
>>> claims, STD protection profiles, evaluated cryptomodules, even  
>>> formal
>>> methods proving the info flow properties of the strong type
>>> system,...
>>> And in grassroots centric openid, We want that all to be developed  
>>> in
>>> and shown by common or garden programmers, not just defense
>>> contractors working for GSA-affiliated .gov sites
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 12, 2009, at 8:37 AM, "Paul Madsen" <paulmadsen at rogers.com>
>>> wrote:
>>>
>>> As you acknowledge ('custom extension albeit'), the application you
>>>
>>> are
>>>
>>> referring to supplemented OpenID's own security in order to meet the
>>>
>>> higher assurance requirements.
>>>
>>> With the standardization of that 'custom extension' continuing to
>>>
>>> progress in the OpenID community, perhaps the GSA will in the future
>>>
>>> reevaluate whether the combination can support higher assurance?
>>>
>>> The GSA have said (or will say soon I guess) only that OpenID 2.0,  
>>> as
>>>
>>> profiled, tops out at LOA1 (for US Gov RPs). The profile doeesnt
>>>
>>> mention
>>>
>>> (I think at least, I havent read it) CX or any other extensions that
>>>
>>> might supplement assurance.
>>>
>>> paul
>>>
>>> p.s. I believe I am as suspicious of the realty industry as you are
>>> of
>>>
>>> Liberty
>>>
>>> Peter Williams wrote:
>>>
>>> So there i am in 2006 trying to let our 100k realtors use their rsa
>>>
>>> tokencodes at lots of other websites in the realty universe.
>>>
>>> Sounds simple, no?
>>>
>>> And I walk into this religion style war of words, of spin  
>>> meistering,
>>>
>>> claim and counterclaim ...and a omnipresent culture of the putdown.
>>>
>>> Generally: an intense over sensitivity, in the saml camp. And it's
>>>
>>> not
>>>
>>> because realty is a hot new market for websso sales!
>>>
>>> As a lapsed security engineer, i love seeing the passion (and i also
>>>
>>> love the saml product we selected, which we use everyday at a cost  
>>> of
>>>
>>> deployment now of about $2000 partner link (taking about 3 days, in
>>>
>>> most cases)). But the "edginess" I see displayed across not one but
>>>
>>> several companies is a real issue for going further with saml. I  
>>> feel
>>>
>>> like I'm stepping across a precipice.
>>>
>>> And the edginess gets noticibly stronger the moment i talk about
>>>
>>> (also) using openid in our customers trust networks.
>>>
>>> Now you are a good person to challenge on the bretts topic of "GSA
>>>
>>> has
>>>
>>> declared openid as inherently unable to address more than loa1
>>>
>>> assurance requirements". A firm you associate with has been using
>>>
>>> openid (with a custom extension albeit) for banking transactions-
>>>
>>> which are not trivial transactions for which low assurance is
>>>
>>> appropriate.how can I reconcile those 2 statements?
>>>
>>> Now I feel I'm being spun to even more. Brett made, in literary
>>>
>>> analysis, a reaching for that "defining" gsa classification. And in
>>>
>>> that act of reaching underminded his case for being impartial. A  
>>> good
>>>
>>> politician doesn't reach for the very classification device that
>>>
>>> devides folks. He or she enables (almost magically) a acceptable
>>>
>>> tradeoff.
>>>
>>> Is kantara going to formally disarm the samlista brigade and move
>>>
>>> forward, or have we just got a new name for the same old warhorse?
>>>
>>>
>>>
>>> Grudgingly, they acceptedn
>>>
>>>
>>>
>>>
>>> On Aug 12, 2009, at 4:10 AM, "Paul Madsen" <paulmadsen at rogers.com>
>>>
>>> wrote:
>>>
>>> Peter, a good theory. But you forget to mention that NORAD
>>>
>>> intentionally
>>>
>>> scrambled the fighters late to allow the planes to get to the
>>>
>>> towers.
>>>
>>> Peter Williams wrote:
>>>
>>> My value- such as it is- is as an outsider.
>>>
>>> I measured 4 sources:
>>>
>>> Sun Micro rsa conference presentation on their openid pilot;
>>>
>>> rationales for never being an rp
>>>
>>> Ping identity factors gating speed of adoption of openid2 -
>>>
>>> privileged acess
>>>
>>> Scott cantors view on openid2 generally, and saml as used in xrd;
>>>
>>> raw opinion, shared freely
>>>
>>> How the uk jisc pilot of openid framed the basis for it's total
>>>
>>> adoption failure in uk academia. Was it geared to fail?
>>>
>>> Given these 4 inputs, I simply conjectured a link (liberty). I
>>>
>>> tested my conjecture by being a bit outlandish. CoMpared to the
>>>
>>> norm (fox news and msnbc), I was MILD in the imputations. Lots of
>>>
>>> Ifs, buts, shoulds, mays....that mature heads would recognize as
>>>
>>> method.
>>>
>>> Don't get upset. It's just an experiment.
>>>
>>> Little, powerless, clueless, skilless, informationless peter throws
>>>
>>> tiny word stone at mighty million dollar liberty standards lobbying
>>>
>>> machine ...and gets "over the top" reaction.
>>>
>>> Why? Why such sensitivity?
>>>
>>>
>>>
>>> On Aug 11, 2009, at 5:29 PM, "John Bradley"
>>>
>>> <john.bradley at wingaa.com<mailto:john.bradley at wingaa.com>> wrote:
>>>
>>> Peter, Brett
>>>
>>> As a member of Liberty, Kantara, ICF, and OIDF.   I can say that I
>>>
>>> have never seen any indication of Liberty plotting against openID
>>>
>>> or info-card.  (I do go to most of the secret meetings)
>>>
>>> The issue with physical access is more one of not trying to boil
>>>
>>> the ocean.
>>>
>>> There is real desire by real government RPs to use open
>>>
>>> technologies and work with commercial identity providers.  There
>>>
>>> are RPs I am working with who want this yesterday.
>>>
>>> This first step is hard enough.  Many people have been working hard
>>>
>>> for many months.
>>>
>>> One of the ways we have been able to make progress is by limiting
>>>
>>> the scope.
>>>
>>> We could have done physical access, LoA 4,  p-cards and other
>>>
>>> things.
>>>
>>> The initial program by the GSA is a start not an end to the
>>>
>>> process.
>>>
>>> There will be changes to the initial profiles and additional
>>>
>>> profiles as time and requirements permit.
>>>
>>> This first step is a scary amount of work,  give us time please.
>>>
>>> John B.
>>>
>>> On 11-Aug-09, at 5:04 PM, <mailto:openid-general-request at lists.openid.net
>>>
>>> openid-general-request at lists.openid.net<mailto:openid-general-request at lists.openid.net
>>>
>>> wrote:
>>>
>>> Date: Tue, 11 Aug 2009 13:43:29 -0700
>>>
>>> From: Peter Williams
>>>
>>> <<mailto:pwilliams at rapattoni.com>pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com
>>>
>>> Subject: Re: [OpenID] OpenID + Government
>>>
>>> To: Brett McDowell
>>>
>>> <<mailto:email at brettmcdowell.com>email at brettmcdowell.com<mailto:email at brettmcdowell.com
>>>
>>> Cc: OpenID List
>>> <<mailto:general at openid.net>general at openid.net<mailto:general at openid.net
>>>
>>> Message-ID: <<mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com
>>>
>>> 7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com<mailto:7911DEBA-C04B-4CC7-8A4B-967626522E9A at rapattoni.com
>>>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> If the infocard stack is technically reputable, can you explain why
>>>
>>> an
>>>
>>> accredited provider would be excluded from using it (and openid)
>>>
>>> from
>>>
>>> making assertions of physical presence?
>>>
>>> _______________________________________________
>>>
>>> general mailing list
>>>
>>> general at lists.openid.net<mailto:general at lists.openid.net>
>>>
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>> _______________________________________________
>>>
>>> general mailing list
>>>
>>> general at lists.openid.net
>>>
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>> End of general Digest, Vol 36, Issue 13
>>> ***************************************
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>>
>>>
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general