Re: [stir] WG Last Call for draft-ietf-stir-rph-emergency-services-02

See my reply to Jack for more info.

For an emergency call, we are protecting the use of rph with the esnet namespace to be limited to emergency calls.  So the signer checks From as usual, and checks Request URI to see that it is urn:service:sos, and if so, checks rph to see that it is esnet.1 SIP Priority is not used with emergency calls.  It could modify rph if it wanted to and then sign, or refuse to put in the claim.

For a call back, the signer has to know that the calling entity is an allowed authority (or it may be that the authority signs its own calls).  That permits SIP Priority to use the call back marking.  rph must be esnet.0 or get modified as above to get the claim.

> On Aug 17, 2020, at 10:36 AM, Russ Housley <housley@vigilsec.com> wrote:
> 
> I am confused by the last sentence of the Introduction (Section 1).  It says:
> 
>   In addition, the PASSPorT claims and values defined in
>   this document are intended for use in environments where there are
>   means to verify that the signer of the SIP 'Resource-Priority' and
>   'Priority' header fields is authoritative.
> 
> The signer signs the PASSPorT.  The PASSPorT includes claims, and each claim has a value.  By construction, the values are expected to match the SIP 'Resource-Priority' header field and the SIP 'Priority' header field.  Is this saying that the PASSPorT must be authoritative for these claims if they are present?
> 
> 
> In Section 3.1, I expected a MUST statement that says what appears in the value of the "ESorig" value.  It says what MUST appear on other claims around the "rph" claim, but it only gives an example of a value that matches an SIP 'Resource-Priority' header field.
> 
> 
> Likewise in Section 3.2, I expected a MUST statement that says what appears in the value of the "EScallback" value.  It says what MUST appear on other claims around the "rph" claim, but it only gives an example of a value that matches an SIP 'Resource-Priority' header field.
> 
> 
> In Section 3.2, I believe that the last paragraph applies to both the "ESorig" value and the "EScallback" value, so it probably belongs in Section 3 or a separate subsection.
> 
> 
> Section 4 says:
> 
>   Therefore, we define a new claim key as part of the "rph" PASSporT, ...
> 
> I think it would be more clear to say:
> 
>   Therefore, we define a new claim key to be used in a PASSporT that includes "rph" claim, ...
> 
> 
> Section 6 should use RFC 2119 wording:
> 
>   The use of the compact form of PASSporT is not specified in this
>   document.   Use of the compact form of PASSporT is NOT
>   RECOMMENDED for a PASSporT that includes a "rph" claim.
> 
> 
> I think that the Security Considerations (Section 8) should say someting about the consequences of a PASSPorT that includes the "rph" or "sph" claim that is signed by a party that is not authoritative for the SIP 'Resource-Priority' header field and the SIP 'Priority' header field.
> 
> Russ
> (No Hats)
> 
> 
>> On Jul 31, 2020, at 11:29 AM, Russ Housley <housley@vigilsec.com> wrote:
>> 
>> 
>> This is the STIR WG Last Call for "Assertion Values for a Resource Priority Header Claim and a SIP Priority Header Claim in Support of Emergency Services Networks” <draft-ietf-stir-rph-emergency-services-02>.  Please review the document and send your comments to the STIR WG mail list by 22 August 2020.
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-stir-rph-emergency-services/
>> 
>> Thanks,
>> Robert & Russ
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir