Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 05 February 2018 06:37 UTC

Return-Path: <christer.holmberg@ericsson.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 4971A126E01 for <stir@ietfa.amsl.com>; Sun, 4 Feb 2018 22:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FTKlfmAFgMiV for <stir@ietfa.amsl.com>; Sun, 4 Feb 2018 22:37:47 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 18C5A126BF0 for <stir@ietf.org>; Sun, 4 Feb 2018 22:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517812663; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SMMdb0kkSESFScqdjEXtUOoEahkcMrpsKnPwvdizgCM=; b=NnBvMfBGH9haxGlBv+pn1izQCXe3isx4o/wI9EBnGT/WD6kx7HpOPfTlQpjSuGcz cGkmgahzmo5ik30qfguAIr0gK4S84ueFRk8DU+ILTfR2ZQZBadINvRcn+szaIzdm aBmdNfYCRmBGG/d/JRQ1hjo2qop6oVc9sniLYP/cl1M=;
X-AuditID: c1b4fb2d-499ff70000005540-9d-5a77fbb79656
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.66.21824.7BBF77A5; Mon, 5 Feb 2018 07:37:43 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Mon, 5 Feb 2018 07:37:43 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Singh, Ray P" <rsingh@vencorelabs.com>
CC: "DOLLY, MARTIN C" <md3135@att.com>, Subir <subirdas21@gmail.com>, "stir@ietf.org" <stir@ietf.org>, Adam Roach <adam@nostrum.com>, STIR Chairs <stir-chairs@ietf.org>, "draft-ietf-stir-rph.all@tools.ietf.org" <draft-ietf-stir-rph.all@tools.ietf.org>
Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?
Thread-Index: AdOTv2oSY/dEf4YfRra4GseuGeXVLAH6TDcAAIWJiHAAEQ/yAAACac0AAAWX2oAACjLjqg==
Date: Mon, 05 Feb 2018 06:37:42 +0000
Message-ID: <D3F011C9-7E23-4BBF-8D9F-E7C2776A4317@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <CAFb8J8pa9_q-pQbDy7ACg-JnFurOCJALYUdBzD6C-P1rJHO52g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, <E42CCDDA6722744CB241677169E8365668A592A9@MISOUT7MSGUSRDB.ITServices.sbc.com>, <C1A3E161FB009440ABA575570A60CD9C9A5FED72@rrc-ats-exmb2.ats.atsinnovate.com>
In-Reply-To: <C1A3E161FB009440ABA575570A60CD9C9A5FED72@rrc-ats-exmb2.ats.atsinnovate.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_D3F011C97E234BBF8D9FE7C2776A4317ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7uu723+VRBjc/Glrs+buI3WL18XNM FocePGW3OP/wJbPFsx3rWS2Wr93GZDHlwDJ2B3aPl/1zGD12zrrL7rFkyU8mj1k7n7B4fLn8 mc2j+dRW5gC2KC6blNSczLLUIn27BK6MK5PXshc0XmSt6P3/hL2BccZ7li5GTg4JAROJ3yeO MXUxcnEICRxmlNh79xYLhLOYUeL3tp/sXYwcHGwCFhLd/7RBTBEBbYl36/xBSpgFGpkk1s9b xwoySFggW2Lj0U1gtohAjsTJX38ZIewwiZuf57KD2CwCKhK3fn0Eq+EVsJfou7+VDWLXMmaJ LzNWMIEkOAUiJZ4+XgzWwCggJvH91BqwOLOAuMStJ/OZIK4WkFiy5zwzhC0q8fLxP1aImmSJ eUdOs0AsEJQ4OfMJywRG4VlI2mchKZuFpAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGZHFFzCy r2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjM+DW37r7mBc/drxEKMAB6MSD2/yy/IoIdbE suLK3EOMEhzMSiK8TteBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQW wWSZODilGhhdlXgkNiSXV9nrn7Kbtn5FfLrLzrfX0qyd/PVNp88uSekPuvZkf7tNvWK69yaP NsP9u+y/7PnQ/VJIO7zmyjpz3eBTH/0Tc3cUXMjl3s4qKnpM/7XCrvsC3HZHMk0dV91rsc8z ixHmiRHf4LD30PcnUsqbLwmfjv1v4dj+I1vrs+POTWXJ4UosxRmJhlrMRcWJAGfV9vfLAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/02ac5vRPNv-THz7et1ZSujEKxSU>
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?
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: Mon, 05 Feb 2018 06:37:52 -0000

