IETF Logo Mail Archive

Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

Hadriel Kaplan <hadriel.kaplan@oracle.com> Wed, 17 July 2013 14:13 UTC

Return-Path: <hadriel.kaplan@oracle.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 301C921E8064 for <stir@ietfa.amsl.com>; Wed, 17 Jul 2013 07:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.982
X-Spam-Level:
X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, J_BACKHAIR_34=1, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW3hhbzo82yG for <stir@ietfa.amsl.com>; Wed, 17 Jul 2013 07:13:30 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8364621E8053 for <stir@ietf.org>; Wed, 17 Jul 2013 07:11:53 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6HEBpdg001652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <stir@ietf.org>; Wed, 17 Jul 2013 14:11:52 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6HEBXsV021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 14:11:33 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6HEBWx3024756; Wed, 17 Jul 2013 14:11:32 GMT
Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jul 2013 07:11:32 -0700
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <CAMcvRPCN-VnKajt0Mi_MNaj9S0UChHi=iOu_z7-dUA+idZgGvA@mail.gmail.com>
Date: Wed, 17 Jul 2013 10:11:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6870AFC-9C65-459E-9B1B-292976304D14@oracle.com>
References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com> <CAMcvRPC6f+0-sx=eGS-1yy=Ubh-WREw-__WZyeNnS1XypY+Xvg@mail.gmail.com> <7B23E7E8-2432-48B8-A2BF-75653D89936F@oracle.com> <CAMcvRPCN-VnKajt0Mi_MNaj9S0UChHi=iOu_z7-dUA+idZgGvA@mail.gmail.com>
To: Torrey Searle <tsearle@sipstacks.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 17 Jul 2013 14:13:37 -0000

On Jul 17, 2013, at 3:26 AM, Torrey Searle <tsearle@sipstacks.com> wrote:

> Hello,
> 
> Regarding the SIP <->XMPP inter-working of SUBSCRIBE.  Subscriptions in SIP are time limited, and last forever in XMPP, as a result, sip<->xmpp gateway may need to generate several SIP subscribes in response to a single XMPP subscribe.  Perhaps it's worthwhile to  note that only the Dialog Creating and Dialog Destroying subscriptions will have a signature, and the rest of the in-dialog requests should be considered trusted as well?

Yeah I'm cool with that - in fact, I'm not really sure we need dialog-destroying subscriptions to be supported for IKES.  Likewise a BYE doesn't really need IKES.
I mean this STIR stuff is really for the purpose of caller-id authentication, not in-dialog/in-call message dialog-matching verification. (and besides, middleboxes need to be able to generate BYEs successfully)
I only put them in the IKES draft to show they could be handled, because 4474 handles them... but if we move forward with the IKES draft I'd probably suggest we take the extraneous stuff out.

-hadriel

v2.23.0 | Report a Bug | By Email