Subject: [stir] Comments on draft-peterson-passport-divert-01

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Jun 2017 09:42:24 -0500

Are Identity Header field values ordered? (I don't think so - I think 
they form
an unordered set, and if some intermediary reordered them it wouldn't change
what they mean). I ask because this draft talks about "earlier PASSport"s. I
suggest that langauge be changed to say a "different PASSport" and where
applicable "already in the message".

(Aside: I wonder if we created unnecessary complexity by not allowing the
passports to appear comma separated on a single Identity: line so it 
could be
handled like a generic header field.)

The first paragraph of 4.1 could be misread to say you are replacing an
Identity header field value rather than adding a new one. You could 
avoid that
by saying "The resulting compact form Identity header field value to add 
to the
message" or better, expand the example to show before and after.

In the second paragraph of 4.2, I think it would be good to point back to
4474bis for what to do when there are invalid Identity header field values.

The Security Considerations section says "the only consequence will be that
downstream entities will have less confidence that the PASSport was mean 
to be
associated with this call". I don't think that's quite right. If the call is
retargetted and no PASSport is created for the retargetting, the 
recipient must
treat the original PASSport as invalid and thus must ignore it.

Nits:

Abstract: "originally destination"

Introduction : "numebr"

Section 3: 3rd paragraph. The second sentence (starting 'The "orig" 
value MUST
be copied' is very complex - can it be separated into several sentences?

The document needs to use "header field" and "header field value" a lot of
places it currently uses "header"

---

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Jun 2017 12:48:29 -0500

On 6/16/17 12:31 PM, Peterson, Jon wrote:
>
> I think we can clarify these fairly easily for the most part. I don't
> think Identity header field values are ordered, no. And definitely we
> should be clear that we're not telling anyone to delete prior PASSporTs.
> And much thanks for the nits.
>
> To this point though:
>
>> downstream entities will have less confidence that the PASSport was meant
>> to be
> Let's say I have call forwarding set up from my office phone to my cell
> phone, and imagine my cell has a verification service built in to it. If
> my office retargets a call and no PASSporT is created for the retargeting,
> when I receive the SIP request with a PASSporT (provided it's full form),
> my phone could inspect the "dest" and see that the original called number
> was my office phone. I imagine the phone could render that information to
> me: "hey, this call is signed, but it was signed 'to' this number - that
> okay?". If I saw that, I wouldn't be confused about the situation - I'd be
> less confident than I might be with a "div", but still pretty confident.
> So I'd say "must treat as invalid" is too strong. In general I hesitate to
> nail down the authorization policies that way because it might close doors
> we want to keep open.
How is this different than just showing every passport that doesn't 
match this call
to the user? I need to go look at the base spec again, but isn't a 
passport that
doesn't "match" the call by definition invalid?

> Jon Peterson
> Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Jun 2017 17:31:28 +0000

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Jun 2017 18:01:09 +0000

Well, define "matching" the call. When dealing with compact form, the
verifier reconstructs the PASSporT from the "To", so if the "To" were
changed by the retarget and no new PASSporT were issued, that would result
in a validation fail. (Of course, if the retargeter just changed the
Request-URI like you're supposed to, that wouldn't be a fail.)

Now, if you have a full-form PASSporT, it will at least be clear which
"dest" was signed - the text in rfc4474bis does rather pointedly say that
using full form can "avoid unnecessary signature breakage caused by
intermediaries that alter certain SIP header fields in transit." That text
(which is from 6.2.4) is not so generous about "orig" - it insists that
"orig" has to match the SIP request, but not "dest".

So yes, I wouldn't want to render a call that has a non-matching "orig" or
an expired "iat" - but I might be more lenient about "dest".

Jon Peterson
Neustar, Inc.

On 6/16/17, 1:48 PM, "Robert Sparks" <[email-masked]> wrote:

>>> associated with this call". I don't think that's quite right. If the
>>>call
>>> is

---

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Jun 2017 15:47:03 -0500

> an expired "iat" - but I might be more lenient about "dest".
We're close to the same page, but unless your phone was told ahead of time
that it was ok to treat this random "dest" as something it should recognize
as one of its own, I think there's a problem with the leniency you suggest.

With what you're proposing, Adam could call me, I copy his valid 
passport for the call to me,
and before iat expires, I paste it into a call to you (reusing Adam's 
call's To and From numbers,
but putting your number in the request URI). How are you going to tell 
that apart from a legitimate
call from Adam that got retargetted but no div passport got added?

The checks against "dest" were what were supposed to keep you from 
believing my call was legitimate, right?

So rather than "phone asks if it's ok" I think you're really wanting "I 
told my phone ahead of time that it's ok".
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir