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
- [sipcore] draft-ietf-sipcore-digest-scheme commen… Olle E. Johansson
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Olle E. Johansson
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Olle E. Johansson
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Paul Kyzivat
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Rifaat Shekh-Yusef
- Re: [sipcore] draft-ietf-sipcore-digest-scheme co… Christer Holmberg