For = convenience, I=92ve submitted tickets to cover the issues = raised: http://trac.tools.ietf.org/wg/httpauth/trac/query?component=3Dhoba

We=92ll leave it to the authors to work through = the LC comments, and whatever needs discussion can be covered here on = the mailing list, and if needed - in = Honolulu.

Thanks again to everyone for taking = the time to review this.

Yoav & = Matt

= --Apple-Mail=_63154DE3-40EC-46D7-A513-4757AFA9DA4A-- From nobody Mon Oct 6 06:22:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42F21A6F30 for ; Mon, 6 Oct 2014 06:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRbZTJH3RnbE for ; Mon, 6 Oct 2014 06:22:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EBC0B1A6F20 for ; Mon, 6 Oct 2014 06:22:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C582EBE01; Mon, 6 Oct 2014 14:22:09 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTBX38hZRpPD; Mon, 6 Oct 2014 14:22:09 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9BA50BDFF; Mon, 6 Oct 2014 14:22:09 +0100 (IST) Message-ID: <54329781.7040308@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:22:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Michael Sweet , Yoav Nir References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <8BBF035E-1E19-494B-AAFE-F43E0FE2D017@apple.com> In-Reply-To: <8BBF035E-1E19-494B-AAFE-F43E0FE2D017@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/SpNbhe2Bu2_fA0N84w5T3cCw3MQ Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:22:15 -0000 Hi Michael, Thanks for the detailed review. Reactions below and the changes I've made can be seen at [1]. (Note [1] has changes from all the various WGLC reviews. [2] is the diff vs. -04.) [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt I'll post the -05 once I figure we're closed out on WGLC comments or after a day or two's silence or as instructed by the chairs. On 22/09/14 23:26, Michael Sweet wrote: > Comments for: > > https://tools.ietf.org/html/draft-ietf-httpauth-hoba-04 > > - In section 1 (introduction), the following text is awkward to > read: > > Current HTTP authentication methods (Basic and Digest), as well as > username/password authentication using web forms, have been in use > for many years, but being based on passwords, are susceptible to > theft of server-side databases. > > The following is my suggested rewording: > > Current username/password authentication methods such as HTTP Basic, > HTTP Digest, and web forms have been in use for many years but are > susceptible to theft of server-side password databases. Done. > > - Also in section 1: > > Session management with HOBA is identical to username/password > session management. Typically, the session management tool (such as > PHP, Python CGI, and so on) inserts a session cookie into the output > to the browser. HOBA does nothing to help or hurt session cookie > hijacking; TLS is still required for that. If the authentication is > not bound to HTTP sessions, even TLS cannot help against all > attacks. > > might read better as: > > HOBA session management is identical to username/password session > management, with a server-side session management tool or script > inserting a session cookie into the output to the browser. HOBA > still requires TLS to prevent session cookie hijacking. Also done. > > - And here in section 1 aren't you talking about revoking keys? > > o Users are also likely to lose a private key, or the client's > memory of which key pair is associated with which origin, such as > when a user loses the computer or mobile device in which state is > stored. HOBA allows for clients to tell servers to delete the > association between an existing CPK and an account. Not really, but it's similar I suppose. The difference is that since HOBA is origin-bound, a UA just needs to tell one server about that public key so its more like a de-register rather than a revocation as would be the case with PGP or X.509. That said, we didn't actually define a de-register message so I've changed it thusly: OLD: HOBA allows for clients to tell servers to delete the association between an existing CPK and an account. NEW: HOBA implementations can, and probably ought, provide mechanisms for clients to tell servers to delete the association between an existing CPK and an account, but that will typically be done at the application layer and not using HOBA-defined messages. In case it helps, with my code I provide a way to associate a string with each UA for an account (e.g. "my ipad", "ff on laptop") and those (and the associated public key binding to the account on that origin) can be deleted, but that's just done using a form and has no HOBA-specific protocol. Not sure how much of that to include to be honest. I think the above NEW text should be ok for an experimental RFC. > > - This text in section 1 is also awkward/confusing: > > o Since there are always devices and applications in which state of > the art digital signature mechanism runtimes are significant, and > since HTTP authentication in theory requires that every HTTP request > to a given realm have a signature in an "Authorization" header field, > and since HOBA is a challenge response scheme, we also define a way > in which HTTP servers can indicate the duration for which they will > consider a given challenge value to be valid. As a consequence we > also define a way for UAs to fetch a fresh challenge. > > Perhaps reword as: > > o Digital signatures can be expensive to compute, so HOBA defines a > way for HTTP servers to indicate how long a given challenge value is > valid, and a way for UAs to fetch a fresh challenge at any time. Done. > > - Section 1.1, drop "in which this can be done" from the third line. Done. > - Section 1.2 is a mix of styles, Well, >1 author => >1 style:-) > consider making it "Term: > definition" throughout, and separate HOBA-js and HOBA-http. Fair point. Tried to do that. > - Section 1.2 is missing a reference to HTTP authentication > specification (which do you mean?) It's there later but I added another here to 7235. > > - Section 1.2: The statement "This specification uses the Augmented > Backus-Naur Form (ABNF) notation of [RFC5234]" probably doesn't > belong here, unless you want to define ABNF as a term (in which case > make it ABNF: definition [RFC5234]) I think its useful to have a ref to 5234 but don't think we need to define a term (we're not defining it anyway:-). I did move that para up to just below the 2119 reference which may help. > > - Figure 1: Shouldn't the unreserved values actually be base64url > values? > > - Figure 2: Ditto here - base64url encoded? Both are in the text, so its specified, but just not in the ABNF. I'm not sure if putting it there would really be of use though, but if someone wants to send me ABNF that does that and if nobody has a problem with it, I'd be ok with making that change. Personally, I prefer the ABNF as-is since I'm guess its more readable now than it would be should we try to define base64url encoded within the ABNF. > > - Section 3: If this is a valid security concern, change to "the > challenge MUST be unique for every HTTP 401 response ..." That'd be fine with my code but I forget if we had a specific reason for the SHOULD. I've made the change though since fewer SHOULDs is better. > > - Section 4, top of page 9: Something is missing betweem "from > HTML5." and "is used". Ah. The full stop shouldn't have been there;-) I also added a note about IndexedDB as an alternative to localStorage since the WebCrypto uses the latter. > > - Section 4, not sure I like the raw URL references - better to make > them informative or normative references (as appropriate). Also, > since WebCrypto is not available I'm not sure it is appropriate to > mention it here - maybe move this to an appendix that outlines some > potential future enhancements based on in-progress work. I've started implementing with WebCrypto so it is available now and shipping in chromium. I still have to turn it on via about:config with FF, but its mostly there too. I think it's better to leave that in. > > - Section 3: Is it ".well-known/hoba/getChal" or > ".well-known/hoba/getchal" (lowercase), as it appears in section > 6.4? Good catch. I've gone with getchal as that matches my code. > - Section 8: If reuse of challenge values (section 3) stays a SHOULD > NOT, then it should be added here in more detail as to why this can > be problematic. Fixed in section 3 now. > > - Section 9.4: Extra "i" after "ok." That's what I get for using vi:-) > > - Section 10: Don't deleted sections go at the end to make the RFC > Editor's job easier and to avoid broken references? That's not a problem for them since we'll give them the xml. Cheers, S. > > > >> On Sep 21, 2014, at 10:48 PM, Yoav Nir >> wrote: >> >> Hi all >> >> Stephen, Paul, and Michael submitted version -04 about a month ago, >> and it has received no discussion so far. The authors are of the >> opinion that the document is ready for publication, and it’s time >> for the group to weigh in on this subject. >> >> This mail begins working group last call for this document. Please >> take the time to read the draft and send comments to the list about >> its security, applicability, usefulness, and any other aspect you >> wish to discuss. For guidance on what to look for, let me quote the >> following from our charter: The httpauth WG will be a short-lived >> working group that will document a small number of HTTP user >> authentication schemes that might offer security benefits, and that >> could, following experimentation, be widely adopted as >> standards-track schemes for HTTP user authentication. Each of these >> RFCs will be Informational or Experimental, and should include a >> description of when use of its mechanism is appropriate, via a >> use-case or other distinguishing characteristics. >> >> The WGLC is two weeks long, and ends on October 6th. Please send >> your reviews as replies to this message. >> >> Thanks, >> >> Yoav & Matt _______________________________________________ >> http-auth mailing list http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > _________________________________________________________ Michael > Sweet, Senior Printing System Engineer, PWG Chair > > _______________________________________________ http-auth mailing > list http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Mon Oct 6 06:22:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF3F1A6F20 for ; Mon, 6 Oct 2014 06:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb-f2qwmxbeW for ; Mon, 6 Oct 2014 06:22:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BCE301A6F29 for ; Mon, 6 Oct 2014 06:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D637BE02; Mon, 6 Oct 2014 14:22:12 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZDEi48wL6St; Mon, 6 Oct 2014 14:22:12 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0B043BDFF; Mon, 6 Oct 2014 14:22:12 +0100 (IST) Message-ID: <54329784.1050709@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:22:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> In-Reply-To: <54211CFF.1040702@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/v9kN-_QyNahRNAEbaLsMkthZ7pU Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:22:16 -0000 Hi Julian, Thanks for the review. As before an updated version is at [1], diff at [2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt On 23/09/14 08:10, Julian Reschke wrote: > On 2014-09-22 07:48, Yoav Nir wrote: >> ... > > I had a look from an editorial and HTTP related angle (me no > security person): > > - it seems that the reference to RFC 7235 needs to be normative Done. > > - in the IANA sections, it would be helpful if the specification > links would be more specific Not sure what you mean there. I think "[[ this document ]]" is fine for IANA and the RFC editor if that's what you mean, but if you mean something else can you say? > > - there's a "TBD" in Section 9.3 oops fixed - deleted the comment. I also added a requirement that new entries here should already be used in some other IETF standard - don't see any reason why HOBA should be innovative in that respect. > > - for the new IANA registries, I believe you ought to specify the > actual format of the registry and/or provide a registration form I don't think that's needed here really. If HOBA gets enough use so that entries get added then I'd say that could be fixed when/if the spec gets put on the standards track and I'm sure there'd be more to fix then too. > > - terminology confusion: Section 2 introduces the "authentication > scheme" (which seems to be about HOBA in general), but the actual > HTTP authentication scheme is defined in Section 3. I think that's ok, happy to correct if others feel its confusing though (esp. if text changes suggested:-) > - TODO in Acknowledgements: "[[ and any more to be added ]]" Some more added now, I think I've added anyone who said something technical;-) > > Finally some comments on Section 3: > > This describes behavior, but reads a bit strange as a formal > definition of an auth scheme. For instance: > >> If the "HOBA" scheme is listed, it MUST be followed by two or more >> auth-param values. > > Replace by: > > "The HOBA scheme has two REQUIRED attributes (...) and one OPTIONAL > attribute (realm) described below:" Done. > > Also, a full HTTP request/response exchange example might make this > simpler to understand. I'll look at that later on, can probably generate it but don't have time today. Noted it in the XML source. Thanks again, S. > > Best regards, Julian > > _______________________________________________ http-auth mailing > list http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Mon Oct 6 06:22:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761E1A6F20 for ; Mon, 6 Oct 2014 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ7LPp5sykaU for ; Mon, 6 Oct 2014 06:22:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF11A6F2E for ; Mon, 6 Oct 2014 06:22:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 124DDBE07; Mon, 6 Oct 2014 14:22:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OK2SHDLXaXl; Mon, 6 Oct 2014 14:22:13 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DA4C7BDFF; Mon, 6 Oct 2014 14:22:13 +0100 (IST) Message-ID: <54329785.7090002@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:22:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> In-Reply-To: <54216016.4060800@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/pptnlxcG3pP5x0sYhDz7GtVpF0g Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:22:17 -0000 As before an updated version is at [1], diff at [2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt On 23/09/14 12:57, Julian Reschke wrote: > On 2014-09-23 09:10, Julian Reschke wrote: >> ... > > Furthermore, Section 9.6 tries to IANA-register the header field > "HOBAREG" which doesn't seem to be defined anywhere. Oops again. Added text to section 6.1 for that. (I added it late in response to Michael Sweet's good comment that something like that was needed:-) Just to check - in my code, once registration is successfully completed, I add a HOBAREG header to the "last" HTTP response that's part of registration with a value of "regok" but I think we just need the presence of the header so that's all the spec calls for right now. Happy to modify if folks think it better to do something else or if there's a better way to write that up. Cheers, S. > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Mon Oct 6 06:22:29 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFCA1A6F20 for ; Mon, 6 Oct 2014 06:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNnmfFNqiH6c for ; Mon, 6 Oct 2014 06:22:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BC4E41A6F2F for ; Mon, 6 Oct 2014 06:22:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 278B1BE01; Mon, 6 Oct 2014 14:22:15 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgIVd4WSMrtd; Mon, 6 Oct 2014 14:22:15 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07C52BDFF; Mon, 6 Oct 2014 14:22:15 +0100 (IST) Message-ID: <54329787.5050108@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:22:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <5422B0D7.6040905@gmx.de> In-Reply-To: <5422B0D7.6040905@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/93qc_zD3GwBjS2dHCB11VjakI44 Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:22:19 -0000 As before an updated version is at [1], diff at [2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt On 24/09/14 12:53, Julian Reschke wrote: > ...also: > >> o An "expires" attribute MUST be included that specifies the number >> of seconds from the time the HTTP response is emitted for which >> responses to this challenge can be accepted. > > HTTP caching (RFC 7235) knows the "Expires" header field (taking a > date), and the "max-age" cache-control directive (taking seconds). Maybe > it would make sense to rename this one to "max-age" for consistency. That sounds like a good change so I made that change to the spec and my code (the latter's not yet committed btw, will be later) Cheers, S. > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Mon Oct 6 06:28:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3011A6F57 for ; Mon, 6 Oct 2014 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WIdAp691wbu for ; Mon, 6 Oct 2014 06:28:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3831A6F40 for ; Mon, 6 Oct 2014 06:28:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C7374BE01; Mon, 6 Oct 2014 14:22:16 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnhxZ18Kot6f; Mon, 6 Oct 2014 14:22:16 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1436BDFF; Mon, 6 Oct 2014 14:22:16 +0100 (IST) Message-ID: <54329788.3080406@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:22:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: IETF HTTP Auth , Amos Jeffries References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <542114CF.3040204@treenet.co.nz> <99737F26-FC05-4570-9FB1-DD8ED1A8905E@gmail.com> In-Reply-To: <99737F26-FC05-4570-9FB1-DD8ED1A8905E@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DuSuWAitDaS4TWUHnIy0l2rw0h8 Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:28:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Amos, > Looks like the HTTP specific part is almost a duplicate of RFC > 6750 OAuth 2.0 Bearer authentication. Well, except that HOBA does not produce bearer tokens, as that term is usually understood - you need to use a private key to make one and each signature will be different. (It is true that with the max-age/expires parameter there is a server-defined window during which HOBA is not that different, but a server can set max-age to zero.) > > One could re-write this specification by doing: > > * reference Bearer specification, * add expires= and challenge= > (code=?) parameters on www-auth header, * add a scope parameter > value "hoba:origin", * prohibit token re-use/replay, * prohibit > URI-query and payload delivery mechanisms * define section 5 and > section 6 using RFC 6749 credential management parameters and > mechanisms. > > Doing so would avoid both the need to register a new > authentication scheme, and "well-known" URI space. I don't see that there's that much benefit in avoiding those registrations myself and do see a lot of downside in being entangled with oauth here. There's nothing wrong with oauth but I don't think HOBA and oauth need to be entangled that way. (When/if an oauth holder-of-key scheme is defined then that might look a lot like HOBA I guess but that's not yet defined I believe.) Also, in an offlist mail, Amos suggested that we look at the security considerations of 6750 since many of those might apply here (esp with max-age!=0). So I've added text saying: "When the max-age parameter is not zero, then a HOBA signature is very similar to a bearer token, as it can be replayed for a server-selected duration. Similarly, for HOBA-js, signatures might be replayable depending on the specific implementation. The security considerations of [RFC6750] therefore apply in any case where the HOBA signature can be replayed." Thanks for the review, Cheers, S. PS: As for the other WGLC mails, an updated version is at [1], diff at [2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt > > Amos >> > > _______________________________________________ http-auth mailing > list http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUMpeIAAoJEC88hzaAX42i49QH/34epelX3gJ6WPQFXFqRIv5c Y5GZtBvrqnaWNK68IkIsLm6jEHXljR94gdRHfWU5bWBWTIjHxWWNpzAolGsebDGU pQAWPnjy2qS0fGX59WS+BB66c1ES4dVsPLoKoe6Hh16mIOED85eFLvgxjukmQ7cd E9a0/fq7+HQSdOuMHHdJMWbf7C36c65/+6NxNzGgq7fiI/g9ySmUFcWKKCrX31L5 INc7+fS0BGl6TPKLBUQZ1nXzpLtRvatCyJYu/ZVeqedhKabB6hRLysOA8fncCSxr 9yDn86Toj6oO33Vxlp+5CpDPreiJl9DyPhMm+ale6SdodE/S8k1382e6VElGBFc= =UnEe -----END PGP SIGNATURE----- From nobody Mon Oct 6 06:28:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6811A6F40 for ; Mon, 6 Oct 2014 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ04C-UMn0NX for ; Mon, 6 Oct 2014 06:28:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9E11A6F42 for ; Mon, 6 Oct 2014 06:28:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AD02BBDFF; Mon, 6 Oct 2014 14:22:18 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndZOQWHrR-5C; Mon, 6 Oct 2014 14:22:18 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CD941BE02; Mon, 6 Oct 2014 14:22:17 +0100 (IST) Message-ID: <5432978A.4060805@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:22:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Benjamin Kaduk , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/y75UKY071YiX2v65xab_kPMdy6w Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:28:12 -0000 Hi Ben, Thanks for the comments. Responses below. As for the other WGLC mails, an updated version is at [1], diff at [2]. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt On 29/09/14 19:54, Benjamin Kaduk wrote: > On Mon, 22 Sep 2014, Yoav Nir wrote: > >> Hi all >> >> Stephen, Paul, and Michael submitted version -04 about a month ago, and >> it has received no discussion so far. The authors are of the opinion >> that the document is ready for publication, and it’s time for the group >> to weigh in on this subject. >> >> This mail begins working group last call for this document. Please take the time to read the draft and send comments to the list about its security, applicability, usefulness, and any other aspect you wish to discuss. For guidance on what to look for, let me quote the following from our charter: >> The httpauth WG will be a short-lived working group that will document >> a small number of HTTP user authentication schemes that might offer >> security benefits, and that could, following experimentation, be >> widely adopted as standards-track schemes for HTTP user >> authentication. Each of these RFCs will be Informational or >> Experimental, and should include a description of when use of its >> mechanism is appropriate, via a use-case or other distinguishing >> characteristics. >> The WGLC is two weeks long, and ends on October 6th. Please send your >> reviews as replies to this message. > > I see a few places that could be unclear, and have a handful of editorial > comments. > > > In section 2, > > On receipt of a challenge (and optional realm) from a server, the > client marshals an HOBA to-be-signed (TBS) blob that includes a > client generated nonce, the web-origin, the realm, an identifier for > the CPK and the challenge string; and signs that hashed blob with the > private key corresponding to the CPK for that web-origin. > > The client is supposed to marshal a blob, but then signs a hashed blob. > How does the hashing happen (or is it part of the signature)? Yes, its part of the signature, but you're correct, the text could be read to be doing two hashes I guess (as DKIM does, but HOBA does not), so I changed to just say "sign the blob." > > > Still in section 2, > > The value that is sent over the network is the HOBA "client result" > which we now define. > > It might be good to explicitly say that this is sent over the network by > the client. Added "by the UA" > > > In section 3, we hear that the HOBA scheme "MUST be followed by two or > more auth-param values." It might be useful to include here an example of > how those attributes are encoded. There's an example in Appendix B and I've an action to try make that a full HTTP request/response example as suggested by Julian. I'll do that but not today. I also added an example "max-age: 10" the challenge already says its base64url encoded. > > And the editorial bits: > > > In section 3, > > the client to authenticate with HOBA. Note that the HOBA auth-scheme > might not be the only one that the server includes in a WWW- > Authenticate. > > I think that "a WWW-Authenticate header" is better grammar, unless this is > some usage I'm not familiar with. Done > > > Still in section 3, > > When the "client response" is created, the UA encodes the HOBA > client-result (a string matching the HOBA-RES production in Figure 2 > as an auth-param with the name "result" and returns that in the > Authorization header. > > There is no matching close parenthesis. Fixed. > In section 4, > > storage. For example, an implementation would store a dictionary > account identifier, public key, private key tuples in the origin's > localStorage for subsequent authentication requests. > > I don't think the grammar is correct in the specification of the contents > of the tuples stored in localStorage. s/,/ and / once there fixed it. > Also in section 4, > > available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI). In > lieu of WebCrypto, JavaScript crypto libraries can be employed with > the known deficiencies of PRNG, and the general immaturity of those > libraries. Fixed. > > The grammar is not correct in this sentence. > > > In section 5.1, > > In the CPK preparation phase, the client determines if it already has > a CPK for the web-origin it is going to. > > Reading this, I want to ask "what is the client going to do?", that is, > the language feels informal to the point of causing confusion. Tweaked. > In section 9.3, > > TBD, hopefully re-use and existing registry > > s/and/an/ Fixed differently as a result of another comment. > > > In section 9.4, > > "1" means a URI, such as a mailto: or acct: URI, but anything > conforming to [RFC3986] is ok.i > > The trailing 'i' was already mentioned, but I would consider expanding out > "okay" or using less-informal terminology. Just a typo. Fixed. > Throughout section 9 in general, the list entries are inconsistent about > whether they end with a period or not. I constantly do that unfortunately:-) I think I fixed it so that those with sentences have a full stop and those that are not do not. Thanks, S. > > > -Ben > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nobody Mon Oct 6 06:30:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCAC1A6F34 for ; Mon, 6 Oct 2014 06:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOS6Y6En8l6A for ; Mon, 6 Oct 2014 06:30:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 54C921A6F1E for ; Mon, 6 Oct 2014 06:30:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBA4BBE01; Mon, 6 Oct 2014 14:30:05 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ZaHjKrs-SD; Mon, 6 Oct 2014 14:30:05 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9831CBDFF; Mon, 6 Oct 2014 14:30:05 +0100 (IST) Message-ID: <5432995D.6070408@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:30:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/iLHU69VdEd1YZ8XErNiakmmTx8k Cc: Amos Jeffries Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:30:08 -0000 Hi Yoav, On 06/10/14 09:04, Yoav Nir wrote: > Hi. > > This concludes WGLC for the HOBA draft. We’ve had quite a few > comments (thanks to Michael, Amos, Julian and Benjamin), most are > editorial, but at least Amos’s is substantial. > > For convenience, I’ve submitted tickets to cover the issues raised: > http://trac.tools.ietf.org/wg/httpauth/trac/query?component=hoba I think the batch of mails I just sent out cover all of those. Since I mostly took on board folks comments I hope we can close all of those after I post the -05 officially, but we'll see I guess. > We’ll leave it to the authors to work through the LC comments, and > whatever needs discussion can be covered here on the mailing list, > and if needed - in Honolulu. I'd hope we might not even need that f2f time if we're already done. > > Thanks again to everyone for taking the time to review this. Indeed, the reviews caught a few things and suggested some good improvements. Cheers, S. > > Yoav & Matt From nobody Mon Oct 6 06:39:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEC11A6F52 for ; Mon, 6 Oct 2014 06:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr4SJlZfQoh5 for ; Mon, 6 Oct 2014 06:39:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1481A033A for ; Mon, 6 Oct 2014 06:39:09 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MFuC6-1XOVRA0qMI-00ErgR; Mon, 06 Oct 2014 15:39:03 +0200 Message-ID: <54329B74.4020100@gmx.de> Date: Mon, 06 Oct 2014 15:39:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Farrell , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54329784.1050709@cs.tcd.ie> In-Reply-To: <54329784.1050709@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/4LN3jOfvY7tyRAURe9EdZqLWxvA6QRNc87HQEmjzQbgECczMv3 ExLloc0AFOQlq9aKiWWjSTNhZDCxJNwTi7OGlxwIRp8ViCGmNK15DQH+1d7WAT3yUs3HoY4 z1VXp01TcMOOTiqSJUI2zdG2dSlN0sbwgnUtQCxz4JXe5Aes/yq17ISXxf/Z7j62qGaOah2 9Ljtyg5abUcuj4KfUg0LQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/s12JSvOD3vLxECtdqOd8AC1YstM Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:39:11 -0000 On 2014-10-06 15:22, Stephen Farrell wrote: > ... >> - in the IANA sections, it would be helpful if the specification >> links would be more specific > > Not sure what you mean there. I think "[[ this document ]]" is > fine for IANA and the RFC editor if that's what you mean, but if > you mean something else can you say? I think it should state the specific section that thing being referenced is defined in. > ... >> - for the new IANA registries, I believe you ought to specify the >> actual format of the registry and/or provide a registration form > > I don't think that's needed here really. If HOBA gets enough use > so that entries get added then I'd say that could be fixed when/if > the spec gets put on the standards track and I'm sure there'd be > more to fix then too. > ... Well, at least you need to say what format the registry has; for instance, is the key a string? An integer? > ... Best regards, Julian From nobody Mon Oct 6 06:59:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89091A6F61 for ; Mon, 6 Oct 2014 06:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35-7tdx3wCqi for ; Mon, 6 Oct 2014 06:59:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 159201A6F49 for ; Mon, 6 Oct 2014 06:59:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DF91BE01; Mon, 6 Oct 2014 14:59:19 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbdZL6PcC-E3; Mon, 6 Oct 2014 14:59:19 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B3CDBE00; Mon, 6 Oct 2014 14:59:19 +0100 (IST) Message-ID: <5432A037.1010907@cs.tcd.ie> Date: Mon, 06 Oct 2014 14:59:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54329784.1050709@cs.tcd.ie> <54329B74.4020100@gmx.de> In-Reply-To: <54329B74.4020100@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/zxP95AG7bfptcEdTfGZFDqYpg4k Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 13:59:22 -0000 Hiya, On 06/10/14 14:39, Julian Reschke wrote: > On 2014-10-06 15:22, Stephen Farrell wrote: >> ... >>> - in the IANA sections, it would be helpful if the specification >>> links would be more specific >> >> Not sure what you mean there. I think "[[ this document ]]" is >> fine for IANA and the RFC editor if that's what you mean, but if >> you mean something else can you say? > > I think it should state the specific section that thing being referenced > is defined in. Fair enough. Done. > >> ... >>> - for the new IANA registries, I believe you ought to specify the >>> actual format of the registry and/or provide a registration form >> >> I don't think that's needed here really. If HOBA gets enough use >> so that entries get added then I'd say that could be fixed when/if >> the spec gets put on the standards track and I'm sure there'd be >> more to fix then too. >> ... > > Well, at least you need to say what format the registry has; for > instance, is the key a string? An integer? Ah gotcha. So you mean more like [1,2] are now? I can tart up the presentation before I post (if you've some example xml that'd be appreciated.) Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt > >> ... > > Best regards, Julian > > > From nobody Mon Oct 6 07:09:39 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBD91A6F88 for ; Mon, 6 Oct 2014 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.087 X-Spam-Level: X-Spam-Status: No, score=-7.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1pmJPw-YgNp for ; Mon, 6 Oct 2014 07:09:23 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556661A6F7E for ; Mon, 6 Oct 2014 07:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1412604561; x=2276518161; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iwWOi27XvegL6N1vr0NiIwyl9+JJ+68QO020H+apTAg=; b=hzw2CT7xyWokI57QhzkOb2FtqyQ3mF1u7qSe+ntrFcRD0TvaHLo7yuJSRCMpaKbY CTu0gg552VFck1Sh7t7Nv9OfiRdsJr6f4cjalR94rsYlKELUAQyd2fE9wJ8Q9evs 8PjxAdQb8xX4PJdgawDOU+02+YStFU9DBI5/cFXtdAnGt+pqbF/wRZvEjgKtHpqo gs4QXzwiupovYrrQaIKxBciIFjr0dok99cW+IujL98+iZi8/+ry9/d/+QAPM48iY uGMCNP7k5PjShXuNaiW07LNuJ9CUrUXc15AsugdsvwAF5kPi5zkiuwe+9yIuBzAm UsEYRu7OoGpZDDHLcVfxEA==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 89.4E.26497.192A2345; Mon, 6 Oct 2014 07:09:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0ND100GW30N2LJA0@local.mail-out.apple.com> for http-auth@ietf.org; Mon, 06 Oct 2014 07:09:21 -0700 (PDT) X-AuditID: 11973e11-f79f76d000006781-8e-5432a291c836 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 3F.67.30921.082A2345; Mon, 6 Oct 2014 07:09:04 -0700 (PDT) Received: from [17.153.96.192] (unknown [17.153.96.192]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0ND1005O70NJP650@spicerack.apple.com> for http-auth@ietf.org; Mon, 06 Oct 2014 07:09:21 -0700 (PDT) From: Michael Sweet In-reply-to: <54329781.7040308@cs.tcd.ie> Date: Mon, 06 Oct 2014 10:09:18 -0400 Message-id: <8E940011-3E25-4BDF-A8B3-9CF075A1C7D8@apple.com> References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <8BBF035E-1E19-494B-AAFE-F43E0FE2D017@apple.com> <54329781.7040308@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1988) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUiON3OWHfiIqMQg61TxC0+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGfLFjEXLJas+D/3KXMD4wLhLkZODgkBE4m3E3rZIWwxiQv3 1rN1MXJxCAnMYpK4e/wqG0iCV0BQ4sfkeyxdjBwczALyEgfPy4KEmQW0JL4/amWBqJ/JJLH4 5TtGmKF3Xt2GGjSZSeLs5rssIAmwqb/XpILYwgK2EqtWngWLswmoSfye1McKYnMKaEo8XrmC GcRmEVCV2NL8lBVim7vE0oaLLBAH2Uh0P7/ADDGzh1HizHx9EFtEQF9i7+ZzUN/ISkxZ8JQZ 5AgJgfesEk/6tzFPYBSZheShWQgPzULy0AJG5lWMQrmJmTm6mXlGeokFBTmpesn5uZsYIeEt uIPx+CqrQ4wCHIxKPLwROwxDhFgTy4orcw8xSnOwKInz/tXVDxESSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXA6Oxe9yxgzfcn1pv13y9qv/dNdFPRTy3TxIXTzi40c1N7khk0NfVl5f6CZemb fQo/bZlYtfDZ177AeWfv5e75o3W1IWGHAG/jTPYzXh4rvpjPCytY57OKd9feOfJP3vG+WvT0 301WnQy+9G1f7xx6OuuOWXZFxJIF1+9J32WwX8WS68+xj2H12RglluKMREMt5qLiRACscUhg UAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCsoduwyCjEYHMDu8WH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXvTGtaC85IVz5d8YGtgPCLcxcjJISFgInHn1W02CFtM4sK9 9UA2F4eQwGQmiaWLz4ElhARmMUn8XpMKYgsL2EqsWnmWBcTmFdCT2HDlKzuIzSygJbF+53Em EJtNQE3i96Q+VhCbU0BT4vHKFcwgNouAqsSW5qesEPXuEksbLrJA2NoST95dYIWYaSPR/fwC M8TeHkaJM/P1QWwRAX2JvZvPsUMcKisxZcFT5gmMArOQnDELyRmzkIxdwMi8ilGgKDUnsdJM L7GgICdVLzk/dxMjOPAKo3YwNiy3OsQowMGoxMMbscMwRIg1say4MvcQowQHs5IIr/k8oxAh 3pTEyqrUovz4otKc1OJDjNIcLErivCfu64YICaQnlqRmp6YWpBbBZJk4OKUaGF3SX8Vb/NyR Fpcb+kJE/q8cv6n8nxv5i3ZqqasnXTNe/OPKNIU3IckFB0zdCz7Pe9Zh8t8vfXrhzJuzZm6x eJbev8mgYYLq88ziiIdhF6pV7m/osZX/1eecPNHkWNL7A91u7/5a6b3nf2qwQp9xakYZc06T NvepmAdv4qIbpsalbau1XsEmo8RSnJFoqMVcVJwIAOXdh5E4AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/3tJe0Ifhl0UojrQAxBUJQA6x8eg Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:09:31 -0000 Stephen, Changes look good. A few follow-up comments below... > On Oct 6, 2014, at 9:22 AM, Stephen Farrell wrote: > ... > Not really, but it's similar I suppose. The difference is that since > HOBA is origin-bound, a UA just needs to tell one server about that > public key so its more like a de-register rather than a revocation as > would be the case with PGP or X.509. That said, we didn't actually > define a de-register message so I've changed it thusly: > > OLD: > > HOBA allows for clients to tell servers to delete the > association between an existing CPK and an account. > > NEW: > > HOBA implementations can, and probably ought, provide mechanisms > for clients to tell servers to delete the association between an > existing CPK and an account, but that will typically be done at > the application layer and not using HOBA-defined messages. > "and probably ought to" (add "to" on the end)? But regardless, if HOBA doesn't define a mechanism then how can you claim it supports it? Seems like you could define a well-known path for a POST that deletes the association on the server side, much as you already do for registration and challenges? > In case it helps, with my code I provide a way to associate a > string with each UA for an account (e.g. "my ipad", "ff on laptop") > and those (and the associated public key binding to the account > on that origin) can be deleted, but that's just done using a > form and has no HOBA-specific protocol. Not sure how much of that > to include to be honest. I think the above NEW text should be ok > for an experimental RFC. I think I'd feel more comfortable with either defining something or being up front about it not being defined after the list of things that HOBA does, e.g.: HOBA currently does not define a mechanism for deleting the association between an existing CPK and an account. Such a mechanism can be implemented at the application layer. (I almost want to add "and may be defined by a future version of this document", but I dislike prognostication in these kinds of documents...) > ... >> >> - Figure 1: Shouldn't the unreserved values actually be base64url >> values? >> >> - Figure 2: Ditto here - base64url encoded? > > Both are in the text, so its specified, but just not in the > ABNF. I'm not sure if putting it there would really be of > use though, but if someone wants to send me ABNF that does > that and if nobody has a problem with it, I'd be ok with > making that change. Personally, I prefer the ABNF as-is since > I'm guess its more readable now than it would be should we > try to define base64url encoded within the ABNF. This is fairly compact; values are just "1*base64urlchars": ; Characters for Base64URL encoding from Table 2 of RFC 4648 base64urlchars = %x30-39 ; Digits / %x41-5A ; Uppercase letters / %x61-7A ; Lowercase letters / "-" / "_" / "=" ; Special characters _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Mon Oct 6 07:19:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4811A0301 for ; Mon, 6 Oct 2014 07:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0Ey8ZYezgAU for ; Mon, 6 Oct 2014 07:19:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F4E1A02D7 for ; Mon, 6 Oct 2014 07:19:48 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LZmd6-1Y4fz72QHs-00lTxG; Mon, 06 Oct 2014 16:19:41 +0200 Message-ID: <5432A4F9.3010002@gmx.de> Date: Mon, 06 Oct 2014 16:19:37 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Farrell , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54329784.1050709@cs.tcd.ie> <54329B74.4020100@gmx.de> <5432A037.1010907@cs.tcd.ie> In-Reply-To: <5432A037.1010907@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:xDJ6ISU0i8cp+XZanhdqBJ1mnIhmcCdJ4qDtNxIJBJVK3KBfEcm NNx34+azS6RpDRIjNWKrwOE8T8uTKKrxecjDSwrRJPwwRBDmVXY8e14ATBFOa9uESV9H4vi zMxwhUNiz96MDqMwU51HOPUMD+7Q17X6iUwrf8bNY71pOe9nfMWAPyvVvXAd2j53cOzPZ1d 9GScJPLG2rI7TJMBaku4g== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/mv4qf6U2F2qieJkJ9GSlppJBjVA Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:19:50 -0000 On 2014-10-06 15:59, Stephen Farrell wrote: >... >>> ... >>>> - for the new IANA registries, I believe you ought to specify the >>>> actual format of the registry and/or provide a registration form >>> >>> I don't think that's needed here really. If HOBA gets enough use >>> so that entries get added then I'd say that could be fixed when/if >>> the spec gets put on the standards track and I'm sure there'd be >>> more to fix then too. >>> ... >> >> Well, at least you need to say what format the registry has; for >> instance, is the key a string? An integer? > > Ah gotcha. So you mean more like [1,2] are now? I can > tart up the presentation before I post (if you've some > example xml that'd be appreciated.) > ... Looks good to me. Best regards, Julian From nobody Mon Oct 6 07:42:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C451A6FB8 for ; Mon, 6 Oct 2014 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.786, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNXeHdG9-zoJ for ; Mon, 6 Oct 2014 07:42:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A4A571A6F2D for ; Mon, 6 Oct 2014 07:42:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 988F1BE08; Mon, 6 Oct 2014 15:42:51 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfk3xQhZqQ_j; Mon, 6 Oct 2014 15:42:51 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6DC99BE00; Mon, 6 Oct 2014 15:42:51 +0100 (IST) Message-ID: <5432AA6B.60907@cs.tcd.ie> Date: Mon, 06 Oct 2014 15:42:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Michael Sweet References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <8BBF035E-1E19-494B-AAFE-F43E0FE2D017@apple.com> <54329781.7040308@cs.tcd.ie> <8E940011-3E25-4BDF-A8B3-9CF075A1C7D8@apple.com> In-Reply-To: <8E940011-3E25-4BDF-A8B3-9CF075A1C7D8@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/XD5aV3T8l3wu19pgAzc5EYwatdY Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:42:57 -0000 Hiya, On 06/10/14 15:09, Michael Sweet wrote: > Stephen, > > Changes look good. A few follow-up comments below... > >> On Oct 6, 2014, at 9:22 AM, Stephen Farrell >> wrote: ... Not really, but it's similar >> I suppose. The difference is that since HOBA is origin-bound, a UA >> just needs to tell one server about that public key so its more >> like a de-register rather than a revocation as would be the case >> with PGP or X.509. That said, we didn't actually define a >> de-register message so I've changed it thusly: >> >> OLD: >> >> HOBA allows for clients to tell servers to delete the association >> between an existing CPK and an account. >> >> NEW: >> >> HOBA implementations can, and probably ought, provide mechanisms >> for clients to tell servers to delete the association between an >> existing CPK and an account, but that will typically be done at the >> application layer and not using HOBA-defined messages. >> > > "and probably ought to" (add "to" on the end)? Actually no, in my local flavour of Béarla [1], I think the text is correct, but the RFC editor will fix to their preferred taste anyway:-) [1] http://www.translate-irish.com/en/dictionary-irish-english/b%C3%A9arla > But regardless, if HOBA doesn't define a mechanism then how can you > claim it supports it? Right. I don't think we should claim it supports it, but that it allows implementations to. > Seems like you could define a well-known path > for a POST that deletes the association on the server side, much as > you already do for registration and challenges? Hmm. I don't think so really. We define a way to kick-off and end registration but not really how to do the "middle" bits which is where the meat of the work will be. I think de-registering is likely not something you'd do normally from the UA concerned. In my case, I provided an a/c management form [2] for that. [2] https://hoba.ie/account.html OTOH, I did actually do a .well-known like thing too in my code as it was handy for debugging - there's an un-register button on [3] so it'd not be hard to add if it was wanted. And I suppose if browsers did adopt HOBA (some hope:-) then having this could be good if a user wants to "forget" about a site. But since broswers are not interested for now, that's not a strong argument. And we could add it later. [3] https://hoba.ie/tech.html But I think [2] or similar makes more sense than [3] in real use so I'd still say that we should leave this out for now. >> In case it helps, with my code I provide a way to associate a >> string with each UA for an account (e.g. "my ipad", "ff on >> laptop") and those (and the associated public key binding to the >> account on that origin) can be deleted, but that's just done using >> a form and has no HOBA-specific protocol. Not sure how much of >> that to include to be honest. I think the above NEW text should be >> ok for an experimental RFC. > > I think I'd feel more comfortable with either defining something or > being up front about it not being defined after the list of things > that HOBA does, e.g.: > > HOBA currently does not define a mechanism for deleting the > association between an existing CPK and an account. Such a mechanism > can be implemented at the application layer. I've no problem putting that in. (So I did:-) > > (I almost want to add "and may be defined by a future version of this > document", but I dislike prognostication in these kinds of > documents...) > >> ... >>> >>> - Figure 1: Shouldn't the unreserved values actually be >>> base64url values? >>> >>> - Figure 2: Ditto here - base64url encoded? >> >> Both are in the text, so its specified, but just not in the ABNF. >> I'm not sure if putting it there would really be of use though, but >> if someone wants to send me ABNF that does that and if nobody has a >> problem with it, I'd be ok with making that change. Personally, I >> prefer the ABNF as-is since I'm guess its more readable now than it >> would be should we try to define base64url encoded within the >> ABNF. > > This is fairly compact; values are just "1*base64urlchars": > > ; Characters for Base64URL encoding from Table 2 of RFC 4648 > base64urlchars = %x30-39 ; Digits / %x41-5A ; > Uppercase letters / %x61-7A ; Lowercase letters / "-" / "_" > / "=" ; Special characters Ah, ok, added that too so. Be great if someone can check that that's ok. Also is unreserved correct for realm or something better? (Not sure, having checked 7235.) Usual -05-pre at [4], diff vs. -04 at [5] Cheers, S. [4] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [5] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt > > _________________________________________________________ Michael > Sweet, Senior Printing System Engineer, PWG Chair > > > From nobody Mon Oct 6 08:05:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1345A1A6FC0 for ; Mon, 6 Oct 2014 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWQqU0OYQhU0 for ; Mon, 6 Oct 2014 08:05:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF1D1A6FCF for ; Mon, 6 Oct 2014 08:05:06 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTkNU-1XjzZ140tk-00QUXZ; Mon, 06 Oct 2014 17:04:56 +0200 Message-ID: <5432AF95.9060905@gmx.de> Date: Mon, 06 Oct 2014 17:04:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Farrell , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <54329785.7090002@cs.tcd.ie> In-Reply-To: <54329785.7090002@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ff71QZ7fDHNN8xBlRne6KPS0EatLs1VVUTOwVHvD4g1GjDbFbkP toIZDec2bBLLeUDUtHI0aV0D27qXvROMcZyum+K+Aoks2sGBHod5CiT5an5TM21k2dE8wP/ S9+usV9YYeLhU3exBGfYBORIwg9QpbBdmFPSi8JDhovM8XHpMlzF8gWl0emare3EkvmfvdY O7dTYlOOcA/LprEw1A+aA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/WZvFeimfgza9o418hGj7sUeFTmc Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:05:09 -0000 On 2014-10-06 15:22, Stephen Farrell wrote: > > As before an updated version is at [1], diff at [2]. > > [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt > [2] > https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt > > On 23/09/14 12:57, Julian Reschke wrote: >> On 2014-09-23 09:10, Julian Reschke wrote: >>> ... >> >> Furthermore, Section 9.6 tries to IANA-register the header field >> "HOBAREG" which doesn't seem to be defined anywhere. > > Oops again. Added text to section 6.1 for that. (I added it > late in response to Michael Sweet's good comment that something > like that was needed:-) > > Just to check - in my code, once registration is successfully > completed, I add a HOBAREG header to the "last" HTTP response > that's part of registration with a value of "regok" but I think > we just need the presence of the header so that's all the spec > calls for right now. Happy to modify if folks think it better > to do something else or if there's a better way to write that > up. Wait. You can't just introduce a new HTTP header field (not HTTP header) in passing. If you need a new header field, please have a separate section with a precise definition of what it is about, and when writing that, please follow the guidance in . That being said; are you sure you need an additional header field? Best regards, Julian From nobody Mon Oct 6 08:13:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4661A01A5 for ; Mon, 6 Oct 2014 08:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJnQgH4F_KHD for ; Mon, 6 Oct 2014 08:13:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 957051A0163 for ; Mon, 6 Oct 2014 08:13:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D264FBE02; Mon, 6 Oct 2014 16:13:38 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLRkLk-dQpPH; Mon, 6 Oct 2014 16:13:38 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1277BE00; Mon, 6 Oct 2014 16:13:38 +0100 (IST) Message-ID: <5432B1A2.4070503@cs.tcd.ie> Date: Mon, 06 Oct 2014 16:13:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <54329785.7090002@cs.tcd.ie> <5432AF95.9060905@gmx.de> In-Reply-To: <5432AF95.9060905@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/KY9joHesEQ-RbI1I4ybGP3TgxBI Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:13:42 -0000 Hiya, On 06/10/14 16:04, Julian Reschke wrote: >> > > Wait. You can't just introduce a new HTTP header field (not HTTP > header) in passing. Heh, I figured the header (field) police would catch up with me at some point:-) And that's ok, better to do it right. Can you tell me the difference here between a HTTP header field and a HTTP header? > If you need a new header field, please have a separate section with > a precise definition of what it is about, and when writing that, > please follow the guidance in > . I'll look that over, but first... > > That being said; are you sure you need an additional header field? I *think* we do. The issue is that the UA needs to know when it can use HOBA which means it needs to know when it has succeeded in registration. And since registration can be a multiple-exchange application layer thing, we need a way to signal the successful end of that back to the UA. So the earlier discussion with Michael ended up with a header field that the server can put into the "last" HTTP response that was needed for successful registration. If there's a better/easier/more-correct way then to handle this then I'd be just fine with that too, whatever it is. Cheers, S. From nobody Mon Oct 6 08:32:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188BF1A02E1 for ; Mon, 6 Oct 2014 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgLyM5zBmMAs for ; Mon, 6 Oct 2014 08:32:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288C41A02DE for ; Mon, 6 Oct 2014 08:32:52 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6BKc-1YP8IJ28mg-00y5zV; Mon, 06 Oct 2014 17:32:45 +0200 Message-ID: <5432B61C.20704@gmx.de> Date: Mon, 06 Oct 2014 17:32:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Farrell , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <54329785.7090002@cs.tcd.ie> <5432AF95.9060905@gmx.de> <5432B1A2.4070503@cs.tcd.ie> In-Reply-To: <5432B1A2.4070503@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:a0i2guWM0j6T1sv0DOxG123ZrtTf4pLFmy5/6o4t/cYTPSOx1Cx xfMpR4L2Rk78G3aVfWMpognMuAAvhI5S1Epn2XqCS2WCxBvtRpZf50TglSLbM2ERKUe2nBY 1Q7OvSs62sqdK+jyMStIUqEgSYyJKRKLhcdgRuCgzjOeJadNkculg9iovThAd4stub7cG8A Y2jZ5mijvpDloZwCE/RDw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/JuZZBpQSmrYoXyQaZwISXbO4TFk Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:32:54 -0000 On 2014-10-06 17:13, Stephen Farrell wrote: > > Hiya, > > On 06/10/14 16:04, Julian Reschke wrote: >>> >> >> Wait. You can't just introduce a new HTTP header field (not HTTP >> header) in passing. > > Heh, I figured the header (field) police would catch up with me > at some point:-) And that's ok, better to do it right. > > Can you tell me the difference here between a HTTP header field > and a HTTP header? The former is the terminology we use in the HTTP specs. The latter I don't know :-) >> If you need a new header field, please have a separate section with >> a precise definition of what it is about, and when writing that, >> please follow the guidance in >> . > > I'll look that over, but first... > >> >> That being said; are you sure you need an additional header field? > > I *think* we do. The issue is that the UA needs to know when > it can use HOBA which means it needs to know when it has succeeded > in registration. And since registration can be a multiple-exchange > application layer thing, we need a way to signal the successful end > of that back to the UA. So the earlier discussion with Michael ended > up with a header field that the server can put into the "last" HTTP > response that was needed for successful registration. If there's a > better/easier/more-correct way then to handle this then I'd be just > fine with that too, whatever it is. > ... I believe it would be better not to return 2xx until authentication is finished; can't you just keep sending 403? Best regards, Julian From nobody Mon Oct 6 08:45:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5283C1A02EC for ; Mon, 6 Oct 2014 08:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu2CyVzrr9PF for ; Mon, 6 Oct 2014 08:45:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DCF251A02E4 for ; Mon, 6 Oct 2014 08:45:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5521BE07; Mon, 6 Oct 2014 16:45:40 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usdsdQ1Yk8ne; Mon, 6 Oct 2014 16:45:40 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9E9E7BE02; Mon, 6 Oct 2014 16:45:40 +0100 (IST) Message-ID: <5432B924.4@cs.tcd.ie> Date: Mon, 06 Oct 2014 16:45:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Julian Reschke , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <54329785.7090002@cs.tcd.ie> <5432AF95.9060905@gmx.de> <5432B1A2.4070503@cs.tcd.ie> <5432B61C.20704@gmx.de> In-Reply-To: <5432B61C.20704@gmx.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DySbpsnUKtOPRLlGIGJzBYT4u84 Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:45:45 -0000 On 06/10/14 16:32, Julian Reschke wrote: >> >> I *think* we do. The issue is that the UA needs to know when it can >> use HOBA which means it needs to know when it has succeeded in >> registration. And since registration can be a multiple-exchange >> application layer thing, we need a way to signal the successful >> end of that back to the UA. So the earlier discussion with Michael >> ended up with a header field that the server can put into the >> "last" HTTP response that was needed for successful registration. >> If there's a better/easier/more-correct way then to handle this >> then I'd be just fine with that too, whatever it is. ... > > I believe it would be better not to return 2xx until authentication > is finished; can't you just keep sending 403? I don't think so. One of the (IMO) core ideas of HOBA is to better separate the handling of identifiers/identity-information from keying material and public keys. Any real account registration is where the former should be gathered, validated or whatever and is an application layer concern. While we can kick that off via a POST to .well-known/hoba/register we can't tell when its done based on the answer to that, because there could (and likely would) be all sorts of processes used to handle account creation that would I think need to get a 200 OK really. So, yeah, I think we need that. Anyway, I've taken a stab at adding the section concerned. Would really appreciate it if you could take a peek at the new 6.1.1 in [1] (diff vs. -04 at [2] as usual.) Thanks, S. [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt [2] https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-04.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-05.txt From jason.greene@redhat.com Mon Oct 6 08:46:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB481A02EC for ; Mon, 6 Oct 2014 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xy60Y_offZ0 for ; Mon, 6 Oct 2014 08:46:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765761A6FDD for ; Mon, 6 Oct 2014 08:46:34 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s96FkXO9001621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 6 Oct 2014 11:46:34 -0400 Received: from [10.10.61.176] (vpn-61-176.rdu2.redhat.com [10.10.61.176]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s96FkWjU023251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 6 Oct 2014 11:46:33 -0400 From: Jason Greene Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <578F9F37-D924-4DD9-B355-297438019B10@redhat.com> Date: Mon, 6 Oct 2014 10:46:30 -0500 To: IETF HTTP Auth Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/kPc2ClylvDd-aUwSwx8DnFhB9ns Subject: [http-auth] User directed logout X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:49:41 -0000 I noticed a statement in reviewing the new mutual auth RFC: "If a user explicitly requests to log out (via user interfaces), the client MUST forget the user's password, go to step 5 and reload the current resource without an authentication header." This reminded me of a long standing issue with browser based = authentication, in that brittle and browser specific hacks are required = to get them to stop caching credentials in the case that a web = application wishes to provide a =93log out=94 feature. Has there been any consideration to resolving this in auth protocols = (e.g. a user directed termination indicator of some sort)? I think this = could be a good thing. Otherwise I don=92t see how the above text could = actually be implemented? -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From nobody Mon Oct 6 08:57:06 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF3B1A0351 for ; Mon, 6 Oct 2014 08:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDXTgInj55P4 for ; Mon, 6 Oct 2014 08:56:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AC41A6FDE for ; Mon, 6 Oct 2014 08:56:50 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MVayZ-1XibZY3drb-00YxRi; Mon, 06 Oct 2014 17:56:48 +0200 Message-ID: <5432BBBD.9080209@gmx.de> Date: Mon, 06 Oct 2014 17:56:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Farrell , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <54329785.7090002@cs.tcd.ie> <5432AF95.9060905@gmx.de> <5432B1A2.4070503@cs.tcd.ie> <5432B61C.20704@gmx.de> <5432B924.4@cs.tcd.ie> In-Reply-To: <5432B924.4@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:TsFzHRn5K5czW90Fai/YV4MgwsrXvIAwMwF0Hn3zOoORMEmQ+dJ l4ZTrUTkF8C0zqVJfpEDntHlSXluI16x5A+fiO4EpUjK5pPj9kxMWRUkjNDcJh4IGjnvAX6 93rM1E+BAuFeV1JHFe3eNPRcIurACTzZ7TlxQGN9sOPDPI4QpCj4DndJxTADhQOoN7Hv8f0 NDrU/AsHyfRYKkRwALjXQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/sWVoGY1o5CHaY2QSyeulO_rkNnQ Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:57:05 -0000 On 2014-10-06 17:45, Stephen Farrell wrote: > ... > I don't think so. One of the (IMO) core ideas of HOBA is to > better separate the handling of identifiers/identity-information > from keying material and public keys. Any real account registration > is where the former should be gathered, validated or whatever and > is an application layer concern. While we can kick that off via a > POST to .well-known/hoba/register we can't tell when its done based > on the answer to that, because there could (and likely would) be > all sorts of processes used to handle account creation that would > I think need to get a 200 OK really. So, yeah, I think we need that. > ... Why would these need a 200? Anyway, I think this kind of shows that it would be good if the document actually contained a complete example of the message flow it's trying to describe. > Anyway, I've taken a stab at adding the section concerned. Would > really appreciate it if you could take a peek at the new 6.1.1 > in [1] (diff vs. -04 at [2] as usual.) > ... > HOBAREG-val = "reg-ok" | "in-work" > > Figure 3: HOBAREG Header Field Definition It's "/", not "|". Are the values meant to be case-insensitive? The ABNF says yes. (BTW there's also a mismatch with the values in prose). I'd also spell it "Hobareg"; field names are case-insensitive, but we usually uppercase only the starting characters in documentation. > Section 8.3.1 of [RFC7231] calls for documenting the following > details for this new header field: > > o Only one single value is allowed in a HOBAREG header field. > Should more than one (a list) be encountered, that should be > interpreted as being the same as "in-work." > > o The HOBAREG header field can only be used in HTTP responses. > > o Since HOBAREG is only meant for responses it ought not appear in a > PUT request. True. Just state once it's a response header field only, then you don't need to mention that here. > o The HTTP response code does affect the interpretation of HOBAREG. > Registration is only considered to have succeeded if the reg-ok > value is seen in a 2xx response. 4xx and other errors means that > registration has failed regardless of the value of HOBAREG seen. > The request method has no influence on the interpretation of > HOBAREG. > > o Intermediaries should never insert, delete or modify a HOBAREG > header field. > > o It is not appropriate to list a HOBAREG in a Vary response header > field. Why? > o HOBAREG is not allowed in trailers Why? > o HOBAREG should not be preserved across re-directs. ...follows from being a response header field. > o HOBAREG itself discloses little security or privacy sensitive > information. If an attacker can somehow detect that a HOBAREG > header field is being added, then that attacker would know that > the UA is in the process of registration which could be > significant. However, it is likely that the set of messages > between the UA and server would expose this information in many > cases, regardless of whether or not TLS is used. Using TLS is > still however a good plan. Best regards, Julian From nobody Mon Oct 6 08:58:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752BF1A0351 for ; Mon, 6 Oct 2014 08:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ1Ygx241Pjd for ; Mon, 6 Oct 2014 08:58:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB4E1A6FF7 for ; Mon, 6 Oct 2014 08:58:12 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcSWg-1Y1wiW0DEE-00jpzn; Mon, 06 Oct 2014 17:58:06 +0200 Message-ID: <5432BC0D.7000607@gmx.de> Date: Mon, 06 Oct 2014 17:58:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stephen Farrell , Yoav Nir , IETF HTTP Auth References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <54211CFF.1040702@gmx.de> <54216016.4060800@gmx.de> <54329785.7090002@cs.tcd.ie> <5432AF95.9060905@gmx.de> <5432B1A2.4070503@cs.tcd.ie> <5432B61C.20704@gmx.de> <5432B924.4@cs.tcd.ie> <5432BBBD.9080209@gmx.de> In-Reply-To: <5432BBBD.9080209@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PPLQRO2tUVRQI2GstHbeimc1M2orOdaqIqMPXQXVMU1tOAJtD/u JZzNcmWGFfEmn0vBKsBDlh4DVFWMD1kqvvMycyVyjSzDCgqosDvvzii0qTefH22PuEqTwC8 HzWO5SmeaGeRiXLgOYsHinw3cMo605W0pRhz2nyXkdpAcbU/Ov4z91xsEtz3mO6EOTUTruQ zeRagh6MupMsOYEYPF3ug== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/_ntPbf5Sfpipums3zvj3Kc6efhc Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:58:14 -0000 On 2014-10-06 17:56, Julian Reschke wrote: > ... >> o It is not appropriate to list a HOBAREG in a Vary >> response header >> field. > > Why? > ... Replying to myself: because it's not a request header field. So...: just drop the considerations that apply to request header fields exclusively. From nobody Mon Oct 6 08:59:35 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2E61A032D for ; Mon, 6 Oct 2014 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zuxyRVpf1Qy for ; Mon, 6 Oct 2014 08:59:32 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CA01A02F6 for ; Mon, 6 Oct 2014 08:59:32 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id n3so5104087wiv.9 for ; Mon, 06 Oct 2014 08:59:31 -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; bh=Wptt/4YKRGPv9+/kK4CVcNBSdTdvli9eZ56RXclpjJU=; b=dLgIicToEwGSHL9WieBLIox7V5lRiicSwTOnVb0q4rpGZHpBg6nVk9YJTZl+EbKgM1 7XFGwapJfs+WjjsuvLQ9yij8VHYcMBF13PHvmQjYGKBT7jwBrtJwZlo6Aoyut1BoaM7Y 4Xb08mYwsOB6ddWKleKOKRwysjRWDnFXAwGP+XRKKt46VhwsRhqvL9l7qhZaIr6sOVgx C6akslNv7fWnM+Jtv4O3/ITJ9p1t5KbCe2r/3x8ghQAsxZs7gKqfFlc39wSLsHcZwOxR bfql80ZUz8KSPoLTtdVLrWajVO6B6EkeifQoNYbGRBShzpWqH/grWy22oVxU59CXZ0mV JWXg== X-Received: by 10.194.134.100 with SMTP id pj4mr31943883wjb.72.1412611170907; Mon, 06 Oct 2014 08:59:30 -0700 (PDT) Received: from yoavs-mbp.mshome.net ([95.35.51.128]) by mx.google.com with ESMTPSA id d6sm11759590wiz.0.2014.10.06.08.59.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 08:59:30 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <578F9F37-D924-4DD9-B355-297438019B10@redhat.com> Date: Mon, 6 Oct 2014 18:59:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <009C6C3A-FDB2-4CA3-95DD-4D01AD05CBD8@gmail.com> References: <578F9F37-D924-4DD9-B355-297438019B10@redhat.com> To: Jason Greene X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/CfdiEaK0NvxfnIePwVKXm1VQqn8 Cc: IETF HTTP Auth Subject: Re: [http-auth] User directed logout X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 15:59:33 -0000 On Oct 6, 2014, at 6:46 PM, Jason Greene = wrote: > I noticed a statement in reviewing the new mutual auth RFC: >=20 > "If a user explicitly requests to log out (via user interfaces), > the client MUST forget the user's password, go to step 5 and > reload the current resource without an authentication header." >=20 > This reminded me of a long standing issue with browser based = authentication, in that brittle and browser specific hacks are required = to get them to stop caching credentials in the case that a web = application wishes to provide a =93log out=94 feature. >=20 > Has there been any consideration to resolving this in auth protocols = (e.g. a user directed termination indicator of some sort)? I think this = could be a good thing. Otherwise I don=92t see how the above text could = actually be implemented? >=20 Hi, Jason. When web applications offer a log-out, there is no way for them to tell = the browser, because the browser=92s ability to cache previously-entered = passwords is at a different layer than the HTML or javascript code that = creates the web form. It may be possible to extend Javascript with an = API to do this, but that would be something for W3C to do.=20 MutualAuth is at the HTTP layer. A browser can=92t support it without = code changes. So the RFC can tell the browser vendor to delete the cache = in certain cases. If the browser password cache is an external = application or extension, it might not work. Yoav From nobody Mon Oct 6 09:12:54 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3F41A6FFE for ; Mon, 6 Oct 2014 09:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.087 X-Spam-Level: X-Spam-Status: No, score=-5.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i07DVFDWx3E for ; Mon, 6 Oct 2014 09:12:38 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3BC1A035D for ; Mon, 6 Oct 2014 09:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1412611954; x=2276525554; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/h8ShjArIA9GFEh6fxaVShiJ0GaDI5FVOWfDX3DmPug=; b=P7CDr6/6eUWH8xoU8R2ycluWR0CloiFp1Tq2lZi67JQgNBXRBi2j0scpHf3NOn1y wLL8d7QbCJQo7IXOsItImc8mwtgXUVImAW4PZS22+9in/Rh7iItS35ehpFWhYdn6 asPKFzUijhG5NtAIpDE/BcLHNYmDdmvNwzTQHE8/WrCJO0iMZzywoFfZY4tdeMmh ySaKgrkm3u00NFTB1QoX0wUtElPqchcmL82rreWNvZPyQb49d6+6qMNhZ+mfFtQ7 8fSZgv5n2LBfY/q19a7ymkqY8xNI6+jfefHeh6hpyT+iNw1/EaWHCrP7yLwZX5rM c51wVlZY46i3udY3KN6gMg==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 45.69.31401.27FB2345; Mon, 6 Oct 2014 09:12:34 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay4.apple.com ([17.128.113.87]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0ND100GZX6CML470@local.mail-out.apple.com> for http-auth@ietf.org; Mon, 06 Oct 2014 09:12:34 -0700 (PDT) X-AuditID: 11973e16-f793b6d000007aa9-27-5432bf725e87 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id B3.A4.03493.B7FB2345; Mon, 6 Oct 2014 09:12:43 -0700 (PDT) Received: from [17.153.96.192] (unknown [17.153.96.192]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0ND10005D6CXMR20@spicerack.apple.com> for http-auth@ietf.org; Mon, 06 Oct 2014 09:12:34 -0700 (PDT) From: Michael Sweet In-reply-to: <009C6C3A-FDB2-4CA3-95DD-4D01AD05CBD8@gmail.com> Date: Mon, 06 Oct 2014 12:12:32 -0400 Content-transfer-encoding: quoted-printable Message-id: References: <578F9F37-D924-4DD9-B355-297438019B10@redhat.com> <009C6C3A-FDB2-4CA3-95DD-4D01AD05CBD8@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1988) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUiON3OULdov1GIwaE1FhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvuNo8wF04QqLnydwNrAeJ+vi5GTQ0LAROLAxHdsELaYxIV7 64FsLg4hgVlMEtte7ANL8AoISvyYfI+li5GDg1lAT+L+RS2ImplMEjNW9bLBDNreeI4JIjGZ SeL93UcIk96vusIEUiUsoCvxdsVXMJtNQE3i96Q+VpCpnAK2Ev1H8kDCLAKqEpdaJoINZRbw l7j94SeUrS3x5N0FVoiDbCS+X1zDDtIqJFAgMeNkBEhYREBJ4vCVr8wQ98hKTFnwlBnkBAmB 96wSyz7NYpzAKDILyT+zEP6ZhWTDAkbmVYxCuYmZObqZeeZ6iQUFOal6yfm5mxghwS22g/Hh KqtDjAIcjEo8vBE7DEOEWBPLiitzDzFKc7AoifP+1dUPERJITyxJzU5NLUgtii8qzUktPsTI xMEp1cBoyLukL+X6wpcf/VbzSufbu1jG1Eg9XBHc9zpzSePhywsuyDyaY/Qx4sT5VasNQoV7 O7u29B/4uET91PVz723mC23dpiBZyyPIub723sJdraeVXCqzZKaURillNyVlMuwUfTK16V31 dY22Q/pzz6xZ0v7BearfX/36Aq/6jfr1tYd0nTMnBMQrsRRnJBpqMRcVJwIAfhA6BE8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FCsoVu93yjEYMEOcYsP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEro/3GUeaCaUIVF75OYG1gvM/XxcjJISFgIrG98RwThC0mceHe ejYQW0hgMpPEibWmXYxcQPYsJon3q66AFQkL6Eq8XfEVzOYV0JPYcOUrexcjBwczkH3/ohZI mE1ATeL3pD5WkDCngK1E/5E8kDCLgKrEpZaJYOOZBfwlbn/4CWVrSzx5d4EVYqKNxPeLa8Am CgkUSMw4GQESFhFQkjh85SszxJWyElMWPGWewCgwC8kNsxBumIVk6AJG5lWMAkWpOYmVJnqJ BQU5qXrJ+bmbGMEBVxi+g/HfMqtDjAIcjEo8vBE7DEOEWBPLiitzDzFKcDArifCazzMKEeJN SaysSi3Kjy8qzUktPsQozcGiJM778L5uiJBAemJJanZqakFqEUyWiYNTqoGR6/efG9umsqoZ n/FYtDy3dlEt+2GuHK1rvv5+OVeXll9OXC+TNW3nyy71k1xbox61BH2tmrem71G+XUHP7Mbn MvqmvxPywtZfeJzi8jSV6av23j6Hv7s9tzy4prRFa97z3ZtPOLy22nxfwE3U9fcNWxbTjIvF d/WD+Te5a5zf/CuKR+fd7MUaSizFGYmGWsxFxYkAZdPFmTQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/qctOcrY3w8bxIhFiTXUuO1z7Vt4 Cc: IETF HTTP Auth Subject: Re: [http-auth] User directed logout X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:12:50 -0000 FWIW, there are ways to prevent the password strings from being cached = by the browser in the first place (autocomplete attribute, Javascript, = etc.) and some OS's and browsers offer guest/privacy modes that will = discard everything after the window/session is closed. Not perfect, but = I suspect any solution will need to be defined at multiple levels to = cover all usage. > On Oct 6, 2014, at 11:59 AM, Yoav Nir wrote: >=20 >=20 > On Oct 6, 2014, at 6:46 PM, Jason Greene = wrote: >=20 >> I noticed a statement in reviewing the new mutual auth RFC: >>=20 >> "If a user explicitly requests to log out (via user interfaces), >> the client MUST forget the user's password, go to step 5 and >> reload the current resource without an authentication header." >>=20 >> This reminded me of a long standing issue with browser based = authentication, in that brittle and browser specific hacks are required = to get them to stop caching credentials in the case that a web = application wishes to provide a =93log out=94 feature. >>=20 >> Has there been any consideration to resolving this in auth protocols = (e.g. a user directed termination indicator of some sort)? I think this = could be a good thing. Otherwise I don=92t see how the above text could = actually be implemented? >>=20 >=20 > Hi, Jason. >=20 > When web applications offer a log-out, there is no way for them to = tell the browser, because the browser=92s ability to cache = previously-entered passwords is at a different layer than the HTML or = javascript code that creates the web form. It may be possible to extend = Javascript with an API to do this, but that would be something for W3C = to do.=20 >=20 > MutualAuth is at the HTTP layer. A browser can=92t support it without = code changes. So the RFC can tell the browser vendor to delete the cache = in certain cases. If the browser password cache is an external = application or extension, it might not work. >=20 > Yoav >=20 >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Mon Oct 6 09:13:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB12C1A6FDD for ; Mon, 6 Oct 2014 09:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqxLjbhChBs0 for ; Mon, 6 Oct 2014 09:12:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867FE1A6FEE for ; Mon, 6 Oct 2014 09:12:46 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s96GCiQA016253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 6 Oct 2014 12:12:44 -0400 Received: from [10.10.61.176] (vpn-61-176.rdu2.redhat.com [10.10.61.176]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s96GCgtJ032610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Oct 2014 12:12:44 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jason Greene In-Reply-To: <009C6C3A-FDB2-4CA3-95DD-4D01AD05CBD8@gmail.com> Date: Mon, 6 Oct 2014 11:12:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <443BBEA5-44DD-4CC7-85E9-58E295F2E558@redhat.com> References: <578F9F37-D924-4DD9-B355-297438019B10@redhat.com> <009C6C3A-FDB2-4CA3-95DD-4D01AD05CBD8@gmail.com> To: Yoav Nir X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/GS60mS_Eb7MpNJDoU9Yk1j4RwuQ Cc: IETF HTTP Auth Subject: Re: [http-auth] User directed logout X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:12:56 -0000 On Oct 6, 2014, at 10:59 AM, Yoav Nir wrote: >=20 > On Oct 6, 2014, at 6:46 PM, Jason Greene = wrote: >=20 >> I noticed a statement in reviewing the new mutual auth RFC: >>=20 >> "If a user explicitly requests to log out (via user interfaces), >> the client MUST forget the user's password, go to step 5 and >> reload the current resource without an authentication header." >>=20 >> This reminded me of a long standing issue with browser based = authentication, in that brittle and browser specific hacks are required = to get them to stop caching credentials in the case that a web = application wishes to provide a =93log out=94 feature. >>=20 >> Has there been any consideration to resolving this in auth protocols = (e.g. a user directed termination indicator of some sort)? I think this = could be a good thing. Otherwise I don=92t see how the above text could = actually be implemented? >>=20 >=20 > Hi, Jason. >=20 > When web applications offer a log-out, there is no way for them to = tell the browser, because the browser=92s ability to cache = previously-entered passwords is at a different layer than the HTML or = javascript code that creates the web form. It may be possible to extend = Javascript with an API to do this, but that would be something for W3C = to do.=20 That=92s true for a client side logout mechanism, but it can also be = server side in a similar a manner that applications can already control = cookies and web sessions. A server vendor could provide an auth log-out = call which would then cause the server, in an http response to include = some credential discard indicator. The client side JS/html portion would = then just perform an application specific POST to the server side code = which calls the method. This would also allow for certain server-side forced logout scenarios, = such as a requirement that a user always re-enter their credentials = after a set idle timeframe. >=20 > MutualAuth is at the HTTP layer. A browser can=92t support it without = code changes. So the RFC can tell the browser vendor to delete the cache = in certain cases. If the browser password cache is an external = application or extension, it might not work. I think, but am not totally sure my above reply would address this. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From nobody Mon Oct 6 09:27:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8FB1A0329 for ; Mon, 6 Oct 2014 09:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBXCb6UtIQ_V for ; Mon, 6 Oct 2014 09:27:09 -0700 (PDT) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id D0DAB1A0324 for ; Mon, 6 Oct 2014 09:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1412612827; d=isode.com; s=selector; i=@isode.com; bh=bmo4pwdtTIRNib5OCk5w7mIshWQMSM5BvBwGScZFWwo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=p6uBKseYn9ALaETBjXDd95AHdR/JwGNGUO+J2hHnVKS8viw2kn7Fbyp/ALe09Ni4xbny/n 0LfEZt9bURE2kBXCRzZDHU1xH+ZI0wz7kPODOmtsZO86z0k6850uR/KDqHhxH/iwnTR6zx LCikenKzM4LeEbqN46mciJCPqPmWRb4=; Received: from [172.20.1.74] (dhcp-74.isode.net [172.20.1.74]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 6 Oct 2014 17:27:07 +0100 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11D257) In-Reply-To: <54329781.7040308@cs.tcd.ie> Date: Mon, 6 Oct 2014 17:39:22 +0100 Message-Id: <018A44F4-EC49-436F-B073-230B0A222CB4@isode.com> References: <8A2A44BA-D6DC-4588-A456-0796208F4BBD@gmail.com> <8BBF035E-1E19-494B-AAFE-F43E0FE2D017@apple.com> <54329781.7040308@cs.tcd.ie> To: Stephen Farrell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/RVUf8rdYPSQr07oyglW-uZ7EkYA Cc: IETF HTTP Auth Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-hoba-04 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:27:11 -0000 Hi Stephen, On 6 Oct 2014, at 14:22, Stephen Farrell wrote: >> - Figure 1: Shouldn't the unreserved values actually be base64url >> values? >>=20 >> - Figure 2: Ditto here - base64url encoded? >=20 > Both are in the text, so its specified, but just not in the > ABNF. I'm not sure if putting it there would really be of > use though, but if someone wants to send me ABNF that does > that and if nobody has a problem with it, I'd be ok with > making that change. Personally, I prefer the ABNF as-is since > I'm guess its more readable now than it would be should we > try to define base64url encoded within the ABNF. You can use ABNF prose: base64url =3D This preserves clarity, while avoiding the need to work on specific syntax. I got confused by use of unreserved, just to discover later that a more spec= ific syntax is actually used in several places. From nobody Mon Oct 6 09:29:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613D51A7001 for ; Mon, 6 Oct 2014 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn26MpGDoYFi for ; Mon, 6 Oct 2014 09:29:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E5B1A6FF3 for ; Mon, 6 Oct 2014 09:28:56 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s96GSqbn022685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 6 Oct 2014 12:28:53 -0400 Received: from [10.10.61.176] (vpn-61-176.rdu2.redhat.com [10.10.61.176]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s96GSp3C015638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Oct 2014 12:28:52 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jason Greene In-Reply-To: Date: Mon, 6 Oct 2014 11:28:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <578F9F37-D924-4DD9-B355-297438019B10@redhat.com> <009C6C3A-FDB2-4CA3-95DD-4D01AD05CBD8@gmail.com> To: Michael Sweet X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/WVwN7aGdhTnWItNuWtPJMKuYHLw Cc: IETF HTTP Auth Subject: Re: [http-auth] User directed logout X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 16:29:13 -0000 The issue referring to is a different scenario. I am referring to = browser directed HTTP authentication (e.g. Basic & Digest today, mutual = auth tomorrow), whereas you are referring to application authentication = via form posting. So in this case there is no form, but a browser = controlled user password pop-up. These aggressively cache passwords, to = the extent that even a digest renogitiaton (due to nonce invalidation) = still reuses the cached password. Aside from the hacks (which typically = involve temporary switching of realms, or the evil user@fake-pass URL = trick), the only reliable mechanism is to require the user exit the = browser. However, as you know, browsers are very long running these days = (especially on a mobile device), and asking users to quit them is just = not a practical solution. =20 On Oct 6, 2014, at 11:12 AM, Michael Sweet