Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
Justin Richer writes: > I think the concern here is that rotation of client credential is not > something discussed before. Before we put it in the spec we should > consider the reasons for doing it and what problems it solves. > > The client doesn't get to choose when its credentials get rotated. It used to > be able to, but now it's purely the server's choice, including whether or not > it wants to rotate things at all. I think this confusion can be cleared up > with the explicit lifecycle discussion getting pulled out into one place. >From a security standpoint, either side should be able to rotate keys. It should not be only one side's choice; either side should have the option to refresh due to local policy (or worse, local knowledge of an issue). -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10
Phil, Phil Hunt writes: > Not quite. I will call you. > > I am saying we are transitioning from the old public client model. The new > model proposes quasi-confidential characteristics but in some respects is > missing key information from the public model. Namely that a group of clients > are related and there have common behaviour and security characteristics. > > We need to add to the self-asserted model an assertion equiv to the old common > client_id. That is all. > > I am NOT looking for a proof of application identity here. That is too far. > But certainly what we define here can open that door. > > Phil I think I understand what you're saying here. In the "old way", a public client had a constant client_id amongst all instances of that public client, whereas in the "new way", a public client will have different client_ids amongst all instances of that client. You feel this is a loss, whereas it seems most people seem to feel this change is okay. Since you are effectively the lone dissenter on this one topic, let me ask you a question: What is a technical reason that you need to have a constant, assertion that would bind together (in a non-authenticated way) multiple instances of a client? I believe that Justin has provides some attacks against this; so I'm trying to understand, (with my chair hat on), why you need this functionality? With my security-mafia hat on, I feel like the old way was bad, and I much prefer the newer way where each instance of a client gets its own ID and a locally-stored secret. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Protocol Action: 'OAuth 2.0 Token Revocation' to Proposed Standard (draft-ietf-oauth-revocation-11.txt)
... Which was just published as RFC 7009. Great work, everyone! -derek Hannes Tschofenig writes: > A big "Thank you" goes to Torsten for working hard to get the document > through the IETF process. > > On Jul 20, 2013, at 4:43 AM, The IESG wrote: > >> The IESG has approved the following document: >> - 'OAuth 2.0 Token Revocation' >> (draft-ietf-oauth-revocation-11.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-revocation/ >> >> >> >> >> Technical Summary >> >> The OAuth Token Revocation specification proposes an additional >> endpoint for OAuth authorization servers, which allows clients to >> notify the authorization server that a previously obtained refresh >> or access token is no longer needed. This allows the authorization >> server to cleanup security credentials. A revocation request will >> invalidate the actual token and, if applicable, other tokens based >> on the same authorization grant. >> >> Working Group Summary >> >> The document experienced no particular problems in the working >> group. >> >> Document Quality >> >> The document has been deployed by four companies, namely >> by Salesforce, Google, Deutsche Telekom, and MITRE. The >> working group reviewed and discussed the document extensively. >> >> There was a comment from the appsdir review that was not >> accepted. The reviewer (mnot) suggested a discovery >> mechanism was needed, but the wg are working on >> generic oauth discovery and not just for revocation and >> so decided not to make that change. >> >> Personnel >> >> Hannes Tschofenig is the document shepherd. >> The responsible area director is Stephen Farrell. >> >> ___ >> 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 > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Current Progress in use case document?
Sorry, I meant to ping about this document but I've been inundated with "Real Work(TM)" since Berlin. Alas, the document expired, which means we need a new version submitted before we can send it through the process. Can one get submitted, please? Thanks, -derek Igor Faynberg writes: > Zhou, > > The correct addres for Zachary is on the (corrected) CC list. > > My take on it is that the Use Cases document has been ready for approval for > quite a while, and there were no concerns about misunderstandings. The cases > are clearly delineated by their respective 1) descriptions, 2) pre-conditions, > and 3) post-conditions. > > I might try to to help, but I don't quite understand what "some diagram" means > here and why it should be added. Nor do I understand what your difficulty in > discerning one use case from another is. If you see something specifically > wrong with what is there please point this out. > > If you need a tutorial on Use Cases, please write to Zachary. > > With thanks, > > Igor > > On 8/5/2013 5:40 AM, zhou.suj...@zte.com.cn wrote: > > Hi, all > The use case documemnt will not be updated? > For a reader it is very difficult to discern a use case from another > one. > Could some diagram be added? Could some explanation be added to > clarify why some cases cannot be supperted by oauth 2.0? > > ___ > 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 -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [oauth-interop] Joint meeting @IETF88: OAuth 2.0 Interop Strategy and Planning and OpenID Connect
I have conflicting meetings Sunday afternoon, so I may wind up jumping from meeting to meeting. At first I thought they only overlapped for a portion of the day, but now they overlap the whole day (my other meeting is from 12:15-3:25, apparently). I will figure it out. See you Sunday. -derek On Thu, October 31, 2013 3:30 pm, Prateek Mishra wrote: > Karen, > > I am planning to attend the meeting on Sunday. > > However, I have made my travel plans based on your previous announcement > of 9/20 > [quote] > 2. Hold a oauth interop planning meeting in Vancouver in conjunction > with IETF#88. > This meeting is planned for: > Sunday, 3 November, 2013, 2:00 pm - 4:00 pm PST (exact location TBD) > [\quote] > > I am only going to arrive with certainty by 1pm, so I would suggest > moving the meeting time back to reflect the previously announced time > slot (or at least start at 1pm). > > - prateek >> Folks, >> >> As I announced earlier via these mailing lists, we will have a meeting >> to discuss strategy and plans for OAuth2.0 Interop testing in general >> and a possible OAuth 2.0 Interop Test Event in early 2014. This will >> be followed by an OpenID Connect meeting. These meetings have been >> scheduled in conjunction with 88 IETF as follows: >> >> Sunday, 3 November 2013 >> Plaza C Room, 2nd Floor >> >> 12:00 - 1:55 pm PST (OAuth 2.0 Interoperability) >> 1:55 - 2:05 pm PDT Beverage/snack/bio break >> 2:05 - 4:00 pm PST (OpenID Connect) >> >> I did establish a wiki to assist with the OAuth 2.0 Interop planning, >> but it was gently pointed out to me today that I never sent the link >> out. My sincere apologies for that oversight. The wiki is available >> via either of these links: >> https://tid.isoc.org/confluence/display/OAuthIOP/OAuth+Interoperability+and+Deployment+Activities+Home >> >> https://tid.isoc.org/confluence/x/JYA7 >> >> Regards, >> Karen >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > ___ > Oauth-interop mailing list > oauth-inte...@elists.isoc.org > https://elists.isoc.org/mailman/listinfo/oauth-interop > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth Agenda for IETF-88
The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 hour session, and I expect we'll use most of it for discussion. For anyone who wants to make a status update on their draft please: 1) Get me slides before the meeting so I can post them online, 2) Try to keep yourself to a MAX of THREE (3) slides 3) Try to keep your comments to under 10 minutes (under 5 even better) Face to face time is best used for discussion, not presentation. :) Here is the proposed agenda. I'll post this on the website before the meeting on Monday. Please let me know if you have any additions before then. * Welcome & Agenda Bashing (10 minutes) * Draft Statuses (20 minutes) * Discussion (2 hours) - draft-bradley-stateless-oauth-client (30 min max) - Proof of Possession (30 min max) - Dynamic Client Registration (remainder, 60+min) * draft-richer-oauth-dyn-reg-core * draft-richer-oauth-dyn-reg-management * ... -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Agenda for IETF-88
Just a clarification: if you are making a status update slides are NOT required. The slide info was if you WERE planning to make slides. Sorry for any confusion. See you Monday! -derek On Thu, October 31, 2013 4:07 pm, Derek Atkins wrote: > The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 > hour session, and I expect we'll use most of it for discussion. For > anyone who wants to make a status update on their draft please: > > 1) Get me slides before the meeting so I can post them online, > 2) Try to keep yourself to a MAX of THREE (3) slides > 3) Try to keep your comments to under 10 minutes (under 5 even better) > > Face to face time is best used for discussion, not presentation. :) > > Here is the proposed agenda. I'll post this on the website before the > meeting on Monday. Please let me know if you have any additions before > then. > > > * Welcome & Agenda Bashing (10 minutes) > * Draft Statuses (20 minutes) > * Discussion (2 hours) > - draft-bradley-stateless-oauth-client (30 min max) > - Proof of Possession (30 min max) > - Dynamic Client Registration (remainder, 60+min) > * draft-richer-oauth-dyn-reg-core > * draft-richer-oauth-dyn-reg-management > * ... > > > -derek > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > > _______ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Agenda for IETF-88
Yes, that is the main topic of discussion. -derek Sent from my HTC smartphone - Reply message - From: "Anthony Nadalin" To: "Derek Atkins" , "oauth@ietf.org" Subject: [OAUTH-WG] OAuth Agenda for IETF-88 Date: Thu, Oct 31, 2013 7:21 PM The client registration is still open, so we need to continue our discussion that was started with the interim call -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Derek Atkins Sent: Thursday, October 31, 2013 1:07 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth Agenda for IETF-88 The IETF is next week, and OAuth meets Monday Afternoon. We have a 2-1/2 hour session, and I expect we'll use most of it for discussion. For anyone who wants to make a status update on their draft please: 1) Get me slides before the meeting so I can post them online, 2) Try to keep yourself to a MAX of THREE (3) slides 3) Try to keep your comments to under 10 minutes (under 5 even better) Face to face time is best used for discussion, not presentation. :) Here is the proposed agenda. I'll post this on the website before the meeting on Monday. Please let me know if you have any additions before then. * Welcome & Agenda Bashing (10 minutes) * Draft Statuses (20 minutes) * Discussion (2 hours) - draft-bradley-stateless-oauth-client (30 min max) - Proof of Possession (30 min max) - Dynamic Client Registration (remainder, 60+min) * draft-richer-oauth-dyn-reg-core * draft-richer-oauth-dyn-reg-management * ... -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IETF WG Follow-up
I realize it's short notice but a bunch of us are going to try to get together for dinner tonight (Tuesday), meeting at the Hotel Lobby (near the concierge desk) at 1845. -derek On Tue, November 5, 2013 7:34 pm, Matt Miller (mamille2) wrote: > A working lunch I can do in both cases, if real-time feedback is deemed > worthwhile. I could also participate in a dinner session Wednesday night. > > Otherwise, I will review anything posted to the list of you can send me > pre-drafts. > > > - m&m > > Matt Miller < mamil...@cisco.com > > Cisco Systems, Inc. > > On Nov 5, 2013, at 4:11 PM, Brian Campbell > wrote: > >> Both after the plenary tomorrow and/or after JOSE on Thus work for me. >> Though not too much after as I've got other commitments later on both >> days. >> >> What about a "working lunch" tomorrow after the plenary? I bet even >> Matt eats lunch... >> >> >> >> On Tue, Nov 5, 2013 at 3:28 PM, Matt Miller (mamille2) >> wrote: >>> >>> On Nov 5, 2013, at 3:01 PM, Richer, Justin P. >>> wrote: >>> >>>> At the end of Monday's WG session here at IETF, Derek suggested that >>>> several of us who are here ought to get together and hash out some >>>> detailed solutions to Dyn-Reg and related issues in person while we >>>> have the opportunity. As such, I suggest that those of us who are >>>> interested get together either tomorrow after the morning plenary >>>> session or on Thursday after the JOSE session. I'm personally here for >>>> the remainder of the week so I'm open to other concrete suggestions as >>>> well. >>>> >>>> I'm even willing to bring my laptop along and we can try doing live >>>> spec surgery if it comes to that. >>>> >>> >>> I fully support this action, but unfortunately I'm not sure I >>> personally can participate before Friday afternoon. I'm not entirely >>> sure how much benefit I can provide directly, but am more than willing >>> to review the output. >>> >>> >>> - m&m >>> >>> Matt Miller < mamil...@cisco.com > >>> Cisco Systems, Inc. >>> >>> >>> ___ >>> 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 > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Draft Minutes from IETF-88
NOTE: Please let me know if you find any issues with the minutes; I'll upload a final version with any necessary changes. -derek OAUTH WG - IETF 88 PARTICIPANTS * Anthony Nadlin (AN) * Brian Campbell (BN) * Derek Atkins (DA) * John Bradley (JB) * Justin Richer (JR) * Mike Jones (MJ) * Nat Sakamura (NS) * Phil Hunt (PH) * Prateek Mishra (PM) * Stephen Farrell (SF) * Tim Bray (TB) * Torsten Lodderstedt (TL) * Matt Miller (MM) Draft Statuses -- * draft-ietf-oauth-jwt-bearer :: Mike Jones is working to update from feedback * PH : At the end of Berlin, presented auth draft. Some changes to align with OpenID, but waiting on recharter discussion. Would like feedback. * NS : What is a good time to talk about recharter? * DA : Looks to AD -- let's finish some of the work we've got, then we can talk about adding more work. * SF : I don't think I saw discussion about recharter, and we have a number of knotty problems that need to be resolved first. * PM : I am confused about where we are with the SAML and assertions dtrafts? * DA : Waiting on Barry and Hannes to finish reviews -- can't do anything until they're done. * PM : Are there any substantive problems? * DA : None that I'm aware of * SF : Sometimes there's too much process in the IESG, so we're kind of waiting on the WG to finish. * NS : On recharter, should we postpone all the discussion on new documents until we get these other things done? I am puzzled by all the -00's while there's WG items to finish. * DA : These new drafts are toward the current charter items. * BN : My understanding -- came back from IESG after 86, and made significant changes. Now waiting on Hannes and other feedback. * DA : Hannes has been very busy with other activities, and can't get to these right now. We are waiting on Hannes right now. * JR : I suggest we fold stateless-client into dynamic registration. Proof of Possession (Anthony Nadlin) * PH : IIRC the MAC spec was folding in HotK, and we thought symmetric was sufficient. * JR : To follow up, we had decided that we wanted to do MAC (symmetric), but if we could do asymmetric as easily then we would. * JB : There was a feeling at the time that asymmetric with channel binding was too complicated, so we started off with the simplest (symmetric). I just sent a message to the list about why symmetric keys are bad. One advantage of asymmetric keys is that people do the right thing more often. * PM : Are you referencing a draft? * AN : Yes, there's a HotK draft (expired), that we think should be updated to talk about asymmetric keys. * PM : ANd you're proposing a new approach? * AN : No, I'm proposing we move it into the WG draft. * PH : On TLS channel binding, that was something exploring a new draft. It was interesting, but introduced a bunch of new questions. * AN : Channel binding was one approach, but there are others. I am proposing we update the HotK draft to talk about a couple of other ways. * JR : One feature from OAuth1 and other drafts, is to optionally sign parts of the HTTP message in addition to just the token. * AN : It gets into some issues, but if you have a specific use-case then we should talk about it. * JR : I brought them up on the list and in the call, but I can reiterate them again. And I think we can layer them into the JWT approach. * AN : But it's a different signature * JR : It's actually not -- it's just JWS. * MJ : I lost track -- does this require rechartering, and is recharting in flight? * DA : I don't think this draft requires rechartering, and we do not have a recharting in flight * TL : Did you want to remove symmetric? * NA : No, we just wanted to update the asymmetric part. ActAs/OnBefalfOf (Mike Jones) - * TL : Clarifying question: is the security token an assertion? * MJ : Yes, it's functionally equivalent. * TL : I suggest you use assertion. Also, is this meant to be a token, or an assertion? * MJ : It's an assertion. It might be used as an access token, but that is outside the scope of this. * TL : I suggest this go to another endpoint because it's not compliant to the current semantics * JR : I would like to see an alignment or clear delineation between this approach and where tokens have been used to get other tokens. I'm not going so far as to requiring a different endpoint, but I would like an alignment or delineation. * DA : What's the difference between of an assertion and a token? * JR : A token is completely opague to the client. * MJ : I take your point on comparing this to token-in/token-out approaches * PM : Is this a profile of the assertion draft? * MJ : No * PM : And this is not a profile is because this is returning an assertion? * MJ : There are several reasons -- you can use an assertion to get access tokens or authorization codes. We didn&#
Re: [OAUTH-WG] Thurs tap and barrel
I'll try to meet you at T&B; I have other dinner plans first. -derek On Thu, November 7, 2013 6:54 pm, Phil Hunt wrote: > A bunch of us were talking about heading over to tap and barrel (near > canada place) for craft brew beer and barrel wine tasting. > > Maybe a little scim/oauth on the side. > > Suggest we meet for 6:30 at hotel lobby. > > Phil > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Request for Agenda Items for IETF-89
Happy new year everyone. I hope you all had a great holiday break, but now it's time to get down and dirty and get the OAUTH documents out the door. IETF-89 in London is coming sooner than you think. I'd like to ask each of you for agenda items to bring up at the meeting. In particular: Document Authors/Editors: Please work up a status report for your documents, and come up with a list of open issues that you think need discussion time. Please include a time estimate. Proposed documents: If you have proposed work, please let me know how much time you'll need. Other issues: If you have other issues that require dedicated time, please let me know too! Thanks, -derek, OAuth co-chair -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: Tutorials (OAuth, Kerberos, PKI) for ACE BOF Preparation
My understanding is that OAuth will meet *before* Connect on Sunday, starting at 10am (or was it 10:30?) -derek On Tue, February 25, 2014 11:17 am, Bill Mills wrote: > I haven't heard the time or place of the Connect meeting, and I'd come to > both. FYI my plane doesn't land until 10:30 I think. > > > > On Monday, February 24, 2014 11:32 PM, John Bradley > wrote: > > Hannes, > > Is the OAuth Proof of possession meeting going to be at 10am Sunday March > 2? > > I was talking to some WG members yesterday who thought that we were > meeting in the afternoon after the Connect meeting. > > John B. > > > On Feb 25, 2014, at 12:53 AM, Hannes Tschofenig > wrote: > >> Hi all, >> >> in preparation for the ACE BOF at this IETF I thought it would be useful >> to have some tutorials about relevant IETF technologies. >> These tutorials will take place this week (via Webex, 1 hour session). >> >> In case you are not on the IETF ACE mailing list I thought it makes >> sense to forward it also to SAAG. >> >> ** Kerberos Tutorial >> Presenter: Thomas Hardjono >> Date: Tuesday, February 25, 2014 >> Time: 1:00 pm, GMT Time (London, GMT) >> Meeting Number: 644 999 834 >> Meeting Password: kerberos >> Online meeting: >> https://ietf.webex.com/ietf/j.php?MTID=m1ece1ae3939e5d85a28b2b235160458c >> Audio conference information >> - Call-in toll number (US/Canada): 1-650-479-3208 >> - Access code:644 999 834 >> To add this meeting to your calendar program: >> https://ietf.webex.com/ietf/j.php?MTID=mbf017fcbf20fad698c6f2b5b704c3847 >> >> ** PKI Tutorial >> Presenter: Sean Turner >> Date: Wednesday, February 26, 2014 >> Time: 1:00 pm, GMT Time (London, GMT) >> Meeting Number: 647 365 244 >> Meeting Password: sean >> >> Online meeting: >> https://ietf.webex.co/ietf/j.php?MTID=mc596baf62b263e8a7ced4831061a994d >> Audio conference information >> - Call-in toll number (US/Canada): 1-650-479-3208 >> - Access code:647 365 244 >> To add this meeting to your calendar program: >> https://ietf.webex.co/ietf/j.php?MTID=ma0d75a19ae69ce587599dcb25dc48d04 >> >> ** OAuth Tutorial >> Presenter: Justin Richer >> Date: Thursday, February 27, 2014 >> Time: 1:00 pm, GMT Time (London, GMT) >> Meeting Number: 646 901 997 >> Meeting Password: justin >> Online meeting: >> https://ietf.webex.co/ietf/j.php?MTID=m51cdea08122259237c6193380a3ccdd4 >> Audio conference information: >> - Call-in toll number (US/Canada): 1-650-479-3208 >> - Access code:646 901 997 >> To add this meeting to your calendar program >> https://ietf.webex.co/ietf/j.php?MTID=m8bcee257eb3ab56e51c9b02c5b63b123 >> >> Ciao >> Hannes >> >> PS: I was told that the IETF Webex bridge does not offer other dial-in >> numbers. If you want to dial-in from remote please use Skype or some >> other VoIP tool to keep the costs at a reasonable level. >> >> >> >> ___ >> 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 > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAUTH Presentation Slides
Hi, If you have a slot to speak tomorrow and are using slides please make sure to send the slides to Hannes and I, preferably in PDF format. This way I can upload them before the meeting tomorrow morning. Thanks! -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question lengths in draft-sakimura-oauth-tcse-03
Brian Campbell writes: > I notice that code_verifier is defined as "high entropy cryptographic random > string of length less than 128 bytes" [1], which brought a few questions and > comments to mind. So here goes: > > Talking about the length of a string in terms of bytes is always potentially > confusing. Maybe characters would be an easier unit for people like me to wrap > their little brains around? It depends if it really is characters or bytes. For example there are many multi-byte UTF-8 characters, so if it really is bytes then saying characters is wrong because it could overflow. So let's make sure we know what we're talking about. Historically, if we're talking bytes the IETF often uses the phrase "octets". Would that be less confusing? > Why are we putting a length restriction on the code_verifier anyway? It seems > like it'd be more appropriate to restrict the length of the code_challenge > because that's the thing the AS will have to maintain somehow (store in a DB > or memory or encrypt into the code). Am I missing something here? > > Let me also say that I hadn't looked at this document since its early days in > draft -00 or -01 last summer but I like the changes and how it's been kept > pretty simple for the common use-case while still allowing for crypto agility/ > extension. Nice work! > > [1] http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03#section-3.3 -derek > _______ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Call for Agenda Items for IETF-92
HI, IETF-92 in Dallas is 50-some days away. If you feel you want agenda time to talk about a draft or topic please get your requests into the chairs. Thanks, -derek and hannes -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] [Fwd: oauth - Requested session has been scheduled for IETF 92]
FYI, -derek Original Message Subject: oauth - Requested session has been scheduled for IETF 92 From:"\"IETF Secretariat\"" Date:Fri, February 27, 2015 5:27 pm To: hannes.tschofe...@gmx.net Cc: oauth-...@tools.ietf.org hannes.tschofe...@gmx.net de...@ihtfp.com -- Dear Hannes Tschofenig, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. oauth Session 1 (2:00:00) Monday, Afternoon Session I 1300-1500 Room Name: Continental size: 90 - Request Information: - Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tls ace saag cfrg dice Second Priority: radext dime Special Requests: Please avoid conflict with sec area BoFs. - -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] WGLC for draft-ietf-oauth-proof-of-possession-01
Hi, I'd like to start a WGLC on draft-ietf-oauth-proof-of-possession-01. This will be a 2-week last call, so it will end on Tuesday, March 24 at 12 noon CDT. Keep in mind that the OAUTH meeting is Monday, March 23rd at 1300, so it would be BETTER if you could get your comments in before the meeting, but technically I need to keep the WGLC open until the 24th. Please send comments to the list. If you feel a comment cannot be sent to the list feel free to send it to the chairs privately and we can appropriately anonymize it for the list. Thanks! Only 13 days until our Dallas meeting. See you there! -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Request for slides for WG meeting
Hi, Can all speakers please send us your slides for the OAuth meeting. I'd prefer to receive them in PDF format. Please send them ASAP (and before lunch tomorrow). Thanks, -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Lunch (pre-)Meeting Monday
Hi, Hannes and I would like to have a lunch meeting before the OAUTH meeting to chat about various ongoing WG activities. If you're available and interested meet us at IETF Regstration at 11:30 and we'll find a place. I expect we'll leave by 11:35 so please be prompt. -derek and hannes -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] [Fwd: IPR Disclosure Kirsten Aldrich's Statement about IPR related to RFC 6749]
FYI, Just so you all are aware of this IPR filing. -derek Original Message Subject: IPR Disclosure Kirsten Aldrich's Statement about IPR related to RFC 6749 From:"IETF Secretariat" Date:Tue, March 24, 2015 11:28 am To: dick.ha...@gmail.com Cc: stephen.farr...@cs.tcd.ie kathleen.moriarty.i...@gmail.com hannes.tschofe...@gmx.net de...@ihtfp.com oauth@ietf.org ipr-annou...@ietf.org -- Dear Dick Hardt: An IPR disclosure that pertains to your RFC entitled "The OAuth 2.0 Authorization Framework" (RFC6749) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2561/). The title of the IPR disclosure is "Kirsten Aldrich's Statement about IPR related to RFC 6749" Thank you IETF Secretariat -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Review of draft-ietf-oauth-pop-architecture
Hi, In performing my shephard review of draft-ietf-oauth-pop-architecture I found one issue that was bugging me: you talk about target naming "too late" in the draft. I.e., as I was reading through section 3.1 about token reuse I think it doesn't have enough detail about how you would prevent server A asking the client for a token for a resource of server B, and then server A acting as the client for server B? I.e., how do you prevent server A acting as a MITM between the client and server B? (This is sort of the same question that resulted in TLS channel bindings). I know this target (scope) protection exists, and it's even discussed a bit later in the document but it's not even mentioned as a possible threat in 3.1, which seems like a glaring ommission. I'll create a more formal shephard review but I'd suggest some additional text to at least mention this threat in 3.1; you can provide a pointer to the protections then, too. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Chair volunteers
Hi everyone, Hannes Tschofenig writes: > On 03/21/2017 06:39 PM, Kathleen Moriarty wrote: >> A big thank you to Derek for his work in OAuth and we hope to have his >> continued participation in the working group! > > Big thanks to Derek for doing the job for such a long time. It has been > a pleasure to work with you! I must apologize for having effectively disappeared from the OAuth group; my current position has limited my ability to do IETF work, and lately I've had even less time to put in, and alas OAuth was a major casualty. I do plan to continue my involvement to the best of my ability. I encourage people to step up and volunteer to co-chair the group. > Ciao > Hannes -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] FW: Appsdir review of draft-ietf-oauth-v2-23
h...@inf.ed.ac.uk (Henry S. Thompson) writes: > Barry Leiba writes: > >>> OK, I now recognise a culture clash as the underlying point at issue, >>> so this spec. is the wrong place to address it. >> >> Ah... so if the issue is how IANA makes registry information >> available > > Precisely. > >> then please go to the "happiana" mailing list ( >> https://www.ietf.org/mailman/listinfo/happiana ) and see if you can >> work with Michelle and the other IANA folks on it. > > Indeed. I should have realised that that was the right level sooner: > as I said, thanks for your patience. If you need help coordinating with Michelle @ IANA I can help coordinate a meeting in Paris next week (assuming you are attending). > ht -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAUTH Report for IETF-83
Hi, OAUTH met earlier this afternoon in Afternoon Session I at 13h00 for a two hour session. After introducing ourselves and welcoming me to the working group we thanked Barry and Blaine for their service. Torsten spoke about draft-ietf-oauth-v2-threatmodel. This document has completed WG Last Call. Torsten has applied changes based on the Last Call Comments and has published a new revision. Barry promised to finish his PROTO Shepard review next week so we can send this document to the IESG. He promises to take Mike Thomas' issues from the list into account and make sure that everyone is happy. [ I'd like to extend a personal thank you to Barry for continuing his role as document shephard for this draft. -- derek ] Next, Mike Jones spoke about the Assertions, SAML2 Bearer, and URN-Sub-NS drafts. Except for one outstanding issue Mike believes these documents are ready for WGLC. Consensus in the room was to take these three docs to WGLC, which the chairs will do by the end of next week. The MAC Token draft has languished while time was spent working on the core document. Eran was not here, nor was he online, to talk about the status of the MAC Token draft. There were only a few people in the room interested in reviewing the draft, which was not a clear consensus of interest, even though this document does solve a problem that the bearer tokens cannot. The chairs will take it to the list to evaluate if there is enough interest to continue with this document. In a related note, this document (as well as the v2-bearer document) is not available off the tools page even though it has not expired. I have taken the action item to get that sorted out. Finally, we spent the majority of our time talking about rechartering based on the proposed charter sent to the list by Hannes a week or two ago. Consensus of the room was that there was enough interest to recharter based roughly on the proposed charter. There was also consensus to include Simple Web Discovery (in addition to, and separate from, Dynamic Client Registration), although we will need to work with the ADs to make sure it gets handled in the appropriate WG and Area. Moreover, it's important to make sure the appropriate applications area participants get involved in the SWD work. Hannes and I will revise the proposed charter and send it out to the WG for additional comments and feedback. Our goal is to send it to the IESG for approval on their April 26th telechat. This would hopefully result in approval on the May 10th chat, after public comment. We finished the meeting at 14h30. -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAUTH Report for IETF-83
Yes, you are missing the meeting we had yesterday where it was discussed to be added to the charter. -derek, WG Chair Sent from my HTC on the Now Network from Sprint! - Reply message - From: "Eran Hammer" Date: Fri, Mar 30, 2012 4:25 am Subject: [OAUTH-WG] OAUTH Report for IETF-83 To: "William Mills" , "Derek Atkins" , "s...@ietf.org" , "oauth@ietf.org" ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAUTH Report for IETF-83
Correct. SWD may or may not happen in this group. The important part is getting the right people in the same room to work on it. If that is here, great. If that is in its own group, that's great too. If it won't happen in another group and if people here are wanting it, then that would imply this is the right place. We can discuss whether SWD is needed, but there was certainly interest in the WG meeting yesterday. -derek Sent from my HTC on the Now Network from Sprint! - Reply message - From: "William Mills" Date: Fri, Mar 30, 2012 1:26 am Subject: [OAUTH-WG] OAUTH Report for IETF-83 To: "Eran Hammer" , "Derek Atkins" , "s...@ietf.org" , "oauth@ietf.org" ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Meeting Minutes - IETF#83
Also, FYI, the audio recording of the meeting is available here: http://www.ietf.org/audio/ietf83/ietf83-252a-20120329-1256-pm.mp3 -derek On Wed, April 4, 2012 12:01 pm, Hannes Tschofenig wrote: > Hey guys, > > Derek took notes during the meeting and I polished them a bit. > > Have a look at them and let us know if there is something missing: > http://www.ietf.org/proceedings/83/minutes/minutes-83-oauth.txt > > Ciao > Hannes & Derek > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)
Justin Richer writes:
> OK, but with SWD and discovery off the table, can this now be
> considered to be within that manageable number instead?
We wanted to keep the # of WG items to approximately 5. Once we finish
some of these items and get them off our plate we could roll new items
onto the plate, theoretically.
> -- Justin
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
"Murray S. Kucherawy" writes: > Thank you Stephen, I think. :-) > > So the discussion on apps-discuss now should be focused on which of the two > should be the basis for forward progress. I've placed both documents in > "Call for Adoption" state in the datatracker for appsawg. >From an OAUTH perspective I believe that we should help define the requirements of what this protocol needs to provide (be it webfinger, swd, or yadp (Yet Another Discovery Protocol) -- whatever it's named!) I think there are two main differerences between webfinger and swd: a) whole-document vs. individual attributes b) a perceived authorization model to control access to said attributes In particular I feel there are some specific security requirements that must be bet by the protocol, but I think it's easily accomplished by a small amount of text that effectively says: 1) requestors of the service should authenticate (or be treated as an anonymous user) 2) content returned must be dynamic and dependent on the authorization of the authenticated user. This leaves only the perceived issue of "whole document" vs "individual attribute". If a client ever wants more than one attribute then a whole document approach reduces the number of round trips. However if documents get large that could also affect performance. We might, then, need a way to specify which attributes are requested, but allow for a wildcard to return "everything I am authorized to see". > Let the games begin. Heh. Play ball! > -MSK > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Dynamic Client Registration
Eran Hammer writes: > All I was saying is that it would be better to postpone it until the > discovery layer, which this draft clearly relies upon, is a bit > clearer. I would be satisfied with a simple note stating that if the > discovery work at the APP area isn't complete, the WG may choose to > delay work on this document until ready. I don't feel that this is explicitly required, but I have no objection to making it clearer in the charter that the DCR is dependent on Discovery. Hannes? > EH -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
Paul, "Paul E. Jones" writes: > Tim, > > I do not agree that it's harmful. If I removed the WF discussion off the > table, I'm still having a hard time buying into everything you said in the > blog post. > > I implement various web services, largely for my own use. Usually, I > implement all of them in XML, JSON, plain text (attribute/value pairs), AND > JavaScript (for JSONP). For simple services, it's not hard. I do it > because I sometimes have different wants/desires on the client side. (For > more complex ones, I use XML.) As an individual (and not the chair of OAUTH) I believe that the server should be allowed, no encouraged, to support multiple formats for data retrieval. I also believe that clients should be allowed to choose only one. I am fine with JSON being Mandatory to Implement. I am NOT okay with making it the only one, and I am even less okay with mandating it is the ONLY one. I would say MUST JSON, MUST (or possibly SHOULD -- you can convince me either way) XML, and MAY for anything else that people feel stronly about (although I feel in 2012 XML and JSON are the two best). I also feel it is okay to say that a client MUST implement one of JSON or XML, and MAY implement more. Note that this is a replay of the historical "MUST Implement" versus "MUST Use" arguments. Just because the server MUST IMPLEMENT JSON and XML does not mean that a Client must use both (or even that a client must implement both). It is perfectly reasonable and generally acceptable to have a server that provides data in multiple formats whereas the client only supports a subset and specifies which format(s) are acceptable. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
Michael Thomas writes: > > Why not MUST ASN.1 while you're at it? JSON has won in case > you'all haven't noticed it. Well, now that you mention it... ;-) But seriously, we're basing this work on an RFC that was just release six months ago and it requires XML. Why be so quick to drop something we just published half a year ago? So maybe in 6 months we drop JSON and add the next big thing? Come on, Mike. I agree, we should definitely support JSON. But I also think we should support XML. The client can do what it wants, which is where want the light weight implementation. > Mike -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
Tim Bray writes: > There's a disconnect here. Mnot and I (at least) have argued that > there are very specific problems and costs associated with going > multi-format. I’ve heard lots of people say "Well, I support > multi-format” but I haven’t heard any specific responses explaining > why those costs and problems aren’t real, or why the benefits are > sufficiently great that we should just accept them. > > Mnot: JSON or XML: Just Decide > http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide > tbray: Case Study: Atom and/or JSON > http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1 > > Would this work better if I summarized the problems here inline in > this thread? It may be the pace that people’s IETF/email workflow is > such that they’re not able comfortably to consult external references? No, but I disagree with your conclusions. Indeed, I disagree with your problem statement. Just because the server supports multiple formats does NOT imply more work for the client. The client can request a specific format and never has to worry about the other, so it has NOT doubled the work on the other side. Let's take your rails example. Yes, it's simple for a rails server to output HTML, XML, JSON, and other formats. But no, this does NOT make it harder for the consumer of that content. The consumer can specifically ask for whatever format it wants! This means you can have a JSON-only client and it can interact 100% with your rails application using just JSON. It doesn't have to worry about receiving XML, because it will always get JSON. As for your abstract model issue.. Maybe Mike was right and we SHOULD use ASN.1! :-D Then we could have defined encodings to XML or JSON ;) > -Tim -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
Michael Thomas writes: > Derek Atkins wrote: >> Michael Thomas writes: >> >>> Why not MUST ASN.1 while you're at it? JSON has won in case >>> you'all haven't noticed it. >> >> Well, now that you mention it... ;-) >> >> But seriously, we're basing this work on an RFC that was just release >> six months ago and it requires XML. Why be so quick to drop something >> we just published half a year ago? So maybe in 6 months we drop JSON >> and add the next big thing? Come on, Mike. >> >> I agree, we should definitely support JSON. But I also think we should >> support XML. The client can do what it wants, which is where want the >> light weight implementation. > > I think you're probably misunderstanding me. I'm (I believe) with Tim > in saying "pick one". Just one. For clients and servers. And I'm only No, I'm not misunderstanding you, I know exactly what you are arguing for. And I'm agreeing with you that we must support JSON. However, I disagree that we should drop XML, especially considering 6415 requires XML and it was just released 6 months ago. I'm also saying that this is only a server-side requirement to support both. The client can choose to support only one based on its own requirements. If you already have an XML-based client, why force them to add JSON support? Similarly, if you already have a JSON-based client, why force them to add XML support? If you're writing a client, you can ignore XML and only play with JSON. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
Eran Hammer writes: > We've been kicking this can of silliness for months now because one > person refuses to move on even in the face of otherwise unanimous > consensus from the group. > > Chairs - Please take this ridiculous and never ending thread off list > and resolve it once and for all. Sure, I'll gladly stop the thread when the document is updated to actually mention all threats that someone has considered and brought to the group's attention. That *is* the point of a threats document, after all. In a threats document nothing should be implicit or assumed -- the reader does not have the advantage of our group's knowledge of the space or operational guidance. As a result, everything should be explicitly stated. Every threat that is brought to the attention of this gorup should be mentioned, explicitly, even if it's only a single sentence as part of a paragraph of "threats that fall outside the aforementioned assumptions" or "threats that have a simple workaround". -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
Eran Hammer writes: > There is a lot of history on this thread. I know. I have read it all. Frankly, I feel that Michael was treated poorly by the members of this group. > At the heart of it is a request from a working group member that the > specification makes it clear that OAuth does not protect against > malware and viruses, or other malicious software installed on the user > device. During the first (or second, I can't recall) run of this > debate, the chair *did* make a consensus call that the WG did not feel > this was an OAuth specific threat. The chair's proposed resolution at > the time was clearly too vague to close the issue and hence we are > still arguing about it. That's not exactly how I read the original request. One part I remember clearly was more a question about user interface and "protecting" the User<->AS request. I think this could've been handled by a simple statement that "protecting a device or end-user user interface is out of scope for OAUTH". There was also an issue about handling bad players in the system (e.g. a Bad Client player). As a security person I'm afraid I do have to agree with Michael here, a threats document cannot say that to counteract a bad player you need to have a good player. You need to either say that the protocol does not protect against a bad player, or you need to say how to protect against a bad player. There is nothing wrong saying that it doesn't protect against a bad player, but writing it off will definitely make you look less credible. > Adding the requested threat will make the document look less credible > for stating the obvious. I do not agree that any threat mentioned > should be listed. At some point, and we're almost there, you lose the > forest for the trees. And it looks credible to imply that OAUTH protects against all attacks including the kitchen-sink attack? Maybe it is obvious to you, but you've been knee deep in the protocol for years. It is not necessarily obvious to the next person who reads the drafts. Being honest about what OAUTH does (and more importantly does NOT) do is more credible than ignoring what might be obvious to some but not obvious to others. > And BTW, as a response to Michael's original comment, I have requested > that the threat of earthquakes will also be listed under UX > considerations to prevent a user from clicking 'Approve' during an > earthquake if it is too close to the 'Deny' button. Is my threat, > which is clearly valid (no matter how unlikely), going to be added as > well? Please don't, but I hope you see my point here. Many bad things > can happen to you while using OAuth. And you're worried about sounding credible by talking about bad players and being explicit about the scope of OAUTH protection on a client device? Following your suggestion, ad absurdium, why not talk about the threat of a meteor shower? Seriously, yes, there is a line that has to be drawn; clearly *I* needed to be more explicit about that. Yes, of course the threat has to actually apply, but dismissing a threat out of hand because you don't like it or you feel it will make you look less "credible" only makes you look less credible. > I don't care how this is resolved. At this point I don't mind the > threat being added just to close the issue. Sold. Thank you, Eran. > EH -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method
he > >> header - both methods have been documented in the drafts since the > >> beginning. Clearly from a practical point of view the implementers > >> have chosen to use the query parameter. " > >> > >> "I have read people proposing dropping it from the spec or pushing it > >> to an Appendix. I agree that the security issues need to be > >> documented and the architectural issues called out. I think dropping > >> it from the spec or pushing it to an appendix is a disservice to > >> implementers and sends a message that the IETF is not in touch with the > realities of the web." > >> > >> -- Mike > >> > >> -Original Message- > >> From: Julian Reschke [mailto:julian.resc...@gmx.de] > >> Sent: Wednesday, May 23, 2012 11:36 PM > >> To: Mike Jones > >> Cc: oauth@ietf.org; Mark Nottingham > >> Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about > >> Bearer URI Query Parameter method > >> > >> On 2012-05-18 09:15, Julian Reschke wrote: > >>> ... > >>> Did you consider to *also* move the whole section into an appendix, > >>> so that it's status is also reflected by the document structure? > >>> > >>> Best regards, Julian > >> > >> Hi, it would be awesome to see feedback on this (it has been > >> mentioned during IETF LC multiple times). > >> > >> Best regards, Julian > >> -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] On the OAuth Core Spec
Eran (and the rest of the OAuth WG), Hannes and I would like to apologize for what transpired last week with the publication of version 27 of the OAuth core specification. It was not our intention to get a document published behind your back, the goal was the get a document published in a more timely manner than it appeared you could provide. Coincidentally there was a communication breakdown where we had an expectation that your co-authors would keep you in the loop about what was going on. We clearly should have been more proactive in doing that ourselves instead of expecting others to do it for us. Moreover, I was not privy to any agreement that you may have had about being "sole editor", so I had no reason to believe that there would have been any particular issue with getting another version of the draft out when you were busy. So, we're sorry. We're also sorry we weren't more clear that we really did need to get a draft out. I'll be sure that Hannes and I are both more clear going forward when there are timely dependencies. Having said that, are you still willing and able to be the editor of this draft and see it to its conclusion and publication? If so, we will need to get another draft out by this Friday (June 15), and I suspect we'll need another draft that solves the encoding issue (brought up by the ABNF exercise), targeting Friday, June 29th. Do you think you can make these target dates (assuming that there is text for you to apply to the draft)? Thanks, and again, our apologies, -derek, co-chair -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Oauth 2 and discovery
Hi, On Tue, June 12, 2012 7:19 pm, William Mills wrote: > If endpoint discovery is to be via WebFinger (LRDD/XRD) we need there > relations defined for the OAuth endpoints I had that in > http://tools.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt section 7.3, > but I've ripped all the discover stuff out of there. > > This seems more appropriate in the OAuth 2 core spec, but it's really late > to put it there. Should it get added as part of the WF draft? As a > separate I-D with just the IANA registry items? I think it's a little late to add this to the core spec now. I would say that you should just write up a separate draft that has the IANA registry items and other ancillary data necessary. It could probably go through as an informational draft, too, and possibly even an individual submission. > -bill -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Change in editorship of OAuth Core Spec
Hi, Eran Hammer has decided to step down as Editor of the OAuth Core specification. I would like to personally thank Eran for all his years of hard work and effort to the draft as well as to the working group at large. Dick Hardt has agreed to take over the editor role to see the draft to completion. Thanks to Eran and Dick! -derek, for the chairs -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Meeting slot for the Vancouver IETF meeting requested
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-boun...@ietf.org [mailto:oauth-boun...@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 > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Remote Participation for Vancouver (was Re: Meeting slot for the Vancouver IETF meeting requested)
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-boun...@ietf.org >>> [mailto:oauth-boun...@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 >>> o
Re: [OAUTH-WG] A question on draft-ietf-oauth-v2-http-mac-01
Hannes Tschofenig writes: > Hi Zhou, > > here is the story. > > The Authorization Server gives an Access Token to the Client and the client > presents that Access Token to Resource Servers. > This has not changed in comparison to Bearer Tokens. > > However, in addition to just presenting the Access Token by the Client to the > Resource Server the Client also needs to compute a keyed message digest on > the access request to the protected resource. > > It needs a key to compute the keyed message digest. > > This key, called MAC key, is provided by the Authorization Server together > with the Access Token. > > What is not said in the document is how the Resource Server obtains the MAC > key from the Authorization Server. It is assumed to be shared somehow. It could even, theoretically, be included in the Access Token! > Hope that makes more sense. > > Ciao > Hannes -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01
Hi,
zhou.suj...@zte.com.cn writes:
> Hi, Hannes,
>
>> The Client and the Resource Server need to obtain this session key somehow.
>> Only two mechanisms exist:
>>
>> a) Key Transport
>> b) Key Agreement
>>
>> Here a key transport based mechanism is used and that's not uncommon.
> I have no doubt about that.
> My concern is may be there are some better ways to do proof-of-posession,
> or proof-of-knowledge of keys.
Keep in mind that this is a short-lived session key that's valid only
for this client<->RS Instance. The MAC Key is tied to the Access Token,
which is (hopefully!) tied to the client_id. The MAC key is a
throw-away key. Future access tokens would use *different* MAC Keys.
Please take a look at the Kerberos Authenticator for prior art that
explains how this works.
> For example, as I wrote in the review of draft-tschofenig-oauth-security-00:
> client send H(R) in token request to AS, AS includes the H(R) in the token,
> and client sends (token,R) to RS,
> RS can verify the access capablity by recalculating H(R) and checking access
> toekn,
> by feature of hash, RS can trust R provider,this method does not use
> pre-shared key between AS and RS.
Sure, this works for a single request. However it also means you need
to have the AS involved in *every* request because you cannot reuse R.
Another option would be:
AS sends an Access token, encrypted to the RS, and includes a MAC
Session Key (Kms). The Client can send the token, a Nonce (N), and N
encrypted with Kms ({N}Kms) to prove posession of Kms. Of course to
protect replay attacks the RS has to keep a cache of all Nonces used
under Kms.
>> > Since distributing shared keys between AS and RS is already a
>> cubersome work,
>> > sending key to client implies the key is only one time thing, that
>> will further increase the complexity.
>> >
>> An authentication and key exchange protocols is a complex thing.
>> No doubt about that.
>
> But Oauth is aimed at simple solutiion and better user experience.
> An AKE and be complex, but some AKE can be simpler than others, depending on
> requirements.
Do you have a particular use-case in mind?
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01
Hannes Tschofenig writes: > I am sure that we can come up with many different protocols; the area of key > agreement protocols isn't necessarily a new one. > > (What by the way is "H(R)" standing for?) I'm pretty sure he means Hash of R. E.g. you send the SHA-1 Hash of R as a commitment of R, and then later you send R. But see my previous message, because this *requires* the AS be involved in EVERY request. I don't think that's a reasonable architecture. Tokens should have a validity period and the client should be free to continually use the token without going back to the AS during that period. Otherwise the AS becomes a single point of failure and a bottleneck. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Planning for IETF 85
Hi, It's that time again, time to start planning for the next IETF. IETF 85 will take place in November in Atlanta, Georgia. I'd like to ask of all our document editors: 1) will you be attending? 2) how much time do you need to summerize the status of the document? Also, is there anyone who wants time on the agenda to talk about any another relevant topics? Thanks, -derek, co-chair -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] 答复: Re: 答复: Re: A question on draft-ietf-oauth-v2-http-mac-01
zhou.suj...@zte.com.cn writes:
>> Sure, this works for a single request. However it also means you need
>> to have the AS involved in *every* request because you cannot reuse R.
>> Another option would be:
>>
>> AS sends an Access token, encrypted to the RS, and includes a MAC
>> Session Key (Kms). The Client can send the token, a Nonce (N), and N
>> encrypted with Kms ({N}Kms) to prove posession of Kms. Of course to
>> protect replay attacks the RS has to keep a cache of all Nonces used
>> under Kms.
> Prove knowledge of key by encryption is not a good idea,as you
> mentioned, for having to keep a cache.
You only have to keep a cache for the validity of the token. In your
case you have to keep a cache forever, because the token could
theoretically be reused over and over with the same commitment and R
values. At best the caches are the same, but in both cases you have to
contain a cache. Therefore your statement above is invalid.
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] More reviewers of the OAuth Security draft?
Hi, This is a request for more reviews of the OAuth Security Draft. You can find it at http://datatracker.ietf.org/doc/draft-tschofenig-oauth-security/ Thanks! -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAUTH Conference Call Dec 14th, 2012 (was Re: OAuth WG Virtual Interim Meetings, 11 January 2013 & 21 January 2013)
FYI, We will also be holding a conference call on Friday, December 14th at 1pm EST. This call is not an official virtual interim meeting which means no decisions can be made, but it is a time where we plan to discuss progress and discuss any open issues. We will send out dial-in information ASAP. Thanks, -derek, wg co-chair IESG Secretary writes: > The OAuth Working Group will hold virtual interim meetings as follows: > > * 11th January 2013, 1pm EST > * 21st January 2013, 1pm EST > > Agenda and dial-in information will be posted on the OAuth mailing list > (http://www.ietf.org/mail-archive/web/oauth/current/maillist.html) prior > to the meetings. > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (3446)
Barry Leiba writes: >> Corrected Text >> -- >> Resource owners cannot revoke access to an individual third party without >> revoking access >> to all third parties, and must do so by changing their password. >> >> Notes >> - >> The text was originally "their" but changed to "the third party's" between >> the last draft and RFC. >> However, "their" means "resource owners'", not "the third party's". > > Yes, this appears to be a change the RFC Editor made that the authors > didn't notice in AUTH48. But the RFC Editor change it from "their" > because "their" wasn't clear. Changing it back to "their" won't help > that. I suggest editing the corrected text to "by changing the > resource owner's password" before marking this as Verified. Yep, I suggested that same change in a private email to Stephen, so I would prefer this modification. > Barry -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
