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

Thanks Olle!

See my replies below.

Regards,
 Rifaat

On Fri, May 17, 2019 at 9:38 AM Olle E. Johansson <oej@edvina.net> wrote:

> 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. :-)
>

Ok

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

> 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”
>
> I do not think that 3261 forbids the -sess variant, and I do not see the
need to forbid it here either.

> Section 2.2:
>
> Is this an update to 7616 or just an explanation of 7616?
>

No update, just an explanation.

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

I can do that, but the last part of this paragraph states that local policy
can override this recommendations anyway.
So, does it make any difference?

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

This is allowed.

>
>  "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?
>
>
Here is a quote form RFC3261:

"Use of the "qop" parameter is optional in RFC 2617 for the purposes
of backwards compatibility with RFC 2069; since RFC 2543 was
based on RFC 2069, the "qop" parameter must unfortunately
remain optional for clients and servers to receive."

That is no longer the case with RFC7616.

> 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.
>
> Take a look at the security considerations section for more information
about downgrade attacks recommendations.

> 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.
>
> See section 3.7
https://tools.ietf.org/html/rfc7616#section-3.7

I will make it clearer.

> 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
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>