Subject: [sipcore] Benjamin Kaduk's Yes on draft-ietf-sipcore-digest-scheme-10: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 28 Oct 2019 13:06:49 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-digest-scheme-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 28 Oct 2019 18:16:00 -0400

Thanks Ben!

I have just submitted a new version that addresses all the comments
received so far, including all your comments.
Please, take a look and let me know what you think.

Regards,
 Rifaat