[OpenID] TransparencyCamp and OpenID (U)

Fri Mar 13 16:54:23 UTC 2009

On Fri, Mar 13, 2009 at 9:49 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  I don’t see why the delegation feature of OpenID would particularly
> interfere. One could be doing exactly the same delegation with SAML.
>
>
>
> B exploiting the “heavy” nameid modules in SAML, one could do it rather
> better than openid does it, not that anyone does - to my knowledge  (At
> Rapattoni, we accomplish what openid delegation achieves by non SAML means,
> seeing as our SAML server doesn’t do nameid. It uses “legacy”
> associative-mappings that realty has had deployed for 10 years.)
>
>
>
> Most of the rules you commented on were about the signals and the security
> handshake , not the quality of user authentication. I see no real difference
> between SAML.authcontextclass and openid.pape.
>

Yes, and I did not say otherwise.

>
>
> The NIST criteria doesn’t impose any trust models – they do not exclude
> self-asserting parties, for example (the openid UCI model).
>
>
>
> If trust issues are not out of scope, they should be. Assurance criteria
> should not be advocating or biasing any administrative elements of
> operational policy .
>

I was not really talking about trust issues, but about assurance criteria
for delegation.

>
>
> …Otherwise, this  process will do to SAML/openid …just what it did to PKI.
>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *Breno de Medeiros
> *Sent:* Friday, March 13, 2009 9:28 AM
> *To:* Paul Madsen
> *Cc:* OpenID List
> *Subject:* Re: [OpenID] TransparencyCamp and OpenID (U)
>
>
>
>
>
> On Fri, Mar 13, 2009 at 3: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.)
>
>
> Implicit indication could be achieved by public documentation.
>
>
> 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.
>
>
> Shared secret key => implies that the OP should not accept negotiations
> over HTTP. Even DH does not bind the shared key to the verifier because
> there is no authenticity.
> Response_nonce should have at least 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.
>
>
> Response_nonce, if properly implemented, would guarantee this. Both the RP
> and the OP (in check_authentication mode) should verify the nonce for
> uniqueness.
>
>
>
> 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.
>
>
> Implies that OP check_authentication should be over SSL only.
>
>
>
> 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.
>
>
> That means that the RP should reject response_nonces older than five
> minutes. Implies some level of clock skew adjustment that OpenID does not
> provide.
>
>
>
> 2a) assertions must specify whether the name of the Subscriber is a
> verified name or a pseudonym.
>
>
> Assuming it to be a pseudonym unless otherwise specified by extensions
> would satisfy this.
>
>
> 2b) assertions shall be protected against manufacture/modification,
> capture, redirect and reuse.,
>
>
> Reuse is prevented by the signature inclusion of the return_to URL,
> op_endpoint. Signature also prevents against modification. Protecting
> against capture could be understood as a mandate for POST, since GET
> assertions can be compromised through the browser history prior to their
> expiration.
>
>
>
> 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
>
>
> This is not applicable, as OpenID does not rely on common-domain cookies.
>
>
>
> 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.
>
>
> Again, implies that check_authentication should be performed over SSL only.
>
>
>
> 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.
>
>
> SSL would likely meet such standards.
>
>
> In the surface, it would seem that OpenID could achieve such standard with
> minor tweaks of the protocol. However, this perception is misleading. The
> standards was developed for non-user-centric systems where the IDP has
> out-of-band mechanisms to bind identifiers to real users. In a user-centric
> system where users can delegate arbitrary identifiers to the OP, one would
> expect it to be necessary to develop an additional set of criteria by which
> delegation can be assured to a minimum level of integrity protection. Today
> delegation can be achieved reasonably easily via phishing attacks that may
> appear relatively benign (do not ask user to enter password credentials, for
> instance).
>
>
>
>
>
>
> 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<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@
> 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
> [image: ConnectID] <http://feeds.feedburner.com/%7Er/blogspot/gMwy/%7E6/1>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090313/a419b8b4/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 22342 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090313/a419b8b4/attachment-0002.gif>