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

"Olle E. Johansson" <oej@edvina.net> Mon, 20 May 2019 05:40 UTC

Return-Path: <oej@edvina.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EFE120129 for <sipcore@ietfa.amsl.com>; Sun, 19 May 2019 22:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SraLnbjGOdSy for <sipcore@ietfa.amsl.com>; Sun, 19 May 2019 22:40:52 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18B6120041 for <sipcore@ietf.org>; Sun, 19 May 2019 22:40:50 -0700 (PDT)
Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id ED6C22E63; Mon, 20 May 2019 07:40:46 +0200 (CEST)
From: "Olle E. Johansson" <oej@edvina.net>
Message-Id: <C1431DCD-C4DD-4BFA-9C5D-E4DFE7B0F2DA@edvina.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_95652F9B-627F-4BBF-BB19-5FDC0589D1F5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 20 May 2019 07:40:46 +0200
In-Reply-To: <CAGL6epLMHoneH6PNgeF5TgJhveh-xWeZSW6XQDBB2Gf5mS9eRQ@mail.gmail.com>
Cc: Olle E Johansson <oej@edvina.net>, SIPCORE <sipcore@ietf.org>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
References: <DE595AFF-5DEA-4A32-8527-10B841D6C7C1@edvina.net> <CAGL6epLMHoneH6PNgeF5TgJhveh-xWeZSW6XQDBB2Gf5mS9eRQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/Hx79zfOp4kFBX2ShhlxwasQl53Y>
Subject: Re: [sipcore] draft-ietf-sipcore-digest-scheme comments
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2019 05:40:56 -0000


> On 18 May 2019, at 20:37, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
> 
> Thanks Olle!
> 
> See my replies below.
> 
> Regards,
>  Rifaat
> 
> 
> 
> 
> On Fri, May 17, 2019 at 9:38 AM Olle E. Johansson <oej@edvina.net <mailto: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
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?
>  
> 
> “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.
> 
> 
>  
> 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 <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.

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