Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

From: N WEINRONK <[email-masked]>
Date: Thu, 6 Oct 2016 00:33:09 +0100 (BST)

Thanks for this document.
 
I have some comments on this version.

4.1.1 para 2: I note the recommendation of the compact form
of PASSporT here. 
I do have concern over B2BUAs actions on Date header. Will B2BUA
actions (stripping / replacing this header) actually mean that everyone in
reality will have to use the full format of PASSporT anyway and probably without does the repeat after failure on the compact form ?

General: Use of the “dest” identity:
I am aware of some services that alter the To header – for
example 3GPP diversion service can do this – does this mean that we should
remove reliance on “dest” ?
Is there any privacy concern with allowing the ‘verification
service’ to identify the original ‘to header’ (full form) when the request
could have been redirected ?
I am aware of some service codes that have * and # not just as
the leading number dialled eg. *24#1# - again could we do anything to remove
reliance on ‘dest’ ?

6.1 step 3: Certain features can cause INVITEs to arrive at
terminating UA more than 1 minute after the call originated – for example diversion
chains - these would fail the 60 second logic but are valid calls.

6.2 step 1: Identity request –> Identity header ? 

6.2 step 1: Here we ignore not supported ppt but above we
reject them – which is correct ?

6.2 step 4: “iat” value is later – do you really mean earlier
here not later – I think you are trying to cover the case where the Date header
has been added along the way so will the “iat” not be earlier ?

6.2 step 5: typo – that the that the

8 last para: Reword around - could itself could

8 para 2: Would you expect the p-asserted-id in the PASSporT
to be in a different field than the 1 the From is in so it can be distinguished
at the terminating end ?

8.3 Why is the ABNF here limited to 1 DIGIT – in fact do you
need tn-spec in this version of the document ?

11 para 5: I am a little confused here before in the document
you talked about using p-asserted-id instead of from (section 8) but now I
think this is a different case – but it is not clear to me.
 
Thanks,
Nigel

---

From: Richard Shockey <[email-masked]>
Date: Thu, 06 Oct 2016 19:58:03 -0400

In line 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of N WEINRONK <[email-masked]>
Reply-To: <[email-masked]>
Date: Wednesday, October 5, 2016 at 7:33 PM
To: <[email-masked]>
Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

 

4.1.1 para 2: I note the recommendation of the compact form of PASSporT here. 

I do have concern over B2BUAs actions on Date header. Will B2BUA actions (stripping / replacing this header) actually mean that everyone in reality will have to use the full format of PASSporT anyway and probably without does the repeat after failure on the compact form ?

RS> In the United States carrier profile of STIR aka SHAKEN, you must use the full form of PASSporT.    There will be more on this after October 26.  

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

---

From: Alan Ford <[email-masked]>
Date: Thu, 13 Oct 2016 08:56:30 +0100

Hi Richard,

> On 7 Oct 2016, at 00:58, Richard Shockey <[email-masked]> wrote:
> 

Given this, and given my previously expressed thoughts that the scenarios in which compact would be useful in the SIP world are limited, is there any need for compact form at all?

Regards,
Alan

---

From: Richard Shockey <[email-masked]>
Date: Thu, 13 Oct 2016 10:15:08 -0400

I never understood the need for the compact form.   Compact was a silly idea IMHO.    

From: stir <[email-masked]> on behalf of Alan Ford <[email-masked]>
Date: Thursday, October 13, 2016 at 3:56 AM
To: Richard Shockey <[email-masked]>, <[email-masked]>
Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

Hi Richard,

Regards,

Alan

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Oct 2016 16:57:02 +0000

I'll be implementing most of the fixes in Nick's comments along with other last call comments at the end of the week, but I did want to speak to this one issue in particular:

It's interesting - speculating about what B2BUAs might do is part of what inspired the compact form in the first place. Long before we tried to distinguish full from compact form or indeed incorporated PASSporT, the original specification of "canon" as the canonical original telephone number was kept optional as an Identity parameter in part because, as Hadriel and others feared, any place where that telephone number appeared in the message it could be a potential target for SBC modification. If SBCs want to modify the number in the From, do we really think we're going to stump them by putting a copy of the number in the "canon" parameter two headers down? They'll just go change that one too, it was argued. But by instead having the two ends do their own canonicalization, rather than trying to tunnel the canonicalized number from end to end in some special spot, we effectively removed the ability of SBCs to modify that canonical number. We wouldn't even need a terminating-side verification service canonicalization pass if we didn't need to defend against this possibility of SBC interference.

