HTTP-AUTH Working Group Meeting IETF 87 (Berlin) Wednesday, July 31. 13:00 - 15:00 ====================================== Chairs: Yoav Nir (ynir@checkpoint.com) Matt Lepinski (mlepinski.ietf@gmail.com) Chair Slides available at: http://www.ietf.org/proceedings/87/slides/slides-87-httpauth-0.pdf -- The cognizant Security Area Director (Sean Turner) has a strong preference for making the Basic and Digest Authentication drafts Standards Track (as opposed to experimental). The chairs will work with the authors to make this happen. -- The chairs will work with Barry Leiba and the authors of draft-ietf-httpauth-basicauth-enc and draft-ietf-httpauth-digest-encoding -- There was general support for the chair's proposal on the evaluation of experimental mechanisms, with minor revisions. The chairs will update the proposal and take it to the list. -- The chairs will work with the authors of the experimental documents to ensure their is ample working group discussion on leveraging commonalities betwen the documents. To facilitate such discussion, authors of experimental documents are encouraged to submit their next revisions well in advance of IETF 88 this fall. =========================== Raw Notes =========================== ***** Basic Encoding Update by Julian Reschke Slides: http://www.ietf.org/proceedings/87/slides/slides-87-httpauth-1.pdf -- Sean Turner[AD] - This should be Proposed Standard Barry Leiba[AD] - Gave thumbs up to Application Area review of this document -- Unicode Normalization : Getting from what is typed in to Unicode code points will require discussion -- Link to test cases in the slides Parsing for WWW-Authenticate in Mozilla is somewhat limited It would require a significant change to the parser to implement this spec -- Unicode normalization is not just for Basic, this is useful for other schemes as well Precis working group has a related presentation on Friday -- Paul Hoffman: Sean are you really willing to push to Proposed Standard something that will break Mozilla (popular browser) Paul misunderstood. He thought authentication fell over and died. -- The nice thing about the current proposal is that user agents (like Chrome) which already implement UTF-8, already implement the spec. Don't really need to change anything. ***** Digest Authentication by Rifaat Shekh-Yusef Slides: http://www.ietf.org/proceedings/87/slides/slides-87-httpauth-2.pdf -- Our intention here is to update an RFC not to deprecate. If you believe that we should deprecate (as opposed to update) we will need additional feedback -- Experiment: Browsers can handle multiple digest headers with different algorithms Chrome+IE gives precedence to Headers at the top Issue with IE: If it doesn't understand the top algorithm, it just gives up -- Julian Reschke: If there is something unclear about number of Authenticate headers in the HTTP scheme (Part 7) then we need to fix it ASAP (like next session/this week) -- Tony Hansen: 6234 RFC re-issue with SHA2-512/256 is forthcoming (Tony is working on it) ... this is the RFC with the C code -- Sean Turner[AD]: SHA-3 speed is an issue (discussed in SAAG) -- Tony Hansen: On 64-bit machines SHA2-512/256 is faster than SHA2 -- Paul Hoffman: What is the fallback if SHA2-256 fails? This is more of an issue for PKIX / SMIME, and they don't have an answer The high-value protocols will do the work for us Honestly, we don't know what a fallback will be When/IF SHA2-256 has significant problems, it will hit other people harder than us -- Internationalization: Allow for non-ASCII characters in A1 (the input to the hash function) -- For Digest, we expect that both server and client will send the 'charset' parameter (newly defined). For Basic, only he server is being asked to send -- Sean Turner[AD] says he wants them both to be standards track -- Yukata Oiwa: Do we need such a complex mechanism (like explanation)? We can do more with Digest because it is key value pairs Rifaat: I don't see the complexity -- Paul Hoffman: You are asking browser venders to do two different things -- Yaron Sheffer: Are we adding code that will never be exercised, sufficiently tested? -- Rifaat: Should we just align with Basic? Chairs will ask this on the list -- Brian Smith: Should we just get rid of Digest? Shouldn't we just get rid of it? Shouldn't we be storing passwords in a way that is incompatible with Digest? ***** Discussion of Experimental Evaluation Criteria [See Chair Slides: http://www.ietf.org/proceedings/87/slides/slides-87-httpauth-0.pdf] -- Paul Hoffman: I don't like that we hide assumptions in Security Consideration. This should be in the Introduction! This is a Design consideration, should be way up front. I don't like reference to "file". Should discuss "storage" instead. -- Stephen Farrell: This is mostly good. Let's not get too hung up. Yoav: This is not a checklist, it is guidance for reviewers. -- Wes Hardaker: Fundamental question should be - "Does it solve the problem, is it secure?" Are there too many things on your list? -- Barry Leiba[AD]: Charter says group will evaluate the proposals. This is consistent with the charter ***** Rest-Auth [Presenter Unable to Attend] -- See presentation in meeting materials -- Draft is forthcoming -- Julian: Syntax URL will need a parameter name -- Take questions/reviews to the list ***** HOBA by Stephen Farrell Slides: http://www.ietf.org/proceedings/87/slides/slides-87-httpauth-3.pdf -- See slides for open issues -- Yaron Sheffer: SHOULD use TLS isn't very helpful, people will decide whether to use TLS before they decide which Authentication mechanism for a resource -- Proxy Authentication Alexy Melnikov: Why be different. So far every scheme (Basic/Digest) works for proxy authentication -- Paul Hoffman: We will not be ready for WGLC at the -02 Our document attacked life-cycle more thoroughly than other documents We should decide as a working group whether this is something that we should address in each document. (Paul votes for not) Stephen: We should have a discussion on the list at some point about this But we should not hold stuff up for this Alexy: We should do this the same for all mechanisms Stephen: Disagree Alexy: This is a change to framework Stephen: We are not changing framework -- Yaron Sheffer: Need to expand more how this can used in a consumer environment Stephen: I am not sure if the experimental draft is the right place to do that Yaron: Seperately, the need for Mutual authentication, is something to think about -- Yutaka Oiwa: We should share between drafts as possible (e.g., channel binding to application) Chairs will kick-off thread as drafts mature ***** Mutual Authentication by Yukata Oiwa Slides: http://www.ietf.org/proceedings/87/slides/slides-87-httpauth-5.pdf -- Yoav Nir: Additional UI elements in Browser? Yutaka: We have implemented experimental UI Request on feedback on whether the experimental UI is useful -- Yoav Nir: Are we re-inventing EAP? (With regards to interface to key-provision facility) -- Jacob (from Tor): Channel binding? Will your authentication be tied to the certificate you see and sent together up the stream? What kind of attackers are you considering? Yukata: When used with TLS, makes use of the hash of the certificate f Yukata: Completely impossible to beat, since using public key cryptography -- Chairs will work with author to handle algorithm/crypto draft vs authentication/framework draft ***** SCRAM : Alexy Melnikov -- Yukata Oiwa: I think it is better to be repeated each time -- Yoav Nir: If you don't expect realm to change, then you should only send it on the first time Session ID should be sufficient If you repeat 'realm' then you need to specify error handling if it changes -- Yukata Oiwa: We are using Authentication-Info -- Julian Reschke: Now that HTTP spec is modular, it is easier to revise a small piece of the framework (e.g., Auth framework) later -- Paul Hoffman: We don't need to rush. We can take our time. If in the future Browser venders care about this work, we will have thought enough about these issues that we can adjust the framework at that time -- Tony Hansen: 'realm' is really an attribute of the user. And you don't repeat the user, then don't repeat 'realm' -- Julian Reschke: Suggestion: Make your SCRAM parameters HTTP parameters. ***** Open Mic -- Stephen Farrell: Rough timescale on having a discussion about commonality? Answer: Vancouver Authors will need to forward submit before Vancouver -- Jacob (Tor): This is my first IETF session ever I think it is very interesting to think about modern threat models I think most frameworks are garbage Most of them have been written by people who have never been targeting ... Jacob is giving a talk tonight at 8:00pm (email to SAAG list)