Subject: [stir] a syntax change

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 8 Jul 2016 23:17:12 +0000

Attentive readers will observed a syntax change in passport-04 which carries over to rfc4744bis-10. Implementers, especially those looking forward to the SIPit coming up, should take note.

The change is to the claims of the PASSporT object. Rather than having two different versions of each claim to reflect the originating and destination side, such as "otn" and "dtn", there is now simply a "tn" claim. That claim will appear within a JSON array explicitly labeled as "orig" or "dest" in the PASSporT object.

This will result in PASSporT claims like the following:

      { "orig":{"tn":"12155551212"},
        "dest":{"tn":"12155551213"},
        "iat":"1443208345" }

The "dest" claim is specifically defined to allow one or more values, so it replaces the previous "dgrp" claim to be used in cases where a message has multiple destinations.

This eliminated the redundancy of having future extensions to the PASSporT claims identify whether they carried an identifier for the originating or destination side. Now, new claim definitions simply have to state that they contain identifiers: the semantics of the identifier will depend on whether it appears under "orig" or "dest". In fact, PASSporT could probably work with some existing JWT claims now that represent identifiers. This seemed like a much better idea than the way we were doing it before.

This was a fairly last-minute fix, but it didn't require much spec change and is hopefully stable and consistent. Thoughts welcome.

Jon Peterson
Neustar, Inc.

---

From: "Di-Shi Sun" <[email-masked]>
Date: Mon, 11 Jul 2016 11:01:59 +0800

Does the example in draft-ietf-stir-passport-04 satisfy JSON rules? There
are two uri in dest but they are not array.

{

                "iat":"1443208345",

                "orig":{

                                "tn":"12155551212"

                },

                "dest":{

                                "uri":"sip:[email-masked]",

                                "tn":"12125551212",

                                "uri":"sip:[email-masked]"

                }

}

Thanks,

Di-Shi Sun.

From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Saturday, July 09, 2016 7:17 AM
To: IETF STIR Mail List
Subject: [stir] a syntax change

Attentive readers will observed a syntax change in passport-04 which carries
over to rfc4744bis-10. Implementers, especially those looking forward to the
SIPit coming up, should take note.

The change is to the claims of the PASSporT object. Rather than having two
different versions of each claim to reflect the originating and destination
side, such as "otn" and "dtn", there is now simply a "tn" claim. That claim
will appear within a JSON array explicitly labeled as "orig" or "dest" in
the PASSporT object. 

The "dest" claim is specifically defined to allow one or more values, so it
replaces the previous "dgrp" claim to be used in cases where a message has
multiple destinations.

This eliminated the redundancy of having future extensions to the PASSporT
claims identify whether they carried an identifier for the originating or
destination side. Now, new claim definitions simply have to state that they
contain identifiers: the semantics of the identifier will depend on whether
it appears under "orig" or "dest". In fact, PASSporT could probably work
with some existing JWT claims now that represent identifiers. This seemed
like a much better idea than the way we were doing it before.

This was a fairly last-minute fix, but it didn't require much spec change
and is hopefully stable and consistent. Thoughts welcome.

Jon Peterson

Neustar, Inc.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jul 2016 13:13:17 +0000

Hi,

Some time ago there was a discussion whether we should include the claims to begin with, as the information can be retrieved from other SIP information elements.

Did we make a conclusion on that?

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: 09 July 2016 02:17
To: IETF STIR Mail List <[email-masked]>
Subject: [stir] a syntax change

        "iat":"1443208345" }

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Jul 2016 13:29:55 +0000

I don't think we took a formal consensus call, or what have you. What we did do though is to include in rfc4474bis a URI normalization procedure that we hope will obviate the ambiguity about URI comparisons you raised.

I still think the message size reduction is worth the complexity trade-off to permit "canon" not to be included - and if it is allowed to be absent at all, then I think by default it should be absent.

Jon Peterson
Neustar, Inc.

Sent from my iPad

On Jul 11, 2016, at 9:13 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: 09 July 2016 02:17
To: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: [stir] a syntax change

        "iat":"1443208345" }

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Mon, 11 Jul 2016 18:31:22 -0600

Hi Di-Shi,

Good catch, yes we must wrap the identity name/value pairs with brackets as an array if there is more than one.

Thanks.

-Chris

