HTTP-AUTH Working Group Meeting
IETF 89 (London)
Monday, March 3, 2014. 15:20 - 17:30
======================================

Chairs:
Yoav Nir (ynir@checkpoint.com)
Matt Lepinski (mlepinski.ietf@gmail.com)

Chair Slides available at: 
http://www.ietf.org/proceedings/89/slides/slides-89-httpauth-0.pdf

-- The cognizant Security Area Director for HTTPAUTH is now Kathleen Moriarty.

-- The Digest and Basic update documents are nearing completion. The chairs hope to Working Group Last Call both of these documents around the time of IETF 90.

-- The consensus in the room at IETF 89 was to remove the preference field from the IANA registry in the Digest update document. More discussion is needed on the proposed username-hiding feature for Digest. In particular, more discussion of the impact of the proposal on server processing is needed.

-- Unicode normalization remains a challenge for the working group (at least for HTTP clients that take input from a keyboard). There was discussion related to both Basic and Digest regarding whether the group should use NFC for Normalization? or use the work coming out of Precis? Or use something else? If you have an opinion on the best way forward for Unicode Normalization, please take it to the list. 

-- The experimental drafts are not receiving enough review. Unless the following drafts begin to receive more discussion on the list, the chairs the Area Director will declare victory and close down the group after the Basic and Digest documents are completed.


===========================
Raw Notes
===========================

***** Digest Update by Rifaat Shekh-Yusef
draft-ietf-httpauth-digest-01
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-httpauth-2.pdf

-- Preference in the IANA registry

-- For "specification required" seems like a low-bar to set preference

-- Also, does preference need to change if we come up with attacks against an algorithm

-- Sean Turner (AD): Destroy Preference from the registry. Put preference into RFCs not registry

-- Question: Is backward compatibility (2069 RFC -- pre 2617) required?

-- Username hash was added for privacy reasons
   ... does the Server have the information it needs to look up the right entry from the password file?

-- Concern about DoS if the client can force server computation based on a simple query with an arbitrary garbage string

-- Resolution: We need more discussion about server processing and the trade off between privacy and performance

-- Do we need an optional parameter with only one value?
   If we are going to do UTF-8, document UTF-8 and don't put in the parameter 
 
   Chair: Need a flag to distinguish new UTF-8 digest from old digest
   
   Could we have a flag instead of a parameter? Compatibility with some existing spec (in another organization) used for the same purpose

-- Normalization
   Precis working group is just about finished. 
   Sean Turner (AD) says that work "Will" be used here
      ... Apps ADs will surely require us to use the new work from Precis

-- Precis chairs are Marc Blanchet and Yoshiro Yoneya

-- Julian: We need something that is implementable in reality. 

-- Username hiding also has an issue if different browsers encode non-UTF-8 differently
   Little Hope of server finding the right username 
     

***** Basic Update by Julian Reschke
draft-ietf-httpauth-basicauth-enc-03
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-httpauth-1.pdf

-- Mozilla Bug 656213 : Unicode Normalization

-- Ad hoc testing shows that UAs when using UTF-8 use UTF-8
   This is good

-- We will get a new version of this spec shortly after the meeting

-- No browsers actually enforce the fact that username cannot include a colon
   ... This is potentially an interop issue (and a security issue)
   We should include text on this in the new spec

-- The Colon issue affects Digest as well

-- Alexey Melnikov: Why don't we just require NFC or Precis, or whatever?

-- Sean Turner: Can we get the HTTPbis people to solve this?

-- Julian: Suggested a way forward documenting the issues and recommending UTF-8 with NFC
   Note: Normalization is ONLY an issue for UAs that take input from the keyboard
   If you take input from any other source then normalization is not an issue
   
-- Suggestion: Should Not / Must Not use colon ??

-- Everyone is on-board with the plan that will result in 2617 being obsoleted
   This includes both APP and SEC AD

-- Julian: We have security considerations in the Basic document
   If anyone wants to write more considerations they are welcome to send text

-- Deprecation of Basic and/or Digest is not in-scope


***** SCRAM by Alexey Melnikov
draft-ietf-httpath-scram-auth-00
Slides: http://www.ietf.org/proceedings/89/slides/slides-89-httpauth-3.pdf

-- Phil: If we are talking about protecting message bodies, we should do it elsewhere and not in the SCRAM authentication
     ... Do something like session-id

-- Comment: We just need to provide a binding for an upper-layer mechanism

-- Consensus: No, don't do hashing/protection of bodies