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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Sat, 25 May 2019 18:23 UTC

Return-Path: <rifaat.ietf@gmail.com>
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 D202F120086 for <sipcore@ietfa.amsl.com>; Sat, 25 May 2019 11:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hKydQbIeAcC9 for <sipcore@ietfa.amsl.com>; Sat, 25 May 2019 11:23:44 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92282120105 for <sipcore@ietf.org>; Sat, 25 May 2019 11:23:44 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id u186so18555305ith.0 for <sipcore@ietf.org>; Sat, 25 May 2019 11:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1ED5afLI9FQOmB3hYGnXMDwbeyLdU7nc/m0kGgAKso=; b=Z/yjXS50Lx5ONqiQYbBSgeHgdmSEePtXF3CTZI3oTeaicxpZ/kmQ5TGr7rddwlrvWx bRG8rbfAENB+6GE1UFLrwsmxkzAmKL5L130YNFWBzYyH3zb/wvwGt0vv9P/pyPU6zmVj OcP/JjrjhncVGy3JTbw68bqB+ywRx+k4ceIVpMj3qKpYVwGUYpNT2v9zJQlxVccyc2wg LilpCh5PP9wiFdiQO2VFkA3/j8wjXTasKSoborbeDjSHLhx/KpkOPusUT2e6dM9uNXNj ecaI/ci0qL4NIISnHJeVsA6NRNq3YPFwXXP4wA+YWZ3W4xNY3I/QQTikeCm5+nL0yjLh Hmmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1ED5afLI9FQOmB3hYGnXMDwbeyLdU7nc/m0kGgAKso=; b=Vxtv9SbVBq/vDD4NvfDmzzxLd2Blr26TYAVb8/UzKKQ9m5ZURSqlkUdDdPJfVZbbA8 s4cNITIWPUtYjNnms+cohpDv+frCRZN9NKl+8O2wVsWb1LBe7u8rYGPahMwDFT9bSh8l xRN+muyJvoLAmxmUrH5P4A8lMVOFwYaaD58fxQ9oRPzv+rpLwZLmtDMGPaIsMMoRzoXA gwk8sz/wubD0UxsYb+GCsy8A/KUDT4THps4pLtQuMlFOe5ID97G2Bdw/2pPphORY47ii hOphJN/szIs86y0uGaFfwuaL6gitSe7AizPSqo7KGvh2Sl3rP4UneEbE628p2xknUF4T 1dAA==
X-Gm-Message-State: APjAAAWxUiTHCzGqSwNTxgPWtDWvFYG9ktDkt3If7+QEviUVVHUXwyUb HWIKER14gJ/SOgRGNz+OK8YnCPGPl1kBiEgc1G8=
X-Google-Smtp-Source: APXvYqxDmfxaQvtoHTlSTkIWdcmhLyJA7JITbpgs2Hy5CWuETiSuGsNu8Y8F4y0DJ0dF9I5LpTbhHu67zoE7v+nU63I=
X-Received: by 2002:a24:19cd:: with SMTP id b196mr23921789itb.74.1558808623975; Sat, 25 May 2019 11:23:43 -0700 (PDT)
MIME-Version: 1.0
References: <DE595AFF-5DEA-4A32-8527-10B841D6C7C1@edvina.net> <CAGL6epLMHoneH6PNgeF5TgJhveh-xWeZSW6XQDBB2Gf5mS9eRQ@mail.gmail.com> <C1431DCD-C4DD-4BFA-9C5D-E4DFE7B0F2DA@edvina.net> <B4A08741-A092-480C-AE12-2DD25D7835D0@ericsson.com> <CAGL6epJTv+Dytk_VHNi4Sk0mimVj=cMqWR4u9uSg1q+RcUQJ_Q@mail.gmail.com> <98D9E38D-4EA3-4F55-B37D-5334FA42F362@ericsson.com> <CAGL6epL7y0jiOqBdt3UOkx31ueQofh-W8vPwjvOUZhHZsaDq3A@mail.gmail.com> <2BD32E4F-AA3F-4C61-BE9F-037353FA4083@ericsson.com> <CAGL6ep+F4Wj6uQMyLttvRaTDmROg=J8__6nwkeCNHgJTR1db_A@mail.gmail.com> <74E1C0B9-8DBE-4301-998F-66A8329CB408@ericsson.com>
In-Reply-To: <74E1C0B9-8DBE-4301-998F-66A8329CB408@ericsson.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Sat, 25 May 2019 14:23:32 -0400
Message-ID: <CAGL6epJUBoFPWsdzYu6bKx9qVLr20btLDQ3R7DwpvxbD-CQ7dQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "Olle E. Johansson" <oej@edvina.net>, SIPCORE <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004e101c0589ba6aba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/6VX650nF4aA0yNGru3codK0UYLM>
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: Sat, 25 May 2019 18:23:47 -0000

On Sat, May 25, 2019 at 2:17 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> ...
>
> >>>>>> 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.
> >>>>
> >>>> RFC 3261 does not say anything about using the topmost header, does
> it?
> >>>>
> >>>> I was referring to this document.
> >>>
> >>> So, the should-use-topmost is something new, defined in this document?
> >>
> >> Yes, as per RFC7616.
> >
> > Perhaps then say "As defined in RFC7617,...."
> >
> > And, perhaps mention it in section 2, where the changes are listed.
> >
> > The normative text for SIP is specified in this document, so I do not
> see the need to add such a sentence.
>
> When we update an RFC, it is good to have an overview about what the
> updates are, so that people don't have to start reading 3261, 7617 and try
> to figure out themselves. They will obviously have to read the RFCs to
> figure out the details, but it helps if they know what the updates are
> about.
>

Section 2 is all about the changes introduced to the Digest mechanism.
If that is not sufficient, can you propose some text?


>
> Regards,
>
> Christer
>
>
>