Re: [OAUTH-WG] draft-ietf-oauth-v2-threatmodel
I think you hit the nail on the head. My feeling is that threats not directly related to OAuth obfuscate the key issues we are trying to alert implementers and deployers to. I think Barry made a good proposal but Michael still feels Barry's text has not addressed the issue. I think you are right to escalate the issue for guidance. Phil On 2012-05-02, at 9:02, Hannes Tschofenig wrote: > Hi all, > > I looked at the feedback for the draft-ietf-oauth-v2-threatmodel and I want > to share my thoughts with you (as a WG co-chair). > > I believe there are three questions that need to be answered: > > 1) Is malicious code a problem? > > I believe most people would agree that malicious code is indeed a problem for > Internet security. > > 2) Are IETF working groups required to address this extended Internet threat > model? > > RFC 3552 provides guidance for protocol developers writing security > considerations. It also defines terminology and a threat model. > The model, however, does not consider malicious code as a threat. > > Malicious code is a problem for any IETF protocol, not just for OAuth. This > requires a broader IETF discussion. > > If there is the believe that IETF groups should (a) describe threats that > result from malicious code and (b) develop solutions to deal with it then the > IAB should facilitate such a discussion. I will discuss this topic within > the IAB. > > Despite the lack of available guidance in RFC 3552 > draft-ietf-oauth-v2-threatmodel talks about this threat. > > 3) What can we do to highlight the threat in our document? > > Barry proposed additional text (see below) that highlights the challenges. > > This issue as resolved. Let's move forward. > > Ciao > Hannes > > PS: Here is Barry's proposed tet > > - > 5.5. A Word on User Interaction and User-Installed Apps > > OAuth, as a security protocol, is distinctive in that its flow usually > involves significant user interaction, making the end user a part of > the security model. This creates some important difficulties in > defending against some of the threats discussed above. Some of these > points have already been made, but it's worth repeating and > highlighting them here. > > * End users must understand what they are being asked to approve (see > Section 5.2.4.2). Users often do not have the expertise to understand > the ramifications of saying "yes" to an authorization request. and are > likely not to be able to see subtle differences in wording of > requests. Malicious software can confuse the user, tricking the user > into approving almost anything. > > * End-user devices are prone to software compromise. This has been a > long-standing problem, with frequent attacks on web browsers and other > parts of the user's system. But with increasing popularity of > user-installed "apps", the threat posed by compromised or malicious > end-user software is very strong, and is one that is very difficult to > mitigate. > > * Be aware that users will demand to install and run such apps, and > that compromised or malicious ones can steal credentials at many > points in the data flow. They can intercept the very user login > credentials that OAuth is designed to protect. They can request > authorization far beyond what they have led the user to understand and > approve. They can automate a response on behalf of the user, hiding > the whole process. No solution is offered here, because none is > known; this remains in the space between better security and better > usability. > > * Addressing these issues by restricting the use of user-installed > software may be practical in some limited environments, and can be > used as a countermeasure in those cases. Such restrictions are not > practical in the general case, and mechanisms for after-the-fact > recovery should be in place. > - > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth WG Rechartering
Hi Stephen, Hi IESG secretary, Derek and myself would like to submit the updated OAuth charter to the IESG. Please find it below. Ciao Hannes -- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones Done Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done Submit 'HTTP Authentication: MAC Authentication' as a working group item Done Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard May 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard May 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012 Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC Dec. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] Dec. 2012 Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC [Starting point for the work will be http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] ___ OAuth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-26.txt
Thanks Phil. These will be corrected in -27 (if we publish one to close IESG issues) or during AUTH48. EH > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phil Harvey > Sent: Wednesday, May 02, 2012 8:24 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-26.txt > > Hello, > > I noticed draft 26 was published and found a few typos while reading the diff > against draft 25: > > 1) Where the word SHALL was inserted into the paragraph under "2. Client > Registration", I noticed that the first word of each bullet point in the list > that > follows it needs to be altered to flow properly: > > When registering a client, the client developer SHALL: > >o specifies the client type as described in Section 2.1, >o provides its client redirection URIs as described in > Section 3.1.2, and >o includes any other information required by the authorization > server (e.g. application name, website, description, logo image, > the acceptance of legal terms). > > To read like this: > > When registering a client, the client developer SHALL: > >o specify the client type as described in Section 2.1, >o provide its client redirection URIs as described in > Section 3.1.2, and >o include any other information required by the authorization > server (e.g. application name, website, description, logo image, > the acceptance of legal terms). > > 2) under "10.3 Access Tokens" (delineated by brackets): > > This specification does not provide any methods for the resource > server to ensure that an access token presented to it by a given > client, was issued to [the that] client by the authorization server. > > Which was probably intended to read like this?: > > This specification does not provide any methods for the resource > server to ensure that an access token presented to it by a given > client, was issued to that client by the authorization server. > > 3) under both "11.1 The OAuth Access Token Type Registry" and "11.2 The > OAuth Parameters Registry", there are two instances where it says "two > weeks" when it should say "two week" in a sentence like this: > > "...after a two weeks review period..." > > Hope that helps, > > Phil Harvey > eBiz Web Developer > The Lampo Group, Inc. > http://www.daveramsey.com > > -Original Message- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Tuesday, May 01, 2012 2:13 AM > To: i-d-annou...@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-26.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol Working Group of > the IETF. > > Title : The OAuth 2.0 Authorization Framework > Author(s) : Eran Hammer > David Recordon > Dick Hardt > Filename: draft-ietf-oauth-v2-26.txt > Pages : 66 > Date: 2012-05-01 > >The OAuth 2.0 authorization framework enables a third-party >application to obtain limited access to an HTTP service, either on >behalf of a resource owner by orchestrating an approval interaction >between the resource owner and the HTTP service, or by allowing the >third-party application to obtain access on its own behalf. This >specification replaces and obsoletes the OAuth 1.0 protocol described >in RFC 5849. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-26.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-26.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-ietf-oauth-v2-threatmodel
Hi all, I looked at the feedback for the draft-ietf-oauth-v2-threatmodel and I want to share my thoughts with you (as a WG co-chair). I believe there are three questions that need to be answered: 1) Is malicious code a problem? I believe most people would agree that malicious code is indeed a problem for Internet security. 2) Are IETF working groups required to address this extended Internet threat model? RFC 3552 provides guidance for protocol developers writing security considerations. It also defines terminology and a threat model. The model, however, does not consider malicious code as a threat. Malicious code is a problem for any IETF protocol, not just for OAuth. This requires a broader IETF discussion. If there is the believe that IETF groups should (a) describe threats that result from malicious code and (b) develop solutions to deal with it then the IAB should facilitate such a discussion. I will discuss this topic within the IAB. Despite the lack of available guidance in RFC 3552 draft-ietf-oauth-v2-threatmodel talks about this threat. 3) What can we do to highlight the threat in our document? Barry proposed additional text (see below) that highlights the challenges. This issue as resolved. Let's move forward. Ciao Hannes PS: Here is Barry's proposed tet - 5.5. A Word on User Interaction and User-Installed Apps OAuth, as a security protocol, is distinctive in that its flow usually involves significant user interaction, making the end user a part of the security model. This creates some important difficulties in defending against some of the threats discussed above. Some of these points have already been made, but it's worth repeating and highlighting them here. * End users must understand what they are being asked to approve (see Section 5.2.4.2). Users often do not have the expertise to understand the ramifications of saying "yes" to an authorization request. and are likely not to be able to see subtle differences in wording of requests. Malicious software can confuse the user, tricking the user into approving almost anything. * End-user devices are prone to software compromise. This has been a long-standing problem, with frequent attacks on web browsers and other parts of the user's system. But with increasing popularity of user-installed "apps", the threat posed by compromised or malicious end-user software is very strong, and is one that is very difficult to mitigate. * Be aware that users will demand to install and run such apps, and that compromised or malicious ones can steal credentials at many points in the data flow. They can intercept the very user login credentials that OAuth is designed to protect. They can request authorization far beyond what they have led the user to understand and approve. They can automate a response on behalf of the user, hiding the whole process. No solution is offered here, because none is known; this remains in the space between better security and better usability. * Addressing these issues by restricting the use of user-installed software may be practical in some limited environments, and can be used as a countermeasure in those cases. Such restrictions are not practical in the general case, and mechanisms for after-the-fact recovery should be in place. - ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-26.txt
Hello, I noticed draft 26 was published and found a few typos while reading the diff against draft 25: 1) Where the word SHALL was inserted into the paragraph under "2. Client Registration", I noticed that the first word of each bullet point in the list that follows it needs to be altered to flow properly: When registering a client, the client developer SHALL: o specifies the client type as described in Section 2.1, o provides its client redirection URIs as described in Section 3.1.2, and o includes any other information required by the authorization server (e.g. application name, website, description, logo image, the acceptance of legal terms). To read like this: When registering a client, the client developer SHALL: o specify the client type as described in Section 2.1, o provide its client redirection URIs as described in Section 3.1.2, and o include any other information required by the authorization server (e.g. application name, website, description, logo image, the acceptance of legal terms). 2) under "10.3 Access Tokens" (delineated by brackets): This specification does not provide any methods for the resource server to ensure that an access token presented to it by a given client, was issued to [the that] client by the authorization server. Which was probably intended to read like this?: This specification does not provide any methods for the resource server to ensure that an access token presented to it by a given client, was issued to that client by the authorization server. 3) under both "11.1 The OAuth Access Token Type Registry" and "11.2 The OAuth Parameters Registry", there are two instances where it says "two weeks" when it should say "two week" in a sentence like this: "...after a two weeks review period..." Hope that helps, Phil Harvey eBiz Web Developer The Lampo Group, Inc. http://www.daveramsey.com -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Tuesday, May 01, 2012 2:13 AM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-26.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Framework Author(s) : Eran Hammer David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-26.txt Pages : 66 Date: 2012-05-01 The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-26.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-26.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Assertion Profile Author(s) : Michael B. Jones Brian Campbell Yaron Y. Goland Filename: draft-ietf-oauth-assertions-03.txt Pages : 17 Date: 2012-05-02 This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present. This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-assertions-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-assertions-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed URN for JWT token type: urn:ietf:params:oauth:token-type:jwt
I agree that context does sufficiently differentiate. I guess I'm just lamenting the way that type has been overloaded in the base OAuth stuff and am already dreading the conversions that might go something like, "well which type of token type are we talking about here?" This particular URN probably doesn't change that one way or the other and I'm okay with what you've proposed. I just felt compelled to mention the potential confusion point. On Tue, May 1, 2012 at 6:39 PM, Mike Jones wrote: > I understand what you're saying, but I still believe that the URN is the > correct one. > > While I agree that the potential for confusion is unfortunate, context will > actually successfully differentiate the two uses of similar terms. Bear in > mind that the OAuth usage of the term is actually short for "Access Token > Type" (see OAuth Core sections 8.1 and 11.1), whereas the URN above is to > provide a type identifier for a particular kind of security token. > > I also believe that the examples in the Bearer spec (see > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-4), the MAC > spec (see > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01#section-5.1), and > the JWT spec will make the uses of these terms clear to implementers in > context. > > -- Mike > > -Original Message- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Tuesday, May 01, 2012 4:26 PM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Proposed URN for JWT token type: > urn:ietf:params:oauth:token-type:jwt > > The only concern I might raise with it is that use of the "token-type" > part might lead to some confusion. The term token type and the parameter > token_type are already pretty loaded and have specific meaning from the core > OAuth framework: > http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-7.1 > > That token type is about providing "the client with the information required > to successfully utilize the access token to make a protected resource > request" (i.e. mac and bearer) and is not about the structure of the token > itself which is what this URI seems to want to describe. > JWTs are usually thought of as bearer type tokens but might someday have HoK > (http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20120430/001860.html) > or mac like constructs. > > I don't think there's really a problem with name collisions here but I think > that the current use of token type in the frame work spec is already the > cause of some confusion and I'd hate to exacerbate that. > > On Tue, May 1, 2012 at 5:04 PM, Mike Jones > wrote: >> I'm editing the JWT spec to prepare for the OAuth WG version and to >> track changes in the JOSE specs. Currently the "typ" values defined >> for JWT tokens are "JWT" and "http://openid.net/specs/jwt/1.0"; (see >> http://tools.ietf.org/html/draft-jones-json-web-token-08#section-5). >> I believe that the URN value should be changed to use a URN taken from >> the OAuth URN namespace urn:ietf:params:oauth (defined in >> http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-02). >> >> >> >> I propose to use the URN: >> >> urn:ietf:params:oauth:token-type:jwt >> >> >> >> I believe this fits well with the other four uses of this namespace to date: >> >> urn:ietf:params:oauth:grant-type:saml2-bearer >> >> >> urn:ietf:params:oauth:client-assertion-type:saml2-bearer >> >> urn:ietf:params:oauth:grant-type:jwt-bearer >> >> urn:ietf:params:oauth:client-assertion-type:jwt-bearer >> >> >> >> (The first two are from >> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-11. The >> latter two are from >> http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-04.) >> >> >> >> Do people agree with this URN choice? >> >> >> >> Thanks, >> >> -- Mike >> >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
