Re: [OAUTH-WG] Agenda for IETF#87 Meeting
I disagree with Mike on several points, and we have had this argument before :) MAC is not interchangable with 1.0a though they are close. We might define 1.0a token usage for 2.0 Holding MAC while we figure out HOK is not my favorite, and if you look at the current MAC draft it has HOK properties. The current draft is not ready for last call in my opinion as there are several things to resolve. Sent from Yahoo! Mail on Android ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
The new signature base string stuff still needs work, I wanted to tackle more major restructuring first. I want to pull all of those things out of the query string. From: Sergey Beryozkin sberyoz...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Friday, March 1, 2013 3:51 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt I'm looking at [1] and I honestly don't follow what would adding JSON structure bring to the table, the text there is quite straight-forward, and the 'sorting' variable is not even there, may be, only if headers are *optionally* included when calculating 'mac'. Are you indirectly referring to the idea of OAuth2 servers supporting an OAuth1-style tokens which was proposed in the other thread by any chance, as you mention oath_... parameters ? In that context, using JWT extension may work, not really sure, but in context of [1] - I don't understand where it would fit in Thanks, Sergey [1] http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/?include_text=1 On 28/02/13 18:06, William Mills wrote: I certainly hope so. *From:* Sergey Beryozkin sberyoz...@gmail.com *To:* William Mills wmills_92...@yahoo.com *Cc:* oauth@ietf.org oauth@ietf.org *Sent:* Thursday, February 28, 2013 10:02 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt On 28/02/13 17:49, William Mills wrote: The JWT replaces the oauth_token data element in the old MAC stuff. I just want to take all the other oauth_* variables and stuff them in a separate JSON object and completely kill the fun with sorting variables when the oauth_* things can be carried in the query string or header or post body. As far as the client accessing RS is concerned, should it be limited to using a header, same as for other OAuth2 tokens ? Cheers, Sergey *From:* Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com *To:* oauth@ietf.org mailto:oauth@ietf.org *Sent:* Thursday, February 28, 2013 9:04 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi On 28/02/13 13:14, William Mills wrote: I'm actually advocating that we change MAC to be a JWT extension. IMHO, having a simpler option, plus, going forward, a possible JWT profile (client to RS path) would work better - Why would JWT completely take over ? May be it should be possible indeed to have it as a JWT extension - should it be part of the relevant JWT assertion spec, where JWT is used as a possible grant ? Thanks, Sergey *From:* Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net *To:* William Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com *Cc:* Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net; oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org *Sent:* Thursday, February 28, 2013 2:28 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi Bill, I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the client still uses the MAC when it accesses a protected resource. The only place where the JWT comes into the picture is with the description of the access token. This matters from a key distribution point of view. The session key for the MAC is included in the encrypted JWT. The JWT is encrypted by the authorization server and decrypted by the resource server. Information about how header fields get included in the MAC is described in Section 5. The nonce isn't killed it is just called differently: seq-nr. The stuff in the original MAC specification actually wasn't a nonce (from the semantic point of view). The extension parameter is there implicitly by allowing additional header fields to be included in the MAC computation. I need to look at the port number field again. Ciao Hannes On Feb 27, 2013, at 11:12 AM, William Mills wrote: Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
I'm actually advocating that we change MAC to be a JWT extension. From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org oauth@ietf.org Sent: Thursday, February 28, 2013 2:28 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi Bill, I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the client still uses the MAC when it accesses a protected resource. The only place where the JWT comes into the picture is with the description of the access token. This matters from a key distribution point of view. The session key for the MAC is included in the encrypted JWT. The JWT is encrypted by the authorization server and decrypted by the resource server. Information about how header fields get included in the MAC is described in Section 5. The nonce isn't killed it is just called differently: seq-nr. The stuff in the original MAC specification actually wasn't a nonce (from the semantic point of view). The extension parameter is there implicitly by allowing additional header fields to be included in the MAC computation. I need to look at the port number field again. Ciao Hannes On Feb 27, 2013, at 11:12 AM, William Mills wrote: Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header. How header fields get included in the signature needs definition. Why did you kill the port number, nonce, and extension parameter out of the signature base string? The BNF appears to have no separators between values. -bill From: internet-dra...@ietf.org internet-dra...@ietf.org To: i-d-annou...@ietf.org Cc: oauth@ietf.org Sent: Monday, February 25, 2013 4:46 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-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 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-03.txt Pages : 26 Date : 2013-02-25 Abstract: This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a crytographic key by using it with a keyed message digest function to the request. The document also defines a key distribution protocol for obtaining a fresh session key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
1) AS issues JWT + secret to client. 2) Client decides to access resource, creates the JWT MAC JSON object which contains stuff about the signature and the signature itself. 3) client appends that base64 encoded thing to the JWT 1) Server gets a JWTMAC token, takes apart the JWT part to get the signing key 2) Server looks at the JWTMAC to figure out what all it has to do to create the signature base string 3) server constructs the SBS computes and checks the sig. The only hairy bit right now is an arbitrary HTTP header list that may be included in the signature. No data in the JWTMAC is duplicated from anywhere else. From: Justin Richer jric...@mitre.org To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org oauth@ietf.org Sent: Thursday, February 28, 2013 9:08 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt What I don't quite get is what exactly would be presented and processed at each step. Who needs to know what piece? We don't want to have to push everything into JSON for the signing to take place (that much is clear), and we don't want the client to be pushing the MAC secret to the RS every time (that would make it a lot less secret, after all). But if we can reuse JWT, JWS, and other JOSE mechanisms to make some parts of the MAC pattern easier for programmers, I'm for it. -- Justin On 02/28/2013 08:14 AM, William Mills wrote: I'm actually advocating that we change MAC to be a JWT extension. From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org oauth@ietf.org Sent: Thursday, February 28, 2013 2:28 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi Bill, I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the client still uses the MAC when it accesses a protected resource. The only place where the JWT comes into the picture is with the description of the access token. This matters from a key distribution point of view. The session key for the MAC is included in the encrypted JWT. The JWT is encrypted by the authorization server and decrypted by the resource server. Information about how header fields get included in the MAC is described in Section 5. The nonce isn't killed it is just called differently: seq-nr. The stuff in the original MAC specification actually wasn't a nonce (from the semantic point of view). The extension parameter is there implicitly by allowing additional header fields to be included in the MAC computation. I need to look at the port number field again. Ciao Hannes On Feb 27, 2013, at 11:12 AM, William Mills wrote: Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header. How header fields get included in the signature needs definition. Why did you kill the port number, nonce, and extension parameter out of the signature base string? The BNF appears to have no separators between values. -bill From: internet-dra...@ietf.org internet-dra...@ietf.org To: i-d-annou...@ietf.org Cc: oauth@ietf.org Sent: Monday, February 25, 2013 4:46 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-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 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-03.txt Pages : 26 Date : 2013-02-25 Abstract: This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a crytographic key by using it with a keyed message digest function to the request. The document also defines a key distribution protocol for obtaining a fresh session key. The IETF datatracker status page for this draft is: https
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
The JWT replaces the oauth_token data element in the old MAC stuff. I just want to take all the other oauth_* variables and stuff them in a separate JSON object and completely kill the fun with sorting variables when the oauth_* things can be carried in the query string or header or post body. From: Sergey Beryozkin sberyoz...@gmail.com To: oauth@ietf.org Sent: Thursday, February 28, 2013 9:04 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi On 28/02/13 13:14, William Mills wrote: I'm actually advocating that we change MAC to be a JWT extension. IMHO, having a simpler option, plus, going forward, a possible JWT profile (client to RS path) would work better - Why would JWT completely take over ? May be it should be possible indeed to have it as a JWT extension - should it be part of the relevant JWT assertion spec, where JWT is used as a possible grant ? Thanks, Sergey *From:* Hannes Tschofenig hannes.tschofe...@gmx.net *To:* William Mills wmills_92...@yahoo.com *Cc:* Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org oauth@ietf.org *Sent:* Thursday, February 28, 2013 2:28 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi Bill, I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the client still uses the MAC when it accesses a protected resource. The only place where the JWT comes into the picture is with the description of the access token. This matters from a key distribution point of view. The session key for the MAC is included in the encrypted JWT. The JWT is encrypted by the authorization server and decrypted by the resource server. Information about how header fields get included in the MAC is described in Section 5. The nonce isn't killed it is just called differently: seq-nr. The stuff in the original MAC specification actually wasn't a nonce (from the semantic point of view). The extension parameter is there implicitly by allowing additional header fields to be included in the MAC computation. I need to look at the port number field again. Ciao Hannes On Feb 27, 2013, at 11:12 AM, William Mills wrote: Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header. How header fields get included in the signature needs definition. Why did you kill the port number, nonce, and extension parameter out of the signature base string? The BNF appears to have no separators between values. -bill From: internet-dra...@ietf.org mailto:internet-dra...@ietf.org internet-dra...@ietf.org mailto:internet-dra...@ietf.org To: i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org Cc: oauth@ietf.org mailto:oauth@ietf.org Sent: Monday, February 25, 2013 4:46 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-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 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-03.txt Pages : 26 Date : 2013-02-25 Abstract: This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a crytographic key by using it with a keyed message digest function to the request. The document also defines a key distribution protocol for obtaining a fresh session key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
I certainly hope so. From: Sergey Beryozkin sberyoz...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, February 28, 2013 10:02 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt On 28/02/13 17:49, William Mills wrote: The JWT replaces the oauth_token data element in the old MAC stuff. I just want to take all the other oauth_* variables and stuff them in a separate JSON object and completely kill the fun with sorting variables when the oauth_* things can be carried in the query string or header or post body. As far as the client accessing RS is concerned, should it be limited to using a header, same as for other OAuth2 tokens ? Cheers, Sergey *From:* Sergey Beryozkin sberyoz...@gmail.com *To:* oauth@ietf.org *Sent:* Thursday, February 28, 2013 9:04 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi On 28/02/13 13:14, William Mills wrote: I'm actually advocating that we change MAC to be a JWT extension. IMHO, having a simpler option, plus, going forward, a possible JWT profile (client to RS path) would work better - Why would JWT completely take over ? May be it should be possible indeed to have it as a JWT extension - should it be part of the relevant JWT assertion spec, where JWT is used as a possible grant ? Thanks, Sergey *From:* Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net *To:* William Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com *Cc:* Hannes Tschofenig hannes.tschofe...@gmx.net mailto:hannes.tschofe...@gmx.net; oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org *Sent:* Thursday, February 28, 2013 2:28 AM *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Hi Bill, I believe you are misreading the document. In draft-ietf-oauth-v2-http-mac the client still uses the MAC when it accesses a protected resource. The only place where the JWT comes into the picture is with the description of the access token. This matters from a key distribution point of view. The session key for the MAC is included in the encrypted JWT. The JWT is encrypted by the authorization server and decrypted by the resource server. Information about how header fields get included in the MAC is described in Section 5. The nonce isn't killed it is just called differently: seq-nr. The stuff in the original MAC specification actually wasn't a nonce (from the semantic point of view). The extension parameter is there implicitly by allowing additional header fields to be included in the MAC computation. I need to look at the port number field again. Ciao Hannes On Feb 27, 2013, at 11:12 AM, William Mills wrote: Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header. How header fields get included in the signature needs definition. Why did you kill the port number, nonce, and extension parameter out of the signature base string? The BNF appears to have no separators between values. -bill From: internet-dra...@ietf.org mailto:internet-dra...@ietf.org mailto:internet-dra...@ietf.org mailto:internet-dra...@ietf.org internet-dra...@ietf.org mailto:internet-dra...@ietf.org mailto:internet-dra...@ietf.org mailto:internet-dra...@ietf.org To: i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org Cc: oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org mailto:oauth@ietf.org Sent: Monday, February 25, 2013 4:46 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-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 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-03.txt Pages : 26 Date : 2013-02-25 Abstract: This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a crytographic key by using
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header. How header fields get included in the signature needs definition. Why did you kill the port number, nonce, and extension parameter out of the signature base string? The BNF appears to have no separators between values. -bill From: internet-dra...@ietf.org internet-dra...@ietf.org To: i-d-annou...@ietf.org Cc: oauth@ietf.org Sent: Monday, February 25, 2013 4:46 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-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 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-03.txt Pages : 26 Date : 2013-02-25 Abstract: This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a crytographic key by using it with a keyed message digest function to the request. The document also defines a key distribution protocol for obtaining a fresh session key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
And also... How would the server mandate a set of header fields requiring signature? How can the server mandate a signature method or do we just stay with the two options and allow either? It might want to enforce SA-256? -bill From: William Mills wmills_92...@yahoo.com To: oauth@ietf.org oauth@ietf.org; Hannes Tschofenig hannes.tschofe...@gmx.net Sent: Wednesday, February 27, 2013 1:12 AM Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt Just read the draft quickly. Since we're now leaning on JWT do we need to include the token in this? Why not just make an additional Envelope MAC thing and have the signature include the 3 JWT parts in the signature base string? That object then just becomes a JSON container for the kid, timestamp, signature method, signature etc. That thing then is a 4th base64 encoded JSON thing in the auth header. How header fields get included in the signature needs definition. Why did you kill the port number, nonce, and extension parameter out of the signature base string? The BNF appears to have no separators between values. -bill From: internet-dra...@ietf.org internet-dra...@ietf.org To: i-d-annou...@ietf.org Cc: oauth@ietf.org Sent: Monday, February 25, 2013 4:46 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-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 Message Authentication Code (MAC) Tokens Author(s) : Justin Richer William Mills Hannes Tschofenig Filename : draft-ietf-oauth-v2-http-mac-03.txt Pages : 26 Date : 2013-02-25 Abstract: This specification describes how to use MAC Tokens in HTTP requests to access OAuth 2.0 protected resources. An OAuth client willing to access a protected resource needs to demonstrate possession of a crytographic key by using it with a keyed message digest function to the request. The document also defines a key distribution protocol for obtaining a fresh session key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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] OAuth2 attack surface....
I think this is worth a read, I don't have time to dive into this :(___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth2 attack surface....
DOH!!! http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html From: Phil Hunt phil.h...@oracle.com To: William Mills wmills_92...@yahoo.com Sent: Monday, February 25, 2013 2:28 PM Subject: Re: [OAUTH-WG] OAuth2 attack surface Whats the link? Phil Sent from my phone. On 2013-02-25, at 14:22, William Mills wmills_92...@yahoo.com wrote: I think this is worth a read, I don't have time to dive into this :( ___ 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
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does not provide. Simply stating move to HTTPS is not a viable response here. From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org Sent: Friday, February 15, 2013 7:22 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, I think one needs to compare the costs/impact of HTTPS on one side and the implementation of integrity protection and replay detection on the other. We had this discussion several times. regards, Torsten. Am 15.02.2013 um 08:08 schrieb William Mills wmills_92...@yahoo.com: I fundamentally disagree with that too. OAuth 2 is the *framework*, one which supports multiple token types. Bearer tokens were the first credential type defined. OAuth 1.0a also requires HTTPS transport for authentication and getting the token. There are real use cases for tokens usable over plain text with integrity protection. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 10:05 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, OAuth 2.0 took a different direction by relying on HTTPS to provide the basic protection. So the need to have a token, which can be used for service requests over plain HTTP is arguable. My understanding of this activity was, the intend is to provide additional protection on top of HTTPS. regards, Torsten. Am 15.02.2013 um 02:31 schrieb William Mills wmills_92...@yahoo.com: I disagree with That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place., unless solving means does not address the need for it at all. OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP. 1.0a solved that. From: Mike Jones michael.jo...@microsoft.com To: Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com Cc: IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 1:44 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 I'm in favor of reusing the JWT work that this WG is also doing. :-) I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Tuesday, February 12, 2013 9:35 AM To: Phil Hunt Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 That's my reading of it as well, Phil, thanks for providing the clarification. One motivator behind using a JSON-based token is to be able to re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload. What neither of us want is a token type that requires stuffing all query, header, and other parameters *into* the JSON object itself, which would be a more SOAPy approach. -- Justin On 02/12/2013 12:30 PM, Phil Hunt wrote: Clarification. I think Justin and I were in agreement that we don't want to see a format that requires JSON payloads. We are both interested in a JSON token used in the authorization header that could be based on a computed signature of some combination of http headers and body if possible. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote: Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * Hannes Tschofenig * Mike Jones * Antonio Sanso * Justin Richer Notes: My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt Slide #2 summarizes earlier discussions during the conference calls. -- HTTP vs. JSON Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. Phil noted that he wants to send JSON but the signature
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Exactly. And in the Flickr case replay of the same event is not a problem. Thanks for keeping me honest, work just cranked the dial up to 11.5 so I'm a bit distracted. From: Phil Hunt phil.h...@oracle.com To: William Mills wmills_92...@yahoo.com Cc: Torsten Lodderstedt tors...@lodderstedt.net; Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; IETF oauth WG oauth@ietf.org Sent: Friday, February 15, 2013 8:19 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Bill You aren't objecting to https in the as communications correct? It is the rs comms which is plain http where you want to protect the credential from theft. Even replay is not the primary issue here. Phil Sent from my phone. On 2013-02-15, at 8:09, William Mills wmills_92...@yahoo.com wrote: I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does not provide. Simply stating move to HTTPS is not a viable response here. From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org Sent: Friday, February 15, 2013 7:22 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, I think one needs to compare the costs/impact of HTTPS on one side and the implementation of integrity protection and replay detection on the other. We had this discussion several times. regards, Torsten. Am 15.02.2013 um 08:08 schrieb William Mills wmills_92...@yahoo.com: I fundamentally disagree with that too. OAuth 2 is the *framework*, one which supports multiple token types. Bearer tokens were the first credential type defined. OAuth 1.0a also requires HTTPS transport for authentication and getting the token. There are real use cases for tokens usable over plain text with integrity protection. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 10:05 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, OAuth 2.0 took a different direction by relying on HTTPS to provide the basic protection. So the need to have a token, which can be used for service requests over plain HTTP is arguable. My understanding of this activity was, the intend is to provide additional protection on top of HTTPS. regards, Torsten. Am 15.02.2013 um 02:31 schrieb William Mills wmills_92...@yahoo.com: I disagree with That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place., unless solving means does not address the need for it at all. OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP. 1.0a solved that. From: Mike Jones michael.jo...@microsoft.com To: Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com Cc: IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 1:44 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 I'm in favor of reusing the JWT work that this WG is also doing. :-) I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Tuesday, February 12, 2013 9:35 AM To: Phil Hunt Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 That's my reading of it as well, Phil, thanks for providing the clarification. One motivator behind using a JSON-based token is to be able to re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload. What neither of us want is a token type that requires stuffing all query, header, and other parameters *into* the JSON object itself, which would be a more SOAPy approach. -- Justin On 02/12/2013 12:30 PM, Phil Hunt wrote: Clarification. I think Justin and I were in agreement that we don't want to see a format that requires JSON payloads. We are both interested in a JSON token used in the authorization header that could be based on a computed signature of some combination of http headers and body if possible. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-02-12, at 1:10 AM
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
At this point I am more in favor converting the MAC token format to JWT and getting the signature envelope added that way. It's really a matter of time. MAC stalled because folks see the HOK tokens as a replacement. It's also been a matter of Justin and I having the time to take it up again. From: Sergey Beryozkin sberyoz...@gmail.com To: oauth@ietf.org Sent: Friday, February 15, 2013 8:25 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 I wonder why it is proving so difficult to get a nearly completed MAC draft completed ? Is it because: 1. JWT was first in OAuth2 and thus it wins ? 2. MAC is not 'capable' enough as JWT is ? 3. Not enough motivation for some vendors to push MAC ? Example, in cases where not a product but a development framework is shipped (as with us for example), IMHO is it a big motivation to get MAC done for the reasons repeated many times. Or in case of migrating Flickr users to OAuth2. I think I can see why no interest is there where nothing is really achieved if JWT is used from the get go, no particular need to get OAuth 1.0 developers out there migrating to the particular products. This is 3. Re 2, I think there was enough expressed to suggest that it can complement JWT nicely. So far I'm inclined to think it is 3. and 2. which stop it from being completed, with 3. 'contributing' indirectly but significantly, Just my 2c Thanks, Sergey On 15/02/13 16:09, William Mills wrote: I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does not provide. Simply stating move to HTTPS is not a viable response here. *From:* Torsten Lodderstedt tors...@lodderstedt.net *To:* William Mills wmills_92...@yahoo.com *Cc:* Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org *Sent:* Friday, February 15, 2013 7:22 AM *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, I think one needs to compare the costs/impact of HTTPS on one side and the implementation of integrity protection and replay detection on the other. We had this discussion several times. regards, Torsten. Am 15.02.2013 um 08:08 schrieb William Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com: I fundamentally disagree with that too. OAuth 2 is the *framework*, one which supports multiple token types. Bearer tokens were the first credential type defined. OAuth 1.0a also requires HTTPS transport for authentication and getting the token. There are real use cases for tokens usable over plain text with integrity protection. -bill *From:* Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net *To:* William Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com *Cc:* Mike Jones michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com; Justin Richer jric...@mitre.org mailto:jric...@mitre.org; Phil Hunt phil.h...@oracle.com mailto:phil.h...@oracle.com; IETF oauth WG oauth@ietf.org mailto:oauth@ietf.org *Sent:* Thursday, February 14, 2013 10:05 PM *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, OAuth 2.0 took a different direction by relying on HTTPS to provide the basic protection. So the need to have a token, which can be used for service requests over plain HTTP is arguable. My understanding of this activity was, the intend is to provide additional protection on top of HTTPS. regards, Torsten. Am 15.02.2013 um 02:31 schrieb William Mills wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com: I disagree with That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place., unless solving means does not address the need for it at all. OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP. 1.0a solved that. *From:* Mike Jones michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com *To:* Justin Richer jric...@mitre.org mailto:jric...@mitre.org; Phil Hunt phil.h...@oracle.com mailto:phil.h...@oracle.com *Cc:* IETF oauth WG oauth@ietf.org mailto:oauth@ietf.org *Sent:* Thursday, February 14, 2013 1:44 PM *Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 I'm in favor of reusing the JWT work that this WG is also doing. :-) I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place. -- Mike -Original Message- From
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Because we're goign to want a single implementation, not N. From: Tim Bray twb...@google.com To: William Mills wmills_92...@yahoo.com Cc: Torsten Lodderstedt tors...@lodderstedt.net; IETF oauth WG oauth@ietf.org Sent: Friday, February 15, 2013 8:49 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Not deeply acquainted with the Flickr scenario, but it occurs to me to ask: If OAuth 1.0 is working well for them, why don’t they just keep using it? I.e. if there’s already a good solution in place for people who require secure authn/authz over insecure channels, why would we go the extra work of duplicating that in OAuth 2 territory? -T On Fri, Feb 15, 2013 at 8:09 AM, William Mills wmills_92...@yahoo.com wrote: I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites that OAuth 2 does not provide. Simply stating move to HTTPS is not a viable response here. From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org Sent: Friday, February 15, 2013 7:22 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, I think one needs to compare the costs/impact of HTTPS on one side and the implementation of integrity protection and replay detection on the other. We had this discussion several times. regards, Torsten. Am 15.02.2013 um 08:08 schrieb William Mills wmills_92...@yahoo.com: I fundamentally disagree with that too. OAuth 2 is the *framework*, one which supports multiple token types. Bearer tokens were the first credential type defined. OAuth 1.0a also requires HTTPS transport for authentication and getting the token. There are real use cases for tokens usable over plain text with integrity protection. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com; IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 10:05 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, OAuth 2.0 took a different direction by relying on HTTPS to provide the basic protection. So the need to have a token, which can be used for service requests over plain HTTP is arguable. My understanding of this activity was, the intend is to provide additional protection on top of HTTPS. regards, Torsten. Am 15.02.2013 um 02:31 schrieb William Mills wmills_92...@yahoo.com: I disagree with That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place., unless solving means does not address the need for it at all. OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP. 1.0a solved that. From: Mike Jones michael.jo...@microsoft.com To: Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com Cc: IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 1:44 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 I'm in favor of reusing the JWT work that this WG is also doing. :-) I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Tuesday, February 12, 2013 9:35 AM To: Phil Hunt Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 That's my reading of it as well, Phil, thanks for providing the clarification. One motivator behind using a JSON-based token is to be able to re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload. What neither of us want is a token type that requires stuffing all query, header, and other parameters *into* the JSON object itself, which would be a more SOAPy approach. -- Justin On 02/12/2013 12:30 PM, Phil Hunt wrote: Clarification. I think Justin and I were in agreement that we don't want to see a format that requires JSON payloads. We are both interested in a JSON token used in the authorization header that could be based on a computed signature of some combination of http headers and body if possible. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote: Here are my notes. Participants: * John
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
I disagree with That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place., unless solving means does not address the need for it at all. OAuth 2 does several good things, but it still lacks a defined token type that is safe to user over plain text HTTP. 1.0a solved that. From: Mike Jones michael.jo...@microsoft.com To: Justin Richer jric...@mitre.org; Phil Hunt phil.h...@oracle.com Cc: IETF oauth WG oauth@ietf.org Sent: Thursday, February 14, 2013 1:44 PM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 I'm in favor of reusing the JWT work that this WG is also doing. :-) I'm pretty skeptical of us inventing another custom scheme for signing HTTP headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved in the first place. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Tuesday, February 12, 2013 9:35 AM To: Phil Hunt Cc: IETF oauth WG Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 That's my reading of it as well, Phil, thanks for providing the clarification. One motivator behind using a JSON-based token is to be able to re-use some of the great work that the JOSE group is doing but apply it to an HTTP payload. What neither of us want is a token type that requires stuffing all query, header, and other parameters *into* the JSON object itself, which would be a more SOAPy approach. -- Justin On 02/12/2013 12:30 PM, Phil Hunt wrote: Clarification. I think Justin and I were in agreement that we don't want to see a format that requires JSON payloads. We are both interested in a JSON token used in the authorization header that could be based on a computed signature of some combination of http headers and body if possible. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote: Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * Hannes Tschofenig * Mike Jones * Antonio Sanso * Justin Richer Notes: My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt Slide #2 summarizes earlier discussions during the conference calls. -- HTTP vs. JSON Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field. -- Flexibility for the keyed message digest computation From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4. After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content. -- Key Distribution Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he the n a gain needs to understand) in order to make a meaningful authorization decision. Everyone agreed that the client must receive the session key from the authorization server and that this approach has to be standardized. It was also agreed that this is a common approach among all three key distribution mechanisms. Hannes
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
You have a trust relationship with the user and perhaps with the client. From: Prateek Mishra prateek.mis...@oracle.com To: oauth@ietf.org Sent: Wednesday, February 13, 2013 8:13 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hannes, 1) Its not clear to me that we need to specify exchanges between the AS and the RS as part of this work. The core specification leaves this unspecified. There could be many different ways that the AS and RS collaborate to validate signatures in messages received from the client. 2) Regarding (symmetric) key distribution, dont we need some kind of existing trust relationship between the client and AS to make this possible? I guess it would be enough to require use of a confidential client, that would make it possible for the two parties to agree on a session key at the point where an access token is issued by the AS. 3) I think do need an MTI key distribution protocol as part of the specification, leaving that as a choice would hurt interoperability. - prateek Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * Hannes Tschofenig * Mike Jones * Antonio Sanso * Justin Richer Notes: My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt Slide #2 summarizes earlier discussions during the conference calls. -- HTTP vs. JSON Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field. -- Flexibility for the keyed message digest computation From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4. After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content. -- Key Distribution Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he then a gain needs to understand) in order to make a meaningful authorization decision. Everyone agreed that the client must receive the session key from the authorization server and that this approach has to be standardized. It was also agreed that this is a common approach among all three key distribution mechanisms. Hannes asked the participants to think about their preference. The questions regarding key naming and the indication for the intended resource server the client wants to talk to have been postponed. Ciao Hannes ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
Is key distribution how AS and PR share keys for token encryption/decryption or specifically about the keys for the HOK tokens? For the MAC token spec, I don't actually care whether we use JSON or now, but I'm in full agreement that we do NOT duplicate any HTTP info into the JSON. Just signatures of that stuff. From: Hannes Tschofenig hannes.tschofe...@gmx.net To: IETF oauth WG oauth@ietf.org Sent: Tuesday, February 12, 2013 1:10 AM Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * Hannes Tschofenig * Mike Jones * Antonio Sanso * Justin Richer Notes: My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt Slide #2 summarizes earlier discussions during the conference calls. -- HTTP vs. JSON Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field. -- Flexibility for the keyed message digest computation From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4. After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content. -- Key Distribution Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he then a gain needs to understand) in order to make a meaningful authorization decision. Everyone agreed that the client must receive the session key from the authorization server and that this approach has to be standardized. It was also agreed that this is a common approach among all three key distribution mechanisms. Hannes asked the participants to think about their preference. The questions regarding key naming and the indication for the intended resource server the client wants to talk to have been postponed. Ciao Hannes ___ 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
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
For key exchange that's true for symmetric key, but no key exchange is required for public key signing by the client. There's so many possibilities here, but I think the best is that the key materiel is conveyed in the token. The key could be included directly, or another way to implement would be that a salt is included in the token and then the secret is some crypto hash of the token contents and a shared secret between the AS and the PR. If we we must pick one I'd say include the signing key as part of the encrypted token itself. Completely self contained then. From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; IETF oauth WG oauth@ietf.org Sent: Tuesday, February 12, 2013 1:44 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Hi Bill, On Feb 12, 2013, at 11:27 AM, William Mills wrote: Is key distribution how AS and PR share keys for token encryption/decryption or specifically about the keys for the HOK tokens? In order for the client to compute the keyed message digest it needs to have the session key. This session key is sent from the authorization server to the client and everyone on the call agreed that this has to be standardized. The resource server who receives the message from the client also needs to have the session key to verify the message. How the resource server obtains this session key was subject for some discussion on the call. I presented three different ways of how the resource server is able to obtain that key. We have to decide on one mandatory-to-implement mechanism. The open issue is which one? For the MAC token spec, I don't actually care whether we use JSON or now, but I'm in full agreement that we do NOT duplicate any HTTP info into the JSON. Just signatures of that stuff. I believe the folks on the call also agreed with you on that aspect that the content of the HTTP message should not be replicated in the JSON payload itself. Ciao Hannes From: Hannes Tschofenig hannes.tschofe...@gmx.net To: IETF oauth WG oauth@ietf.org Sent: Tuesday, February 12, 2013 1:10 AM Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * Hannes Tschofenig * Mike Jones * Antonio Sanso * Justin Richer Notes: My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt Slide #2 summarizes earlier discussions during the conference calls. -- HTTP vs. JSON Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field. -- Flexibility for the keyed message digest computation From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4. After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content. -- Key Distribution Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0 framework, be entities produced by different vendors there is an interoperability need. Justin responded that he disagrees and that the resource server needs to understand the access token and referred to the recent draft submission for the token introspection endpoint. Derek indicated that the resource server has to understand the content of the access token and the token introspection endpoint just pushes the problem around: the resource server has to send the access token to the authorization server and then the resource server gets the result back (which he then a gain needs to understand) in order to make a meaningful
Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013
One of the things I do not like about a MTI key transport mechanism if we put it in the token is that there will be some systems that already have a per user secret provisioned and we'll be forcing data duplication. If if the encrypted token already includes any random component that could easily be used as part of the signing key. So I feel like this will fatten up the token, potentially a lot. If we don't put it in the token this problem is WAY harder. From: Hannes Tschofenig hannes.tschofe...@gmx.net To: Antonio Sanso asa...@adobe.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; William Mills wmills_92...@yahoo.com; IETF oauth WG oauth@ietf.org Sent: Tuesday, February 12, 2013 3:06 AM Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 The transport of the session key from the authorization server is described in Section 5.1 and is called mac_key. The mechanism to transport the session key from the authorization server to the resource server is not yet described in the document. This has historical reasons: OAuth 1.0 did not separate the authorization server from the resource server in the way OAuth 2.0 does. Ciao Hannes On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote: Hi Hannes, how this session key differs from the key described in the current draft [0]? Thanks and regards Antonio [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote: Hi Bill, On Feb 12, 2013, at 11:27 AM, William Mills wrote: Is key distribution how AS and PR share keys for token encryption/decryption or specifically about the keys for the HOK tokens? In order for the client to compute the keyed message digest it needs to have the session key. This session key is sent from the authorization server to the client and everyone on the call agreed that this has to be standardized. The resource server who receives the message from the client also needs to have the session key to verify the message. How the resource server obtains this session key was subject for some discussion on the call. I presented three different ways of how the resource server is able to obtain that key. We have to decide on one mandatory-to-implement mechanism. The open issue is which one? For the MAC token spec, I don't actually care whether we use JSON or now, but I'm in full agreement that we do NOT duplicate any HTTP info into the JSON. Just signatures of that stuff. I believe the folks on the call also agreed with you on that aspect that the content of the HTTP message should not be replicated in the JSON payload itself. Ciao Hannes From: Hannes Tschofenig hannes.tschofe...@gmx.net To: IETF oauth WG oauth@ietf.org Sent: Tuesday, February 12, 2013 1:10 AM Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013 Here are my notes. Participants: * John Bradley * Derek Atkins * Phil Hunt * Prateek Mishra * Hannes Tschofenig * Mike Jones * Antonio Sanso * Justin Richer Notes: My slides are available here: http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt Slide #2 summarizes earlier discussions during the conference calls. -- HTTP vs. JSON Phil noted that he does not like to use the MAC Token draft as a starting point because it does not re-use any of the work done in the JOSE working group and in particular all the libraries that are available today. He mentioned that earlier attempts to write the MAC Token code lead to problems for implementers. Justin responded that he does not agree with using JSON as a transport mechanism since this would replicate a SOAP style. Phil noted that he wants to send JSON but the signature shall be computed over the HTTP header field. -- Flexibility for the keyed message digest computation From earlier discussion it was clear that the conference call participants wanted more flexibility regarding the keyed message digest computation. For this purpose Hannes presented the DKIM based approach, which allows selective header fields to be included in the digest. This is shown in slide #4. After some discussion the conference call participants thought that this would meet their needs. Further investigations would still be useful to determine the degree of failed HMAC calculations due to HTTP proxies modifying the content. -- Key Distribution Hannes presented the open issue regarding the choice of key distribution. Slides #6-#8 present three techniques and Hannes asked for feedback regarding the preferred style. Justin and others didn't see the need to decide on one mechanism - they wanted to keep the choice open. Derek indicated that this will not be an acceptable approach. Since the resource server and the authorization server may, in the OAuth 2.0
Re: [OAUTH-WG] A question on token revocation.
+1 From: Prabath Siriwardena prab...@wso2.com To: Todd W Lainhart lainh...@us.ibm.com Cc: oauth@ietf.org WG oauth@ietf.org; oauth-boun...@ietf.org Sent: Wednesday, February 6, 2013 7:04 AM Subject: Re: [OAUTH-WG] A question on token revocation. On Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart lainh...@us.ibm.com wrote: There can be cases where resource owner needs to revoke an authorized access token from a given client. Why wouldn't the RO go through the client to revoke the token? RO needs not to go through the client to revoke. Resource owner should have the capability to revoke an acces token by client. Thanks regards, -Prabath Todd Lainhart Rational software IBM Corporation 550 King Street, Littleton, MA 01460-1250 1-978-899-4705 2-276-4705 (T/L) lainh...@us.ibm.com From: Prabath Siriwardena prab...@wso2.com To: oauth@ietf.org WG oauth@ietf.org, Date: 02/06/2013 04:36 AM Subject: [OAUTH-WG] A question on token revocation. Sent by: oauth-boun...@ietf.org I am sorry if this was already discussed in this list.. Looking at [1] it only talks about revoking the access token from the client. How about the resource owner..? There can be cases where resource owner needs to revoke an authorized access token from a given client. Or revoke an scope.. How are we going to address these requirements..? Thoughts appreciated... [1] http://tools.ietf.org/html/draft-ietf-oauth-revocation-04 -- Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com ___ 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
Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests
Yes, MAC relies on SSL for transport security. But you have bigger problems than that if SSL is broken, because your primary authentication credential is compromised now. Do we need to address sslstrip here if it's a general attack on SSL transport for the browser? From: Prabath Siriwardena prab...@wso2.com To: William Mills wmills_92...@yahoo.com Cc: L. Preston Sego III lpse...@gmail.com; oauth@ietf.org oauth@ietf.org Sent: Wednesday, February 6, 2013 8:23 AM Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests On Mon, Feb 4, 2013 at 9:57 PM, William Mills wmills_92...@yahoo.com wrote: There are two efforts at signed token types: MAC which is still a possibility if we wake up and do it, and the Holder Of Key type tokens. If someone can use sslstrip then even MAC is not safe - since MAC key needs to be transferred over SSL to the Client from the AS. There are standard ways in HTTP to avoid or protect from sslstrip - IMHO we need to occupy those best practices... Thanks regards, -Prabath There are a lot of folks that agree with you. From: L. Preston Sego III lpse...@gmail.com To: oauth@ietf.org Sent: Friday, February 1, 2013 7:37 AM Subject: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests In an oauth2 request, the access token is passed along in the header, with nothing else. As I understand it, oauth2 was designed to be simple for everyone to use. And while, that's true, I don't really like how all of the security is reliant on SSL. what if an attack can strip away SSL using a tool such as sslstrip (or whatever else would be more suitable for modern https)? They would be able to see the access token and start forging whatever request he or she wants to. Why not do some sort of RSA-type public-private key thing like back in Oauth1, where there is verification of the payload on each request? Just use a better algorithm? ___ 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 -- Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
There are some specific design mis-matches for OAuth as an authentication protocol, it's not what it's designed for and there are some problems you will run into. Some have used it as such, but it's not a good general solution. -bill From: Paul Madsen paul.mad...@gmail.com To: John Bradley ve7...@ve7jtb.com Cc: oauth@ietf.org WG oauth@ietf.org Sent: Tuesday, February 5, 2013 1:12 PM Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ? why pigeonhole it? OAuth can be deployed with no authz semantics at all (or at least as little as any authn mechanism), e.g client creds grant type with no scopes I agree that OAuth is not an *SSO* protocol. On 2/5/13 3:36 PM, John Bradley wrote: OAuth is an Authorization protocol as many of us have pointed out. The post is largely correct and based on one of mine. John B. On 2013-02-05, at 12:52 PM, Prabath Siriwardena prab...@wso2.com wrote: FYI and for your comments.. http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com/ http://rampartfaq.com/ ___ 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 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
Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ?
Why use OAuth when OpenID does everything that OAuth can do as an authentication method and does a few things much better? Specifically OAuth lacks any defined way to: -feed back any additional information like the real user ID (as opposed to what the entered) -bound an authentication event in time -provide any form of additional SSO payload like a display name for the user there's probably other things. It'll mostly work but there are things it doesn't do. Could you solve some of the rest of this with token introspection or a user API that the RP could use to fetch user info, sure, but why rebuild OpenID when OpenID exists? -bill From: Lewis Adam-CAL022 adam.le...@motorolasolutions.com To: Tim Bray twb...@google.com; William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org WG oauth@ietf.org Sent: Tuesday, February 5, 2013 2:27 PM Subject: RE: [OAUTH-WG] Why OAuth it self is not an authentication framework ? I think this is becoming a largely academic / philosophical argument by this time. The people who designed OAuth will likely point out that it was conceptualized as an authorization protocol to enable a RO to delegate access to a client to access its protected resources on some RS. And of course this is the history of it. And the RO and end-user were typically the same entity. But get caught up in what it was envisioned to do vs. real life use cases that OAuth can solve (and is solving) beyond its initial use cases misses the point … because OAuth is gaining traction in the enterprise and will be used in all different sorts of ways, including authentication. This is especially true of RESTful APIs within an enterprise where the RO and end-user are *not* the same: e.g. RO=enterprise and end-user=employee. In this model the end-user is not authorizing anything when their client requests a token from the AS … they authenticate to the AS and the client gets an AT, which will likely be profiled by most enterprise deployments to look something like an OIDC id_token. The AT will be presented to the RS which will examine the claims (user identity, LOA, etc.) and make authorization decisions based on business logic. The AT has not authorized the user to do anything, it has only made an assertion that the user has been authenticated by the AS (sort of sounds a lot like an IdP now). All this talked of OAuth being authorization and not authentication was extremely confusing to me when I first started looking at OAuth for my use cases, and I think at some point the authors of OAuth are going to have to recognize that their baby has grown up to be multi-faceted (and I mean this as a complement). The abstractions left in the OAuth spec (while some have claimed of the lack of interoperability it will cause) will also enable it to be used in ways possibly still not envisioned by any of us. I think as soon as we can stop trying to draw the artificial line around OAuth being “an authorization protocol” the better things will be. I like to say that they authors had it right when they named it “OAuth” and not “OAuthR” J -adam From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tim Bray Sent: Tuesday, February 05, 2013 3:28 PM To: William Mills Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ? OIDC seems about the most plausible candidate for a “good general solution” that I’m aware of. -T On Tue, Feb 5, 2013 at 1:22 PM, William Mills wmills_92...@yahoo.com wrote: There are some specific design mis-matches for OAuth as an authentication protocol, it's not what it's designed for and there are some problems you will run into. Some have used it as such, but it's not a good general solution. -bill From:Paul Madsen paul.mad...@gmail.com To: John Bradley ve7...@ve7jtb.com Cc: oauth@ietf.org WG oauth@ietf.org Sent: Tuesday, February 5, 2013 1:12 PM Subject: Re: [OAUTH-WG] Why OAuth it self is not an authentication framework ? why pigeonhole it? OAuth can be deployed with no authz semantics at all (or at least as little as any authn mechanism), e.g client creds grant type with no scopes I agree that OAuth is not an *SSO* protocol. On 2/5/13 3:36 PM, John Bradley wrote: OAuth is an Authorization protocol as many of us have pointed out. The post is largely correct and based on one of mine. John B. On 2013-02-05, at 12:52 PM, Prabath Siriwardena prab...@wso2.com wrote: FYI and for your comments.. http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com/ http://rampartfaq.com/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https
Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests
There are two efforts at signed token types: MAC which is still a possibility if we wake up and do it, and the Holder Of Key type tokens. There are a lot of folks that agree with you. From: L. Preston Sego III lpse...@gmail.com To: oauth@ietf.org Sent: Friday, February 1, 2013 7:37 AM Subject: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests In an oauth2 request, the access token is passed along in the header, with nothing else. As I understand it, oauth2 was designed to be simple for everyone to use. And while, that's true, I don't really like how all of the security is reliant on SSL. what if an attack can strip away SSL using a tool such as sslstrip (or whatever else would be more suitable for modern https)? They would be able to see the access token and start forging whatever request he or she wants to. Why not do some sort of RSA-type public-private key thing like back in Oauth1, where there is verification of the payload on each request? Just use a better algorithm? ___ 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] conf call follow up from today
1) I think that we need to focus on specific solutions, as I said on the call, and solve the OAuth 1.0a/MAC use case. There's significant installed base of OAuth 1.0a and we need a path for those installations into OAuth 2.0. I may well pursue MAC in the interim to do this, but a full HOK solution woul work too. 2) I think the discussion we were having about which authenticator to use falls squarely into the endpoint discovery discussion and we should put that energy into endpoint discovery as distinct from HOK. 3) We haven't talked yet about how a client will be able to specify a token type if it wants a specific one. OAuth 2 core will need to be extended to support this. 4) We should leave the key distribution/discovery mechanism either out of scope or define it explicitly per HOK token type profile. This will have to work with the extensions for #3 above. 5) I want to avoid the problem in OAuth 1.0a of having to support and accept every possible signing mode. Being force to accept PLAINTEXT sucks. We need a way for the discovery endpoint to mandate a specific set of allowed signature methods. Regards, -bill ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] conf call follow up from today
OAuth 1.0a solves ordering problems there but not additional data being added to the specific headers. It specifically requires the library to break apart, sort, and reassemble in a alphabetical order by name the query string parameters and oauth_* parameters. One of the less popular things about it. From: Prateek Mishra prateek.mis...@oracle.com To: oauth@ietf.org; William Mills wmills_92...@yahoo.com Sent: Monday, February 4, 2013 1:28 PM Subject: Re: [OAUTH-WG] conf call follow up from today Bill - How does OAuth 1.0a deal with the problem of HTTP URL and header mutability? Header order may get re-arranged and URLs modified in transit from client to server. As a result, the signature/HMAC might not validate at the final destination. Isn't that a foundational problem with the OAuth 1.0a model? I thought that was one of the concerns expressed at the meeting today. - prateek 1) I think that we need to focus on specific solutions, as I said on the call, and solve the OAuth 1.0a/MAC use case. There's significant installed base of OAuth 1.0a and we need a path for those installations into OAuth 2.0. I may well pursue MAC in the interim to do this, but a full HOK solution woul work too. 2) I think the discussion we were having about which authenticator to use falls squarely into the endpoint discovery discussion and we should put that energy into endpoint discovery as distinct from HOK. 3) We haven't talked yet about how a client will be able to specify a token type if it wants a specific one. OAuth 2 core will need to be extended to support this. 4) We should leave the key distribution/discovery mechanism either out of scope or define it explicitly per HOK token type profile. This will have to work with the extensions for #3 above. 5) I want to avoid the problem in OAuth 1.0a of having to support and accept every possible signing mode. Being force to accept PLAINTEXT sucks. We need a way for the discovery endpoint to mandate a specific set of allowed signature methods. Regards, -bill ___ 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
Re: [OAUTH-WG] conf call follow up from today
We can do that too, and I rather like it. I thought there was a big don't cross the beams warning somewhere though. -bill From: Richer, Justin P. jric...@mitre.org To: William Mills wmills_92...@yahoo.com Cc: O Auth WG oauth@ietf.org Sent: Monday, February 4, 2013 1:37 PM Subject: Re: [OAUTH-WG] conf call follow up from today What if we define a means to request OAuth1 style tokens from an OAuth2 auth/token endpoint, but defer to OAuth1 for methods of how to use the token at protected resources? -- Justin On Feb 4, 2013, at 3:22 PM, William Mills wmills_92...@yahoo.com wrote: 1) I think that we need to focus on specific solutions, as I said on the call, and solve the OAuth 1.0a/MAC use case. There's significant installed base of OAuth 1.0a and we need a path for those installations into OAuth 2.0. I may well pursue MAC in the interim to do this, but a full HOK solution woul work too. 2) I think the discussion we were having about which authenticator to use falls squarely into the endpoint discovery discussion and we should put that energy into endpoint discovery as distinct from HOK. 3) We haven't talked yet about how a client will be able to specify a token type if it wants a specific one. OAuth 2 core will need to be extended to support this. 4) We should leave the key distribution/discovery mechanism either out of scope or define it explicitly per HOK token type profile. This will have to work with the extensions for #3 above. 5) I want to avoid the problem in OAuth 1.0a of having to support and accept every possible signing mode. Being force to accept PLAINTEXT sucks. We need a way for the discovery endpoint to mandate a specific set of allowed signature methods. Regards, -bill ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-revocation
Why do we need invalid_token as an error code at all? To me it only introduces a way to get information about tokens. Invalid parameter I can see as a use case, but if the token is invalid just return 200/OK because there is nothing to do. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: OAuth WG oauth@ietf.org Sent: Sunday, February 3, 2013 5:01 AM Subject: [OAUTH-WG] draft-ietf-oauth-revocation Hi all, before I publish a new revision of the draft, I would like to sort out the following issues and would like to ask you for your feedback. - Authorization vs. access grant vs. authorization grant: I propose to use authorization grant. - invalid_token error code: I propose to use the new error code invalid_parameter (as suggested by Peter and George). I don't see the need to register it (see http://www.ietf.org/mail-archive/web/oauth/current/msg10604.html) but would like to get your advice. - Donald F. Coffin raised the need for a token_type parameter to the revocation request. Shall we re-consider this topic? best regards, Torsten. ___ 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
Re: [OAUTH-WG] Where / how do we report security risks?
Here is probably your best bet if it's a design question. If it's a specific implementation then send it to the company in question first if you think they have a vulnerability. From: L. Preston Sego III lpse...@gmail.com To: oauth@ietf.org Sent: Thursday, January 31, 2013 6:01 AM Subject: [OAUTH-WG] Where / how do we report security risks? Don't want hackers to try anything on oauth2-using applications... ___ 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
Re: [OAUTH-WG] Client cannot specify the token type it needs
This is true. It's possible for the AS to vary it's behavior on scope name, but it's presumed the AS and RS have an agreement of what token type is in play. Likely a good extension to the spec. From: Prabath Siriwardena prab...@wso2.com To: oauth@ietf.org WG oauth@ietf.org Sent: Sunday, January 20, 2013 7:28 PM Subject: [OAUTH-WG] Client cannot specify the token type it needs Although token type is extensible according to the OAuth core specification - it is fully governed by the Authorization Server. There can be a case where a single AS supports multiple token types based on client request. But currently we don't have a way the client can specify (or at least suggest) which token type it needs in the OAuth access token request ? Is this behavior intentional ? or am I missing something... Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com ___ 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
Re: [OAUTH-WG] Client cannot specify the token type it needs
Not a problem for the client to request a type, but it may not get it. From: zhou.suj...@zte.com.cn zhou.suj...@zte.com.cn To: Prabath Siriwardena prab...@wso2.com Cc: oauth@ietf.org WG oauth@ietf.org; William Mills wmills_92...@yahoo.com Sent: Sunday, January 20, 2013 9:38 PM Subject: Re: Re: Re: [OAUTH-WG] Client cannot specify the token type it needs Well, if RS could specify token type, then Client could transfer it to AS, I think, but it is not a good idea for client itself to specify the token type. Prabath Siriwardena prab...@wso2.com 写于 2013-01-21 13:29:05: Think about a distributed setup. You have single Authorization Server and multiple Resource Servers. Although OAuth nicely decouples AS from RS - AFAIK there is no standard established for communication betweens AS and RS - how to declare metadata between those. Also there can be Resource Servers which support multiple token types. It could vary on APIs hosted in a given RS. Thanks regards, -Prabath On Mon, Jan 21, 2013 at 10:48 AM, zhou.suj...@zte.com.cn wrote: The token type shoulbe decided by resource server, which consumes access token. Client just re-tell the requested token type to AS. Client should not specify the token type. oauth-boun...@ietf.org 写于 2013-01-21 13:08:39: This is true. It's possible for the AS to vary it's behavior on scope name, but it's presumed the AS and RS have an agreement of what token type is in play. Likely a good extension to the spec. From: Prabath Siriwardena prab...@wso2.com To: oauth@ietf.org WG oauth@ietf.org Sent: Sunday, January 20, 2013 7:28 PM Subject: [OAUTH-WG] Client cannot specify the token type it needs Although token type is extensible according to the OAuth core specification - it is fully governed by the Authorization Server. There can be a case where a single AS supports multiple token types based on client request. But currently we don't have a way the client can specify (or at least suggest) which token type it needs in the OAuth access tokenrequest ? Is this behavior intentional ? or am I missing something... Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com ___ 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 -- Thanks Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] December 27, 2012 OAuth Release
It's the core problem I see MAC solving. I'd be happy enough to define a JWT variant that does this if that's easier than MAC. What do you think? From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 4, 2013 2:35 PM Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release There’s no generic OAuth way to do this. There is a way to do it in OpenID Connect – see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_algin http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supportedin http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9. -- Mike From:William Mills [mailto:wmills_92...@yahoo.com] Sent: Friday, December 28, 2012 6:07 PM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release Mike, I've read through the JWT spec and I'm curious about something. How do I specify a signature requirement as the server? I didn't see it but I probably just missed it. I'm thinking that with very little work a JWT can do everything that MAC does with greater flexibility, *BUT* the server needs to be able to require a signed usage. Something I never liked about OAuth 1.0 is that the server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that. It would require the client to be able to include client generated stuff in the JWT. Thanks, -bill___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth 2 fun... for some values of fun.
FYI http://prosecco.gforge.inria.fr/CVE/Facebook_JS_2012.html As a part of our study of various security critical Javascript SDKs we did an analysis of the Facebook Connect JS SDK. Since they use HTML5 based PostMessage API we were specifically interested in the way the origins were validated. We managed to bypass the origin validation by exploiting 3 different bugs in their SDK. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] December 27, 2012 OAuth Release
Yeah, I think it would work. Adding client asserted JWT payload would also nicely get out of the whole question of where the nonce, timestamp, and such go and whether they can be part of the query string, which was always annoying with MAC and OAuth 1. We still have the problem that some clients don't know what order the query or post arguments will be generated in, but that wasn't resolved yet anyway. How do we solve for the server requiring a specific set of supported hashes and feeding that back to the client? -bill From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 4, 2013 3:44 PM Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release If everything you want to sign can go in the JWT there is nothing to stop that. Otherwise you are back to coming up with a way of doing a detached signature and putting a hash in the JWT like connect is doing by putting a hash of the token in the id_token for the token id_token} flow. The hard part is figuring out what needs to be signed. As for client generated JWT we already have the JWT assertion profile. Connect is using that as an option to authenticate to the token endpoint. Would doing a similar thing but to the RS really work for you? John B. On 2013-01-04, at 7:48 PM, William Mills wmills_92...@yahoo.com wrote: It's the core problem I see MAC solving. I'd be happy enough to define a JWT variant that does this if that's easier than MAC. What do you think? From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 4, 2013 2:35 PM Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release There’s no generic OAuth way to do this. There is a way to do it in OpenID Connect – see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_algin http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supportedin http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9. -- Mike From:William Mills [mailto:wmills_92...@yahoo.com] Sent: Friday, December 28, 2012 6:07 PM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release Mike, I've read through the JWT spec and I'm curious about something. How do I specify a signature requirement as the server? I didn't see it but I probably just missed it. I'm thinking that with very little work a JWT can do everything that MAC does with greater flexibility, *BUT* the server needs to be able to require a signed usage. Something I never liked about OAuth 1.0 is that the server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that. It would require the client to be able to include client generated stuff in the JWT. Thanks, -bill ___ 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
Re: [OAUTH-WG] December 27, 2012 OAuth Release
That would work. Register a link relation property for supported signing methods. From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 4, 2013 4:09 PM Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release In the Connect case part of discovery is a JSON document in .well-known that describes the servers capabilities. Something similar might work. There is nothing JWT specific about the connect document though we do specify the JWA set of algorithms and JWK for publishing keys. John On 2013-01-04, at 8:57 PM, William Mills wmills_92...@yahoo.com wrote: Yeah, I think it would work. Adding client asserted JWT payload would also nicely get out of the whole question of where the nonce, timestamp, and such go and whether they can be part of the query string, which was always annoying with MAC and OAuth 1. We still have the problem that some clients don't know what order the query or post arguments will be generated in, but that wasn't resolved yet anyway. How do we solve for the server requiring a specific set of supported hashes and feeding that back to the client? -bill From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 4, 2013 3:44 PM Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release If everything you want to sign can go in the JWT there is nothing to stop that. Otherwise you are back to coming up with a way of doing a detached signature and putting a hash in the JWT like connect is doing by putting a hash of the token in the id_token for the token id_token} flow. The hard part is figuring out what needs to be signed. As for client generated JWT we already have the JWT assertion profile. Connect is using that as an option to authenticate to the token endpoint. Would doing a similar thing but to the RS really work for you? John B. On 2013-01-04, at 7:48 PM, William Mills wmills_92...@yahoo.com wrote: It's the core problem I see MAC solving. I'd be happy enough to define a JWT variant that does this if that's easier than MAC. What do you think? From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 4, 2013 2:35 PM Subject: RE: [OAUTH-WG] December 27, 2012 OAuth Release There’s no generic OAuth way to do this. There is a way to do it in OpenID Connect – see request_object_signing_alg, userinfo_signed_response_alg, and id_token_signed_response_algin http://openid.net/specs/openid-connect-registration-1_0-13.html#anchor3 and userinfo_signing_alg_values_supported, id_token_signing_alg_values_supported, and request_object_signing_alg_values_supportedin http://openid.net/specs/openid-connect-discovery-1_0-11.html#anchor9. -- Mike From:William Mills [mailto:wmills_92...@yahoo.com] Sent: Friday, December 28, 2012 6:07 PM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release Mike, I've read through the JWT spec and I'm curious about something. How do I specify a signature requirement as the server? I didn't see it but I probably just missed it. I'm thinking that with very little work a JWT can do everything that MAC does with greater flexibility, *BUT* the server needs to be able to require a signed usage. Something I never liked about OAuth 1.0 is that the server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that. It would require the client to be able to include client generated stuff in the JWT. Thanks, -bill ___ 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
Re: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x
Don't use OAuth, use OpenID. OAuth isn't designed for authentication and OpenID is. From: Adrian Servenschi adr...@c4media.com To: oauth@ietf.org Sent: Wednesday, January 2, 2013 1:25 PM Subject: [OAUTH-WG] need advice on sign out after performing sign in via OAuth 10x Hi guys, I am working on implementing login/registration with common identity providers into our application. I am using Scribe for java library which implements the OAuth protocol. I've encountered what I consider a small security issue that I don't know how to solve. If I sign in into our application via let's say Google and then I sign out, the Google session cookie remains active in the browser. I can open Gmail afterwards in my browser and my inbox is displayed without the need of authentication. Imagine that a user signs in to our application in an internet cafe, then signs out and leaves the facility. A different client comes at the same desk, opens Gmail and he/she sees the inbox of the first person. This can be a security hazard which I don't know how to solve. I see only 3 options: 1) I can leave it like this -- hazardous 2) If I use Google API to sign out the user from the Google when performing Sign out from our application then the user will be signed out from every Google application he has opened in his browser. In addition I heard that the documentation for performing Sign Out via various identity providers APIs is not quite clear. But this still needs to be investigated. 3) The third option : displaying some informative text when the user sings out from the application informing him that he/she signed out from our application only, and not from Google/other identity provider, seems to be the best option. I will highly appreciate if you can advise me regarding this issue. Thank you very much in advance! Adrian Servenschi. P.S. This is what I found on Facebook Platform Policies page http://developers.facebook.com/policy/ Your website must offer an explicit Log Out option that also logs the user out of Facebook. So indeed a form of 3) option will be the best choice? Looking forward to your advices and suggestions. ___ 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
Re: [OAUTH-WG] December 27, 2012 OAuth Release
Mike, I've read through the JWT spec and I'm curious about something. How do I specify a signature requirement as the server? I didn't see it but I probably just missed it. I'm thinking that with very little work a JWT can do everything that MAC does with greater flexibility, *BUT* the server needs to be able to require a signed usage. Something I never liked about OAuth 1.0 is that the server must support all valid signature types, even PLAINTEXT, so I want to be able to avoid that. It would require the client to be able to include client generated stuff in the JWT. Thanks, -bill___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Few questions about HOTK
I want to argue to change that. I think they should be separate and that the full token type definitiuon should be removed, defining only the key assertion. ANY token that needs signing by the client could be an HOK token. From: zhou.suj...@zte.com.cn zhou.suj...@zte.com.cn To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth,_oauth-boun...@ietf.org; SergeyBeryozkin sberyoz...@yahoo.com Sent: Thursday, December 20, 2012 11:46 PM Subject: Re: Re: [OAUTH-WG] Few questions about HOTK oauth-boun...@ietf.org 写于 2012-12-21 13:30:08: MAC and HOTK describe different properties of a token, and could both be used in the same token. MAC specifies a basic format for a signed token payload and transaction. HOTK defines part of a token payload. HOTK payload can be carried in a MAC token. -bill HOTK and MAC are different token types, how can they be used in the same token? What whould the token type be then? MAC and HOTK-SK are really very similar, they are actually alternative solutions to each other. The meaning is HOTK is more high level. From: Sergey Beryozkin sberyoz...@gmail.com To: oauth@ietf.org oauth@ietf.org Sent: Thursday, December 20, 2012 1:49 PM Subject: [OAUTH-WG] Few questions about HOTK Hi Hannes, others, I'd like to understand what is the difference between HOTK Symmetric [1] and MAC [2]. I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK Symmetric text can support MAC. My main question at the moment: does HOTK (Symmetric) offer an alternative to MAC or is HOTK actually a higher-level token scheme which can support different types of tokens ? thanks, Sergey [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Few questions about HOTK
No, MAC as I'm using it is a MAC token per http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 From: Sergey Beryozkin sberyoz...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Friday, December 21, 2012 3:15 AM Subject: Re: [OAUTH-WG] Few questions about HOTK On 21/12/12 05:30, William Mills wrote: MAC and HOTK describe different properties of a token, and could both be used in the same token. MAC specifies a basic format for a signed token payload and transaction. HOTK defines part of a token payload. HOTK payload can be carried in a MAC token. Speaking of MAC, are you referring to mac parameter within MAC Authorization payload representing a HOTK property ? Cheers, Sergey -bill *From:* Sergey Beryozkin sberyoz...@gmail.com *To:* oauth@ietf.org oauth@ietf.org *Sent:* Thursday, December 20, 2012 1:49 PM *Subject:* [OAUTH-WG] Few questions about HOTK Hi Hannes, others, I'd like to understand what is the difference between HOTK Symmetric [1] and MAC [2]. I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK Symmetric text can support MAC. My main question at the moment: does HOTK (Symmetric) offer an alternative to MAC or is HOTK actually a higher-level token scheme which can support different types of tokens ? thanks, Sergey [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Few questions about HOTK
I would find using a mac attribute inside a MAC token confusing. Inside a MAC token or any other client signed thing I'd probably call the keying assertion inside key, and make the payload of that defined by token type since some things like EC have more than one value in the keying information. From: Sergey Beryozkin sberyoz...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Friday, December 21, 2012 7:59 AM Subject: Re: [OAUTH-WG] Few questions about HOTK On 21/12/12 15:54, William Mills wrote: No, MAC as I'm using it is a MAC token per http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 Sure, what do you mean though when saying HOTK payload can be carried in a MAC token. ? I'm presuming you have in mind the parameters as defined in the draft, and specifically I thought it was the 'mac' attribute which is effectively a HOTK payload, possibly alongside few other Authorization MAC scheme attributes ? Sergey *From:* Sergey Beryozkin sberyoz...@gmail.com *To:* William Mills wmills_92...@yahoo.com *Cc:* oauth@ietf.org oauth@ietf.org *Sent:* Friday, December 21, 2012 3:15 AM *Subject:* Re: [OAUTH-WG] Few questions about HOTK On 21/12/12 05:30, William Mills wrote: MAC and HOTK describe different properties of a token, and could both be used in the same token. MAC specifies a basic format for a signed token payload and transaction. HOTK defines part of a token payload. HOTK payload can be carried in a MAC token. Speaking of MAC, are you referring to mac parameter within MAC Authorization payload representing a HOTK property ? Cheers, Sergey -bill *From:* Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com *To:* oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org *Sent:* Thursday, December 20, 2012 1:49 PM *Subject:* [OAUTH-WG] Few questions about HOTK Hi Hannes, others, I'd like to understand what is the difference between HOTK Symmetric [1] and MAC [2]. I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK Symmetric text can support MAC. My main question at the moment: does HOTK (Symmetric) offer an alternative to MAC or is HOTK actually a higher-level token scheme which can support different types of tokens ? thanks, Sergey [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org mailto:OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Few questions about HOTK
MAC and HOTK describe different properties of a token, and could both be used in the same token. MAC specifies a basic format for a signed token payload and transaction. HOTK defines part of a token payload. HOTK payload can be carried in a MAC token. -bill From: Sergey Beryozkin sberyoz...@gmail.com To: oauth@ietf.org oauth@ietf.org Sent: Thursday, December 20, 2012 1:49 PM Subject: [OAUTH-WG] Few questions about HOTK Hi Hannes, others, I'd like to understand what is the difference between HOTK Symmetric [1] and MAC [2]. I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK Symmetric text can support MAC. My main question at the moment: does HOTK (Symmetric) offer an alternative to MAC or is HOTK actually a higher-level token scheme which can support different types of tokens ? thanks, Sergey [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 ___ 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
Re: [OAUTH-WG] What needs to be done to complete MAC
I don't see in that document a significant use case for a signed token, which is use over clear text channels. Bearer tokens have similar security properties to HTTP cookies (minus for the moment the XSRF problem). Signed token types can be used over plain text channels without the concern about re-use of the token by a 3rd party. Replay protection is still needed but that's not in scope for the token mechanism itself. It's always been this simple use case that has been my focus for MAC. Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we won't be able to go completely SSL due to the installed base of clients. Given the dynamic I see in the mobile development community I don't see us getting all mobile apps into SSL only anytime soon. MAC and OAuth 1.0 solve the token security problem for the last hop to the phone/wi-fi device without SSL for the bulk of the application traffic. -bill From: Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com To: ext Sergey Beryozkin sberyoz...@gmail.com; Hannes Tschofenig hannes.tschofe...@gmx.net Cc: oauth@ietf.org Sent: Tuesday, November 27, 2012 4:33 AM Subject: Re: [OAUTH-WG] What needs to be done to complete MAC Hi Sergey, I believe we would make faster progress on security topics if could focus on listing security requirements we have and what threats we want to mitigate. The reason why we have not finished this topic is simply because everyone was just talking about specific (but incomplete) solutions. You are unfortunately falling in the same trap as well. If you really care about the topic then have a look at the mentioned document and tell us whether the requirements are complete. Reading through the document you will notice that there a few more considerations to pay attention to than just the few listed below. Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Sergey Beryozkin Sent: Tuesday, November 27, 2012 1:23 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What needs to be done to complete MAC Hi Hannes On 26/11/12 19:01, Hannes Tschofenig wrote: Hi Sergey, as Phil said it would be helpful for us to receive reviews of this document: http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 The document lists requirements and threats. Let me offer two possibly naive reasons why using MAC may help, one of them is related to the security, another to the ease of HOK support on the client 1. The most safe way to return MAC token to the client is to use a two-way TLS due to the mac key also returned to the client. Two-Way TLS offers a stronger support for getting the client authenticated along the way too 2. Assuming HOK confirmation matters at all (and I believe it does), IMHO it is much simpler for a basic client implementation to apply a MAC signature algo and thus work with the OAuth2 servers expecting HOK confirmations One more reason is more about facilitating the further migration to 2.0 which I tried to outline in my response to Phil Hunt Thanks, Sergey Ciao Hannes On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs. Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined and understood. More dialog on use cases is very helpful to moving HOK/MAC/etc forward. Phil On 2012-11-26, at 10:15, Sergey Beryozkinsberyoz...@gmail.com wrote: Hi What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0. I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press. Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0). Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ? If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such... Cheers, Sergey ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list
Re: [OAUTH-WG] What needs to be done to complete MAC
Yes! The other thing that is better in the OAuth 2 model is the refresh capability, which makes plain text channel token usage more palatable. From: Richer, Justin P. jric...@mitre.org To: William Mills wmills_92...@yahoo.com Cc: Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com; ext Sergey Beryozkin sberyoz...@gmail.com; Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org oauth@ietf.org Sent: Tuesday, November 27, 2012 9:51 AM Subject: Re: [OAUTH-WG] What needs to be done to complete MAC An important point to note, that many OAuth1 implementations in the wild screw up, is that you still need TLS between the client and the Authorization Server to protect the token and secret in transit, even if you don't use TLS during the client's calls to the protected resource. Since OAuth2 core mandates TLS at the Token Endpoint explicitly for all token types, that's much more clear to understand (in my opinion) in implementation. In case the above is unclear, what I'm trying to say is this: putting a signed token like MAC into the OAuth2 framework will give us the capability of OAuth1 in a clearer, more secure (in the wild) structure. I think it's vitally important that we have this functionality, and while I understand the need for clear use cases, I don't understand the feet-dragging. -- Justin On Nov 27, 2012, at 12:32 PM, William Mills wrote: I don't see in that document a significant use case for a signed token, which is use over clear text channels. Bearer tokens have similar security properties to HTTP cookies (minus for the moment the XSRF problem). Signed token types can be used over plain text channels without the concern about re-use of the token by a 3rd party. Replay protection is still needed but that's not in scope for the token mechanism itself. It's always been this simple use case that has been my focus for MAC. Flickr uses OAuth 1.0a today over HTTP and will for many years to come, we won't be able to go completely SSL due to the installed base of clients. Given the dynamic I see in the mobile development community I don't see us getting all mobile apps into SSL only anytime soon. MAC and OAuth 1.0 solve the token security problem for the last hop to the phone/wi-fi device without SSL for the bulk of the application traffic. -bill From: Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com To: ext Sergey Beryozkin sberyoz...@gmail.com; Hannes Tschofenig hannes.tschofe...@gmx.net Cc: oauth@ietf.org Sent: Tuesday, November 27, 2012 4:33 AM Subject: Re: [OAUTH-WG] What needs to be done to complete MAC Hi Sergey, I believe we would make faster progress on security topics if could focus on listing security requirements we have and what threats we want to mitigate. The reason why we have not finished this topic is simply because everyone was just talking about specific (but incomplete) solutions. You are unfortunately falling in the same trap as well. If you really care about the topic then have a look at the mentioned document and tell us whether the requirements are complete. Reading through the document you will notice that there a few more considerations to pay attention to than just the few listed below. Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Sergey Beryozkin Sent: Tuesday, November 27, 2012 1:23 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] What needs to be done to complete MAC Hi Hannes On 26/11/12 19:01, Hannes Tschofenig wrote: Hi Sergey, as Phil said it would be helpful for us to receive reviews of this document: http://tools.ietf.org/html/draft-tschofenig-oauth-security-00 The document lists requirements and threats. Let me offer two possibly naive reasons why using MAC may help, one of them is related to the security, another to the ease of HOK support on the client 1. The most safe way to return MAC token to the client is to use a two-way TLS due to the mac key also returned to the client. Two-Way TLS offers a stronger support for getting the client authenticated along the way too 2. Assuming HOK confirmation matters at all (and I believe it does), IMHO it is much simpler for a basic client implementation to apply a MAC signature algo and thus work with the OAuth2 servers expecting HOK confirmations One more reason is more about facilitating the further migration to 2.0 which I tried to outline in my response to Phil Hunt Thanks, Sergey Ciao Hannes On Nov 26, 2012, at 8:28 PM, Phil Hunt wrote: If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs. Some would argue that OAuth1 users arguably have less security than the simpler bearer token
Re: [OAUTH-WG] What needs to be done to complete MAC
I object to tying MAC to HOK, I see them as independent and I frankly don't understand why folks insist that MAC can not proceed without a broader HOK spec. -bill From: Phil Hunt phil.h...@oracle.com To: Sergey Beryozkin sberyoz...@gmail.com Cc: oauth@ietf.org oauth@ietf.org Sent: Monday, November 26, 2012 10:28 AM Subject: Re: [OAUTH-WG] What needs to be done to complete MAC If we want to get this done we have to get agreements on the requirements for HOK. Several meetings ago (quebec) the group indicated that mac wasn't appropriate to anyone's needs. Some would argue that OAuth1 users arguably have less security than the simpler bearer token /tls model in OAuth2. This just shows the real issue of demonstrated need has not been properly defined and understood. More dialog on use cases is very helpful to moving HOK/MAC/etc forward. Phil On 2012-11-26, at 10:15, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi What needs to be done to complete the MAC token spec ? Without having it signed off it will be difficult to get people working with OAuth 1.0 convinced to move to 2.0. I'm seeing another user request for getting OAuth 1.0 support extended further because the user expects it is more secure, and I guess because it is proven to work for people, and I guess because many OAuth 1.0 users feel that should stay from OAuth 2.0 because of some bad press. Without MAC being completed the division will continue, with even more misleading anti-OAuth2 posts appearing (though I guess some of the better posts point to some level of complexity in 2.0). Is it a matter of a security expert validating the text, fixing few typos, and basically signing it off ? If someone is interested then I can provide the info offline on how it MAC supported in our framework to get things tested easily and such... Cheers, Sergey ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] How the client can decide it is time to use the refresh token
Yes, exactly right. The client gets a hint about the AT lifespan, but must always handle the error response too. If the AT fails with a 401 then you try a refresh. If the refresh fails and you get a 401 response then you re-authenticate the user. Other 4XX error codes mean something different of course. From: Sergey Beryozkin sberyoz...@gmail.com To: Justin Richer jric...@mitre.org Cc: oauth@ietf.org Sent: Wednesday, November 21, 2012 6:18 AM Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token Hi On 21/11/12 14:11, Justin Richer wrote: There's no signaling regarding the validity of the refresh token from the protected resource. In more distributed setups, the protected resources know nothing about the refresh tokens because the PR never sees them. I was just asking how the client decides it can use the refresh token, and In any case. the code path is fairly straightforward, even if both tokens are expired: - client presents AT to resource - resource returns data, AT worked - [or] resource returns 400 error to client, AT didn't work - client presents RT to auth server - auth server returns new AT, RT worked - [or] auth server returns 400 error to client, RT didn't work - client has to go get a new auth grant from the resource owner, start over the answer seems to be that whenever it gets 400 after presenting AT to resource it should try to use RT next to get a new AT, I guess it was not really obvious to me though now that I think about it, it makes sense, 400 at the initial try means that the current AT is not good enough for whatever reasons Thanks, Sergey -- Justin On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: Hi I'm looking for some guidance on how the client which already owns an access token can decide, after getting HTTP 400 back from the resource server it tries to access on behalf of the end user/resource owner, can decide that the refresh token it has can now be used to get a new access token. [1] refers to various error conditions but it is not obvious to me that the same conditions (some of them) should or can be reported during the actual client accessing the protected resource. My question is, what error condition, if any, from [1] should be reported back to the client failing to access a protected resource due to the access token being invalid or expired, so that it can help the client who also owns the refresh token to decide it can use it now... Thanks, Sergey [1] http://tools.ietf.org/html/rfc6749#section-5.2 ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] How the client can decide it is time to use the refresh token
401 not 400 From: Justin Richer jric...@mitre.org To: Sergey Beryozkin sberyoz...@gmail.com Cc: oauth@ietf.org Sent: Wednesday, November 21, 2012 6:11 AM Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh token There's no signaling regarding the validity of the refresh token from the protected resource. In more distributed setups, the protected resources know nothing about the refresh tokens because the PR never sees them. In any case. the code path is fairly straightforward, even if both tokens are expired: - client presents AT to resource - resource returns data, AT worked - [or] resource returns 400 error to client, AT didn't work - client presents RT to auth server - auth server returns new AT, RT worked - [or] auth server returns 400 error to client, RT didn't work - client has to go get a new auth grant from the resource owner, start over -- Justin On 11/21/2012 06:50 AM, Sergey Beryozkin wrote: Hi I'm looking for some guidance on how the client which already owns an access token can decide, after getting HTTP 400 back from the resource server it tries to access on behalf of the end user/resource owner, can decide that the refresh token it has can now be used to get a new access token. [1] refers to various error conditions but it is not obvious to me that the same conditions (some of them) should or can be reported during the actual client accessing the protected resource. My question is, what error condition, if any, from [1] should be reported back to the client failing to access a protected resource due to the access token being invalid or expired, so that it can help the client who also owns the refresh token to decide it can use it now... Thanks, Sergey [1] http://tools.ietf.org/html/rfc6749#section-5.2 ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Identifying token type during protected resource access
The Authorization scheme name in the Authorization header tells you From: Ib Lundgren ib.lundg...@gmail.com To: oauth@ietf.org Sent: Sunday, November 18, 2012 8:57 AM Subject: [OAUTH-WG] Identifying token type during protected resource access Hey everyone, http://tools.ietf.org/html/rfc6749#section-7 provides examples of MAC and Bearer tokens being supplied when accessing a protected resource. It also mentions that it is up to each type of token to define additional parameters. However it is not quite clear whether there exists a recommended/intended way of differentiating the token type of any particular request as the token_type parameter is not supplied. Consider a bearer token supplied as the access_token query component. Then I invent and register Bearer+ which in addition has the plus query component. Then later Super Bearer is created with the additional super query component. The only way to differentiate would be to inspect present parameters and make an educated guess. Am I missing something obvious? Thanks, Ib ___ 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
Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
I think a resource server might validly revoke a token, but that a client will not. -bill - Original Message - From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; Torsten Lodderstedt tors...@lodderstedt.net; Justin Richer jric...@mitre.org; oauth@ietf.org WG oauth@ietf.org Sent: Tuesday, September 11, 2012 1:49 AM Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00 Hi Bill, if I read your post correctly then you are saying that you do not like what is in draft-ietf-oauth-revocation-00 Did I understood you correctly? Ciao Hannes On Sep 11, 2012, at 7:45 AM, William Mills wrote: Well, the only way the client would request revocation is if the client thinks the token is compromised, e.g. that the client has done dumb stuff. In that sense I think the client requesting revocation makes no sense. I am also not in favor of token introspection endpoints at all, the client should already have all of the information it needs about the token. From: Torsten Lodderstedt tors...@lodderstedt.net To: Justin Richer jric...@mitre.org Cc: oauth@ietf.org WG oauth@ietf.org Sent: Monday, September 10, 2012 12:55 PM Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-00 +1 Am 10.09.2012 15:49, schrieb Justin Richer: That requires the client and/or resource server to run an endpoint of their own at all times, and it requires the AS to keep track of all instances of a client and RS. This isn't likely to be particularly desirable, scalable, or usable. I don't see too much harm in trying to define it, but I don't think it will see much adoption. Besides, the client can find out the token is revoked by just presenting it to the RS and getting back a 40x code. Clients don't really need anything faster than that for security reasons, and any shortcuts would be for performance. The connection between the RS and AS isn't defined -- but I think this is another instance where the generic token introspection endpoint makes more sense. If the RS wants to check, the AS can just tell it (via introspection) that the token was revoked so don't honor it. -- Justin On 09/10/2012 08:25 AM, Hannes Tschofenig wrote: The current draft defines an additional endpoint, the token revocation endpoint, so that clients can request the revocation of a particular token. Wouldn't it make sense to also allow Authorization Servers to tell Clients or Resource Servers to revoke tokens? Ciao Hannes ___ 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 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-revocation-00
Revocation endpoint discovery can be handled through standard discovery mechanisms. I don't think clients should request revocation (see earlier message). From: Hannes Tschofenig hannes.tschofe...@gmx.net To: oauth@ietf.org WG oauth@ietf.org Sent: Monday, September 10, 2012 5:25 AM Subject: [OAUTH-WG] draft-ietf-oauth-revocation-00 The current draft defines an additional endpoint, the token revocation endpoint, so that clients can request the revocation of a particular token. Wouldn't it make sense to also allow Authorization Servers to tell Clients or Resource Servers to revoke tokens? Ciao Hannes ___ 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
Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01
It could even, theoretically, be included in the Access Token! It certainly could, this is the simplest form of holder of key in fact. From: Derek Atkins de...@ihtfp.com To: Hannes Tschofenig hannes.tschofe...@gmx.net Cc: oauth@ietf.org oauth@ietf.org Sent: Monday, September 10, 2012 6:14 AM Subject: Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01 Hannes Tschofenig hannes.tschofe...@gmx.net writes: Hi Zhou, here is the story. The Authorization Server gives an Access Token to the Client and the client presents that Access Token to Resource Servers. This has not changed in comparison to Bearer Tokens. However, in addition to just presenting the Access Token by the Client to the Resource Server the Client also needs to compute a keyed message digest on the access request to the protected resource. It needs a key to compute the keyed message digest. This key, called MAC key, is provided by the Authorization Server together with the Access Token. What is not said in the document is how the Resource Server obtains the MAC key from the Authorization Server. It is assumed to be shared somehow. It could even, theoretically, be included in the Access Token! Hope that makes more sense. Ciao Hannes -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
Re: [OAUTH-WG] OAuth Service Chaining
Are you trying to limit how widely the more powerful token gets used so peer systems can't access each other? What problem does this solve? That said I think you want to turn in an AT and get back N tokens with all possible subordinate scopes if in fact this is worth doing. AT1 with scop a b could be split to a and b, or it could return a_1, a_2, and b tokens. The AS will know the mapping policy. From: Justin Richer jric...@mitre.org To: oauth@ietf.org oauth@ietf.org Sent: Friday, September 7, 2012 7:28 AM Subject: [OAUTH-WG] OAuth Service Chaining In many of the systems that I've run into, especially legacy systems, we have multiple independent services that need to work in concert with each other to fulfill a service request. In a SAML based world, somebody usually builds up an uber-assertion that gets passed around to all the services, who each check it to make sure it's got the bits in it that they care about. I've been asked by several people how we can solve this in an OAuth world, and we can of course do this same exact thing with OAuth bearer tokens, using either introspection or structured tokens to fulfill the SAML-parsing role. But I think that tokens are fundamentally different from assertions, and that we can do better. What if, instead, a client gets a token from an AS, like usual, and passes it to the RS, like usual. But then that RS could in turn talk to the RS to get another token so that it can call a second RS. This secondary token can have at most the same rights as the original token. For all intents and purposes, this is the refresh tokens flow, but with one major difference: it's the RS that's trading one AT for another AT. This is important, since the RS won't ever have the refresh token (and shouldn't!). With that flow in mind, I've submitted a rough outline for a new grant type and method of using OAuth2 bearer tokens in a chained environment, to facilitate discussion in this group about it. It's a pattern we plan on implementing here, so whether it eventually becomes a WG item or an individual submission, I thought it would be useful to get it out in the open. It doesn't yet have the normative cross-references or the formal IANA registration language in it, but the core of the flow is there. http://tools.ietf.org/html/draft-richer-oauth-chain-00 I look forward to comments and discussion. -- Justin Original Message Subject: New Version Notification for draft-richer-oauth-chain-00.txt Date: Fri, 7 Sep 2012 07:13:53 -0700 From: internet-dra...@ietf.org To: jric...@mitre.org A new version of I-D, draft-richer-oauth-chain-00.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-chain Revision:00 Title: A Method of Bearer Token Redelegation and Chaining for OAuth 2 Creation date: 2012-09-07 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-chain Htmlized: http://tools.ietf.org/html/draft-richer-oauth-chain-00 Abstract: This document provides a method for a resource server to present a token that it has received from a client back to its authorization server for the purposes of receiving a derivative token for use on another resource server in order to chain together service requests. The IETF Secretariat ___ 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
Re: [OAUTH-WG] OAuth Service Chaining
You're doubling the number of back end calls to satisfy a request though, and in the end you're only really getting a benefit when the back end system would never see an ubertoken anyway. From: Justin Richer jric...@mitre.org To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Friday, September 7, 2012 8:08 AM Subject: Re: [OAUTH-WG] OAuth Service Chaining On 09/07/2012 10:51 AM, William Mills wrote: Are you trying to limit how widely the more powerful token gets used so peer systems can't access each other? What problem does this solve? Exactly -- it keeps you from passing around the ubertoken to all of your systems, especially when they don't need it. It lets you better scope what each system is doing. Additionally, it gets you away from passing on the access token that you were passed in, which I see as an anti-pattern that's potentially almost as dangerous as passing along a user's primary credential, the original problem that OAuth sought to solve. That said I think you want to turn in an AT and get back N tokens with all possible subordinate scopes if in fact this is worth doing. AT1 with scop a b could be split to a and b, or it could return a_1, a_2, and b tokens. The AS will know the mapping policy. But then you'd also have to define a multi-access-token response format, and I think that's better left to its own pluggable mechanism. Such a mechanism could be used here because there's nothing in here that says what's returned has to be another single bearer token. (Though if you do that, it lets you go turtles all the way down at the next RS.) -- Justin From: Justin Richer jric...@mitre.org To: oauth@ietf.org oauth@ietf.org Sent: Friday, September 7, 2012 7:28 AM Subject: [OAUTH-WG] OAuth Service Chaining In many of the systems that I've run into, especially legacy systems, we have multiple independent services that need to work in concert with each other to fulfill a service request. In a SAML based world, somebody usually builds up an uber-assertion that gets passed around to all the services, who each check it to make sure it's got the bits in it that they care about. I've been asked by several people how we can solve this in an OAuth world, and we can of course do this same exact thing with OAuth bearer tokens, using either introspection or structured tokens to fulfill the SAML-parsing role. But I think that tokens are fundamentally different from assertions, and that we can do better. What if, instead, a client gets a token from an AS, like usual, and passes it to the RS, like usual. But then that RS could in turn talk to the RS to get another token so that it can call a second RS. This secondary token can have at most the same rights as the original token. For all intents and purposes, this is the refresh tokens flow, but with one major difference: it's the RS that's trading one AT for another AT. This is important, since the RS won't ever have the refresh token (and shouldn't!). With that flow in mind, I've submitted a rough outline for a new grant type and method of using OAuth2 bearer tokens in a chained environment, to facilitate discussion in this group about it. It's a pattern we plan on implementing here, so whether it eventually becomes a WG item or an individual submission, I thought it would be useful to get it out in the open. It doesn't yet have the normative cross-references or the formal IANA registration language in it, but the core of the flow is there. http://tools.ietf.org/html/draft-richer-oauth-chain-00 I look forward to comments and discussion. -- Justin Original Message Subject: New Version Notification for draft-richer-oauth-chain-00.txt Date: Fri, 7 Sep 2012 07:13:53 -0700 From: internet-dra...@ietf.org To: jric...@mitre.org A new version of I-D, draft-richer-oauth-chain-00.txt has been successfully submitted by Justin Richer and posted to the IETF repository. Filename: draft-richer-oauth-chain Revision:00 Title: A Method of Bearer Token Redelegation and Chaining for OAuth 2 Creation date: 2012-09-07 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-richer-oauth-chain-00.txt Status: http://datatracker.ietf.org/doc/draft-richer-oauth-chain Htmlized: http://tools.ietf.org/html/draft-richer-oauth-chain-00 Abstract: This document provides a method for a resource server to present a token that it has received from a client back to its authorization server for the purposes
Re: [OAUTH-WG] Access token timeout
It's a hint to the client of when the token will probably expire. There was a lot of discussion on what the right way to go was and there were several camps on the right strategy choice would be, but in the end a very simple solution was chosen. Most folks agreed that having more than one way to go was not worth the complexity, so this single one was picked. From: Jérôme LELEU lel...@gmail.com To: oauth@ietf.org Sent: Sunday, August 19, 2012 1:25 AM Subject: [OAUTH-WG] Access token timeout Hi, I might be misunderstanding the OAuth 2.0 spec (part 5.1, expires_in property), but I understand that the timeout of the access token is a hard one (amount of time between creation and expiration). Am I right ? Can we have a multiple use timeout ? A sliding window timeout ? Or a combination of all ? Thanks. Best regards, Jérôme ___ 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
Re: [OAUTH-WG] OAuth 1.0a
You are mistaken, I cite MAC directly right now, but now that it is up in the air I would much rather rely on 3 specs (Oauth 2 core, Bearer, and 1.0a) than refer to MAC when I think I can do without MAC and use 1.0a instead. MAC is now in flux again, the other 3 are stable or already standards. I think you also mistaken that we can't support 1.0a and OAuth 2 tokens in the same SASL mechanism. Why do you think this is true? From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; Mike Jones michael.jo...@microsoft.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 10:48 PM Subject: Re: [OAUTH-WG] OAuth 1.0a FYI: just to repeat my note here as well that I sent to Bill on the KITTEN list: I see three possible ways forward for the OAuth SASL work, namely: • Focus on Oauth 1.0 only (since it has a MAC specification in there). Then, you ignore all the Oauth 2.0 deployment that is out there, of which there is a lot. That would be pretty bad IMHO. • Copy relevant parts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no deployment). • Wait for the Oauth group to settle on a mechanism. May take time. I doubt that the question about the views of the WG about OAuth 1.0a can answer any of the above questions. Bill does not want to wait. He also does not want to copy parts from draft-ietf-oauth-v2-http-mac-01 into the SASL OAuth spec. Focusing on OAuth 1.0 for now would require the specification to be extended later on to fit to OAuth 2.0 deployments (and whatever new security mechanism we will come up with). As a consequence, the specification will then suffer from additional complexity. Ciao Hannes On Aug 14, 2012, at 10:37 PM, William Mills wrote: It's for the OAUTH SASL spec. I've been writing it with the idea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want to allow for IMAP), but several folks were saying when this all started that 1.0a was dead and I should not refer to it. I want to make sure the SASL mechanism is build to properly handle signed auth schemes and not just bearer (cookie) type. -bill From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, August 14, 2012 12:22 PM To: O Auth WG Subject: [OAUTH-WG] OAuth 1.0a What's the general opinion on 1.0a? Am I stepping in something if I refer to it in another draft? I want to reference an auth scheme that uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a. Thanks, -bill ___ 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
Re: [OAUTH-WG] OAuth 1.0a
Fundamentally MAC and any HoK that uses symmetric keys are equivalent. Either can pull in the same profile of HTTP stuff into the signature. I commented on your argument that MAC and Bearer have equivalent security properties in a different thread. -bill From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; Torsten Lodderstedt tors...@lodderstedt.net; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 10:49 PM Subject: Re: [OAUTH-WG] OAuth 1.0a Hi Bill, how do you know that the outcome of the security discussions will unlikely be different than MAC? The views about TLS had changed in the meanwhile (a few years ago many thought it is too heavy and too expensive to get certificates), and we now have the JSON work as well. On top of that we may also want to provide not just client to server key confirmation with integrity protection of a few fields but more than that. In a nutshell the solution has to provide better security than bearer -- not just be different. Ciao Hannes On Aug 14, 2012, at 10:53 PM, William Mills wrote: I want to get the SASL work done. HoK is interesting, but I've become convinced that it's not actually anything that needs it's own spec, you can do HoK with MAC or any other signed scheme by including the needed proof of ownership in the token. HoK, however it works out, is unlikely to vary a lot from the elements that would currently be needed to support MAC or 1.0a and if needed can just extend the SASL mechanism. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:42 PM Subject: Re: [OAUTH-WG] OAuth 1.0a Hi Bill, do you need to specify this aspect of your SASL profile now? Why don't you wait for the group to complete the work on signing/HoK? You could also contribute your use cases to drive the discussion. best regards, Torsten. Am 14.08.2012 21:37, schrieb William Mills: It's for the OAUTH SASL spec. I've been writing it with the idea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want to allow for IMAP), but several folks were saying when this all started that 1.0a was dead and I should not refer to it. I want to make sure the SASL mechanism is build to properly handle signed auth schemes and not just bearer (cookie) type. -bill From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, August 14, 2012 12:22 PM To: O Auth WG Subject: [OAUTH-WG] OAuth 1.0a What's the general opinion on 1.0a? Am I stepping in something if I refer to it in another draft? I want to reference an auth scheme that uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a. Thanks, -bill ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 1.0a
Sorry, that other thread is on the Kitten list. Cross post it here? Certainly MAC or HoK could change and become incompatible with the current SASL mechanism spec. Hopefully not fundamentally incompatible, and either a new spec or the updated MAC or HoK spec can update the SASL mechanism to provide comatibility. -bill From: Hannes Tschofenig hannes.tschofe...@nsn.com To: William Mills wmills_92...@yahoo.com; Hannes Tschofenig hannes.tschofe...@gmx.net Cc: O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 11:32 PM Subject: Re: [OAUTH-WG] OAuth 1.0a Re: [OAUTH-WG] OAuth 1.0a Hi Bill, On 8/15/12 9:16 AM, ext William Mills wmills_92...@yahoo.com wrote: Fundamentally MAC and any HoK that uses symmetric keys are equivalent. Either can pull in the same profile of HTTP stuff into the signature. The issue is: a small change in the protocol specification makes the two mechanisms incompatible. Hence, you have to provide the code for the two and a possible negotiation mechanism along with it. For example, the fact that OAuth 1.0 does not allow for automatic token refresh already makes the OAuth 1.0 MAC and the OAuth 2.0 MAC different. I commented on your argument that MAC and Bearer have equivalent security properties in a different thread. Sorry. I missed that. Do you have a pointer for me by chance? Ciao Hannes -bill From:Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; Torsten Lodderstedt tors...@lodderstedt.net; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 10:49 PM Subject: Re: [OAUTH-WG] OAuth 1.0a Hi Bill, how do you know that the outcome of the security discussions will unlikely be different than MAC? The views about TLS had changed in the meanwhile (a few years ago many thought it is too heavy and too expensive to get certificates), and we now have the JSON work as well. On top of that we may also want to provide not just client to server key confirmation with integrity protection of a few fields but more than that. In a nutshell the solution has to provide better security than bearer -- not just be different. Ciao Hannes On Aug 14, 2012, at 10:53 PM, William Mills wrote: I want to get the SASL work done. HoK is interesting, but I've become convinced that it's not actually anything that needs it's own spec, you can do HoK with MAC or any other signed scheme by including the needed proof of ownership in the token. HoK, however it works out, is unlikely to vary a lot from the elements that would currently be needed to support MAC or 1.0a and if needed can just extend the SASL mechanism. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:42 PM Subject: Re: [OAUTH-WG] OAuth 1.0a Hi Bill, do you need to specify this aspect of your SASL profile now? Why don't you wait for the group to complete the work on signing/HoK? You could also contribute your use cases to drive the discussion. best regards, Torsten. Am 14.08.2012 21:37, schrieb William Mills: It's for the OAUTH SASL spec. I've been writing it with the idea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want to allow for IMAP), but several folks were saying when this all started that 1.0a was dead and I should not refer to it. I want to make sure the SASL mechanism is build to properly handle signed auth schemes and not just bearer (cookie) type. -bill From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, August 14, 2012 12:22 PM To: O Auth WG Subject: [OAUTH-WG] OAuth 1.0a What's the general opinion on 1.0a? Am I stepping in something if I refer to it in another draft? I want to reference an auth scheme that uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a. Thanks, -bill ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman
Re: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)
Thanks. From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; Dick Hardt dick.ha...@gmail.com; oauth@ietf.org WG oauth@ietf.org Sent: Tuesday, August 14, 2012 11:43 AM Subject: RE: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) “Specification Required” is correct, as that’s what’s used in OAuth Core. I believe that the case insensitivity comes from RFC 2617, which for instance, seems to use “Basic” and “basic” interchangeably. -- Mike From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Monday, August 13, 2012 9:34 AM To: Dick Hardt; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) 1) Is it a problem that everything here seems to have specification required for the Registration Procedures? 2) In HTTP Authentication schemes, is the case insensitivity implicit here? (I think so) -bill From:Dick Hardt dick.ha...@gmail.com To: oauth@ietf.org WG oauth@ietf.org Sent: Friday, August 10, 2012 1:04 PM Subject: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) Once again, would be great to have a few more eyes checking the IANA registrations. Note these are for the Bearer Token spec. I like that the error registry items are sorted alphabetically already. :) Begin forwarded message: From: Amanda Baber via RT drafts-appro...@iana.org Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) Date: August 10, 2012 12:20:33 PM PDT Cc: m...@microsoft.com, dick.ha...@gmail.com, oauth-cha...@tools.ietf.org, oauth-...@tools.ietf.org Reply-To: drafts-appro...@iana.org Dear Authors: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We have completed the IANA Actions for RFC-to-be draft-ietf-oauth-v2-bearer-23 ACTION 1: IANA has registered the following OAuth Access Token Type: Name: Bearer Additional Endpoint Response Parameters: HTTP Authentication Scheme(s): Bearer Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] Please see http://www.iana.org/assignments/oauth-parameters ACTION 2: IANA has registered the following in the OAuth Extensions Error Registry: invalid_request Usage Location: Resource access error response Protocol Extension: Bearer access token type Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] invalid_token Usage Location: Resource access error response Protocol Extension: Bearer access token type Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] insufficient_scope Usage Location: Resource access error response Protocol Extension: Bearer access token type Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] Please see http://www.iana.org/assignments/oauth-parameters Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) Thanks, Amanda Baber ICANN/IANA ___ 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
Re: [OAUTH-WG] OAuth 1.0a
It's for the OAUTH SASL spec. I've been writing it with the idea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want to allow for IMAP), but several folks were saying when this all started that 1.0a was dead and I should not refer to it. I want to make sure the SASL mechanism is build to properly handle signed auth schemes and not just bearer (cookie) type. -bill From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, August 14, 2012 12:22 PM To: O Auth WG Subject: [OAUTH-WG] OAuth 1.0a What's the general opinion on 1.0a? Am I stepping in something if I refer to it in another draft? I want to reference an auth scheme that uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a. Thanks, -bill___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 1.0a
I want to get the SASL work done. HoK is interesting, but I've become convinced that it's not actually anything that needs it's own spec, you can do HoK with MAC or any other signed scheme by including the needed proof of ownership in the token. HoK, however it works out, is unlikely to vary a lot from the elements that would currently be needed to support MAC or 1.0a and if needed can just extend the SASL mechanism. -bill From: Torsten Lodderstedt tors...@lodderstedt.net To: William Mills wmills_92...@yahoo.com Cc: Mike Jones michael.jo...@microsoft.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:42 PM Subject: Re: [OAUTH-WG] OAuth 1.0a Hi Bill, do you need to specify this aspect of your SASL profile now? Why don't you wait for the group to complete the work on signing/HoK? You could also contribute your use cases to drive the discussion. best regards, Torsten. Am 14.08.2012 21:37, schrieb William Mills: It's for the OAUTH SASL spec. I've been writing it with the idea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want to allow for IMAP), but several folks were saying when this all started that 1.0a was dead and I should not refer to it. I want to make sure the SASL mechanism is build to properly handle signed auth schemes and not just bearer (cookie) type. -bill From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, August 14, 2012 12:22 PM To: O Auth WG Subject: [OAUTH-WG] OAuth 1.0a What's the general opinion on 1.0a? Am I stepping in something if I refer to it in another draft? I want to reference an auth scheme that uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a. Thanks, -bill ___ 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
Re: [OAUTH-WG] OAuth 1.0a
Yeah, I still need 1.0a to work which I was hoping to replace with MAC. From: Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; Torsten Lodderstedt tors...@lodderstedt.net Cc: O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:44 PM Subject: RE: [OAUTH-WG] OAuth 1.0a Agreed. Use Bearer now. If you have requirements that Bearer *can’t* meet, please use them as input to the working group’s future work. -- Mike From:Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Tuesday, August 14, 2012 12:43 PM To: William Mills Cc: Mike Jones; O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a Hi Bill, do you need to specify this aspect of your SASL profile now? Why don't you wait for the group to complete the work on signing/HoK? You could also contribute your use cases to drive the discussion. best regards, Torsten. Am 14.08.2012 21:37, schrieb William Mills: It's for the OAUTH SASL spec. I've been writing it with the idea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want to allow for IMAP), but several folks were saying when this all started that 1.0a was dead and I should not refer to it. I want to make sure the SASL mechanism is build to properly handle signed auth schemes and not just bearer (cookie) type. -bill From:Mike Jones michael.jo...@microsoft.com To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, August 14, 2012 12:22 PM To: O Auth WG Subject: [OAUTH-WG] OAuth 1.0a What's the general opinion on 1.0a? Am I stepping in something if I refer to it in another draft? I want to reference an auth scheme that uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a. Thanks, -bill ___ 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
Re: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)
1) Is it a problem that everything here seems to have specification required for the Registration Procedures? 2) In HTTP Authentication schemes, is the case insensitivity implicit here? (I think so) -bill From: Dick Hardt dick.ha...@gmail.com To: oauth@ietf.org WG oauth@ietf.org Sent: Friday, August 10, 2012 1:04 PM Subject: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) Once again, would be great to have a few more eyes checking the IANA registrations. Note these are for the Bearer Token spec. I like that the error registry items are sorted alphabetically already. :) Begin forwarded message: From: Amanda Baber via RT drafts-appro...@iana.org Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) Date: August 10, 2012 12:20:33 PM PDT Cc: m...@microsoft.com, dick.ha...@gmail.com, oauth-cha...@tools.ietf.org, oauth-...@tools.ietf.org Reply-To: drafts-appro...@iana.org Dear Authors: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We have completed the IANA Actions for RFC-to-be draft-ietf-oauth-v2-bearer-23 ACTION 1: IANA has registered the following OAuth Access Token Type: Name: Bearer Additional Endpoint Response Parameters: HTTP Authentication Scheme(s): Bearer Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] Please see http://www.iana.org/assignments/oauth-parameters ACTION 2: IANA has registered the following in the OAuth Extensions Error Registry: invalid_request Usage Location: Resource access error response Protocol Extension: Bearer access token type Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] invalid_token Usage Location: Resource access error response Protocol Extension: Bearer access token type Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] insufficient_scope Usage Location: Resource access error response Protocol Extension: Bearer access token type Change Controller: IETF Reference: [RFC-ietf-oauth-v2-bearer-23] Please see http://www.iana.org/assignments/oauth-parameters Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) Thanks, Amanda Baber ICANN/IANA ___ 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
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I would say that's true in theory, but practically speaking it's not gonna happen. You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable. If we're gonna improve on the current PKI that is SSL certificates we should do that separately. From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: David Waite da...@alkaline-solutions.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 8:47 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Bill, I seem to recall in Paris that client misconfiguration of TLS was a concern. In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication. If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions. Or conversely additional protection of the token endpoint needs to be considered for key distribution. John B. On 2012-08-09, at 7:19 PM, William Mills wrote: AS would still be required to be HTTPS as per the spec. From: David Waite da...@alkaline-solutions.com To: oauth@ietf.org Sent: Thursday, August 9, 2012 4:02 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 For #1: Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS? For #2: Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response? -DW On Aug 9, 2012, at 1:37 PM, Justin Richer jric...@mitre.org wrote: Use case #2: signature protection over plain HTTP parameters MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms. Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today) Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The Client generates the signed URLs and passes them to a user agent which actually does the fetch to the service. -- Justin On 08/09/2012 02:43 PM, William Mills wrote: OK, I'll play and start documenting the use cases. Use case #1: Secure authentication in plain text connections: Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection. -bill From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: Dick Hardt dick.ha...@gmail.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 11:26 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor. The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document. Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP. People are welcome to contribute to the use-case document. Part of the problem with MAC has been that people could never agree on what it was protecting against. I think there is general agreement that one or more proof mechanisms are required for access tokens. Security for the token endpoint also cannot be ignored. John B. On 2012-08-09, at 1:53 PM, William Mills wrote: MAC fixes the signing problems encountered
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
From: Hannes Tschofenig hannes.tschofe...@gmx.net To: William Mills wmills_92...@yahoo.com Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; John Bradley ve7...@ve7jtb.com; oauth@ietf.org oauth@ietf.org Sent: Friday, August 10, 2012 12:01 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Hi Bill, thanks for the feedback. Let's have a look at this use case: You need to provide me a bit more information regarding your use case. Could you please explain 1) Who is authenticated to whom? wjm the client is authenticated to the server. 2) What plaintext connection are you talking about? wjm generally an HTTP connection to a webservice 3) What is the problem with encrypted connections? Is this again the TLS has so bad performance argument? wjm Yes, annoying but true. This may change, but we do business with enough folks that refuse SSL that this is a real problem. 4) Since you are talking about cookies and making them more secure are you trying to come up with a general solution to better cookie security - a topic others are working on as well. wjm No, I'm pointing out the problems with a simple replayable credential like cookies as a comparison. 5) What is the threat you are concerned about? wjm The vulnerability of plaintext connections: theft of credentials and tampering. Ciao Hannes PS: I would heavily argue against standardize a security mechanism that offers weaker protection than bearer when the entire argument has always been Bearer is so insecure and we need something stronger. On Aug 9, 2012, at 9:43 PM, William Mills wrote: OK, I'll play and start documenting the use cases. Use case #1: Secure authentication in plain text connections: Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection. -bill From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: Dick Hardt dick.ha...@gmail.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 11:26 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor. The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document. Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP. People are welcome to contribute to the use-case document. Part of the problem with MAC has been that people could never agree on what it was protecting against. I think there is general agreement that one or more proof mechanisms are required for access tokens. Security for the token endpoint also cannot be ignored. John B. On 2012-08-09, at 1:53 PM, William Mills wrote: MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 10:27 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 On Aug 9, 2012, at 9:52 AM, William Mills wrote: I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft. I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done. Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key. Just my $.02 -- Dick ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
It's not intended to address anything in TLS other than the fact that we have real use cases where TLS isn't in play. From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: David Waite da...@alkaline-solutions.com; oauth@ietf.org oauth@ietf.org Sent: Friday, August 10, 2012 8:09 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 No I wasn't talking about changing TLS. I think the TLS threat has been expressed more as people who turn verification in the client rather than any failure of the TLS protocol or certificates. The question I was trying to get at was if any of the message signing was intended to protect against clients misconfiguring TLS or Man in the middle attacking communications with the RS or token server. Part of the reason behind MAC has been expressed as concern that Server TLS doesn't prevent tokens from being intercepted and replayed sufficiently. Where TLS is used if we believe clients are properly implemented what is the signing getting us. I think sessions without TLS and TLS terminated on the firewall need to be supported, but there the threat is clearer. John On 2012-08-10, at 10:36 AM, William Mills wrote: I would say that's true in theory, but practically speaking it's not gonna happen. You're stating we need to come up with a better method for public key than we have now for this to be widely adopted, and I don't think that's reasonable. If we're gonna improve on the current PKI that is SSL certificates we should do that separately. From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: David Waite da...@alkaline-solutions.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 8:47 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Bill, I seem to recall in Paris that client misconfiguration of TLS was a concern. In MAC the token secret is delivered with the token based on server TLS and HTTP basic authentication. If this is OK and we trust the client to do TLS server certificate verification correctly that needs to go in as one of our base assumptions. Or conversely additional protection of the token endpoint needs to be considered for key distribution. John B. On 2012-08-09, at 7:19 PM, William Mills wrote: AS would still be required to be HTTPS as per the spec. From: David Waite da...@alkaline-solutions.com To: oauth@ietf.org Sent: Thursday, August 9, 2012 4:02 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 For #1: Does the use of plain HTTP to talk to protected resources provide significant value when using an AS that requires HTTPS? Or am I misunderstanding, and this use case would also include new modes for non-TLS communication with the AS? For #2: Would the signature protection just cover HTTP parameters, or would it extend to covering any request data, such as a PUT binary file? Would the integrity protection only cover requests, or would you also have integrity protection of the response? -DW On Aug 9, 2012, at 1:37 PM, Justin Richer jric...@mitre.org wrote: Use case #2: signature protection over plain HTTP parameters MAC gives us message-level signing in a way that doesn't require all the parameters to be packed into an extra structure, like JWT/SAML do. TLS gives no application-layer verification of integrity of parameters, nor does it give you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody does). MAC gives you a fairly simple way to protect all parameters on a call to the resource server while still keeping all of those parameters in their native HTTP forms. Use case #3: generic signed HTTP fetch (not directly addressed by MAC spec as of today) Sometimes you want to create a URL with one service, fix all of the parameters in that URL, and protect those parameters with a signature. Then that URL can be passed to an untrusted service who cannot modify any portion of it. Nor can they re-use the signature portion to protect different parameters. We do this today with a 2-legged OAuth signature across a service URL. The Client generates the signed URLs and passes them to a user agent which actually does the fetch to the service. -- Justin On 08/09/2012 02:43 PM, William Mills wrote: OK, I'll play and start documenting the use cases. Use case #1: Secure authentication in plain text connections: Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft. I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done. -bill On 08/08/2012 05:21 PM, John Bradley wrote: We did discuss per message signing in Vancouver. The idea is to get agreement on the threats we are trying to mitigate, then decide on the mechanisms. Per message signing will likely still be one of the mechanisms. The chair will need to decide if we start fresh and copy the parts of MAC that are needed or try and continue the existing MAC draft. John B. On 2012-08-08, at 4:59 PM, Justin Richer wrote: I believe that there's value in per-message signing completely apart from the channel level encryption. MAC tokens let us do this with a per-token secret using a pattern very well established in OAuth1. I'm sorry that I wasn't at the Vancouver meeting to voice this opinion, for what it's worth. -- Justin On 08/08/2012 12:24 PM, Hannes Tschofenig wrote: Hi Justas, thanks for sending your feedback to the list. There is indeed currently no editor for the document. That is, however, not the problem. The problem, as discussed on the list and also at the last IETF meeting, is that we do not yet know what type of security properties we want. The MAC draft may or may not provide the type of protection we want. For that reason we first have to figure out what problem we want to solve before we jump into the details of fixing some minor errors. Ciao Hannes On Aug 8, 2012, at 6:08 PM, Justin Richer wrote: Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error. A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well. -- Justin On 08/05/2012 06:30 AM, Justas Janauskas wrote: Hello, Sorry if this is not the right group to send this message; I am new here. I believe there is mistake in calculated request MAC presented in draft-ietf-oauth-v2-http-mac-01 example, section 1.1. I made a small program to test correctness of an example and it shows that it is incorrectly calculated in the document: https://gist.github.com/3263677 I have also implemented an example from previous draft 00, section 1.2 which shows that request MAC is calculated correctly there: https://gist.github.com/3263765 Thank you, Justas Janauskas ___ 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 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 10:27 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 On Aug 9, 2012, at 9:52 AM, William Mills wrote: I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft. I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done. Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key. Just my $.02 -- Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
OK, I'll play and start documenting the use cases. Use case #1: Secure authentication in plain text connections: Some applications need a secure form authorization, but do not want or need the overhead of encrypted connections. HTTP cookies and their ilk are replayable credentials and do not satisfy this need. the MAC scheme using signed HTTP authorization credentials offer the capability to securely authorize a transaction, can offer integrity protection on all or part of an HTTP request, and can provide replay protection. -bill From: John Bradley ve7...@ve7jtb.com To: William Mills wmills_92...@yahoo.com Cc: Dick Hardt dick.ha...@gmail.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 11:26 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 In Vancouver the question was asked about the future of the MAC spec due to it no linger having a editor. The Chair and AD indicated a desire to have a document on the use-cases we are trying to address before deciding on progressing MAC or starting a new document. Phil Hunt is going to put together a summery of the Vancouver discussion and we are going to work on the use-case/problem description document ASAP. People are welcome to contribute to the use-case document. Part of the problem with MAC has been that people could never agree on what it was protecting against. I think there is general agreement that one or more proof mechanisms are required for access tokens. Security for the token endpoint also cannot be ignored. John B. On 2012-08-09, at 1:53 PM, William Mills wrote: MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 10:27 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 On Aug 9, 2012, at 9:52 AM, William Mills wrote: I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft. I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done. Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key. Just my $.02 -- Dick ___ 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
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Mostly it's around making sure you get the signature base string constructed right in my experience. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: Dick Hardt dick.ha...@gmail.com; oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 12:48 PM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 As an implementer, I have an app that accesses 10 different resources. Some are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code path since each resource is its own beautiful snowflake. I did not use any libraries for OAuth 2. Supporting MAC would give me yet another library to integrate with. I'd be interested in what signing problems OAuth 1.0A has. I have my own list of how writing to OAuth 1.0A is hard. On Aug 9, 2012, at 10:53 AM, William Mills wrote: MAC fixes the signing problems encountered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 10:27 Aa Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 On Aug 9, 2012, at 9:52 AM, William Mills wrote: I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something that supports both PK and SK, or finish the SK use case and then work on a PK based draft. I think it's better to leave them separate and finish out MAC which is *VERY CLOSE* to being done. Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. For my projects, I prefer the flexibility of a signed or encrypted JWT if I need holder of key. Just my $.02 -- Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Justin, Count me in to help revive this and get it done. -bill From: Justin Richer jric...@mitre.org To: oauth@ietf.org Sent: Wednesday, August 8, 2012 8:08 AM Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error. A wider note to the WG: I wouldn't mind taking over editorship of the MAC token document so long as I could get a co-editor with enough cryptographic expertise to make sure all the magical crypto bits work like they should. I've sent an email to the chairs saying as much, as well. -- Justin On 08/05/2012 06:30 AM, Justas Janauskas wrote: Hello, Sorry if this is not the right group to send this message; I am new here. I believe there is mistake in calculated request MAC presented in draft-ietf-oauth-v2-http-mac-01 example, section 1.1. I made a small program to test correctness of an example and it shows that it is incorrectly calculated in the document: https://gist.github.com/3263677 I have also implemented an example from previous draft 00, section 1.2 which shows that request MAC is calculated correctly there: https://gist.github.com/3263765 Thank you, Justas Janauskas ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Holder-of-the-Key for OAuth
The server would need to issue a key pair and not just the private key. Are
you saying the private key is for the certificate, and that certificate is part
of the access_token?
From: Manger, James H james.h.man...@team.telstra.com
To: Hannes Tschofenig hannes.tschofe...@gmx.net; OAuth WG oauth@ietf.org
Sent: Monday, July 9, 2012 8:54 PM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
Hannes,
today I submitted a short document that illustrates the concept of
holder-of-the-key for OAuth.
Here is the document:
https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk
A different approach would be for the service to issue a private asymmetric key
to the client app, along with a certificate, in the access token response. This
is a slightly better match to the OAuth2 model of the authorization service
issuing temporary credentials for accessing resources on a user’s behalf.
When the token_type is tls_client_cert (probably a better label than hotk),
the client can access protected resources using TLS with client authentication;
using the key from the private_key field. The access_token field holds a
base64url-encoded certificate to include in the TLS handshake.
An example access token response could be:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
token_type:tls_client_cert,
access_token:MIIGcDCCBdmgAwIBAgIKE…,
private_key:{
alg:RSA, mod:Ovx7…, p:7dE…, q:fJ3…, …
},
expires_in:3600,
refresh_token:tGzv3JOkF0XG5Qx2TlKWIA
}
The suggestion above passes the access_token to the protected resource in the
TLS protocol in the form of a certificate.
draft-tschofenig-oauth-hotk says the client presents the access token to the
resource server, but it wasn't clear to me how it was done. Were you expecting
the client to use the BEARER HTTP auth scheme inside the client-authenticated
TLS connection?
--
James Manger
___
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
Re: [OAUTH-WG] 'Finishing up design team' Conference Call
Ah... sigh. I did reply yesterday, but never got connection information. From: Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com To: William Mills wmills_92...@yahoo.com; Hannes Tschofenig hannes.tschofe...@gmx.net; OAuth WG oauth@ietf.org Sent: Monday, July 9, 2012 11:50 AM Subject: RE: [OAUTH-WG] 'Finishing up design team' Conference Call Hi Bill, the call started at 8pm Helsinki time. You were an hour too late. Ciao Hannes Sent from my Windows Phone From: ext William Mills Sent: 7/9/2012 9:20 PM To: Hannes Tschofenig; OAuth WG Subject: Re: [OAUTH-WG] 'Finishing up design team' Conference Call Is this on? Is there a dial-in or hangout link? From: Hannes Tschofenig hannes.tschofe...@gmx.net To: OAuth WG oauth@ietf.org Sent: Sunday, July 8, 2012 11:03 AM Subject: [OAUTH-WG] 'Finishing up design team' Conference Call I don't know why Google Hangout does not forward my invitation to the oauth@ietf.org mailing list. So, send me private mail if you plan to participate. Original Message Subject: Hannes Tschofenig invited you to 'Finishing up design team' Conference Call Date: Sun, 08 Jul 2012 08:43:39 -0700 (PDT) From: Hannes Tschofenig (Google+) noreply-d883e...@plus.google.com Reply-To: Hannes Tschofenig (Google+) noreply-d883e...@plus.google.com Hannes Tschofenig invited you to 'Finishing up design team' Conference Call Tomorrow, July 9, 8:00 PM GMT+03:00 12 people invited As discussed at the last conference call we will try it with Google hangout this time instead of the conventional conference bridge. Date: 9th July 2012 (Monday) Time: 1pm EDT Agenda: We will do a status check on these documents: * draft-ietf-oauth-v2 * draft-ietf-oauth-v2-bearer * draft-ietf-oauth-v2-threatmodel * draft-ietf-oauth-urn-sub-ns * draft-ietf-oauth-assertions ___ 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
Re: [OAUTH-WG] 'Finishing up design team' Conference Call
I'll try to attend this. From: Hannes Tschofenig hannes.tschofe...@gmx.net To: OAuth WG oauth@ietf.org Sent: Sunday, July 8, 2012 11:03 AM Subject: [OAUTH-WG] 'Finishing up design team' Conference Call I don't know why Google Hangout does not forward my invitation to the oauth@ietf.org mailing list. So, send me private mail if you plan to participate. Original Message Subject: Hannes Tschofenig invited you to 'Finishing up design team' Conference Call Date: Sun, 08 Jul 2012 08:43:39 -0700 (PDT) From: Hannes Tschofenig (Google+) noreply-d883e...@plus.google.com Reply-To: Hannes Tschofenig (Google+) noreply-d883e...@plus.google.com Hannes Tschofenig invited you to 'Finishing up design team' Conference Call Tomorrow, July 9, 8:00 PM GMT+03:00 12 people invited As discussed at the last conference call we will try it with Google hangout this time instead of the conventional conference bridge. Date: 9th July 2012 (Monday) Time: 1pm EDT Agenda: We will do a status check on these documents: * draft-ietf-oauth-v2 * draft-ietf-oauth-v2-bearer * draft-ietf-oauth-v2-threatmodel * draft-ietf-oauth-urn-sub-ns * draft-ietf-oauth-assertions ___ 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
Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions
Aesthetically this makes my tummy hurt... That said, I think it will work, and I'm willing to go with it. From: Mike Jones michael.jo...@microsoft.com To: George Fletcher gffle...@aol.com Cc: oauth@ietf.org oauth@ietf.org Sent: Friday, June 15, 2012 10:30 AM Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions I was asked a question off-list, which I think is worth answering on-line. The question was: Why the Tab character, rather than %-encoding? Introducing % encoding would break all existing OAuth 2.0 deployments using HTTP Basic. A non-starter… Tab is legal in HTTP Basic but not in URLs or presently client_ids. It’s also a character that can be visibly rendered in an acceptable manner for debugging. The other choices were CR and LF, which are also legal in HTTP Basic but wouldn’t render very nicely. ;-) Cheers, -- Mike From:Mike Jones Sent: Friday, June 15, 2012 9:30 AM To: 'Eran Hammer' Cc: George Fletcher; oauth@ietf.org Subject: RE: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions I agree with Eran that I prefer that this not be underspecified and that an encoding for just colon for just Basic will suffice. I’d suggested the encoding s/:/tab/g as a strawman. Are there any other encoding proposals? -- Mike From:Eran Hammer [mailto:e...@hueniverse.com] Sent: Friday, June 15, 2012 9:26 AM To: Mike Jones Cc: George Fletcher; oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions We should not leave this under specified. Picking an encoding for just Basic and just colon is simple enough. EH On Jun 15, 2012, at 19:17, Mike Jones michael.jo...@microsoft.com wrote: Based on use cases I’m seeing, believe it’s important to allow the use of URIs as client_id values (which means allowing “:” in the client_id string). I’m OK with us either specifying a specific encoding when using them in Basic or simply saying that “When client_ids are used with HTTP Basic that contain characters such as “:” not allowed in HTTP Basic usernames, then the participants will need to agree upon a method of encoding the client_id for use with HTTP Basic. -- Mike From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher Sent: Friday, June 15, 2012 8:48 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions +1 for a simple encoding and allowing ':' in the client_id On 6/13/12 6:53 PM, Amos Jeffries wrote: On 14.06.2012 06:40, John Bradley wrote: That would probably work as well. That is why I am not particularly concerned about excluding the : We originally used the URI itself, mostly for convenience of debugging, but there are other potential options. The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work. Also a sha256 hash is probably longer than the uri it is hashing. I am not super concerned with being able to have : in the client_id John B. If I'm following all these threads correctly the only explicit problem with URI in client_id is HTTP username field being : terminated. As such it does not have to be a hash per-se, just an encoding that removes : and other reserved characters from the on-wire form *when sent via HTTP*. AYJ ___ 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 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
Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
I agree generally with your assumption about clients, but rather than saying clients are devices I think it makes much more sense to say clients are NOT users, so client_id need not be internationalized. In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id. -bill From: Hannes Tschofenig hannes.tschofe...@gmx.net To: Julian Reschke julian.resc...@gmx.de Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions): http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client_secret) With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more options. One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote: On 2012-06-12 00:16, Mike Jones wrote: Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, should be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic. I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them. Therefore, I'd like to propose these updated ABNF definitions: VSCHAR = %20-7E NOCOLONVSCHAR = %x20-39 / %x3B-7E UNICODENOCTRLCHAR = Any Unicode character other than ( %x0-1F / %x7F ) client-id = *NOCOLONVSCHAR client_secret = *VSCHAR username = *UNICODENOCTRLCHAR password = *UNICODENOCTRLCHAR In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time). It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified. I'll send a separate mail about that, the current text in the spec is way too unspecific. -- Mike P.S. If anyone has a better ABNF for UNICODENOCTRLCHAR than Any Unicode character other than ( %x0-1F / %x7F ), please send it to me! As noted before, here's an example: http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1 Best regards, Julian ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions
I think dynamic client registration is something we have not talked out enough yet. There's a pretty clear use case for dynamic registration. Does identifying the client with a URI allow some form of OpenID-ish flow for this? Is the client ID as a URI a way to allow a trusted site to provide metadata about the client? Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret? I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing. -bill From: Eran Hammer e...@hueniverse.com To: Mike Jones michael.jo...@microsoft.com; William Mills wmi...@yahoo-inc.com; Hannes Tschofenig hannes.tschofe...@gmx.net; Julian Reschke julian.resc...@gmx.de Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, June 12, 2012 11:39 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means. I just want to make sure those thinking about more complex use cases involving dynamic registration or distributed client manamgenet are aware of this potential restriction. I'm fine either way. EH From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard. For instance, neither “scope” nor “error” allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it. Then there’s no possibility of misunderstanding the intent of suggested changes. Thanks all, -- Mike From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I agree generally with your assumption about clients, but rather than saying clients are devices I think it makes much more sense to say clients are NOT users, so client_id need not be internationalized. In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id. -bill From:Hannes Tschofenig hannes.tschofe...@gmx.net To: Julian Reschke julian.resc...@gmx.de Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions): http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client_secret) With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more options. One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter. Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret? Here we have the possibility to define something better. In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails. Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism? Ciao Hannes On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote
Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions
Is it workable/useful then to define something like: basic_client_id = 1*basic_auth_allowed_characters uri_client_id = 1*uri_allowed_characters And include text saying, Clients using HTTP Basic authentication MUST have a client_id of type basic_client_id. Clients using client_id of type uri_client_id MUST NOT use HTTP Basic client authentication.? -bill From: Eran Hammer e...@hueniverse.com To: George Fletcher gffle...@aol.com Cc: Mike Jones michael.jo...@microsoft.com; William Mills wmi...@yahoo-inc.com; Hannes Tschofenig hannes.tschofe...@gmx.net; Julian Reschke julian.resc...@gmx.de; oauth@ietf.org oauth@ietf.org Sent: Tuesday, June 12, 2012 11:57 AM Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions Encoding is an option which does not require us to address it. Those seeking to use URIs can simply specify that. However, Julian indicated earlier that this restriction in Basic may change, in which case we can reference Basic and simply add an interop warning (like the one we have for redirections including a fragment) about it. EH From:George Fletcher [mailto:gffle...@aol.com] Sent: Tuesday, June 12, 2012 11:44 AM To: Eran Hammer Cc: Mike Jones; William Mills; Hannes Tschofenig; Julian Reschke; oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I agree that there is value in allowing the client_id to be a URI. The problem is that the ':' of the URI is not allowed in HTTP Basic which is required by the OAuth2 spec for client authentication. We could encode the client_id before HTTP Basic but that needs to be documented and adds complexity. Thanks, George On 6/12/12 2:39 PM, Eran Hammer wrote: Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means. I just want to make sure those thinking about more complex use cases involving dynamic registration or distributed client manamgenet are aware of this potential restriction. I'm fine either way. EH From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, June 12, 2012 11:27 AM To: William Mills; Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard. For instance, neither “scope” nor “error” allow non-ASCII characters. Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it. Then there’s no possibility of misunderstanding the intent of suggested changes. Thanks all, -- Mike From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Tuesday, June 12, 2012 11:18 AM To: Hannes Tschofenig; Julian Reschke Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I agree generally with your assumption about clients, but rather than saying clients are devices I think it makes much more sense to say clients are NOT users, so client_id need not be internationalized. In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way. I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id. -bill From:Hannes Tschofenig hannes.tschofe...@gmx.net To: Julian Reschke julian.resc...@gmx.de Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, June 12, 2012 11:01 AM Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions I had a chat with Julian yesterday and here is my short summary. Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions): http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3 1) HTTP Basic Authentication 2) A custom OAuth authentication mechanism (which uses client_id and client_secret) With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support. With our brand new custom OAuth authentication mechanism we have more options. One possible
Re: [OAUTH-WG] New draft process / editor role
+1 From: Anthony Nadalin tony...@microsoft.com To: Eran Hammer e...@hueniverse.com; oauth@ietf.org WG (oauth@ietf.org) oauth@ietf.org Sent: Friday, June 8, 2012 7:18 PM Subject: Re: [OAUTH-WG] New draft process / editor role Why rant here, talk to the chairs or AD Sent from my Windows Phone From: Eran Hammer Sent: 6/8/2012 6:58 PM To: oauth@ietf.org WG (oauth@ietf.org) Subject: [OAUTH-WG] New draft process / editor role Today, a new draft of the OAuth 2.0 specification was published. * I had nothing to do with this draft. I did not edit or authored it. I didn't know it was being published. * The draft was authored by Mike Jones and published by Dick Hardt. * Neither one is an editor or an active author of the document. Here are the facts: * On 5/31 Hannes asked me to publish a new draft with the proposed changes posted by Mike by Sunday 6/3 (within 3 days). The chairs did not offer any reason for requesting such a quick turnaround. It took the chairs weeks to respond to me about the request for ABNF or error text. There wasn't any urgency when it was their task. * I promptly replied that I plan to wait until the ABNF is completed before publishing a new draft. The ABNF, which is the only pending DISCUSS for the core specification, is still being actively debated on the list and was clearly presented as work in progress. * Hannes did not reply back with any other instructions. * Mike replied back trying to speak on behalf of the chairs, suggesting that 'version numbers are cheap'. I replied that my time isn't. * At no point did any of the chairs indicated any issue with my publication schedule. The full thread is here: http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html. * Today, using Dick Hardt author credit on the document, Mike published his draft. There is no indication that changes were made by someone other than the editor or that the added sections are still a work in progress and pending consensus as is WG practice (e.g. [[ Pending Consensus ]] or [[ Proposed Text]]). * No one has offered any explanation as to why the editor was pushed aside and blindsided with a new draft. There was no communication or any attempt to from the chairs, Mike, Dick, or anyone else. * After posting the new draft, Mike emailed the IESG to resolve a pending DISCUSS item on the core specification, something that is clearly my role and handled by me so far. I was not included in the email list but received a copy through the tracker system as author. Publishing a new draft must be done by a listed author. The only reason Dick and David are listed is historical in regognition of their initial contribution. Both David and Dick offered to remove their name from the top credits in the past (the reason Dick gave at the time was that the document was clearly my work). Using the author credit as a way to sidestep the editor is within the chairs right but that doesn't make it right. I have done absolutely nothing to justify taking the document editorial work from me, even temporarily. I have tirelessly published 26 drafts of this documenty. I have been working on this specification for almost 5 years. While the chairs can certainly decide who gets to edit and publish new drafts, there was no reason to do this here, and typically this is done when an editor is unresponsive and has to be removed. In this case, it was the chairs who were unresponsive and uncommunicative. They didn't think to even give me the courtesy of a head up. It is not clear to me what my standing is at this point with regard to this document. I will wait for further information from the AD to decide how to proceed. EH ___ 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
Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested
I will not be attending in person, but will probably attend by conference call. -bill From: Hannes Tschofenig hannes.tschofe...@gmx.net To: oauth@ietf.org WG oauth@ietf.org Sent: Saturday, June 2, 2012 12:46 AM Subject: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested Hi all, I have requested a 2,5 hour slot for the upcoming meeting. While the next meeting is still a bit away it is nevertheless useful to hear * whether you plan to attend the next meeting, and * whether you want to present something. I could imagine that these documents will be discussed: * draft-ietf-oauth-dyn-reg * draft-ietf-oauth-json-web-token * draft-ietf-oauth-jwt-bearer * draft-ietf-oauth-revocation * draft-ietf-oauth-use-cases To the draft authors of these docuemnts: Please think about the open issues and drop a mail to the list so that we make some progress already before the face-to-face meeting. I am assume that the following documents do not require any discussion time at the upcoming IETF meeting anymore: * draft-ietf-oauth-assertions * draft-ietf-oauth-saml2-bearer * draft-ietf-oauth-urn-sub-ns * draft-ietf-oauth-v2 * draft-ietf-oauth-v2-bearer Ciao Hannes ___ 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
Re: [OAUTH-WG] ABNF elements for suggested WG review
We've definitely needed full ABNF, this is good. I don't like the habit of multiple definitions for the same character sets though. Things like %x21 / %x23-5B / %x5D-7E should be named once and re-used. From: Mike Jones michael.jo...@microsoft.com To: oauth@ietf.org oauth@ietf.org Sent: Saturday, June 2, 2012 1:10 AM Subject: [OAUTH-WG] ABNF elements for suggested WG review Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the syntax of a number of the OAuth protocol elements had not been previously defined. (Thanks, Sean, for having us do this!) I took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that the working group actively review the choices in my proposed draft. For instance, I chose to use the same syntax definitions for username and password and client_id and client_secret as HTTP Basic used for userid and password. Other choices were possible, such as perhaps limiting client_id and possibly username values to use “unreserved” characters, rather than allowing all characters other than “:” (as HTTP Basic did with userid). Please particularly review the syntax definitions for these elements, as I had to make choices that went beyond the current specs to provide unambiguous syntax definitions: client_id client_secret state code access_token username password refresh_token The full proposed ABNF section follows. -- Mike Appendix A. Augmented Backus-Naur Form (ABNF) Syntax This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. Elements are presented in the order first defined. Some of the definitions that follow use the unreserved and URI definitions from [RFC3986], which are: unreserved = ALPHA / DIGIT / - / . / _ / ~ URI = scheme : hier-part [ ? query ] [ # fragment ] Some of the definitions that follow use the b64token syntax below, which matches the b64token syntax defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: b64token = 1*( ALPHA / DIGIT / - / . / _ / ~ / + / / ) *= A.1. client_id Syntax The client_id element is defined in Section 2.3.1: client-id = *TEXT excluding : (This matches the userid definition in the HTTP Basic Authentication Scheme [RFC2617].) A.2. client_secret Syntax The client_secret element is defined in Section 2.3.1: client-secret = *TEXT (This matches the password definition in the HTTP Basic Authentication Scheme [RFC2617].) A.3. response_type Syntax The response_type element is defined in Section 3.1.1 and Section 8.4: response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = _ / DIGIT / ALPHA A.4. scope Syntax The scope element is defined in Section 3.3: scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) A.5. state Syntax The state element is defined in Section 4.1.1, Section 4.1.2, Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: state = 1*unreserved A.6. redirect_uri Syntax The redirect_uri element is defined in Section 4.1.1, Section 4.1.3, and Section 4.2.1: redirect-uri = URI A.7. error Syntax The error element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, Section 7.2, and Section 8.5: error = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E A.8. error_description Syntax The error_description element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-description = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E A.9. error_uri Syntax The error_uri element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-uri = URI A.10. grant_type Syntax The grant_type element is defined in Section 4.1.3, Section 4.3.2, Section 4.4.1, Section 6, and Section 4.5: grant-type = grant-name / URI grant-name = 1*name-char name-char = - / . / _ / DIGIT / ALPHA A.11. code Syntax The code element is defined in Section 4.1.3: code = 1*unreserved A.12. access_token Syntax The access_token element is defined in Section 4.2.2 and Section 5.1: access-token = b64token A.13. token_type Syntax The token_type element is defined in Section 4.2.2, Section 5.1, and Section 8.1: token-type = type-name / URI type-name = 1*name-char name-char = - / . / _ / DIGIT / ALPHA A.14. expires_in Syntax The
Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method
And yet, the security properties of query parameters make them not ideal for credentials. From a security perspective it is hard to justify recommending it. From: David Recordon record...@gmail.com To: Mark Nottingham m...@mnot.net; Eran Hammer e...@hueniverse.com; Mike Jones michael.jo...@microsoft.com Cc: Julian Reschke julian.resc...@gmx.de; oauth@ietf.org oauth@ietf.org Sent: Thursday, May 24, 2012 12:11 AM Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method Regardless of how we got here, just feels strange to have a strong recommendation against the way the protocol is actually being used. I completely understand that standards live on for well over eighteen months (or five years if we start with OAuth 1.0) but this feels like we're just going to end up with the vast majority of deployments doing what the standard explicitly recommends against. Query parameters are used because they're easy and implementor simplicity was always something driving design decisions. So at least to me this is not the path toward a widely deployed standard. --David On Thu, May 24, 2012 at 12:02 AM, Mike Jones michael.jo...@microsoft.com wrote: My recollection is that putting it in an appendix was explicitly rejected in the threads discussing the DISCUSS issues and no one on those threads pushed back afterwards, particularly after Dick's explanations of why it should stay. (Why these DISCUSS discussions don't include the full working group is a mystery to me, but apparently that's the way it's done at this stage of the IETF spec finalization process. Can anyone tell me why that's the case?) Anyway, since this feature has been in *every* version of the spec, leaving it in hardly seemed to require a consensus call. The chairs, of course, can obviously hold one if they believe one is called for. Best wishes, -- Mike -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Wednesday, May 23, 2012 11:54 PM To: Eran Hammer Cc: Mike Jones; Julian Reschke; oauth@ietf.org Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method Thanks, Eran - I was just about to ask about that. On 24/05/2012, at 4:53 PM, Eran Hammer wrote: I don't care about this either way, but 'explicitly rejected' is an over-reach. I have not seen the chairs make a consensus call about that, or even formally ask the list. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Wednesday, May 23, 2012 11:49 PM To: Julian Reschke Cc: Mark Nottingham; oauth@ietf.org Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method Yes, putting the query parameter method into an appendix was considered and explicitly rejected. Dick Hardt wrote about these issues in the discussions that led to this decision, and I'll take the liberty of quoting him, as I believe he explained it well: The reality is that the world is a messy place. Developers hack the architecture to accomplish goals not envisioned by the architects. The architects can accept the reality of the world, or ignore it and lose their relevance. In my opinion, putting the query parameter mechanism into an appendix is ignoring the reality of current implementations. Adding language to the spec that use of the query parameter is not architecturally ideal, but accepts the reality of the current web would be far more preferable. Many sites with substantial security expertise (Google, Facebook, LinkedIn, Foursquare) have chosen to use the query parameter as opposed to the header - both methods have been documented in the drafts since the beginning. Clearly from a practical point of view the implementers have chosen to use the query parameter. I have read people proposing dropping it from the spec or pushing it to an Appendix. I agree that the security issues need to be documented and the architectural issues called out. I think dropping it from the spec or pushing it to an appendix is a disservice to implementers and sends a message that the IETF is not in touch with the realities of the web. -- Mike -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Wednesday, May 23, 2012 11:36 PM To: Mike Jones Cc: oauth@ietf.org; Mark Nottingham Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method On 2012-05-18 09:15, Julian Reschke wrote: ... Did you consider to *also* move the whole section into an appendix, so that it's status is also reflected by the document structure? Best regards, Julian Hi, it would be awesome to see feedback on this (it has been mentioned during IETF LC multiple times).
Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method
wfm From: Mike Jones michael.jo...@microsoft.com To: oauth@ietf.org oauth@ietf.org Cc: Mark Nottingham m...@mnot.net Sent: Thursday, May 17, 2012 3:11 PM Subject: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method Dear working group members: I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved. This DISCUSS had been raised about the URI Query Parameter method: * Section 2.3 URI Query Parameter This section effectively reserves a URI query parameter for the draft's use. This should not be done lightly, since this would be a precedent for the IETF encroaching upon a server's URIs (done previously in RFC5785, but in a much more limited fashion, as a tactic to prevent further, uncontrolled encroachment). Given that the draft already discourages the use of this mechanism, I'd recommend dropping it altogether. If the Working Group wishes it to remain, this issues should be vetted both through the APPS area and the W3C liaison. I wanted to let you know that the agreed-upon resolution to this issue is to add the following text to the URI Query Parameter section: This method is included to document current use; its use is NOT RECOMMENDED, both due to its security deficiencies (see Security Considerations) and because it uses a reserved query parameter name, which is counter to URI namespace best practices [W3C TAG WebArch]. The reference above is to http://www.w3.org/TR/webarch/. Thanks to Mark Nottingham, Stephen Farrell, Pete Resnick, and Dick Hardt for helping us get to this resolution. Cheers, -- 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
Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
Yeah, unfortunately the WWW-Authenticate solution advertising an AS has bad (fatal) security problems. That's the underlying reason/urgency behind a separate services discovery mechanism. It's not that we ignored WWW-Authenticate, and in fact I'm in process of ripping that mechanism out of a draft I'm working on. This is not hard when the protected resource or user identifier is in a domain where WebFinger (WF) will work. The problem comes when we have, for example, N email domain names all served by the same AS, and you have to discover that way. The solution there may be that you take an indirect path through the MX record (one suggestion), determine the domain from that, and do the WF lookup based on the MX domain. For arbitrary webservices running on a domain where they can't run their own WF endpoint we don't yet have a solution. At some point the client may well be expected to know somehting about the identity it expects to use for a site. -bill From: Manger, James H james.h.man...@team.telstra.com To: Sergey Shishkin sergei.shish...@gmail.com; oauth@ietf.org oauth@ietf.org Sent: Tuesday, May 15, 2012 10:30 PM Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request Sergey, A hypermedia-driven (RESTful) API should be able to use OAuth. Unfortunately, OAuth does not have a RESTful design. Most APIs require client apps (not just the user) to be pre-registered with the service. That seems to have made hypermedia-driven design less important — if a client app has to explicitly register with a service it may as well learn details like the authorization URI at registration time as well. A WWW-Authenticate response header that identifies an authorization server (AS) would be a great hypermedia-driven solution. It tells the client app which AS a service trusts. The client app can then get a token. Before sending a AS-issued token to the original service the client app needs to know the AS trusts that service. Unfortunately this detail is missing from OAuth: tokens are issued with no indication of where they can safely be used [http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.4]. -- James Manger From:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Wednesday, 16 May 2012 3:45 AM To: Sergey Shishkin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request The danger is a bad resource, If that can redirect the client to a arbitrary AS to phish the resource owner's credentials that is a bad thing. The presumption is that the client knows where the trusted AS for that resource is, and if it needs to discover it that is a much bigger issue. In the IMAP case the client probably needs to do discovery on the identifier itself to figure out where to send the user. John B. On 2012-05-15, at 1:18 PM, Sergey Shishkin wrote: Bill, it might be me misreading the Implicit Grant Flow, but I understood it like this: 1. client tries to get a resource from server; 2. server redirects client to auth-service; 3. client authenticates against auth-service (HTTP Basic or whatever); 4. auth-service redirects client back to the resource; 5. client tries to get the resource providing the token. In step 3 the client is of course responsible for protecting its password from phishing, so auth-service should authenticate itself with a certificate. Am I right? If, yes my idea was to use this flow while choosing a standardized token - Bearer. But Bearer insists on 401 instead of redirects and that confused me. Sergey On Tue, May 15, 2012 at 6:24 PM, William Mills wmi...@yahoo-inc.com wrote: You can hard configure it into your client, that's safe. The problem comes when the client can be sent to an arbitrary, possibly phishing, site to do authentication. If the client supports the password grant then it probably just hands in the username and password without user interaction. -bill From:Sergey Shishkin sergei.shish...@gmail.com To:William Mills wmi...@yahoo-inc.com Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, May 15, 2012 9:09 AM Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request In my scenario I control both the resource provider and the token issuer and I'm fine with the resource provider knowing the issuer. So, discovery is not needed. Or do I miss something? On Tue, May 15, 2012 at 6:04 PM, William Mills wmi...@yahoo-inc.com wrote: Yes, what you're running across here is the discovery problem. How do you discover the authentication endpoints for a service. Unfortunately it turns out returning that as part of the 401 has big security concerns. It's still being figured out. From:Sergey Shishkin sergei.shish...@gmail.com To: oauth@ietf.org Sent: Tuesday, May 15, 2012 5:12 AM Subject: [OAUTH-WG
Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
The problem is the password grant. Clients that support it would potentially deliver the username and password without asking the user, or by prompting in the UI itself and not through a web interaction with the AS. From: Manger, James H james.h.man...@team.telstra.com To: William Mills wmi...@yahoo-inc.com; oauth@ietf.org oauth@ietf.org Sent: Wednesday, May 16, 2012 5:55 AM Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request Bill, A WWW-Authenticate response header that identifies an authorization server (AS) would be a great hypermedia-driven solution. It tells the client app which AS a service trusts. The client app can then get a token. ... Yeah, unfortunately the WWW-Authenticate solution advertising an AS has bad (fatal) security problems. Is phishing the fatal security problem? It doesn't sound quite like normal phishing. Are there still fatal problems if phishing-resistant user authentication mechanisms are used? I would really appreciate any further explanation (or pointers to explanations). That's the underlying reason/urgency behind a separate services discovery mechanism. It's not that we ignored WWW-Authenticate, and in fact I'm in process of ripping that mechanism out of a draft I'm working on. This is not hard when the protected resource or user identifier is in a domain where WebFinger (WF) will work. Is this because we assume a domain controls its webfinger URI, but we don't want to assume a domain controls all its other URIs (perhaps because some will serve user-generated content)? The problem comes when we have, for example, N email domain names all served by the same AS, and you have to discover that way. The solution there may be that you take an indirect path through the MX record (one suggestion), determine the domain from that, and do the WF lookup based on the MX domain. This doesn't sound like Sergey’s situation where the client app has made a web request -- so it knows the URI it wants. For arbitrary webservices running on a domain where they can't run their own WF endpoint we don't yet have a solution. At some point the client may well be expected to know something about the identity it expects to use for a site. Could you clarify the identity it expects to use for a site? I'm not sure if this is talking about the user's identity, the client app's identity or the site's identity. -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC Token draft
I think there is a need for a signed token style OAuth 2 scheme, and MAC fills this niche, although holder-of-key (as yet un-drafted) would also do this nicely. Is MAC going to get picked up and driven to completion? Do others feel this token style (and security properties) are needed? Or am I alone in this? -bill From: Eran Hammer e...@hueniverse.com To: oauth@ietf.org WG (oauth@ietf.org) oauth@ietf.org Sent: Tuesday, May 15, 2012 6:41 PM Subject: [OAUTH-WG] MAC Token draft I am stepping down from my role as editor of the MAC token specification. I do not intend to participate in this work moving forward. I will forward my notes to the next editor if requested. EH ___ 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
Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
The problem is not with the auth servers, it's with clients that support password grant. If they trust info sent to them by a resource server they will give up the goods. From: Manger, James H james.h.man...@team.telstra.com To: William Mills wmi...@yahoo-inc.com; oauth@ietf.org oauth@ietf.org Sent: Wednesday, May 16, 2012 5:33 PM Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request The problem is the password grant. This doesn’t sound like a good reason to ditch AS discovery via an WWW-Authenticate response header. Client apps using the password grant are only a subset of OAuth clients, and a specialized subset at that. The spec [draft-ietf-oauth-v2-26#section-4.3] says the “authorization server should take special care when enabling this grant type, and only allow it when other flows are not viable”. Just tell those few “highly privileged” client apps using the password grant not to use AS discovery via an WWW-Authenticate response if it is a problem (though I’m not sure it is any worse than a resource returning WWW-Authenticate: BASIC ... to trigger the password being sent?). -- James Manger From:William Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, 17 May 2012 12:29 AM To: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request The problem is the password grant. Clients that support it would potentially deliver the username and password without asking the user, or by prompting in the UI itself and not through a web interaction with the AS. From:Manger, James H james.h.man...@team.telstra.com To: William Mills wmi...@yahoo-inc.com; oauth@ietf.org oauth@ietf.org Sent: Wednesday, May 16, 2012 5:55 AM Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request Bill, A WWW-Authenticate response header that identifies an authorization server (AS) would be a great hypermedia-driven solution. It tells the client app which AS a service trusts. The client app can then get a token. ... Yeah, unfortunately the WWW-Authenticate solution advertising an AS has bad (fatal) security problems. Is phishing the fatal security problem? It doesn't sound quite like normal phishing. Are there still fatal problems if phishing-resistant user authentication mechanisms are used? I would really appreciate any further explanation (or pointers to explanations). That's the underlying reason/urgency behind a separate services discovery mechanism. It's not that we ignored WWW-Authenticate, and in fact I'm in process of ripping that mechanism out of a draft I'm working on. This is not hard when the protected resource or user identifier is in a domain where WebFinger (WF) will work. Is this because we assume a domain controls its webfinger URI, but we don't want to assume a domain controls all its other URIs (perhaps because some will serve user-generated content)? The problem comes when we have, for example, N email domain names all served by the same AS, and you have to discover that way. The solution there may be that you take an indirect path through the MX record (one suggestion), determine the domain from that, and do the WF lookup based on the MX domain. This doesn't sound like Sergey’s situation where the client app has made a web request -- so it knows the URI it wants. For arbitrary webservices running on a domain where they can't run their own WF endpoint we don't yet have a solution. At some point the client may well be expected to know something about the identity it expects to use for a site. Could you clarify the identity it expects to use for a site? I'm not sure if this is talking about the user's identity, the client app's identity or the site's identity. -- James Manger ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
Yes, what you're running across here is the discovery problem. How do you discover the authentication endpoints for a service. Unfortunately it turns out returning that as part of the 401 has big security concerns. It's still being figured out. From: Sergey Shishkin sergei.shish...@gmail.com To: oauth@ietf.org Sent: Tuesday, May 15, 2012 5:12 AM Subject: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request While designing a hypermedia-driven API I'm evaluating possibilities to use OAuth Bearer tokens for claims-based authorization. Currently I struggle with how to communicate to the API client the way to obtain the token. In a hypermedia-driven manner I don't want the API client to get this information out of band, but rather let the client just follow the links. The Bearer draft [http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-3] advises to send a 401 response with a WWW-Authenticate challenge specifying optional realm and scope. The problem here: neither realm nor scope identify the token issuer. The OAuth 2.0 draft [http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.1] suggests to redirect the resource owner to the token issuer, IIRC. I like this way from the hypermedia perspective, but still have mixed feelings about missed 401 and WWW-Authenticate challenge. Did I missed some part of draft covering my scenario? Are there any known grassroots implementations doing just that on the internet? Any opinion on the subject is very much appreciated. Thanks in advance, Sergey ___ 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
Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
You can hard configure it into your client, that's safe. The problem comes when the client can be sent to an arbitrary, possibly phishing, site to do authentication. If the client supports the password grant then it probably just hands in the username and password without user interaction. -bill From: Sergey Shishkin sergei.shish...@gmail.com To: William Mills wmi...@yahoo-inc.com Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, May 15, 2012 9:09 AM Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request In my scenario I control both the resource provider and the token issuer and I'm fine with the resource provider knowing the issuer. So, discovery is not needed. Or do I miss something? On Tue, May 15, 2012 at 6:04 PM, William Mills wmi...@yahoo-inc.com wrote: Yes, what you're running across here is the discovery problem. How do you discover the authentication endpoints for a service. Unfortunately it turns out returning that as part of the 401 has big security concerns. It's still being figured out. From: Sergey Shishkin sergei.shish...@gmail.com To: oauth@ietf.org Sent: Tuesday, May 15, 2012 5:12 AM Subject: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request While designing a hypermedia-driven API I'm evaluating possibilities to use OAuth Bearer tokens for claims-based authorization. Currently I struggle with how to communicate to the API client the way to obtain the token. In a hypermedia-driven manner I don't want the API client to get this information out of band, but rather let the client just follow the links. The Bearer draft [http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-3] advises to send a 401 response with a WWW-Authenticate challenge specifying optional realm and scope. The problem here: neither realm nor scope identify the token issuer. The OAuth 2.0 draft [http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.1] suggests to redirect the resource owner to the token issuer, IIRC. I like this way from the hypermedia perspective, but still have mixed feelings about missed 401 and WWW-Authenticate challenge. Did I missed some part of draft covering my scenario? Are there any known grassroots implementations doing just that on the internet? Any opinion on the subject is very much appreciated. Thanks in advance, Sergey ___ 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
Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to know
Kitten is in the CC list because this applies to the discovery needs of the OAUTH SASL draft. From: SM s...@resistor.net To: Justin Richer jric...@mitre.org Cc: kit...@ietf.org; oauth@ietf.org Sent: Friday, May 11, 2012 12:19 AM Subject: Re: [OAUTH-WG] [kitten] OAuth Discovery and what the relying partyneeds to know Hi Justin, [not sure why kitten@ is in the Cc. Feel free to drop] At 08:15 10-05-2012, Justin Richer wrote: user@domain represents a person. SMTP, XMPP, SIP, and other protocols have used this format successfully. OpenID made the mistake of trying to teach people that http://domain/user could also stand for them, but people just don't think of themselves in terms of HTTP URLs. Webfinger came about to address this, and SWD adopted The strings industry probably have some reason to believe that people think of themselves in terms of domain names. Some people think of the other person in terms of what's your [insert social network]?. There are several specifications which reference rfc822 identifiers. The interesting point in the above is what will be people's expected behavior while taking into account the usual technical limitations. Regards, -sm ___ 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
Re: [OAUTH-WG] IPR on OAuth bearer
Is it correct to say that the IPR in question touched the portion of Bearer that deals with allowing the token in the URL, and that tokens in the Auth header and tokens in POST body? If so, then for me this issue is another reason not to use tokens in the URL, which I would already recommend against for several reasons. We would not use this in our own implementations. -bill From: Sam Hartman hartmans-i...@mit.edu To: Michael Thomas m...@mtcc.com Cc: oauth@ietf.org WG oauth@ietf.org Sent: Wednesday, May 9, 2012 2:45 PM Subject: Re: [OAUTH-WG] IPR on OAuth bearer So, here are statements that you could make as part of this discussion that would be entirely in scope: 1) I've read the IPR. Prior to this disclosure I was interested in developing|deploying|shipping an implementation of this specification. Now I am not. 2) I think you could go so far as to say. Based on this IPR I would no longer feel comfortable making an open-source implementation of this spec available. 3) Or on the other side: I've reviewed this new IPR and I believe I could implement|ship|deploy|whatever this specification. Or if you don't like giving out as much information as 1-3: 4) I've reviewed the new IPr and I recommend that we not advance this standard 5) I've reviewed the IPR and I do recommend we advance. Obviously, people may weigh statements of the form 1-3 with more value than 4-5. However it's really hard to get many organizations to say something in the 1-3 range. Other valid things to say in such a context include: 6) We've successfully obtained any licenses we believe that we need in order to implement this specification given the IPR. 7) We attempted to obtain the licenses we needed in order to implement given this IPR but were unsuccessful. believe all the above statements are acceptable. In particular, none of them comment on the validity of the IPR nor give legal advice about stuff. I believe you could even go so far as to say something like I believe that an open-source implementation of this technology is|is not important to whether we should standardize it. I believe we've come very close to that in the past. ___ 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
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
So you are guaranteeing that there are no clients using WF today? From: Mike Jones michael.jo...@microsoft.com To: Paul E. Jones pau...@packetizer.com; 'Murray S. Kucherawy' m...@cloudmark.com; oauth@ietf.org oauth@ietf.org; 'Apps Discuss' apps-disc...@ietf.org Sent: Thursday, April 19, 2012 10:48 PM Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) To be clear, making this mandatory would break no clients. It would require updating some servers, just as requiring JSON would. This seems like a fair tradeoff when it makes an appreciable difference in user interface latency in some important scenarios. If you and the other key WebFinger supporters can agree to making resource support mandatory and requiring JSON, I believe we may have a path forward. Cheers, -- Mike -Original Message- From: Paul E. Jones [mailto:pau...@packetizer.com] Sent: Thursday, April 19, 2012 10:39 PM To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) That's correct. We could certainly make it mandatory, but the reason it isn't is to maintain backward compatibility with existing deployments. I think we should always think carefully when we decide to make a change that breaks backward-compatibility. This is one change that would do that. Paul -Original Message- From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Friday, April 20, 2012 1:10 AM To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Currently, support for the resource parameter is optional, as per the following (correct?): Note that support for the resource parameter is optional, but strongly RECOMMENDED for improved performance. If a server does not implement the resource parameter, then the server's host metadata processing logic remains unchanged from RFC 6415. To truly support 1, this would need to be changed to REQUIRED, correct? -- Mike -Original Message- From: Paul E. Jones [mailto:pau...@packetizer.com] Sent: Thursday, April 19, 2012 8:16 PM To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss' Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) Mike, There are two criteria that I would consider to be essential requirements for any resulting general-purpose discovery specification: 1. Being able to always discover per-user information with a single GET (minimizing user interface latency for mobile devices, etc.) WF can do that. See: $ curl -v https://packetizer.com/.well-known/\ host-meta.json?resource=acct:pau...@packetizer.com 2. JSON should be required and it should be the only format required (simplicity and ease of deployment/adoption) See the above example. However, I also support XML with my server. It took me less than 10 minutes to code up both XML and JSON representations. Once the requested format is determined, the requested URI is determined, data is pulled from the database, spitting out the desired format is trivial. Note, and very important note: supporting both XML and JSON would only be a server-side requirement. The client is at liberty to use the format it prefers. I would agree that forcing a client to support both would be unacceptable, but the server? Nothing to it. SWD already meets those requirements. If the resulting spec meets those requirements, it doesn't matter a lot whether we call it WebFinger or Simple Web Discovery, but I believe that the requirements discussion is probably the most productive one to be having at this point - not the starting point document. I believe WebFinger meets those requirements. We could debate whether XML should be supported, but I'll note (again) that it is there in RFC 6415. That document isn't all that old and, frankly, it concerns me that we would have a strong preference for format A one week and then Format B the next. We are where we are and I can see reason for asking for JSON, but no good reason to say we should not allow XML (on the server side). Paul ___ 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
Re: [OAUTH-WG] Best-Practice for dealing with OAuth 2.0 Token expiration at the Consumer
Scope having actual meaning to the client (you usage of 'offline' is what I'm looking at) is something you can define but is not something currently in the protocol. I think it's a simpler picture than you are painting: 1) You might get a hint with the expires_in value for when the token will expire. The client can refresh based on that. 2) If you get an access token failure, then if you have a refresh token you try to get a new access token. 3) If your refresh token fails (not authorized) to get you a new access token, then you have to re-authenticate. HTTP temporary failures and such get retried. Clients basically have to support that logic flow. From: Andreas Åkre Solberg andreas.solb...@uninett.no To: oauth@ietf.org Sent: Thursday, April 19, 2012 1:29 AM Subject: [OAUTH-WG] Best-Practice for dealing with OAuth 2.0 Token expiration at the Consumer Please give me feedback if I got anything wrong, or if you have comments. https://rnd.feide.no/2012/04/19/best-practice-for-dealing-with-oauth-2-0-token-expiration-at-the-consumer/ Kind regards, Andreas Åkre Solberg UNINETT ___ 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
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
I would characterize it as two distinct camps, folks that think WF can be updated to do what SWD (growing contingent I think) does and folks that are invested in SWD. I haven't seen any movement between those two camps, specifically that the SWD folks think WF can in fact solve their problem if updated. -bill From: Murray S. Kucherawy m...@cloudmark.com To: oauth@ietf.org WG oauth@ietf.org; Apps Discuss apps-disc...@ietf.org Sent: Thursday, April 19, 2012 9:32 AM Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD) By all means people should correct me if they think I'm wrong about this, but so far from monitoring the discussion there seems to be general support for focusing on WebFinger and developing it to meet the needs of those who have deployed SWD, versus the opposite. Does anyone want to argue the opposite? -MSK, appsawg co-chair ___ 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
Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
Various additional anti-abuse controls can be applied like CAPTCHA if you have a full browser to leverage. Much harder to get that flexibility in a fixed client UI. From: Paul Madsen paul.mad...@gmail.com To: adam.le...@motorolasolutions.com; jric...@mitre.org Cc: oauth@ietf.org Sent: Thursday, April 19, 2012 3:03 PM Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token Using the browser as part of the AS interaction allows you to more easily collect the users consent. Once you get the tokens based on that consent, everything is 'RESTful' Original message Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token From: Lewis Adam-CAL022 adam.le...@motorolasolutions.com To: Justin Richer jric...@mitre.org CC: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token Hi Justin, There is one thing I have not understood about the whole external browser vs. embedded browser guidance … and that is, why is *any* browser needed? Java for example has an HTTP library, and OAuth is RESTful. So why is it necessary to require the web browser at all, whether external or embedded? Why can’t my native client make RESTful API calls to the AS and RS natively? Tx! adam From:Justin Richer [mailto:jric...@mitre.org] Sent: Friday, April 13, 2012 11:38 AM To: Lewis Adam-CAL022 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token If the mobile device has a web browser (such as a smart phone), then this is pretty easy, and you've got a couple of options. One of the best options when the token is on behalf of an end user is, in my opinion, to use the authorization code flow like this: First, register what's called a public client with your server -- so you'll get an ID but not a client secret. With that client ID, register a custom-scheme callback URI, like myapp://oauthcallback, and register your app on the device as the handler for myapp. In your application, to start things off, you fire off a web browser to the authorization server's authorization endpoint. The user logs in to the authorization server through the web browser, approves this copy of your app, and gets redirected to myapp://oauthcallback?code=basdf132. Your app grabs the myapp:// url and plucks the authorization code off the end of it. Your app then takes that code and sends it in the background to the token endpoint to exchange for a token. Some key points: 1) You need to have access to a web browser on the platform, and it's considered best practice to push the user to the external browser application on the platform instead of embedding one. There are a couple paragraphs in the spec's security considerations section that talk about this. 2) Your app is public because you can't publish it with a secret at configuration time. It can, however, keep the tokens secret at runtime. 3) You need to be very careful with how you store the tokens on the device -- they need to be in a trusted space where other apps on the device can't sniff them out. 4) Another app can try to register myapp:// and intercept your code on the way through, so make sure your codes are all one time use and short lived. None of this is just theoretically possible, people are doing it today. What libraries and stuff you'd be after depends wholly on your platform (both server and client side). -- Justin On 04/12/2012 03:01 PM, Lewis Adam-CAL022 wrote: Hi all, I’ve been talking to some of you off line about this already, but I need some help in terms of implementation. I would like to use OAuth as a means to get either a JWT or SAML token to a client running on a handheld device. This is something that I’m looking to prototype (as part of a larger project) beginning this week. So, it is important to me to understand the divide between what is theoretically possible and what is actually possible. Anybody aware of any implementations out there, either vendor or open source, that I can use for this? Tx! adam ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] web sso study...
Yeah, we encountered this problem doing a binding between FB and other accounts. We found that FB actually used a valid browser cookie rather than serving back the needed auth page we wanted for the user. We had to work around this by calling their un-CSRF protected sign-out link first. It's a very real, very bad problem. -bill From: John Bradley ve7...@ve7jtb.com To: Stephen Farrell stephen.farr...@cs.tcd.ie Cc: oauth@ietf.org oauth@ietf.org Sent: Tuesday, April 17, 2012 7:57 AM Subject: Re: [OAUTH-WG] web sso study... I posted to my blog about a significant implementation flaw made by people using Facebook's OAuth 2 implementation. I understand that Facebook is fixing it in there own code, but many clients are exploitable. For those interested. http://www.thread-safe.com/2012/04/followup-on-oauth-facebook-login.html The flaw is not in the spec but in implementations. John B. On 2012-04-17, at 4:45 PM, Stephen Farrell wrote: Hi all, A recent news article [1] was brought to my attention this week that's about a paper [2] which I've just read. While it mostly deals with implementation and integration flaws, I'm wondering if there's anything in there that could benefit any of the oauth drafts. Anyone had a look at that already? Be interesting if any similar analysis has been done on any oauth 1.0 or 2.0 sites or implementations. Ta, S. [1] http://www.itbusiness.ca/it/client/en/CDN/News.asp?id=66741 [2] https://research.microsoft.com/pubs/160659/websso-final.pdf ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IIW and OAuth
I am planning to. -bill From: Hannes Tschofenig hannes.tschofe...@gmx.net To: oauth@ietf.org WG oauth@ietf.org Sent: Monday, April 16, 2012 4:55 AM Subject: [OAUTH-WG] IIW and OAuth Hi guys, I was wondering how many of you will be at the upcoming IIW in Mountain View (or for some other event). IIW will run from Tuesday (May 1st) to Thursday (May 3rd). I thought it might be good to useful to get together on the Friday after the IIW event for a OAuth breakfast chat. I am sure that there are still a couple of topics that require brainstorming. Drop me a message if you are able and interested. Ciao Hannes PS: Please do not forget to read the Assertion specs so that we can get them out of the door. (And thanks to those who have already read them.) ___ 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
Re: [OAUTH-WG] Dynamic Client Registration
Yeah, SCIM as a way to federate and distribute info like this seems sane, with extensions for the data items we need here. The hard part is still around the security stuff which they have not dealt with yet, and that's going to be a blocker until it's solved. Authority to update elemnts or namespaces is going to be needed, and that's a hard problem. -bill From: Eve Maler e...@xmlgrrl.com To: Hannes Tschofenig hannes.tschofe...@gmx.net Cc: oauth@ietf.org WG oauth@ietf.org Sent: Friday, April 13, 2012 6:29 PM Subject: Re: [OAUTH-WG] Dynamic Client Registration Hi Hannes-- That's kind of a cool idea. You're right that it's a client account of sorts. At least worth exploring, I'd say, unless a SCIM expert pipes up with a reason why not. Eve On 13 Apr 2012, at 7:36 AM, Hannes Tschofenig wrote: Hi all, at the IETF#83 OAuth working group meeting we had some confusion about the Dynamic Client Registration and the Simple Web Discovery item. I just listened to the audio recording again. With the ongoing mailing list discussion regarding WebFinger vs. Simple Web Discovery I hope that folks had a chance to look at the documents again and so the confusion of some got resolved. I believe the proposed new charter item is sufficiently clear with regard to the scope of the work. Right? Here is the item again: 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 ] Of course there there is a relationship between Simple Web Discovery (or WebFinger) and the dynamic client registration since the client first needs to discover the client registration endpoint at the authorization server before interacting with it. Now, one thing that just came to my mind when looking again at draft-hardjono-oauth-dynreq was the following: Could the Client Registration Request and Response protocol exchange could become a profile of the SCIM protocol? In some sense this exchange is nothing else than provisioning an account at the Authorization Server (along with some meta-data). Is this too far fetched? Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl ___ 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
Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
Or perhaps update/extend the existing spec to do what is needed? Is there anything that is fundamentally in conflict? -bill From: Igor Faynberg igor.faynb...@alcatel-lucent.com To: John Bradley ve7...@ve7jtb.com Cc: oauth@ietf.org Sent: Thursday, April 12, 2012 11:29 AM Subject: Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD) John, I agree with you on everything you said about the differences. My question: Are these not about API rather than the protocol? (I was just trying to see if I can find a common fixed point to start with.) Igor On 4/12/2012 2:00 PM, John Bradley wrote: There are important deployment and privacy issues that caused openID Connect to use SWD. I was part of the OASIS XRI/XRD work that Web Finger has been based on. The main differences are around allowing all of the users information to be publicly discoverable, vs providing for access control. They are similar, but have real design differences. Web Finger without XML is not horrible by any means, but nether is SWD. SWD is more about users while host-meta is more about server resources. John B. On 2012-04-12, at 7:33 PM, Igor Faynberg wrote: To me this looks like more than the same problem being solved--it appears to be the same protocol... I wonder if, the representation issues were put aside (i.e., left to the API specification), the common part is what can be adopted. Igor On 4/12/2012 8:01 AM, Stephen Farrell wrote: On 04/12/2012 12:00 PM, Hannes Tschofenig wrote: Hi all, those who had attended the last IETF meeting may have noticed the ongoing activity in the 'Applications Area Working Group' regarding Web Finger. We had our discussion regarding Simple Web Discovery (SWD) as part of the re-chartering process. Here are the two specifications: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03 http://tools.ietf.org/html/draft-jones-simple-web-discovery-02 Now, the questions that seems to be hanging around are 1) Aren't these two mechanisms solving pretty much the same problem? 2) Do we need to have two standards for the same functionality? 3) Do you guys have a position or comments regarding either one of them? Ciao Hannes PS: Please also let me know if your view is: I don't really know what all this is about and the documents actually don't provide enough requirements to make a reasonable judgement about the solution space. So just as a data-point. We (the IETF, but including me personally;-) mucked up badly on this some years ago in the PKI space - we standardised both CMP (rfc 2510) and CMC (rfc 2797) as two ways to do the same thing, after a protracted battle between factions supporting one or the other. We even made sure they had as much common syntax as possible. (CRMF, rfc 2511) Result: neither fully adopted, lots of people still do proprietary stuff, neither can be killed off (despite attempts), both need to be maintained (CMP is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO partly as a result of us screwing up for what seemed like good reasons at the time, PKI administration stuff has never gotten beyond horrible-to-do. All-in-all, a really bad outcome which is still a PITA a dozen years later. As OAuth AD I will need *serious* convincing that there is a need to provide two ways to do the same thing. I doubt it'll be possible to convince me, in fact, so if you wanna try, you'll need to start by saying that they are not in fact two ways to do the same thing:-) S. PS: This discussion needs to also involve the Apps area, so I've cc'd that list. ___ 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 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAUTH Report for IETF-83
Thanks for the process lecture except we already had extensive discussion of same in the WG meeting... Partially this issue was raised because my draft does a discovery thing and I want this sorted out to figure out what hooks I need to put in so I can get done. I want to be consistent with whatever will be the chosen standardized usage. I really DO NOT care how we solve the problem as long as it's solved. I think your point that host-meta and LINK/REL solve the same problem is a fair one, it came up in the room. Another comment in the room was that for JS based stuff JSON is far easier to deal with than XML, and I think that's probably also really true, so there are some competing isues. -bill From: Eran Hammer e...@hueniverse.com To: William Mills wmi...@yahoo-inc.com; Derek Atkins de...@ihtfp.com; s...@ietf.org s...@ietf.org; oauth@ietf.org oauth@ietf.org Sent: Thursday, March 29, 2012 7:25 PM Subject: RE: [OAUTH-WG] OAUTH Report for IETF-83 The narrative so far: The IETF has adopted host-meta as a general-purpose discovery mechanism in RFC 6415. The OpenID Connect group, which utilizes OAuth but is out of scope for this WG, adopted SWD as its discovery mechanism. The proposed charter references ‘OAuth Dynamic Client Registration Protocol’, which in turn references RFC 6415 as its discovery mechanism. Am I missing a WG item or proposed draft which relies on SWD at this time? If I am, are these documents included in the proposed charter or are requested to be included (e.g. not SWT itself but other documents with dependencies on it)? In such documents, is SWD a required component which cannot be substituted with something else such as RFC 6415? Here is how this process should work: 1. The WG agrees on including a discovery related item in its charter. The dynamic client registration is a reasonable such item. 2. The charter references an existing proposal as foundation. 3. The WG begins discussing the proposed draft (which can happen at any time on the list as long as the chairs allow it). 4. The WG discusses any required enabling technologies, their suitability, maturity, industry support, etc. In the case of dynamic registration, I expect the WG to discuss SWD (because it is the technology selected by the OpenID subset of this WG), host-meta (because it is an IETF proposed standard RFC), as well as other solutions (Link headers, other well-known URIs, etc.). The publication status of the proposed technologies is another factor. 5. If an enabling technology is decided to be the most suitable, and is not available in normative reference form, the WG will discuss the best way to accomplish that. This includes identifying the right community, standards body, working group, etc. that is best to take on the work. If no suitable venue is found, the WG may decide to take on the work with very limited scope only to enable its own use cases. I am not opposed to having this discussion, but why are *we* having it *now*, other than the OpenID Connect group, which has nothing to do with this WG, is stuck with the problem of finding a venue for this work, and are dumping it on our laps? I do not recall this WG ever decided (or even *proposed*) to use SWD for any of its chartered items. When we have this discussion, I expect it to include a detailed examination of host-meta and other solutions *as equal* alternatives. The OpenID Connect group preference is a valid input as it covers some potential market share with OAuth deployment, but it is *far* from any significant deployment worthy of bypassing this evaluation. Am I missing something here? EH From:William Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, March 29, 2012 4:26 PM To: Eran Hammer; Derek Atkins; s...@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83 On the SWD stuff there was general discussion about is this the right place?, and there were issues raised. The question was also asked well, where is the right place? which got crickets. It is exactly coming back to the list for discussion to sort out the right place. From:Eran Hammer e...@hueniverse.com To: Derek Atkins de...@ihtfp.com; s...@ietf.org s...@ietf.org; oauth@ietf.org oauth@ietf.org Sent: Thursday, March 29, 2012 8:44 AM Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83 Hi Derek, Thanks for the notes. Is an audio recording available? -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Derek Atkins Sent: Thursday, March 29, 2012 8:27 AM To: s...@ietf.org; oauth@ietf.org Subject: [OAUTH-WG] OAUTH Report for IETF-83 Hi, OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a two hour session. After introducing ourselves and welcoming me to the working group we thanked Barry and Blaine
Re: [OAUTH-WG] OAUTH Report for IETF-83
On the SWD stuff there was general discussion about is this the right place?, and there were issues raised. The question was also asked well, where is the right place? which got crickets. It is exactly coming back to the list for discussion to sort out the right place. From: Eran Hammer e...@hueniverse.com To: Derek Atkins de...@ihtfp.com; s...@ietf.org s...@ietf.org; oauth@ietf.org oauth@ietf.org Sent: Thursday, March 29, 2012 8:44 AM Subject: Re: [OAUTH-WG] OAUTH Report for IETF-83 Hi Derek, Thanks for the notes. Is an audio recording available? -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Derek Atkins Sent: Thursday, March 29, 2012 8:27 AM To: s...@ietf.org; oauth@ietf.org Subject: [OAUTH-WG] OAUTH Report for IETF-83 Hi, OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a two hour session. After introducing ourselves and welcoming me to the working group we thanked Barry and Blaine for their service. Torsten spoke about draft-ietf-oauth-v2-threatmodel. This document has completed WG Last Call. Torsten has applied changes based on the Last Call Comments and has published a new revision. Barry promised to finish his PROTO Shepard review next week so we can send this document to the IESG. He promises to take Mike Thomas' issues from the list into account and make sure that everyone is happy. [ I'd like to extend a personal thank you to Barry for continuing his role as document shephard for this draft. -- derek ] Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub- NS drafts. Except for one outstanding issue Mike believes these documents are ready for WGLC. Consensus in the room was to take these three docs to WGLC, which the chairs will do by the end of next week. The MAC Token draft has languished while time was spent working on the core document. Eran was not here, nor was he online, to talk about the status of the MAC Token draft. There were only a few people in the room interested in reviewing the draft, which was not a clear consensus of interest, even though this document does solve a problem that the bearer tokens cannot. The chairs will take it to the list to evaluate if there is enough interest to continue with this document. As I've updated the list and chairs on multiple occasions, the draft is practically ready. There was some late arriving feedback which I did not get around to process. However, the main issue is lack of WG interest in this work. I am still planning to finish it by making very minor tweaks to the current draft, but would be very happy to make it an individual submission. The MAC draft has largely been my personal project to date. In a related note, this document (as well as the v2-bearer document) is not available off the tools page even though it has not expired. I have taken the action item to get that sorted out. Finally, we spent the majority of our time talking about rechartering based on the proposed charter sent to the list by Hannes a week or two ago. Consensus of the room was that there was enough interest to recharter based roughly on the proposed charter. There was also consensus to include Simple Web Discovery (in addition to, and separate from, Dynamic Client Registration), although we will need to work with the ADs to make sure it gets handled in the appropriate WG and Area. Moreover, it's important to make sure the appropriate applications area participants get involved in the SWD work. There is something very awkward about discussing SWD both in the context of this working group, and in the context of future OAuth discovery work. The idea of picking a discovery mechanism before the WG had a single discussion about what is included in discovery and what are the use cases and requirement is absurd. There has not been consensus on the list for including SWD in the WG charter. The only justification I have heard so far for this WG to be the SWD venue is that it's easy because the author and a few other people interested are already here. That's not a valid reason. Any further work on SWD also requires the IETF to view it in light of RFC 6415 (host-meta) which is a proposed standard approved in October 2011. The IETF is not in the 'flavor of the month' business. Proper process requires discussion about the merits of redoing the host-meta work from scratch in a non-compatible way just because a handful of people 'like it better' with little technical justification. Either way, this discussion does not belong here. EH ___ 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
Re: [OAUTH-WG] Issue token for another user
Can you specify the user being accesses as the resource in the URL? P.S. Please start using the http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest for new requests like product and feature reviews. From: David Fox da...@davidjfox.com To: 'OAuth WG' oauth@ietf.org Sent: Sunday, March 11, 2012 7:10 PM Subject: [OAUTH-WG] Issue token for another user http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8 In order to achieve the use case above, how would the client (a.k.a the resource owner in this case) specify which user to authorize? Would the correct approach be to make a request to the Authorization Server with the grant type set to client_credentials and set the scope to user=user_id (where user_id would be the identifier for the user Bob)? -David ___ 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