Hi,

I think the reason why ‘orig’ and ‘dest’ are required in every PASSPorT should be explained the the PASSPorT document, in my opinion. It is not specific to the RPH extension.

Not sure how ‘orig’ can be used to identify a call. You can have multiple calls with the same ‘orig’ value, can’t you?

Regards,

Christer



Sent from my iPhone

On 4 Feb 2018, at 21.45, Singh, Ray P <rsingh@vencorelabs.com<mailto:rsingh@vencorelabs.com>> wrote:


All,

Yes, the claim is only for the RPH. The"orig" and "dest" is included so that the RPH claim can be correlated to the call.  We can add some clarification text to indicate that "orig" is only included so that the RPH claim can be correlated to a specific call, and that the signer of the RPH claim may no have authority of the "orig" TN.

Thanks

Ray





________________________________
From: stir [stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>] on behalf of DOLLY, MARTIN C [md3135@att.com<mailto:md3135@att.com>]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org<mailto:stir@ietf.org>; Adam Roach; STIR Chairs; draft-ietf-stir-rph.all@tools.ietf.org<mailto:draft-ietf-stir-rph.all@tools.ietf.org>
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?

We only have one claim and that is the RPH

From: Subir [mailto:subirdas21@gmail.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Cc: Adam Roach <adam@nostrum.com<mailto:adam@nostrum.com>>; STIR Chairs <stir-chairs@ietf.org<mailto:stir-chairs@ietf.org>>; stir@ietf.org<mailto:stir@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org<mailto:draft-ietf-stir-rph.all@tools.ietf.org>
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?


We can add some texts to clarify that in the next version. The point is that in some use cases service provider may have the authority to  other claims such as 'orig' and in other cases it may not have.  We can add a may statement clarifying this or explicitly say that it is not required to have authority to other claims.

Thanks,

Subir
Sent from my iPhone

On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi,

The text says:

   “The credentials (e.g., authority responsible for authorizing Resource-
   Priority) used to create the signature must have authority over the
   namespace of the "rph" claim and there is only one authority per
   claim.”

If the credentials don’t need to have authority of the other claims (e.g., “orig”) in the RPH PASSPorT I think you should explicitly say so.

Regards,

Christer


From: Subir Das [mailto:subirdas21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Cc: Adam Roach <adam@nostrum.com<mailto:adam@nostrum.com>>; STIR Chairs <stir-chairs@ietf.org<mailto:stir-chairs@ietf.org>>; stir@ietf.org<mailto:stir@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org<mailto:draft-ietf-stir-rph.all@tools.ietf.org>
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed?

Hello Christer,
The signing entity does not have always the authority to assert the caller identity in rph. We are submitting ver-03 draft  and it is clarified  as follows:
"The credentials (e.g., authority responsible for authorizing Resource-Priority) used to create the signature must have authority over the namespace of the“rph" claim.."

-Subir

On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi,

Another question for clarification.

Section 3 contains the following example:

    { "orig":{"tn":"12155551212<tel:(215)%20555-1212>"}
     "dest":{["tn":"12125551213<tel:(212)%20555-1213>"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0","wps.0"]}

…and the following text:

   “The credentials (e.g., authority responsible for authorizing Resource-
   Priority) used to create the signature must have authority over the
   "rph" claim…”

Since the claim also contains “orig”, is the assumption that the signing entity always also has authority to assert the callers identity? I think it would be good to explicitly mention it.

Regards,

Christer






From: stir [mailto:stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org<mailto:stir-chairs@ietf.org>>; stir@ietf.org<mailto:stir@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org<mailto:draft-ietf-stir-rph.all@tools.ietf.org>
Subject: [stir] AD Review: draft-ietf-stir-rph-02


I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who has worked on this document, and the authors and chairs in particular.

The technical content here looks generally good to me. I'd like to see a few issues addressed before IETF LC. In short sumary:

  *   The validation section needs to add a discussion of how to treat calls when the priority values in "rph" passports and SIP "Resource-Priority" header fields aren't 100% identical.
  *   The examples need some adjustment.
  *   There is a minor point of ambiguity in the Security Section, but this should be easy to fix, as long as the WG knows what was intended.
  *   The IANA actions need a little bit of adjustment.
  *   There are a number of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the document below. I've removed some portions of the document on which I have no comments.



Abstract

   This document extends the STIR PASSporT specification to allow the



"...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token (PASSporT) specification defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_materials_abbrev.expansion.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=iBTAhwN517BNArmj8bb8Uat3LAIfSqEb3OzuqHOl6ko&e=> for guidance on abbreviations)


   inclusion of cryptographically-signed assertions of authorization for
   the values populated in the SIP 'Resource-Priority' header field,
   which is used for communications resource prioritization.

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based on JWT
   [RFC7519] for conveying cryptographically-signed information about
   the identities involved in personal communications; it is used with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the
   identity of the participants in real-time communications established
   via a protocol like SIP.  This specification extends PASSporT to



"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)


   allow cryptographic-signing of the SIP 'Resource-Priority' header
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field for
   communications Resource Priority.  As specified in [RFC4412], the
   'Resource-Priority' header field may be used by SIP user agents
   [RFC3261], including, Public Switched Telephone Network (PSTN)



"...including Public Switched..."

(remove the comma)


   gateways and terminals, and SIP proxy servers to influence



"...and by SIP proxy servers, to influence..."

(add "by" and comma)


   prioritization afforded to communication sessions,including PSTN


"...sessions, including..."

(space after comma)


   calls.  However, the SIP 'Resource-Priority' header field could be
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority on the



"...STIR architecture [RFC7340] assumes..."

(space before "assumes")


   originating side of a call provides a cryptographic assurance of the
   validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows extension that



"...allows extensions..."


   can be utilized by authorities supporting real-time communication
   services using the 'Resource-Priority' header field to
   cryptographically sign the SIP 'Resource-Priority' header field and
   convey assertion of the authorization for 'Resource-Priority'.  For
   example, the authority on the originating side verifying the
   authorization of a particular communication for Resource-Priority can



Single quotes around 'Resource-Priority'.


   use a PASSPorT claim to cryptographically-sign the SIP 'Resource-



"...cryptographically sign..."


   Priority' header field and convey an assertion of the authorization
   for 'Resource-Priority'.  This will allow a receiving entity
   (including entities located in different network domains/boundaries)
   to verify the validity of assertions authorizing Resource-Priority.



Single quotes around 'Resource-Priority'.


   Cryptographically-signed SIP 'Resource-Priority' headers will allow a



"...cryptographically signed SIP 'Resource-Priority' header fields..."

(remove hyphen, and replace "headers" with "header fields")


   receiving entity to verify and act on the information with confidence
   that the information have not been spoofed or compromised.



"...has not been spoofed or compromised."



   This specification documents an optional extension to PASSporT and
   the associated STIR mechanisms to provide a function to sign the SIP
   'Resource-Priority' header field.  This PASSporT object is used to
   provide attestation of a calling user authorization for priority
   communications.  This is necessary in addition to the PASSporT object
   that is used for calling user telephone number attestation.  How the
   optional extension to PASSporT is used for real-time communications
   supported using SIP 'Resource-Priority' header field is defined in
   other documents and is outside the scope of this document.



I assume these other documents are under development? If so, they should be cited here.



2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



This document has several non-normative uses of "must", "should," and "may," and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boilerplate.



3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for "rph",
   which provides an assertion for information in SIP 'Resource-
   Priority'header.



"...Priority' header field."

(space after closing quotation mark, "header field" instead of "header")



   The creator of a PASSporT object adds a "ppt" value of "rph" to the
   header of a PASSporT object, in which case the PASSporT claims MUST
   contain a "rph" claim, and any entities verifying the PASSporT object
   will be required to understand the "ppt" extension in order to
   process the PASSporT in question.  A PASSPorT header with the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.example.org_cert.cer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=WTTuDmy39i2zI3icMHo82cqRGaXjzHywIgBAIK1oqCU&e=>}



Ideally, this would be either pretty-printed or canonicalized. Since it's too long to fit on a line in canonical form, I propose:

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":"https://www.example.org/cert.cer"<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.example.org_cert.cer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=WTTuDmy39i2zI3icMHo82cqRGaXjzHywIgBAIK1oqCU&e=>
}



   The "rph" claim will provide an assertion of authorization,"auth",



"...authorization, "auth", ..."

(space between comma and opening quotation mark)


   for information in the SIP "Resource-Priority" header field (i.e.,
   Resource-Priority: namespace "." r-priority) based on [RFC4412].



The use of the string 'namespace "." r-priority' here and elsewhere in the document has a detrimental impact on readability. I strongly suggest replacing it with "r-value" (the name of this production in RFC4412) everywhere.


   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 array containing one or more of JSON
   objects for the content of the SIP 'Resource-Priority' header that is
   being asserted of which one of the "rph" object, is mandatory.



This last sentence is very hard to parse; and (based on the example) the value is intended to be a JSON Object (curly braces) rather than a JSON Array (square braces). I suggest: '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 indicated in the SIP "Resource-Priority" header field.' (note: "header field", not "header")



   The following is an example "rph" claim for a SIP "Resource-Priority"
   header field with a "namespace "." r-priority" value of "ets.0" and
   with a "namespace "." r-priority" value of "wps.0".

    { "orig":{"tn":"12155551212<tel:(215)%20555-1212>"}
     "dest":{["tn":"12125551213<tel:(212)%20555-1213>"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0","wps.0"]}



As above, I recommend pretty-printing this. It's also missing a comma after the "orig" value, and the top-level structure is missing a closing brace. The value for "iat" needs to be enclosed in quotes.

The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.nationalnanpa.com_pdf_NRUF_ATIS-2D0300115.pdf&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=j5qBjswSQA0ysoO_pLKTUdCkKPLbwR6Q-gg8AbaBcFM&e=>).

Putting all this together, I believe what you want is:

{
  "orig":{"tn":"12155550112<tel:(215)%20555-0112>"},
  "dest":{["tn":"12125550113<tel:(212)%20555-0113>"]},
  "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0"]}
}



   After the header and claims PASSporT objects have been constructed,
   their signature is generated normally per the guidance in
   [I-D.ietf-stir-passport] using the full form of PASSPorT.  The
   credentials (e.g., authority responsible for authorizing Resource-
   Priority) used to create the signature must have authority over the
   "rph" claim and there is only one authority per claim.  The authority
   MUST use its credentials (i.e., CERT) associated with the specific
   service supported by the SIP namespace in the claim.

4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rph" claim in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph" claim using the
   values discussed in section 3 based on [RFC4412].  The construction
   of "rph" claim follows the steps described in Section 4 of
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might look as follows:



"...header field..."



   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_
   oos2P2Dyw"; info= "https://www.example.org/cert.cer"<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.example.org_cert.cer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=WTTuDmy39i2zI3icMHo82cqRGaXjzHywIgBAIK1oqCU&e=>;alg=ES256;
   ppt="rph"



This example has a number of issues:

  *   In the Identity header field, the signed-identity-digest shouldn't be quoted.
  *   In the Identity header field, info is enclosed in <> rather than "".
  *   In the Identity header field, ppt is a token rather than a quoted string.
  *   The signed-identity-digest header needs to indicate a "typ" of "passport" rather than JWT, and it needs to include both a "ppt" and "x5u" field.
  *   The signed-identity-digest body should contain only the passport claim rather than a JSON object that itself contains a base64-encoded JWS header concatenated with a claim.
  *   I believe that, even when the body is included, values in the header and body need to be be canonicalized (i.e., all on one line, no spaces, in alphabetical order, etc.)

I would also recommend following the convention of indicating that line-wraps are only for readability, and including the header field name in the example. Putting all this together, I believe what you want is:

   For example, a Identity header field for "rph" might look
   as follows (backslashes shown for line folding only):

   Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
   iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \
   Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \
   6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \
   AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \
   18vYYFy3blXvs3fslM_oos2P2Dyw;info=<https://www.example.org/cert.cer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.example.org_cert.cer&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=WTTuDmy39i2zI3icMHo82cqRGaXjzHywIgBAIK1oqCU&e=> \
   >;alg=ES256;ppt=rph

(Note: this example assumes the calling and called party numbers in the previous example are changed to 12155550112<tel:(215)%20555-0112> and 12155550113<tel:(215)%20555-0113>, respectively)



   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 "." r-priority" values
   based on [RFC4412].  The authentication service derives the value of
   the PASSPorT claim by verifying the authorization for Resource-
   Priority (i.e., verifying a calling user privilege for Resource-
   Priority based on its identity) which might be derived from customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-priority" pairs, either in
   a single SIP Resource-Priority header or across multiple SIP



Single quotes around 'Resource-Priority'.

"...header field..."


   Resource-Priority headers.  However, it is not necessary to sign all



Single quotes around 'Resource-Priority'.

"...header fields..."


   content of a SIP Resource-Priority header or all SIP Resource-



Single quotes around 'Resource-Priority'.

"...header field..."


   Priority headers in a given SIP message.  An authority is only



Single quotes around 'Resource-Priority'.

"...header fields..."


   responsible for signing the content of a SIP Resource-Priority header



Single quotes around 'Resource-Priority'.

"...header field..."


   for which it has authority (e.g., a specific "namespace "."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that
   specifications defining "ppt" values describe any additional verifier
   behavior.  The behavior specified for the "ppt" values of "rph" is as
   follows:

   The verification service MUST extract the value associated with the
   "auth" key in a full form PASSPorT with a "ppt" value of "rph".  If
   the signature validates, then the verification service can use the
   value of the "rph" claim as validation that the calling party is
   authorized for Resource-Priority, which would in turn be used for


Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indicates that the calling party is authorized to use the priorities indicated in the passport object, or the values in the SIP 'Resource-Priority' header field; and (taken on its face) implies the latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in the claim. This value would in turn be used for..."

The text also needs to say something about comparing values in the claim to values in the 'Resource-Priority' header field, and what a mismatch might mean. The document says elsewhere that the signature might only cover some of the r-values, which makes it entirely possible that the 'Resource-Priority' field might contain more values than are signed. On the other hand, intermediaries might reasonably remove r-values as the call is processed. This probably means that those removed priorities should not be used, even if they are present in the passport. It seems reasonable to say that *typical* processing by a receiving party would be to take the *union* of all RPH passports that they trust, and *intersect* that with the priorities in 'Resource-Priority' header fields to get the actual priority or priorities to be applied to the call (subject to local policy).


   priority treatment in accordance with local policy for the associated
   communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires
   "iat" value in "rph" claim to be verified.

   The behavior of a SIP UAs upon receiving an INVITE containing a



"...of a SIP UA upon..."

or

"...of SIP UAs upon..."


   PASSporT object with a "rph" claim will largely remain a matter of
   implementation policy for the specific communication service.  In
   most cases,implementations would act based on confidence in the



"...cases, implementations..."

(space after comma)


   veracity of this information.  The use of the compact form of



Paragraph break before "The".


   PASSporT is not specified in this document.

5.  Further Information Associated with Resource-Priority



Single quotes around 'Resource-Priority'.



   There may be additional information about the calling party or the
   call that could be relevant to authorization for Resource-Priority.



Single quotes around 'Resource-Priority'.


   This may include information related to the device subscription of
   the caller, or to any institutions that the caller or device is
   associated with, or even categories of institutions.  All of these
   data elements would benefit from the secure attestations provided by
   the STIR and PASSporT frameworks.  The specification of the "rph"
   claim could entail the optional presence of one or more such
   additional information fields.

   A new IANA registry has been defined to hold potential values of the
   "rph" array; see Section 6.2.  The definition of the "rph" claim may
   have one or more such additional information field(s).  Details of
   such "rph" claim to encompass other data elements are left for future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration



I think there's some confusion here. You're registering a PASSporT ppt value, not a new JWT claim. That is to say, you're adding an entry to this table:

https://www.iana.org/assignments/passport/passport.xhtml<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_passport_passport.xhtml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=XHIsWMuytA6Mju6miEzVpnt0D4ZxkABTSvJ-jfcYuTU&e=>

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=Azmjfo546YHWk9r4HQWdEB5PjY9NxAP8lluWfa6f_B4&e=>

You would only use the second table if you had a new key to add to the PASSporT header -- this specification does not do that.

This section also needs some introductory text to let the IANA know exactly what to do; e.g. "This document registers a new value for the "Personal Assertion Token (PASSporT) Extensions" table.

   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to the PASSporT
   Types registry for the type "rph" which is specified in [RFCThis].



There isn't an IANA table called "PASSporT Types." I presume this is the registration we just discussed in section 6.1, and so the above two lines can be removed.


   This specification also requests that the IANA create a new registry
   for PASSporT "rph" types.  Registration of new PASSporT "rph" types
   shall be under the specification required policy.  This registry is
   to be initially populated with a single value for "auth" which is
   specified in [RFCThis].



This needs to be very clear about the fields to be included in this new registry (e.g., "Registry entries must contain two fields: the name of the 'rph' type and the specification in which the type is described").



7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rfc4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of "rph" MUST only be sent
   with SIP INVITE when 'Resource-Priority' header is used to convey the



"...header field..."


   priority of the communication as defined in [RFC4412].  To avoid the
   replay, and cut and paste attacks, the procedures described in
   Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed.

7.2.  Solution Considerations

   The use of extension to PASSporT tokens with "ppt" value "rph" based
   on the validation of the digital signature and the associated
   certificate requires consideration of the authentication and
   authority or reputation of the signer to attest to the identity being
   asserted.  The following considerations should be recognized when
   using PASSporT extension with "ppt" value of "rph":

   o  An authority (signer) is only allowed to sign the content of a SIP
      'Resource-Priority' header for which it has the right authority.



"...header field..."


      The authority that signs the token MUST have a secure method for
      authentication of the end user or the device.

   o  The verification of the signature MUST include means of verifying
      that the signer is authoritative for the signed content of the SIP



It's not clear what authority is being claimed here. Is this supposed to mean something like "...verifying that the signer is authoritative for the originating tn in the PASSporT..."? Or "...authoritative for the resource priority namespace in the PASSporT?" Whatever the server is purportedly authoritative for needs to be clearly spelled out.


      'Resource-Priority' header.



"...header field."


/a

_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=slKIBY37y8p4iC3JgjuwD1TI9OgW7QTHWzmJVyqyJNg&s=u6QCrnmkjzqxu6Q3ZTM6MCUPPjwXFbiYnRRtMpZTX6I&e=>