Re: [stir] Comments on rfc4916-update

["Peterson, Jon" <[e-mail]>]

Hey Jonathan,

Thanks for the notes on this document – we discussed most of this at the mic back in SF, but I figured I’d capture this here for the record, so responses below inline.

Jon Peterson
TransUnion


There is another interesting use case for this spec that is not mentioned in the intro. Specifically, when calls are placed by automata for the purposes of verifying ownership of phone numbers, it is really important that the call has not actually been forwarded. One can imagine that the entity performing the call to verify ownership of the number, would want to receive the rsp passport and check that it matches the called number. This would actually address some of the concerns that have been raised about the insecurity of forward routability checks for verifying number ownership.

Added.

On this:
> An "rsp" PASSporT that signs a different "dest" than the one that appeared in the PASSporT of the dialog-forming request MUST send at least one "div" PASSporT with it. If no "div" PASSporTs were received in the dialog-forming request, then "rsp" PASSporTs MUST NOT be used in responses.

I think this MUST is overly harsh. The entity sending the rsp passport has no control over whether intermediaries inserted div passports along the way. If none of them do, it means that the rsp passport can never be sent and this spec is useless. Indeed, for the use case I outline above, the originator of the call doesnt need the div passports at all, just the rsp passport.

As we discussed at the mic in SF, this is just a case where the second sentence above was meant to build on the first, but taken in isolation, it reads wrong – which is fixed in the new version. If the “dest” is changed, and there’s no “div” received by the terminating side, this spec is not applicable, as I think we agree on. Broadly, if you place an TFA call to 2125551212 and got back a “rsp” from 2125559999 (with no “div” explaining why), what are you supposed to do with it? You certainly shouldn’t trust it any more than you would a call with no connected identity at all.

As to whether anyone should trust an unexpected “rsp” “dest” accompanied by proper “div”s explaining that the call was legitimately redirected, I think we can just call that a matter of local policy – I think it’s pretty trustworthy, but there could be differences of opinion on this matter. We at the IETF can leave that up to the conscience of implementers/deployers – the protocol machinery is there for people who do want to trust it.

On this:
> The use of the connected identity mechanism here specified is not limited to provisional dialog requests. Once a dialog has been established with connected identity, any re-INVITEs from either the originating and terminating side, as well as any BYE requests, MUST contain Identity headers with valid PASSporTs.

It seems odd to me that this spec would require the originator of the call to take extra actions (namely, including passports in mid-dialog requests) just because the terminating side decided to add an rsp passport in the 200 OK response to the INVITE.

Broadly, I see the scope of this draft as mutually authenticating requests in a dialog, not merely protecting call setup, due to the various fraud use cases involving later in-dialog signaling that are described in the draft’s motivation.

As we also discussed in SF, I’m willing to slip that down to a SHOULD. I’m treating receipt of an “rsp” like a capability negotiation, effectively. I can tweak the text there a bit to support the case where the originating side does not understand “rsp”, which it doesn’t really account for now, but basically the intention is that if both sides support connected identity, they should apply it to all mid-dialog or dialog-terminating requests. I have a hard time imagining a case where support is established and both sides wouldn’t want to have relevant requests signed… but that is more a SHOULD than a MUST.

Along similar lines, this seems a bit onerous as it introduces requirements on the caller that have nothing to do with connected identity per se:

> It is however REQUIRED by this specification that if a UAC sends a CANCEL for its own PASSporT-protected INVITE request, that it include an Identity header with a valid PASSporT in the CANCEL.

Yeah, due to HERFP etc. CANCEL just doesn’t work – too many CANCELs can come from entities other than the UAC, so, it’s too complicated to try to make this work. I’ve downgraded this text to say that it is not forbidden for UACs to send CANCELs for their own requests, but that relying parties should not expect to see them.

This too, seems like it is more appropraite as a SHOULD, in cases like I outline above where the div chain itself is not interesting to the caller:

> Mid-dialog requests also require special handling in diversion cases. Implementations compliant with this specification MUST validate the "div" chain back to the "rsp" PASSporT on any Identity header field values received in responses.

This is another case where, again, the sentence out of context reads wrong and needed a fix. I still think that if you are going to rely on “div” for these redirection cases, you do need the “div” chain to actually validate the “rsp”. But we don’t want to turn that into a MUST for validation for those people whose local policy is just not to care about “div” at all.

Thanks again.

--
Jonathan Rosenberg, Ph.D.
[e-mail]<mailto:[e-mail]>
http://www.jdrosen.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jdrosen.net_&d=DwMFaQ&c=7gn0PlAmraV3zr-k385KhKAz9NTx0dwockj5vIsr5Sw&r=rQo6AhlF8tKhxgONBTTPp2dKudYXajoA6N78vvkOkzA&m=PWlNE9fIu4EkzmoZJeJjofVZXbYbi6kFJ4ueYnKoFUOJxssIifRgINsvlNbSiLSB&s=8-bwIJlWl9oKmaC072A7pGrwevBdj2Dz2B9HnBCYRd4&e=>