From torsten@lodderstedt.net Wed Aug 1 08:31:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E351B21F89EB for ; Wed, 1 Aug 2012 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEElNE-Mj+TG for ; Wed, 1 Aug 2012 08:31:58 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id A7C7021F89EA for ; Wed, 1 Aug 2012 08:31:57 -0700 (PDT) Received: from [80.67.16.111] (helo=webmail.df.eu) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Swatu-0001UC-Hu; Wed, 01 Aug 2012 17:31:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Aug 2012 17:31:54 +0200 From: Torsten Lodderstedt To: Derek Atkins In-Reply-To: References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> <4E1F6AAD24975D4BA5B16804296739436672BBBE@TK5EX14MBXC285.redmond.corp.microsoft.com> <6DEBD33A-815E-460D-934E-A684AED2BA6B@ve7jtb.com> <5E393DF26B791A428E5F003BB6C5342A108171DC@OC11EXPO24.exchange.mit.edu> <50101C74.6060005@lodderstedt.net> Message-ID: <5779a15a8c83bd9cb0626a5c933d3e89@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.6 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 15:31:59 -0000 Hi Derek, I will give it a try. Where can I find the respective meeting data? regards, Torsten. Am 30.07.2012 19:55, schrieb Derek Atkins: > We will have a WebEx available if you can attend remotely? > That's my plan, as I cannot make Vancouver this week. > > -derek > > Torsten Lodderstedt writes: > >> Hi Hannes, >> >> I'm unfortunately had to cancel my trip to IETF-84. Phil will cover >> the status >> of the threat model document. But none of the authors of the >> Revocation Draft >> will be attending. So I would ask you to postpone the presentation >> of this I-D >> to the next IETF meeting as well. >> >> best regards, >> Torsten. >> >> Am 23.07.2012 17:02, schrieb Thomas Hardjono: >> >> Hannes, Derek, >> >> Would it possible to postpone presentation/discussion of the >> Dyn-Reg >> draft (Dynamic Client Registration Protocol) to the >> Atlanta/November >> IETF meeting? >> >> The reason is that none of the proposers will be attending the >> Vancouver IETF in-person. >> >> Thanks. >> >> /thomas/ >> >> __________________________________________ >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> On >> >> Behalf >> >> Of Hannes Tschofenig >> Sent: Sunday, July 15, 2012 1:58 PM >> To: John Bradley >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF >> meeting >> requested >> >> Hi all, >> >> I have uploaded an agenda for the meeting. >> >> I am assuming that all these items do not require discussion >> time >> 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 >> >> Hence, we can focus on the new items. As discussed in the >> mail below >> >> I >> >> put a separate slot for discussion of the >> holder-of-the-key/MAC >> >> token >> >> security discussion on the agenda. I would suggest that a >> couple of >> >> us >> >> meeting during the IETF week to work together on a >> presentation that >> provides some concrete suggestions for next steps to the >> rest of the >> group. >> >> I also put the following persons on the spot for the >> presentations >> >> of >> >> working group items: >> >> - OAuth Dynamic Client Registration Protocol (Thomas) >> - JSON Web Token (JWT) (Mike) >> - JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >> (Mike) >> - Token Revocation (Torsten) >> - SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 (Brian) >> - OAuth Use Cases (Zachary) >> >> Let me know if you want someone else to give the >> presentation. >> >> As a preparation for the meeting it would be good if you >> could >> (a) identify the open issues with your document, and >> (b) find one or two reviewers to have a look at your >> document during >> the next two weeks. >> >> Ciao >> Hannes >> >> On Jul 15, 2012, at 5:59 PM, John Bradley wrote: >> >> Yes we need to get clearer on the the threats and use >> cases. >> >> I think Phil Hunt has some though there is likely >> overlap. >> >> Part of the problem with MAC was people never agreed on >> the >> >> threats >> >> it was mitigating. >> >> I can present something or coordinate with Tony or Phil. >> >> John B. >> >> On 2012-07-14, at 9:36 PM, Anthony Nadalin wrote: >> >> How about a few min on proof-of-possession >> requirements? I can >> >> present our use cases and requirements >> >> -----Original Message----- >> From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Mike Jones >> >> Sent: Friday, July 13, 2012 4:42 PM >> To: Hannes Tschofenig; oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Meeting slot for the >> Vancouver IETF >> >> meeting >> >> requested >> >> I'm willing to do 5 minutes on the status of the >> Core and Bearer >> >> documents. >> >> I'm willing to give an update on JWT and the JWT >> Bearer - >> >> probably >> >> 15 minutes. It's probably good that we're a day after the >> JOSE WG >> meeting, given the JWT dependency upon the JOSE specs. >> >> I'm willing to be part of a discussion on the >> Assertions draft, >> >> but >> >> would appreciate doing this with Brian and/or Chuck - I'm >> guessing >> >> 15 >> >> minutes for that as well. (I'm not certain this will be >> needed, but >> I'd like to review the recent changes before saying that >> it's not.) >> >> Looking forward to seeing many of you in Vancouver! >> >> -- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Hannes Tschofenig >> >> Sent: Saturday, June 02, 2012 12:46 AM >> To: oauth@ietf.org WG >> 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 >> >> _______________________________________________ >> 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 >> From tonynad@microsoft.com Wed Aug 1 09:31:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5174311E817D for ; Wed, 1 Aug 2012 09:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEE7D0XRwxSj for ; Wed, 1 Aug 2012 09:31:26 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id EEC7B11E815C for ; Wed, 1 Aug 2012 09:31:24 -0700 (PDT) Received: from mail273-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 16:31:24 +0000 Received: from mail273-tx2 (localhost [127.0.0.1]) by mail273-tx2-R.bigfish.com (Postfix) with ESMTP id 3C9B81C0065 for ; Wed, 1 Aug 2012 16:31:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz9371Ic85fh1418Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail273-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail273-tx2 (localhost.localdomain [127.0.0.1]) by mail273-tx2 (MessageSwitch) id 1343838681531561_25277; Wed, 1 Aug 2012 16:31:21 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.239]) by mail273-tx2.bigfish.com (Postfix) with ESMTP id 74DAC1E80044 for ; Wed, 1 Aug 2012 16:31:21 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 16:31:20 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 1 Aug 2012 16:31:19 +0000 Received: from mail128-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 16:31:02 +0000 Received: from mail128-ch1 (localhost [127.0.0.1]) by mail128-ch1-R.bigfish.com (Postfix) with ESMTP id 54395360428 for ; Wed, 1 Aug 2012 16:31:02 +0000 (UTC) Received: from mail128-ch1 (localhost.localdomain [127.0.0.1]) by mail128-ch1 (MessageSwitch) id 1343838656214443_2733; Wed, 1 Aug 2012 16:30:56 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail128-ch1.bigfish.com (Postfix) with ESMTP id 3286C24006C; Wed, 1 Aug 2012 16:30:56 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 16:30:50 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.232]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0175.005; Wed, 1 Aug 2012 16:30:49 +0000 From: Anthony Nadalin To: Phil Hunt , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] High-level observations on HoK Issues Thread-Index: AQHNY7uVVNBMFa5hU0CLQwxxbt7ApZcvW4ZA Date: Wed, 1 Aug 2012 16:30:48 +0000 Message-ID: References: <421480EA-B719-4164-88A3-96C850489B68@oracle.com> In-Reply-To: <421480EA-B719-4164-88A3-96C850489B68@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.19.205] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E755535C1CBL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] High-level observations on HoK Issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:31:28 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E755535C1CBL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that there is also the Proof Key observation for Proof of Possessio= n that needs to be included: When creating response, the AS encrypts both the token and the proof key wi= thin it using the public key of the RS. The AS also includes the proof key = in the response and encrypts it using the public key of the client. Upon re= ceiving this, the client is able to decrypt the proof key. It then sends th= e token and a message that it signed with the proof key to the RS. When the= RS receives the message, it is able to decrypt the token using its private= key. It computes the signature of the token using the public key of the AS= and compares it to the one included in the token. If they match, the RS kn= ows that the token was sent by the AS and that the proof key in the token i= s trustworthy. It then uses this to sign the message. If the signature matc= hes the signature created by subject using the proof key, the RS knows that= the message originated from the subject claiming to have sent it and no on= e else. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Monday, July 16, 2012 6:29 PM To: oauth@ietf.org WG Subject: [OAUTH-WG] High-level observations on HoK Issues Some observations about requirements and issues for designing an OAuth HoK = proposal. Note: I have intentionally tried to stay away from specifics like token typ= es, encryption types and have only at most delved into asymmetric vs. symme= tric keys. I see positives in many combinations for different scenarios. = That said, I'm not yet sure that one proposal can meet all high level requi= rements. I am happy to present this for discussion at the OAuth WG meeting in Vancou= ver. Players at The Party Most crypto cases discuss scenarios involving a sender and receiver. For th= ese scenarios, there may be 3 identities in play. Plus a 4th during setup. 1. The client application (that accesses the resource). * A client applicaiton may have its own client credential (backed by= PKI key pair or other credential). Many clients may share the same credent= ial so... * Sometimes we are more interested in uniquely identifying an instan= ce of a client (if the client keys are not unique). 1. The resource server being accessed. 2. Delegation token (access token). An authority granted by an authoriza= tion server for a client to access on a users behalf 3. Authorization server (a server that does secure communication with th= e client for the purpose of issuing access tokens and potentially exchangin= g secrets). Public vs. Confidential Clients In OAuth scenarios, there are two sets of broad clients to consider: Public= and Confidential. Here are some characterizations that occur to me. Public * In many cases public clients are light weight. While they can do TLS,= their ability to generate key pairs might be limited. Symmetric keys may b= e easier? * Public clients generate requests primarily based on user input action= s. While latency is an issue, overall throughput is low. * A public client typically only has access tokens representing delegat= ed authorizations for a single user. * Public clients are difficult to uniquely identify. In OAuth, such cli= ents may only be identified by a self asserted client_id which by itself ca= nnot be verified. Confidential * Confidential clients are often web apps that can serve many users and= other service providers directly. * Confidential clients usually have many access tokens (100s to million= s) representing delegated authorizations for many many users. * A single confidential client may generate 1000s of requests per secon= d using 1000s of different access tokens. * Connection pooling is an important scaling factor. * Confidential clients usually have client credential that can be well = protected. It may be reasonable to expect a client to have a private key. * Confidential clients often have unique client credentials (though not= guaranteed). Authentication vs. Uniqueness Typically in HoK the drive is "authentication". I would contend that this i= sn't the case in OAuth. The "authentication" step was already performed in = the authorization steps (or done externally). In most cases we simply want = to verify that the client issued a token is the one using an access token. * In OAuth, client credentials are often shared by multiple client soft= ware instances. * Many OAuth threats are mitigated when a token or code can be bound to= a specific "instance" of a client. * Binding a token to a "client" credential may not be sufficient. Even = while a strong client authentication credential helps mitigate risk, bindin= g tokens to "instances" of clients is better. TLS vs. Open Channel There are many cases where transport security may not be needed or not desi= red. Since a particular access token could be used for many things, it is n= ot necessarily true that an access token intended for a low-risk service is= only used at a low-risk service. * Bearer tokens can be sniffed over open (non-TLS) connections, this po= ses a particular risk for sniffing attacks. * For some applications the oauth token may be more valuable than the r= esource. Some applications may wish to secure only the access token. * TLS One-way provides a way for clients to authenticate the service an= d to secure and protect traffic integrity. * Two-way TLS provides bi-directional authentication but has limited us= e in practice as service providers often terminate TLS at load balancers. = TLS channel information may not be available to the web tier. * Their is some discussion that even with TLS, rogue proxies could be u= sed as an attack vector. Therefore a secure token is still desirable. Message vs. Channel HoK There are three forms of HoK that can be used: * Channel HoK - In channel HoK, the client proves identity as suggested= by Hannes HoTK draft. * A client HoK channel could be bound to the client or could be boun= d to a oauth authorize token context. * There may trade-offs in connection pooling for using client bound= vs. access token bound HoK. * Client bound Keys may be long-lived. Access token keys are shorter= lived * Long lived keys should be asymmetric. * * Message HoK - In message HoK, a proof contained within the authorizat= ion header token protects the credential from sniffing because it binds the= client instance to the token. Message HoK tokens can be used in non-secur= e channels, in TLS channels, and in Channel HoK scenarios. * An HoK message token should bind an *instance* of a client to the = token. * The key establishes some sort of proof about the client being the = same client that originally requested the access token. It does not necess= arily need to prove the client's identity * The keys can be ephemeral. * Since keys last only as long as an access token many scenarios may= only require symmetric keys. * Asymmetric message keys add limited value if the Channel HoK is al= ready asymmetric (confirm?) * I suspect that unique keys should be generated by the client and n= ot by the server so the client may detect "insertion" attacks. (confirm?) * Message authentication (a signature of the request) provides messa= ge integrity when used over non-secure channel. * Message authentication could also be designed to prevent replay at= tacks. Note: I think Hannes HoTK proposal is interesting. It actually inserts anot= her dimension into these observations which I think is important for public= clients (e.g. mobile apps). It doesn't break down into message vs. channe= l, but rather uses access token scoped channel security to achieve some fea= tures of both. Still I have concerns about performance for client web apps= (confidential clients). Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_B26C1EF377CB694EAB6BDDC8E624B6E755535C1CBL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that there is also the Proof Key o= bservation for Proof of Possession that needs to be included:

 

When creating response, the AS encrypts bo= th the token and the proof key within it using the public key of the RS. Th= e AS also includes the proof key in the response and encrypts it using the public key of the client. Upon receiving this, the client is = able to decrypt the proof key. It then sends the token and a message that i= t signed with the proof key to the RS. When the RS receives the message, it= is able to decrypt the token using its private key. It computes the signature of the token using the public k= ey of the AS and compares it to the one included in the token. If they matc= h, the RS knows that the token was sent by the AS and that the proof key in= the token is trustworthy. It then uses this to sign the message. If the signature matches the signature crea= ted by subject using the proof key, the RS knows that the message originate= d from the subject claiming to have sent it and no one else.

 

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Monday, July 16, 2012 6:29 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] High-level observations on HoK Issues=

 

Some observations about requirements and issues for = designing an OAuth HoK proposal.  

 

Note: I have intentionally tried to stay away from s= pecifics like token types, encryption types and have only at most delved in= to asymmetric vs. symmetric keys.  I see positives in many combination= s for different scenarios.  That said, I'm not yet sure that one proposal can meet all high level requirements.

 

I am happy to present this for discussion at the OAu= th WG meeting in Vancouver.

 

Players at The Party

Most crypto cases discuss scenarios involving a send= er and receiver. For these scenarios, there may be 3 identities in play. &n= bsp;Plus a 4th during setup.

  1. The client application (that accesses the resource). 
    2. <= /ol>
      1. A client applicaiton may have its own client credential (backed by PKI key = pair or other credential). Many clients may share the same credential so...=
      2. Sometimes we are more interested in uniquely identifying an instance of a c= lient (if the client keys are not unique).
    1. The resource server being accessed.
    2. Delegation token (access token). An authority granted by an authorization s= erver for a client to access on a users behalf
    3. Authorization server (a server that does secure communication with the clie= nt for the purpose of issuing access tokens and potentially exchanging secr= ets).

 

Public vs. Confidential Clients

In OAuth scenarios, there are two sets of broad clie= nts to consider: Public and Confidential. Here are some characterizations t= hat occur to me.

 

Public

  • In many cases public clients are light weight. While they can do TLS, their= ability to generate key pairs might be limited. Symmetric keys may be easi= er?
  • Public clients generate requests primarily based on user input actions. Whi= le latency is an issue, overall throughput is low.
  • A public client typically only has access tokens representing delegated aut= horizations for a single user.
  • Public clients are difficult to uniquely identify. In OAuth, such clients m= ay only be identified by a self asserted client_id which by itself cannot b= e verified.

Confidential

  • Confidential clients are often web apps that can serve many users and other= service providers directly.
  • Confidential clients usually have many access tokens (100s to millions) rep= resenting delegated authorizations for many many users.
  • A single confidential client may generate 1000s of requests per second usin= g 1000s of different access tokens. 
  • Connection pooling is an important scaling factor.
  • Confidential clients usually have client credential that can be well protec= ted.  It may be reasonable to expect a client to have a private key.
  • Confidential clients often have unique client credentials (though not guara= nteed).

 

Authentication vs. Uniqueness

Typically in HoK the drive is "authentication&q= uot;. I would contend that this isn't the case in OAuth. The "aut= hentication" step was already performed in the authorization steps (or= done externally). In most cases we simply want to verify that the client issued a token is the one using an access token. 

  • In OAuth, client credentials are often shared by multiple client software i= nstances.
  • Many OAuth threats are mitigated when a token or code can be bound to a spe= cific "instance" of a client.  
  • Binding a token to a "client" credential may not be sufficient.&n= bsp;Even while a strong client authentication credential helps mitigate ris= k, binding tokens to "instances" of clients is better.=

 

TLS vs. Open Channel

There are many cases where transport security may no= t be needed or not desired. Since a particular access token could be used f= or many things, it is not necessarily true that an access token intended fo= r a low-risk service is only used at a low-risk service.  

  • Bearer tokens can be sniffed over open (non-TLS) connections, this poses a = particular risk for sniffing attacks.
  • For some applications the oauth token may be more valuable than the resourc= e. Some applications may wish to secure only the access token.
  • TLS One-way provides a way for clients to authenticate the service and to s= ecure and protect traffic integrity.
  • Two-way TLS provides bi-directional authentication but has limited use in p= ractice as service providers often terminate TLS at load balancers.  T= LS channel information may not be available to the web tier.
  • Their is some discussion that even with TLS, rogue proxies could be used as= an attack vector. Therefore a secure token is still desirable.<= /li>

Message vs. Channel HoK

There are three forms of HoK that can be used:<= /o:p>

  • Channel HoK - In channel HoK, the client proves identity as suggested by Ha= nnes HoTK draft.
    • A client HoK channel could be bound to the client or could be bound to a oa= uth authorize token context.
    • There may  trade-offs in connection pooling for using client bound vs.= access token bound HoK.
    • Client bound Keys may be long-lived. Access token keys are shorter lived
    • Long lived keys should be asymmetric.
    •  
  • Message HoK - In message HoK, a proof contained within the authorization he= ader token protects the credential from sniffing because it binds the clien= t instance to the token.  Message HoK tokens can be used in non-s= ecure channels, in TLS channels, and in Channel HoK scenarios.
    • An HoK message token should bind an *instance* of a client to the token. &n= bsp;
    • The key establishes some sort of proof about the client being the same clie= nt that originally requested the access token.  It does not necessaril= y need to prove the client's identity
    • The keys can be ephemeral. 
    • Since keys last only as long as an access token many scenarios may only req= uire symmetric keys.
    • Asymmetric message keys add limited value if the Channel HoK is already asy= mmetric (confirm?)
    • I suspect that unique keys should be generated by the client and not by the= server so the client may detect "insertion" attacks. (confirm?)<= o:p>
    • Message authentication (a signature of the request) provides message integr= ity when used over non-secure channel.
    • Message authentication could also be designed to prevent replay attacks.

Note: I think Hannes HoTK = proposal is interesting. It actually inserts another dimension into these o= bservations which I think is important for public clients (e.g. mobile apps).  It doesn't break down into message vs. channel, = but rather uses access token scoped channel security to achieve some featur= es of both.  Still I have concerns about performance for client web ap= ps (confidential clients).

 

Phil

 

@independentid<= /span>

phil.hunt@oracle.com

 <= /p>



 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E755535C1CBL2PRD0310MB362_-- From internet-drafts@ietf.org Wed Aug 1 14:56:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97E611E832A; Wed, 1 Aug 2012 14:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nks3F7ZSZCjd; Wed, 1 Aug 2012 14:56:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33E411E833B; Wed, 1 Aug 2012 14:56:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120801215628.22405.23186.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 14:56:28 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-31.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:56:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : The OAuth 2.0 Authorization Framework Author(s) : Dick Hardt Filename : draft-ietf-oauth-v2-31.txt Pages : 72 Date : 2012-08-01 Abstract: The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-31 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-31 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Aug 1 14:58:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41911E8364; Wed, 1 Aug 2012 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnYEiA-DXlNW; Wed, 1 Aug 2012 14:58:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0670111E836D; Wed, 1 Aug 2012 14:58:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120801215844.8750.32176.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 14:58:44 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-23.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:58:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : The OAuth 2.0 Authorization Framework: Bearer Token Usage Author(s) : Michael B. Jones Dick Hardt Filename : draft-ietf-oauth-v2-bearer-23.txt Pages : 26 Date : 2012-08-01 Abstract: This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-bearer-23 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Wed Aug 1 15:00:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF4321F88CB for ; Wed, 1 Aug 2012 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnLQMuyYRk4q for ; Wed, 1 Aug 2012 15:00:50 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2F11E81B6 for ; Wed, 1 Aug 2012 15:00:26 -0700 (PDT) Received: from mail192-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 22:00:26 +0000 Received: from mail192-co1 (localhost [127.0.0.1]) by mail192-co1-R.bigfish.com (Postfix) with ESMTP id 1285E4801B2 for ; Wed, 1 Aug 2012 22:00:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail192-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail192-co1 (localhost.localdomain [127.0.0.1]) by mail192-co1 (MessageSwitch) id 1343858424735234_16750; Wed, 1 Aug 2012 22:00:24 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.236]) by mail192-co1.bigfish.com (Postfix) with ESMTP id B19CC340048 for ; Wed, 1 Aug 2012 22:00:24 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 22:00:23 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Wed, 1 Aug 2012 22:00:19 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Core -31 and OAuth Bearer -23 specs published Thread-Index: Ac1wMQh2r03CznjvS0Cd8xGLzmA7lg== Date: Wed, 1 Aug 2012 22:00:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436674FB6E@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436674FB6ETK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] OAuth Core -31 and OAuth Bearer -23 specs published X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:00:51 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436674FB6ETK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hopefully final versions of the OAuth Core and Bearer specs have been publi= shed. These versions correct an editorial issue with the security clarific= ation made in Core -30 and remove David Recordon from the author lists, at = his request. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-oauth-v2-31 * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23 Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-31 are: * Clarify that any client can send client_id but that sending it is onl= y required when using the code flow if the client is not otherwise authenti= cated. * Removed David Recordon's name from the author list, at his request. Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23 are: * Removed David Recordon's name from the author list, at his request. HTML-formatted versions are available at: * http://self-issued.info/docs/draft-ietf-oauth-v2-31.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-23.html -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436674FB6ETK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hopefully final versions of the OAuth Core and Beare= r specs have been published.  These versions correct an editorial issu= e with the security clarification made in Core -30 and remove David Recordo= n from the author lists, at his request.

 

The specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-oauth-v2-31

·        http://tools.ietf.org/html/draft-ietf-oauth-v2-bea= rer-23

 

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-31 are:

  • Clarify that any client can send client_id but that sending it is only required whe= n using the code flow if the client is not otherwise authenticated.
  • Removed David Recordon's name from the author lis= t, at his request.

 

Changes in http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23 are:

  • Removed David Recordon's name from the author list, at his request.=

 

HTML-formatted versions are available at:=

·        http://self-issued.info/docs/draft-ietf-oauth-v2-3= 1.html

·        http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-23.html

 

        &nbs= p;            &= nbsp;           &nbs= p;             =              --= Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739436674FB6ETK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Wed Aug 1 15:55:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9411E8125 for ; Wed, 1 Aug 2012 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.797 X-Spam-Level: X-Spam-Status: No, score=-3.797 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yojd0LbFVlmj for ; Wed, 1 Aug 2012 15:55:39 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB7A11E80BA for ; Wed, 1 Aug 2012 15:55:39 -0700 (PDT) Received: from mail46-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 1 Aug 2012 22:55:38 +0000 Received: from mail46-am1 (localhost [127.0.0.1]) by mail46-am1-R.bigfish.com (Postfix) with ESMTP id 41C794A01B0 for ; Wed, 1 Aug 2012 22:55:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I1b0bI542M4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail46-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail46-am1 (localhost.localdomain [127.0.0.1]) by mail46-am1 (MessageSwitch) id 1343861735401543_5204; Wed, 1 Aug 2012 22:55:35 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.239]) by mail46-am1.bigfish.com (Postfix) with ESMTP id 569154E003F for ; Wed, 1 Aug 2012 22:55:35 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 1 Aug 2012 22:55:34 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Wed, 1 Aug 2012 22:55:21 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Approved: draft-ietf-oauth-v2-bearer Thread-Index: AQHNcDiein5cSfhHdUmxAa2sBlk6QZdFkO4g Date: Wed, 1 Aug 2012 22:55:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436674FDC9@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <5019B387.9020407@cs.tcd.ie> In-Reply-To: <5019B387.9020407@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] FW: Approved: draft-ietf-oauth-v2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:55:40 -0000 FYI -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Wednesday, August 01, 2012 3:54 PM To: draft-ietf-oauth-v2-bearer@tools.ietf.org; IESG; oauth-chairs@tools.iet= f.org Subject: Approved: draft-ietf-oauth-v2-bearer Dear secretariat folks, draft-ietf-oauth-v2-bearer is approved, the RFC editor notes are correct. P= lease shoot it off to the RFC editor. Thanks, Stephen. From dick.hardt@gmail.com Wed Aug 1 16:06:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D1811E8159 for ; Wed, 1 Aug 2012 16:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9Yk-kf1xv12 for ; Wed, 1 Aug 2012 16:06:31 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C839111E8117 for ; Wed, 1 Aug 2012 16:06:31 -0700 (PDT) Received: by yhq56 with SMTP id 56so8552393yhq.31 for ; Wed, 01 Aug 2012 16:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=dv/74u2gZo/dTrwksP65uH0NyGZP41GaLaVxqes0z6M=; b=sVjWHIdm4fVF+r8jbMLt3HS+0uw+i8Vd4g1SGLqTGbT4zTifSWA6duhlDhFKMewKO3 nWaxHy2TygJm1c5lHrqev/Tcu9DzR+Vziobc6nQGAG0VcpeFok4qLcjbhuY3EQTRPqkN XfwIjyTJIwHbS32yVhLtBlWHc4crMsjApQAlHvQd6gUFgBs8zRfw9dwCZDndpJC1ag8j Xs9bw6XWb3Yqy9HHrcgswuosQs/c9yvR2oAU62VU/evxbsRIjyasaUfX7J0Vsfs1Lzot b2m35l0BGLmS9tI3KN5pSKIMzx5fnMzn4Hhkfo8WgYE8KRpXhDYfb389HwcPqO5JLU0i aVTA== Received: by 10.50.190.163 with SMTP id gr3mr6876570igc.74.1343862391048; Wed, 01 Aug 2012 16:06:31 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id a10sm8270127igd.1.2012.08.01.16.06.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 16:06:30 -0700 (PDT) From: Dick Hardt Content-Type: multipart/alternative; boundary="Apple-Mail=_71AA403C-35DB-482D-BE39-9F8811296113" Date: Wed, 1 Aug 2012 16:06:29 -0700 References: <5019B384.30805@cs.tcd.ie> To: oauth WG Message-Id: <596EE4FF-4A35-4B11-B585-068FBAAC8991@gmail.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [OAUTH-WG] Fwd: Approved: draft-ietf-oauth-v2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:06:32 -0000 --Apple-Mail=_71AA403C-35DB-482D-BE39-9F8811296113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI Begin forwarded message: > From: Stephen Farrell > Subject: Approved: draft-ietf-oauth-v2 > Date: August 1, 2012 3:53:56 PM PDT > Resent-To: dick.hardt@gmail.com, dr@fb.com > Resent-To: derek@ihtfp.com, Hannes.Tschofenig@gmx.net, > To: draft-ietf-oauth-v2@tools.ietf.org, IESG , = "oauth-chairs@tools.ietf.org" >=20 >=20 > Dear secretariat folks, >=20 > draft-ietf-oauth-v2 is approved, the RFC editor notes are correct. > Please shoot it off to the RFC editor. >=20 > Thanks, > Stephen. --Apple-Mail=_71AA403C-35DB-482D-BE39-9F8811296113 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
From: Stephen Farrell = <stephen.farrell@cs.tcd.ie>= ;
Subject: Approved: = draft-ietf-oauth-v2
Date: August 1, 2012 3:53:56 PM PDT


Dear secretariat = folks,

draft-ietf-oauth-v2 is approved, the RFC editor notes are = correct.
Please shoot it off to the RFC = editor.

Thanks,
Stephen.

= = --Apple-Mail=_71AA403C-35DB-482D-BE39-9F8811296113-- From iesg-secretary@ietf.org Wed Aug 1 17:10:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8821F898C; Wed, 1 Aug 2012 17:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1vVIhAR0fzC; Wed, 1 Aug 2012 17:10:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DAE21F87F7; Wed, 1 Aug 2012 17:10:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120802001002.21023.57516.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 17:10:02 -0700 Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:10:25 -0000 The IESG has approved the following document: - 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' (draft-ietf-oauth-v2-bearer-23.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ Technical Summary This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to granted resources (without demonstrating possession of a cryptographic key). To prevent misuse, the bearer token MUST be protected from disclosure in storage and in transport. Working Group Summary The working group decided to develop two types of mechanisms for a client to access a protected resource. The second specification is being worked on with draft-ietf-oauth-v2-http-mac. The two specifications offer different security properties to allow deployments to meet their specific needs. Document Quality This specification is implemented, deployed and used by Microsoft Access Control Service (ACS), Google Apps, Facebook Connect and the Graph API, Salesforce, Mitre, and many others. Source code is available as well. For example http://static.springsource.org/spring-security/oauth/ http://incubator.apache.org/projects/amber.html https://github.com/nov/rack-oauth2 + many more, including those listed at https://github.com/teohm/teohm.github.com/wiki/OAuth Personnel Hannes Tschofenig is the document shepherd. Stephen Farrell is the responsible AD. RFC Editor Note 1) Please replace text in section 2.1 as follows: OLD: The "Authorization" header field uses the framework defined by HTTP/1.1 [RFC2617] as follows: NEW: The syntax of the "Authorization" header field for this scheme follows the usage of the Basic scheme defined in Section 2 of [RFC2617]. Note that, as with Basic, it does not conform to the generic syntax defined in Section 1.2 of [RFC2617], but that it is compatible with the the general authentication framework being developed for HTTP 1.1 [I-D.ietf-httpbis-p7-auth], although it does not follow the preferred practice outlined therein in order to reflect existing deployments. The syntax for Bearer credentials is as follows: 2) Please add the informative reference needed by the above in section 7.2, to this Internet draft: http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth From iesg-secretary@ietf.org Wed Aug 1 17:14:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA56F21F89BF; Wed, 1 Aug 2012 17:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abfUclEALXN0; Wed, 1 Aug 2012 17:14:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9940011E81A2; Wed, 1 Aug 2012 17:14:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120802001424.27749.61170.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2012 17:14:24 -0700 Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:14:27 -0000 The IESG has approved the following document: - 'The OAuth 2.0 Authorization Framework' (draft-ietf-oauth-v2-31.txt) as Proposed Standard This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Technical Summary The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. Working Group Summary There have been a number of controversies over the course of the development of OAuth 2.0. All were eventually worked out to the satisfaction of the working group as a whole, and the result has significant consensus in the group, but some of it hasn't been easy. The native application scenario (see section 9) remains a significant point in question: applications that users install -- perhaps may be convinced to install by malefactors -- are always a difficult security point, and that is true with OAuth as well. As the text in the document says, these "may require special consideration", particularly in regard to security. Because OAuth is trying to tie together applications and services from different trust domains, and because it is relying on end users to make important decisions, largely based on what they're told by the user interfaces, there are an extraordinary set of possible threats and security considerations involved. The working group has chosen to handle this with a Security Considerations section that covers general issues and focuses on protocol issues, and a separate document (draft-ietf-oauth-v2-threatmodel) that describes detailed threats and further security considerations in more depth than would be possible in the base protocol spec. There has been a great deal of discussion about where the line is -- what should go into the Security Considerations (section 10) in the base spec, and what will be in the companion document (to which there is an informative reference at the beginning of section 10). In the end, the current text reflects strong working group consensus, though it is not without disagreement. The working group believes the two documents together do the right job, they continue to work on draft-ietf-oauth-v2-threatmodel, and they expect to complete that document within the next months. Document Quality There has been fairly broad deployment of OAuth 1.0, from such companies as Yahoo!, Facebook, Google, and Twitter, and many of the existing deployments have been keeping up with the OAuth 2.0 progress, and adjusting their implementations accordingly. Quite a number of working-group participants have given the current spec very thorough review. Personnel Derek Atkins is the document shepherd. Stephen Farrell is the responsible AD. RFC Editor Note none From derek@ihtfp.com Wed Aug 1 17:21:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F8211E8106 for ; Wed, 1 Aug 2012 17:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.969 X-Spam-Level: X-Spam-Status: No, score=-101.969 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znbxp3q6UM5K for ; Wed, 1 Aug 2012 17:21:35 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9686211E80D7 for ; Wed, 1 Aug 2012 17:21:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 64C7F260268; Wed, 1 Aug 2012 20:21:34 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 03826-10; Wed, 1 Aug 2012 20:21:32 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 273A9260245; Wed, 1 Aug 2012 20:21:32 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id q720LTad019946; Wed, 1 Aug 2012 20:21:29 -0400 From: Derek Atkins To: Torsten Lodderstedt References: <09CE58C6-9409-4E28-B4CA-DC76C37B898E@gmx.net> <4E1F6AAD24975D4BA5B16804296739436672BBBE@TK5EX14MBXC285.redmond.corp.microsoft.com> <6DEBD33A-815E-460D-934E-A684AED2BA6B@ve7jtb.com> <5E393DF26B791A428E5F003BB6C5342A108171DC@OC11EXPO24.exchange.mit.edu> <50101C74.6060005@lodderstedt.net> <5779a15a8c83bd9cb0626a5c933d3e89@lodderstedt-online.de> Date: Wed, 01 Aug 2012 20:21:27 -0400 In-Reply-To: <5779a15a8c83bd9cb0626a5c933d3e89@lodderstedt-online.de> (Torsten Lodderstedt's message of "Wed, 01 Aug 2012 17:31:54 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: Derek Atkins , oauth@ietf.org Subject: [OAUTH-WG] Remote Participation for Vancouver (was Re: Meeting slot for the Vancouver IETF meeting requested) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:21:37 -0000 Hi, You can find remote participation info at: http://www.ietf.org/meeting/84/remote-participation.html Hannes, I am assuming that you will set up as the WebEx Host during the meeting tomorrow? I'm just not 100% sure how to audio *in* remotely. Worst case I'll just use Jabber to send back in. -derek Torsten Lodderstedt writes: > Hi Derek, > > I will give it a try. Where can I find the respective meeting data? > > regards, > Torsten. > > Am 30.07.2012 19:55, schrieb Derek Atkins: >> We will have a WebEx available if you can attend remotely? >> That's my plan, as I cannot make Vancouver this week. >> >> -derek >> >> Torsten Lodderstedt writes: >> >>> Hi Hannes, >>> >>> I'm unfortunately had to cancel my trip to IETF-84. Phil will cover >>> the status >>> of the threat model document. But none of the authors of the >>> Revocation Draft >>> will be attending. So I would ask you to postpone the presentation >>> of this I-D >>> to the next IETF meeting as well. >>> >>> best regards, >>> Torsten. >>> >>> Am 23.07.2012 17:02, schrieb Thomas Hardjono: >>> >>> Hannes, Derek, >>> >>> Would it possible to postpone presentation/discussion of the >>> Dyn-Reg >>> draft (Dynamic Client Registration Protocol) to the >>> Atlanta/November >>> IETF meeting? >>> >>> The reason is that none of the proposers will be attending the >>> Vancouver IETF in-person. >>> >>> Thanks. >>> >>> /thomas/ >>> >>> __________________________________________ >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org >>> [mailto:oauth-bounces@ietf.org] On >>> >>> Behalf >>> >>> Of Hannes Tschofenig >>> Sent: Sunday, July 15, 2012 1:58 PM >>> To: John Bradley >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Meeting slot for the Vancouver IETF >>> meeting >>> requested >>> >>> Hi all, >>> >>> I have uploaded an agenda for the meeting. >>> >>> I am assuming that all these items do not require >>> discussion time >>> 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 >>> >>> Hence, we can focus on the new items. As discussed in the >>> mail below >>> >>> I >>> >>> put a separate slot for discussion of the >>> holder-of-the-key/MAC >>> >>> token >>> >>> security discussion on the agenda. I would suggest that a >>> couple of >>> >>> us >>> >>> meeting during the IETF week to work together on a >>> presentation that >>> provides some concrete suggestions for next steps to the >>> rest of the >>> group. >>> >>> I also put the following persons on the spot for the >>> presentations >>> >>> of >>> >>> working group items: >>> >>> - OAuth Dynamic Client Registration Protocol (Thomas) >>> - JSON Web Token (JWT) (Mike) >>> - JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 >>> (Mike) >>> - Token Revocation (Torsten) >>> - SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 (Brian) >>> - OAuth Use Cases (Zachary) >>> >>> Let me know if you want someone else to give the >>> presentation. >>> >>> As a preparation for the meeting it would be good if you >>> could >>> (a) identify the open issues with your document, and >>> (b) find one or two reviewers to have a look at your >>> document during >>> the next two weeks. >>> >>> Ciao >>> Hannes >>> >>> On Jul 15, 2012, at 5:59 PM, John Bradley wrote: >>> >>> Yes we need to get clearer on the the threats and use >>> cases. >>> >>> I think Phil Hunt has some though there is likely >>> overlap. >>> >>> Part of the problem with MAC was people never agreed on >>> the >>> >>> threats >>> >>> it was mitigating. >>> >>> I can present something or coordinate with Tony or Phil. >>> >>> John B. >>> >>> On 2012-07-14, at 9:36 PM, Anthony Nadalin wrote: >>> >>> How about a few min on proof-of-possession >>> requirements? I can >>> >>> present our use cases and requirements >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org >>> [mailto:oauth-bounces@ietf.org] On >>> >>> Behalf Of Mike Jones >>> >>> Sent: Friday, July 13, 2012 4:42 PM >>> To: Hannes Tschofenig; oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Meeting slot for the >>> Vancouver IETF >>> >>> meeting >>> >>> requested >>> >>> I'm willing to do 5 minutes on the status of the >>> Core and Bearer >>> >>> documents. >>> >>> I'm willing to give an update on JWT and the JWT >>> Bearer - >>> >>> probably >>> >>> 15 minutes. It's probably good that we're a day after the >>> JOSE WG >>> meeting, given the JWT dependency upon the JOSE specs. >>> >>> I'm willing to be part of a discussion on the >>> Assertions draft, >>> >>> but >>> >>> would appreciate doing this with Brian and/or Chuck - I'm >>> guessing >>> >>> 15 >>> >>> minutes for that as well. (I'm not certain this will be >>> needed, but >>> I'd like to review the recent changes before saying that >>> it's not.) >>> >>> Looking forward to seeing many of you in Vancouver! >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org >>> [mailto:oauth-bounces@ietf.org] On >>> >>> Behalf Of Hannes Tschofenig >>> >>> Sent: Saturday, June 02, 2012 12:46 AM >>> To: oauth@ietf.org WG >>> 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 >>> -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From stephen.farrell@cs.tcd.ie Thu Aug 2 10:30:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C7111E8186 for ; Thu, 2 Aug 2012 10:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je2o6Q6dik92 for ; Thu, 2 Aug 2012 10:30:25 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7E311E817C for ; Thu, 2 Aug 2012 10:30:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 07D5B17147A; Thu, 2 Aug 2012 18:30:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1343928622; bh=rfhR45gnr9huZj /SN0p4fHPbqngvtIiw3zBI5Exalw4=; b=148oy5zZzD3vBua3dpnFvmK405p6cB 7VKHgh3ohqljZDlCY15JBJ0xY3HN8HiVuh+lPgX0kvxW7717B3+4iSxcROeK4WMv t66KdshGQsMZBazGQpP2QHdVDNJUEJKqu+oXLiat0EZodFkSSTVPt55QxRUmW8eg +t2t9Pg7kxOTO4s3tseF5sxW8Q0o7yOioIeZY52+90+vwGOSt4P/lOmemHXpXyOv mC6ZUZzpquP0CPbBMjWXL4beAm10kHp4QCMPbcPnqsMfHvCQIArdlv075BPcoOv3 47FPGyIw4BQh8IwlmoFlWXtnF7ogZpeds0MtQrQSfqS4z4Eo2yNpnJ3Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Cd-mHznCfbsb; Thu, 2 Aug 2012 18:30:22 +0100 (IST) Received: from [130.129.103.171] (dhcp-67ab.meeting.ietf.org [130.129.103.171]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F1269171477; Thu, 2 Aug 2012 18:30:12 +0100 (IST) Message-ID: <501AB920.1070007@cs.tcd.ie> Date: Thu, 02 Aug 2012 18:30:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Phil Hunt References: <4FC3C53E.8020704@cs.tcd.ie> <4FEB4B0C.2030700@lodderstedt.net> <4FEBA286.6020003@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Derek Atkins , "oauth@ietf.org" , Barry Leiba Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:30:29 -0000 Since I'm told this is now ready, I've put this on the August 30th telechat. Note there is an RFC editor note [1] calling for making the reference to oauth core normative. S. [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/writeup/ On 06/28/2012 04:21 AM, Phil Hunt wrote: > Stephen > > One more threat has come up in the core spec that is being looked at. As Torsten is heading out on vacation I have agreed to augment if needed with any supplementary text to the threat model. > > Will keep you informed. > > Phil > > On 2012-06-27, at 17:17, Stephen Farrell wrote: > >> >> Hiya, >> >> Great. I've asked for IETF LC to start. I'll go through >> the changes below during that in case there's some more >> follow up. >> >> Thanks, >> S. >> >> On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote: >>> Hi Stephen, >>> >>> I just submitted a new revision of the security document incorporating >>> your review comments. >>> >>> Please find answers to your comments below. >>> >>> Thank you again for your detailed review. You helped us to significantly >>> improve the document's quality. >>> >>> best regards, >>> Torsten. >>> >>> Am 28.05.2012 20:34, schrieb Stephen Farrell: >>>> Hi all, >>>> >>>> I've gotten the publication request for oauth-threatmodel >>>> so here's my AD review of -05. >>>> >>>> Its quite a read (and a good one) but I've a bunch of >>>> questions. Some of these will need fixing I suspect >>>> but a lot are ok to fix later after IETF LC, depending >>>> on whether the authors want to re-spin it before then >>>> or not. But I'd like to at least see reactions to the >>>> questions before I start IETF LC. >>>> >>>> Although there are many many nits and typos, those >>>> don't actually make the document unreadable so >>>> though I'd prefer to see 'em fixed now, I'm ok with >>>> that happening later if its a problem to get it >>>> all done now. >>>> >>>> If you want to argue for going ahead with IETF LC >>>> now please do so, but I suspect that this might need >>>> a revised ID to fix at least a couple of the points >>>> raised below. If nobody does argue to go ahead now, >>>> I'll mark it as revised ID needed, but first let's >>>> see what the answers are to the questions. >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>> (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. >>> done >>>> (2) You don't say anything about the probability of >>>> occurrence of the various threats. I realise that you >>>> can't be precise but it seems wrong to say nothing. Would >>>> it be worth at least saying that that's not done here and >>>> that readers of this document need to do their own risk >>>> analysis including that aspect? >>> >>> That's correct - I added the following paragraph to the introduction: >>> >>> "Note: This document cannot assess the probability nor the risk >>> associated with a particular threat because those aspects strongly >>> depend on the particular application and deployment OAuth is used to >>> protect. Similar, impacts are given on a rather abstract level. But the >>> information given here may serve as a foundation for deployment-specific >>> threat models. Implementors may refine and detail the abstract threat >>> model in order to account for the specific properties of their >>> deployment and to come up with a risk analysis." >>> >>>> (3) Many deployments will use TLS accelerators. That >>>> means that TLS isn't fully e2e, and that opens up some >>>> (mainly) insider attacks or attacks that can be launched >>>> from within a compromised DMZ, but from outside the server >>>> applications. Does that need a mention somewhere? (I've >>>> seen systems like that deployed and a lot could go wrong >>>> from the inside, so I think this is a real threat.) >>> >>> I added another paragraph to section 5.1.1: >>> >>> "Note: this document assumes end-to-end TLS protected connections >>> between the respective protocol entities. Deployments deviating from >>> this assumption by offloading TLS in between (e.g. on the data center >>> edge) must refine this threat model in order to account for the >>> additional (mainly insider) threat this may cause." >>> >>>> (4) Could you use just one of "client identity" or "client >>>> identifier" consistently? I'd much prefer the latter, >>>> which has also been the outcome of various discussions on >>>> this topic elsewhere. For example you say "revocation of >>>> such an identity" at the end of p13, and that's a >>>> potential rathole, better to say "revocation of the rights >>>> associated with a client identifier" or similar I think. >>>> And similar changes throughout. >>> >>> Replaced client identity by client identifier in most places and >>> incorporated your proposed text >>> >>>> (5) 4.4.2.2: Here you recommend native applications should >>>> use an embedded browser, but earlier you said that was a >>>> bad idea. I think you need to be consistent or else >>>> provide more about when its ok to embed and when its not. >>>> Did I misread it or does that need a change? >>> >>> removed 3rd bullet as native apps should use code flow >>> >>> We also removed the 1st bullet in 4.4.1.9 >>> >>>> (6) 4.4.3.1: This calls for "obfuscation" of passwords in >>>> logs. I think you ought be stronger there and call for >>>> strong encryption of passwords wherever they are stored, >>>> be that logs or DBs or whatever. Would'nt that be reasonable? >>> >>> This section is about preventing accidential exposure by the client. I >>> think encryption is not appropriate here since the password is entered >>> in the clear by the user. I added the advice to encrypt credentials as >>> alternative means to salted hashes to 5.1.4.1.3. >>> >>>> (7) 4.6.4: 1st countermeasure: I don't think you mean >>>> address here (in the sense of an IP address, which is what >>>> that means) but rather the domain name or FQDN or URL. In >>>> any case, you need to say what is meant clearly. (Also in >>>> 5.1.5.6 and elsewhere when you use the term "address".) >>> >>> replaced address in most cases by URL and in some place by FDQN >>> >>>> (8) 4.6.6: You say to use Cache-Control, but don't say >>>> how. Is more needed really? Maybe there's a good document >>>> you could reference for that? (I'm not suggesting you add >>>> a lecture on caching btw:-) >>> >>> Added text from core spec describing usage of Cache-Control and Pragma >>> response header fields >>> >>>> (9) 5.1.1: needs a reference to RFC 5246 (and better to >>>> just say TLS and not say SSL, at least for me :-) >>> >>> done >>>> (10) 5.1.1: needs a reference to whatever you mean by >>>> "VPN" since there are many types of VPN. I assume you mean >>>> an IPsec VPN? But even if not, saying more would be good. >>> >>> Extended description and added reference to RFC 4301. >>>> (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 >>>> and/or RFC 2818. Bascially, you need to say how this is >>>> done (by reference). >>> >>> Added reference to RFC 2818 since it seems to be closest to the problem >>> >>>> (12) 5.1.4.1: Isn't there some good reference you can give >>>> here? (Having said that, I'd have to go look myself, but >>>> I'd maybe start with owasp or sans.) >>> >>> added reference to OWASP >>> >>>> (13) 5.1.4.2.2: if p(collision) should be <=2^(-160) then >>>> what's the point of saying it ought be <= 2^(-128)? Also >>>> if sha-1 were perfect, then the 160 bits output would >>>> really have a collision probability of about 2^(-80) with >>>> many many tokens, but not 2^(-160). I think you need >>>> to fix something there. Perhaps you're really saying that >>>> all high-entropy secrets should be >=128 bits long and >>>> constructed with a good (P)RNG? If so, saying so more >>>> clearly would be better. Not everyone will get the >>>> collision probability way of saying that even when its >>>> properly stated. (This text is also repeated, be better if >>>> you just said this once I think.) >>> >>> modified text as follows >>> >>> "When creating secrets not intended for usage by human users (e.g. >>> client secrets or token handles), the authorization server should >>> include a reasonable level of entropy in order to mitigate the risk of >>> guessing attacks. The token value should be >=128 bits long and >>> constructed from a cryptographically strong random or pseudo-random >>> number sequence (see [RFC4086] for best current practice) generated by >>> the Authorization Server." >>> >>> removed 5.1.5.11. (redundant text) and updated references accordingly >>> >>>> (14) 5.1.5.2: what is a "reasonable duration" - I don't >>>> think its ok to say that but nothing else. Can't you give >>>> some "reasonable" examples based on current usage? >>> >>> added examples and explanation of factors determining reasonable >>> expiration time >>> >>> "Tokens should generally expire after a reasonable duration. This >>> complements and strengthens other security measures (such as signatures) >>> and reduces the impact of all kinds of token leaks. Depending on the >>> risk associated with a token leakage, tokens may expire after a few >>> minutes (e.g. for payment transactions) or stay valid for hours (e.g. >>> read access to contacts). >>> >>> The expiration time is determined by a couple of factors, including: >>> >>> - risk associated to a token leakage >>> - duration of the underlying access grant, >>> - duration until the modification of an access grant should take effect, >>> and >>> - time required for an attacker to guess or produce valid token." >>> >>>> (15) 5.1.5.5: needs a reference to SAML assertions with >>>> the current text. >>> >>> done - also added reference to RFC4120 in section 3.1 >>>> (16) 5.2.2.3: this describes a refresh token rotation >>>> scheme that I don't recall being discussed on the list, so >>>> this is just to check that that rotation scheme, as >>>> described, doesn't ring any alarms bells for the WG. If >>>> not, that's fine. And if it was discussed on the list and >>>> I've forgotten, then sorry about that:-) >>> >>> It has been discussed, the first time with the introduction of the >>> option to return a new referesh token value in response to a refresh >>> token grant request. A more recent discussion can be found here: >>> http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html >>> >>>> (17) 5.2.2.5: Using IMEI's like this has privacy >>>> implications that I think you ought call out. A single >>>> sentence and a reference to something that says "be >>>> careful about privacy here" would be fine I'd say. (And >>>> you need a reference for "IMEI" and to expand the term.) >>> >>> added note and reference to respective 3gpp spec >>> >>>> (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. >>>> There's a websec draft about that I think. >>> >>> added reference to >>> http://tools.ietf.org/html/draft-gondrom-x-frame-options/ >>>> (19) 5.2.3.4: what do you mean when you say "for different >>>> deployments of a client"? That could be one secret per >>>> install or one secret for all customers of a mobile >>>> operator and those are radically different. I think you >>>> need to be clear and hope you mean the former. That's >>>> almost cleared up in the 3rd paragraph of the section but >>>> I wanted to just check. Not sure "deployment" is the best >>>> term there really - what's wrong with "installation"? >>> >>> nothing is wrong with "installation" :-) >>> >>> replaced deployment by installation and partially re-phrased section >>> >>>> (many:-) nits and typos: >>>> >>>> 2.3.1: maybe explain "handle-based design" or give a >>>> reference? (Or maybe just a forward ref to 3.1?) >>> >>> added ref to 3.1 >>>> 2.3.3: It might be worth re-iterating that the term >>>> "client" in oauth is used differently, e.g. by copying a >>>> bit of text from the base spec. I can see folks being >>>> confused by this otherwise. >>> >>> copied a sentence from base spec and extended description >>> >>>> 3.1: "is digitally signed" - do you mean it has data >>>> integrity and origin authentication? If MACs are commonly >>>> used (or maybe authenticated encryption), and not >>>> necessarily signatures, then saying that would be better. >>> >>> we mean data integrity and origin authentication - added some text to >>> explain this >>> >>>> 3.1.2: typo: s/this mechanisms/this mechanism/ >>>> >>>> 3.1.2: maybe s/Expires_In/expires_in/ to match the case in >>>> the base spec? I think it'd be better not to capitalise >>>> this in case it finds its way into someone's code. You >>>> could also use "Expires In" in the title and then say that >>>> its "expires_in" in the protocol. Might be worth doing >>>> something generic to call out when you're talking about >>>> specific things from the protocol, e.g. use a convention >>>> like ``expires_in'' or "expires_in" consistently and say >>>> that in the intro. >>> >>> Renamed section to "Limited access token limetime" and changed wording >>> to explicitely distinct between concept and protocol parameter. >>> >>>> 3.4: typo: s/the later/the latter/ >>>> >>>> 3.4: bullet item 1 isn't really a reason for anything but >>>> a downside of doing this, at least as written. Maybe this >>>> needs to be tweaked? >>> >>> tweaked it >>>> 3.6: expand CSRF on 1st use and maybe give a reference >>>> CSRF is expanded in 4.4.1.8 which is a good bit later, >>>> and also in 4.4.2.5 which could presumably be >>>> shortened a bit by removing the repetition. >>> >>> expanded CSRF a bit, added forward reference to 4.4.1.8 and shortened >>> 4.4.2.5 >>> >>>> 3.7: typo: s/collage associated request/collate associated >>>> requests/ >>>> >>>> 3.7: Maybe give a pointer to the definition of "native >>>> application" in the base spec (Its section 9 of that.) >>>> 2nd last para of p13 would be a good place for that. >>> >>> added pointer >>> >>>> section 4: maybe s/Security Threat Model/Threat Model/ >>>> in the section title - what other kind of threat >>>> model is there? >>> >>> changed to Threat Model >>> >>>> section 4: I wondered how we know the threat model >>>> is "comprehensive"? Perhaps "detailed" is better? >>> >>> We are rather confident because we created the threat model a systematic >>> way and had it reviewed by a lot of security folks >>> >>>> 4.2.1: typo: s/Users/users/g unless you mean something >>>> special? >>>> >>>> 4.2.2: typo: s/a understandable/an understandable/ >>>> >>>> 4.2.2: "...based on who the client is." is unclear >>>> and not gramatically nice:-) "...based on the client >>>> identifier." would seem better. >>>> >>>> 4.3.1: typo? s/on transit/in transit/ Or did you >>>> mean something else? and s/may attempts/may attempt/ >>>> >>>> 4.3.3: maybe s/Revelation/Disclosure/ to be a tad >>>> less biblical:-) >>> >>> changed to "Revelation of client credentials during transmission" >>> >>>> 4.3.3: typo? 1st countermeasure reads oddly and >>>> refers to a different place than other references >>>> to TLS - is that correct? >>> >>> changed to standard wording >>> >>>> 4.3.3: digest auth is nearly the same as sending >>>> credentials over the wire, TLS client auth based >>>> on certificates would be a better example, even >>>> if its not often done. >>> >>> Isn't TLS client authentication always combined with TLS protected >>> communication? So this would merly be an additional and not alternative >>> mechanism. >>> >>>> 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. >>>> Maybe it ought to? >>> >>> Sorry, don't understand this comment. Are you saying 5.1.4.1.2 should >>> point back to 4.3.2? >>> >>>> 4.3.6: typo s/an authorization servers/an authorization >>>> server/ >>>> >>>> 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there >>>> a reason to not do that here too? >>> >>> this section discussed a potential threat on dynamic client >>> registration. Wen decided to remove the whole section as dynamic client >>> registration is subject of current charter and respective security >>> considerations should delt with in this context. >>> >>>> 4.4: typo? s/tokens endpoint/token endpoint/ ? >>>> >>>> 4.4.1.1: typo: s/by different ways/in different ways/ >>>> >>>> 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, >>>> but you fixed their typo here - might be better to live >>>> with the bad spelling, in which case >>>> s/referrer/referer/g;-) >>> >>> ok :-) >>> >>>> 4.4.1.1: Is there no better way to reference these >>>> OASIS docs? More importantly, is there no better (more >>>> stable) reference than thomasgross.net for the >>>> PDF you reference? Tidying this up would be good. >>> >>> added references to OASIS documents and stable reference to 3rd document >>> in proceedings of Computer Security Applications Conference >>> >>>> 4.4.1.1 and elsewhere: a few times you say "such as >>>> TLS or SSL," I think it'd be better to just say TLS >>>> there and do it consistently everwhere. In other >>>> places (e.g. 4.4.1.5) you say "HTTPS" - again that'd >>>> be better done consistently. >>> >>> removed SSL - would you expect us to replace HTTPS by TLS? We used HTTPS >>> for the more specific case of HTTP+TLS >>> >>>> 4.4.1.1: typo: s/redeem a authorization code/redeem >>>> an authorizatio code/ >>>> >>>> 4.4.1.4: "counterfeit a valid client" reads oddly, >>>> do you mean "pretend to be a valid client"? If so, >>>> I think that'd be clearer. >>>> >>>> 4.4.1.4: "and to prevent unauthorized access to >>>> them" - I think you might add "via the oauth >>>> protocol" there since the AS isn't responsible for >>>> all possible ways of preventing unauthorized access. >>>> >>>> 4.4.1.4: typo: s/not neccesserily indicates/doesn't >>>> necessarily indicate/ >>>> >>>> 4.4.1.4: typo: s/user should be explained the purpose/ >>>> something better/ :-) >>> >>> tried my best: >>> >>> "In this context, the authorization server should explain to the >>> end-user the purpose, scope, and duration of the authorization the >>> client asked for. " >>> >>> >>>> 4.4.1.4: expand/define CAPTCHA on 1st use. Give a >>>> reference for this too. Especially since you also >>>> have 5.1.4.2.5, which is maybe the best place for >>>> the reference. >>> >>> Changed counter measure paragraph from: >>> "If the authorization server automatically authenticates the end- >>> user, it may nevertheless require some user input in order to >>> prevent screen scraping. Examples are CAPTCHAs or user-specific >>> secrets like PIN codes." >>> to: >>> "If the authorization server automatically authenticates the end-user, >>> it may nevertheless require some user input in order to prevent screen >>> scraping. Examples are CAPTCHAs (Completely Automated Public Turing test >>> to tell Computers and Humans Apart) or other multi-factor authentication >>> techniques such as random questions, token code generators, etc." >>> >>> >>>> 4.4.1.4: isn't a PIN code another user authentiation? >>>> Seems like a bad example of automatic authentication, >>>> since it isn't automatic if the user has to enter a >>>> PIN. >>> >>> see above >>>> 4.4.1.6: Is Facebook a trademark? Maybe better to not >>>> use that if so? >>> >>> Changed Facebook reference section to: >>> (e.g. as in the implementation of "Login" button to a third-party social >>> network site) >>> >>> >>>> 4.4.1.7: typo: s/achieve that goal/achieves that goal/ >>>> >>>> 4.4.1.7: typo: s/victims resources/victim's resources/ >>>> >>>> 4.4.1.7: typo: s/The attackers gains/The attacker gains/ >>>> >>>> 4.4.1.7: typo: s/then the target web site/rather than >>>> the target web site/ >>>> >>>> 4.4.1.7: "session fixation" could do with a reference >>>> or definition, and that might be better earlier in >>>> this section and not just in the countermeasures >>>> part. >>> >>> changed >>> >>> "The authorization server may also enforce the usage and validation of >>> pre-registered redirect URIs (see Section 5.2.3.5). This will allow for >>> an early recognition of session fixation attempts." >>> to: >>> "The authorization server may also enforce the usage and validation of >>> pre-registered redirect URIs (see Section 5.2.3.5). This will allow for >>> an early recognition of authorization code disclosure to counterfeit >>> clients." >>> >>> >>>> 4.4.1.7: typo: s/kind of attacks/kind of attack/ >>>> >>>> 4.4.1.8: typo: s/not follow untrusted/to not follow >>>> untrusted/ >>>> >>>> 4.4.1.9: maybe add a reference for "iframe"? And >>>> you say "iFrames" later, better to be consistent. >>>> >>>> 4.4.1.9: 1st countermeasure - do you mean end-user >>>> authorization here or end-user authentication? And >>>> would it be better to say "system browser" or >>>> something rather than "external browser"? (I forget >>>> what phrase you used for that earlier but there >>>> was something bettter:-) >>> >>> We mean "authorization" >>> >>> We came to the conclusion that it does not matter in which browser the >>> page is loaded - removed 1st bullet >>> >>>> 4.4.1.9: "javascript framebusting" really needs >>>> a reference >>> added >>>> 4.4.1.10: typo: s/the victims resources/the victim's >>>> resources/ >>>> >>>> 4.4.1.10: typo: s/or split the/or splits the/ >>>> >>>> 4.4.1.10: "corresponding form post requests" isn't >>>> clear to me - does that need rephrasing or is it >>>> just me? >>>> >>>> 4.4.1.10: this is the first mention of cookies, which >>>> I found surprising, but that's all;-) >>>> >>>> 4.4.1.10: the 2nd "ways to achieve this" bullet is >>>> a bit unclear - which "It" and whose browser? I >>>> think this could be clearer. >>>> >>>> 4.4.1.10: typo: s/as native app/as a native application/ >>>> >>>> 4.4.1.10: what does "assume" the threat mean? >>>> >>>> 4.4.1.10: typo: s/an user interaction/a user interaction/ >>>> >>>> 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get >>>> rid of the "or" from the last bullet >>>> >>>> 4.4.1.10: typo: s/send out of bound/sent out of band/ >>>> >>>> 4.4.1.10: typo: s/instance message/instant message/ >>> >>> considerably re-worded this section >>> >>>> 4.4.1.11: typo? s/directing user(s) browser/directing >>>> the user's browser/ ? >>>> >>>> 4.4.1.11: I don't get the explanation here. Are you >>>> assuming (but not saying) that generating non-trivial >>>> entropy is a slow process? (e.g. /dev/random blocking?) >>>> Its also not clear what "pool" you mean? This probably >>>> needs a bit of tweaking. >>>> >>>> 4.4.1.12: semicomplete.com may not be a sufficiently >>>> stable reference - can't you find a better one? >>> >>> unfortunately not >>>> 4.4.1.12: typo: s/Defenses such rate limiting/Defenses >>>> such as rate limiting/ >>>> >>>> 4.4.1.12: typo: s/an anonymizing systems/an anonymizing >>>> system/ >>>> >>>> 4.4.1.12: nicest typo yet! s/annoying system/anonymizing >>>> system/ :-) >>>> >>>> 4.4.1.12: typo? maybe s/iframe/iFrame/ again? >>>> >>>> 4.4.1.12: 1st reference to "the CSRF token" here? That >>>> might warrant a reference of some sort? (Maybe to >>>> a later section?) >>>> >>>> 4.4.1.12: Facebook again. >>>> >>>> 4.4.1.12: Signing the code seems like a bit of a hack. Do >>>> you really want to recommend this here? I suspect it'd end >>>> up different if you actually tried it out aiming for an >>>> interoperable solution. I'd suggest deleting this, or >>>> maybe make it less specific, e.g. saying if origin >>>> authentication for authorization codes could be validated >>>> by clients, then that'd be a countermeasure, but that >>>> there's no current spec for that. (And doing that might >>>> just move the DoS to somewhere else depending how you >>>> did it.) >>>> >>>> 4.4.2: typo: s/and It cannot/and it cannot/ >>>> >>>> 4.4.2.1: Is the countermeasure here TLS? If so, better to >>>> say so. >>>> >>>> 4.4.2.2: requests aren't cached are they but rather >>>> responses? >>>> >>>> 4.4.2.3: typo: s/An malicious/A malicious/ >>>> >>>> 4.4.2.3: The reference back to 4.4.1.4 isn't very >>>> clear since a lot of the countermeasures there >>>> mention authentication. It'd be better to explicitly >>>> list things here or else if you stick with the >>>> backwards reference to be more explicit about whic >>>> exactly apply. >>>> >>>> 4.4.2.5: Is this entirely identical to 4.4.1.8? That >>>> doesn't seem right. If it is, then say so explicitly. >>>> If not, then say what's different. >>>> >>>> 4.4.3: 1st mention of username/password anti-pattern, >>>> so you could add a reference >>>> >>>> 4.4.3: Be good to metion here that passwords are often >>>> used for >1 service, so this anti-pattern risks whatever >>>> else is accessible with that credential or an >>>> algorithmically derivable equivalent (e.g. >>>> joe@example.com/pwd might easily allow someone to guess >>>> that the same pwd is used forjoe.user@example.net) and >>>> then another countermeasure is to educate users to >>>> not use the same pwd for multiple services (hard as >>>> that is to really do;-) >>>> >>>> 4.4.3.4: again digest auth isn't a good example >>>> here, but client certs are. >>>> >>>> 4.4.3.6: What does "Abandon on grant type..." mean? >>>> If you mean "don't do this" then say that more >>>> clearly. >>> >>> Changed to "Consider not to use grant type "password"" >>> >>>> 4.6.2: typo: s/transport security measure/transport >>>> security measures/ or maybe just say TLS >>>> >>>> 4.6.2: typo: s/nounces/nonces/ >>>> >>>> 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ >>>> I don't see why "difficult" guessing is hard enough? >>>> >>>> 4.6.4: typo: s/a valid access tokens/a valid access token/ >>>> >>>> 4.6.4: Do you mean the IP address in the 2nd >>>> countermeasure? I'm not sure, esp. given the above. >>>> >>>> 4.6.4: typo: s/miss the capabilities/lack the capability/ >>>> >>>> 4.6.6: reference to 2616 is broken >>>> >>>> 4.6.6: Should you reference httpbis drafts? Just asking, I >>>> can see arguments for referencing just 2616 or just >>>> httpbis or both, given that this'll be read for hopefully >>>> a while after httpbis is done. >>>> >>>> 4.6.7: referrer vs. referer again >>>> >>>> 4.6.7: What is an appropriat logging configuration? Can >>>> you give a reference maybe or is it really that well >>>> known? >>>> >>>> 4.6.7: Reloading the target page again? Are you really >>>> recommending that? >>>> >>>> 5.1: typo: s/consideratios/considerations/ >>>> >>>> 5.1.3: I think you should note the email notifications >>>> can be a phishing vector so don't make your emails >>>> such that lookalike phish messages can easily be >>>> derived from them. >>>> >>>> 5.1.3: Don't you need to say something about getting >>>> email notifications delivered and not treated as spam? >>>> Maybe you could recommend dkim here or other ways to >>>> get better delivery. (Not sure myself, probably best >>>> to ask someone who operates like this so see if there's >>>> stuff to be said.) >>>> >>>> 5.1.4.1.3: typo: s/not store credential/not store >>>> credentials/ >>>> >>>> 5.1.4.1.4: salted hashes don't prevent offline >>>> dictionary attacks, they just increase the workload >>>> >>>> 5.1.5.1.4: would it be worthwhile recommending that >>>> different client credentials be used in development >>>> or integration mode vs. when operational? I've seen >>>> a bunch of times when programmers were given "live" >>>> API keys when that could've been avoided. >>>> >>>> 5.1.4.1.5: I don't get this. If it was only that >>>> easy:-) I think you need to say which private keys >>>> are used here and for what for this section to be >>>> useful. >>>> >>>> 5.1.4.2.1: I think you could note that complex password >>>> policies can also increase the liklihood that users >>>> re-use passwords or write them down or store them >>>> somewhere not so good, if e.g. the entropy required >>>> over all the user's passwords (dozens usually) is >>>> too great for long-term memory. >>>> >>>> 5.1.5.1: typo: s/Basis of/The basis of/ >>>> >>>> 5.1.5.1: typo: s/sensible service/sensitive service/ >>>> (2nd best typo:-) >>>> >>>> 5.1.5.3: typo: s/preciser/more precise/ >>>> >>>> 5.1.5.3: typo: s/refreshments/refreshes/ >>>> >>>> 5.1.5.4: 2nd bullet is not a threat but a goal >>>> >>>> 5.1.5.4: typo: s/redeem a/redeem an/ >>>> >>>> 5.1.5.5: what is a "rough" server? Do you mean rogue? >>>> >>>> 5.5.5.6: I think you need to clarify what "address" >>>> means here too. >>>> >>>> 5.1.5.9: please clarify if you mean digitally signed >>>> (asymmetric) or also include MACing here >>>> >>>> 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ >>>> >>>> 5.1.5.10: s/privacy/confidentiality/ ? >>>> >>>> 5.1.5.10: this (typically, I'd guess) requires sharing >>>> symmetric keys between server nodes, so you should >>>> say that as its a bunch of work. >>>> >>>> 5.1.5.11: I don't get why you want to repeat this >>>> text (and its error:-) better to refer back to >>>> the earlier section I think. >>>> >>>> 5.1.5.12: Another place where a SAML reference would >>>> be needed. >>>> >>>> 5.1.6: 2nd bullet is not a "measure" but a goal. If >>>> you had something in mind, it doesn't come out from >>>> that text. >>>> >>>> 5.2.2.2: You say the binding should be protected, but >>>> don't say how. I think you ought. >>>> >>>> 5.2.3: typo: s/sub-sequent/subsequent/ but maybe >>>> better to delete the word >>>> >>>> 5.2.3: 2nd bullet - "trustworthiness" has gotta >>>> be the wrong word there, what did you mean? >>>> >>>> 5.2.3: typo: s/statics/statistics/ >>>> >>>> 5.2.3: typo: s/support achieve objectives/achieve these >>>> objectives/ ? >>>> >>>> 5.2.3: typo: s/by hand of an administrator/something >>>> better/ >>>> >>>> 5.2.3.1: "prevents...overestimating" seems wrong, I think >>>> you mean it reduces the probability of mistakenly treating >>>> a useless authentication as a good one. (The point is >>>> that servers don't "overestimate," only people do that.) >>>> >>>> 5.2.3.1: "cannot be entirely protected" seems like >>>> understatement - the reality is any such secret will >>>> leak out from anything that's any way successful. It >>>> only protects stuff that *nobody* cares about. >>>> >>>> 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it >>>> to not use the terms "trust" nor "identity" and then >>>> it'd be better I think. >>>> >>>> 5.2.3.2: typo? s/The authorization may/The authrozation >>>> server may/ ? Not sure what "issue a cliend id" means >>>> either. (Same in 5.2.3.3) >>>> >>>> 5.2.3.4: typo: s/A authorization server/An authorization >>>> server/ >>>> >>>> 5.2.3.5: what are "validated properties"? >>>> >>>> 5.2.3.5: what is the 1st bullet list on p57? there's >>>> no introductory text? >>>> >>>> 5.2.3.5: the "it" in "it only works" in the last >>>> paragraph isn't clear - which "it" do you mean? >>>> >>>> 5.2.3.5: saying discovery "gets involved" seems >>>> wrong - do you mean "is used"? And what is the >>>> "that" in "that's no longer feasible"? >>>> >>>> 5.2.3.6: typo: s/be unintentionally for/unintentionally >>>> affect/? >>>> >>>> 5.2.3.7: typo: s/to distribute client_secret/to >>>> distribute a client_secret/ >>>> >>>> 5.2.4.1: Is a "security certificate" a public key >>>> certificate? If so, saying that is better. >>>> >>>> 5.2.4.1: the references to 5.7.2.x are wrong and >>>> look like you're missing some xref's in the xml >>>> maybe >>>> >>>> 5.2.4.2: you said "address" again, so the usual >>>> question arises :-) >>>> >>>> 5.2.4.3: typo: s/in all situation/in situations/ >>>> (not sure "all" is right so suggest deleting it) >>>> >>>> 5.2.4.4: again, be good to say how to protect >>>> the binding >>>> >>>> 5.2.4.5: as for 5.2.4.4 say how binding is done >>>> >>>> 5.3.1: typo: s/a associated/an associated/ >>>> >>>> 5.3.1: "entirely protected" is (again:-) understatement >>>> see above for a suggestion >>>> >>>> 5.3.1: what does "trust on the client's identity" mean? >>>> Its not clear anyway >>>> >>>> 5.3.3: typo: s/operation systems/operating systems/ >>>> (enrire 2nd & 3rd paras could do with re-phrasing) >>>> >>>> 5.3.4: typo: s/their level/the level/ >>>> >>>> 5.3.5: this is too terse - is it really finished? I'd >>>> say there's a sentence or two missing. >>>> >>>> 5.4.2: what does it mean to "encourage resource >>>> servers" to do something? I guess you mean to encourage >>>> the people deploying those to pick resource servers >>>> with that capability and to turn that on. >>>> >>>> 5.4.2: not sure if everyone will know what a >>>> "distinguished name" is, maybe add a reference to >>>> rfc 5280? >>>> >>>> 5.4.2: token-bound secrets would be used to MAC >>>> the request and not to sign, be better to make that >>>> clear even if you still call that "signing" here >>>> (its not really, if we're being pedantic) >>>> >>>> 5.4.2: typo: s/This mechanisms/This mechanism/ >>>> >>>> 5.4.2 and 5.4.3: I forget - where are the protocol >>>> mechanisms for this defined? Can you give a reference >>>> or say that its future stuff if there aren't any >>>> good ones? >>>> >>>> 5.5: typo: s/capable to validate/capable of validating/ >>>> >>>> 8.1: Is the base spec really normative? I'd say you're >>>> fine with that as informative too. >>>> >>>> 8.2: there are a bunch of references missing as per >>>> the questions above >>>> >>>> 8.2: is there no better (more stable) reference than >>>> portablecontacts.net? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > From phil.hunt@oracle.com Thu Aug 2 11:07:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E5011E81E4 for ; Thu, 2 Aug 2012 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.717 X-Spam-Level: X-Spam-Status: No, score=-9.717 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4404j+Ai+bvC for ; Thu, 2 Aug 2012 11:07:11 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0725D11E81BF for ; Thu, 2 Aug 2012 11:07:10 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q72I6tWv021583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 18:06:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q72I6rqf009419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 18:06:53 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q72I6q2V030673; Thu, 2 Aug 2012 13:06:52 -0500 Received: from dhcp-1578.meeting.ietf.org (/130.129.21.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Aug 2012 11:06:52 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: <501AB920.1070007@cs.tcd.ie> Date: Thu, 2 Aug 2012 11:06:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38A1F1F5-3404-45A1-95AB-0D6F746FC763@oracle.com> References: <4FC3C53E.8020704@cs.tcd.ie> <4FEB4B0C.2030700@lodderstedt.net> <4FEBA286.6020003@cs.tcd.ie> <501AB920.1070007@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Derek Atkins , "oauth@ietf.org" , Barry Leiba Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-threatmodel-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:07:15 -0000 Stephen, I just realized we do have a deliverable to amend for a substitution = attack that came up late in the OAuth Core document. We are putting in a = parallel paragraph in the Threat Model document. Expect a new draft shortly.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-02, at 10:30 AM, Stephen Farrell wrote: >=20 > Since I'm told this is now ready, I've put this on the August 30th > telechat. Note there is an RFC editor note [1] calling for making > the reference to oauth core normative. >=20 > S. >=20 > [1] > = https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/writeup/ >=20 > On 06/28/2012 04:21 AM, Phil Hunt wrote: >> Stephen >>=20 >> One more threat has come up in the core spec that is being looked at. = As Torsten is heading out on vacation I have agreed to augment if needed = with any supplementary text to the threat model. >>=20 >> Will keep you informed.=20 >>=20 >> Phil >>=20 >> On 2012-06-27, at 17:17, Stephen Farrell = wrote: >>=20 >>>=20 >>> Hiya, >>>=20 >>> Great. I've asked for IETF LC to start. I'll go through >>> the changes below during that in case there's some more >>> follow up. >>>=20 >>> Thanks, >>> S. >>>=20 >>> On 06/27/2012 07:03 PM, Torsten Lodderstedt wrote: >>>> Hi Stephen, >>>>=20 >>>> I just submitted a new revision of the security document = incorporating >>>> your review comments. >>>>=20 >>>> Please find answers to your comments below. >>>>=20 >>>> Thank you again for your detailed review. You helped us to = significantly >>>> improve the document's quality. >>>>=20 >>>> best regards, >>>> Torsten. >>>>=20 >>>> Am 28.05.2012 20:34, schrieb Stephen Farrell: >>>>> Hi all, >>>>>=20 >>>>> I've gotten the publication request for oauth-threatmodel >>>>> so here's my AD review of -05. >>>>>=20 >>>>> Its quite a read (and a good one) but I've a bunch of >>>>> questions. Some of these will need fixing I suspect >>>>> but a lot are ok to fix later after IETF LC, depending >>>>> on whether the authors want to re-spin it before then >>>>> or not. But I'd like to at least see reactions to the >>>>> questions before I start IETF LC. >>>>>=20 >>>>> Although there are many many nits and typos, those >>>>> don't actually make the document unreadable so >>>>> though I'd prefer to see 'em fixed now, I'm ok with >>>>> that happening later if its a problem to get it >>>>> all done now. >>>>>=20 >>>>> If you want to argue for going ahead with IETF LC >>>>> now please do so, but I suspect that this might need >>>>> a revised ID to fix at least a couple of the points >>>>> raised below. If nobody does argue to go ahead now, >>>>> I'll mark it as revised ID needed, but first let's >>>>> see what the answers are to the questions. >>>>>=20 >>>>> Cheers, >>>>> S. >>>>>=20 >>>>>=20 >>>>> (1) s/RFC1750/RFC4086/ is needed as noted in the write-up. >>>> done >>>>> (2) You don't say anything about the probability of >>>>> occurrence of the various threats. I realise that you >>>>> can't be precise but it seems wrong to say nothing. Would >>>>> it be worth at least saying that that's not done here and >>>>> that readers of this document need to do their own risk >>>>> analysis including that aspect? >>>>=20 >>>> That's correct - I added the following paragraph to the = introduction: >>>>=20 >>>> "Note: This document cannot assess the probability nor the risk >>>> associated with a particular threat because those aspects strongly >>>> depend on the particular application and deployment OAuth is used = to >>>> protect. Similar, impacts are given on a rather abstract level. But = the >>>> information given here may serve as a foundation for = deployment-specific >>>> threat models. Implementors may refine and detail the abstract = threat >>>> model in order to account for the specific properties of their >>>> deployment and to come up with a risk analysis." >>>>=20 >>>>> (3) Many deployments will use TLS accelerators. That >>>>> means that TLS isn't fully e2e, and that opens up some >>>>> (mainly) insider attacks or attacks that can be launched >>>>> from within a compromised DMZ, but from outside the server >>>>> applications. Does that need a mention somewhere? (I've >>>>> seen systems like that deployed and a lot could go wrong >>>>> from the inside, so I think this is a real threat.) >>>>=20 >>>> I added another paragraph to section 5.1.1: >>>>=20 >>>> "Note: this document assumes end-to-end TLS protected connections >>>> between the respective protocol entities. Deployments deviating = from >>>> this assumption by offloading TLS in between (e.g. on the data = center >>>> edge) must refine this threat model in order to account for the >>>> additional (mainly insider) threat this may cause." >>>>=20 >>>>> (4) Could you use just one of "client identity" or "client >>>>> identifier" consistently? I'd much prefer the latter, >>>>> which has also been the outcome of various discussions on >>>>> this topic elsewhere. For example you say "revocation of >>>>> such an identity" at the end of p13, and that's a >>>>> potential rathole, better to say "revocation of the rights >>>>> associated with a client identifier" or similar I think. >>>>> And similar changes throughout. >>>>=20 >>>> Replaced client identity by client identifier in most places and >>>> incorporated your proposed text >>>>=20 >>>>> (5) 4.4.2.2: Here you recommend native applications should >>>>> use an embedded browser, but earlier you said that was a >>>>> bad idea. I think you need to be consistent or else >>>>> provide more about when its ok to embed and when its not. >>>>> Did I misread it or does that need a change? >>>>=20 >>>> removed 3rd bullet as native apps should use code flow >>>>=20 >>>> We also removed the 1st bullet in 4.4.1.9 >>>>=20 >>>>> (6) 4.4.3.1: This calls for "obfuscation" of passwords in >>>>> logs. I think you ought be stronger there and call for >>>>> strong encryption of passwords wherever they are stored, >>>>> be that logs or DBs or whatever. Would'nt that be reasonable? >>>>=20 >>>> This section is about preventing accidential exposure by the = client. I >>>> think encryption is not appropriate here since the password is = entered >>>> in the clear by the user. I added the advice to encrypt credentials = as >>>> alternative means to salted hashes to 5.1.4.1.3. >>>>=20 >>>>> (7) 4.6.4: 1st countermeasure: I don't think you mean >>>>> address here (in the sense of an IP address, which is what >>>>> that means) but rather the domain name or FQDN or URL. In >>>>> any case, you need to say what is meant clearly. (Also in >>>>> 5.1.5.6 and elsewhere when you use the term "address".) >>>>=20 >>>> replaced address in most cases by URL and in some place by FDQN >>>>=20 >>>>> (8) 4.6.6: You say to use Cache-Control, but don't say >>>>> how. Is more needed really? Maybe there's a good document >>>>> you could reference for that? (I'm not suggesting you add >>>>> a lecture on caching btw:-) >>>>=20 >>>> Added text from core spec describing usage of Cache-Control and = Pragma >>>> response header fields >>>>=20 >>>>> (9) 5.1.1: needs a reference to RFC 5246 (and better to >>>>> just say TLS and not say SSL, at least for me :-) >>>>=20 >>>> done >>>>> (10) 5.1.1: needs a reference to whatever you mean by >>>>> "VPN" since there are many types of VPN. I assume you mean >>>>> an IPsec VPN? But even if not, saying more would be good. >>>>=20 >>>> Extended description and added reference to RFC 4301. >>>>> (11) 5.1.2: needs a reference to RFC 5280 and/or RFC 6125 >>>>> and/or RFC 2818. Bascially, you need to say how this is >>>>> done (by reference). >>>>=20 >>>> Added reference to RFC 2818 since it seems to be closest to the = problem >>>>=20 >>>>> (12) 5.1.4.1: Isn't there some good reference you can give >>>>> here? (Having said that, I'd have to go look myself, but >>>>> I'd maybe start with owasp or sans.) >>>>=20 >>>> added reference to OWASP >>>>=20 >>>>> (13) 5.1.4.2.2: if p(collision) should be <=3D2^(-160) then >>>>> what's the point of saying it ought be <=3D 2^(-128)? Also >>>>> if sha-1 were perfect, then the 160 bits output would >>>>> really have a collision probability of about 2^(-80) with >>>>> many many tokens, but not 2^(-160). I think you need >>>>> to fix something there. Perhaps you're really saying that >>>>> all high-entropy secrets should be >=3D128 bits long and >>>>> constructed with a good (P)RNG? If so, saying so more >>>>> clearly would be better. Not everyone will get the >>>>> collision probability way of saying that even when its >>>>> properly stated. (This text is also repeated, be better if >>>>> you just said this once I think.) >>>>=20 >>>> modified text as follows >>>>=20 >>>> "When creating secrets not intended for usage by human users (e.g. >>>> client secrets or token handles), the authorization server should >>>> include a reasonable level of entropy in order to mitigate the risk = of >>>> guessing attacks. The token value should be >=3D128 bits long and >>>> constructed from a cryptographically strong random or pseudo-random >>>> number sequence (see [RFC4086] for best current practice) generated = by >>>> the Authorization Server." >>>>=20 >>>> removed 5.1.5.11. (redundant text) and updated references = accordingly >>>>=20 >>>>> (14) 5.1.5.2: what is a "reasonable duration" - I don't >>>>> think its ok to say that but nothing else. Can't you give >>>>> some "reasonable" examples based on current usage? >>>>=20 >>>> added examples and explanation of factors determining reasonable >>>> expiration time >>>>=20 >>>> "Tokens should generally expire after a reasonable duration. This >>>> complements and strengthens other security measures (such as = signatures) >>>> and reduces the impact of all kinds of token leaks. Depending on = the >>>> risk associated with a token leakage, tokens may expire after a few >>>> minutes (e.g. for payment transactions) or stay valid for hours = (e.g. >>>> read access to contacts). >>>>=20 >>>> The expiration time is determined by a couple of factors, = including: >>>>=20 >>>> - risk associated to a token leakage >>>> - duration of the underlying access grant, >>>> - duration until the modification of an access grant should take = effect, >>>> and >>>> - time required for an attacker to guess or produce valid token." >>>>=20 >>>>> (15) 5.1.5.5: needs a reference to SAML assertions with >>>>> the current text. >>>>=20 >>>> done - also added reference to RFC4120 in section 3.1 >>>>> (16) 5.2.2.3: this describes a refresh token rotation >>>>> scheme that I don't recall being discussed on the list, so >>>>> this is just to check that that rotation scheme, as >>>>> described, doesn't ring any alarms bells for the WG. If >>>>> not, that's fine. And if it was discussed on the list and >>>>> I've forgotten, then sorry about that:-) >>>>=20 >>>> It has been discussed, the first time with the introduction of the >>>> option to return a new referesh token value in response to a = refresh >>>> token grant request. A more recent discussion can be found here: >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg06974.html >>>>=20 >>>>> (17) 5.2.2.5: Using IMEI's like this has privacy >>>>> implications that I think you ought call out. A single >>>>> sentence and a reference to something that says "be >>>>> careful about privacy here" would be fine I'd say. (And >>>>> you need a reference for "IMEI" and to expand the term.) >>>>=20 >>>> added note and reference to respective 3gpp spec >>>>=20 >>>>> (18) 5.2.2.6: needs a reference for X-FRAME-OPTION. >>>>> There's a websec draft about that I think. >>>>=20 >>>> added reference to >>>> http://tools.ietf.org/html/draft-gondrom-x-frame-options/ >>>>> (19) 5.2.3.4: what do you mean when you say "for different >>>>> deployments of a client"? That could be one secret per >>>>> install or one secret for all customers of a mobile >>>>> operator and those are radically different. I think you >>>>> need to be clear and hope you mean the former. That's >>>>> almost cleared up in the 3rd paragraph of the section but >>>>> I wanted to just check. Not sure "deployment" is the best >>>>> term there really - what's wrong with "installation"? >>>>=20 >>>> nothing is wrong with "installation" :-) >>>>=20 >>>> replaced deployment by installation and partially re-phrased = section >>>>=20 >>>>> (many:-) nits and typos: >>>>>=20 >>>>> 2.3.1: maybe explain "handle-based design" or give a >>>>> reference? (Or maybe just a forward ref to 3.1?) >>>>=20 >>>> added ref to 3.1 >>>>> 2.3.3: It might be worth re-iterating that the term >>>>> "client" in oauth is used differently, e.g. by copying a >>>>> bit of text from the base spec. I can see folks being >>>>> confused by this otherwise. >>>>=20 >>>> copied a sentence from base spec and extended description >>>>=20 >>>>> 3.1: "is digitally signed" - do you mean it has data >>>>> integrity and origin authentication? If MACs are commonly >>>>> used (or maybe authenticated encryption), and not >>>>> necessarily signatures, then saying that would be better. >>>>=20 >>>> we mean data integrity and origin authentication - added some text = to >>>> explain this >>>>=20 >>>>> 3.1.2: typo: s/this mechanisms/this mechanism/ >>>>>=20 >>>>> 3.1.2: maybe s/Expires_In/expires_in/ to match the case in >>>>> the base spec? I think it'd be better not to capitalise >>>>> this in case it finds its way into someone's code. You >>>>> could also use "Expires In" in the title and then say that >>>>> its "expires_in" in the protocol. Might be worth doing >>>>> something generic to call out when you're talking about >>>>> specific things from the protocol, e.g. use a convention >>>>> like ``expires_in'' or "expires_in" consistently and say >>>>> that in the intro. >>>>=20 >>>> Renamed section to "Limited access token limetime" and changed = wording >>>> to explicitely distinct between concept and protocol parameter. >>>>=20 >>>>> 3.4: typo: s/the later/the latter/ >>>>>=20 >>>>> 3.4: bullet item 1 isn't really a reason for anything but >>>>> a downside of doing this, at least as written. Maybe this >>>>> needs to be tweaked? >>>>=20 >>>> tweaked it >>>>> 3.6: expand CSRF on 1st use and maybe give a reference >>>>> CSRF is expanded in 4.4.1.8 which is a good bit later, >>>>> and also in 4.4.2.5 which could presumably be >>>>> shortened a bit by removing the repetition. >>>>=20 >>>> expanded CSRF a bit, added forward reference to 4.4.1.8 and = shortened >>>> 4.4.2.5 >>>>=20 >>>>> 3.7: typo: s/collage associated request/collate associated >>>>> requests/ >>>>>=20 >>>>> 3.7: Maybe give a pointer to the definition of "native >>>>> application" in the base spec (Its section 9 of that.) >>>>> 2nd last para of p13 would be a good place for that. >>>>=20 >>>> added pointer >>>>=20 >>>>> section 4: maybe s/Security Threat Model/Threat Model/ >>>>> in the section title - what other kind of threat >>>>> model is there? >>>>=20 >>>> changed to Threat Model >>>>=20 >>>>> section 4: I wondered how we know the threat model >>>>> is "comprehensive"? Perhaps "detailed" is better? >>>>=20 >>>> We are rather confident because we created the threat model a = systematic >>>> way and had it reviewed by a lot of security folks >>>>=20 >>>>> 4.2.1: typo: s/Users/users/g unless you mean something >>>>> special? >>>>>=20 >>>>> 4.2.2: typo: s/a understandable/an understandable/ >>>>>=20 >>>>> 4.2.2: "...based on who the client is." is unclear >>>>> and not gramatically nice:-) "...based on the client >>>>> identifier." would seem better. >>>>>=20 >>>>> 4.3.1: typo? s/on transit/in transit/ Or did you >>>>> mean something else? and s/may attempts/may attempt/ >>>>>=20 >>>>> 4.3.3: maybe s/Revelation/Disclosure/ to be a tad >>>>> less biblical:-) >>>>=20 >>>> changed to "Revelation of client credentials during transmission" >>>>=20 >>>>> 4.3.3: typo? 1st countermeasure reads oddly and >>>>> refers to a different place than other references >>>>> to TLS - is that correct? >>>>=20 >>>> changed to standard wording >>>>=20 >>>>> 4.3.3: digest auth is nearly the same as sending >>>>> credentials over the wire, TLS client auth based >>>>> on certificates would be a better example, even >>>>> if its not often done. >>>>=20 >>>> Isn't TLS client authentication always combined with TLS protected >>>> communication? So this would merly be an additional and not = alternative >>>> mechanism. >>>>=20 >>>>> 4.3.4: 4.3.2 points to 5.1.4.1.2 but this doesn't. >>>>> Maybe it ought to? >>>>=20 >>>> Sorry, don't understand this comment. Are you saying 5.1.4.1.2 = should >>>> point back to 4.3.2? >>>>=20 >>>>> 4.3.6: typo s/an authorization servers/an authorization >>>>> server/ >>>>>=20 >>>>> 4.3.6: 4.3.5 refers to 5.1.4.2.2 wrt entropy. Is there >>>>> a reason to not do that here too? >>>>=20 >>>> this section discussed a potential threat on dynamic client >>>> registration. Wen decided to remove the whole section as dynamic = client >>>> registration is subject of current charter and respective security >>>> considerations should delt with in this context. >>>>=20 >>>>> 4.4: typo? s/tokens endpoint/token endpoint/ ? >>>>>=20 >>>>> 4.4.1.1: typo: s/by different ways/in different ways/ >>>>>=20 >>>>> 4.4.1.1: typo-fix-typo? HTTP has a "Referer" header field, >>>>> but you fixed their typo here - might be better to live >>>>> with the bad spelling, in which case >>>>> s/referrer/referer/g;-) >>>>=20 >>>> ok :-) >>>>=20 >>>>> 4.4.1.1: Is there no better way to reference these >>>>> OASIS docs? More importantly, is there no better (more >>>>> stable) reference than thomasgross.net for the >>>>> PDF you reference? Tidying this up would be good. >>>>=20 >>>> added references to OASIS documents and stable reference to 3rd = document >>>> in proceedings of Computer Security Applications Conference >>>>=20 >>>>> 4.4.1.1 and elsewhere: a few times you say "such as >>>>> TLS or SSL," I think it'd be better to just say TLS >>>>> there and do it consistently everwhere. In other >>>>> places (e.g. 4.4.1.5) you say "HTTPS" - again that'd >>>>> be better done consistently. >>>>=20 >>>> removed SSL - would you expect us to replace HTTPS by TLS? We used = HTTPS >>>> for the more specific case of HTTP+TLS >>>>=20 >>>>> 4.4.1.1: typo: s/redeem a authorization code/redeem >>>>> an authorizatio code/ >>>>>=20 >>>>> 4.4.1.4: "counterfeit a valid client" reads oddly, >>>>> do you mean "pretend to be a valid client"? If so, >>>>> I think that'd be clearer. >>>>>=20 >>>>> 4.4.1.4: "and to prevent unauthorized access to >>>>> them" - I think you might add "via the oauth >>>>> protocol" there since the AS isn't responsible for >>>>> all possible ways of preventing unauthorized access. >>>>>=20 >>>>> 4.4.1.4: typo: s/not neccesserily indicates/doesn't >>>>> necessarily indicate/ >>>>>=20 >>>>> 4.4.1.4: typo: s/user should be explained the purpose/ >>>>> something better/ :-) >>>>=20 >>>> tried my best: >>>>=20 >>>> "In this context, the authorization server should explain to the >>>> end-user the purpose, scope, and duration of the authorization the >>>> client asked for. " >>>>=20 >>>>=20 >>>>> 4.4.1.4: expand/define CAPTCHA on 1st use. Give a >>>>> reference for this too. Especially since you also >>>>> have 5.1.4.2.5, which is maybe the best place for >>>>> the reference. >>>>=20 >>>> Changed counter measure paragraph from: >>>> "If the authorization server automatically authenticates the end- >>>> user, it may nevertheless require some user input in order to >>>> prevent screen scraping. Examples are CAPTCHAs or = user-specific >>>> secrets like PIN codes." >>>> to: >>>> "If the authorization server automatically authenticates the = end-user, >>>> it may nevertheless require some user input in order to prevent = screen >>>> scraping. Examples are CAPTCHAs (Completely Automated Public Turing = test >>>> to tell Computers and Humans Apart) or other multi-factor = authentication >>>> techniques such as random questions, token code generators, etc." >>>>=20 >>>>=20 >>>>> 4.4.1.4: isn't a PIN code another user authentiation? >>>>> Seems like a bad example of automatic authentication, >>>>> since it isn't automatic if the user has to enter a >>>>> PIN. >>>>=20 >>>> see above >>>>> 4.4.1.6: Is Facebook a trademark? Maybe better to not >>>>> use that if so? >>>>=20 >>>> Changed Facebook reference section to: >>>> (e.g. as in the implementation of "Login" button to a third-party = social >>>> network site) >>>>=20 >>>>=20 >>>>> 4.4.1.7: typo: s/achieve that goal/achieves that goal/ >>>>>=20 >>>>> 4.4.1.7: typo: s/victims resources/victim's resources/ >>>>>=20 >>>>> 4.4.1.7: typo: s/The attackers gains/The attacker gains/ >>>>>=20 >>>>> 4.4.1.7: typo: s/then the target web site/rather than >>>>> the target web site/ >>>>>=20 >>>>> 4.4.1.7: "session fixation" could do with a reference >>>>> or definition, and that might be better earlier in >>>>> this section and not just in the countermeasures >>>>> part. >>>>=20 >>>> changed >>>>=20 >>>> "The authorization server may also enforce the usage and validation = of >>>> pre-registered redirect URIs (see Section 5.2.3.5). This will = allow for >>>> an early recognition of session fixation attempts." >>>> to: >>>> "The authorization server may also enforce the usage and validation = of >>>> pre-registered redirect URIs (see Section 5.2.3.5). This will = allow for >>>> an early recognition of authorization code disclosure to = counterfeit >>>> clients." >>>>=20 >>>>=20 >>>>> 4.4.1.7: typo: s/kind of attacks/kind of attack/ >>>>>=20 >>>>> 4.4.1.8: typo: s/not follow untrusted/to not follow >>>>> untrusted/ >>>>>=20 >>>>> 4.4.1.9: maybe add a reference for "iframe"? And >>>>> you say "iFrames" later, better to be consistent. >>>>>=20 >>>>> 4.4.1.9: 1st countermeasure - do you mean end-user >>>>> authorization here or end-user authentication? And >>>>> would it be better to say "system browser" or >>>>> something rather than "external browser"? (I forget >>>>> what phrase you used for that earlier but there >>>>> was something bettter:-) >>>>=20 >>>> We mean "authorization" >>>>=20 >>>> We came to the conclusion that it does not matter in which browser = the >>>> page is loaded - removed 1st bullet >>>>=20 >>>>> 4.4.1.9: "javascript framebusting" really needs >>>>> a reference >>>> added >>>>> 4.4.1.10: typo: s/the victims resources/the victim's >>>>> resources/ >>>>>=20 >>>>> 4.4.1.10: typo: s/or split the/or splits the/ >>>>>=20 >>>>> 4.4.1.10: "corresponding form post requests" isn't >>>>> clear to me - does that need rephrasing or is it >>>>> just me? >>>>>=20 >>>>> 4.4.1.10: this is the first mention of cookies, which >>>>> I found surprising, but that's all;-) >>>>>=20 >>>>> 4.4.1.10: the 2nd "ways to achieve this" bullet is >>>>> a bit unclear - which "It" and whose browser? I >>>>> think this could be clearer. >>>>>=20 >>>>> 4.4.1.10: typo: s/as native app/as a native application/ >>>>>=20 >>>>> 4.4.1.10: what does "assume" the threat mean? >>>>>=20 >>>>> 4.4.1.10: typo: s/an user interaction/a user interaction/ >>>>>=20 >>>>> 4.4.1.10: typo: s/CAPTCAs, or/CAPTCHAs/ or else get >>>>> rid of the "or" from the last bullet >>>>>=20 >>>>> 4.4.1.10: typo: s/send out of bound/sent out of band/ >>>>>=20 >>>>> 4.4.1.10: typo: s/instance message/instant message/ >>>>=20 >>>> considerably re-worded this section >>>>=20 >>>>> 4.4.1.11: typo? s/directing user(s) browser/directing >>>>> the user's browser/ ? >>>>>=20 >>>>> 4.4.1.11: I don't get the explanation here. Are you >>>>> assuming (but not saying) that generating non-trivial >>>>> entropy is a slow process? (e.g. /dev/random blocking?) >>>>> Its also not clear what "pool" you mean? This probably >>>>> needs a bit of tweaking. >>>>>=20 >>>>> 4.4.1.12: semicomplete.com may not be a sufficiently >>>>> stable reference - can't you find a better one? >>>>=20 >>>> unfortunately not >>>>> 4.4.1.12: typo: s/Defenses such rate limiting/Defenses >>>>> such as rate limiting/ >>>>>=20 >>>>> 4.4.1.12: typo: s/an anonymizing systems/an anonymizing >>>>> system/ >>>>>=20 >>>>> 4.4.1.12: nicest typo yet! s/annoying system/anonymizing >>>>> system/ :-) >>>>>=20 >>>>> 4.4.1.12: typo? maybe s/iframe/iFrame/ again? >>>>>=20 >>>>> 4.4.1.12: 1st reference to "the CSRF token" here? That >>>>> might warrant a reference of some sort? (Maybe to >>>>> a later section?) >>>>>=20 >>>>> 4.4.1.12: Facebook again. >>>>>=20 >>>>> 4.4.1.12: Signing the code seems like a bit of a hack. Do >>>>> you really want to recommend this here? I suspect it'd end >>>>> up different if you actually tried it out aiming for an >>>>> interoperable solution. I'd suggest deleting this, or >>>>> maybe make it less specific, e.g. saying if origin >>>>> authentication for authorization codes could be validated >>>>> by clients, then that'd be a countermeasure, but that >>>>> there's no current spec for that. (And doing that might >>>>> just move the DoS to somewhere else depending how you >>>>> did it.) >>>>>=20 >>>>> 4.4.2: typo: s/and It cannot/and it cannot/ >>>>>=20 >>>>> 4.4.2.1: Is the countermeasure here TLS? If so, better to >>>>> say so. >>>>>=20 >>>>> 4.4.2.2: requests aren't cached are they but rather >>>>> responses? >>>>>=20 >>>>> 4.4.2.3: typo: s/An malicious/A malicious/ >>>>>=20 >>>>> 4.4.2.3: The reference back to 4.4.1.4 isn't very >>>>> clear since a lot of the countermeasures there >>>>> mention authentication. It'd be better to explicitly >>>>> list things here or else if you stick with the >>>>> backwards reference to be more explicit about whic >>>>> exactly apply. >>>>>=20 >>>>> 4.4.2.5: Is this entirely identical to 4.4.1.8? That >>>>> doesn't seem right. If it is, then say so explicitly. >>>>> If not, then say what's different. >>>>>=20 >>>>> 4.4.3: 1st mention of username/password anti-pattern, >>>>> so you could add a reference >>>>>=20 >>>>> 4.4.3: Be good to metion here that passwords are often >>>>> used for >1 service, so this anti-pattern risks whatever >>>>> else is accessible with that credential or an >>>>> algorithmically derivable equivalent (e.g. >>>>> joe@example.com/pwd might easily allow someone to guess >>>>> that the same pwd is used forjoe.user@example.net) and >>>>> then another countermeasure is to educate users to >>>>> not use the same pwd for multiple services (hard as >>>>> that is to really do;-) >>>>>=20 >>>>> 4.4.3.4: again digest auth isn't a good example >>>>> here, but client certs are. >>>>>=20 >>>>> 4.4.3.6: What does "Abandon on grant type..." mean? >>>>> If you mean "don't do this" then say that more >>>>> clearly. >>>>=20 >>>> Changed to "Consider not to use grant type "password"" >>>>=20 >>>>> 4.6.2: typo: s/transport security measure/transport >>>>> security measures/ or maybe just say TLS >>>>>=20 >>>>> 4.6.2: typo: s/nounces/nonces/ >>>>>=20 >>>>> 4.6.3: 1st countermeasure: maybe s/difficult/infeasible/ >>>>> I don't see why "difficult" guessing is hard enough? >>>>>=20 >>>>> 4.6.4: typo: s/a valid access tokens/a valid access token/ >>>>>=20 >>>>> 4.6.4: Do you mean the IP address in the 2nd >>>>> countermeasure? I'm not sure, esp. given the above. >>>>>=20 >>>>> 4.6.4: typo: s/miss the capabilities/lack the capability/ >>>>>=20 >>>>> 4.6.6: reference to 2616 is broken >>>>>=20 >>>>> 4.6.6: Should you reference httpbis drafts? Just asking, I >>>>> can see arguments for referencing just 2616 or just >>>>> httpbis or both, given that this'll be read for hopefully >>>>> a while after httpbis is done. >>>>>=20 >>>>> 4.6.7: referrer vs. referer again >>>>>=20 >>>>> 4.6.7: What is an appropriat logging configuration? Can >>>>> you give a reference maybe or is it really that well >>>>> known? >>>>>=20 >>>>> 4.6.7: Reloading the target page again? Are you really >>>>> recommending that? >>>>>=20 >>>>> 5.1: typo: s/consideratios/considerations/ >>>>>=20 >>>>> 5.1.3: I think you should note the email notifications >>>>> can be a phishing vector so don't make your emails >>>>> such that lookalike phish messages can easily be >>>>> derived from them. >>>>>=20 >>>>> 5.1.3: Don't you need to say something about getting >>>>> email notifications delivered and not treated as spam? >>>>> Maybe you could recommend dkim here or other ways to >>>>> get better delivery. (Not sure myself, probably best >>>>> to ask someone who operates like this so see if there's >>>>> stuff to be said.) >>>>>=20 >>>>> 5.1.4.1.3: typo: s/not store credential/not store >>>>> credentials/ >>>>>=20 >>>>> 5.1.4.1.4: salted hashes don't prevent offline >>>>> dictionary attacks, they just increase the workload >>>>>=20 >>>>> 5.1.5.1.4: would it be worthwhile recommending that >>>>> different client credentials be used in development >>>>> or integration mode vs. when operational? I've seen >>>>> a bunch of times when programmers were given "live" >>>>> API keys when that could've been avoided. >>>>>=20 >>>>> 5.1.4.1.5: I don't get this. If it was only that >>>>> easy:-) I think you need to say which private keys >>>>> are used here and for what for this section to be >>>>> useful. >>>>>=20 >>>>> 5.1.4.2.1: I think you could note that complex password >>>>> policies can also increase the liklihood that users >>>>> re-use passwords or write them down or store them >>>>> somewhere not so good, if e.g. the entropy required >>>>> over all the user's passwords (dozens usually) is >>>>> too great for long-term memory. >>>>>=20 >>>>> 5.1.5.1: typo: s/Basis of/The basis of/ >>>>>=20 >>>>> 5.1.5.1: typo: s/sensible service/sensitive service/ >>>>> (2nd best typo:-) >>>>>=20 >>>>> 5.1.5.3: typo: s/preciser/more precise/ >>>>>=20 >>>>> 5.1.5.3: typo: s/refreshments/refreshes/ >>>>>=20 >>>>> 5.1.5.4: 2nd bullet is not a threat but a goal >>>>>=20 >>>>> 5.1.5.4: typo: s/redeem a/redeem an/ >>>>>=20 >>>>> 5.1.5.5: what is a "rough" server? Do you mean rogue? >>>>>=20 >>>>> 5.5.5.6: I think you need to clarify what "address" >>>>> means here too. >>>>>=20 >>>>> 5.1.5.9: please clarify if you mean digitally signed >>>>> (asymmetric) or also include MACing here >>>>>=20 >>>>> 5.1.5.10: typo: s/Self-contained/Self-contained tokens/ >>>>>=20 >>>>> 5.1.5.10: s/privacy/confidentiality/ ? >>>>>=20 >>>>> 5.1.5.10: this (typically, I'd guess) requires sharing >>>>> symmetric keys between server nodes, so you should >>>>> say that as its a bunch of work. >>>>>=20 >>>>> 5.1.5.11: I don't get why you want to repeat this >>>>> text (and its error:-) better to refer back to >>>>> the earlier section I think. >>>>>=20 >>>>> 5.1.5.12: Another place where a SAML reference would >>>>> be needed. >>>>>=20 >>>>> 5.1.6: 2nd bullet is not a "measure" but a goal. If >>>>> you had something in mind, it doesn't come out from >>>>> that text. >>>>>=20 >>>>> 5.2.2.2: You say the binding should be protected, but >>>>> don't say how. I think you ought. >>>>>=20 >>>>> 5.2.3: typo: s/sub-sequent/subsequent/ but maybe >>>>> better to delete the word >>>>>=20 >>>>> 5.2.3: 2nd bullet - "trustworthiness" has gotta >>>>> be the wrong word there, what did you mean? >>>>>=20 >>>>> 5.2.3: typo: s/statics/statistics/ >>>>>=20 >>>>> 5.2.3: typo: s/support achieve objectives/achieve these >>>>> objectives/ ? >>>>>=20 >>>>> 5.2.3: typo: s/by hand of an administrator/something >>>>> better/ >>>>>=20 >>>>> 5.2.3.1: "prevents...overestimating" seems wrong, I think >>>>> you mean it reduces the probability of mistakenly treating >>>>> a useless authentication as a good one. (The point is >>>>> that servers don't "overestimate," only people do that.) >>>>>=20 >>>>> 5.2.3.1: "cannot be entirely protected" seems like >>>>> understatement - the reality is any such secret will >>>>> leak out from anything that's any way successful. It >>>>> only protects stuff that *nobody* cares about. >>>>>=20 >>>>> 5.2.3.1: typo: s/trust on/trust/ But I'd rephrase it >>>>> to not use the terms "trust" nor "identity" and then >>>>> it'd be better I think. >>>>>=20 >>>>> 5.2.3.2: typo? s/The authorization may/The authrozation >>>>> server may/ ? Not sure what "issue a cliend id" means >>>>> either. (Same in 5.2.3.3) >>>>>=20 >>>>> 5.2.3.4: typo: s/A authorization server/An authorization >>>>> server/ >>>>>=20 >>>>> 5.2.3.5: what are "validated properties"? >>>>>=20 >>>>> 5.2.3.5: what is the 1st bullet list on p57? there's >>>>> no introductory text? >>>>>=20 >>>>> 5.2.3.5: the "it" in "it only works" in the last >>>>> paragraph isn't clear - which "it" do you mean? >>>>>=20 >>>>> 5.2.3.5: saying discovery "gets involved" seems >>>>> wrong - do you mean "is used"? And what is the >>>>> "that" in "that's no longer feasible"? >>>>>=20 >>>>> 5.2.3.6: typo: s/be unintentionally for/unintentionally >>>>> affect/? >>>>>=20 >>>>> 5.2.3.7: typo: s/to distribute client_secret/to >>>>> distribute a client_secret/ >>>>>=20 >>>>> 5.2.4.1: Is a "security certificate" a public key >>>>> certificate? If so, saying that is better. >>>>>=20 >>>>> 5.2.4.1: the references to 5.7.2.x are wrong and >>>>> look like you're missing some xref's in the xml >>>>> maybe >>>>>=20 >>>>> 5.2.4.2: you said "address" again, so the usual >>>>> question arises :-) >>>>>=20 >>>>> 5.2.4.3: typo: s/in all situation/in situations/ >>>>> (not sure "all" is right so suggest deleting it) >>>>>=20 >>>>> 5.2.4.4: again, be good to say how to protect >>>>> the binding >>>>>=20 >>>>> 5.2.4.5: as for 5.2.4.4 say how binding is done >>>>>=20 >>>>> 5.3.1: typo: s/a associated/an associated/ >>>>>=20 >>>>> 5.3.1: "entirely protected" is (again:-) understatement >>>>> see above for a suggestion >>>>>=20 >>>>> 5.3.1: what does "trust on the client's identity" mean? >>>>> Its not clear anyway >>>>>=20 >>>>> 5.3.3: typo: s/operation systems/operating systems/ >>>>> (enrire 2nd & 3rd paras could do with re-phrasing) >>>>>=20 >>>>> 5.3.4: typo: s/their level/the level/ >>>>>=20 >>>>> 5.3.5: this is too terse - is it really finished? I'd >>>>> say there's a sentence or two missing. >>>>>=20 >>>>> 5.4.2: what does it mean to "encourage resource >>>>> servers" to do something? I guess you mean to encourage >>>>> the people deploying those to pick resource servers >>>>> with that capability and to turn that on. >>>>>=20 >>>>> 5.4.2: not sure if everyone will know what a >>>>> "distinguished name" is, maybe add a reference to >>>>> rfc 5280? >>>>>=20 >>>>> 5.4.2: token-bound secrets would be used to MAC >>>>> the request and not to sign, be better to make that >>>>> clear even if you still call that "signing" here >>>>> (its not really, if we're being pedantic) >>>>>=20 >>>>> 5.4.2: typo: s/This mechanisms/This mechanism/ >>>>>=20 >>>>> 5.4.2 and 5.4.3: I forget - where are the protocol >>>>> mechanisms for this defined? Can you give a reference >>>>> or say that its future stuff if there aren't any >>>>> good ones? >>>>>=20 >>>>> 5.5: typo: s/capable to validate/capable of validating/ >>>>>=20 >>>>> 8.1: Is the base spec really normative? I'd say you're >>>>> fine with that as informative too. >>>>>=20 >>>>> 8.2: there are a bunch of references missing as per >>>>> the questions above >>>>>=20 >>>>> 8.2: is there no better (more stable) reference than >>>>> portablecontacts.net? >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 From sakimura@gmail.com Thu Aug 2 22:38:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3EE11E80D7 for ; Thu, 2 Aug 2012 22:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0-XJzMmXxwt for ; Thu, 2 Aug 2012 22:38:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF27311E80D5 for ; Thu, 2 Aug 2012 22:38:35 -0700 (PDT) Received: by yhq56 with SMTP id 56so404757yhq.31 for ; Thu, 02 Aug 2012 22:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9Lkkf/uiqpJ3fUi9RAaycSDOWIrdv1LuhOvPLMETUNU=; b=ZYtEduxcjXafjacRbDSyiNlwfYUdPMXJE1iqQBkFLS38KI2VppEV7WYvrKwTRjiy/d etWgAGRQ9IyxGTEWe3uYR8gttqCI28kst6rYtaTTG8l8KnOO4TSbFcb3yJmD73qWkt2l lx6iyro6t39/9oAfFGHRvHzGN0hJ5SE8HL2qbIdEjBDJA6Jmlgq/oleum+Ck407h34m+ aqy1Krvv3D9PCJZxC9qv0Yq/l4DzeU48VFfzYpEq3N0kzEMWFpg/FPHNqOUm9EvUG4BL 8b7gUfSCfLghTEAS8Y6you+ZQQlhRYpbk/uUQg2UV/mCI4IfWybp7sdKbpoaD+yXpAbi uLPA== MIME-Version: 1.0 Received: by 10.50.208.34 with SMTP id mb2mr8507428igc.5.1343972315213; Thu, 02 Aug 2012 22:38:35 -0700 (PDT) Received: by 10.64.148.71 with HTTP; Thu, 2 Aug 2012 22:38:35 -0700 (PDT) Date: Thu, 2 Aug 2012 22:38:35 -0700 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=14dae9340cad6faf9a04c655f0bb Subject: [OAUTH-WG] Named token profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 05:38:36 -0000 --14dae9340cad6faf9a04c655f0bb Content-Type: text/plain; charset=ISO-8859-1 Hi OAuthers! Here is the idea that I have briefly touched on during today's session. It is very rough sketch, but is probably easier to understand than half a minute comment that I have done. http://nat.sakimura.org/2012/08/03/named-token/ Catch me at the Hyatt tomorrow if any of you are interested. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --14dae9340cad6faf9a04c655f0bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi OAuthers!

Here is the idea that I have briefly touche= d on during today's session.=A0
It is very rough sketch, but = is probably easier to understand than half a minute comment that I have don= e.=A0


<= /div>
Catch me at the Hyatt tomorrow if any of you are interested.=A0

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation=
http://nat.sakim= ura.org/
@_nat_en

--14dae9340cad6faf9a04c655f0bb-- From leleuj@gmail.com Fri Aug 3 00:07:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F711E80B8 for ; Fri, 3 Aug 2012 00:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpDcytYCynys for ; Fri, 3 Aug 2012 00:07:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23311E809A for ; Fri, 3 Aug 2012 00:07:18 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1518803lbb.31 for ; Fri, 03 Aug 2012 00:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DslcS685l/GVBw56MBz3uMs95mevi8TloFEhF98sCko=; b=se0r0l4sht9MU+lDu7B14/lfbn09ssjd6xSSehehbdQIV2aoDY42YrAkNqR5j/+JdS nKrldW01L09AQMABO6BRrZ0ajlFQGjZ0VRJxAMyOdD8RvNmfp4uI50Rdp+toOhT8pWEt Mhme7i61I4K5UO3ujS/2vhNiaTxRvI5CGUdwH7gJD+E5BHMcMDtohwQN8AR+MQHqQv9I qGhrHhe7YGQRYXuOim5wPsK0EY9fgZcVhA9kQsBScv2cWzP3rR8pq9T81JMNsXRtZyoZ Nb5uekp2SVYk/Wc4IWjkkDmWC6KuDI5dqIW9B6U/u6bLz8QOz43WfEW4V7qshVI8TpFi aHew== MIME-Version: 1.0 Received: by 10.152.104.146 with SMTP id ge18mr706420lab.7.1343977637337; Fri, 03 Aug 2012 00:07:17 -0700 (PDT) Received: by 10.112.106.166 with HTTP; Fri, 3 Aug 2012 00:07:17 -0700 (PDT) Date: Fri, 3 Aug 2012 09:07:17 +0200 Message-ID: From: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d04083e13a8d8c404c6572d4a Subject: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 07:07:20 -0000 --f46d04083e13a8d8c404c6572d4a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, In the OAuth 2.0 spec, I don't see any mention of the "Allow / disallow" screen (just after the user is logged in). However, most of the OAuth providers I know (Facebook, Google, Twitter...) have such a "allow / disallow" screen. Did I miss something in the spec ? What are the security concerns about not having such "Allow / disallow" screen ? Thanks. Best regards, J=E9r=F4me --f46d04083e13a8d8c404c6572d4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

In the OAuth 2.0 spec,=A0I don't see any mention= of the "Allow / disallow" screen (just after the user is logged = in). However, most of the OAuth providers I know (Facebook, Google, Twitter= ...) have such a "allow / disallow" screen.

Did I miss something in the spec ?

=
What are the security concerns about not having such "Allow / dis= allow" screen ?

Thanks.
Best regard= s,
J=E9r=F4me

--f46d04083e13a8d8c404c6572d4a-- From d.tangren@gmail.com Fri Aug 3 05:36:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F21421F8D85 for ; Fri, 3 Aug 2012 05:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fud4u96+7mA for ; Fri, 3 Aug 2012 05:36:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA92721F8D84 for ; Fri, 3 Aug 2012 05:36:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so715757vbb.31 for ; Fri, 03 Aug 2012 05:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xJFElTOIYxL3trfsCcg8IJBIIztlgwHLwgl6PCCmTFQ=; b=DPAJBvvnClVoeJloV1X/FyJgKxt7c81ZN3VijRTYmCXkkqLBEEpw7r4Guhs/sKjlRq o74gjyPUcu++oCAA1FwRPb6+0AmJF3Uf1GqW4ETIPoOAvl/IPuIAHH9MLZQbuv4EfaNy YOIviFblKmWH9DGlWewsIiMqIRQ5CKTOmO9lxEy6u0WM97lSFbLMlNXp2hN6uGkowVuz SmSk9JDFjQ5abbkXsJ2MHxe4RzcC0gI7d3jbqjfPK8j9+5Bio9CKBhZdjSVtC9Vh+nf+ jWPKVGn8xfcVPzf/Msk93szBTCODJPrQYERWhQu/wf7OQ5eWDY/glL5glnTI8MCTkd18 V50w== Received: by 10.58.4.232 with SMTP id n8mr1271948ven.54.1343997392064; Fri, 03 Aug 2012 05:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.7 with HTTP; Fri, 3 Aug 2012 05:36:11 -0700 (PDT) In-Reply-To: References: From: Doug Tangren Date: Fri, 3 Aug 2012 08:36:11 -0400 Message-ID: To: =?UTF-8?B?SsOpcsO0bWUgTEVMRVU=?= Content-Type: multipart/alternative; boundary=047d7b66fcad220f1604c65bc786 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 12:36:33 -0000 --047d7b66fcad220f1604c65bc786 Content-Type: text/plain; charset=UTF-8 > What are the security concerns about not having such "Allow / disallow" > screen ? > Obtaining access to a user's data without their consent? --047d7b66fcad220f1604c65bc786 Content-Type: text/html; charset=UTF-8
What are the security concerns about not having such "Allow / disallow" screen ?

Obtaining access to a user's data without their consent?
--047d7b66fcad220f1604c65bc786-- From leleuj@gmail.com Fri Aug 3 06:23:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8EA21F8DA0 for ; Fri, 3 Aug 2012 06:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJwgBdSJiZ0z for ; Fri, 3 Aug 2012 06:23:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B85621F8D96 for ; Fri, 3 Aug 2012 06:23:11 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1714594lbb.31 for ; Fri, 03 Aug 2012 06:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fedJjtBPmR3WInWwQDwiEHsTaFuaFjhv5r1A9t+Jc2A=; b=NoIcS9HFVGb3bfIPpw02fl0mmS4K+emw2jF+I6/Es1agQx1bglXndwN2H5mf6anRL8 SpSIe9rXucoovy1FxrQY4fk/9j6j6n52R/eGXYpKluntdAdffxOc3J6LMjjfhPWUROhD Iostxnoule4+RFWGh2blo2BakFPJQ1KnQnditf3KCkNmYjxgoLWM/kEfKHVajpiSe0gR GkR48zU3onDwNv+zPx70LYn7uVraa94muqCsElRJbaASn45nbmMBbvzkXwkbLlKPjsUh qxcDAtRk+1KaIax6xHjcSsos96GmfESOxdKK+nGRyVRr10tsYbKd77kvlTpSX9wgkoAX Q7MQ== MIME-Version: 1.0 Received: by 10.112.49.230 with SMTP id x6mr658766lbn.86.1344000190411; Fri, 03 Aug 2012 06:23:10 -0700 (PDT) Received: by 10.112.106.166 with HTTP; Fri, 3 Aug 2012 06:23:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 3 Aug 2012 15:23:10 +0200 Message-ID: From: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= To: Doug Tangren Content-Type: multipart/alternative; boundary=bcaec554deb2ed72af04c65c6dde Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:23:12 -0000 --bcaec554deb2ed72af04c65c6dde Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Said like that, I feel totally stupid... but it's not totally without their consent, they previously clicked on the "Authenticate at the OAuth provider" link... I understand that it's mandatory. Thanks, J=E9r=F4me 2012/8/3 Doug Tangren > > What are the security concerns about not having such "Allow / disallow" >> screen ? >> > > Obtaining access to a user's data without their consent? > --bcaec554deb2ed72af04c65c6dde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Said like that, I feel totally stupi= d... but it's not totally without their consent, they previously clicke= d on the "Authenticate at the OAuth provider" link...

I understand that it's = mandatory.

Thanks,
J=E9r=F4me



2012/8/3 Doug Tangren <d.tangre= n@gmail.com>

What are= the security concerns about not having such "Allow / disallow" s= creen ?

Obtaining access to a user's data with= out their consent?

--bcaec554deb2ed72af04c65c6dde-- From havardge@comoyo.com Fri Aug 3 06:42:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC7321F8D65 for ; Fri, 3 Aug 2012 06:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BVvHU6qebRz for ; Fri, 3 Aug 2012 06:42:52 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2621F8CB6 for ; Fri, 3 Aug 2012 06:42:52 -0700 (PDT) Received: by ggnc4 with SMTP id c4so945192ggn.31 for ; Fri, 03 Aug 2012 06:42:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=BqpsMA50JOvpZVrmKYlD1aXUAa8+CnD4kwcW58DTrrQ=; b=bsoGrO0HHIqw5s7uyPnuL0sDDJgHop2EPDGvtDkGbXYoY/bD9UvNB1SOjebtA3Y0JJ N6dr8pKgKZ9RWxypTXinQDdpQiI/ONNGY1n+O1W1L1suNnrKDePrDeYWbe2AOVOjx3nr iz8HKlcgeicGwZZw3A24UtpfeQLTIQW18e6phZX50OKrU/dioBCDapXJgaoIEGRBAi5W bA8X6Umr/yOT5vSaiVGEQ3MtV+tdthHtTEyCUwccQaJux/BafyYrLgLFUb/KNVAE8q7o t0kijHNLb4fQYkjQBmtpCKO6ZDaSMTZVKAcIfd0SRsp2AxbHo9tK+pJqgvZ50Y7F0Djr V1Zg== Received: by 10.50.189.134 with SMTP id gi6mr10746800igc.55.1344001371404; Fri, 03 Aug 2012 06:42:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.29.152 with HTTP; Fri, 3 Aug 2012 06:42:19 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?H=E5vard_Geithus?= Date: Fri, 3 Aug 2012 15:42:19 +0200 Message-ID: To: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= Content-Type: multipart/alternative; boundary=14dae9340a1b51fac804c65cb450 X-Gm-Message-State: ALoCoQmozNVh6kPlkTlgkxNUemlVAhKoNuR4Ub/LFMdc0dAt4nUtYelNMQ+2n1w4XKMguFAAw2WH Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:42:53 -0000 --14dae9340a1b51fac804c65cb450 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you look at Google's API, they have a parameter named approval_prompt which can be "force" or "auto": Description: *Indicates if the user should be re-prompted for consent. The default is auto, so a given user should only see the consent page for a given set of scopes the first time through the sequence. If the value is force, then the user sees a consent page even if they have previously given consent to your application for a given set of scopes.* * * I guess that's one way to solve it :) On Fri, Aug 3, 2012 at 3:23 PM, J=E9r=F4me LELEU wrote: > Said like that, I feel totally stupid... but it's not totally without > their consent, they previously clicked on the "Authenticate at the OAuth > provider" link... > > I understand that it's mandatory. > > Thanks, > J=E9r=F4me > > > > 2012/8/3 Doug Tangren > >> >> What are the security concerns about not having such "Allow / disallow" >>> screen ? >>> >> >> Obtaining access to a user's data without their consent? >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --14dae9340a1b51fac804c65cb450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you look at Google's API, they have a parameter named= =A0approval_prompt which can be "force" or "au= to":

Description:
Indicates if the user should be re= -prompted for consent. The default is auto, so a given user should only see= the consent page for a given set of scopes the first time through the sequ= ence. If the value is force, then the user sees a consent page even if they= have previously given consent to your application for a given set of scope= s.

I guess that's one way to solve it :)
On Fri, Aug 3, 2012 at 3:23 PM, J=E9r=F4me LELE= U <leleuj@gmail.com> wrote:
Said like that, I feel totally stupid..= . but it's not totally without their consent, they previously clicked o= n the "Authenticate at the OAuth provider" link...

I understand that it's mandatory.

Thanks,
J=E9r=F4me



2012/8/3 Doug Tangren <d.tangre= n@gmail.com>

What are= the security concerns about not having such "Allow / disallow" s= creen ?

Obtaining access to a user's data with= out their consent?


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--14dae9340a1b51fac804c65cb450-- From ve7jtb@ve7jtb.com Fri Aug 3 07:21:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D9521F8D02 for ; Fri, 3 Aug 2012 07:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvs21dnLsbmy for ; Fri, 3 Aug 2012 07:21:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3F421F8CD1 for ; Fri, 3 Aug 2012 07:21:15 -0700 (PDT) Received: by yhq56 with SMTP id 56so982801yhq.31 for ; Fri, 03 Aug 2012 07:21:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UTBAG6AfmDLhykOncqAe/AD/0SizdsG7+QW82GBvoc8=; b=gNAIcaOkCbhZH173+1KpCoiLgAyiSEzphik2yG+vSnzMCaxdOC0wWQUZdyQcJsgJ17 KcW4OpX83OUSkCB4NRuc77MemZYJyt3MqzLFx7Jqc3PI7fBTf+hmcpeUeWcMYKK9H3Bh RZH76H1COjnUzDRccMRUukqCH0aPutB0DFF1+eWDkrPPV9ka3BGKwZa8n8mr78c9CHRT cJVsdOfcGhd10CM+MRF2s10Ft86Ii1JRFL2mzaeUIsN99WUU8EhK7RpLy5oBPGelf4AL ZHvbrbu58boJA6ZYzPB1fzfF6FWtYPVpKT/sk+8xPsaH7Ghs7v9+bHIAFsDQs/i8BVSf yEHg== Received: by 10.50.222.200 with SMTP id qo8mr10902520igc.20.1344003674402; Fri, 03 Aug 2012 07:21:14 -0700 (PDT) Received: from [192.168.111.113] (S01060014bf06f566.vc.shawcable.net. [24.84.116.132]) by mx.google.com with ESMTPS id ai6sm21924788igc.0.2012.08.03.07.21.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 07:21:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF60E58F-B12D-49B5-A168-57038AA4A792" From: John Bradley In-Reply-To: Date: Fri, 3 Aug 2012 07:21:08 -0700 Message-Id: <132870FF-D49B-43C7-AD7D-8F65BE93E5BB@ve7jtb.com> References: To: =?iso-8859-1?Q?J=E9r=F4me_LELEU?= X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQmZeMmY93VcBaPeXo8dRi/SioZM60cquzR+sZHvFSDv0FLMoSNVItJaMXyKkh4U79twmE/y Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:21:16 -0000 --Apple-Mail=_CF60E58F-B12D-49B5-A168-57038AA4A792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 In OAuth 2 the A is Authorization, not Authentication. Not all flows support user interaction, so it can't be a MUST present = dialog, as that may not be possible. For flows such as code and implicit the Authorization server should = present the user with a choice of allowing the requested scopes. Depending on the protected resource and client the Authorization server = may not present each scope individually, it would depend on the API = being protected. Your question seems to presume some sort of federated login like = Facebook Connect, or openID Connect. The specifics of using OAuth for = federated login are out of scope for the core OAuth spec. In those cases you need to inform the user and involve extensions to = OAuth for security and dealing with login sessions. You can look at openID Connect or Googles documentation on using OAuth = for SSO to get more information on that use-case. On 2012-08-03, at 6:23 AM, J=E9r=F4me LELEU wrote: > Said like that, I feel totally stupid... but it's not totally without = their consent, they previously clicked on the "Authenticate at the OAuth = provider" link... >=20 > I understand that it's mandatory. >=20 > Thanks, > J=E9r=F4me >=20 >=20 >=20 > 2012/8/3 Doug Tangren >=20 > What are the security concerns about not having such "Allow / = disallow" screen ? >=20 > Obtaining access to a user's data without their consent? >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_CF60E58F-B12D-49B5-A168-57038AA4A792 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 In = OAuth 2 the  A is Authorization, not = Authentication.

Not all flows support user = interaction, so it can't be a MUST present dialog, as that may not be = possible.

For flows such as code and implicit = the Authorization server should present the user with a choice of = allowing the requested scopes.

Depending on the = protected resource and client the Authorization server may not present = each scope individually, it would depend on the API being = protected.

Your question seems to presume some = sort of federated login like Facebook Connect, or openID Connect.   = The specifics of using OAuth for federated login are out of scope for = the core OAuth spec.

In those cases you need to = inform the user and involve extensions to OAuth for security and dealing = with login sessions.

You can look at openID Connect or Googles = documentation on using OAuth for SSO to get more information on that = use-case.


On 2012-08-03, at 6:23 = AM, J=E9r=F4me LELEU wrote:

Said like that, I feel totally = stupid... but it's not totally without their consent, they previously = clicked on the "Authenticate at the OAuth provider" link...

I understand that it's = mandatory.

Thanks,
J=E9r=F4me



2012/8/3 Doug Tangren <d.tangren@gmail.com>

What are the security concerns about not = having such "Allow / disallow" screen ?

Obtaining access to a user's data = without their consent?

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_CF60E58F-B12D-49B5-A168-57038AA4A792-- From jricher@mitre.org Fri Aug 3 07:48:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAF021F8DD9 for ; Fri, 3 Aug 2012 07:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c3wAb0KjIl0 for ; Fri, 3 Aug 2012 07:48:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8421F8DD8 for ; Fri, 3 Aug 2012 07:48:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB50721B1AF7 for ; Fri, 3 Aug 2012 10:48:52 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DFAB121B0886 for ; Fri, 3 Aug 2012 10:48:52 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 3 Aug 2012 10:48:52 -0400 Message-ID: <501BE48F.8050703@mitre.org> Date: Fri, 3 Aug 2012 10:47:43 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000405090805010105010401" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:48:54 -0000 --------------000405090805010105010401 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit The approval screen is a detail of the UX that the protocol itself doesn't address, since there are several instances where an approval screen does and does not make sense. If you're doing a "trust on first use" (TOFU) scenario where the resource owner is the same as the end user (remember, they may be different entities entirely!), then the approval screen is very important. This is the classical OAuth use case, and one of the primary novel things that it allows for which other protocols don't. Since most of the publicly-facing deployments of OAuth are in this kind of world, where you're using the end user to bridge trusted security boundaries via OAuth, then you see a lot of this. If your end user and resource owner are different entities, then the person sitting at the browser might not actually have a choice about whether to allow access. In this case, it doesn't make any sense to ask them because the decision is being made by policy, or by circumstances around the request. It does still make sense to do a three-legged OAuth in this flow, because you can then bind the context of the user having authenticated to the AS in the front channel with the client having authenticated to the AS in the back channel. This separating and re-binding gives you three legs in an authorization triangle, which is a very powerful and secure pattern to follow. We're starting to see things like this in the enterprise world around OAuth. Instead of using an all-powerful tight binding credential between systems, you've got a whitelisted OAuth client. As far as the client knows, it's doing vanilla OAuth and the world is all as it should be. This is a very good (and somewhat novel) thing for enterprise systems. But even in the TOFU scenario, it's important to let the user say "remember this decision in the future and don't bug me about it". In this case, the server remembers the authorization grant decision that was previously made by the resource owner and doesn't prompt the user. Most OpenID 2.0 setups do this already, and some OAuth setups do as well. I think Google does this, I know we're building it in to our projects, and I think we'll see more of this functionality going forward. -- Justin On 08/03/2012 03:07 AM, Jérôme LELEU wrote: > Hi, > > In the OAuth 2.0 spec, I don't see any mention of the "Allow / > disallow" screen (just after the user is logged in). However, most of > the OAuth providers I know (Facebook, Google, Twitter...) have such a > "allow / disallow" screen. > > Did I miss something in the spec ? > > What are the security concerns about not having such "Allow / > disallow" screen ? > > Thanks. > Best regards, > Jérôme > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000405090805010105010401 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
The approval screen is a detail of the UX that the protocol itself doesn't address, since there are several instances where an approval screen does and does not make sense.

If you're doing a "trust on first use" (TOFU) scenario where the resource owner is the same as the end user (remember, they may be different entities entirely!), then the approval screen is very important. This is the classical OAuth use case, and one of the primary novel things that it allows for which other protocols don't. Since most of the publicly-facing deployments of OAuth are in this kind of world, where you're using the end user to bridge trusted security boundaries via OAuth, then you see a lot of this.

If your end user and resource owner are different entities, then the person sitting at the browser might not actually have a choice about whether to allow access. In this case, it doesn't make any sense to ask them because the decision is being made by policy, or by circumstances around the request. It does still make sense to do a three-legged OAuth in this flow, because you can then bind the context of the user having authenticated to the AS in the front channel with the client having authenticated to the AS in the back channel. This separating and re-binding gives you three legs in an authorization triangle, which is a very powerful and secure pattern to follow. We're starting to see things like this in the enterprise world around OAuth. Instead of using an all-powerful tight binding credential between systems, you've got a whitelisted OAuth client. As far as the client knows, it's doing vanilla OAuth and the world is all as it should be. This is a very good (and somewhat novel) thing for enterprise systems.

But even in the TOFU scenario, it's important to let the user say "remember this decision in the future and don't bug me about it". In this case, the server remembers the authorization grant decision that was previously made by the resource owner and doesn't prompt the user. Most OpenID 2.0 setups do this already, and some OAuth setups do as well. I think Google does this, I know we're building it in to our projects, and I think we'll see more of this functionality going forward.

  -- Justin

On 08/03/2012 03:07 AM, Jérôme LELEU wrote:
Hi,

In the OAuth 2.0 spec, I don't see any mention of the "Allow / disallow" screen (just after the user is logged in). However, most of the OAuth providers I know (Facebook, Google, Twitter...) have such a "allow / disallow" screen.

Did I miss something in the spec ?

What are the security concerns about not having such "Allow / disallow" screen ?

Thanks.
Best regards,
Jérôme



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------000405090805010105010401-- From hannes.tschofenig@gmx.net Fri Aug 3 12:19:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1383421F8D7B for ; Fri, 3 Aug 2012 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-AsF8XAQyfm for ; Fri, 3 Aug 2012 12:19:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EE9A621F8D86 for ; Fri, 3 Aug 2012 12:19:13 -0700 (PDT) Received: (qmail invoked by alias); 03 Aug 2012 19:19:11 -0000 Received: from dhcp-172b.meeting.ietf.org (EHLO dhcp-172b.meeting.ietf.org) [130.129.23.43] by mail.gmx.net (mp040) with SMTP; 03 Aug 2012 21:19:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19vpLMlGkFvIAuNTHV7L8Fm3c5Wzlqs/8WUtmWomD m3GkBRZ/ZYdvaG Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Fri, 3 Aug 2012 12:19:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <57B9F7EE-3909-4C8A-88DC-3EE056B4ECE7@gmx.net> References: To: =?iso-8859-1?Q?J=E9r=F4me_LELEU?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:19:15 -0000 Hi Jerome,=20 you raise a good and important point.=20 A core part of the OAuth specification is to obtain the consent of the = resource owner. If you look at Section 1.3 of = http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the different = authorization grants that are supported. Except for the client = credential authorization grant every other grant type requires a = protocol exchange to obtain the permission from the resource owner. The threats document discusses the importance of the consent mechanism = in more detail.=20 However, the actual screen (and the importance of the UI representation) = is not standardized. Most standardization organizations do not = standardize the look-and-feel of the actual permission screen. Having = said that I believe it is a very important aspect of every identity = management protocol and there is research available. Maybe someone = should put a page with a few links together to illustrate the current = state of the art and the best current practice.=20 Ciao Hannes On Aug 3, 2012, at 12:07 AM, J=E9r=F4me LELEU wrote: > Hi, >=20 > In the OAuth 2.0 spec, I don't see any mention of the "Allow / = disallow" screen (just after the user is logged in). However, most of = the OAuth providers I know (Facebook, Google, Twitter...) have such a = "allow / disallow" screen. >=20 > Did I miss something in the spec ? >=20 > What are the security concerns about not having such "Allow / = disallow" screen ? >=20 > Thanks. > Best regards, > J=E9r=F4me >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From d.tangren@gmail.com Fri Aug 3 12:23:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABE921F8D36 for ; Fri, 3 Aug 2012 12:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMPQANhbWctu for ; Fri, 3 Aug 2012 12:23:23 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA7EF21F8CCD for ; Fri, 3 Aug 2012 12:23:22 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1174322vcb.31 for ; Fri, 03 Aug 2012 12:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Uuzb9Uu7AYF6y0jjV/takWtp9Xsie3pv29jm74dUfvw=; b=jZW0lfMbWD80qonaHvVn48iQD5zQ0q7dqpNcgvjWG9ICJkxoO3rhFFKZaJoTlKtNd1 EX1TRbdQD67SOq2/Rk7mP7eBUmLLGLTK7SxHDNqs6y2UO1KgvTpKS1ozgYY1DlOTxYpm ds2iWTxmpzg9Vsn1Xee5dHgz9hrdc0s30aozhuEwAIFkBR6SzbzdpykQ63TWLbJdQW2T B4ezjazAkcf1NjQ0TD0knuMunIB16jmYOAWCLrpJpl0LpJsjWT4hgDLOj3MG/sXNyp0q jXYTReNBHQ7HIzw1zdDup6CeDQyzkaLZeLZux8aCfdxv1OhtDhkwyQDYUHf6TCLgdxcC lelw== Received: by 10.58.102.83 with SMTP id fm19mr2533347veb.24.1344021802166; Fri, 03 Aug 2012 12:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.7 with HTTP; Fri, 3 Aug 2012 12:23:02 -0700 (PDT) In-Reply-To: <57B9F7EE-3909-4C8A-88DC-3EE056B4ECE7@gmx.net> References: <57B9F7EE-3909-4C8A-88DC-3EE056B4ECE7@gmx.net> From: Doug Tangren Date: Fri, 3 Aug 2012 15:23:02 -0400 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b5da31316a83c04c6617681 Cc: oauth@ietf.org, =?UTF-8?B?SsOpcsO0bWUgTEVMRVU=?= Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 19:23:24 -0000 --047d7b5da31316a83c04c6617681 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig wrote: > Hi Jerome, > > you raise a good and important point. > > A core part of the OAuth specification is to obtain the consent of the > resource owner. If you look at Section 1.3 of > http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the different > authorization grants that are supported. Except for the client credential > authorization grant every other grant type requires a protocol exchange t= o > obtain the permission from the resource owner. > > The threats document discusses the importance of the consent mechanism in > more detail. > > However, the actual screen (and the importance of the UI representation) > is not standardized. Most standardization organizations do not standardiz= e > the look-and-feel of the actual permission screen. Having said that I > believe it is a very important aspect of every identity management protoc= ol > and there is research available. Maybe someone should put a page with a f= ew > links together to illustrate the current state of the art and the best > current practice. > > This is not an oauth issue but an application UX issue dating back to oauth 1. Many service providers offer an "authorize" endpoint that always asks for authorization (safer for the user but less convenient) and "authenticate" endpoint that skips authorization if the user previously authorized the app (more convenient but less safe). > Ciao > Hannes > > On Aug 3, 2012, at 12:07 AM, J=C3=A9r=C3=B4me LELEU wrote: > > > Hi, > > > > In the OAuth 2.0 spec, I don't see any mention of the "Allow / disallow= " > screen (just after the user is logged in). However, most of the OAuth > providers I know (Facebook, Google, Twitter...) have such a "allow / > disallow" screen. > > > > Did I miss something in the spec ? > > > > What are the security concerns about not having such "Allow / disallow" > screen ? > > > > Thanks. > > Best regards, > > J=C3=A9r=C3=B4me > > > > _______________________________________________ > > 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 > --047d7b5da31316a83c04c6617681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 3, 2012 at 3:19 PM, Hannes T= schofenig <hannes.tschofenig@gmx.net> wrote:
Hi Jerome,

you raise a good and important point.

A core part of the OAuth specification is to obtain the consent of the reso= urce owner. If you look at Section 1.3 of http://tools.ietf.org/html/d= raft-ietf-oauth-v2-31 you see the different authorization grants that a= re supported. Except for the client credential authorization grant every ot= her grant type requires a protocol exchange to obtain the permission from t= he resource owner.

The threats document discusses the importance of the consent mechanism in m= ore detail.

However, the actual screen (and the importance of the UI representation) is= not standardized. Most standardization organizations do not standardize th= e look-and-feel of the actual permission screen. Having said that I believe= it is a very important aspect of every identity management protocol and th= ere is research available. Maybe someone should put a page with a few links= together to illustrate the current state of the art and the best current p= ractice.


This is not an oauth issue but an appl= ication UX issue dating back to oauth 1.=C2=A0

Man= y service providers offer an "authorize" endpoint that always ask= s for authorization (safer for the user but less convenient) and "auth= enticate" endpoint that skips authorization if the user previously aut= horized the app (more convenient but less safe).



=C2=A0
Ciao
Hannes

On Aug 3, 2012, at 12:07 AM, J=C3=A9r=C3=B4me LELEU wrote:

> Hi,
>
> In the OAuth 2.0 spec, I don't see any mention of the "Allow = / disallow" screen (just after the user is logged in). However, most o= f the OAuth providers I know (Facebook, Google, Twitter...) have such a &qu= ot;allow / disallow" screen.
>
> Did I miss something in the spec ?
>
> What are the security concerns about not having such "Allow / dis= allow" screen ?
>
> Thanks.
> Best regards,
> J=C3=A9r=C3=B4me
>
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--047d7b5da31316a83c04c6617681-- From leleuj@gmail.com Sun Aug 5 23:55:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6A921F846B for ; Sun, 5 Aug 2012 23:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE7EOodpS9o6 for ; Sun, 5 Aug 2012 23:55:37 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA85421F8467 for ; Sun, 5 Aug 2012 23:55:36 -0700 (PDT) Received: by lahm15 with SMTP id m15so1429225lah.31 for ; Sun, 05 Aug 2012 23:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uAtYvSwgf5oPY8FEJUQa+eG+O+VVI/1o14HiMvaWzvg=; b=zNHVjC5gcDcr1JAMI9PCQWtlQH9AdjnVQvgy5wtWn0vLi7iMLa5RW1onGxNYXfw9m3 CH3bw/2G6qXh0vDz6qKgHBCs7JlbtE6rAvwmNdzwadU+IzSxs5rJs17EDhosgvCAvL1r 1r6PeSK4nYq/a8KCLxbkO8RJprEUog82c7YwDVTLT+NYewprF7xCoDu3/SnAAxtAYevL TKj6bEt8/CODi0HdAc9kVYC2ybLTfuXr74+Xal0elrn1PtiCGN2Hz7ALEy4sigsSUAi8 RLri3k5MO0ajm4ipDF58jfLGzqNvzmFA2zD55MkDIT6QNuY0MdlTlLm9sebwwM31plA7 OVPw== MIME-Version: 1.0 Received: by 10.112.99.71 with SMTP id eo7mr4267611lbb.84.1344236135542; Sun, 05 Aug 2012 23:55:35 -0700 (PDT) Received: by 10.112.32.161 with HTTP; Sun, 5 Aug 2012 23:55:35 -0700 (PDT) In-Reply-To: References: <57B9F7EE-3909-4C8A-88DC-3EE056B4ECE7@gmx.net> Date: Mon, 6 Aug 2012 08:55:35 +0200 Message-ID: From: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= To: Doug Tangren Content-Type: multipart/alternative; boundary=f46d04016a235a6f6204c6935d28 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 06:55:38 -0000 --f46d04016a235a6f6204c6935d28 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Thank you all for your answers. I read section 1.3.1 : "the authorization server authenticates the resource owner and obtains authorization", the "obtains authorization" implies the confirmation screen I talked about. But it's not only about UI. There are some behaviour issues remaining : is there a "disallow" button ? where does it point at ? when should this screen appear (every time, just the first time and why) ? This confirmation screen deserves more explanations. Thanks. Best regards, J=E9r=F4me 2012/8/3 Doug Tangren > > > On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi Jerome, >> >> you raise a good and important point. >> >> A core part of the OAuth specification is to obtain the consent of the >> resource owner. If you look at Section 1.3 of >> http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the different >> authorization grants that are supported. Except for the client credentia= l >> authorization grant every other grant type requires a protocol exchange = to >> obtain the permission from the resource owner. >> >> The threats document discusses the importance of the consent mechanism i= n >> more detail. >> >> However, the actual screen (and the importance of the UI representation) >> is not standardized. Most standardization organizations do not standardi= ze >> the look-and-feel of the actual permission screen. Having said that I >> believe it is a very important aspect of every identity management proto= col >> and there is research available. Maybe someone should put a page with a = few >> links together to illustrate the current state of the art and the best >> current practice. >> >> > This is not an oauth issue but an application UX issue dating back to > oauth 1. > > Many service providers offer an "authorize" endpoint that always asks for > authorization (safer for the user but less convenient) and "authenticate" > endpoint that skips authorization if the user previously authorized the a= pp > (more convenient but less safe). > > > > > >> Ciao >> Hannes >> >> On Aug 3, 2012, at 12:07 AM, J=E9r=F4me LELEU wrote: >> >> > Hi, >> > >> > In the OAuth 2.0 spec, I don't see any mention of the "Allow / >> disallow" screen (just after the user is logged in). However, most of th= e >> OAuth providers I know (Facebook, Google, Twitter...) have such a "allow= / >> disallow" screen. >> > >> > Did I miss something in the spec ? >> > >> > What are the security concerns about not having such "Allow / disallow= " >> screen ? >> > >> > Thanks. >> > Best regards, >> > J=E9r=F4me >> > >> > _______________________________________________ >> > 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 >> > > --f46d04016a235a6f6204c6935d28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thank you all for your answers.

=
I read section 1.3.1 : "the authorization server authenticates th= e resource owner and obtains authorization", the "obtains authori= zation" implies the confirmation screen I talked about.
But it's not only about UI. There are some behaviour issues remain= ing : is there a "disallow" button ? where does it point at ? whe= n should this screen appear (every time, just the first time and why) ?
This confirmation screen deserves more explanations.

Thanks.
Best regards,
J=E9r=F4me

=


2012/8/3 Doug Tangren <d.t= angren@gmail.com>


On Fri, A= ug 3, 2012 at 3:19 PM, Hannes Tschofenig <hannes.tschofenig@gmx.ne= t> wrote:
Hi Jerome,

you raise a good and important point.

A core part of the OAuth specification is to obtain the consent of the reso= urce owner. If you look at Section 1.3 of http://tools.ietf.org/html/d= raft-ietf-oauth-v2-31 you see the different authorization grants that a= re supported. Except for the client credential authorization grant every ot= her grant type requires a protocol exchange to obtain the permission from t= he resource owner.

The threats document discusses the importance of the consent mechanism in m= ore detail.

However, the actual screen (and the importance of the UI representation) is= not standardized. Most standardization organizations do not standardize th= e look-and-feel of the actual permission screen. Having said that I believe= it is a very important aspect of every identity management protocol and th= ere is research available. Maybe someone should put a page with a few links= together to illustrate the current state of the art and the best current p= ractice.


This is not an oauth issue but an appl= ication UX issue dating back to oauth 1.=A0

Many s= ervice providers offer an "authorize" endpoint that always asks f= or authorization (safer for the user but less convenient) and "authent= icate" endpoint that skips authorization if the user previously author= ized the app (more convenient but less safe).



=A0
Ciao
Hannes

On Aug 3, 2012, at 12:07 AM, J=E9r=F4me LELEU wrote:

> Hi,
>
> In the OAuth 2.0 spec, I don't see any mention of the "Allow = / disallow" screen (just after the user is logged in). However, most o= f the OAuth providers I know (Facebook, Google, Twitter...) have such a &qu= ot;allow / disallow" screen.
>
> Did I miss something in the spec ?
>
> What are the security concerns about not having such "Allow / dis= allow" screen ?
>
> Thanks.
> Best regards,
> J=E9r=F4me
>
> _______________________________________________<= br> > OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--f46d04016a235a6f6204c6935d28-- From jricher@mitre.org Mon Aug 6 08:07:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566D821F865E for ; Mon, 6 Aug 2012 08:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPF+4ezoxwP5 for ; Mon, 6 Aug 2012 08:07:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 215A821F84E4 for ; Mon, 6 Aug 2012 08:07:32 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6222B21B0CED for ; Mon, 6 Aug 2012 11:07:31 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 470BA21B0A31 for ; Mon, 6 Aug 2012 11:07:31 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 6 Aug 2012 11:07:31 -0400 Message-ID: <501FDD6A.2050702@mitre.org> Date: Mon, 6 Aug 2012 11:06:18 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: <57B9F7EE-3909-4C8A-88DC-3EE056B4ECE7@gmx.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070308090608050405040307" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 15:07:33 -0000 --------------070308090608050405040307 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit I agree with the idea that we need to collect and document some best practices around the UX of authorization, especially in the case where it's the end user making the determination. There have been a few chirps about this in the past, but I haven't seen anyone really stand something up. The OpenID Foundation has its UI working group which is probably good place to start. -- Justin On 08/06/2012 02:55 AM, Jérôme LELEU wrote: > Hi, > > Thank you all for your answers. > > I read section 1.3.1 : "the authorization server authenticates the > resource owner and obtains authorization", the "obtains authorization" > implies the confirmation screen I talked about. > But it's not only about UI. There are some behaviour issues remaining > : is there a "disallow" button ? where does it point at ? when should > this screen appear (every time, just the first time and why) ? > This confirmation screen deserves more explanations. > > Thanks. > Best regards, > Jérôme > > > > 2012/8/3 Doug Tangren > > > > > On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig > > wrote: > > Hi Jerome, > > you raise a good and important point. > > A core part of the OAuth specification is to obtain the > consent of the resource owner. If you look at Section 1.3 of > http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the > different authorization grants that are supported. Except for > the client credential authorization grant every other grant > type requires a protocol exchange to obtain the permission > from the resource owner. > > The threats document discusses the importance of the consent > mechanism in more detail. > > However, the actual screen (and the importance of the UI > representation) is not standardized. Most standardization > organizations do not standardize the look-and-feel of the > actual permission screen. Having said that I believe it is a > very important aspect of every identity management protocol > and there is research available. Maybe someone should put a > page with a few links together to illustrate the current state > of the art and the best current practice. > > > This is not an oauth issue but an application UX issue dating back > to oauth 1. > > Many service providers offer an "authorize" endpoint that always > asks for authorization (safer for the user but less convenient) > and "authenticate" endpoint that skips authorization if the user > previously authorized the app (more convenient but less safe). > > > > Ciao > Hannes > > On Aug 3, 2012, at 12:07 AM, Jérôme LELEU wrote: > > > Hi, > > > > In the OAuth 2.0 spec, I don't see any mention of the "Allow > / disallow" screen (just after the user is logged in). > However, most of the OAuth providers I know (Facebook, Google, > Twitter...) have such a "allow / disallow" screen. > > > > Did I miss something in the spec ? > > > > What are the security concerns about not having such "Allow > / disallow" screen ? > > > > 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 > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070308090608050405040307 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
I agree with the idea that we need to collect and document some best practices around the UX of authorization, especially in the case where it's the end user making the determination. There have been a few chirps about this in the past, but I haven't seen anyone really stand something up. The OpenID Foundation has its UI working group which is probably good place to start.

 -- Justin

On 08/06/2012 02:55 AM, Jérôme LELEU wrote:
Hi,

Thank you all for your answers.

I read section 1.3.1 : "the authorization server authenticates the resource owner and obtains authorization", the "obtains authorization" implies the confirmation screen I talked about.
But it's not only about UI. There are some behaviour issues remaining : is there a "disallow" button ? where does it point at ? when should this screen appear (every time, just the first time and why) ?
This confirmation screen deserves more explanations.

Thanks.
Best regards,
Jérôme



2012/8/3 Doug Tangren <d.tangren@gmail.com>


On Fri, Aug 3, 2012 at 3:19 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Jerome,

you raise a good and important point.

A core part of the OAuth specification is to obtain the consent of the resource owner. If you look at Section 1.3 of http://tools.ietf.org/html/draft-ietf-oauth-v2-31 you see the different authorization grants that are supported. Except for the client credential authorization grant every other grant type requires a protocol exchange to obtain the permission from the resource owner.

The threats document discusses the importance of the consent mechanism in more detail.

However, the actual screen (and the importance of the UI representation) is not standardized. Most standardization organizations do not standardize the look-and-feel of the actual permission screen. Having said that I believe it is a very important aspect of every identity management protocol and there is research available. Maybe someone should put a page with a few links together to illustrate the current state of the art and the best current practice.


This is not an oauth issue but an application UX issue dating back to oauth 1. 

Many service providers offer an "authorize" endpoint that always asks for authorization (safer for the user but less convenient) and "authenticate" endpoint that skips authorization if the user previously authorized the app (more convenient but less safe).



 
Ciao
Hannes

On Aug 3, 2012, at 12:07 AM, Jérôme LELEU wrote:

> Hi,
>
> In the OAuth 2.0 spec, I don't see any mention of the "Allow / disallow" screen (just after the user is logged in). However, most of the OAuth providers I know (Facebook, Google, Twitter...) have such a "allow / disallow" screen.
>
> Did I miss something in the spec ?
>
> What are the security concerns about not having such "Allow / disallow" screen ?
>
> 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




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------070308090608050405040307-- From Hannes.Tschofenig@gmx.net Tue Aug 7 02:03:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA3921F85A0 for ; Tue, 7 Aug 2012 02:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o74hrfFjoykv for ; Tue, 7 Aug 2012 02:03:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E4E3B21F858A for ; Tue, 7 Aug 2012 02:03:18 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2012 09:03:17 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 07 Aug 2012 11:03:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183p5wBeJc3S6AHk7YENzDbEAUq3Hp7c2Oocc6ldJ klBBTsRFvQlD3w From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Aug 2012 12:03:16 +0300 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Meeting Minutes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 09:03:20 -0000 I have uploaded the meeting minutes: http://www.ietf.org/proceedings/84/minutes/minutes-84-oauth Have a look at them and let me know if there is something missing or = incorrect. Thanks to Melinda for taking notes.=20 From paul.madsen@gmail.com Tue Aug 7 06:07:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B1F21F8697 for ; Tue, 7 Aug 2012 06:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Beycvrputilu for ; Tue, 7 Aug 2012 06:07:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC2321F8690 for ; Tue, 7 Aug 2012 06:07:06 -0700 (PDT) Received: by yhq56 with SMTP id 56so3985798yhq.31 for ; Tue, 07 Aug 2012 06:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ZWTsKCbBzx9Kwm7jdtBULBoSMVfCv1Bip78gM7TGNM8=; b=ndZ+nEAIH0xCIdGBtuoRhZc/vqyf66im9dFWRFZkIdcgJYOBTpo1p6j4mDvAa7Ne5F LTgagi4zwcwCD49KNBKKcyEYFwQ/Yq0DM0EYWg5XN/+rtJSILlgf8/pn0tS9do4BMYP9 s+IFct9jPdjcvehKEpVpFbnaQmExfF3Lvf1s40nQoxxYOveh4GJ0b1gAiz9whLWG7Vtw dYocLHK/UGenfWEUX/9VWJN12Azl/J6ERfJ/Js2Eq//VYlUhFXud24fWvGFa/UyS1AjS UEPSp20RABrMMw/f28R/2z7zsTUaBejoomTRleGMRO5VlWSESyb77aPFSOxJPtJ99++m nWuQ== Received: by 10.50.171.40 with SMTP id ar8mr8559297igc.14.1344344825730; Tue, 07 Aug 2012 06:07:05 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id k5sm9173270igq.12.2012.08.07.06.07.04 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 06:07:04 -0700 (PDT) Message-ID: <502112F8.9040303@gmail.com> Date: Tue, 07 Aug 2012 09:07:04 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=E9r=F4me_LELEU?= References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020409020208070801020404" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:07:07 -0000 This is a multi-part message in MIME format. --------------020409020208070801020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit there are legitimate (non consumer centric) applications of OAuth where such explicit consent gathering is not necessary On 8/3/12 9:23 AM, Jérôme LELEU wrote: > Said like that, I feel totally stupid... but it's not totally without > their consent, they previously clicked on the "Authenticate at the > OAuth provider" link... > > I understand that it's mandatory. > > Thanks, > Jérôme > > > > 2012/8/3 Doug Tangren > > > > What are the security concerns about not having such "Allow / > disallow" screen ? > > > Obtaining access to a user's data without their consent? > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020409020208070801020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit there are legitimate (non consumer centric) applications of OAuth where such explicit consent gathering is not necessary

On 8/3/12 9:23 AM, Jérôme LELEU wrote:
Said like that, I feel totally stupid... but it's not totally without their consent, they previously clicked on the "Authenticate at the OAuth provider" link...

I understand that it's mandatory.

Thanks,
Jérôme



2012/8/3 Doug Tangren <d.tangren@gmail.com>

What are the security concerns about not having such "Allow / disallow" screen ?

Obtaining access to a user's data without their consent?


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------020409020208070801020404-- From Adam.Lewis@motorolasolutions.com Tue Aug 7 06:21:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEEA21F8678 for ; Tue, 7 Aug 2012 06:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXdXSUrkiogf for ; Tue, 7 Aug 2012 06:21:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5884021F8607 for ; Tue, 7 Aug 2012 06:21:10 -0700 (PDT) Received: from mail5-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 13:21:09 +0000 Received: from mail5-co1 (localhost [127.0.0.1]) by mail5-co1-R.bigfish.com (Postfix) with ESMTP id 87959DC0324 for ; Tue, 7 Aug 2012 13:21:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371Ic89bhc85dh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail5-co1: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT001.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail5-co1 (localhost.localdomain [127.0.0.1]) by mail5-co1 (MessageSwitch) id 1344345667552972_2574; Tue, 7 Aug 2012 13:21:07 +0000 (UTC) Received: from CO1EHSMHS020.bigfish.com (unknown [10.243.78.233]) by mail5-co1.bigfish.com (Postfix) with ESMTP id 7B0A214004B for ; Tue, 7 Aug 2012 13:21:07 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by CO1EHSMHS020.bigfish.com (10.243.66.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 13:21:06 +0000 Received: from il06msg01.mot-solutions.com (il06vts01.mot.com [129.188.137.141]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q77E9TS7003818 for ; Tue, 7 Aug 2012 09:09:29 -0500 (CDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q77E9T9W003813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Aug 2012 09:09:29 -0500 (CDT) Received: from mail263-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 13:21:04 +0000 Received: from mail263-va3 (localhost [127.0.0.1]) by mail263-va3-R.bigfish.com (Postfix) with ESMTP id 96A2A3C02F8 for ; Tue, 7 Aug 2012 13:21:04 +0000 (UTC) Received: from mail263-va3 (localhost.localdomain [127.0.0.1]) by mail263-va3 (MessageSwitch) id 1344345662764234_28258; Tue, 7 Aug 2012 13:21:02 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.238]) by mail263-va3.bigfish.com (Postfix) with ESMTP id B687A640043; Tue, 7 Aug 2012 13:21:02 +0000 (UTC) Received: from BY2PRD0411HT001.namprd04.prod.outlook.com (157.56.237.133) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 13:21:02 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.11.62]) by BY2PRD0411HT001.namprd04.prod.outlook.com ([10.255.128.36]) with mapi id 14.16.0175.005; Tue, 7 Aug 2012 13:21:00 +0000 From: Lewis Adam-CAL022 To: Paul Madsen , =?iso-8859-1?Q?J=E9r=F4me_LELEU?= Thread-Topic: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? Thread-Index: AQHNdJ2eTl6G9XNZU0KeURQkKlYcnpdOVLGA Date: Tue, 7 Aug 2012 13:21:00 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A923F04C0C@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <502112F8.9040303@gmail.com> In-Reply-To: <502112F8.9040303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.7.144] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A923F04C0CBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:21:12 -0000 --_000_59E470B10C4630419ED717AC79FCF9A923F04C0CBY2PRD0411MB441_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi J=E9r=F4me, I am one of those non-consumer use cases where explicit consent is not part= of our envisioned OAuth flow. The resource servers that we create and sel= l to our customers are owned by the customer's IT department, so when a use= r (employee) authenticates to the AS, it is the enterprise policy rules tha= t determine whether or not the user is authorized to obtain an access-token= or not. The confusion is that in classic OAuth the end-user and resource = owner are often the same, but in other cases (including mine) this is not t= he case. Hope that helps. -adam From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Madsen Sent: Tuesday, August 07, 2012 8:07 AM To: J=E9r=F4me LELEU Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen mandatory ? there are legitimate (non consumer centric) applications of OAuth where suc= h explicit consent gathering is not necessary On 8/3/12 9:23 AM, J=E9r=F4me LELEU wrote: Said like that, I feel totally stupid... but it's not totally without their= consent, they previously clicked on the "Authenticate at the OAuth provide= r" link... I understand that it's mandatory. Thanks, J=E9r=F4me 2012/8/3 Doug Tangren > What are the security concerns about not having such "Allow / disallow" scr= een ? Obtaining access to a user's data without their consent? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A923F04C0CBY2PRD0411MB441_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi J=E9r=F4me,

 =

I am one of those= non-consumer use cases where explicit consent is not part of our envisione= d OAuth flow.  The resource servers that we create and sell to our customers are owned by the customer’s IT department, so when = a user (employee) authenticates to the AS, it is the enterprise policy rule= s that determine whether or not the user is authorized to obtain an access-= token or not.  The confusion is that in classic OAuth the end-user and resource owner are often the same, but in o= ther cases (including mine) this is not the case.  Hope that helps.

 =

-adam<= /span>

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Paul Madsen
Sent: Tuesday, August 07, 2012 8:07 AM
To: J=E9r=F4me LELEU
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Is "Allow / disallow" screen manda= tory ?

 

there are legitimate (non consumer centric) applications o= f OAuth where such explicit consent gathering is not necessary

On 8/3/12 9:23 AM, J=E9r=F4me LELEU wrote:

Said like that, I feel tota= lly stupid... but it's not totally without their consent, they previously c= licked on the "Authenticate at the OAuth provider" link...

=  

= I understand that it's mandatory.

=  

= Thanks,

= J=E9r=F4me

=  

=  

 

2012/8/3 Doug Tangren <d.tangren@gmail.com>

 

What are the security concerns about not having such= "Allow / disallow" screen ?

 

Obtaining access to a user's data without their cons= ent?



 
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth
--_000_59E470B10C4630419ED717AC79FCF9A923F04C0CBY2PRD0411MB441_-- From dick.hardt@gmail.com Tue Aug 7 17:52:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFB721F86A4 for ; Tue, 7 Aug 2012 17:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0GyUxr9t2kj for ; Tue, 7 Aug 2012 17:52:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F021F86A1 for ; Tue, 7 Aug 2012 17:52:40 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so500824pbb.31 for ; Tue, 07 Aug 2012 17:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=VZ/UbwNz3MffrVF7g6IVmkN8SOduLLjKuo0b6Ee2N00=; b=eJLY/itchsys7qu4ejwSYmekDD1kIfMnevgAUAC06WoFoFsel5FbijYoAvwCaKlttD RM4Hq1VNevpeUPw37SzwfW4eCJLmee2tvlz8NbP3QbyOzewJUrc4S+fMg8IfHrZ0Qf2Z nOiqXAruQZLkv4hKrtgQHRknndh3DKw0XtaFSc2m0Cazv1MEs+07PhpKxxuog3nss0Vl Qh7LEiFuMgApRQ7nI/NY3Nw+670Atshn2K/6TPW3OO+xPHzM4jUa17tTsUTJ4z/PTP7d 7DfZURCLQp0JuARj2yv+I9ifM9PkiJB3O+Ik0j1drMBuWwg4b7bXeo2+I9TvewM41qea Ax1g== Received: by 10.66.75.168 with SMTP id d8mr29842275paw.63.1344387160372; Tue, 07 Aug 2012 17:52:40 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id gh9sm12176612pbc.20.2012.08.07.17.52.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 17:52:39 -0700 (PDT) From: Dick Hardt Content-Type: multipart/alternative; boundary="Apple-Mail=_CBED57C8-11A7-43D7-A361-2994148E1966" Date: Tue, 7 Aug 2012 17:52:37 -0700 References: To: oauth WG Message-Id: <825EF775-C6BC-4630-AE00-4063C6458A46@gmail.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 00:52:42 -0000 --Apple-Mail=_CBED57C8-11A7-43D7-A361-2994148E1966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Would appreciate a few others checking to make sure the IANA entries are = valid.=20 -- Dick Begin forwarded message: > From: "Amanda Baber via RT" > Subject: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization = Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt)=20 > Date: August 7, 2012 5:34:26 PM PDT > Cc: dick.hardt@gmail.com, oauth-chairs@tools.ietf.org, = oauth-ads@tools.ietf.org > Reply-To: drafts-approval@iana.org >=20 > Dear Author: >=20 > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED=20 >=20 > We have completed the IANA Actions for RFC-to-be > draft-ietf-oauth-v2-31 >=20 > IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth > Authorization Endpoint Response Types, and OAuth Extensions Errors > registries at >=20 > http://www.iana.org/assignments/oauth-parameters >=20 >=20 > Please let us know whether the above IANA Actions look OK. As=20 > soon as we receive your confirmation, we'll notify the RFC Editor=20 > that this document's IANA Actions are complete.=20 >=20 > Thanks, >=20 > Amanda Baber > ICANN/IANA >=20 --Apple-Mail=_CBED57C8-11A7-43D7-A361-2994148E1966 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Would = appreciate a few others checking to make sure the IANA entries are = valid. 

-- Dick

Begin forwarded = message:

From: "Amanda Baber via RT" <drafts-approval@iana.org><= br>
Subject: [IANA #596671] Protocol Action: 'The OAuth 2.0 = Authorization Framework' to Proposed Standard = (draft-ietf-oauth-v2-31.txt)
Date: August 7, 2012 = 5:34:26 PM PDT
Reply-To: drafts-approval@iana.org
<= /span>

Dear Author:

ATTENTION: A RESPONSE TO THIS = MESSAGE IS NEEDED

We have completed the IANA Actions for = RFC-to-be
draft-ietf-oauth-v2-31

IANA has created the OAuth = Access Token Types, OAuth Parameters, OAuth
Authorization Endpoint = Response Types, and OAuth Extensions Errors
registries at

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.

Thanks,

Amanda = Baber
ICANN/IANA


= --Apple-Mail=_CBED57C8-11A7-43D7-A361-2994148E1966-- From stpeter@stpeter.im Tue Aug 7 18:27:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8837821F8550 for ; Tue, 7 Aug 2012 18:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlqBh+rkUlC1 for ; Tue, 7 Aug 2012 18:27:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC13021F854A for ; Tue, 7 Aug 2012 18:27:55 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3626A4006D; Tue, 7 Aug 2012 19:27:58 -0600 (MDT) Message-ID: <5021C098.3090606@stpeter.im> Date: Tue, 07 Aug 2012 19:27:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dick Hardt References: <825EF775-C6BC-4630-AE00-4063C6458A46@gmail.com> In-Reply-To: <825EF775-C6BC-4630-AE00-4063C6458A46@gmail.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth WG Subject: Re: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 01:27:56 -0000 Putting the parameters in alphabetical order would make the page more readable, but other than that it seems fine. On 8/7/12 6:52 PM, Dick Hardt wrote: > Would appreciate a few others checking to make sure the IANA entries are > valid. > > -- Dick > > Begin forwarded message: > >> *From: *"Amanda Baber via RT" > > >> *Subject: **[IANA #596671] Protocol Action: 'The OAuth 2.0 >> Authorization Framework' to Proposed Standard >> (draft-ietf-oauth-v2-31.txt) * >> *Date: *August 7, 2012 5:34:26 PM PDT >> *Cc: *dick.hardt@gmail.com , >> oauth-chairs@tools.ietf.org , >> oauth-ads@tools.ietf.org >> *Reply-To: *drafts-approval@iana.org >> >> Dear Author: >> >> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED >> >> We have completed the IANA Actions for RFC-to-be >> draft-ietf-oauth-v2-31 >> >> IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth >> Authorization Endpoint Response Types, and OAuth Extensions Errors >> registries at >> >> 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. >> >> Thanks, >> >> Amanda Baber >> ICANN/IANA >> From Michael.Jones@microsoft.com Tue Aug 7 18:35:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B7611E80DF for ; Tue, 7 Aug 2012 18:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.291 X-Spam-Level: X-Spam-Status: No, score=-5.291 tagged_above=-999 required=5 tests=[AWL=1.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyW+LXA4sgwO for ; Tue, 7 Aug 2012 18:35:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id B767411E80D2 for ; Tue, 7 Aug 2012 18:35:08 -0700 (PDT) Received: from mail273-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 01:35:08 +0000 Received: from mail273-tx2 (localhost [127.0.0.1]) by mail273-tx2-R.bigfish.com (Postfix) with ESMTP id 1B4261C034F; Wed, 8 Aug 2012 01:35:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zf7Iz9371Ic85fh4015I9a6kzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail273-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail273-tx2 (localhost.localdomain [127.0.0.1]) by mail273-tx2 (MessageSwitch) id 1344389705504948_11394; Wed, 8 Aug 2012 01:35:05 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.249]) by mail273-tx2.bigfish.com (Postfix) with ESMTP id 6EB6D1E80044; Wed, 8 Aug 2012 01:35:05 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 01:35:05 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Wed, 8 Aug 2012 01:35:04 +0000 From: Mike Jones To: Dick Hardt , oauth WG Thread-Topic: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) Thread-Index: AQHNdQAik4rWsaMrRU+1KnKAS95v5JdPIOiA Date: Wed, 8 Aug 2012 01:35:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436676BD56@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <825EF775-C6BC-4630-AE00-4063C6458A46@gmail.com> In-Reply-To: <825EF775-C6BC-4630-AE00-4063C6458A46@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436676BD56TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 01:35:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436676BD56TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The reference for the OAuth Access Token Types registry should be http://to= ols.ietf.org/html/draft-ietf-oauth-v2-31 - not http://tools.ietf.org/html/d= raft-ietf-oauth-urn-sub-ns-06. Other than that, looks good. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= ick Hardt Sent: Tuesday, August 07, 2012 5:53 PM To: oauth WG Subject: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Aut= horization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) Would appreciate a few others checking to make sure the IANA entries are va= lid. -- Dick Begin forwarded message: From: "Amanda Baber via RT" > Subject: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Frame= work' to Proposed Standard (draft-ietf-oauth-v2-31.txt) Date: August 7, 2012 5:34:26 PM PDT Cc: dick.hardt@gmail.com, oauth-chairs@tools.i= etf.org, oauth-ads@tools.ietf.org Reply-To: drafts-approval@iana.org Dear Author: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We have completed the IANA Actions for RFC-to-be draft-ietf-oauth-v2-31 IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth Authorization Endpoint Response Types, and OAuth Extensions Errors registries at 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. Thanks, Amanda Baber ICANN/IANA --_000_4E1F6AAD24975D4BA5B16804296739436676BD56TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The reference for the OAu= th Access Token Types registry should be http://tools.= ietf.org/html/draft-ietf-oauth-v2-31 - not http:= //tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06.=

 <= /p>

Other than that, looks go= od.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Tuesday, August 07, 2012 5:53 PM
To: oauth WG
Subject: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth = 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.t= xt)

 

Would appreciate a few others checking to make sure = the IANA entries are valid. 

 

-- Dick

 

Begin forwarded message:



From: "Amanda Baber via RT" <drafts-approval@iana.org>=

Subject: [IANA #596671] Protocol A= ction: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-= ietf-oauth-v2-31.txt)

Date: August 7, 2012 5:34:26 PM PDT

 

Dear Author:

ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED

We have completed the IANA Actions for RFC-to-be
draft-ietf-oauth-v2-31

IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth
Authorization Endpoint Response Types, and OAuth Extensions Errors
registries at

http://www.ian= a.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.

Thanks,

Amanda Baber
ICANN/IANA

 

--_000_4E1F6AAD24975D4BA5B16804296739436676BD56TK5EX14MBXC283r_-- From dick.hardt@gmail.com Tue Aug 7 18:53:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B6F11E80FA for ; Tue, 7 Aug 2012 18:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8zNF6mJGKVM for ; Tue, 7 Aug 2012 18:53:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 389E511E80F1 for ; Tue, 7 Aug 2012 18:53:06 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so578031pbb.31 for ; Tue, 07 Aug 2012 18:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=llL+91lOWZwcD0s1JAAcm7ixlzCU8OiVEzlZgEX0Y1M=; b=QaqKgC7TQX6ggrH3t4cCmZSv+b+MYjqdgRt9WuTZmZWLFju6pmITSRyRm9xbQ4dcg4 9MOJgAI3b2fKQcfQoewDRLV06OVi4973yei4pEG7oSzb+whOn2h/xZtDNVVayeNS/FgQ R8w0qE0s5sLPpYEzyglew3HX7PXInOM+1L2IRMrZghaqsgYYpXTP9pUEc3CeV1ODNh/0 WPT4iDi77xib+V1wmT5Ny/foMszg8UVcJQnn/CYd77NUmddQVYq/N2FxhKkT3wGO0Sgn Nl6Qi9iU2Bq7A9QV8ZMY+5u0RAcfozBUhuhlaD1EErCVr6FqtvpGo+q7ltuyha++VvCZ yEkA== Received: by 10.68.136.38 with SMTP id px6mr32173697pbb.103.1344390785940; Tue, 07 Aug 2012 18:53:05 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id oj8sm8846488pbb.54.2012.08.07.18.53.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 18:53:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Tue, 7 Aug 2012 18:53:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120802001424.27749.75383.idtracker@ietfa.amsl.com> To: drafts-approval@iana.org X-Mailer: Apple Mail (2.1278) Cc: oauth-chairs@tools.ietf.org, oauth-ads@tools.ietf.org, oauth WG Subject: Re: [OAUTH-WG] [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 01:53:08 -0000 Hello Amanda (or whoever :) It would be nice if the OAuth Parameters were listed alphabetical.=20 Also, the reference for the OAuth Access Token Types registry should be = http://tools.ietf.org/html/draft-ietf-oauth-v2-31 - = nothttp://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06. -- Dick On Aug 7, 2012, at 5:34 PM, Amanda Baber via RT wrote: > Dear Author: >=20 > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED=20 >=20 > We have completed the IANA Actions for RFC-to-be > draft-ietf-oauth-v2-31 >=20 > IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth > Authorization Endpoint Response Types, and OAuth Extensions Errors > registries at >=20 > http://www.iana.org/assignments/oauth-parameters >=20 >=20 > Please let us know whether the above IANA Actions look OK. As=20 > soon as we receive your confirmation, we'll notify the RFC Editor=20 > that this document's IANA Actions are complete.=20 >=20 > Thanks, >=20 > Amanda Baber > ICANN/IANA >=20 From ve7jtb@ve7jtb.com Tue Aug 7 18:53:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEA411E80D2 for ; Tue, 7 Aug 2012 18:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Tgy+Tuq8Jmm for ; Tue, 7 Aug 2012 18:53:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31DF611E80F1 for ; Tue, 7 Aug 2012 18:53:57 -0700 (PDT) Received: by yhq56 with SMTP id 56so281833yhq.31 for ; Tue, 07 Aug 2012 18:53:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UFUqctjtD3uXz58MJmQN0yj5KxUVu2tZtAIoNpKQ828=; b=kh0IzImZFp+vMTDFZBIV8FfqjPRZcELAWvdCJ8iWSMzypEK+lkk5HwcjUnr5UeiYfv p85QAGN1YSAIQXwmpr02ceExP0dVIGSuqpmyqXwZPbP3gKxO1RFwgJxEvVZT4QIHQO7q vZRAHzttMcFq5u1ghdLQFXX6xaPX5V0V85379AsBda6Yk/5zw/w1hfliebv4KOpFki7d K8a4aJyNMlF+FdhnUVRVo3f/iv4+fucU0/a+f5EOksIOU/nI5at80H6kJeO1JzyH4kjy lOFCu/DlOmjgfcQSN0rZxu1b2EAEP3UYRrBXlHehuZQIr+hfndE8695Dl+I6G1K5eeka Lpcw== Received: by 10.236.178.38 with SMTP id e26mr15625447yhm.12.1344390836676; Tue, 07 Aug 2012 18:53:56 -0700 (PDT) Received: from [192.168.1.211] (190-20-38-200.baf.movistar.cl. [190.20.38.200]) by mx.google.com with ESMTPS id t39sm19262211anh.3.2012.08.07.18.53.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 18:53:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_7FE8AF8B-3098-4F32-B25A-D84E34E92C64"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436676BD56@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 7 Aug 2012 21:54:40 -0400 Message-Id: <693AC132-C8CA-4DE3-A7D6-20861E110DBE@ve7jtb.com> References: <825EF775-C6BC-4630-AE00-4063C6458A46@gmail.com> <4E1F6AAD24975D4BA5B16804296739436676BD56@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnlZ5tO4cyXYv5bEGc+sBskmhZdYM8rlq25spSZ3Eda8iwCwDGb2Rp6pNuRJv2CcjwxKSZr Cc: oauth WG Subject: Re: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 01:53:58 -0000 --Apple-Mail=_7FE8AF8B-3098-4F32-B25A-D84E34E92C64 Content-Type: multipart/alternative; boundary="Apple-Mail=_0F393F10-1725-42BF-A314-C7D004556EEE" --Apple-Mail=_0F393F10-1725-42BF-A314-C7D004556EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes I was just trying to work out what was going on with the OAuth = Access token types. The OAuth parameters are in the same order as the spec has them so not = too surprising. I can't make out any particular significance of the = order, having them make it alphabetical would not hurt. Other than that looks fine. John B. On 2012-08-07, at 9:35 PM, Mike Jones wrote: > The reference for the OAuth Access Token Types registry should be = http://tools.ietf.org/html/draft-ietf-oauth-v2-31 - = nothttp://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06. > =20 > Other than that, looks good. > =20 > -- Mike > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Tuesday, August 07, 2012 5:53 PM > To: oauth WG > Subject: [OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth = 2.0 Authorization Framework' to Proposed Standard = (draft-ietf-oauth-v2-31.txt) > =20 > Would appreciate a few others checking to make sure the IANA entries = are valid.=20 > =20 > -- Dick > =20 > Begin forwarded message: >=20 >=20 > From: "Amanda Baber via RT" > Subject: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization = Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) > Date: August 7, 2012 5:34:26 PM PDT > Cc: dick.hardt@gmail.com, oauth-chairs@tools.ietf.org, = oauth-ads@tools.ietf.org > Reply-To: drafts-approval@iana.org > =20 > Dear Author: >=20 > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED=20 >=20 > We have completed the IANA Actions for RFC-to-be > draft-ietf-oauth-v2-31 >=20 > IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth > Authorization Endpoint Response Types, and OAuth Extensions Errors > registries at >=20 > http://www.iana.org/assignments/oauth-parameters >=20 >=20 > Please let us know whether the above IANA Actions look OK. As=20 > soon as we receive your confirmation, we'll notify the RFC Editor=20 > that this document's IANA Actions are complete.=20 >=20 > Thanks, >=20 > Amanda Baber > ICANN/IANA >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0F393F10-1725-42BF-A314-C7D004556EEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes I was just trying to work out what was going on = with the OAuth Access token types.

The OAuth = parameters are in the same order as the spec has them so not too = surprising.  I can't make out any particular significance of the = order,  having them make it alphabetical would not = hurt.

Other than that looks = fine.

John B.

On = 2012-08-07, at 9:35 PM, Mike Jones wrote:

The = reference for the OAuth Access Token Types registry should be  - notOther = than that, looks good.
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Dick = Hardt
Sent: Tuesday, August 07, 2012 = 5:53 PM
To: oauth = WG
Subject: [OAUTH-WG] Fwd: [IANA = #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to = Proposed Standard = (draft-ietf-oauth-v2-31.txt)
 
Would appreciate a few = others checking to make sure the IANA entries are = valid. 
-- = Dick
Begin forwarded = message:
 Subject: [IANA #596671] Protocol Action: 'The = OAuth 2.0 Authorization Framework' to Proposed Standard = (draft-ietf-oauth-v2-31.txt)
Date: August = 7, 2012 5:34:26 PM PDT
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_0F393F10-1725-42BF-A314-C7D004556EEE-- --Apple-Mail=_7FE8AF8B-3098-4F32-B25A-D84E34E92C64 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw ODAxNTQ0MVowIwYJKoZIhvcNAQkEMRYEFIYKU7fn/O8Llf3kEI9Hv5Y9aczbMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AEqhKfALzSHv6BBP7AnlCNthfRGCFytkVn1OYbfGlVWpJ+4YESyObT4/J97ePR46PsuP00cqDDme r1dBlPzbrsx7newL89tTs+aY+frG4r4HU/+iaK0Q2gVpOyFTE1o/SVA94Vqc7SCOVI85+zObIzFO +v6RqEo1SZgpRkIOOdZPbG7Nn9juxcR9+YlkjYGsMgf/qhrFwAuaIN1i2u09xH6+lzbG8Iv6PM3a xjEDDnw59JDf/O8d+4V3uwAGGD51sPF+hriRonlW0loJxDPcRv6BbEETQeqGiPEcsEoOgDrbsOwg 23oAMMhd564ZXJPnqKA4Hott/9MTp9gzPHRtYoIAAAAAAAA= --Apple-Mail=_7FE8AF8B-3098-4F32-B25A-D84E34E92C64-- From jjanauskas@gmail.com Sun Aug 5 03:31:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A117121F8503 for ; Sun, 5 Aug 2012 03:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxF+KqP9J-Hz for ; Sun, 5 Aug 2012 03:31:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3A21F84A1 for ; Sun, 5 Aug 2012 03:31:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4639888obb.31 for ; Sun, 05 Aug 2012 03:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=woTEYh8ydZr8cTKBJmr8mItJc39cgqpz6AnlgutDvqs=; b=AlEfmzkJll8LO0sWLRglyaf/eONY+rFOINqb7hqKxl4XL87vbPbuYRMde6Kd/+jCDn DA8V3Nx43XwsJW9h6g3e1q76+k70XBInnnP6ayZxsoM7wXyUDKxlQVFhvYZcYrzG/qaJ uXw9/wMSwvtqWxqqw5e2eql0eMpGaZZwYGGoiJT1hcqwQj7RXKpw4zJsKtN3RlRkTEV0 9DMoGa084bmW0yhZ9+EpiXZmJc5rwrPY6DIvLJwaBSgEbIfQDThx8BWhnfDL6jzJ0zQc nUrDF2ctfp9o3BEfEtOSkjIbUVoU8wjAKVOka91p333aeS4cbkUcPfNy4JHw0o31AuqR Pfxg== Received: by 10.182.14.36 with SMTP id m4mr14114296obc.71.1344162675780; Sun, 05 Aug 2012 03:31:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.47.6 with HTTP; Sun, 5 Aug 2012 03:30:55 -0700 (PDT) From: Justas Janauskas Date: Sun, 5 Aug 2012 13:30:55 +0300 Message-ID: To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 08 Aug 2012 07:25:12 -0700 Subject: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 10:32:23 -0000 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 From jricher@mitre.org Wed Aug 8 08:09:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40A021F8670 for ; Wed, 8 Aug 2012 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-C4deoQMqiZ for ; Wed, 8 Aug 2012 08:09:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7C421F84F5 for ; Wed, 8 Aug 2012 08:09:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2036921B1AEA for ; Wed, 8 Aug 2012 11:09:24 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1023521B0845 for ; Wed, 8 Aug 2012 11:09:24 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 8 Aug 2012 11:09:23 -0400 Message-ID: <502280D8.40708@mitre.org> Date: Wed, 8 Aug 2012 11:08:08 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:09:25 -0000 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 From wmills_92105@yahoo.com Wed Aug 8 08:22:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED8411E80EE for ; Wed, 8 Aug 2012 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT27Y1ATGQCx for ; Wed, 8 Aug 2012 08:22:43 -0700 (PDT) Received: from nm6-vm0.bullet.mail.bf1.yahoo.com (nm6-vm0.bullet.mail.bf1.yahoo.com [98.139.213.146]) by ietfa.amsl.com (Postfix) with ESMTP id 62FE611E80C5 for ; Wed, 8 Aug 2012 08:22:40 -0700 (PDT) Received: from [98.139.212.153] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 08 Aug 2012 15:22:39 -0000 Received: from [98.139.212.205] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 08 Aug 2012 15:22:39 -0000 Received: from [127.0.0.1] by omp1014.mail.bf1.yahoo.com with NNFMP; 08 Aug 2012 15:22:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 768499.82470.bm@omp1014.mail.bf1.yahoo.com Received: (qmail 23670 invoked by uid 60001); 8 Aug 2012 15:22:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344439359; bh=/doR8eV95ZO0by8jsNrLqQ9EdZcbdsRie5vPM51onfo=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rMPW+aQBiY3TAzcKseVHqo+6zBXCkgaqqaoFxcArtF1pEZDN+MlrQ3XWhcFAqyQPd3opQ8d2or/iP3JuxTt9H8eNyzBDn9KJf1gVURZbUHhT7FelPW31eKto+C+bx+v7X6tzk1rwHczFTFY5iBGNtBquxjX+No02SAT+i7pRh1Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2Re63WA43HpZea7pLZy17q8O4o/EM3pgBFE94ZYgO0ISTOKG0seNsjcCgUa/kQ6i/L/wRPyAt4sS6dLDIwl0UJx6dppG5q9x1Wol7cscNApuV4GIca1e98bCcaFR102kGoaGzwsVpkfmvvEQUfF49uKd6cXcRUY0AYixWmSaA+8=; X-YMail-OSG: MJt9eogVM1lE8oPrXlAxeVxzUHWYZKXRMjKGgW9WAqg3c3q 51JdqfNBhRExIxa.pQspUb2pSF70m5M2c.aT2_75hqXViy5oJ_tKs81VE6i3 GaIB1H1IqoCml9vQGdR7nxQTp5Spux7aAP4kHvm4FmP8wx0VGD0GEHWhgibU JIKPQdWTSf4pP99xIVzGGJFpfNIR19y7VaBzejOwGP6ITjPQVIBOQoRWRZoK pcz5lBcpgjUe25oejcY3Sslw9sJExfE8N5d9q2iPlaXcARYobtvmIN05pjBF SUrY9cWrF84dYC8yTLfmGvkOVdpipNQQtvZQD84vnt5.ETCbK927BkM6cVtP 9HUaOEbiETkAv4PCjrlpt19vo__Qg7W0pKncvHBFpEqzbcz4BdVIDJBX.w9O F.nVS8tio7Mf7KfuZA8JXT.hAcC_eLxiTS508QOnKjkl9G5ZMV4E5nItwfFO VuB6j1O4XzWruSw4AQSm0twNesWO8sJ5G8ic5R7XK5mN7CfApoFSa0agDttV 5Ovj3pT9luI4XqkwubXuge.tQJ7AROuuzfsNGuFE8XvvDPzJDzXCAGJtWfMH Cbvhx7b1jmNo4A9o- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Wed, 08 Aug 2012 08:22:39 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> Message-ID: <1344439359.20069.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 8 Aug 2012 08:22:39 -0700 (PDT) From: William Mills To: Justin Richer , "oauth@ietf.org" In-Reply-To: <502280D8.40708@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1054223212-1344439359=:20069" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:22:46 -0000 --1458549034-1054223212-1344439359=:20069 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Justin,=0A=0ACount me in to help revive this and get it done.=0A=0A-bill=0A= =0A=0A________________________________=0A From: Justin Richer =0ATo: oauth@ietf.org =0ASent: Wednesday, August 8, 2012 8:08 AM=0ASu= bject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A =0AThan= ks Justas. The MAC document is currently without an editor within =0Athe WG= , so this is the best place to record the error.=0A=0AA wider note to the W= G: I wouldn't mind taking over editorship of the =0AMAC token document so l= ong as I could get a co-editor with enough =0Acryptographic expertise to ma= ke sure all the magical crypto bits work =0Alike they should. I've sent an = email to the chairs saying as much, as well.=0A=0A=A0 -- Justin=0A=0AOn 08/= 05/2012 06:30 AM, Justas Janauskas wrote:=0A> Hello,=0A>=0A> Sorry if this = is not the right group to send this message; I am new here.=0A>=0A> I belie= ve there is mistake in calculated request MAC presented in=0A> "draft-ietf-= oauth-v2-http-mac-01" example, section 1.1.=0A>=0A> I made a small program = to test correctness of an example and it shows=0A> that it is incorrectly c= alculated in the document:=0A> https://gist.github.com/3263677=0A>=0A> I ha= ve also implemented an example from previous draft 00, section 1.2=0A> whic= h shows that request MAC is calculated correctly there:=0A> https://gist.gi= thub.com/3263765=0A>=0A> Thank you,=0A> Justas Janauskas=0A> ______________= _________________________________=0A> OAuth mailing list=0A> OAuth@ietf.org= =0A> https://www.ietf.org/mailman/listinfo/oauth=0A=0A_____________________= __________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/oauth --1458549034-1054223212-1344439359=:20069 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Justin,

Count me in to help revi= ve this and get it done.

-bill

From: Justin Richer <jricher@mitre.org>
To: oauth@ietf.org
Sent: Wednesday, August 8, 2012 8:0= 8 AM
Subject: Re: [OAU= TH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

= =0AThanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.

A wider not= e to the WG: I wouldn't mind taking over editorship of the
MAC token do= cument so long as I could get a co-editor with enough
cryptographic exp= ertise 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 r= equest 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 do= cument:
> https://gist.github.com/3263677
>
> I ha= ve 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 li= st
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=
--1458549034-1054223212-1344439359=:20069-- From hannes.tschofenig@gmx.net Wed Aug 8 09:24:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BA921F873A for ; Wed, 8 Aug 2012 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Yvu3oSG0LSn for ; Wed, 8 Aug 2012 09:24:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CA49F21F8726 for ; Wed, 8 Aug 2012 09:24:35 -0700 (PDT) Received: (qmail invoked by alias); 08 Aug 2012 16:24:34 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp038) with SMTP; 08 Aug 2012 18:24:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2W7Q3CWP2W8OgbbtW10HGVnzNow9Kh7RGNoKPBm Nbpgsv9NNhtepx Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <502280D8.40708@mitre.org> Date: Wed, 8 Aug 2012 19:24:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> References: <502280D8.40708@mitre.org> To: Justin Richer , Justas Janauskas X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:24:37 -0000 Hi Justas,=20 thanks for sending your feedback to the list.=20 There is indeed currently no editor for the document. That is, however, = not the problem.=20 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.=20 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.=20 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. >=20 > 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. >=20 > -- Justin >=20 > On 08/05/2012 06:30 AM, Justas Janauskas wrote: >> Hello, >>=20 >> Sorry if this is not the right group to send this message; I am new = here. >>=20 >> I believe there is mistake in calculated request MAC presented in >> "draft-ietf-oauth-v2-http-mac-01" example, section 1.1. >>=20 >> 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 >>=20 >> 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 >>=20 >> Thank you, >> Justas Janauskas >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Wed Aug 8 09:53:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEDB21F875E for ; Wed, 8 Aug 2012 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASUuZttLABoU for ; Wed, 8 Aug 2012 09:53:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9197211E80FE for ; Wed, 8 Aug 2012 09:53:43 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q78GrdvR024886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Aug 2012 16:53:40 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q78Grdcf001560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Aug 2012 16:53:39 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q78GrcnS015627; Wed, 8 Aug 2012 11:53:38 -0500 Received: from [25.65.10.249] (/74.198.150.249) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 08 Aug 2012 09:53:38 -0700 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> In-Reply-To: <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Wed, 8 Aug 2012 09:53:33 -0700 To: Hannes Tschofenig X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: Justas Janauskas , "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:53:47 -0000 I have promised to put together a summary of the discussion presented in van= couver meeting.=20 Unfortunately it may take a few weeks as i am away for another week and a ha= lf.=20 Phil On 2012-08-08, at 9:24, Hannes Tschofenig wrote:= > Hi Justas,=20 >=20 > thanks for sending your feedback to the list.=20 >=20 > There is indeed currently no editor for the document. That is, however, no= t the problem.=20 > The problem, as discussed on the list and also at the last IETF meeting, i= s that we do not yet know what type of security properties we want. The MAC d= raft may or may not provide the type of protection we want.=20 >=20 > For that reason we first have to figure out what problem we want to solve b= efore we jump into the details of fixing some minor errors.=20 >=20 > Ciao > Hannes >=20 > On Aug 8, 2012, at 6:08 PM, Justin Richer wrote: >=20 >> Thanks Justas. The MAC document is currently without an editor within the= WG, so this is the best place to record the error. >>=20 >> 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. >>=20 >> -- Justin >>=20 >> On 08/05/2012 06:30 AM, Justas Janauskas wrote: >>> Hello, >>>=20 >>> Sorry if this is not the right group to send this message; I am new here= . >>>=20 >>> I believe there is mistake in calculated request MAC presented in >>> "draft-ietf-oauth-v2-http-mac-01" example, section 1.1. >>>=20 >>> 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 >>>=20 >>> 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 >>>=20 >>> Thank you, >>> Justas Janauskas >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Aug 8 14:01:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E2E21F8527 for ; Wed, 8 Aug 2012 14:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpDX1CZABk9o for ; Wed, 8 Aug 2012 14:01:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02B3021F851E for ; Wed, 8 Aug 2012 14:01:05 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 521FB21B1AF1; Wed, 8 Aug 2012 17:01:04 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4307621B1036; Wed, 8 Aug 2012 17:01:04 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 8 Aug 2012 17:01:04 -0400 Message-ID: <5022D344.40600@mitre.org> Date: Wed, 8 Aug 2012 16:59:48 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Hannes Tschofenig References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> In-Reply-To: <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: oauth@ietf.org, Justas Janauskas Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 21:01:06 -0000 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 From ve7jtb@ve7jtb.com Wed Aug 8 14:21:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1EE21F85AA for ; Wed, 8 Aug 2012 14:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkJZGzn2xi1o for ; Wed, 8 Aug 2012 14:21:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E75021F85A8 for ; Wed, 8 Aug 2012 14:21:13 -0700 (PDT) Received: by yenm5 with SMTP id m5so1422847yen.31 for ; Wed, 08 Aug 2012 14:21:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Dgj4Aws42nHAHx4eTuwdwAHUBrBn0R7/0s4FsrI06Uo=; b=LLNemwnaKamCOYbv0P86kTfTWn92vSo2Tk4XaMJ65t2s5ot9Q2jrDFnvZfjPDyIl6/ bA8ZdXFnF5ABVOlzn2MR03aKZTeAZPQyRuZ91lHF1j+lXhP055f8dMd3cqBzxZddYovt M9cXzZnpTpu95bPAes+tmAzNCQKGIIVBF/4011b8kFT/EQ5rak5IWbTg3IuaNvwUa78E lFxmV15ZeMt1xbJzLdMmXKCXUzSqI+oVii2Xs+EBDkUKb89f7s2u1OclSAsV9bfn6mK4 PHKl5/tdYbymlftfxTZaHgL1wbYIKAaNn1pAXXaX4UFvF0bAFAmOSXj5IbheBA8aKjda hIdA== Received: by 10.100.244.25 with SMTP id r25mr4915944anh.30.1344460872667; Wed, 08 Aug 2012 14:21:12 -0700 (PDT) Received: from [192.168.1.211] (190-20-28-180.baf.movistar.cl. [190.20.28.180]) by mx.google.com with ESMTPS id s12sm14833659anh.2.2012.08.08.14.21.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Aug 2012 14:21:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_3004E9BF-240F-4580-A046-6378BA1F2D65"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <5022D344.40600@mitre.org> Date: Wed, 8 Aug 2012 17:21:52 -0400 Message-Id: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmlHiFOeFIOkJ33Y4dRrpFlz93dipw4z7qv5GJL+ks67J25hIrty6AmpISW0SY8+66gD+Gs Cc: oauth@ietf.org, Justas Janauskas Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 21:21:14 -0000 --Apple-Mail=_3004E9BF-240F-4580-A046-6378BA1F2D65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.=20 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. >=20 > -- Justin >=20 > On 08/08/2012 12:24 PM, Hannes Tschofenig wrote: >> Hi Justas, >>=20 >> thanks for sending your feedback to the list. >>=20 >> 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. >>=20 >> 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. >>=20 >> Ciao >> Hannes >>=20 >> On Aug 8, 2012, at 6:08 PM, Justin Richer wrote: >>=20 >>> Thanks Justas. The MAC document is currently without an editor = within the WG, so this is the best place to record the error. >>>=20 >>> 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. >>>=20 >>> -- Justin >>>=20 >>> On 08/05/2012 06:30 AM, Justas Janauskas wrote: >>>> Hello, >>>>=20 >>>> Sorry if this is not the right group to send this message; I am new = here. >>>>=20 >>>> I believe there is mistake in calculated request MAC presented in >>>> "draft-ietf-oauth-v2-http-mac-01" example, section 1.1. >>>>=20 >>>> 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 >>>>=20 >>>> 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 >>>>=20 >>>> 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_3004E9BF-240F-4580-A046-6378BA1F2D65 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw ODIxMjE1M1owIwYJKoZIhvcNAQkEMRYEFDUNHi7k7BE1NqVvjcl3borEf33GMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AE5TKNfigXgADzi9FGaHvPWeQlqm4FRtrthPFt1KGtRc/86IWL60nVhc7GS88+BtywSF2+rmAjIC b4DIEEEz1W5Da/SoPSx7oMS+FEwpiYy40hs8EOe1fTAkhZAcQLEshINJo9HfSc/l5DocQUYLeP/s W5l6P3xMPbLzy0fxEjN//WsydJfzv/Jtm4Dzl3PB4su242Puu4hrq9/AXqnFiJvr5fXjuV5zzQ46 PFja4VeXzFlVp0ZF7UHkMNS0uHh7dDrPhNCa4TgpM4E72BaXoVOHKsMqH9tLxszOR6stEjdS2QVh 5IhCZERAnRWdlReIj5ChMRtn/0cqMnW3az5qc2IAAAAAAAA= --Apple-Mail=_3004E9BF-240F-4580-A046-6378BA1F2D65-- From jricher@mitre.org Thu Aug 9 07:42:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520621F866D for ; Thu, 9 Aug 2012 07:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qQRgA62A+qt for ; Thu, 9 Aug 2012 07:42:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DA3A121F863F for ; Thu, 9 Aug 2012 07:42:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 233DB21B12ED; Thu, 9 Aug 2012 10:42:45 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 127DA21B033D; Thu, 9 Aug 2012 10:42:45 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 9 Aug 2012 10:42:44 -0400 Message-ID: <5023CC18.9090809@mitre.org> Date: Thu, 9 Aug 2012 10:41:28 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: John Bradley References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: oauth@ietf.org, Justas Janauskas Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:42:47 -0000 OK, that's fair. I just don't want process to get in the way of progress. -- Justin 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 From wmills_92105@yahoo.com Thu Aug 9 09:53:00 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9256221F875D for ; Thu, 9 Aug 2012 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdYzQjxtlUYp for ; Thu, 9 Aug 2012 09:52:59 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (nm17-vm0.bullet.mail.ne1.yahoo.com [98.138.91.58]) by ietfa.amsl.com (Postfix) with SMTP id 3A94C21F875B for ; Thu, 9 Aug 2012 09:52:59 -0700 (PDT) Received: from [98.138.90.49] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 16:52:55 -0000 Received: from [98.138.87.9] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 16:52:55 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 16:52:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 870643.41305.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 5378 invoked by uid 60001); 9 Aug 2012 16:52:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344531175; bh=8n4XI8Y3XgYlaKq8+L01lERz+K8R/MhqCSXPdS1+FUQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZTD9JyPNzxsB+C3VtvOGsAofVyfuoKOL2PjL9KjKcwUr2W+rVvNMrDHw5jnxm5Y9GmNVfAQQgaS9viipkTuALdtwF2bJPB3uQYUwsGBJEACkLBAOknCaJc1CLctwIXohP9piw2mHOOhHE5EnlAP81yAi/JLiNLS/oVN2Ejn9h08= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mMdXrN8KbdpBSN69sJ/2mZI3PM2zQLM9zLb8rUyMrKu/bk0J/vIEAkjN8yrVR8RzQmIKxgtYBy+paVOHySKrPPm6axjDhdGimicV7MPAk3eIw+7u3bxvtx5JTxuD0WvLt92VpK/DTzseaLaMH2HGviEFM3vTNmBQLqgoKCqXc/4=; X-YMail-OSG: 1r2.rSAVM1mkiLe.GBUz34LaYIKrfA8lNhO4C46CJ4T6oxV HbQSwfWDtuYU6foIeHFn8BQQVBAHEPAQktIitHT_WpoX_W9byiOqpXX8w0oz tNT_goTKpdixHrnA8rV_x79DLPVJco03nSKou65NQmlYpha4FNcf.vP2R0a4 HzQgQbqXJV_9cw36R3KHNFKjWAir2halNnaYWlHiWgS1_n6nKiVsLZ.YRsTH qIDQTvx2dSf2hjLq.h8MeuaD4cF5EaGvFV0df94IAac7g.f6oXfr50vzfIjE aQv9v2t_OAcjpu7sU9.eDL3cpCyAJsgOFTWjkUVxCiILuErRI7iOzhwa.618 5nDj1Rz3U1RzRdfqNZZFEonDc0Wvz98uYyf8DKngHn6CetTw1gILXAXIFtOP Eh_5pcHfJECyNQcHJc_MgiaAVNJvdCgrXzjU_WTjsnl051m_i8rFw.nIxIrM hhJPmtCXJ9pzioL1ZUssn7AtqIe9p3RQ3IaMwmG_QRRcy8mN6n8c7oKnSVam Fu.akgxgSzedep7ds7RbokgTHiHRmLOaAofm86_xByAA3rhQrjqBaDjCosJL g8MS6phltpyaj3Vc- Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 09:52:55 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> Message-ID: <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 09:52:55 -0700 (PDT) From: William Mills To: "oauth@ietf.org" In-Reply-To: <5023CC18.9090809@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-726678046-1344531175=:4871" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 16:53:00 -0000 --1458549034-726678046-1344531175=:4871 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I find the idea of starting from scratch frustrating. =A0MAC solves a set o= f specific problems and has a well defined use case. =A0It's symmetric key = based which doesn't work for some folks, and the question is do we try to d= evelop something that supports both PK and SK, or finish the SK use case an= d then work on a PK based draft.=0A=0AI think it's better to leave them sep= arate and finish out MAC which is *VERY CLOSE* to being done.=0A=0A-bill=0A= =0AOn 08/08/2012 05:21 PM, John Bradley wrote:=0A=0A> We did discuss per me= ssage signing in Vancouver.=0A>=0A> The idea is to get agreement on the thr= eats we are trying to mitigate, then decide on the mechanisms.=0A>=0A> Per = message signing will likely still be one of the mechanisms.=0A>=0A> The cha= ir 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.=0A>=0A> John B.=0A>=0A>= On 2012-08-08, at 4:59 PM, Justin Richer wrote:=0A>=0A>> I believe that th= ere'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 patte= rn very well established in OAuth1. I'm sorry that I wasn't at the Vancouve= r meeting to voice this opinion, for what it's worth.=0A>>=0A>> -- Justin= =0A>>=0A>> On 08/08/2012 12:24 PM, Hannes Tschofenig wrote:=0A>>> Hi Justas= ,=0A>>>=0A>>> thanks for sending your feedback to the list.=0A>>>=0A>>> The= re is indeed currently no editor for the document. That is, however, not th= e problem.=0A>>> 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 wan= t.=0A>>>=0A>>> 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.= =0A>>>=0A>>> Ciao=0A>>> Hannes=0A>>>=0A>>> On Aug 8, 2012, at 6:08 PM, Just= in Richer wrote:=0A>>>=0A>>>> Thanks Justas. The MAC document is currently = without an editor within the WG, so this is the best place to record the er= ror.=0A>>>>=0A>>>> A wider note to the WG: I wouldn't mind taking over edit= orship of the MAC token document so long as I could get a co-editor with en= ough 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.= =0A>>>>=0A>>>> -- Justin=0A>>>>=0A>>>> On 08/05/2012 06:30 AM, Justas Janau= skas wrote:=0A>>>>> Hello,=0A>>>>>=0A>>>>> Sorry if this is not the right g= roup to send this message; I am new here.=0A>>>>>=0A>>>>> I believe there i= s mistake in calculated request MAC presented in=0A>>>>> "draft-ietf-oauth-= v2-http-mac-01" example, section 1.1.=0A>>>>>=0A>>>>> I made a small progra= m to test correctness of an example and it shows=0A>>>>> that it is incorre= ctly calculated in the document:=0A>>>>> https://gist.github.com/3263677=0A= >>>>>=0A>>>>> I have also implemented an example from previous draft 00, se= ction 1.2=0A>>>>> which shows that request MAC is calculated correctly ther= e:=0A>>>>> https://gist.github.com/3263765=0A>>>>>=0A>>>>> Thank you,=0A>>>= >> Justas Janauskas=0A>>>>> _______________________________________________= =0A>>>>> OAuth mailing list=0A>>>>> OAuth@ietf.org=0A>>>>> https://www.ietf= .org/mailman/listinfo/oauth=0A>>>> ________________________________________= _______=0A>>>> OAuth mailing list=0A>>>> OAuth@ietf.org=0A>>>> https://www.= ietf.org/mailman/listinfo/oauth=0A>> ______________________________________= _________=0A>> OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf= .org/mailman/listinfo/oauth=0A=0A__________________________________________= _____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/oauth --1458549034-726678046-1344531175=:4871 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I find the idea of starting from scratch frustrating.  MAC s= olves 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 i= s do we try to develop something that supports both PK and SK, or finish th= e SK use case and then work on a PK based draft.
<= span style=3D"font-size: 12pt; ">
I think it's better to leave them separate and finis= h 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, the= n decide on the mechanisms.
>
> Per message signing will likely= still be one of the mechanisms.
>
> The chair will need to dec= ide 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 channe= l 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,
>&= gt;>
>>> thanks for sending your feedback to the list.
&g= t;>>
>>> There is indeed currently no editor for the docu= ment. That is, however, not the problem.
>>> The problem, as di= scussed on the list and also at the last IETF meeting, is that we do not ye= t know what type of security properties we want. The MAC draft may or may n= ot provide the type of protection we want.
>>>
>>> = For that reason we first have to figure out what problem we want to solve b= efore we jump into the details of fixing some minor errors.
>>>=
>>> Ciao
>>> Hannes
>>>
>>>= ; On Aug 8, 2012, at 6:08 PM, Justin Richer wrote:
>>>
>&= gt;>> Thanks Justas. The MAC document is currently without an editor within the WG, so this is the best place to record the error.
&g= t;>>>
>>>> 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 c= o-editor with enough cryptographic expertise to make sure all the magical c= rypto bits work like they should. I've sent an email to the chairs saying a= s much, as well.
>>>>
>>>> -- Justin
>&= gt;>>
>>>> On 08/05/2012 06:30 AM, Justas Janauskas wr= ote:
>>>>> Hello,
>>>>>
>>>= >> Sorry if this is not the right group to send this message; I am ne= w here.
>>>>>
>>>>> I believe there is = mistake in calculated request MAC presented in
>>>>> "dra= ft-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<= br>>>>>>
>>>>> I have also implemented an = example from previous draft 00, section 1.2
>>>>> which s= hows that request MAC is calculated correctly there:
>>>>>= ; https://gis= t.github.com/3263765
>>>>>
>>>>> Th= ank you,
>>>>> Justas Janauskas
>>>>> _= ______________________________________________
>>>>> OAut= h mailing list
>>>>> OAuth@ietf.org
>>>>> = https://www.ietf.org/mailman/listinfo/oauth
>&= gt;>> _______________________________________________
>>>= > 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 listOAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
--1458549034-726678046-1344531175=:4871-- From dick.hardt@gmail.com Thu Aug 9 10:27:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E32A21F871A for ; Thu, 9 Aug 2012 10:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ7WgM82U4fe for ; Thu, 9 Aug 2012 10:27:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9183421F8715 for ; Thu, 9 Aug 2012 10:27:30 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1231013pbb.31 for ; Thu, 09 Aug 2012 10:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=PftSs5qCcAXtg1/Xz9cN7oo3zjTHYN7S1sMTJJJrbj4=; b=F3PvVaRJru0mGnSI0JBmJIN1dSy7Co8aTIwzzQNpOYHOR21qTaffbbR3ucwNLajyDr OUAWgiUwfrw0z4G2zD5cqj6HyrB22Q+j3844dEi207a9J9GXP1RKsikfkKsgY31K4Xyb iXsCW+BE/NEKezQde+yaAsJrBbqiIeYIVkq0w27gZWHUJjScJtE8YxvUoP1UqI5QiFpN 6h7sN27VHzXPvvA36NdPhJAIBDdFxf0IiSZOHM2B4MRpNF0GNYQK/XSmX/XEf9CNNKno GtTD07A04N7zut+wJxaN3zHFY0rce+6WRjw1zL6GQaoDK+m3CTNvzM7DazTBYkVfabPR oiHg== Received: by 10.68.231.168 with SMTP id th8mr5878575pbc.14.1344533250345; Thu, 09 Aug 2012 10:27:30 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id st6sm162808pbc.58.2012.08.09.10.27.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 10:27:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_3B5FB52F-6A2A-43DC-B8DB-F7ACABEA2026" From: Dick Hardt In-Reply-To: <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 10:27:27 -0700 Message-Id: <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:27:31 -0000 --Apple-Mail=_3B5FB52F-6A2A-43DC-B8DB-F7ACABEA2026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. >=20 > 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.=20 For my projects, I prefer the flexibility of a signed or encrypted JWT = if I need holder of key. Just my $.02 -- Dick =20 --Apple-Mail=_3B5FB52F-6A2A-43DC-B8DB-F7ACABEA2026 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
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  

= --Apple-Mail=_3B5FB52F-6A2A-43DC-B8DB-F7ACABEA2026-- From wmills_92105@yahoo.com Thu Aug 9 10:53:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC30121F8778 for ; Thu, 9 Aug 2012 10:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQhiUOmYD4TR for ; Thu, 9 Aug 2012 10:53:48 -0700 (PDT) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) by ietfa.amsl.com (Postfix) with SMTP id 1082321F8769 for ; Thu, 9 Aug 2012 10:53:47 -0700 (PDT) Received: from [98.138.90.55] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 17:53:44 -0000 Received: from [98.138.89.251] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 17:53:44 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 17:53:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 948742.78487.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 42965 invoked by uid 60001); 9 Aug 2012 17:53:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344534823; bh=fJa1imf4M+QVNkiL0kpgek6Bz6VGz/OxQ486NzjTjks=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gK3HBgy6yfQNnwq747ewxzXv/lxFRte1aLUZ/K6QpvDsuBGeho+BOrYh1/Eq5TDg3oUHWwKq9g4vIjkd6UlVhuR42CQgy6zlMXR3wdiPc45cqvdB7d72mZcdYNofWFn3woAK3TaGTA5Y8kR8wfoHlt9ca8ej5rSx2XEEv4jxzuU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lNLfOHbTIqS5HOyRBY+PUXiTjcS1mkFEfRD3U/cP2JqwMLsnPU0+je7wwsTgnKNplFryWHP1WUHsCrah3UkPj10QgFsQg93qHXPaafY2/jyCt14XjQzPn1qPTdMB2Rq4aUKEBnzkqbFeKivYEDFOt6w4bzL8iLHxkuQl+mogSHw=; X-YMail-OSG: 17CsEk4VM1nrYt1Gv1YBK1bhhKpptIu6q55emlaFmpMfg3T UV0znepws8K5W3m.J9S_UwguMC0DRxuTEm889Xv_3Qy5Vokj6j8pZpDWVFfh RSSRUMvFzySS3vhpwV.gSPxLSLprVleVq1uCzzFGDH6diIe0_oNWKdq0elQ2 qxsQQHj1ECZ3IGJt1hdejbJWTPpXazB32msFcfZs5OLjercv5M_fw.K.m_nO 0D7fu_GBzlWN39v7uK4nWXZPLhTWRbtBijn8OrMDoDRMXmeawj3Y1VKguTRx NcAvOl_75ku_CEg9uhRSmsc2oOXGsImT0rynHpFTha49Yuxu3yodOcxETAiu 76aijgn4JvQCVUg25kV6v78.mPvzHM8mM6zq1t6UZ_.0yz4lPTs.fOBMqE6f VbMnGNTxaMgBa5vBbZZW6HnOSFuqJ5I9iBsjsLYGH.jj86ThtKUwYoKfdtve Et_xWudg2gUXmI5VRxt7VKFppq2.09P53tp3adlvYuMnNcv9yUdH8A0WUjov jlA-- Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 10:53:43 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> Message-ID: <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 10:53:43 -0700 (PDT) From: William Mills To: Dick Hardt In-Reply-To: <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1253285153-1344534823=:39489" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:53:49 -0000 ---368338466-1253285153-1344534823=:39489 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MAC fixes the signing problems encountered in OAuth 1.0a, yes there are lib= raries out there for OAuth 1.0a. =A0MAC fits in to the OAuth 2 auth model a= nd will provide for a single codepath for sites that want to use both Beare= r and MAC.=0A=0A=0A________________________________=0A From: Dick Hardt =0ATo: William Mills =0ACc: "oa= uth@ietf.org" =0ASent: Thursday, August 9, 2012 10:27 AM= =0ASubject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A = =0A=0A=0A=0AOn Aug 9, 2012, at 9:52 AM, William Mills wrote:=0A=0AI find th= e idea of starting from scratch frustrating. =A0MAC solves a set of specifi= c problems and has a well defined use case. =A0It's symmetric key based whi= ch doesn't work for some folks, and the question is do we try to develop so= mething that supports both PK and SK, or finish the SK use case and then wo= rk on a PK based draft.=0A>=0A>=0A>I think it's better to leave them separa= te and finish out MAC which is *VERY CLOSE* to being done.=0A=0AWho is inte= rested in MAC? People can use OAuth 1.0 if they prefer that model.=A0=0A=0A= For my projects, I prefer the flexibility of a signed or encrypted JWT if I= need holder of key.=0A=0AJust my $.02=0A=0A-- Dick =A0 ---368338466-1253285153-1344534823=:39489 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
MAC fixes the sign= ing problems encountered in OAuth 1.0a, yes there are libraries out there f= or 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.hardt@gmail.com>
= To: William Mills <wmil= ls_92105@yahoo.com>
Cc:= "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 9, 2012 10:27 AM
Subject: Re: [OAUTH-WG] mistake in dra= ft-ietf-oauth-v2-http-mac-01

=0A

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 specif= ic 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 develo= p something that supports both PK and SK, or finish the SK use case and the= n work on a PK based draft.

I think it's better to leave them separate and f= inish out=0A MAC which is *VERY CLOSE* to being done.

Who is interested in MAC? People can use OAu= th 1.0 if they prefer that model. 

For my pro= jects, I prefer the flexibility of a signed or encrypted JWT if I need hold= er of key.

Just my $.02

-= - Dick  



---368338466-1253285153-1344534823=:39489-- From herestomwiththeweather@gmail.com Thu Aug 9 10:58:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F317921F8646 for ; Thu, 9 Aug 2012 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 242DwYB1Ipet for ; Thu, 9 Aug 2012 10:58:20 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 94C3D21F85AD for ; Thu, 9 Aug 2012 10:58:19 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so471076wib.13 for ; Thu, 09 Aug 2012 10:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JX0WMzyVVDIIiYo7648J0rwW64wT0NKVsSjfxn8RUjA=; b=Y8RAKJTY123pRhe2T5JpELgxkgTjGpCBbZQc54PrigrQjbZAWK06+MxLWAJzRyQGGH CYuv/Kag1MfMQpnDiHhU3o/wiNB7ermXUgpWemF9ttnK51KVrUwtJ5eys+9GAvEVAGLS wLe2kx5tn4Ps8o8zN0yUkNx7MMiN0iGY2ezdmYoMoMtvf/Amk2qp7ZplmqGwGAtg5mqr Q/2ghwbDnuZNwyfz2dYg7Fr5m+pBhNM4WA77GoLoKnjMOXg592PZ312nFyIa+uBg+jqE T8U+Nu7mKZMm8si9vIZt7fbDwva8naMjjC3uRgjKjaLVDdN4r2ORol/xO/qaRXs9yXbB vq3A== Received: by 10.216.101.72 with SMTP id a50mr22167weg.210.1344535098639; Thu, 09 Aug 2012 10:58:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.82 with HTTP; Thu, 9 Aug 2012 10:57:58 -0700 (PDT) In-Reply-To: <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> From: Tom Brown Date: Thu, 9 Aug 2012 12:57:58 -0500 Message-ID: To: William Mills Content-Type: multipart/alternative; boundary=e0cb4e6ffe4bf1464b04c6d8f819 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:58:21 -0000 --e0cb4e6ffe4bf1464b04c6d8f819 Content-Type: text/plain; charset=ISO-8859-1 also, the oauth 2 abstract says the following so it seems confusing that oauth 1 is the proposed solution for mac: This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849 . On Thu, Aug 9, 2012 at 12: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 > *To:* William Mills > *Cc:* "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 > > --e0cb4e6ffe4bf1464b04c6d8f819 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable also, the oauth 2 abstract says the following so it seems confusing that oa= uth 1 is the proposed solution for mac:

This
   specification replaces and obsoletes the OAuth 1.0 protocol described
   in RFC 5849.

On Thu, Aug 9, 2012 at 12:53 PM, William Mi= lls <wmills_92105@yahoo.com> wrote:
MAC fixes the signing p= roblems encountered in OAuth 1.0a, yes there are libraries out there for OA= uth 1.0a. =A0MAC fits in to the OAuth 2 auth model and will provide for a s= ingle codepath for sites that want to use both Bearer and MAC.

=
From: Dick Hardt <dick.hardt@gmail.com><= br> To: William Mills <wmills_92105@yahoo.c= om>
Cc: "oauth@ietf.org" &= lt;oauth@ietf.org&g= t;
Sent: Thursday, August 9, 2= 012 10:27 AM

Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-ma= c-01


On Aug 9, 2012, at 9:52 AM, William Mills wrote:
I find the idea of starting from scratch frustrating= . =A0MAC solves a set of specific problems and has a well defined use case.= =A0It'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 S= K, or finish the SK use case and then work on a PK based draft.

<= div style=3D"font-style:normal;font-size:16px;background-color:transparent;= font-family:times,serif"> I think it's better to leave them separa= te and finish out MAC which is *VERY CLOSE* to being done.

Who is interested in MAC? People can use OAuth 1.0 if th= ey prefer that model.=A0

For my projects, I prefer= the flexibility of a signed or encrypted JWT if I need holder of key.

Just my $.02

-- Dick =A0
=



_______= ________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--e0cb4e6ffe4bf1464b04c6d8f819-- From ve7jtb@ve7jtb.com Thu Aug 9 11:25:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CED921F86C5 for ; Thu, 9 Aug 2012 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp2L7ZzexCnF for ; Thu, 9 Aug 2012 11:25:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2FB21F86AD for ; Thu, 9 Aug 2012 11:25:16 -0700 (PDT) Received: by yenm5 with SMTP id m5so852668yen.31 for ; Thu, 09 Aug 2012 11:25:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=D/giJWBY6pWC3e/+8PRTMh82zGBnRtzZ7xvd/Bo/dxo=; b=PZV6rr0vtTcTf3A2mRY76EDsa25OFSDC4ZumbO2gFMC8uYvToNd4z452Nj+k2M22p1 JwjRH3zoZ2np3gncIdcfHXjQAAzg2OVmL/dfOiUhZXqvbRWUjcIpEynufMFuhw9Dl6+f GHyb+t3GtJxvKDAJ5io587e3AKSC5M/0Dm1TewkaPikBCW98M+HyCTVhPpj0FiuRLhNp 6FuHU95/YSyOnNq0x1VWsXdCb+Omzt1+P1XDFMoD/JmSsctf0tQtRm3I+HHphsl6v8q8 /k/1q2iA/hyrKGxSJ0FwyM6RG6YEN2XunlZS+kBIWpJVFci6dtbLtMIp+vsLHgT2+rT9 eMbw== Received: by 10.236.193.105 with SMTP id j69mr297877yhn.21.1344536715976; Thu, 09 Aug 2012 11:25:15 -0700 (PDT) Received: from [192.168.1.211] (190-20-39-163.baf.movistar.cl. [190.20.39.163]) by mx.google.com with ESMTPS id e16sm1478405ani.22.2012.08.09.11.25.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 11:25:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_4998441C-A58A-46AB-85F2-B09047885F44"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 14:26:05 -0400 Message-Id: <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnDy+RXCIrz7LgPprXUwwpWwQCkBC0KBN3GkhO2/uU/QKvxyfx0ig4Uxu1PhyuFph4lzc2m Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:25:17 -0000 --Apple-Mail=_4998441C-A58A-46AB-85F2-B09047885F44 Content-Type: multipart/alternative; boundary="Apple-Mail=_036677DD-821E-4E8F-8F0A-08CA7688503D" --Apple-Mail=_036677DD-821E-4E8F-8F0A-08CA7688503D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. =20 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.=20 John B. =20 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. >=20 > From: Dick Hardt > To: William Mills =20 > Cc: "oauth@ietf.org" =20 > Sent: Thursday, August 9, 2012 10:27 AM > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >=20 >=20 > On Aug 9, 2012, at 9:52 AM, William Mills wrote: >=20 >> 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. >>=20 >> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >=20 > Who is interested in MAC? People can use OAuth 1.0 if they prefer that = model.=20 >=20 > For my projects, I prefer the flexibility of a signed or encrypted JWT = if I need holder of key. >=20 > Just my $.02 >=20 > -- Dick =20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_036677DD-821E-4E8F-8F0A-08CA7688503D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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.hardt@gmail.com>
= To: William Mills = <wmills_92105@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

= --Apple-Mail=_036677DD-821E-4E8F-8F0A-08CA7688503D-- --Apple-Mail=_4998441C-A58A-46AB-85F2-B09047885F44 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgw OTE4MjYwNVowIwYJKoZIhvcNAQkEMRYEFLrNU/QC0Yp77UPa9pIMM88Rh6VDMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AKc4KBGQ2K2AmzMvc9YXftOA4GCJxuIZRZu2BgCxLQN3FVQDcWlwRPCIEAlvNzH/+/JqmzM6/8Ay 9athwF/1pcu+8x+TNBcfb0mvTn5LHw4+sc5L7RqW6MkfVP93B2gs3VwIZYKOZF8g+9Ovq1RLzQry 9lMUKPleH86YvBiViVy3H1Asu8jlwEHBgQTsRom3mtlZT87AfDI+tT/ngUkaikZqktVnfERJ79Jq fUqjLIgVE2ORUbwR++8niZsObDkrDpfMGIULS4mx3pJ3x3U4EXQ24EKo9WesTSq/XvkK+M13wPQ8 TYj2++fLnmqASGI/6bRw8ml5kyf//5DyMMdA5u8AAAAAAAA= --Apple-Mail=_4998441C-A58A-46AB-85F2-B09047885F44-- From stephen.farrell@cs.tcd.ie Thu Aug 9 11:29:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED81221F86BA for ; Thu, 9 Aug 2012 11:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpY5RWpsrPZK for ; Thu, 9 Aug 2012 11:29:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BB89421F86B5 for ; Thu, 9 Aug 2012 11:29:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 65F471715B7; Thu, 9 Aug 2012 19:29:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1344536952; bh=sbSV3dlNGs2fYR 1EaVH/laq/JY5E+7FAFChcy3azKWw=; b=nYQ12p184xtXe83PMY4LU67m+E/7G5 N1vEe3bCqMvCGIpkLTJdwCq8BLp2MepzmDIT1iamnlHleoqLNEYQ/f59H3cPtTtL ss4L/r9EUVW3SvIDIHxcYcdWpqsLR8H1bzEaQRmfVglF5nWbwJbzMYJqA+2EDYfa BD2L7zm85x410o2G6Q0k3BWTgzPGyMhdNnm/OrgzFVyHTjryq+CaVFrXF57GXzAh itpHx7hawOnngQxWyqUgkuC1p610ZvkiKlLXFVJ2ML2RntmsbI3/0PqiFFujYFPq /jloW1QqE7KfBSkYS5VG/GsBOO8hRF4sM0qG83jNULVEE89qRWvWtS+g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Y0TZT8ogx8ea; Thu, 9 Aug 2012 19:29:12 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.11.118]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 555F41715B5; Thu, 9 Aug 2012 19:29:12 +0100 (IST) Message-ID: <50240177.6090606@cs.tcd.ie> Date: Thu, 09 Aug 2012 19:29:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: John Bradley References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> In-Reply-To: <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:29:17 -0000 On 08/09/2012 07:26 PM, John Bradley wrote: > 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. Just to clarify: I don't care if its documented in an I-D, a tune you whistle, or a bunch of emails. I do agree with what Hannes was saying in Vancouver: that the WG need to figure out what you want and document that however the chairs figure is best. S > 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 >> To: William Mills >> Cc: "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 > From prateek.mishra@oracle.com Thu Aug 9 11:29:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D7721F86B5 for ; Thu, 9 Aug 2012 11:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U575KkbUGAg5 for ; Thu, 9 Aug 2012 11:29:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9217221F871E for ; Thu, 9 Aug 2012 11:29:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79ITfXW021602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Aug 2012 18:29:42 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79ITft8014428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Aug 2012 18:29:41 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79ITeMk003169 for ; Thu, 9 Aug 2012 13:29:40 -0500 Received: from [10.152.55.167] (/10.152.55.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 11:29:40 -0700 Message-ID: <5024018B.2040907@oracle.com> Date: Thu, 09 Aug 2012 14:29:31 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: oauth@ietf.org References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> In-Reply-To: <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> Content-Type: multipart/alternative; boundary="------------060809020500000202060507" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:29:44 -0000 This is a multi-part message in MIME format. --------------060809020500000202060507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 finishing a draft for historical reasons without the full context of HoK use-cases and identified threats concerns me > 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 > >> *To:* William Mills > > >> *Cc:* "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 --------------060809020500000202060507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

finishing a draft for historical reasons without the full context of HoK use-cases and identified threats concerns me

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.hardt@gmail.com>
To: William Mills <wmills_92105@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

--------------060809020500000202060507-- From wmills_92105@yahoo.com Thu Aug 9 11:43:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48E21F877C for ; Thu, 9 Aug 2012 11:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHr-1hFyMMLl for ; Thu, 9 Aug 2012 11:43:41 -0700 (PDT) Received: from nm1-vm0.bullet.mail.ac4.yahoo.com (nm1-vm0.bullet.mail.ac4.yahoo.com [98.139.53.202]) by ietfa.amsl.com (Postfix) with SMTP id 25A2621F878E for ; Thu, 9 Aug 2012 11:43:41 -0700 (PDT) Received: from [98.139.52.191] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 18:43:40 -0000 Received: from [98.139.52.136] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 18:43:40 -0000 Received: from [127.0.0.1] by omp1019.mail.ac4.yahoo.com with NNFMP; 09 Aug 2012 18:43:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 645537.97568.bm@omp1019.mail.ac4.yahoo.com Received: (qmail 49866 invoked by uid 60001); 9 Aug 2012 18:43:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344537819; bh=PFiq4aPIsQP8H1V0Vahb2fJA5aQ441wuMZAWrdOyHLQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nB7IvMG3yihdEBInz1gQfmJp/f/wI9u/cWyD2SCFDKg1Xpsr8YZnGhfLPJTloawZlcilETAXisv14tDcXG3A/sDHSJQKLCBEsShDtbXmowPBOOEWgMzsUrdylcwYz4rOE4NoDgAiuavwD8YTIAJ/itxyj6quhJNRqVuOUWH4Jx8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Drk5/RB8nl+nbx++gSk1yNAM3w7/llPelQoahWF+WoWIKElGOD12XYjX3+oAKBNuNx87oX463Jg8Qz1JwE+y2TnJ8Mx6JuiC6ecdXr1MgKWshy+SnX7XlPEkz8bY7nmQb7uvQhhMEDPSFWtiqNR3Kkjb52NgcE5HYc29iRw/cBM=; X-YMail-OSG: DWzBPEYVM1nykX6hk5PV3Ic1r5RqvOv3NtZtW_kw7OEO0C2 t.TaPUOPIKHxUpSMyEiX35QIjL.YL6hDt0M9UgM7HCWgngiLcbFnd3Cy4DG6 CEju1Cx1w6_NRe_tLp7TqX8VE2yfo1eBALR1rsTrOno4i4wEQn41RoW21w9d EdWRakTaOxtJS5Vq70KaHdKtOIO5MxO1bIo_n0g24mvum.6SVLBRSnzQnR4x 493xjJs0ka8DoY0_pAwNcgvoKRTFCT8V_RglF2JA6u5RZMB7iNqJUE.oUucZ QbCHyrT4gmg6erD4bBJ4Att77VqGk7Bw8iWPAjczIE5hsB9twGXtPKppy4Bx jKBYcDozQwCd9Ws3EaPg3nVb7dKcfucvxNWoXMKoSVKMkmh3jhYsBMuozPhZ .ClJ.i3Bezu.d3BwM86Mzb_F5EAFj5RZW5sZrbVubzhGAt7SnLu_XoGhp8cQ RqEJV3ZEn0XR3VPXsyld4EPvJiUYDvX3guoS95PqLV.tuHtm.Md.0uacqQOj 8fcvTD8k_eiNTk1MzHL.I Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 11:43:39 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> Message-ID: <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 11:43:39 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1502656925-1355533442-1344537819=:41154" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:43:42 -0000 --1502656925-1355533442-1344537819=:41154 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, I'll play and start documenting the use cases. =A0=0A=0AUse case #1:=A0= Secure authentication in plain text connections:=0A=0ASome applications nee= d a secure form authorization, but do not want or need the overhead of encr= ypted connections. =A0HTTP cookies and their ilk are replayable credentials= and do not satisfy this need. =A0 the MAC scheme using signed HTTP authori= zation 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.=0A=0A-bill=0A=0A=0A____________________________= ____=0A From: John Bradley =0ATo: William Mills =0ACc: Dick Hardt ; "oauth@ietf.org"= =0ASent: Thursday, August 9, 2012 11:26 AM=0ASubject: Re:= [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A =0A=0AIn Vancouve= r the question was asked about the future of the MAC spec due to it no ling= er having a editor.=0A=0AThe Chair and AD indicated a desire to have a docu= ment on the use-cases we are trying to address before deciding on progressi= ng MAC or starting a new document.=0A=0APhil Hunt is going to put together = a summery of the Vancouver discussion and we are going to work on the use-c= ase/problem description document ASAP.=0A=0APeople are welcome to contribut= e to the use-case document.=0A=0APart of the problem with MAC has been that= people could never agree on what it was protecting against. =A0=0A=0AI thi= nk there is general agreement that one or more proof mechanisms are require= d for access tokens.=0ASecurity for the token endpoint also cannot be ignor= ed.=A0=0A=0A=0AJohn B.=0A=A0=0A=0AOn 2012-08-09, at 1:53 PM, William Mills = wrote:=0A=0AMAC fixes the signing problems encountered in OAuth 1.0a, yes t= here are libraries out there for OAuth 1.0a. =A0MAC fits in to the OAuth 2 = auth model and will provide for a single codepath for sites that want to us= e both Bearer and MAC.=0A>=0A>=0A>=0A>________________________________=0A> = From: Dick Hardt =0A>To: William Mills =0A>Cc: "oauth@ietf.org" =0A>Sent: Thursday, Au= gust 9, 2012 10:27 AM=0A>Subject: Re: [OAUTH-WG] mistake in draft-ietf-oaut= h-v2-http-mac-01=0A> =0A>=0A>=0A>=0A>On Aug 9, 2012, at 9:52 AM, William Mi= lls wrote:=0A>=0A>I find the idea of starting from scratch frustrating. =A0= MAC solves a set of specific problems and has a well defined use case. =A0I= t'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.=0A>>=0A>>=0A>>I think it= 's better to leave them separate and finish out MAC which is *VERY CLOSE* t= o being done.=0A>=0A>Who is interested in MAC? People can use OAuth 1.0 if = they prefer that model.=A0=0A>=0A>=0A>For my projects, I prefer the flexibi= lity of a signed or encrypted JWT if I need holder of key.=0A>=0A>=0A>Just = my $.02=0A>=0A>=0A>-- Dick =A0=0A>=0A>=0A>_________________________________= ______________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.= org/mailman/listinfo/oauth=0A> --1502656925-1355533442-1344537819=:41154 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, I'll play and = start documenting the use cases.  

=
Use case #1: Secure authentication in plain text connectio= ns:

Some app= lications need a secure form authorization, but do not want or need the ove= rhead of encrypted connections.  HTTP cookies and their ilk are replay= able credentials and do not satisfy this need.   the MAC scheme using = signed HTTP authorization credentials offer the capability to securely auth= orize a transaction, can offer integrity protection on all or part of an HT= TP request, and can provide replay protection.

-bill

<= div style=3D"font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; ">
From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>=
Cc: Dick Hardt <di= ck.hardt@gmail.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 9, 2012 1= 1:26 AM
Subject: Re: [= OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
=0A
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 starti= ng a new document.

Phil Hunt is going to put toget= her a summery of the Vancouver discussion and we are going to work on the u= se-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 wh= at it was protecting against.  

I think there= is general agreement that one or more proof mechanisms are required for ac= cess tokens.
Security for the token endpoint also cannot be ignor= ed. 


John B.
 
On 2012-08-09, at 1:53 PM, William Mills = wrote:

<= div style=3D"color: rgb(0, 0, 0); font-size: 12pt; font-family: times, seri= f; background-color: transparent; font-style: normal; ">
I think it's better to leave them separate and finish out=0A MAC which is *VERY CLOSE* = to being done.

Who is i= nterested in MAC? People can use OAuth 1.0 if they prefer that model. =

For my projects, I prefer the flexibility of a si= gned or encrypted JWT if I need holder of key.

Jus= t my $.02

-- Dick  


=
___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=


--1502656925-1355533442-1344537819=:41154-- From sberyozkin@gmail.com Thu Aug 9 12:22:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C2821F8763 for ; Thu, 9 Aug 2012 12:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49DL0uJ8fu2H for ; Thu, 9 Aug 2012 12:22:51 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3F21F875C for ; Thu, 9 Aug 2012 12:22:50 -0700 (PDT) Received: by bkty7 with SMTP id y7so363643bkt.31 for ; Thu, 09 Aug 2012 12:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9WYHl+jw2fAeHEGI76djIZ38KxOcPk4FhGqjCvOyWDY=; b=Hk2loNKs6WVorsFwQdL+X1eXVwVSoztlE9ni22y0sHOhE6ejTImWBv91Pc4xwaUsPe qm2TYnZWZK/F81p5fro+QUcfwxF0RtlYuisezvGpjSiXVMd9PwEv4603zfBR2fldBjgn J5MK5IAc40PZZLJ3Rl6p1yklJEF3Nvm9VDRoyxhfP6xFP3X03yYeAUXFYLaQIfyjdCzA G6yLwGI8YKxIjv0KcHbwzU0o/e8YVoD8ZYrGn1Dh5ej7L1BJGxQ3B2DdZyuIsEo3Pzk7 ixhH1xI5iJ1crfFyrSJ32pf8BD31GQ2MiqVcocMn4nolDRF2Yx7MgUuVx9Q1iES7UbkJ YuCg== Received: by 10.204.132.80 with SMTP id a16mr215203bkt.82.1344540169636; Thu, 09 Aug 2012 12:22:49 -0700 (PDT) Received: from [10.39.0.31] ([87.252.227.101]) by mx.google.com with ESMTPS id n17sm1121225bks.6.2012.08.09.12.22.48 (version=SSLv3 cipher=OTHER); Thu, 09 Aug 2012 12:22:49 -0700 (PDT) Message-ID: <50240E07.5060000@gmail.com> Date: Thu, 09 Aug 2012 22:22:47 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:22:56 -0000 On 09/08/12 20:53, 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 I work on the framework which already supports MAC (with major thanks to a user contribution). I'm not too worried that MAC draft may not end up being a final specification - because OAuth2.0 allows for different token types and whatever MAC already offers can be 'packaged' as a custom token if really needed, moreover, experienced users may help to fix whatever bugs that still remain in the draft; I'm very new to this list and effort, but I think I can get that it offers a (symmetric) holder-of-key support - and as such it's good for the framework because there will be users which will like working with MAC. Having said that, I'd really like to give some support to the idea of completing the draft - to minimize the proliferation of custom token types which may end up trying to solve the same problem > and will provide for a single codepath for sites that want to use > both Bearer and MAC. +1 Sergey > > ------------------------------------------------------------------------ > *From:* Dick Hardt > *To:* William Mills > *Cc:* "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 From jricher@mitre.org Thu Aug 9 12:38:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FF121F86A5 for ; Thu, 9 Aug 2012 12:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8ERaG0lzhJa for ; Thu, 9 Aug 2012 12:38:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 35B0B21F8659 for ; Thu, 9 Aug 2012 12:38:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9493821B0696 for ; Thu, 9 Aug 2012 15:38:26 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 79AC121B073D for ; Thu, 9 Aug 2012 15:38:26 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 9 Aug 2012 15:38:26 -0400 Message-ID: <50241165.40209@mitre.org> Date: Thu, 9 Aug 2012 15:37:09 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------000508030407000900070805" X-Originating-IP: [129.83.31.51] Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:38:29 -0000 --------------000508030407000900070805 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 > *To:* William Mills > *Cc:* Dick Hardt ; "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 > >> *To:* William Mills > > >> *Cc:* "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 --------------000508030407000900070805 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: Dick Hardt <dick.hardt@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.hardt@gmail.com>
To: William Mills <wmills_92105@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

--------------000508030407000900070805-- From dick.hardt@gmail.com Thu Aug 9 12:48:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FA921F8736 for ; Thu, 9 Aug 2012 12:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrz1+9uX4Srv for ; Thu, 9 Aug 2012 12:48:21 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEE21F8669 for ; Thu, 9 Aug 2012 12:48:21 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1397771pbb.31 for ; Thu, 09 Aug 2012 12:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=k87/vD+Q0ZxPt/kWd7u8+jv3r3wddLhKghoth8LECk0=; b=XJIDDBqVpMnP2ouNay3ASUsoft2YHdGde+wrhRoSUm7kMtf/5KCZM5w+8A919grzmA ukZ+BFzbRHXsypkzCIXDWRIM9iikAqUuWHbLuvzNurACuaf9zyLXjfPN965kqgokLv1b YDwCBbASLDUbcPRQM82WJO+NkN7MzBi4/KF85RbGSt+kgf3lkPhswv1hBAfMLOlx2h5t c5XYAQ5drQ6mP24AEkZOZsTQudVNyNGmP0o8q+Zgctybu6rCRwRnINBpN8H97iPImKB5 i7lrvQzrriRWUlQIpvzFUmKT+vqpccPWBqW7xiBCpPvxvJFAbpn6FNfju9HcHhIcuDiM ZMiw== Received: by 10.68.136.138 with SMTP id qa10mr152385pbb.103.1344541701258; Thu, 09 Aug 2012 12:48:21 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hr9sm1709022pbc.36.2012.08.09.12.48.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 12:48:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_FBE3C65B-D9FA-4FA1-8A7C-459AEED04CB6" From: Dick Hardt In-Reply-To: <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 12:48:11 -0700 Message-Id: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:48:22 -0000 --Apple-Mail=_FBE3C65B-D9FA-4FA1-8A7C-459AEED04CB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. >=20 > From: Dick Hardt > To: William Mills =20 > Cc: "oauth@ietf.org" =20 > Sent: Thursday, August 9, 2012 10:27 Aa > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >=20 >=20 > On Aug 9, 2012, at 9:52 AM, William Mills wrote: >=20 >> 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. >>=20 >> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >=20 > Who is interested in MAC? People can use OAuth 1.0 if they prefer that = model.=20 >=20 > For my projects, I prefer the flexibility of a signed or encrypted JWT = if I need holder of key. >=20 > Just my $.02 >=20 > -- Dick =20 >=20 >=20 >=20 --Apple-Mail=_FBE3C65B-D9FA-4FA1-8A7C-459AEED04CB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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.hardt@gmail.com>
= To: William Mills = <wmills_92105@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  



=

= --Apple-Mail=_FBE3C65B-D9FA-4FA1-8A7C-459AEED04CB6-- From jricher@mitre.org Thu Aug 9 13:09:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8B821F872E for ; Thu, 9 Aug 2012 13:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hiOWwCJ52dJ for ; Thu, 9 Aug 2012 13:09:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 00BA621F8733 for ; Thu, 9 Aug 2012 13:09:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40C9F21B07C1; Thu, 9 Aug 2012 16:09:52 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1C38921B0748; Thu, 9 Aug 2012 16:09:52 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 9 Aug 2012 16:09:51 -0400 Message-ID: <502418C3.5080402@mitre.org> Date: Thu, 9 Aug 2012 16:08:35 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dick Hardt References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010103060907060505060009" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:09:58 -0000 --------------010103060907060505060009 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below. I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so many beautiful snowflakes. -- Justin On 08/09/2012 03:48 PM, Dick Hardt wrote: > 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 > >> *To:* William Mills > > >> *Cc:* "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 --------------010103060907060505060009 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below.

I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so many beautiful snowflakes.

 -- Justin

On 08/09/2012 03:48 PM, Dick Hardt wrote:
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.hardt@gmail.com>
To: William Mills <wmills_92105@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

--------------010103060907060505060009-- From gffletch@aol.com Thu Aug 9 13:32:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6E21F86DE for ; Thu, 9 Aug 2012 13:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZovyftmNXNQ for ; Thu, 9 Aug 2012 13:32:17 -0700 (PDT) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50D21F86D8 for ; Thu, 9 Aug 2012 13:32:17 -0700 (PDT) Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id q79KWAom030853; Thu, 9 Aug 2012 16:32:11 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 9E0BAE0000E9; Thu, 9 Aug 2012 16:32:10 -0400 (EDT) Message-ID: <50241E4A.1080500@aol.com> Date: Thu, 09 Aug 2012 16:32:10 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: oauth@ietf.org References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> In-Reply-To: <50241165.40209@mitre.org> Content-Type: multipart/alternative; boundary="------------010105030503090505070402" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1344544330; bh=Igh3IlaOKcfkC/jYayOWfldJo2+2xYg1KQVTWKr8xhA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ihsO9+2c17rUjajMeWjABEADoGL/VLs9XfRkayoIS62oL4w7kjIuvMAs0SNDit5eU Y0q++kOnHXSYNXiNnkni+TaSTN33iBUKm//XZEJ+8r+EG+Q0kJD1MqJM/Y9qvRLGw+ Z8UGpvOtw4zMfM9H06KXODiIu36g0qStNBqDT6ck= X-AOL-SCOLL-SCORE: 0:2:460862080:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c650241e4a65d1 X-AOL-IP: 10.181.186.254 Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:32:19 -0000 This is a multi-part message in MIME format. --------------010105030503090505070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 We've supported #3 for quite some time in our public APIs that pre-date OAuth. Thanks, George On 8/9/12 3:37 PM, Justin Richer 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 >> *To:* William Mills >> *Cc:* Dick Hardt ; "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 > >>> *To:* William Mills >> > >>> *Cc:* "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 --------------010105030503090505070402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

We've supported #3 for quite some time in our public APIs that pre-date OAuth.

Thanks,
George
On 8/9/12 3:37 PM, Justin Richer 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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: Dick Hardt <dick.hardt@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.hardt@gmail.com>
To: William Mills <wmills_92105@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

--------------010105030503090505070402-- From wmills_92105@yahoo.com Thu Aug 9 13:47:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898EC21F8678 for ; Thu, 9 Aug 2012 13:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x36lN6J2DCrl for ; Thu, 9 Aug 2012 13:47:37 -0700 (PDT) Received: from nm31-vm6.bullet.mail.ne1.yahoo.com (nm31-vm6.bullet.mail.ne1.yahoo.com [98.138.229.46]) by ietfa.amsl.com (Postfix) with SMTP id B617721F8670 for ; Thu, 9 Aug 2012 13:47:37 -0700 (PDT) Received: from [98.138.90.52] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 20:47:32 -0000 Received: from [98.138.88.234] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 20:47:32 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 09 Aug 2012 20:47:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 333258.67451.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 44245 invoked by uid 60001); 9 Aug 2012 20:47:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344545251; bh=AhkZlgX2vZf1eVZ7qBx70GllnlNSYD/n9dJl/7QoixY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xYocGMd8FXuz6zCUgyj6diqzjyovSpXdPSxgioV6O+CHCLFrVW4UEdRmtfjLTA/TiHbma7Uyq/xrYJGRS7I2AEuiUFMeI2L/t6KTOCEn7vdD4fEpYYGvwTGd/nxxK4Pwjyb07eevTtBF227eyeGkoL7mfLRAlxznfviUy/ZV2OI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0f2oXPwHAAVl0vBxIUfyVT8Th2j2/xKz0JxQ147OzXLz6Q0Jk7WoOgpPMThdTi5mHFde0Dv58d9UPqO2bRtJNi2PH4Im74l99pmvY4ojWJqgv2D4HUj1TYriEcoEDoy7pZ/7dwCwoCx9KjTHoLL4uJXo0BdTXT1cHagMiilhLTo=; X-YMail-OSG: wjJpEpQVM1ka6JuDmh52NDfa88g9ljVXuGUHS3m6Tj2RZme ILC94q4q0hPgRRykgy8YbrVuEXDZS5rKfAhHXOxWm8EWGzr4Olg40g_GanQA WIT44uvPPbmlEuz71x9QpyVOR0_x6qPcZ8UerI0_d1rxX.bxHdeOO3G6NqS7 hFiwiEpysO6TKPgm7alR_RU00XnC08Dv1xQJDQkji3EDOTkWnrLIZKRrc_lF LEd4dAZpETEXHk6jxbj3v8E1hMaUhiTollyCQbsKQVmjMkmMQpgHlUIbstLV z.r8bvCBk_a_bSqYlPXrhoESJLt3qZT.aPmjN93CqsASd_sQVYVK9it04Z2j zwaq6k3P8i2Canuf0EFIgpgtHLLahlBQejs8iHFwPzoIJQaiclNsk970x4i9 W2o9gaP6KtMQvU6oVoQWLN2SNnGVpD39iSnI.65O3e7FtMsLz5QuTP8ka3VS z9ioJBX15oqbLd8nlf52VePz1.xzZln8HZf6LzIF32hacs80R_wEVn8PfjCG OyQ-- Received: from [209.131.62.113] by web31801.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 13:47:30 PDT X-Mailer: YahooMailWebService/0.8.120.356233 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> Message-ID: <1344545250.38511.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 13:47:30 -0700 (PDT) From: William Mills To: Dick Hardt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-368338466-1763934022-1344545250=:38511" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 20:47:38 -0000 ---368338466-1763934022-1344545250=:38511 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mostly it's around making sure you get the signature base string constructe= d right in my experience.=0A=0A=0A________________________________=0A From:= Dick Hardt =0ATo: William Mills =0ACc: Dick Hardt ; "oauth@ietf.org" =0ASent: Thursday, August 9, 2012 12:48 PM=0ASubject: Re: [OAUTH-WG] = mistake in draft-ietf-oauth-v2-http-mac-01=0A =0A=0AAs an implementer, I ha= ve an app that accesses 10 different resources. Some are OAuth 1.0A, some a= re 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 O= Auth 2. Supporting MAC would give me yet another library to integrate with.= =0A=0AI'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.=0A=0A=0A=0AOn Aug 9, 2012, a= t 10:53 AM, William Mills wrote:=0A=0AMAC fixes the signing problems encoun= tered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. =A0M= AC 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.=0A>=0A>=0A>=0A>___________= _____________________=0A> From: Dick Hardt =0A>To: Wi= lliam Mills =0A>Cc: "oauth@ietf.org" =0A>Sent: Thursday, August 9, 2012 10:27 Aa=0A>Subject: Re: [OAUTH-WG] = mistake in draft-ietf-oauth-v2-http-mac-01=0A> =0A>=0A>=0A>=0A>On Aug 9, 20= 12, at 9:52 AM, William Mills wrote:=0A>=0A>I find the idea of starting fro= m scratch frustrating. =A0MAC solves a set of specific problems and has a w= ell defined use case. =A0It's symmetric key based which doesn't work for so= me 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= .=0A>>=0A>>=0A>>I think it's better to leave them separate and finish out M= AC which is *VERY CLOSE* to being done.=0A>=0A>Who is interested in MAC? Pe= ople can use OAuth 1.0 if they prefer that model.=A0=0A>=0A>=0A>For my proj= ects, I prefer the flexibility of a signed or encrypted JWT if I need holde= r of key.=0A>=0A>=0A>Just my $.02=0A>=0A>=0A>-- Dick =A0=0A>=0A>=0A> ---368338466-1763934022-1344545250=:38511 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Mostly it's around= making sure you get the signature base string constructed right in my expe= rience.

From: Dick Hardt <dick.hardt@gmail.= com>
To: William Mi= lls <wmills_92105@yahoo.com>
Sent: Thursday, August 9, 2012 12:48 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-h= ttp-mac-01

=0A
As an im= plementer, I have an app that accesses 10 different resources. Some are OAu= th 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 proble= ms 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 encoun= tered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a. &nbs= p;MAC fits in to the OAuth 2 auth model and will provide for a single codep= ath for sites that want to use both Bearer and MAC.


=0A

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 symmet= ric 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=0A MAC which is *VERY CLOSE* = to being done.

Who is i= nterested in MAC? People can use OAuth 1.0 if they prefer that model. =

For my projects, I prefer the flexibility of a si= gned or encrypted JWT if I need holder of key.

Jus= t my $.02

-- Dick  


=



---368338466-1763934022-1344545250=:38511-- From dick.hardt@gmail.com Thu Aug 9 15:40:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4379221F86C1 for ; Thu, 9 Aug 2012 15:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5S3NuD4dIA9 for ; Thu, 9 Aug 2012 15:40:02 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3699321F86B8 for ; Thu, 9 Aug 2012 15:40:02 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1599456pbb.31 for ; Thu, 09 Aug 2012 15:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=WR7l9yOj81hxCJnMtcBqQW9bXYZJGmqejg8GqTBqRs8=; b=X6f8/z3aBUkHPj9T5+xxasG2uJseSstEsJrLE0mCGMqqwXaqYeyVmAXesHWMlhbspf HlRLGVX2rwbuXJEcl0muvRZzkICynYSM4A62HDwwVvj58LTXxletK0TlYEfkEiPRftjH +6P+ciTDj4wWiJGE6MXU/hWhVzAUtCymGubCd1USf6sgCfYnbi+kTvnaGm2qrLx7AjSK neo15107AeSCSHACFTf/NpMYcOc/Qi4oFjpX6vuzYV4jR1JEmsPzBHYGsLIl/emkA5Jw /0WtyHsk64CMTlr9ANvX2QJ83ZkzaRkx6+J533soHvjbnSm95zySm5d/XUXc5Ix//73M Qx8w== Received: by 10.68.227.70 with SMTP id ry6mr7476723pbc.53.1344551998350; Thu, 09 Aug 2012 15:39:58 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id vc5sm1953481pbc.2.2012.08.09.15.39.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 15:39:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_054B0802-F9E5-42C2-BF55-CBE7FB9D0E0E" From: Dick Hardt In-Reply-To: <1344545250.38511.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 15:39:50 -0700 Message-Id: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <1344545250.38511.YahooMailNeo@web31801.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:40:03 -0000 --Apple-Mail=_054B0802-F9E5-42C2-BF55-CBE7FB9D0E0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, sort of. I blew two days debugging my code accessing Twitter. We had intermittent failures. It would work for hours, and then fail for = hours. Eventually I noticed that we were calling http://api.twitter.com instead = of https://api.twitter.com. Once we changed that it worked fine.=20 On Aug 9, 2012, at 1:47 PM, William Mills wrote: > Mostly it's around making sure you get the signature base string = constructed right in my experience. >=20 > From: Dick Hardt > To: William Mills =20 > Cc: Dick Hardt ; "oauth@ietf.org" = =20 > Sent: Thursday, August 9, 2012 12:48 PM > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >=20 > 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. >=20 > 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. >=20 > On Aug 9, 2012, at 10:53 AM, William Mills wrote: >=20 >> 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. >>=20 >> From: Dick Hardt >> To: William Mills =20 >> Cc: "oauth@ietf.org" =20 >> Sent: Thursday, August 9, 2012 10:27 Aa >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>=20 >>=20 >> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>=20 >>> 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. >>>=20 >>> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >>=20 >> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>=20 >> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>=20 >> Just my $.02 >>=20 >> -- Dick =20 >>=20 >>=20 >>=20 >=20 >=20 >=20 --Apple-Mail=_054B0802-F9E5-42C2-BF55-CBE7FB9D0E0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Yes, = sort of.

I blew two days debugging my code accessing = Twitter.

We had intermittent failures. It would work = for hours, and then fail for hours.


On Aug = 9, 2012, at 1:47 PM, William Mills wrote:

Mostly it's around making = sure you get the signature base string constructed right in my = experience.

=
From: = Dick Hardt <dick.hardt@gmail.com>
= To: William Mills = <wmills_92105@yahoo.com> =
Cc: Dick Hardt = <dick.hardt@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.hardt@gmail.com>
= To: William Mills <wmills_92105@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  



=



=
=

= --Apple-Mail=_054B0802-F9E5-42C2-BF55-CBE7FB9D0E0E-- From dick.hardt@gmail.com Thu Aug 9 15:47:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26721F86F6 for ; Thu, 9 Aug 2012 15:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXPMHZ5h9VBx for ; Thu, 9 Aug 2012 15:47:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3DA21F86DF for ; Thu, 9 Aug 2012 15:47:43 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1608932pbb.31 for ; Thu, 09 Aug 2012 15:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=28WI0erFbwi+UX36n3DfF5T865TQ/VVDwYElbbV9P68=; b=d7OmHokgOQ7/6dL3Jmi3e5CE/fds+sJFE+7qndW7/b5iQQILOPgVjPP7/NWnRLOSA2 1gizVgW+37J39RmIVEa07RvtrHgecJlIiH9Qzdfgi75UtZ5BSwpJ5e2EiSyrQA6+8rGf YBvJFOnKrlhxXKyXWQ5vBi9VfqO4VPEhXkGrTd/94MLZkXzaZ+N9gcRCCcJ9mVoHLdh3 fx1Y9pHdb+wV+5SYXGO3FDK7/fTRfmA+J29NtaKuocR6KY1MC2oJj6PDw51oxKQGFkZF 7OipL8udAsRSNMzmaxFtrITahR80AbrdQmAHFqPbaYYJlh65ZzRr2g5wyC6ohU/5el9C FYiQ== Received: by 10.66.89.234 with SMTP id br10mr1763084pab.25.1344552462745; Thu, 09 Aug 2012 15:47:42 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id iq1sm1956487pbc.37.2012.08.09.15.47.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 15:47:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6FC9B446-AC49-4B4A-BE87-50099A531CE1" From: Dick Hardt In-Reply-To: <502418C3.5080402@mitre.org> Date: Thu, 9 Aug 2012 15:47:36 -0700 Message-Id: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <502418C3.5080402@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 22:47:44 -0000 --Apple-Mail=_6FC9B446-AC49-4B4A-BE87-50099A531CE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 9, 2012, at 1:08 PM, Justin Richer wrote: > With MAC, you should be able to re-use about 80-90% of your existing = codepath that's in place for Bearer, simplifying the setup below.=20 That makes no sense, I would be adding MAC to the sites that support MAC = in addition to OAuth 1.0A or OAuth 2.0 >=20 > I would figure that the "variant of OAuth2" issue is a red herring = because not everyone out there is fully spec compliant. If they were, = you wouldn't have so many beautiful snowflakes. Being consistent in the spec would help, but likely would just give me = snowflakes that look more like each other. There are many aspects of the OAuth dance that are implementation = dependent and it is simpler to just have a separate method for each one = that deals with those unique characteristics. Note this is not theory, = this is practice. Different modules was not an issue. Not having to use = a library to sign requests and being able to use CURL or a browser to = see what a request returned had a HUGE productivity gain for OAuth 2.0 = implementations over OAuth 1.0A implemetations.=20 >=20 > -- Justin >=20 > On 08/09/2012 03:48 PM, Dick Hardt wrote: >> 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. >>=20 >> 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. >>=20 >> On Aug 9, 2012, at 10:53 AM, William Mills wrote: >>=20 >>> 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. >>>=20 >>> From: Dick Hardt >>> To: William Mills =20 >>> Cc: "oauth@ietf.org" =20 >>> Sent: Thursday, August 9, 2012 10:27 Aa >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>=20 >>>=20 >>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>=20 >>>> 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. >>>>=20 >>>> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >>>=20 >>> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>>=20 >>> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>>=20 >>> Just my $.02 >>>=20 >>> -- Dick =20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_6FC9B446-AC49-4B4A-BE87-50099A531CE1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:

With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below.

That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAuth 2.0


I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so many beautiful snowflakes.


Being consistent in the spec would help, but likely would just give me snowflakes that look more like each other.

There are many aspects of the OAuth dance that are implementation dependent and it is simpler to just have a separate method for each one that deals with those unique characteristics. Note this is not theory, this is practice. Different modules was not an issue. Not having to use a library to sign requests and being able to use CURL or a browser to see what a request returned had a HUGE productivity gain for OAuth 2.0 implementations over OAuth 1.0A implemetations. 


 -- Justin

On 08/09/2012 03:48 PM, Dick Hardt wrote:
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.hardt@gmail.com>
To: William Mills <wmills_92105@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


--Apple-Mail=_6FC9B446-AC49-4B4A-BE87-50099A531CE1-- From david@alkaline-solutions.com Thu Aug 9 16:02:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C952C21F8599 for ; Thu, 9 Aug 2012 16:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB6QaMAAud-0 for ; Thu, 9 Aug 2012 16:02:10 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2C22821F8598 for ; Thu, 9 Aug 2012 16:02:10 -0700 (PDT) Received: from [192.168.3.15] (c-71-196-188-115.hsd1.co.comcast.net [71.196.188.115]) by alkaline-solutions.com (Postfix) with ESMTPSA id 0AA5B3155C for ; Thu, 9 Aug 2012 23:05:04 +0000 (UTC) From: David Waite Content-Type: multipart/alternative; boundary="Apple-Mail=_A3C95DF8-7F3A-4F75-9473-973F1DDEAB0E" Message-Id: <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Date: Thu, 9 Aug 2012 17:02:06 -0600 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> To: oauth@ietf.org In-Reply-To: <50241165.40209@mitre.org> X-Mailer: Apple Mail (2.1485) Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:02:11 -0000 --Apple-Mail=_A3C95DF8-7F3A-4F75-9473-973F1DDEAB0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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 wrote: > Use case #2: signature protection over plain HTTP parameters >=20 > 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. >=20 >=20 > Use case #3: generic signed HTTP fetch (not directly addressed by MAC = spec as of today) >=20 > 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. >=20 >=20 > -- Justin >=20 > On 08/09/2012 02:43 PM, William Mills wrote: >> OK, I'll play and start documenting the use cases. =20 >>=20 >> Use case #1: Secure authentication in plain text connections: >>=20 >> 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. >>=20 >> -bill >>=20 >> From: John Bradley >> To: William Mills =20 >> Cc: Dick Hardt ; "oauth@ietf.org" = =20 >> Sent: Thursday, August 9, 2012 11:26 AM >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>=20 >> In Vancouver the question was asked about the future of the MAC spec = due to it no linger having a editor. >>=20 >> 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. >>=20 >> 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. >>=20 >> People are welcome to contribute to the use-case document. >>=20 >> Part of the problem with MAC has been that people could never agree = on what it was protecting against. =20 >>=20 >> 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.=20 >>=20 >>=20 >> John B. >> =20 >> On 2012-08-09, at 1:53 PM, William Mills wrote: >>=20 >>> 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. >>>=20 >>> From: Dick Hardt >>> To: William Mills =20 >>> Cc: "oauth@ietf.org" =20 >>> Sent: Thursday, August 9, 2012 10:27 AM >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>=20 >>>=20 >>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>=20 >>>> 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. >>>>=20 >>>> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >>>=20 >>> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>>=20 >>> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>>=20 >>> Just my $.02 >>>=20 >>> -- Dick =20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A3C95DF8-7F3A-4F75-9473-973F1DDEAB0E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
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 <jricher@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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: Dick Hardt <dick.hardt@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.hardt@gmail.com>
To: William Mills <wmills_92105@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

--Apple-Mail=_A3C95DF8-7F3A-4F75-9473-973F1DDEAB0E-- From wmills_92105@yahoo.com Thu Aug 9 16:19:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1055A21F861C for ; Thu, 9 Aug 2012 16:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAaTuR0k9-gS for ; Thu, 9 Aug 2012 16:19:53 -0700 (PDT) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9070011E808E for ; Thu, 9 Aug 2012 16:19:53 -0700 (PDT) Received: from [72.30.22.77] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2012 23:19:51 -0000 Received: from [98.139.91.37] by tm11.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2012 23:19:51 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 09 Aug 2012 23:19:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 745377.16463.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 5331 invoked by uid 60001); 9 Aug 2012 23:19:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344554391; bh=VNT5Xl+mG1T3JmUiG7L6KB4T0bK+fnEpD95P9rbSIJE=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=oB4yx3GpOWdICyk/1oluj648ke5QNkB7giHtc0DA9JgctDtAGfaAJwE80MnfTcbUZDUZ64baP6CYHofpc3Pt1iRFBUZ6zLXP9tFlVnAFxmpfK1+IX9g+eVow/q7CWqCH0QHMmsNXsBxVNxyBgLw+QPpLMHJXYTvUYmi4emLelFI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IdI30riY2jNl/3jMTfV73f8TVhKoS5fBzcvJ+Z0LoRVnp2xRIzjxJ4bz5iR2jSUkwQ0pTQc7lxaTC05AbyEQT8s5NhQ7wtVVZ00WToRjzgnPMxn79NjJtTPF/X0S8Wy/6a8jy9mtKfAgVmO9pWhKnCrCIIsZargwqveQ7AF3Fbw=; X-YMail-OSG: B.9LuR4VM1l7gsWoJnZpMAW0vldOE7mDQoClm8tJUQBJ2BR 0ngOoZqHuvDbkySV0esu5GBow1jaQGggXRvvLvYJDPrna6zULCu_D677rC7j ZA2g4a0cvklxtmVuefHNKmwKXstFSWDV.cnKII.urOoLv67OeJZIS5hk3d80 F0sGE8bBvxINn6DrAeV5H97PbgxF3ni0ZcQsOVWLV44KbbFAIB_nsYNS3.RI o_jOoFHSw0_oE9rmhvW45C8kaBxdgipdoPYix9kSdUcZtfXn64h5IyXa1zbs d9XNKi0.xkbcRDwVlt4LqG3w8a4nV0a5x2YKa4ouOtDNPoNr8n85.PEwEToE tg4gL6FBSdo82fymrqnj5AeGUG0_CkoD7exn0hNWMQh88u.uHWW5wI9PSBBn lhAM3JjkEyQMvNr9w0CGib4HCkSr0fG3zhLz8aKy7vOL6vxicbtXk1lt6OXz CQUbZW0sUxYGWrBTnsr9MDo7.r9i6ZHDHMjHn4ZXoOzLtOPLNrc1dLz12ReQ 6eA-- Received: from [209.131.62.113] by web31811.mail.mud.yahoo.com via HTTP; Thu, 09 Aug 2012 16:19:51 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> Message-ID: <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 16:19:51 -0700 (PDT) From: William Mills To: David Waite , "oauth@ietf.org" In-Reply-To: <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-2106440992-1344554391=:70300" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 23:19:55 -0000 --764183289-2106440992-1344554391=:70300 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable AS would still be required to be HTTPS as per the spec.=0A=0A=0A___________= _____________________=0A From: David Waite = =0ATo: oauth@ietf.org =0ASent: Thursday, August 9, 2012 4:02 PM=0ASubject: = Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A =0A=0AFor #1:= =0ADoes the use of plain HTTP to talk to protected resources provide signif= icant 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 w= ith the AS?=0A=0AFor #2:=0AWould the signature protection just cover HTTP p= arameters, or would it extend to covering any request data, such as a PUT b= inary file?=A0Would the integrity protection only cover requests, or would = you also have integrity protection of the response?=0A=0A-DW=0A=0AOn Aug 9,= 2012, at 1:37 PM, Justin Richer wrote:=0A=0AUse case #= 2: signature protection over plain HTTP parameters=0A>=0A>MAC gives us mess= age-level signing in a way that doesn't require=0A all the parameters = to be packed into an extra structure, like=0A JWT/SAML do. TLS gives n= o application-layer verification of=0A integrity of parameters, nor do= es it give you the ability to know=0A who presented those parameters (= unless you're doing mutual TLS,=0A which nobody does). MAC gives you a= fairly simple way to protect=0A all parameters on a call to the resou= rce server while still=0A keeping all of those parameters in their nat= ive HTTP forms.=0A>=0A>=0A>Use case #3: generic signed HTTP fetch (not dire= ctly addressed by=0A MAC spec as of today)=0A>=0A>Sometimes you want t= o create a URL with one service, fix all of=0A the parameters in that = URL, and protect those parameters with a=0A signature. Then that URL c= an be passed to an untrusted service who=0A cannot modify any portion = of it. Nor can they re-use the signature=0A portion to protect differe= nt parameters. We do this today with a=0A 2-legged OAuth signature acr= oss a service URL. The "Client"=0A generates the signed URLs and passe= s them to a user agent which=0A actually does the fetch to the service= .=0A>=0A>=0A>=A0-- Justin=0A>=0A>On 08/09/2012 02:43 PM, William Mills wrot= e:=0A>=0A>OK, I'll play and start documenting the use cases. =A0=0A>>=0A>>= =0A>>Use case #1:=A0Secure authentication in plain text connections:=0A>>= =0A>>=0A>>Some applications need a secure form authorization, but do not wa= nt or need the overhead of encrypted connections. =A0HTTP cookies and their= ilk are replayable credentials and do not satisfy this need. =A0 the MAC s= cheme using signed HTTP authorization credentials offer the capability to s= ecurely authorize a transaction, can offer integrity protection on all or p= art of an HTTP request, and can provide replay protection.=0A>>=0A>>=0A>>-b= ill=0A>>=0A>>=0A>>=0A>>________________________________=0A>> From: John Bra= dley =0A>>To: William Mills =0A= >>Cc: Dick Hardt ; "oauth@ietf.org" = =0A>>Sent: Thursday, August 9, 2012 11:26 AM=0A>>Subject: Re: [OAUTH-WG] mi= stake in draft-ietf-oauth-v2-http-mac-01=0A>> =0A>>=0A>>In Vancouver the qu= estion was asked about the future of the MAC spec due to it no linger havin= g a editor. =0A>>=0A>>=0A>>The Chair and AD indicated a desire to have a do= cument on the use-cases we are trying to address before deciding on progres= sing MAC or starting a new document.=0A>>=0A>>=0A>>Phil Hunt is going to pu= t together a summery of the Vancouver discussion and we are going to work o= n the use-case/problem description document ASAP.=0A>>=0A>>=0A>>People are = welcome to contribute to the use-case document.=0A>>=0A>>=0A>>Part of the p= roblem with MAC has been that people could never agree on what it was prote= cting against. =A0=0A>>=0A>>=0A>>I think there is general agreement that on= e or more proof mechanisms are required for access tokens.=0A>>Security for= the token endpoint also cannot be ignored.=A0=0A>>=0A>>=0A>>=0A>>=0A>>John= B.=0A>>=A0=0A>>=0A>>On 2012-08-09, at 1:53 PM, William Mills wrote:=0A>>= =0A>>MAC fixes the signing problems encountered in OAuth 1.0a, yes there ar= e libraries out there for OAuth 1.0a. =A0MAC fits in to the OAuth 2 auth mo= del and will provide for a single codepath for sites that want to use both = Bearer and MAC.=0A>>>=0A>>>=0A>>>=0A>>>________________________________=0A>= >> From: Dick Hardt =0A>>>To: William Mills =0A>>>Cc: "oauth@ietf.org" =0A>>>Sent: Thu= rsday, August 9, 2012 10:27 AM=0A>>>Subject: Re: [OAUTH-WG] mistake in draf= t-ietf-oauth-v2-http-mac-01=0A>>> =0A>>>=0A>>>=0A>>>=0A>>>On Aug 9, 2012, a= t 9:52 AM, William Mills wrote:=0A>>>=0A>>>I find the idea of starting from= scratch frustrating. =A0MAC solves a set of specific problems and has a we= ll defined use case. =A0It's symmetric key based which doesn't work for som= e folks, and the question is do we try to develop something that supports b= oth PK and SK, or finish the SK use case and then work on a PK based draft.= =0A>>>>=0A>>>>=0A>>>>I think it's better to leave them separate and finish = out MAC which is *VERY CLOSE* to being done.=0A>>>=0A>>>Who is interested i= n MAC? People can use OAuth 1.0 if they prefer that model.=A0=0A>>>=0A>>>= =0A>>>For my projects, I prefer the flexibility of a signed or encrypted JW= T if I need holder of key.=0A>>>=0A>>>=0A>>>Just my $.02=0A>>>=0A>>>=0A>>>-= - Dick =A0=0A>>>=0A>>>=0A>>>=0A____________________________________________= ___=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.org/m= ailman/listinfo/oauth=0A>>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>__________________= _____________________________=0AOAuth mailing list OAuth@ietf.org https://w= ww.ietf.org/mailman/listinfo/oauth =0A>=0A_________________________________= ______________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.= org/mailman/listinfo/oauth=0A>=0A=0A_______________________________________= ________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailm= an/listinfo/oauth --764183289-2106440992-1344554391=:70300 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
AS would still be = required to be HTTPS as per the spec.

From: Da= vid Waite <david@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

=0A
For #1:
Does the use of plain HTTP to talk to p= rotected 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?&nb= sp;Would the integrity protection only cover requests, or would you also ha= ve integrity protection of the response?

-DW
=

On Aug 9, 2012, at 1:37 PM, Justin Richer <jricher@mitre.org> wrote:

=0A = =0A =0A =0A
=0A
Us= e case #2: signature protection over=0A plain HTTP parameters
=0A =
=0A MAC gives us message-level signing in a way that doesn't r= equire=0A all the parameters to be packed into an extra structure, lik= e=0A JWT/SAML do. TLS gives no application-layer verification of=0A = integrity of parameters, nor does it give you the ability to know=0A = who presented those parameters (unless you're doing mutual TLS,=0A w= hich nobody does). MAC gives you a fairly simple way to protect=0A all= parameters on a call to the resource server while still=0A keeping al= l of those parameters in their native HTTP forms.
=0A
=0A =
=0A Use case #3: generic signed HTTP fetch (not directly addressed= by=0A MAC spec as of today)
=0A
=0A Sometimes you wa= nt to create a URL with one service, fix all of=0A the parameters in t= hat URL, and protect those parameters with a=0A signature. Then that U= RL can be passed to an untrusted service who=0A cannot modify any port= ion of it. Nor can they re-use the signature=0A portion to protect dif= ferent parameters. We do this today with a=0A 2-legged OAuth signature= across a service URL. The "Client"=0A generates the signed URLs and p= asses them to a user agent which=0A actually does the fetch to the ser= vice.
=0A
=0A
=0A  -- Justin
=0A =0A On 08/09/2012 02:43 PM, William Mills wrote:
=0A
=0A =
=0A =0A
=0A <= div>OK, I'll play and start documenting the use cases.  <= /div>=0A

=0A =
=0A
Use case = #1: Secure=0A = authentication in plain text connections:
=0A
=0A
=0A =
Some applications=0A = need a secure form authorization, but do not want or need=0A = the overhead of encrypted connections.  HTTP cookies and=0A = their ilk are replayable credentials and do not satisfy this=0A = need.   the MAC scheme using signed HTTP authorization=0A = credentials offer the capability to securely authorize a=0A tr= ansaction, can offer integrity protection on all or part=0A of a= n HTTP request, and can provide replay protection.
=0A <= div style=3D"font-size: 16px; font-family: times, serif; background-color: = transparent; font-style: normal; ">
=0A
=0A =
-bill
=0A =

=0A
=0A
=0A
=0A =0A
=0A =0A
In Vancouver the question was = asked about the future=0A of the MAC spec due to it no linge= r having a editor.=0A

=0A
=0A =
The Chair and AD indicated a desire to have a=0A = document on the use-cases we are trying to address=0A = before deciding on progressing MAC or starting a new=0A = document.
=0A

=0A
= =0A
Phil Hunt is going to put together a summery of the= =0A Vancouver discussion and we are going to work on the= =0A use-case/problem description document ASAP.
=0A =

=0A
=0A
Peo= ple are welcome to contribute to the use-case=0A document.=
=0A

=0A
=0A =
Part of the problem with MAC has been that people=0A = could never agree on what it was protecting against.  
=0A =

=0A
=0A
I thi= nk there is general agreement that one or more=0A proof me= chanisms are required for access tokens.
=0A
Secur= ity for the token endpoint also cannot be=0A ignored. = ;
=0A

=0A
=0A =

=0A
=0A
John B.
= =0A
 
=0A
=0A =
On 2012-08-09, at 1:53 PM, William Mills wrote:
=0A =
=0A =
=0A
=0A =
=0A
MAC fixes the signing proble= ms=0A encountered in OAuth 1.0a, yes there are= =0A libraries out there for OAuth 1.0a.  = MAC=0A fits in to the OAuth 2 auth model and w= ill=0A provide for a single codepath for sites= =0A that want to use both Bearer and MAC.
=0A

=0A =
=0A
=0A
=0A
=0A =
From:= =0A Dick Hardt <dick.hardt@gmail.com>
=0A = To:=0A = William Mills <wmills_92105@yahoo.com>=0A =
=0A Cc:=0A "oauth@ietf.org"=0A <oauth@ietf.org>=0A =
=0A Sent:=0A Thursday, A= ugust 9, 2012 10:27 AM
=0A Subject:=0A = Re: [OAUTH-WG] mistake in=0A draft-i= etf-oauth-v2-http-mac-01
=0A =0A
=0A =0A

=0A =
=0A On Aug 9, 2012, at 9:52 AM,=0A Willi= am Mills wrote:
=0A
=0A =
=0A
= =0A
=0A I=0A = find the idea of starting=0A = from scratch frustrating.=0A =  MAC solves a set of=0A = specific problems and has=0A = a well defined use case.=0A =  It's symmetric key based=0A = which doesn't work for=0A = some folks, and the=0A que= stion is do we try to=0A devel= op something that=0A supports = both PK and SK,=0A or finish t= he SK use case=0A and then wor= k on a PK=0A based draft.
=0A

=0A =
=0A =
I= =0A think it's better to leave= =0A them separate and finish= =0A out MAC which is *VERY=0A = CLOSE* to being done.=0A
=0A =
=0A =0A
=0A =
=0A
Who is interested in= MAC? People=0A can use OAuth 1.0 if the= y prefer=0A that model. 
=0A =

=0A =
=0A
For my projects, I prefe= r the=0A flexibility of a signed or encr= ypted=0A JWT if I need holder of key.=0A

=0A =
=0A
Just my $.02=0A

=0A =
=0A
-- Dick  =0A
=0A =
=0A
=0A =
=0A
=0A =
=0A
=0A =0A
=0A ________________= _______________________________
=0A OAuth mailing l= ist
=0A OAuth@ietf.org<= /a>
=0A https://www.ietf.org/mailman/listinfo/oauth
=0A =
=0A
=0A =
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A 
______________________=
_________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.or=
g/mailman/listinfo/oauth=0A
=0A =0A
=0A =0A=0A_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth


______= _________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth


--764183289-2106440992-1344554391=:70300-- From ve7jtb@ve7jtb.com Thu Aug 9 20:48:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0786321F85A0 for ; Thu, 9 Aug 2012 20:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yCIpDpsn5wu for ; Thu, 9 Aug 2012 20:48:28 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAAF21F8543 for ; Thu, 9 Aug 2012 20:48:28 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1301959ggn.31 for ; Thu, 09 Aug 2012 20:48:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=TB67S9r9SaeBzJqTrVj5wg/mu2mkH4lAxEvVk9GQ/O0=; b=aY2vku+caHPdYKDAVo2lXh7VjBTLFBo3IzDXAY3BUYhjbYQTfV/tiofjbbbap+2u0m 1eUoRfFXRWWcniaeiYu69f3ygcME9CBVEcQtuTllTJfMt4xjgFku03MKta/m96axXx2V G364Iq2f4YdRxTzijXgywufr6deNTlGL0ra64gvEQ5uvqGlYNDgEUyGx9gAVfwXhgMw/ YirZjFXGrHIt4rcBbwqILU8Y221IhXHPjt7HPyEuS+z6CMeeVy1YwAD/Ia6L7OZW3+AK 9HcuXSubNV1uLKIwsQMNydAZdFimUM1XxNUoaJevyEvHeAgH+sDbXl9HqnhKjKolhk5Q cCoQ== Received: by 10.236.141.42 with SMTP id f30mr1641196yhj.120.1344570508149; Thu, 09 Aug 2012 20:48:28 -0700 (PDT) Received: from [192.168.1.38] (190-20-39-163.baf.movistar.cl. [190.20.39.163]) by mx.google.com with ESMTPS id d21sm5351425yhe.22.2012.08.09.20.48.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Aug 2012 20:48:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_40CFD598-7400-4CB9-96C4-400A245D8611" From: John Bradley In-Reply-To: <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 9 Aug 2012 23:47:54 -0400 Message-Id: <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQm+DGoEuOs5WZg/sphdZHMu+3FlzSxki2rTpkKxC/uvkZVuLbL5U6zSZcOoVPocV0G7KdsA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 03:48:30 -0000 --Apple-Mail=_40CFD598-7400-4CB9-96C4-400A245D8611 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. >=20 > From: David Waite > To: oauth@ietf.org=20 > Sent: Thursday, August 9, 2012 4:02 PM > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >=20 > 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? >=20 > 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? >=20 > -DW >=20 > On Aug 9, 2012, at 1:37 PM, Justin Richer wrote: >=20 >> Use case #2: signature protection over plain HTTP parameters >>=20 >> 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. >>=20 >>=20 >> Use case #3: generic signed HTTP fetch (not directly addressed by MAC = spec as of today) >>=20 >> 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. >>=20 >>=20 >> -- Justin >>=20 >> On 08/09/2012 02:43 PM, William Mills wrote: >>> OK, I'll play and start documenting the use cases. =20 >>>=20 >>> Use case #1: Secure authentication in plain text connections: >>>=20 >>> 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. >>>=20 >>> -bill >>>=20 >>> From: John Bradley >>> To: William Mills =20 >>> Cc: Dick Hardt ; "oauth@ietf.org" = =20 >>> Sent: Thursday, August 9, 2012 11:26 AM >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>=20 >>> In Vancouver the question was asked about the future of the MAC spec = due to it no linger having a editor. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> People are welcome to contribute to the use-case document. >>>=20 >>> Part of the problem with MAC has been that people could never agree = on what it was protecting against. =20 >>>=20 >>> 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.=20 >>>=20 >>>=20 >>> John B. >>> =20 >>> On 2012-08-09, at 1:53 PM, William Mills wrote: >>>=20 >>>> 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. >>>>=20 >>>> From: Dick Hardt >>>> To: William Mills =20 >>>> Cc: "oauth@ietf.org" =20 >>>> Sent: Thursday, August 9, 2012 10:27 AM >>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>>=20 >>>>=20 >>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> I think it's better to leave them separate and finish out MAC = which is *VERY CLOSE* to being done. >>>>=20 >>>> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>>>=20 >>>> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>>>=20 >>>> Just my $.02 >>>>=20 >>>> -- Dick =20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_40CFD598-7400-4CB9-96C4-400A245D8611 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
AS would still be required = to be HTTPS as per the spec.

From: David Waite <david@alkaline-solutions.com<= /a>>
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 <jricher@mitre.org> = wrote:

= =20 =20 =20
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:
=20
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.

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com> =
Cc: Dick Hardt <dick.hardt@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.hardt@gmail.com>
To: William Mills <wmills_92105@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


_____= __________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_40CFD598-7400-4CB9-96C4-400A245D8611-- From zhou.sujing@zte.com.cn Thu Aug 9 23:53:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CCC11E80FF for ; Thu, 9 Aug 2012 23:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.219 X-Spam-Level: X-Spam-Status: No, score=-98.219 tagged_above=-999 required=5 tests=[AWL=3.619, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmDrNWZ+M6+r for ; Thu, 9 Aug 2012 23:53:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D405B11E80E6 for ; Thu, 9 Aug 2012 23:53:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723546696947; Fri, 10 Aug 2012 14:41:10 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 28963.546696947; Fri, 10 Aug 2012 14:53:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q7A6rTLP084990 for ; Fri, 10 Aug 2012 14:53:29 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: "oauth@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 10 Aug 2012 14:53:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-10 14:53:23, Serialize complete at 2012-08-10 14:53:23 Content-Type: multipart/alternative; boundary="=_alternative 0025E9A048257A56_=" X-MAIL: mse02.zte.com.cn q7A6rTLP084990 Subject: [OAUTH-WG] a question on authorization to resource and scope in request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 06:53:53 -0000 This is a multipart message in MIME format. --=_alternative 0025E9A048257A56_= Content-Type: text/plain; charset="US-ASCII" Hi, all I wonder how an access token is bound with the required resource item, I cann't see any field specifying the requested resource in request for authorization token and access token. Is "scope" relevant with this? Regards~~~ -Sujing Zhou --=_alternative 0025E9A048257A56_= Content-Type: text/html; charset="US-ASCII"
Hi, all
   I wonder how an access token is bound with the required resource item, I cann't see any field specifying the requested resource  in request for authorization token and access token.
Is "scope" relevant with this?

Regards~~~

-Sujing Zhou --=_alternative 0025E9A048257A56_=-- From hannes.tschofenig@gmx.net Fri Aug 10 00:00:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B60F21F84B6 for ; Fri, 10 Aug 2012 00:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lVd0bDbBvFt for ; Fri, 10 Aug 2012 00:00:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 36B6821F84C5 for ; Fri, 10 Aug 2012 00:00:53 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2012 07:00:51 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 10 Aug 2012 09:00:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ArBNNHnQAgEAgrGT0WXTSu5NkQEjCWk2GQCERGg MdRffmw1xH7Ip1 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2012 10:00:50 +0300 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] MAC Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:00:56 -0000 Justin wrote:=20 " I believe that there's value in per-message signing completely apart = from the channel level encryption.=20 " May well be. But we have to figure out what exactly the reasons are why = there is value.=20 Bill wrote: " I find the idea of starting from scratch frustrating. MAC solves a set = of specific problems and has a well defined use case. " This would be a very quick process if we had ever done our home work = properly.=20 So, what are the problems it tries to solve? Yesterday I found an old = presentation about MAC and the basic argument was that it has better = performance than TLS. While that's true it is not a good argument per = se. However, performance is not the only factor to look at and the = negative performance impact caused by TLS is overrated. =20 Here is the slide set I am talking about:=20 http://www.tschofenig.priv.at/Why_are_we_Signing.pdf In many cases I had noticed that more time was spent with the pictures = (in slides and blog post) than with the content. That's not good IMHO.=20= Bill, we can hardly call a specification "complete" if many of us don't = know what problem it solves. John phrases it nicely as "Part of the = problem with MAC has been that people could never agree on what it was = protecting against." I am also interested in hearing about deployment = constraints that people have. Blaine always said that many developers = cannot get TLS to work. I am sure that's true but OAuth 2.0 requires TLS = to be used anyway to secure the interaction with the authorization = server.=20 Note: I am not saying that we are not going to standardize something = like the MAC token (maybe with different details) but let us spend a = little bit of time to figure out what threats we want to deal with.=20 From hannes.tschofenig@gmx.net Fri Aug 10 00:01:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706F911E8100 for ; Fri, 10 Aug 2012 00:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJogcg6DdeoK for ; Fri, 10 Aug 2012 00:01:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5962D11E80E6 for ; Fri, 10 Aug 2012 00:01:35 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2012 07:01:33 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp070) with SMTP; 10 Aug 2012 09:01:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+hYK510GmhlNH3uEFNdwbZOjWdoGEUO4dCdxL+Y5 DH0OsL+X3TrjKu Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 10:01:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:01:36 -0000 Hi Bill,=20 thanks for the feedback. Let's have a look at this use case:=20 You need to provide me a bit more information regarding your use case. = Could you please explain=20 1) Who is authenticated to whom? 2) What plaintext connection are you talking about?=20 3) What is the problem with encrypted connections? Is this again the = "TLS has so bad performance" argument?=20 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.=20 5) What is the threat you are concerned about?=20 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. =20 >=20 > Use case #1: Secure authentication in plain text connections: >=20 > 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. >=20 > -bill >=20 > From: John Bradley > To: William Mills =20 > Cc: Dick Hardt ; "oauth@ietf.org" = =20 > Sent: Thursday, August 9, 2012 11:26 AM > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >=20 > In Vancouver the question was asked about the future of the MAC spec = due to it no linger having a editor. >=20 > 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. >=20 > 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. >=20 > People are welcome to contribute to the use-case document. >=20 > Part of the problem with MAC has been that people could never agree on = what it was protecting against. =20 >=20 > 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.=20 >=20 >=20 > John B. > =20 > On 2012-08-09, at 1:53 PM, William Mills wrote: >=20 >> 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. >>=20 >> From: Dick Hardt >> To: William Mills =20 >> Cc: "oauth@ietf.org" =20 >> Sent: Thursday, August 9, 2012 10:27 AM >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>=20 >>=20 >> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>=20 >>> 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. >>>=20 >>> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >>=20 >> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>=20 >> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>=20 >> Just my $.02 >>=20 >> -- Dick =20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Aug 10 00:05:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7136821F84D8 for ; Fri, 10 Aug 2012 00:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pCyMTYhsDN1 for ; Fri, 10 Aug 2012 00:05:27 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0FB3821F84C2 for ; Fri, 10 Aug 2012 00:05:26 -0700 (PDT) Received: (qmail invoked by alias); 10 Aug 2012 07:05:25 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.108]) [88.115.216.191] by mail.gmx.net (mp029) with SMTP; 10 Aug 2012 09:05:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+U0hsx2G2UBkIKc84NEACzyt5EXXgTgGE9jxLhFb TrtPXzrVXQkAxT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50241165.40209@mitre.org> Date: Fri, 10 Aug 2012 10:05:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <047A5679-FE6B-4EF4-8D43-A3372B928F05@gmx.net> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:05:28 -0000 Hi Justin,=20 thanks for the feedback. Comments below.=20 On Aug 9, 2012, at 10:37 PM, Justin Richer wrote: > Use case #2: signature protection over plain HTTP parameters >=20 > 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. >=20 First, we have to assume as a starting point that we have bearer. So, = assuming that there is actually plain HTTP for the communication between = the client and the resource server does not exist.=20 TLS does indeed not give the ability for the resource server to know who = the client is. Client authentication would do that.=20 Btw, the MAC draft does not allow the client to be authenticated.=20 The MAC token does not protect all the parameters in the message. In = fact, it protects only very, very few! TLS is an application layer protocol (it runs on top of TCP) and = protects the integrity and the confidentiality of the parameters in an = end-to-end fashion. However, as others have noted the end on the server = side may be a load balancer in case a system administrator has = intentionally decided to terminate all secure traffic there. Saying that = MAC would then be "more e2e" may be true unless the administrator has = again decided to terminate it also at the load balancer (which may not = be completely unlikely).=20 >=20 > Use case #3: generic signed HTTP fetch (not directly addressed by MAC = spec as of today) >=20 > 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. >=20 >=20 (I personally would have even liked to get rid of the 2-legged OAuth use = cases).=20 I think that this use case is again a bit different from what we have = been talking about so far. Maybe you want to compile an Internet draft = so that we have more details to assess the security properties better.=20= Ciao Hannes > -- Justin >=20 > On 08/09/2012 02:43 PM, William Mills wrote: >> OK, I'll play and start documenting the use cases. =20 >>=20 >> Use case #1: Secure authentication in plain text connections: >>=20 >> 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. >>=20 >> -bill >>=20 >> From: John Bradley >> To: William Mills =20 >> Cc: Dick Hardt ; "oauth@ietf.org" = =20 >> Sent: Thursday, August 9, 2012 11:26 AM >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>=20 >> In Vancouver the question was asked about the future of the MAC spec = due to it no linger having a editor. =20 >>=20 >> 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. >>=20 >> 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. >>=20 >> People are welcome to contribute to the use-case document. >>=20 >> Part of the problem with MAC has been that people could never agree = on what it was protecting against. =20 >>=20 >> 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.=20 >>=20 >>=20 >> John B. >> =20 >> On 2012-08-09, at 1:53 PM, William Mills wrote: >>=20 >>> 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. >>>=20 >>> From: Dick Hardt >>> To: William Mills =20 >>> Cc: "oauth@ietf.org" =20 >>> Sent: Thursday, August 9, 2012 10:27 AM >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>=20 >>>=20 >>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>=20 >>>> 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. >>>>=20 >>>> I think it's better to leave them separate and finish out MAC which = is *VERY CLOSE* to being done. >>>=20 >>> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>>=20 >>> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>>=20 >>> Just my $.02 >>>=20 >>> -- Dick =20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From havardge@comoyo.com Fri Aug 10 00:50:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268BD21F84D6 for ; Fri, 10 Aug 2012 00:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0nfPZyAnICp for ; Fri, 10 Aug 2012 00:50:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 740B621F84CE for ; Fri, 10 Aug 2012 00:50:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1426613ghb.31 for ; Fri, 10 Aug 2012 00:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=GLAudmWHG4a98OpI97i+Pi64ZfanYEPWh0L0Z5ofQtc=; b=gbCRqBxlE0dBH1a/Qnz/F3cQDJFL95f7DAkjcsDszLnBirBhpt1IT8vfYEAYvIpFn0 5sq1H38FMiQCch7cgz2X2x1zDyp3S1oh0ixsmuJNbTsgpW/DNprVoiM9L3qfoqubarO4 EcGBpUynNZPBgX8e/KDWetP1O1KXzHTot2ou6CRDXJeEVScHv0FPQiONL9q48buw5Bui EbPpXqvQEh/q/GXOJJ1L9bTFoDZP+e4cy1HX3LXKp5MIzzuDYr8zIJj4P5zL1hL+3U6M 98UZqjYk7+nZxsjlA28tCAg4lasPLAz7TXERH5O531SPjQ3cGMAw63C0ucy5E/lYD6jP vmIQ== Received: by 10.50.95.230 with SMTP id dn6mr980217igb.16.1344585053850; Fri, 10 Aug 2012 00:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.253.13 with HTTP; Fri, 10 Aug 2012 00:50:33 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?H=E5vard_Geithus?= Date: Fri, 10 Aug 2012 09:50:33 +0200 Message-ID: To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=e89a8f23438b814dcd04c6e49a09 X-Gm-Message-State: ALoCoQnh9k18uMGNOYCJjLvQ+baGWNSomti6z6BDuFeGVoxGJFMwQt4M1TyQS64ZNKEL0CL4pJCf Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] a question on authorization to resource and scope in request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:50:56 -0000 --e89a8f23438b814dcd04c6e49a09 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Hi, Either the resource server can ask the authentication server for information associated with the token (e.g. resource owner's id and scope) or this information can be encrypted into the token string. The scope defines what resources, and resource owner id defines whose resource. At least that's how I *think* it is. On Fri, Aug 10, 2012 at 8:53 AM, wrote: > > Hi, all > I wonder how an access token is bound with the required resource item, > I cann't see any field specifying the requested resource in request for > authorization token and access token. > Is "scope" relevant with this? > > Regards~~~ > > -Sujing Zhou > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --e89a8f23438b814dcd04c6e49a09 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,

Either the resource server can ask the authenticatio= n server for information associated with the token (e.g. resource owner'= ;s id and scope) or this information can be encrypted into the token string= . The scope defines what resources, and resource owner id defines whose res= ource. At least that's how I think it is.

On Fri, Aug 10, 2012 at 8:53 AM, <zh= ou.sujing@zte.com.cn> wrote:
Hi, all
   I wonder how an access token is bound with the required resource item, I cann't see any field specifying the requested resource  in request for authorization token and access token.
Is "scope" relevant with this?

Regards~~~

-Sujing Zhou
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--e89a8f23438b814dcd04c6e49a09-- From havardge@comoyo.com Fri Aug 10 00:52:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE9621F85BB for ; Fri, 10 Aug 2012 00:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RLFWZE36xsL for ; Fri, 10 Aug 2012 00:52:47 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 425AA21F853C for ; Fri, 10 Aug 2012 00:52:47 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1423681ggn.31 for ; Fri, 10 Aug 2012 00:52:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ME1ytjVd/BdvnLQ7xEoZRaVwMS5y3W4hAbhtVB8F94M=; b=XqoAYqkJ+xBiVyQmQbnKUIuVk8AM+KYG7dLPctJ0WtyWayJLFhLpWCS0ugZaqV0Spq ZgZzzPXWuZzbbB9PfPFY/0r/0rOI1SvVggvLBkRytwkSvZ1Sl1Qovhg45Qi8OOnOu69H vMofs8H2AT4+wNAVtG2ExgRem9spp+BTe0IcTm5Q4gO/t3Rvh69LPEEBSPT6aCmn1m70 6WYgKa57PLGQ9M1J82prPDozM0yB3CLS1S0jni0zS49IbPuRf1DoPVREkJfNJ1L0WhBq qoyV/ZE9PR14/F99E4HxLU1lShQk48PdTe5dA/EtgZvK6SudaaRLNCouXHB/XpU7bLy4 uRJA== Received: by 10.50.149.134 with SMTP id ua6mr990227igb.11.1344585166593; Fri, 10 Aug 2012 00:52:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.253.13 with HTTP; Fri, 10 Aug 2012 00:52:26 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?H=E5vard_Geithus?= Date: Fri, 10 Aug 2012 09:52:26 +0200 Message-ID: To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=e89a8f23554d399d7604c6e4a101 X-Gm-Message-State: ALoCoQkAs9xb4vdgh5FJt5vufQte108dpUTln+AUcd9WsrKzPi9oc+radqWNdEp4neT5+UcVL6/T Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] a question on authorization to resource and scope in request X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 07:52:48 -0000 --e89a8f23554d399d7604c6e4a101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Replace "authentication server" with "authorization server" in the previous message ;) On Fri, Aug 10, 2012 at 9:50 AM, H=E5vard Geithus wro= te: > Hi, > > Either the resource server can ask the authentication server for > information associated with the token (e.g. resource owner's id and scope= ) > or this information can be encrypted into the token string. The scope > defines what resources, and resource owner id defines whose resource. At > least that's how I *think* it is. > > On Fri, Aug 10, 2012 at 8:53 AM, wrote: > >> >> Hi, all >> I wonder how an access token is bound with the required resource item= , >> I cann't see any field specifying the requested resource in request for >> authorization token and access token. >> Is "scope" relevant with this? >> >> Regards~~~ >> >> -Sujing Zhou >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --e89a8f23554d399d7604c6e4a101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Replace "authentication server" with "authorization server&q= uot; in the previous message ;)

On Fri, A= ug 10, 2012 at 9:50 AM, H=E5vard Geithus <havardge@comoyo.com> wrote:
Hi,

Either the resource s= erver can ask the authentication server for information associated with the= token (e.g. resource owner's id and scope) or this information can be = encrypted into the token string. The scope defines what resources, and reso= urce owner id defines whose resource. At least that's how I=A0think<= /i>=A0it is.

On Fri, Aug 10, 2012 = at 8:53 AM, <zhou.sujing@zte.com.cn> wrote:
<= /div>

Hi, all
=A0 =A0I wonder how an access token is bound with the required resource item, I cann't see any field specifying the requested resource =A0in request for authorization token and access token.
Is "scope" relevant with this?

Regards~~~

-Sujing Zhou
________________________________________= _______
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--e89a8f23554d399d7604c6e4a101-- From wmills_92105@yahoo.com Fri Aug 10 07:36:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C516A21F8604 for ; Fri, 10 Aug 2012 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5uEv3fj3UgQ for ; Fri, 10 Aug 2012 07:36:13 -0700 (PDT) Received: from nm9-vm0.bullet.mail.sp2.yahoo.com (nm9-vm0.bullet.mail.sp2.yahoo.com [98.139.91.196]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9321F85C3 for ; Fri, 10 Aug 2012 07:36:13 -0700 (PDT) Received: from [72.30.22.79] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 14:36:13 -0000 Received: from [72.30.22.36] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 14:36:12 -0000 Received: from [127.0.0.1] by omp1066.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 14:36:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 416283.53193.bm@omp1066.mail.sp2.yahoo.com Received: (qmail 70993 invoked by uid 60001); 10 Aug 2012 14:36:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344609371; bh=FrFW/gLMpn1F/GAYWpGCnmVfN1ufSbPBP9qU+s785M0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Sp0eWpOoieyFhrPpYNUyFCaz/PwtHGCQMOsYMOgOXXWEp5Z7JgClRsG6pE1aKArnQnTUScPDCDq+uxJW2W0+87uHIYg0eE/jWpYKhjpm/S/y0UsbKxgA1Rwr7dvl5zG8S7/tLisvDe+PTIcMYTpT6V4dx+M+sWWXotNPQIDd6X4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=f+juGsAOIBSP9DzM2ehK40CerJpMfaugJ3TYF+OOiAZ9sUCODIDA14oOfmY+C0g1gC1FOTyk4PGuCrh5v7Ei3raGVW4QOWqATk72NeDdiygoaCx54FhVHW5cVZ6pkyYPi3WtdnJ5Q6sWEtxnTf382jjM8norHjkCghBMG49eqSM=; X-YMail-OSG: bCPeoKMVM1m5DGnRqvvDndzEuvIW4VsPhZT2TjVpjX4hE_S XNgbpJ2svx3ahiUyNdXWh4BQvkiHlGl05Ssip8szSAR3iJCdGaSpQ9W8_9qQ dmhe9acbdPXF4Mlv3SQHmP90l5A1F3QTi5EcDs95XBtTI4Hkt7jweAFX7sQD JWfd7tD6Ubry9Y5jLnaRRXfOzdIvqqc9s19TZeW2Z1f5Pfubmz9ZpmGTpteg bB0biKeuNBFxR8r6n6A9MZ5fg6qJ3BNfJ0C8T1z7EZYB._NmdgtUvynkm4EM OOBcTfgBW1ZsYzvIb3I6rpcjJZtLHGZ1LtxXSymPPQcQpsK_J534PMdrTA6x HYtfViUh1_rUz6zeVnax1eN3Ve1fI3FZiewujEFuMEkd5_GQuaoS22fN2_HJ g0i9OgAgsmfjQGDIYAW8Xdrm9FQv6AmgDZk9gKVGk4hxd1yHzTRpCckolf6J 6ABI49N12Ye8t_Z6aTm1kwPGO16wZFN5ln6uDRIc- Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 07:36:11 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> Message-ID: <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 07:36:11 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-1999875829-1344609371=:51892" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:36:14 -0000 --767760015-1999875829-1344609371=:51892 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would say that's true in theory, but practically speaking it's not gonna = happen. =A0You're stating we need to come up with a better method for publi= c key than we have now for this to be widely adopted, and I don't think tha= t's reasonable.=0A=0AIf we're gonna improve on the current PKI that is SSL = certificates we should do that separately.=0A=0A=0A________________________= ________=0A From: John Bradley =0ATo: William Mills =0ACc: David Waite ; "oa= uth@ietf.org" =0ASent: Thursday, August 9, 2012 8:47 PM=0A= Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A =0A= =0ABill,=0A=0AI seem to recall in Paris that client misconfiguration of TLS= was a concern.=0A=0AIn MAC the token secret is delivered with the token ba= sed on server TLS and HTTP basic authentication.=0A=0AIf this is OK and we = trust the client to do TLS server certificate verification correctly that n= eeds to go in as one of our base assumptions. =A0Or conversely additional p= rotection of the token endpoint needs to be considered for key distribution= .=0A=0AJohn B.=0A=0AOn 2012-08-09, at 7:19 PM, William Mills wrote:=0A=0AAS= would still be required to be HTTPS as per the spec.=0A>=0A>=0A>=0A>______= __________________________=0A> From: David Waite =0A>To: oauth@ietf.org =0A>Sent: Thursday, August 9, 2012 4:02 PM=0A>Su= bject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A> =0A>= =0A>For #1:=0A>Does the use of plain HTTP to talk to protected resources pr= ovide significant value when using an AS that requires HTTPS? Or am I misun= derstanding, and this use case would also include new modes for non-TLS com= munication with the AS?=0A>=0A>=0A>For #2:=0A>Would the signature protectio= n just cover HTTP parameters, or would it extend to covering any request da= ta, such as a PUT binary file?=A0Would the integrity protection only cover = requests, or would you also have integrity protection of the response?=0A>= =0A>=0A>-DW=0A>=0A>=0A>On Aug 9, 2012, at 1:37 PM, Justin Richer wrote:=0A>=0A>Use case #2: signature protection over plain HTTP p= arameters=0A>>=0A>>MAC gives us message-level signing in a way that doesn't= require=0A all the parameters to be packed into an extra structure, l= ike=0A JWT/SAML do. TLS gives no application-layer verification of=0A = integrity of parameters, nor does it give you the ability to know=0A = who presented those parameters (unless you're doing mutual TLS,=0A = which nobody does). MAC gives you a fairly simple way to protect=0A a= ll parameters on a call to the resource server while still=0A keeping = all of those parameters in their native HTTP forms.=0A>>=0A>>=0A>>Use case = #3: generic signed HTTP fetch (not directly addressed by=0A MAC spec a= s of today)=0A>>=0A>>Sometimes you want to create a URL with one service, f= ix all of=0A the parameters in that URL, and protect those parameters = with a=0A signature. Then that URL can be passed to an untrusted servi= ce who=0A cannot modify any portion of it. Nor can they re-use the sig= nature=0A portion to protect different parameters. We do this today wi= th a=0A 2-legged OAuth signature across a service URL. The "Client"=0A= generates the signed URLs and passes them to a user agent which=0A = actually does the fetch to the service.=0A>>=0A>>=0A>>=A0-- Justin=0A>>= =0A>>On 08/09/2012 02:43 PM, William Mills wrote:=0A>>=0A>>OK, I'll play an= d start documenting the use cases. =A0=0A>>>=0A>>>=0A>>>Use case #1:=A0Secu= re authentication in plain text connections:=0A>>>=0A>>>=0A>>>Some applicat= ions need a secure form authorization, but do not want or need the overhead= of encrypted connections. =A0HTTP cookies and their ilk are replayable cre= dentials and do not satisfy this need. =A0 the MAC scheme using signed HTTP= authorization credentials offer the capability to securely authorize a tra= nsaction, can offer integrity protection on all or part of an HTTP request,= and can provide replay protection.=0A>>>=0A>>>=0A>>>-bill=0A>>>=0A>>>=0A>>= >=0A>>>________________________________=0A>>> From: John Bradley =0A>>>To: William Mills =0A>>>Cc: Dick Ha= rdt ; "oauth@ietf.org" =0A>>>Sent: T= hursday, August 9, 2012 11:26 AM=0A>>>Subject: Re: [OAUTH-WG] mistake in dr= aft-ietf-oauth-v2-http-mac-01=0A>>> =0A>>>=0A>>>In Vancouver the question w= as asked about the future of the MAC spec due to it no linger having a edit= or. =0A>>>=0A>>>=0A>>>The Chair and AD indicated a desire to have a documen= t on the use-cases we are trying to address before deciding on progressing = MAC or starting a new document.=0A>>>=0A>>>=0A>>>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.=0A>>>=0A>>>=0A>>>People are= welcome to contribute to the use-case document.=0A>>>=0A>>>=0A>>>Part of t= he problem with MAC has been that people could never agree on what it was p= rotecting against. =A0=0A>>>=0A>>>=0A>>>I think there is general agreement = that one or more proof mechanisms are required for access tokens.=0A>>>Secu= rity for the token endpoint also cannot be ignored.=A0=0A>>>=0A>>>=0A>>>=0A= >>>=0A>>>John B.=0A>>>=A0=0A>>>=0A>>>On 2012-08-09, at 1:53 PM, William Mil= ls wrote:=0A>>>=0A>>>MAC fixes the signing problems encountered in OAuth 1.= 0a, yes there are libraries out there for OAuth 1.0a. =A0MAC fits in to the= OAuth 2 auth model and will provide for a single codepath for sites that w= ant to use both Bearer and MAC.=0A>>>>=0A>>>>=0A>>>>=0A>>>>________________= ________________=0A>>>> From: Dick Hardt =0A>>>>To: W= illiam Mills =0A>>>>Cc: "oauth@ietf.org" =0A>>>>Sent: Thursday, August 9, 2012 10:27 AM=0A>>>>Subject: Re: [= OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A>>>> =0A>>>>=0A>>>>= =0A>>>>=0A>>>>On Aug 9, 2012, at 9:52 AM, William Mills wrote:=0A>>>>=0A>>>= >I find the idea of starting from scratch frustrating. =A0MAC solves a set = of specific problems and has a well defined use case. =A0It'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 a= nd then work on a PK based draft.=0A>>>>>=0A>>>>>=0A>>>>>I think it's bette= r to leave them separate and finish out MAC which is *VERY CLOSE* to being = done.=0A>>>>=0A>>>>Who is interested in MAC? People can use OAuth 1.0 if th= ey prefer that model.=A0=0A>>>>=0A>>>>=0A>>>>For my projects, I prefer the = flexibility of a signed or encrypted JWT if I need holder of key.=0A>>>>=0A= >>>>=0A>>>>Just my $.02=0A>>>>=0A>>>>=0A>>>>-- Dick =A0=0A>>>>=0A>>>>=0A>>>= >=0A_______________________________________________=0A>>>>OAuth mailing lis= t=0A>>>>OAuth@ietf.org=0A>>>>https://www.ietf.org/mailman/listinfo/oauth=0A= >>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>=0A>>>___________________________________= ____________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailm= an/listinfo/oauth =0A>>=0A_______________________________________________= =0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman= /listinfo/oauth=0A>>=0A>=0A>_______________________________________________= =0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/li= stinfo/oauth=0A>=0A>=0A>_______________________________________________=0A>= OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listin= fo/oauth=0A> --767760015-1999875829-1344609371=:51892 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
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 h= ave now for this to be widely adopted, and I don't think that's reasonable.=

If we'r= e gonna improve on the current PKI that is SSL certificates we should do th= at separately.

From: John Bradley &l= t;ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: David Waite <david@alkaline-solutions.c= om>; "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

=0A
Bill,

I seem to recall in Paris that cl= ient 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 t= he client to do TLS server certificate verification correctly that needs to= go in as one of our base assumptions.  Or conversely additional prote= ction of the token endpoint needs to be considered for key distribution.

John B.
On 2012-08-09, at 7:19 PM, Will= iam Mills wrote:

<= blockquote type=3D"cite">
AS would still be = required to be HTTPS as per the spec.

=
From: David Waite <david@alkaline-solutions.com>
To: oau= th@ietf.org
Sent: = Thursday, August 9, 2012 4:02 PM
S= ubject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-0= 1

=0A
For #1:
Does the use of plain HTTP to talk to protected resources provide sig= nificant value when using an AS that requires HTTPS? Or am I misunderstandi= ng, and this use case would also include new modes for non-TLS communicatio= n with the AS?

For #2:
Would the signatu= re protection just cover HTTP parameters, or would it extend to covering an= y request data, such as a PUT binary file? Would the integrity protect= ion only cover requests, or would you also have integrity protection of the= response?

-DW

On Au= g 9, 2012, at 1:37 PM, Justin Richer <= jricher@mitre.org> wrote:

=0A =0A =0A =0A
=0A =
Use case #2: signature protectio= n over=0A plain HTTP parameters
=0A
=0A MAC gives us = message-level signing in a way that doesn't require=0A all the paramet= ers to be packed into an extra structure, like=0A JWT/SAML do. TLS giv= es no application-layer verification of=0A integrity of parameters, no= r does it give you the ability to know=0A who presented those paramete= rs (unless you're doing mutual TLS,=0A which nobody does). MAC gives y= ou a fairly simple way to protect=0A all parameters on a call to the r= esource server while still=0A keeping all of those parameters in their= native HTTP forms.
=0A
=0A
=0A Use case #3: gene= ric signed HTTP fetch (not directly addressed by=0A MAC spec as of tod= ay)
=0A
=0A Sometimes you want to create a URL with one se= rvice, fix all of=0A the parameters in that URL, and protect those par= ameters with a=0A signature. Then that URL can be passed to an untrust= ed service who=0A cannot modify any portion of it. Nor can they re-use= the signature=0A portion to protect different parameters. We do this = today with a=0A 2-legged OAuth signature across a service URL. The "Cl= ient"=0A generates the signed URLs and passes them to a user agent whi= ch=0A actually does the fetch to the service.
=0A
=0A =
=0A  -- Justin
=0A
=0A On 08/09/2012 02:43 = PM, William Mills wrote:
=0A
=0A
= =0A =0A
=0A
=0A
= Use case #1: Secure=0A authentication in plain text connections:=0A

=0A
=0A
Some applica= tions=0A need a secure form authorization, but do not want or ne= ed=0A the overhead of encrypted connections.  HTTP cookies = and=0A their ilk are replayable credentials and do not satisfy t= his=0A need.   the MAC scheme using signed HTTP authorizati= on=0A credentials offer the capability to securely authorize a= =0A transaction, can offer integrity protection on all or part= =0A of an HTTP request, and can provide replay protection.
=0A

=0A =
=0A
-bill
=0A

=0A
=0A
=0A
=0A
= =0A
From:=0A John Bradle= y <ve7jtb@ve7jtb.com>
=0A To:=0A William Mills <wmills_92105@yahoo.com>
=0A Cc: Dick=0A Hardt <dick.hardt@gmail.com>; "oauth@ietf.org"=0A = &l= t;oauth@ietf.org>
=0A Sent:=0A Thursday, August 9, 2012 11:26= AM
=0A Subject:=0A Re: [OAUTH-WG] mistake in=0A draft= -ietf-oauth-v2-http-mac-01
=0A
=0A =
=0A
=0A
In Vanco= uver the question was asked about the future=0A of the MAC s= pec due to it no linger having a editor.=0A

=0A =
=0A
The Chair and AD indicated a desi= re to have a=0A document on the use-cases we are trying to= address=0A before deciding on progressing MAC or starting= a new=0A document.
=0A

=0A =
=0A
Phil Hunt is going to put toget= her a summery of the=0A Vancouver discussion and we are go= ing to work on the=0A use-case/problem description documen= t ASAP.
=0A

=0A
=0A =
People are welcome to contribute to the use-case=0A = document.
=0A

=0A =0A
Part of the problem with MAC has been that people= =0A could never agree on what it was protecting against. &= nbsp;
=0A

=0A
=0A =
I think there is general agreement that one or more=0A = proof mechanisms are required for access tokens.
=0A =
Security for the token endpoint also cannot be=0A = ignored. 
=0A

=0A =0A

=0A
=0A =
John B.
=0A
 
=0A =0A
On 2012-08-09, at 1:53 PM, William Mills wro= te:
=0A
=0A
=0A =
=0A
=0A
MAC fixes = the signing problems=0A encountered in OAuth 1= .0a, yes there are=0A libraries out there for = OAuth 1.0a.  MAC=0A fits in to the OAuth = 2 auth model and will=0A provide for a single = codepath for sites=0A that want to use both Be= arer and MAC.
=0A

=0A =
=0A
=0A
=0A =
=0A =
From:=0A Dick Hardt <dick.hardt@gmail.com>
=0A = To:=0A William Mills <wmills_92105@yahoo.com>=0A =
=0A Cc:=0A = "oauth@ietf.org"=0A = <oauth@ietf.org>=0A =
=0A Sent:=0A = Thursday, August 9, 2012 10:27 AM
=0A = Subject:=0A = Re: [OAUTH-WG] mistake in=0A = draft-ietf-oauth-v2-http-mac-01
=0A =
=0A
=0A =
=0A =

=0A
=0A =
On Aug 9, 2012, at 9:52 AM,=0A = William Mills wrote:
=0A =
=0A =
=0A =
=0A
=0A =
I=0A = find the idea of starting=0A = from scratch frustrating.=0A =  MAC solves a set of=0A = specific problems and has=0A = a well defined use case.=0A =  It's symmetric key based=0A = which doesn't work for=0A = some folks, and the=0A = question is do we try to=0A = develop something that=0A = supports both PK and SK,=0A = or finish the SK use case=0A = and then work on a PK=0A = based draft.
=0A

=0A =
=0A =
I=0A think it's= better to leave=0A them separ= ate and finish=0A out MAC whic= h is *VERY=0A CLOSE* to being = done.
=0A
=0A =
=0A =
=0A
=0A =
=0A
Who is= interested in MAC? People=0A can use OA= uth 1.0 if they prefer=0A that model.&nb= sp;
=0A

=0A =
=0A
For my pro= jects, I prefer the=0A flexibility of a = signed or encrypted=0A JWT if I need hol= der of key.
=0A

=0A =
=0A
Ju= st my $.02
=0A

=0A =
=0A
-- = Dick  
=0A
=0A =
=0A
=0A =
=0A
=0A =
=0A
=0A =
=0A
=0A __= _____________________________________________
=0A O= Auth mailing list
=0A OAuth@ietf.org
=0A https://www.ietf.org/mailman/listinfo/oa= uth
=0A
=0A
= =0A
=0A
=0A
= =0A
=0A
=0A
=0A =0A
=0A
=0A
=0A
=0A
=0A 
__=
_____________________________________________=0AOAuth mailing list=0AOAuth@=
ietf.org=0A=
https://www.ietf.org/mailman/listinfo/oauth=0A
=0A =0A
=0A
=0A=0A______________________________________________= _
OAuth mailing list
OAuth@ietf.orghttps://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



=
--767760015-1999875829-1344609371=:51892-- From jricher@mitre.org Fri Aug 10 07:38:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF57421F8678 for ; Fri, 10 Aug 2012 07:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtPbIMgOlEh8 for ; Fri, 10 Aug 2012 07:38:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 387D321F8568 for ; Fri, 10 Aug 2012 07:38:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3566721B05B0; Fri, 10 Aug 2012 10:38:05 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1E58821B043D; Fri, 10 Aug 2012 10:38:05 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 10:38:04 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Thread-Index: AQHNdsaCSF2cG8V1/E2FdFvBUY4SypdTYP+A Date: Fri, 10 Aug 2012 14:38:03 +0000 Message-ID: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <047A5679-FE6B-4EF4-8D43-A3372B928F05@gmx.net> In-Reply-To: <047A5679-FE6B-4EF4-8D43-A3372B928F05@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <2536DA04C1FE1844B1057799939326E1@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:38:10 -0000 On Aug 10, 2012, at 3:05 AM, Hannes Tschofenig wrote: > Hi Justin,=20 >=20 > thanks for the feedback. Comments below.=20 Sure thing, I think that use cases are very important to enumerate. I think= the fact that several people in the WG are coming forward and saying "Yes = I have use cases for this" is very telling that this is an important proble= m to solve. >=20 > On Aug 9, 2012, at 10:37 PM, Justin Richer wrote: >=20 >> Use case #2: signature protection over plain HTTP parameters >>=20 >> 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 giv= es no application-layer verification of integrity of parameters, nor does i= t give you the ability to know who presented those parameters (unless you'r= e doing mutual TLS, which nobody does). MAC gives you a fairly simple way t= o protect all parameters on a call to the resource server while still keepi= ng all of those parameters in their native HTTP forms. >>=20 >=20 > First, we have to assume as a starting point that we have bearer. So, ass= uming that there is actually plain HTTP for the communication between the c= lient and the resource server does not exist.=20 I'm confused here -- what exactly do you mean by this statement? >=20 > TLS does indeed not give the ability for the resource server to know who = the client is. Client authentication would do that.=20 > Btw, the MAC draft does not allow the client to be authenticated.=20 TLS mutual auth doesn't let you express the full context that comes with an= OAuth token.=20 >=20 > The MAC token does not protect all the parameters in the message. In fact= , it protects only very, very few! Which is why we need to update and fix it! I never said that MAC was *done*= , just that it's a pretty good starting point and we shouldn't ignore it. T= his is the point that Bill was making, too, if I read it right. >=20 > TLS is an application layer protocol (it runs on top of TCP) and protects= the integrity and the confidentiality of the parameters in an end-to-end f= ashion. However, as others have noted the end on the server side may be a l= oad balancer in case a system administrator has intentionally decided to te= rminate all secure traffic there. Saying that MAC would then be "more e2e" = may be true unless the administrator has again decided to terminate it also= at the load balancer (which may not be completely unlikely).=20 Load balancers and performance are a red herring and are distracting this c= onversation. There are other reasons to have message-level signing. Not eve= rything is a single point-to-point HTTP transaction that TLS assumes. In su= ch multi-hop scenarios, TLS can protect things on the wire but not within t= he components that can read and forward it, such as in use case #3 below. >=20 >>=20 >> Use case #3: generic signed HTTP fetch (not directly addressed by MAC sp= ec as of today) >>=20 >> Sometimes you want to create a URL with one service, fix all of the para= meters in that URL, and protect those parameters with a signature. Then tha= t URL can be passed to an untrusted service who cannot modify any portion o= f it. Nor can they re-use the signature portion to protect different parame= ters. 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 wh= ich actually does the fetch to the service. >>=20 >>=20 > (I personally would have even liked to get rid of the 2-legged OAuth use = cases).=20 There are many, many important use cases that use the two legged pattern, a= nd many, many people use them today in both OAuth1 (which never specified t= hem) and OAuth2 (which finally embraced them as valid). They're not going a= way. >=20 > I think that this use case is again a bit different from what we have bee= n talking about so far. Maybe you want to compile an Internet draft so that= we have more details to assess the security properties better.=20 >=20 Yes it is, but it can be covered by the same solution set with some minor c= hanges. Like I said, it's not directly covered by the MAC draft right now.= =20 I have other scenarios that have message-level signing as a stated requirem= ent, full stop. I'd like to be able to use OAuth machinery to fulfill this. -- Justin > Ciao > Hannes >=20 >> -- Justin >>=20 >> On 08/09/2012 02:43 PM, William Mills wrote: >>> OK, I'll play and start documenting the use cases. =20 >>>=20 >>> Use case #1: Secure authentication in plain text connections: >>>=20 >>> 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 usin= g signed HTTP authorization credentials offer the capability to securely au= thorize a transaction, can offer integrity protection on all or part of an = HTTP request, and can provide replay protection. >>>=20 >>> -bill >>>=20 >>> From: John Bradley >>> To: William Mills =20 >>> Cc: Dick Hardt ; "oauth@ietf.org" =20 >>> Sent: Thursday, August 9, 2012 11:26 AM >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>=20 >>> In Vancouver the question was asked about the future of the MAC spec du= e to it no linger having a editor. =20 >>>=20 >>> 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. >>>=20 >>> Phil Hunt is going to put together a summery of the Vancouver discussio= n and we are going to work on the use-case/problem description document ASA= P. >>>=20 >>> People are welcome to contribute to the use-case document. >>>=20 >>> Part of the problem with MAC has been that people could never agree on = what it was protecting against. =20 >>>=20 >>> I think there is general agreement that one or more proof mechanisms ar= e required for access tokens. >>> Security for the token endpoint also cannot be ignored.=20 >>>=20 >>>=20 >>> John B. >>>=20 >>> On 2012-08-09, at 1:53 PM, William Mills wrote: >>>=20 >>>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there ar= e libraries out there for OAuth 1.0a. MAC fits in to the OAuth 2 auth mode= l and will provide for a single codepath for sites that want to use both Be= arer and MAC. >>>>=20 >>>> From: Dick Hardt >>>> To: William Mills =20 >>>> Cc: "oauth@ietf.org" =20 >>>> Sent: Thursday, August 9, 2012 10:27 AM >>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>>=20 >>>>=20 >>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>>=20 >>>>> I find the idea of starting from scratch frustrating. MAC solves a s= et of specific problems and has a well defined use case. It's symmetric ke= y 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. >>>>>=20 >>>>> I think it's better to leave them separate and finish out MAC which i= s *VERY CLOSE* to being done. >>>>=20 >>>> Who is interested in MAC? People can use OAuth 1.0 if they prefer that= model.=20 >>>>=20 >>>> For my projects, I prefer the flexibility of a signed or encrypted JWT= if I need holder of key. >>>>=20 >>>> Just my $.02 >>>>=20 >>>> -- Dick =20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>>=20 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From jricher@mitre.org Fri Aug 10 07:38:57 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0B21F8688 for ; Fri, 10 Aug 2012 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XGvOmlvtJYd for ; Fri, 10 Aug 2012 07:38:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEB521F8686 for ; Fri, 10 Aug 2012 07:38:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 038BE21B05B0; Fri, 10 Aug 2012 10:38:55 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D0D2B21B043D; Fri, 10 Aug 2012 10:38:54 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 10:38:54 -0400 From: "Richer, Justin P." To: William Mills Thread-Topic: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Thread-Index: AQHNdoL/SF2cG8V1/E2FdFvBUY4SypdSYPuAgABK5QCAALUhgIAAAMGA Date: Fri, 10 Aug 2012 14:38:53 +0000 Message-ID: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.81] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E067DF35CIMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:38:57 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E067DF35CIMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agreed w/Bill, let's not unnecessarily conflate the problem space. -- Justin On Aug 10, 2012, 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 shoul= d do that separately. ________________________________ From: John Bradley > To: William Mills > Cc: David Waite >; "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 verifica= tion correctly that needs to go in as one of our base assumptions. Or conv= ersely additional protection of the token endpoint needs to be considered f= or 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 > 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 significa= nt value when using an AS that requires HTTPS? Or am I misunderstanding, an= d 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 exte= nd to covering any request data, such as a PUT binary file? Would the integ= rity protection only cover requests, or would you also have integrity prote= ction of the response? -DW On Aug 9, 2012, at 1:37 PM, Justin Richer > 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 pa= rameters to be packed into an extra structure, like JWT/SAML do. TLS gives = no application-layer verification of integrity of parameters, nor does it g= ive you the ability to know who presented those parameters (unless you're d= oing mutual TLS, which nobody does). MAC gives you a fairly simple way to p= rotect 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 paramet= ers in that URL, and protect those parameters with a signature. Then that U= RL can be passed to an untrusted service who cannot modify any portion of i= t. Nor can they re-use the signature portion to protect different parameter= s. We do this today with a 2-legged OAuth signature across a service URL. T= he "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 rep= layable credentials and do not satisfy this need. the MAC scheme using si= gned HTTP authorization credentials offer the capability to securely author= ize a transaction, can offer integrity protection on all or part of an HTTP= request, and can provide replay protection. -bill ________________________________ From: John Bradley To: William Mills Cc: Dick Hardt ; "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 an= d 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 re= quired 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 lib= raries 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 > To: William Mills > Cc: "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 base= d which doesn't work for some folks, and the question is do we try to devel= op something that supports both PK and SK, or finish the SK use case and th= en work on a PK based draft. I think it's better to leave them separate and finish out MAC which is *VER= Y CLOSE* to being done. Who is interested in MAC? People can use OAuth 1.0 if they prefer that mode= l. 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 _______________________________________________ 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 --_000_B33BFB58CCC8BE4998958016839DE27E067DF35CIMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Agreed w/Bill, let's not unnecessarily conflate the problem space.

 -- Justin

On Aug 10, 2012, 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 me= thod for public key than we have now for this to be widely adopted, and I d= on'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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: David Waite <david@alkaline-solutions.com&= gt;; "oauth@ietf.org" <<= a href=3D"mailto:oauth@ietf.org">oauth@ietf.org>
Sent: Thursday, August 9, = 2012 8:47 PM
Subject: Re: [OAUTH-WG] mi= stake in draft-ietf-oauth-v2-http-mac-01

Bill,

I seem to recall in Paris that client misconfiguration of TLS was a co= ncern.

In MAC the token secret is delivered with the token based on server TL= S and HTTP basic authentication.

If this is OK and we trust the client to do TLS server certificate ver= ification correctly that needs to go in as one of our base assumptions. &nb= sp;Or conversely additional protection of the token endpoint needs to be co= nsidered 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 <david@alkaline-solutions= .com>
To: oauth@ietf.org
Sent: Thursday, August 9, 2= 012 4:02 PM
Subject: Re: [OAUTH-WG] mis= take in draft-ietf-oauth-v2-http-mac-01

For #1:
Does the use of plain HTTP to talk to protected resources provide sign= ificant value when using an AS that requires HTTPS? Or am I misunderstandin= g, 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 integ= rity protection of the response?

-DW

On Aug 9, 2012, at 1:37 PM, Justin Richer <jricher@mitre.org> wrote:

Use case #2: signature protectio= n over plain HTTP parameters

MAC gives us message-level signing in a way that doesn't require all the pa= rameters to be packed into an extra structure, like JWT/SAML do. TLS gives = no application-layer verification of integrity of parameters, nor does it g= ive you the ability to know who presented those parameters (unless you're doing mutual TLS, which nobody d= oes). 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 thei= r 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 paramet= ers in that URL, and protect those parameters with a signature. Then that U= RL can be passed to an untrusted service who cannot modify any portion of i= t. 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 t= o 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 o= r 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 integr= ity protection on all or part of an HTTP request, and can provide replay pr= otection.

-bill

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: Dick Hardt <dick.hardt@gmail.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 9, 2= 012 11:26 AM
Subject: Re: [OAUTH-WG] mis= take in draft-ietf-oauth-v2-http-mac-01

In Vancouver the question was asked about the future of the MAC spec d= ue to it no linger having a editor.

The Chair and AD indicated a desire to have a document on the use-case= s 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 discussi= on and we are going to work on the use-case/problem description document AS= AP.

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 a= re 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 th= ere 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.hardt@gmail.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: "oauth@ietf.org" <oauth@i= etf.org>
Sent: Thursday, August 9, 2= 012 10:27 AM
Subject: Re: [OAUTH-WG] mis= take 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 scrat= ch 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 som= e 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.iet= f.org/mailman/listinfo/oauth





_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet=
f.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.or= g/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_B33BFB58CCC8BE4998958016839DE27E067DF35CIMCMBX01MITREOR_-- From jricher@mitre.org Fri Aug 10 07:41:08 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3A21F85FF for ; Fri, 10 Aug 2012 07:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJO1I+Czk9wt for ; Fri, 10 Aug 2012 07:41:07 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1219221F8582 for ; Fri, 10 Aug 2012 07:41:07 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ADE8A21B0406; Fri, 10 Aug 2012 10:41:06 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 96AF821B0499; Fri, 10 Aug 2012 10:41:06 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 10:41:06 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 Thread-Index: AQHNdsX3SF2cG8V1/E2FdFvBUY4SypdTYYAA Date: Fri, 10 Aug 2012 14:41:05 +0000 Message-ID: References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> In-Reply-To: <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D635130402BE14DAC8672A530267443@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:41:08 -0000 What about security in depth? Signing + TLS is more secure than either alon= e, isn't it? -- Justin On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: > Hi Bill,=20 >=20 > thanks for the feedback. Let's have a look at this use case:=20 >=20 > You need to provide me a bit more information regarding your use case. Co= uld you please explain=20 >=20 > 1) Who is authenticated to whom? > 2) What plaintext connection are you talking about?=20 > 3) What is the problem with encrypted connections? Is this again the "TLS= has so bad performance" argument?=20 > 4) Since you are talking about cookies and making them more secure are yo= u trying to come up with a general solution to better cookie security - a t= opic others are working on as well.=20 > 5) What is the threat you are concerned about?=20 >=20 > Ciao > Hannes >=20 > PS: I would heavily argue against standardize a security mechanism that o= ffers weaker protection than bearer when the entire argument has always bee= n "Bearer is so insecure and we need something stronger." >=20 > On Aug 9, 2012, at 9:43 PM, William Mills wrote: >=20 >> OK, I'll play and start documenting the use cases. =20 >>=20 >> Use case #1: Secure authentication in plain text connections: >>=20 >> Some applications need a secure form authorization, but do not want or n= eed 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 aut= horize a transaction, can offer integrity protection on all or part of an H= TTP request, and can provide replay protection. >>=20 >> -bill >>=20 >> From: John Bradley >> To: William Mills =20 >> Cc: Dick Hardt ; "oauth@ietf.org" = =20 >> Sent: Thursday, August 9, 2012 11:26 AM >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>=20 >> In Vancouver the question was asked about the future of the MAC spec due= to it no linger having a editor. >>=20 >> 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 n= ew document. >>=20 >> 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= . >>=20 >> People are welcome to contribute to the use-case document. >>=20 >> Part of the problem with MAC has been that people could never agree on w= hat it was protecting against. =20 >>=20 >> 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.=20 >>=20 >>=20 >> John B. >>=20 >> On 2012-08-09, at 1:53 PM, William Mills wrote: >>=20 >>> 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 Bea= rer and MAC. >>>=20 >>> From: Dick Hardt >>> To: William Mills =20 >>> Cc: "oauth@ietf.org" =20 >>> Sent: Thursday, August 9, 2012 10:27 AM >>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>=20 >>>=20 >>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>=20 >>>> I find the idea of starting from scratch frustrating. MAC solves a se= t 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 a= nd then work on a PK based draft. >>>>=20 >>>> I think it's better to leave them separate and finish out MAC which is= *VERY CLOSE* to being done. >>>=20 >>> Who is interested in MAC? People can use OAuth 1.0 if they prefer that = model.=20 >>>=20 >>> For my projects, I prefer the flexibility of a signed or encrypted JWT = if I need holder of key. >>>=20 >>> Just my $.02 >>>=20 >>> -- Dick =20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills_92105@yahoo.com Fri Aug 10 07:42:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE0221F8681 for ; Fri, 10 Aug 2012 07:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDA3fb-xDMMD for ; Fri, 10 Aug 2012 07:42:45 -0700 (PDT) Received: from nm29.bullet.mail.sp2.yahoo.com (nm29.bullet.mail.sp2.yahoo.com [98.139.91.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6F50521F8680 for ; Fri, 10 Aug 2012 07:42:45 -0700 (PDT) Received: from [98.139.91.68] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 14:42:42 -0000 Received: from [72.30.22.33] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 14:42:42 -0000 Received: from [127.0.0.1] by omp1061.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 14:42:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 876280.90680.bm@omp1061.mail.sp2.yahoo.com Received: (qmail 60669 invoked by uid 60001); 10 Aug 2012 14:42:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344609762; bh=aGvA5MlDe8slwREHplGy+bBu9VCO2h6ASbFAwfiVGTo=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kpFYTM4TsJuoMELi0kc7jONmUCot/5kFvyMr4Lxx+APMQT+TYkvAivK/ZIH2u5nPO8KFQZ6HWJMYjRouHwKMRUsHxAfgeU0FgLyBMQoT13hn31MlMGItnTW8Pjj3IIcea7dKFoGzjJf/6A7Rc92JMxQO5w/MxyioDFjqk20UrvQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Hs7whSPpmtT4GO9j2svrrSfYazQR/o90vOpQOhVlOHsAYudia+f7vJifZzkBMv/okcB3PH39S/YwE7maGVen3fQsg+I0eHusAakQOsYgrx3UHmVt3WMniCdS+IB45qptXRePyXyDy2BaUswA6jImZlO1HsdaqYNK6dDd4khUS8k=; X-YMail-OSG: MfBJfFQVM1l9FQUD3yj00qGKYmt8_ndtPqYc.VjsdsYI3B3 Fb7RBZgafMfBTPaXpj_7BH_.F42GnM2q0spUlFImtNOBZXNma3l4R8hLDfJr MWkmWlG17Fixc36OcNEx7P9EzRcJLT0AYH_vO0fVBMf_69ma11OkfqHAqyBF UY0iE6_PAMjCQdtlQambEJU7IRMNmDG7DQCAesbjVRGax2HSuwF959P70_WP FbzVfOmXQxQtQTNmisJN0TqTkO8rt1MHcuswR.2qOkT_wT4NPAlLBrKdHlTm ZKPL.el6LEnRdyY0tAhl_sHA4rumYSYuhkWDBvy6HAtT6KkB5M3G9e0rSP1Z cDpjdggk97lX3ko4ky4kZ_YSUTqtYGQJhEcWxt.PXrI5HXq4V.88T6liqqJB oiDbRXEguE89CSfTe.UVfgdMRaPxe.xdGkAoIeBsrpwRt_A0vX17dj79sgR3 32owq_JXi4QNrgdRcbs3DkaxcDCpeNlSVhaCGvWNCWXt7o8V5zXPJMClTb9w - Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 07:42:42 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> Message-ID: <1344609762.59093.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 07:42:42 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:42:46 -0000 =0A=0A=0A=0A________________________________=0AFrom: Hannes Tschofenig =0ATo: William Mills =0ACc:= Hannes Tschofenig ; John Bradley ; "oauth@ietf.org" =0ASent: Friday, August 10, 2012 1= 2:01 AM=0ASubject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-0= 1=0A=0AHi Bill, =0A=0Athanks for the feedback. Let's have a look at this us= e case: =0A=0AYou need to provide me a bit more information regarding your = use case. Could you please explain =0A=0A1) Who is authenticated to whom?= =0A=0A=0Awjm> the client is authenticated to the server.=0A=0A2) What plain= text connection are you talking about?=A0=0A=0Awjm> generally an HTTP conne= ction to a webservice=0A=0A3) What is the problem with encrypted connection= s? Is this again the "TLS has so bad performance" argument?=A0=0A=0A=0Awjm>= =A0Yes, annoying but true. =A0This may change, but we do business with eno= ugh folks that refuse SSL that this is a real problem.=0A=0A4) Since you ar= e 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 w= orking on as well.=A0=0A=0Awjm> =A0No, I'm pointing out the problems with a= simple replayable credential like cookies as a comparison.=0A=0A5) What is= the threat you are concerned about? =0A=0Awjm> The vulnerability of plaint= ext connections: theft of credentials and tampering.=A0=0A=0ACiao=0AHannes= =0A=0APS: I would heavily argue against standardize a security mechanism th= at offers weaker protection than bearer when the entire argument has always= been "Bearer is so insecure and we need something stronger."=0A=0AOn Aug 9= , 2012, at 9:43 PM, William Mills wrote:=0A=0A> OK, I'll play and start doc= umenting the use cases.=A0 =0A> =0A> Use case #1: Secure authentication in = plain text connections:=0A> =0A> Some applications need a secure form autho= rization, but do not want or need the overhead of encrypted connections.=A0= HTTP cookies and their ilk are replayable credentials and do not satisfy t= his need.=A0=A0=A0the MAC scheme using signed HTTP authorization credential= s offer the capability to securely authorize a transaction, can offer integ= rity protection on all or part of an HTTP request, and can provide replay p= rotection.=0A> =0A> -bill=0A> =0A> From: John Bradley = =0A> To: William Mills =0A> Cc: Dick Hardt ; "oauth@ietf.org" =0A> Sent: Thursday, Aug= ust 9, 2012 11:26 AM=0A> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oaut= h-v2-http-mac-01=0A> =0A> In Vancouver the question was asked about the fut= ure of the MAC spec due to it no linger having a editor.=0A> =0A> The Chair= and AD indicated a desire to have a document on the use-cases we are tryin= g to address before deciding on progressing MAC or starting a new document.= =0A> =0A> Phil Hunt is going to put together a summery of the Vancouver dis= cussion and we are going to work on the use-case/problem description docume= nt ASAP.=0A> =0A> People are welcome to contribute to the use-case document= .=0A> =0A> Part of the problem with MAC has been that people could never ag= ree on what it was protecting against.=A0 =0A> =0A> I think there is genera= l agreement that one or more proof mechanisms are required for access token= s.=0A> Security for the token endpoint also cannot be ignored. =0A> =0A> = =0A> John B.=0A>=A0 =0A> On 2012-08-09, at 1:53 PM, William Mills wrote:=0A= > =0A>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there= are libraries out there for OAuth 1.0a.=A0 MAC fits in to the OAuth 2 auth= model and will provide for a single codepath for sites that want to use bo= th Bearer and MAC.=0A>> =0A>> From: Dick Hardt =0A>> = To: William Mills =0A>> Cc: "oauth@ietf.org" =0A>> Sent: Thursday, August 9, 2012 10:27 AM=0A>> Subject: Re:= [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A>> =0A>> =0A>> On = Aug 9, 2012, at 9:52 AM, William Mills wrote:=0A>> =0A>>> I find the idea o= f starting from scratch frustrating.=A0 MAC solves a set of specific proble= ms and has a well defined use case.=A0 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.=0A>>> =0A>>> I think it's better to leave them separate and= finish out MAC which is *VERY CLOSE* to being done.=0A>> =0A>> Who is inte= rested in MAC? People can use OAuth 1.0 if they prefer that model. =0A>> = =0A>> For my projects, I prefer the flexibility of a signed or encrypted JW= T if I need holder of key.=0A>> =0A>> Just my $.02=0A>> =0A>> -- Dick=A0 = =0A>> =0A>> =0A>> =0A>> _______________________________________________=0A>= > OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/= listinfo/oauth=0A> =0A> =0A> =0A> _________________________________________= ______=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/oauth From jricher@mitre.org Fri Aug 10 07:49:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D96521F8644 for ; Fri, 10 Aug 2012 07:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcdyfuUN5j9A for ; Fri, 10 Aug 2012 07:49:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EFE0221F8623 for ; Fri, 10 Aug 2012 07:49:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9429521C003F; Fri, 10 Aug 2012 10:49:26 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BCF321B0302; Fri, 10 Aug 2012 10:49:26 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.151]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0309.002; Fri, 10 Aug 2012 10:49:26 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] MAC Discussion Thread-Index: AQHNdsX3Q5Km15GrhUWrw/RLZ+jq3pdTZC2A Date: Fri, 10 Aug 2012 14:49:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <4342AAB630D0804D87FE5E99544F7375@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] MAC Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:49:28 -0000 On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote: > Justin wrote:=20 > " > I believe that there's value in per-message signing completely apart from= the channel level encryption.=20 > " >=20 > May well be. But we have to figure out what exactly the reasons are why t= here is value.=20 Yes, there is value in this, and that's why we're collecting a handful of u= se cases to support this. Otherwise, people wouldn't keep reinventing this.= See SAML and OpenID Connect's signed request object for other examples. >=20 > Bill wrote: > " > I find the idea of starting from scratch frustrating. MAC solves a set of= specific problems and has a well defined use case. > " >=20 > This would be a very quick process if we had ever done our home work prop= erly.=20 It's not done, but it's not empty. Why throw it out? Whether or not we cont= inue the draft itself or import its best ideas into a new draft is beside t= he point. >=20 > So, what are the problems it tries to solve? Yesterday I found an old pre= sentation about MAC and the basic argument was that it has better performan= ce than TLS. While that's true it is not a good argument per se. However, p= erformance is not the only factor to look at and the negative performance i= mpact caused by TLS is overrated. =20 This is a red herring, as pointed out by other use cases. >=20 > Here is the slide set I am talking about:=20 > http://www.tschofenig.priv.at/Why_are_we_Signing.pdf >=20 > In many cases I had noticed that more time was spent with the pictures (i= n slides and blog post) than with the content. That's not good IMHO.=20 >=20 > Bill, we can hardly call a specification "complete" if many of us don't k= now what problem it solves. John phrases it nicely as "Part of the problem = with MAC has been that people could never agree on what it was protecting a= gainst." I am also interested in hearing about deployment constraints that = people have. Blaine always said that many developers cannot get TLS to work= . I am sure that's true but OAuth 2.0 requires TLS to be used anyway to sec= ure the interaction with the authorization server.=20 It solves this problem: How can I use the framework of OAuth to get a tempo= rary signing key that I can use to protect HTTP messages with signing (with= out stuffing my parameters into a structured document like a SAML or JWT as= sertion)? There are many justifications for that problem and use cases that= expand on this, but that's the core thing that the MAC does. >=20 > Note: I am not saying that we are not going to standardize something like= the MAC token (maybe with different details) but let us spend a little bit= of time to figure out what threats we want to deal with.=20 It's not just about threats, it's about capabilities and features.=20 -- Justin >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rrichards@cdatazone.org Fri Aug 10 08:00:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1469921F861D for ; Fri, 10 Aug 2012 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b41P--grhYY for ; Fri, 10 Aug 2012 08:00:43 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0D21F8441 for ; Fri, 10 Aug 2012 08:00:36 -0700 (PDT) Message-ID: <50252211.2010105@cdatazone.org> Date: Fri, 10 Aug 2012 11:00:33 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:00:44 -0000 I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution. Rob On 8/10/12 10:41 AM, Richer, Justin P. wrote: > What about security in depth? Signing + TLS is more secure than either alone, isn't it? > > -- Justin > > On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: > >> 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? >> 2) What plaintext connection are you talking about? >> 3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument? >> 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. >> 5) What is the threat you are concerned about? >> >> 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 >>> To: William Mills >>> Cc: Dick Hardt ; "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 >>>> To: William Mills >>>> Cc: "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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From ve7jtb@ve7jtb.com Fri Aug 10 08:08:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E028221F85E7 for ; Fri, 10 Aug 2012 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn-f0nAhTv2X for ; Fri, 10 Aug 2012 08:08:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED0B21F84DA for ; Fri, 10 Aug 2012 08:08:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so1821181yhq.31 for ; Fri, 10 Aug 2012 08:08:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=lx70JVLK8YCRGx4GvWUwQ9w9jDCSKAUXDBVGrmfj/O4=; b=cImMGJ8EO2LoXQPZ9KIomTaAgUZ4k7vk5K/Utjy02YopGNlh0bLj0lzMVKxsbJU5Mw cHDh6EGkM/4+I0PqPlZ+uB1EA9nDg4U7cR+hjt76uTgGthU0MV6pZCoAFRQ5wDREEMQH Y7xtUQSFi3Rak0fmhetYshuUppSNIV24joXeIizf5hRtuqzTCODR7fvqvDLEZc+S6DBQ xbVjpT6UEebNTm0UATjL1VqwctHj0xReECgiAssg9racjfTn1eD9R7ySII3jUfzqP3z+ /xGD0UiIQrQdSzeSZL6zJ+a8whmwSwku6BiDzDqTTr9FoJwIfHUM29gvYNcftaAEI1Vh ayDg== Received: by 10.101.180.34 with SMTP id h34mr961995anp.69.1344611307679; Fri, 10 Aug 2012 08:08:27 -0700 (PDT) Received: from [192.168.1.211] (190-20-39-163.baf.movistar.cl. [190.20.39.163]) by mx.google.com with ESMTPS id t20sm3677934anl.19.2012.08.10.08.08.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 08:08:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E4E802C6-6E2F-4ADA-A0F9-106FF1AC4C2D"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 11:09:10 -0400 Message-Id: <47A03274-9F23-40A6-B321-CB7044C0FA4B@ve7jtb.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlWW8gbAhxwIsZHl+xJUHGktJnTwLUpgeWdKRut9NiPhwA5nOxDvsmUq680kD2I/HYuxBbT Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:08:30 -0000 --Apple-Mail=_E4E802C6-6E2F-4ADA-A0F9-106FF1AC4C2D Content-Type: multipart/alternative; boundary="Apple-Mail=_5128F3A3-35CB-43AF-825B-74E0C9352260" --Apple-Mail=_5128F3A3-35CB-43AF-825B-74E0C9352260 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. =20 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. >=20 > If we're gonna improve on the current PKI that is SSL certificates we = should do that separately. >=20 > From: John Bradley > To: William Mills =20 > Cc: David Waite ; "oauth@ietf.org" = =20 > Sent: Thursday, August 9, 2012 8:47 PM > Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >=20 > Bill, >=20 > I seem to recall in Paris that client misconfiguration of TLS was a = concern. >=20 > In MAC the token secret is delivered with the token based on server = TLS and HTTP basic authentication. >=20 > 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. >=20 > John B. > On 2012-08-09, at 7:19 PM, William Mills wrote: >=20 >> AS would still be required to be HTTPS as per the spec. >>=20 >> From: David Waite >> To: oauth@ietf.org=20 >> Sent: Thursday, August 9, 2012 4:02 PM >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>=20 >> 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? >>=20 >> 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? >>=20 >> -DW >>=20 >> On Aug 9, 2012, at 1:37 PM, Justin Richer wrote: >>=20 >>> Use case #2: signature protection over plain HTTP parameters >>>=20 >>> 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. >>>=20 >>>=20 >>> Use case #3: generic signed HTTP fetch (not directly addressed by = MAC spec as of today) >>>=20 >>> 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. >>>=20 >>>=20 >>> -- Justin >>>=20 >>> On 08/09/2012 02:43 PM, William Mills wrote: >>>> OK, I'll play and start documenting the use cases. =20 >>>>=20 >>>> Use case #1: Secure authentication in plain text connections: >>>>=20 >>>> 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. >>>>=20 >>>> -bill >>>>=20 >>>> From: John Bradley >>>> To: William Mills =20 >>>> Cc: Dick Hardt ; "oauth@ietf.org" = =20 >>>> Sent: Thursday, August 9, 2012 11:26 AM >>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>>=20 >>>> In Vancouver the question was asked about the future of the MAC = spec due to it no linger having a editor. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> People are welcome to contribute to the use-case document. >>>>=20 >>>> Part of the problem with MAC has been that people could never agree = on what it was protecting against. =20 >>>>=20 >>>> 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.=20 >>>>=20 >>>>=20 >>>> John B. >>>> =20 >>>> On 2012-08-09, at 1:53 PM, William Mills wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> From: Dick Hardt >>>>> To: William Mills =20 >>>>> Cc: "oauth@ietf.org" =20 >>>>> Sent: Thursday, August 9, 2012 10:27 AM >>>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>>>=20 >>>>>=20 >>>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I think it's better to leave them separate and finish out MAC = which is *VERY CLOSE* to being done. >>>>>=20 >>>>> Who is interested in MAC? People can use OAuth 1.0 if they prefer = that model.=20 >>>>>=20 >>>>> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>>>>=20 >>>>> Just my $.02 >>>>>=20 >>>>> -- Dick =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 --Apple-Mail=_5128F3A3-35CB-43AF-825B-74E0C9352260 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com> =
Cc: David Waite = <david@alkaline-solutions.com<= /a>>; "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 <david@alkaline-solutions.com<= /a>>
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 <jricher@mitre.org> = wrote:

= =20 =20 =20
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:
=20
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.

From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com> =
Cc: Dick Hardt <dick.hardt@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.hardt@gmail.com>
To: William Mills <wmills_92105@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


_____= __________________________________________
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


=

= --Apple-Mail=_5128F3A3-35CB-43AF-825B-74E0C9352260-- --Apple-Mail=_E4E802C6-6E2F-4ADA-A0F9-106FF1AC4C2D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx MDE1MDkxMVowIwYJKoZIhvcNAQkEMRYEFP/VgrVibAG7EwRLXGgVhF/Y3e4aMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFJqBDywbtEdMEIT6ZkEDWanTZowU/16Q+s7Na/Nrqho0CSUPru3qcuzcQWwsGFHjV+XNrni0OfC 9TtMly9KlUQIZJruFtMoFjuiw5KqswM1sRXMdxdsE0WhIiqalXALB5WXSw+dq4tbckNLShZypiMq 8HppF7IqF/rzVxGtR7X/tEhfgVQb7Gnm51KEDkJPxrS2AWPYDd2oKLJx2Roy4kRpw8UUIPc3XpVM 7yyoYBRWYXHygHbtydHolTD4RSf6P91vufrOMAVz8Y1+jf35sC6m2EoCTZDC4S5DxCuDKJE3/IfK HIbW+GeLeQq/pkLkIM+N66qGZ+77I1p3Mz7wcnoAAAAAAAA= --Apple-Mail=_E4E802C6-6E2F-4ADA-A0F9-106FF1AC4C2D-- From wmills_92105@yahoo.com Fri Aug 10 08:59:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E464221F86C8 for ; Fri, 10 Aug 2012 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWHWTVisXqZ8 for ; Fri, 10 Aug 2012 08:59:30 -0700 (PDT) Received: from nm21-vm0.bullet.mail.bf1.yahoo.com (nm21-vm0.bullet.mail.bf1.yahoo.com [98.139.213.137]) by ietfa.amsl.com (Postfix) with ESMTP id 067B621F86A0 for ; Fri, 10 Aug 2012 08:59:29 -0700 (PDT) Received: from [98.139.212.144] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 10 Aug 2012 15:59:29 -0000 Received: from [98.139.212.220] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 10 Aug 2012 15:59:29 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 10 Aug 2012 15:59:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 367207.11091.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 16064 invoked by uid 60001); 10 Aug 2012 15:59:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344614368; bh=lnzbO1vLi5vgwW2PEXZpDY0ydNyByXPxaVdmDicAUEA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yTS0QEIKjnBplh5IqPwBi2AwqB/1K0kGi/7E7tO8JifkEjinBTg9SGwb/DXA+GTHqM8TIeUlm32Ed29bAyCUx8WKn+Gakbc70bC5CU0Jz1qAk2GlKYHWwHKdSjIQgtpdmkzasrQ1aNTvPqAwzTxUMilVKXuQI0jgSawsKNHt0DE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=uBbL8kWHZuImq69iPt4yn8LQk/maItcZxqEbj4qB5kqvs6EF2Cq3dGnPnI6IklHVyNy2DXJkUTVuCRPgKoh+wisnz6THNGK9SecWxZVXO3aN97Njjvfn02i04IXc2fWy60DG4+5uq45J9UFpaaLwRpezHK7hgFomONHMA5ViweI=; X-YMail-OSG: hT5uIscVM1m0r9KoI_S_FjdqLeINUlNUYOlL_Qvw78VCf09 gubRiihrD1PX7HVQuYqf3TFYoOQZl7De5FS8NWl3tlcaiAkCZkSHonFOxXSP KlR74DF3CfAcXPMSzfkTQp_o75QLGsYBnwsLmLM56sblbH2sD48CLu9o7PzQ fmPshhRladf4M9A8lhFA1FJsXulV9.GLdVTmuoPPEBd1jFJNWKeHmNOS0q3x gwoqboGrH.Soh1Gzg27vgcKKPZOMjMOFJBie9a.0YRGOuO0NZCy9HAYqfl4l GQLU22osD3Cak8afpwpioo9Zy4Daw52PJRsQcHALOT7eN_sOCbgyCnvQ2wU_ CQuF3VePhb.Cu1VKdjq8Hs_7bHOiNLyj4O27VUalqvlsbuhhzvRJlR0QXBRj wcqKtmNELx7sXHSRe8vz6GWZ.XQzivheTOrDGHoZlddPA1Njo4W0k3J935Ct ejWacP70.yjKgRuXdVB2m09bAFdvgIcGzp0pp7tyPBd6pkhv4NjxQePM0z_4 yezVau9jneXetd70CCEt7 Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 08:59:27 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> <47A03274-9F23-40A6-B321-CB7044C0FA4B@ve7jtb.com> Message-ID: <1344614367.16061.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 08:59:27 -0700 (PDT) From: William Mills To: John Bradley In-Reply-To: <47A03274-9F23-40A6-B321-CB7044C0FA4B@ve7jtb.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-315314306-1344614367=:16061" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:59:32 -0000 --767760015-315314306-1344614367=:16061 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It's not intended to address anything in TLS other than the fact that we ha= ve real use cases where TLS isn't in play. =A0=0A=0A=0A=0A_________________= _______________=0A From: John Bradley =0ATo: William Mil= ls =0ACc: David Waite ; "oauth@ietf.org" =0ASent: Friday, August 10, 2012 8:09= AM=0ASubject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A= =0A=0ANo I wasn't talking about changing TLS. =A0I think the TLS threat ha= s been expressed more as people who turn verification in the client rather = than any failure of the TLS protocol or certificates.=0A=0AThe question I w= as trying to get at was if any of the message signing was intended to prote= ct against clients misconfiguring TLS or Man in the middle attacking commun= ications with the RS or token server.=0A=0APart of the reason behind MAC ha= s been expressed as concern that Server TLS doesn't prevent tokens from bei= ng intercepted and replayed sufficiently. =A0=A0=0A=0AWhere TLS is used if = we believe clients are properly implemented what is the signing getting us.= =0A=0AI think sessions without TLS and TLS terminated on the firewall need = to be supported, but there the threat is clearer.=0A=0AJohn=0A=0A=0AOn 2012= -08-10, at 10:36 AM, William Mills wrote:=0A=0AI would say that's true in t= heory, but practically speaking it's not gonna happen. =A0You're stating we= need to come up with a better method for public key than we have now for t= his to be widely adopted, and I don't think that's reasonable.=0A>=0A>=0A>I= f we're gonna improve on the current PKI that is SSL certificates we should= do that separately.=0A>=0A>=0A>=0A>________________________________=0A> Fr= om: John Bradley =0A>To: William Mills =0A>Cc: David Waite ; "oauth@ietf.org= " =0A>Sent: Thursday, August 9, 2012 8:47 PM=0A>Subject: R= e: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A> =0A>=0A>Bill,= =0A>=0A>=0A>I seem to recall in Paris that client misconfiguration of TLS w= as a concern.=0A>=0A>=0A>In MAC the token secret is delivered with the toke= n based on server TLS and HTTP basic authentication.=0A>=0A>=0A>If this is = OK and we trust the client to do TLS server certificate verification correc= tly that needs to go in as one of our base assumptions. =A0Or conversely ad= ditional protection of the token endpoint needs to be considered for key di= stribution.=0A>=0A>=0A>John B.=0A>=0A>On 2012-08-09, at 7:19 PM, William Mi= lls wrote:=0A>=0A>AS would still be required to be HTTPS as per the spec.= =0A>>=0A>>=0A>>=0A>>________________________________=0A>> From: David Waite= =0A>>To: oauth@ietf.org =0A>>Sent: Thursday,= August 9, 2012 4:02 PM=0A>>Subject: Re: [OAUTH-WG] mistake in draft-ietf-o= auth-v2-http-mac-01=0A>> =0A>>=0A>>For #1:=0A>>Does the use of plain HTTP t= o talk to protected resources provide significant value when using an AS th= at requires HTTPS? Or am I misunderstanding, and this use case would also i= nclude new modes for non-TLS communication with the AS?=0A>>=0A>>=0A>>For #= 2:=0A>>Would the signature protection just cover HTTP parameters, or would = it extend to covering any request data, such as a PUT binary file?=A0Would = the integrity protection only cover requests, or would you also have integr= ity protection of the response?=0A>>=0A>>=0A>>-DW=0A>>=0A>>=0A>>On Aug 9, 2= 012, at 1:37 PM, Justin Richer wrote:=0A>>=0A>>Use case= #2: signature protection over plain HTTP parameters=0A>>>=0A>>>MAC gives u= s message-level signing in a way that doesn't require=0A all the param= eters to be packed into an extra structure, like=0A JWT/SAML do. TLS g= ives no application-layer verification of=0A integrity of parameters, = nor does it give you the ability to know=0A who presented those parame= ters (unless you're doing mutual TLS,=0A which nobody does). MAC gives= you a fairly simple way to protect=0A all parameters on a call to the= resource server while still=0A keeping all of those parameters in the= ir native HTTP forms.=0A>>>=0A>>>=0A>>>Use case #3: generic signed HTTP fet= ch (not directly addressed by=0A MAC spec as of today)=0A>>>=0A>>>Some= times you want to create a URL with one service, fix all of=0A the par= ameters in that URL, and protect those parameters with a=0A signature.= Then that URL can be passed to an untrusted service who=0A cannot mod= ify any portion of it. Nor can they re-use the signature=0A portion to= protect different parameters. We do this today with a=0A 2-legged OAu= th signature across a service URL. The "Client"=0A generates the signe= d URLs and passes them to a user agent which=0A actually does the fetc= h to the service.=0A>>>=0A>>>=0A>>>=A0-- Justin=0A>>>=0A>>>On 08/09/2012 02= :43 PM, William Mills wrote:=0A>>>=0A>>>OK, I'll play and start documenting= the use cases. =A0=0A>>>>=0A>>>>=0A>>>>Use case #1:=A0Secure authenticatio= n in plain text connections:=0A>>>>=0A>>>>=0A>>>>Some applications need a s= ecure form authorization, but do not want or need the overhead of encrypted= connections. =A0HTTP cookies and their ilk are replayable credentials and = do not satisfy this need. =A0 the MAC scheme using signed HTTP authorizatio= n credentials offer the capability to securely authorize a transaction, can= offer integrity protection on all or part of an HTTP request, and can prov= ide replay protection.=0A>>>>=0A>>>>=0A>>>>-bill=0A>>>>=0A>>>>=0A>>>>=0A>>>= >________________________________=0A>>>> From: John Bradley =0A>>>>To: William Mills =0A>>>>Cc: Dick Hardt= ; "oauth@ietf.org" =0A>>>>Sent: Thu= rsday, August 9, 2012 11:26 AM=0A>>>>Subject: Re: [OAUTH-WG] mistake in dra= ft-ietf-oauth-v2-http-mac-01=0A>>>> =0A>>>>=0A>>>>In Vancouver the question= was asked about the future of the MAC spec due to it no linger having a ed= itor. =0A>>>>=0A>>>>=0A>>>>The Chair and AD indicated a desire to have a do= cument on the use-cases we are trying to address before deciding on progres= sing MAC or starting a new document.=0A>>>>=0A>>>>=0A>>>>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.=0A>>>>=0A>>>>=0A>>>= >People are welcome to contribute to the use-case document.=0A>>>>=0A>>>>= =0A>>>>Part of the problem with MAC has been that people could never agree = on what it was protecting against. =A0=0A>>>>=0A>>>>=0A>>>>I think there is= general agreement that one or more proof mechanisms are required for acces= s tokens.=0A>>>>Security for the token endpoint also cannot be ignored.=A0= =0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>John B.=0A>>>>=A0=0A>>>>=0A>>>>On 2012-0= 8-09, at 1:53 PM, William Mills wrote:=0A>>>>=0A>>>>MAC fixes the signing p= roblems encountered in OAuth 1.0a, yes there are libraries out there for OA= uth 1.0a. =A0MAC fits in to the OAuth 2 auth model and will provide for a s= ingle codepath for sites that want to use both Bearer and MAC.=0A>>>>>=0A>>= >>>=0A>>>>>=0A>>>>>________________________________=0A>>>>> From: Dick Hard= t =0A>>>>>To: William Mills = =0A>>>>>Cc: "oauth@ietf.org" =0A>>>>>Sent: Thursday, Augus= t 9, 2012 10:27 AM=0A>>>>>Subject: Re: [OAUTH-WG] mistake in draft-ietf-oau= th-v2-http-mac-01=0A>>>>> =0A>>>>>=0A>>>>>=0A>>>>>=0A>>>>>On Aug 9, 2012, a= t 9:52 AM, William Mills wrote:=0A>>>>>=0A>>>>>I find the idea of starting = from scratch frustrating. =A0MAC solves a set of specific problems and has = a well defined use case. =A0It's symmetric key based which doesn't work for= some folks, and the question is do we try to develop something that suppor= ts both PK and SK, or finish the SK use case and then work on a PK based dr= aft.=0A>>>>>>=0A>>>>>>=0A>>>>>>I think it's better to leave them separate a= nd finish out MAC which is *VERY CLOSE* to being done.=0A>>>>>=0A>>>>>Who i= s interested in MAC? People can use OAuth 1.0 if they prefer that model.=A0= =0A>>>>>=0A>>>>>=0A>>>>>For my projects, I prefer the flexibility of a sign= ed or encrypted JWT if I need holder of key.=0A>>>>>=0A>>>>>=0A>>>>>Just my= $.02=0A>>>>>=0A>>>>>=0A>>>>>-- Dick =A0=0A>>>>>=0A>>>>>=0A>>>>>=0A________= _______________________________________=0A>>>>>OAuth mailing list=0A>>>>>OA= uth@ietf.org=0A>>>>>https://www.ietf.org/mailman/listinfo/oauth=0A>>>>>=0A>= >>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>_____________________________________= __________=0AOAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman= /listinfo/oauth =0A>>>=0A_______________________________________________=0A= >>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.org/mailman= /listinfo/oauth=0A>>>=0A>>=0A>>____________________________________________= ___=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mail= man/listinfo/oauth=0A>>=0A>>=0A>>__________________________________________= _____=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.org/ma= ilman/listinfo/oauth=0A>>=0A>=0A>=0A> --767760015-315314306-1344614367=:16061 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It's not intended to address = anything in TLS other than the fact that we have real use cases where TLS i= sn't in play.  


From: John Bradley <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105= @yahoo.com>
Cc: Dav= id Waite <david@alkaline-solutions.com>; "oauth@ietf.org" <oauth@i= etf.org>
Sent: Fri= day, August 10, 2012 8:09 AM
Subj= ect: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

=0A
No I wasn't talking= about changing TLS.  I think the TLS threat has been expressed more a= s 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 agains= t clients misconfiguring TLS or Man in the middle attacking communications = with the RS or token server.

Part of the reason be= hind MAC has been expressed as concern that Server TLS doesn't prevent toke= ns from being intercepted and replayed sufficiently.   

Where TLS is used if we believe clients are properly implem= ented what is the signing getting us.

I think sess= ions without TLS and TLS terminated on the firewall need to be supported, b= ut there the threat is clearer.

John
On 2012-08-10, at 10:36 AM, William Mills wrote:


If we're gonna improve on the current = PKI that is SSL certificates we should do that separately.

<= div style=3D"font-family: times, serif; font-size: 12pt; ">
=
From: John Bradley <ve7jtb@ve7jtb.com>
T= o: William Mills <wmills_92105@yahoo.com>
Cc= : David Waite <david@alkaline-solutions.com>; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 9, 2012 8:47 PM Subject: Re: [OAUTH-WG] m= istake in draft-ietf-oauth-v2-http-mac-01

=0A
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 an= d HTTP basic authentication.

If this is OK and we = trust the client to do TLS server certificate verification correctly that n= eeds to go in as one of our base assumptions.  Or conversely additiona= l protection of the token endpoint needs to be considered for key distribut= ion.

John B.
On 2012-08-09, at 7:19 P= M, William Mills wrote:

AS would still be required to be HTTPS as= per the spec.

From: David W= aite <david@alka= line-solutions.com>
To: oauth@ietf.org
Sent: Thursday, August 9, 2012 4:02 PM Subject: Re: [OAUTH-WG] m= istake in draft-ietf-oauth-v2-http-mac-01

=0A
For #1:
Does the use of plain HTTP t= o talk to protected resources provide significant value when using an AS th= at requires HTTPS? Or am I misunderstanding, and this use case would also i= nclude new modes for non-TLS communication with the AS?

For #2:
Would the signature protection just cover HTTP para= meters, or would it extend to covering any request data, such as a PUT bina= ry 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 Rich= er <jricher@mitre.org> wrote:
=0A =0A =0A =0A
=0A
Use case #2: signature protection over=0A plain HTTP para= meters
=0A
=0A MAC gives us message-level signing in a way= that doesn't require=0A all the parameters to be packed into an extra= structure, like=0A JWT/SAML do. TLS gives no application-layer verifi= cation of=0A integrity of parameters, nor does it give you the ability= to know=0A who presented those parameters (unless you're doing mutual= TLS,=0A which nobody does). MAC gives you a fairly simple way to prot= ect=0A all parameters on a call to the resource server while still=0A = keeping all of those parameters in their native HTTP forms.
=0A =
=0A
=0A Use case #3: generic signed HTTP fetch (not dir= ectly addressed by=0A MAC spec as of today)
=0A
=0A S= ometimes you want to create a URL with one service, fix all of=0A the = parameters in that URL, and protect those parameters with a=0A signatu= re. Then that URL can be passed to an untrusted service who=0A cannot = modify any portion of it. Nor can they re-use the signature=0A portion= to protect different parameters. We do this today with a=0A 2-legged = OAuth signature across a service URL. The "Client"=0A generates the si= gned URLs and passes them to a user agent which=0A actually does the f= etch to the service.
=0A
=0A
=0A  -- Justin<= br>=0A
=0A On 08/09/2012 02:43 PM, William Mills wrote:
= =0A
=0A
=0A =0A
=0A
OK,= I'll play and start documenting the use cases.  
=0A =

=0A
= =0A
Use case #1: Secure=0A authe= ntication in plain text connections:
=0A

=0A
=0A
Some applications=0A need a s= ecure form authorization, but do not want or need=0A the overhea= d of encrypted connections.  HTTP cookies and=0A their ilk = are replayable credentials and do not satisfy this=0A need. &nbs= p; the MAC scheme using signed HTTP authorization=0A credentials= offer the capability to securely authorize a=0A transaction, ca= n offer integrity protection on all or part=0A of an HTTP reques= t, and can provide replay protection.
=0A

=0A
=0A
-bill
=0A

= =0A
=0A
=0A
=0A
=0A
Fr= om:=0A John Bradley <ve7jtb@ve7jtb.com>=
=0A To:<= /b>=0A William Mills <wmills_92105@yahoo.c= om>
=0A Cc:<= /span> Dick=0A Hardt <dick.hardt@gmail.com&= gt;; "oauth@ietf.org"=0A <oauth@ietf.org>
= =0A Sent:=0A= Thursday, August 9, 2012 11:26 AM
=0A = Subject:=0A Re:= [OAUTH-WG] mistake in=0A draft-ietf-oauth-v2-http-mac-01=0A
=0A
=0A
=0A
In Vancouver the question was aske= d about the future=0A of the MAC spec due to it no linger ha= ving a editor.=0A

=0A
=0A =
The Chair and AD indicated a desire to have a=0A = document on the use-cases we are trying to address=0A = before deciding on progressing MAC or starting a new=0A = document.
=0A

=0A
=0A =
Phil Hunt is going to put together a summery of the=0A = Vancouver discussion and we are going to work on the=0A = use-case/problem description document ASAP.
=0A =

=0A
=0A
People are = welcome to contribute to the use-case=0A document.
= =0A

=0A
=0A Part of the problem with MAC has been that people=0A cou= ld never agree on what it was protecting against.  
=0A =

=0A
=0A
I think the= re is general agreement that one or more=0A proof mechanis= ms are required for access tokens.
=0A
Security fo= r the token endpoint also cannot be=0A ignored. =0A

=0A
=0A
=0A
=0A
John B.
=0A =
 
=0A
=0A =
On 2012-08-09, at 1:53 PM, William Mills wrote:
=0A =
=0A =
=0A
=0A =
=0A
=0A
=0A =
From:= =0A Dick Hardt <dick.hardt@gmail.com>
=0A = To:=0A = William Mills <wmills_92105@yahoo.com>=0A =
=0A Cc:=0A "oauth@ietf.org"=0A <oauth@ietf.org>=0A =
=0A Sent:=0A Thursday, A= ugust 9, 2012 10:27 AM
=0A Subject:=0A = Re: [OAUTH-WG] mistake in=0A draft-i= etf-oauth-v2-http-mac-01
=0A =0A
=0A =0A

=0A =
=0A On Aug 9, 2012, at 9:52 AM,=0A Will= iam Mills wrote:
=0A
=0A =
=0A
= =0A
=0A I=0A = find the idea of starting=0A = from scratch frustrating.=0A =  MAC solves a set of=0A = specific problems and has=0A = a well defined use case.=0A =  It's symmetric key based=0A = which doesn't work for=0A = some folks, and the=0A que= stion is do we try to=0A devel= op something that=0A supports = both PK and SK,=0A or finish t= he SK use case=0A and then wor= k on a PK=0A based draft.
=0A

=0A =
=0A =
I= =0A think it's better to leave= =0A them separate and finish= =0A out MAC which is *VERY=0A = CLOSE* to being done.=0A
=0A =
=0A =0A
=0A =
=0A
Who is interested in= MAC? People=0A can use OAuth 1.0 if the= y prefer=0A that model. 
=0A =

=0A =
=0A
For my projects, I prefe= r the=0A flexibility of a signed or encr= ypted=0A JWT if I need holder of key.=0A

=0A =
=0A
Just my $.02=0A

=0A =
=0A
-- Dick  =0A
=0A =
=0A
=0A =
=0A
=0A =
=0A
=0A =0A
=0A ________________= _______________________________
=0A OAuth mailing l= ist
=0A OAuth@ietf.org<= /a>
=0A https://www.ietf.org/mailman/listinfo/oauth
=0A =
=0A
=0A =
=0A
=0A
=0A =0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A 
_____________________=
__________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.=
org/mailman/listinfo/oauth=0A
=0A
=0A
=0A =
=0A=0A_______________________________________________
OAuth mailin= g list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

_______________________________________________
OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


=


--767760015-315314306-1344614367=:16061-- From jricher@mitre.org Fri Aug 10 09:08:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1FC21F877C for ; Fri, 10 Aug 2012 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkmMS1OUTHdF for ; Fri, 10 Aug 2012 09:08:56 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D239321F874C for ; Fri, 10 Aug 2012 09:08:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6918621B00B9; Fri, 10 Aug 2012 12:08:53 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4F22621B016D; Fri, 10 Aug 2012 12:08:53 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 10 Aug 2012 12:08:52 -0400 Message-ID: <502531C7.4020006@mitre.org> Date: Fri, 10 Aug 2012 12:07:35 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: William Mills References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <50241165.40209@mitre.org> <9B05DBF3-59B6-4377-944A-1917F26D7FA6@alkaline-solutions.com> <1344554391.70300.YahooMailNeo@web31811.mail.mud.yahoo.com> <5FCFF09E-AA4F-48C6-9789-AED8C83B3F2B@ve7jtb.com> <1344609371.51892.YahooMailNeo@web31813.mail.mud.yahoo.com> <47A03274-9F23-40A6-B321-CB7044C0FA4B@ve7jtb.com> <1344614367.16061.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1344614367.16061.YahooMailNeo@web31813.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------020006030300040405010905" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:08:58 -0000 --------------020006030300040405010905 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Specifically, there are cases where it "isn't in play at all" and cases where it "isn't in play end to end". -- Justin On 08/10/2012 11:59 AM, William Mills wrote: > 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 > *To:* William Mills > *Cc:* David Waite ; "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 > >> *To:* William Mills > > >> *Cc:* David Waite > >; "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 >> > >>> *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 >> > 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 >>>>> *To:* William Mills >>>>> >>>>> *Cc:* Dick Hardt >>>>> ; "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 >>>>> > >>>>>> *To:* William Mills >>>>> > >>>>>> *Cc:* "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 >>> >>> >>> _______________________________________________ >>> 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 --------------020006030300040405010905 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Specifically, there are cases where it "isn't in play at all" and cases where it "isn't in play end to end".

 -- Justin

On 08/10/2012 11:59 AM, William Mills wrote:
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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: David Waite <david@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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: David Waite <david@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 <david@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 <jricher@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 <ve7jtb@ve7jtb.com>
To: William Mills <wmills_92105@yahoo.com>
Cc: Dick Hardt <dick.hardt@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.hardt@gmail.com>
To: William Mills <wmills_92105@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


_______________________________________________
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

--------------020006030300040405010905-- From dick.hardt@gmail.com Fri Aug 10 09:18:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2AD21F87B3 for ; Fri, 10 Aug 2012 09:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skmrGShM2sPJ for ; Fri, 10 Aug 2012 09:18:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3623121F87BC for ; Fri, 10 Aug 2012 09:18:37 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2952639pbb.31 for ; Fri, 10 Aug 2012 09:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eLMWk3JyL3OdJdzgq+aP2I9Zy3BtRLYJ8NNUVDN2BqY=; b=ys55rBMdeu19DNBHys0j4PAEMk+PggiC5BKM4uzVKpmLrZFFNJ76EYYM98dm6CCqlE 5bWDhIjG2rNEerLBJfVHfkYnRhwFuVUED9QIBajHSckVNNmxiEzbya7qqcAU8os2Qina YoqKATvtmGGsEXe/Ww6G4dq/NMMy/Yzf5Ga0voS6dkTdzZKEvWZWua3lN4OS0z0VIGxV WGSZAgQIkFCrsOGgenerVeHo1T7SGTUetpcPS1rsNkz+iIV7xuBaLAQu6ip/gAiPDUe+ OVWoqKBai0XXsaHyuTBfUNo5DdqLQ7SASKaaWz8VVjfMMPxARHGGfTY8pR5k6U0aGbbt uSKg== Received: by 10.68.241.65 with SMTP id wg1mr13960311pbc.25.1344615516898; Fri, 10 Aug 2012 09:18:36 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id oa5sm3616285pbb.14.2012.08.10.09.18.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 09:18:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: <50252211.2010105@cdatazone.org> Date: Fri, 10 Aug 2012 09:18:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> <50252211.2010105@cdatazone.org> To: Rob Richards X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:18:38 -0000 As an implementor, I would pick a signed JWT over OAuth 1.0A. Just = saying. Given that, there is also a clear need for signing an HTTP(S) request as = some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't = want to use bearer tokens.=20 I never followed what MAC solved that OAuth 1.0A did not solve. Would = someone elaborate? We do have an RFC for signing requests, there are = lots of libraries already. Why the desire to reinvent OAuth 1.0A? -- Dick On Aug 10, 2012, at 8:00 AM, Rob Richards wrote: > I think you nailed it which that statement. Up until now it as been = back and forth about one or the other. Personally I prefer to used = layered security and not relying on a single point of attack. It's = unrealistic to say everyone is going to want/need/be able to use (take = your pick) signed/encrypted JWT. MAC at least offers an alternative, = less complicated solution. >=20 > Rob >=20 > On 8/10/12 10:41 AM, Richer, Justin P. wrote: >> What about security in depth? Signing + TLS is more secure than = either alone, isn't it? >>=20 >> -- Justin >>=20 >> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: >>=20 >>> Hi Bill, >>>=20 >>> thanks for the feedback. Let's have a look at this use case: >>>=20 >>> You need to provide me a bit more information regarding your use = case. Could you please explain >>>=20 >>> 1) Who is authenticated to whom? >>> 2) What plaintext connection are you talking about? >>> 3) What is the problem with encrypted connections? Is this again the = "TLS has so bad performance" argument? >>> 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. >>> 5) What is the threat you are concerned about? >>>=20 >>> Ciao >>> Hannes >>>=20 >>> 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." >>>=20 >>> On Aug 9, 2012, at 9:43 PM, William Mills wrote: >>>=20 >>>> OK, I'll play and start documenting the use cases. >>>>=20 >>>> Use case #1: Secure authentication in plain text connections: >>>>=20 >>>> 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. >>>>=20 >>>> -bill >>>>=20 >>>> From: John Bradley >>>> To: William Mills >>>> Cc: Dick Hardt ; "oauth@ietf.org" = >>>> Sent: Thursday, August 9, 2012 11:26 AM >>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>>=20 >>>> In Vancouver the question was asked about the future of the MAC = spec due to it no linger having a editor. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> People are welcome to contribute to the use-case document. >>>>=20 >>>> Part of the problem with MAC has been that people could never agree = on what it was protecting against. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> John B. >>>>=20 >>>> On 2012-08-09, at 1:53 PM, William Mills wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>> From: Dick Hardt >>>>> To: William Mills >>>>> Cc: "oauth@ietf.org" >>>>> Sent: Thursday, August 9, 2012 10:27 AM >>>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 >>>>>=20 >>>>>=20 >>>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key. >>>>>=20 >>>>> Just my $.02 >>>>>=20 >>>>> -- Dick >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Fri Aug 10 09:26:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B6021F8535 for ; Fri, 10 Aug 2012 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8zdUhGBUiO3 for ; Fri, 10 Aug 2012 09:26:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4B14021F8568 for ; Fri, 10 Aug 2012 09:26:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E3B4021B1440; Fri, 10 Aug 2012 12:26:36 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C7A7721B143B; Fri, 10 Aug 2012 12:26:36 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 10 Aug 2012 12:26:36 -0400 Message-ID: <502535EE.9070803@mitre.org> Date: Fri, 10 Aug 2012 12:25:18 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dick Hardt References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> <50252211.2010105@cdatazone.org> <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com> In-Reply-To: <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:26:38 -0000 The reason is simple: to benefit from the rest of the improvements in the OAuth2 framework. These are just the ones off the top of my head: 1) Multiple means for getting a token (all the flows are now available) 2) No request tokens 3) No reliance on per-client secrets (though, addendum, I think the MAC spec should be augmented to use them if present) 4) Ability to integrate with many different extensions to OAuth2, both now and in the future -- Justin On 08/10/2012 12:18 PM, Dick Hardt wrote: > As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying. > > Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens. > > I never followed what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? We do have an RFC for signing requests, there are lots of libraries already. Why the desire to reinvent OAuth 1.0A? > > -- Dick > > On Aug 10, 2012, at 8:00 AM, Rob Richards wrote: > >> I think you nailed it which that statement. Up until now it as been back and forth about one or the other. Personally I prefer to used layered security and not relying on a single point of attack. It's unrealistic to say everyone is going to want/need/be able to use (take your pick) signed/encrypted JWT. MAC at least offers an alternative, less complicated solution. >> >> Rob >> >> On 8/10/12 10:41 AM, Richer, Justin P. wrote: >>> What about security in depth? Signing + TLS is more secure than either alone, isn't it? >>> >>> -- Justin >>> >>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: >>> >>>> 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? >>>> 2) What plaintext connection are you talking about? >>>> 3) What is the problem with encrypted connections? Is this again the "TLS has so bad performance" argument? >>>> 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. >>>> 5) What is the threat you are concerned about? >>>> >>>> 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 >>>>> To: William Mills >>>>> Cc: Dick Hardt ; "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 >>>>>> To: William Mills >>>>>> Cc: "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 >>> _______________________________________________ >>> 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 From jricher@mitre.org Fri Aug 10 09:29:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9621F85C5 for ; Fri, 10 Aug 2012 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1Fu3aTKdPSk for ; Fri, 10 Aug 2012 09:29:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 518B221F8569 for ; Fri, 10 Aug 2012 09:29:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EC5B021B07A9; Fri, 10 Aug 2012 12:29:25 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id ABE4621B143E; Fri, 10 Aug 2012 12:29:25 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 10 Aug 2012 12:29:25 -0400 Message-ID: <50253697.5070706@mitre.org> Date: Fri, 10 Aug 2012 12:28:07 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dick Hardt References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <502418C3.5080402@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060109000606020408010209" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:29:27 -0000 --------------060109000606020408010209 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 08/09/2012 06:47 PM, Dick Hardt wrote: > > On Aug 9, 2012, at 1:08 PM, Justin Richer wrote: > >> With MAC, you should be able to re-use about 80-90% of your existing >> codepath that's in place for Bearer, simplifying the setup below. > > That makes no sense, I would be adding MAC to the sites that support > MAC in addition to OAuth 1.0A or OAuth 2.0 You get to re-use all of the code for OAuth2 for issuing tokens (from server side) and requesting tokens (from client side). Apart from parsing the JSON value that's returned from the token endpoint (and you are using a generic parser there, right?), nothing changes here. The part where you *use* the token to access a protected resource (client), or *validate* a request to a protected resource (server) changes significantly, yes. But that's only a small part of the process. > >> >> I would figure that the "variant of OAuth2" issue is a red herring >> because not everyone out there is fully spec compliant. If they were, >> you wouldn't have so many beautiful snowflakes. > > > Being consistent in the spec would help, but likely would just give me > snowflakes that look more like each other. > > There are many aspects of the OAuth dance that are implementation > dependent and it is simpler to just have a separate method for each > one that deals with those unique characteristics. Note this is not > theory, this is practice. Different modules was not an issue. Not > having to use a library to sign requests and being able to use CURL or > a browser to see what a request returned had a HUGE productivity gain > for OAuth 2.0 implementations over OAuth 1.0A implemetations. > >> >> -- Justin >> >> On 08/09/2012 03:48 PM, Dick Hardt wrote: >>> 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 > >>>> *To:* William Mills >>> > >>>> *Cc:* "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 >> > --------------060109000606020408010209 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 08/09/2012 06:47 PM, Dick Hardt wrote:

On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:

With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below.

That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAuth 2.0

You get to re-use all of the code for OAuth2 for issuing tokens (from server side) and requesting tokens (from client side). Apart from parsing the JSON value that's returned from the token endpoint (and you are using a generic parser there, right?), nothing changes here. The part where you *use* the token to access a protected resource (client), or *validate* a request to a protected resource (server) changes significantly, yes. But that's only a small part of the process.



I would figure that the "variant of OAuth2" issue is a red herring because not everyone out there is fully spec compliant. If they were, you wouldn't have so many beautiful snowflakes.


Being consistent in the spec would help, but likely would just give me snowflakes that look more like each other.

There are many aspects of the OAuth dance that are implementation dependent and it is simpler to just have a separate method for each one that deals with those unique characteristics. Note this is not theory, this is practice. Different modules was not an issue. Not having to use a library to sign requests and being able to use CURL or a browser to see what a request returned had a HUGE productivity gain for OAuth 2.0 implementations over OAuth 1.0A implemetations. 


 -- Justin

On 08/09/2012 03:48 PM, Dick Hardt wrote:
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.hardt@gmail.com>
To: William Mills <wmills_92105@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



--------------060109000606020408010209-- From dick.hardt@gmail.com Fri Aug 10 09:44:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E2921F8792 for ; Fri, 10 Aug 2012 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4WbgWWNRsCf for ; Fri, 10 Aug 2012 09:44:45 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4521F878B for ; Fri, 10 Aug 2012 09:44:00 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1939851ggn.31 for ; Fri, 10 Aug 2012 09:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Wrxr5Q4cpTSZZXYbBHS5UXFScfkUnTlCus7SOc+0x1w=; b=eE+z+cTqNYL9BQugSbT7GSChc2p95tvSAyhy1EnqkQmj2Eh3EXXXl5ZaWRD6WHmDZK HJYr3RgDV1rvKkqBe5K2bY7XGzG34Ae2xr/andaEy2w4VD8vPj9DYkl/rjzz97/V2kkg 9rFmInd+5yCvsBJYyu60cz0ta0v2FmtKK/xH6B9buN6+5DeSWlJFQ8+z89aqeHhFoPwB 2E3nTELR53mUoLRriULr5h+eI+On9L6QnXgQt0XkIoWoymCoyCvEdbPI3c2ss6mUXyj0 3+bwFJRiCGKx7Fl7Fq0yqZEaeri5SGJDpKCq3S2oH994sGYcvF6L4m0cuUl1/JMorVF0 JBxQ== Received: by 10.66.88.233 with SMTP id bj9mr7305097pab.72.1344617039352; Fri, 10 Aug 2012 09:43:59 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id op10sm3637663pbc.75.2012.08.10.09.43.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 09:43:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Dick Hardt In-Reply-To: <502535EE.9070803@mitre.org> Date: Fri, 10 Aug 2012 09:43:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C44552A-A485-4AE6-AF9B-B36A5A843513@gmail.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> <50252211.2010105@cdatazone.org> <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com> <502535EE.9070803@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:44:46 -0000 Those reasons make sense to me, thanks for enumerating. On Aug 10, 2012, at 9:25 AM, Justin Richer wrote: > The reason is simple: to benefit from the rest of the improvements in = the OAuth2 framework. These are just the ones off the top of my head: >=20 > 1) Multiple means for getting a token (all the flows are now = available) > 2) No request tokens > 3) No reliance on per-client secrets (though, addendum, I think the = MAC spec should be augmented to use them if present) > 4) Ability to integrate with many different extensions to OAuth2, both = now and in the future >=20 > -- Justin >=20 > On 08/10/2012 12:18 PM, Dick Hardt wrote: >> As an implementor, I would pick a signed JWT over OAuth 1.0A. Just = saying. >>=20 >> Given that, there is also a clear need for signing an HTTP(S) request = as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't = want to use bearer tokens. >>=20 >> I never followed what MAC solved that OAuth 1.0A did not solve. Would = someone elaborate? We do have an RFC for signing requests, there are = lots of libraries already. Why the desire to reinvent OAuth 1.0A? >>=20 >> -- Dick >>=20 >> On Aug 10, 2012, at 8:00 AM, Rob Richards wrote: >>=20 >>> I think you nailed it which that statement. Up until now it as been = back and forth about one or the other. Personally I prefer to used = layered security and not relying on a single point of attack. It's = unrealistic to say everyone is going to want/need/be able to use (take = your pick) signed/encrypted JWT. MAC at least offers an alternative, = less complicated solution. >>>=20 >>> Rob >>>=20 >>> On 8/10/12 10:41 AM, Richer, Justin P. wrote: >>>> What about security in depth? Signing + TLS is more secure than = either alone, isn't it? >>>>=20 >>>> -- Justin >>>>=20 >>>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote: >>>>=20 >>>>> Hi Bill, >>>>>=20 >>>>> thanks for the feedback. Let's have a look at this use case: >>>>>=20 >>>>> You need to provide me a bit more information regarding your use = case. Could you please explain >>>>>=20 >>>>> 1) Who is authenticated to whom? >>>>> 2) What plaintext connection are you talking about? >>>>> 3) What is the problem with encrypted connections? Is this again = the "TLS has so bad performance" argument? >>>>> 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. >>>>> 5) What is the threat you are concerned about? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>> 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." >>>>>=20 >>>>> On Aug 9, 2012, at 9:43 PM, William Mills wrote: >>>>>=20 >>>>>> OK, I'll play and start documenting the use cases. >>>>>>=20 >>>>>> Use case #1: Secure authentication in plain text connections: >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> -bill >>>>>>=20 >>>>>> From: John Bradley >>>>>> To: William Mills >>>>>> Cc: Dick Hardt ; "oauth@ietf.org" = >>>>>> Sent: Thursday, August 9, 2012 11:26 AM >>>>>> Subject: Re: [OAUTH-WG] mistake in = draft-ietf-oauth-v2-http-mac-01 >>>>>>=20 >>>>>> In Vancouver the question was asked about the future of the MAC = spec due to it no linger having a editor. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> People are welcome to contribute to the use-case document. >>>>>>=20 >>>>>> Part of the problem with MAC has been that people could never = agree on what it was protecting against. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On 2012-08-09, at 1:53 PM, William Mills wrote: >>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> From: Dick Hardt >>>>>>> To: William Mills >>>>>>> Cc: "oauth@ietf.org" >>>>>>> Sent: Thursday, August 9, 2012 10:27 AM >>>>>>> Subject: Re: [OAUTH-WG] mistake in = draft-ietf-oauth-v2-http-mac-01 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote: >>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> For my projects, I prefer the flexibility of a signed or = encrypted JWT if I need holder of key. >>>>>>>=20 >>>>>>> Just my $.02 >>>>>>>=20 >>>>>>> -- Dick >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From dick.hardt@gmail.com Fri Aug 10 09:49:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E210821F8759 for ; Fri, 10 Aug 2012 09:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzyxJ+BKyGwC for ; Fri, 10 Aug 2012 09:49:05 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A32821F8757 for ; Fri, 10 Aug 2012 09:49:05 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2989042pbb.31 for ; Fri, 10 Aug 2012 09:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=UoJhserXU8AnMIGhuNlQBtNE/M1dNYy4QUXJIWoXhAM=; b=zY6cv3+6GZOND/5bzkG+5EbyenS39UlHrmEfdJZTraV2ues07NuoJ73s5tSm5gvYJF hUM9rcJrnQLtTnEDBS2PNNT357hacXc8IttZTJJDhM9iYkWNq/Sz8L/VtnuSY0ghgR0+ OfDO/jS0AqVfqreRHQeC7p5KvxMFgFfLREP5W6NsZHHcizDk8uUd98gh6/6RMo+biPxV O8pJqwW0cjbdQcy0of1WL1m4QrIb3im3ksEsNq0bOxG3fUbTNit4VSZuNCU7WL0T4Hp0 P6r4alRlDzP43z+1HOfzCntXrzB1tzBQYFg6gb5AK40bDLMDCENTvMzfHSOYoBQ5HDSJ pkdw== Received: by 10.68.216.136 with SMTP id oq8mr14090225pbc.68.1344617344403; Fri, 10 Aug 2012 09:49:04 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hr9sm3655922pbc.36.2012.08.10.09.49.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 09:49:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_F42074D0-2C70-46E7-8918-019B2D50B7A0" From: Dick Hardt In-Reply-To: <50253697.5070706@mitre.org> Date: Fri, 10 Aug 2012 09:48:59 -0700 Message-Id: <8CA5C199-D005-45B6-A352-81F6396181AF@gmail.com> References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <502418C3.5080402@mitre.org> <50253697.5070706@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1278) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:49:06 -0000 --Apple-Mail=_F42074D0-2C70-46E7-8918-019B2D50B7A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 10, 2012, at 9:28 AM, Justin Richer wrote: > On 08/09/2012 06:47 PM, Dick Hardt wrote: >>=20 >> On Aug 9, 2012, at 1:08 PM, Justin Richer wrote: >>=20 >>> With MAC, you should be able to re-use about 80-90% of your existing = codepath that's in place for Bearer, simplifying the setup below.=20 >>=20 >> That makes no sense, I would be adding MAC to the sites that support = MAC in addition to OAuth 1.0A or OAuth 2.0 >=20 > You get to re-use all of the code for OAuth2 for issuing tokens (from = server side) and requesting tokens (from client side). Apart from = parsing the JSON value that's returned from the token endpoint (and you = are using a generic parser there, right?), nothing changes here. The = part where you *use* the token to access a protected resource (client), = or *validate* a request to a protected resource (server) changes = significantly, yes. But that's only a small part of the process. That makes sense, sorry I was not clear on what I said did not make = sense, which was "simplifying the setup below" As a client developer, adding MAC to the mix *increases* my code base as = it is yet another protocol to understand and implement against. OAuth = 1.0A and OAuth 2.0 bearer are not going to go away. -- Dick= --Apple-Mail=_F42074D0-2C70-46E7-8918-019B2D50B7A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 On = Aug 10, 2012, at 9:28 AM, Justin Richer wrote:

On 08/09/2012 06:47 PM, Dick Hardt = wrote:

On Aug 9, 2012, at 1:08 PM, Justin Richer = wrote:

With MAC, you should be able to re-use about = 80-90% of your existing codepath that's in place for Bearer, simplifying = the setup below. 
=

That makes no sense, I would be adding MAC to the = sites that support MAC in addition to OAuth 1.0A or OAuth = 2.0

You get to re-use all of the code for = OAuth2 for issuing tokens (from server side) and requesting tokens (from = client side). Apart from parsing the JSON value that's returned from the = token endpoint (and you are using a generic parser there, right?), = nothing changes here. The part where you *use* the token to access a = protected resource (client), or *validate* a request to a protected = resource (server) changes significantly, yes. But that's only a small = part of the process.

That makes = sense, sorry I was not clear on what I said did not make sense, which = was "simplifying the setup below"

As a client = developer, adding MAC to the mix *increases* my code base as it is yet = another protocol to understand and implement against. OAuth 1.0A and = OAuth 2.0 bearer are not going to go away.

-- = Dick
= --Apple-Mail=_F42074D0-2C70-46E7-8918-019B2D50B7A0-- From wmills_92105@yahoo.com Fri Aug 10 09:57:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDCA21F877B for ; Fri, 10 Aug 2012 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsAEJkLKO84H for ; Fri, 10 Aug 2012 09:57:39 -0700 (PDT) Received: from nm11.bullet.mail.sp2.yahoo.com (nm11.bullet.mail.sp2.yahoo.com [98.139.91.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDC621F8775 for ; Fri, 10 Aug 2012 09:57:39 -0700 (PDT) Received: from [72.30.22.79] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 16:57:36 -0000 Received: from [98.139.91.15] by tm13.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 16:57:36 -0000 Received: from [127.0.0.1] by omp1015.mail.sp2.yahoo.com with NNFMP; 10 Aug 2012 16:57:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 792011.57242.bm@omp1015.mail.sp2.yahoo.com Received: (qmail 47484 invoked by uid 60001); 10 Aug 2012 16:57:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344617856; bh=wosk1gXkvgUDNC5BY7uJR+cuWfE4CT8756bRW5H1/1c=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TtMx9VEre0RJFPXjf3i7aFtu9OuJ+qrpQZ5xWVC8mRiaDL+Da+iDuCi/IlPu1HfAfqSIFkY1TmdJM6V+sxz9ORcb8MyGXxoh9n25ZLdWO93b187haakhxPDDPOxNSZUmDxMoeuF+F6hsyCeboSu6bap3MUlNjIsIr1LWqEOLUxo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=leim08zBVc/8t+FvBiQ5HMpd7sXzoTPphIOAKKHIB3w+JZGXft8XmcdSOKmvv0NMW3SKSpQZRQnozogv7VMA4IspEG2mqBTzmjB7AGDSNy89em4vkMFbI9pKlwGMjNVqx3UrkLJRXzIbvkjOeQPjBej1AuA0eqHfpWkiLlWvucg=; X-YMail-OSG: tlROLv4VM1nt7KD8EWqL7snOlU_FyegCd0raqLNCRILqib6 dPBL90JWlTxZyRJ1ehpLgpVSve1tghXfAuNKc0NuPrQP3oWCsPsOLsiutJAx sLy1MvsDJ8Nk31Eda.mDoxNww5DQE6GhA2MSSFhO1d7F4bmV_bi92in7WOCP V_elqiL6q7G3V5_RZqqWNbx6LnUqBcU.eXICxZhxl1QrkCyFWrnPwtxv_N.n aFQQIIvHFnT.if2VnpRQCJUZ_isd2MSsBYYM5rGPxPC3zXt60Dox4FUYMcDj 0WLp5jTL7X.5LImDmKbFb8PFuwkzbOkoednx2NmVp7qOe12n.UAMpZzMNFIL 3eUN7aNBRySy8Xv43way0uUQ8XS5VgnLH.Zsr1JQbMyRBQT5f43LEriT1fcW fWBNqLhyR7mYr9sN_rIeXXmAWhYd5E5_J7wuEMkA.TdWDDYsUulgm4p9E_3K kweTYCFrti2nR.0y5EviE5sEgpWahS82XZkRxpghqAca7tbV.c4nTZHZBMDO fea8- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2012 09:57:35 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <5B59B739-F8E7-4F5A-A39C-8C46055D0E98@ve7jtb.com> <1344537819.41154.YahooMailNeo@web31803.mail.mud.yahoo.com> <283C0846-4D26-4B3B-AD6D-7F895E8AF47D@gmx.net> <50252211.2010105@cdatazone.org> <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com> Message-ID: <1344617855.44198.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Fri, 10 Aug 2012 09:57:35 -0700 (PDT) From: William Mills To: Dick Hardt , Rob Richards In-Reply-To: <9630A9AB-300F-476C-9FC6-4779695DE559@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-741155742-1344617855=:44198" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:57:40 -0000 --767760015-741155742-1344617855=:44198 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In no particular order:=0A=0AAs I said before, and many have said before me= , a major issue with OAuth 1.0a has always been the signing process. =A0Yes= there are libraries. =A0MAC was begun before there were a significant numb= er of libraries. =A0You also have to process/parse the post body for oauth_= variables if you're really going to be compliant, and people don't like th= at much.=0A=0AOAuth 1.0a has signing with a client secret, but that secret = is managed out of band. =A0MAC+Oauth 2 has the client secret issued with th= e token. =A0This is fundamentally different and far more suitable for the c= onsumer/end user client case. =A01.0a is structured more for a 3 party mode= l, where the secret is used to authenticate the 3rd party, out of band secr= et management isn't as much of a problem there. =A0=0A=0A1.0a is just clums= y to implement for consumer/end user clients, the OAuth 2 model is far clea= ner, and in the end in 1.0a =A0the secret ends up not a secret anymore. =A0= It ends up being the equivalent of bearer tokens in security. =A0 This is b= ecause, I think, =A0fundamentally the client secret is tied in through the = token request/auth stuff and then also in the access to the protected resou= rce. =A0=0A=0AWe could theoretically have something very similar to the way= MAC tokens would be fetched in OAuth 2, and use that secret with OAuth 1.0= a signing to access the protected resource. =A0That would work, but it woul= d be kinda gross.=0A=0A-bill=0A=0A=0A=0A=0A=0A=0A=0A_______________________= _________=0A From: Dick Hardt =0ATo: Rob Richards =0ACc: "oauth@ietf.org" =0ASent: Fr= iday, August 10, 2012 9:18 AM=0ASubject: Re: [OAUTH-WG] mistake in draft-ie= tf-oauth-v2-http-mac-01=0A =0AAs an implementor, I would pick a signed JWT = over OAuth 1.0A. Just saying.=0A=0AGiven that, there is also a clear need f= or signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OA= uth 2.0 because they don't want to use bearer tokens. =0A=0AI never followe= d what MAC solved that OAuth 1.0A did not solve. Would someone elaborate? W= e do have an RFC for signing requests, there are lots of libraries already.= Why the desire to reinvent OAuth 1.0A?=0A=0A-- Dick=0A=0AOn Aug 10, 2012, = at 8:00 AM, Rob Richards wrote:=0A=0A> I think you nailed it which that sta= tement. Up until now it as been back and forth about one or the other. Pers= onally I prefer to used layered security and not relying on a single point = of attack. It's unrealistic to say everyone is going to want/need/be able t= o use (take your pick) signed/encrypted JWT. MAC at least offers an alterna= tive, less complicated solution.=0A> =0A> Rob=0A> =0A> On 8/10/12 10:41 AM,= Richer, Justin P. wrote:=0A>> What about security in depth? Signing + TLS = is more secure than either alone, isn't it?=0A>> =0A>>=A0 -- Justin=0A>> = =0A>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote:=0A>> =0A>>> Hi = Bill,=0A>>> =0A>>> thanks for the feedback. Let's have a look at this use c= ase:=0A>>> =0A>>> You need to provide me a bit more information regarding y= our use case. Could you please explain=0A>>> =0A>>> 1) Who is authenticated= to whom?=0A>>> 2) What plaintext connection are you talking about?=0A>>> 3= ) What is the problem with encrypted connections? Is this again the "TLS ha= s so bad performance" argument?=0A>>> 4) Since you are talking about cookie= s and making them more secure are you trying to come up with a general solu= tion to better cookie security - a topic others are working on as well.=0A>= >> 5) What is the threat you are concerned about?=0A>>> =0A>>> Ciao=0A>>> H= annes=0A>>> =0A>>> PS: I would heavily argue against standardize a security= mechanism that offers weaker protection than bearer when the entire argume= nt has always been "Bearer is so insecure and we need something stronger."= =0A>>> =0A>>> On Aug 9, 2012, at 9:43 PM, William Mills wrote:=0A>>> =0A>>>= > OK, I'll play and start documenting the use cases.=0A>>>> =0A>>>> Use cas= e #1: Secure authentication in plain text connections:=0A>>>> =0A>>>> Some = applications need a secure form authorization, but do not want or need the = overhead of encrypted connections.=A0 HTTP cookies and their ilk are replay= able credentials and do not satisfy this need.=A0 the MAC scheme using sig= ned HTTP authorization credentials offer the capability to securely authori= ze a transaction, can offer integrity protection on all or part of an HTTP = request, and can provide replay protection.=0A>>>> =0A>>>> -bill=0A>>>> =0A= >>>> From: John Bradley =0A>>>> To: William Mills =0A>>>> Cc: Dick Hardt ; "oauth@iet= f.org" =0A>>>> Sent: Thursday, August 9, 2012 11:26 AM=0A>>= >> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01=0A>>>= > =0A>>>> In Vancouver the question was asked about the future of the MAC s= pec due to it no linger having a editor.=0A>>>> =0A>>>> The Chair and AD in= dicated a desire to have a document on the use-cases we are trying to addre= ss before deciding on progressing MAC or starting a new document.=0A>>>> = =0A>>>> Phil Hunt is going to put together a summery of the Vancouver discu= ssion and we are going to work on the use-case/problem description document= ASAP.=0A>>>> =0A>>>> People are welcome to contribute to the use-case docu= ment.=0A>>>> =0A>>>> Part of the problem with MAC has been that people coul= d never agree on what it was protecting against.=0A>>>> =0A>>>> I think the= re is general agreement that one or more proof mechanisms are required for = access tokens.=0A>>>> Security for the token endpoint also cannot be ignore= d.=0A>>>> =0A>>>> =0A>>>> John B.=0A>>>> =0A>>>> On 2012-08-09, at 1:53 PM,= William Mills wrote:=0A>>>> =0A>>>>> MAC fixes the signing problems encoun= tered in OAuth 1.0a, yes there are libraries out there for OAuth 1.0a.=A0 M= AC 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.=0A>>>>> =0A>>>>> From: Dic= k Hardt =0A>>>>> To: William Mills =0A>>>>> Cc: "oauth@ietf.org" =0A>>>>> Sent: Thursday= , August 9, 2012 10:27 AM=0A>>>>> Subject: Re: [OAUTH-WG] mistake in draft-= ietf-oauth-v2-http-mac-01=0A>>>>> =0A>>>>> =0A>>>>> On Aug 9, 2012, at 9:52= AM, William Mills wrote:=0A>>>>> =0A>>>>>> I find the idea of starting fro= m scratch frustrating.=A0 MAC solves a set of specific problems and has a w= ell defined use case.=A0 It's symmetric key based which doesn't work for so= me 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= .=0A>>>>>> =0A>>>>>> I think it's better to leave them separate and finish = out MAC which is *VERY CLOSE* to being done.=0A>>>>> Who is interested in M= AC? People can use OAuth 1.0 if they prefer that model.=0A>>>>> =0A>>>>> Fo= r my projects, I prefer the flexibility of a signed or encrypted JWT if I n= eed holder of key.=0A>>>>> =0A>>>>> Just my $.02=0A>>>>> =0A>>>>> -- Dick= =0A>>>>> =0A>>>>> =0A>>>>> =0A>>>>> _______________________________________= ________=0A>>>>> OAuth mailing list=0A>>>>> OAuth@ietf.org=0A>>>>> https://= www.ietf.org/mailman/listinfo/oauth=0A>>>> =0A>>>> =0A>>>> ________________= _______________________________=0A>>>> OAuth mailing list=0A>>>> OAuth@ietf= .org=0A>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>> _____________= __________________________________=0A>>> OAuth mailing list=0A>>> OAuth@iet= f.org=0A>>> https://www.ietf.org/mailman/listinfo/oauth=0A>> ______________= _________________________________=0A>> OAuth mailing list=0A>> OAuth@ietf.o= rg=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A>> =0A> =0A> ________= _______________________________________=0A> OAuth mailing list=0A> OAuth@ie= tf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A=0A_______________= ________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/oauth --767760015-741155742-1344617855=:44198 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In no particular o= rder:

As= I said before, and many have said before me, a major issue with OAuth 1.0a= has always been the signing process.  Yes there are libraries.  = MAC was begun before there were a significant number of libraries.  Yo= u also have to process/parse the post body for oauth_ variables if you're r= eally going to be compliant, and people don't like that much.
<= div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: 'times new roman', 'new york', times, serif; background-color: transparent; font-styl= e: normal; ">
OAuth 1.0a has signi= ng with a client secret, but that secret is managed out of band.  MAC+= Oauth 2 has the client secret issued with the token.  This is fundamen= tally different and far more suitable for the consumer/end user client case= .  1.0a is stru= ctured more for a 3 party model, where the secret is used to authenticate t= he 3rd party, out of band secret management isn't as much of a problem ther= e.  

1.0a is just clumsy to implem= ent for consumer/end user clients, the OAuth 2 model is far cleaner, and in= the end in 1.0a  the secret ends up not a secret anymore.  It en= ds up being the equivalent of bearer tokens in security.   This is bec= ause, I think,  fundam= entally the client secret is tied in through the token request/auth stuff a= nd then also in the access to the protected resource.  

We could theor= etically have something very similar to the way MAC tokens would be fetched= in OAuth 2, and use that secret with OAuth 1.0a signing to access the prot= ected resource.  That would work, but it would be kinda gross.<= /div>

-bill






From: Dick Hardt <dick.hardt@g= mail.com>
To: Rob R= ichards <rrichards@cdatazone.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Friday, August 10, 2012 9:18= AM
Subject: Re: [OAUT= H-WG] mistake in draft-ietf-oauth-v2-http-mac-01

=0A= As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.<= br>
Given that, there is also a clear need for signing an HTTP(S) reques= t as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't w= ant to use bearer tokens.

I never followed what MAC solved that OAu= th 1.0A did not solve. Would someone elaborate? We do have an RFC for signi= ng requests, there are lots of libraries already. Why the desire to reinven= t OAuth 1.0A?

-- Dick

On Aug 10, 2012, at 8:00 AM, Rob Richar= ds wrote:

> I think you nailed it which that statement. Up until = now it as been back and forth about one or the other. Personally I prefer t= o used layered security and not relying on a single point of attack. It's u= nrealistic to say everyone is going to want/need/be able to use (take your = pick) signed/encrypted JWT. MAC at least offers an alternative, less compli= cated solution.
>
> Rob
>
> On 8/10/12 10:41 AM, Richer, Justin P. wrote:
>> What about security in dept= h? Signing + TLS is more secure than either alone, isn't it?
>> >>  -- Justin
>>
>> On Aug 10, 2012, at 3:0= 1 AM, Hannes Tschofenig wrote:
>>
>>> Hi Bill,
>= ;>>
>>> thanks for the feedback. Let's have a look at th= is use case:
>>>
>>> You need to provide me a bit = more information regarding your use case. Could you please explain
>&= gt;>
>>> 1) Who is authenticated to whom?
>>> 2= ) What plaintext connection are you talking about?
>>> 3) What = is the problem with encrypted connections? Is this again the "TLS has so ba= d performance" argument?
>>> 4) Since you are talking about coo= kies and making them more secure are you trying to come up with a general s= olution to better cookie security - a topic others are working on as well.
>>> 5) What is the threat you are concerned about?
&g= t;>>
>>> Ciao
>>> Hannes
>>> >>> PS: I would heavily argue against standardize a security mech= anism that offers weaker protection than bearer when the entire argument ha= s always been "Bearer is so insecure and we need something stronger."
&g= t;>>
>>> 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 wan= t or need the overhead of encrypted connections.  HTTP cookies and the= ir 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 protec= tion on all or part of an HTTP request, and can provide replay protection.<= br>>>>>
>>>> -bill
>>>>
>= >>> From: John Bradley <ve7jtb@ve7jtb.com>
>>>= ;> To: William Mills <wmills_92105@yahoo.com>
>= >>> Cc: Dick Hardt <dick.hardt@gmail.com>; "oauth@ietf.org= " <oauth@ietf.org>
>>>> Sent: Thursday, August 9, 201= 2 11:26 AM
>>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>>>
>>>> I= n 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 docu= ment.
>>>>
>>>> Phil Hunt is going to put to= gether a summery of the Vancouver discussion and we are going to work on th= e use-case/problem description document ASAP.
>>>>
>&= gt;>> People are welcome to contribute to the use-case document.
&= gt;>>>
>>>> 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.
>>>>
>>>>
>>>> Joh= n B.
>>>>
>>>> On 2012-08-09, at 1:53 PM, Wi= lliam Mills wrote:
>>>>
>>>>> MAC fixes t= he 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 MA= C.
>>>>>
>>>>> From: Dick Hardt <dick.hardt@gmail.com>
>>>>> To: William Mills &= lt;wmills_92105@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-0= 1
>>>>>
>>>>>
>>>>>= On Aug 9, 2012, at 9:52 AM, William Mills wrote:
>>>>> <= br>>>>>>> I find the idea of starting from scratch frustr= ating.  MAC solves a set of specific problems and has a well defined u= se 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 an= d SK, or finish the SK use case and then work on a PK based draft.
>&= gt;>>>>
>>>>>> I think it's better to lea= ve them separate and finish out MAC which is *VERY CLOSE* to being done.
>>>>> Who is interested in MAC? People can use OAu= th 1.0 if they prefer that model.
>>>>>
>>>&= gt;> For my projects, I prefer the flexibility of a signed or encrypted = JWT if I need holder of key.
>>>>>
>>>>&g= t; Just my $.02
>>>>>
>>>>> -- Dick>>>>>
>>>>>
>>>>> >>>>> _______________________________________________
&g= t;>>>> OAuth mailing list
>>>>> OAuth@ietf.org>>>>> https://www.ietf.org/mailman/listinfo/oauth
&g= t;>>>
>>>>
>>>> __________________= _____________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.o= rg/mailman/listinfo/oauth
>>> _____________________________= __________________
>>> OAuth mailing list
>>> OAuth@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/oauth
&g= t;> _______________________________________________
>> OAuth ma= iling 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 li= st
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=
--767760015-741155742-1344617855=:44198-- From phil.hunt@oracle.com Fri Aug 10 10:03:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1C21F8809 for ; Fri, 10 Aug 2012 10:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.31 X-Spam-Level: X-Spam-Status: No, score=-10.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DHkc9BMoKX9 for ; Fri, 10 Aug 2012 10:03:30 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E59B521F8808 for ; Fri, 10 Aug 2012 10:03:27 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AH3Oqc026893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2012 17:03:25 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7AH3Oaq003839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2012 17:03:24 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7AH3N4a028346; Fri, 10 Aug 2012 12:03:23 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 10:03:23 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Fri, 10 Aug 2012 10:03:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C75E137-2C30-4D74-AABE-EB4D97C5B56F@oracle.com> References: To: "Richer, Justin P." X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] MAC Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:03:31 -0000 There's no reason why the spec, or key elements of it can't be re-used. But to assume it should be "THE" spec, goes against previous formal = consensus (can't remember if it was Quebec or Paris meeting) and jumps = the gun on defining what the problem is. If we jump into a spec without = defining the problem, we're guessing. What I saw of the previous email = discussion was a lot of circular debate indicating no clear problem = definition. I agree, it would be nice to re-use code from previous implementations. = But that strikes me as an issue to raise when we discuss the = implementation based upon future consensus of the problem. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-10, at 7:49 AM, Richer, Justin P. wrote: >=20 > On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote: >=20 >> Justin wrote:=20 >> " >> I believe that there's value in per-message signing completely apart = from the channel level encryption.=20 >> " >>=20 >> May well be. But we have to figure out what exactly the reasons are = why there is value.=20 >=20 > Yes, there is value in this, and that's why we're collecting a handful = of use cases to support this. Otherwise, people wouldn't keep = reinventing this. See SAML and OpenID Connect's signed request object = for other examples. >=20 >>=20 >> Bill wrote: >> " >> I find the idea of starting from scratch frustrating. MAC solves a = set of specific problems and has a well defined use case. >> " >>=20 >> This would be a very quick process if we had ever done our home work = properly.=20 >=20 > It's not done, but it's not empty. Why throw it out? Whether or not we = continue the draft itself or import its best ideas into a new draft is = beside the point. >=20 >>=20 >> So, what are the problems it tries to solve? Yesterday I found an old = presentation about MAC and the basic argument was that it has better = performance than TLS. While that's true it is not a good argument per = se. However, performance is not the only factor to look at and the = negative performance impact caused by TLS is overrated. =20 >=20 > This is a red herring, as pointed out by other use cases. >=20 >>=20 >> Here is the slide set I am talking about:=20 >> http://www.tschofenig.priv.at/Why_are_we_Signing.pdf >>=20 >> In many cases I had noticed that more time was spent with the = pictures (in slides and blog post) than with the content. That's not = good IMHO.=20 >>=20 >> Bill, we can hardly call a specification "complete" if many of us = don't know what problem it solves. John phrases it nicely as "Part of = the problem with MAC has been that people could never agree on what it = was protecting against." I am also interested in hearing about = deployment constraints that people have. Blaine always said that many = developers cannot get TLS to work. I am sure that's true but OAuth 2.0 = requires TLS to be used anyway to secure the interaction with the = authorization server.=20 >=20 > It solves this problem: How can I use the framework of OAuth to get a = temporary signing key that I can use to protect HTTP messages with = signing (without stuffing my parameters into a structured document like = a SAML or JWT assertion)? There are many justifications for that problem = and use cases that expand on this, but that's the core thing that the = MAC does. >=20 >>=20 >> Note: I am not saying that we are not going to standardize something = like the MAC token (maybe with different details) but let us spend a = little bit of time to figure out what threats we want to deal with.=20 >=20 > It's not just about threats, it's about capabilities and features.=20 >=20 > -- Justin >=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Fri Aug 10 10:04:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55721F880F for ; Fri, 10 Aug 2012 10:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NonAc0cXwRra for ; Fri, 10 Aug 2012 10:04:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC2021F8808 for ; Fri, 10 Aug 2012 10:04:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8037121B0668; Fri, 10 Aug 2012 13:04:00 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 67D2F21B07EF; Fri, 10 Aug 2012 13:04:00 -0400 (EDT) Received: from [129.83.50.26] (129.83.31.51) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 10 Aug 2012 13:04:00 -0400 Message-ID: <50253EB2.705@mitre.org> Date: Fri, 10 Aug 2012 13:02:42 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Dick Hardt References: <502280D8.40708@mitre.org> <9AD4EEF7-6187-4A4F-A855-32819BCB8321@gmx.net> <5022D344.40600@mitre.org> <5023CC18.9090809@mitre.org> <1344531175.4871.YahooMailNeo@web31812.mail.mud.yahoo.com> <3940317E-948C-4909-9B8F-2689A6B8D4EB@gmail.com> <1344534823.39489.YahooMailNeo@web31801.mail.mud.yahoo.com> <502418C3.5080402@mitre.org> <50253697.5070706@mitre.org> <8CA5C199-D005-45B6-A352-81F6396181AF@gmail.com> In-Reply-To: <8CA5C199-D005-45B6-A352-81F6396181AF@gmail.com> Content-Type: multipart/alternative; boundary="------------090009090506020700050207" X-Originating-IP: [129.83.31.51] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 17:04:02 -0000 --------------090009090506020700050207 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 08/10/2012 12:48 PM, Dick Hardt wrote: > On Aug 10, 2012, at 9:28 AM, Justin Richer wrote: > >> On 08/09/2012 06:47 PM, Dick Hardt wrote: >>> >>> On Aug 9, 2012, at 1:08 PM, Justin Richer wrote: >>> >>>> With MAC, you should be able to re-use about 80-90% of your >>>> existing codepath that's in place for Bearer, simplifying the setup >>>> below. >>> >>> That makes no sense, I would be adding MAC to the sites that support >>> MAC in addition to OAuth 1.0A or OAuth 2.0 >> >> You get to re-use all of the code for OAuth2 for issuing tokens (from >> server side) and requesting tokens (from client side). Apart from >> parsing the JSON value that's returned from the token endpoint (and >> you are using a generic parser there, right?), nothing changes here. >> The part where you *use* the token to access a protected resource >> (client), or *validate* a request to a protected resource (server) >> changes significantly, yes. But that's only a small part of the process. > > That makes sense, sorry I was not clear on what I said did not make > sense, which was "simplifying the setup below" > > As a client developer, adding MAC to the mix *increases* my code base > as it is yet another protocol to understand and implement against. > OAuth 1.0A and OAuth 2.0 bearer are not going to go away. > > OK, I follow now. Yes, that's a fair concern for anyone who has to support multiple protocols that aren't mutually compatible. I'm personally hoping that OAuth2/MAC will help push out most (if not all) of the remaining OAuth1 pieces we have here, helping is shut down at least one of those. -- Justin --------------090009090506020700050207 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 08/10/2012 12:48 PM, Dick Hardt wrote:
On Aug 10, 2012, at 9:28 AM, Justin Richer wrote:

On 08/09/2012 06:47 PM, Dick Hardt wrote:

On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:

With MAC, you should be able to re-use about 80-90% of your existing codepath that's in place for Bearer, simplifying the setup below. 

That makes no sense, I would be adding MAC to the sites that support MAC in addition to OAuth 1.0A or OAuth 2.0

You get to re-use all of the code for OAuth2 for issuing tokens (from server side) and requesting tokens (from client side). Apart from parsing the JSON value that's returned from the token endpoint (and you are using a generic parser there, right?), nothing changes here. The part where you *use* the token to access a protected resource (client), or *validate* a request to a protected resource (server) changes significantly, yes. But that's only a small part of the process.

That makes sense, sorry I was not clear on what I said did not make sense, which was "simplifying the setup below"

As a client developer, adding MAC to the mix *increases* my code base as it is yet another protocol to understand and implement against. OAuth 1.0A and OAuth 2.0 bearer are not going to go away.


OK, I follow now. Yes, that's a fair concern for anyone who has to support multiple protocols that aren't mutually compatible. I'm personally hoping that OAuth2/MAC will help push out most (if not all) of the remaining OAuth1 pieces we have here, helping is shut down at least one of those.

 -- Justin
--------------090009090506020700050207-- From dick.hardt@gmail.com Fri Aug 10 13:04:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3021F8694 for ; Fri, 10 Aug 2012 13:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgUdvBxjXNpB for ; Fri, 10 Aug 2012 13:04:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01621F8690 for ; Fri, 10 Aug 2012 13:04:43 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3215688pbb.31 for ; Fri, 10 Aug 2012 13:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=OPbvhELwMOyEeYP1+WqCeCLewAHtNTGcb6lquM1uruY=; b=SC0h3gzO5GSuRnpvTnmOnOtXU8lZ0RH0EaK31TDPEG4ntTqI2vL8BH9s+aC5iVQT3w sHDxcySHg//u/1Rel+gGqVQPyNesUj7QpiY1rY1DYE0Vj3HhnW8BBkZbybim8mPpLTU6 xW+XoCqk20pAQy5iVKB5XdEkqJDpf9o4NVhI9bfjd9E8UXSDBs4wGD12Y/Bm77j61DI/ WiH5oRAoaCl09GivuKr+YpMtvh5vjhbw8v2ulsnaRQApdvKzN23sEPYYPjci3zrjdNNH O8jPXM65jZhGK8I5myF5+eUDYPkJiCe5VbpLyffdi7UWKJmvjEcY7kGVqBYl4Re1Zdir c4Hw== Received: by 10.68.239.103 with SMTP id vr7mr260746pbc.0.1344629082866; Fri, 10 Aug 2012 13:04:42 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id st6sm2586368pbc.58.2012.08.10.13.04.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 13:04:39 -0700 (PDT) From: Dick Hardt Content-Type: multipart/alternative; boundary="Apple-Mail=_CE471CD6-41F0-437D-8ED1-F7F14462AD5F" Date: Fri, 10 Aug 2012 13:04:31 -0700 References: To: "oauth@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) 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) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:04:44 -0000 --Apple-Mail=_CE471CD6-41F0-437D-8ED1-F7F14462AD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Once again, would be great to have a few more eyes checking the IANA = registrations.=20 Note these are for the Bearer Token spec.=20 I like that the error registry items are sorted alphabetically already. = :) Begin forwarded message: > From: "Amanda Baber via RT" > Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization = Framework: Bearer Token Usage' to Proposed Standard = (draft-ietf-oauth-v2-bearer-23.txt)=20 > Date: August 10, 2012 12:20:33 PM PDT > Cc: mbj@microsoft.com, dick.hardt@gmail.com, = oauth-chairs@tools.ietf.org, oauth-ads@tools.ietf.org > Reply-To: drafts-approval@iana.org >=20 > Dear Authors: >=20 > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED=20 >=20 > We have completed the IANA Actions for RFC-to-be > draft-ietf-oauth-v2-bearer-23 >=20 > ACTION 1: >=20 > IANA has registered the following OAuth Access Token Type: >=20 > Name: Bearer > Additional Endpoint Response Parameters:=20 > HTTP Authentication Scheme(s): Bearer=20 > Change Controller: IETF =20 > Reference: [RFC-ietf-oauth-v2-bearer-23] >=20 > Please see > http://www.iana.org/assignments/oauth-parameters >=20 >=20 > ACTION 2: >=20 > IANA has registered the following in the OAuth Extensions Error = Registry: >=20 > invalid_request =20 > Usage Location: Resource access error response =20 > Protocol Extension: Bearer access token type =20 > Change Controller: IETF =20 > Reference: [RFC-ietf-oauth-v2-bearer-23] >=20 > invalid_token > Usage Location: Resource access error response =20 > Protocol Extension: Bearer access token type =20 > Change Controller: IETF =20 > Reference: [RFC-ietf-oauth-v2-bearer-23] >=20 > insufficient_scope > Usage Location: Resource access error response =20 > Protocol Extension: Bearer access token type =20 > Change Controller: IETF =20 > Reference: [RFC-ietf-oauth-v2-bearer-23] >=20 > Please see > http://www.iana.org/assignments/oauth-parameters >=20 >=20 > Please let us know whether the above IANA Actions look OK. As=20 > soon as we receive your confirmation, we'll notify the RFC Editor=20 > that this document's IANA Actions are complete. (If this document=20 > has a team of authors, one reply on behalf of everyone will suffice.) >=20 > Thanks, >=20 > Amanda Baber > ICANN/IANA >=20 --Apple-Mail=_CE471CD6-41F0-437D-8ED1-F7F14462AD5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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-approval@iana.org><= br>
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
Reply-To: drafts-approval@iana.org
<= /span>

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


= --Apple-Mail=_CE471CD6-41F0-437D-8ED1-F7F14462AD5F-- From torsten@lodderstedt.net Sun Aug 12 00:21:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CCC11E80DC for ; Sun, 12 Aug 2012 00:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO2R7wp6bvf7 for ; Sun, 12 Aug 2012 00:21:04 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90911E80D5 for ; Sun, 12 Aug 2012 00:21:03 -0700 (PDT) Received: from [91.2.84.120] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T0STt-0001QT-5u; Sun, 12 Aug 2012 09:21:01 +0200 Message-ID: <50275959.2000406@lodderstedt.net> Date: Sun, 12 Aug 2012 09:20:57 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: OAuth WG , Mark Mcgloin , Phil Hunt Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: [OAUTH-WG] Threat Document (new revision) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 07:21:05 -0000 Hi all, this is to let you know we are working towards a new revision of the "OAuth 2.0 Threat Model and Security Considerations". It will cover token substitution and some editorial comments raised during IETF review. regards, Torsten. From wmills_92105@yahoo.com Mon Aug 13 09:34:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB96B21F8541 for ; Mon, 13 Aug 2012 09:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-tfBLYccEfU for ; Mon, 13 Aug 2012 09:34:39 -0700 (PDT) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by ietfa.amsl.com (Postfix) with ESMTP id D722121F85C7 for ; Mon, 13 Aug 2012 09:34:38 -0700 (PDT) Received: from [98.139.91.67] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 Aug 2012 16:34:29 -0000 Received: from [98.139.91.14] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 13 Aug 2012 16:34:29 -0000 Received: from [127.0.0.1] by omp1014.mail.sp2.yahoo.com with NNFMP; 13 Aug 2012 16:34:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 575624.17530.bm@omp1014.mail.sp2.yahoo.com Received: (qmail 30318 invoked by uid 60001); 13 Aug 2012 16:34:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344875669; bh=exK5JN2WbruueEcdKbPMzpHTTRTGTLFcRDW7XZoQwrM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Zav7lDQxDZj0EZmskcBv8gaiQT1bNwT4VimDqmcEJOkjfwtVMyfm7lw5EQ4pbm6cNehKAew5TOw4UT7ECl7UlhPsQ2ejghZy+3LxuOjtlVPZxezZQwuxghmPpFS8Hga823SAvdW/l6cqjX7QeEBDo6eTNmgn+yA7zTJsnS+ex+I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mCnek6kgcowswrQkGibJQAuzuOgdWND8zJ0LzA8/UyKWMY9Z/7CgnJWAQSbEq1csKvbcAry50WRtapcgtjSP4Padn/63LbkK9bxCeA9xW0NZZzp4qNNjuFKAPqnb3/wDn57+0Ov4R11XEWI/tHc1kLfFUrbP6JuB3Z1Wo77pBwM=; X-YMail-OSG: LoABS9cVM1mRzLRUZqP.fWJpNUMk.kEOlRVGEC8ufbiLIeL gSmOUOTe3f4sCtB0gEa0GhikfVmGczVhXGczaEARbY6mUUh6eRYYHLu0hBPu V0ORTQfslu57Iv.B3KISV8x2Id4lX3zIqMLFW6DfA.B51kjeycow1h9L2KNX T3oqE2wFkdYXLF7sBGcXgZmdwkDsknbacmUYuJTgypTE18E3hW48mE_99Hir xgMiad.6wocaO9o2O2itCCBI4CQawnEvfn9xowvXN88PZCxN0ICKi8mM732a Lbgo7m7meRj0Za3sFQSswbhx8TejyCqGB.tSW0rNi91UPHU7cFKTzuYiYihS ZCntJUFU2IYfagnU6Wv4hxk3hf6bYlcl3bCp59_yNcw2OW4zoy5kkT2d1SSg kpMwUdVpErxEEo_r5Q9YF5e6uGY.LHP3LC4JHwql7uGtCkpbldmPn8660hcd 3F5qFrwIArpjjlrGxfHD8SNOnAh9xCH6UabpIkW3I62dOBogMkjO.NtMUa61 ecNI- Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Mon, 13 Aug 2012 09:34:28 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: Message-ID: <1344875668.20926.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Mon, 13 Aug 2012 09:34:28 -0700 (PDT) From: William Mills To: Dick Hardt , "oauth@ietf.org WG" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-125733401-297129888-1344875668=:20926" 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) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:34:43 -0000 ---125733401-297129888-1344875668=:20926 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 1) Is it a problem that everything here seems to have "specification requir= ed" for the "Registration Procedures"?=0A=0A2) In HTTP Authentication schem= es, is the case insensitivity implicit here? (I=A0think=A0so)=0A=0A-bill=0A= =0A=0A=0A=0A________________________________=0A From: Dick Hardt =0ATo: "oauth@ietf.org WG" =0ASent: Friday, Au= gust 10, 2012 1:04 PM=0ASubject: [OAUTH-WG] Fwd: [IANA #596670] Protocol Ac= tion: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Propos= ed Standard (draft-ietf-oauth-v2-bearer-23.txt)=0A =0A=0AOnce again, would = be great to have a few more eyes checking the IANA registrations.=A0=0A=0AN= ote these are for the Bearer Token spec.=A0=0A=0AI like that the error regi= stry items are sorted alphabetically already. :)=0A=0A=0A=0ABegin forwarded= message:=0A=0AFrom: "Amanda Baber via RT" =0A>= =0A>Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization F= ramework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bea= rer-23.txt) =0A>=0A>Date: August 10, 2012 12:20:33 PM PDT=0A>=0A>Cc: mbj@mi= crosoft.com, dick.hardt@gmail.com, oauth-chairs@tools.ietf.org, oauth-ads@t= ools.ietf.org=0A>=0A>Reply-To: drafts-approval@iana.org=0A>=0A>=0A>Dear Aut= hors:=0A>=0A>ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED =0A>=0A>We hav= e completed the IANA Actions for RFC-to-be=0A>draft-ietf-oauth-v2-bearer-23= =0A>=0A>ACTION 1:=0A>=0A>IANA has registered the following OAuth Access Tok= en Type:=0A>=0A>Name: Bearer=0A>Additional Endpoint Response Parameters: = =0A>HTTP Authentication Scheme(s): Bearer =0A>Change Controller: IETF =A0= =A0=A0=A0=A0=A0=A0=A0=A0=0A>Reference: [RFC-ietf-oauth-v2-bearer-23]=0A>=0A= >Please see=0A>http://www.iana.org/assignments/oauth-parameters=0A>=0A>=0A>= ACTION 2:=0A>=0A>IANA has registered the following in the OAuth Extensions = Error Registry:=0A>=0A>invalid_request =A0=0A>Usage Location: Resource acce= ss error response =A0=0A>Protocol Extension: Bearer access token type =A0= =0A>Change Controller: IETF =A0=0A>Reference: [RFC-ietf-oauth-v2-bearer-23]= =0A>=0A>invalid_token=0A>Usage Location: Resource access error response =A0= =0A>Protocol Extension: Bearer access token type =A0=0A>Change Controller: = IETF =A0=0A>Reference: [RFC-ietf-oauth-v2-bearer-23]=0A>=0A>insufficient_sc= ope=0A>Usage Location: Resource access error response =A0=0A>Protocol Exten= sion: Bearer access token type =A0=0A>Change Controller: IETF =A0=0A>Refere= nce: [RFC-ietf-oauth-v2-bearer-23]=0A>=0A>Please see=0A>http://www.iana.org= /assignments/oauth-parameters=0A>=0A>=0A>Please let us know whether the abo= ve IANA Actions look OK. As =0A>soon as we receive your confirmation, we'll= notify the RFC Editor =0A>that this document's IANA Actions are complete. = (If this document =0A>has a team of authors, one reply on behalf of everyon= e will suffice.)=0A>=0A>Thanks,=0A>=0A>Amanda Baber=0A>ICANN/IANA=0A>=0A>= =0A=0A_______________________________________________=0AOAuth mailing list= =0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth ---125733401-297129888-1344875668=:20926 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
1) Is= it a problem that everything here seems to have "specification required" f= or the "Registration Procedures"?

2) In HTTP Authentication schemes, is th= e case insensitivity implicit here? (I think&n= bsp;so)
-bill



=
From: Dick Hardt <dick.hardt@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: Be= arer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)<= br>

=0A
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 alre= ady. :)

Begin forwarded message:

From: "Amanda Baber via R= T" <drafts-approval@iana= .org>
Subject: = [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bea= rer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) <= /b>
Date: August 10, 2012 12:20:33 PM PDT

Dear Authors:

ATTENTI= ON: 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 E= ndpoint Response Parameters:
HTTP Authentication Scheme(s): Bearer
= Change Controller: IETF         &nb= sp;
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 Con= troller: IETF  
Reference: [RFC-ietf-oauth-v2-bearer-23]

inv= alid_token
Usage Location: Resource access error response  
Prot= ocol Extension: Bearer access token type  
Change Controller: IETF =  
Reference: [RFC-ietf-oauth-v2-bearer-23]

insufficient_scop= e
Usage Location: Resource access error response  
Protocol Extension: Bearer access token type  
Change Co= ntroller: IETF  
Reference: [RFC-ietf-oauth-v2-bearer-23]

Pl= ease see
http://www.iana.org/assignments/oauth-parameters


Ple= ase let us know whether the above IANA Actions look OK. As
soon as we r= eceive your confirmation, we'll notify the RFC Editor
that this documen= t's IANA Actions are complete. (If this document
has a team of authors,= one reply on behalf of everyone will suffice.)

Thanks,

Amand= a Baber
ICANN/IANA



_______________________________________________
OAuth mailing= list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= br>
---125733401-297129888-1344875668=:20926-- From Michael.Jones@microsoft.com Tue Aug 14 11:43:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8541C21F8790 for ; Tue, 14 Aug 2012 11:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHnoTKWwm7lk for ; Tue, 14 Aug 2012 11:43:26 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id C992A21F87A0 for ; Tue, 14 Aug 2012 11:43:26 -0700 (PDT) Received: from mail200-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 18:43:17 +0000 Received: from mail200-co1 (localhost [127.0.0.1]) by mail200-co1-R.bigfish.com (Postfix) with ESMTP id C9D66A20351; Tue, 14 Aug 2012 18:43:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zf7Iz9371Ic85fh4015I9a6kzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail200-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail200-co1 (localhost.localdomain [127.0.0.1]) by mail200-co1 (MessageSwitch) id 1344969795638313_20956; Tue, 14 Aug 2012 18:43:15 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.242]) by mail200-co1.bigfish.com (Postfix) with ESMTP id 98FAE340044; Tue, 14 Aug 2012 18:43:15 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 18:43:14 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Tue, 14 Aug 2012 18:43:13 +0000 From: Mike Jones To: William Mills , Dick Hardt , "oauth@ietf.org WG" Thread-Topic: [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) Thread-Index: AQHNdzNnM13UPCZ7D0qBrM7NqoksbZdX9JwAgAGz6tA= Date: Tue, 14 Aug 2012 18:43:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667777B8@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1344875668.20926.YahooMailNeo@web31807.mail.mud.yahoo.com> In-Reply-To: <1344875668.20926.YahooMailNeo@web31807.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667777B8TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com 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) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:43:29 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667777B8TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "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 instan= ce, seems to use "Basic" and "basic" interchangeably. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam 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-i= etf-oauth-v2-bearer-23.txt) 1) Is it a problem that everything here seems to have "specification requir= ed" for the "Registration Procedures"? 2) In HTTP Authentication schemes, is the case insensitivity implicit here?= (I think so) -bill ________________________________ From: Dick Hardt > To: "oauth@ietf.org WG" > Sent: Friday, August 10, 2012 1:04 PM Subject: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Aut= horization 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 regist= rations. 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" > Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Frame= work: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-= 23.txt) Date: August 10, 2012 12:20:33 PM PDT Cc: mbj@microsoft.com, dick.hardt@gmail.com, oauth-chairs@tools.ietf.org, oauth-ads@tools.ietf.org Reply-To: drafts-approval@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 --_000_4E1F6AAD24975D4BA5B1680429673943667777B8TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Specification Requ= ired” is correct, as that’s what’s used in OAuth Core.&nb= sp; I believe that the case insensitivity comes from RFC 2617, which for in= stance, seems to use “Basic” and “basic” interchangeably.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@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 OA= uth 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 "specificatio= n required" for the "Registratio= n Procedures"?=

 

2) In HTTP Authentication schemes, is the case insensitivity implicit he= re? (I think so)

 

-bill

 

 

 

From: Dick Hardt <dick.hardt@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 (draf= t-ietf-oauth-v2-bearer-23.txt)

 

Once again, would be great to have a few more eyes checking the IANA reg= istrations. 

 

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" <<= a href=3D"mailto:drafts-approval@iana.org" target=3D"_blank">drafts-approva= l@iana.org>

Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization = Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-be= arer-23.txt)

Date: August 10, 2012 12:20:33 PM PDT

 

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         &nb= sp;
Reference: [RFC-ietf-oauth-v2-bearer-23]

Please see
http://www.ian= a.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.ian= a.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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B1680429673943667777B8TK5EX14MBXC283r_-- From wmills_92105@yahoo.com Tue Aug 14 11:51:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3521E803D for ; Tue, 14 Aug 2012 11:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0eLO1THnzdr for ; Tue, 14 Aug 2012 11:51:21 -0700 (PDT) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87521E803C for ; Tue, 14 Aug 2012 11:51:21 -0700 (PDT) Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 14 Aug 2012 18:51:21 -0000 Received: from [98.138.226.164] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 14 Aug 2012 18:51:21 -0000 Received: from [127.0.0.1] by omp1065.mail.ne1.yahoo.com with NNFMP; 14 Aug 2012 18:51:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 253724.3610.bm@omp1065.mail.ne1.yahoo.com Received: (qmail 94935 invoked by uid 60001); 14 Aug 2012 18:51:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344970280; bh=xu1F4IfMoXtrsFL7Ih3+IY3bL3VJRVG65pneEVVVw8w=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZdJ9RxBmV9yuuMh0goYhtNJF7eKMbnBeB5mv9YnbtCb88Qc/zG4LwmBNoLVXwls2YbCajQQTW14zp7W3vnnygzCcde0wjwIStKCWWb9BHXn9J3ntnkgd7hr620/GFRlGiY4NdhM70xzr4lHAauMe4TVnOJ8zD5m7NDov0+hHCwM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=moKw0o3xYp7ZwTcTCRrC/QoCZKUSpPYZlmoZaJEzuBWFAwlYxhFZ5bc/snV1dER+IrGwldq/IpwMOI++jBEOZM1NQ07ItIIIGf7WgMLmNNU/YEmI/eAVSxRbr1gA+TIN2b3OMWMUUS876N9+oJEKZ9RgjaFHb0GimjOywNhoASc=; X-YMail-OSG: HKXaPRAVM1ncMk8.K5iBIqWdTlTqe9yUPDcXrJ7bHhodTzN 3j.147TympWndZXp3v8eonGcJF7uJ6TTCgjDCAUBVuSWGW6QZNMW49jWtgix TVA29faQLENSacmt67ThTt699VeawWSSJUGNfTmlZeZM2jjVV1GrEf4KyhEf LZ0NYYd9akOIz9XkvgwBx7kbXnaUqrf3eR70xmR6MAEnOpmBxvuCjEV9cgno y4rMeQKybB2Csi_7Vr8SGSyoKjd7hEG34GIH0JgzfW3wzBSF.yKA4hyyknrp gYCUooV1NZQqzQyh8nLRvPUjO60q4zjBhTV8qT5ew74E.ssbvdH19wtD_jcE sHx1zRUrre8locF7TfAPOAkw2yr.0_xI26ea.uAPIyUdKDDqM5YYBO3_F2lz JfhxvuL.A3WSctW8wzUCVlUFw_CzOiJzWtas8nlixSDU_Kem7qOPhHDuVQ.W TiFBWJIk39bd942gYVcrDFZwQFik3qIk11tatBvHZx4v.VlwM8m._fwAUOt9 rvQ-- Received: from [209.131.62.113] by web31805.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 11:51:20 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1344875668.20926.YahooMailNeo@web31807.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B1680429673943667777B8@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1344970280.72536.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 11:51:20 -0700 (PDT) From: William Mills To: Mike Jones , Dick Hardt , "oauth@ietf.org WG" In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667777B8@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-832967850-1344970280=:72536" 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) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:51:23 -0000 ---551393103-832967850-1344970280=:72536 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks.=0A=0A=0A________________________________=0A From: Mike Jones =0ATo: William Mills ; Dick = Hardt ; "oauth@ietf.org WG" =0ASent:= Tuesday, August 14, 2012 11:43 AM=0ASubject: RE: [OAUTH-WG] Fwd: [IANA #59= 6670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token= Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)=0A =0A=0A = =0A=E2=80=9CSpecification Required=E2=80=9D is correct, as that=E2=80=99s w= hat=E2=80=99s used in OAuth Core.=C2=A0 I believe that the case insensitivi= ty comes from RFC 2617, which for instance, seems to use =E2=80=9CBasic=E2= =80=9D and =E2=80=9Cbasic=E2=80=9D interchangeably.=0A=C2=A0=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike= =0A=C2=A0=0AFrom:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of William Mills=0ASent: Monday, August 13, 2012 9:34 AM=0ATo: Dick = Hardt; oauth@ietf.org WG=0ASubject: Re: [OAUTH-WG] Fwd: [IANA #596670] Prot= ocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to= Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)=0A=C2=A0=0A1) Is it = a problem that everything here seems to have "specification required" for t= he "Registration Procedures"?=0A=C2=A0=0A2) In HTTP Authentication schemes,= is the case insensitivity implicit here? (I=C2=A0think=C2=A0so)=0A=C2=A0= =0A-bill=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=0A________________________________= =0A =0AFrom:Dick Hardt =0ATo: "oauth@ietf.org WG" =0ASent: Friday, August 10, 2012 1:04 PM=0ASubject: [OAUTH-WG= ] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framewo= rk: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23= .txt)=0A=C2=A0=0AOnce again, would be great to have a few more eyes checkin= g the IANA registrations.=C2=A0=0A=C2=A0=0ANote these are for the Bearer To= ken spec.=C2=A0=0A=C2=A0=0AI like that the error registry items are sorted = alphabetically already. :)=0A=C2=A0=0ABegin forwarded message:=0A=0A=0AFrom= : "Amanda Baber via RT" =0ASubject: [IANA #596670= ] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usa= ge' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt) =0ADate: Augus= t 10, 2012 12:20:33 PM PDT=0ACc: mbj@microsoft.com, dick.hardt@gmail.com, o= auth-chairs@tools.ietf.org, oauth-ads@tools.ietf.org=0AReply-To: drafts-app= roval@iana.org=0A=C2=A0=0ADear Authors:=0A=0AATTENTION: A RESPONSE TO THIS = MESSAGE IS NEEDED =0A=0AWe have completed the IANA Actions for RFC-to-be=0A= draft-ietf-oauth-v2-bearer-23=0A=0AACTION 1:=0A=0AIANA has registered the f= ollowing OAuth Access Token Type:=0A=0AName: Bearer=0AAdditional Endpoint R= esponse Parameters: =0AHTTP Authentication Scheme(s): Bearer =0AChange Cont= roller: IETF =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0ARefer= ence: [RFC-ietf-oauth-v2-bearer-23]=0A=0APlease see=0Ahttp://www.iana.org/a= ssignments/oauth-parameters=0A=0A=0AACTION 2:=0A=0AIANA has registered the = following in the OAuth Extensions Error Registry:=0A=0Ainvalid_request =C2= =A0=0AUsage Location: Resource access error response =C2=A0=0AProtocol Exte= nsion: Bearer access token type =C2=A0=0AChange Controller: IETF =C2=A0=0AR= eference: [RFC-ietf-oauth-v2-bearer-23]=0A=0Ainvalid_token=0AUsage Location= : Resource access error response =C2=A0=0AProtocol Extension: Bearer access= token type =C2=A0=0AChange Controller: IETF =C2=A0=0AReference: [RFC-ietf-= oauth-v2-bearer-23]=0A=0Ainsufficient_scope=0AUsage Location: Resource acce= ss error response =C2=A0=0AProtocol Extension: Bearer access token type =C2= =A0=0AChange Controller: IETF =C2=A0=0AReference: [RFC-ietf-oauth-v2-bearer= -23]=0A=0APlease see=0Ahttp://www.iana.org/assignments/oauth-parameters=0A= =0A=0APlease let us know whether the above IANA Actions look OK. As =0Asoon= as we receive your confirmation, we'll notify the RFC Editor =0Athat this = document's IANA Actions are complete. (If this document =0Ahas a team of au= thors, one reply on behalf of everyone will suffice.)=0A=0AThanks,=0A=0AAma= nda Baber=0AICANN/IANA=0A=C2=A0=0A=0A______________________________________= _________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/oauth ---551393103-832967850-1344970280=:72536 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks.

From: Mike Jones <Michael.Jones@microsoft.com= >
To: William Mills= <wmills_92105@yahoo.com>; Dick Hardt <dick.hardt@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 Tok= en Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)
<= br>=0A
=0A=0A =0A =0A

At https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/writeup/, t= here’s an RFC Editor’s note that we’ve already addressed = in edits to the spec.  Could you change the editor’s note to sim= ply say “none” like h= ttps://datatracker.ietf.org/doc/draft-ietf-oauth-v2/writeup/ does?=

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394366777A39TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Aug 14 12:28:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85ED521F86FD for ; Tue, 14 Aug 2012 12:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnBRw59bdsWY for ; Tue, 14 Aug 2012 12:28:15 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8F921F86FA for ; Tue, 14 Aug 2012 12:28:14 -0700 (PDT) Received: from mail112-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 19:28:13 +0000 Received: from mail112-am1 (localhost [127.0.0.1]) by mail112-am1-R.bigfish.com (Postfix) with ESMTP id 80E111C00C4; Tue, 14 Aug 2012 19:28:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail112-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1 (MessageSwitch) id 1344972492257538_18676; Tue, 14 Aug 2012 19:28:12 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.229]) by mail112-am1.bigfish.com (Postfix) with ESMTP id 3D999A0046; Tue, 14 Aug 2012 19:28:12 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 19:28:11 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Tue, 14 Aug 2012 19:28:08 +0000 From: Mike Jones To: William Mills , O Auth WG Thread-Topic: [OAUTH-WG] OAuth 1.0a Thread-Index: AQHNelIeRIYAXXdX2U+xkUXfulfBLJdZsS0g Date: Tue, 14 Aug 2012 19:28:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366777A7FTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:28:15 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366777A7FTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What problem are you trying to solve? From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of W= illiam 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 signi= ng and now MAC is apparently going back to the drawing board, so I'm thinki= ng about using 1.0a. Thanks, -bill --_000_4E1F6AAD24975D4BA5B168042967394366777A7FTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What problem are you tryi= ng to solve?

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@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 th= at uses signing and now MAC is apparently going back to the drawing board, so I'm thinking about using 1.0a.

 

Thanks,

 

-bill

--_000_4E1F6AAD24975D4BA5B168042967394366777A7FTK5EX14MBXC283r_-- From wmills_92105@yahoo.com Tue Aug 14 12:37:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2300021F876A for ; Tue, 14 Aug 2012 12:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvHjveycTyfu for ; Tue, 14 Aug 2012 12:37:37 -0700 (PDT) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by ietfa.amsl.com (Postfix) with ESMTP id A38E421F875E for ; Tue, 14 Aug 2012 12:37:37 -0700 (PDT) Received: from [98.139.91.63] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 14 Aug 2012 19:37:37 -0000 Received: from [98.139.91.27] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 14 Aug 2012 19:37:37 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 14 Aug 2012 19:37:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 478487.37998.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 76345 invoked by uid 60001); 14 Aug 2012 19:37:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344973056; bh=x+ljUhBdCYG/jZqbKA9OgfUcmR2hi89XqKIikRJpfNs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Kf2eQOOKjRZXdi9N1i0lN8U80CYm4sWe9V8tTvzl0H3gkxkok8BIRhOdkeA9HwINMhvsZnt2wcatbaE8Ilh07a81Xk8lfnyK9UyYLbHqtIDAZ/jXC9Z5BixqtpbLgIx+IaYGiLElkqvDVzjLQrqXrAAabe+dPLde718qHZxcEXs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JU1qK08c7t/3/mkFpkTfeALUMc6hB6pFfY08jfyyrveGsWT4YVIO6sR2uRp9uJVWcLXyRH2kG1dVFTbt+DcscAKehYIpiuJ0q3uUadQdhKesgSXsnJwapP6LMJhVkN0qyGD4oBArlO11vqBqsu0+xIxaCMJFUMYH1Hy2b/tEb5c=; X-YMail-OSG: yh884LoVM1kWAUO1qK50acIR1VkUqfuNXuhkvQAxNtVvNy0 I0f8gu2fOO5ij.f_owoLVHuPM2rwv8v5ccHn7cD8sfzB8pZeXAmmtLx9PrWv 4255V4GVnAayTHaRnRyCMRzG6m4ELDEcCSbJ7mkpOsekAmGDXhTXup9fclVi C.pdQopQItKyZ3XApoIPYgdZhZqcPRf2oLeitjBkdrYzf5J_ZAA.1a9jzzA4 h3DyRsMJFcpn0vID63cksAPX7yyFKGMSlvzOcObQj0NhGAlwvJB9OEyTjJt5 3itJoVmCKreBtqNiBDz6Pzrsm7KtIs.OkmTku.bRizRpMCPr5nwnc_Z9VHvV TQc4uFEDSSXaFR7OEGyNP3b0V85_KiigUVSjrFn1V8.RavHJ2nubzBam3AVc VStSK4Sh9y28UpTPNvFKEUbK.tIRo.rO0GfAlT8HudYdY11hVOx6F7.qY0E4 uu5L2EM4hRSJ9iaH977KHMTrqIB8UHvO5NVolXF1j4NLhx.0QfOPdTphtB_7 6YA-- Received: from [209.131.62.113] by web31812.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 12:37:36 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> Message-ID: <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 12:37:36 -0700 (PDT) From: William Mills To: Mike Jones , O Auth WG In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-1198625634-1344973056=:51964" Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:37:38 -0000 --1458549034-1198625634-1344973056=:51964 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It's for the OAUTH SASL spec. =A0I've been writing it with the idea that OA= uth 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we w= ant 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.=0A=0AI want to make sure = the SASL mechanism is build to properly handle signed auth schemes and not = just bearer (cookie) type. =A0=0A=0A-bill=0A=0A=0A_________________________= _______=0A From: Mike Jones =0ATo: William Mil= ls ; O Auth WG =0ASent: Tuesday, A= ugust 14, 2012 12:28 PM=0ASubject: RE: [OAUTH-WG] OAuth 1.0a=0A =0A=0A =0AW= hat problem are you trying to solve?=0A=A0=0AFrom:oauth-bounces@ietf.org [m= ailto:oauth-bounces@ietf.org] On Behalf Of William Mills=0ASent: Tuesday, A= ugust 14, 2012 12:22 PM=0ATo: O Auth WG=0ASubject: [OAUTH-WG] OAuth 1.0a=0A= =A0=0AWhat's the general opinion on 1.0a? =A0Am I stepping in something if = I refer to it in another draft? =A0I 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.=0A=A0=0AThanks,=0A=A0=0A-bill --1458549034-1198625634-1344973056=:51964 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It's for t= he OAUTH SASL spec.  I've been writing it with the idea that OAuth 1.0= a 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 prope= rly handle signed auth schemes and not just bearer (cookie) type.  

-bill
From: Mike Jones <Michael.Jones@= microsoft.com>
To: = William Mills <wmills_92105@yahoo.com>; O Auth WG <oauth@ietf.org&= gt;
Sent: Tuesday, Au= gust 14, 2012 12:28 PM
Subject: RE: [OAUTH-WG] OAuth 1.0a

=0A
=0A=0A =0A =0A=0A=0A
=0A
=0A
What problem are you trying to solve?
=0A
 <= /span>
=0A
=0A
=0A
= From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=0AOn= Behalf Of William Mills
=0ASent: Tuesday, August 14, 2012 12= :22 PM
=0ATo: O Auth WG
=0ASubject: [OAUTH-WG] OAuth 1.= 0a
=0A
=0A
=0A
=  
=0A
=0A
=0A
What's the general opi= nion 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 M= AC is apparently going=0A back to the drawing board, so I'm thinking about = using 1.0a.
=0A
=0A
=0A
 
=0A
=0A
=0A
Thanks,
= =0A
=0A
=0A
 
=0A
=0A=0A
-bill
=0A
=0A
=0A
=0A=
=0A=0A


--1458549034-1198625634-1344973056=:51964-- From torsten@lodderstedt.net Tue Aug 14 12:42:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFBF21E8063 for ; Tue, 14 Aug 2012 12:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Y7YCwthWsX for ; Tue, 14 Aug 2012 12:42:41 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC33221E8082 for ; Tue, 14 Aug 2012 12:42:40 -0700 (PDT) Received: from [91.2.74.115] (helo=[192.168.71.42]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T1N0g-0000zQ-Dh; Tue, 14 Aug 2012 21:42:38 +0200 Message-ID: <502AAA2D.1050404@lodderstedt.net> Date: Tue, 14 Aug 2012 21:42:37 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: William Mills References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------080307000904010005070001" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:42:42 -0000 This is a multi-part message in MIME format. --------------080307000904010005070001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > *To:* William Mills ; O Auth WG > *Sent:* Tuesday, August 14, 2012 12:28 PM > *Subject:* RE: [OAUTH-WG] OAuth 1.0a > > What problem are you trying to solve? > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@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 --------------080307000904010005070001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.Jones@microsoft.com>
To: William Mills <wmills_92105@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-bounces@ietf.org [mailto:oauth-bounces@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

--------------080307000904010005070001-- From Michael.Jones@microsoft.com Tue Aug 14 12:44:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4341121E8087 for ; Tue, 14 Aug 2012 12:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.005 X-Spam-Level: X-Spam-Status: No, score=-5.005 tagged_above=-999 required=5 tests=[AWL=0.993, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e1qTsbXF0sZ for ; Tue, 14 Aug 2012 12:44:26 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 755B921E8063 for ; Tue, 14 Aug 2012 12:44:26 -0700 (PDT) Received: from mail95-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 19:44:25 +0000 Received: from mail95-tx2 (localhost [127.0.0.1]) by mail95-tx2-R.bigfish.com (Postfix) with ESMTP id 9BDAB1401BE; Tue, 14 Aug 2012 19:44:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail95-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail95-tx2 (localhost.localdomain [127.0.0.1]) by mail95-tx2 (MessageSwitch) id 1344973463161771_13864; Tue, 14 Aug 2012 19:44:23 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.246]) by mail95-tx2.bigfish.com (Postfix) with ESMTP id 19E6BC017D; Tue, 14 Aug 2012 19:44:23 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 19:44:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Tue, 14 Aug 2012 19:44:19 +0000 From: Mike Jones To: William Mills , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] OAuth 1.0a Thread-Index: AQHNelIeRIYAXXdX2U+xkUXfulfBLJdZsS0ggAACsQCAAAFngIAAAD8w Date: Tue, 14 Aug 2012 19:44:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366777BBC@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> <502AAA2D.1050404@lodderstedt.net> In-Reply-To: <502AAA2D.1050404@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366777BBCTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:44:28 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366777BBCTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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:torsten@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 OAut= h 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we wan= t to allow for IMAP), but several folks were saying when this all started t= hat 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 a= uth schemes and not just bearer (cookie) type. -bill ________________________________ From: Mike Jones To: William Mills ; = O Auth WG Sent: Tuesday, August 14, 2012 12:28 PM Subject: RE: [OAUTH-WG] OAuth 1.0a What problem are you trying to solve? From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@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 signi= ng and now MAC is apparently going back to the drawing board, so I'm thinki= ng about using 1.0a. Thanks, -bill _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B168042967394366777BBCTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.n= et]
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 s= pec.  I've been writing it with the idea that OAuth 1.0a would work (s= ince 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 S= ASL mechanism is build to properly handle signed auth schemes and not just = bearer (cookie) type.  

 

-bill

 

From: Mike Jones <Michael.Jones@microsoft.= com>
To: William Mills <wmil= ls_92105@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-bounces@ietf.org [mailto:oauth-bounces@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 opinio= n on 1.0a?  Am I stepping in something if I refer to it in another dra= ft?  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.ie=
tf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B168042967394366777BBCTK5EX14MBXC283r_-- From wmills_92105@yahoo.com Tue Aug 14 12:53:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29B921E808E for ; Tue, 14 Aug 2012 12:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME-LpqRObb2e for ; Tue, 14 Aug 2012 12:53:45 -0700 (PDT) Received: from nm38-vm1.bullet.mail.bf1.yahoo.com (nm38-vm1.bullet.mail.bf1.yahoo.com [72.30.239.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E08D21E8063 for ; Tue, 14 Aug 2012 12:53:45 -0700 (PDT) Received: from [98.139.212.144] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 14 Aug 2012 19:53:44 -0000 Received: from [98.139.212.228] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 14 Aug 2012 19:53:44 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 14 Aug 2012 19:53:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353772.66736.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 82838 invoked by uid 60001); 14 Aug 2012 19:53:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1344974023; bh=VMAj0LWSNzvrvDDfGrIq9NnRtEDHXx7/T4hsS3xSMIM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=doVTx8AM5/LPa8muxut3U7xsV62JbjRlWZZcf/eefBFvdEa7fmwJeqzGqHTY8PUG0jBkN+DOPUnsDuLB8NwtR2mxUQpvr7i/h0I69aeJWPAhBWEgqvTGbn6IcTEioxUF7gTjzLsy0KSUcaHLw04EF6T0tWwUfWk4txux9OsnX1k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=US6lpBiJLyKNnRnsrirsgGmxOvEBzlsh4sPJ2Ew278EqxBBM7QKdYd0UxGQADtMLSRKUfWDl+jO36LZk5okL7OCIZLgJqK45q8ygx4bKpYGSyt97m7oefg3rUyiNL06BpAiGvqkzEPZUFu4j8c2bQD4uD2OOP8XugDcc43M2k0Q=; X-YMail-OSG: MyQw4qcVM1n6yDbuFFd2bQAMEub5ajFM_vbqD3oNfBC17W4 dGtPjMImSVWEsu8XRHfseaJRVNPeelrU8P6Xa0Po0XvJgvCvAg4GGuVKKrHj B.Xxlpt93FqdZ7Zv5L8O8eEQxJVJvy6PBapN6PZ_A0l5Qu7a9l.mmwtaufxs xtmxjCqh2trXRNNvXqOm1Z.0bwAjCfbPYEkYSiVFwRGz2OvrzaYou1G7wn29 yR18MTmdgUvzAsIJ1ypVRObIqbsYqN2Ll_ctwZhTjRBq7rcMXTQCkCiYy50t NDO2Ytku9OxG8H.4JA4_WwMGOQlG0ZfbMqIwLzjlmAv8xjcPqjfX2dLCfOCh yNkKtXId8nmiWvVyQbMRhxQOf68IsmqauGjbJ567rlajx7xaEkYL_JmPIv3w 1h7wKdqSr7tLmgbBZuRVfuCaPNvsSbB4OEj_i9_Z5xQbFwXtCGEI_z1HQH03 1G60nDUh4gdXj4b27Bfk6lizTkVXjWtKwT.XmhKHFHaIEigsDu7Ops0L7fax PMiw- Received: from [209.131.62.113] by web31804.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 12:53:43 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> <502AAA2D.1050404@lodderstedt.net> Message-ID: <1344974023.98979.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 12:53:43 -0700 (PDT) From: William Mills To: Torsten Lodderstedt In-Reply-To: <502AAA2D.1050404@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="835683298-1845260303-1344974023=:98979" Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:53:46 -0000 --835683298-1845260303-1344974023=:98979 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I want to get the SASL work done. =A0 HoK is interesting, but I've become c= onvinced 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. =A0 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.=0A=0A-bill=0A=0A=0A__= ______________________________=0A From: Torsten Lodderstedt =0ATo: William Mills =0ACc: Mike Jones <= Michael.Jones@microsoft.com>; O Auth WG =0ASent: Tuesday, = August 14, 2012 12:42 PM=0ASubject: Re: [OAUTH-WG] OAuth 1.0a=0A =0A=0AHi B= ill,=0A=0Ado you need to specify this aspect of your SASL profile now? Why= =0A don't you wait for the group to complete the work on signing/HoK? = =0A=0AYou could also contribute your use cases to drive the discussion.=0A= =0Abest regards,=0ATorsten.=0A=0A=0AAm 14.08.2012 21:37, schrieb William Mi= lls:=0A=0AIt's for the OAUTH SASL spec. =A0I've been writing it with the id= ea that OAuth 1.0a would work (since I think we'll have extant 1.0a typ[e t= okens we want to allow for IMAP), but several folks were saying when this a= ll started that 1.0a was dead and I should not refer to it.=0A>=0A>=0A>I wa= nt to make sure the SASL mechanism is build to properly handle signed auth = schemes and not just bearer (cookie) type. =A0=0A>=0A>=0A>-bill=0A>=0A>=0A>= =0A>________________________________=0A> From: Mike Jones =0A>To: William Mills ; O Auth WG =0A>Sent: Tuesday, August 14, 2012 12:28 PM=0A>Subject: RE: [OA= UTH-WG] OAuth 1.0a=0A> =0A>=0A> =0A>What problem are you trying to solve?= =0A>=A0=0A>From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of William Mills=0A>Sent: Tuesday, August 14, 2012 12:22 PM=0A>To: O = Auth WG=0A>Subject: [OAUTH-WG] OAuth 1.0a=0A>=A0=0A>What's the general opin= ion on 1.0a? =A0Am I stepping in something if I refer to it in another draf= t? =A0I want to reference an auth scheme that uses signing and now MAC is a= pparently going back to the drawing board, so I'm thinking about using 1.0a= .=0A>=A0=0A>Thanks,=0A>=A0=0A>-bill=0A>=0A>=0A>=0A>=0A>____________________= ___________________________=0AOAuth mailing list OAuth@ietf.org https://www= .ietf.org/mailman/listinfo/oauth --835683298-1845260303-1344974023=:98979 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I want to get th= e 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 M= AC 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 fro= m the elements that would currently be needed to support MAC or 1.0a and if= needed can just extend the SASL mechanism.

-bill<= /div>

<= font size=3D"2" face=3D"Arial">
From: Torsten Lodderstedt <torsten@lodderstedt.net= >
To: William Mills <wmi= lls_92105@yahoo.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; O Auth WG <oauth@i= etf.org>
Sent: Tue= sday, August 14, 2012 12:42 PM
Su= bject: Re: [OAUTH-WG] OAuth 1.0a

=0A
=0A =0A=0A =0A =0A
=0A Hi Bill,
=0A =
=0A do you need to specify this aspect of your SASL profile now? Wh= y=0A don't you wait for the group to complete the work on signing/HoK? <= br>=0A
=0A You could also contribute your use cases to drive the = discussion.
=0A
=0A best regards,
=0A Torsten.
=0A =
=0A
Am 14.08.2012 21:37,= schrieb William=0A Mills:
=0A
=0A
=0A
=0A
It's for the OAUTH SASL spec.  I'= ve been writing it=0A with the idea that OAuth 1.0a would work (= since I think=0A we'll have extant 1.0a typ[e tokens we want to = allow for=0A IMAP), but several folks were saying when this all = started=0A that 1.0a was dead and I should not refer to it.
=0A

=0A
=0A I want to make sure the SASL mechanism is build to=0A pro= perly handle signed auth schemes and not just bearer=0A (cookie)= type.  
=0A

=0A =0A
-bill
=0A

=0A <= /div>=0A
=0A
= =0A =0A =
=0A
=0A
What problem are you trying to solve?
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@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

= --Apple-Mail=_027B7564-2706-423B-9DAE-E166345116C4-- From rtroll@google.com Tue Aug 14 16:27:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D25421E80C4 for ; Tue, 14 Aug 2012 16:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37jJRkcFJPiD for ; Tue, 14 Aug 2012 16:27:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6016621E80A4 for ; Tue, 14 Aug 2012 16:27:47 -0700 (PDT) Received: by qcac10 with SMTP id c10so908038qca.31 for ; Tue, 14 Aug 2012 16:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=kN7/OjTS8/xr7Q8flg0n8ccuGwrg0xewZsJ3WpMV8Bc=; b=HqWNCmLSeFOcb6F0Ok51V1Q9X156NHw1BE8oThlx6jOr1OwNWZZQw+huxLHO3y2kcj rIw8c9Pj7wk6J/eEmMzKv8p3quZZrQyaPFMs/9g2IczJCvz8LhopPgVne8lSct7FFvuA cYzWlXNE1ZyJjr1/1dugpALf8U4DwPUSwe2g8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=kN7/OjTS8/xr7Q8flg0n8ccuGwrg0xewZsJ3WpMV8Bc=; b=QG7X7ERAtgPcIX+MsJ9Y20JFPitDYwN/BnnEr/GR4SZk5Ck7w7M3zltWjz2MM6XP9e JOPiW9L+gaUo0Oi2+HVVhhGlDSi9F2qFWgZsln6JLgeWFwtMad8ku1grLhaQhWNhRaUs FeJUqCOOxz97hwqLj74XyFeaN+ra/m2aYjVaDZlNVU2Uc1t1HZWgN/NQn7scKmhzsm6K TbDgRtuOd53QiLpdczxBbx2BO+KpqIwutGNuS3uHulZUDx0X1futZ2pgOBWIAQPIWgPQ s4Z76+CzKD6I6v+Wx43sMrk9RsHxkOuZT+M9sqto2GYLiVmyoF3t0euT6q4R3YZg5+7x iQhA== Received: by 10.229.134.202 with SMTP id k10mr467531qct.71.1344986866717; Tue, 14 Aug 2012 16:27:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.202 with SMTP id k10mr467521qct.71.1344986866466; Tue, 14 Aug 2012 16:27:46 -0700 (PDT) Received: by 10.229.134.13 with HTTP; Tue, 14 Aug 2012 16:27:46 -0700 (PDT) In-Reply-To: References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> <502AAA2D.1050404@lodderstedt.net> <1344974023.98979.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 16:27:46 -0700 Message-ID: From: Ryan Troll To: Dick Hardt Content-Type: multipart/alternative; boundary=00248c711815673fa004c74228a4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnjqiHBSOuCt6HG8XGlSexMKK4hDd6ibn4xAXd9VODKGztfvsJ0+X341+u2UigMFPTRvBKxYLZzWAG8TLMs8I1OTtMUnM9M2H2UkipQibhzotut8pIPKUHr6giMuga9z8ma6ER49ucekDK0gzW7+q2XuttcOrPrYRN5H5ObxBadsjobjuoMRpSzCTnFx+W/W8oPfhza Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 23:27:48 -0000 --00248c711815673fa004c74228a4 Content-Type: text/plain; charset=ISO-8859-1 And our SASL for IMAP (and SMTP) support for OAuth 2.0 will be launching in the very near future. The implementation conforms to draft-ietf-kitten-sasl-oauth-03, except for the mechanism name. (We're launching with an alternate mechanism name, so that we don't conflict with the standard when it is completed.) Once this standard is published, we'll also add support for it. -R On Tue, Aug 14, 2012 at 2:11 PM, Dick Hardt wrote: > FYI: Google's SASL for IMAP is with OAuth 1.0A -- took me a while to get > it working. > > On Aug 14, 2012, at 12: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 > *To:* William Mills > *Cc:* Mike Jones ; O Auth WG > > *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 > *To:* William Mills ; O > Auth WG > *Sent:* Tuesday, August 14, 2012 12:28 PM > *Subject:* RE: [OAUTH-WG] OAuth 1.0a > > What problem are you trying to solve? > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@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 listOAuth@ietf.orghttps://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 > > --00248c711815673fa004c74228a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And our SASL for IMAP (and SMTP) support for OAuth 2.0 will be launching in= the very near future.

The implementation conforms to dr= aft-ietf-kitten-sasl-oauth-03, except for the mechanism name. =A0(We're= launching with an alternate mechanism name, so that we don't conflict = with the standard when it is completed.) =A0Once this standard is published= , we'll also add support for it.

-R


On Tue,= Aug 14, 2012 at 2:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: Goo= gle's SASL for IMAP is with OAuth 1.0A -- took me a while to get it wor= king.

On Aug 14, 2012, at 12:53 PM, William = Mills wrote:

I want to get= the SASL work done. =A0 HoK is interesting, but I've become convinced = that it's not actually anything that needs it's own spec, you can d= o HoK with MAC or any other signed scheme by including the needed proof of = ownership in the token. =A0 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 <torsten@lodderstedt.net&g= t;
To: William Mills <wmills_92105@yahoo.c= om>
Cc: Mike Jone= s <Mich= ael.Jones@microsoft.com>; O Auth WG <oauth@ietf.org>
Sent: Tuesday, August 14, 2= 012 12:42 PM
Subject: Re= : [OAUTH-WG] OAuth 1.0a

=20 =20 =20
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? <= br>
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. =A0I've been writi= ng 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. =A0

-bill

From: Mike Jones <Michael.Jones@microsoft.com> To: William Mills <wmills_92105@yahoo.com>; O Auth = WG <oauth@ietf.org>
Sent: Tuesday, August 14, 2012 12:28 PM
Subject: RE: [OAUTH-WG] OAuth 1.0a

=20
What problem are you trying to solve?
=A0<= /span>
From:= oauth-bounces@ietf.org [mailto:oauth-bounces@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
=A0
What'= s the general opinion on 1.0a? =A0Am I stepping in something if I refer to it in another draft? =A0I 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.
=A0
Thanks,
=A0
-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
h= ttps://www.ietf.org/mailman/listinfo/oauth


--00248c711815673fa004c74228a4-- From sakimura@gmail.com Tue Aug 14 18:41:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BD821E80CD for ; Tue, 14 Aug 2012 18:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOuVhjD4Woqb for ; Tue, 14 Aug 2012 18:41:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7C6921E80E2 for ; Tue, 14 Aug 2012 18:41:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1553796obb.31 for ; Tue, 14 Aug 2012 18:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=drVIWFqKN15vpcdyWCDB7doqUdQVmnbIzLZuVSJFGWw=; b=ljcW6Ys0CzhzoY3WckAEo0wbiFZGBhbODJimhN4wuBwhKqNk02dm7HoRD5eWTLrguP /xxEjtWEfXkEmqom57ZuzPUUY5LCkzG7TOODzBDGABe+nRpfPxPPz5mOwVd8kVANqmaD LMQ4AJp1GdQtGzJU3vtTs11cvFByu7FT0gt5o/qgcr9x5aDoZf/3GIuvI8Ci1RZsZHrI B1w6H7IqknkORV2aLG5qJSzdM8KMdoXQsM5WJg06feiLLNwWGd75L7eTWf996vzmnpYA HoZsE9vZ2Lgmo7MASsV5/0GJ3UtW4hwMPZo+ydb4eMDJTRiSCZJu7VNSqKAfk6Lqj+/Y +/aA== Received: by 10.50.85.230 with SMTP id k6mr14949490igz.49.1344994874937; Tue, 14 Aug 2012 18:41:14 -0700 (PDT) References: <6C75E137-2C30-4D74-AABE-EB4D97C5B56F@oracle.com> <4E1F6AAD24975D4BA5B168042967394366777949@TK5EX14MBXC283.redmond.corp.microsoft.com> <502AB994.4040707@mitre.org> From: Nat Sakimura In-Reply-To: <502AB994.4040707@mitre.org> Mime-Version: 1.0 (1.0) Date: Wed, 15 Aug 2012 10:41:15 +0900 Message-ID: <-8175415284312961594@unknownmsgid> To: Justin Richer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] MAC Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 01:41:23 -0000 So, are we talking about the authz request or resource request? =3Dnat via iPhone On Aug 15, 2012, at 5:49 AM, Justin Richer wrote: > I would argue that it's exactly the process that you describe below that = makes my original comparison accurate. As a strawman example, OAuth2 core s= pecifies a bunch of parameters that get sent to the Auth Endpoint, like sco= pe and response_type. OpenID Connect defines a few more, like display. In o= rder to get these protected by a signature, I have to take them out of the = HTTP parameters and put them into a secondary object for message transit. W= hat I believe you're missing is that there are times where I don't *want* t= o bundle everything up into a container object. Sure it's a relatively stra= ightforward process to create a JSON object and sign it with JWS, but then = the server has to unfurl the whole thing. What if I *want* to use my existi= ng HTTP processors for pulling out variables? What if I need to do routing = based on these? Connect takes the approach of letting you specify things in= both the object and the query params and has rules about how their values = have to match. The way we've had to do this in one of our systems is to tak= e that signed JSON, preprocess it, and pretend that it's a parameter map so= that other parts of the system can make any sense of it. I don't want to h= ave to repeat that for every API I want to protect in a similar manner. > > Are there use cases for putting everything into a single object? Absolute= ly! It's a great thing to be able to do, and we are using JWT and its kin a= ll over the place to do just that. In Connect's case, there were other, mor= e complex data structures that were at play that the request object uses. B= ut if I just wanted to protect the default parameters with a signature, why= should I jump through the hoops of putting it into a container? Are you re= ally suggesting that in order to get signature protection on parameters, we= should put everything into container objects? To me, this feels like a mov= e back to SOAP more than anything else, and I'd like an alternative. > > Could the MAC-draft be a lot better at defining these parameters? Absolut= ely, which is why I think we need to fix it. History informs us but it does= n't define us: Just because it hasn't been done right yet doesn't mean that= it can't be done. Signing with the MAC algorithm *should* be simple. It sh= ould be at least as easy and powerful as OAuth1, and hopefully much easier = if we do it right. I think that there have been real suggestions about *how= * to do this as well. > > At the end of the day, I think we need both approaches for different uses= and deployments. > > -- Justin > > On 08/14/2012 03:17 PM, Mike Jones wrote: >> Replying to Justin's point about the OpenID Connect signed request objec= t, Justin, I don't believe this comparison is accurate. When an OpenID Req= uest Object is signed, a single, self-contained object is being signed. Th= e signing described in the MAC spec signs a combination of payload elements= and transport elements. It's a testament to the complexity of this approa= ch that Eran kept changing which elements were signed and which weren't in = successive drafts. >> >> Signing an OpenID Connect Request Object is simple (just apply JWS). Si= gning using the MAC algorithm is an exercise left to the reader... >> >> -- Mike >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Phil Hunt >> Sent: Friday, August 10, 2012 10:03 AM >> To: Richer, Justin P. >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] MAC Discussion >> >> There's no reason why the spec, or key elements of it can't be re-used. >> >> But to assume it should be "THE" spec, goes against previous formal cons= ensus (can't remember if it was Quebec or Paris meeting) and jumps the gun = on defining what the problem is. If we jump into a spec without defining th= e problem, we're guessing. What I saw of the previous email discussion was= a lot of circular debate indicating no clear problem definition. >> >> I agree, it would be nice to re-use code from previous implementations. = But that strikes me as an issue to raise when we discuss the implementatio= n based upon future consensus of the problem. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-08-10, at 7:49 AM, Richer, Justin P. wrote: >> >>> On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote: >>> >>>> Justin wrote: >>>> " >>>> I believe that there's value in per-message signing completely apart f= rom the channel level encryption. >>>> " >>>> >>>> May well be. But we have to figure out what exactly the reasons are wh= y there is value. >>> Yes, there is value in this, and that's why we're collecting a handful = of use cases to support this. Otherwise, people wouldn't keep reinventing t= his. See SAML and OpenID Connect's signed request object for other examples= . >>> >>>> Bill wrote: >>>> " >>>> I find the idea of starting from scratch frustrating. MAC solves a set= of specific problems and has a well defined use case. >>>> " >>>> >>>> This would be a very quick process if we had ever done our home work p= roperly. >>> It's not done, but it's not empty. Why throw it out? Whether or not we = continue the draft itself or import its best ideas into a new draft is besi= de the point. >>> >>>> So, what are the problems it tries to solve? Yesterday I found an old = presentation about MAC and the basic argument was that it has better perfor= mance than TLS. While that's true it is not a good argument per se. However= , performance is not the only factor to look at and the negative performanc= e impact caused by TLS is overrated. >>> This is a red herring, as pointed out by other use cases. >>> >>>> Here is the slide set I am talking about: >>>> http://www.tschofenig.priv.at/Why_are_we_Signing.pdf >>>> >>>> In many cases I had noticed that more time was spent with the pictures= (in slides and blog post) than with the content. That's not good IMHO. >>>> >>>> Bill, we can hardly call a specification "complete" if many of us don'= t know what problem it solves. John phrases it nicely as "Part of the probl= em with MAC has been that people could never agree on what it was protectin= g against." I am also interested in hearing about deployment constraints th= at people have. Blaine always said that many developers cannot get TLS to w= ork. I am sure that's true but OAuth 2.0 requires TLS to be used anyway to = secure the interaction with the authorization server. >>> It solves this problem: How can I use the framework of OAuth to get a t= emporary signing key that I can use to protect HTTP messages with signing (= without stuffing my parameters into a structured document like a SAML or JW= T assertion)? There are many justifications for that problem and use cases = that expand on this, but that's the core thing that the MAC does. >>> >>>> Note: I am not saying that we are not going to standardize something l= ike the MAC token (maybe with different details) but let us spend a little = bit of time to figure out what threats we want to deal with. >>> It's not just about threats, it's about capabilities and features. >>> >>> -- Justin >>> >>>> _______________________________________________ >>>> 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 From hannes.tschofenig@gmx.net Tue Aug 14 22:48:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49F821F8652 for ; Tue, 14 Aug 2012 22:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAqVzTd2eFEh for ; Tue, 14 Aug 2012 22:48:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EEF8421F8650 for ; Tue, 14 Aug 2012 22:48:41 -0700 (PDT) Received: (qmail invoked by alias); 15 Aug 2012 05:48:40 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 15 Aug 2012 07:48:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180XoMNdwc0huLpSsgWgZ7q4HHFjembWPvE6g31ZQ tK7iwvEH+FDgeS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Wed, 15 Aug 2012 08:48:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:48:42 -0000 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: > =95 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. > =95 Copy relevant parts from = http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which = there is almost no deployment). > =95 Wait for the Oauth group to settle on a mechanism. May take = time.=20 I doubt that the question about the views of the WG about OAuth 1.0a can = answer any of the above questions.=20 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.=20 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. >=20 > I want to make sure the SASL mechanism is build to properly handle = signed auth schemes and not just bearer (cookie) type. =20 >=20 > -bill >=20 > From: Mike Jones > To: William Mills ; O Auth WG =20= > Sent: Tuesday, August 14, 2012 12:28 PM > Subject: RE: [OAUTH-WG] OAuth 1.0a >=20 > What problem are you trying to solve? > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@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 > =20 > 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. > =20 > Thanks, > =20 > -bill >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Tue Aug 14 22:49:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CAA21F865C for ; Tue, 14 Aug 2012 22:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvogKzJtmtMp for ; Tue, 14 Aug 2012 22:49:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CD28021F8650 for ; Tue, 14 Aug 2012 22:49:04 -0700 (PDT) Received: (qmail invoked by alias); 15 Aug 2012 05:49:03 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp016) with SMTP; 15 Aug 2012 07:49:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/zZUauvt/EayQxP/4/P4K3hRbu+VOU20KHBPv9E Tl3ZUtUiXkIicd Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1344974023.98979.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Wed, 15 Aug 2012 08:49:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> <502AAA2D.1050404@lodderstedt.net> <1344974023.98979.YahooMailNeo@web31804.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:49:05 -0000 Hi Bill,=20 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.=20 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. >=20 > -bill >=20 > From: Torsten Lodderstedt > To: William Mills =20 > Cc: Mike Jones ; O Auth WG = =20 > Sent: Tuesday, August 14, 2012 12:42 PM > Subject: Re: [OAUTH-WG] OAuth 1.0a >=20 > Hi Bill, >=20 > 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?=20 >=20 > You could also contribute your use cases to drive the discussion. >=20 > best regards, > Torsten. >=20 > 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. >>=20 >> I want to make sure the SASL mechanism is build to properly handle = signed auth schemes and not just bearer (cookie) type. =20 >>=20 >> -bill >>=20 >> From: Mike Jones >> To: William Mills ; O Auth WG = =20 >> Sent: Tuesday, August 14, 2012 12:28 PM >> Subject: RE: [OAUTH-WG] OAuth 1.0a >>=20 >> What problem are you trying to solve? >> =20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@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 >> =20 >> 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. >> =20 >> Thanks, >> =20 >> -bill >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Tue Aug 14 22:50:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EAA21F865D for ; Tue, 14 Aug 2012 22:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqhv4Xubrh-J for ; Tue, 14 Aug 2012 22:50:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3080121F8650 for ; Tue, 14 Aug 2012 22:50:22 -0700 (PDT) Received: (qmail invoked by alias); 15 Aug 2012 05:50:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp028) with SMTP; 15 Aug 2012 07:50:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/P+1tB4HrPN/0twdwFQw56HSl1mx/jahIDESCi8p f6VBGX8rtQMnQQ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <-8175415284312961594@unknownmsgid> Date: Wed, 15 Aug 2012 08:50:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <242C1174-4141-4F60-8818-9095A01CA215@gmx.net> References: <6C75E137-2C30-4D74-AABE-EB4D97C5B56F@oracle.com> <4E1F6AAD24975D4BA5B168042967394366777949@TK5EX14MBXC283.redmond.corp.microsoft.com> <502AB994.4040707@mitre.org> <-8175415284312961594@unknownmsgid> To: Nat Sakimura X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] MAC Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:50:25 -0000 Hi Nat,=20 in the MAC discussions I was only talking about the interaction between = the client and the resource server.=20 Ciao Hannes On Aug 15, 2012, at 4:41 AM, Nat Sakimura wrote: > So, are we talking about the authz request or resource request? >=20 > =3Dnat via iPhone >=20 > On Aug 15, 2012, at 5:49 AM, Justin Richer wrote: >=20 >> I would argue that it's exactly the process that you describe below = that makes my original comparison accurate. As a strawman example, = OAuth2 core specifies a bunch of parameters that get sent to the Auth = Endpoint, like scope and response_type. OpenID Connect defines a few = more, like display. In order to get these protected by a signature, I = have to take them out of the HTTP parameters and put them into a = secondary object for message transit. What I believe you're missing is = that there are times where I don't *want* to bundle everything up into a = container object. Sure it's a relatively straightforward process to = create a JSON object and sign it with JWS, but then the server has to = unfurl the whole thing. What if I *want* to use my existing HTTP = processors for pulling out variables? What if I need to do routing based = on these? Connect takes the approach of letting you specify things in = both the object and the query params and has rules about how their = values have to match.=20 > The way we've had to do this in one of our systems is to take that = signed JSON, preprocess it, and pretend that it's a parameter map so = that other parts of the system can make any sense of it. I don't want to = have to repeat that for every API I want to protect in a similar manner. >>=20 >> Are there use cases for putting everything into a single object? = Absolutely! It's a great thing to be able to do, and we are using JWT = and its kin all over the place to do just that. In Connect's case, there = were other, more complex data structures that were at play that the = request object uses. But if I just wanted to protect the default = parameters with a signature, why should I jump through the hoops of = putting it into a container? Are you really suggesting that in order to = get signature protection on parameters, we should put everything into = container objects? To me, this feels like a move back to SOAP more than = anything else, and I'd like an alternative. >>=20 >> Could the MAC-draft be a lot better at defining these parameters? = Absolutely, which is why I think we need to fix it. History informs us = but it doesn't define us: Just because it hasn't been done right yet = doesn't mean that it can't be done. Signing with the MAC algorithm = *should* be simple. It should be at least as easy and powerful as = OAuth1, and hopefully much easier if we do it right. I think that there = have been real suggestions about *how* to do this as well. >>=20 >> At the end of the day, I think we need both approaches for different = uses and deployments. >>=20 >> -- Justin >>=20 >> On 08/14/2012 03:17 PM, Mike Jones wrote: >>> Replying to Justin's point about the OpenID Connect signed request = object, Justin, I don't believe this comparison is accurate. When an = OpenID Request Object is signed, a single, self-contained object is = being signed. The signing described in the MAC spec signs a combination = of payload elements and transport elements. It's a testament to the = complexity of this approach that Eran kept changing which elements were = signed and which weren't in successive drafts. >>>=20 >>> Signing an OpenID Connect Request Object is simple (just apply JWS). = Signing using the MAC algorithm is an exercise left to the reader... >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Phil Hunt >>> Sent: Friday, August 10, 2012 10:03 AM >>> To: Richer, Justin P. >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] MAC Discussion >>>=20 >>> There's no reason why the spec, or key elements of it can't be = re-used. >>>=20 >>> But to assume it should be "THE" spec, goes against previous formal = consensus (can't remember if it was Quebec or Paris meeting) and jumps = the gun on defining what the problem is. If we jump into a spec without = defining the problem, we're guessing. What I saw of the previous email = discussion was a lot of circular debate indicating no clear problem = definition. >>>=20 >>> I agree, it would be nice to re-use code from previous = implementations. But that strikes me as an issue to raise when we = discuss the implementation based upon future consensus of the problem. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-08-10, at 7:49 AM, Richer, Justin P. wrote: >>>=20 >>>> On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote: >>>>=20 >>>>> Justin wrote: >>>>> " >>>>> I believe that there's value in per-message signing completely = apart from the channel level encryption. >>>>> " >>>>>=20 >>>>> May well be. But we have to figure out what exactly the reasons = are why there is value. >>>> Yes, there is value in this, and that's why we're collecting a = handful of use cases to support this. Otherwise, people wouldn't keep = reinventing this. See SAML and OpenID Connect's signed request object = for other examples. >>>>=20 >>>>> Bill wrote: >>>>> " >>>>> I find the idea of starting from scratch frustrating. MAC solves a = set of specific problems and has a well defined use case. >>>>> " >>>>>=20 >>>>> This would be a very quick process if we had ever done our home = work properly. >>>> It's not done, but it's not empty. Why throw it out? Whether or not = we continue the draft itself or import its best ideas into a new draft = is beside the point. >>>>=20 >>>>> So, what are the problems it tries to solve? Yesterday I found an = old presentation about MAC and the basic argument was that it has better = performance than TLS. While that's true it is not a good argument per = se. However, performance is not the only factor to look at and the = negative performance impact caused by TLS is overrated. >>>> This is a red herring, as pointed out by other use cases. >>>>=20 >>>>> Here is the slide set I am talking about: >>>>> http://www.tschofenig.priv.at/Why_are_we_Signing.pdf >>>>>=20 >>>>> In many cases I had noticed that more time was spent with the = pictures (in slides and blog post) than with the content. That's not = good IMHO. >>>>>=20 >>>>> Bill, we can hardly call a specification "complete" if many of us = don't know what problem it solves. John phrases it nicely as "Part of = the problem with MAC has been that people could never agree on what it = was protecting against." I am also interested in hearing about = deployment constraints that people have. Blaine always said that many = developers cannot get TLS to work. I am sure that's true but OAuth 2.0 = requires TLS to be used anyway to secure the interaction with the = authorization server. >>>> It solves this problem: How can I use the framework of OAuth to get = a temporary signing key that I can use to protect HTTP messages with = signing (without stuffing my parameters into a structured document like = a SAML or JWT assertion)? There are many justifications for that problem = and use cases that expand on this, but that's the core thing that the = MAC does. >>>>=20 >>>>> Note: I am not saying that we are not going to standardize = something like the MAC token (maybe with different details) but let us = spend a little bit of time to figure out what threats we want to deal = with. >>>> It's not just about threats, it's about capabilities and features. >>>>=20 >>>> -- Justin >>>>=20 >>>>> _______________________________________________ >>>>> 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 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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 From wmills_92105@yahoo.com Tue Aug 14 23:10:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAAC21F85D7 for ; Tue, 14 Aug 2012 23:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXluFngV5Etk for ; Tue, 14 Aug 2012 23:10:53 -0700 (PDT) Received: from nm2-vm4.bullet.mail.ne1.yahoo.com (nm2-vm4.bullet.mail.ne1.yahoo.com [98.138.91.162]) by ietfa.amsl.com (Postfix) with SMTP id EA10721F85D6 for ; Tue, 14 Aug 2012 23:10:52 -0700 (PDT) Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:10:51 -0000 Received: from [98.138.89.161] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:10:51 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:10:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 690870.30718.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 83347 invoked by uid 60001); 15 Aug 2012 06:10:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345011050; bh=aG54Wod4mOfa8/t+S7WrKebk5/EGYn/fTuAlD9ZufUw=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j7Bw0hzyFYPcv1RyqveeI2dREPdQqmgG7H3CsoKiveG6JjXCWglYr3D4BQn+nvS9frTyoC9eHeYTBfbVd184YP8Llra80w7l3Zr8WAHuXTjMVud7j6UrVc3D/CftV03OXCRlLCcJejp2QuUIfhwg9rm2ZT59wSP7wt8Mm1kaYdQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S5nFIf96/xH/seh4IugQLWN+ul35BaKSNeL/My/gKV8RPcdyt3Dgs2PbuFXyqwTC81tZ6j1V0opIEsioPTTJI3FqWuzoSmh2WIxE+WMp7kklwUor3L8hm9odzHiElT0SbIxw016hhoAnqNzTB4vbQzho7QR2r9GuZN1bNUpefVI=; X-YMail-OSG: inX0bgoVM1krHhQKen1cuG6CEamRG4mJbejAl7Nn5zgNsG5 mMaEQLcPrKsbySl5p2Emp7xyeYYhUPi.J8Wr1hYWsRJ7_eR81bkQmW5BOZDZ MqIuPHoMpOozGznx2_M_Rbr.j6DtYou0xt0sHVsTlTw0m8snj0cgkflIWS5k e8kFn5Bpwz0X_AiVyFrt433Z8._08TUepHInus_38zWTruX7hrcCExDTTzzu rC_34dVSJr7CDVT179NavnM2nj2iSteDqN8UMalIxricRzSyhHKJP9uYA83U GarDxLQrByVqRbXFU0Xqe8nz4vIK3AHynNumVXxZ6BeX3hlDjmpCjQ.AVSrz 4_l5f5sUV.fgv9eQZFHQiUbW4Whn9vgh67QzCS.x0m_BmtHwS4jwxdyDjlso rE8Eer_RTfQVtChlH9Ff4w.Eo42VV4Auk0l.Nqc..7o7tDVxL1Pa3dkJBAYG ge.7Om0Jjh7b_OEkzFfWOlYzNBfFOGktMtE.r79SgBxErhkhLzDwQe8o0B0c bltK6D6h2.8qVh2O3Deu.MQ-- Received: from [209.131.62.115] by web31813.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 23:10:50 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1345011050.82572.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 23:10:50 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="767760015-221394207-1345011050=:82572" Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 06:10:54 -0000 --767760015-221394207-1345011050=:82572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You are mistaken, I cite MAC directly right now, but now that it is up in t= he 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. = =C2=A0MAC is now in flux again, the other 3 are stable or already standards= .=0A=0AI think you also mistaken that we can't support 1.0a and OAuth 2 tok= ens in the same SASL mechanism. =C2=A0Why do you think this is true?=0A=0A= =0A________________________________=0A From: Hannes Tschofenig =0ATo: William Mills =0ACc: Hannes = Tschofenig ; Mike Jones ; O Auth WG =0ASent: Tuesday, August 14, 2012 10:48 P= M=0ASubject: Re: [OAUTH-WG] OAuth 1.0a=0A =0AFYI: just to repeat my note he= re as well that I sent to Bill on the KITTEN list:=0A=0AI see three possibl= e ways forward for the OAuth SASL work, namely:=0A=0A> =C2=A0=C2=A0=C2=A0 = =E2=80=A2 Focus on Oauth 1.0 only (since it has a MAC specification in ther= e). Then, you ignore all the Oauth 2.0 deployment that is out there, of whi= ch there is a lot. That would be pretty bad IMHO.=0A> =C2=A0=C2=A0=C2=A0 = =E2=80=A2 Copy relevant parts from http://tools.ietf.org/html/draft-ietf-oa= uth-v2-http-mac-01 (of which there is almost no deployment).=0A> =C2=A0=C2= =A0=C2=A0 =E2=80=A2 Wait for the Oauth group to settle on a mechanism. May = take time. =0A=0A=0AI doubt that the question about the views of the WG abo= ut OAuth 1.0a can answer any of the above questions. =0A=0ABill does not wa= nt to wait. He also does not want to copy parts from draft-ietf-oauth-v2-ht= tp-mac-01 into the SASL OAuth spec. Focusing on OAuth 1.0 for now would req= uire the specification to be extended later on to fit to OAuth 2.0 deployme= nts (and whatever new security mechanism we will come up with). As a conseq= uence, the specification will then suffer from additional complexity. =0A= =0ACiao=0AHannes=0A=0AOn Aug 14, 2012, at 10:37 PM, William Mills wrote:=0A= =0A> It's for the OAUTH SASL spec.=C2=A0 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 tok= ens 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.=0A> =0A> I want t= o make sure the SASL mechanism is build to properly handle signed auth sche= mes and not just bearer (cookie) type.=C2=A0 =0A> =0A> -bill=0A> =0A> From:= Mike Jones =0A> To: William Mills ; O Auth WG =0A> Sent: Tuesday, August 14, 20= 12 12:28 PM=0A> Subject: RE: [OAUTH-WG] OAuth 1.0a=0A> =0A> What problem ar= e you trying to solve?=0A>=C2=A0 =0A> From: oauth-bounces@ietf.org [mailto:= oauth-bounces@ietf.org] On Behalf Of William Mills=0A> Sent: Tuesday, Augus= t 14, 2012 12:22 PM=0A> To: O Auth WG=0A> Subject: [OAUTH-WG] OAuth 1.0a=0A= >=C2=A0 =0A> What's the general opinion on 1.0a?=C2=A0 Am I stepping in som= ething if I refer to it in another draft?=C2=A0 I want to reference an auth= scheme that uses signing and now MAC is apparently going back to the drawi= ng board, so I'm thinking about using 1.0a.=0A>=C2=A0 =0A> Thanks,=0A>=C2= =A0 =0A> -bill=0A> =0A> =0A> ______________________________________________= _=0A> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailma= n/listinfo/oauth --767760015-221394207-1345011050=:82572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You are mi= staken, I cite MAC directly right now, but now that it is up in the air I w= ould much rather rely on 3 specs (Oauth 2 core, Bearer, and 1.0a) than refe= r 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 w= e can't support 1.0a and OAuth 2 tokens in the same SASL mechanism.  W= hy do you think this is true?

=
From: Hannes Tsc= hofenig <hannes.tschofenig@gmx.net>
Cc: Hannes Tschofenig <hannes.ts= chofenig@gmx.net>; Mike Jones <Michael.Jones@microsoft.com>; O Aut= h WG <oauth@ietf.org>
Sent= : Tuesday, August 14, 2012 10:48 PM
Subject: Re: [OAUTH-WG] OAuth 1.0a
=0AFYI: 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 SAS= L work, namely:

>     =E2=80=A2 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 woul= d be pretty bad IMHO.
>     =E2=80=A2 Copy relevant pa= rts from http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of whi= ch there is almost no deployment).
>     =E2=80=A2 Wai= t 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 an= swer any of the above questions.

Bill does not want to wait. He als= o 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 specifica= tion to be extended later on to fit to OAuth 2.0 deployments (and whatever new security mechan= ism we will come up with). As a consequence, the specification will then su= ffer from additional complexity.

Ciao
Hannes

On Aug 14, 2= 012, 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 a= nd 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 bear= er (cookie) type. 
>
> -bill
>
> From: Mike= Jones <Michael.Jones@microsoft.com>
> T= o: William Mills <wmills_92105@yahoo.com>; O A= uth WG <oauth@ietf.org>
> Sent: Tuesday, August 14, 2012 12:28 PM=
> Subject: RE: [OAUTH-WG] OAuth 1.0a
>
> What problem a= re you trying to solve?
> 
> From: oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Wil= liam Mills
> Sent: Tuesday, August 14, 2012 12:22 PM
> To: O Au= th 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 si= gning and now MAC is apparently going back to the drawing board, so I'm thi= nking about using 1.0a.
> 
> Thanks,
> 
> -b= ill
>
>
> _____________________________________________= __
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/oauth



<= /html> --767760015-221394207-1345011050=:82572-- From wmills_92105@yahoo.com Tue Aug 14 23:16:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC5621F865E for ; Tue, 14 Aug 2012 23:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC1ddp-LxZ79 for ; Tue, 14 Aug 2012 23:16:13 -0700 (PDT) Received: from nm39-vm5.bullet.mail.ne1.yahoo.com (nm39-vm5.bullet.mail.ne1.yahoo.com [98.138.229.165]) by ietfa.amsl.com (Postfix) with SMTP id DC47221F8620 for ; Tue, 14 Aug 2012 23:16:12 -0700 (PDT) Received: from [98.138.90.50] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:16:02 -0000 Received: from [98.138.88.232] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:16:01 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:16:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 864873.95950.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 59460 invoked by uid 60001); 15 Aug 2012 06:16:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345011361; bh=aquZhruE9cHVAmp2A1QFQ4vG48OaVWFDlqdn+02Lja8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PTUdGD6DWw1s/lPfAmxeF5po8wz1ifR4CQcDtsgNmjdmTz1fVeSaPua2LHAsNXGOwKqRi6b1JTgRGbk+QHamMa9O9akjZ9YiUR2Ubg5jRzOxSvGnxQJJ/CgrY+O/p8ombMMCxwLF6faowwvrIULGT0ZvcbJF0iuFh0a8vZMeW3U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M2UGme5W3qX2NSTMegUml2Lw3rBpJmbKL5xTYUnHG76g5Fyo/OZBZ8V5co3UH9yRBzyundrdLp+SlEWt9fPMj8sa+XZfgxAHTrpxR7jT6gb+QN67H690SPEtdEaRzA9WVaXJ5H3IgVivRKymvXA+cIiIyjvWdqdqvvW6kD5PzYk=; X-YMail-OSG: Pc5m.UkVM1ndMcGjp9UT.GdZVF2ALjApig_H9DxrGnd405N D8Hj880TlEU88w3r39sLsC8Jf8bJiwMWyyEGCLlYmzR6fno_z1UoTNwi.tQK GpC1n26dkIZvLaWf9oJPzOxwaqczk2Hu4.L9SyiDu2JWIw4ZErSaCrErBwgG wS4tNeYwbVmMWS_AvpUHAaEIelXtTsspzGOWz0w1ISDEZDGkJ8wG_cD0ohWL azplVaCTv8ep8vFU7GVwsvKdwGzzXI3uIkjOftCCHRMl7kpmwwTDAf3DrmZF OO3XXSvcaZU.IvxK4ximbfUDdQuYYF4Xiee0l7zQTWB4CTSiPoD74OnJwiiu 4f9Kzo4eCIGBnhWmyEKVo4LYiWJ_7Z77ysEtWo24WueUqhOvZpdF4HaTL4Yd Z9lClf1YTTWQOE3QsbTXRQRO6Nt29DCa41QYBf3ETjAhl2imdZZO.K0d6Bbb mzFaosKG0JWt9xLBMVwaoUpkwmyWTGCFgI540Yy4D9mR8P4cKxcxyRx1JTEQ HnIw- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 23:16:01 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1344972117.60342.YahooMailNeo@web31802.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B168042967394366777A7F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1344973056.51964.YahooMailNeo@web31812.mail.mud.yahoo.com> <502AAA2D.1050404@lodderstedt.net> <1344974023.98979.YahooMailNeo@web31804.mail.mud.yahoo.com> Message-ID: <1345011361.54744.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 23:16:01 -0700 (PDT) From: William Mills To: Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-818528360-1345011361=:54744" Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 06:16:14 -0000 ---1238014912-818528360-1345011361=:54744 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Fundamentally MAC and any HoK that uses symmetric keys are equivalent. =A0E= ither can pull in the same profile of HTTP stuff into the signature.=0A=0AI= commented on your argument that MAC and Bearer have equivalent security pr= operties in a different thread.=0A=0A-bill=0A=0A=0A________________________= ________=0A From: Hannes Tschofenig =0ATo: Willi= am Mills =0ACc: Hannes Tschofenig ; Torsten Lodderstedt ; O Auth WG =0ASent: Tuesday, August 14, 2012 10:49 PM=0ASubject: Re: [OAUT= H-WG] OAuth 1.0a=0A =0AHi Bill, =0A=0Ahow do you know that the outcome of t= he security discussions will unlikely be different than MAC?=0A=0AThe 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 t= o server key confirmation with integrity protection of a few fields but mor= e than that. In a nutshell the solution has to provide better security than= bearer -- not just be different. =0A=0ACiao=0AHannes=0A=0AOn Aug 14, 2012,= at 10:53 PM, William Mills wrote:=0A=0A> I want to get the SASL work done.= =A0 HoK is interesting, but I've become convinced that it's not actually a= nything that needs it's own spec, you can do HoK with MAC or any other sign= ed scheme by including the needed proof of ownership in the token.=A0 HoK,= however it works out, is unlikely to vary a lot from the elements that wou= ld currently be needed to support MAC or 1.0a and if needed can just extend= the SASL mechanism.=0A> =0A> -bill=0A> =0A> From: Torsten Lodderstedt =0A> To: William Mills =0A> C= c: Mike Jones ; O Auth WG =0A= > Sent: Tuesday, August 14, 2012 12:42 PM=0A> Subject: Re: [OAUTH-WG] OAuth= 1.0a=0A> =0A> Hi Bill,=0A> =0A> 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? =0A> =0A> You could also contribute your use cases to drive t= he discussion.=0A> =0A> best regards,=0A> Torsten.=0A> =0A> Am 14.08.2012 2= 1:37, schrieb William Mills:=0A>> It's for the OAUTH SASL spec.=A0 I've bee= n 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 refe= r to it.=0A>> =0A>> I want to make sure the SASL mechanism is build to prop= erly handle signed auth schemes and not just bearer (cookie) type.=A0 =0A>>= =0A>> -bill=0A>> =0A>> From: Mike Jones =0A>>= To: William Mills ; O Auth WG =0A= >> Sent: Tuesday, August 14, 2012 12:28 PM=0A>> Subject: RE: [OAUTH-WG] OAu= th 1.0a=0A>> =0A>> What problem are you trying to solve?=0A>>=A0 =0A>> From= : oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Willi= am Mills=0A>> Sent: Tuesday, August 14, 2012 12:22 PM=0A>> To: O Auth WG=0A= >> Subject: [OAUTH-WG] OAuth 1.0a=0A>>=A0 =0A>> What's the general opinion = on 1.0a?=A0 Am I stepping in something if I refer to it in another draft?= =A0 I want to reference an auth scheme that uses signing and now MAC is app= arently going back to the drawing board, so I'm thinking about using 1.0a.= =0A>>=A0 =0A>> Thanks,=0A>>=A0 =0A>> -bill=0A>> =0A>> =0A>> =0A>> =0A>> ___= ____________________________________________=0A>> OAuth mailing list=0A>> = =0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/oauth=0A> = =0A> =0A> =0A> _______________________________________________=0A> OAuth ma= iling list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oau= th ---1238014912-818528360-1345011361=:54744 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Fundamentally MA= C and any HoK that uses symmetric keys are equivalent.  Either can pul= l in the same profile of HTTP stuff into the signature.

I commented on your argument that MAC and Bearer have equivalent secu= rity properties in a different thread.

-bill
=

From: Hannes Tschofenig <hannes.tschofenig@gmx.net><= br> To: William Mills <= wmills_92105@yahoo.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Torsten Lodderstedt &= lt;torsten@lodderstedt.net>; O Auth WG <oauth@ietf.org>
Sent: Tuesday, August 14, 2012 = 10:49 PM
Subject: Re: = [OAUTH-WG] OAuth 1.0a

=0AHi Bill,

how do you= know that the outcome of the security discussions will unlikely be differe= nt 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 certificat= es), 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 prote= ction 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 unli= kely to vary a lot from the elements that would currently be needed to support MAC or 1.0a and if needed can just ex= tend the SASL mechanism.
>
> -bill
>
> From: Tors= ten Lodderstedt <torsten@lodderstedt.net>
> To: = William Mills <wmills_92105@yahoo.com>
> Cc: Mike= Jones <Michael.Jones@microsoft.com>; O Auth W= G <o= auth@ietf.org>
> Sent: Tuesday, August 14, 2012 12:42 PM
&= gt; 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, s= chrieb 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 fo= lks were saying when this all started that 1.0a was dead and I should not r= efer to it.
>>
>> I want to make sure the SASL mechanism= is build to properly handle signed auth schemes and not just bearer (cooki= e) type. 
>>
>> -bill
>>
>> Fro= m: Mike Jones <Michael.Jones@microsoft.com>>> To: William Mills <wmills_92105@yahoo.com>; O Auth WG <oauth@ietf.org>
>> Sent: Tuesday, August 14, 2012 12= :28 PM
>> Subject: RE: [OAUTH-WG] OAuth 1.0a
>>
>&= gt; What problem are you trying to solve?
>> 
>> Fr= om: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of William Mills
>> Sent: Tuesday, August 14, = 2012 12:22 PM
>> To: O Auth WG
>> Subject: [OAUTH-WG] OAu= th 1.0a
>> 
>> What's the general opinion on 1.0a?&= nbsp; 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 apparent= ly 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/mailm= an/listinfo/oauth
>
>
>
> __________________= _____________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



---1238014912-818528360-1345011361=:54744-- From hannes.tschofenig@nsn.com Tue Aug 14 23:26:59 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D2421F8687 for ; Tue, 14 Aug 2012 23:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.605 X-Spam-Level: X-Spam-Status: No, score=-105.605 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibpIxymIfUmC for ; Tue, 14 Aug 2012 23:26:56 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id BC21121F8683 for ; Tue, 14 Aug 2012 23:26:55 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7F6QsHP015315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 08:26:54 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7F6QsLc003217; Wed, 15 Aug 2012 08:26:54 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Aug 2012 08:26:54 +0200 Received: from 10.144.250.187 ([10.144.250.187]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Aug 2012 06:26:52 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Wed, 15 Aug 2012 09:26:48 +0300 From: Hannes Tschofenig To: William Mills , Hannes Tschofenig Message-ID: Thread-Topic: [OAUTH-WG] OAuth 1.0a Thread-Index: Ac16rvLMhl3vRRcCDUqid4/Wc1ilhw== In-Reply-To: <1345011050.82572.YahooMailNeo@web31813.mail.mud.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3427867610_26668852" X-OriginalArrivalTime: 15 Aug 2012 06:26:54.0085 (UTC) FILETIME=[F66D0350:01CD7AAE] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10500 X-purgate-ID: 151667::1345012014-00003184-C3BF1A63/0-0/0-0 Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 06:26:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3427867610_26668852 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Bill,=20 I know that you can reference many specifications. I already see you being referenced by Eran in an upcoming blog post about the complexity and the lack of interoperability you have added even to SASL Oauth ;-) Ciao Hannes On 8/15/12 9:10 AM, "ext William Mills" wrote: > 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. >=20 > I think you also mistaken that we can't support 1.0a and OAuth 2 tokens i= n the > same SASL mechanism. Why do you think this is true? >=20 > =20 > =20 > =20 > =20 >=20 > From: Hannes Tschofenig > To: William Mills > Cc: Hannes Tschofenig ; Mike Jones > ; O Auth WG > Sent: Tuesday, August 14, 2012 10:48 PM > Subject: Re: [OAUTH-WG] OAuth 1.0a > =20 > =20 > FYI: just to repeat my note here as well that I sent to Bill on the KITTE= N > list: >=20 > I see three possible ways forward for the OAuth SASL work, namely: >=20 >> > =80 Focus on Oauth 1.0 only (since it has a MAC specification in the= re). >> Then, you ignore all the Oauth 2.0 deployment that is out there, of whic= h >> there is a lot. That would be pretty bad IMHO. >> > =80 Copy relevant parts from >> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 (of which the= re is >> almost no deployment). >> > =80 Wait for the Oauth group to settle on a mechanism. May take time= . >=20 >=20 > I doubt that the question about the views of the WG about OAuth 1.0a can > answer any of the above questions. >=20 > 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 OAu= th > 1.0 for now would require the specification to be extended later on to fi= t to > OAuth 2.0 deployments (and whatever new security mechanism we will come u= p > with). As a consequence, the specification will then suffer from addition= al > complexity.=20 >=20 > Ciao > Hannes >=20 > On Aug 14, 2012, at 10:37 PM, William Mills wrote: >=20 >> > 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 sta= rted >> that 1.0a was dead and I should not refer to it. >> >=20 >> > I want to make sure the SASL mechanism is build to properly handle sig= ned >> auth schemes and not just bearer (cookie) type. >> >=20 >> > -bill >> >=20 >> > From: Mike Jones >> > To: William Mills ; O Auth WG >> > Sent: Tuesday, August 14, 2012 12:28 PM >> > Subject: RE: [OAUTH-WG] OAuth 1.0a >> >=20 >> > What problem are you trying to solve? >> > =20 >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@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 >> > =20 >> > What's the general opinion on 1.0a? Am I stepping in something if I r= efer >> to it in another draft? I want to reference an auth scheme that uses si= gning >> and now MAC is apparently going back to the drawing board, so I'm thinki= ng >> about using 1.0a. >> > =20 >> > Thanks, >> > =20 >> > -bill >> >=20 >> >=20 >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =20 > =20 > =20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --B_3427867610_26668852 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] OAuth 1.0a Hi Bill,

I know that you can reference many specifications.

I already see you being referenced by Eran in an upcoming blog post about t= he complexity and the lack of interoperability you have added even to SASL O= auth ;-)

Ciao
Hannes


On 8/15/12 9:10 AM, "ext William Mills" <wmills_92105@yahoo.com> wrote:

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, an= d 1.0a) than refer to MAC when I think I can do without MAC and use 1.0a ins= tead.  MAC is now in flux again, the other 3 are stable or already stan= dards.

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.tschofenig@gmx.net>
 To: William Mills <wmills_= 92105@yahoo.com>
Cc: Hannes Tschofenig <hannes= .tschofenig@gmx.net>; Mike Jones <Michael.Jones@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.<= BR> >     • Copy relevant parts from http://tools.ietf.or= g/html/draft-ietf-oauth-v2-http-mac-01 (of which there is almost no depl= oyment).
>     • 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 an= swer 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 fo= r now would require the specification to be extended later on to fit to OAut= h 2.0 deployments (and whatever new security mechanism we will come up with)= . As a consequence, the specification will then suffer from additional compl= exity.

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 toke= ns we want to allow for IMAP), but several folks were saying when this all s= tarted 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 sig= ned auth schemes and not just bearer (cookie) type.  
>
> -bill
>
> From: Mike Jones <Michael.Jon= es@microsoft.com>
> To: William Mills <wmills_92105@ya= hoo.com>; O Auth WG <oauth@ietf.org&g= t;
> Sent: Tuesday, August 14, 2012 12:28 PM
> Subject: RE: [OAUTH-WG] OAuth 1.0a
>
> What problem are you trying to solve?
>  
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf 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 i= f I refer to it in another draft?  I want to reference an auth scheme t= hat 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
--B_3427867610_26668852-- From hannes.tschofenig@nsn.com Tue Aug 14 23:32:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6F11E80AE for ; Tue, 14 Aug 2012 23:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuKpE5GUjAA4 for ; Tue, 14 Aug 2012 23:32:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B845311E80A6 for ; Tue, 14 Aug 2012 23:32:12 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7F6W8tm012760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Aug 2012 08:32:08 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7F6W8Tp019767; Wed, 15 Aug 2012 08:32:08 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Aug 2012 08:32:08 +0200 Received: from 10.144.250.187 ([10.144.250.187]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Aug 2012 06:32:07 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Wed, 15 Aug 2012 09:32:06 +0300 From: Hannes Tschofenig To: William Mills , Hannes Tschofenig Message-ID: Thread-Topic: [OAUTH-WG] OAuth 1.0a Thread-Index: Ac16r7BXzjYdXSyIOEqICAFEIvu9VA== In-Reply-To: <1345011361.54744.YahooMailNeo@web31816.mail.mud.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3427867926_26679067" X-OriginalArrivalTime: 15 Aug 2012 06:32:08.0204 (UTC) FILETIME=[B1A7C4C0:01CD7AAF] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12317 X-purgate-ID: 151667::1345012328-00006F5F-545E10B4/0-0/0-0 Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 06:32:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3427867926_26679067 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Bill, On 8/15/12 9:16 AM, "ext William Mills" 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 > To: William Mills > Cc: Hannes Tschofenig ; Torsten Lodderstedt > ; O Auth WG > 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 >> > To: William Mills >> > Cc: Mike Jones ; O Auth WG >> > 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 >>> >> To: William Mills ; O Auth WG >>> >> Sent: Tuesday, August 14, 2012 12:28 PM >>> >> Subject: RE: [OAUTH-WG] OAuth 1.0a >>> >> >>> >> What problem are you trying to solve? >>> >> >>> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@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 --B_3427867926_26679067 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [OAUTH-WG] OAuth 1.0a Hi Bill,


On 8/15/12 9:16 AM, "ext William Mills" <wmills_92105@yahoo.com> wrote:

Fundamentally MAC and any HoK that uses symmetric keys are equivale= nt.  Either can pull in the same profile of HTTP stuff into the signatu= re.

The issue is: a small change in the protocol specification makes the two me= chanisms incompatible. Hence, you have to provide the code for the two and a= possible negotiation mechanism along with it. For example, the fact that OA= uth 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 p= roperties in a different thread.

Sorry. I missed that. Do you have a pointer for me by chance?


Ciao
Hannes

-bill

  
 
 
 
 From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
 To: William Mills <wmills_= 92105@yahoo.com>
Cc: Hannes Tschofenig <hannes= .tschofenig@gmx.net>; Torsten Lodderstedt <torsten@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 thou= ght 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 c= lient to server key confirmation with integrity protection of a few fields b= ut 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 sp= ec, you can do HoK with MAC or any other signed scheme by including the need= ed proof of ownership in the token.   HoK, however it works out, i= s 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 <torste= n@lodderstedt.net>
> To: William Mills <wmills_92105@ya= hoo.com>
> Cc: Mike Jones <Michael.Jones= @microsoft.com>; O Auth WG <oauth@ietf.or= g>
> 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 a= ll 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= .Jones@microsoft.com>
>> To: William Mills <wmills_9210= 5@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-bounces@ietf.org = [mailto:oauth-bounces@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 somethi= ng if I refer to it in another draft?  I want to reference an auth sche= me that uses signing and now MAC is apparently going back to the drawing boa= rd, 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
--B_3427867926_26679067-- From wmills_92105@yahoo.com Tue Aug 14 23:37:31 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F34921F85C7 for ; Tue, 14 Aug 2012 23:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEa6C39ANDHj for ; Tue, 14 Aug 2012 23:37:30 -0700 (PDT) Received: from nm33-vm6.bullet.mail.ne1.yahoo.com (nm33-vm6.bullet.mail.ne1.yahoo.com [98.138.229.70]) by ietfa.amsl.com (Postfix) with SMTP id 1062721F85BB for ; Tue, 14 Aug 2012 23:37:29 -0700 (PDT) Received: from [98.138.90.54] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:37:29 -0000 Received: from [98.138.87.5] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:37:29 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 15 Aug 2012 06:37:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 531774.92437.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 60991 invoked by uid 60001); 15 Aug 2012 06:37:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345012648; bh=1sOoGRe8QlSzeaMY3F9j++qBQIFINumjOg8AcnFhf8g=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WOqIfkMrldcj+ycK07NCWJPso6NqtoLm55ry8B3QKbz6pOr+e1sg4TJg1BGEBFjjGM2lFuoXR55cTW0D7FPy5NTFKnVvGdNqnzJM/H6+DGMYJ2NNNSoB7yiOd8j8SO5pevdq58ZOceMau99uZG9vi+yQHC8n1y00tl92Ej/YFFg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Kc7WuY/PfGc8G+i+arOE76ZXZobGHzLNXmQ5BiRePZJnV/HoQ1iK3FfMjPf2o4m331bP7lHkm8mzUU44YAtqmmGilK5wIhqkdjbVyo/+RfDBCL1q1EAIMSUHrLtIhDADU1TejBLn4hn2GcpVxbhAK9K3w31ON/xJCPCVk3W7ywI=; X-YMail-OSG: 2F8XuEQVM1ni_39KZ4P2jWl6xYm1r1CQw8N0LeaJNd3x_aZ IWAT.Ae1MjSX7IUS5uIeSHrQi2UCn8qjF9g_dHosZ4zgJ5GA73yD6BNPKzsC 0F2ZfkOe0HI4brTqHD3L70qnjNFI1A9usNaybNpoUtE6BLdUHGV2fg3tmVH_ qDSIv0eZe5ILxL3G8n6PmSUR5Zw3DQHc1KZtnZXyScXMwbMnORcCTMNaCpOV TUFBCjC2JjANSurxRXWyVfOh74J5JbGoih5tXbsm6DrzUl9NOxmn80WPlDmz Gy2wvQHFehILS8wpfQvlJ9mJUgZqq1oE5HnbKjGCQZiVo6daicsJCUpO_Y56 _2pIV9L1Tve.2QRAcNJVa2k.SOEvEW.tj8d1W.pYYWqiQJGqtxtf_W4pChO1 Ls3L2pSl4F11TJCKSFgvrxeQ6K1qozYkXm7cKHpAkz6_j8yBC9KitrL_VHce PKAFhuZS89fiUtvpWR5JXwfOmMXvQS2wIT7YHUhasEyq6AUqKog8i0oapMyZ m Received: from [209.131.62.115] by web31812.mail.mud.yahoo.com via HTTP; Tue, 14 Aug 2012 23:37:28 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: <1345011361.54744.YahooMailNeo@web31816.mail.mud.yahoo.com> Message-ID: <1345012648.53966.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Tue, 14 Aug 2012 23:37:28 -0700 (PDT) From: William Mills To: Hannes Tschofenig , Hannes Tschofenig In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1458549034-120121525-1345012648=:53966" Cc: O Auth WG Subject: Re: [OAUTH-WG] OAuth 1.0a X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 06:37:31 -0000 --1458549034-120121525-1345012648=:53966 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, that other thread is on the Kitten list. =A0Cross post it here?=0A= =0ACertainly MAC or HoK could change and become incompatible with the curre= nt SASL mechanism spec. =A0Hopefully not fundamentally incompatible, and ei= ther a new spec or the updated MAC or HoK spec can update the SASL mechanis= m to provide comatibility.=0A=0A-bill=0A=0A=0A_____________________________= ___=0A From: Hannes Tschofenig =0ATo: William Mi= lls ; Hannes Tschofenig = =0ACc: O Auth WG =0ASent: Tuesday, August 14, 2012 11:32 = PM=0ASubject: Re: [OAUTH-WG] OAuth 1.0a=0A =0A=0ARe: [OAUTH-WG] OAuth 1.0a = =0AHi Bill, =0A=0A=0AOn 8/15/12 9:16 AM, "ext William Mills" wrote:=0A=0A=0AFundamentally MAC and any HoK that uses symmetric= keys are equivalent. =A0Either can pull in the same profile of HTTP stuff = into the signature.=0A>=0A>The issue is: a small change in the protocol spe= cification makes the two mechanisms incompatible. Hence, you have to provid= e 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 ref= resh already makes the OAuth 1.0 MAC and the OAuth 2.0 MAC different.=0A>= =0A>I commented on your argument that MAC and Bearer have equivalent securi= ty properties in a different thread.=0A>=0A>Sorry. I missed that. Do you ha= ve a pointer for me by chance?=0A>=0A>=0A>Ciao=0A>Hannes=0A>=0A>-bill=0A>= =0A>=A0=A0=0A>=A0=0A>=A0=0A>=A0=0A>>________________________________=0A> = =A0From:Hannes Tschofenig =0A>=A0To: William Mil= ls =0A>Cc: Hannes Tschofenig ; Torsten Lodderstedt ; O Auth WG =0A>=A0Sent: Tuesday, August 14, 2012 10:49 PM=0A>=A0Subject: Re: [O= AUTH-WG] OAuth 1.0a=0A>=A0=0A>=A0=0A>Hi Bill, =0A>=0A>how do you know that = the outcome of the security discussions will unlikely be different than MAC= ?=0A>=0A>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 be= tter security than bearer -- not just be different. =0A>=0A>Ciao=0A>Hannes= =0A>=0A>On Aug 14, 2012, at 10:53 PM, William Mills wrote:=0A>=0A>> I want = to get the SASL work done. =A0=A0HoK is interesting, but I've become convin= ced that it's not actually anything that needs it's own spec, you can do Ho= K with MAC or any other signed scheme by including the needed proof of owne= rship in the token. =A0=A0HoK, 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.=0A>> =0A>> -bill=0A>> = =0A>> From: Torsten Lodderstedt =0A>> To: William = Mills =0A>> Cc: Mike Jones ; O Auth WG =0A>> Sent: Tuesday, August 14, 2012 12:= 42 PM=0A>> Subject: Re: [OAUTH-WG] OAuth 1.0a=0A>> =0A>> Hi Bill,=0A>> =0A>= > do you need to specify this aspect of your SASL profile now? Why don't yo= u wait for the group to complete the work on signing/HoK? =0A>> =0A>> You c= ould also contribute your use cases to drive the discussion.=0A>> =0A>> bes= t regards,=0A>> Torsten.=0A>> =0A>> Am 14.08.2012 21:37, schrieb William Mi= lls:=0A>>> It's for the OAUTH SASL spec. =A0I've been writing it with the i= dea 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.=0A>>> =0A>>> I= want to make sure the SASL mechanism is build to properly handle signed au= th schemes and not just bearer (cookie) type. =A0=0A>>> =0A>>> -bill=0A>>> = =0A>>> From: Mike Jones =0A>>> To: William Mil= ls ; O Auth WG =0A>>> Sent: Tuesda= y, August 14, 2012 12:28 PM=0A>>> Subject: RE: [OAUTH-WG] OAuth 1.0a=0A>>> = =0A>>> What problem are you trying to solve?=0A>>> =A0=0A>>> From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills= =0A>>> Sent: Tuesday, August 14, 2012 12:22 PM=0A>>> To: O Auth WG=0A>>> Su= bject: [OAUTH-WG] OAuth 1.0a=0A>>> =A0=0A>>> What's the general opinion on = 1.0a? =A0Am I stepping in something if I refer to it in another draft? =A0I= want to reference an auth scheme that uses signing and now MAC is apparent= ly going back to the drawing board, so I'm thinking about using 1.0a.=0A>>>= =A0=0A>>> Thanks,=0A>>> =A0=0A>>> -bill=0A>>> =0A>>> =0A>>> =0A>>> =0A>>> = _______________________________________________=0A>>> OAuth mailing list=0A= >>> =0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/oauth= =0A>> =0A>> =0A>> =0A>> _______________________________________________=0A>= > OAuth mailing list=0A>> OAuth@ietf.org=0A>> https://www.ietf.org/mailman/= listinfo/oauth=0A>=0A>=0A>=0A>=A0=0A>=A0=0A>=A0=A0=0A>=0A>>________________= ________________=0A>_______________________________________________=0A>OAut= h mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/o= auth=0A> --1458549034-120121525-1345012648=:53966 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry, tha= t other thread is on the Kitten list.  Cross post it here?

Certainly MAC or HoK could change a= nd become incompatible with the current SASL mechanism spec.  Hopefull= y not fundamentally incompatible, and either a new spec or the updated MAC = or HoK spec can update the SASL mechanism to provide comatibility.

-bill

=0A>
=0A> -bill
=0A>= ;
=0A> From: Torsten Lodderstedt <t= orsten@lodderstedt.net>
=0A> To: William Mills <wmills_92105@yahoo.com>
=0A> Cc: Mike Jone= s <Michael.Jones@microsoft.com>; O = Auth WG <oauth@ietf.org>
=0A>= ; Sent: Tuesday, August 14, 2012 12:42 PM
=0A> Subject: Re: [OAUTH-WG= ] OAuth 1.0a
=0A>
=0A> Hi Bill,
=0A>
=0A> do you = need to specify this aspect of your SASL profile now? Why don't you wait fo= r the group to complete the work on signing/HoK?
=0A>
=0A> Yo= u could also contribute your use cases to drive the discussion.
=0A> =
=0A> best regards,
=0A> Torsten.
=0A>
=0A> Am 14.= 08.2012 21:37, schrieb William Mills:
=0A>> It's for the OAUTH SAS= L 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 IM= AP), but several folks were saying when this all started that 1.0a was dead= and I should not refer to it.
=0A>>
=0A>> I want to mak= e sure the SASL mechanism is build to properly handle signed auth schemes a= nd not just bearer (cookie) type.  
=0A>>
=0A>> -bi= ll
=0A>>
=0A>> From: Mike Jones <Michael.Jones@microsoft.com>
=0A>> To: William Mi= lls <wmills_92105@yahoo.com>; O Aut= h WG <oauth@ietf.org>
=0A>&g= t; Sent: Tuesday, August 14, 2012 12:28 PM
=0A>> Subject: RE: [OAU= TH-WG] OAuth 1.0a
=0A>>
=0A>> What problem are you tryin= g to solve?
=0A>>  
=0A>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills
=0A= >> Sent: Tuesday, August 14, 2012 12:22 PM
=0A>> To: O Auth = WG
=0A>> Subject: [OAUTH-WG] OAuth 1.0a
=0A>>  
= =0A>> What's the general opinion on 1.0a?  Am I stepping in some= thing 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 drawin= g board, so I'm thinking about using 1.0a.
=0A>>  
=0A>= > Thanks,
=0A>>  
=0A>> -bill
=0A>>
= =0A>>
=0A>>
=0A>>
=0A>> _______________= ________________________________
=0A>> OAuth mailing list
=0A&g= t;>
=0A>> OAuth@ietf.org
= =0A>> https://www.ietf.org/mailman/listinfo/oauth=
=0A>
=0A>
=0A>
=0A> ___________________________= ____________________
=0A> OAuth mailing list
=0A> OAuth@ietf.org
=0A> https://ww= w.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A
=0A 
= =0A 
=0A  
=0A
=0A
_______= ________________________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps:/= /www.ietf.org/mailman/listinfo/oauth
=0A=0A
=0A=0A=0A


--1458549034-120121525-1345012648=:53966-- From sberyozkin@gmail.com Wed Aug 15 02:15:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2FF21F8757 for ; Wed, 15 Aug 2012 02:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UxsMeXyEeXN for ; Wed, 15 Aug 2012 02:15:30 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A39B221F86DC for ; Wed, 15 Aug 2012 02:15:29 -0700 (PDT) Received: by eekb45 with SMTP id b45so398332eek.31 for ; Wed, 15 Aug 2012 02:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RlbJPw0dEfL7ZSI05CC5phK9zu8CsmN5xRMhSmV9+rI=; b=LX+3G9r/Y3A3EuR150HFGbCI/oxfCHzpaBK80JJXdnJSt/ep1wnpUtqYGkkKtT2HR7 5WZuZfIBAFddeljOTR9jDzEjZ7iw6zhgVTh3C4OKkIrmre1iocVkVEqh4r5nYhKr3nc7 TsW0gd1vEa6txQz4SccYSeoWnGHKLxNUJaWqKteySZDJHAjDkgPkI10JFfyDZ494+1YF RbFKSmIL8WGYKUdtS5+mBb/ETHa1gdHoNYgoJ/8M/IEhUnkN7Q5bkMrGN5IN0jPOMcRr DLY9Sz8OACLaX/WQb6l82B/FiEw/NCTGwZ902zQ4zLZfJS6JQeUsZjqPABrTlvIxho8l zZFg== Received: by 10.14.181.132 with SMTP id l4mr19370133eem.17.1345022128426; Wed, 15 Aug 2012 02:15:28 -0700 (PDT) Received: from [192.168.2.3] ([89.100.138.117]) by mx.google.com with ESMTPS id 45sm2364537eed.17.2012.08.15.02.15.27 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 02:15:27 -0700 (PDT) Message-ID: <502B68AF.2050204@gmail.com> Date: Wed, 15 Aug 2012 12:15:27 +0300 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: oauth@ietf.org References: <6C75E137-2C30-4D74-AABE-EB4D97C5B56F@oracle.com> <4E1F6AAD24975D4BA5B168042967394366777949@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366777949@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] MAC Discussion X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 09:15:32 -0000 Hi Mike On 14/08/12 22:17, Mike Jones wrote: > Replying to Justin's point about the OpenID Connect signed request object, Justin, I don't believe this comparison is accurate. When an OpenID Request Object is signed, a single, self-contained object is being signed. The signing described in the MAC spec signs a combination of payload elements and transport elements. It's a testament to the complexity of this approach that Eran kept changing which elements were signed and which weren't in successive drafts. > Is there a requirement to get a transport-independent token envelope working ? I guess it might be the case when OAuth2 is implemented with the help of HTTP-centric and existing stores (ex, WS-based ones). MAC is an HTTP-centric scheme, so it seems OK that transport elements are also included > Signing an OpenID Connect Request Object is simple (just apply JWS). Signing using the MAC algorithm is an exercise left to the reader... Even I was able to understand how MAC signature is done, with the help of stock Java classes. I reckon appying JWS is simple indeed, provided JWS routine is available :-). Not trying to compare both approaches here, but I agree with the statements that both mechanisms might be useful. Btw, seeing http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-03 referencing MAC too, Cheers, Sergey > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt > Sent: Friday, August 10, 2012 10:03 AM > To: Richer, Justin P. > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] MAC Discussion > > There's no reason why the spec, or key elements of it can't be re-used. > > But to assume it should be "THE" spec, goes against previous formal consensus (can't remember if it was Quebec or Paris meeting) and jumps the gun on defining what the problem is. If we jump into a spec without defining the problem, we're guessing. What I saw of the previous email discussion was a lot of circular debate indicating no clear problem definition. > > I agree, it would be nice to re-use code from previous implementations. But that strikes me as an issue to raise when we discuss the implementation based upon future consensus of the problem. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-08-10, at 7:49 AM, Richer, Justin P. wrote: > >> >> On Aug 10, 2012, at 3:00 AM, Hannes Tschofenig wrote: >> >>> Justin wrote: >>> " >>> I believe that there's value in per-message signing completely apart from the channel level encryption. >>> " >>> >>> May well be. But we have to figure out what exactly the reasons are why there is value. >> >> Yes, there is value in this, and that's why we're collecting a handful of use cases to support this. Otherwise, people wouldn't keep reinventing this. See SAML and OpenID Connect's signed request object for other examples. >> >>> >>> Bill wrote: >>> " >>> I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. >>> " >>> >>> This would be a very quick process if we had ever done our home work properly. >> >> It's not done, but it's not empty. Why throw it out? Whether or not we continue the draft itself or import its best ideas into a new draft is beside the point. >> >>> >>> So, what are the problems it tries to solve? Yesterday I found an old presentation about MAC and the basic argument was that it has better performance than TLS. While that's true it is not a good argument per se. However, performance is not the only factor to look at and the negative performance impact caused by TLS is overrated. >> >> This is a red herring, as pointed out by other use cases. >> >>> >>> Here is the slide set I am talking about: >>> http://www.tschofenig.priv.at/Why_are_we_Signing.pdf >>> >>> In many cases I had noticed that more time was spent with the pictures (in slides and blog post) than with the content. That's not good IMHO. >>> >>> Bill, we can hardly call a specification "complete" if many of us don't know what problem it solves. John phrases it nicely as "Part of the problem with MAC has been that people could never agree on what it was protecting against." I am also interested in hearing about deployment constraints that people have. Blaine always said that many developers cannot get TLS to work. I am sure that's true but OAuth 2.0 requires TLS to be used anyway to secure the interaction with the authorization server. >> >> It solves this problem: How can I use the framework of OAuth to get a temporary signing key that I can use to protect HTTP messages with signing (without stuffing my parameters into a structured document like a SAML or JWT assertion)? There are many justifications for that problem and use cases that expand on this, but that's the core thing that the MAC does. >> >>> >>> Note: I am not saying that we are not going to standardize something like the MAC token (maybe with different details) but let us spend a little bit of time to figure out what threats we want to deal with. >> >> It's not just about threats, it's about capabilities and features. >> >> -- Justin >> >>> >>> _______________________________________________ >>> 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 From internet-drafts@ietf.org Thu Aug 16 10:14:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A0A21F8653; Thu, 16 Aug 2012 10:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovzecJ7WnBoX; Thu, 16 Aug 2012 10:14:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061C121F8658; Thu, 16 Aug 2012 10:14:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816171445.29317.99704.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 10:14:45 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:14:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename : draft-ietf-oauth-v2-threatmodel-07.txt Pages : 70 Date : 2012-08-16 Abstract: This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-threatmodel-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Thu Aug 16 10:19:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BBD21F8672 for ; Thu, 16 Aug 2012 10:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl4js5ldhtjp for ; Thu, 16 Aug 2012 10:19:35 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by ietfa.amsl.com (Postfix) with ESMTP id A98CE21F8671 for ; Thu, 16 Aug 2012 10:19:35 -0700 (PDT) Received: from [79.253.20.219] (helo=[192.168.71.42]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T23jJ-0006As-9s for oauth@ietf.org; Thu, 16 Aug 2012 19:19:33 +0200 Message-ID: <502D2BA4.9010305@lodderstedt.net> Date: Thu, 16 Aug 2012 19:19:32 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: oauth@ietf.org References: <20120816171445.29317.99704.idtracker@ietfa.amsl.com> In-Reply-To: <20120816171445.29317.99704.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:19:36 -0000 Hi all, the new revision covers token substitution, which has been added to the core spec lately. Additionally, it describes a similar attack on the code flow, which is prevented by forcing the authorization server to validate that an authorization code had been issued to the calling client. We also made the references to core and bearer spec normative. regards, Torsten. Am 16.08.2012 19:14, schrieb internet-drafts@ietf.org: > 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 Threat Model and Security Considerations > Author(s) : Torsten Lodderstedt > Mark McGloin > Phil Hunt > Filename : draft-ietf-oauth-v2-threatmodel-07.txt > Pages : 70 > Date : 2012-08-16 > > Abstract: > This document gives additional security considerations for OAuth, > beyond those in the OAuth specification, based on a comprehensive > threat model for the OAuth 2.0 Protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-threatmodel-07 > > > 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 From stephen.farrell@cs.tcd.ie Thu Aug 16 10:36:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386B721F85D5 for ; Thu, 16 Aug 2012 10:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN9jsuAB8mTY for ; Thu, 16 Aug 2012 10:36:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 82CEF21F85D2 for ; Thu, 16 Aug 2012 10:36:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 01196171490; Thu, 16 Aug 2012 18:36:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1345138588; bh=asRTs XPbIqyXwPSvhFUkVMOITF4QCVlCRRQhW7AhMeU=; b=W6G5Bp/w/ZxlFWnw3FMHI GDUk//A99T9jKEb69q2HBnYJBZzQ3w9DeKjjXW1B0/QYRk3uUPGcyQFraKFQAyi4 /cmncT5cRiGjnx4fu3UXnhsJMIR5AwKfbdigIAOarsNPOMfi7WduoDN8GCo/Jkbs 5QEspkVTprNUrP650X7YFE+mAzj7g/RwESj7IDNYmq5wpX/CLiKVsmH3DRmx+UYs JgnMJJZjeutYXbs+u/z84HHDoYVEsOfQ/JFvxpUpdeyqDyane6VV2mO1OQT+/ebY xgS0BCWsEBbDlw+PhJL0/x/HJW+tliX3iVnS2alrFSP2LXapWsAQ9qTcvZZS8QAy w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id h8PvZik3k9HD; Thu, 16 Aug 2012 18:36:28 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.61.162]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5373E17148F; Thu, 16 Aug 2012 18:36:27 +0100 (IST) References: <20120816171445.29317.99704.idtracker@ietfa.amsl.com> <502D2BA4.9010305@lodderstedt.net> In-Reply-To: <502D2BA4.9010305@lodderstedt.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6D4DA1C9-B84C-4075-AF94-AB960344D645@cs.tcd.ie> X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Thu, 16 Aug 2012 18:35:58 +0100 To: Torsten Lodderstedt Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:36:33 -0000 Thanks, Since this is on the Aug 30 telechat let's not have any further changes wit= hout a chair/AD asking. Ta, S On 16 Aug 2012, at 18:19, Torsten Lodderstedt wrot= e: > Hi all, >=20 > the new revision covers token substitution, which has been added to the co= re spec lately. Additionally, it describes a similar attack on the code flow= , which is prevented by forcing the authorization server to validate that an= authorization code had been issued to the calling client. >=20 > We also made the references to core and bearer spec normative. >=20 > regards, > Torsten. >=20 > Am 16.08.2012 19:14, schrieb internet-drafts@ietf.org: >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Web Authorization Protocol Working Grou= p of the IETF. >>=20 >> Title : OAuth 2.0 Threat Model and Security Considerations >> Author(s) : Torsten Lodderstedt >> Mark McGloin >> Phil Hunt >> Filename : draft-ietf-oauth-v2-threatmodel-07.txt >> Pages : 70 >> Date : 2012-08-16 >>=20 >> Abstract: >> This document gives additional security considerations for OAuth, >> beyond those in the OAuth specification, based on a comprehensive >> threat model for the OAuth 2.0 Protocol. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-07 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-threatmodel-07 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Thu Aug 16 11:00:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6A621F85E6 for ; Thu, 16 Aug 2012 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t2DCE5xtt79 for ; Thu, 16 Aug 2012 11:00:53 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3621F8596 for ; Thu, 16 Aug 2012 11:00:53 -0700 (PDT) Received: from [79.253.20.219] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1T24NH-0000XX-Fd; Thu, 16 Aug 2012 20:00:51 +0200 Message-ID: <502D3553.1090708@lodderstedt.net> Date: Thu, 16 Aug 2012 20:00:51 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Stephen Farrell References: <20120816171445.29317.99704.idtracker@ietfa.amsl.com> <502D2BA4.9010305@lodderstedt.net> <6D4DA1C9-B84C-4075-AF94-AB960344D645@cs.tcd.ie> In-Reply-To: <6D4DA1C9-B84C-4075-AF94-AB960344D645@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 18:00:54 -0000 Hi, we don't plan further changes. regards, Torsten. Am 16.08.2012 19:35, schrieb Stephen Farrell: > Thanks, > > Since this is on the Aug 30 telechat let's not have any further changes without a chair/AD asking. > > Ta, > S > > On 16 Aug 2012, at 18:19, Torsten Lodderstedt wrote: > >> Hi all, >> >> the new revision covers token substitution, which has been added to the core spec lately. Additionally, it describes a similar attack on the code flow, which is prevented by forcing the authorization server to validate that an authorization code had been issued to the calling client. >> >> We also made the references to core and bearer spec normative. >> >> regards, >> Torsten. >> >> Am 16.08.2012 19:14, schrieb internet-drafts@ietf.org: >>> 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 Threat Model and Security Considerations >>> Author(s) : Torsten Lodderstedt >>> Mark McGloin >>> Phil Hunt >>> Filename : draft-ietf-oauth-v2-threatmodel-07.txt >>> Pages : 70 >>> Date : 2012-08-16 >>> >>> Abstract: >>> This document gives additional security considerations for OAuth, >>> beyond those in the OAuth specification, based on a comprehensive >>> threat model for the OAuth 2.0 Protocol. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-07 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-threatmodel-07 >>> >>> >>> 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 From leleuj@gmail.com Sun Aug 19 01:25:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0721F8498 for ; Sun, 19 Aug 2012 01:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBO8e4U2pjCk for ; Sun, 19 Aug 2012 01:25:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00F2C21F848F for ; Sun, 19 Aug 2012 01:25:29 -0700 (PDT) Received: by lahm15 with SMTP id m15so2929225lah.31 for ; Sun, 19 Aug 2012 01:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qYPoXScldJLjCbCOj2+3WPfD8X4OnsdqkO0nIEFEC68=; b=v83J6Qe9tthP1ZTZtlzWfGe1HYBvOReiF1HutAksGD4ISESk6MmuDz2NmGMsuRdzh0 KZdep+dx3cU8TxHpyEARnmmKMTCayFI7ZI/ejv/KSNh2fTaRMcqL76KNKvbqv593O1kt oSY5VtadXKKla71Mxr/DC/3ZF5L0No8ma0MoxlZUwpVTWZ8TfUsczMnrz8JwACZ1SyTI +36mPoY0p9kSH+eWP3jDVZzi3unL5AGoCUUnRUj7QpoQF9X7Wq1ecfacTXVRuIYKNBfu wBX61RI8yr1WHiAtIzqJqzLh8I9FDQ9PybXDsP/G8Yyad2sWWS/Lw6ngNvGn0mG0lNI4 /yrw== MIME-Version: 1.0 Received: by 10.152.146.169 with SMTP id td9mr10075092lab.42.1345364728833; Sun, 19 Aug 2012 01:25:28 -0700 (PDT) Received: by 10.112.48.161 with HTTP; Sun, 19 Aug 2012 01:25:28 -0700 (PDT) Date: Sun, 19 Aug 2012 10:25:28 +0200 Message-ID: From: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= To: oauth@ietf.org Content-Type: multipart/alternative; boundary=e89a8f234589c1664a04c79a227e Subject: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 08:25:31 -0000 --e89a8f234589c1664a04c79a227e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=E9r=F4me --e89a8f234589c1664a04c79a227e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I might be misunderstanding the OAuth 2.0 spec (part= 5.1, "expires_in" property), but I understand that the timeout o= f the access token is a hard one (amount of time between creation and expir= ation).

Am I right ?

Can we have a mul= tiple use timeout ? A sliding window timeout ? Or a combination of all ?

Thanks.
Best regards,
J=E9r=F4me=

--e89a8f234589c1664a04c79a227e-- From wmills_92105@yahoo.com Sun Aug 19 10:35:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25BD21F8597 for ; Sun, 19 Aug 2012 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYF5Z5JDtPBG for ; Sun, 19 Aug 2012 10:35:46 -0700 (PDT) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with SMTP id 4339A21F8593 for ; Sun, 19 Aug 2012 10:35:46 -0700 (PDT) Received: from [98.139.91.66] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2012 17:35:36 -0000 Received: from [72.30.22.39] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 19 Aug 2012 17:35:36 -0000 Received: from [127.0.0.1] by omp1069.mail.sp2.yahoo.com with NNFMP; 19 Aug 2012 17:35:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 162374.5087.bm@omp1069.mail.sp2.yahoo.com Received: (qmail 4626 invoked by uid 60001); 19 Aug 2012 17:35:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1345397735; bh=BqCn/7tg7CSHALTtaoV+81dY9e3IsuFRx6v/kcJAHTM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=cRwPgTTsAIKlS/rAzPyYgFskFaR26EdWpoFI9jk1B5cde87+FXWj7DeOYtJwkdD5o+hTIIDuVMRCKPa5su59lsqPS8mQcQNccU29FE4qPILuPOhfp3R9/olYi309c1bVKgBNRoAq9HWgL8vEw32UG8DHhZSWZjce9w//AX1JsT8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=jcnRnftp27zWo4bAdm+o1yhiiPrbW6nk4kcjfn8jxhAU0wSplzU0zkTwBYViWYPlfSJOJuA9Z/uKyxxXLEju5Bj5QirNtWofwCvT/w7c7RAUhgWiYWmzyZRkL23hBmwiPwl98qCKoO45+NJO2vZw1oj2tqQPDYrcjCzO+aeXpHU=; X-YMail-OSG: PS0mM4oVM1kir9BpsuzmTrQWwCDJkEHodqVPB6PzdPWAOeE 2eVcHnZdnYBj2c39Tf.ay.ys7NZhA9esU49oUX6.dKHpk2Ex_HpQCq9LXDKA EgmIWinXjnjkQCuOQ1j.kiszR7Qwf62Pj4z4ykAckiNe0O6Cx6k411oa0W1h zRzfi7jVCB7XyMQF2.GxBoUN9yLlLlyZQdeqw7iRrIKVBl8Xrk_hhQiBupBR phFINkyVg1CEOGCmwLz6AMwKh79tGk0urUBikyW0YkZbNI5u6qQkKZr4W2.5 R6KomFrlhzsP0oPz2mjRIuBlzcK.V19ps8MDCIWO9jq7dVeGukHyfbDZ8H_V eNZB0Dajub9CjtwfsPsew9u3acR9tFamHRrcwubFm7gKoI3zj5glaBauIsYB qIExsFlei8rQPjX2X.AQzH71XWCh3PUebEeOVnD7MZddLu24.4YvWrazNZuO jFbyFWBuC1mXCVKKqMAGYtlk4JqtzR5L4PxxZ4Q6. Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Sun, 19 Aug 2012 10:35:35 PDT X-Mailer: YahooMailWebService/0.8.121.416 References: Message-ID: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Sun, 19 Aug 2012 10:35:35 -0700 (PDT) From: William Mills To: =?iso-8859-1?Q?J=E9r=F4me_LELEU?= , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1395015409-1485803473-1345397735=:4226" Subject: Re: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 17:35:47 -0000 ---1395015409-1485803473-1345397735=:4226 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable It's a hint to the client of when the token will probably expire. =A0There = was a lot of discussion on what the right way to go was and there were seve= ral "camps" on the right strategy choice would be, but in the end a very si= mple solution was chosen. =A0Most folks agreed that having more than one wa= y to go was not worth the complexity, so this single one was picked.=0A=0A= =0A________________________________=0A From: J=E9r=F4me LELEU =0ATo: oauth@ietf.org =0ASent: Sunday, August 19, 2012 1:25 AM=0ASubje= ct: [OAUTH-WG] Access token timeout=0A =0A=0AHi,=0A=0AI might be misunderst= anding the OAuth 2.0 spec (part 5.1, "expires_in" property), but I understa= nd that the timeout of the access token is a hard one (amount of time betwe= en creation and expiration).=0A=0AAm I right ?=0A=0ACan we have a multiple = use timeout ? A sliding window timeout ? Or a combination of all ?=0A=0ATha= nks.=0ABest regards,=0AJ=E9r=F4me=0A=0A____________________________________= ___________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/ma= ilman/listinfo/oauth ---1395015409-1485803473-1345397735=:4226 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
It's a hin= t to the client of when the token will probably expire.  There was a l= ot of discussion on what the right way to go was and there were several "ca= mps" on the right strategy choice would be, but in the end a very simple so= lution 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=E9r=F4me LELEU <leleuj@gmail.com>
<= span style=3D"font-weight: bold;">To: oauth@ietf.org
Sent: Sunday, August 19, 2012 1:25= AM
Subject: [OAUTH-WG= ] Access token timeout

=0A
H= i,

I might be misunderstanding the OAuth 2.0 spec (part = 5.1, "expires_in" property), but I understand that the timeout of the acces= s token is a hard one (amount of time between creation and expiration).=0A

Am I right ?

Can we have = a multiple use timeout ? A sliding window timeout ? Or a combination of all= ?

Thanks.
Best regards,
J=E9r= =F4me
=0A

=0A

_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


---1395015409-1485803473-1345397735=:4226-- From ve7jtb@ve7jtb.com Sun Aug 19 10:41:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2280621F8596 for ; Sun, 19 Aug 2012 10:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBSYBWFBmHPH for ; Sun, 19 Aug 2012 10:41:12 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 685D321F852C for ; Sun, 19 Aug 2012 10:41:12 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5261755ghb.31 for ; Sun, 19 Aug 2012 10:41:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=5+kZ4yzcUOR5t3NnWWYGDM8jtSit6LTuprLHwAhlzwo=; b=hK/gmvZ4kDWbVP2vGzItqoyfPCabFekgEugTYPXL1kPDhGJFIFf42qKBSXEcaNeL7Z /6ojJsFYtKuCxIrYPtlV1q44LsNjltEC/5Vxz5ObfnZR0FaWqPb1PTQU4exnKLDd+/54 RTJxqvMlN6ABsVUTMSvFCzjgc3CaFvVfvX9REsUxMEuiaL36SEALXgbm3WpdDY9QdDJE xZa/bMbQI/3C1+C/xjY3iX3UquMnjB/7yQRAwDuo1sPENbJV3G3oVftsBd64K/OQH2qm tesmbv7fFzUiHAsjcRj9Y2Jk/FP9Xlwpa2MNTZ27knEfJPkMwo+qwTnybMPSmj/q/bJc ku3A== Received: by 10.236.136.39 with SMTP id v27mr17561173yhi.96.1345398071899; Sun, 19 Aug 2012 10:41:11 -0700 (PDT) Received: from [192.168.1.39] (190-20-20-82.baf.movistar.cl. [190.20.20.82]) by mx.google.com with ESMTPS id t57sm25136551yhg.0.2012.08.19.10.41.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 10:41:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB8B400A-38B8-43DC-8FF7-FAE697AB6843" From: John Bradley In-Reply-To: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Sun, 19 Aug 2012 13:40:59 -0400 Message-Id: <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com> References: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQksRBhJkUMnCa5xM2Do7TRUu8uTAzG77yq3pTTRdumyQbTeJL+B7GGHD720u30NQctngo0X Cc: "oauth@ietf.org" , =?iso-8859-1?Q?J=E9r=F4me_LELEU?= Subject: Re: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 17:41:13 -0000 --Apple-Mail=_DB8B400A-38B8-43DC-8FF7-FAE697AB6843 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 A token can always expire in less than that time. I have seen deployments that use sliding windows and single use access = tokens. In those cases the "expires_in" is sent as a Max time before = the token will expire. A client always needs to be prepared that a token will have been revoked = or expired and fall back to using the refresh token, or reauthorize.=20 John B. On 2012-08-19, at 1:35 PM, William Mills wrote: > 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. >=20 > From: J=E9r=F4me LELEU > To: oauth@ietf.org=20 > Sent: Sunday, August 19, 2012 1:25 AM > Subject: [OAUTH-WG] Access token timeout >=20 > Hi, >=20 > 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). >=20 > Am I right ? >=20 > Can we have a multiple use timeout ? A sliding window timeout ? Or a = combination of all ? >=20 > Thanks. > Best regards, > J=E9r=F4me >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DB8B400A-38B8-43DC-8FF7-FAE697AB6843 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 A = token can always expire in less than that time.

I = have seen deployments that use sliding windows and single use access = tokens.   In those cases the "expires_in" is sent as a Max time = before the token will expire.

A client always = needs to be prepared that a token will have been revoked or expired and = fall back to using the refresh token, or = reauthorize. 

John B.
On = 2012-08-19, at 1:35 PM, William Mills wrote:

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=E9r=F4me LELEU <leleuj@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=E9r=F4me


_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= br>
=
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_DB8B400A-38B8-43DC-8FF7-FAE697AB6843-- From dgq2011@gmail.com Tue Aug 21 00:14:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6087921F8567 for ; Tue, 21 Aug 2012 00:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=1.983, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se9t55uVGGet for ; Tue, 21 Aug 2012 00:14:34 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55321F8565 for ; Tue, 21 Aug 2012 00:14:34 -0700 (PDT) Received: by ggnh4 with SMTP id h4so6212732ggn.31 for ; Tue, 21 Aug 2012 00:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=euNFK6wHF1mAtVJJIZdvtYCMykqgCB4eyEGgr80OqJ0=; b=qTDHAwNnDjPV4yf7ufVdwPXRp383vlQCxHukn0IuItozdpz+yhqz9oU6umC3NUPSWg 6rYyJKTRxDFQnBX/ATDpdtwGx9LcJlb2quMn0m0F/ydzJMGExFLAVL7MA+4mcGD32+LT qtOJOQtCKldhQUveNvb9BSWTLpwU0RWJJKQnnJcubxWaXSbLI9C4HmAJh8CszXAoILN0 Vyb1zk5pfaaVlJKPjE4th7ufkUoxrst8V8OycEUCZdco59d2wKJp6BWfYPY+C52zAASZ Z5UoTfHNClSPoVcuyR3e8hCSeCNUK/CtY/DjfD2158++xOjglQWToLDpOShKH/HrhTk4 y+HQ== MIME-Version: 1.0 Received: by 10.50.88.167 with SMTP id bh7mr12411529igb.69.1345533273590; Tue, 21 Aug 2012 00:14:33 -0700 (PDT) Received: by 10.64.52.68 with HTTP; Tue, 21 Aug 2012 00:14:33 -0700 (PDT) In-Reply-To: <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com> References: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com> Date: Tue, 21 Aug 2012 15:14:33 +0800 Message-ID: From: Guangqing Deng To: John Bradley Content-Type: multipart/alternative; boundary=e89a8f3ba245ce4b3104c7c160ed Cc: =?ISO-8859-1?B?Suly9G1lIExFTEVV?= , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:14:35 -0000 --e89a8f3ba245ce4b3104c7c160ed Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Since both the =93Client=94 and =93Resource Server=94 don=92t know the exac= t creation time (namely the time the response was generated on =93Authorization Server= =94, just as mentioned in part 5.1 of OAUTH 2.0) of an access token, the exact expiration time of an access token can=92t be directly obtained by =93Clien= t=94 and =93Resource Server=94 in the presence of "expires_in". Usually, it does= n=92t matter to the =93client=94, for a hint of when the token will probably expi= re is enough; however, the =93Resource Server=94 must know the exact expiratio= n time of an access token and another scheme to obtain that time is needed. So why not directly send the exact expiration time of an access token? 2012/8/20 John Bradley > A token can always expire in less than that time. > > I have seen deployments that use sliding windows and single use access > tokens. In those cases the "expires_in" is sent as a Max time before th= e > token will expire. > > A client always needs to be prepared that a token will have been revoked > or expired and fall back to using the refresh token, or reauthorize. > > John B. > > On 2012-08-19, at 1:35 PM, William Mills wrote: > > 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=E9r=F4me LELEU > *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 har= d > 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=E9r=F4me > > > _______________________________________________ > 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 > > --=20 Guangqing Deng --e89a8f3ba245ce4b3104c7c160ed Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Since both the =93Client=94 and= =93Resource Server=94 don=92t know the exact creation time (namely the time the respons= e was generated on =93Authorization Server=94, just as mentioned in part 5.1 of O= AUTH 2.0) of an access token, the exact expiration time of an access token can=92t be directly obtained by =93Client=94 and =93Resource Server=94 in the presence= of "expires_in". Usually, it doesn=92t matter to the =93client=94, for a hint of when the to= ken will probably expire is enough; however, the =93Resource Server=94 must know the= exact expiration time of an access token and another scheme to obtain that time is needed. S= o why not directly send the exact expiration time of an access token?



2012/8/20 John Bradley <ve7jtb@ve7jtb.c= om>
A token can always expire in less than = that time.

I have seen deployments that use sliding wind= ows and single use access tokens. =A0 In those cases the "expires_in&q= uot; is sent as a Max time before the token will expire.

A client always needs to be prepared that a token will = have been revoked or expired and fall back to using the refresh token, or r= eauthorize.=A0

John B.

<= div>
On 2012-08-19, at 1:35 PM, William Mills wrote:

It's a hint to the client of when the = token will probably expire. =A0There was a lot of discussion on what the ri= ght way to go was and there were several "camps" on the right str= ategy choice would be, but in the end a very simple solution was chosen. = =A0Most folks agreed that having more than one way to go was not worth the = complexity, so this single one was picked.

From: J=E9r=F4me LELEU <leleuj@gmail.com>
To: = oauth@ietf.org
Sent: Sunday, August 19, 20= 12 1:25 AM
Subject: [OAU= TH-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 time= out of the access token is a hard one (amount of time between creation and = expiration).

Am I right ?

Can we have a mul= tiple use timeout ? A sliding window timeout ? Or a combination of all ?

Thanks.
Best regards,
J=E9r=F4me=


_______________________________________________
OAuth mailing = list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h


________________________= _______________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Guangqing Deng
<= br> --e89a8f3ba245ce4b3104c7c160ed-- From zameer21@hotmail.com Tue Aug 21 07:32:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E947821F86C8 for ; Tue, 21 Aug 2012 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uskxde3r6jZ for ; Tue, 21 Aug 2012 07:32:19 -0700 (PDT) Received: from snt0-omc1-s15.snt0.hotmail.com (snt0-omc1-s15.snt0.hotmail.com [65.55.90.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6EC21F86C3 for ; Tue, 21 Aug 2012 07:32:19 -0700 (PDT) Received: from SNT125-W6 ([65.55.90.8]) by snt0-omc1-s15.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Aug 2012 07:32:19 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b16de3ea-d7d4-4ecd-84cb-4ba542077cae_" X-Originating-IP: [198.210.1.3] From: Zameer syed To: Date: Tue, 21 Aug 2012 14:32:18 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 21 Aug 2012 14:32:19.0489 (UTC) FILETIME=[C4FF7910:01CD7FA9] Subject: [OAUTH-WG] OAuth from .net (C#) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:32:20 -0000 --_b16de3ea-d7d4-4ecd-84cb-4ba542077cae_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am pretty new to oAuth and no basically nothing about it=2C is this a fre= e service=2C does it have a download. I basically am trying to see if i can= create my own website that has a login and provide that login credentials = for other web sites to use. I am basically trying to see if i can implement= this using .Net as i am .Net developer. Any help and resource will be grea= tly appreciated. If you cant help atleast if you can point me to right dire= ction that will help. Thanks=2C Zameer = --_b16de3ea-d7d4-4ecd-84cb-4ba542077cae_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am pretty new to oAuth and no basically nothing about it=2C is this a fre= e service=2C does it have a download. I basically am trying to see if i can= create my own website that has a login and provide that login credentials = for other web sites to use. I am basically trying to see if i can implement= this using .Net as i am .Net developer. Any help and resource will be grea= tly appreciated. If you cant help atleast if you can point me to right dire= ction that will help.
 =3B
Thanks=2C
Zameer
= --_b16de3ea-d7d4-4ecd-84cb-4ba542077cae_-- From jricher@mitre.org Tue Aug 21 07:39:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3217221F8671 for ; Tue, 21 Aug 2012 07:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKU+cDq1x9A9 for ; Tue, 21 Aug 2012 07:39:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CB9A521F8679 for ; Tue, 21 Aug 2012 07:39:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EDD2F21B15BB; Tue, 21 Aug 2012 10:39:43 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C164A21B15B4; Tue, 21 Aug 2012 10:39:43 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 Aug 2012 10:39:43 -0400 Message-ID: <50339D54.9080406@mitre.org> Date: Tue, 21 Aug 2012 10:38:12 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Guangqing Deng References: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020407040304040409040206" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" , =?ISO-8859-1?Q?J=E9r=F4me_LELEU?= Subject: Re: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:39:48 -0000 --------------020407040304040409040206 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit First, note that the "expires_in" field is never communicated to the Resource Server. It really is only just a hint to the Client. The Client has no way of even communicating this hint to the Resource Server within the bounds of OAuth. Second, the connection between Resource Server and Authorization Server is explicitly undefined in OAuth. There are four common approaches here: 1) Bake the RS and AS into a single box. This is the most common deployment on the web outside of the really big players like Google, AOL, and the like. This is the setup that you'll get out of the box from most libraries as well. In this case, the AS drops the token into a database and the RS can simply look it up in the same database to see if it's still good. When the AS wants to revoke a token, delete it from the data store and the RS can no longer find/validate it. 2) Use a structured token (like JWT or SAML) to bake the expiration and other parameters into the token itself. The RS can then validate the token using a signature of some kind and look at fields within the token like "exp". 3) Use token introspection style approaches to let the RS make a backchannel callback to the AS to see if the token's still good. There are a couple drafts floating around the WG with how to do that, and I think (and hope) we'll see that standardized. I just haven't seen any traction on it yet. 4) Use a full-featured permissions protocol like UMA. This lets you even dynamically provision the RS at the AS and get extended sets of permissions attached to a token. The "expires_in" field comes in to play in exactly none of these cases. Hope this helps, -- Justin On 08/21/2012 03:14 AM, Guangqing Deng wrote: > > Since both the "Client" and "Resource Server" don't know the exact > creation time (namely the time the response was generated on > "Authorization Server", just as mentioned in part 5.1 of OAUTH 2.0) of > an access token, the exact expiration time of an access token can't be > directly obtained by "Client" and "Resource Server" in the presence of > "expires_in". Usually, it doesn't matter to the "client", for a hint > of when the token will probably expire is enough; however, the > "Resource Server" must know the exact expiration time of an access > token and another scheme to obtain that time is needed. So why not > directly send the exact expiration time of an access token? > > > > 2012/8/20 John Bradley > > > A token can always expire in less than that time. > > I have seen deployments that use sliding windows and single use > access tokens. In those cases the "expires_in" is sent as a Max > time before the token will expire. > > A client always needs to be prepared that a token will have been > revoked or expired and fall back to using the refresh token, or > reauthorize. > > John B. > > On 2012-08-19, at 1:35 PM, William Mills wrote: > >> 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 > >> *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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Guangqing Deng > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020407040304040409040206 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
First, note that the "expires_in" field is never communicated to the Resource Server. It really is only just a hint to the Client. The Client has no way of even communicating this hint to the Resource Server within the bounds of OAuth.

Second, the connection between Resource Server and Authorization Server is explicitly undefined in OAuth. There are four common approaches here:
  1) Bake the RS and AS into a single box. This is the most common deployment on the web outside of the really big players like Google, AOL, and the like. This is the setup that you'll get out of the box from most libraries as well. In this case, the AS drops the token into a database and the RS can simply look it up in the same database to see if it's still good. When the AS wants to revoke a token, delete it from the data store and the RS can no longer find/validate it.
  2) Use a structured token (like JWT or SAML) to bake the expiration and other parameters into the token itself. The RS can then validate the token using a signature of some kind and look at fields within the token like "exp".
  3) Use token introspection style approaches to let the RS make a backchannel callback to the AS to see if the token's still good. There are a couple drafts floating around the WG with how to do that, and I think (and hope) we'll see that standardized. I just haven't seen any traction on it yet.
  4) Use a full-featured permissions protocol like UMA. This lets you even dynamically provision the RS at the AS and get extended sets of permissions attached to a token.

The "expires_in" field comes in to play in exactly none of these cases.

Hope this helps,
 -- Justin

On 08/21/2012 03:14 AM, Guangqing Deng wrote:

Since both the “Client” and “Resource Server” don’t know the exact creation time (namely the time the response was generated on “Authorization Server”, just as mentioned in part 5.1 of OAUTH 2.0) of an access token, the exact expiration time of an access token can’t be directly obtained by “Client” and “Resource Server” in the presence of "expires_in". Usually, it doesn’t matter to the “client”, for a hint of when the token will probably expire is enough; however, the “Resource Server” must know the exact expiration time of an access token and another scheme to obtain that time is needed. So why not directly send the exact expiration time of an access token?



2012/8/20 John Bradley <ve7jtb@ve7jtb.com>
A token can always expire in less than that time.

I have seen deployments that use sliding windows and single use access tokens.   In those cases the "expires_in" is sent as a Max time before the token will expire.

A client always needs to be prepared that a token will have been revoked or expired and fall back to using the refresh token, or reauthorize. 

John B.

On 2012-08-19, at 1:35 PM, William Mills wrote:

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 <leleuj@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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Guangqing Deng



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------020407040304040409040206-- From jricher@mitre.org Tue Aug 21 08:01:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401A021F86DF for ; Tue, 21 Aug 2012 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHcm9B+iQwFT for ; Tue, 21 Aug 2012 08:01:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 290A921F86B8 for ; Tue, 21 Aug 2012 08:01:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DC4121B15BE; Tue, 21 Aug 2012 11:01:44 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BFC621B0C80; Tue, 21 Aug 2012 11:01:44 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 21 Aug 2012 11:01:44 -0400 Message-ID: <5033A27D.8000603@mitre.org> Date: Tue, 21 Aug 2012 11:00:13 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Guangqing Deng References: <1345397735.4226.YahooMailNeo@web31809.mail.mud.yahoo.com> <8E82B87D-B819-462A-8546-6E20CA3B48CA@ve7jtb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090005060101070103010700" X-Originating-IP: [129.83.31.58] Cc: "oauth@ietf.org" , =?ISO-8859-1?Q?J=E9r=F4me_LELEU?= Subject: Re: [OAUTH-WG] Access token timeout X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:01:46 -0000 --------------090005060101070103010700 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Forgot to address this bit directly: > So why not directly send the exact expiration time of an access token? > As Bill said, this question of "expires_in" vs. "expires_at" was discussed in depth on the list. The truth is, "expires at" is susceptible to clock skew between the server and client (or RS and AS), and this was shown to be a real-world problem with both OAuth1 and OpenID 2.0 timestamps. (I would imagine it's so with other systems as well.) In Oauth1, tokens could expire on the client without the client ever knowing what just happened. With this hint, a smart client can try to refresh their token ahead of time if the timestamp is getting close. Dumb clients still get to ignore it and just respond to an expired token and revoked token in the same way, and everyone's happy. -- Justin > > 2012/8/20 John Bradley > > > A token can always expire in less than that time. > > I have seen deployments that use sliding windows and single use > access tokens. In those cases the "expires_in" is sent as a Max > time before the token will expire. > > A client always needs to be prepared that a token will have been > revoked or expired and fall back to using the refresh token, or > reauthorize. > > John B. > > On 2012-08-19, at 1:35 PM, William Mills wrote: > >> 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 > >> *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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Guangqing Deng > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------090005060101070103010700 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Forgot to address this bit directly:

So why not directly send the exact expiration time of an access token?


As Bill said, this question of "expires_in" vs. "expires_at" was discussed in depth on the list. The truth is, "expires at" is susceptible to clock skew between the server and client (or RS and AS), and this was shown to be a real-world problem with both OAuth1 and OpenID 2.0 timestamps. (I would imagine it's so with other systems as well.)

In Oauth1, tokens could expire on the client without the client ever knowing what just happened. With this hint, a smart client can try to refresh their token ahead of time if the timestamp is getting close. Dumb clients still get to ignore it and just respond to an expired token and revoked token in the same way, and everyone's happy.

 -- Justin


2012/8/20 John Bradley <ve7jtb@ve7jtb.com>
A token can always expire in less than that time.

I have seen deployments that use sliding windows and single use access tokens.   In those cases the "expires_in" is sent as a Max time before the token will expire.

A client always needs to be prepared that a token will have been revoked or expired and fall back to using the refresh token, or reauthorize. 

John B.

On 2012-08-19, at 1:35 PM, William Mills wrote:

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 <leleuj@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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




--
Guangqing Deng



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090005060101070103010700-- From ve7jtb@ve7jtb.com Tue Aug 21 08:33:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB39921F86C8 for ; Tue, 21 Aug 2012 08:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWmKFPBn4731 for ; Tue, 21 Aug 2012 08:33:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2AEB21F86A1 for ; Tue, 21 Aug 2012 08:33:29 -0700 (PDT) Received: by yenm5 with SMTP id m5so6542499yen.31 for ; Tue, 21 Aug 2012 08:33:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=zLp1oMjvSo1i1jAOiv/bq+d26o3mRAVajLXRxoi08xU=; b=aS6UwmaeFxX+hJ6shtfgY1l4KfjDtO8VDLYGlUHUVe1VzsE8ztg6u8iiCXZrnwZxJy cAdv0TS9h9+28IpvR2NRKfguO+/kVZ1MZot4sfL4DdpAuPgj0fme6vIRCWMeoKwM0WCh HxO0fTaP+Nq09z2pktkLmeUhF3OO67hcHoTBHDYCBPVSU2Mk1VKF46+m0PxVsVQvK3Hd FhS+bXSHNxh8XoyQdgEGYnu0ipWBp9MAU88IdVkYjjKGPtbwExnLa1s1+yFu6rZLkMAj +ZZZd6uN9B7ZtdLdzQIsfzS8aPj3AOpalXCDYT5tTb8IxbkDKTMIei+c2V5hAjMtaifx 2wag== Received: by 10.236.161.233 with SMTP id w69mr25496072yhk.74.1345563209363; Tue, 21 Aug 2012 08:33:29 -0700 (PDT) Received: from [192.168.1.39] (190-20-37-8.baf.movistar.cl. [190.20.37.8]) by mx.google.com with ESMTPS id s17sm1431942anj.13.2012.08.21.08.33.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 08:33:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_46D5F834-E004-4FD8-93D3-A5B3A8D58DC7" From: John Bradley In-Reply-To: Date: Tue, 21 Aug 2012 11:33:06 -0400 Message-Id: References: To: Zameer syed X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQmKoobdX8f3Bqwo3vENMUcrD83hNGxRe63LszO8bvSYG91HeOAuGEgHWNtL8Mb0mSJ4LRyS Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth from .net (C#) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:33:30 -0000 --Apple-Mail=_46D5F834-E004-4FD8-93D3-A5B3A8D58DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 There is a .NET open source project http://www.dotnetopenauth.net. That = list may be a good place for your questions. John B. On 2012-08-21, at 10:32 AM, Zameer syed wrote: > I am pretty new to oAuth and no basically nothing about it, is this a = free service, does it have a download. I basically am trying to see if i = can create my own website that has a login and provide that login = credentials for other web sites to use. I am basically trying to see if = i can implement this using .Net as i am .Net developer. Any help and = resource will be greatly appreciated. If you cant help atleast if you = can point me to right direction that will help. > =20 > Thanks, > Zameer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_46D5F834-E004-4FD8-93D3-A5B3A8D58DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 There is a .NET open source project http://www.dotnetopenauth.net. = That list may be a good place for your = questions.

John = B.


On 2012-08-21, at 10:32 AM, = Zameer syed wrote:

I am pretty new to oAuth and no basically nothing = about it, is this a free service, does it have a download. I basically = am trying to see if i can create my own website that has a login and = provide that login credentials for other web sites to use. I am = basically trying to see if i can implement this using .Net as i am .Net = developer. Any help and resource will be greatly appreciated. If you = cant help atleast if you can point me to right direction that will = help.
 
Thanks,
Zameer
____________________________= ___________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_46D5F834-E004-4FD8-93D3-A5B3A8D58DC7-- From jricher@mitre.org Thu Aug 23 07:39:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEC321F8497 for ; Thu, 23 Aug 2012 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bysoi81uIgSK for ; Thu, 23 Aug 2012 07:39:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC3821F847A for ; Thu, 23 Aug 2012 07:39:49 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 004EF21B06BE for ; Thu, 23 Aug 2012 10:39:48 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DE8F721B06B8 for ; Thu, 23 Aug 2012 10:39:47 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 23 Aug 2012 10:39:47 -0400 Message-ID: <50364056.4000400@mitre.org> Date: Thu, 23 Aug 2012 10:38:14 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Subject: [OAUTH-WG] Implementation Support and Community X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:39:50 -0000 With the core specs basically out the door and seeing wider adoption and publicity, the OAuth community is going to start to get more questions about "how do I do X?", and many of these are questions that have been answered before or seem "obvious" to those of us who have been up to our ears in the spec for the past few years. Nevertheless, these are important questions to support for the wellbeing of the protocol community, but where should they be asked? When the OAuth community lived on a simple Google Group, these kinds of questions make sense. But I'd argue that the IETF list is not really the right place for them. This list, and the IETF in general, seems to be best suited for *building* the protocol, not for the *use* and *support* of said protocol once it's built. The problem is that, as of right now, we don't have anywhere to point people where they could get a "real" answer. This opens a larger question of who might "sponsor" or "host" such a community. Anything like that needs moderators, and more importantly, needs experts willing to answer the questions. Some options I can think of: - Revive the google groups list for these kinds of questions/discussions - Start a new list/forum, linked to oauth.net - Point everyone to StackOverflow with an "oauth" tag -- Justin (who is not volunteering himself to host or moderate the group) From ve7jtb@ve7jtb.com Thu Aug 23 07:51:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053EF21F8566 for ; Thu, 23 Aug 2012 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwMfcBgXw5W7 for ; Thu, 23 Aug 2012 07:51:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37DA821F84F3 for ; Thu, 23 Aug 2012 07:51:52 -0700 (PDT) Received: by yhq56 with SMTP id 56so194286yhq.31 for ; Thu, 23 Aug 2012 07:51:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=hS6jSBS4ART9M8Bht1gbCAl7QKf0i1r2fv6Bw+nYo8E=; b=mwpWPdZfNiSxv+GGhrfOO3pY0AvQPfs8ceNxSN84wAdAbmodXCqJl8f3ncZg1xAaja xWiJMzGLjrbsJOHWZTOKqImdJpMjTFr+54pYeecuxUOEPZGQ//Nb0EaBnTtZFoUfhnMg 1UrdomLQ3cHjowJwgL9arSdV9rHEVow0IhMnMilZJCzpGgK8impt9gn8Fzn7mlcn8Tn4 n2rseDfcl6xEBY3N76wpES78dun9xlFy9NyO8U0SJXD2P3GB84z38/wlDEujg0bWsXVa IHg0XxUdz977f/3WYc2ih7jq3/ugTcCURu0vlBiWJQE1OHpByScCEZ+bh7JqxgC2mBDc Soxg== Received: by 10.236.173.137 with SMTP id v9mr1508393yhl.0.1345733511665; Thu, 23 Aug 2012 07:51:51 -0700 (PDT) Received: from [192.168.1.35] (190-20-49-249.baf.movistar.cl. [190.20.49.249]) by mx.google.com with ESMTPS id e24sm13762428yhh.4.2012.08.23.07.51.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 07:51:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: John Bradley In-Reply-To: <50364056.4000400@mitre.org> Date: Thu, 23 Aug 2012 10:51:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50364056.4000400@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQmjZc65JY45cLIfJr8bpOIYupjFxGgE9IBPkj3zuLG0irz3fDJ2vWr7FYQCurC22fe3MVme Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Implementation Support and Community X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 14:51:53 -0000 The openID foundation is in a position of promoting OAuth 2 now as a = significant dependency of openID Connect and other work. I can ask the board if there is a interest in hosting something specific = for OAuth 2. =20 I agree with Justin, now that the core spec is done there needs to be = some consideration put to marketing and support by someone.=20 This WG has new work items to progress so we probably don't want to get = bogged down with that in this group. I will wait to see the discussion on this here before asking OIDF or = anyone else if they want to set something up. John B. On 2012-08-23, at 10:38 AM, Justin Richer wrote: > With the core specs basically out the door and seeing wider adoption = and publicity, the OAuth community is going to start to get more = questions about "how do I do X?", and many of these are questions that = have been answered before or seem "obvious" to those of us who have been = up to our ears in the spec for the past few years. Nevertheless, these = are important questions to support for the wellbeing of the protocol = community, but where should they be asked? >=20 > When the OAuth community lived on a simple Google Group, these kinds = of questions make sense. But I'd argue that the IETF list is not really = the right place for them. This list, and the IETF in general, seems to = be best suited for *building* the protocol, not for the *use* and = *support* of said protocol once it's built. >=20 > The problem is that, as of right now, we don't have anywhere to point = people where they could get a "real" answer. >=20 > This opens a larger question of who might "sponsor" or "host" such a = community. Anything like that needs moderators, and more importantly, = needs experts willing to answer the questions. Some options I can think = of: >=20 > - Revive the google groups list for these kinds of = questions/discussions > - Start a new list/forum, linked to oauth.net > - Point everyone to StackOverflow with an "oauth" tag >=20 >=20 > -- Justin (who is not volunteering himself to host or moderate the = group) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eve@xmlgrrl.com Thu Aug 23 19:49:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B739C21F8574 for ; Thu, 23 Aug 2012 19:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbzfG27KsqzO for ; Thu, 23 Aug 2012 19:49:11 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id EB78B21F85AD for ; Thu, 23 Aug 2012 19:49:10 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q7O2n7J8002959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Aug 2012 19:49:09 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Thu, 23 Aug 2012 19:49:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26F5345A-064F-4330-A274-A90CFC653978@xmlgrrl.com> References: <50364056.4000400@mitre.org> To: John Bradley X-Mailer: Apple Mail (2.1485) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Implementation Support and Community X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 02:49:11 -0000 Perhaps relatedly, in the UMA group we've been defining feature tests = for interoperability testing, and since UMA uses OAuth, we wondered if = any OAuth feature tests exist; we couldn't find any. That might be = another activity worthy of being taken up by such a community. (Both UMA = and OpenID Connect are using the OSIS.idcommons.net wiki for interop = testing.) Eve On 23 Aug 2012, at 7:51 AM, John Bradley wrote: > The openID foundation is in a position of promoting OAuth 2 now as a = significant dependency of openID Connect and other work. >=20 > I can ask the board if there is a interest in hosting something = specific for OAuth 2. =20 >=20 > I agree with Justin, now that the core spec is done there needs to be = some consideration put to marketing and support by someone.=20 > This WG has new work items to progress so we probably don't want to = get bogged down with that in this group. >=20 > I will wait to see the discussion on this here before asking OIDF or = anyone else if they want to set something up. >=20 > John B. > On 2012-08-23, at 10:38 AM, Justin Richer wrote: >=20 >> With the core specs basically out the door and seeing wider adoption = and publicity, the OAuth community is going to start to get more = questions about "how do I do X?", and many of these are questions that = have been answered before or seem "obvious" to those of us who have been = up to our ears in the spec for the past few years. Nevertheless, these = are important questions to support for the wellbeing of the protocol = community, but where should they be asked? >>=20 >> When the OAuth community lived on a simple Google Group, these kinds = of questions make sense. But I'd argue that the IETF list is not really = the right place for them. This list, and the IETF in general, seems to = be best suited for *building* the protocol, not for the *use* and = *support* of said protocol once it's built. >>=20 >> The problem is that, as of right now, we don't have anywhere to point = people where they could get a "real" answer. >>=20 >> This opens a larger question of who might "sponsor" or "host" such a = community. Anything like that needs moderators, and more importantly, = needs experts willing to answer the questions. Some options I can think = of: >>=20 >> - Revive the google groups list for these kinds of = questions/discussions >> - Start a new list/forum, linked to oauth.net >> - Point everyone to StackOverflow with an "oauth" tag >>=20 >>=20 >> -- Justin (who is not volunteering himself to host or moderate the = group) >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > 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 From ve7jtb@ve7jtb.com Thu Aug 23 20:03:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E8121F8526 for ; Thu, 23 Aug 2012 20:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAuWo5abqgwL for ; Thu, 23 Aug 2012 20:03:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1E21F8527 for ; Thu, 23 Aug 2012 20:03:00 -0700 (PDT) Received: by qcac10 with SMTP id c10so1060352qca.31 for ; Thu, 23 Aug 2012 20:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=2x5dZSBjinTJidukiIggUqDc+q8S7llLDu8r3ym6Cj0=; b=aVm5enrY94jKnmdTF8LSVcHmxjYI4C+mLiYYoPK3wGUzBtSAW/2x30GdY1PoNcn8l1 ixi2BfpRl0vaD0ZpoMVTT0x+vZf1k8EwXNVFe0kCAI9DcMQ9yVlBiQsHX1Cnm9Mc/c8I L7RVxVtibeyRCB1/Ld66kVH5wZXNTsudJJ8uwuIWecRzHhjbLuqLxxsOrrnk9ZqWXs1g 6khh1ztjiJNG2CjBjAH49Y/d4Bt/UYCrUEZenT3AE9bOjJTnXtPLfV3tZ7pp1deWPDeI GauUIkMZSb8mGp3z63pSKmuusVF/mYHpxh3u9AaQc556iZF2ftEMvaLHWFxL1JYCAncY 6REw== Received: by 10.229.135.202 with SMTP id o10mr1808670qct.19.1345777380240; Thu, 23 Aug 2012 20:03:00 -0700 (PDT) Received: from [192.168.1.211] (190-20-25-212.baf.movistar.cl. [190.20.25.212]) by mx.google.com with ESMTPS id hq10sm6564445qab.1.2012.08.23.20.02.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 20:02:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_732276A4-A817-4019-9AF0-B537F3A6B4F6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: John Bradley In-Reply-To: <26F5345A-064F-4330-A274-A90CFC653978@xmlgrrl.com> Date: Thu, 23 Aug 2012 23:02:52 -0400 Message-Id: References: <50364056.4000400@mitre.org> <26F5345A-064F-4330-A274-A90CFC653978@xmlgrrl.com> To: Eve Maler X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQkh5TVAhnqEySnbSlzF/qJQOyEjQWoVzCjj9NxqXLN9ODdY/n4g9i2x5XamM0NtJP5k9cJR Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Implementation Support and Community X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 03:03:04 -0000 --Apple-Mail=_732276A4-A817-4019-9AF0-B537F3A6B4F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Not that I know of beyond what we have as part of the openID Connect = testing. =20 A good number of those tests cover the underlying OAuth 2 flows. It would not take too much to expand the FEDLAB test harness for more = generic OAuth tests if there was a demand. Though without a protocol to apply OAuth to the tests are more of a = challenge. John B. On 2012-08-23, at 10:49 PM, Eve Maler wrote: > Perhaps relatedly, in the UMA group we've been defining feature tests = for interoperability testing, and since UMA uses OAuth, we wondered if = any OAuth feature tests exist; we couldn't find any. That might be = another activity worthy of being taken up by such a community. (Both UMA = and OpenID Connect are using the OSIS.idcommons.net wiki for interop = testing.) >=20 > Eve >=20 > On 23 Aug 2012, at 7:51 AM, John Bradley wrote: >=20 >> The openID foundation is in a position of promoting OAuth 2 now as a = significant dependency of openID Connect and other work. >>=20 >> I can ask the board if there is a interest in hosting something = specific for OAuth 2. =20 >>=20 >> I agree with Justin, now that the core spec is done there needs to be = some consideration put to marketing and support by someone.=20 >> This WG has new work items to progress so we probably don't want to = get bogged down with that in this group. >>=20 >> I will wait to see the discussion on this here before asking OIDF or = anyone else if they want to set something up. >>=20 >> John B. >> On 2012-08-23, at 10:38 AM, Justin Richer wrote: >>=20 >>> With the core specs basically out the door and seeing wider adoption = and publicity, the OAuth community is going to start to get more = questions about "how do I do X?", and many of these are questions that = have been answered before or seem "obvious" to those of us who have been = up to our ears in the spec for the past few years. Nevertheless, these = are important questions to support for the wellbeing of the protocol = community, but where should they be asked? >>>=20 >>> When the OAuth community lived on a simple Google Group, these kinds = of questions make sense. But I'd argue that the IETF list is not really = the right place for them. This list, and the IETF in general, seems to = be best suited for *building* the protocol, not for the *use* and = *support* of said protocol once it's built. >>>=20 >>> The problem is that, as of right now, we don't have anywhere to = point people where they could get a "real" answer. >>>=20 >>> This opens a larger question of who might "sponsor" or "host" such a = community. Anything like that needs moderators, and more importantly, = needs experts willing to answer the questions. Some options I can think = of: >>>=20 >>> - Revive the google groups list for these kinds of = questions/discussions >>> - Start a new list/forum, linked to oauth.net >>> - Point everyone to StackOverflow with an "oauth" tag >>>=20 >>>=20 >>> -- Justin (who is not volunteering himself to host or moderate the = group) >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 --Apple-Mail=_732276A4-A817-4019-9AF0-B537F3A6B4F6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy NDAzMDI1MlowIwYJKoZIhvcNAQkEMRYEFK7uFMj7i+JRpc4nH+fmHYXEqZcUMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ABiW7lu53+CJdMbshynqT81GErmrY1037G71zX5KeJycLinnf7vMw2SgbOd20H2iwqLKHQjD+Ltx AF956VrLhNNBdlJJNdyLSlQKNK4LgwkiQ0kKe1S33ajA0O99lRamyUwCaMctVxVot8beByDrxNiC K6LHanBowi3sqjfmV1EX+Ljl16JYhWx8GPcsiVg/zwQxna23Ry+JLT4GWUViqmjU94jOzEulfDT6 Ga1Ygslom0rv/HDENWvjmfoG7NjpaqMQuN57FblqyPxHCsoMyPGmjJtzv0WiYPXwALO0BR8hs4uL xOqPLcnzcbMRBxLBpShmT11vVQYOzLpcpJVIgFwAAAAAAAA= --Apple-Mail=_732276A4-A817-4019-9AF0-B537F3A6B4F6-- From igor.faynberg@alcatel-lucent.com Thu Aug 23 20:14:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9498A21F866C for ; Thu, 23 Aug 2012 20:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.333 X-Spam-Level: X-Spam-Status: No, score=-7.333 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLAcNiVKyI87 for ; Thu, 23 Aug 2012 20:14:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69B21F8668 for ; Thu, 23 Aug 2012 20:14:37 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7O3Ea1D006052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 Aug 2012 22:14:36 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7O3EZpi003435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 Aug 2012 22:14:36 -0500 Received: from [135.244.41.244] (faynberg.lra.lucent.com [135.244.41.244]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q7O3EZgU016079; Thu, 23 Aug 2012 22:14:35 -0500 (CDT) Message-ID: <5036F19A.7070703@alcatel-lucent.com> Date: Thu, 23 Aug 2012 23:14:34 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <50364056.4000400@mitre.org> <26F5345A-064F-4330-A274-A90CFC653978@xmlgrrl.com> In-Reply-To: <26F5345A-064F-4330-A274-A90CFC653978@xmlgrrl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] Implementation Support and Community X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 03:14:38 -0000 An interesting thought! It is true that interoperability testing is a requirement for an advancement of a Proposed Standard to Draft Standard, so surely OAuth interoperability testing must take place. I I don't recall test suits defined per se in the IETF. Not that it has not happened--it simply has not happened in the groups I worked in or followed. I remember SIP bake-offs progressing well, but not tested to a specific test case set. Very roughly, the use case document does identify pre- and post conditions, but this may not provide enough granularity. Maybe it can be used as a starting point though. Igor On 8/23/2012 10:49 PM, Eve Maler wrote: > Perhaps relatedly, in the UMA group we've been defining feature tests for interoperability testing, and since UMA uses OAuth, we wondered if any OAuth feature tests exist; we couldn't find any. That might be another activity worthy of being taken up by such a community. (Both UMA and OpenID Connect are using the OSIS.idcommons.net wiki for interop testing.) > > Eve > > On 23 Aug 2012, at 7:51 AM, John Bradley wrote: > >> The openID foundation is in a position of promoting OAuth 2 now as a significant dependency of openID Connect and other work. >> >> I can ask the board if there is a interest in hosting something specific for OAuth 2. >> >> I agree with Justin, now that the core spec is done there needs to be some consideration put to marketing and support by someone. >> This WG has new work items to progress so we probably don't want to get bogged down with that in this group. >> >> I will wait to see the discussion on this here before asking OIDF or anyone else if they want to set something up. >> >> John B. >> On 2012-08-23, at 10:38 AM, Justin Richer wrote: >> >>> With the core specs basically out the door and seeing wider adoption and publicity, the OAuth community is going to start to get more questions about "how do I do X?", and many of these are questions that have been answered before or seem "obvious" to those of us who have been up to our ears in the spec for the past few years. Nevertheless, these are important questions to support for the wellbeing of the protocol community, but where should they be asked? >>> >>> When the OAuth community lived on a simple Google Group, these kinds of questions make sense. But I'd argue that the IETF list is not really the right place for them. This list, and the IETF in general, seems to be best suited for *building* the protocol, not for the *use* and *support* of said protocol once it's built. >>> >>> The problem is that, as of right now, we don't have anywhere to point people where they could get a "real" answer. >>> >>> This opens a larger question of who might "sponsor" or "host" such a community. Anything like that needs moderators, and more importantly, needs experts willing to answer the questions. Some options I can think of: >>> >>> - Revive the google groups list for these kinds of questions/discussions >>> - Start a new list/forum, linked to oauth.net >>> - Point everyone to StackOverflow with an "oauth" tag >>> >>> >>> -- Justin (who is not volunteering himself to host or moderate the group) >>> _______________________________________________ >>> 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 > > 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 From dick.hardt@gmail.com Thu Aug 23 20:33:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6BF21F84BF for ; Thu, 23 Aug 2012 20:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGOkAYRZTNpp for ; Thu, 23 Aug 2012 20:33:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79B21F84B8 for ; Thu, 23 Aug 2012 20:33:27 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2541813pbb.31 for ; Thu, 23 Aug 2012 20:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5yXox+19LvBciKAxcsxFq0olp3mBCAy3rGpueKfcm3U=; b=NR8l77hZiZNvrtDysWjHYd07IpId2kQVkWnfcsj2bs9K+8YvJti8U/38NHe+IpW/5S tbXq4lpMJhymoYcJHImJY/ANBI98rFpgdKK6iufcu+UEYcjgkzjDlTk2gCKqPFbpNtLE jqJfT278mOBhRmHT490UtKc9KzZ+04lASHIzKfb6SA00X2A/XLcrNFgqiQtTS4vPIid2 zaUAQDWyxCm577WSWDqvDtn+PmR3WUim4H74bceWB3z0Q72OdQ8WUUaORzoZpRvKQaL7 PVgDeJqD/GOJ/SEKPiHAvdxjyt34daP0ANzWbWo7zzFgFlSz2fV3GpX4/DaIotb67YNX HPIQ== Received: by 10.68.228.132 with SMTP id si4mr2325252pbc.57.1345779206855; Thu, 23 Aug 2012 20:33:26 -0700 (PDT) Received: from [10.0.0.91] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hc10sm426605pbc.21.2012.08.23.20.33.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 20:33:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Dick Hardt In-Reply-To: <50364056.4000400@mitre.org> Date: Thu, 23 Aug 2012 20:33:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50364056.4000400@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1485) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Implementation Support and Community X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 03:33:27 -0000 +1 to StackOverflow -- that has become the goto source for programming = FAQs On Aug 23, 2012, at 7:38 AM, Justin Richer wrote: > With the core specs basically out the door and seeing wider adoption = and publicity, the OAuth community is going to start to get more = questions about "how do I do X?", and many of these are questions that = have been answered before or seem "obvious" to those of us who have been = up to our ears in the spec for the past few years. Nevertheless, these = are important questions to support for the wellbeing of the protocol = community, but where should they be asked? >=20 > When the OAuth community lived on a simple Google Group, these kinds = of questions make sense. But I'd argue that the IETF list is not really = the right place for them. This list, and the IETF in general, seems to = be best suited for *building* the protocol, not for the *use* and = *support* of said protocol once it's built. >=20 > The problem is that, as of right now, we don't have anywhere to point = people where they could get a "real" answer. >=20 > This opens a larger question of who might "sponsor" or "host" such a = community. Anything like that needs moderators, and more importantly, = needs experts willing to answer the questions. Some options I can think = of: >=20 > - Revive the google groups list for these kinds of = questions/discussions > - Start a new list/forum, linked to oauth.net > - Point everyone to StackOverflow with an "oauth" tag >=20 >=20 > -- Justin (who is not volunteering himself to host or moderate the = group) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Prateek.Mishra@oracle.com Sat Aug 25 07:48:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7432121F847A for ; Sat, 25 Aug 2012 07:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.843 X-Spam-Level: X-Spam-Status: No, score=-7.843 tagged_above=-999 required=5 tests=[AWL=-2.755, BAYES_05=-1.11, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfjhlLLUZhdK for ; Sat, 25 Aug 2012 07:48:58 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id E61C721F8452 for ; Sat, 25 Aug 2012 07:48:57 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7PEmtt5028006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 25 Aug 2012 14:48:56 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7PEmtAS022916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 25 Aug 2012 14:48:55 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7PEmskK025998 for ; Sat, 25 Aug 2012 09:48:55 -0500 Message-Id: <201208251448.q7PEmskK025998@acsmt357.oracle.com> Received: from [192.168.2.3] (/66.31.108.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 25 Aug 2012 07:48:54 -0700 To: oauth@ietf.org From: "=?utf-8?B?UHJhdGVlayBNaXNocmE=?=" Date: Sat, 25 Aug 2012 10:48:54 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1345906134468" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 14:48:58 -0000 ------=_Part_0_1345906134468 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline CgpTZW50IGZyb20gbXkgVmVyaXpvbiBXaXJlbGVzcyBQaG9uZQ== ------=_Part_0_1345906134468 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxicj5TZW50IGZyb20gbXkgVmVyaXpvbiBXaXJlbGVzcyBQaG9uZTxicj48YnI+ ------=_Part_0_1345906134468--