Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Stephen, On 6/1/2011 5:16 AM, Stephen Farrell wrote: Just on DOSETA - that's not currently got any official home in the IETF so its not something that would be right to reference at this point (unless the oauth WG wanted to adopt DOSETA but I'd be very surprised if that were the case for timing reasons). I'm confused on two counts. (To be honest, of course, I'm confused about many points, but two of them are relevant to this thread...) One, of course, is that I've been actively raising DOSETA in various IETF venues for the different groups to considering adopting and/or adapting it. As such, discussion of DOSETA permits exploring the possibility of adoption and/or adaptation. The second is that you appear to be stating a policy that a working group is only permitted to reference things which are currently and officially IETF work items. I suspect that that is not what you meant, so at the least, please clarify what you do mean. If you really do mean anything like the interpretation I just summarized, please explain its basis. To be clear, as an individual, I do think that "something like DOSETA" is a really good idea and maybe DOSETA will turn out to be that something, I don't know. If it is not acceptable to 'reference' DOSETA now and here, then how will the determination of its utility be made? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
On 03/06/2011, at 1:44 AM, Eran Hammer-Lahav wrote: > > >> -Original Message- >> From: Mark Nottingham [mailto:m...@mnot.net] >> Sent: Wednesday, June 01, 2011 5:16 PM >> To: Eran Hammer-Lahav >> Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; >> 'Adam Barth (a...@adambarth.com)'; HTTP Working Group >> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >> >> >> On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >> >>> This was suggested before, but are there really attack vectors for this? >> >> If not having a current, working attack to demonstrate is a valid way to >> shrug >> off a security concern, that's great; it'll be a useful approach to many of >> the >> discussions I have. :) > > No, but its valid as long as it is fully documented. We're not going to solve > everything. > >>> The problem is that content-type is a pretty flexible header, which means >> normalization of the header will be required (case, parameter order, white >> space, etc.). >> >> The media type is the important part, and it's much more constrained. > > So include just the: > > type "/" subtype > > forced to lowercase? Think so. > >> >>> I would argue that if you are using MAC with body hash and an attacker >> changing the media type can cause harm, you should use additional methods >> to secure the content-type (such as making the body self-describing). >> >> >> That seems like a step backwards, considering all of the work that Adam has >> put into limiting the use of sniffing. > > I wasn't suggesting sniffing. > > EHL > >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Hi Dave, On 02/06/11 22:16, Dave CROCKER wrote: > Stephen, > > On 6/1/2011 5:16 AM, Stephen Farrell wrote: >> Just on DOSETA - that's not currently got any official >> home in the IETF so its not something that would be right >> to reference at this point (unless the oauth WG wanted to >> adopt DOSETA but I'd be very surprised if that were the >> case for timing reasons). > > I'm confused on two counts. (To be honest, of course, I'm confused > about many points, but two of them are relevant to this thread...) > > One, of course, is that I've been actively raising DOSETA in various > IETF venues for the different groups to considering adopting and/or > adapting it. As such, discussion of DOSETA permits exploring the > possibility of adoption and/or adaptation. I don't get the confusion aspect there, but the rest below might clarify. > The second is that you appear to be stating a policy that a working > group is only permitted to reference things which are currently and > officially IETF work items. I suspect that that is not what you meant, > so at the least, please clarify what you do mean. Right. I wasn't stating any general policy. What I meant was that the oauth WG needs to get oauth2.0 done and that seems to require also getting the mac scheme done, so adding a dependency to something at an early stage of development (like DOSETA) at this point would not be a good plan for oauth. That's all. Exploring whether DOSETA or something similar is useful is a fine thing to do, its just a bit early for oauth. > If you really do mean anything like the interpretation I just > summarized, please explain its basis. > >> To be clear, as an individual, I do think that "something >> like DOSETA" is a really good idea and maybe DOSETA will >> turn out to be that something, I don't know. > > If it is not acceptable to 'reference' DOSETA now and here, then how > will the determination of its utility be made? Following our usual highly-predictable process I guess;-) I assume that the next step would be for a bunch of interested folks to figure out where and when it might make sense to do more on DOSETA. S. > > > Thanks. > > d/ > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
> -Original Message- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Tuesday, May 31, 2011 4:57 PM > The "normalized request string" contains the request-URI and values > extracted from the Host header. Be aware that intermediaries can and do > change these; e.g., they may change an absolute URI to a relative URI in the > request-line, without affecting the semantics of the request. See [1] for > details (it covers other problematic conditions too). > > It would be more robust to calculate an effective request URI, as in [2]. > [2] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 Using the effective request URI has proved to be a significant point of friction in OAuth 1.0. I would rather note that intermediaries can change the request URI and that the server must reverse those changes based on what the values should have been if they were received from the client directly. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
It sounds like it's specifying *almost* the same thing, but in a different way. Why is there friction? Is it fashion, NIH or something more substantial? Cheers, On 20/11/2011, at 4:08 AM, Eran Hammer-Lahav wrote: > > >> -Original Message- >> From: Mark Nottingham [mailto:m...@mnot.net] >> Sent: Tuesday, May 31, 2011 4:57 PM > >> The "normalized request string" contains the request-URI and values >> extracted from the Host header. Be aware that intermediaries can and do >> change these; e.g., they may change an absolute URI to a relative URI in the >> request-line, without affecting the semantics of the request. See [1] for >> details (it covers other problematic conditions too). >> >> It would be more robust to calculate an effective request URI, as in [2]. >> [2] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 > > Using the effective request URI has proved to be a significant point of > friction in OAuth 1.0. I would rather note that intermediaries can change the > request URI and that the server must reverse those changes based on what the > values should have been if they were received from the client directly. > > EHL -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Additional comments: - Using nonces for replay protection is heavy-duty. It is difficult to implement a reliable, secure, high-performance replay cache. (It is easy to implement just a high-performance replay cache: use memcache.) I recommend an option to use sequence numbers at the server's choice, understanding, of course, that requests will not be received in sequence. The use of a sliding sequence number window makes it possible to do at least as well as when using nonce, and probably faster while still being secure. - In an open wifi environment active attacks may not be very difficult, thus an option to secure more than just a handful of bits from the request, would be nice (all of the request and all of the response, say). The hard part is how to decide when to use one or the other. Ideally browsers can request more protection when the network is reconfigured such that there's one or more clear wifi interfaces. Nico -- ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
> -Original Message- > From: Nico Williams [mailto:n...@cryptonector.com] > Sent: Friday, May 20, 2011 1:25 PM > To: Eran Hammer-Lahav > Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; Adam > Barth (a...@adambarth.com); HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme > > Additional comments: > > - Using nonces for replay protection is heavy-duty. It is difficult to > implement a reliable, secure, high-performance replay cache. (It is easy to > implement just a high-performance replay cache: use > memcache.) > >I recommend an option to use sequence numbers at the server's choice, > understanding, of course, that requests will not be received in sequence. > The use of a sliding sequence number window makes it possible to do at > least as well as when using nonce, and probably faster while still being > secure. We switched to use time since credentials were issued. This should be pretty easy to implement if you really need reply protection by using a small window (clock sync is no longer a problem, just the delay in getting the credentials to the client, which should be a small window). > - In an open wifi environment active attacks may not be very difficult, thus > an option to secure more than just a handful of bits from the request, would > be nice (all of the request and all of the response, say). The hard part is > how > to decide when to use one or the other. Ideally browsers can request more > protection when the network is reconfigured such that there's one or more > clear wifi interfaces. There is just no easy way to do that. If you need more, use TLS. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav wrote: >> Additional comments: >> >> - Using nonces for replay protection is heavy-duty. It is difficult to >> implement a reliable, secure, high-performance replay cache. (It is easy to >> implement just a high-performance replay cache: use >> memcache.) >> >> I recommend an option to use sequence numbers at the server's choice, >> understanding, of course, that requests will not be received in sequence. >> The use of a sliding sequence number window makes it possible to do at >> least as well as when using nonce, and probably faster while still being >> secure. > > We switched to use time since credentials were issued. This should be pretty > easy to implement if you really need reply protection by using a small window > (clock sync is no longer a problem, just the delay in getting the credentials > to the client, which should be a small window). Kerberos has had an option to use time or sequence numbers for a long time. We've learned a few things from this experience. For a memcache-type implementation, timestamps are probably best because maintaining a sequence number window in memcache, synchronized, would be a pain, if not impossible. Other replay cache implementations would likely do better using sequence numbers, especially when they have a small sequence number window per-session. And, of course, memcache isn't going to be durable (but probably it will be good enough in many cases). If you set a skew window to be tight on the future side, then you can compensate for this if you can detect loss of replay data (hmmm, not likely with memcache, eh?). One big gotcha to be aware of: - Some clocks have lousy resolution, leading to easily repeated values in high-rate environments. One fix is to add resolution on the wire and use random numbers for the unused precision bits. Another solution is to not use time. My advice is that you allow the server to select which of timestamps or sequence numbers to use. Also, I strongly recommend that you specify replay cache semantics in some detail. Think of the Kerberos V5 replay cache semantics. >> - In an open wifi environment active attacks may not be very difficult, thus >> an option to secure more than just a handful of bits from the request, would >> be nice (all of the request and all of the response, say). The hard part is >> how >> to decide when to use one or the other. Ideally browsers can request more >> protection when the network is reconfigured such that there's one or more >> clear wifi interfaces. > > There is just no easy way to do that. If you need more, use TLS. But even then you need to know when to use TLS. TLS doesn't solve the problem when you're trying to solve problems without introducing TLS in the first place. This is a serious problem. You think you're fixing one problem (cookie theft by passive attackers on open networks) and you're very likely only making things somewhat harder for the attacker -- we need to be very careful that the attacker can't just automate active attacks and still win. Nico -- ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Hi, Reading draft -05. The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). It would be more robust to calculate an effective request URI, as in [2]. Also, if you include a hash of the request body, you really need to include a hash of the body media type. Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it. Regards, 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > (Please discuss this draft on the Apps-Discuss > mailing list) > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > The draft includes: > > * An HTTP authentication scheme using a MAC algorithm to authenticate > requests (via a pre-arranged MAC key). > * An extension to the Set-Cookie header, providing a method for associating a > MAC key with a session cookie. > * An OAuth 2.0 binding, providing a method of returning MAC credentials as an > access token. > > Some background: OAuth 1.0 introduced an HTTP authentication scheme using > HMAC for authenticating an HTTP request with partial cryptographic protection > of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 > scheme was designed for delegation-based use cases, but is widely “abused” > for simple client-server authentication (the poorly named ‘two-legged’ use > case). This functionality has been separated from OAuth 2.0 and has been > reintroduced as a standalone, generally applicable HTTP authentication scheme > called MAC. > > Comments and feedback is greatly appreciated. > > EHL > ___ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Just on DOSETA - that's not currently got any official home in the IETF so its not something that would be right to reference at this point (unless the oauth WG wanted to adopt DOSETA but I'd be very surprised if that were the case for timing reasons). However I do agree that keeping in mind that folks may move towards something like DOESTA in future is a good plan. To be clear, as an individual, I do think that "something like DOSETA" is a really good idea and maybe DOSETA will turn out to be that something, I don't know. S. On 01/06/11 00:57, Mark Nottingham wrote: > Hi, > > Reading draft -05. > > The "normalized request string" contains the request-URI and values extracted > from the Host header. Be aware that intermediaries can and do change these; > e.g., they may change an absolute URI to a relative URI in the request-line, > without affecting the semantics of the request. See [1] for details (it > covers other problematic conditions too). > > It would be more robust to calculate an effective request URI, as in [2]. > > Also, if you include a hash of the request body, you really need to include a > hash of the body media type. > > Generally, I think that people can and will want to include other headers; > just because *some* developers can't get this right doesn't mean we should > preclude *all* developers from doing it. It'd be really nice to see this > either leverage DOSETA [3][4], or at least offer a clean transition path to > it. > > Regards, > > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 > 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 > 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 > 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 > > > On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > >> (Please discuss this draft on the Apps-Discuss >> mailing list) >> >> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >> >> The draft includes: >> >> * An HTTP authentication scheme using a MAC algorithm to authenticate >> requests (via a pre-arranged MAC key). >> * An extension to the Set-Cookie header, providing a method for associating >> a MAC key with a session cookie. >> * An OAuth 2.0 binding, providing a method of returning MAC credentials as >> an access token. >> >> Some background: OAuth 1.0 introduced an HTTP authentication scheme using >> HMAC for authenticating an HTTP request with partial cryptographic >> protection of the HTTP request (namely, the request URI, host, and port). >> The OAuth 1.0 scheme was designed for delegation-based use cases, but is >> widely “abused” for simple client-server authentication (the poorly named >> ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 >> and has been reintroduced as a standalone, generally applicable HTTP >> authentication scheme called MAC. >> >> Comments and feedback is greatly appreciated. >> >> EHL >> ___ >> apps-discuss mailing list >> apps-disc...@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > > ___ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
> -Original Message- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Tuesday, May 31, 2011 4:57 PM > To: Eran Hammer-Lahav > Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; > 'Adam Barth (a...@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme > > Hi, > > Reading draft -05. > > The "normalized request string" contains the request-URI and values > extracted from the Host header. Be aware that intermediaries can and do > change these; e.g., they may change an absolute URI to a relative URI in the > request-line, without affecting the semantics of the request. See [1] for > details (it covers other problematic conditions too). > > It would be more robust to calculate an effective request URI, as in [2]. I'll take a look. > Also, if you include a hash of the request body, you really need to include a > hash of the body media type. This was suggested before, but are there really attack vectors for this? The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.). I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing). > Generally, I think that people can and will want to include other headers; > just > because *some* developers can't get this right doesn't mean we should > preclude *all* developers from doing it. It'd be really nice to see this > either > leverage DOSETA [3][4], or at least offer a clean transition path to it. If someone comes up with a practical and secure way to normalize HTTP request headers, they can either define a new authentication scheme or use the 'ext' parameter to pass the additional values. I would vote for a new scheme. MAC is trivial to implement and interoperate. That simplicity comes at a significant lack of features, and limiting extensibility is a design goal. EHL > Regards, > > 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section- > 4.1.2 > 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 > 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 > 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 > > > On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > > > (Please discuss this draft on the Apps-Discuss > mailing list) > > > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > The draft includes: > > > > * An HTTP authentication scheme using a MAC algorithm to authenticate > requests (via a pre-arranged MAC key). > > * An extension to the Set-Cookie header, providing a method for > associating a MAC key with a session cookie. > > * An OAuth 2.0 binding, providing a method of returning MAC credentials > as an access token. > > > > Some background: OAuth 1.0 introduced an HTTP authentication scheme > using HMAC for authenticating an HTTP request with partial cryptographic > protection of the HTTP request (namely, the request URI, host, and port). > The OAuth 1.0 scheme was designed for delegation-based use cases, but is > widely "abused" for simple client-server authentication (the poorly named > 'two-legged' use case). This functionality has been separated from OAuth 2.0 > and has been reintroduced as a standalone, generally applicable HTTP > authentication scheme called MAC. > > > > Comments and feedback is greatly appreciated. > > > > EHL > > ___ > > apps-discuss mailing list > > apps-disc...@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: > This was suggested before, but are there really attack vectors for this? If not having a current, working attack to demonstrate is a valid way to shrug off a security concern, that's great; it'll be a useful approach to many of the discussions I have. :) > The problem is that content-type is a pretty flexible header, which means > normalization of the header will be required (case, parameter order, white > space, etc.). The media type is the important part, and it's much more constrained. > I would argue that if you are using MAC with body hash and an attacker > changing the media type can cause harm, you should use additional methods to > secure the content-type (such as making the body self-describing). That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing. Cheers, -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
On Wed, Jun 1, 2011 at 5:15 PM, Mark Nottingham wrote: > On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >> This was suggested before, but are there really attack vectors for this? > > If not having a current, working attack to demonstrate is a valid way to > shrug off a security concern, that's great; it'll be a useful approach to > many of the discussions I have. :) > > >> The problem is that content-type is a pretty flexible header, which means >> normalization of the header will be required (case, parameter order, white >> space, etc.). > > The media type is the important part, and it's much more constrained. > > >> I would argue that if you are using MAC with body hash and an attacker >> changing the media type can cause harm, you should use additional methods to >> secure the content-type (such as making the body self-describing). > > That seems like a step backwards, considering all of the work that Adam has > put into limiting the use of sniffing. Yeah, I tried to twist Eran's arm into including the media type in the body hash too. It's probably more important for responses than requests, however. Adam ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
> -Original Message- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Wednesday, June 01, 2011 5:16 PM > To: Eran Hammer-Lahav > Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; > 'Adam Barth (a...@adambarth.com)'; HTTP Working Group > Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme > > > On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: > > > This was suggested before, but are there really attack vectors for this? > > If not having a current, working attack to demonstrate is a valid way to shrug > off a security concern, that's great; it'll be a useful approach to many of > the > discussions I have. :) No, but its valid as long as it is fully documented. We're not going to solve everything. > > The problem is that content-type is a pretty flexible header, which means > normalization of the header will be required (case, parameter order, white > space, etc.). > > The media type is the important part, and it's much more constrained. So include just the: type "/" subtype forced to lowercase? > > > I would argue that if you are using MAC with body hash and an attacker > changing the media type can cause harm, you should use additional methods > to secure the content-type (such as making the body self-describing). > > > That seems like a step backwards, considering all of the work that Adam has > put into limiting the use of sniffing. I wasn't suggesting sniffing. EHL > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
