Subject: [stir] AD Review: draft-ietf-stir-rph-02

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jan 2018 16:15:03 -0600

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> 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"}

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"
}

>
>    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"}
>      "dest":{["tn":"12125551213"]},
>      "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>).

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

{
   "orig":{"tn":"12155550112"},
   "dest":{["tn":"12125550113"]},
   "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";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 \
    >;alg=ES256;ppt=rph

(Note: this example assumes the calling and called party numbers in the 
previous example are changed to 12155550112 and 12155550113, 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

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml

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

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jan 2018 23:34:03 +0000

Hi,

Do the nesting discussions affect this extension? I assume one could use this with other passports.

Regards,

Christer

Sent from my iPhone

On 20 Jan 2018, at 0.15, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

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

"...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://www.rfc-editor.org/materials/abbrev.expansion.txt> for guidance on abbreviations)

...

1.  Introduction

(remove the comma)

(add "by" and comma)

(space after comma)

(space before "assumes")

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

2.  Terminology

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

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"<https://www.example.org/cert.cer>}

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://www.example.org/cert.cer>
}

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.

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")

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://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).

{

4.  'rph' in SIP

"...header field..."

   oos2P2Dyw"; info= "https://www.example.org/cert.cer"<https://www.example.org/cert.cer>;alg=ES256;
   ppt="rph"

  *   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:

   >;alg=ES256;ppt=rph

(Note: this example assumes the calling and called party numbers in the previous example are changed to 12155550112 and 12155550113, respectively)

"...header field..."

"...header fields..."

"...header field..."

"...header fields..."

"...header field..."

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).

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

or

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

(space after comma)

6.  IANA Considerations

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:

Not to this table:

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"

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 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").

"...header field..."

"...header field..."

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.

"...header field."

/a
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Jan 2018 10:30:47 -0600

The -divert- document needs to co-exist with "ppt" extensions in 
general, and I would be very sad if its design required additional 
considerations in each such extension. What kind of impact are you 
envisioning?

/a

On 1/20/18 5:34 PM, Christer Holmberg wrote:
>> 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:
>>
>> 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
>>>
>> 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.
>>
>>
>> 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")
>>
>>
>>>
>> 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 
>>     "passport" rather than JWT, and it needs to include both a "ppt"
>>     and "x5u" field.
>>   * 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.)
>>
>> 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:
>>
>> (Note: this example assumes the calling and called party numbers in 
>> the previous example are changed to 12155550112 and 12155550113, 
>> respectively)
>>
>>
>>>
>> 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.
>>
>> 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).
>>
>>
>> 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:
>>
>> 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.
>>
>> 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 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").
>>
>>
>>>
>> 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.
>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jan 2018 18:46:46 +0000

Hi,

>The -divert- document needs to co-exist with "ppt" extensions in general, and I would be very
> sad if its design required additional considerations in each such extension. What kind of impact are you envisioning?

I wonder if the problem(s) with using multiple Identity header fields are divert-specific, or if they also apply to other passport extensions.

(There are generic issues with the suggested nesting mechanism, most of which were raised by my colleague Julio, but that’s a separate thread)

Regards,

Christer

Regards,

Christer
Sent from my iPhone

Abstract

...

1.  Introduction

(remove the comma)

(add "by" and comma)

(space after comma)

(space before "assumes")

2.  Terminology

3.  PASSporT 'rph' Claim

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",

{

4.  'rph' in SIP

"...header field..."

"...header field..."

"...header fields..."

"...header field..."

"...header fields..."

"...header field..."

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

or

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

(space after comma)

6.  IANA Considerations

Not to this table:

   o  ppt value: "rph"

"...header field..."

"...header field..."

"...header field."

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Jan 2018 12:52:26 -0600

On 1/22/18 12:46 PM, Christer Holmberg wrote:
>
> I wonder if the problem(s) with using multiple Identity header fields 
> are divert-specific, or if they also apply to other passport extensions.
>

The issue with -divert- is that you have a semantic stack of 
destinations, rather than a variety of PASSporTs that can assert 
different things about the call. Nesting is specific to the -divert- use 
case.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jan 2018 19:45:21 +0000

> The issue with -divert- is that you have a semantic stack of destinations, rather than a variety of PASSporTs that can assert 
> different things about the call. Nesting is specific to the -divert- use case.

Ok. So, if a node receives an Identity header field (#1), and wants to add RPH, it will add the "rph" claim in a separate PASSPorT, carried in a separate Identity header field (#2)? It will not add the "rph" claim to the existing PASSPorT carried in #1, and it will not perform any nesting.

Regards,

Christer