[stir] Review of draft-ietf-stir-rph-emergency-services

[Jack Rickard <[e-mail]>]

I have reviewed draft-ietf-stir-rph-emergency-services-02 and have some concerns and questions. I don't believe this spec is implementable in its current form.

Thanks,
Jack

Why are "ESorig" and "EScallback" distinct?
They seem to serve a very similar purpose with the only difference being whether orig or dest should be the emergency services. I don't believe there's any check that can be done to validate:
   When using "ESorig" as the "rph" assertion value, the "orig" claim of
   the PASSporT MUST represent the calling party number that initiates
   the call to emergency services.
This (and the equivalent statement for EScallback) don't seem possible to me to check (barring the standard orig/dest checking).
This would make the check "at least one of the parties should be the emergency services" enough to validate that this was a reasonable call.


Why have them at all rather than just using auth?
This is very possibly an issue with my understanding, but I'm not clear on why "ESorig" and "EScallback" even need to exist. "esnet.0" etc. are SIP Resource Priority headers, so should be included in the "auth" field anyway by the RPH spec. This spec appears to apply extra constraints (that a one of the callers must be the emergency services) for the "esnet" namespace but it's not clear why entirely separate claims are needed.

In a similar vein, what should a verifier do if it receives a call containing an invalid "ESorig" or "EScallback" value or the passport is invalid/untrusted, I'm assuming the behaviour is the same as for auth but this isn't clear. Although stripping the fact that this is an emergency call is potentially dangerous.


Specify the type of the "ESorig" and "EScallback" claims.
This specification currently doesn't specify the type of the new fields, there are only examples and this isn't enough. It looks like they both follow the same scheme as the rph "auth" claim, however "esnet,x" doesn't quite fit into that due to the comma and that x isn't a valid priority value.


Why is sph limited to psap-callback? What should the verifier do if it isn't that? What should it do if it is?
I'm not entirely clear on the purpose of the sph claim, however, it seems odd that it doesn't cover the full range of possible values for the SIP Priority Header. Is there a reason that it doesn't cover the "non-urgent", "normal", "urgent", or "emergency" values?
There is also no verifier behaviour defined here, should the verifier remove the Priority header if it receives an invite with no passports signing for it? That seems dangerous to me but would be consistent with rph. Alternatively, what should the verifier do if it receives an invite with a valid passport claiming sph but with no Priority header should it add it in? I'm not sure the spec needs to be too prescriptive here, however some mention of verifier behaviour and the associated security considerations would be useful.


Should the spec be stronger about the compact form?
Section 3 currently states

   The use of the compact form of PASSporT is not specified in this

   document.
However, a compact-form passport following this spec would be hard to verify as it introduces multiple possible rph variants, I think this spec could go further and say you shouldn't/mustn't.


What is the requirement of these new parameters.
As I understand it, the passport spec allows you to create a passport containing whatever JWT fields you want and verifiers should just ignore any fields they don't understand. Unless the "ppt" claim is set, which indicates that verifiers should discard it if they don't recognise that passport type. As this spec adds additional fields to an existing passport type it isn't immediately clear what the behaviour should be. Specifically, is an rph passport containing only "rph.ESorig" valid now (where it wouldn't be before because auth isn't present), is an rph passport containing no rph and only sph valid, and what does a non-rph passport with sph or ESorig set mean?