What that means is that using the full form potentially makes the contents of the JWS header and payload a target for SBC modification - if the SBC is modifying the From header, why wouldn't an Identity-aware SBC modify the "orig" in the JWS payload too? The same argument can, unsurprisingly, be made for the Date header. The full form resend mechanism in there today is a compromise intended to try to address some specific legacy behavior that we see out there today. I consider it our best guess, but I think I'd like some deployment experience before I come down hard on either side of this issue.

The other motivation for compact form was just to save space in more constrained environments: not to add redundant bytes to the message unless you need to. Full form adds bytes, and it isn't a particularly small number of bytes. This is basically the motivation given in JWS Appendix F for having an abbreviated form of the payload when its being used in such an environment. Our usage of compact form here is well within the spirit of JWS design.

Does all of this add up to a RECOMMENDED compact form? It's real close. We could take out the recommendation and just leave this up to the STIR profiles to decide for themselves when they want to use compact or full, if people feel strongly about it.

Are there other profiles of STIR than SHAKEN under development? Yes, if you consider SIPBRANDY a profile, which we probably should. It could use the compact form.

Jon Peterson
Neustar, Inc.

---

From: Alan Ford <[email-masked]>
Date: Thu, 13 Oct 2016 18:43:32 +0100

Hi Jon,

I admit I came to this late, and so never saw this initial discussion you refer to, but I am really confused by what you write below. I hope you can clear up my confusion; comments inline...

> It's interesting - speculating about what B2BUAs might do is part of what inspired the compact form in the first place. Long before we tried to distinguish full from compact form or indeed incorporated PASSporT, the original specification of "canon" as the canonical original telephone number was kept optional as an Identity parameter in part because, as Hadriel and others feared, any place where that telephone number appeared in the message it could be a potential target for SBC modification. If SBCs want to modify the number in the From, do we really think we're going to stump them by putting a copy of the number in the "canon" parameter two headers down? They'll just go change that one too, it was argued.

OK, I can see that...

> But by instead having the two ends do their own canonicalization, rather than trying to tunnel the canonicalized number from end to end in some special spot, we effectively removed the ability of SBCs to modify that canonical number.

...But this I don’t. Since if they modified what was carried in the canon / full form, the signature would no longer verify.

If they rewrote the signature, it would be from a certificate which isn’t authorised to represent that source domain.

Or if it is authorised, then they could do that to the compact form too.

So what exactly are you protecting against here?

> We wouldn't even need a terminating-side verification service canonicalization pass if we didn't need to defend against this possibility of SBC interference.

Right now this statement makes no sense to me - but if I can understand what threat you are protecting against above, this may make sense!

> What that means is that using the full form potentially makes the contents of the JWS header and payload a target for SBC modification - if the SBC is modifying the From header, why wouldn't an Identity-aware SBC modify the "orig" in the JWS payload too? The same argument can, unsurprisingly, be made for the Date header.

Sure it could, but it would also have to rewrite the signature. And if it couldn’t do so, since it doesn’t have an appropriate certificate, it would no longer verify. Which is surely what you want?

> The other motivation for compact form was just to save space in more constrained environments: not to add redundant bytes to the message unless you need to. Full form adds bytes, and it isn't a par…

Certainly fair, however if you start to throw around 6KB SDPs (which is the norm in the video SIP world), the size of the Identity header suddenly doesn’t seem so significant.

> Does all of this add up to a RECOMMENDED compact form? It's real close. We could take out the recommendation and just leave this up to the STIR profiles to decide for themselves when they want to u…

That seems reasonable.

Regards,
Alan

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Oct 2016 18:03:35 +0000

The distinction I am drawing is between the verifier using the bit-exact version of the originating telephone number in "canon" versus a verifier performing its own canonicalization procedure on the From header field. In the former case, if the SBC modifies "canon", obviously the signature won't be valid. In the latter case, provided that whatever is in the From can be canonicalized by the verifier, it uses that.

This argument (and again, to be clear, it was not my argument at the time) is effectively a regress argument. If we're afraid that SBCs could modify field A, we are tempted to create field A-prime which contains the "real" value of A, just in case A gets modified by an SBC. The problem is that as long as A-prime also goes through the SBC, the SBC can (and surely will) modify A-prime too - SBCs modify A in the first place to enforce some policy or constraint, and those policies apply equally well to A-prime. "canon" was just an A-prime in its original incarnation. The full form of PASSporT is readily analogous.

I don't mean creating a new PASSporT or redoing the signature.

