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

[Rifaat Shekh-Yusef <[e-mail]>]

Inline...

On Mon, May 20, 2019 at 1:40 AM Olle E. Johansson <[e-mail]> wrote:

>
>
> On 18 May 2019, at 20:37, Rifaat Shekh-Yusef <[e-mail]>
> wrote:
>
> Thanks Olle!
>
> See my replies below.
>
> Regards,
>  Rifaat
>
>
>
>
> On Fri, May 17, 2019 at 9:38 AM Olle E. Johansson <[e-mail]> 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
>
> So then I suggest we remove the statement that the -sess variants are not
> used with SIP.
>
>
>
>
>> 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?
>
> Should we allow that? Why would local policy enforce a downgrade?
>

This is meant to provide the client with the ability to decide on the
priority of the algorithm to use when the client supports more than one
strong algorithm.


>
>>
>> “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.
>
> Since this is a change from RFC 3261 we propably want clarify that for
> developers.
> I think that if we want to modify RFC7616 for SIP, we can. The question
> still
> stands - are we ready to change the way current auth works today in
> SIP/2.0. There’s
> a lot of implementations out there that will suddenly not be
> standard-following.
>
> I’m not saying it’s a bad thing, just that we have to understand the
> implication.
>
>
> Here is the following part of the quote:

          remain optional for clients and servers to receive.  *However,
          servers MUST always send a "qop" parameter in WWW-Authenticate
          and Proxy-Authenticate header field values.  If a client
          receives a "qop" parameter in a challenge header field, it
          MUST send the "qop" parameter in any resulting authorization
          header field.*


RFC3261 already requires the servers to include "qop" in the challenge and
requires the client to include the "qop" in the response.
The change is that the client must now send "qop" in the Authorize header
in the initial request, not only in response to a challenge.
Are you saying that clients do not do that today?




>
>
>
>> 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.
>
> But that is not part of the registry, so what happens if I somewhere in
> the future add Edvina-9042 to
> the registry? What’s the order then? This section just says what’s
> mandatory to implement but doesn’t
> say anything about priority or which one that is the “strongest” one.
>
> I like the idea of a prioritized list for developers with some “strength”
> weight but fail to find one
> in these documents.  There has to be some advice in some RFC somewhere.
> …at this point I can’t find anything out there.
>
>
I do not think that we need to explicitly prioritize the algorithms,
because every time you add new algorithm the priority will change.
It is up to the server to device on the priority based on the placement of
the algorithm in the response.

Regards,
 Rifaat



> Cheers,
> /O
>
>
>
>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>
>