The Session Initiation Protocol (SIP) Digest Access Authentication Scheme
draft-ietf-sipcore-digest-scheme-15

Thanks for doing this.  I have some editorial comments, and one substantive suggestion that we state more strongly here what's said in 7616: that MD5 is NOT RECOMMENDED.

— Abstract —

   to replace the broken MD5 algorithm, which might be used
   for backward compatibility reasons only.

I suggest that the “, which…” part isn’t useful in the Abstract, and should be removed.  It's said in the Security Considerations, and we don't need to lead with it.

— Section 2 —

   It replaces the reference to [RFC2617] with a reference to [RFC7616]
   in [RFC3261], and describes the modifications to the usage of the
   Digest mechanism in [RFC3261] resulting from that reference update.

I had a hard time with this sentence.  Let me suggest this:

NEW
   It replaces the reference used in [RFC3261] for Digest Access
   Authentication, substituting [RFC7616] for the obsolete [RFC2617],
   and describes the modifications to the usage of the Digest
   mechanism in [RFC3261] resulting from that reference update.
END

— Section 2.1 —

   The IANA
   registry named "HTTP Digest Hash Algorithms" specifies the algorithms
   that correspond to 'algorithm' values.

That is not the name of the registry; it’s “Hash Algorithms for HTTP Digest Authentication” (which you correctly cite in other sections).

— Section 2.2 —

   If the MD5 algorithm is used to
   calculate the digest, then the digest will be represented as 32
   hexadecimal characters, SHA-256 and SHA-512/256 by 64 hexadecimal
   characters.

As we’re phasing out MD5, I suggest not using it as an example.  Just:

NEW
   If the SHA-256 or SHA-512/256 algorithm is used to
   calculate the digest, then the digest will be represented as 64
   hexadecimal characters.
END

— Section 2.4 —

   If the UAC cannot respond to any of the challenges in the response,
   then it SHOULD abandon attempts to send the request, e.g. if the UAC
   does not have credentials or has stale credentials for any of the
   realms, unless a local policy dictates otherwise.

This is really hard to parse; I think your “e.g.” clause gets in the way.  I suggest this:

NEW
   If the UAC cannot respond to any of the challenges in the response,
   then it SHOULD abandon attempts to send the request unless a local
   policy dictates otherwise.  For example, if the UAC does not have
   credentials or has stale credentials for any of the realms, the UAC
   will abandon the request.
END

— Section 2.5 —

   When the forking proxy places multiple WWW-Authenticate and Proxy-
   Authenticate header fields from one received response into the single
   response it MUST maintain the order of these header fields.  The
   ordering of values received from proxies relative to values received
   from other proxies is not significant.

I can’t make sense of this; can you try rephrasing it?  There’s one response and a single response.  I don’t follow.  There’s values received from proxies and values received from other proxies.  What’s the difference between “proxies” and “other proxies”?  I don’t follow.

— Section 3 —

   This specification adds new secure algorithms to be used with the
   Digest mechanism to authenticate users, but leaves the broken MD5
   algorithm for backward compatibility.

I recommend being stronger about this by using text from 7616:

NEW
   This specification adds new secure algorithms to be used with the
   Digest mechanism to authenticate users. The broken MD5 algorithm
   remains only for backward compatibility with [RFC2617], but its use is
   NOT RECOMMENDED.
END

Thanks for this document; it's always good to see ways to move off of md5.

The genart thread suggests that we are expecting a new rev of the doc?

I do have some comments, despite balloting Yes; please note especially
the comment on Section 2.6, which may reflect an error in the document.

Abstract

nit: comma after "e.g." (as well as before).

Section 2.1

   A UAS prioritizes which algorithm to use based on the ordering of the
   challenge header fields in the response it is processing.  That

nit: the UAS is *preparing* the response, not processing it, right?

Section 2.4

Why does the first paragraph get an exemption for local policy but the
second paragraph does not?

Section 2.6

   6.  [RFC7616] requires that a server check that the URI in the
   request line and the URI included in the Authorization header field
   point to the same resource.  In a SIP context, these two URIs may
   refer to different users, due to forwarding at some proxy.
   Therefore, in SIP, a UAS MAY check that the Request-URI in the
   Authorization/Proxy-Authorization header field value corresponds to a
   user for whom the UAS is willing to accept forwarded or direct
   requests, but it is not necessarily a failure if the two fields are
   not equivalent.

I think there's a subtle difference between what this says and what we want;
we still want a "MUST check" requirement (right?), but the nature of the
check changes, with default still being exact match but a "MAY" option for
the relaxed target-user check.

   8.  A UAS MUST be able to properly handle "qop" parameter received in
   an Authorization/Proxy-Authorization header field, and a UAC MUST be
   able to properly handle "qop" parameter received in WWW-Authenticate
   and Proxy-Authenticate header fields.  However, for backward
   compatibility reasons, the "qop" parameter is optional for
   RFC3261-based clients and servers to receive.

Should we remind people what the default is when it's not specified?