> On Jul 10, 2016, at 9:01 PM, Di-Shi Sun <[email-masked]> wrote:
> 
> Does the example in draft-ietf-stir-passport-04 satisfy JSON rules? There are two uri in dest but they are not array.
>  
> {
>                 "iat":"1443208345",
>                 "orig":{
>                                 "tn":"12155551212"
>                 },
>                 "dest":{
>                                 "uri":"sip:[email-masked] <sip:[email-masked]>",
>                                 "tn":"12125551212",
>                                 "uri":"sip:[email-masked] <sip:[email-masked]>"
>                 }
> }
>  
> Thanks,
>  
> Di-Shi Sun.
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Chris Wendt <[email-masked]>
Date: Mon, 11 Jul 2016 18:50:28 -0600

Relevant to this topic, I think one other valid discussion point that we may or may not have talked about on the list or face to face is how often we think the date header will be changed in transit.

The current rule is if signature verification fails a 438 is sent back and the authentication service should sent the INVITE with an identity header with canon parameter and the full token with the date explicitly included.

If we believe the date header will be changed often, then we obviously don’t want a high percentage of SIP calls creating 438 errors to force new INVITES (or effectively sending INVITEs twice)

Perhaps, for some real-world applications there is a low chance of a date header change because the call path is fairly predictable, and the cases where a 438 happens is very rare.  Then favoring the current default is correct.  

But, for example, in situation where many B2BUAs are part of the application, you may have a very decent chance that someone is going to change a date header out of your control, we may want canon because sending the invite twice is more expensive than saving the header and claims bytes in the first place.

One approach is rely on industry SIP profile documents to define such things to send “canon” for every call.  I don’t think anything in 4474bis prevents that, correct me if I’m wrong Jon.

The question I think would be good to get more input on is if date header changes are more common or rare in most peoples operational experience. 

Thanks.

-Chris

> On Jul 11, 2016, at 7:29 AM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> On Jul 11, 2016, at 9:13 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi,
>>  
>>   <>
>> From: stir [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Peterson, Jon
>> Sent: 09 July 2016 02:17
>> To: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jul 2016 20:57:22 +0000

Hi,

>I don't think we took a formal consensus call, or what have you. What we did do though is to >include in rfc4474bis a URI normalization procedure that we hope will obviate the ambiguity >about URI comparisons you raised.

Thanks, I'll have a look :)

>I still think the message size reduction is worth the complexity trade-off to permit "canon" not >to be included - and if it is allowed to be absent at all, then I think by default it should be >absent.

The claims are allowed to be absent, if they can be retrieved in other ways. It is described in Appendix F of RFC 7315.

Regards,

Christer

Sent from my iPad

Regards,

Christer

        "iat":"1443208345" }

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 14 Jul 2016 21:24:16 +0000

Well, many of the same B2BUAs that today alter the Date header surely strip the Identity header as well, as they strip virtually any header that is not specifically authorized. There is a certain amount we can and should do to accommodate such devices, but its a two-way street - reconfiguring such devices to accept Identity while still munging Date might be counterproductive.

That much said, yes, rfc4474bis-10 certainly allows sending "canon" without first receiving a 438. Maybe the answer is a deployment profile, as you suggest, for environments where it is known to be a problem. If that turns out to be "all meaningful environments" well... then in time we migrate the base standard in that direction. The point is, if it turned out that we always needed "canon," then we should design the header in such a way that "canon" isn't even a parameter, and just carry the raw PASSporT object. We should avoid options where we don't think they're useful, especially when it comes to security mechanisms. But until we're sure it isn't useful, I think the guidance we have now is what we should stick with.

Jon Peterson
Neustar, Inc.

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 5:50 PM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] a syntax change

Thanks.

-Chris

On Jul 11, 2016, at 7:29 AM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.

Sent from my iPad

Hi,

Regards,

Christer

        "iat":"1443208345" }

Jon Peterson
Neustar, Inc.

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

---

From: Eric Burger <[email-masked]>
Date: Mon, 18 Jul 2016 21:16:20 -0400

I agree with Jon. There is only so much we can do to support MITM attacks. At a certain point, if something hacks SIP to the point the signaling is unintelligible, the signaling is unintelligible.

> On Jul 14, 2016, at 5:24 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> From: Chris Wendt <[email-masked] <mailto:[email-masked]>>
> To: Jon Peterson <[email-masked] <mailto:[email-masked]>>
> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]>>, IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
>>> On Jul 11, 2016, at 7:29 AM, Peterson, Jon <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>