Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Mon, 04 November 2019 12:54 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 9FDE01200C3; Mon, 4 Nov 2019 04:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oJ-274H4xGlh; Mon, 4 Nov 2019 04:54:07 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 686DE1200B7; Mon, 4 Nov 2019 04:54:07 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id q1so18288175ion.1; Mon, 04 Nov 2019 04:54:07 -0800 (PST)
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=fgArjmSbySkzxvQvKcOLTWHHMwDZNDb9qrK2QuXX+Fc=; b=IJIUzb0+yqspEAp0RzboW6NCX4D0Ft7yQk+3DxV2UsxM7acig6Tr8Fo75O8ppC9COh NS0hgHGfBaiHZca3DCJ5eTt7AtTMG7NFsnBqH9aoek/nbigzooXVPok9LCZ0E/gGR38F VJGNQk1A8Tt12JBBqmYcky6vDFIAIbpuxDOpxwbhFoKW+fEQ5LhAFQpIKxQ69oqwdUuB myy5n31W6lVWW2k8kJbbzcTGqYJWI4ZuHzxDSjq1Rn23rOylqdiWP5i8t4dyxQ/XZS7R 3w1Q/ls1cA6TtoN2dn9II9/Tqk5g2Xjrc3HUsqAhKH3EFr6ApiSVgUn33UedGZUJmXDc GO9Q==
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=fgArjmSbySkzxvQvKcOLTWHHMwDZNDb9qrK2QuXX+Fc=; b=Cz6CmGj0Z3FkbmVK3CYqyqjYOtMXdxn2lvaYbBgmpOBsm7IZuiFmC3G2tQK61Yd9NC L3DK1VRJNY/tdCCQE+UrjhMnrVJQToNZDyDtgWi2SopDQc5yMNudePdAVTyZmSHzbUGg dP2ycGCVJLl08Nid5mZtCbMu4qbUl8P+KcnfT8JbZYGJw/drcnMP7Ea0MiM+geAhcXQu IrZQ13Fi/K95/Sayg1yz0j/rUk4iaB7L1Ad8KfVCDLuYlxWMuGrPCOtQArOnshPMu6HK RJXhHrcg7ceOoKBXGrOWe7KQocJgRxI3kap5fVtj8CsY0NyYPW5un1n+eSIXgn5o8khz 0pxQ==
X-Gm-Message-State: APjAAAXKhfL1XxUATAi68hs+1i/ulja8/DAhxWa5xY7t2+N2E2K/0zbx soRn9JhgjWOGPmkDzjsVpAUD7C9da3XlDxXigmU=
X-Google-Smtp-Source: APXvYqwwprnAQkXi9MBS93J9wNM5UJMh0pOgt3HnOON1a5SThrfMpQrVBku0wBJP7xj0wxsP/CG3qdzaQB0Vm/LCy3E=
X-Received: by 2002:a02:1c41:: with SMTP id c62mr19800321jac.132.1572872046672; Mon, 04 Nov 2019 04:54:06 -0800 (PST)
MIME-Version: 1.0
References: <157245577700.32490.10990766778571550817.idtracker@ietfa.amsl.com> <CAGL6epJgyr_VUYgKCgxDcP5ObKWErtDCHxaX7JusUYPXu=a6jQ@mail.gmail.com> <a9ebadcc-36ae-4bdb-af69-05486eef2569@www.fastmail.com> <CAGL6ep+AK4BuGZ2Y1RMsomAYGLiy2NbEHgm5-941FLVKS6bY9Q@mail.gmail.com> <6ec209ae-72e9-4dd1-8d68-3ee1704f3d92@www.fastmail.com> <CAGL6epLQS9xqHybZLTk1qM4i_LaDWVk8-iF0-0e_osf271R_Rg@mail.gmail.com> <7B4921E1-66A3-4D6D-A943-8EC0F44195CC@ericsson.com> <CAGL6epLrJYPaaYwFQjP8Lk3Uc3PUogtfPyxE5FsoTMJs3GvsgA@mail.gmail.com> <4C17F34D-7046-4706-AE5C-FB7ADC4B1427@ericsson.com> <4EEBC37C-3C1B-42A9-883B-571FAE867C31@ericsson.com> <CAGL6epLp=x+Z3g+BZAYsmOob1pkchnvRObnJ7JfTSWES8xaEmA@mail.gmail.com> <2B1C666E-1718-49B2-AECA-B2759BEE6872@ericsson.com> <CAGL6epJToAGBnvxNO0kTu74AtTL7eSqvsRyemKRt4=RBgU8z8g@mail.gmail.com> <7D911FFD-814F-4DCF-A13E-C3E19A5D0EE5@ericsson.com> <064B1BB7-6D54-453B-B58B-527EC3B9D78D@fastmail.fm> <CAGL6ep+b77z=W8ig6b5yzPAYir4rdAk8YTRbW58xkw0QRHgnNA@mail.gmail.com> <HE1PR07MB31611E03B4AE9575E9C224D8937C0@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAGL6epLH0ioOP2ZK5nv-awwZbCciV8hyQcYKWXE6XM9xt-YWwg@mail.gmail.com> <84CA4DD0-3877-46A0-8772-43F35BB788A3@ericsson.com>
In-Reply-To: <84CA4DD0-3877-46A0-8772-43F35BB788A3@ericsson.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Mon, 04 Nov 2019 07:53:54 -0500
Message-ID: <CAGL6epKTCrveo6HVNa4h2weii5kfO1csNLKYKHMNwEhKYfXdvQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, "sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, "draft-ietf-sipcore-digest-scheme@ietf.org" <draft-ietf-sipcore-digest-scheme@ietf.org>, The IESG <iesg@ietf.org>, SIPCORE <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009e7f2c059684cf86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/UcnUcmAIIg6l6qfy1fCisXjXIC0>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
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, 04 Nov 2019 12:54:11 -0000
I see. I am fine with this. Regards, Rifaat On Mon, Nov 4, 2019 at 2:57 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >I am not sure I am following, What do you mean by "challenge response not > being provided"? > > > > The response to the challenge provided by the server. > > > > If you think it is unclear, maybe something like: > > > > “A parameter with an empty value (empty string) is allowed when the UAC > has not yet received a challenge." > > > > Regards, > > > > Christer > > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 1:53 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > I am fine with the suggestion, but instead of talking about an algorithm > not being provided I would like to talk about a *challenge response* not > being provided. > > > > Regards, > > > > Christer > > > > > ------------------------------ > > *From:* Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > *Sent:* Sunday, November 3, 2019 12:01 PM > *To:* Alexey Melnikov <aamelnikov@fastmail.fm> > *Cc:* Christer Holmberg <christer.holmberg@ericsson.com>; > sipcore-chairs@ietf.org <sipcore-chairs@ietf.org>; > draft-ietf-sipcore-digest-scheme@ietf.org < > draft-ietf-sipcore-digest-scheme@ietf.org>; The IESG <iesg@ietf.org>; > SIPCORE <sipcore@ietf.org> > *Subject:* Re: [sipcore] Alexey Melnikov's No Objection on > draft-ietf-sipcore-digest-scheme-12: (with COMMENT) > > > > Alexey, Christer, > > > > How about the following: > > 1. Change the ABNF to "request-digest = LDQUOT *LHEX RDQUOT" > > 2. Change the text below it to say "The number of hex digits is implied by > the length of the value of the algorithm used, with the minimum size of 32. > A parameter with an empty value (empty string) is allowed when the > algorithm is not specified."" > > > > Regards, > > Rifaat > > > > On Fri, Nov 1, 2019 at 6:10 AM Alexey Melnikov <aamelnikov@fastmail.fm> > wrote: > > > > On 1 Nov 2019, at 07:09, Christer Holmberg <christer.holmberg@ericsson.com> > wrote: > > Hi, > > > > >I do not have a strong opinion here. > > > > > >Anybody has an opinion or thoughts about adding such a text? > > > > In addition we’d obviously also change the ABNF back, to allow empty > values. > > > > If the ABNF is changed back for this, I think some extra text would be > useful. > > > > Regards, > > > > Christer > > > > > > > > > > On Thu, Oct 31, 2019 at 1:50 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Something like this: > > > > “In some cases a UAC needs to include an Authorization header field in a > request before it has received a challenge, in order to provide user > information (using the ‘userinfo’ header field parameter) that is needed in > order to create the challenge. An example of such case is when the HTTP > Digest Authentication Using AKA mechanism (RFC3310) (RFC4169) is used. In > such case the Authorization header field would typically not contain a > ‘response’ header field parameter before a challenge response is provided. > However, for the IP Multimedia Subsystem (IMS) it has been specified that > the Authorization header field in such case does contain a ‘response’ > header field parameter, with an empty value (empty string). For that reason > the modified request-digest ABNF allows such empty values.” > > > > Regards, > > > > Christer > > > > > > *From: *Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > *Date: *Thursday, 31 October 2019 at 19.22 > *To: *Christer Holmberg <christer.holmberg@ericsson.com> > *Cc: *Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, > "sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, " > draft-ietf-sipcore-digest-scheme@ietf.org" < > draft-ietf-sipcore-digest-scheme@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, > "sipcore@ietf.org" <sipcore@ietf.org>, Alexey Melnikov < > aamelnikov@fastmail.fm> > *Subject: *Re: [sipcore] Alexey Melnikov's No Objection on > draft-ietf-sipcore-digest-scheme-12: (with COMMENT) > > > > Can you propose some text? > > > > Thanks, > > Rifaat > > > > > > On Thu, Oct 31, 2019 at 11:44 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > Perhaps we could add some text about the IMS use-case, in order to explain > the empty value? > > > > Regards, > > > > Christer > > > > *From: *sipcore <sipcore-bounces@ietf.org> on behalf of Christer Holmberg > <christer.holmberg=40ericsson.com@dmarc.ietf.org> > *Date: *Thursday, 31 October 2019 at 15.52 > *To: *Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> > *Cc: *"sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, " > draft-ietf-sipcore-digest-scheme@ietf.org" < > draft-ietf-sipcore-digest-scheme@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, > "sipcore@ietf.org" <sipcore@ietf.org>, Alexey Melnikov < > aamelnikov@fastmail.fm> > *Subject: *Re: [sipcore] Alexey Melnikov's No Objection on > draft-ietf-sipcore-digest-scheme-12: (with COMMENT) > > > > Hi, > > > > >This IMS behavior would have been in violation of RFC3261 which specified > exactly 32 Hex characters. > > >So, this change should not make much of a difference in this case. > > > > In reality it probably doesn’t make a difference, but it would make the > IMS procedures “aligned” with the IETF spec. > > > > Regards, > > > > Christer > > > > > > > > > > On Thu, Oct 31, 2019 at 9:37 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > Hi, > > > > The reason for the empty value comes from IMS and AKA, where you need to > include the user id already in the initial REGISTER request (this seems to > be missing from RFC 3310, but that’s a separate topic) in order for the > server to create the challenge, meaning that in the initial REGISTER > request you include an Authorization header field with the username > parameter carrying the IMS private user identity, the realm parameter and > the uri parameter. At this point you obviously don’t yet have the response, > so in IMS it is specified that the response parameter is inserted with an > empty value. > > > > WHY it was specified that way (instead of simply not including the > response parameter) I don’t know, but I do know that it has been > implemented and deployed that way for many years. > > > > Regards, > > > > Christer > > > > > > *From: *sipcore <sipcore-bounces@ietf.org> on behalf of Rifaat > Shekh-Yusef <rifaat.ietf@gmail.com> > *Date: *Thursday, 31 October 2019 at 15.20 > *To: *Alexey Melnikov <aamelnikov@fastmail.fm> > *Cc: *"sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, " > draft-ietf-sipcore-digest-scheme@ietf.org" < > draft-ietf-sipcore-digest-scheme@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, > "sipcore@ietf.org" <sipcore@ietf.org> > *Subject: *Re: [sipcore] Alexey Melnikov's No Objection on > draft-ietf-sipcore-digest-scheme-12: (with COMMENT) > > > > Done. > > > > On Thu, Oct 31, 2019 at 9:13 AM Alexey Melnikov <aamelnikov@fastmail.fm> > wrote: > > On Thu, Oct 31, 2019, at 1:11 PM, Rifaat Shekh-Yusef wrote: > > Hi Alexey, > > > > I am fine with Paul's suggestion. > > Are you ok with "32*LHEX"? > > Yes! > > > > Thank you, > > Alexey > > > > Regards, > > Rfaat > > > > > > On Thu, Oct 31, 2019 at 7:22 AM Alexey Melnikov <aamelnikov@fastmail.fm> > wrote: > > > > Hi Rifaat, > > > > On Wed, Oct 30, 2019, at 9:50 PM, Rifaat Shekh-Yusef wrote: > > Thanks Alexey! > > > > I am fine with the first two comments, and will fix these in the coming > version of the document. > > > > I am not sure I follow the 3rd one. Why do you see the need for a minimum > number of hex digits? > > You do say that the number of hex digits match the hash lenght, so it is > probably Ok. However empty value is never valid (and I am worried it might > hit some boundary condition bug in implementations), so prohibiting it in > ABNF would be the best. > > > > Best Regards, > > Alexey > > > > Regards, > > Rifaat > > > > > > > > On Wed, Oct 30, 2019 at 1:16 PM Alexey Melnikov via Datatracker < > noreply@ietf.org> wrote: > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-sipcore-digest-scheme-12: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I am agreeing with Alissa's DISCUSS. > > > > Also, I have a few comments of my own: > > > > 1) Last para of Section 2.1: > > > > 2.1. Hash Algorithms > > > > A UAS prioritizes which algorithm to use based on the ordering of the > > challenge header fields in the response it is preparing. > > > > This looks either wrong or confusing to me. I think you are just saying > here > > that the order is decided by the server at this point. > > > > That > > process is specified in section 2.3 and parallels the process used in > > HTTP specified by [RFC7616]. > > > > So based on the above, my suggested replacement for both sentences: > > > > A UAS prioritizes which algorithm to use based on its policy, > > which is specified in section 2.3 and parallels the process used in > > HTTP specified by [RFC7616]. > > > > 2) Last para of Section 2.4: > > > > If the UAC cannot respond to any of the challenges in the response, > > then it SHOULD abandon attempts to send the request unless a local > > policy dictates otherwise. > > > > Is trying other non Digest algorithms covered by "SHOULD abandon"? > > If yes, maybe you should make this clearer. > > > > For example, if the UAC does not have > > credentials or has stale credentials for any of the realms, the UAC > > will abandon the request. > > > > 3) In Section 2.7: > > > > request-digest = LDQUOT *LHEX RDQUOT > > > > This now allows empty value. I suggest you specify a minimum number of hex > > digits allowed in the ABNF. Or at least change "*LHEX" to "2*LHEX". > > > > > > > > > >
- [sipcore] Alexey Melnikov's No Objection on draft… Alexey Melnikov via Datatracker
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Paul Kyzivat
- Re: [sipcore] Alexey Melnikov's No Objection on d… Alexey Melnikov
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Alexey Melnikov
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Alexey Melnikov
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg
- Re: [sipcore] Alexey Melnikov's No Objection on d… Rifaat Shekh-Yusef
- Re: [sipcore] Alexey Melnikov's No Objection on d… Paul Kyzivat
- Re: [sipcore] Alexey Melnikov's No Objection on d… Christer Holmberg