[OpenID] OpenID + Government

Thu Aug 13 16:00:12 UTC 2009

Just to add another merit for artifact, it is very mobile client friendly. It
is pretty simple to write a spec for it, and to implement it.
RSA-SHA sign, we do not have to wait until 3.0.
If I remember correctly, it was one of the thing to be done in 2.1
timeframe.

=nat

On Fri, Aug 14, 2009 at 12:55 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

> if saml2 satisfies the rule, at "loa=2"and "loa=3", then we don't have to
> do any more than SAML2 does.
>
> Why not let a WG profile/amend messages, for use in 12m time, and choose
> suitable security mechanisms that address the fact that assertion
> communication is indirect (and request communication is typically indirect).
>
> Now, we faced what openid faces with indirect communication structures when
> we (Visa/Mastercard/IBM/VeriSign etc) designed SET; IBM's OAEP saved the
> day.
>
> lets reopen the WG for openid auth, for minor releases: 2.1 and 2.2.
> Fundamentally, lets add public key techniques to the communication plane ,
> in the form of the OAEP. I dont know who Will is, but i'll guess he will
> implement OAEP in about 30m. Its just a one-time pad, and the generation/use
> of reversible trapdoor hash-based KDFs that generate the
> encryption/decryption subkey schedule of a DES-era feistel network).
>
> Define v2.1 as
> 1. the simple addition of OAEP as a new "signing" method, and
> 2. the sensitive information values in a signed assertion can now blank in
> the cleartext form of the assertion transferred classically, when OAEP is
> the  signing method.
>
> The point is that the public association + nonces is the source keying
> material - that OAEP then uses to generate the one time pad that
> encrypts/signs the request or response under the reversible public key
> properties of the OAEP scheme.
>
> define v2.2 as
> 1. the addition of an artifact binding mode. That is, a private association
> used by OPs when responding need not sign the assertion any longer, but can
> sign (using OAEP) a blank assertion template. (The use-once private
> association handle is the artifact id, itself).
> 2. Over direct channel and existing flow, enable RP to resolve the private
> association (= artifactID in SAML speak). Amend verification response so its
> message can be optionally signed (using OAEP) using a public association,
> thus delivering the ciphertext of the assertion to the intended recipient as
> well as the status of the private association resolution (isvalid=true).
>
> in a v3.0, once you have signed XRD, and add RSA entity public keys (with
> signing keyusage only) to the (provider-signed) endpoint XRDs, we can
> address non-repudiation for higher levels of assuraces. One can sign the
> OAEP ciphertext, using RSA, where the (rsaciphertext,oaepciphertext) is put
> into the base64 of an openid signature type -  for either requests or
> responses.
>
> ________________________________________
> 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 10:40 PM
> To: Nat Sakimura
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] OpenID + Government
>
> Nat,
>
> Look at sec 8.1.2
> Eavesdropping resistance: An authentication protocol is resistant to
> eavesdropping attacks if an eavesdropper who records all the messages
> passing
> between a claimant and a verifier or relying party finds that it is
> impractical to
> learn the private key, secret key or password or to otherwise obtain
> information
> that would allow the eavesdropper to impersonate the claimant.
> Eavesdropping
> resistant protocols make it impractical3 for an attacker to carry out
> an off-line
> attack where he/she records an authentication protocol run then
> analyses it on
> his/her own system for an extended period, for example by systematically
> attempting to try every password in a large dictionary, or by brute
> force
> exhaustion.
>
> Also Table 3 on page 39 Required Protections
>
> Using AX update_url doesn't protect the authentication token.
> It would send a unsolicited positive assertion to the RP return_to URL
> with a separate token.
>
> 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.
>
> In AX the store message is a indirect message sorry.  It is not
> relevant to the LoA 2 case in any event as LoA 2 requires protection
> against eavesdroppers on the reply.
>
> Honestly it is better to take LoA 1 now and work on LoA 2 with proper
> planning and spec cycle.
>
> 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.
>
> We have only covered some of the issues.  Password entropy, identity
> proofing, liability, and other issues all come into play at LoA 2.
>
> Getting LoA 1 approved was no cake walk itself.
>
> I have probably said too much as it is.
>
> 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.
>
> John B.
>
> On 12-Aug-09, at 8:48 PM, Nat Sakimura wrote:
>
> > Yes. Go for Artifact Binding!
> > That happens to be the main road block for even writing CX.
> > If we had that, we could completely reuse the OpenID protocols
> > already spec'ed out.
> > Unfortunately it is not the case.
> >
> > 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???
> > Hope so. See http://www.sakimura.org/en/modules/wordpress/index.php?p=89
> >  for details in Section 4, Protocol.
> >
> > 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).
> >
> > Which document are you referring to?
> >
> > 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.
> >
> > =nat
> >
> > On Thu, Aug 13, 2009 at 5:42 AM, Breno de Medeiros
> > <breno at google.com> 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
> >
> >
> >
> > --
> > Nat Sakimura (=nat)
> > http://www.sakimura.org/en/
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090814/5e5f5e3f/attachment-0001.htm>