Re: [stir] a syntax change

"Peterson, Jon" <> Thu, 14 July 2016 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0E2E12D869 for <>; Thu, 14 Jul 2016 14:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AfbhOGSXgm4r for <>; Thu, 14 Jul 2016 14:24:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5FF812D82A for <>; Thu, 14 Jul 2016 14:24:22 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u6ELMnp5024750; Thu, 14 Jul 2016 17:24:18 -0400
Received: from ([]) by with ESMTP id 242wcqhhaa-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jul 2016 17:24:18 -0400
Received: from ([]) by ([]) with mapi id 14.03.0279.002; Thu, 14 Jul 2016 17:24:17 -0400
From: "Peterson, Jon" <>
To: Chris Wendt <>
Thread-Topic: [stir] a syntax change
Thread-Index: AQHR2W7bzsTobHl6sEOOeZEJkt6dxqATONnwgAAE6VuAAQEyAIAECBUA
Date: Thu, 14 Jul 2016 21:24:16 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D3AD4D531A61E9jonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607140227
Archived-At: <>
Cc: IETF STIR Mail List <>, Christer Holmberg <>
Subject: Re: [stir] a syntax change
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jul 2016 21:24:25 -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 <<>>
Date: Monday, July 11, 2016 at 5:50 PM
To: Jon Peterson <<>>
Cc: Christer Holmberg <<>>, IETF STIR Mail List <<>>
Subject: Re: [stir] a syntax change

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.



On Jul 11, 2016, at 7:29 AM, Peterson, Jon <<>> wrote:

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 <<>> wrote:


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?



From: stir [] On Behalf Of Peterson, Jon
Sent: 09 July 2016 02:17
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.

This will result in PASSporT claims like the following:

      { "orig":{"tn":"12155551212"},


        "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.

stir mailing list<>