Re: [stir] Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)
Subir Das <subirdas21@gmail.com> Wed, 18 April 2018 14:04 UTC
Return-Path: <subirdas21@gmail.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07AB12D778; Wed, 18 Apr 2018 07:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 dNAJtGoYim3s; Wed, 18 Apr 2018 07:04:42 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 5C6AC124D68; Wed, 18 Apr 2018 07:04:42 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id d1-v6so5177750wrj.13; Wed, 18 Apr 2018 07:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gongXMJ86S9Qb4wXZDR9VhyuGVR1yWOv5tDymjlsifg=; b=RhioxdJ7FV2K1WFd094H857faF7VBEdRG7Y+l+Mrri/ILpx6yx4Jqr22wUDh/uLk/e AHM6vpZo3002Ee87oYtwyzer/uRzV1omJoIW0v52yteFh1pslQo+7UUplwopH8RfT1e1 s1bcJKuQFpx4dwQLuixKff3nRq1Vxu5TYq1kHJQFTx8ooOtf6UYZimlneHoDutBDdKNV 11XvDjHCXbhP8Y+6gIOCfSO5fFyyEJ0XFlEI1E8ihZVRNilWmfXMpDAKBHrv4KnNDxDR 8hUqvmT+Ab/xfcoRfMwO0e+KLnQllvTuzQpQowuUp+XMWQhknaUh9c0J//1nKpUME2Sj aCDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gongXMJ86S9Qb4wXZDR9VhyuGVR1yWOv5tDymjlsifg=; b=blWS7i4MRA9vrZMhl49wp5lgUTVvdZ0TMq4aG6aMRLpESS2aRl4shAjrcudOF4loQT a4YnRWDtdnWI38soBP5fekIMwbVOJmgCXxJfnqmQ74dMePFBsdDb74dP+XG1inpONLqI 3AfdWzD1beQhX+3UATHY76/GOy4nqMvIZQZNkEPe7aVfedQYsLuFbieD1XGKWq3GRMuU tB9jbl8V8DZzDwhTdj8ezdM4Iq/jHM/WQ6a91LJxczMkS7xEF9IXM8/5wFs8H8UOde1o BrvG9k7owCNM3mMsOP16eD4JfZB4sJ5IBTTGcvVsEjcM7PMWS852fewE8AIRV3NpwGes 8DeQ==
X-Gm-Message-State: ALQs6tBAjSDtaaUP702kx645R3BGtdB4ldy2wJN42HUAOWxniHxRRLS6 N6Ln2tQhRLftNdBi8kYgXuEqDDEIipTYaFmexOTFrw==
X-Google-Smtp-Source: AIpwx4/y5O3efUKKt0/dFaj8wAJNXAVr1K/oKxMBbul3dRmx9aEwfZQoyPdnUKNuFCbdmlfZIptx/7Xj6O+Q2Y3yz5U=
X-Received: by 10.28.146.200 with SMTP id u191mr1951289wmd.115.1524060280783; Wed, 18 Apr 2018 07:04:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.69.25 with HTTP; Wed, 18 Apr 2018 07:04:40 -0700 (PDT)
In-Reply-To: <152393202955.26114.3853075658304497317.idtracker@ietfa.amsl.com>
References: <152393202955.26114.3853075658304497317.idtracker@ietfa.amsl.com>
From: Subir Das <subirdas21@gmail.com>
Date: Wed, 18 Apr 2018 10:04:40 -0400
Message-ID: <CAFb8J8o=TKvvEkzuBP1QZuQ5wKpKmooScKdRXSOQxp7WbND0vA@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: The IESG <iesg@ietf.org>, IETF STIR Mail List <stir@ietf.org>, rhousley@vigilsec.com, STIR Chairs <stir-chairs@ietf.org>, draft-ietf-stir-rph@ietf.org
Content-Type: multipart/alternative; boundary="001a114307d6a70930056a1fef3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/Wa0wHT3iS_mlVvmrLA5QZHHZ8Ls>
Subject: Re: [stir] Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2018 14:04:45 -0000
Hello Ben, Thanks for your review and comments. Please see the answers inline. Regards, _Subir -----Original Message----- From: Ben Campbell <ben@nostrum.com> Sent: Monday, April 16, 2018 10:27 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-stir-rph@ietf.org; Russ Housley <rhousley@vigilsec.com>; stir-chairs@ietf.org; rhousley@vigilsec.com; stir@ietf.org Subject: Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-stir-rph-03: Discuss 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-stir-rph/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this work. I plan to ballot "yes", but I have a couple of points I think need to be discussed first. SD> Appreciate it. §4.2: " If the signature validation fails, the verification service should infer that the calling party is not authorized for ’Resource-Priority’ as indicated in the claim. In such cases, the priority treatment for the associated communication service is handled as per the local policy." I suspect there will be deployments where the node making these local policy decisions is downstream from the verifier. How do they know RPH verification failed? Should the verifier strip resource priority header fields for which validation failed? SD> We will clarify the last sentence of the paragraph as follows: “In such cases, the priority treatment for the associated communication service is handled as per the local policy of the verifier (e.g., the RPH may be stripped and call can be treated as an ordinary call)." §7.2: o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the resource priority namespace in the PASSporT." I gather the intent is to leave that means to local policy, or to be specified elsewhere. I think that's a problem from an interoperability standpoint. The verifier needs a way to know whether the authorizer is authoritative for the RPH. If we want authorizers and verifiers from different vendors to be able to interoperate, it seems like at least some mechanism needs to be standardized and possibly MTI. SD> Yes, you are correct that the end-to-end architecture is specified outside of IETF. This is currently done in ATIS where the verifier can verify the authorizer’s certificate even if they are from different providers. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- General: It's probably worth updating the references to 4474bis and passport to their respective RFCs. SD> Will update. §3, 4th paragraph: The imbedding of ABNF in the middle of a paragraph is difficult to read. It would be helpful to separate that from the surrounding text in the conventional fashion. SD> How about the following? "The "rph" claim will provide an assertion of authorization, "auth", for information in the SIP ’Resource-Priority’ header field based on [RFC4412] and the syntax is: Resource-Priority = "Resource-Priority": r-value r-value= "namespace "." r-priority Specifically, the "rph" claim includes assertion of the priority-level of the user to be used for a given communication session. The value of the "rph" claim is an Object with one or more keys. Each key is associated with a JSON Array. These arrays contain Strings that correspond to the ‘r-values’ values indicated in the SIP ’Resource-Priority’ header field." §3, 5th paragraph and throughout: The repeated use of "r-value ="namespace "." priority value" is hard to read. Please consider giving that parameter construct a name, and using the name throughout. SD> How about the following? “The following is an example "rph" claim for a SIP ’Resource-Priority’ header field with an r-value of "ets.0" and with another r-value of "wps.0". Note: Will change the rest accordingly. §3, 7th paragraph: "The authority MUST use its credentials (i.e., CERT)" Does "CERT" mean "Certificate"? I assume it's not "Computer Emergency Response Team". SD> Yes CERT implies Certificate. We will change it to 'Certificate' §4.1 : A SIP authentication service typically will derive the value of "rph" from the ’Resource-Priority’ header field based on policy associated with service specific use of the "namespace "." priority value" for r-values based on [RFC4412].: "Typically" usually implies "Most but not all of the time". Is that the intent? SD> No that is not the intent. Will delete ‘typically”. The sentence will read : SD> “A SIP authentication service will derive the value of "rph" from the ’Resource-Priority’ header field based on policy associated with service specific use of the "namespace "." r-priority " for r-values based on [RFC4412]. “ §4.2, last paragraph: Am I correct to guess that this is talking about valid claims? SD> This statement is valid for both valid and invalid claims. The policy will determine how claim will be treated. On Mon, Apr 16, 2018 at 10:27 PM, Ben Campbell <ben@nostrum.com> wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-stir-rph-03: Discuss > > 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-stir-rph/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this work. I plan to ballot "yes", but I have a couple of > points I > think need to be discussed first. > > §4.2: " If the signature validation fails, the verification service should > infer > that the calling party is not authorized for ’Resource-Priority’ as > indicated in the claim. In such cases, the priority treatment for > the associated communication service is handled as per the local > policy." > > I suspect there will be deployments where the node making these local > policy > decisions is downstream from the verifier. How do they know RPH > verification > failed? Should the verifier strip resource priority header fields for which > validation failed? > > §7.2: > o The verification of the signature MUST include means of verifying > that the signer is authoritative for the signed content of the > resource priority namespace in the PASSporT." > > I gather the intent is to leave that means to local policy, or to be > specified > elsewhere. I think that's a problem from an interoperability standpoint. > The > verifier needs a way to know whether the authorizer is authoritative for > the > RPH. If we want authorizers and verifiers from different vendors to be > able to > interoperate, it seems like at least some mechanism needs to be > standardized > and possibly MTI. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > General: It's probably worth updating the references to 4474bis and > passport to > their respective RFCs. > > §3, 4th paragraph: The imbedding of ABNF in the middle of a paragraph is > difficult to read. It would be helpful to separate that from the > surrounding > text in the conventional fashion. > > §3, 5th paragraph and throughout: The repeated use of "r-value ="namespace > "." > priority value" is hard to read. Please consider giving that parameter > construct a name, and using the name throughout. > > §3, 7th paragraph: "The authority MUST use its credentials (i.e., CERT)" > Does "CERT" mean "Certificate"? I assume it's not "Computer Emergency > Response > Team". > > §4.1 : A SIP authentication service typically will derive the value of > "rph" > from the ’Resource-Priority’ header field based on policy associated > with service specific use of the "namespace "." priority value" for > r-values based on [RFC4412].: > "Typically" usually implies "Most but not all of the time". Is that the > intent? > > §4.2, last paragraph: Am I correct to guess that this is talking about > valid > claims? > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >
- [stir] Ben Campbell's Discuss on draft-ietf-stir-… Ben Campbell
- Re: [stir] Ben Campbell's Discuss on draft-ietf-s… Subir Das
- Re: [stir] Ben Campbell's Discuss on draft-ietf-s… Ben Campbell
- Re: [stir] Ben Campbell's Discuss on draft-ietf-s… Das, Subir