Subject: [stir] Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Apr 2018 19:27:09 -0700

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?

---

From: Subir Das <[email-masked]>
Date: Wed, 18 Apr 2018 10:04:40 -0400

Hello Ben,

Thanks for your review and comments. Please see the answers inline.

Regards,

_Subir

-----Original Message-----
From: Ben Campbell <[email-masked]>
Sent: Monday, April 16, 2018 10:27 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Russ Housley <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Subject: Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS
and COMMENT)

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

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

   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:

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

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.

Does "CERT" mean "Certificate"? I assume it's not "Computer Emergency
Response Team".

SD> Yes CERT implies Certificate. We will change it to 'Certificate'

"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 <[email-masked]> wrote:

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 19 Apr 2018 11:46:51 +0200

> On Apr 18, 2018, at 4:04 PM, Subir Das <[email-masked]> wrote:
> 
> Hello Ben,
> Cc: [email-masked]; Russ Housley <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)
>  
> 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.)
>  
>  
> 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. 
>  
> 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?
>  
> “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)."

Can you envision a case where it would make sense to leave RPH verifiers where verification has failed? That seems like a dangerous practice worthy of at least a SHOULD NOT.

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

Is it the intent that this extension only be used with the ATIS framework? If so, some scoping language early in the document would be helpful.

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

Works for me.

> priority value" is hard to read. Please consider giving that parameter construct a name, and using the name throughout.
>  
> “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".

Works for me.

> Does "CERT" mean "Certificate"? I assume it's not "Computer Emergency Response Team".
>  
> 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.

I don’t understand what that means for invalid claims. Are you saying that local policy could mean you use an invalid claim anyway? If so, why bother verifying it?

>> elsewhere. I think that's a problem from an interoperability standpoint.. The

---

From: "Das, Subir" <[email-masked]>
Date: Thu, 19 Apr 2018 18:15:28 +0000

Hi Ben,
Please see the answers below.

regards,
_Subir

From: Ben Campbell <[email-masked]>
Sent: Thursday, April 19, 2018 5:47 AM
To: Subir Das <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]; STIR Chairs <[email-masked]>
Subject: Re: [stir] Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)

On Apr 18, 2018, at 4:04 PM, Subir Das <[email-masked]<mailto:[email-masked]>> wrote:

Hello Ben,

Regards,

_Subir

-----Original Message-----
From: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Sent: Monday, April 16, 2018 10:27 PM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Russ Housley <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Ben Campbell's Discuss on draft-ietf-stir-rph-03: (with DISCUSS and COMMENT)

DISCUSS:

SD> Appreciate it.

   policy."

SD> You are correct that it  should not but it is hard to imagine what the operators’ policy would be.  From a protocol perspective, we can recommend  SHOULD NOT if that is  what you are suggesting.

§7.2:

              SD> At this moment, it will be used with the ATIS framework. However, we do not know if some other framework will find it useful. We will  try to add a reference to ATIS framework. Will this work?

COMMENT:

SD> Will update.

Works for me.

Works for me.

SD> By ‘invalid’ claim I meant failed claim.   This specification does not define the call processing behavior of SIP UA. The intent here is to simply  provide an input to such a call processing entity about the validity of  RPH.
This is the reason why we leave this aspect to the local policy.

On Mon, Apr 16, 2018 at 10:27 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
Ben Campbell has entered the following ballot position for
draft-ietf-stir-rph-03: Discuss

§7.2:

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