[sipcore] draft-ietf-sipcore-digest-scheme comments

["Olle E. Johansson" <[e-mail]>]

Hi!
Sorry to be late in this discussion.

" This document updates the Digest Access Authentication scheme used by
   the Session Initiation Protocol (SIP) to add support for secure
   digest algorithms to replace the broken MD5 algorithm.”

I would suggest changing “for secure” to “for more secure” to be a bit humble.
In XXX years, the schemes suggested here will be less secure than now.
The good thing is that we don’t have to update this document every time
IANA adds a new algorithm to the registry. :-)

section 2: "SHA- 256” - remove the extra space. Also, there’s an extra
quotation mark at the end of the section.

Section 2.1:

"Note that [RFC7616
] defines a -sess variant for each algorithm; the
   -sess variants are not used with SIP.”

Is this already forbidden in 3261 or is this new proposed language? If so, “are not” should propably
be something like “MUST not”

Section 2.2:

Is this an update to 7616 or just an explanation of 7616?

Section 2.4:

"When the UAC receives a response with multiple header fields with the
   same realm it SHOULD use the topmost header field that it supports,
   unless a local policy dictates otherwise.”

Why a SHOULD? I would prefer a MUST.

“When the UAC receives a 401 response with multiple WWW-Authenticate
   header fields with different realms it SHOULD retry and include an
   Authorization header field containing credentials that match the
   topmost header field of any one of the realms.”

If you are disallowing multiple Authorization headers for the same realm,
but with different algorithms I think this should be clearly written. In my
view, that would be a good thing.

 "8.  Servers MUST be able to properly handle "qop" parameter received
   in an authorization header field, and clients MUST be able to
   properly handle "qop" parameter received in WWW-Authenticate and
   Proxy-Authenticate header fields.  Servers MUST always send a "qop"
   parameter in WWW-Authenticate and Proxy-Authenticate header field
   values, and clients MUST send the "qop" parameter in any resulting
   authorization header field.”

This is not clear. If the servers MUST always send “qop” then we
add that to SIP 2.0 with no backwards options or compatibility.
Since you write “clients MUST be able to”… it seems like you
assume that clients have a choise of whether they use it. I think
one has to be a bit more clear so developers understands how
to modify their implementations.


In addition:
Are we ready to require that all SIP 2.0 compliant software support QOP?

I would like to run an online-SIPit when we have software that supports this
so we can test the behaviour, especially looking into downgrade attacks.

And as Dave said, I don’t see any priority in the IANA registry. RFC 7616 mentions
“strongest” algorithm. "A user agent MUST choose to use the strongest auth-scheme it
   understands and request credentials from the user based upon that
   challenge.” and then adds "When the server offers choices of authentication schemes using the
   WWW-Authenticate header field, the strength of the resulting
   authentication is only as good as that of the of the weakest of the
   authentication schemes.”

I don’t find any definition of “strong algorithm” in RFC 7616. 

Note that this document also suggests that UACs remember the “strongest”
algorithm used by a specific server/service and refuse a downgrade attack
- without discussing any implementation issues.


Good work. A small step forward!

Cheers,
/O