Re: [stir] a syntax change

Eric Burger <eburger@standardstrack.com> Tue, 19 July 2016 01:16 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3464E12DBBB for <stir@ietfa.amsl.com>; Mon, 18 Jul 2016 18:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level:
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz91-9UMAgVz for <stir@ietfa.amsl.com>; Mon, 18 Jul 2016 18:16:27 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7536912DB2D for <stir@ietf.org>; Mon, 18 Jul 2016 18:16:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=JssJ+T9vQA8YrHSd1ey8sPwWGf72EeG24tA3bumvEyI=; b=h9WVijUxLooh7PO0qX+Nr8gCVw 7HKRGosH24Ovk6pGaljE/V8ruoSzbQlhQJlknLd9e1PvB1irQUnLrnsyvvwiSGNpiYiIRRb5Lvq80 uSPYO8rKjWqjs4AsBDulGoaSKhEm+YlapEzJalyMgPEk2NGqRgEkaGA4BPA4hQEzO1aw=;
Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:52387 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <eburger@standardstrack.com>) id 1bPJe1-0001UZ-S3 for stir@ietf.org; Mon, 18 Jul 2016 18:16:26 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_ACC8C9E6-6260-4CF9-83D5-A9DA6F728074"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Pgp-Agent: GPGMail
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <D3AD4D53.1A61E9%jon.peterson@neustar.biz>
Date: Mon, 18 Jul 2016 21:16:20 -0400
Message-Id: <0C0703AE-CD3F-456A-A482-89DCC45BF7D3@standardstrack.com>
References: <D3A58289.1A58E7%jon.peterson@neustar.biz> <7594FB04B1934943A5C02806D1A2204B476855E5@ESESSMB208.ericsson.se> <2EF2D1DC-A510-42A8-BAA9-C2058F9EA782@neustar.biz> <96FA6E44-83FF-41B1-A8C3-63620B813937@chriswendt.net> <D3AD4D53.1A61E9%jon.peterson@neustar.biz>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/AnUsgR64Et0_68dzZIf4nMha95U>
Subject: Re: [stir] a syntax change
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2016 01:16:31 -0000

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 <jon.peterson@neustar.biz> wrote:
> 
> 
> 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 <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>>
> Date: Monday, July 11, 2016 at 5:50 PM
> To: Jon Peterson <jon.peterson@neustar.biz <mailto:jon.peterson@neustar.biz>>
> Cc: Christer Holmberg <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>>, IETF STIR Mail List <stir@ietf.org <mailto:stir@ietf.org>>
> 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.
>> 
>> Thanks.
>> 
>> -Chris
>> 
>>> On Jul 11, 2016, at 7:29 AM, Peterson, Jon <jon.peterson@neustar.biz <mailto:jon.peterson@neustar.biz>> 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 <christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com>> wrote:
>>> 
>>>> 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:stir-bounces@ietf.org <mailto:stir-bounces@ietf.org>] On Behalf Of Peterson, Jon
>>>> Sent: 09 July 2016 02:17
>>>> To: IETF STIR Mail List <stir@ietf.org <mailto:stir@ietf.org>>
>>>> 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"},
>>>>         "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.
>>>> 
>>>> 
>>> _______________________________________________
>>> stir mailing list
>>> stir@ietf.org <mailto:stir@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir