Subject: Re: [http-auth] Draft Minutes Posted for IETF 89 - HTTP Digest

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 6 Apr 2014 08:17:44 -0400

Here is my reply to the Digest minutes:

> ***** 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

Will take the Preference field out of the registry.

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

Will remove the backward compatibility with RFC2069.

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

The current text requires the following calculations:

   Server: H( username | realm )
   Client:  H( H( username | realm ) | nonce)

If we require client to perform the same calculations done by the server,
H( username | realm ), that will reduce the load on the server as the
server can use that calculation to directly look up the user without any
further hashing operations.
Any thoughts?

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

I am not sure that I understand this comment. What is the problem with the
current approach?

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

Can we use the same text provided by Julian for the Basic scheme?

   "The only allowed value is "UTF-8", to be matched case-insensitively
   (see [RFC2978], Section 2.3).  It indicates that the server expects
   user name and password to be converted to Unicode Normalization Form
   C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
   using the UTF-8 character encoding scheme ([RFC3629])."

Regards,
 Rifaat

On Mon, Mar 31, 2014 at 5:47 PM, Matthew Lepinski
<[email-masked]>wrote:

> The draft minutes for the HTTPAUTH session have been posted to the
> proceedings tool.
>
> The draft minutes can be found here:
> http://www.ietf.org/proceedings/89/minutes/minutes-89-httpauth
>
> If you identify any corrections that need to be made in the minutes,
> please send them to the list.
>
> - Yoav and Matt
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>
>