Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
I think so. What about cases where two descrete applications/consumers share a realm? Sent from a mobile device. On Nov 13, 2008, at 3:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote: On Thu, Nov 13, 2008 at 12:46 PM, Allen Tom <[EMAIL PROTECTED]> wrote: Hi Yariv, In the registered consumer case, the SP will need the Consumer Key to show the Approval page. Previous versions of the spec had the Request Token in the OpenID Authentication request, which allowed the SP to derive the Consumer Key from the Request Token. At the IIW, we had discussed somehow tying the Association Handle to the Consumer Key. Regardless of the solution, the SP will need to be know the Consumer Key in order to properly identify the OAuth Consumer when displaying the Approval page. The OpenID Realm is not quite sufficient, at least for SPs which require consumers to pre-register for a CK. I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. Let's assume that The Bad Guy somehow managed to sneak a misleading realm into a request, i.e. the user sees the realm on the login page and clicks "approve" when he wouldn't have approved had he known the real identity of The Bad Guy. The OP embeds, in the request token, the realm to which the request token was issued. Later, when The Bad Guy tries to exchange the request token for an access token, it won't work, b/c The Bad Guy only has access to his own consumer secret, which doesn't match the realm embedded in the request token. So we _do_ have a binding from the request token to the consumer key, it's just enforced later, not at approval time. Does this make sense, or am I missing something? Dirk. One possible optimization would be to just use the Consumer Key as the OpenID Association Handle, and Consumer Secret as the OpenID Association. The Consumer can just sign the OpenID Auth request using its CK/CS and the OP can return a pre-approved response token in the OpenID assertion. The Consumer can then exchange the response token for the OAuth Access Token/ ATS. Thoughts? Allen Yariv Adan wrote: Following the IIW session on this topic, we updated the spec in http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html to address the issues that were raised. Especially, optimizing on how OAuth request token is handled, allowed to remove one full roundtrip! Would appreciate any feedback on the updated suggestion. Thanks On Mon, Nov 3, 2008 at 12:00 PM, <[EMAIL PROTECTED]> wrote: Send specs mailing list submissions to specs@openid.net To subscribe or unsubscribe via the World Wide Web, visit http://openid.net/mailman/listinfo/specs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of specs digest..." Today's Topics: 1. Proposal to create the OpenID OAuth Hybrid Working Group (Yariv Adan) --- --- Message: 1 Date: Mon, 3 Nov 2008 15:30:57 +0100 From: Yariv Adan <[EMAIL PROTECTED]> Subject: Proposal to create the OpenID OAuth Hybrid Working Group To: specs@openid.net Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" In accordance with the OpenID Foundation IPR policies and procedures< http://openid.net/foundation/intellectual-property/ > this note proposes the formation of a new working group chartered to produce an OpenID specification. As per Section 4.1 of the Policies, the specifics of the proposed working group are: Background Information: OpenID has always been focused on how to enable user-authentication within the browser. Over the last year, OAuth has been developed to allow authorization either from within a browser, desktop software, or mobile devices. Obviously there has been interest in using OpenID and OAuth together allowing a user to share their identity as well as grant a Relying Party access to an OAuth protected resource in a single step. A small group of people have been working on developing an extension to OpenID which makes this possible in a collaborative fashion within http://code.google.com/p/step2/. This small project includes a draft spec and Open Source implementations which the proposers would like to finalize within the OpenID Foundation. Working Group Name: OpenID OAuth Hybrid Working Group Purpose: Produce a standard OpenID extension to the OpenID Authentication protocol that provides a mechanism to embed an OAuth approval request into an OpenID authentication req
Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]
Certainly but the consumer context you display to the user is falsely represented based solely on the realm in that circumstance. Sent from a mobile device. On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote: On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote: Dirk Balfanz wrote: I don't think this is true - I believe the realm is sufficient. Let me try and explain. (We'll assume registered consumers.) On the approval page, we need to identify the consumer. In its current form, the spec basically assumes that you're gonna use the realm for that. You're assuming that a realm has only one CK. A site might have multiple consumer keys, with different scopes attached to them... Actually, I wasn't assuming that. At access token request time, you follow the map from consumer-key to realm (that's the direction you can do, right)? If that's a many-to-one map then this will give you one realm. Then you check whether that's the realm that the request token was issued to. The one thing you're losing is that you can't, at approval time, figure out whether that realm is requesting a scope that they have access to. So a realm could ask for a certain scope in their auth request, the user approves it, and then at access-token-request time, you won't issue the token b/c they're using a CK that doesn't have enough privileges. It's still secure, but gives you a crappy user experience if the consumer mixes up their CKs. Wait - I think I have an idea: what if the Yahoo-specific way of requesting the scope is to include the CK into the openid.oauth.scope parameter? That way, you can at approval time make sure that they are requesting a scope that they are actually authorized to pick up. This wouldn't be for security purposes - just as a way to make sure the user experience isn't surprising. Dirk. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID/OAuth hybrid - without app pre-registration
OAuth Discovery 1.0 Draft 2 addresses this issue through the Static Consumer Identity allocation (http://oauth.net/discovery/#static_alloc). For example: http://oauth.net/discovery/1.0/consumer-identity/static 0685bd9184jfhq22 I would assume compatibility with OAuth Discovery is something that will be desirable within the hybrid specification as well. - darren bounds cliqset.com On Wed, Nov 26, 2008 at 1:20 AM, Manger, James H <[EMAIL PROTECTED]> wrote: > The latest OpenID/OAuth hybrid draft REQUIRES the openid.oauth.consumer > parameter, which means an app must be pre-registered with a service before > it can use the protocol. > Requiring per-service pre-registration is not suitable for a web-scale > authentication & delegation solution. [Web sites don't require Firefox, IE, > Safari, Opera, curl, wget, lynx, search crawlers, feed readers... to be > pre-registered] > I don't mind if some service only support pre-registered apps, but pre- > registration really needs to be optional in the *protocol* (even if extra > security considerations apply to that case). > > > A couple of other issues (of lesser importance to supporting un-registered > apps): > > > Response: > openid.oauth.consumer is REQUIRED in the OpenID authentication response. > What is supposed to be done with this field? > Is the app supposed to check that the value in the response matches the value > in the request? > Are there security implications of not doing the check? > I suspect it can be omitted (openid.return_to is still present and signed if > the app want to confirm the response is meant for itself). > > Similarly with openid.oauth.scope in the response. The draft hints that the > value in the response is likely to be different from the value in the > request. It seems like there is nothing an app can do with the scope from the > response without SP-specific knowledge. > I suggest omitting scope from the response. > The OP/SP can define its own structure for openid.oauth.request_token if it > wants to provide more details to an app with SP-specific knowledge. > An arbitrary amount of metadata about the delegation (scopes, lifetimes...) > would be better communicated separately -- perhaps as extra parameters > returned when getting an access token. > > > Signing: > The openid.oauth.* parameters in the OpenID response "MUST be signed" [§9]. > No reason is offered. It is not clear if this is necessary for security, an > arbitrary choice, or adds some value. > This seems to contradict the aim of NOT introducing reliance on the security > properties of one protocol (OpenID) for the correctness of the other (OAuth) > [§11 Security Considerations]. > I think signing openid.oauth.request_token DOES add value. > It proves that the authentication and delegation come from the same user. It > prevents a strange case of two colluding users constructing a response where: > (1) openid.claimed_id identifies user1; but > (2) openid.oauth.request_token gives access to user2's resources. > I am not sure how or if this could be exploited. > I suggest adding a sentence that openid.oauth.request_token MUST be signed to > bind the delegated rights to the user identified by openid.claimed_id. > > > Scopes: > The openid.oauth.scope parameter encodes "one or more scopes" in a way > "possibly specific to the Consumer Provider" [section 7 "Requesting > Authentication"]. > This complicates any future OAuth discovery. Not only will a protected > resource need to indicate a scope value, it will also need to indicate how to > combine that with other scope values (separators, escaping...). Yuck. > I suggest avoiding any mention of structure in the scope field (just call it > a blob obtained from the SP to represent the context of the delegation, with > an expectation that a future OAuth discovery step will supply the blob -- > even better if one blob covers scope & consumer key). > [Poor alternative: define the structure (|-separated relative URIs?, > comma-separated alphanumeric strings?).] > > > Access token secret: > Section "3 Purpose" says > "for security reasons, the OAuth access token is not returned in the URL" > A hint as to the security reasons would be helpful. > The access token is useless without the access token secret that cannot be > obtained without the corresponding consumer secret (since the spec requires > pre-registration). > [Changing "in the URL" to "in the OpenID authentication response" might also > be clearer] > > > Request token secret: > Using an empty string for the request token secret [§10
Re: OpenID Security
I do not believe OWASP presently does any active vulnerability analysis. Rather they provide definition around best practices and reference material around web application security as well as a small set of open source vulnerability analysis and penetration testing tools. With regard to the Fortify link you sent previously; in my experience thus far, I have not found a single automated vulnerability analysis tool that's worth the price tag or the effort involved in tuning it. More often than not they find nothing more than low hanging fruit and false positives. Even worse, they often miss ore than they catch, resulting in a large number of false negatives. Subsequently any 'certification' an automated tool can provide should be taken with a grain of salt. IMO, if a formal security assessment is desirable, it would be much more fruitful to engage a reputable 3rd party to perform one manually. Darren On Thu, Feb 5, 2009 at 3:08 PM, McGovern, James F (HTSC, IT) wrote: > If your implementation is 100% open source, then you don't have to worry > about licensing as OWASP (http://www.owasp.org) will scan at no cost... > > -- > > Message: 1 > Date: Fri, 6 Feb 2009 01:34:33 +0900 > From: Nat Sakimura > Subject: Re: OpenID Security > To: "McGovern, James F (HTSC, IT)" > Cc: specs@openid.net > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Yeah. Fortify is nice. I do not know what would be the licensing terms > now, but before, it used to have a "traveling" kind of license that > allowed consultants to do the evaluation for the projects of their > customers. It might be worthwhile for somebody like OIDF to buy a > license and run a certification program out of it. Of course, having > secure profile, which we do not have yet, is a prerequisite though. > > =nat > > On Wed, Feb 4, 2009 at 11:48 PM, McGovern, James F (HTSC, IT) > wrote: >> OpenID certainly has security features but are all the libraries out >> there written to secure coding practices? Wouldn't it be great if all >> the library creators could have their code reviewed for security >> defects? Check out http://owasp.fortify.com/ >> >> This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential and/or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If > you are not the intended recipient, please notify the sender immediately > by return e-mail, delete this communication and destroy all copies. >> >> >> ___ >> specs mailing list >> specs@openid.net >> http://openid.net/mailman/listinfo/specs >> > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > > > -- > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > End of specs Digest, Vol 30, Issue 7 > > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential and/or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately by return > e-mail, delete this communication and destroy all copies. > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > -- Thank you, Darren Bounds ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Security
Thanks James, I don't believe it's quite so binary, nor was I advocating doing nothing. Based on my experience, automated analysis tools really just scratch the surface and often result in a false sense of security. If it can be accomplished for free and with little effort, fantastic. Furthermore, and as I'm sure you'd agree, I have much more of a problem with the false negatives than I do with the false positives. If I was walking into a field that contained a single land mine, I'd much rather you tell me there are 40 than tell me there are none at all. :) With regard to the free OWASP OS analysis; that's great news. I'd love to hear more about who's actually performing the analysis and how OWASP is meeting the demand. Feel free to email me offline. Darren On Fri, Feb 6, 2009 at 3:43 PM, McGovern, James F (HTSC, IT) wrote: > Darren, I would challenge you by saying the following: > > 1. In the same sense that it is unreasonable for OpenID to satisfy every > identity use case on the planet, you also shouldn't expect a static > analysis toolkit to do the same either. > > 2. Which is worse, having to sort through false positives or to not > perform static analysis at all and have OpenID fail once some bad guy > busts the implementation so badly that everyone runs away from OpenID? > > 3. A small correction on OWASP. OWASP DOES perform analysis on OPEN > SOURCE implementations at no cost. If you have a commercial version, > then you need to pay. The open source implementations simply need to > submit their code to http://owasp.fortify.com to get the process > started. > > 4. The link above is merely hosted by Fortify and they provide the > tools. The actual execution of scanning isn't even done by Fortify > employees but other members of the OWASP community. > > 5. FYI, I am the project leader for several OWASP projects and am the > chapter leader for Hartford (one of the largest). Our next meeting is on > Tuesday at 5pm Eastern where we will have Mary Ruddy of Higgins > presenting. Our meetings are free to attend and for this one, we will > also be webcasting it. The webinar information will be sent out on > Monday to the mailing list. Subscribe at: > http://lists.owasp.org/mailman/listinfo/owasp-hartford If you would like > to attend in person, here is the information: > http://www.owasp.org/index.php/Hartford > > 6. Engaging a reputable third party isn't a bad idea but keep in mind > that "part" of their assessment will use the same automated tools. Firms > I like include Security Compass (http://www.securitycompass.com) Artec > (http://www.artecgroup.net) and Cigital (http://www.cigital.com) > > Date: Thu, 5 Feb 2009 15:48:06 -0500 > From: Darren Bounds > Subject: Re: OpenID Security > To: "McGovern, James F (HTSC, IT)" > Cc: specs@openid.net > Message-ID: ><26563eca0902051248o446aa21br23aeb19f743ae...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I do not believe OWASP presently does any active vulnerability analysis. > Rather they provide definition around best practices and reference > material around web application security as well as a small set of open > source vulnerability analysis and penetration testing tools. > > With regard to the Fortify link you sent previously; in my experience > thus far, I have not found a single automated vulnerability analysis > tool that's worth the price tag or the effort involved in tuning it. > More often than not they find nothing more than low hanging fruit and > false positives. Even worse, they often miss ore than they catch, > resulting in a large number of false negatives. Subsequently any > 'certification' an automated tool can provide should be taken with a > grain of salt. > > IMO, if a formal security assessment is desirable, it would be much more > fruitful to engage a reputable 3rd party to perform one manually. > > > Darren > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential and/or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately by return > e-mail, delete this communication and destroy all copies. > > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > -- Thank you, Darren Bounds ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