Sure, hypothetically.

By forcing both sides to build their own "real" version of A (the canonical telephone number) rather than having the originating side generate an A-prime that would be used by the terminating side, we remove the ability of an SBC to modify A-prime - because there is no A-prime. Instead the SBC can just modify A, but our canonicalization on the verifier side is (supposedly anyway) sufficient to turn that modified A into the "real" A.

I do get that this is a complicated argument: this was however the argument that moved the working group back in the day. I hesitate to reopen this discussion, but I do think people really need to understand that if we think using "iat" solves the problem of SBCs altering Date, it only does partially: it solves the problem of some legacy SBC modifying Date, but why is Date modified in the first place? Will the policies and constraints that cause that today extend to Identity-aware SBCs, as they come into being? The problem with designing anything that is supposed to cope with SBCs is that SBCs are undefined entities with unlimited powers. We need to see what happens in deployment to see how effective full form is at addressing this problem.

Jon Peterson
Neustar, Inc.

---

From: Alan Ford <[email-masked]>
Date: Thu, 13 Oct 2016 21:06:36 +0100

Hi Jon,

Thanks for the feedback. Comments inline… I think I’ve got what this is all about at long last, but I’ve left thought processes in place in case I’ve still got the wrong end of the stick ;-)

> On 13 Oct 2016, at 19:03, Peterson, Jon <[email-masked]> wrote:
> 
>> 

But in the latter case, the signature still won’t be valid. Unless it can be canonicalised to the same thing. In which case it is valid.

Are you saying that is if something’s in canon, the verifier may look at that and treat it as gospel, and assume that even though the From header has been changed, it “must” be a valid canonicalisation since the signature verifies? Surely that’s not what you’re saying?

If full form / canon is present, then surely the verifier must know if it is a valid canonicalisation (by its own rules) before it chooses whether to validate the signature?

> This argument (and again, to be clear, it was not my argument at the time) is effectively a regress argument. If we're afraid that SBCs could modify field A, we are tempted to create field A-prime…

Yes, that’s fine. However, A is not protected by a signature, but A-prime is. So given it’s protected, what’s the problem that canon / full form introduces?

> By forcing both sides to build their own "real" version of A (the canonical telephone number) rather than having the originating side generate an A-prime that would be used by the terminating side,…

Ah! Suddenly a lightbulb moment...

I’ve been coming at this from the wrong angle. I’ve been assuming we want to stop (or at least, detect) modification of A. But in fact, what you’re saying is you want to permit modification _as long as it can be canonicalised to the same thing_. Is that correct?

In which case I get this - I think.

However, the cases where this would be useful are surely limited. This requires the verifier to know and understand modifications that could be applied along the path by non-STIR-aware entities.

“Full form”, being base64 encoded, gets around a simple search/replace here, which is probably an improvement.

Regards,
Alan

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Oct 2016 17:35:44 +0000

Right, more or less. We can't prevent the modification of A whether we want to or not - and detecting that something has been changed is only helpful if you know that changing things is a problem - and for the kinds of changes we observe in the wild, it usually isn't a problem. What we're trying to resist in the design is the temptation to invent an A-prime with the delusional assumption that it would be safe to give A-prime integrity protection, because we intermediaries will modify A but spare A-prime. As long as there are SBCs, we have to admit the possibility that anything in the message might be modified. But yes, we want to permit A to be modified, and we do just assume that the modifications performed will permit relying parties to canonicalize the eventual value of A to the same bit-exact string (the "real" A) that the creator of the PASSporT canonicalized it to.

The verifier doesn't have to anticipate or understand the modifications performed by intermediaries, it just needs to be able to look at the end result of those modifications and perform a canonicalization procedure.

This is the basically the same discussion we were previously having on the list about the value of canonicalization. I submit, anyway, that the sorts of modifications that are practically applied by non-STIR-aware entities will still result in call signaling being routable, and that in those conditions the canonicalization we've detailed will work. We can of course imagine that entities will do weird things to telephone numbers that will make canonicalization impossible, but in those cases calls probably won't route or work well anyway. There was a chorus of voices on this list saying things to the effect that operators have dealt with this since time immemorial. I don't think there's a practical problem here. It'll work when it works, and in cases where it doesn't work, identity shouldn't be verifiable.

I don't think that would be material. If this would fix it, then we could have used the original "canon" parameter and rot13'd it. The policies are the problem, not the encoding.

Jon Peterson
Neustar, Inc.

Regards,
Alan