[OpenID] TransparencyCamp and OpenID (U)

Fri Mar 13 13:28:28 UTC 2009

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