[OpenID] TransparencyCamp and OpenID (U)

Fri Mar 13 14:15:26 UTC 2009

There is operational policy specific stuff in there, that does not belong  in there (shame on NIST).

It's for the deployment theatre and the accreditation officer to decide if 5m for external domains or 12h for internal domains are the right thresholds, not NIST. Similarly, the obligation to limit assertion queries to use-once or per-transaction semantics is also an unwarranted policy bias. One may well query the IDP for live assertions whose audience satisfies the RP. UI you take a paypal type designer-policy, one may have an authorizationStatement in an assertion that arms the users rights to assert a RP-stored credit-card number for 24h (or 36h), during which all payment will be honored - without the RP having to go download the users CRL supporting the user's signed XRDs each time later assertions confirm the user controls his/her URI - when then initiating a payment, for example.

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Ben Laurie
> Sent: Friday, March 13, 2009 6:28 AM
> To: Paul Madsen
> Cc: OpenID List
> Subject: Re: [OpenID] TransparencyCamp and OpenID (U)
>
> On Fri, Mar 13, 2009 at 10:42 AM, Paul Madsen <paulmadsen at rogers.com>
> wrote:
> > Full NIST LOA requirements for 'assertions' (NIST uses the term in
> the
> > inclusive sense and not specific to SAML) are laid in Section 10.3.2
> of
> > http://csrc.nist.gov/publications/drafts/800-63-rev1/SP800-63-
> Rev1_Dec2008.pdf
> >
> > Focusing on Level 2, the combined assertion requirements of LOA 1 & 2
> are
> >
> > 1a) All assertions recognized within this guideline must indicate the
> > assurance level of the initial authentication of the Claimant to the
> > Verifier using the former's long-term token(s). The assurance level
> > indication within the assertion may be implicit (e.g., through the
> identity
> > of the Verifier implicitly indicating the resulting assurance level)
> or
> > explicit (e.g., through an explicit field within the assertion.)
> > 1b)  it must be impractical for an Attacker to manufacture an
> assertion or
> > assertion reference that can be used to impersonate the Subscriber.
> If the
> > direct model is used, the assertion which is used must be signed by
> the
> > Verifier or integrity protected using a secret key shared by the
> Verifier
> > and Relying Party, and if the indirect model is used, the assertion
> > reference which is used must have a minimum of 64 bits of entropy.
> > 1c) Assertions shall be specific to a single transaction, and, if
> assertion
> > references are used, they shall be freshly generated whenever a new
> > assertion is created by the Verifier. In other words, assertions and
> > assertion references are generated for one time use.
> > 1d) all assertions sent from the Verifier to the Relying Party must
> either
> > be signed by the Verifier, or transmitted from an authenticated
> Verifier via
> > a protected channel. In either case, a strong mechanism must be in
> place
> > which allows the Relying Party to establish a binding between the
> assertion
> > reference and its corresponding assertion, based on integrity
> protected (or
> > signed) communications with the authenticated Verifier.
> > 1e) assertions that are consumed by a Relying Party which is not part
> of the
> > same Internet domain as the Verifier must expire within 5 minutes of
> their
> > creation. Assertions used within a single Internet domain, including
> > assertions contained in or referenced by cookies, however, may last
> as long
> > as 12 hours.
> > 2a) assertions must specify whether the name of the Subscriber is a
> verified
> > name or a pseudonym.
>
> See, we run into i18n problems already: in the UK there is no concept
> of a legal name.
>
> > 2b) assertions shall be protected against manufacture/modification,
> capture,
> > redirect and reuse.,
>
> Reuse? Surely the whole point of assertions is that they _can_ be
> reused? e.g. I should be able to prove that everyone who logged in to
> my over 18 site was over 18. How do I do that without reuse?
>
> > 2c) assertions, assertion references and any session cookies used by
> the
> > Verifier or Relying party for authentication purposes, shall be
> transmitted
> > to the Subscriber through a protected channel which is linked to the
> primary
> > authentication process in such a way that session hijacking attacks
> are
> > resisted
> > 2d) To protect assertions against manufacture, modification, and
> disclosure,
> > assertions which are sent from the Verifier to the Relying Party,
> whether
> > directly or through the Subscriber's device, shall either be sent via
> a
> > mutually authenticated channel between the Verifier and Relying
> Party, or
> > equivalently shall be signed by the Verifier and encrypted for the
> Relying
> > Party.
> > 2e) All assertion protocols used at Level 2 and above require the use
> of
> > Approved cryptographic techniques. As such, the use of Kerberos keys
> derived
> > from user generated passwords is not permitted at Level 2 or above.
> >
> >
> > paul
> >
> > Brett McDowell wrote:
> >
> > To (what I think is) Chris' point about changing/up-leveling the
> discussion
> > out of a "OpenID vs. SAML" or "OpenID is insecure" sidetrack, and to
> (what I
> > think is) Johannes' point about capturing the security requirements
> that we
> > can base a new work stream on... I humbly suggest we look at the
> > requirements our friends in the US Government (and others) are
> requiring now
> > and are confident they will continue to require regardless of (and
> > independent of) private sector innovation.  I'm specifically
> referring to
> > their requirement to compliance to the NIST defined levels of
> assurance
> > (LOA).
> > If I were to peer into my crystal ball I would probably see that most
> of the
> > compelling applications that governments will open to 3rd-party
> credentialed
> > citizens are likely to be set to LOA 2 or LOA 3.  How about we shift
> this
> > conversation to focus on how OP's can offer OpenID-based services to
> their
> > users that achieve government recognized compliance to LOA 2 (and
> soon
> > after, LOA 3)?
> > Some work on this has already been *started* but not progressed in
> earnest.
> >  Project Concordia has some use cases that look at this problem
> space.  The
> > Identity Assurance Framework looks at how any particular credential
> service
> > can achieve LOA 1 through LOA 4.  What we don't have is any analysis
> of what
> > an OP could achieve with OpenID 2.0.  Knowing this will provide a
> clear gap
> > analysis of what we have vs. what we need. We can base our
> deliberations on
> > these hard facts.  I can only believe this will be more productive
> than...
> > actually I don't see any alternative to this approach if we are
> serious
> > about making progress.
> > Next Steps?
> > Since I work closely with the primary US Government agency in charge
> of
> > procurement (which is quite important to the issue of what/which IT
> > infrastructure Federal agencies deploy), and because they already
> require
> > our certification for all federation technology prior to being
> considered by
> > agencies for procurement (this is all SAML and/or PKI  today -- just
> to
> > clear up any confusion about the usage of SAML in eCitizen
> applications),
> > and since they are working closely with us to adopt our credential
> > assessment framework for LOA 1-2 in the very near future (and LOA 3-4
> down
> > the road), I would be happy to talk with them about co-hosting a
> kick-off
> > event to drill into this issue as it relates to OpenID specifically.
> I
> > assume they will be interested.  They, like I, would like to see
> citizens be
> > able to use whatever private sector credentials they "already have"
> to
> > access government applications.  If those are OpenID's, then lets
> make sure
> > those OpenID's are going to be acceptable to these federal Relying
> Parties
> > (who knows, we might learn something that helps us win more RP
> adoption in
> > other markets as well).
> > Thoughts?
> >
> > Brett McDowell | +1.413.652.1248 | http://info.brettmcdowell.com
> > On Mar 12, 2009, at 9:05 PM, Peter Williams wrote:
> >
> >
> > I've been playing with dynamic SAML metadata modes recently. Instead
> of
> > reading a signed XRDS file, peers dynamically  sign SAML metadata
> files. A
> > SAML metadata file is only XML, and has extensions:  one of which
> could
> > include an XRD or 2 (and thus get signed XRD off the ground). You can
> look
> > at the SAML endpoints as funky XRD services, all expressed in their
> own
> > markup.
> >
> > The best thing that ever happened to SAML2 was openid - as [most of]
> the
> > SAML crowd have largely got off their ultra high horse and been
> forced to
> > match openid in simplicity and effectiveness (or be made irrelevant).
> >
> >
> >
> >
> >
> > From: general-bounces at openid.net [mailto:general-
> bounces at openid.net] On
> > Behalf Of Chris Messina
> > Sent: Thursday, March 12, 2009 3:59 PM
> > To: Johannes Ernst
> > Cc: OpenID List
> > Subject: Re: [OpenID] TransparencyCamp and OpenID (U)
> >
> > On Thu, Mar 12, 2009 at 4:37 PM, Johannes Ernst
> > <jernst+openid.net at netmesh.us> wrote:
> > On Mar 12, 2009, at 9:46, Ben Laurie wrote:
> > I agree that all of SAML is way too large a pill to swallow but
> > there's no reason subsets that are usable cannot be defined, and,
> > indeed, have been.
> >
> > I would love it if somebody was actually starting a working group (in
> Apache
> > they would call it "incubate") that would propose all the gory
> details of a
> > "more secure" form of OpenID that still fits into the decentralized,
> > discovery-based OpenID architecture. Only then can we tell what may
> or may
> > not be the better approach.
> >
> > +1.
> >
> > I'm not the person to do it, simply because I don't have the
> background, but
> > I'm really no longer interested in the discussion that "OpenID isn't
> good
> > enough for high-value transactions". Tell that to the Japanese who
> are
> > already pushing payments over/with OpenID.
> >
> > If it's got security issues, as Johannes said, we should collect a
> list of
> > them as issues and go about finding suitable solutions, best
> practices or
> > explanations for WONTFIX-type resolutions.
> >
> > The reality is, people will use OpenID in all kinds of cases that we
> can't
> > be able to anticipate; SAML (again, from what I hear - being mostly
> SAML
> > ignorant) is that SAML requires sysadmins to maintain and more and
> more
> > organizations want to move away from that kind of model.
> >
> > HTTP succeeds because (among many, many other reasons) you can jack
> up your
> > service to things like S3 once you realize that you're not really
> saving any
> > money as a small to mid-sized organization running a server farm. The
> same
> > thing applies to user authentication and security over time, where
> it'd be
> > nice to have a fairly straight-forward, interoperable protocol for
> doing
> > authentication. From what I've heard, I don't question the
> sophistication or
> > technological pedigree of SAML; it's just that when I hear people say
> that
> > OpenID isn't secure enough, it's like saying we should all switch to
> RDF
> > because it's OMG-so-much-better.
> >
> > I don't doubt that either are, if your primary concerns in life are
> centered
> > around the problems that these technologies solve; but for folks for
> whom
> > security isn't necessarily their only responsibility, and they no
> longer
> > have an IT department or staff to manage a SAML solution and look to
> OpenID
> > as a potential answer - saying that OpenID isn't secure enough
> doesn't seem
> > to be an answer to the question "well, then what do I use?"
> >
> > How do we get from where we are today to a point where OpenID really
> does
> > solve a large number of security problems - if only because it
> hopefully
> > means fewer passwords in use overall - and fewer unique accounts to
> > maintain? Look, let's take another look at this: it isn't just "is
> OpenID by
> > itself secure?" It's: "given how OpenID changes the makeup of and
> behavior
> > in the overall ecosystem, are we now more secure than we were
> before?" In
> > general, I think the answer is yes, though of course good security
> > necessitates vigilance and constant improvement.
> >
> > To Johannes point: are we capturing these needed improvements
> anywhere, and
> > if not, can we begin to?
> >
> > Chris
> >
> >
> > --
> > Chris Messina
> > Citizen-Participant &
> >  Open Web Advocate-at-Large
> >
> > factoryjoe.com # diso-project.org
> > citizenagency.com # vidoop.com
> > This email is:   [ ] bloggable    [X] ask first   [ ] private
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> > ________________________________
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
> > ________________________________
> > No virus found in this incoming message.
> > Checked by AVG.
> > Version: 7.5.557 / Virus Database: 270.11.10/1996 - Release Date:
> 11/03/2009
> > 8:42 PM
> >
> >
> > --
> > Paul Madsen
> > e:paulmadsen @ ntt-at.com
> > p:613-482-0432
> > m:613-282-8647
> > web:connectid.blogspot.com
> >
> > _______________________________________________
> > general mailing list
> > general at openid.net
> > http://openid.net/mailman/listinfo/general
> >
> >
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general