From nobody Fri Sep 2 11:03:48 2016 Return-Path: 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 32F6F12D1DC for ; Fri, 2 Sep 2016 11:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zipdx.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 t8BI4nobpimD for ; Fri, 2 Sep 2016 11:03:45 -0700 (PDT) Received: from xdev1sjc.zipdx.com (sjc-e-66.zipdx.com [166.88.23.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A60A12D1BC for ; Fri, 2 Sep 2016 11:03:44 -0700 (PDT) Received: from DPFyoga (c-73-15-29-134.hsd1.ca.comcast.net [73.15.29.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: dfrankel) by xdev1sjc.zipdx.com (Postfix) with ESMTPSA id 66B3A1B80296 for ; Fri, 2 Sep 2016 11:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=zipdx.com; s=default; t=1472839423; bh=Uk7azChLzFGcriyfHXL/imKbE5zonOnDhAMOVNG9QOg=; h=From:To:Subject:Date:From; b=ZUvVLvN98hpBmL7NUSiRt1lpWeFzKQRumXPqNOgkAtTFuGLxa9L2MBUYYcBk1RouX s8UVgyOoux25sc6aS9znzb+5MEt/PZw9bvVS7dmZN1FB6WoAHoIhb7MQYY9RtTgM3U w/kV1KDHv2TFqeVqJaHaJ2f8xWSJ24kPms/bg2ZI= From: "David Frankel" To: Date: Fri, 2 Sep 2016 11:03:43 -0700 Organization: ZipDX LLC Message-ID: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EFA_01D20509.AB6EB710" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+g== Content-Language: en-us Archived-At: Subject: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 18:03:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0EFA_01D20509.AB6EB710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings. I find myself worried about the following text in the 4474bis draft at 4.1: "Fourth, if the request contains an SDP message body, and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] Section 3.2.2.2." As I understand it, this is done to ensure that the fingerprint has not been altered (perhaps by a "man in the middle") and give confidence that the media is encrypted end-to-end. However, I fear that this may break STIR in some not-entirely-uncommon situations. Public network SIP calls are routinely re-originated (as we've discussed). Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream as well as the SIP messaging. For example, a transit operator might need to transcode the audio if the operators on either side don't have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reality may be that anybody that can handle a-law can handle mu-law, so transcoding should "never" be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA) the interceptor would still be able to LISTEN without altering the fingerprint, so perhaps that wouldn't break the STIR signature. I raise the point for discussion. (The details here are a bit outside my expertise, and I probably missed some earlier discussion.) One possible suggestion is to change "MUST" to "MAY" in the text I quoted above. This gives the originator of the call the opportunity to decide whether they want downstream operators to have the flexibility to alter the fingerprint but still maintain the end-to-end identity assurance offered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn't recall it in the STIR charter or problem statement. David David Frankel ZipDXR LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! ------=_NextPart_000_0EFA_01D20509.AB6EB710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings.

 

I find = myself worried about the following text in the 4474bis draft at = 4.1:

 

“Fourth, if the request contains an SDP message = body, and if that SDP contains one or more "a=3Dfingerprint" = attributes, then the JSON key "mky" MUST appear with the = algorithm(s) and value(s) of the fingerprint attributes (if they = differ), following the format given in [I-D.ietf-stir-passport] Section = 3.2.2.2.”

 

As I = understand it, this is done to ensure that the fingerprint has not been = altered (perhaps by a “man in the middle”) and give = confidence that the media is encrypted end-to-end.

 

However, I = fear that this may break STIR in some not-entirely-uncommon situations. = Public network SIP calls are routinely re-originated (as we’ve = discussed). Sometimes the RTP will still go end-to-end unaltered, but in = other cases it may be necessary to terminate and re-originate the stream = as well as the SIP messaging. For example, a transit operator might need = to transcode the audio if the operators on either side don’t have = matching codecs. For example, a transit operator might transcode = wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and = G.711. Or possibly between G.711 a-law and mu-law. (The reality may be = that anybody that can handle a-law can handle mu-law, so transcoding = should “never” be required for G.711.) There could be other = examples. I guess for lawful intercept (CALEA) the interceptor would = still be able to LISTEN without altering the fingerprint, so perhaps = that wouldn’t break the STIR signature.

 

I raise the = point for discussion. (The details here are a bit outside my expertise, = and I probably missed some earlier discussion.) One possible suggestion = is to change “MUST” to “MAY” in the text I = quoted above. This gives the originator of the call the opportunity to = decide whether they want downstream operators to have the flexibility to = alter the fingerprint but still maintain the end-to-end identity = assurance offered with STIR. An originator may be mostly concerned with = protecting their media on the first hop; this would let them do that (I = think).

 

While protecting the fingerprint is a nice-to-have, I = didn’t recall it in the STIR charter or problem = statement.

 

David

 

David Frankel

ZipDX® LLC

Monte Sereno, CA = USA

Tel: 1-800-FRANKEL = (1-800-372-6535)

Watch Our Video!

 

------=_NextPart_000_0EFA_01D20509.AB6EB710-- From nobody Fri Sep 2 12:02:13 2016 Return-Path: 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 6354F12B006 for ; Fri, 2 Sep 2016 12:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pQbUilG5BwAq for ; Fri, 2 Sep 2016 12:02:10 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3C01288B8 for ; Fri, 2 Sep 2016 12:02:09 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-2a-57c9ccaeecd4 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 4B.2D.02553.EACC9C75; Fri, 2 Sep 2016 21:02:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0301.000; Fri, 2 Sep 2016 21:02:05 +0200 From: Christer Holmberg To: David Frankel , "stir@ietf.org" Thread-Topic: [stir] RFC 4474bis Last Call - Fingerprint Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+gADJY7A Date: Fri, 2 Sep 2016 19:02:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> In-Reply-To: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC829D5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbFdRXfDmZPhBtu/sFmc/j2BxWL52m1M DkweS5b8ZPJo6PnCFsAUxWWTkpqTWZZapG+XwJXxs7+XqaAtvWLW0Q2MDYzrI7sYOTkkBEwk +tdfY+ti5OIQEljPKHH+7jUWCGcxo8SfIwtYuxg5ONgELCS6/2mDmCIC7hJTl6qA9AoLmEvc 3viHHcQWAarYeGMhE4RtJHGs6y0bSDmLgIrE1PsCICavgK/Etz+cIBVCQJ3Tm7eAdXICdZ45 e4MFxGYUEJP4fmoN2BRmAXGJW0/mM0FcKSCxZM95ZghbVOLl43+sELaSROOSJ2A3MgvkSyxf EwIS5hUQlDg58wnLBEbhWUgmzUKomoWkCqJER2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/F KFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERg1B7f8NtjB+PK54yFGAQ5GJR7eB60nw4VYE8uK K3MPMUpwMCuJ8MadBArxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQWgST ZeLglGpg1P/27Pqd/QW55jVRWut2rU89s2hGbVznpcCZd6ebR8aXXJpY+jZ9d/J3TlfZZbHB h51e3b0zz227fwfHfoXHX8IdYj4k1HJuPV77IfvE9c9Fles9/V8/Np1TG6S2w2pLbrW1ofT+ 3yV5vlYXly9d8zeCy0HxQZKTVolA8A6xEiGlO63rp7x3VmIpzkg01GIuKk4EAM8oujiWAgAA Archived-At: Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 19:02:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC829D5ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In addition to the cases David presented, there can also be an intermediary= disables media by setting the m=3D line port value to zero. In such cases = the intermediary may also remove all fingerprint attributes associated with= the m=3D line. And, even if all fingerprints sent by the signer reach the verifier, there = is no guarantee they will be in the same matter. Not sure whether it matter= s as far as calculating the signature is concerned, but just to keep in min= d... In general, assuming we are going to use (or at least allow) Appendix F, we= cannot change any "MUST" to "MAY", because we need to specify exactly what= content is used to calculate the signature, as that information will not b= e carried in the SIP message. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel Sent: 02 September 2016 21:04 To: stir@ietf.org Subject: [stir] RFC 4474bis Last Call - Fingerprint Greetings. I find myself worried about the following text in the 4474bis draft at 4.1: "Fourth, if the request contains an SDP message body, and if that SDP conta= ins one or more "a=3Dfingerprint" attributes, then the JSON key "mky" MUST = appear with the algorithm(s) and value(s) of the fingerprint attributes (if= they differ), following the format given in [I-D.ietf-stir-passport] Secti= on 3.2.2.2." As I understand it, this is done to ensure that the fingerprint has not bee= n altered (perhaps by a "man in the middle") and give confidence that the m= edia is encrypted end-to-end. However, I fear that this may break STIR in some not-entirely-uncommon situ= ations. Public network SIP calls are routinely re-originated (as we've disc= ussed). Sometimes the RTP will still go end-to-end unaltered, but in other = cases it may be necessary to terminate and re-originate the stream as well = as the SIP messaging. For example, a transit operator might need to transco= de the audio if the operators on either side don't have matching codecs. Fo= r example, a transit operator might transcode wideband audio between G.722.= 2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711= a-law and mu-law. (The reality may be that anybody that can handle a-law c= an handle mu-law, so transcoding should "never" be required for G.711.) The= re could be other examples. I guess for lawful intercept (CALEA) the interc= eptor would still be able to LISTEN without altering the fingerprint, so pe= rhaps that wouldn't break the STIR signature. I raise the point for discussion. (The details here are a bit outside my ex= pertise, and I probably missed some earlier discussion.) One possible sugge= stion is to change "MUST" to "MAY" in the text I quoted above. This gives t= he originator of the call the opportunity to decide whether they want downs= tream operators to have the flexibility to alter the fingerprint but still = maintain the end-to-end identity assurance offered with STIR. An originator= may be mostly concerned with protecting their media on the first hop; this= would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn't recall it in t= he STIR charter or problem statement. David David Frankel ZipDX(r) LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! --_000_7594FB04B1934943A5C02806D1A2204B4BC829D5ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In addition to the cases David presented, there can also be an interme= diary disables media by setting the m=3D line port value to zero. In such c= ases the intermediary may also remove all fingerprint attributes associated with the m=3D line.

 

And, even if all fingerprints sent by the signer reach the verifier, t= here is no guarantee they will be in the same matter. Not sure whether it m= atters as far as calculating the signature is concerned, but just to keep in mind…

 

In general, assuming we are going to use (or at least allow) Appendix = F, we cannot change any “MUST” to “MAY”, because we= need to specify exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

 

Regards,

 

Christer

 

 

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: stir@ietf.org
Subject: [stir] RFC 4474bis Last Call - Fingerprint

 

Greetings.

 

I find myself worried about the= following text in the 4474bis draft at 4.1:

 

“Fourth, if the request c= ontains an SDP message body, and if that SDP contains one or more "a= =3Dfingerprint" attributes, then the JSON key "mky" MUST app= ear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] S= ection 3.2.2.2.”

 

As I understand it, this is don= e to ensure that the fingerprint has not been altered (perhaps by a “= man in the middle”) and give confidence that the media is encrypted e= nd-to-end.

 

However, I fear that this may b= reak STIR in some not-entirely-uncommon situations. Public network SIP call= s are routinely re-originated (as we’ve discussed). Sometimes the RTP= will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream a= s well as the SIP messaging. For example, a transit operator might need to = transcode the audio if the operators on either side don’t have matchi= ng codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or betw= een G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reali= ty may be that anybody that can handle a-law can handle mu-law, so transcod= ing should “never” be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA= ) the interceptor would still be able to LISTEN without altering the finger= print, so perhaps that wouldn’t break the STIR signature.<= /span>

 

I raise the point for discussio= n. (The details here are a bit outside my expertise, and I probably missed = some earlier discussion.) One possible suggestion is to change “MUST&= #8221; to “MAY” in the text I quoted above. This gives the originator of the call the opportunity to decide whether they wa= nt downstream operators to have the flexibility to alter the fingerprint bu= t still maintain the end-to-end identity assurance offered with STIR. An or= iginator may be mostly concerned with protecting their media on the first hop; this would let them do that = (I think).

 

While protecting the fingerprin= t is a nice-to-have, I didn’t recall it in the STIR charter or proble= m statement.

 

David

 

David F= rankel

ZipDX® LLC

Monte S= ereno, CA USA

Tel: 1-= 800-FRANKEL (1-800-372-6535)<= /p>

Watch Our Video!

 

--_000_7594FB04B1934943A5C02806D1A2204B4BC829D5ESESSMB209erics_-- From nobody Fri Sep 2 12:04:49 2016 Return-Path: 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 7CA7812B006 for ; Fri, 2 Sep 2016 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 plPk0SzKtqLd for ; Fri, 2 Sep 2016 12:04:45 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE46C1288B8 for ; Fri, 2 Sep 2016 12:04:44 -0700 (PDT) X-AuditID: c1b4fb2d-917ff700000019a3-27-57c9cd49e0e1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id BF.96.06563.94DC9C75; Fri, 2 Sep 2016 21:04:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0301.000; Fri, 2 Sep 2016 21:04:40 +0200 From: Christer Holmberg To: Christer Holmberg , David Frankel , "stir@ietf.org" Thread-Topic: [stir] RFC 4474bis Last Call - Fingerprint Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+gADJY7AAABx/WA= Date: Fri, 2 Sep 2016 19:04:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC82A3E@ESESSMB209.ericsson.se> References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC82A3EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9Stfr7Mlwg77LNhanf09gsVi+dhuT A5PHkiU/mTwaer6wBTBFcdmkpOZklqUW6dslcGXM/v+ApWB6acXEq+4NjH1pXYwcHBICJhLf zyd2MXJxCAmsZ5S4sXQRO4SzmFHi6tXNLCBFbAIWEt3/tLsYOTlEBGoluhduZAexhQXMJW5v /MMOEbeQ2HhjIROEbSVxf+peFhCbRUBF4taauWwgNq+Ar8S7Lf9ZQWwhgWqJhVeOgdVzCvhJ LJs6kRHEZhQQk/h+ag1YnFlAXOLWk/lgtoSAgMSSPeeZIWxRiZeP/7FC2EoSjUuesIKcySyQ L3F8rRTEKkGJkzOfsExgFJ6FZNIshKpZSKogSnQkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2 VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBcXNwy2/dHYyrXzseYhTgYFTi4X3QejJciDWx rLgy9xCjBAezkghv3EmgEG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalF MFkmDk6pBkYdxVVsH+b7Z5XvnrqhsZQ9per8lTdOKSl3etznf+VaaqbwWf6LwMkPtv6Rm1zL nsgqzvPZu5uhwmHRk5ZFG2b/eDVN57Kl9wTja5t2um3zV9rYbpXR3/VUMfzLc4nnF54cFlu5 rErtkbNfSK34pswHu9OV9p8+nHpgxofp+0WW2+8VsJC/bLNKiaU4I9FQi7moOBEA9mLTcpcC AAA= Archived-At: Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 19:04:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC82A3EESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correction: "there is no guarantee they will be in the same ORDER". Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 02 September 2016 22:02 To: David Frankel ; stir@ietf.org Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint Hi, In addition to the cases David presented, there can also be an intermediary= disables media by setting the m=3D line port value to zero. In such cases = the intermediary may also remove all fingerprint attributes associated with= the m=3D line. And, even if all fingerprints sent by the signer reach the verifier, there = is no guarantee they will be in the same matter. Not sure whether it matter= s as far as calculating the signature is concerned, but just to keep in min= d... In general, assuming we are going to use (or at least allow) Appendix F, we= cannot change any "MUST" to "MAY", because we need to specify exactly what= content is used to calculate the signature, as that information will not b= e carried in the SIP message. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel Sent: 02 September 2016 21:04 To: stir@ietf.org Subject: [stir] RFC 4474bis Last Call - Fingerprint Greetings. I find myself worried about the following text in the 4474bis draft at 4.1: "Fourth, if the request contains an SDP message body, and if that SDP conta= ins one or more "a=3Dfingerprint" attributes, then the JSON key "mky" MUST = appear with the algorithm(s) and value(s) of the fingerprint attributes (if= they differ), following the format given in [I-D.ietf-stir-passport] Secti= on 3.2.2.2." As I understand it, this is done to ensure that the fingerprint has not bee= n altered (perhaps by a "man in the middle") and give confidence that the m= edia is encrypted end-to-end. However, I fear that this may break STIR in some not-entirely-uncommon situ= ations. Public network SIP calls are routinely re-originated (as we've disc= ussed). Sometimes the RTP will still go end-to-end unaltered, but in other = cases it may be necessary to terminate and re-originate the stream as well = as the SIP messaging. For example, a transit operator might need to transco= de the audio if the operators on either side don't have matching codecs. Fo= r example, a transit operator might transcode wideband audio between G.722.= 2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711= a-law and mu-law. (The reality may be that anybody that can handle a-law c= an handle mu-law, so transcoding should "never" be required for G.711.) The= re could be other examples. I guess for lawful intercept (CALEA) the interc= eptor would still be able to LISTEN without altering the fingerprint, so pe= rhaps that wouldn't break the STIR signature. I raise the point for discussion. (The details here are a bit outside my ex= pertise, and I probably missed some earlier discussion.) One possible sugge= stion is to change "MUST" to "MAY" in the text I quoted above. This gives t= he originator of the call the opportunity to decide whether they want downs= tream operators to have the flexibility to alter the fingerprint but still = maintain the end-to-end identity assurance offered with STIR. An originator= may be mostly concerned with protecting their media on the first hop; this= would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn't recall it in t= he STIR charter or problem statement. David David Frankel ZipDX(r) LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! --_000_7594FB04B1934943A5C02806D1A2204B4BC82A3EESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correction: “there is no guarantee they will be in the same ORDE= R”.

 

Regards,

 

Christer

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 02 September 2016 22:02
To: David Frankel <dfrankel@zipdx.com>; stir@ietf.org
Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint

 

Hi,

 

In addition to the cases David presented, there can also be an interme= diary disables media by setting the m=3D line port value to zero. In such c= ases the intermediary may also remove all fingerprint attributes associated with the m=3D line.

 

And, even if all fingerprints sent by the signer reach the verifier, t= here is no guarantee they will be in the same matter. Not sure whether it m= atters as far as calculating the signature is concerned, but just to keep in mind…

 

In general, assuming we are going to use (or at least allow) Appendix = F, we cannot change any “MUST” to “MAY”, because we= need to specify exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

 

Regards,

 

Christer

 

 

 

From: stir [mailto:stir-boun= ces@ietf.org] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: stir@ietf.org
Subject: [stir] RFC 4474bis Last Call - Fingerprint

 

Greetings.

 

I find myself worried about the= following text in the 4474bis draft at 4.1:

 

“Fourth, if the request c= ontains an SDP message body, and if that SDP contains one or more "a= =3Dfingerprint" attributes, then the JSON key "mky" MUST app= ear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] S= ection 3.2.2.2.”

 

As I understand it, this is don= e to ensure that the fingerprint has not been altered (perhaps by a “= man in the middle”) and give confidence that the media is encrypted e= nd-to-end.

 

However, I fear that this may b= reak STIR in some not-entirely-uncommon situations. Public network SIP call= s are routinely re-originated (as we’ve discussed). Sometimes the RTP= will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream a= s well as the SIP messaging. For example, a transit operator might need to = transcode the audio if the operators on either side don’t have matchi= ng codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or betw= een G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reali= ty may be that anybody that can handle a-law can handle mu-law, so transcod= ing should “never” be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA= ) the interceptor would still be able to LISTEN without altering the finger= print, so perhaps that wouldn’t break the STIR signature.<= /span>

 

I raise the point for discussio= n. (The details here are a bit outside my expertise, and I probably missed = some earlier discussion.) One possible suggestion is to change “MUST&= #8221; to “MAY” in the text I quoted above. This gives the originator of the call the opportunity to decide whether they wa= nt downstream operators to have the flexibility to alter the fingerprint bu= t still maintain the end-to-end identity assurance offered with STIR. An or= iginator may be mostly concerned with protecting their media on the first hop; this would let them do that = (I think).

 

While protecting the fingerprin= t is a nice-to-have, I didn’t recall it in the STIR charter or proble= m statement.

 

David

 

David F= rankel

ZipDX® LLC

Monte S= ereno, CA USA

Tel: 1-= 800-FRANKEL (1-800-372-6535)<= /p>

Watch Our Video!

 

--_000_7594FB04B1934943A5C02806D1A2204B4BC82A3EESESSMB209erics_-- From nobody Fri Sep 2 12:07:21 2016 Return-Path: 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 A348812B006 for ; Fri, 2 Sep 2016 12:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 Ivc34lZ4FkVb for ; Fri, 2 Sep 2016 12:07:19 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EF01288B8 for ; Fri, 2 Sep 2016 12:07:19 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u82Ii4E9020923; Fri, 2 Sep 2016 14:45:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=P8/3bMZwu7RFXIeesUz/IAweyJUiiB9iIUivAzeGm24=; b=DCIVYlURQP5iTHiMwRo4Ib/kka6s6qCaquW8avuql5iYW67FPIt6rw74CSVCnJeDM811 3eMdG51rAx2OhkAtAPaIhDQOIFy4YP3QAqmTQsnurP9FLHrBUDIq/t2rY5hJSsF5ZuI0 gfpySPPNWngOdDZj/S9xYzMc4fGWP0WOj8QJiRodUOnyWvHjfFMJMAgeczLU/Uc9fq8f vlgK099kuwj/LGVYQkfKChtnAbOcvKfGzcg59t9v8Iw2KpnW9m89p1M+8FOq47YKL3fg a1aO3rT0jEQrjf/H5NZ4C645iMI7Y9q9b4pSuhvRzdC87x3JwZzpRuuZMozFA6tQCmFm nQ== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 256ejpjqcm-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 02 Sep 2016 14:45:52 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Fri, 2 Sep 2016 14:45:52 -0400 From: "Peterson, Jon" To: David Frankel , "stir@ietf.org" Thread-Topic: [stir] RFC 4474bis Last Call - Fingerprint Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+v//5VQA Date: Fri, 2 Sep 2016 18:45:51 +0000 Message-ID: References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> In-Reply-To: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.117] Content-Type: multipart/alternative; boundary="_000_D3EF11E81AD141jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-02_06:, , 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-1609020251 Archived-At: Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 19:07:20 -0000 --_000_D3EF11E81AD141jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable However, I fear that this may break STIR in some not-entirely-uncommon situ= ations. Using "mkey" at all is, I'd say, an extremely uncommon situation today. Tha= t could change over time, though. Public network SIP calls are routinely re-originated (as we=92ve discussed)= . Sometimes the RTP will still go end-to-end unaltered, but in other cases = it may be necessary to terminate and re-originate the stream as well as the= SIP messaging. For example, a transit operator might need to transcode the= audio if the operators on either side don=92t have matching codecs. For ex= ample, a transit operator might transcode wideband audio between G.722.2 (A= MR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711 a-l= aw and mu-law. (The reality may be that anybody that can handle a-law can h= andle mu-law, so transcoding should =93never=94 be required for G.711.) The= re could be other examples. I guess for lawful intercept (CALEA) the interc= eptor would still be able to LISTEN without altering the fingerprint, so pe= rhaps that wouldn=92t break the STIR signature. We take the presence of "mkey" here as an indication that the user demands = confidentiality and wants the call to fail if confidentiality is not availa= ble. This is, as I said, not the common situation. But where that is the us= er's explicit intention, a transcoder can and should be seen as a man-in-th= e-middle intercepting media and making end-to-end confidentiality impossibl= e. If intermediaries outright remove some media streams because they don't lik= e the codecs, and with them the resulting keys, but leave other streams and= keys intact, we do want that to be a recoverable error - and "canon" as us= ually can come to the rescue here. This was actually a motivation for the c= urrent "mkey" syntax in PASSporT. Elsewhere (in SIPBRANDY) we recently began exploring the distinction betwee= n opportunistically offering crypto parameters in SIP and demanding them. W= e aspire to basically create profiles in SIPBRANDY that build on rfc4474bis= to allow both those options. The strict SIPBRANDY profile will also requir= e things like implementing the authentication and verification service func= tions in the UA rather than in an intermediary. I am trying to make sure th= at as rfc4474bis ships we aren't closing any doors that SIPBRANDY will need= open. We've already added some support text for it, and I will ponder if t= here's anything more we could do here that will help enable a more opportun= istic use - where the originator is willing to grant some "flexibility" as = you say to entities downstream. I raise the point for discussion. (The details here are a bit outside my e= xpertise, and I probably missed some earlier discussion.) One possible sugg= estion is to change =93MUST=94 to =93MAY=94 in the text I quoted above. Thi= s gives the originator of the call the opportunity to decide whether they w= ant downstream operators to have the flexibility to alter the fingerprint b= ut still maintain the end-to-end identity assurance offered with STIR. An o= riginator may be mostly concerned with protecting their media on the first = hop; this would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn=92t recall it in= the STIR charter or problem statement. In terms of earlier discussion you might have missed, the PERPASS BCP that = rfc4474bis cites motivated this text, which was the then subject of a conse= nsus call taken by the chairs, which the working group affirmed. I rather t= hink the absence of this text would be an impediment to the advancement of = the document through the standardization process due to the very strong com= munity support for PERPASS. Jon Peterson Neustar, Inc. --_000_D3EF11E81AD141jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <78B21386B364B341AD2A7CB3D6BEAC2D@neustar.biz> Content-Transfer-Encoding: quoted-printable

However, I fear that this may break STIR in some not= -entirely-uncommon situations.


Using "mkey" at all is, I'd say, an extremely uncommon situa= tion today. That could change over time, though.

Public network SIP calls are routinely re-originated= (as we=92ve discussed). Sometimes the RTP will still go end-to-end unalter= ed, but in other cases it may be necessary to terminate and re-originate th= e stream as well as the SIP messaging. For example, a transit operator might need to transcode the audio if the o= perators on either side don=92t have matching codecs. For example, a transi= t operator might transcode wideband audio between G.722.2 (AMR-WB) and G.72= 2. Or between G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reality may be that anybody = that can handle a-law can handle mu-law, so transcoding should =93never=94 = be required for G.711.) There could be other examples. I guess for lawful i= ntercept (CALEA) the interceptor would still be able to LISTEN without altering the fingerprint, so perhaps that = wouldn=92t break the STIR signature.

We take the presence of "mkey" here as an indication that th= e user demands confidentiality and wants the call to fail if confidentialit= y is not available. This is, as I said, not the common situation. But where= that is the user's explicit intention, a transcoder can and should be seen as a man-in-the-middle intercepting medi= a and making end-to-end confidentiality impossible.

If intermediaries outright remove some media streams because they don'= t like the codecs, and with them the resulting keys, but leave other stream= s and keys intact, we do want that to be a recoverable error - and "ca= non" as usually can come to the rescue here. This was actually a motivation for the current "mkey" synt= ax in PASSporT.

Elsewhere (in SIPBRANDY) we recently began exploring the distinction b= etween opportunistically offering crypto parameters in SIP and demanding th= em. We aspire to basically create profiles in SIPBRANDY that build on rfc44= 74bis to allow both those options. The strict SIPBRANDY profile will also require things like implementing th= e authentication and verification service functions in the UA rather than i= n an intermediary. I am trying to make sure that as rfc4474bis ships we are= n't closing any doors that SIPBRANDY will need open. We've already added some support text for it, and I will p= onder if there's anything more we could do here that will help enable a mor= e opportunistic use - where the originator is willing to grant some "f= lexibility" as you say to entities downstream.

 I = raise the point for discussion. (The details here are a bit outside my expe= rtise, and I probably missed some earlier discussion.) One possible suggest= ion is to change =93MUST=94 to =93MAY=94 in the text I quoted above. This gives the originator of the call the opportunity to d= ecide whether they want downstream operators to have the flexibility to alt= er the fingerprint but still maintain the end-to-end identity assurance off= ered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this wou= ld let them do that (I think).

 

While protecting the fingerprint is a nice-to-have, = I didn=92t recall it in the STIR charter or problem statement.

In terms of earlier discussion you might have missed, the PERPASS BCP = that rfc4474bis cites motivated this text, which was the then subject of a = consensus call taken by the chairs, which the working group affirmed. I rat= her think the absence of this text would be an impediment to the advancement of the document through the stan= dardization process due to the very strong community support for PERPASS.

Jon Peterson
Neustar, Inc.
--_000_D3EF11E81AD141jonpetersonneustarbiz_-- From nobody Fri Sep 2 12:17:23 2016 Return-Path: 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 B0C5D12B029 for ; Fri, 2 Sep 2016 12:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 cfa9ab-if5td for ; Fri, 2 Sep 2016 12:17:19 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A29312B00C for ; Fri, 2 Sep 2016 12:17:19 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u82JDro8010971; Fri, 2 Sep 2016 15:17:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=0WrsMjXa+iIUERXQQ3UaWPKKiKop12rHG3/M0p7I0zU=; b=I+9biW941oM78xKQep+/JBLftXIUKddeHXLHH+NgdjlDI+1o/hxrvj13lAWslf3hJ78t oDpPxEZgyM45wjEYj2pcTeW27tBBD3be4iJfQvTWxyj0ZnUrSuS8DkMojR7MW7llg7rU 8LP/GhHID645i7hb7VlJ0waalz/+PBLjDvOSTKnh1Yix+2F1Ps5E6DVxkumW/QDXlB/X x6z48J/Ku2rhik3OxwCvikPYNeT2f7eZTkG7LNODipr818lKa295Rk58eoYcMgMNeAWg R38RBjZrltgbkjQ+f7fx5C9ladmphLWqUHqkcqGB7t3icckol2TTCXVsJrO1evhtKmTF Ow== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 256ejpjtgp-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 02 Sep 2016 15:17:01 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Fri, 2 Sep 2016 15:17:00 -0400 From: "Peterson, Jon" To: Christer Holmberg , David Frankel , "stir@ietf.org" Thread-Topic: [stir] RFC 4474bis Last Call - Fingerprint Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+gADJY7A///U3IA= Date: Fri, 2 Sep 2016 19:17:00 +0000 Message-ID: References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.117] Content-Type: multipart/alternative; boundary="_000_D3EF1C6E1AD1DAjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-02_06:, , 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-1609020258 Archived-At: Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 19:17:22 -0000 --_000_D3EF1C6E1AD1DAjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable PASSporT is designed to allow media streams to be reordered (again, this is= one of the cases Jonathan Lennox raised that got us to change the original= "mkey" syntax). Setting an "m=3D" line to zero and removing the associated= fingerprint will also be captured by "canon" and should be recoverable - p= rovided of course that the intermediaries are willing to let "canon" throug= h. Jon Peterson Neustar, Inc. From: stir > on behalf = of Christer Holmberg > Date: Friday, September 2, 2016 at 12:02 PM To: David Frankel >, "stir@ie= tf.org" > Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint Hi, In addition to the cases David presented, there can also be an intermediary= disables media by setting the m=3D line port value to zero. In such cases = the intermediary may also remove all fingerprint attributes associated with= the m=3D line. And, even if all fingerprints sent by the signer reach the verifier, there = is no guarantee they will be in the same matter. Not sure whether it matter= s as far as calculating the signature is concerned, but just to keep in min= d=85 In general, assuming we are going to use (or at least allow) Appendix F, we= cannot change any =93MUST=94 to =93MAY=94, because we need to specify exac= tly what content is used to calculate the signature, as that information wi= ll not be carried in the SIP message. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel Sent: 02 September 2016 21:04 To: stir@ietf.org Subject: [stir] RFC 4474bis Last Call - Fingerprint Greetings. I find myself worried about the following text in the 4474bis draft at 4.1: =93Fourth, if the request contains an SDP message body, and if that SDP con= tains one or more "a=3Dfingerprint" attributes, then the JSON key "mky" MUS= T appear with the algorithm(s) and value(s) of the fingerprint attributes (= if they differ), following the format given in [I-D.ietf-stir-passport] Sec= tion 3.2.2.2.=94 As I understand it, this is done to ensure that the fingerprint has not bee= n altered (perhaps by a =93man in the middle=94) and give confidence that t= he media is encrypted end-to-end. However, I fear that this may break STIR in some not-entirely-uncommon situ= ations. Public network SIP calls are routinely re-originated (as we=92ve di= scussed). Sometimes the RTP will still go end-to-end unaltered, but in othe= r cases it may be necessary to terminate and re-originate the stream as wel= l as the SIP messaging. For example, a transit operator might need to trans= code the audio if the operators on either side don=92t have matching codecs= . For example, a transit operator might transcode wideband audio between G.= 722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G= .711 a-law and mu-law. (The reality may be that anybody that can handle a-l= aw can handle mu-law, so transcoding should =93never=94 be required for G.7= 11.) There could be other examples. I guess for lawful intercept (CALEA) th= e interceptor would still be able to LISTEN without altering the fingerprin= t, so perhaps that wouldn=92t break the STIR signature. I raise the point for discussion. (The details here are a bit outside my ex= pertise, and I probably missed some earlier discussion.) One possible sugge= stion is to change =93MUST=94 to =93MAY=94 in the text I quoted above. This= gives the originator of the call the opportunity to decide whether they wa= nt downstream operators to have the flexibility to alter the fingerprint bu= t still maintain the end-to-end identity assurance offered with STIR. An or= iginator may be mostly concerned with protecting their media on the first h= op; this would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn=92t recall it in= the STIR charter or problem statement. David David Frankel ZipDX=AE LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! --_000_D3EF1C6E1AD1DAjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

PASSporT is designed to allow media streams to be reordered (again, th= is is one of the cases Jonathan Lennox raised that got us to change the ori= ginal "mkey" syntax). Setting an "m=3D" line to zero an= d removing the associated fingerprint will also be captured by "canon" and should be recoverable - provided of course that t= he intermediaries are willing to let "canon" through.

Jon Peterson
Neustar, Inc.

From: stir <stir-bounces@ietf.org> on behalf of Christer Ho= lmberg <christer.holmb= erg@ericsson.com>
Date: Friday, September 2, 2016 at = 12:02 PM
To: David Frankel <dfrankel@zipdx.com>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] RFC 4474bis Las= t Call - Fingerprint

Hi,

 

In addition to the cases David presented, there can also be an interme= diary disables media by setting the m=3D line port value to zero. In such c= ases the intermediary may also remove all fingerprint attributes associated with the m=3D line.

 

And, even if all fingerprints sent by the signer reach the verifier, t= here is no guarantee they will be in the same matter. Not sure whether it m= atters as far as calculating the signature is concerned, but just to keep in mind=85

 

In general, assuming we are going to use (or at least allow) Appendix = F, we cannot change any =93MUST=94 to =93MAY=94, because we need to specify= exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

 

Regards,

 

Christer

 

 

 

From: stir [mailto:stir-boun= ces@ietf.org] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: stir@ietf.org
Subject: [stir] RFC 4474bis Last Call - Fingerprint

 

Greetings.

 

I find myself worried about the= following text in the 4474bis draft at 4.1:

 

=93Fourth, if the request conta= ins an SDP message body, and if that SDP contains one or more "a=3Dfin= gerprint" attributes, then the JSON key "mky" MUST appear wi= th the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] S= ection 3.2.2.2.=94

 

As I understand it, this is don= e to ensure that the fingerprint has not been altered (perhaps by a =93man = in the middle=94) and give confidence that the media is encrypted end-to-en= d.

 

However, I fear that this may b= reak STIR in some not-entirely-uncommon situations. Public network SIP call= s are routinely re-originated (as we=92ve discussed). Sometimes the RTP wil= l still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream a= s well as the SIP messaging. For example, a transit operator might need to = transcode the audio if the operators on either side don=92t have matching c= odecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or betw= een G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reali= ty may be that anybody that can handle a-law can handle mu-law, so transcod= ing should =93never=94 be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA= ) the interceptor would still be able to LISTEN without altering the finger= print, so perhaps that wouldn=92t break the STIR signature.

 

I raise the point for discussio= n. (The details here are a bit outside my expertise, and I probably missed = some earlier discussion.) One possible suggestion is to change =93MUST=94 t= o =93MAY=94 in the text I quoted above. This gives the originator of the call the opportunity to decide whether they wa= nt downstream operators to have the flexibility to alter the fingerprint bu= t still maintain the end-to-end identity assurance offered with STIR. An or= iginator may be mostly concerned with protecting their media on the first hop; this would let them do that = (I think).

 

While protecting the fingerprin= t is a nice-to-have, I didn=92t recall it in the STIR charter or problem st= atement.

 

David

 

David F= rankel

ZipDX=AE LLC

Monte S= ereno, CA USA

Tel: 1-= 800-FRANKEL (1-800-372-6535)<= /p>

Watch Our Video!

 

 --_000_D3EF1C6E1AD1DAjonpetersonneustarbiz_-- From nobody Fri Sep 2 13:01:13 2016 Return-Path: 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 3F01312B012 for ; Fri, 2 Sep 2016 13:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 07ohEkXMY2e8 for ; Fri, 2 Sep 2016 13:01:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE09126579 for ; Fri, 2 Sep 2016 13:01:08 -0700 (PDT) X-AuditID: c1b4fb2d-903ff700000019a3-b1-57c9da81515d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 7A.21.06563.18AD9C75; Fri, 2 Sep 2016 22:01:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Fri, 2 Sep 2016 22:01:05 +0200 From: Christer Holmberg To: "Peterson, Jon" , David Frankel , "stir@ietf.org" Thread-Topic: [stir] RFC 4474bis Last Call - Fingerprint Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+gADJY7A///U3ID//8JNgA== Date: Fri, 2 Sep 2016 20:01:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC82CC7@ESESSMB209.ericsson.se> References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC82CC7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7lm7TrZPhBn+OK1mc/j2BxeJMg6XF 8rXbmByYPZYs+cnksaPhObNHQ88XtgDmKC6blNSczLLUIn27BK6Md3M3shUsnMFY0fj4JEsD Y1cbYxcjJ4eEgInEoqXn2LsYuTiEBNYzSny6fx7KWcwosW3FUyCHg4NNwEKi+582SIOIQKnE trbZYM3CAuYStzf+YYeIW0hsvLGQCcJ2kthyYyIbiM0ioCIxde5JVhCbV8BXov30Pqj5Kxgl nvbtYgZJcAINWjfrFFgRo4CYxPdTa8AGMQuIS9x6Mp8J4lIBiSV7zjND2KISLx//Y4WwlSQa lzxhhajPl/i44ggzxDJBiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPg MROy+AJG9lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgXF1cMtv3R2Mq187HmIU4GBU4uF9 0HoyXIg1say4MvcQowQHs5IIb911oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6Ykl qdmpqQWpRTBZJg5OqQZGuUuFdUld1z5wL//yWJJ1jrK5QtH9KxFP5/hP4Dl3NnXL4RIzd/mz +mcqPun94PSwsVK9NGNfgPDVy1UdLKuUf9pYz7x6dv3m8zde1Uk+6wib07DSvsxnmd9BXrk7 PqtK8p21qqt4liid1zB0MQv/aXeQ4a/L+rmPpqbp6QgKPy8TsJvwaaqEEktxRqKhFnNRcSIA Gqex8qcCAAA= Archived-At: Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 20:01:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC82CC7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >PASSporT is designed to allow media streams to be reordered (again, this i= s one of the >cases Jonathan Lennox raised that got us to change the origin= al "mkey" syntax). Setting an >"m=3D" line to zero and removing the associa= ted fingerprint will also be captured by "canon" >and should be recoverable= - provided of course that the intermediaries are willing to let >"canon" t= hrough. Doesn't that require "canon", and the claims, to be present in the request?= In the latest version of 4474bis they are still optional... Regards, Christer From: stir > on behalf = of Christer Holmberg > Date: Friday, September 2, 2016 at 12:02 PM To: David Frankel >, "stir@ie= tf.org" > Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint Hi, In addition to the cases David presented, there can also be an intermediary= disables media by setting the m=3D line port value to zero. In such cases = the intermediary may also remove all fingerprint attributes associated with= the m=3D line. And, even if all fingerprints sent by the signer reach the verifier, there = is no guarantee they will be in the same matter. Not sure whether it matter= s as far as calculating the signature is concerned, but just to keep in min= d... In general, assuming we are going to use (or at least allow) Appendix F, we= cannot change any "MUST" to "MAY", because we need to specify exactly what= content is used to calculate the signature, as that information will not b= e carried in the SIP message. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel Sent: 02 September 2016 21:04 To: stir@ietf.org Subject: [stir] RFC 4474bis Last Call - Fingerprint Greetings. I find myself worried about the following text in the 4474bis draft at 4.1: "Fourth, if the request contains an SDP message body, and if that SDP conta= ins one or more "a=3Dfingerprint" attributes, then the JSON key "mky" MUST = appear with the algorithm(s) and value(s) of the fingerprint attributes (if= they differ), following the format given in [I-D.ietf-stir-passport] Secti= on 3.2.2.2." As I understand it, this is done to ensure that the fingerprint has not bee= n altered (perhaps by a "man in the middle") and give confidence that the m= edia is encrypted end-to-end. However, I fear that this may break STIR in some not-entirely-uncommon situ= ations. Public network SIP calls are routinely re-originated (as we've disc= ussed). Sometimes the RTP will still go end-to-end unaltered, but in other = cases it may be necessary to terminate and re-originate the stream as well = as the SIP messaging. For example, a transit operator might need to transco= de the audio if the operators on either side don't have matching codecs. Fo= r example, a transit operator might transcode wideband audio between G.722.= 2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711= a-law and mu-law. (The reality may be that anybody that can handle a-law c= an handle mu-law, so transcoding should "never" be required for G.711.) The= re could be other examples. I guess for lawful intercept (CALEA) the interc= eptor would still be able to LISTEN without altering the fingerprint, so pe= rhaps that wouldn't break the STIR signature. I raise the point for discussion. (The details here are a bit outside my ex= pertise, and I probably missed some earlier discussion.) One possible sugge= stion is to change "MUST" to "MAY" in the text I quoted above. This gives t= he originator of the call the opportunity to decide whether they want downs= tream operators to have the flexibility to alter the fingerprint but still = maintain the end-to-end identity assurance offered with STIR. An originator= may be mostly concerned with protecting their media on the first hop; this= would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn't recall it in t= he STIR charter or problem statement. David David Frankel ZipDX(r) LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! --_000_7594FB04B1934943A5C02806D1A2204B4BC82CC7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

><= /span>PASSporT is designed to = allow media streams to be reordered (again, this is one of the >cases Jonathan Lennox raised that got us= to change the original "mkey" syntax). Setting an >"m=3D" line to zero and removi= ng the associated fingerprint will also be captured by "canon" >and should be recoverable - provided of = course that the intermediaries are willing to let >"canon" through.

=  

Doesn’t that req= uire “canon”, and the claims, to be present in the request? In = the latest version of 4474bis they are still optional…

 

Regards,

 

Christer

 

=  

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Friday, September 2, 2016 at 12:02 PM
To: David Frankel <dfrankel= @zipdx.com>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint

&n= bsp;

Hi,

 

In addition to the cases David presented, there can also be an interme= diary disables media by setting the m=3D line port value to zero. In such c= ases the intermediary may also remove all fingerprint attributes associated with the m=3D line.

 

And, even if all fingerprints sent by the signer reach the verifier, t= here is no guarantee they will be in the same matter. Not sure whether it m= atters as far as calculating the signature is concerned, but just to keep in mind…

 

In general, assuming we are going to use (or at least allow) Appendix = F, we cannot change any “MUST” to “MAY”, because we= need to specify exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

 

Regards,

 

Christer

 

 

 

From:<= /span> stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: stir@ietf.org
Subject: [stir] RFC 4474bis Last Call - Fingerprint

 =

Greetings= .

 

I find my= self worried about the following text in the 4474bis draft at 4.1:

 

“Fo= urth, if the request contains an SDP message body, and if that SDP contains= one or more "a=3Dfingerprint" attributes, then the JSON key &quo= t;mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-= D.ietf-stir-passport] Section 3.2.2.2.”

 

As I unde= rstand it, this is done to ensure that the fingerprint has not been altered= (perhaps by a “man in the middle”) and give confidence that th= e media is encrypted end-to-end.

 

However, = I fear that this may break STIR in some not-entirely-uncommon situations. P= ublic network SIP calls are routinely re-originated (as we’ve discuss= ed). Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-orig= inate the stream as well as the SIP messaging. For example, a transit opera= tor might need to transcode the audio if the operators on either side don&#= 8217;t have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB)= and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and= mu-law. (The reality may be that anybody that can handle a-law can handle = mu-law, so transcoding should “never” be required for G.711.) There could be other examples. I guess for lawful = intercept (CALEA) the interceptor would still be able to LISTEN without alt= ering the fingerprint, so perhaps that wouldn’t break the STIR signat= ure.

 

I raise t= he point for discussion. (The details here are a bit outside my expertise, = and I probably missed some earlier discussion.) One possible suggestion is = to change “MUST” to “MAY” in the text I quoted above. This gives the originator of the call the opportunity to d= ecide whether they want downstream operators to have the flexibility to alt= er the fingerprint but still maintain the end-to-end identity assurance off= ered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this wou= ld let them do that (I think).

 

While pro= tecting the fingerprint is a nice-to-have, I didn’t recall it in the = STIR charter or problem statement.<= /o:p>

 

David

 

David F= rankel

ZipDX® LLC

Monte S= ereno, CA USA

Tel: 1-= 800-FRANKEL (1-800-372-6535)<= /span>

Watch Our V= ideo!

 

--_000_7594FB04B1934943A5C02806D1A2204B4BC82CC7ESESSMB209erics_-- From nobody Fri Sep 2 13:13:01 2016 Return-Path: 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 274DF12D1E4 for ; Fri, 2 Sep 2016 13:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 ltAlWBe1iEuh for ; Fri, 2 Sep 2016 13:12:58 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F7412D18D for ; Fri, 2 Sep 2016 13:12:58 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u82K30TG019571; Fri, 2 Sep 2016 16:12:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=CXcuf9AYPw73zJmFziD2kws7SnIQwmJpD+ZJuPRHDH0=; b=rrx6MzyUIWUVtrqJyIW/YCS3Dv2guERb/skk5vu2BFqYay9RASGxTEd6l67aex/oIRIE +jbep8zIGbyuJ4LjTHXMcMHJ4Tfhqa1T1W1jM9k+usRLxu0o1EQ1Bv+yKkcBT+RO3YHg EgAcxk2fSEDXsIt8ILI8kNcyk5v+AfkKIIXvuGMan4irPh32xXIXnQbrVEzuUnEkLIQ9 yQti2kRmOs6u57+gCAC6kK1CTzDTfXfgEn5wUlQAcVpSTEdjmMIBRY30xOFjnV+yVXdB ZyTq5x4Fuj0MqjF4HaZCoYIEEsOiDrTJey70ZDBFHcbUhAXstG8SqCVl8qNzUp29wXBN nA== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 256e6xk1dj-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 02 Sep 2016 16:12:54 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc10.cis.neustar.com ([169.254.4.225]) with mapi id 14.03.0279.002; Fri, 2 Sep 2016 16:12:53 -0400 From: "Peterson, Jon" To: Christer Holmberg , David Frankel , "stir@ietf.org" Thread-Topic: [stir] RFC 4474bis Last Call - Fingerprint Thread-Index: AdIFPm7BYZKjrJgLQVygpQwlh+74+gADJY7A///U3ID//8JNgIAATU+A Date: Fri, 2 Sep 2016 20:12:53 +0000 Message-ID: References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC82CC7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC82CC7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.117] Content-Type: multipart/alternative; boundary="_000_D3EF29A71AD1F2jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-02_06:, , 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-1609020270 Archived-At: Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Fri, 02 Sep 2016 20:13:00 -0000 --_000_D3EF29A71AD1F2jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To recover these if they were removed requires the presence of "canon." Tha= t does not mean that "canon" is or should be required. Again, the decision to make "canon" optional depends on how common we antic= ipate these removal cases will be, and how heavily we would weigh the cost = of increasing the message size every time we use Identity. We've had this d= iscussion a number of times now, including a consensus call at the last mee= ting, and consistently the conclusion has been to keep "canon" optional. Th= is "mkey" one especially I do not anticipate will result in a common failur= e condition. Jon Peterson Neustar, Inc. From: Christer Holmberg > Date: Friday, September 2, 2016 at 1:01 PM To: Jon Peterson = >, David Frankel >, "stir@iet= f.org" > Subject: RE: [stir] RFC 4474bis Last Call - Fingerprint Hi, >PASSporT is designed to allow media streams to be reordered (again, this i= s one of the >cases Jonathan Lennox raised that got us to change the origin= al "mkey" syntax). Setting an >"m=3D" line to zero and removing the associa= ted fingerprint will also be captured by "canon" >and should be recoverable= - provided of course that the intermediaries are willing to let >"canon" t= hrough. Doesn=92t that require =93canon=94, and the claims, to be present in the re= quest? In the latest version of 4474bis they are still optional=85 Regards, Christer From: stir > on behalf = of Christer Holmberg > Date: Friday, September 2, 2016 at 12:02 PM To: David Frankel >, "stir@ie= tf.org" > Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint Hi, In addition to the cases David presented, there can also be an intermediary= disables media by setting the m=3D line port value to zero. In such cases = the intermediary may also remove all fingerprint attributes associated with= the m=3D line. And, even if all fingerprints sent by the signer reach the verifier, there = is no guarantee they will be in the same matter. Not sure whether it matter= s as far as calculating the signature is concerned, but just to keep in min= d=85 In general, assuming we are going to use (or at least allow) Appendix F, we= cannot change any =93MUST=94 to =93MAY=94, because we need to specify exac= tly what content is used to calculate the signature, as that information wi= ll not be carried in the SIP message. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel Sent: 02 September 2016 21:04 To: stir@ietf.org Subject: [stir] RFC 4474bis Last Call - Fingerprint Greetings. I find myself worried about the following text in the 4474bis draft at 4.1: =93Fourth, if the request contains an SDP message body, and if that SDP con= tains one or more "a=3Dfingerprint" attributes, then the JSON key "mky" MUS= T appear with the algorithm(s) and value(s) of the fingerprint attributes (= if they differ), following the format given in [I-D.ietf-stir-passport] Sec= tion 3.2.2.2.=94 As I understand it, this is done to ensure that the fingerprint has not bee= n altered (perhaps by a =93man in the middle=94) and give confidence that t= he media is encrypted end-to-end. However, I fear that this may break STIR in some not-entirely-uncommon situ= ations. Public network SIP calls are routinely re-originated (as we=92ve di= scussed). Sometimes the RTP will still go end-to-end unaltered, but in othe= r cases it may be necessary to terminate and re-originate the stream as wel= l as the SIP messaging. For example, a transit operator might need to trans= code the audio if the operators on either side don=92t have matching codecs= . For example, a transit operator might transcode wideband audio between G.= 722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G= .711 a-law and mu-law. (The reality may be that anybody that can handle a-l= aw can handle mu-law, so transcoding should =93never=94 be required for G.7= 11.) There could be other examples. I guess for lawful intercept (CALEA) th= e interceptor would still be able to LISTEN without altering the fingerprin= t, so perhaps that wouldn=92t break the STIR signature. I raise the point for discussion. (The details here are a bit outside my ex= pertise, and I probably missed some earlier discussion.) One possible sugge= stion is to change =93MUST=94 to =93MAY=94 in the text I quoted above. This= gives the originator of the call the opportunity to decide whether they wa= nt downstream operators to have the flexibility to alter the fingerprint bu= t still maintain the end-to-end identity assurance offered with STIR. An or= iginator may be mostly concerned with protecting their media on the first h= op; this would let them do that (I think). While protecting the fingerprint is a nice-to-have, I didn=92t recall it in= the STIR charter or problem statement. David David Frankel ZipDX=AE LLC Monte Sereno, CA USA Tel: 1-800-FRANKEL (1-800-372-6535) Watch Our Video! --_000_D3EF29A71AD1F2jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <28B6C1D1FA334046BE5FCDA154926554@neustar.biz> Content-Transfer-Encoding: quoted-printable

To recover these if they were removed requires the presence of "c= anon." That does not mean that "canon" is or should be requi= red.

Again, the decision to make "canon" optional depends on how = common we anticipate these removal cases will be, and how heavily we would = weigh the cost of increasing the message size every time we use Identity. W= e've had this discussion a number of times now, including a consensus call at the last meeting, and consistently the = conclusion has been to keep "canon" optional. This "mkey&quo= t; one especially I do not anticipate will result in a common failure condi= tion.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, September 2, 2016 at = 1:01 PM
To: Jon Peterson <jon.peterson@neustar.biz>, David Frank= el <dfrankel@zipdx.com>, &q= uot;stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] RFC 4474bis Las= t Call - Fingerprint

Hi,

&n= bsp;

><= /span>PASSporT is designed to = allow media streams to be reordered (again, this is one of the >cases Jonathan Lennox raised that got us= to change the original "mkey" syntax). Setting an >"m=3D" line to zero and removi= ng the associated fingerprint will also be captured by "canon" >and should be recoverable - provided of = course that the intermediaries are willing to let >"canon" through.

=  

Doesn=92t that require= =93canon=94, and the claims, to be present in the request? In the latest v= ersion of 4474bis they are still optional=85

 

Regards,

 

Christer

 

=  

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Friday, September 2, 2016 at 12:02 PM
To: David Frankel <dfrankel= @zipdx.com>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint

&n= bsp;

Hi,

 

In addition to the cases David presented, there can also be an interme= diary disables media by setting the m=3D line port value to zero. In such c= ases the intermediary may also remove all fingerprint attributes associated with the m=3D line.

 

And, even if all fingerprints sent by the signer reach the verifier, t= here is no guarantee they will be in the same matter. Not sure whether it m= atters as far as calculating the signature is concerned, but just to keep in mind=85

 

In general, assuming we are going to use (or at least allow) Appendix = F, we cannot change any =93MUST=94 to =93MAY=94, because we need to specify= exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

 

Regards,

 

Christer

 

 

 

From:<= /span> stir [mailto:stir-bounces@ietf.org] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: stir@ietf.org
Subject: [stir] RFC 4474bis Last Call - Fingerprint

 =

Greetings= .

 

I find my= self worried about the following text in the 4474bis draft at 4.1:

 

=93Fourth= , if the request contains an SDP message body, and if that SDP contains one= or more "a=3Dfingerprint" attributes, then the JSON key "mk= y" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-= D.ietf-stir-passport] Section 3.2.2.2.=94

 

As I unde= rstand it, this is done to ensure that the fingerprint has not been altered= (perhaps by a =93man in the middle=94) and give confidence that the media = is encrypted end-to-end.

 

However, = I fear that this may break STIR in some not-entirely-uncommon situations. P= ublic network SIP calls are routinely re-originated (as we=92ve discussed).= Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-orig= inate the stream as well as the SIP messaging. For example, a transit opera= tor might need to transcode the audio if the operators on either side don= =92t have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB)= and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and= mu-law. (The reality may be that anybody that can handle a-law can handle = mu-law, so transcoding should =93never=94 be required for G.711.) There could be other examples. I guess for lawful = intercept (CALEA) the interceptor would still be able to LISTEN without alt= ering the fingerprint, so perhaps that wouldn=92t break the STIR signature.=

 

I raise t= he point for discussion. (The details here are a bit outside my expertise, = and I probably missed some earlier discussion.) One possible suggestion is = to change =93MUST=94 to =93MAY=94 in the text I quoted above. This gives the originator of the call the opportunity to d= ecide whether they want downstream operators to have the flexibility to alt= er the fingerprint but still maintain the end-to-end identity assurance off= ered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this wou= ld let them do that (I think).

 

While pro= tecting the fingerprint is a nice-to-have, I didn=92t recall it in the STIR= charter or problem statement.

 

David

 

David F= rankel

ZipDX=AE LLC

Monte S= ereno, CA USA

Tel: 1-= 800-FRANKEL (1-800-372-6535)<= /span>

Watch Our V= ideo!

 

 --_000_D3EF29A71AD1F2jonpetersonneustarbiz_-- From nobody Mon Sep 5 15:33:11 2016 Return-Path: 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 0708512B0C2 for ; Mon, 5 Sep 2016 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 KV_gYQyc7SvN for ; Mon, 5 Sep 2016 15:33:08 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B34F12B0B4 for ; Mon, 5 Sep 2016 15:33:08 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 93so97719383qtg.2 for ; Mon, 05 Sep 2016 15:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zf/F8FneBpuLhNH2wbOS2pVRqiN7HldFhyGXbkaB3SU=; b=GbmENDGjHoNbXbt4rWFoqw9ss0knTmgk6lqsxBcaIWBhfJZvK0NkDerMP9YIUesgsO s4HBDyZfEL+UEJcbfDwQtxz5pwiOtnb6dRyhZZm0eySVDsfYcIqvJVMVDFXQwrCermqA RrIUIk9h2/2WKO5EKvUTkrQ33QIDPo9EunV+8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Zf/F8FneBpuLhNH2wbOS2pVRqiN7HldFhyGXbkaB3SU=; b=G3GU2dxKYR+8j2gV1udTzVwVCtKQj7de/6Z4mukRE/UeUqAb+8+pt011vwtctgZZx0 l2lh4vBC2OCjGB4jZ2MlzGo17y8rN2wI6lOR023a+RMIN1HPKmqjfPlGCwlr9AHuMYEQ fGVdaYJMrhR9CqrGZpAnIg2ynqeQ5Kmh4ZTooZfH8lqFhf158JaTMi2HmKeacx69ld0S xP4OzweEdcN0uYPAtePOWGAuJ1HMQLyyb1d9lZ+19Qry1eRXHBPjKZ43sYCvxfqr1QTH /Cv61ZLRnnRNlS/1O3XX5yvj6LZnO+TAvbbIzpHm+j4DUFxkmb/MDG/wboKJzFHqVlls IzCQ== X-Gm-Message-State: AE9vXwPEXGlxgPiOB76VVAOrktBi4DgVziIXztmQJ5Ua3otvTMNMRTbDL7LmR9LiH8ml4A== X-Received: by 10.237.39.34 with SMTP id n31mr42041292qtd.55.1473114787211; Mon, 05 Sep 2016 15:33:07 -0700 (PDT) Received: from [172.16.0.112] ([96.231.228.70]) by smtp.gmail.com with ESMTPSA id f17sm15913270qke.37.2016.09.05.15.33.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Sep 2016 15:33:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Mon, 5 Sep 2016 18:33:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B9A1931-72D9-48E0-9099-91AE4EF18AD5@sn3rd.com> References: To: J Braunberger X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org 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: Mon, 05 Sep 2016 22:33:10 -0000 John, Thanks for the comments, and apologies for taking so long to get to = these. tl;dr: All fixed up in the editor=E2=80=99s copy. > On Jul 13, 2016, at 17:09, J Braunberger = wrote: >=20 > Just found a few proofreading things for cleanup... >=20 > - page 3, 2nd last paragraph, 2nd last line: s/taht/that/ fixed > - page 8, section 7, near end of 1st paragraph, the phrase before = the "," seems incomplete > "[I-D.ietf-stir-rfc4474bis] provides an "info" = parameter of the > Identity header which contains a URI where the = credential used to > generate the Identity header, and requires = documents which define > credential systems to list the URI schemes that may = be present in the > "info" parameter.=E2=80=9D Changed it to: [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the Identity header which contains a URI for the credential used to generate the Identity header; [I-D.ietf-stir-rfc4474bis] also requires documents which define credential systems list the URI schemes that may be present in the "info" parameter. > - page 9, section 8, near end of 1st paragraph: "TN = Authorization List extension particular is to allow a verifier to" - = should it be "in particular=E2=80=9D? Made it =E2=80=9Cin particular" > - page 10, section 3, last sentence: should be "a future = version" or "future versions" > - page 10, section 9, last sentence on page: s/that/than/ > - page 11, section 9.1, last paragraph: s/relying/relied/ > - page 13, section 9.2.1, 2nd paragraph, 2nd sentence: = s/signlerequestExtensions/singleRequestExtensions/ > - page 13, first bullet: s/Sectin/Section/ > also, "of as per in" - a little = awkward? fixed * 5 > - page 14, section 9.3, last sentence: "A verifier would then = follow the URI to ascertain whether the list of TNs authorized for use = by the caller." - > = incomplete sentence? I think a verb was missing: A verifier would then follow the URI to ascertain whether the list of TNs authorized [are] for use by the caller. > - page 15, 2nd line: s/number/numbers/ fixed Note that these fixes will appear in the next version. spt= From nobody Mon Sep 5 20:09:19 2016 Return-Path: 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 9204E12B0FE for ; Mon, 5 Sep 2016 20:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 XL3eZ2ATFZpu for ; Mon, 5 Sep 2016 20:09:16 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8B812B08D for ; Mon, 5 Sep 2016 20:09:15 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 11so87194173qtc.0 for ; Mon, 05 Sep 2016 20:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OytLFodDVz3nysKURYSjUV2yhq9z90/OI9h3cyCWzWg=; b=XT/0qVnsyIxFft9EIQk0K4/+18paGEwb46P09P7VxhV3yogUJJFXwOB9qIKLSjzZ2z Pp6MOB5gJ58QAZv+b44F03z6tgFpdMv96d0HVu6SiHKhoKaqh5QnqjnThveZt2LubP+a H3hazyBoRU102U2NIw9M8b3ykoMcs5CvCmiv8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OytLFodDVz3nysKURYSjUV2yhq9z90/OI9h3cyCWzWg=; b=lb9lAfAkGfdjDuJbOLScV9gE1GpFkXsUMH0zEZncBibZBdGcz8hDzpmSC1vDNyHPFA sK09MZKNHctz7fD0bREOpHodrivUk1WO+gAY0D15YXFzLNXpY81eIpSqii62Ik8M0UBC kOug3mqZr2kiku3f81bRgsxp05SerJJ+Y1/ktKbrqYocvKSt3TMkPIproSHkgJpyNOEv 45adSvXvgK2+1lx1rSwWufE16e6zEqZ/pZS6gaBkC7ACjH5AjaN4G0ZgO79jRu9DB1/i WQv8OqI9BEz/ZIMndGFpcnrCy48QNEWsQL0qnAHfYqXxPoOU6hsRIiwZq4d4sZnbI63x Fngw== X-Gm-Message-State: AE9vXwOw2WHPZPu88tVxTkI7kTo3ZCuFTeb2jboy+EuFdYU9wD2Ya+kLMGMSTFopju3ffg== X-Received: by 10.200.36.13 with SMTP id c13mr42485776qtc.45.1473131354579; Mon, 05 Sep 2016 20:09:14 -0700 (PDT) Received: from [172.16.0.112] ([96.231.228.70]) by smtp.gmail.com with ESMTPSA id v10sm2844118qkg.20.2016.09.05.20.09.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Sep 2016 20:09:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <0351fc4a-dd81-c62b-ad8e-78c9969d6d04@dcrocker.net> Date: Mon, 5 Sep 2016 23:09:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0351fc4a-dd81-c62b-ad8e-78c9969d6d04@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Review: draft-ietf-stir-certificates-07 X-BeenThere: stir@ietf.org 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: Tue, 06 Sep 2016 03:09:19 -0000 Dave, Thanks for the review. Apologies for taking so long to get to back to = this; I had a life event recently that made synching up with Jon on a = response take longer than anticipated. > On Aug 12, 2016, at 11:51, Dave Crocker wrote: -snip- >> Abstract >>=20 >> In order to prevent the impersonation of telephone numbers on the >> Internet, some kind of credential system needs to exist that >> cryptographically proves authority over telephone numbers. This >> document describes the use of certificates in establishing = authority >> over telephone numbers, as a component of a broader architecture = for >> managing telephone numbers as identities in protocols like SIP. >=20 > It mostly does not 'describe the use'. It has bits of discussion, = about bits of use, but gives no integrated description. It also = contains a few bits of incomplete specification. It allows things to be done a few different ways because people want to = use certs with STIR a few different ways. -snip- >>=20 >>=20 >> One of the most important components of a system to prevent >> impersonation is the implementation of credentials which identify = the >> parties who control telephone numbers. With these credentials, >=20 > Credentials normally are for validation, not identification. = Typically, the user already has the identifier. So identification of = the owner, per se, is not the goal. Credentials are normally used to identify the party to which the = credentials have been assigned. The dictionary definition of = =E2=80=9Ccredential" I see on Google is "a document or certificate = proving a person's identity or qualifications". This isn't being used in = any different sense here. There=E2=80=99s also a definition in RFC 4949 = of credential (search for =E2=80=9D$ credential=E2=80=9D) that lines up = with this use. > In any event, are these credentials really that usage-specific? = Normally, credentials are simply a means of validating some information = associated with an identifier, but they aren't so tightly coupled with a = particular application. For this application, for STIR and it's threat model, credentials need = to serve this purpose (to "identify the parties who control telephone = numbers"). That doesn't mean the credentials STIR uses have to be = limited to that purpose, just that this have to perform it. -snip- >> present such credentials. For that reason the STIR threat model >> [RFC7375] stipulates, "The design of the credential system = envisioned >> as a solution to these threats must, for example, limit the scope = of >> the credentials issued to carriers or national authorities to those >> numbers that fall under their purview." This document describes >=20 > The quoted text is meant to provide an underpinning to the current = specification. Unfortunately there is no obvious meaning to "limit the = scope of the credentials". For example, it might refer to limitations = in the semantics, or it might refer to the distribution of the = credential. The reader can't tell. It says "limit the scope... to those numbers that fall under their = purview." So it clearly isn't talking about the distribution of the = credential, it's talking about the semantics. -snip- >> 3. Authority for Telephone Numbers in Certificates >>=20 >> At a high level, this specification details two non-exclusive >=20 > 'non-exclusive' is distracting and doesn't add the clarity it intends. = There is no default assumption that adding one set of enhancements now = precludes adding others later. Some people might think these are mutually exclusive approaches, we = explain why they aren't. >> approaches that can be employed to determine authority over = telephone >=20 > I suspect these are not 'approaches' but rather are specific = capabilities. They are different approaches to the problem of determining authority = over telephone numbers. The certificates used for these two different = approaches contain different information. Not sure if the presence or = absence of that information is a "capability," but I suspect not. >> numbers with certificates. >=20 > 'can be'... >=20 > This appears to be saying that this specification does not provide a = clear and interoperable solution for the use of certificates to validate = telephone numbers. That is, by defining two, the two parties to use of = a cert could each make different choices and fail to interoperate. It is saying that it provides two approaches, both of which are clear = and interoperable, but which are intended for use in a different trust = model. They are not mutually interoperable in the sense that a relying = party who subscribes to one trust model wouldn't trust parties who don't = operate within that model. No different than receiving something signed = by a trust anchor you don't trust. > After some re-reading, I'm suspecting that what this paragraph intends = to mean is something like: >=20 > This specification defines two enhancements to common X.509 = certificates. One indicates the subject of the certificate No, it doesn't describe an enhancement of that form, as the subject of = certificates is existing in the specification of certificates. > But unfortunately I think it does not actually define either of them = as complete and implementable. The use of a subject of a certificate to determine whether it is trusted = or not is a common practice that is neither defined nor specified in = this document. What is novel here is adding information to a certificate = that explicitly gives a "scope" of authority over telephone numbers. The = part of this document this specifies a new technology is that part. -snip- >=20 >> The first approach is to leverage the subject of the certificate to >> ascertain that the holder of the certificate is authorized to claim >> authority over a telephone number. The subject might be = represented >> as a domain name in the SubjectAltName, such as an "example.net" >> where that domain is known to relying parties as a carrier, or >=20 > This appears to be saying that the consumer of a certificate must have = significant, independent knowledge of the semantics and use of the = certificate's contents. That's likely to be a serious issue. How will = they obtain this? What will ensure that certificates are, in fact, = interoperably useful? This model assumes that relying parties all have bilateral trust = agreements, yes. It is modeled on similar trust relationships in the = telephone network. >> represented with other identifiers related to the operation of the >> telephone network including Service Provider Identifiers (SPIDs) >> could serve as a subject as well. A relying party could then = employ >> an external data set or service that determines whether or not a >> specific telephone number is under the authority of the carrier >> identified as the subject of the certificate, and use that to >> ascertain whether or not the carrier should have authority over a >=20 > How is this sort of hypothetical useful for providing concrete = specification detail? Describing this practice is useful for reasons that have nothing to do = with providing concrete specification detail. > If, ultimately, this is saying that the specification here is merely = providing some common syntax, but that complete specification of the = semantics is out of scope for the document, then it needs to say that = early and clearly. It probably also should explain why. This isn't saying that the specification here is merely providing some = common syntax. > However, of course, this opens the question for where that additional = information is specified. And how is the reader to know? That additional information is not provided in some other place, so = there is no need for a reader to wonder where it is. >> telephone number. Potentially, a certificate extension to convey = the >> URI of such an information service trusted by the issuer of the >> certificate could be developed (though this specification does not >> propose one). Alternatively, some relying parties could form >> bilateral or multilateral trust relationships with peer carriers, >> trusting one another's assertions just as telephone carriers in the >> SS7 network today rely on transitive trust when displaying the >> calling party telephone number received through SS7 signaling. >=20 > Again, this explores hypotheticals rather than giving specification. = While possibly useful for a general overview of this architecture and = its possible application, it doesn't help with the current explanation. This section is giving an overview of the architecture. The first = paragraph of this section indicates that this section gives a high level = description. -snip- >> The first approach requires little change to existing Public Key >> Infrastructure (PKI) certificates; for the second approach, we must >> define an appropriate enrollment and authorization process. For = the >> purposes of STIR, the over-the-wire format specified in >> [I-D.ietf-stir-rfc4474bis] accommodates either of these approaches: >> the methods for canonicalizing, signing, for identifying and >> accessing the certificate and so on remain the same; it is only the >> verifier behavior and authorization decision that will change >> depending on the approach to telephone number authority taken by = the >> certificate. >=20 > So the verifier must support both, since they won't know which the = signer chose. Ideally, we'd like verifiers to support both, yes. But since the second = approach (the TN extension) can be built on top of certificates designed = for the first approach (just relying on the subject), we might say that = we fall back to the first approach for compatibility. > What is the compelling benefit in defining these two different = mechanisms? While the former mechanism doesn't address all of the problems in the = STIR threat model, it is an acceptable first step for the operating = community. We want to define a migration path from that to a solution = that will handle more of the threats. >> exclusive, and in fact a certificate issued to a traditional >> telephone network service provider could contain a TN Authorization >> List or not, depending on the CA issuing the credential. = Regardless >=20 > Sounds like good opportunity for conflicting information. Or a good way to manage transitioning from one to the other. >> of which approach is used, certificates that assert authority over >> telephone numbers are subject to the ordinary operational = procedures >> that govern certificate use per [RFC5280]. This means that >> verification services must be mindful of the need to ensure that = they >> trust the trust anchor that issued the certificate, and that they >=20 > "must be mindful of the need to ensure that they trust the trust = anchor" huh? This says that you need to trust the CA that issued a certificate in = order to trust the certificate. The previous sentence indicated that = this sentence would describe some ordinary operational procedures that = govern certificate use. > This is a specification and I have no idea what the above text is = specifying. This is a sentence at the end of some expository text reminding the = reader of guidance that is in RFC5280. >> have some means to determine the freshness of the certificate (see >> Section 9). >>=20 >> 4. Certificate Usage >=20 > This section has nothing to do with /using/ certificates. It provides = some discussion -- but no specification -- of issues concerning the = /creation/ of them. See for example bullet 1 directly below. Is that about creating = certificates? What about bullet 2? What about bullet 3? Or bullet 4? = Maybe bullet 5 is salient to how certificates are issued. As the very = next sentence reads, this section answers a set of questions that = rfc4474bis asks of credential systems. Maybe we could retitle the = section "Certificate Usage by STIR" if that would be less jarring. >> [I-D.ietf-stir-rfc4474bis] requires that all credential systems = used >> for signing the Identity header in SIP detail the following: -snip- >=20 >> 5. Enrollment and Authorization using the TN Authorization List >=20 > This entire section contains no specification. It describes a variety = of things, and cites and summarizes a variety of things, but it provides = no technical specification content. This section is also largely introducing the certificate architecture. >> This document assumes a threefold model for certificate enrollment >> when using the TN Authorization List extension. >=20 > I don't know what a 'threefold model' is. =46rom the rest of the = context, I suspect what is meant is something like: >=20 > Certificates used as telephone identity credentials can follow any = of three different certification models. >=20 > But really, that's just a guess at what's meant. That rewording doesn't capture that this section is specific to the use = of the TN Authorization List extension (which was not, say, true of = Section 3). The phrase "threefold model" can go away if it's a problem, = though. > But I'm not clear what the benefit of this section's discussion is, = since it neither specifies nor constrains anything. So, for example, = there's nothing that prevents having a twofold model or a fourfold = model=E2=80=A6 It is true this there could be other models that use the TN = Authorization List than the one described here; this document however = assumes that there are only three under serious consideration > For that matter, the details of creating a workable cert system for = this service border on being an open research task, which makes this = section that much more marginal. There is a long history of problematic = cert use. There is a storied history of problems with inter-provider = phone-number-based query services. It is saved from being an open research task by the fact that it is = deployable today. > But the current effort needs a working service that does both. = However there is /no/ history of a public phone-number-based query = service at scale and with adequate privacy protection. The truth of that statement hinges on what you mean by "adequate privacy = protection". Any number of candidates exist, anyway. > And yet the current task requires solving at least two of these and = maybe all three=E2=80=A6 No, the task at hand is specifying the TN Authorization List extension, = and outlining some use cases in which it might be used. Three, in this = section. -snip- >=20 >> 5.1. Levels Of Assurance >>=20 >> This specification supports different level of assurance (LOA). = The >=20 > Where and how does it support this? Where is it actually specified? The text that follows answers these questions. >> LOA indications, which are Object Identifiers (OIDs) included in = the >> certificate's certificate policies extension [RFC5280], allow CAs = to >> differentiate those enrolled from proof-of-possession versus >> delegation. A Certification Policy and a Certification Practice >> Statement [RFC3647] are produced as part of the normal PKI >> bootstrapping process (i.e., the CP is written first and then the = CAs >> say how they conform to the CP in the CPS). OIDs are used to >> reference the CP and if the CA wishes it can also include a = reference >> to the CPS with the certificate policies extension. CAs that wish = to >> express different LOAs MUST include the certificate policies >> extension in issued certificates. See Section 11 for additional >> information about the LOA registry. -snip- >> 5.2. Certificate Extension Scope and Structure >>=20 >> This specification places no limits on the number of telephone >> numbers that can be associated with any given certificate. Some >> service providers may be assigned millions of numbers, and may wish >> to have a single certificate that is capable of signing for any one >> of those numbers. Others may wish to compartmentalize authority = over >> subsets of the numbers they control. >=20 > I suspect that certificates don't do signing. I suspect what is meant = is that the certificates can be applied to the signing of... or = somesuch. Rather than "have a single certificate that is capable of signing" we could say "have a single certificate that can be applied to the = signing". -snip- >> 6. Provisioning Private Keying Material >>=20 > Another non-specification section. The specification of the TN Authorization List extension is in Section = 8. -snip- >> The specification recommends distribution of private keys through >> PKCS#8 objects signed by a trusted entity, for example through the >> CMS package specified in [RFC5958]. >=20 > Why is this here? It is such a generic 'recommendation' and so = detached from the rest of the private key management issues, that it = serves no useful purpose. It resides in this section because it is a recommendation about the = provisioning of private keying material. See the section title. >> 7. Acquiring Credentials to Verify Signatures >>=20 >> This specification documents multiple ways that a verifier can gain >=20 > Where is this documented? Mostly in the second and third paragraphs. >> access to the credentials needed to verify a request. As the >> validity of certificates does not depend on the method of their >> acquisition, there is no need to standardize any single mechanism = for >=20 > Well, this is an interesting assertion to make, given that it is = fundamentally wrong. Interoperability requires common conventions to be = followed by both sides of an interaction, such as providing a credential = and finding a credential. Absent at least one common mechanism for = this, there can be no guarantee of interoperability. The validity of certificates does not depend on their method of = acquisition. The cited text above does not guarantee interoperability or = even mention it in any way. The second and third paragraphs below = describe required support for common mechanisms of accessing credentials = in order to guarantee interoperability. >> this purpose. All entities that comply with >> [I-D.ietf-stir-rfc4474bis] necessarily support SIP, and = consequently >> SIP itself can serve as a way to acquire certificates. >=20 > On what basis is it acceptable for the supplier of a request to = provide their own credential??? What other security services operate = useful with such a model? On the basis that the validity of a certificate does not depend on who = you got it from. A certificate is trusted or not by a relying party = based on the relying party's trust for the CA that issued and signed the = certificate. This is no different than, say, connecting to a web server = and having the TLS connection in the backwards direction deliver a copy = of the certificate for the web server. The browser trusts that = certificate despite the fact that it was delivered from the party that = the certificate exists to identify, because the browser trusts the CA = that issued the certificate.=20 BTW - sending the credential along with the signature "blob=E2=80=9D is = something that=E2=80=99s pretty common, see S/MIME, IPsec, and others. >> [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the >=20 > Don't repeat the technical details written elsewhere. We cannot describe how to populate the "info" parameter without = identifying that it exists. rfc4474bis delegates the specification of = URIs in that parameter to credential specs (i.e. This). >> Identity header which contains a URI where the credential used to >> generate the Identity header, and requires documents which define >> credential systems to list the URI schemes that may be present in = the >> "info" parameter. For implementations compliant with this >> specification, three URI schemes are REQUIRED: the CID URI, the SIP >> URI, and the HTTP URI. >=20 > Why? This is the part where we are encouraging interoperability. Bullet 1 of = Section 4 outlines why we need to do this. >> The simplest way for a verifier to acquire the certificate needed = to >> verify a signature is for the certificate be conveyed in a SIP >> request along with the signature itself. In SIP, for example, a >> certificate could be carried in a multipart MIME body [RFC2046], = and >=20 > Since this isn't being specified in enough detail, and as a = requirement, then it appears to expect the verifier to guess that the = information might be in some MIME body-part, somewhere in the object??? The previous paragraph contained a normative requirement that the CID = header be supported; this sentence explains why CID support might be = helpful. > Again: this is commentary about technical issues. It isn't an actual = spec. No, that doesn't follow or apply. >> the URI in the Identity header "info" parameter could specify that >> body with a CID URI [RFC2392]. However, in many environments this = is >> not feasible due to message size restrictions or lack of necessary >> support for multipart MIME. >>=20 >> More commonly, the Identity header "info" parameter in a SIP = request >=20 > "commonly"? for something that has no field experience and isn't even = mandatory? In what field experience we have, this is how it is being used today. >> may contain a URI that the verifier dereferences with a network = call. >=20 > "network" call? We=E2=80=99ll strike =E2=80=9Cwith a network call=E2=80=9D. --snip-- >> 8. Verifying Certificate Scope with TN Authorization List >=20 > I don't see an algorithm for "verifying certificate scope". For that = matter, it's not entirely clear what this means, although I assume it = equates to "discovering what the range of caller-ids covered by the cert = is=E2=80=9D. This section presents a TN Authorization List that can be used to verify = certificate scope. >> The subjects of certificates containing the TN Authorization List >> extension are the administrative entities to whom numbers are >> assigned or delegated. When a verifier is validating a caller's >> identity, local policy always determines the circumstances under >> which any particular subject may be trusted, but the purpose of the >> TN Authorization List extension particular is to allow a verifier = to >> ascertain when the CA has designed that the subject has authority >> over a particular telephone number or number range. >=20 > "Local policy always determines the circumstances under which any = particular subject may be trusted, " >=20 > This is quite a profound statement, for a specification about an = inter-organization certificate service. While of course there is always = the option or even requirement that the verifier retain a final = authority over whether to treat a validation as credible, this statement = mostly means that there is nothing in the design of the certification = service that ensures or even encourages that belief. Given that the = cert system is the core of this entire service, that's sort of wild west = model is problematic=E2=80=A6 Local policy determines the circumstance under which any particular = subject of a certificate may be trusted. This statement is neither = profound nor problematic, it is just an obvious statement of fact that = is true in virtually every system that relies on certificates, but bears = repeating here because this extension described in this section provides = additional information that relying parties might use to make a trust = decision. >> The Telephony Number (TN) Authorization List certificate extension = is >> identified by the following object identifier: >=20 > This sort of detail is usually provided either as an independent = section about format, or during the specification of the /creation/ or = /signing/ processes. Having it be an independent format section works = better, IMO, because then all three (signing, packaging, verifying) can = refer to it equally, as needed. This section specifies the extension. > The formal meta-syntax here needs to be introduced and cited. What is = the meta-syntax language being used? Since apparently this is meant as = an extension, where is the ruleset it plugs into? That is true, we=E2=80=99ll include some text to say it=E2=80=99s an = X.509 extension, defined using ASN.1 (the ASN.1 references were in = Appendix A but it=E2=80=99d be fine to move them up here too), etc. We = will also add some text in s1 to explicitly note that the TN = Authorization List is an X.509 extension; now it just says =E2=80=9Cextend= ing X.509 with ... =E2=80=9D and doesn=E2=80=99t say we=E2=80=99re = defining an =E2=80=9Cextension=E2=80=9D until s4. > And all of the rules that aren't defined here need to be explicitly = defined or a citation given for their important. Also true. >> id-ce-TNAuthList OBJECT IDENTIFIER ::=3D { id-ce TBD } >=20 > This rule appears to be unanchored to anything in this document and = contains no pointer to any other. Same for the two rules contained in = it (id-ce and TBD). This is the object identifier for the extension, but we can add more = explanation in the paragraph that precedes this to say where the OID = goes. It=E2=80=99s TBD because we=E2=80=99re using an IANA defined OID = arc see the IANA considerations section. >> The TN Authorization List certificate extension has the following >> syntax: >>=20 >> TNAuthorizationList ::=3D SEQUENCE SIZE (1..MAX) OF = TNAuthorization >>=20 >> TNAuthorization ::=3D SEQUENCE SIZE (1..MAX) OF TNEntry >>=20 >> TNEntry ::=3D CHOICE { >> spid [0] ServiceProviderIdentifierList, >> range [1] TelephoneNumberRange, >> one E164Number } >>=20 >> ServiceProviderIdentifierList ::=3D SEQUENCE SIZE (1..3) OF >> OCTET STRING >=20 > This rule appears to be unanchored to anything in this document and = contains no point to any other. And note that the intro to this = meta-syntax only said it would supply the "Telephony Number (TN) = Authorization List certificate extension=E2=80=9D. A TNAuthorizationList is made up of TNAuthorizations, where are in turn = a sequence of TNEntrys, which may contain = ServiceProviderIdentifierLists. What exactly is unanchored here? ---snip-- >> 1. A Service Provider Identifier (SPID) can be used to indirectly >> name all of the telephone numbers associated with that service >> provider, >=20 > Where does this identifier come from? cite it. We can cite a spec for SPID. >> 2. Telephone numbers can be listed in a range, and >=20 > What is the format of the numbers? cite it. That's E164Number. --snip-- >> 3. A single telephone number can be listed. >>=20 >> Note that because large-scale service providers may want to = associate >> many numbers, possibly millions of numbers, with a particular >> certificate, optimizations are required for those cases to prevent >> certificate size from becoming unmanageable. In these cases, the = TN >> Authorization List may be given by reference rather than by value, >> through the presence of a separate certificate extension that = permits >> verifiers to either securely download the list of numbers = associated >> with a certificate, or to verify that a single number is under the >> authority of this certificate. This optimization will be detailed = in >> future version of this specification. >=20 > If you aren't going to specify it here, don't describe it. Make a = reservation for the entry and don't say any more. Describing the future = is almost always wrong. No, it is worth describing. >> 9. Certificate Freshness and Revocation >>=20 >> Regardless of which of the approaches in Section 3 is followed for >> using certificates, some sort of certificate verification mechanism >=20 > No. "some sort" isn't required. Rather, an explicit, specific and = interoperable sort is required. We can remove "some sort." >> is required. However, the traditional problem of certificate >> freshness gains a new wrinkle when using the TN Authorization List >> extension, because verifiers must establish not only that a >> certificate remains valid, but also that the certificate's scope >> contains the telephone number that the verifier is validating. >=20 > It isn't really a wrinkle. It's just one more component in the cert = that needs to be covered by the validity management mechanisms. This however is well described as a wrinkle. >> Dynamic changes to number assignments can occur due to number >> portability, for example. So even if a verifier has a valid cached >> certificate for a telephone number (or a range containing the >> number), the verifier must determine that the entity that signed is >> still a proper authority for that number. >=20 > This sounds more like a fundamental issue with caching behavior vs. = 'freshness' enforcement. Ordinarily yes, but we're casting the problem differently, which is why we're talking about it differently. >> To verify the status of the certificate, the verifier needs to >> acquire the certificate if necessary (via the methods described in >> Section 7), and then would need to either: >>=20 >> (a) Rely on short-lived certificates and not check the = certificate's >> status, or >=20 > This option is not an 'either/or' choice. It is merely a choice of = lifetime by the creator of the credential. If the cert is short-lived, = the verifier-side problem presumably doesn't exist, as indeed later text = here seems also to suggest. A relying party can choose to do one of these two things. >> (b) Rely on status information from the authority >=20 > What does 'rely on status information' mean? What status information? = Where is this specified? How is interoperability ensured? We are going to specify that in 9.2 so we can add a pointer to that = section. >> The tradeoff between short lived certificates and using status >> information is the former's burden is on the front end (i.e., >> enrollment) and the latter's burden is on the back end (i.e., >=20 > former =3D who? latter =3D who? This is clear in the text as written. >> verification). Both impact call setup time, but it is assumed that >> performing enrollment for each call is more of an impact that using >=20 > What is meant by "performing enrollment for each call" and where is = this specified? It means such short-lived certificates that you generate a new one (and = thus require a new enrollment) each time a call is placed. That can be = expanded >> status information. This document therefore recommends relying on >> status information. >=20 > Recommending between two unspecified mechanisms makes no sense. There = isn't enough detail here to justify making a recommendation. The next section talks about approaches to status information. This = section introduces why we need to choose a verification method. >> 9.1. Choosing a Verification Method >=20 > This section appears to basically cite some technology (not service) = specifications and then discuss their use. So we are back to not = specifying the details of an interoperable credential service. This section is motivating the use of a verification method. The = following section specifies the details of that method, and 9.2.1 = ultimately defined the extension. --snip-- >=20 >> CAs in the STIR architecture will likely all create CRLs for audit >> purposes, but it NOT RECOMMENDED that they be relying upon for = status >=20 > Again: making a recommendation in the absence of detail. This is = actually counter-productive. The previous paragraph details why this recommendation has been made. --snip-- >=20 >> 9.2. Using OCSP with TN Auth List >>=20 >> Certificates compliant with this specification therefore SHOULD >=20 > A normative requirement of this type, here, makes no sense, since = there is no OCSP service that is specified. I looked at this one as running an OCSP Server is providing an "OCSP = service=E2=80=9D, we=E2=80=99re saying folks who issue certificates = should run an OCSP server to provide a service. The OCSP RFC also = refers to it as a service: "An OCSP request contains the following data: = =E2=80=A6 - service request". Further, one can locate the OCSP server = with the AIA extension [RFC5280] and the AIA definition is as follows: The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears. so =E2=80=9Cservice=E2=80=9D seemed to fit here. spt (coordinated with Jon)= From nobody Tue Sep 6 19:33:33 2016 Return-Path: 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 551E612B49E for ; Tue, 6 Sep 2016 19:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 0_xDzV3jEBbA for ; Tue, 6 Sep 2016 19:33:28 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A47912B484 for ; Tue, 6 Sep 2016 19:33:28 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id l2so2239623qkf.3 for ; Tue, 06 Sep 2016 19:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=/JCgUwvAHSVUkOG7qXFAorRKjR5ybGwOi+a6qluSlaI=; b=qlLN5NyJHX6RRrKfb++zKa/8XCACXcfFkJ4dhuX0UziTJHT6HtYh68xKtfoAWLF8/+ EZnE+c0oQm2hRbDZQiXVVROYD3NvSp5if5K0WGoV3kOu989alrI1FXUxriD4BDgcB4Eu lL+dwarT5wGYq/VriuyOY8Ey9Cz8CQ/W6KIlyzoJsfC4oiuiI3SfEgB/0KZVqm+pqtuX l9VUdmgAUA+RCMNPumM31y9ILfB+yljENmUTRwlRqJVvxfvZGGYv0nTcJHABKIazlMJu y6+gsrB4n+Vh9llHJgw2OlD+oHlWXUmOUIUiR20YDruicBGeK3AoRhiCT6Y2opxFTZJD +utA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=/JCgUwvAHSVUkOG7qXFAorRKjR5ybGwOi+a6qluSlaI=; b=P5ndoOvWtoG6b6EApOoUKT8s4UxcplMK37piPyN6LHx76azdKglZe8bCCtAXMgkLye FumYjNoZYSuh9+4Vwn8xLmmvbYJJRFHVySM7MBq+U3H+t2etu7EZ2BxipGdGGUwzYjTg 83CdFc10CfDG5lQlMtb9VUXHTdpSmmewwp1jGQNBpFw/PqWxO0fRJFiuCo/Hvm41rSSh enmfKMdXWa32B5oJ4Q0vXX0Pyzl5BCWJ8Sslhng0zWe7ReTDvhvJQwxFcBfrgXGooAie Q4+5Wn3FKk6xQIL+skq22NgywNOD8yE3Is4bE/47sTb9zfoMRbYqDJNxgI3OBi9ADXMI 6bmw== X-Gm-Message-State: AE9vXwO5SNbZ6GouCpaggQJTstB5otBSCKKMvMUh3QwmxxQxARQw3NTQ0oG+D+84OTDtew== X-Received: by 10.55.22.22 with SMTP id g22mr30739662qkh.267.1473215607561; Tue, 06 Sep 2016 19:33:27 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:e95e:7986:863:68b0? ([2601:41:c101:9364:e95e:7986:863:68b0]) by smtp.gmail.com with ESMTPSA id l22sm19767438qtl.34.2016.09.06.19.33.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Sep 2016 19:33:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_22850B6F-C462-4589-A5B5-C5A11F3E5393" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Tue, 6 Sep 2016 22:33:37 -0400 Message-Id: References: <0ef901d20544$57cc7da0$076578e0$@zipdx.com> <7594FB04B1934943A5C02806D1A2204B4BC829D5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BC82CC7@ESESSMB209.ericsson.se> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , David Frankel , Christer Holmberg Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint X-BeenThere: stir@ietf.org 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: Wed, 07 Sep 2016 02:33:31 -0000 --Apple-Mail=_22850B6F-C462-4589-A5B5-C5A11F3E5393 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I did get this comment from other folks as well and for mky, I will be = updating in the next release of passport incorporating a MUST for = ordering fingerprint values in lexicographic order to guarantee it = validating in the case where fingerprint order is changed. Hopefully this should solve your concerns. Thanks. > On Sep 2, 2016, at 4:12 PM, Peterson, Jon = wrote: >=20 >=20 > To recover these if they were removed requires the presence of = "canon." That does not mean that "canon" is or should be required. >=20 > Again, the decision to make "canon" optional depends on how common we = anticipate these removal cases will be, and how heavily we would weigh = the cost of increasing the message size every time we use Identity. = We've had this discussion a number of times now, including a consensus = call at the last meeting, and consistently the conclusion has been to = keep "canon" optional. This "mkey" one especially I do not anticipate = will result in a common failure condition. >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Christer Holmberg > > Date: Friday, September 2, 2016 at 1:01 PM > To: Jon Peterson >, David Frankel >, "stir@ietf.org " = > > Subject: RE: [stir] RFC 4474bis Last Call - Fingerprint >=20 >> Hi, >> =20 >> >PASSporT is designed to allow media streams to be reordered (again, = this is one of the >cases Jonathan Lennox raised that got us to change = the original "mkey" syntax). Setting an >"m=3D" line to zero and = removing the associated fingerprint will also be captured by "canon" = >and should be recoverable - provided of course that the intermediaries = are willing to let >"canon" through. >> =20 >> Doesn=92t that require =93canon=94, and the claims, to be present in = the request? In the latest version of 4474bis they are still optional=85 >> =20 >> Regards, >> =20 >> Christer >> =20 >> =20 >> =20 >> From: stir > on = behalf of Christer Holmberg > >> Date: Friday, September 2, 2016 at 12:02 PM >> To: David Frankel >, = "stir@ietf.org " > >> Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint >> =20 >>> Hi, >>> =20 >>> In addition to the cases David presented, there can also be an = intermediary disables media by setting the m=3D line port value to zero. = In such cases the intermediary may also remove all fingerprint = attributes associated with the m=3D line. >>> =20 >>> And, even if all fingerprints sent by the signer reach the verifier, = there is no guarantee they will be in the same matter. Not sure whether = it matters as far as calculating the signature is concerned, but just to = keep in mind=85 >>> =20 >>> In general, assuming we are going to use (or at least allow) = Appendix F, we cannot change any =93MUST=94 to =93MAY=94, because we = need to specify exactly what content is used to calculate the signature, = as that information will not be carried in the SIP message. >>> =20 >>> Regards, >>> =20 >>> Christer >>> =20 >>> =20 >>> =20 >>> From: stir [mailto:stir-bounces@ietf.org = ] On Behalf Of David Frankel >>> Sent: 02 September 2016 21:04 >>> To: stir@ietf.org >>> Subject: [stir] RFC 4474bis Last Call - Fingerprint >>> =20 >>> Greetings. >>> =20 >>> I find myself worried about the following text in the 4474bis draft = at 4.1: >>> =20 >>> =93Fourth, if the request contains an SDP message body, and if that = SDP contains one or more "a=3Dfingerprint" attributes, then the JSON key = "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint = attributes (if they differ), following the format given in = [I-D.ietf-stir-passport] Section 3.2.2.2.=94 >>> =20 >>> As I understand it, this is done to ensure that the fingerprint has = not been altered (perhaps by a =93man in the middle=94) and give = confidence that the media is encrypted end-to-end. >>> =20 >>> However, I fear that this may break STIR in some = not-entirely-uncommon situations. Public network SIP calls are routinely = re-originated (as we=92ve discussed). Sometimes the RTP will still go = end-to-end unaltered, but in other cases it may be necessary to = terminate and re-originate the stream as well as the SIP messaging. For = example, a transit operator might need to transcode the audio if the = operators on either side don=92t have matching codecs. For example, a = transit operator might transcode wideband audio between G.722.2 (AMR-WB) = and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law = and mu-law. (The reality may be that anybody that can handle a-law can = handle mu-law, so transcoding should =93never=94 be required for G.711.) = There could be other examples. I guess for lawful intercept (CALEA) the = interceptor would still be able to LISTEN without altering the = fingerprint, so perhaps that wouldn=92t break the STIR signature. >>> =20 >>> I raise the point for discussion. (The details here are a bit = outside my expertise, and I probably missed some earlier discussion.) = One possible suggestion is to change =93MUST=94 to =93MAY=94 in the text = I quoted above. This gives the originator of the call the opportunity to = decide whether they want downstream operators to have the flexibility to = alter the fingerprint but still maintain the end-to-end identity = assurance offered with STIR. An originator may be mostly concerned with = protecting their media on the first hop; this would let them do that (I = think). >>> =20 >>> While protecting the fingerprint is a nice-to-have, I didn=92t = recall it in the STIR charter or problem statement. >>> =20 >>> David >>> =20 >>> David Frankel >>> ZipDX=AE LLC >>> Monte Sereno, CA USA >>> Tel: 1-800-FRANKEL (1-800-372-6535) >>> Watch Our Video! >>> =20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_22850B6F-C462-4589-A5B5-C5A11F3E5393 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I did get this comment from other folks as = well and for mky, I will be updating in the next release of passport = incorporating a MUST for ordering fingerprint values in lexicographic = order to guarantee it validating in the case where fingerprint order is = changed.

Hopefully this should solve your concerns.

Thanks.

On Sep 2, 2016, at 4:12 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


To recover these if they were = removed requires the presence of "canon." That does not mean that = "canon" is or should be required.

Again, the decision to = make "canon" optional depends on how common we anticipate these removal = cases will be, and how heavily we would weigh the cost of increasing the = message size every time we use Identity. We've had this discussion a = number of times now, including a consensus call at the last meeting, and = consistently the conclusion has been to keep "canon" optional. This = "mkey" one especially I do not anticipate will result in a common = failure condition.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 2, = 2016 at 1:01 PM
To: Jon Peterson <jon.peterson@neustar.biz>, David Frankel <dfrankel@zipdx.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] RFC = 4474bis Last Call - Fingerprint

Hi,
 
>PASSporT is designed to allow media streams to be = reordered (again, this is one of the >cases = Jonathan Lennox raised that got us to change the original "mkey" = syntax). Setting an >"m=3D"= line to zero and removing the associated fingerprint will also be = captured by "canon" >and = should be recoverable - provided of course that the intermediaries are = willing to let >"canon" through.
 
Doesn=92t = that require =93canon=94, and the claims, to be present in the request? = In the latest version of 4474bis they are still optional=85
 
Regards,
 
Christer
 
 
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 2, = 2016 at 12:02 PM
To: David Frankel <dfrankel@zipdx.com>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] RFC 4474bis = Last Call - Fingerprint
 
Hi,
 
In addition to the cases David presented, there can = also be an intermediary disables media by setting the m=3D line port = value to zero. In such cases the intermediary may also remove all = fingerprint attributes associated with the m=3D line.
 
And, even if all = fingerprints sent by the signer reach the verifier, there is no = guarantee they will be in the same matter. Not sure whether it matters = as far as calculating the signature is concerned, but just to keep in = mind=85
 
In general, assuming we are going to use (or at least = allow) Appendix F, we cannot change any =93MUST=94 to =93MAY=94, because = we need to specify exactly what content is used to calculate the = signature, as that information will not be carried in the SIP = message.
 
Regards,
 
Christer
 
 
 
From: stir [mailto:stir-bounces@ietf.org] On Behalf = Of David = Frankel
Sent: 02 September 2016 21:04
To: stir@ietf.org
Subject: [stir] RFC 4474bis Last = Call - Fingerprint
 
Greetings.
 
I find myself worried about the following text in the 4474bis = draft at 4.1:
 
=93Fourth, if the = request contains an SDP message body, and if that SDP contains one or = more "a=3Dfingerprint" attributes, then the JSON key "mky" MUST appear = with the algorithm(s) and value(s) of the fingerprint attributes (if = they differ), following the format given in [I-D.ietf-stir-passport] = Section 3.2.2.2.=94
 
As I understand = it, this is done to ensure that the fingerprint has not been altered = (perhaps by a =93man in the middle=94) and give confidence that the = media is encrypted end-to-end.
 
However, I fear = that this may break STIR in some not-entirely-uncommon situations. = Public network SIP calls are routinely re-originated (as we=92ve = discussed). Sometimes the RTP will still go end-to-end unaltered, but in = other cases it may be necessary to terminate and re-originate the stream = as well as the SIP messaging. For example, a transit operator might need = to transcode the audio if the operators on either side don=92t have = matching codecs. For example, a transit operator might transcode = wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and = G.711. Or possibly between G.711 a-law and mu-law. (The reality may be = that anybody that can handle a-law can handle mu-law, so transcoding = should =93never=94 be required for G.711.) There could be other = examples. I guess for lawful intercept (CALEA) the interceptor would = still be able to LISTEN without altering the fingerprint, so perhaps = that wouldn=92t break the STIR signature.
 
I raise the point for discussion. (The details here are a bit = outside my expertise, and I probably missed some earlier discussion.) = One possible suggestion is to change =93MUST=94 to =93MAY=94 in the text = I quoted above. This gives the originator of the call the opportunity to = decide whether they want downstream operators to have the flexibility to = alter the fingerprint but still maintain the end-to-end identity = assurance offered with STIR. An originator may be mostly concerned with = protecting their media on the first hop; this would let them do that (I = think).
 
While protecting = the fingerprint is a nice-to-have, I didn=92t recall it in the STIR = charter or problem statement.
 
David
 
David = Frankel
ZipDX=AE LLC
Monte Sereno, CA USA
Tel: = 1-800-FRANKEL (1-800-372-6535)
Watch Our Video!
 
<= /blockquote>_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_22850B6F-C462-4589-A5B5-C5A11F3E5393-- From nobody Fri Sep 9 04:32:56 2016 Return-Path: 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 B50E812B0E8 for ; Fri, 9 Sep 2016 04:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tWe32Ihxmv01 for ; Fri, 9 Sep 2016 04:32:54 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD7112B00E for ; Fri, 9 Sep 2016 04:32:53 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-10-57d29de37ac4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 57.64.04209.3ED92D75; Fri, 9 Sep 2016 13:32:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0301.000; Fri, 9 Sep 2016 13:32:50 +0200 From: Christer Holmberg To: "stir@ietf.org" Thread-Topic: 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCo3lfOmK4VV2fUuPoIrZGoG5sQ== Date: Fri, 9 Sep 2016 11:32:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D3F87914EF96christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7k+6TuZfCDU5MYLFYvnYbkwOjx5Il P5kCGKO4bFJSczLLUov07RK4MpbNOMFa0ClS0dMW2cD4TKCLkZNDQsBE4uKqVSxdjFwcQgLr GSWmfLnICpIQEljMKHFiY00XIwcHm4CFRPc/bZCwiICyxJZ1d9hBbGEBO4l1M9+xQ8SdJRpu tDJC2HoSP690gI1hEVCRWDyzlRnE5hWwkljRsJcNxGYUEJP4fmoNE4jNLCAucevJfCaIewQk luw5zwxhi0q8fPwPbI4o0MzvX2dDxRUldp5tZ4bojZf49GsX1HxBiZMzn7BMYBSahWTsLCRl s5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjhG0tsX7HWTZkNQsYOVYxihanFiflphsZ66UW ZSYXF+fn6eWllmxiBMbJwS2/VXcwXn7jeIhRgINRiYf3Qd7FcCHWxLLiytxDjBIczEoivItn XQoX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwGj6hLst SEDkTFXKzEnaS/vLLdasi1YMT/sp+05F7dlDnodXj3l7PVdev4/tj7rBqVN5d8Oe377wT1aw erdKren55JXb45RmJZj3fwg2+PVHWJRnsraey4VwNcVAR7l5M6d4RCRuP7JBx+BmHMdH438P XZMnRr5qehWZ+GAaU/Hp6i23Mn9sm6nEUpyRaKjFXFScCABvnf5xjwIAAA== Archived-At: Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 09 Sep 2016 11:32:56 -0000 --_000_D3F87914EF96christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Section 8 of draft-4474bis says (or, that=92s at least my reading) that, if= the SIP request contains multiple identities (e.g. if the request in addit= ion to the From header field contains one or more P-Asserted-Identity heade= r fields), it is RECOMMENDED to include =93canon=94, so that the verifier k= nows which identity to verify. Why is this only RECOMMENDED? If there are more than one identity, shouldn= =92t it be a MUST? I don=92t think we want the verifier to try all identiti= es, and see which one (if any) works, do we? Now, the text DOES talk about =93local policy=94 when it comes to choosing = between From and PAI for deriving the identity, so perhaps we could say =93= MUST, unless local policy defines from where the identity is retrieved=94, = or something like that=85 Regards, Christer --_000_D3F87914EF96christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <06FA0EC3FF7C9C429FEBF36568018C0E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Section 8 of draft-4474bis says (or, that=92s at least my reading) tha= t, if the SIP request contains multiple identities (e.g. if the request in = addition to the From header field contains one or more P-Asserted-Identity = header fields), it is RECOMMENDED to include =93canon=94, so that the verifier knows which identity to verif= y.

Why is this only RECOMMENDED? If there are more than one identity, sho= uldn=92t it be a MUST? I don=92t think we want the verifier to try all iden= tities, and see which one (if any) works, do we?

Now, the text DOES talk about =93local policy=94 when it comes to choo= sing between From and PAI for deriving the identity, so perhaps we could sa= y =93MUST, unless local policy defines from where the identity is retrieved= =94, or something like that=85

Regards,

Christer
--_000_D3F87914EF96christerholmbergericssoncom_-- From nobody Fri Sep 9 08:34:00 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C912B557; Fri, 9 Sep 2016 08:08:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147343371523.15111.7467407874650450002.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 08:08:35 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-07.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 15:08:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Persona Assertion Token Authors : Chris Wendt Jon Peterson Filename : draft-ietf-stir-passport-07.txt Pages : 19 Date : 2016-09-09 Abstract: This document defines a canonical string object or 'token' including a digital signature for verifying the author of the token, their authority to author the token and the information asserted in the token, minimally, the originating identity or 'persona' corresponding specifically to the originator of 'personal communications', or signalled communications between a set of parties with identities. The PASSporT token is cryptographically signed to protect the integrity of the identify the originator of a personal communications session (e.g. the telephone number or URI) and verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-passport-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 9 08:34:14 2016 Return-Path: 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 D089212B3B9 for ; Fri, 9 Sep 2016 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 Dc5A9T6ngmds for ; Fri, 9 Sep 2016 08:19:28 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743EA12B3DD for ; Fri, 9 Sep 2016 08:12:05 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 93so42033506qtg.2 for ; Fri, 09 Sep 2016 08:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z95y+X2wtHCElC+WYyQ2Lnh2nWhb+0U2zYVd7/nFkZQ=; b=xT18LMfCQ71atNeuUW9FP8q0BTc7ewqolrYswAQ5xp0jEeMh7v43VNOzaCqcCLe3CB nFYYvW791iCDHUWwVOorwJbUKMk5aS5ydpki/+gdnJJ7Nf1GeM6W0LFEgzQCPYUvWEHs 3iw81ueV6NdjTMEh0sO9SIuD433tBDyynmu3KAW3xvP+Wvd23gNa64t2ol82SX81lPuT 7Rl2bi3aGEageRzlDmyGOf6J5/65wl/wQJhODlknjpMD0vV/1IMF2ByEAfkeAAC7KZyL O3IM0TU0Lqa+dGJWloBIqfX0oMadqVHXxSUcN1K9E8kKOoUllLlt8wUZDbglAtoQNnWp aRSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z95y+X2wtHCElC+WYyQ2Lnh2nWhb+0U2zYVd7/nFkZQ=; b=Bi+FJqObN3mKSR8O1mACIIauw/MV93G4Ih7EbES3aKoBo/HJm3K8sQXJo47g//whZ6 1f7oCFpZ9F1SM3HEL+35MIYIJ/C0QKQCUK7NgFndPV8+ILtwiXCCJj9SY1uD1qumvzpW 1zPwcHDbmgM3LJFhJ0HS+DoOMhDosIvvDD8wt5p9c3uXciHcwubWTBnS2/CNIzuM3KBt Ksvtn1up2YFP1LiPei9x5ZqpxOzgTXiW8Rt6QKa4xXuiQw11mLTDpOIyiTYd4cCcXsfG /yy5zJum39Ciet+IxsZJPTldxvED9gP+ZxJorEVzuaRyFtmYPAQJ5yYdCkxMCXN9B59g iwtQ== X-Gm-Message-State: AE9vXwMVqzEqk4mIPSBd/uZ0RfMQVh+6pqGONqgahA7Cge5Bw7j3K1JuzjyP+HxRX1bZWQ== X-Received: by 10.200.34.135 with SMTP id f7mr4425951qta.141.1473433924175; Fri, 09 Sep 2016 08:12:04 -0700 (PDT) Received: from [10.0.1.203] (c-73-13-103-172.hsd1.pa.comcast.net. [73.13.103.172]) by smtp.gmail.com with ESMTPSA id w67sm2267543qkb.24.2016.09.09.08.12.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Sep 2016 08:12:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: <8fd2cf67-5241-039a-e3a4-a9ad0928023a@dcrocker.net> Date: Fri, 9 Sep 2016 11:12:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <07e0eb16-6758-cdf1-c571-1f1ed768e741@dcrocker.net> <67A1F75C-DAA9-4E84-8C70-9A392A90FF6F@chriswendt.net> <8fd2cf67-5241-039a-e3a4-a9ad0928023a@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] Review of: draft-ietf-stir-passport-05 X-BeenThere: stir@ietf.org 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: Fri, 09 Sep 2016 15:19:37 -0000 HI Dave, Thanks again for the comments, i have submitted 07 version of draft that = incorporates the fixes and modifications hopefully addressing most of = your feedback. The new draft also provides other private comments i have received as = well. Thanks! -Chris > On Aug 27, 2016, at 5:40 PM, Dave Crocker wrote: >=20 > Chris, >=20 > Thanks for the followup. Pruned responses to responses, below... >=20 > \ > On 8/22/2016 10:58 AM, Chris Wendt wrote: >>> Detailed Comments ----------------- >>>> STIR >>>> C. Wendt Internet-Draft >>>> Comcast Intended status: Standards Track >>>> J. Peterson Expires: January 23, 2017 >>>> Neustar Inc. July 22, 2016 >>>>=20 >>>>=20 >>>> Persona Assertion Token draft-ietf-stir-passport-05 >>>>=20 >>>> Abstract > ... >>> Is the timestamp the basis of claiming non-repudiation? >>=20 >> Partially, depending on your interpretation of how non-repudiation is >> achieved. The digital signature based on a certificate is the >> non-repudiation of the original assertion and signing of the token. >=20 > That seems to equate authentication with non-reputation of originator. = But they aren't the same. >=20 > = http://security.stackexchange.com/questions/6730/what-is-the-difference-be= tween-authenticity-and-non-repudiation >=20 > Worse, the opening sentence above, means that there is no way to know = what the term applies to or how to validate its use. >=20 > At the least, a technical specification should use terms of art = precisely and should provide enough detail so there is reliable, = cross-reader understanding of its meaning and appropriateness in the = document. >=20 > When the term refers to something that is foundational-but-partial, = such as working 'in support of' something else that is detailed outside = of the specification or hasn't even been detailed anywhere, then there = needs to be text that explains the basis of that support. >=20 > For example, authentication of an identifier used in an email = 'supports' the development of accurate and reliable reputation = assessment for mail associated with the identifier. A specification for = authentication that makes this assertion but does not specify the detail = for achieving that use needs to explain the claim, such as: It does = that by ensuring that the identifier's use is only by authorized = entities, thereby eliminating the reputation analysis 'noise' from = unauthorized use of the identifier in messages. >=20 > The current spec needs to similarly explain/justify a claim of use for = non-reputation, but with something more substantive and reliable than = "depending on your interpretation". To the extent that it's useful in = some cases of non-repudiation and not others, there should be an = explanation of which cases it helps and how. Removed non-repudiation from the overview, the solution consideration = also reinforces the point that only the signer can be verified, not the = claims. >=20 >=20 >> The timestamp and including the destination identity adds the ability >> to further validate that there wasn=E2=80=99t someone illegitimate = that >> simply replayed the sending of the token. >=20 > My understanding is that a replay attack is quite different from = non-repudiation protection. So the text should not conflate the two. agree, addressed above >=20 >=20 >>>> repudiation the sender of and authorization to send information >>>> related to the originator of personal communications. A >>>=20 >>> 'info related to'... what does this mean? >>=20 >> Yes this was a bit too broad and the abstract text wasn=E2=80=99t = updated >> when the scope was reduced. >>=20 >> replaced with: 'non-repudiation the author of the token, their >> authority to author the token and, minimally, the asserted >> originating identity or persona contained within the token >> corresponding specifically to the originator of personal >> communications' >=20 > My guess is that all of the above fall under authentication, not = non-repuduation. If my guess is wrong, it really would help to see a = careful explanation of how it is non-repudiation rather than = authentication. >=20 agreed, addressed above >=20 >=20 >>>> This document defines a common method for creating and validating >>>> a >>>=20 >>> [common] delete >>=20 >> fixed >>=20 >>>=20 >>>> token that cryptographically verifies an originating identity, >>>> or more generally a URI or application specific identity string >>>=20 >>> 'identity string'? what does this mean? >>>=20 >>> 'app string id'? what does this mean? >>=20 >> Removed and replaced with 'URI or telephone number' >=20 > So this seems like a good place to raise this basic question: I = thought all of the strings that were to be used at 'identity' strings = started as URIs, albeit with some variations on the type of URI. >=20 > Also, there is the continuing point that has been repeatedly stressed = that STIR's current goal is telephone numbers, not other forms of = addressing. Yes, but i think the consensus is that it wouldn=E2=80=99t be a bad = thing to be compatible with SIP URIs at a minimum, and have a framework = that could be accommodated in the future if necessary. >=20 >=20 >>>> representing the originator of personal communications. Through >>>> extended profiles other information relevant to the personal >>>> communications can also be attached to the token. The primary >>>> goal of PASSporT is to provide a common framework for signing >>>> persona >>>=20 >>> What is a 'persona'? Where is this construct introduced or cited >>> and explained? >>=20 >> =E2=80=98persona=E2=80=99 replaced with 'originating identity' >>=20 >>>=20 >>> 'profiles'? Where is this construct introduced or cited and >>> explained? >>=20 >> replaced with 'Through extensions defined in this document' >=20 > Normally, when extensibility is permitted, a base document like this = defines the extensibility mechanism and might or might not /also/ give = an initial set of extensions. >=20 > (In which case, these really are 'options' and not 'extensions', but = yes, that's just quibbling...) >=20 > In any event, the reference should point to where the extensions or = extensibility mechanism are specified. >=20 provided a section reference >=20 >=20 >>>> however this is intentionally out of scope for this document. >>>>=20 >>>> Note: As of the authoring of this document, >>>> [I-D.ietf-stir-rfc4474bis] provides details of how to use >>>> PASSporT within SIP signaling for the signing and verification of >>>> telephone numbers. >>>=20 >>> remove Note. Or make it a note to RFC Editor to remove it, or >>> rephrase so it's useful 10 years from now. >>=20 >> Would probably like a reference here, don=E2=80=99t want to just = remove. >=20 > Why? It's an uplink reference. This is a component system used by = rfc4474bism. So the uplink confuses the relationship and messes with = the clean, subsystem interface. I changed this from a Note to a explicit reference, hopefully that = covers your concern. >=20 >=20 >=20 >>>> 2. Token Overview >>>>=20 >>>> Tokens are a convenient way of encapsulating information with >>>=20 >>> Why? What are the alternatives? Why is this the starting point? >>>=20 >>>=20 >>>> associated digital signatures. They are used in many >>>> applications >>>=20 >>> Such as? >>>=20 >>> Anyhow, this section seems to take the construct of 'token' as >>> being an established term of art. It isn't. Or, at least, I've no >>> idea what is meant here that distinguishes a token from anything >>> else, such as other forms of encapsulation. Say/cite what a token >>> is, if it is such a distinctive thing. Say/cite how it differs >>> from alternatives, if its superiority is going to be touted. >>>=20 >>>=20 >>>> that require authentication, authorization, encryption, non- >>>> repudiation and other use cases. JSON Web Token (JWT) [RFC7519] >>>> and JSON Web Signature (JWS) [RFC7515] are designed to provide a >>>> compact form for many of these purposes and define a specific >>>> method and syntax for signing a specific set of information or >>>> "claims" within the token and therefore providing an extensible >>>> set of claims. Additionally, JWS provides extensible mechanisms >>>> for specifying the method and cryptographic algorithms used for >>>> the associated digital signatures. >>>=20 >>> Note that there is nothing in the above text that actually explains >>> what a token is or how it differs from things that aren't tokens. >>=20 >> I would challenge the fact that =E2=80=98token=E2=80=99 is a term of = art, but i >> suppose maybe it depends on what crowd you run with. In either case, >> I defined it as a canonical string object at the beginning of the >> document. >=20 > If it is not a term of art, then what does it mean and why is it used? = That is, it is used here as if it has distinctive meaning -- even at the = level of being part of a section title! -- but the meaning isn't = provided. Sorry i phrased my last comment incorrectly, I DO believe it is a term = of art, but in either case i specifically defined it. >=20 >=20 >>>> 3.1.3. "x5u" (X.509 URL) Header Parameter >>>>=20 >>>> As defined in JWS, the "x5u" header parameter is used to provide >>>> a URI [RFC3986] referring to the resource for the X.509 public >>>> key certificate or certificate chain [RFC5280] corresponding to >>>> the key >>>=20 >>> So this service uses a classic X.509 authentication hierarchy? >>> That's a key design point, only mentioned in a third-level >>> section. >>=20 >> clarified this in overview >>=20 >>>=20 >>>=20 >>>> used to digitally sign the JWS. Note: The definition of what the >>>> URI represents in terms of the actor serving the X.509 public key >>>> is out >>>=20 >>> 'actor serving the X.509 public key' ? what does that mean? >>=20 >> removed >>=20 >>>=20 >>>> of scope of this document. However, generally this would >>>> correspond to an HTTPS or DNSSEC resource with the guidance that >>>> it MUST be a >>>=20 >>> [a] remove >>=20 >> fixed >>=20 >>>=20 >>>> TLS protected, per JWS spec. >>>=20 >>> This /object/ specification (that is transport independent) >>> dictates /transport/ security??? This is probably wrong, but at >>> least needs careful explanation. >>>=20 >>=20 >> This is mostly a comment towards security consideration >> recommendation. I could remove the comment if it=E2=80=99s bothering = folks. >=20 > For specification of a discrete component like this, which should be = entirely independent of lower-level transport, etc. issues, I think the = legitimate concern is noting that nature of sensitive information is = carries and the need to protect that information 'appropriate', but to = treat or state that the details of that protection are outside the scope = of this specification. >=20 >=20 changed to "Generally, as defined in JWS section 4.1.5, this would = correspond to an HTTPS or DNSSEC resource using integrity protection." >=20 >>>> 3.2.1. JWT defined claims >>>=20 >>> When something like this is imported from another spec, there needs >>> to be a precise pointer to the specific part of the spec defining >>> it. >>=20 >> This was the text provided by Ted based on discussion in Berlin, but >> beyond that i=E2=80=99m not seeing what isn=E2=80=99t specific = enough. >=20 > iat - rfc7519, section 4.1.6, as I noted. >=20 > etc. >=20 > In other words, try to never require the reader to search around an = entire document for the information being imported or referenced. >=20 ok, got it, i think i did update those references, or at least they seem = to have section references into the documents. >=20 >=20 >>>> 3.2.2.1. Originating and Destination Identity Claims >>>>=20 >>>> Baseline PASSporT defines claims that convey the identity of the >>>=20 >>> "Baseline PASSporT defines claims" ? First reference in a >>> 4th-level section??? >>=20 >> Removed baseline >>=20 >>>=20 >>>=20 >>>> origination and destination of personal communications. There >>>> are >>>=20 >>> 'personal'? so this can't be used by and between companies? >>> Really, there is nothing about any of this that pertains to the >>> type of users or even the content of the communication. >>=20 >> defined =E2=80=98personal communications' >>=20 >>>=20 >>> What is the exact definition or origination and destination? For >>> example, there is an important distinction between the person >>> making a call vs. the device they are using, versus the provider >>> they are going through. Which is meant here and how is the reader >>> to know? (cf, call for a terminology section.) >>=20 >> we don=E2=80=99t want to make the distinction here, it=E2=80=99s only = about the >> identity, URI or TN. whether device or network. we don=E2=80=99t = want to >> predetermine what the end to end architecture is, this is protocol >> only. >=20 > origination and destinction are extremely important terms of art for = STIR and for this specification. if they have no meaning, don't use = them. if they have to be used, they need to be carefully defined, = either here or in a cited document. Modified this paragraph to be the following:=20 PASSporT defines claims that convey the identity of the origination and = destination of personal communications. Origination in the context of = PASSporT and for a given application=E2=80=99s use of PASSporT is the = point in the network that has the authority to assert the callers = identity. This authority is represented in PASSporT by the certificate = holder and is signed at the applications choice of authoritative = point(s) in the network, for example, at a device that has authenticated = with a user, or at a network entity with an authenticated trust = relationship with that device and it's user. Destination represents the = intended destination of the personal communications, i.e. the = identity(s) being called by the caller, The destination point(s) = determined by the application must have the capability to verify the = PASSporT token and the digital signature. The PASSporT associated = certificate is used to validate the authority of the originating signer, = generally via a certificate chain to the trust anchor for that = application. =20 >=20 >=20 >>>> two claims that are required for PASSporT, the "orig" and "dest" >>>> claims. Both "orig" and "dest" should have values that are JSON >>>> objects that include identities represented by key value pairs, >>>> where >>>=20 >>> 'key value pairs' aren't 'claims'? >>>=20 >>> should and not must? why? >>>=20 >>=20 >> changed to MUST and clarified >>=20 >>>=20 >>>> the key represents an identity type and the value is the >>>> identity string. Currently, these identities can be represented >>>> as either >>>=20 >>> So, there is expectation of other types? There needs to be a >>> pointer to an IANA registry. >>=20 >> we do have IANA request for these types, will add text once i figure >> out how to point to that >>=20 >>>=20 >>>=20 >>>> telephone numbers or Uniform Resource Indicators (URIs). The >>>> definition of how telephone numbers or URIs and examples are >>>> provided below. >>>>=20 >>>> The "orig" JSON object MUST only have one key value pair >>>> representing the asserted identity of any type (currently either >>>> "tn" or "uri") of the originator of the personal communications >>>> signaling. >>>>=20 >>>> The "dest" JSON object MUST have at least have one key value >>>> pair, but could have multiple identity types (i.e. "tn" and/or >>>> "uri") but only one of each. Additionaly, in the case of "dest" >>>> only, the identity type key value MUST be an array signaled by >>>> standard JSON brackets, even when there is a single identity >>>> value in the identity type key value. >>>>=20 >>>> 3.2.2.1.1. "tn" - Telephone Number identity >>>=20 >>> A document that uses five-levels of section numbering warrants >>> reconsideration of its structure. >>=20 >> fair point, looking for suggestion >=20 > My personal style is to try to have at most 3 levels, with the table = of contents showing only the first two. OVerall it seems to be cleaner, = but yeas, that's purely a matter of taste (although there are also some = human factors cognitive loading issues when there are more than 3 levels = in a structure...) >=20 > (Re-)organzing things to fit that model sometimes requires creativity. >=20 > But since you asked... >=20 >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. PASSporT Token Overview . . . . . . . . . . . . . . . . . . . 3 >=20 > 3. PASSporT Header . . . . . . . . . . . . . . . . . . . . . 4 > 3.1.1. "typ" (Type) Header Parameter . . . . . . . . . . . . = 4 > 3.1.2. "alg" (Algorithm) Header Parameter . . . . . . . . . = 4 > 3.1.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . = 4 > 4 PASSporT Payload . . . . . . . . . . . . . . . . . . . . 5 > 3.2.1. JWT defined claims . . . . . . . . . . . . . . . . . = 5 > 3.2.1.1. "iat" - Issued At claim . . . . . . . . . . . . . = 5 > 3.2.2. PASSporT specific claims . . . . . . . . . . . . . . = 5 > 3.2.2.1. Originating and Destination Identity Claims . . . = 5 > 3.2.2.2. "mky" - Media Key claim . . . . . . . . . . . . . = 7 > 3.3. PASSporT Signature . . . . . . . . . . . . . . . . . . . = 8 > 5. Extending PASSporT . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. "ppt" (PASSporT) header parameter . . . . . . . . . . . . = 8 > 4.2. Extended PASSporT Claims . . . . . . . . . . . . . . . . = 9 > 6. Deterministic JSON Serialization . . . . . . . . . . . . . . 9 > 5.1. Example PASSport deterministic JSON form . . . . . . . . = 10 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 > 6.1. Avoidance of replay and cut and paste attacks . . . . . . = 10 > 6.2. Solution Considerations . . . . . . . . . . . . . . . . . = 10 > 6.3. Privacy Considerations . . . . . . . . . . . . . . . . . = 11 >=20 >=20 > For deeper subsections, consider converting them to a labeled hanging = indent. This especially works when there's already a convenient label, = like 'iat'. >=20 > Lots of small subsections tends to break up the reading. Hanging = indents don=E2=80=99t. Have for the most part followed your suggestion, thanks. >=20 >=20 >>>>=20 >>>> If the originating or destination identity is a telephone number, >>>> the key representing the identity should be "tn". >>>=20 >>> should and not must??? why? >>=20 >> fixed >>=20 >>>=20 >>>=20 >>>> Telephone Number strings for "tn" MUST be canonicalized according >>>> to the procedures specified in [I-D.ietf-stir-rfc4474bis] Section >>>> 7.2. >>>=20 >>> Actually, this dependency on 4474bis seems odd. >>>=20 >>> Given that the phone number construct is at the core of the work >>> here and this is the essential data object, and this object is >>> presumably intended for use outside of 4474bis, I'd expect that >>> canonicalization algorithm to be here. >>>=20 >>> If 4474 needs to cite/use the algorithm, it can cite here, which it >>> already will have to do. There is no other normative use of 4474 >>> in this document. >>>=20 >>=20 >> needs discussion >=20 > oh goodie. Some discussion has happened between authors and Working Group chairs on = this. Considered new draft specifically for telephone number = canonicalization, but given time and practicalities of imposing this = pretty disruptive change at this point, the current conclusion was to = continue to reference 4474bis as a default definition of telephone = number canonicalization for SIP for STIR. >=20 >=20 >=20 >>>> 3.2.2.1.2. "uri" - URI identity >>>>=20 >>>> If any of the originating or destination identities is of the >>>> form URI, as defined in [RFC3986], the key representing the >>>> identity should be "uri" URI form of the identity. >>>=20 >>> should and not must? why? >>=20 >> fixed >>=20 >>>=20 >>>=20 >>>> 3.2.2.1.3. Future identity forms >>>>=20 >>>> We recognize that in the future there may be other standard >>>> mechanisms for representing identities. The "orig" and "dest" >>>> JSON >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Wendt & Peterson Expires January 23, 2017 >>>> [Page 6] >>>>=20 >>>> Internet-Draft PASSporT >>>> July 2016 >>>>=20 >>>>=20 >>>> objects with "tn" and "uri" allow for other identity types with >>>> unique keys to represent these forms. >>>=20 >>> Recognition is dandy, but where is the specification detail to >>> support the extensibility? >>=20 >> clarified text >>=20 >>>=20 >>>=20 >>>> 3.2.2.1.4. Examples >>>=20 >>> *** Explain these examples, so they aren't merely syntax detail >>> *** >>>=20 >>>=20 >>>> Single Originator to Single Destination example: >>>>=20 >>>> { "dest":{"uri":["sip:alice@example.com"]}, "iat":"1443208345", >>>> "orig":{"tn":"12155551212"} } >>>>=20 >>>> Single Originator to Multiple Destination Identities example: >>>>=20 >>>> { "dest":{ "tn":["12125551212"], "uri":["sip:alice@example.com", >>>> "sip:bob@example.net"] }, "iat":"1443208345", >>>> "orig":{"tn":"12155551212"} } >>>>=20 >>>> 3.2.2.2. "mky" - Media Key claim >>>>=20 >>>> Some protocols that use PASSporT convey hashes for media >>>> security keys within their signaling in order to bind those keys >>>> to the identities established in the signaling layers. One >>>> example would be the DTLS-SRTP key fingerprints carried in SDP >>>> via the "a=3Dfingerprint" attribute; multiple instances of that >>>> fingerprint may appear in a single SDP body corresponding to >>>> difference media streams offered. >>>=20 >>> difference -> different? >>>=20 >>> The above text belongs elsewhere, explaining the overall set of >>> capabilities, use cases, and the like In a definitions section >>> like this, focus on definitions, not discussions about use. >>>=20 >>> First use of 'SDP', with no explanation of its meaning. >>=20 >> Added citation >>=20 >>>=20 >>> 'DTLS-SRTP' citation? >>>=20 >>> And again, how does this citation slip into a transport-independent >>> object signing spec? >>=20 >> Meant to be a useful/likely used example. >=20 > Well, I fear it's a relatively esoteric reference, so that it probably = needs to assume less familiarity by the reader, which is to say the = example needs to explain itself more. Removed DTLS-SRTP reference and replaced with a citing a reference to = a=3Dfingerprint definition in rfc4572#section-5 which i think covers = things better anyway. >=20 >=20 >=20 >>>> 4.2. Extended PASSporT Claims >>>>=20 >>>> Future specifications that define such extensions to the >>>> PASSporT >>>=20 >>> [Future] remove >>>=20 >>> [such] remove. there's no context for it. >>=20 >> removed >>=20 >>>=20 >>>=20 >>>> mechanism MUST explicitly designate what claims they include >>>> beyond >>>=20 >>> designate -> specify (it's defining, not appointing) >>=20 >> fixed >>=20 >>>=20 >>>=20 >>>> the base set of claims from this document, the order in which >>>> they will appear, and any further information necessary to >>>> implement the extension. All extensions MUST incorporate the >>>> baseline JWT elements specified in Section 3; claims may only be >>>> appended to the claims >>>=20 >>> If all extensions include the baseline, then 'must incorporate' is >>> an odd way to say that >>=20 >> changed to include >>=20 >>>=20 >>> This seems best and first handled by earlier in the spec, by >>> providing a syntax (and text) that shows the base set and then an >>> optional extended set. With that setup, it is clear that >>> extensions are always /in addition to/ the base. >>=20 >> JSON sort of provides this capability inherently, so would prefer to >> keep it simple rather than adding more protocol. >=20 > The 'sort of' does not encourage confidence about the resolution of = this point=E2=80=A6 >=20 added basic example, we could also point to draft-peterson-stir-cnam-00 = as a specific example >=20 >=20 >=20 >>> The JSON object MUST follow the rules for the construction of >>>> the thumbprint of a JSON Web Key (JWK) as defined in [RFC7638] >>>> Section 3. Each JSON object MUST contain no whitespace or line >>>> breaks before or after any syntactic elements and with the >>>> required members ordered lexicographically by the Unicode >>>> [UNICODE] code points of the member names. >>>=20 >>> mumble. >>=20 >> ? >=20 > I was reacting the to the redundant specification here, as well as to = its being in prose that gets a bit complicated. (Humans process = negation and discussion worse than conjunction.) >=20 > Basically, this spec should not be repeated technical details that are = being specified elsewhere and used here. They should be be reference. >=20 Agree, fixed the reference to be more accurate without repeating text. >=20 >=20 >>>> 5.1. Example PASSport deterministic JSON form >>>>=20 >>>> For the example PASSporT Payload shown in Section 3.2.2.2, the >>>> following is the deterministic JSON object form. >>>>=20 >>>> {"dest":{"uri":["sip:alice@example.com"],"iat": 1443208345,"mky" >>>> :[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442 >>>> CD54F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F8 >>>> 2183B540212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}], >>>> "orig":{"tn":"12155551212"}} >>>=20 >>> Perhaps explain the steps followed to produce this? Perhaps show >>> the intermediate forms? >>>=20 >>=20 >> will discuss the need for more explicit instructions, to me, it=E2=80=99= s >> following the spec, but could improve if folks think it=E2=80=99s = necessary. >=20 > I think the main concern I was expressing was that it should a result, = without commentary, and without showing the intermediate steps. As = such, the reader learns relatively little from the example, IMO. Expanded the example with steps of construction of the final object. >=20 >=20 >=20 >>>> 7. Security Considerations >>>>=20 >>>> 7.1. Avoidance of replay and cut and paste attacks >>>>=20 >>>> There are a number of security considerations for use of the >>>> token >>>=20 >>> I suspect they are not 'security considerations' as much as >>> 'mechanisms' or 'provisions' >>>=20 >>>=20 >>>> for avoidance of replay and cut and paste attacks. PASSporT >>>> tokens must be sent along with other application level protocol >>>> information >>>=20 >>> Huh? You are trying to dictate application-level transport >>> behavior? >>>=20 >>> This smacks of layer/scoping violation. >>=20 >> changed to should and removed along, but don=E2=80=99t want to remove = this >> consideration. >>=20 >>>=20 >>>=20 >>>> (e.g. for SIP an INVITE as defined in [RFC3261]). There should >>>> be a link between various information provided in the token and >>>> information provided by the application level protocol >>>> information. >>>=20 >>> Why? >>=20 >> explained >>=20 >>>=20 >>>=20 >>>> These would include: >>>>=20 >>>> o "iat" claim should closely correspond to a date/time the >>>> message >>>=20 >>> The semantics of iat are defined earlier. Either there is >>> compliance or there isn't. The discussion here, therefore, should >>> probably say something like "a valid iat claim aids in detecting >>> re-use at a later time.=E2=80=9D >>=20 >> i am explaining the =E2=80=98why=E2=80=99 here, added a sentence = about validation and >> correlation to network time variances. >>=20 >>>=20 >>>=20 >>>> was originated. It should also be within a relative delta time >>>=20 >>> What is a delta time? How is the reader to know? Where is it >>> defined? I suspect what is meant is that it's deviation from time >>> of origination should be small. If this has a more precise >>> technical definition, then cite it. >>=20 >> removed delta >>=20 >>>=20 >>>=20 >>>> that is reasonable for clock drift and transmission time >>>> characteristics associated with the application using the >>>> PASSporT token. >>>>=20 >>>> o "dest" claim is included to prevent the ability to use a >>>> previously originated message to send to another destination >>>> party >>>=20 >>> the ability to -> using (or use of) >>=20 >> fixed with =E2=80=98valid re-use' >>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Wendt & Peterson Expires January 23, 2017 >>>> [Page 10] >>>>=20 >>>> Internet-Draft PASSporT >>>> July 2016 >>>>=20 >>>>=20 >>>> 7.2. Solution Considerations >>>>=20 >>>> It should be recognized that the use of this token should not, >>>> in it's own right, be considered a full solution for absolute >>>> non- repudiation of the persona being asserted. This only >>>> provides non- repudiation of the signer of PASSporT. If the >>>> signer and the persona >>>=20 >>> huh? So the originator isn't really being validated, as >>> claimed??? >>=20 >> This is only a statement to recognize that you are only trusting the >> signer and certificate owner to tell the truth about the originating >> identity. If you are familiar with how certificates work, this is an >> obvious statement, but just a word of consideration. >=20 > Start by saying the affirmative, so that the negative has a = foundation. >=20 > For the current topic, the usual caveat language is along the lines = that "authentication validates authorization to use the identifier, but = does not imply any assessment about the reputation or safety of the = actor using the identifier" or somesuch... >=20 > While authentication does involve a kind of trust, using that word = here usually confuses readers that it it has something to do with 'usage = reputation' that is the derivative function after authentication. Tried to clarify things and incorporate relevant considerations i = removed based on next comment. >=20 >=20 >>>> are not one in the same, which can and often will be the case in >>>> telecommunications networks today, protecting the destination >>>> party from being spoofed may take some interpretation or >>>> additional verification of the link between the PASSporT >>>> signature and the persona being asserted. >>>>=20 >>>> In addition, the telecommunications systems and specifications >>>> that use PASSporT should in practice provide mechanisms for: >>>>=20 >>>> o Managing X.509 certificates and X.509 certificate chains to >>>> an authorized trust anchor that can be a trusted entity to all >>>> participants in the telecommunications network >>>=20 >>> Touching this sort of topic is, at the very best, redundant with >>> specifications devoted to X.509. Just cite them and don't attempt >>> to repeat them. >>=20 >> I see this as helpful, we can discuss if it=E2=80=99s not needed, but = I >> recall being asked by working group to include text to inform the >> reader. >>=20 >>>=20 >>>> o Accounting for entities that may route calls from other peer >>>> or interconnected telecommunications networks that are not part >>>> of the "trusted" communications network or may not be following >>>> the usage of PASSporT or the profile of PASSporT appropriate to >>>> that network >>>=20 >>> Passport doesn't do calls. Dictating activity involving calls is >>> out of scope. >=20 > While some of my comments in this subsection can be class as matters = of taste or an opinion about risks of redundant text, this here point is = about language that is simply wrong. text is redundant and removed the bullets. >=20 >=20 >>> On the other hand, perhaps this qualifies for a discussion about >>> transferring passport objects across administrative (trust) domain >>> boundaries? >>>=20 >>> At best, this section seems to be trying to compensate for the lack >>> of a framework discussion about the problem domain and the >>> practical uses of the various specifications being produced. >>=20 >> similar to above comment, this is meant to be a cautionary statement >> and something to consider if you are an implementer. If you >> understand the limits of what X.509 based certificate signing and PKI >> can represent in terms of trust, these are obvious statements, but I >> think it=E2=80=99s good to include none-the-less. >=20 > In other words, you are trying to provide a tutorial about X.509 = rather than discussion about Passport. same comment as above. >=20 >=20 >=20 >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From nobody Fri Sep 9 08:34:17 2016 Return-Path: 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 2550412B459 for ; Fri, 9 Sep 2016 08:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 6fB0DB0F1klQ for ; Fri, 9 Sep 2016 08:22:54 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E9A12B4A4 for ; Fri, 9 Sep 2016 08:15:34 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 93so42092248qtg.2 for ; Fri, 09 Sep 2016 08:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:subject:date:references:to:message-id:mime-version; bh=Yb+Dvb/umSpuZcfvVjD3ktmDrwUxsRCLGCbCXCrLF3E=; b=MvLexkf0SWaUd3jzIvPMP0M2q6JznraI9ue1bxeqDkdWbz2Za4AJ/W+ad8MToemAxg Dno5cdTFBMPHPvfPYY3r3u4073Cn+DLKMpnp0/jVETK7NTEzrGJTWSWdg1Q7kKQK8TI8 o/sUU66jcs5uprGhse5qsg8y8E98Vjw2kxcKC6Z6NrAD7HC30WcScevC+5hLVk/7hCUr roa2IW24ToU7D7fb3VeCODAEeSrz8C3u0FHC5EyxB3jjMZsngd6OYwPpAQFcQ22HUG2l wOqkhhu/KuWy1MnWe1SVBPyTQOHNpw0vY+NwWYTdnexgdGEETsBXPFkurBpEApo9pVhO 5FqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=Yb+Dvb/umSpuZcfvVjD3ktmDrwUxsRCLGCbCXCrLF3E=; b=gtmjqqdKOkZRNkcDSWQzK/3b0+r9tA5I5Ea4iRxQ75yc8fo7i2gtdD2MoxE9sYVh63 DFkYQuqW0WAwXv1TGIhCvP/rzEMOUKmnnAbSCZKPHbHmVdCCnR4FW61YHOBO2u2YYZAm g01Po1Z2oXmM+9+WYc/Ua52tTkAGG3z2M1cR0HHHUUwQKqWr2ZmvKMy4pbgRmnnTKoWr VbY4tABJcVX0UNhgobczggcD+QImUiEfEZS6NVvHrAK3UW+fn9n5MMKL+I+lUIcgM3sV R2W3G+dEpqH2r3aMK8Br+8SbVKeI6ojktsHQKIf6lYDXCDzpWqjH52Xxp74j50cKbWiP KbHQ== X-Gm-Message-State: AE9vXwOfLQhvGawmqZ4W+u0aPH3dLA5lcPV10A8e8CLWaGJiJr6unAQrK6QcFdUE9rk0Cw== X-Received: by 10.200.39.201 with SMTP id x9mr4580380qtx.3.1473434133777; Fri, 09 Sep 2016 08:15:33 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:9c00:ae2:db6b:f00f? ([2601:41:c101:9364:9c00:ae2:db6b:f00f]) by smtp.gmail.com with ESMTPSA id s36sm2285372qta.11.2016.09.09.08.15.33 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Sep 2016 08:15:33 -0700 (PDT) From: Chris Wendt Content-Type: multipart/alternative; boundary="Apple-Mail=_D8AE5619-C144-4D9C-8820-25A0C52C2057" Date: Fri, 9 Sep 2016 11:15:32 -0400 References: <147343371664.15111.16287882269710549185.idtracker@ietfa.amsl.com> To: IETF STIR Mail List Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] Fwd: New Version Notification for draft-ietf-stir-passport-07.txt X-BeenThere: stir@ietf.org 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: Fri, 09 Sep 2016 15:23:02 -0000 --Apple-Mail=_D8AE5619-C144-4D9C-8820-25A0C52C2057 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have updated passport draft to 07 with coordination with Jon on = 4474bis as well. It incorporates a lot of fixes and tries to be much = more comprehensive in terms of references and examples. I think it=E2=80=99= s a much more robust document now. Thanks especially to Dave and also Robert for their detailed reviews. -Chris > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-stir-passport-07.txt > Date: September 9, 2016 at 11:08:36 AM EDT > To: "Jon Peterson" , "Chris Wendt" = >=20 >=20 > A new version of I-D, draft-ietf-stir-passport-07.txt > has been successfully submitted by Chris Wendt and posted to the > IETF repository. >=20 > Name: draft-ietf-stir-passport > Revision: 07 > Title: Persona Assertion Token > Document date: 2016-09-09 > Group: stir > Pages: 19 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-stir-passport-07.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-stir-passport-07 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-07 >=20 > Abstract: > This document defines a canonical string object or 'token' including > a digital signature for verifying the author of the token, their > authority to author the token and the information asserted in the > token, minimally, the originating identity or 'persona' = corresponding > specifically to the originator of 'personal communications', or > signalled communications between a set of parties with identities. > The PASSporT token is cryptographically signed to protect the > integrity of the identify the originator of a personal = communications > session (e.g. the telephone number or URI) and verify the assertion > of the identity information at the destination. The cryptographic > signature is defined with the intention that it can confidently > verify the originating persona even when the signature is sent to = the > destination party over an insecure channel. PASSporT is = particularly > useful for many personal communications applications over IP = networks > and other multi-hop interconnection scenarios where the originating > and destination parties may not have a direct trusted relationship. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_D8AE5619-C144-4D9C-8820-25A0C52C2057 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have updated passport draft to 07 with coordination with = Jon on 4474bis as well.  It incorporates a lot of fixes and tries = to be much more comprehensive in terms of references and examples. =  I think it=E2=80=99s a much more robust document now.

Thanks especially to = Dave and also Robert for their detailed reviews.

-Chris

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-stir-passport-07.txt
Date: = September 9, 2016 at 11:08:36 = AM EDT
To: = "Jon Peterson" <jon.peterson@neustar.biz>, "Chris Wendt" <chris-ietf@chriswendt.net>

A new version of I-D, draft-ietf-stir-passport-07.txt
has been successfully submitted by Chris Wendt and posted to = the
IETF repository.

Name: = draft-ietf-stir-passport
Revision: 07
Title:= = Persona Assertion Token
Document date: = 2016-09-09
Group: stir
Pages: 19
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-stir-passport-0= 7.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-stir-passport/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-ietf-stir-passport-07
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-07=

Abstract:
=   This document defines a canonical string object or 'token' = including
  a digital signature for verifying = the author of the token, their
  authority to = author the token and the information asserted in the
=   token, minimally, the originating identity or 'persona' = corresponding
  specifically to the originator = of 'personal communications', or
  signalled = communications between a set of parties with identities.
=   The PASSporT token is cryptographically signed to protect = the
  integrity of the identify the originator = of a personal communications
  session (e.g. = the telephone number or URI) and verify the assertion
=   of the identity information at the destination.  The = cryptographic
  signature is defined with the = intention that it can confidently
  verify the = originating persona even when the signature is sent to the
=   destination party over an insecure channel.  PASSporT = is particularly
  useful for many personal = communications applications over IP networks
=   and other multi-hop interconnection scenarios where the = originating
  and destination parties may not = have a direct trusted relationship.




Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_D8AE5619-C144-4D9C-8820-25A0C52C2057-- From nobody Fri Sep 9 09:10:31 2016 Return-Path: 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 2D62F12B28C for ; Fri, 9 Sep 2016 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 rDmoJh8Q0QgC for ; Fri, 9 Sep 2016 09:10:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E62112B275 for ; Fri, 9 Sep 2016 09:10:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 899FA300581 for ; Fri, 9 Sep 2016 11:56:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tIKzE-xq1udt for ; Fri, 9 Sep 2016 11:56:06 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id C3773300086 for ; Fri, 9 Sep 2016 11:56:06 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_653C034E-EB0F-43A4-B54F-F92958190015" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 9 Sep 2016 12:08:54 -0400 References: <61F85536-9AAE-4F5B-8BEE-FCC4912B3EE7@vigilsec.com> To: IETF STIR Mail List In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] MIT Technology Review Article About Stopping Robocalls X-BeenThere: stir@ietf.org 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: Fri, 09 Sep 2016 16:10:29 -0000 --Apple-Mail=_653C034E-EB0F-43A4-B54F-F92958190015 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttps://www.technologyreview.com/s/602284/the-do-not-call-list-has-a-gaping= -hole/= --Apple-Mail=_653C034E-EB0F-43A4-B54F-F92958190015 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

https://www.technologyreview.com/s/602284/the-do-not-call-list-has-a-gaping-hole/

--Apple-Mail=_653C034E-EB0F-43A4-B54F-F92958190015-- From nobody Fri Sep 9 10:10:54 2016 Return-Path: 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 3B88112B05A for ; Fri, 9 Sep 2016 10:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 0Wy6SSQchciI for ; Fri, 9 Sep 2016 10:10:49 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE347126D74 for ; Fri, 9 Sep 2016 10:10:49 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u89H3TsJ003091; Fri, 9 Sep 2016 13:10:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : content-type : mime-version; s=neustar.biz; bh=Cpui1c5l4F9Yx4oJrYNKLpdvF7Mr1upzvwnvaFW0E30=; b=g1PagnKAN1BnqVX7ZpZc0e1iq7rnzzMf93jekQ9vACbfpwy1O8+De8qcdUr+/oMHNy41 m492a8A3YBlBDa7KNRN95ptupLO+acCV+4KcREL880VIlLzo4Yk5iqTkPzHiVGMtgkGK xZkG+JHxzBOJQeIYakaw3NIfL9mmjTtSMcCBits1X4tLOvgejjY0OSn3r24M7oK/LO7J 1ysLvyrLfY3k7fMxy/PoWK8H4DinRkLq7Zk/ododgrU/oxGPLk3TwQ09Ie1fV9yU64Lz OvdpY+XADcS0X3fYRvM7Cheo22HeUlKIEGL1RqEdyPmRqpp+Dl3GLXpImOYt9+PByCtt CA== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25bc2hbxyy-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 09 Sep 2016 13:10:46 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Fri, 9 Sep 2016 13:10:45 -0400 From: "Peterson, Jon" To: Christer Holmberg , "stir@ietf.org" Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wg== Date: Fri, 9 Sep 2016 17:10:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.194] Content-Type: multipart/alternative; boundary="_000_D3F837FA1AD7F7jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-09_10:, , 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-1609020000 definitions=main-1609090254 Archived-At: Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 09 Sep 2016 17:10:52 -0000 --_000_D3F837FA1AD7F7jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The only normative RECOMMEND in Section 8 is for cases "where local policy = canonicalizes the identity into a form different form how it appears in the= From header field." That doesn't have anything to do with multiple identit= ies. The text in the previous sentence notes that it is talking about a cas= e where "the canonical identity derives from the P-Asserted-Identity field = rather than the From header field," not a case where identities based on bo= th appear in different Identity headers. If P-Asserted-Identity is present, surely that's where you should be lookin= g for identity information. As I've argued several times in the past, this = is no more or less ambiguous than the practical use of P-Asserted-Identity = in the field today: nothing about the request tells you "use PAI instead of= From" other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say= anything more than that it's a matter of local policy, as nothing about th= e protocol tells you whether or not you are in an RFC3324 trust domain. Thu= s far, I gather this hasn't impeded the adoption of PAI. I did ask the WG i= n Berlin if we should include some more explicit indicator that would tell = you that an Identity header came from PAI rather than From, and the consens= us was not to. We are largely punting on why you might have multiple Identity headers pres= ent in the same request: this is included for forward compatibility. The mo= st likely use cases are ones where extensions will differentiate the Identi= ty headers. The recommendation to include "canon" here just enables some po= tential implementation optimizations (e.g. Verifier canonicalizes the ident= ity in PAI, then compares to value in "canon" to save cycles before computi= ng the identity string and checking for breakage). Jon Peterson Neustar, Inc. From: stir > on behalf = of Christer Holmberg > Date: Friday, September 9, 2016 at 4:32 AM To: "stir@ietf.org" > Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Section 8 of draft-4474bis says (or, that=92s at least my reading) that, if= the SIP request contains multiple identities (e.g. if the request in addit= ion to the From header field contains one or more P-Asserted-Identity heade= r fields), it is RECOMMENDED to include =93canon=94, so that the verifier k= nows which identity to verify. Why is this only RECOMMENDED? If there are more than one identity, shouldn= =92t it be a MUST? I don=92t think we want the verifier to try all identiti= es, and see which one (if any) works, do we? Now, the text DOES talk about =93local policy=94 when it comes to choosing = between From and PAI for deriving the identity, so perhaps we could say =93= MUST, unless local policy defines from where the identity is retrieved=94, = or something like that=85 Regards, Christer --_000_D3F837FA1AD7F7jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <61C59E220367144DBCD2AA78D4161C9A@neustar.biz> Content-Transfer-Encoding: quoted-printable

The only normative RECOMMEND in Section 8 is for cases "where loc= al policy canonicalizes the identity into a form different form how it appe= ars in the From header field." That doesn't have anything to do with m= ultiple identities. The text in the previous sentence notes that it is talking about a case where "the canonical i= dentity derives from the P-Asserted-Identity field rather than the From hea= der field," not a case where identities based on both appear in differ= ent Identity headers.

If P-Asserted-Identity is present, surely that's where you should be l= ooking for identity information. As I've argued several times in the past, = this is no more or less ambiguous than the practical use of P-Asserted-Iden= tity in the field today: nothing about the request tells you "use PAI instead of From" other than= the presence of PAI. Because of all the RFC3324 trust domain stuff that Ma= rk Watson talked us into back in the day, it's hard to say anything more th= an that it's a matter of local policy, as nothing about the protocol tells you whether or not you are in an RFC3324 = trust domain. Thus far, I gather this hasn't impeded the adoption of PAI. I= did ask the WG in Berlin if we should include some more explicit indicator= that would tell you that an Identity header came from PAI rather than From, and the consensus was not to.

We are largely punting on why you might have multiple Identity headers= present in the same request: this is included for forward compatibility. T= he most likely use cases are ones where extensions will differentiate the I= dentity headers. The recommendation to include "canon" here just enables some potential implementati= on optimizations (e.g. Verifier canonicalizes the identity in PAI, then com= pares to value in "canon" to save cycles before computing the ide= ntity string and checking for breakage).

Jon Peterson
Neustar, Inc.

From: stir <stir-bounces@ietf.org> on behalf of Christer Ho= lmberg <christer.holmb= erg@ericsson.com>
Date: Friday, September 9, 2016 at = 4:32 AM
To: "stir@ietf.org" <stir@i= etf.org>
Subject: [stir] 4474bis: Why only R= ECOMMEND when multiple identities?

Hi,

Section 8 of draft-4474bis says (or, that=92s at least my reading) tha= t, if the SIP request contains multiple identities (e.g. if the request in = addition to the From header field contains one or more P-Asserted-Identity = header fields), it is RECOMMENDED to include =93canon=94, so that the verifier knows which identity to verif= y.

Why is this only RECOMMENDED? If there are more than one identity, sho= uldn=92t it be a MUST? I don=92t think we want the verifier to try all iden= tities, and see which one (if any) works, do we?

Now, the text DOES talk about =93local policy=94 when it comes to choo= sing between From and PAI for deriving the identity, so perhaps we could sa= y =93MUST, unless local policy defines from where the identity is retrieved= =94, or something like that=85

Regards,

Christer
 --_000_D3F837FA1AD7F7jonpetersonneustarbiz_-- From nobody Fri Sep 9 16:24:57 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 773DB12B219; Fri, 9 Sep 2016 16:24:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147346349146.30892.1926622321013524348.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 16:24:51 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-08.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 23:24:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Secure Telephone Identity Credentials: Certificates Authors : Jon Peterson Sean Turner Filename : draft-ietf-stir-certificates-08.txt Pages : 23 Date : 2016-09-09 Abstract: In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-certificates-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 9 18:26:57 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D44B112B004; Fri, 9 Sep 2016 18:26:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147347081582.30949.3409586314082980880.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2016 18:26:55 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-12.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 01:26:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Chris Wendt Filename : draft-ietf-stir-rfc4474bis-12.txt Pages : 43 Date : 2016-09-09 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 10 09:01:18 2016 Return-Path: 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 11A5E12B097 for ; Sat, 10 Sep 2016 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 ZbxdnU6BhReE for ; Sat, 10 Sep 2016 09:01:14 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 845C112B153 for ; Sat, 10 Sep 2016 09:01:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4CBC330063A for ; Sat, 10 Sep 2016 11:46:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UsAjIbRg-7Lg for ; Sat, 10 Sep 2016 11:46:53 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 47AB03004BC for ; Sat, 10 Sep 2016 11:46:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Sat, 10 Sep 2016 12:01:21 -0400 Content-Transfer-Encoding: 7bit Message-Id: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> References: To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Sat, 10 Sep 2016 16:01:17 -0000 A revised document to address the issues raised in the first WG Last Call on this document was posted yesterday. (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-12.txt). This message starts a second two-week WG Last Call for this document, which will end on 24 September 2016. Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. Thanks, Russ & Robert From nobody Sat Sep 10 09:02:18 2016 Return-Path: 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 4A57D12B153 for ; Sat, 10 Sep 2016 09:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 PAyRpo5Wk1ha for ; Sat, 10 Sep 2016 09:02:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110D412B097 for ; Sat, 10 Sep 2016 09:02:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 16C1430063A for ; Sat, 10 Sep 2016 11:47:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZvtpXQn0hjgt for ; Sat, 10 Sep 2016 11:47:55 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 080B93004BC for ; Sat, 10 Sep 2016 11:47:54 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 Sep 2016 12:02:26 -0400 Message-Id: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF STIR Mail List List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 16:02:17 -0000 A revised document to address the issues raised in the first WG Last Call on this document was posted yesterday. (https://www.ietf.org/id/draft-ietf-stir-certificates-08.txt). This message starts a second two-week WG Last Call for this document, which will end on 24 September 2016. Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. Thanks, Russ & Robert From nobody Sat Sep 10 09:04:03 2016 Return-Path: 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 59E7812B153 for ; Sat, 10 Sep 2016 09:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 IolObZ7xDWRv for ; Sat, 10 Sep 2016 09:04:01 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F9612B097 for ; Sat, 10 Sep 2016 09:04:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1137E30063A for ; Sat, 10 Sep 2016 11:49:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r9qkG4SdHszV for ; Sat, 10 Sep 2016 11:49:40 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 0BCB43004BC for ; Sat, 10 Sep 2016 11:49:39 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 Sep 2016 12:04:11 -0400 Message-Id: <20388E22-CF03-4338-954B-B9BAFA33C4AF@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Second WG Last Call for PASSporT Document X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF STIR Mail List List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 16:04:02 -0000 A revised document to address the issues raised in the first WG Last Call on this document was posted yesterday. (https://www.ietf.org/id/draft-ietf-stir-passport-07.txt). This message starts a second two-week WG Last Call for this document, which will end on 24 September 2016. Please review the document and send comments on it to the STIR WG mail list. Please clearly state your opinion as to whether the document is ready for publication as a standards-track RFC. Remember that support for publication is needed, so if you think the document is ready to go forward, please say so. Thanks, Russ & Robert From nobody Mon Sep 12 09:22:30 2016 Return-Path: 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 C45F912B2F4 for ; Mon, 12 Sep 2016 09:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 QmvIOAdGmdc8 for ; Mon, 12 Sep 2016 09:22:28 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C4912B712 for ; Mon, 12 Sep 2016 08:32:09 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-03v.sys.comcast.net with SMTP id jTBebDgGm8GkCjTDLbfdjU; Mon, 12 Sep 2016 15:32:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with SMTP id jTDKbwHsiVK25jTDLb8ueq; Mon, 12 Sep 2016 15:32:07 +0000 To: "" References: <147347081582.30949.3409586314082980880.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Mon, 12 Sep 2016 11:32:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147347081582.30949.3409586314082980880.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCqzelRwU0UhuhdM2myqvcvRtkU995Yoo+4vv9Bpb/7VKAEr3xfz1oK/mrf2I72bOyT80YVdkBw/yO6u24go8Vw9aPz1SVe4nAODQLJ33Qk+VJw/0SEk 9DFTMZFAYhbzpQhQxa42wB6oOi7GgOSvZVYVeoCqh2R/dw4URfppbBK69cQfGzdRGqo7yrcj6Q6oGw== Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-12.txt X-BeenThere: stir@ietf.org 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: Mon, 12 Sep 2016 16:22:29 -0000 I noticed a nit while looking over this version: In several places in figures a "\" is used to signify line wrapping. In some of the examples this is necessary because of the existence of long text fields. But this is also used (gratuitously) in ABNF. This means that the ABNF isn't valid without some post processing. So please remove gratuitous use of "\". Thanks, Paul From nobody Mon Sep 12 10:33:54 2016 Return-Path: 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 8347C127A91 for ; Mon, 12 Sep 2016 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eeseEbifegb7 for ; Mon, 12 Sep 2016 10:33:41 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A286127A90 for ; Mon, 12 Sep 2016 10:33:40 -0700 (PDT) X-AuditID: c1b4fb2d-cf87d980000019a3-bf-57d6e6f33073 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 7F.C9.06563.3F6E6D75; Mon, 12 Sep 2016 19:33:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0301.000; Mon, 12 Sep 2016 19:31:16 +0200 From: Christer Holmberg To: "Peterson, Jon" , "stir@ietf.org" Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfg Date: Mon, 12 Sep 2016 17:31:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BC9C3D6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdT/fzs2vhBqee81ucabC0WL52G5MD k8eSJT+ZPHY0PGcOYIrisklJzcksSy3St0vgyljQ/4iloL+mouPJVZYGxobcLkZODgkBE4l1 H/exdTFycQgJrGeUmPxkBjOEs4RRYvf+ZvYuRg4ONgELie5/2iANIgKBEpuefGUBsYUFPCVu LrnLChH3kth3oZ8FwjaSmH3oJCOIzSKgKrFrwzRmEJtXwFeibdZLMFtIwEzixYvvYDWcAuYS 698eZgexGQXEJL6fWsMEYjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsJUkGpc8YYWoz5f4 PPM5G8QuQYmTM5+wTGAUnoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZV jKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIHRc3DLb90djKtfOx5iFOBgVOLhfbDlWrgQa2JZ cWXuIUYJDmYlEd7yp0Ah3pTEyqrUovz4otKc1OJDjNIcLErivMvOA6UE0hNLUrNTUwtSi2Cy TBycUg2MoYwC7ZFWW+6f5pY5G6antavMtX7lncKsNVoddb7BqzLN1sQKhRx9qC+24UfG4Yjb n3ew5k47967j0Hs7xaMFfcLdc2WuzJ30/HZPuuV35+JZtjIidz0XOs08lLtd5EXI7ADbM/Nd Op5mP5Vc5dLsWt5l+dOOd0nw0zPuRgxbtsTeK5BalHxPiaU4I9FQi7moOBEAhZIpF5oCAAA= Archived-At: Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Mon, 12 Sep 2016 17:33:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BC9C3D6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Ok, maybe "multiple identities" was the wrong wording. My point was that, even if you know you should derive the identity from PAI= instead of From, you can have two P-Asserted-Identity header fields, and a= s far as I understand there is no guarantee that the canonicalized form of = those match. Regards, Christer From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 09 September 2016 20:11 To: Christer Holmberg ; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? The only normative RECOMMEND in Section 8 is for cases "where local policy = canonicalizes the identity into a form different form how it appears in the= From header field." That doesn't have anything to do with multiple identit= ies. The text in the previous sentence notes that it is talking about a cas= e where "the canonical identity derives from the P-Asserted-Identity field = rather than the From header field," not a case where identities based on bo= th appear in different Identity headers. If P-Asserted-Identity is present, surely that's where you should be lookin= g for identity information. As I've argued several times in the past, this = is no more or less ambiguous than the practical use of P-Asserted-Identity = in the field today: nothing about the request tells you "use PAI instead of= From" other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say= anything more than that it's a matter of local policy, as nothing about th= e protocol tells you whether or not you are in an RFC3324 trust domain. Thu= s far, I gather this hasn't impeded the adoption of PAI. I did ask the WG i= n Berlin if we should include some more explicit indicator that would tell = you that an Identity header came from PAI rather than From, and the consens= us was not to. We are largely punting on why you might have multiple Identity headers pres= ent in the same request: this is included for forward compatibility. The mo= st likely use cases are ones where extensions will differentiate the Identi= ty headers. The recommendation to include "canon" here just enables some po= tential implementation optimizations (e.g. Verifier canonicalizes the ident= ity in PAI, then compares to value in "canon" to save cycles before computi= ng the identity string and checking for breakage). Jon Peterson Neustar, Inc. From: stir > on behalf = of Christer Holmberg > Date: Friday, September 9, 2016 at 4:32 AM To: "stir@ietf.org" > Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Section 8 of draft-4474bis says (or, that's at least my reading) that, if t= he SIP request contains multiple identities (e.g. if the request in additio= n to the From header field contains one or more P-Asserted-Identity header = fields), it is RECOMMENDED to include "canon", so that the verifier knows w= hich identity to verify. Why is this only RECOMMENDED? If there are more than one identity, shouldn'= t it be a MUST? I don't think we want the verifier to try all identities, a= nd see which one (if any) works, do we? Now, the text DOES talk about "local policy" when it comes to choosing betw= een From and PAI for deriving the identity, so perhaps we could say "MUST, = unless local policy defines from where the identity is retrieved", or somet= hing like that... Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4BC9C3D6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Ok, maybe = “multiple identities” was the wrong wording.<= /p>

 = ;

My point w= as that, even if you know you should derive the identity from PAI instead o= f From, you can have two P-Asserted-Identity header fields, and as far as I understand there is no guarantee that the canonica= lized form of those match.

 = ;

Regards,

 = ;

Christer

 

From: = Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: 09 September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@i= etf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

 

The only normative RECOMMEND in Section= 8 is for cases "where local policy canonicalizes the identity into a = form different form how it appears in the From header field." That doesn't have anything to do with multiple identities. Th= e text in the previous sentence notes that it is talking about a case where= "the canonical identity derives from the P-Asserted-Identity field ra= ther than the From header field," not a case where identities based on both appear in different Identity headers.<= /o:p>

 

If P-Asserted-Identity is present, sure= ly that's where you should be looking for identity information. As I've arg= ued several times in the past, this is no more or less ambiguous than the practical use of P-Asserted-Identity in the fie= ld today: nothing about the request tells you "use PAI instead of From= " other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say anything more than that it's a matter of= local policy, as nothing about the protocol tells you whether or not you a= re in an RFC3324 trust domain. Thus far, I gather this hasn't impeded the a= doption of PAI. I did ask the WG in Berlin if we should include some more explicit indicator that would tel= l you that an Identity header came from PAI rather than From, and the conse= nsus was not to.

 

We are largely punting on why you might= have multiple Identity headers present in the same request: this is includ= ed for forward compatibility. The most likely use cases are ones where extensions will differentiate the Identity header= s. The recommendation to include "canon" here just enables some p= otential implementation optimizations (e.g. Verifier canonicalizes the iden= tity in PAI, then compares to value in "canon" to save cycles before computing the identity string and checking for break= age).

 

Jon Peterson

Neustar, Inc.

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Friday, September 9, 2016 at 4:32 AM
To: "stir@ietf.org" &= lt;stir@ietf.org>
Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities= ?

 

Hi,

 

Section 8 of draft-4474bis says (or, th= at’s at least my reading) that, if the SIP request contains multiple = identities (e.g. if the request in addition to the From header field contains one or more P-Asserted-Identity header fields), it i= s RECOMMENDED to include “canon”, so that the verifier knows wh= ich identity to verify.

 

Why is this only RECOMMENDED? If there = are more than one identity, shouldn’t it be a MUST? I don’t thi= nk we want the verifier to try all identities, and see which one (if any) works, do we?

 

Now, the text DOES talk about “lo= cal policy” when it comes to choosing between From and PAI for derivi= ng the identity, so perhaps we could say “MUST, unless local policy defines from where the identity is retrieved”, or something l= ike that…

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4BC9C3D6ESESSMB209erics_-- From nobody Tue Sep 13 07:54:23 2016 Return-Path: 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 4AB4D12B3F1 for ; Tue, 13 Sep 2016 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 l60ZI32VBaGF for ; Tue, 13 Sep 2016 07:54:20 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C750E12B6DE for ; Tue, 13 Sep 2016 07:22:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A6C69300A04 for ; Tue, 13 Sep 2016 10:08:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XGTf6FyXgpsp for ; Tue, 13 Sep 2016 10:08:25 -0400 (EDT) Received: from 132-177-252-228.ip.sipit.net (unknown [132.177.252.228]) by mail.smeinc.net (Postfix) with ESMTPSA id 965B1300455 for ; Tue, 13 Sep 2016 10:08:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> Date: Tue, 13 Sep 2016 10:21:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Tue, 13 Sep 2016 14:54:22 -0000 I was talking to a developer a few minutes ago, and he found a small = bug. It is very simple to fix. Maybe he will find other bugs as = development continues =85 In section 4, the ABNF includes: base64-char =3D ALPHA / DIGIT / "/" / "+" This line should say: base64-char =3D ALPHA / DIGIT / "/" / =93+=94 / =93=3D" Russ From nobody Tue Sep 13 10:29:16 2016 Return-Path: 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 6094312B43F for ; Tue, 13 Sep 2016 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zR3YX6MOoh-L for ; Tue, 13 Sep 2016 10:29:14 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id CA81412B42A for ; Tue, 13 Sep 2016 10:29:13 -0700 (PDT) X-AuditID: 12074413-ab7ff70000000955-d7-57d83767756c Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 17.B1.02389.76738D75; Tue, 13 Sep 2016 13:29:13 -0400 (EDT) Received: from 132-177-252-148.ip.sipit.net ([132.177.252.148]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u8DHTAF5009221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2016 13:29:11 -0400 To: stir@ietf.org References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> From: Paul Kyzivat Message-ID: Date: Tue, 13 Sep 2016 13:29:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqJtpfiPc4Os1Hovla7cxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8+FLpaCX+wVzevMGhhb2LoYOTkkBEwklj+ewNTFyMUhJLCV UeL8r8eMEM4VJolfn+4xg1QJC5hJNB/ZxgpiiwgIStybcZoJxBYSWM0ocfiCKIjNJqAlMefQ fxYQm1fAXmLP6TWMIDaLgKrEkq2PwXpFBdIkph/uZ4SoEZQ4OfMJWD2ngIPEymPnwWxmAVuJ O3N3M0PY8hLNW2czT2Dkm4WkZRaSsllIyhYwMq9ilEvMKc3VzU3MzClOTdYtTk7My0st0jXX y80s0UtNKd3ECAky4R2Mu07KHWIU4GBU4uEN+HE9XIg1say4MvcQoyQHk5Io7/w1QCG+pPyU yozE4oz4otKc1OJDjBIczEoivNVmN8KFeFMSK6tSi/JhUtIcLErivGpL1P2EBNITS1KzU1ML UotgsjIcHEoSvCEgjYJFqempFWmZOSUIaSYOTpDhPEDDG8CGFxck5hZnpkPkTzEqSonzTjEF SgiAJDJK8+B6YUngFaM40CvCvK0g7TzABALX/QpoMBPQ4C0gH/EWlyQipKQaGNkOyZc+nb/9 Uckil3vVuus3mta59Z/MP3xAOC9Wz8SsuprPeZoLh9/GC13++9SjZs3mWFL301ol+VvmnZ64 2u/CFw+lyv9RPOC/7G3ArTuC7ju/XMxrfmAaKj+x0lb65hZlvhKpY3afRNe4Hrz141zdvESW z6lRvId1XeW7A4JK7ivu7jW4oMRSnJFoqMVcVJwIADqhhsjdAgAA Archived-At: Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Tue, 13 Sep 2016 17:29:15 -0000 On 9/13/16 10:21 AM, Russ Housley wrote: > I was talking to a developer a few minutes ago, and he found a small bug. It is very simple to fix. Maybe he will find other bugs as development continues … > > In section 4, the ABNF includes: > > base64-char = ALPHA / DIGIT / "/" / "+" > > > This line should say: > > base64-char = ALPHA / DIGIT / "/" / “+” / “=" That is an improvement. However, the document lacks any definition of how base64 encoding/decoding works. I suggest a reference to RFC4648. That RFC has two distinct base64 encodings: "base64" and "base64url". The examples in this draft clearly use "base64" because some of them contain "/". Also, it would be possible to write the syntax to more tightly define the syntax for base64: canonical-str = "canon" EQUAL LDQUOT base64-encoding RDQUOT base64-encoding = *(3base64-char) [ (2base64-char "=") / (base64-char 2"=") ] OTOH referencing RF4648 may be sufficient. Thanks, Paul From nobody Tue Sep 13 11:26:16 2016 Return-Path: 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 9FB31120727 for ; Tue, 13 Sep 2016 11:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zXdsWtNfR6Wl for ; Tue, 13 Sep 2016 11:26:12 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id A88BE126B6D for ; Tue, 13 Sep 2016 11:26:12 -0700 (PDT) X-AuditID: 12074412-1afff70000000931-c8-57d844c3c9ab Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 14.5A.02353.3C448D75; Tue, 13 Sep 2016 14:26:11 -0400 (EDT) Received: from 132-177-252-148.ip.sipit.net ([132.177.252.148]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u8DIQAoH012761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Sep 2016 14:26:11 -0400 To: stir@ietf.org References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> From: Paul Kyzivat Message-ID: <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu> Date: Tue, 13 Sep 2016 14:26:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixO6iqHvY5Ua4wY8uE4vla7cxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+n3A+wF2wUq+r6+ZmpgvMTTxcjJISFgIrH/xXVmEFtIYCuj xLuWsi5GLiD7CpPEvVdXwRLCAmYSzUe2sYLYIgKCEvdmnGaCKHrIKDHpwAs2kASbgJbEnEP/ WUBsXgF7iQmzOsAaWARUJead6QCLiwqkSUw/3M8IUSMocXLmE7A4p4CDRP/lNUwgNrOArcSd ubuZIWx5ieats5knMPLNQtIyC0nZLCRlCxiZVzHKJeaU5urmJmbmFKcm6xYnJ+blpRbpmunl ZpbopaaUbmKEhJnQDsb1J+UOMQpwMCrx8Ab8uB4uxJpYVlyZe4hRkoNJSZSX1eJGuBBfUn5K ZUZicUZ8UWlOavEhRgkOZiURXgVgcAvxpiRWVqUW5cOkpDlYlMR5fy5W9xMSSE8sSc1OTS1I LYLJynBwKEnw/nMGahQsSk1PrUjLzClBSDNxcIIM5wEargo2vLggMbc4Mx0if4pRUUqctxqk WQAkkVGaB9cLSwOvGMWBXhHmvQRSxQNMIXDdr4AGMwEN3rLmOsjgkkSElFQD49oskynPZWYd nf1pX4Aoo0+J2+3PcerXbQQc9Q8xzFRNd4rgrHjz9tSZX69XtOi+jF+w6+KvoyWnly/XVnL7 +c3w6+wLrPY3rh74bXP5DkOfx+Jj95QWmxunO1ddXc91SL/lc+zKNsm78p/z8wu6rQ+YT9cL /vSXzz/ZezejdFjHyh2FuTtm/VViKc5INNRiLipOBAANn9jE3gIAAA== Archived-At: Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Tue, 13 Sep 2016 18:26:15 -0000 Replying to myself :-( I discovered more problems with this: I presume that there should be some consistency between this document and passport and JWS regarding how base64 encoding is done. * JWS [RFC7515] defines a modified encoding that is like "base64url" from RFC4648 except that it omits the trailing "=" for padding. It uses BASE64URL(octets) to denote this. * passport references JWS, and also uses BASE64URL in examples. * as I noted below, the examples in rfc4474bis clearly use "base64" encoding as defined in RFC4648, including the trailing "=" pad characters. ISTM the proper fix for this is for both rfc4474bis and passport to explicitly reference RFC7515 for the definition of BASE64URL. Then the examples in 4474bis need to be changed accordingly. Once this is done there is no need for allowing "=" in the syntax. More below. On 9/13/16 1:29 PM, Paul Kyzivat wrote: > On 9/13/16 10:21 AM, Russ Housley wrote: >> I was talking to a developer a few minutes ago, and he found a small >> bug. It is very simple to fix. Maybe he will find other bugs as >> development continues … >> >> In section 4, the ABNF includes: >> >> base64-char = ALPHA / DIGIT / "/" / "+" >> >> >> This line should say: >> >> base64-char = ALPHA / DIGIT / "/" / “+” / “=" Actually, now it should be: base64-char = ALPHA / DIGIT / "-" / “_” > That is an improvement. However, the document lacks any definition of > how base64 encoding/decoding works. I suggest a reference to RFC4648. > That RFC has two distinct base64 encodings: "base64" and "base64url". > The examples in this draft clearly use "base64" because some of them > contain "/". > Also, it would be possible to write the syntax to more tightly define > the syntax for base64: > > canonical-str = "canon" EQUAL LDQUOT base64-encoding RDQUOT > base64-encoding = > *(3base64-char) [ (2base64-char "=") / (base64-char 2"=") ] The above isn't right. I was going to correct it, but now there is no need to do so. Thanks, Paul From nobody Tue Sep 13 11:58:41 2016 Return-Path: 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 513E612B4DB for ; Tue, 13 Sep 2016 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 RuYTx4cE60Hd for ; Tue, 13 Sep 2016 11:58:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E78412B02E for ; Tue, 13 Sep 2016 11:58:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2372A300A05 for ; Tue, 13 Sep 2016 14:44:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xwADPCwzQjwm for ; Tue, 13 Sep 2016 14:44:17 -0400 (EDT) Received: from 132-177-252-228.ip.sipit.net (unknown [132.177.252.228]) by mail.smeinc.net (Postfix) with ESMTPSA id C6C09300086; Tue, 13 Sep 2016 14:44:16 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu> Date: Tue, 13 Sep 2016 14:58:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10F20385-407D-41C5-94FF-013354FE44C0@vigilsec.com> References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Tue, 13 Sep 2016 18:58:40 -0000 On Sep 13, 2016, at 2:26 PM, Paul Kyzivat wrote: > Replying to myself :-( >=20 > I discovered more problems with this: >=20 > I presume that there should be some consistency between this document = and passport and JWS regarding how base64 encoding is done. >=20 > * JWS [RFC7515] defines a modified encoding that is like "base64url" = from RFC4648 except that it omits the trailing "=3D" for padding. It = uses BASE64URL(octets) to denote this. >=20 > * passport references JWS, and also uses BASE64URL in examples. >=20 > * as I noted below, the examples in rfc4474bis clearly use "base64" = encoding as defined in RFC4648, including the trailing "=3D" pad = characters. >=20 > ISTM the proper fix for this is for both rfc4474bis and passport to = explicitly reference RFC7515 for the definition of BASE64URL. Then the = examples in 4474bis need to be changed accordingly. Once this is done = there is no need for allowing "=3D" in the syntax. >=20 > More below. >=20 > On 9/13/16 1:29 PM, Paul Kyzivat wrote: >> On 9/13/16 10:21 AM, Russ Housley wrote: >>> I was talking to a developer a few minutes ago, and he found a small >>> bug. It is very simple to fix. Maybe he will find other bugs as >>> development continues =85 >>>=20 >>> In section 4, the ABNF includes: >>>=20 >>> base64-char =3D ALPHA / DIGIT / "/" / "+" >>>=20 >>>=20 >>> This line should say: >>>=20 >>> base64-char =3D ALPHA / DIGIT / "/" / =93+=94 / =93=3D" >=20 > Actually, now it should be: >=20 > base64-char =3D ALPHA / DIGIT / "-" / =93_=94 >=20 >> That is an improvement. However, the document lacks any definition = of >> how base64 encoding/decoding works. I suggest a reference to RFC4648. >> That RFC has two distinct base64 encodings: "base64" and "base64url". >> The examples in this draft clearly use "base64" because some of them >> contain "/". >=20 >=20 >> Also, it would be possible to write the syntax to more tightly define >> the syntax for base64: >>=20 >> canonical-str =3D "canon" EQUAL LDQUOT base64-encoding RDQUOT >> base64-encoding =3D >> *(3base64-char) [ (2base64-char "=3D") / (base64-char 2"=3D") = ] >=20 > The above isn't right. I was going to correct it, but now there is no = need to do so. >=20 You are right, the equal sign is not needed. JWT uses Base64url = encoding, which is defined in RFC 7515. Base64url encoding produces the = URL-safe and filename-safe result. It uses =93-=93 instead of =93+=93, = it uses =93_=94 instead of =93/=93, and it strips any trailing =93=3D=93 = characters. RFC 7515, Appendix C shows how to convert a Base64 string to a Base64url = string. So, the ABNF above should be: signed-identity-digest =3D LDQUOT *base64url-char RDQUOT canonical-str =3D "canon" EQUAL LDQUOT *base64url-char RDQUOT base64url-char =3D ALPHA / DIGIT / =93_" / =93-=93 Russ From nobody Tue Sep 13 15:27:33 2016 Return-Path: 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 E6F7412B0E3 for ; Tue, 13 Sep 2016 15:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 7zYWcowRK_qR for ; Tue, 13 Sep 2016 15:27:28 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2745512B0BE for ; Tue, 13 Sep 2016 15:27:27 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8DMMb1x026237; Tue, 13 Sep 2016 18:27:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar.biz; bh=Bb1r3qopsOmUFj+ZM/La8WwvQ2z4KH9m6U5IO0DsBi0=; b=Xx8UFt82XxxFjpU55EZjD3z6r5Fp4VODPozXIicO6+rolXk6DtUr5biNJWkGaVo9xYHd tEtP3zNwiasvZOFCrlSZPJFliE2IowDEJHtjbokD6Wt36xs6hkklM8ehVoasIH6zX4Tk LdE0wfNtYtcC6o05XqF851w4MbGkZsUbyRyfEn4CMkhwaQk+vnSyk0vlKEsF/zxjnkDU Uwicj4+njTxrL4Tz+KR052N8DVTrbZYmSLgyn0KR3Z+PWu5xWe6L87smvhSsbKq3cMpj AFUkZAX8EaaXMCO5xuwkh8nNzIB2KI/eW5JDPZ1NaMhEe5k8JHgpSdXGQjUdVAOvK4Ll Lw== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25ce9pxq66-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Sep 2016 18:27:24 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 13 Sep 2016 18:27:22 -0400 From: "Peterson, Jon" To: Russ Housley , Paul Kyzivat Thread-Topic: [stir] Second WG Last Call for RFC4474bis Thread-Index: AQHSC3yUpcAXn9+uD0OZaEWmNt6JrqB3wGKAgAA0XwCAAA/tAIAACQ+A///E6IA= Date: Tue, 13 Sep 2016 22:27:22 +0000 Message-ID: References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu> <10F20385-407D-41C5-94FF-013354FE44C0@vigilsec.com> In-Reply-To: <10F20385-407D-41C5-94FF-013354FE44C0@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.120] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5BB84542982F5D4EB5A79FD8D6F41327@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-13_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609130318 Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Tue, 13 Sep 2016 22:27:32 -0000 We'll cite RFC7515 Appendix C for the base64 in the next rev. We'll also remove the gratuitous uses of "\". Additionally, we've gotten a request from the implementers at SIPit to remove the leading and trailing quotes (LDQUOT and RDQUOT) around the signed-identity-digest and the canon parameter value in the Identity header. The presence of the quotes is really just mechanism grandfathered in from RFC4474; it adds a few bites but don't seem to add any value. Unless anyone objects, we'll remove those quotes from the syntax in the next version.=20 Jon Peterson Neustar, Inc. On 9/13/16, 11:58 AM, "stir on behalf of Russ Housley" wrote: > >On Sep 13, 2016, at 2:26 PM, Paul Kyzivat wrote: > >> Replying to myself :-( >>=20 >> I discovered more problems with this: >>=20 >> I presume that there should be some consistency between this document >>and passport and JWS regarding how base64 encoding is done. >>=20 >> * JWS [RFC7515] defines a modified encoding that is like "base64url" >>from RFC4648 except that it omits the trailing "=3D" for padding. It uses >>BASE64URL(octets) to denote this. >>=20 >> * passport references JWS, and also uses BASE64URL in examples. >>=20 >> * as I noted below, the examples in rfc4474bis clearly use "base64" >>encoding as defined in RFC4648, including the trailing "=3D" pad >>characters. >>=20 >> ISTM the proper fix for this is for both rfc4474bis and passport to >>explicitly reference RFC7515 for the definition of BASE64URL. Then the >>examples in 4474bis need to be changed accordingly. Once this is done >>there is no need for allowing "=3D" in the syntax. >>=20 >> More below. >>=20 >> On 9/13/16 1:29 PM, Paul Kyzivat wrote: >>> On 9/13/16 10:21 AM, Russ Housley wrote: >>>> I was talking to a developer a few minutes ago, and he found a small >>>> bug. It is very simple to fix. Maybe he will find other bugs as >>>> development continues =8A >>>>=20 >>>> In section 4, the ABNF includes: >>>>=20 >>>> base64-char =3D ALPHA / DIGIT / "/" / "+" >>>>=20 >>>>=20 >>>> This line should say: >>>>=20 >>>> base64-char =3D ALPHA / DIGIT / "/" / =B3+=B2 / =B3=3D" >>=20 >> Actually, now it should be: >>=20 >> base64-char =3D ALPHA / DIGIT / "-" / =B3_=B2 >>=20 >>> That is an improvement. However, the document lacks any definition of >>> how base64 encoding/decoding works. I suggest a reference to RFC4648. >>> That RFC has two distinct base64 encodings: "base64" and "base64url". >>> The examples in this draft clearly use "base64" because some of them >>> contain "/". >>=20 >>=20 >>> Also, it would be possible to write the syntax to more tightly define >>> the syntax for base64: >>>=20 >>> canonical-str =3D "canon" EQUAL LDQUOT base64-encoding RDQUOT >>> base64-encoding =3D >>> *(3base64-char) [ (2base64-char "=3D") / (base64-char 2"=3D") ] >>=20 >> The above isn't right. I was going to correct it, but now there is no >>need to do so. >>=20 > >You are right, the equal sign is not needed. JWT uses Base64url >encoding, which is defined in RFC 7515. Base64url encoding produces the >URL-safe and filename-safe result. It uses =B3-=B3 instead of =B3+=B3, it= uses >=B3_=B2 instead of =B3/=B3, and it strips any trailing =B3=3D=B3 character= s. > >RFC 7515, Appendix C shows how to convert a Base64 string to a Base64url >string. > >So, the ABNF above should be: > > signed-identity-digest =3D LDQUOT *base64url-char RDQUOT > > canonical-str =3D "canon" EQUAL LDQUOT *base64url-char RDQUOT > > base64url-char =3D ALPHA / DIGIT / =B3_" / =B3-=B3 > >Russ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Sep 13 15:31:56 2016 Return-Path: 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 F035312B0B9 for ; Tue, 13 Sep 2016 15:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 f5l-nVPrSa9Y for ; Tue, 13 Sep 2016 15:31:52 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CE812B0FF for ; Tue, 13 Sep 2016 15:31:51 -0700 (PDT) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8DMMgv1032033; Tue, 13 Sep 2016 18:31:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=sMqm5leSWTsA9yEaPHoQB+aDJUZU5QXvwsScy1PYgsE=; b=B8l9xaserbkGy5WeElJK3497zUnj+BGPDuvOX5AhM/Eelgfs5H4qm3BU1NknF165BecZ u76Fgnk7Ia6byiRJ0tbOFlObVlj0MfBHAv0q+90VEng3wjvmUzioJ4j4C4QNpA+a+A/N NymL+rmzZ03I7kyHfRcrEGdJpykFzvO5RgBoe/nkIfPqm6RpaG9VKaCOBakiR3OfLulE 1jwYPXrziyh4P9oZkSS1JPwiP1ueHvZ5jzUI362tLc11iVMTePvDrOz7Bc1cLA9Qqgb8 IPme6xYV0TNc8kVBsuHhkGWoFh1dQh6PQ8gV0v9EpbU6RBOUlj5B0SMt9PqKISR9CV5T Jg== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25ccttxv0d-2 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Sep 2016 18:31:47 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Tue, 13 Sep 2016 18:30:35 -0400 From: "Peterson, Jon" To: Christer Holmberg , "stir@ietf.org" Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jAA= Date: Tue, 13 Sep 2016 22:30:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.120] Content-Type: multipart/alternative; boundary="_000_D3FDCA671B0885jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-13_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609130318 Archived-At: Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Tue, 13 Sep 2016 22:31:55 -0000 --_000_D3FDCA671B0885jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The more values there are in a SIP request that are candidates for the iden= tity of the caller, the more likely we are going to entertain corner cases = like this. There is no guarantee that the canonicalized identity in the Fro= m header field will be identical to one in PAI - why carry PAI if it would = be? - and similarly if there are multiple PAIs there's no guarantee that th= ey will all canonicalize to the same form. Somehow, though, in those RFC332= 4 trust environments, you are supposed to be able to know which PAI contain= s the identity that you care about for this purpose, the identity of the or= iginator of the call. STIR can't tell you how to find that, only local trus= t domain policy can. I don't think the burden is on STIR to make this unamb= iguous when apparently the trust domains already can and do. But, of course, when carrying the "canon" parameter, it will have one value= for the originating telephone number, say, and that will match the canonic= alized form of one of those identities and not the others. If your trust do= main introduces this ambiguity into every call, then your trust domain shou= ld probably set a local policy of sending "canon" with every call. I'm not = sure there's much more to say about it than that in the core specs, though. Jon Peterson Neustar, Inc. From: Christer Holmberg > Date: Monday, September 12, 2016 at 10:31 AM To: Jon Peterson = >, "stir@ietf.org" > Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Ok, maybe =93multiple identities=94 was the wrong wording. My point was that, even if you know you should derive the identity from PAI= instead of From, you can have two P-Asserted-Identity header fields, and a= s far as I understand there is no guarantee that the canonicalized form of = those match. Regards, Christer From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 09 September 2016 20:11 To: Christer Holmberg >; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? The only normative RECOMMEND in Section 8 is for cases "where local policy = canonicalizes the identity into a form different form how it appears in the= From header field." That doesn't have anything to do with multiple identit= ies. The text in the previous sentence notes that it is talking about a cas= e where "the canonical identity derives from the P-Asserted-Identity field = rather than the From header field," not a case where identities based on bo= th appear in different Identity headers. If P-Asserted-Identity is present, surely that's where you should be lookin= g for identity information. As I've argued several times in the past, this = is no more or less ambiguous than the practical use of P-Asserted-Identity = in the field today: nothing about the request tells you "use PAI instead of= From" other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say= anything more than that it's a matter of local policy, as nothing about th= e protocol tells you whether or not you are in an RFC3324 trust domain. Thu= s far, I gather this hasn't impeded the adoption of PAI. I did ask the WG i= n Berlin if we should include some more explicit indicator that would tell = you that an Identity header came from PAI rather than From, and the consens= us was not to. We are largely punting on why you might have multiple Identity headers pres= ent in the same request: this is included for forward compatibility. The mo= st likely use cases are ones where extensions will differentiate the Identi= ty headers. The recommendation to include "canon" here just enables some po= tential implementation optimizations (e.g. Verifier canonicalizes the ident= ity in PAI, then compares to value in "canon" to save cycles before computi= ng the identity string and checking for breakage). Jon Peterson Neustar, Inc. From: stir > on behalf = of Christer Holmberg > Date: Friday, September 9, 2016 at 4:32 AM To: "stir@ietf.org" > Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Section 8 of draft-4474bis says (or, that=92s at least my reading) that, if= the SIP request contains multiple identities (e.g. if the request in addit= ion to the From header field contains one or more P-Asserted-Identity heade= r fields), it is RECOMMENDED to include =93canon=94, so that the verifier k= nows which identity to verify. Why is this only RECOMMENDED? If there are more than one identity, shouldn= =92t it be a MUST? I don=92t think we want the verifier to try all identiti= es, and see which one (if any) works, do we? Now, the text DOES talk about =93local policy=94 when it comes to choosing = between From and PAI for deriving the identity, so perhaps we could say =93= MUST, unless local policy defines from where the identity is retrieved=94, = or something like that=85 Regards, Christer --_000_D3FDCA671B0885jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2DA27B09685A3F41AE0C47F0A3B13549@neustar.biz> Content-Transfer-Encoding: quoted-printable

The more values there are in a SIP request that are candidates for the= identity of the caller, the more likely we are going to entertain corner c= ases like this. There is no guarantee that the canonicalized identity in th= e From header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there are= multiple PAIs there's no guarantee that they will all canonicalize to the = same form. Somehow, though, in those RFC3324 trust environments, you are su= pposed to be able to know which PAI contains the identity that you care about for this purpose, the identi= ty of the originator of the call. STIR can't tell you how to find that, onl= y local trust domain policy can. I don't think the burden is on STIR to mak= e this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will= have one value for the originating telephone number, say, and that will ma= tch the canonicalized form of one of those identities and not the others. I= f your trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy= of sending "canon" with every call. I'm not sure there's much mo= re to say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Monday, September 12, 2016 at= 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: Why on= ly RECOMMEND when multiple identities?

Hi,

 = ;

Ok, maybe = =93multiple identities=94 was the wrong wording.

 = ;

My point w= as that, even if you know you should derive the identity from PAI instead o= f From, you can have two P-Asserted-Identity header fields, and as far as I understand there is no guarantee that the canonica= lized form of those match.

 = ;

Regards,

 = ;

Christer

 

From: = Peterson, Jon [mailto:jon.peter= son@neustar.biz]
Sent: 09 September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

 

The only normative RECOMMEND in Section= 8 is for cases "where local policy canonicalizes the identity into a = form different form how it appears in the From header field." That doesn't have anything to do with multiple identities. Th= e text in the previous sentence notes that it is talking about a case where= "the canonical identity derives from the P-Asserted-Identity field ra= ther than the From header field," not a case where identities based on both appear in different Identity headers.<= /o:p>

 

If P-Asserted-Identity is present, sure= ly that's where you should be looking for identity information. As I've arg= ued several times in the past, this is no more or less ambiguous than the practical use of P-Asserted-Identity in the fie= ld today: nothing about the request tells you "use PAI instead of From= " other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say anything more than that it's a matter of= local policy, as nothing about the protocol tells you whether or not you a= re in an RFC3324 trust domain. Thus far, I gather this hasn't impeded the a= doption of PAI. I did ask the WG in Berlin if we should include some more explicit indicator that would tel= l you that an Identity header came from PAI rather than From, and the conse= nsus was not to.

 

We are largely punting on why you might= have multiple Identity headers present in the same request: this is includ= ed for forward compatibility. The most likely use cases are ones where extensions will differentiate the Identity header= s. The recommendation to include "canon" here just enables some p= otential implementation optimizations (e.g. Verifier canonicalizes the iden= tity in PAI, then compares to value in "canon" to save cycles before computing the identity string and checking for break= age).

 

Jon Peterson

Neustar, Inc.

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Friday, September 9, 2016 at 4:32 AM
To: "stir@ietf.org" &= lt;stir@ietf.org>
Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities= ?

 

Hi,

 

Section 8 of draft-4474bis says (or, th= at=92s at least my reading) that, if the SIP request contains multiple iden= tities (e.g. if the request in addition to the From header field contains one or more P-Asserted-Identity header fields), it i= s RECOMMENDED to include =93canon=94, so that the verifier knows which iden= tity to verify.

 

Why is this only RECOMMENDED? If there = are more than one identity, shouldn=92t it be a MUST? I don=92t think we wa= nt the verifier to try all identities, and see which one (if any) works, do we?

 

Now, the text DOES talk about =93local = policy=94 when it comes to choosing between From and PAI for deriving the i= dentity, so perhaps we could say =93MUST, unless local policy defines from where the identity is retrieved=94, or something like = that=85

 

Regards,

 

Christer

 --_000_D3FDCA671B0885jonpetersonneustarbiz_-- From nobody Thu Sep 15 09:11:47 2016 Return-Path: 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 80A8E12BB84 for ; Thu, 15 Sep 2016 09:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 ISW-Zfvc8yoi for ; Thu, 15 Sep 2016 09:11:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1497312BE16 for ; Thu, 15 Sep 2016 08:11:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 32FC6300A06 for ; Thu, 15 Sep 2016 11:11:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Eb_zb2C3b_Lz for ; Thu, 15 Sep 2016 11:11:56 -0400 (EDT) Received: from 132-177-252-228.ip.sipit.net (unknown [132.177.252.228]) by mail.smeinc.net (Postfix) with ESMTPSA id 49094300446 for ; Thu, 15 Sep 2016 11:11:56 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> Date: Thu, 15 Sep 2016 11:11:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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, 15 Sep 2016 16:11:46 -0000 I was talking to several implementers during SIPit32. There was some = surprise that JOSE and PKIX have specified different syntax for an ECDSA = signature value. I suggest that we include a warning about this in at = least one of the documents. I am not totally sure that 4474bis is the = best place, and I=92m pleased to let the authors select the best = location or locations. I propose some text below. Russ =3D =3D =3D =3D =3D =3D =3D =3D Implementation Considerations An ECDSA signature is comprised of two values, called r and s. These signatures are represented in two different ways in PASSporT and certificates. PASSport signature values follow the conventions specified in JSON Web Algorithms (JWA) [RFC7518], where r and s are concatenated without any stripping or padding. Since r and s are always the same length, dividing the signature value in half will recover the r and s values. Certificate signature values follow the conventions in [RFC3279], where the r and s are ASN.1-encoded as a SEQUENCE of two non-negative integer values. If the high order bit is set, then a zero octet is prepended to produce a positive integer value. Recovery of the r and s values requires the removal of the added zero octet.= From nobody Thu Sep 15 09:47:19 2016 Return-Path: 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 7F54212B761 for ; Thu, 15 Sep 2016 09:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 SyWhhxJyHTRe for ; Thu, 15 Sep 2016 09:47:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D0712BA6C for ; Thu, 15 Sep 2016 09:07:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5A49330063A for ; Thu, 15 Sep 2016 12:07:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sQpX2XhPkv8U for ; Thu, 15 Sep 2016 12:07:22 -0400 (EDT) Received: from 132-177-252-228.ip.sipit.net (unknown [132.177.252.228]) by mail.smeinc.net (Postfix) with ESMTPSA id 623703004C3 for ; Thu, 15 Sep 2016 12:07:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> Date: Thu, 15 Sep 2016 12:07:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org 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, 15 Sep 2016 16:47:17 -0000 I have found a place where additional clarity is needed in Section 5.1. = The current text is: 5.1. Levels Of Assurance This specification supports different level of assurance (LOA). The LOA indications, which are Object Identifiers (OIDs) included in the certificate's certificate policies extension [RFC5280], allow CAs to differentiate those enrolled from proof-of-possession versus delegation. A Certification Policy and a Certification Practice Statement [RFC3647] are produced as part of the normal PKI bootstrapping process (i.e., the CP is written first and then the CAs say how they conform to the CP in the CPS). OIDs are used to reference the CP and if the CA wishes it can also include a reference to the CPS with the certificate policies extension. CAs that wish to express different LOAs MUST include the certificate policies extension in issued certificates. See Section 11 for additional information about the LOA registry. This all makes sense to me, but it does not say whether the LOA is = inferred from the CertPolicyId or explicitly carried in the = PolicyQualifierInfo. I think that the later is intended because of the = reference to an LOA registry. Please confirm that I got that right. For background, RFC 5280 specifies the following ASN.1 for the = PolicyQualifierInfo: PolicyQualifierInfo ::=3D SEQUENCE { policyQualifierId PolicyQualifierId, qualifier ANY DEFINED BY policyQualifierId } So, I think we need to specify a single OID for the LOA = policyQualifierId that is used in all certificates, and then have the = qualifier carry an object identifier for the LOA. Each certificate = policy would list the LOA object identifiers that are supported. If = this is the intent, then the IANA considerations should ask for the = assignment of the policyQualifierId object identifier. That would result in something like this: id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }=20 id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 }=20 id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 }=20 id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } Comments? Russ From nobody Thu Sep 15 11:40:12 2016 Return-Path: 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 5F8CF126579 for ; Thu, 15 Sep 2016 11:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bcDtRiWHYFje for ; Thu, 15 Sep 2016 11:40:08 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B9A12B300 for ; Thu, 15 Sep 2016 11:40:08 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id t7so66432168qkh.2 for ; Thu, 15 Sep 2016 11:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tTD8VMAyoQOLtEgf5ElPMrsg63h5FVUH7bszAZvD1zw=; b=IDPsNERiy/6JvDRAq5gTbC1Fg0eMUlbX6V8+ulyisXcJV377x0THnHBmt1udJxwKhi jBnAno3jCYHY1vwMChW9R8gX+wtdkqmqW6H2UAP9VQNzTBziuEPshcz8sRDSnU1T/T9/ I88WAKSwfticLG3A1xOLTYWgw0l839urIXP00dEhNOPrfROIR4Mjgf6tV3VjVongGxE5 D5M0Gl1nI2NKTGYIaGzBSmxGGh2SBdHEXo1llfHBKHcLOf8XG3qr0bvlm3G0hBNGHFU+ uO7aDYusQnvorzY7k1eSq6KcwnSJV2Adz4FuVxJa+qqB5wti8C9dGW7FjTqdEWFtTfmm C25Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tTD8VMAyoQOLtEgf5ElPMrsg63h5FVUH7bszAZvD1zw=; b=V6H9drQSpQH+F2rWrd9H33nXGa8L3kNeAr939oKzHMFo5KkvKI/CtacuGS1WbKmPcp pPBSdviLABXb8oqWgcpOb7stLTL7i6pC1URMK3j3sDbx7Lip7iKn9yLPPox0vgQJCWvs +Xqn/Ev8WeO8EFy2Y5S0ioZ+TSu6eY1+jpY0+lDqPEi2gywo0CxXJUVXhz01kYEwuwbd e0yR+5HzrLsczE0iIzPbNODo52UM9SEpkbqKVux4WzGENhnNNNWp9b89DtvVIRdS0LM8 oFtcs51cGYtasEqn0vkvV9MQuJlERNrvPym5xoDCj527/pHP5MKR39bluGwxpoOMVU+0 psxw== X-Gm-Message-State: AE9vXwP7ogydDV0MreDWADEbcL6zhv3dEjXMKolHApobb/k5tat2IsE5S36TwC6pATKbcg== X-Received: by 10.55.167.67 with SMTP id q64mr10779966qke.97.1473964807121; Thu, 15 Sep 2016 11:40:07 -0700 (PDT) Received: from ?IPv6:2606:4100:3880:2520:29a7:505a:ef46:214b? ([2606:4100:3880:2520:29a7:505a:ef46:214b]) by smtp.gmail.com with ESMTPSA id o51sm2553397qto.10.2016.09.15.11.40.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 11:40:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A48D6A46-B957-403D-BB1A-D7F17326D42E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Thu, 15 Sep 2016 19:40:09 +0100 Message-Id: <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 18:40:11 -0000 --Apple-Mail=_A48D6A46-B957-403D-BB1A-D7F17326D42E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, I=92m involved in the interop testing of early STIR implementations at = Sipit, and we have quickly run into issues around understanding how the = sender has encoded the source/destination. One person=92s tn: is another = person=92s sip: URI; the rules from the draft simply assume that any = purely-numeric user part is a telephone number, which is not always the = case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not validate. In short, I agree with Christer that the canon is far more important = than the draft suggests, and is needed whenever there could be any = ambiguity about how a sender has encoded (or a receiver would encode) = some of the data (which, frankly, is most B2B scenarios). Indeed, I would go probably further and suggest the canon SHOULD always = be included, - i.e. MUST, unless it is known to be operating within a = controlled environment where all entities that may be validating the = Identity header have a common understanding on its construction. The second reason I think that future implementers would thank you for = guidance like this is to enable extensibility. Say we wanted to add = protection of Display Name - and in the SIP world this is very important = since endpoints will typically display only display name if it is = present, so provides a trivial way of bypassing human visual validation. = Today, that would be achieved by defining a new ppt that added this = field. Which is all well and good, but both the sender and the receiver = would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was = always included, then (and I=92m not saying this should necessarily be = baseline spec, since it=92s too big a change at this stage) a receiver = could validate the signature of the canon, rather than reconstructing = it, and then validate field-by-field for the fields it cares/knows = about. Regards, Alan > On 13 Sep 2016, at 23:30, Peterson, Jon = wrote: >=20 >=20 > The more values there are in a SIP request that are candidates for the = identity of the caller, the more likely we are going to entertain corner = cases like this. There is no guarantee that the canonicalized identity = in the =46rom header field will be identical to one in PAI - why carry = PAI if it would be? - and similarly if there are multiple PAIs there's = no guarantee that they will all canonicalize to the same form. Somehow, = though, in those RFC3324 trust environments, you are supposed to be able = to know which PAI contains the identity that you care about for this = purpose, the identity of the originator of the call. STIR can't tell you = how to find that, only local trust domain policy can. I don't think the = burden is on STIR to make this unambiguous when apparently the trust = domains already can and do. >=20 > But, of course, when carrying the "canon" parameter, it will have one = value for the originating telephone number, say, and that will match the = canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your = trust domain should probably set a local policy of sending "canon" with = every call. I'm not sure there's much more to say about it than that in = the core specs, though. >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Christer Holmberg > > Date: Monday, September 12, 2016 at 10:31 AM > To: Jon Peterson >, "stir@ietf.org = " > > Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >=20 >> Hi, >> =20 >> Ok, maybe =93multiple identities=94 was the wrong wording. >> =20 >> My point was that, even if you know you should derive the identity = from PAI instead of From, you can have two P-Asserted-Identity header = fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >> =20 >> Regards, >> =20 >> Christer >> =A0 <> >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >> Sent: 09 September 2016 20:11 >> To: Christer Holmberg >; stir@ietf.org = >> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >> =20 >> =20 >> The only normative RECOMMEND in Section 8 is for cases "where local = policy canonicalizes the identity into a form different form how it = appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >> =20 >> If P-Asserted-Identity is present, surely that's where you should be = looking for identity information. As I've argued several times in the = past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >> =20 >> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >> =20 >> Jon Peterson >> Neustar, Inc. >> =20 >> From: stir > on = behalf of Christer Holmberg > >> Date: Friday, September 9, 2016 at 4:32 AM >> To: "stir@ietf.org " > >> Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? >> =20 >>> Hi, >>> =20 >>> Section 8 of draft-4474bis says (or, that=92s at least my reading) = that, if the SIP request contains multiple identities (e.g. if the = request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>> =20 >>> Why is this only RECOMMENDED? If there are more than one identity, = shouldn=92t it be a MUST? I don=92t think we want the verifier to try = all identities, and see which one (if any) works, do we? >>> =20 >>> Now, the text DOES talk about =93local policy=94 when it comes to = choosing between =46rom and PAI for deriving the identity, so perhaps we = could say =93MUST, unless local policy defines from where the identity = is retrieved=94, or something like that=85 >>> =20 >>> Regards, >>> =20 >>> Christer > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_A48D6A46-B957-403D-BB1A-D7F17326D42E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi all,

I=92= m involved in the interop testing of early STIR implementations at = Sipit, and we have quickly run into issues around understanding how the = sender has encoded the source/destination. One person=92s tn: is another = person=92s sip: URI; the rules from the draft simply assume that any = purely-numeric user part is a telephone number, which is not always the = case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not = validate.

In = short, I agree with Christer that the canon is far more important than = the draft suggests, and is needed whenever there could be any ambiguity = about how a sender has encoded (or a receiver would encode) some of the = data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and = suggest the canon SHOULD always be included, - i.e. MUST, unless it is = known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future = implementers would thank you for guidance like this is to enable = extensibility. Say we wanted to add protection of Display Name - and in = the SIP world this is very important since endpoints will typically = display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to = support this new ppt, and this is by no means guaranteed. So for maximum = compatibility what would a sender do? Should a sender include multiple = Identity headers of multiple ppts, hoping one is supported by the far = end? The overhead there would be huge. If canon was always included, = then (and I=92m not saying this should necessarily be baseline spec, = since it=92s too big a change at this stage) a receiver could validate = the signature of the canon, rather than reconstructing it, and then = validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 Sep 2016, at 23:30, = Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP = request that are candidates for the identity of the caller, the more = likely we are going to entertain corner cases like this. There is no = guarantee that the canonicalized identity in the =46rom header field = will be identical to one in PAI - why carry PAI if it would be? - and = similarly if there are multiple PAIs there's no guarantee that they will = all canonicalize to the same form. Somehow, though, in those RFC3324 = trust environments, you are supposed to be able to know which PAI = contains the identity that you care about for this purpose, the identity = of the originator of the call. STIR can't tell you how to find that, = only local trust domain policy can. I don't think the burden is on STIR = to make this unambiguous when apparently the trust domains already can = and do.

But, of course, when carrying the "canon" parameter, it will = have one value for the originating telephone number, say, and that will = match the canonicalized form of one of those identities and not the = others. If your trust domain introduces this ambiguity into every call, = then your trust domain should probably set a local policy of sending = "canon" with every call. I'm not sure there's much more to say about it = than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple = identities=94 was the wrong wording.
 
My point was that, even = if you know you should derive the identity from PAI instead of From, you = can have two P-Asserted-Identity header fields, and as far as I = understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, = Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 = September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative = RECOMMEND in Section 8 is for cases "where local policy canonicalizes = the identity into a form different form how it appears in the =46rom = header field." That doesn't have anything to do with multiple = identities. The text in the previous sentence notes that it is talking = about a case where "the canonical identity derives from the = P-Asserted-Identity field rather than the =46rom header field," not a = case where identities based on both appear in different Identity = headers.
 
If P-Asserted-Identity is = present, surely that's where you should be looking for identity = information. As I've argued several times in the past, this is no more = or less ambiguous than the practical use of P-Asserted-Identity in the = field today: nothing about the request tells you "use PAI instead of = From" other than the presence of PAI. Because of all the RFC3324 trust = domain stuff that Mark Watson talked us into back in the day, it's hard = to say anything more than that it's a matter of local policy, as nothing = about the protocol tells you whether or not you are in an RFC3324 trust = domain. Thus far, I gather this hasn't impeded the adoption of PAI. I = did ask the WG in Berlin if we should include some more explicit = indicator that would tell you that an Identity header came from PAI = rather than From, and the consensus was not to.
 
We are largely punting on = why you might have multiple Identity headers present in the same = request: this is included for forward compatibility. The most likely use = cases are ones where extensions will differentiate the Identity headers. = The recommendation to include "canon" here just enables some potential = implementation optimizations (e.g. Verifier canonicalizes the identity = in PAI, then compares to value in "canon" to save cycles before = computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only = RECOMMENDED? If there are more than one identity, shouldn=92t it be a = MUST? I don=92t think we want the verifier to try all identities, and = see which one (if any) works, do we?
 
Now, the text DOES talk = about =93local policy=94 when it comes to choosing between =46rom and = PAI for deriving the identity, so perhaps we could say =93MUST, unless = local policy defines from where the identity is retrieved=94, or = something like that=85
 
Regards,
 
Christer
<= /div>
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_A48D6A46-B957-403D-BB1A-D7F17326D42E-- From nobody Thu Sep 15 11:51:52 2016 Return-Path: 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 07CDD12B1EE for ; Thu, 15 Sep 2016 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 KS0NXiSdOgcM for ; Thu, 15 Sep 2016 11:51:46 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3397B12B313 for ; Thu, 15 Sep 2016 11:51:46 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id w204so65868468qka.0 for ; Thu, 15 Sep 2016 11:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tWEf5BpkvSCJBJFuqi1WVqp8KJBhlSPmvwp5S6/qp5c=; b=Vv/KTf1r1rs7Duj0ulDjM/+EPuyfAlau1a+PScQ/GwikLBKc4jSwdMcTj+6ZfxNiAY paBfTLZwihpFcDEWS7yJCuDTo7UYQ8L0dO2uGMgc22TrwULXIHqLZtQ4G8RvfhZqWl6Z WJ5FQKphrqWFf0n3EOtAld95QDHqbmuRslTVrIDh9r0oikv+sGolPDPAvXMKklNGrpBO AsA4Y2z9M6aFYQZm7P8TnThZIka/eBmB/PDGX5jKPKPcQ9Rut+xn2M5ArmogTmZ+F6xB Dbtt5NQYxm/WYU23mSPDZ3ksKMkT4Rmr3Ocq/K0+laVQ7Ji+MwaZBU+aqwdBJ+7Vg2YE ntyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tWEf5BpkvSCJBJFuqi1WVqp8KJBhlSPmvwp5S6/qp5c=; b=Nji1zJKCGVf6jDejMdA07lQJA5kcKy5CETeBQJ4hzVx5PuUJAy0jqHu46l0X0aIDGQ 9nLGypUmZrqj0LfUswEzOyTBr5B5sltgLciMYePBbizNF0fjD6SFHsAdhCBMskQVrLDH ptSsV6ENCnvcsNOBxroabFj9OEDj33FLm3yGZQHC/GHxsI/FvA0A7ccIBnGtgvgvemx1 YThfXtjk1zJkjX//Sik575xOttI3KsqcX0itgQOQ5RsjdxZ9wHrBpPnxte4ZlvbFHLiF TCzB3z6gK2UOYY5LLKyxCDvDELvHTv1w91Drdl7oR3qzJOObo747egzGzZ1iytlLia6T TTlw== X-Gm-Message-State: AE9vXwPglS4f1WUSzseH/7ERWZlZeAzVmyZfYT6maxGvscl3gK0j74XXQwZ3gWNEs4Uk1Q== X-Received: by 10.55.165.10 with SMTP id o10mr12276886qke.282.1473965505327; Thu, 15 Sep 2016 11:51:45 -0700 (PDT) Received: from [10.33.192.39] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id f56sm2561707qta.26.2016.09.15.11.51.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 11:51:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A2C5F73C-4399-42C9-A27F-66B669E71F0A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> Date: Thu, 15 Sep 2016 14:51:40 -0400 Message-Id: <7B94A7E2-DC98-4589-8764-4F2660631C03@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> To: Alan Ford X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , "Peterson, Jon" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 18:51:50 -0000 --Apple-Mail=_A2C5F73C-4399-42C9-A27F-66B669E71F0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Can you cite an example? I=92m having trouble guessing where you have a = >6 digit number string on the user side which is not a telephone number. = =20 If there is an implementation that is assigning = sip:2025551212@example.com to a user that doesn=92t have the telephone = number +12025551212, then I don=92t think I care much that identify = fails. Brian =20 > On Sep 15, 2016, at 2:40 PM, Alan Ford wrote: >=20 > Hi all, >=20 > I=92m involved in the interop testing of early STIR implementations at = Sipit, and we have quickly run into issues around understanding how the = sender has encoded the source/destination. One person=92s tn: is another = person=92s sip: URI; the rules from the draft simply assume that any = purely-numeric user part is a telephone number, which is not always the = case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not validate. >=20 > In short, I agree with Christer that the canon is far more important = than the draft suggests, and is needed whenever there could be any = ambiguity about how a sender has encoded (or a receiver would encode) = some of the data (which, frankly, is most B2B scenarios). >=20 > Indeed, I would go probably further and suggest the canon SHOULD = always be included, - i.e. MUST, unless it is known to be operating = within a controlled environment where all entities that may be = validating the Identity header have a common understanding on its = construction. >=20 > The second reason I think that future implementers would thank you for = guidance like this is to enable extensibility. Say we wanted to add = protection of Display Name - and in the SIP world this is very important = since endpoints will typically display only display name if it is = present, so provides a trivial way of bypassing human visual validation. = Today, that would be achieved by defining a new ppt that added this = field. Which is all well and good, but both the sender and the receiver = would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was = always included, then (and I=92m not saying this should necessarily be = baseline spec, since it=92s too big a change at this stage) a receiver = could validate the signature of the canon, rather than reconstructing = it, and then validate field-by-field for the fields it cares/knows = about. >=20 > Regards, > Alan >=20 >> On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: >>=20 >>=20 >> The more values there are in a SIP request that are candidates for = the identity of the caller, the more likely we are going to entertain = corner cases like this. There is no guarantee that the canonicalized = identity in the =46rom header field will be identical to one in PAI - = why carry PAI if it would be? - and similarly if there are multiple PAIs = there's no guarantee that they will all canonicalize to the same form. = Somehow, though, in those RFC3324 trust environments, you are supposed = to be able to know which PAI contains the identity that you care about = for this purpose, the identity of the originator of the call. STIR can't = tell you how to find that, only local trust domain policy can. I don't = think the burden is on STIR to make this unambiguous when apparently the = trust domains already can and do. >>=20 >> But, of course, when carrying the "canon" parameter, it will have one = value for the originating telephone number, say, and that will match the = canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your = trust domain should probably set a local policy of sending "canon" with = every call. I'm not sure there's much more to say about it than that in = the core specs, though. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> From: Christer Holmberg > >> Date: Monday, September 12, 2016 at 10:31 AM >> To: Jon Peterson >, "stir@ietf.org = " > >> Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>=20 >>> Hi, >>> =20 >>> Ok, maybe =93multiple identities=94 was the wrong wording. >>> =20 >>> My point was that, even if you know you should derive the identity = from PAI instead of From, you can have two P-Asserted-Identity header = fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >>> =20 >>> Regards, >>> =20 >>> Christer >>> =A0 <> >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >>> Sent: 09 September 2016 20:11 >>> To: Christer Holmberg >; stir@ietf.org = >>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>> =20 >>> =20 >>> The only normative RECOMMEND in Section 8 is for cases "where local = policy canonicalizes the identity into a form different form how it = appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >>> =20 >>> If P-Asserted-Identity is present, surely that's where you should be = looking for identity information. As I've argued several times in the = past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >>> =20 >>> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >>> =20 >>> Jon Peterson >>> Neustar, Inc. >>> =20 >>> From: stir > on = behalf of Christer Holmberg > >>> Date: Friday, September 9, 2016 at 4:32 AM >>> To: "stir@ietf.org " > >>> Subject: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>> =20 >>>> Hi, >>>> =20 >>>> Section 8 of draft-4474bis says (or, that=92s at least my reading) = that, if the SIP request contains multiple identities (e.g. if the = request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>>> =20 >>>> Why is this only RECOMMENDED? If there are more than one identity, = shouldn=92t it be a MUST? I don=92t think we want the verifier to try = all identities, and see which one (if any) works, do we? >>>> =20 >>>> Now, the text DOES talk about =93local policy=94 when it comes to = choosing between =46rom and PAI for deriving the identity, so perhaps we = could say =93MUST, unless local policy defines from where the identity = is retrieved=94, or something like that=85 >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir = > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_A2C5F73C-4399-42C9-A27F-66B669E71F0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Can you cite an example?  I=92m having trouble guessing = where you have a >6 digit number string on the user side which is not = a telephone number.  

If there is an implementation that is assigning sip:2025551212@example.com to a user that doesn=92t have = the telephone number +12025551212, then I don=92t think I care much that = identify fails.

Brian
 
On = Sep 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com>= wrote:

Hi all,

I=92m involved in the = interop testing of early STIR implementations at Sipit, and we have = quickly run into issues around understanding how the sender has encoded = the source/destination. One person=92s tn: is another person=92s sip: = URI; the rules from the draft simply assume that any purely-numeric user = part is a telephone number, which is not always the case in the real = world. Without any context, when you call a numeric alias in another = domain, you have no idea whether this maps to a telephone number or a = SIP URI. If the receiver thinks it=92s a tn:, but the sender thinks it=92s= a SIP URI, then the Identity will not validate.

In short, I agree with Christer that = the canon is far more important than the draft suggests, and is needed = whenever there could be any ambiguity about how a sender has encoded (or = a receiver would encode) some of the data (which, frankly, is most B2B = scenarios).

Indeed, I would go probably further and suggest the canon = SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future = implementers would thank you for guidance like this is to enable = extensibility. Say we wanted to add protection of Display Name - and in = the SIP world this is very important since endpoints will typically = display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to = support this new ppt, and this is by no means guaranteed. So for maximum = compatibility what would a sender do? Should a sender include multiple = Identity headers of multiple ppts, hoping one is supported by the far = end? The overhead there would be huge. If canon was always included, = then (and I=92m not saying this should necessarily be baseline spec, = since it=92s too big a change at this stage) a receiver could validate = the signature of the canon, rather than reconstructing it, and then = validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 = Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP = request that are candidates for the identity of the caller, the more = likely we are going to entertain corner cases like this. There is no = guarantee that the canonicalized identity in the =46rom header field = will be identical to one in PAI - why carry PAI if it would be? - and = similarly if there are multiple PAIs there's no guarantee that they will = all canonicalize to the same form. Somehow, though, in those RFC3324 = trust environments, you are supposed to be able to know which PAI = contains the identity that you care about for this purpose, the identity = of the originator of the call. STIR can't tell you how to find that, = only local trust domain policy can. I don't think the burden is on STIR = to make this unambiguous when apparently the trust domains already can = and do.

But, of course, when carrying the "canon" parameter, it will = have one value for the originating telephone number, say, and that will = match the canonicalized form of one of those identities and not the = others. If your trust domain introduces this ambiguity into every call, = then your trust domain should probably set a local policy of sending = "canon" with every call. I'm not sure there's much more to say about it = than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple = identities=94 was the wrong wording.
 
My point was that, even = if you know you should derive the identity from PAI instead of From, you = can have two P-Asserted-Identity header fields, and as far as I = understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, = Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 = September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative = RECOMMEND in Section 8 is for cases "where local policy canonicalizes = the identity into a form different form how it appears in the =46rom = header field." That doesn't have anything to do with multiple = identities. The text in the previous sentence notes that it is talking = about a case where "the canonical identity derives from the = P-Asserted-Identity field rather than the =46rom header field," not a = case where identities based on both appear in different Identity = headers.
 
If P-Asserted-Identity is = present, surely that's where you should be looking for identity = information. As I've argued several times in the past, this is no more = or less ambiguous than the practical use of P-Asserted-Identity in the = field today: nothing about the request tells you "use PAI instead of = From" other than the presence of PAI. Because of all the RFC3324 trust = domain stuff that Mark Watson talked us into back in the day, it's hard = to say anything more than that it's a matter of local policy, as nothing = about the protocol tells you whether or not you are in an RFC3324 trust = domain. Thus far, I gather this hasn't impeded the adoption of PAI. I = did ask the WG in Berlin if we should include some more explicit = indicator that would tell you that an Identity header came from PAI = rather than From, and the consensus was not to.
 
We are largely punting on = why you might have multiple Identity headers present in the same = request: this is included for forward compatibility. The most likely use = cases are ones where extensions will differentiate the Identity headers. = The recommendation to include "canon" here just enables some potential = implementation optimizations (e.g. Verifier canonicalizes the identity = in PAI, then compares to value in "canon" to save cycles before = computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only = RECOMMENDED? If there are more than one identity, shouldn=92t it be a = MUST? I don=92t think we want the verifier to try all identities, and = see which one (if any) works, do we?
 
Now, the text DOES talk = about =93local policy=94 when it comes to choosing between =46rom and = PAI for deriving the identity, so perhaps we could say =93MUST, unless = local policy defines from where the identity is retrieved=94, or = something like that=85
 
Regards,
 
Christer
<= /div>
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_A2C5F73C-4399-42C9-A27F-66B669E71F0A-- From nobody Thu Sep 15 11:56:06 2016 Return-Path: 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 A156812B33F for ; Thu, 15 Sep 2016 11:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gsIrPrPuDijh for ; Thu, 15 Sep 2016 11:56:01 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8139512B346 for ; Thu, 15 Sep 2016 11:56:00 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id t7so66886942qkh.2 for ; Thu, 15 Sep 2016 11:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iPGulmfcaYwUHijLM2ObBGtWPPqp1SANdCwPhtvJvU0=; b=nUOGTl60SS2EMvlV+A/sdOcQuN9fEdCtdBWsCjLsF9R/3l9asfHcwAMqdVG0Tda9YB NZo8l619a4EMXBrBzSp2LWwT9l2NVwShVzTZednSYFvK5DqOm1x96EF6v7auEww/JQ9Q +FNai6ewVcbJt7dq8cee8y/ElLTROTQQJhsxyJlUOL+0hFCgvjM1U5NWTKUfD8Kfe+4A JMbwo3hPsG2nY3h9TX4ZKZfINoohnHSn1KKKGr4TlvkT99XxxGXdCC/KvDxwEoU15KoI rhe77LCcxB8hKc1kzhbgU+d7TeLBVcE5XTkYZ3OAMu2qc1tA32FvFZLdG/yIKbidV867 Ewog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iPGulmfcaYwUHijLM2ObBGtWPPqp1SANdCwPhtvJvU0=; b=QAXXJk63ZmBF7pxZQaxxA/KJ3rA3RKGPSH6KuAUcd2mNmPxZDu/U+cPgtpyB9cUAn6 DGqFpKVeofmbd4vnlSp3g1UM4VplPubbyZGivnQr3qjMwRQPHRgkJGa6fL2Gm2XI75ba 7+xD/B2yga7/XA2Dn7WJpmqUDQXc3Pa0MG1FETz5GNYODebfrPLz4Wzei6/WzaI0jkB1 +IoKnFpbHYZmsD2dSpu10ntkvWG3vXC3RMrwUlMs7mXgl+qLjGoIr0FE4Ui+/EXPhr+J kXlDQvt2HZuijzrYLsYXjCLmuT7j5c1H7bDe/IrG5atsWQxpnBkLUeYcX4jDRiTkR6H0 BNaw== X-Gm-Message-State: AE9vXwNf7Ac6ovrysTdV3PKbCn7AnRD2G61IUpKOGtO300bxVc3lyK8syMpbpTN66+rzcQ== X-Received: by 10.55.181.194 with SMTP id e185mr2261434qkf.299.1473965759653; Thu, 15 Sep 2016 11:55:59 -0700 (PDT) Received: from ?IPv6:2606:4100:3880:2520:29a7:505a:ef46:214b? ([2606:4100:3880:2520:29a7:505a:ef46:214b]) by smtp.gmail.com with ESMTPSA id c64sm2562048qkg.43.2016.09.15.11.55.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 11:55:58 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_69E10810-2685-44A6-8533-B77DCF1D1B94" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <7B94A7E2-DC98-4589-8764-4F2660631C03@brianrosen.net> Date: Thu, 15 Sep 2016 19:56:03 +0100 Message-Id: <28CFDD61-D94F-444F-9CED-DA031A076EB7@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <7B94A7E2-DC98-4589-8764-4F2660631C03@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , "Peterson, Jon" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 18:56:05 -0000 --Apple-Mail=_69E10810-2685-44A6-8533-B77DCF1D1B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Brian, I can think of many enterprises that have long numeric aliases (at least = 6 digits) for internal dialling, but are mapped to external PSTN = differently. So everyone gets an extension, e.g. 44121234, but this is mapped to +44 = 1999 881234 for external dialling. Regards, Alan > On 15 Sep 2016, at 19:51, Brian Rosen wrote: >=20 > Can you cite an example? I=92m having trouble guessing where you have = a >6 digit number string on the user side which is not a telephone = number. =20 >=20 > If there is an implementation that is assigning = sip:2025551212@example.com to a user that = doesn=92t have the telephone number +12025551212, then I don=92t think I = care much that identify fails. >=20 > Brian > =20 >> On Sep 15, 2016, at 2:40 PM, Alan Ford > wrote: >>=20 >> Hi all, >>=20 >> I=92m involved in the interop testing of early STIR implementations = at Sipit, and we have quickly run into issues around understanding how = the sender has encoded the source/destination. One person=92s tn: is = another person=92s sip: URI; the rules from the draft simply assume that = any purely-numeric user part is a telephone number, which is not always = the case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not validate. >>=20 >> In short, I agree with Christer that the canon is far more important = than the draft suggests, and is needed whenever there could be any = ambiguity about how a sender has encoded (or a receiver would encode) = some of the data (which, frankly, is most B2B scenarios). >>=20 >> Indeed, I would go probably further and suggest the canon SHOULD = always be included, - i.e. MUST, unless it is known to be operating = within a controlled environment where all entities that may be = validating the Identity header have a common understanding on its = construction. >>=20 >> The second reason I think that future implementers would thank you = for guidance like this is to enable extensibility. Say we wanted to add = protection of Display Name - and in the SIP world this is very important = since endpoints will typically display only display name if it is = present, so provides a trivial way of bypassing human visual validation. = Today, that would be achieved by defining a new ppt that added this = field. Which is all well and good, but both the sender and the receiver = would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was = always included, then (and I=92m not saying this should necessarily be = baseline spec, since it=92s too big a change at this stage) a receiver = could validate the signature of the canon, rather than reconstructing = it, and then validate field-by-field for the fields it cares/knows = about. >>=20 >> Regards, >> Alan >>=20 >>> On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: >>>=20 >>>=20 >>> The more values there are in a SIP request that are candidates for = the identity of the caller, the more likely we are going to entertain = corner cases like this. There is no guarantee that the canonicalized = identity in the =46rom header field will be identical to one in PAI - = why carry PAI if it would be? - and similarly if there are multiple PAIs = there's no guarantee that they will all canonicalize to the same form. = Somehow, though, in those RFC3324 trust environments, you are supposed = to be able to know which PAI contains the identity that you care about = for this purpose, the identity of the originator of the call. STIR can't = tell you how to find that, only local trust domain policy can. I don't = think the burden is on STIR to make this unambiguous when apparently the = trust domains already can and do. >>>=20 >>> But, of course, when carrying the "canon" parameter, it will have = one value for the originating telephone number, say, and that will match = the canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your = trust domain should probably set a local policy of sending "canon" with = every call. I'm not sure there's much more to say about it than that in = the core specs, though. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> From: Christer Holmberg > >>> Date: Monday, September 12, 2016 at 10:31 AM >>> To: Jon Peterson >, "stir@ietf.org = " > >>> Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>=20 >>>> Hi, >>>> =20 >>>> Ok, maybe =93multiple identities=94 was the wrong wording. >>>> =20 >>>> My point was that, even if you know you should derive the identity = from PAI instead of From, you can have two P-Asserted-Identity header = fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >>>> =A0 <> >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >>>> Sent: 09 September 2016 20:11 >>>> To: Christer Holmberg >; stir@ietf.org = >>>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>> =20 >>>> =20 >>>> The only normative RECOMMEND in Section 8 is for cases "where local = policy canonicalizes the identity into a form different form how it = appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >>>> =20 >>>> If P-Asserted-Identity is present, surely that's where you should = be looking for identity information. As I've argued several times in the = past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >>>> =20 >>>> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >>>> =20 >>>> Jon Peterson >>>> Neustar, Inc. >>>> =20 >>>> From: stir > = on behalf of Christer Holmberg > >>>> Date: Friday, September 9, 2016 at 4:32 AM >>>> To: "stir@ietf.org " > >>>> Subject: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>> =20 >>>>> Hi, >>>>> =20 >>>>> Section 8 of draft-4474bis says (or, that=92s at least my reading) = that, if the SIP request contains multiple identities (e.g. if the = request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>>>> =20 >>>>> Why is this only RECOMMENDED? If there are more than one identity, = shouldn=92t it be a MUST? I don=92t think we want the verifier to try = all identities, and see which one (if any) works, do we? >>>>> =20 >>>>> Now, the text DOES talk about =93local policy=94 when it comes to = choosing between =46rom and PAI for deriving the identity, so perhaps we = could say =93MUST, unless local policy defines from where the identity = is retrieved=94, or something like that=85 >>>>> =20 >>>>> Regards, >>>>> =20 >>>>> Christer >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir = >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_69E10810-2685-44A6-8533-B77DCF1D1B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Brian,

I= can think of many enterprises that have long numeric aliases (at least = 6 digits) for internal dialling, but are mapped to external PSTN = differently.

So = everyone gets an extension, e.g. 44121234, but this is mapped to +44 = 1999 881234 for external dialling.

Regards,
Alan

On 15 Sep 2016, at 19:51, Brian = Rosen <br@brianrosen.net> wrote:

Can you cite = an example?  I=92m having trouble guessing where you have a >6 = digit number string on the user side which is not a telephone number. =  

If there is = an implementation that is assigning sip:2025551212@example.com to a user that doesn=92t have = the telephone number +12025551212, then I don=92t think I care much that = identify fails.

Brian
 
On Sep = 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com> wrote:

Hi all,

I=92m involved in the = interop testing of early STIR implementations at Sipit, and we have = quickly run into issues around understanding how the sender has encoded = the source/destination. One person=92s tn: is another person=92s sip: = URI; the rules from the draft simply assume that any purely-numeric user = part is a telephone number, which is not always the case in the real = world. Without any context, when you call a numeric alias in another = domain, you have no idea whether this maps to a telephone number or a = SIP URI. If the receiver thinks it=92s a tn:, but the sender thinks it=92s= a SIP URI, then the Identity will not validate.

In short, I agree with Christer that = the canon is far more important than the draft suggests, and is needed = whenever there could be any ambiguity about how a sender has encoded (or = a receiver would encode) some of the data (which, frankly, is most B2B = scenarios).

Indeed, I would go probably further and suggest the canon = SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future = implementers would thank you for guidance like this is to enable = extensibility. Say we wanted to add protection of Display Name - and in = the SIP world this is very important since endpoints will typically = display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to = support this new ppt, and this is by no means guaranteed. So for maximum = compatibility what would a sender do? Should a sender include multiple = Identity headers of multiple ppts, hoping one is supported by the far = end? The overhead there would be huge. If canon was always included, = then (and I=92m not saying this should necessarily be baseline spec, = since it=92s too big a change at this stage) a receiver could validate = the signature of the canon, rather than reconstructing it, and then = validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 = Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP = request that are candidates for the identity of the caller, the more = likely we are going to entertain corner cases like this. There is no = guarantee that the canonicalized identity in the =46rom header field = will be identical to one in PAI - why carry PAI if it would be? - and = similarly if there are multiple PAIs there's no guarantee that they will = all canonicalize to the same form. Somehow, though, in those RFC3324 = trust environments, you are supposed to be able to know which PAI = contains the identity that you care about for this purpose, the identity = of the originator of the call. STIR can't tell you how to find that, = only local trust domain policy can. I don't think the burden is on STIR = to make this unambiguous when apparently the trust domains already can = and do.

But, of course, when carrying the "canon" parameter, it will = have one value for the originating telephone number, say, and that will = match the canonicalized form of one of those identities and not the = others. If your trust domain introduces this ambiguity into every call, = then your trust domain should probably set a local policy of sending = "canon" with every call. I'm not sure there's much more to say about it = than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple = identities=94 was the wrong wording.
 
My point was that, even = if you know you should derive the identity from PAI instead of From, you = can have two P-Asserted-Identity header fields, and as far as I = understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, = Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 = September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative = RECOMMEND in Section 8 is for cases "where local policy canonicalizes = the identity into a form different form how it appears in the =46rom = header field." That doesn't have anything to do with multiple = identities. The text in the previous sentence notes that it is talking = about a case where "the canonical identity derives from the = P-Asserted-Identity field rather than the =46rom header field," not a = case where identities based on both appear in different Identity = headers.
 
If P-Asserted-Identity is = present, surely that's where you should be looking for identity = information. As I've argued several times in the past, this is no more = or less ambiguous than the practical use of P-Asserted-Identity in the = field today: nothing about the request tells you "use PAI instead of = From" other than the presence of PAI. Because of all the RFC3324 trust = domain stuff that Mark Watson talked us into back in the day, it's hard = to say anything more than that it's a matter of local policy, as nothing = about the protocol tells you whether or not you are in an RFC3324 trust = domain. Thus far, I gather this hasn't impeded the adoption of PAI. I = did ask the WG in Berlin if we should include some more explicit = indicator that would tell you that an Identity header came from PAI = rather than From, and the consensus was not to.
 
We are largely punting on = why you might have multiple Identity headers present in the same = request: this is included for forward compatibility. The most likely use = cases are ones where extensions will differentiate the Identity headers. = The recommendation to include "canon" here just enables some potential = implementation optimizations (e.g. Verifier canonicalizes the identity = in PAI, then compares to value in "canon" to save cycles before = computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only = RECOMMENDED? If there are more than one identity, shouldn=92t it be a = MUST? I don=92t think we want the verifier to try all identities, and = see which one (if any) works, do we?
 
Now, the text DOES talk = about =93local policy=94 when it comes to choosing between =46rom and = PAI for deriving the identity, so perhaps we could say =93MUST, unless = local policy defines from where the identity is retrieved=94, or = something like that=85
 
Regards,
 
Christer
<= /div>
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


= --Apple-Mail=_69E10810-2685-44A6-8533-B77DCF1D1B94-- From nobody Thu Sep 15 12:02:21 2016 Return-Path: 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 50B0912B006 for ; Thu, 15 Sep 2016 12:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 8bMarMB32rtd for ; Thu, 15 Sep 2016 12:02:16 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39AA12B383 for ; Thu, 15 Sep 2016 12:01:21 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so66851272qkc.3 for ; Thu, 15 Sep 2016 12:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=HnDBioYFQDbzCQBvIeYx6yXHMlunPQr9BnKxcGvY7x8=; b=ZuMlYUQ2pL220lr4t9qXJMoDUKA394wige760N7d8hGVVsopgJBiQjtL1dT/7JqJgK LUf/ZCaharCAr4SCp8a/aGYdhVoXWj8SHy82DXEbZZsD4shNpdU0NA/5e5nnUeC+bhbB fPTPFfWp+uOID3F8zblGSNVkQwBY45mt2EE65umnApm33GfBZSO/F2IH0B1SU3LUr3zz hFKaDH5M6kYSKiO87i/0uGVFNPs17SeF1Mhv6DLarScaEyPrtPSm2H3IVMhDBNlP0lr1 t/Zsjp1aOf+78RExTqmdMOs1cs3Zw/cFN9APcICaJttC9+YEld8LkD+eLoGloumaTaWZ FerQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HnDBioYFQDbzCQBvIeYx6yXHMlunPQr9BnKxcGvY7x8=; b=dnbE5GQ2J1tj8OyD1CggxAFByEV4eNMMhQfZOL98yBwf++oSzXtg/VfY0SJjIZJjyK HYk/5zmsOGGqd6tx3/+hEhlerBLL+9MTHUZ3BQNjHhJKmjt+1L3/RTnEr/BFgxYhpfjH pEehcyHi4ExEQUlDNWPaNzQZ74lBHx1qga0XcZUx1eKFgYLI6WVi4ZJcam9jjXnue04j RCO95QJSCNzsVA+jh0P3dgKOmWApisWTm/QRfQPL6YNPAjoWTzBVQg+PW0Bio8jE2ZEV lRDFaN1o1PF9x0CZMxCTw7p+u5WY/36+nDGj3lVyIs2nCZxTBxmvvnlPEjjH/Bt4ZVlQ YsJQ== X-Gm-Message-State: AE9vXwOT7Io49z0TxHkqIPS9WDEFY2mRN04f36AYKNLnJz4+TTjyVRGy4VqJ6r+0NmqRqg== X-Received: by 10.55.17.71 with SMTP id b68mr11839966qkh.141.1473966080678; Thu, 15 Sep 2016 12:01:20 -0700 (PDT) Received: from [10.33.192.39] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r5sm2571067qkf.34.2016.09.15.12.01.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 12:01:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0493295A-BCCF-4CB4-8649-746B6DDCCF81" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> Date: Thu, 15 Sep 2016 15:01:18 -0400 Message-Id: <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> To: Alan Ford X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , "Peterson, Jon" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 19:02:19 -0000 --Apple-Mail=_0493295A-BCCF-4CB4-8649-746B6DDCCF81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Okay, got it. Pity the poor blokes who have to DTMF these extensions, = but I get it. So, what really is correct behavior here? The call is sent with an = internal extension as a SIP URI, the mechanism tries to set an Identity = header, and what? If it does not have a credential for that TN, it shouldn=92t be trying = to sign using a TN credential. If it has a credential for the SIP ID, then the scope of that credential = wouldn=92t be a telephone number, it would be a domain, and the = recipient should be able to figure out what is happening. Where is the problem? Brian > On Sep 15, 2016, at 2:40 PM, Alan Ford wrote: >=20 > Hi all, >=20 > I=92m involved in the interop testing of early STIR implementations at = Sipit, and we have quickly run into issues around understanding how the = sender has encoded the source/destination. One person=92s tn: is another = person=92s sip: URI; the rules from the draft simply assume that any = purely-numeric user part is a telephone number, which is not always the = case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not validate. >=20 > In short, I agree with Christer that the canon is far more important = than the draft suggests, and is needed whenever there could be any = ambiguity about how a sender has encoded (or a receiver would encode) = some of the data (which, frankly, is most B2B scenarios). >=20 > Indeed, I would go probably further and suggest the canon SHOULD = always be included, - i.e. MUST, unless it is known to be operating = within a controlled environment where all entities that may be = validating the Identity header have a common understanding on its = construction. >=20 > The second reason I think that future implementers would thank you for = guidance like this is to enable extensibility. Say we wanted to add = protection of Display Name - and in the SIP world this is very important = since endpoints will typically display only display name if it is = present, so provides a trivial way of bypassing human visual validation. = Today, that would be achieved by defining a new ppt that added this = field. Which is all well and good, but both the sender and the receiver = would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was = always included, then (and I=92m not saying this should necessarily be = baseline spec, since it=92s too big a change at this stage) a receiver = could validate the signature of the canon, rather than reconstructing = it, and then validate field-by-field for the fields it cares/knows = about. >=20 > Regards, > Alan >=20 >> On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: >>=20 >>=20 >> The more values there are in a SIP request that are candidates for = the identity of the caller, the more likely we are going to entertain = corner cases like this. There is no guarantee that the canonicalized = identity in the =46rom header field will be identical to one in PAI - = why carry PAI if it would be? - and similarly if there are multiple PAIs = there's no guarantee that they will all canonicalize to the same form. = Somehow, though, in those RFC3324 trust environments, you are supposed = to be able to know which PAI contains the identity that you care about = for this purpose, the identity of the originator of the call. STIR can't = tell you how to find that, only local trust domain policy can. I don't = think the burden is on STIR to make this unambiguous when apparently the = trust domains already can and do. >>=20 >> But, of course, when carrying the "canon" parameter, it will have one = value for the originating telephone number, say, and that will match the = canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your = trust domain should probably set a local policy of sending "canon" with = every call. I'm not sure there's much more to say about it than that in = the core specs, though. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> From: Christer Holmberg > >> Date: Monday, September 12, 2016 at 10:31 AM >> To: Jon Peterson >, "stir@ietf.org = " > >> Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>=20 >>> Hi, >>> =20 >>> Ok, maybe =93multiple identities=94 was the wrong wording. >>> =20 >>> My point was that, even if you know you should derive the identity = from PAI instead of From, you can have two P-Asserted-Identity header = fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >>> =20 >>> Regards, >>> =20 >>> Christer >>> =A0 <> >>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >>> Sent: 09 September 2016 20:11 >>> To: Christer Holmberg >; stir@ietf.org = >>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>> =20 >>> =20 >>> The only normative RECOMMEND in Section 8 is for cases "where local = policy canonicalizes the identity into a form different form how it = appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >>> =20 >>> If P-Asserted-Identity is present, surely that's where you should be = looking for identity information. As I've argued several times in the = past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >>> =20 >>> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >>> =20 >>> Jon Peterson >>> Neustar, Inc. >>> =20 >>> From: stir > on = behalf of Christer Holmberg > >>> Date: Friday, September 9, 2016 at 4:32 AM >>> To: "stir@ietf.org " > >>> Subject: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>> =20 >>>> Hi, >>>> =20 >>>> Section 8 of draft-4474bis says (or, that=92s at least my reading) = that, if the SIP request contains multiple identities (e.g. if the = request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>>> =20 >>>> Why is this only RECOMMENDED? If there are more than one identity, = shouldn=92t it be a MUST? I don=92t think we want the verifier to try = all identities, and see which one (if any) works, do we? >>>> =20 >>>> Now, the text DOES talk about =93local policy=94 when it comes to = choosing between =46rom and PAI for deriving the identity, so perhaps we = could say =93MUST, unless local policy defines from where the identity = is retrieved=94, or something like that=85 >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir = > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_0493295A-BCCF-4CB4-8649-746B6DDCCF81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Okay, got it.  Pity the poor blokes who have to DTMF = these extensions, but I get it.

So, what really is correct behavior here?  The call is = sent with an internal extension as a SIP URI, the mechanism tries to set = an Identity header, and what?

If it does not have a credential for = that TN, it shouldn=92t be trying to sign using a TN = credential.

If = it has a credential for the SIP ID, then the scope of that credential = wouldn=92t be a telephone number, it would be a domain, and the = recipient should be able to figure out what is happening.

Where is the = problem?

Brian

On Sep 15, 2016, at 2:40 PM, = Alan Ford <alan.ford@gmail.com> wrote:

Hi all,

I=92m involved in the = interop testing of early STIR implementations at Sipit, and we have = quickly run into issues around understanding how the sender has encoded = the source/destination. One person=92s tn: is another person=92s sip: = URI; the rules from the draft simply assume that any purely-numeric user = part is a telephone number, which is not always the case in the real = world. Without any context, when you call a numeric alias in another = domain, you have no idea whether this maps to a telephone number or a = SIP URI. If the receiver thinks it=92s a tn:, but the sender thinks it=92s= a SIP URI, then the Identity will not validate.

In short, I agree with Christer that = the canon is far more important than the draft suggests, and is needed = whenever there could be any ambiguity about how a sender has encoded (or = a receiver would encode) some of the data (which, frankly, is most B2B = scenarios).

Indeed, I would go probably further and suggest the canon = SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future = implementers would thank you for guidance like this is to enable = extensibility. Say we wanted to add protection of Display Name - and in = the SIP world this is very important since endpoints will typically = display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to = support this new ppt, and this is by no means guaranteed. So for maximum = compatibility what would a sender do? Should a sender include multiple = Identity headers of multiple ppts, hoping one is supported by the far = end? The overhead there would be huge. If canon was always included, = then (and I=92m not saying this should necessarily be baseline spec, = since it=92s too big a change at this stage) a receiver could validate = the signature of the canon, rather than reconstructing it, and then = validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 = Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP = request that are candidates for the identity of the caller, the more = likely we are going to entertain corner cases like this. There is no = guarantee that the canonicalized identity in the =46rom header field = will be identical to one in PAI - why carry PAI if it would be? - and = similarly if there are multiple PAIs there's no guarantee that they will = all canonicalize to the same form. Somehow, though, in those RFC3324 = trust environments, you are supposed to be able to know which PAI = contains the identity that you care about for this purpose, the identity = of the originator of the call. STIR can't tell you how to find that, = only local trust domain policy can. I don't think the burden is on STIR = to make this unambiguous when apparently the trust domains already can = and do.

But, of course, when carrying the "canon" parameter, it will = have one value for the originating telephone number, say, and that will = match the canonicalized form of one of those identities and not the = others. If your trust domain introduces this ambiguity into every call, = then your trust domain should probably set a local policy of sending = "canon" with every call. I'm not sure there's much more to say about it = than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple = identities=94 was the wrong wording.
 
My point was that, even = if you know you should derive the identity from PAI instead of From, you = can have two P-Asserted-Identity header fields, and as far as I = understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, = Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 = September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative = RECOMMEND in Section 8 is for cases "where local policy canonicalizes = the identity into a form different form how it appears in the =46rom = header field." That doesn't have anything to do with multiple = identities. The text in the previous sentence notes that it is talking = about a case where "the canonical identity derives from the = P-Asserted-Identity field rather than the =46rom header field," not a = case where identities based on both appear in different Identity = headers.
 
If P-Asserted-Identity is = present, surely that's where you should be looking for identity = information. As I've argued several times in the past, this is no more = or less ambiguous than the practical use of P-Asserted-Identity in the = field today: nothing about the request tells you "use PAI instead of = From" other than the presence of PAI. Because of all the RFC3324 trust = domain stuff that Mark Watson talked us into back in the day, it's hard = to say anything more than that it's a matter of local policy, as nothing = about the protocol tells you whether or not you are in an RFC3324 trust = domain. Thus far, I gather this hasn't impeded the adoption of PAI. I = did ask the WG in Berlin if we should include some more explicit = indicator that would tell you that an Identity header came from PAI = rather than From, and the consensus was not to.
 
We are largely punting on = why you might have multiple Identity headers present in the same = request: this is included for forward compatibility. The most likely use = cases are ones where extensions will differentiate the Identity headers. = The recommendation to include "canon" here just enables some potential = implementation optimizations (e.g. Verifier canonicalizes the identity = in PAI, then compares to value in "canon" to save cycles before = computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only = RECOMMENDED? If there are more than one identity, shouldn=92t it be a = MUST? I don=92t think we want the verifier to try all identities, and = see which one (if any) works, do we?
 
Now, the text DOES talk = about =93local policy=94 when it comes to choosing between =46rom and = PAI for deriving the identity, so perhaps we could say =93MUST, unless = local policy defines from where the identity is retrieved=94, or = something like that=85
 
Regards,
 
Christer
<= /div>
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_0493295A-BCCF-4CB4-8649-746B6DDCCF81-- From nobody Thu Sep 15 12:06:34 2016 Return-Path: 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 4059212B346 for ; Thu, 15 Sep 2016 12:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 APtWuNZtuDB6 for ; Thu, 15 Sep 2016 12:06:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF5C12B356 for ; Thu, 15 Sep 2016 12:06:26 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id w204so66298615qka.0 for ; Thu, 15 Sep 2016 12:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tOT3Wme+IX90ThyArsL7o0DKS0z4fjYEKQmo73dWWaM=; b=CA+yc5CgrLfT91/ld3Z/zljMCeAyiZUbtqk/C2xlBlvLzt3YhvYEv+2YPb6zg35A0b UvuH7LkBRGwevWtJl6iXQu4LKJbuuRmc9tGFvezDS4HpQ58PQeB7J3abmseEEFuAFfXS TGJKTLZ0qBuVK3vwpw8YyMw6LI1bano1Eg5nPe6a2dUuY2fpEi7tktRbvhFZGrXg8Om1 R5wot4qB8GdHQExpYYH8mxRRfobaZx0rvmrzg7X4i8roStVVL+NB25TqE7O5aDdgRADO kYuFq/krEY/P9dOArTwcyiW66Ms0pp0JQv50/8l7nTgynLJY/6pNU99Sc4PJNx9Z5TwK TBtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tOT3Wme+IX90ThyArsL7o0DKS0z4fjYEKQmo73dWWaM=; b=IfXn4lrQdu4WkCHN7goqxtceSknmSfJQIPf3/au2AhIgWEEXDKZn+1Y7d7wfpl9L8V hDZjw/hAm4bpcBABFGpdvAjAet/67xnV3gCAcJopGiXmBbYZFbhSSliGRJi5pSm9cdsI GoEPuxBHpjyVzIefvtsoOZj8vcVVmEoVDjGK+tafaBtZV1ssCfJctZ9u+1sqSCx7ZZw/ iYIJY0gbtn8nKPczrvGjOZHWFeqoBrr2y44/7nsGhyeFjobYnC9N92BJQOWYP5nyuEDd F7Oz1XNufRxMf2z3T0kQa0V06HxszbugKB3G1w3bpFN+SQg6+aq19e5b5b3wvBJAl6z4 zE4g== X-Gm-Message-State: AE9vXwOCy8NedSHYZexodhhI2Rvr6hcGNQgUgBLCUybPWGoYp3+wDB+9ylg25F2cPp9dyA== X-Received: by 10.55.9.132 with SMTP id 126mr11074736qkj.234.1473966385769; Thu, 15 Sep 2016 12:06:25 -0700 (PDT) Received: from ?IPv6:2606:4100:3880:2520:29a7:505a:ef46:214b? ([2606:4100:3880:2520:29a7:505a:ef46:214b]) by smtp.gmail.com with ESMTPSA id h46sm2608386qte.21.2016.09.15.12.06.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 12:06:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C5C8BC9-84E8-40CA-8CB4-FCB1905852A4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> Date: Thu, 15 Sep 2016 20:06:28 +0100 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , "Peterson, Jon" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 19:06:32 -0000 --Apple-Mail=_0C5C8BC9-84E8-40CA-8CB4-FCB1905852A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Brian, The problem is on the receiving end. I see a number as the source or = destination, and decide it=92s a tn: so try to construct a passport = object with a tn: and validate it as such, but this fails. This is = because the sender sent it as a sip: URI instead. But because there=92s = no canon, I don=92t know how to reconstruct the passport so can=92t = validate. Regards, Alan > On 15 Sep 2016, at 20:01, Brian Rosen wrote: >=20 > Okay, got it. Pity the poor blokes who have to DTMF these extensions, = but I get it. >=20 > So, what really is correct behavior here? The call is sent with an = internal extension as a SIP URI, the mechanism tries to set an Identity = header, and what? >=20 > If it does not have a credential for that TN, it shouldn=92t be trying = to sign using a TN credential. >=20 > If it has a credential for the SIP ID, then the scope of that = credential wouldn=92t be a telephone number, it would be a domain, and = the recipient should be able to figure out what is happening. >=20 > Where is the problem? >=20 > Brian >=20 >> On Sep 15, 2016, at 2:40 PM, Alan Ford > wrote: >>=20 >> Hi all, >>=20 >> I=92m involved in the interop testing of early STIR implementations = at Sipit, and we have quickly run into issues around understanding how = the sender has encoded the source/destination. One person=92s tn: is = another person=92s sip: URI; the rules from the draft simply assume that = any purely-numeric user part is a telephone number, which is not always = the case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not validate. >>=20 >> In short, I agree with Christer that the canon is far more important = than the draft suggests, and is needed whenever there could be any = ambiguity about how a sender has encoded (or a receiver would encode) = some of the data (which, frankly, is most B2B scenarios). >>=20 >> Indeed, I would go probably further and suggest the canon SHOULD = always be included, - i.e. MUST, unless it is known to be operating = within a controlled environment where all entities that may be = validating the Identity header have a common understanding on its = construction. >>=20 >> The second reason I think that future implementers would thank you = for guidance like this is to enable extensibility. Say we wanted to add = protection of Display Name - and in the SIP world this is very important = since endpoints will typically display only display name if it is = present, so provides a trivial way of bypassing human visual validation. = Today, that would be achieved by defining a new ppt that added this = field. Which is all well and good, but both the sender and the receiver = would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was = always included, then (and I=92m not saying this should necessarily be = baseline spec, since it=92s too big a change at this stage) a receiver = could validate the signature of the canon, rather than reconstructing = it, and then validate field-by-field for the fields it cares/knows = about. >>=20 >> Regards, >> Alan >>=20 >>> On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: >>>=20 >>>=20 >>> The more values there are in a SIP request that are candidates for = the identity of the caller, the more likely we are going to entertain = corner cases like this. There is no guarantee that the canonicalized = identity in the =46rom header field will be identical to one in PAI - = why carry PAI if it would be? - and similarly if there are multiple PAIs = there's no guarantee that they will all canonicalize to the same form. = Somehow, though, in those RFC3324 trust environments, you are supposed = to be able to know which PAI contains the identity that you care about = for this purpose, the identity of the originator of the call. STIR can't = tell you how to find that, only local trust domain policy can. I don't = think the burden is on STIR to make this unambiguous when apparently the = trust domains already can and do. >>>=20 >>> But, of course, when carrying the "canon" parameter, it will have = one value for the originating telephone number, say, and that will match = the canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your = trust domain should probably set a local policy of sending "canon" with = every call. I'm not sure there's much more to say about it than that in = the core specs, though. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> From: Christer Holmberg > >>> Date: Monday, September 12, 2016 at 10:31 AM >>> To: Jon Peterson >, "stir@ietf.org = " > >>> Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>=20 >>>> Hi, >>>> =20 >>>> Ok, maybe =93multiple identities=94 was the wrong wording. >>>> =20 >>>> My point was that, even if you know you should derive the identity = from PAI instead of From, you can have two P-Asserted-Identity header = fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >>>> =20 >>>> Regards, >>>> =20 >>>> Christer >>>> =A0 <> >>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >>>> Sent: 09 September 2016 20:11 >>>> To: Christer Holmberg >; stir@ietf.org = >>>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>> =20 >>>> =20 >>>> The only normative RECOMMEND in Section 8 is for cases "where local = policy canonicalizes the identity into a form different form how it = appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >>>> =20 >>>> If P-Asserted-Identity is present, surely that's where you should = be looking for identity information. As I've argued several times in the = past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >>>> =20 >>>> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >>>> =20 >>>> Jon Peterson >>>> Neustar, Inc. >>>> =20 >>>> From: stir > = on behalf of Christer Holmberg > >>>> Date: Friday, September 9, 2016 at 4:32 AM >>>> To: "stir@ietf.org " > >>>> Subject: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>> =20 >>>>> Hi, >>>>> =20 >>>>> Section 8 of draft-4474bis says (or, that=92s at least my reading) = that, if the SIP request contains multiple identities (e.g. if the = request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>>>> =20 >>>>> Why is this only RECOMMENDED? If there are more than one identity, = shouldn=92t it be a MUST? I don=92t think we want the verifier to try = all identities, and see which one (if any) works, do we? >>>>> =20 >>>>> Now, the text DOES talk about =93local policy=94 when it comes to = choosing between =46rom and PAI for deriving the identity, so perhaps we = could say =93MUST, unless local policy defines from where the identity = is retrieved=94, or something like that=85 >>>>> =20 >>>>> Regards, >>>>> =20 >>>>> Christer >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir = >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_0C5C8BC9-84E8-40CA-8CB4-FCB1905852A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Brian,

The problem is on the receiving end. I see a number as the = source or destination, and decide it=92s a tn: so try to construct a = passport object with a tn: and validate it as such, but this fails. This = is because the sender sent it as a sip: URI instead. But because there=92s= no canon, I don=92t know how to reconstruct the passport so can=92t = validate.

Regards,
Alan

On = 15 Sep 2016, at 20:01, Brian Rosen <br@brianrosen.net> = wrote:

Okay, got it. =  Pity the poor blokes who have to DTMF these extensions, but I get = it.

So, what really = is correct behavior here?  The call is sent with an internal = extension as a SIP URI, the mechanism tries to set an Identity header, = and what?

If = it does not have a credential for that TN, it shouldn=92t be trying to = sign using a TN credential.

If it has a credential for the SIP ID, then the scope of = that credential wouldn=92t be a telephone number, it would be a domain, = and the recipient should be able to figure out what is = happening.

Where= is the problem?

Brian

On Sep = 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com> wrote:

Hi all,

I=92m involved in the = interop testing of early STIR implementations at Sipit, and we have = quickly run into issues around understanding how the sender has encoded = the source/destination. One person=92s tn: is another person=92s sip: = URI; the rules from the draft simply assume that any purely-numeric user = part is a telephone number, which is not always the case in the real = world. Without any context, when you call a numeric alias in another = domain, you have no idea whether this maps to a telephone number or a = SIP URI. If the receiver thinks it=92s a tn:, but the sender thinks it=92s= a SIP URI, then the Identity will not validate.

In short, I agree with Christer that = the canon is far more important than the draft suggests, and is needed = whenever there could be any ambiguity about how a sender has encoded (or = a receiver would encode) some of the data (which, frankly, is most B2B = scenarios).

Indeed, I would go probably further and suggest the canon = SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future = implementers would thank you for guidance like this is to enable = extensibility. Say we wanted to add protection of Display Name - and in = the SIP world this is very important since endpoints will typically = display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to = support this new ppt, and this is by no means guaranteed. So for maximum = compatibility what would a sender do? Should a sender include multiple = Identity headers of multiple ppts, hoping one is supported by the far = end? The overhead there would be huge. If canon was always included, = then (and I=92m not saying this should necessarily be baseline spec, = since it=92s too big a change at this stage) a receiver could validate = the signature of the canon, rather than reconstructing it, and then = validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 = Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP = request that are candidates for the identity of the caller, the more = likely we are going to entertain corner cases like this. There is no = guarantee that the canonicalized identity in the =46rom header field = will be identical to one in PAI - why carry PAI if it would be? - and = similarly if there are multiple PAIs there's no guarantee that they will = all canonicalize to the same form. Somehow, though, in those RFC3324 = trust environments, you are supposed to be able to know which PAI = contains the identity that you care about for this purpose, the identity = of the originator of the call. STIR can't tell you how to find that, = only local trust domain policy can. I don't think the burden is on STIR = to make this unambiguous when apparently the trust domains already can = and do.

But, of course, when carrying the "canon" parameter, it will = have one value for the originating telephone number, say, and that will = match the canonicalized form of one of those identities and not the = others. If your trust domain introduces this ambiguity into every call, = then your trust domain should probably set a local policy of sending = "canon" with every call. I'm not sure there's much more to say about it = than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple = identities=94 was the wrong wording.
 
My point was that, even = if you know you should derive the identity from PAI instead of From, you = can have two P-Asserted-Identity header fields, and as far as I = understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, = Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 = September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative = RECOMMEND in Section 8 is for cases "where local policy canonicalizes = the identity into a form different form how it appears in the =46rom = header field." That doesn't have anything to do with multiple = identities. The text in the previous sentence notes that it is talking = about a case where "the canonical identity derives from the = P-Asserted-Identity field rather than the =46rom header field," not a = case where identities based on both appear in different Identity = headers.
 
If P-Asserted-Identity is = present, surely that's where you should be looking for identity = information. As I've argued several times in the past, this is no more = or less ambiguous than the practical use of P-Asserted-Identity in the = field today: nothing about the request tells you "use PAI instead of = From" other than the presence of PAI. Because of all the RFC3324 trust = domain stuff that Mark Watson talked us into back in the day, it's hard = to say anything more than that it's a matter of local policy, as nothing = about the protocol tells you whether or not you are in an RFC3324 trust = domain. Thus far, I gather this hasn't impeded the adoption of PAI. I = did ask the WG in Berlin if we should include some more explicit = indicator that would tell you that an Identity header came from PAI = rather than From, and the consensus was not to.
 
We are largely punting on = why you might have multiple Identity headers present in the same = request: this is included for forward compatibility. The most likely use = cases are ones where extensions will differentiate the Identity headers. = The recommendation to include "canon" here just enables some potential = implementation optimizations (e.g. Verifier canonicalizes the identity = in PAI, then compares to value in "canon" to save cycles before = computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only = RECOMMENDED? If there are more than one identity, shouldn=92t it be a = MUST? I don=92t think we want the verifier to try all identities, and = see which one (if any) works, do we?
 
Now, the text DOES talk = about =93local policy=94 when it comes to choosing between =46rom and = PAI for deriving the identity, so perhaps we could say =93MUST, unless = local policy defines from where the identity is retrieved=94, or = something like that=85
 
Regards,
 
Christer
<= /div>
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


= --Apple-Mail=_0C5C8BC9-84E8-40CA-8CB4-FCB1905852A4-- From nobody Thu Sep 15 13:51:56 2016 Return-Path: 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 E81C812B107 for ; Thu, 15 Sep 2016 13:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 hzZnllG360vV for ; Thu, 15 Sep 2016 13:51:52 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D59812B02C for ; Thu, 15 Sep 2016 13:51:52 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8FKh9XG021356; Thu, 15 Sep 2016 16:51:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=QXAiYO3GS6ZMUmBef3zLIhB7gWyXmuFgba8uWo9Usn0=; b=mmrN44ONRWuxlT/s/akBN8IJi/8ciCcRowuioMl9ue2nUiojMyOI6K/T59yFgsrq+ylt iCsl8Zzo5f1qn9SiLzmxxkOV3riQtGfmwahUmaQO2DzigIqPuoWjtNBiVcJJNnEn7S5Q bQQqUICRjzIPeiM4oVajJwrCs83A/x2HAUVRBbnfZyMeZRwAIQXxALVtDcOkcsI3c+XD 1xFUo+so7kgK8dw5lEKkADuFavX48QNhYtXCgYSlhqpAAx5PX+zIIAibUEMcXs2bDfGy 8zhtj5ur44ezFcARKTfScstqTGEPeMwPvbHKGRAtl+0Y365pnaozmUzZt0ptsUj930Bv jg== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25ce9qkjgb-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Sep 2016 16:51:45 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 15 Sep 2016 16:51:43 -0400 From: "Peterson, Jon" To: Alan Ford , Brian Rosen Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAA1l8gIAABekAgAABcQD//6g2gA== Date: Thu, 15 Sep 2016 20:51:42 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.120] Content-Type: multipart/alternative; boundary="_000_D4004AA81B3224jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-15_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609150275 Archived-At: Cc: "stir@ietf.org" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 20:51:56 -0000 --_000_D4004AA81B3224jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't think I agree with either the framing of the problem or the propose= d solution here (for the first problem in Alan's mail); but to dig in to th= is, we need to go back to the first principles of canonicalizing phone numb= ers. A From identity (or a PAI identity) is expected to contain an address-of-re= cord of the originator of the request. If some really unhelpful URI that is= only resolvable locally is used as the From, then we should expect there t= o be problems in ordinary SIP operations if the request escapes that local = environment. The whole point of including an AoR as your public identity is= that someone who sees it can dereference it, and through standard routing = procedures (in baseline SIP we mean RFC3263) you'll end up reaching the rig= ht user agents(). If you aren't operating within those constraints, I don't= think that's really something that RFC4474bis can fix. A To identity expresses the AoR you are trying to reach. We already have a = split in baseline SIP between the To and the Request-URI, because SIP recog= nizes that the target of a request is likely to be dynamic: in baseline SIP= , the To is supposed to be immutable, and the Request-URI is supposed to su= pport hard changes. When it comes to rfc4474bis, the idea of having both sides run their own in= dependent canonicalization of the telephone number arose because deployment= experience suggests that intermediaries in fact modify telephone numbers i= n transit in various ways, be they found in the To and From header field va= lues or wherever else. This meddling includes thing like removing visual se= parators, but also includes adding and subtracting suffixes and prefixes as= necessary to render the telephone number or URI there globally reachable a= nd meaningful. Or in some cases, it includes nulling them out entirely beca= use some other header (like PAI) is doing their job in a way that the inter= mediary likes better. Nothing that we do on the originating side will preve= nt intermediaries that want to alter these numbers form doing so -- includi= ng sticking them in a PASSporT object we tunnel in the SIP request. All tha= t would do is encourage those intermediaries to change the numbers in the P= ASSporT object too. Like, years ago, we entertained just having a new SIP h= eader field that would contain the canonical number as the authentication s= ervice saw it - but merely adding another field cannot get around the inter= mediaries: they will know it's there and they will do what they want to it.= "canon" has no magic powers that would save it from the same fate. At the end of the day, if you are on the receiving side, you are left to in= spect whatever is left after intermediaries get through with the message. T= his remains one of the most important reasons that "canon" (which now means= carrying the header and payload PASSporT objects) is optional: the philoso= phy behind canonicalization is that what matters isn't some value that the = authentication service mandates, but instead how the two sides understand t= he numbers as they receive them. The originating side may initially direct = the request to some local seven digital telephone number: but by the time t= hat gets to the terminating side, a country code and area code might be add= ed to it. They both "mean" the same number, and the authentication service = that signs the request exercises the canonicalization process in order to c= apture what it thinks the originator "meant" for the global environment. Moreover, to your specific argument, here's the rub: because this is a secu= rity function, carrying the canonical value in "canon" cannot really help u= nless the verification service already knows how to turn the value already = in the From (or PAI or whatever) into the canonical value anyway. Why not? = Because if I get a From with "sip:0020121421@example.com" and the PASSporT = object in canon says the orig is a tn value "12012142102", how is the verif= ication service supposed to know whether or not this is a cut-and-paste att= ack? If the verification service just blindly trusted that the contents of = the PASSporT object's orig were equivalent to the URI in the From, it would= never be able to tell whether or not the PASSporT object actually belonged= with this call. The value of "canon" is only there for debugging and optim= ization purposes, we say this many times in the spec. It is NOT there to tu= nnel some "secret" value for the telephone number between the authenticatio= n service and verification service, as that would be a huge security hole. = And it wouldn't work anyway because as I said above intermediaries could ju= st change it. The neat thing about not including "canon" is that intermedia= ries can't change something that isn't in the message. This was effectively= the argument Hadriel and others made back in the day. You can argue that the verification service will sometimes not have suffici= ent information to arrive at the same canonicalization as the authenticatio= n service, and I agree. In some cases it won't: like when calls escape from= really opaque private branches, or in if one end is in some weird variable= -length dialing plan, or if a nationally-specific service number is used, o= r whatever. I just think that in order for those calls to realistically get= routed and expect identity to work, they need to express identifiers in a = way that is actually useful to the rest of the world. We formerly had some = text in rfc4474bis that recommended (against the normative guidance of RFC3= 261, incidentally) that authentication services alter the To and From heade= r fields to conform with the canonicalizations that they performed if those= changes warranted notice. Ultimately, though, I took that out because the = potential intermediary interference after the fact makes it moot. The quest= ion is not whether the verification service trusts the bits the authenticat= ion service claims it saw, the question is whether or not the verification = service can derive an identity equal to that from the values it sees in the= SIP request. Ultimately, implementations need to use numbers in a sane way in order to h= ave any expectation that SIP will work. In those cases where the use of num= bers is sane enough that SIP will work, then I think Identity will probably= work too. Jon Peterson Neustar, Inc. From: Alan Ford > Date: Thursday, September 15, 2016 at 12:06 PM To: Brian Rosen > Cc: Jon Peterson = >, "stir@ietf.org" >, Christer Holmberg > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi Brian, The problem is on the receiving end. I see a number as the source or destin= ation, and decide it=92s a tn: so try to construct a passport object with a= tn: and validate it as such, but this fails. This is because the sender se= nt it as a sip: URI instead. But because there=92s no canon, I don=92t know= how to reconstruct the passport so can=92t validate. Regards, Alan On 15 Sep 2016, at 20:01, Brian Rosen > wrote: Okay, got it. Pity the poor blokes who have to DTMF these extensions, but = I get it. So, what really is correct behavior here? The call is sent with an interna= l extension as a SIP URI, the mechanism tries to set an Identity header, an= d what? If it does not have a credential for that TN, it shouldn=92t be trying to s= ign using a TN credential. If it has a credential for the SIP ID, then the scope of that credential wo= uldn=92t be a telephone number, it would be a domain, and the recipient sho= uld be able to figure out what is happening. Where is the problem? Brian On Sep 15, 2016, at 2:40 PM, Alan Ford > wrote: Hi all, I=92m involved in the interop testing of early STIR implementations at Sipi= t, and we have quickly run into issues around understanding how the sender = has encoded the source/destination. One person=92s tn: is another person=92= s sip: URI; the rules from the draft simply assume that any purely-numeric = user part is a telephone number, which is not always the case in the real w= orld. Without any context, when you call a numeric alias in another domain,= you have no idea whether this maps to a telephone number or a SIP URI. If = the receiver thinks it=92s a tn:, but the sender thinks it=92s a SIP URI, t= hen the Identity will not validate. In short, I agree with Christer that the canon is far more important than t= he draft suggests, and is needed whenever there could be any ambiguity abou= t how a sender has encoded (or a receiver would encode) some of the data (w= hich, frankly, is most B2B scenarios). Indeed, I would go probably further and suggest the canon SHOULD always be = included, - i.e. MUST, unless it is known to be operating within a controll= ed environment where all entities that may be validating the Identity heade= r have a common understanding on its construction. The second reason I think that future implementers would thank you for guid= ance like this is to enable extensibility. Say we wanted to add protection = of Display Name - and in the SIP world this is very important since endpoin= ts will typically display only display name if it is present, so provides a= trivial way of bypassing human visual validation. Today, that would be ach= ieved by defining a new ppt that added this field. Which is all well and go= od, but both the sender and the receiver would need to support this new ppt= , and this is by no means guaranteed. So for maximum compatibility what wou= ld a sender do? Should a sender include multiple Identity headers of multip= le ppts, hoping one is supported by the far end? The overhead there would b= e huge. If canon was always included, then (and I=92m not saying this shoul= d necessarily be baseline spec, since it=92s too big a change at this stage= ) a receiver could validate the signature of the canon, rather than reconst= ructing it, and then validate field-by-field for the fields it cares/knows = about. Regards, Alan On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: The more values there are in a SIP request that are candidates for the iden= tity of the caller, the more likely we are going to entertain corner cases = like this. There is no guarantee that the canonicalized identity in the Fro= m header field will be identical to one in PAI - why carry PAI if it would = be? - and similarly if there are multiple PAIs there's no guarantee that th= ey will all canonicalize to the same form. Somehow, though, in those RFC332= 4 trust environments, you are supposed to be able to know which PAI contain= s the identity that you care about for this purpose, the identity of the or= iginator of the call. STIR can't tell you how to find that, only local trus= t domain policy can. I don't think the burden is on STIR to make this unamb= iguous when apparently the trust domains already can and do. But, of course, when carrying the "canon" parameter, it will have one value= for the originating telephone number, say, and that will match the canonic= alized form of one of those identities and not the others. If your trust do= main introduces this ambiguity into every call, then your trust domain shou= ld probably set a local policy of sending "canon" with every call. I'm not = sure there's much more to say about it than that in the core specs, though. Jon Peterson Neustar, Inc. From: Christer Holmberg > Date: Monday, September 12, 2016 at 10:31 AM To: Jon Peterson = >, "stir@ietf.org" > Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Ok, maybe =93multiple identities=94 was the wrong wording. My point was that, even if you know you should derive the identity from PAI= instead of From, you can have two P-Asserted-Identity header fields, and a= s far as I understand there is no guarantee that the canonicalized form of = those match. Regards, Christer From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 09 September 2016 20:11 To: Christer Holmberg >; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? The only normative RECOMMEND in Section 8 is for cases "where local policy = canonicalizes the identity into a form different form how it appears in the= From header field." That doesn't have anything to do with multiple identit= ies. The text in the previous sentence notes that it is talking about a cas= e where "the canonical identity derives from the P-Asserted-Identity field = rather than the From header field," not a case where identities based on bo= th appear in different Identity headers. If P-Asserted-Identity is present, surely that's where you should be lookin= g for identity information. As I've argued several times in the past, this = is no more or less ambiguous than the practical use of P-Asserted-Identity = in the field today: nothing about the request tells you "use PAI instead of= From" other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say= anything more than that it's a matter of local policy, as nothing about th= e protocol tells you whether or not you are in an RFC3324 trust domain. Thu= s far, I gather this hasn't impeded the adoption of PAI. I did ask the WG i= n Berlin if we should include some more explicit indicator that would tell = you that an Identity header came from PAI rather than From, and the consens= us was not to. We are largely punting on why you might have multiple Identity headers pres= ent in the same request: this is included for forward compatibility. The mo= st likely use cases are ones where extensions will differentiate the Identi= ty headers. The recommendation to include "canon" here just enables some po= tential implementation optimizations (e.g. Verifier canonicalizes the ident= ity in PAI, then compares to value in "canon" to save cycles before computi= ng the identity string and checking for breakage). Jon Peterson Neustar, Inc. From: stir > on behalf = of Christer Holmberg > Date: Friday, September 9, 2016 at 4:32 AM To: "stir@ietf.org" > Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Section 8 of draft-4474bis says (or, that=92s at least my reading) that, if= the SIP request contains multiple identities (e.g. if the request in addit= ion to the From header field contains one or more P-Asserted-Identity heade= r fields), it is RECOMMENDED to include =93canon=94, so that the verifier k= nows which identity to verify. Why is this only RECOMMENDED? If there are more than one identity, shouldn= =92t it be a MUST? I don=92t think we want the verifier to try all identiti= es, and see which one (if any) works, do we? Now, the text DOES talk about =93local policy=94 when it comes to choosing = between From and PAI for deriving the identity, so perhaps we could say =93= MUST, unless local policy defines from where the identity is retrieved=94, = or something like that=85 Regards, Christer _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_D4004AA81B3224jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I don't think I agree with either the framing of the problem or the pr= oposed solution here (for the first problem in Alan's mail); but to dig in = to this, we need to go back to the first principles of canonicalizing phone= numbers.

A From identity (or a PAI identity) is expected to contain an address-= of-record of the originator of the request. If some really unhelpful URI th= at is only resolvable locally is used as the From, then we should expect th= ere to be problems in ordinary SIP operations if the request escapes that local environment. The whole point = of including an AoR as your public identity is that someone who sees it can= dereference it, and through standard routing procedures (in baseline SIP w= e mean RFC3263) you'll end up reaching the right user agents(). If you aren't operating within those constraints,= I don't think that's really something that RFC4474bis can fix.

A To identity expresses the AoR you are trying to reach. We already ha= ve a split in baseline SIP between the To and the Request-URI, because SIP = recognizes that the target of a request is likely to be dynamic: in baselin= e SIP, the To is supposed to be immutable, and the Request-URI is supposed to support hard changes.

When it comes to rfc4474bis, the idea of having both sides run their o= wn independent canonicalization of the telephone number arose because deplo= yment experience suggests that intermediaries in fact modify telephone numb= ers in transit in various ways, be they found in the To and From header field values or wherever else. Thi= s meddling includes thing like removing visual separators, but also include= s adding and subtracting suffixes and prefixes as necessary to render the t= elephone number or URI there globally reachable and meaningful. Or in some cases, it includes nulling them out e= ntirely because some other header (like PAI) is doing their job in a way th= at the intermediary likes better. Nothing that we do on the originating sid= e will prevent intermediaries that want to alter these numbers form doing so -- including sticking them in a = PASSporT object we tunnel in the SIP request. All that would do is encourag= e those intermediaries to change the numbers in the PASSporT object too. Li= ke, years ago, we entertained just having a new SIP header field that would contain the canonical number as t= he authentication service saw it - but merely adding another field cannot g= et around the intermediaries: they will know it's there and they will do wh= at they want to it. "canon" has no magic powers that would save it from the same fate.

At the end of the day, if you are on the receiving side, you are left = to inspect whatever is left after intermediaries get through with the messa= ge. This remains one of the most important reasons that "canon" (= which now means carrying the header and payload PASSporT objects) is optional: the philosophy behind canonicalization is t= hat what matters isn't some value that the authentication service mandates,= but instead how the two sides understand the numbers as they receive them.= The originating side may initially direct the request to some local seven digital telephone number: but by th= e time that gets to the terminating side, a country code and area code migh= t be added to it. They both "mean" the same number, and the authe= ntication service that signs the request exercises the canonicalization process in order to capture what it thinks the origin= ator "meant" for the global environment.

Moreover, to your specific argument, here's the rub: because this is a= security function, carrying the canonical value in "canon" canno= t really help unless the verification service already knows how to turn the= value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a From with &qu= ot;sip:0020121421@example.com" and the PASSporT object in canon says t= he orig is a tn value "12012142102", how is the verification serv= ice supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the contents= of the PASSporT object's orig were equivalent to the URI in the From, it w= ould never be able to tell whether or not the PASSporT object actually belo= nged with this call. The value of "canon" is only there for debugging and optimization purposes, w= e say this many times in the spec. It is NOT there to tunnel some "sec= ret" value for the telephone number between the authentication service= and verification service, as that would be a huge security hole. And it wouldn't work anyway because as I said above intermediaries c= ould just change it. The neat thing about not including "canon" i= s that intermediaries can't change something that isn't in the message. Thi= s was effectively the argument Hadriel and others made back in the day.

You can argue that the verification service will sometimes not have su= fficient information to arrive at the same canonicalization as the authenti= cation service, and I agree. In some cases it won't: like when calls escape= from really opaque private branches, or in if one end is in some weird variable-length dialing plan, or if a na= tionally-specific service number is used, or whatever. I just think that in= order for those calls to realistically get routed and expect identity to w= ork, they need to express identifiers in a way that is actually useful to the rest of the world. We formerly had= some text in rfc4474bis that recommended (against the normative guidance o= f RFC3261, incidentally) that authentication services alter the To and From= header fields to conform with the canonicalizations that they performed if those changes warranted notice. U= ltimately, though, I took that out because the potential intermediary inter= ference after the fact makes it moot. The question is not whether the verif= ication service trusts the bits the authentication service claims it saw, the question is whether or not t= he verification service can derive an identity equal to that from the value= s it sees in the SIP request.

Ultimately, implementations need to use numbers in a sane way in order= to have any expectation that SIP will work. In those cases where the use o= f numbers is sane enough that SIP will work, then I think Identity will pro= bably work too.

Jon Peterson
Neustar, Inc.

From: Alan Ford <alan.ford@gmail.com>
Date: Thursday, September 15, 2016 = at 12:06 PM
To: Brian Rosen <br@brianrosen.net>
Cc: Jon Peterson <jon.peterson@neustar.biz>, "stir@ietf.org" <stir@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com> Subject: Re: [stir] 4474bis: Why on= ly RECOMMEND when multiple identities?

Hi Brian,

The problem is on the receiving end. I see a number as the = source or destination, and decide it=92s a tn: so try to construct a passpo= rt object with a tn: and validate it as such, but this fails. This is becau= se the sender sent it as a sip: URI instead. But because there=92s no canon, I don=92t know how to reconstruct= the passport so can=92t validate.

Regards,
Alan

On 15 Sep 2016, at 20:01, Brian Rosen <br@brianrosen.net> wrote:

Okay, got it.  Pity the poor blokes who have to DTMF these extensions,= but I get it.

So, what really is correct behavior here?  The call is= sent with an internal extension as a SIP URI, the mechanism tries to set a= n Identity header, and what?

If it does not have a credential for that TN, it shouldn=92= t be trying to sign using a TN credential.

If it has a credential for the SIP ID, then the scope of th= at credential wouldn=92t be a telephone number, it would be a domain, and t= he recipient should be able to figure out what is happening.

Where is the problem?

Brian

On Sep 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com> wrote:

Hi all,

I=92m involved in the interop testing of early STIR impleme= ntations at Sipit, and we have quickly run into issues around understanding= how the sender has encoded the source/destination. One person=92s tn: is a= nother person=92s sip: URI; the rules from the draft simply assume that any purely-numeric user part is a telephone n= umber, which is not always the case in the real world. Without any context,= when you call a numeric alias in another domain, you have no idea whether = this maps to a telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but the sender thinks i= t=92s a SIP URI, then the Identity will not validate.

In short, I agree with Christer that the canon is far more = important than the draft suggests, and is needed whenever there could be an= y ambiguity about how a sender has encoded (or a receiver would encode) som= e of the data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and suggest the canon S= HOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment whe= re all entities that may be validating the Identity header have a common un= derstanding on its construction.

The second reason I think that future implementers would th= ank you for guidance like this is to enable extensibility. Say we wanted to= add protection of Display Name - and in the SIP world this is very importa= nt since endpoints will typically display only display name if it is present, so prov= ides a trivial way of bypassing human visual validation. Today, that would = be achieved by defining a new ppt that added this field. Which is all well = and good, but both the sender and the receiver would need to support this new ppt, and this is by no means guaranteed. So= for maximum compatibility what would a sender do? Should a sender include = multiple Identity headers of multiple ppts, hoping one is supported by the = far end? The overhead there would be huge. If canon was always included, then (and I=92m not saying this sho= uld necessarily be baseline spec, since it=92s too big a change at this sta= ge) a receiver could validate the signature of the canon, rather than recon= structing it, and then validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wr= ote:


The more values there are in a SIP request that are candidates for the iden= tity of the caller, the more likely we are going to entertain corner cases = like this. There is no guarantee that the canonicalized identity in the Fro= m header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there are= multiple PAIs there's no guarantee that they will all canonicalize to the = same form. Somehow, though, in those RFC3324 trust environments, you are su= pposed to be able to know which PAI contains the identity that you care about for this purpose, the identi= ty of the originator of the call. STIR can't tell you how to find that, onl= y local trust domain policy can. I don't think the burden is on STIR to mak= e this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will have= one value for the originating telephone number, say, and that will match t= he canonicalized form of one of those identities and not the others. If you= r trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy of s= ending "canon" with every call. I'm not sure there's much more to= say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Monday, September 12, 2016 at 10:31 AM To: Jon Peterson <jon.peterson@neustar.biz>, "stir@i= etf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: Why only RECOMMEND= when multiple identities?

Hi,
 
Ok, maybe =93multiple identities=94 was the wro= ng wording.
 
My point was that, even if you know you should = derive the identity from PAI instead of From, you can have two P-Asserted-I= dentity header fields, and as far as I understand there is no guarantee that the canonicalized form of those ma= tch.
 
Regards,
 
Christer
 
From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
Sent: 0= 9 September 2016 20:11
To: Chr= ister Holmberg <christer.holmber= g@ericsson.com>; <= a href=3D"mailto:stir@ietf.org" style=3D"color: purple; text-decoration: un= derline;" class=3D"">stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?
 
 
The only normative RECOMMEND in Section 8 is for cases "where lo= cal policy canonicalizes the identity into a form different form how it app= ears in the From header field." That doesn't have anything to do with multiple identities. The text in the previous sen= tence notes that it is talking about a case where "the canonical ident= ity derives from the P-Asserted-Identity field rather than the From header = field," not a case where identities based on both appear in different Identity headers.=
 
If P-Asserted-Identity is present, surely that's where you should be = looking for identity information. As I've argued several times in the past,= this is no more or less ambiguous than the practical use of P-Asserted-Identity in the field today: nothing about= the request tells you "use PAI instead of From" other than the p= resence of PAI. Because of all the RFC3324 trust domain stuff that Mark Wat= son talked us into back in the day, it's hard to say anything more than that it's a matter of local policy, as nothing a= bout the protocol tells you whether or not you are in an RFC3324 trust doma= in. Thus far, I gather this hasn't impeded the adoption of PAI. I did ask t= he WG in Berlin if we should include some more explicit indicator that would tell you that an Identity header c= ame from PAI rather than From, and the consensus was not to.
 
We are largely punting on why you might have multiple Identity header= s present in the same request: this is included for forward compatibility. = The most likely use cases are ones where extensions will differentiate the Identity headers. The recommendation to = include "canon" here just enables some potential implementation o= ptimizations (e.g. Verifier canonicalizes the identity in PAI, then compare= s to value in "canon" to save cycles before computing the identity string and checking for breakage).<= /o:p>
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg <= christer.holmberg@ericsson.com>
Date: F= riday, September 9, 2016 at 4:32 AM
To: &qu= ot;stir@ietf.org" <= stir@ietf.org>
Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my reading) th= at, if the SIP request contains multiple identities (e.g. if the request in= addition to the From header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to inclu= de =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only RECOMMENDED? If there are more than one identity, sh= ouldn=92t it be a MUST? I don=92t think we want the verifier to try all ide= ntities, and see which one (if any) works, do we?
 
Now, the text DOES talk about =93local policy=94 when it comes to cho= osing between From and PAI for deriving the identity, so perhaps we could s= ay =93MUST, unless local policy defines from where the identity is retrieved=94, or something like that=85
 
Regards,
 
Christer
_______________________________________________
stir mailing list
stir@ietf.org
https://www.i= etf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://w= ww.ietf.org/mailman/listinfo/stir


 --_000_D4004AA81B3224jonpetersonneustarbiz_-- From nobody Thu Sep 15 14:29:00 2016 Return-Path: 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 BC34E12B046 for ; Thu, 15 Sep 2016 14:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 Y4aHnu9v-jeW for ; Thu, 15 Sep 2016 14:28:54 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3333C12B00C for ; Thu, 15 Sep 2016 14:28:54 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id h8so65693559qka.1 for ; Thu, 15 Sep 2016 14:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=1BUA0ZO8m40iQ9rJCpL7sCkJeJ/baXAKTwhQwKGlcik=; b=CsjRz7G9BPbUlDWCc1yeMeb070yskRzGj/TyxuegowRrrTKQgWJQIqRFXgdWgSMel8 9BuH2iwbNxNm3dOkUpCaDa2wHUgy09sflYkazSJHetnEymCgxY8HMkORSWphKb9bdyXr zN3944BvMQP9XC9EzI56c4N9o7HNyp1V+Wjdl/komyAnZ5fAYkhuqeM9mzeYYkxVEZH7 r/C+Sq1B1Kpl4PFsEuUdwg2gPx4706SFW2cCt64sknW62sbE7mETsqwKtTdIkiquk+Pr iHzOX9+DCygiqTcqnk4dmzhdVo44cdF0C14aDGjz9M1yviMWbbLI20scdU1YsgroUqK5 SfQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1BUA0ZO8m40iQ9rJCpL7sCkJeJ/baXAKTwhQwKGlcik=; b=aIg5ISeIEVVAFQTPbnUyIDopYzpmjbogen2BCpN/HlxxgiMyq7UDzk6IF/c9cOLueu BTzECwF6YyEyOaRaKXFuhEGJqq6FxudrsXUZDSZu1T5f1cWW3xKk3cSilY/hhxuFnblj Igc6TUH4H9F24CD2J8kKKqt0WNz+HFCTZORmTLoc8kkKrn+doAci1RmfMfs4Bneq7fhF +f7QN3KZiPK6VYFYGw0WOljL0UYOE++IAFXGebCuEr4xz7v/CNPfQkmeKGI+z6icexYn 3XjOocvXlqlEJQMLiciqJ6Zn3fyvhOMsu7tDNiUvd67CaUAJzyQUX9tX9netNdHhLXHw 2zuQ== X-Gm-Message-State: AE9vXwOQmQKDn4BZe2ccb9XCvdg7TESi6/fZKiHkKi3hUyT5E1dPbOIa/Guite50O19b6w== X-Received: by 10.55.161.196 with SMTP id k187mr11975387qke.11.1473974933128; Thu, 15 Sep 2016 14:28:53 -0700 (PDT) Received: from [10.33.192.39] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id r187sm2889292qkc.49.2016.09.15.14.28.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 14:28:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_196C3A19-C7F9-457E-90CF-F6F3F6BB4EC4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Thu, 15 Sep 2016 17:28:50 -0400 Message-Id: <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 21:28:59 -0000 --Apple-Mail=_196C3A19-C7F9-457E-90CF-F6F3F6BB4EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I understood the problem to be: sip:414428123@example.com is a perfectly valid SIP URI, which, if called = would get to the right person. 414428123 however, is not a telephone = number, it=92s a userId, and a valid userId within the example.com = domain. If the receiving end tries to canonicalize that digit string, = and use that as the identity, it will fail. It has to use the entire SIP = URI as the identity. And I think the solution is the domain of the credential. Brian > On Sep 15, 2016, at 4:51 PM, Peterson, Jon = wrote: >=20 >=20 > I don't think I agree with either the framing of the problem or the = proposed solution here (for the first problem in Alan's mail); but to = dig in to this, we need to go back to the first principles of = canonicalizing phone numbers. >=20 > A =46rom identity (or a PAI identity) is expected to contain an = address-of-record of the originator of the request. If some really = unhelpful URI that is only resolvable locally is used as the From, then = we should expect there to be problems in ordinary SIP operations if the = request escapes that local environment. The whole point of including an = AoR as your public identity is that someone who sees it can dereference = it, and through standard routing procedures (in baseline SIP we mean = RFC3263) you'll end up reaching the right user agents(). If you aren't = operating within those constraints, I don't think that's really = something that RFC4474bis can fix. >=20 > A To identity expresses the AoR you are trying to reach. We already = have a split in baseline SIP between the To and the Request-URI, because = SIP recognizes that the target of a request is likely to be dynamic: in = baseline SIP, the To is supposed to be immutable, and the Request-URI is = supposed to support hard changes. >=20 > When it comes to rfc4474bis, the idea of having both sides run their = own independent canonicalization of the telephone number arose because = deployment experience suggests that intermediaries in fact modify = telephone numbers in transit in various ways, be they found in the To = and =46rom header field values or wherever else. This meddling includes = thing like removing visual separators, but also includes adding and = subtracting suffixes and prefixes as necessary to render the telephone = number or URI there globally reachable and meaningful. Or in some cases, = it includes nulling them out entirely because some other header (like = PAI) is doing their job in a way that the intermediary likes better. = Nothing that we do on the originating side will prevent intermediaries = that want to alter these numbers form doing so -- including sticking = them in a PASSporT object we tunnel in the SIP request. All that would = do is encourage those intermediaries to change the numbers in the = PASSporT object too. Like, years ago, we entertained just having a new = SIP header field that would contain the canonical number as the = authentication service saw it - but merely adding another field cannot = get around the intermediaries: they will know it's there and they will = do what they want to it. "canon" has no magic powers that would save it = from the same fate. >=20 > At the end of the day, if you are on the receiving side, you are left = to inspect whatever is left after intermediaries get through with the = message. This remains one of the most important reasons that "canon" = (which now means carrying the header and payload PASSporT objects) is = optional: the philosophy behind canonicalization is that what matters = isn't some value that the authentication service mandates, but instead = how the two sides understand the numbers as they receive them. The = originating side may initially direct the request to some local seven = digital telephone number: but by the time that gets to the terminating = side, a country code and area code might be added to it. They both = "mean" the same number, and the authentication service that signs the = request exercises the canonicalization process in order to capture what = it thinks the originator "meant" for the global environment. >=20 > Moreover, to your specific argument, here's the rub: because this is a = security function, carrying the canonical value in "canon" cannot really = help unless the verification service already knows how to turn the value = already in the =46rom (or PAI or whatever) into the canonical value = anyway. Why not? Because if I get a =46rom with = "sip:0020121421@example.com" and the PASSporT object in canon says the = orig is a tn value "12012142102", how is the verification service = supposed to know whether or not this is a cut-and-paste attack? If the = verification service just blindly trusted that the contents of the = PASSporT object's orig were equivalent to the URI in the From, it would = never be able to tell whether or not the PASSporT object actually = belonged with this call. The value of "canon" is only there for = debugging and optimization purposes, we say this many times in the spec. = It is NOT there to tunnel some "secret" value for the telephone number = between the authentication service and verification service, as that = would be a huge security hole. And it wouldn't work anyway because as I = said above intermediaries could just change it. The neat thing about not = including "canon" is that intermediaries can't change something that = isn't in the message. This was effectively the argument Hadriel and = others made back in the day. >=20 > You can argue that the verification service will sometimes not have = sufficient information to arrive at the same canonicalization as the = authentication service, and I agree. In some cases it won't: like when = calls escape from really opaque private branches, or in if one end is in = some weird variable-length dialing plan, or if a nationally-specific = service number is used, or whatever. I just think that in order for = those calls to realistically get routed and expect identity to work, = they need to express identifiers in a way that is actually useful to the = rest of the world. We formerly had some text in rfc4474bis that = recommended (against the normative guidance of RFC3261, incidentally) = that authentication services alter the To and =46rom header fields to = conform with the canonicalizations that they performed if those changes = warranted notice. Ultimately, though, I took that out because the = potential intermediary interference after the fact makes it moot. The = question is not whether the verification service trusts the bits the = authentication service claims it saw, the question is whether or not the = verification service can derive an identity equal to that from the = values it sees in the SIP request. >=20 > Ultimately, implementations need to use numbers in a sane way in order = to have any expectation that SIP will work. In those cases where the use = of numbers is sane enough that SIP will work, then I think Identity will = probably work too. >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Alan Ford > > Date: Thursday, September 15, 2016 at 12:06 PM > To: Brian Rosen > > Cc: Jon Peterson >, "stir@ietf.org = " >, Christer = Holmberg > > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >=20 >> Hi Brian, >>=20 >> The problem is on the receiving end. I see a number as the source or = destination, and decide it=92s a tn: so try to construct a passport = object with a tn: and validate it as such, but this fails. This is = because the sender sent it as a sip: URI instead. But because there=92s = no canon, I don=92t know how to reconstruct the passport so can=92t = validate. >>=20 >> Regards, >> Alan >>=20 >>> On 15 Sep 2016, at 20:01, Brian Rosen > wrote: >>>=20 >>> Okay, got it. Pity the poor blokes who have to DTMF these = extensions, but I get it. >>>=20 >>> So, what really is correct behavior here? The call is sent with an = internal extension as a SIP URI, the mechanism tries to set an Identity = header, and what? >>>=20 >>> If it does not have a credential for that TN, it shouldn=92t be = trying to sign using a TN credential. >>>=20 >>> If it has a credential for the SIP ID, then the scope of that = credential wouldn=92t be a telephone number, it would be a domain, and = the recipient should be able to figure out what is happening. >>>=20 >>> Where is the problem? >>>=20 >>> Brian >>>=20 >>>> On Sep 15, 2016, at 2:40 PM, Alan Ford > wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I=92m involved in the interop testing of early STIR implementations = at Sipit, and we have quickly run into issues around understanding how = the sender has encoded the source/destination. One person=92s tn: is = another person=92s sip: URI; the rules from the draft simply assume that = any purely-numeric user part is a telephone number, which is not always = the case in the real world. Without any context, when you call a numeric = alias in another domain, you have no idea whether this maps to a = telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but = the sender thinks it=92s a SIP URI, then the Identity will not validate. >>>>=20 >>>> In short, I agree with Christer that the canon is far more = important than the draft suggests, and is needed whenever there could be = any ambiguity about how a sender has encoded (or a receiver would = encode) some of the data (which, frankly, is most B2B scenarios). >>>>=20 >>>> Indeed, I would go probably further and suggest the canon SHOULD = always be included, - i.e. MUST, unless it is known to be operating = within a controlled environment where all entities that may be = validating the Identity header have a common understanding on its = construction. >>>>=20 >>>> The second reason I think that future implementers would thank you = for guidance like this is to enable extensibility. Say we wanted to add = protection of Display Name - and in the SIP world this is very important = since endpoints will typically display only display name if it is = present, so provides a trivial way of bypassing human visual validation. = Today, that would be achieved by defining a new ppt that added this = field. Which is all well and good, but both the sender and the receiver = would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was = always included, then (and I=92m not saying this should necessarily be = baseline spec, since it=92s too big a change at this stage) a receiver = could validate the signature of the canon, rather than reconstructing = it, and then validate field-by-field for the fields it cares/knows = about. >>>>=20 >>>> Regards, >>>> Alan >>>>=20 >>>>> On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: >>>>>=20 >>>>>=20 >>>>> The more values there are in a SIP request that are candidates for = the identity of the caller, the more likely we are going to entertain = corner cases like this. There is no guarantee that the canonicalized = identity in the =46rom header field will be identical to one in PAI - = why carry PAI if it would be? - and similarly if there are multiple PAIs = there's no guarantee that they will all canonicalize to the same form. = Somehow, though, in those RFC3324 trust environments, you are supposed = to be able to know which PAI contains the identity that you care about = for this purpose, the identity of the originator of the call. STIR can't = tell you how to find that, only local trust domain policy can. I don't = think the burden is on STIR to make this unambiguous when apparently the = trust domains already can and do. >>>>>=20 >>>>> But, of course, when carrying the "canon" parameter, it will have = one value for the originating telephone number, say, and that will match = the canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your = trust domain should probably set a local policy of sending "canon" with = every call. I'm not sure there's much more to say about it than that in = the core specs, though. >>>>>=20 >>>>> Jon Peterson >>>>> Neustar, Inc. >>>>>=20 >>>>> From: Christer Holmberg > >>>>> Date: Monday, September 12, 2016 at 10:31 AM >>>>> To: Jon Peterson >, "stir@ietf.org = " > >>>>> Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>>>=20 >>>>>> Hi, >>>>>> =20 >>>>>> Ok, maybe =93multiple identities=94 was the wrong wording. >>>>>> =20 >>>>>> My point was that, even if you know you should derive the = identity from PAI instead of From, you can have two P-Asserted-Identity = header fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >>>>>> =20 >>>>>> Regards, >>>>>> =20 >>>>>> Christer >>>>>> =A0 <> >>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >>>>>> Sent: 09 September 2016 20:11 >>>>>> To: Christer Holmberg >; stir@ietf.org = >>>>>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>>>> =20 >>>>>> =20 >>>>>> The only normative RECOMMEND in Section 8 is for cases "where = local policy canonicalizes the identity into a form different form how = it appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >>>>>> =20 >>>>>> If P-Asserted-Identity is present, surely that's where you should = be looking for identity information. As I've argued several times in the = past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >>>>>> =20 >>>>>> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >>>>>> =20 >>>>>> Jon Peterson >>>>>> Neustar, Inc. >>>>>> =20 >>>>>> From: stir > = on behalf of Christer Holmberg > >>>>>> Date: Friday, September 9, 2016 at 4:32 AM >>>>>> To: "stir@ietf.org " > >>>>>> Subject: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>>>> =20 >>>>>>> Hi, >>>>>>> =20 >>>>>>> Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>>>>>> =20 >>>>>>> Why is this only RECOMMENDED? If there are more than one = identity, shouldn=92t it be a MUST? I don=92t think we want the verifier = to try all identities, and see which one (if any) works, do we? >>>>>>> =20 >>>>>>> Now, the text DOES talk about =93local policy=94 when it comes = to choosing between =46rom and PAI for deriving the identity, so perhaps = we could say =93MUST, unless local policy defines from where the = identity is retrieved=94, or something like that=85 >>>>>>> =20 >>>>>>> Regards, >>>>>>> =20 >>>>>>> Christer >>>>> _______________________________________________ >>>>> stir mailing list >>>>> stir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/stir = >>>> _______________________________________________ >>>> stir mailing list >>>> stir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stir = >>>=20 >>=20 --Apple-Mail=_196C3A19-C7F9-457E-90CF-F6F3F6BB4EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I understood the problem to be:
sip:414428123@example.com is a perfectly valid SIP URI, = which, if called would get to the right person.  414428123 however, = is not a telephone number, it=92s a userId, and a valid userId within = the example.com domain. =  If the receiving end tries to canonicalize that digit string, and = use that as the identity, it will fail. It has to use the entire SIP URI = as the identity.

And I think the solution is the domain of the = credential.

Brian


On Sep 15, 2016, at 4:51 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


I don't think I agree with either the framing of the = problem or the proposed solution here (for the first problem in Alan's = mail); but to dig in to this, we need to go back to the first principles = of canonicalizing phone numbers.

A =46rom identity (or a PAI identity) is expected to = contain an address-of-record of the originator of the request. If some = really unhelpful URI that is only resolvable locally is used as the = From, then we should expect there to be problems in ordinary SIP operations if the request escapes that local environment. The whole = point of including an AoR as your public identity is that someone who = sees it can dereference it, and through standard routing procedures (in = baseline SIP we mean RFC3263) you'll end up reaching the right user agents(). If you aren't operating within those = constraints, I don't think that's really something that RFC4474bis can = fix.

A To identity expresses the AoR you are trying to reach. = We already have a split in baseline SIP between the To and the = Request-URI, because SIP recognizes that the target of a request is = likely to be dynamic: in baseline SIP, the To is supposed to be immutable, and the Request-URI is supposed to support hard = changes.

When it comes to rfc4474bis, the idea of having both = sides run their own independent canonicalization of the telephone number = arose because deployment experience suggests that intermediaries in fact = modify telephone numbers in transit in various ways, be they found in the To and =46rom header field values or wherever = else. This meddling includes thing like removing visual separators, but = also includes adding and subtracting suffixes and prefixes as necessary = to render the telephone number or URI there globally reachable and meaningful. Or in some cases, it includes nulling them = out entirely because some other header (like PAI) is doing their job in = a way that the intermediary likes better. Nothing that we do on the = originating side will prevent intermediaries that want to alter these numbers form doing so -- including sticking them in = a PASSporT object we tunnel in the SIP request. All that would do is = encourage those intermediaries to change the numbers in the PASSporT = object too. Like, years ago, we entertained just having a new SIP header field that would contain the canonical number = as the authentication service saw it - but merely adding another field = cannot get around the intermediaries: they will know it's there and they = will do what they want to it. "canon" has no magic powers that would save it from the same fate.

At the end of the day, if you are on the receiving side, = you are left to inspect whatever is left after intermediaries get = through with the message. This remains one of the most important reasons = that "canon" (which now means carrying the header and payload PASSporT objects) is optional: the philosophy behind canonicalization = is that what matters isn't some value that the authentication service = mandates, but instead how the two sides understand the numbers as they = receive them. The originating side may initially direct the request to some local seven digital telephone number: but by = the time that gets to the terminating side, a country code and area code = might be added to it. They both "mean" the same number, and the = authentication service that signs the request exercises the canonicalization process in order to capture what it thinks the = originator "meant" for the global environment.

Moreover, to your specific argument, here's the rub: = because this is a security function, carrying the canonical value in = "canon" cannot really help unless the verification service already knows = how to turn the value already in the =46rom (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a =46rom = with "sip:0020121421@example.com" and the PASSporT object in = canon says the orig is a tn value "12012142102", how is the verification = service supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the = contents of the PASSporT object's orig were equivalent to the URI in the = From, it would never be able to tell whether or not the PASSporT object = actually belonged with this call. The value of "canon" is only there for debugging and optimization purposes, we say = this many times in the spec. It is NOT there to tunnel some "secret" = value for the telephone number between the authentication service and = verification service, as that would be a huge security hole. And it wouldn't work anyway because as I said above = intermediaries could just change it. The neat thing about not including = "canon" is that intermediaries can't change something that isn't in the = message. This was effectively the argument Hadriel and others made back in the day.

You can argue that the verification service will = sometimes not have sufficient information to arrive at the same = canonicalization as the authentication service, and I agree. In some = cases it won't: like when calls escape from really opaque private = branches, or in if one end is in some weird variable-length dialing plan, or if a = nationally-specific service number is used, or whatever. I just think = that in order for those calls to realistically get routed and expect = identity to work, they need to express identifiers in a way that is actually useful to the rest of the world. We formerly = had some text in rfc4474bis that recommended (against the normative = guidance of RFC3261, incidentally) that authentication services alter = the To and =46rom header fields to conform with the canonicalizations that they performed if those changes warranted = notice. Ultimately, though, I took that out because the potential = intermediary interference after the fact makes it moot. The question is = not whether the verification service trusts the bits the authentication service claims it saw, the question is whether or = not the verification service can derive an identity equal to that from = the values it sees in the SIP request.

Ultimately, implementations need to use numbers in a = sane way in order to have any expectation that SIP will work. In those = cases where the use of numbers is sane enough that SIP will work, then I = think Identity will probably work too.

Jon Peterson
Neustar, Inc.

From: Alan Ford = <alan.ford@gmail.com>
Date: Thursday, = September 15, 2016 at 12:06 PM
To: Brian Rosen = <br@brianrosen.net>
Cc: Jon Peterson = <jon.peterson@neustar.biz>, "stir@ietf.org" <stir@ietf.org>, Christer = Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [stir] = 4474bis: Why only RECOMMEND when multiple identities?

Hi Brian,

The problem is on the receiving end. I see a number as = the source or destination, and decide it=92s a tn: so try to construct a = passport object with a tn: and validate it as such, but this fails. This = is because the sender sent it as a sip: URI instead. But because there=92s no canon, I don=92t know how to = reconstruct the passport so can=92t validate.

Regards,
Alan

On 15 Sep 2016, at 20:01, Brian Rosen <br@brianrosen.net> = wrote:

Okay, got it.  Pity the poor blokes who have to DTMF these = extensions, but I get it.

So, what really is correct behavior here?  The call = is sent with an internal extension as a SIP URI, the mechanism tries to = set an Identity header, and what?

If it does not have a credential for that TN, it = shouldn=92t be trying to sign using a TN credential.

If it has a credential for the SIP ID, then the scope of = that credential wouldn=92t be a telephone number, it would be a domain, = and the recipient should be able to figure out what is happening.

Where is the problem?

Brian

On Sep 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com>= wrote:

Hi all,

I=92m involved in the interop testing of early STIR = implementations at Sipit, and we have quickly run into issues around = understanding how the sender has encoded the source/destination. One = person=92s tn: is another person=92s sip: URI; the rules from the draft simply assume that any purely-numeric user part is a = telephone number, which is not always the case in the real world. = Without any context, when you call a numeric alias in another domain, = you have no idea whether this maps to a telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but the sender = thinks it=92s a SIP URI, then the Identity will not validate.

In short, I agree with Christer that the canon is far = more important than the draft suggests, and is needed whenever there = could be any ambiguity about how a sender has encoded (or a receiver = would encode) some of the data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and suggest the = canon SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future implementers would = thank you for guidance like this is to enable extensibility. Say we = wanted to add protection of Display Name - and in the SIP world this is = very important since endpoints will typically display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was always included, then (and I=92m not saying this = should necessarily be baseline spec, since it=92s too big a change at = this stage) a receiver could validate the signature of the canon, rather = than reconstructing it, and then validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP request that are candidates for the = identity of the caller, the more likely we are going to entertain corner = cases like this. There is no guarantee that the canonicalized identity = in the =46rom header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there = are multiple PAIs there's no guarantee that they will all canonicalize = to the same form. Somehow, though, in those RFC3324 trust environments, = you are supposed to be able to know which PAI contains the identity that you care about for this purpose, the = identity of the originator of the call. STIR can't tell you how to find = that, only local trust domain policy can. I don't think the burden is on = STIR to make this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will have one = value for the originating telephone number, say, and that will match the = canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy = of sending "canon" with every call. I'm not sure there's much more to = say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple identities=94 was = the wrong wording.
 
My point was that, even if you know you = should derive the identity from PAI instead of From, you can have two = P-Asserted-Identity header fields, and as far as I understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative RECOMMEND in Section 8 is for cases "where = local policy canonicalizes the identity into a form different form how = it appears in the =46rom header field." That doesn't have anything to do with multiple identities. The text in the previous = sentence notes that it is talking about a case where "the canonical = identity derives from the P-Asserted-Identity field rather than the =46rom= header field," not a case where identities based on both appear in different Identity headers.
 
If P-Asserted-Identity is present, surely that's where you = should be looking for identity information. As I've argued several times = in the past, this is no more or less ambiguous than the practical use of P-Asserted-Identity in the field today: nothing = about the request tells you "use PAI instead of From" other than the = presence of PAI. Because of all the RFC3324 trust domain stuff that Mark = Watson talked us into back in the day, it's hard to say anything more than that it's a matter of local policy, as = nothing about the protocol tells you whether or not you are in an = RFC3324 trust domain. Thus far, I gather this hasn't impeded the = adoption of PAI. I did ask the WG in Berlin if we should include some more explicit indicator that would tell you that an Identity = header came from PAI rather than From, and the consensus was not to.
 
We are largely punting on why you might have multiple = Identity headers present in the same request: this is included for = forward compatibility. The most likely use cases are ones where extensions will differentiate the Identity headers. The recommendation = to include "canon" here just enables some potential implementation = optimizations (e.g. Verifier canonicalizes the identity in PAI, then = compares to value in "canon" to save cycles before computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to = include =93canon=94, so that the verifier knows which identity to = verify.
 
Why is this only RECOMMENDED? If there are more than one = identity, shouldn=92t it be a MUST? I don=92t think we want the verifier = to try all identities, and see which one (if any) works, do we?
 
Now, the text DOES talk about =93local policy=94 when it = comes to choosing between =46rom and PAI for deriving the identity, so = perhaps we could say =93MUST, unless local policy defines from where the identity is retrieved=94, or something like that=85
 
Regards,
 
Christer
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_196C3A19-C7F9-457E-90CF-F6F3F6BB4EC4-- From nobody Thu Sep 15 14:43:07 2016 Return-Path: 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 7D45E12B019 for ; Thu, 15 Sep 2016 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tA0lLGhCXkNy for ; Thu, 15 Sep 2016 14:43:03 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7484212B015 for ; Thu, 15 Sep 2016 14:43:03 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id r126so89054168oib.0 for ; Thu, 15 Sep 2016 14:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Net61vF/jOoQr+FqYig3EfAPNj3Iw730kJmuPZh0O3k=; b=htnBf+d9ayo4+jSt6+pfyiA19JbtnMU6GEQUsLx5526n7Xfr1eZljp7F5ideZ9e9h7 RNXF1IIYIIkLmN6j19JR7x7BZZwdoZ8+TDpIJVeH/PAu8z819kOJUUG6aisDVOYooGgn sBG/s4yOnlkRCrp31Vs9L5KN7sx0FQOSsXHgYGSkmzkzUJ5efFYSjUCEqCR+7mDYMMTa I953svipMMSfqq3Oq/ukx5EkVZaV6vKCiWZapGAnIkSFs+wJCMW2JUQYToQNZCaJYfb5 9/W7zqOCVhxv9VsIl+lRJejF6HZTPplD8HJmzW3pOzd2f+BUMVrNyHoRDdzPGxDPKO8k WqJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Net61vF/jOoQr+FqYig3EfAPNj3Iw730kJmuPZh0O3k=; b=dlck2a+cXC43o/y2fsd+xF1S2UhfJaMftsrkYT9PWE6NXVjECWZxK/BCigxHk6Y26H onfbvD+bMUahAd+muNhA7kY5SCWV5EUA5WQyxPWuKu/cCbAC9xFFqXo5UB+s8pZJvh5K QJgnC3RzxQntvqekTjOKvoxTqM5iSylJ3uH4iLnIn0Xs+13ZGbEF9IduP2s36X9C/yQT 4oGg0v57+BWCsF6+WtYb5tVA7zrVhh+gOfRC63bjtkJNcwu1HO7ULxVMw3aZ2Mc8PvRf cMZZpUj4aT20wZSM8GCO0YpoSicJjuUw8OrKUX8FO6aegY34zk9cfiXXMdLl9Qa4zYmA rbUw== X-Gm-Message-State: AE9vXwMmb6ZJnX5/QrXcAVPsUGvj+MOrHwIlKsXnVNyZf+Uat6lXGqLeQXofcAXOFxmqreLGBlvl59Mh5Gz0Lw== X-Received: by 10.157.58.2 with SMTP id j2mr9175745otc.166.1473975782860; Thu, 15 Sep 2016 14:43:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.153 with HTTP; Thu, 15 Sep 2016 14:43:02 -0700 (PDT) In-Reply-To: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> From: Mary Barnes Date: Thu, 15 Sep 2016 16:43:02 -0500 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a1147356ef1eef0053c92bab1 Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org 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, 15 Sep 2016 21:43:05 -0000 --001a1147356ef1eef0053c92bab1 Content-Type: text/plain; charset=UTF-8 Hi Russ, Your proposal makes a lot of sense to me. So, this then removes the dependency on the LoA Registry defined for SAML, correct? Regards, Mary. On Thu, Sep 15, 2016 at 11:07 AM, Russ Housley wrote: > I have found a place where additional clarity is needed in Section 5.1. > The current text is: > > 5.1. Levels Of Assurance > > This specification supports different level of assurance (LOA). The > LOA indications, which are Object Identifiers (OIDs) included in the > certificate's certificate policies extension [RFC5280], allow CAs to > differentiate those enrolled from proof-of-possession versus > delegation. A Certification Policy and a Certification Practice > Statement [RFC3647] are produced as part of the normal PKI > bootstrapping process (i.e., the CP is written first and then the CAs > say how they conform to the CP in the CPS). OIDs are used to > reference the CP and if the CA wishes it can also include a reference > to the CPS with the certificate policies extension. CAs that wish to > express different LOAs MUST include the certificate policies > extension in issued certificates. See Section 11 for additional > information about the LOA registry. > > This all makes sense to me, but it does not say whether the LOA is > inferred from the CertPolicyId or explicitly carried in the > PolicyQualifierInfo. I think that the later is intended because of the > reference to an LOA registry. Please confirm that I got that right. > > For background, RFC 5280 specifies the following ASN.1 for the > PolicyQualifierInfo: > > PolicyQualifierInfo ::= SEQUENCE { > policyQualifierId PolicyQualifierId, > qualifier ANY DEFINED BY policyQualifierId } > > So, I think we need to specify a single OID for the LOA policyQualifierId > that is used in all certificates, and then have the qualifier carry an > object identifier for the LOA. Each certificate policy would list the LOA > object identifiers that are supported. If this is the intent, then the > IANA considerations should ask for the assignment of the policyQualifierId > object identifier. > > That would result in something like this: > > id-qt-loa OBJECT IDENTIFIER ::= { id-qt TBD1 } > > id-loa-full OBJECT IDENTIFIER ::= { TBD2 } > id-loa-partial OBJECT IDENTIFIER ::= { TBD3 } > id-loa-none OBJECT IDENTIFIER ::= { TBD4 } > > Comments? > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a1147356ef1eef0053c92bab1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Russ,

Your proposal makes a lot of s= ense to me.=C2=A0 So, this then removes the dependency on the LoA Registry = defined for SAML, correct?=C2=A0

Regards,
Mary. =C2=A0

On Thu, Sep 15, 2016 at 11:07 AM, Russ Housley &= lt;housley@vigils= ec.com> wrote:
I have found= a place where additional clarity is needed in Section 5.1.=C2=A0 The curre= nt text is:

5.1.=C2=A0 Levels Of Assurance

=C2=A0 =C2=A0This specification supports different level of assurance (LOA)= .=C2=A0 The
=C2=A0 =C2=A0LOA indications, which are Object Identifiers (OIDs) included = in the
=C2=A0 =C2=A0certificate's certificate policies extension [RFC5280], al= low CAs to
=C2=A0 =C2=A0differentiate those enrolled from proof-of-possession versus =C2=A0 =C2=A0delegation.=C2=A0 A Certification Policy and a Certification P= ractice
=C2=A0 =C2=A0Statement [RFC3647] are produced as part of the normal PKI
=C2=A0 =C2=A0bootstrapping process (i.e., the CP is written first and then = the CAs
=C2=A0 =C2=A0say how they conform to the CP in the CPS).=C2=A0 OIDs are use= d to
=C2=A0 =C2=A0reference the CP and if the CA wishes it can also include a re= ference
=C2=A0 =C2=A0to the CPS with the certificate policies extension.=C2=A0 CAs = that wish to
=C2=A0 =C2=A0express different LOAs MUST include the certificate policies =C2=A0 =C2=A0extension in issued certificates.=C2=A0 See Section 11 for add= itional
=C2=A0 =C2=A0information about the LOA registry.

This all makes sense to me, but it does not say whether the LOA is inferred= from the CertPolicyId or explicitly carried in the PolicyQualifierInfo.=C2= =A0 I think that the later is intended because of the reference to an LOA r= egistry.=C2=A0 Please confirm that I got that right.

For background, RFC 5280 specifies the following ASN.1 for the PolicyQualif= ierInfo:

=C2=A0 =C2=A0PolicyQualifierInfo ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 policyQualifierId=C2=A0 PolicyQualifierId,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 qualifier=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ANY= DEFINED BY policyQualifierId }

So, I think we need to specify a single OID for the LOA policyQualifierId t= hat is used in all certificates, and then have the qualifier carry an objec= t identifier for the LOA.=C2=A0 Each certificate policy would list the LOA = object identifiers that are supported.=C2=A0 If this is the intent, then th= e IANA considerations should ask for the assignment of the policyQualifierI= d object identifier.

That would result in something like this:

=C2=A0 =C2=A0id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }

=C2=A0 =C2=A0id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 }
=C2=A0 =C2=A0id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 }
=C2=A0 =C2=A0id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 }

Comments?

Russ

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--001a1147356ef1eef0053c92bab1-- From nobody Thu Sep 15 14:52:28 2016 Return-Path: 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 26BDA12B071 for ; Thu, 15 Sep 2016 14:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 6k0ZqgAxQ8kM for ; Thu, 15 Sep 2016 14:52:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B7A12B00C for ; Thu, 15 Sep 2016 14:52:22 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u8FLgxTA002511; Thu, 15 Sep 2016 17:52:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=k3ATu54vruwbK0d2HHnB2wX2Xv9HoHl9VzKZdDWUD/w=; b=WOpGDSPxkbQtAISbiCta7Ls6U7S2MKNRpPuZZ+Rx75cZHv0RRbVX1A/b+395JAjZvqWR vUxPr9obOrkuUHSyVoFwd4C/zzxBjxRfIXJeNyROi7H2Dwn8+7w49p6myX9zxwAtZWTS BYX+fXFfbC2+wd4PY4odTyiIKy625B7yaXRpZRaARnvugY33zo6jJutQ7wLsYJFDl5uX loPrE8VTXcoipnqo7Pu5aqFvb4FFn/yvhiCa30XgvnLvC9KvXG4yoAk+PcLDNjf57sXo 2hiy32h2mZ89rC6I2EYnCBK7cTs56xonY78ireZuSyGD/xjtc4M+KPxOvZLCRrf8BdDy dQ== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 25ceg9cmkc-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Sep 2016 17:52:15 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 15 Sep 2016 17:52:15 -0400 From: "Peterson, Jon" To: Brian Rosen Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAA1l8gIAABekAgAABcQD//6g2gIAAf5EA//+RW4A= Date: Thu, 15 Sep 2016 21:52:14 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> In-Reply-To: <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.120] Content-Type: multipart/alternative; boundary="_000_D40065331B345Ajonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-15_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609150288 Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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, 15 Sep 2016 21:52:27 -0000 --_000_D40065331B345Ajonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I took Alan's mail to be speaking to the much more general problem of why w= e perform two independent canonicalization passes at all, if in some cases = it is impossible for the terminating side to know what the originating side= meant. I don't disagree that the signing credential, and its scope of authority, c= an give you an indication of which kind of identity the originating side th= inks its signing for. I'm not sure even that will ever be entirely free of = potential ambiguity; I could construct some corner cases where a certificat= e has both a subjectAltName and a TNAuthorizationList, say. But if you're s= aying it's worth mentioning that the signing credential can provide a hint,= we could put in some text to that effect. Jon Peterson Neustar, Inc. From: Brian Rosen > Date: Thursday, September 15, 2016 at 2:28 PM To: Jon Peterson = > Cc: Alan Ford >, "stir@ietf= .org" >, Christer= Holmberg > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? I understood the problem to be: sip:414428123@example.com is a perfectly valid SIP URI, which, if called wo= uld get to the right person. 414428123 however, is not a telephone number,= it=92s a userId, and a valid userId within the example.com domain. If the receiving end tries to canonicalize that digit string,= and use that as the identity, it will fail. It has to use the entire SIP U= RI as the identity. And I think the solution is the domain of the credential. Brian On Sep 15, 2016, at 4:51 PM, Peterson, Jon > wrote: I don't think I agree with either the framing of the problem or the propose= d solution here (for the first problem in Alan's mail); but to dig in to th= is, we need to go back to the first principles of canonicalizing phone numb= ers. A From identity (or a PAI identity) is expected to contain an address-of-re= cord of the originator of the request. If some really unhelpful URI that is= only resolvable locally is used as the From, then we should expect there t= o be problems in ordinary SIP operations if the request escapes that local = environment. The whole point of including an AoR as your public identity is= that someone who sees it can dereference it, and through standard routing = procedures (in baseline SIP we mean RFC3263) you'll end up reaching the rig= ht user agents(). If you aren't operating within those constraints, I don't= think that's really something that RFC4474bis can fix. A To identity expresses the AoR you are trying to reach. We already have a = split in baseline SIP between the To and the Request-URI, because SIP recog= nizes that the target of a request is likely to be dynamic: in baseline SIP= , the To is supposed to be immutable, and the Request-URI is supposed to su= pport hard changes. When it comes to rfc4474bis, the idea of having both sides run their own in= dependent canonicalization of the telephone number arose because deployment= experience suggests that intermediaries in fact modify telephone numbers i= n transit in various ways, be they found in the To and From header field va= lues or wherever else. This meddling includes thing like removing visual se= parators, but also includes adding and subtracting suffixes and prefixes as= necessary to render the telephone number or URI there globally reachable a= nd meaningful. Or in some cases, it includes nulling them out entirely beca= use some other header (like PAI) is doing their job in a way that the inter= mediary likes better. Nothing that we do on the originating side will preve= nt intermediaries that want to alter these numbers form doing so -- includi= ng sticking them in a PASSporT object we tunnel in the SIP request. All tha= t would do is encourage those intermediaries to change the numbers in the P= ASSporT object too. Like, years ago, we entertained just having a new SIP h= eader field that would contain the canonical number as the authentication s= ervice saw it - but merely adding another field cannot get around the inter= mediaries: they will know it's there and they will do what they want to it.= "canon" has no magic powers that would save it from the same fate. At the end of the day, if you are on the receiving side, you are left to in= spect whatever is left after intermediaries get through with the message. T= his remains one of the most important reasons that "canon" (which now means= carrying the header and payload PASSporT objects) is optional: the philoso= phy behind canonicalization is that what matters isn't some value that the = authentication service mandates, but instead how the two sides understand t= he numbers as they receive them. The originating side may initially direct = the request to some local seven digital telephone number: but by the time t= hat gets to the terminating side, a country code and area code might be add= ed to it. They both "mean" the same number, and the authentication service = that signs the request exercises the canonicalization process in order to c= apture what it thinks the originator "meant" for the global environment. Moreover, to your specific argument, here's the rub: because this is a secu= rity function, carrying the canonical value in "canon" cannot really help u= nless the verification service already knows how to turn the value already = in the From (or PAI or whatever) into the canonical value anyway. Why not? = Because if I get a From with "sip:0020121421@example.com" and the PASSporT = object in canon says the orig is a tn value "12012142102", how is the verif= ication service supposed to know whether or not this is a cut-and-paste att= ack? If the verification service just blindly trusted that the contents of = the PASSporT object's orig were equivalent to the URI in the From, it would= never be able to tell whether or not the PASSporT object actually belonged= with this call. The value of "canon" is only there for debugging and optim= ization purposes, we say this many times in the spec. It is NOT there to tu= nnel some "secret" value for the telephone number between the authenticatio= n service and verification service, as that would be a huge security hole. = And it wouldn't work anyway because as I said above intermediaries could ju= st change it. The neat thing about not including "canon" is that intermedia= ries can't change something that isn't in the message. This was effectively= the argument Hadriel and others made back in the day. You can argue that the verification service will sometimes not have suffici= ent information to arrive at the same canonicalization as the authenticatio= n service, and I agree. In some cases it won't: like when calls escape from= really opaque private branches, or in if one end is in some weird variable= -length dialing plan, or if a nationally-specific service number is used, o= r whatever. I just think that in order for those calls to realistically get= routed and expect identity to work, they need to express identifiers in a = way that is actually useful to the rest of the world. We formerly had some = text in rfc4474bis that recommended (against the normative guidance of RFC3= 261, incidentally) that authentication services alter the To and From heade= r fields to conform with the canonicalizations that they performed if those= changes warranted notice. Ultimately, though, I took that out because the = potential intermediary interference after the fact makes it moot. The quest= ion is not whether the verification service trusts the bits the authenticat= ion service claims it saw, the question is whether or not the verification = service can derive an identity equal to that from the values it sees in the= SIP request. Ultimately, implementations need to use numbers in a sane way in order to h= ave any expectation that SIP will work. In those cases where the use of num= bers is sane enough that SIP will work, then I think Identity will probably= work too. Jon Peterson Neustar, Inc. From: Alan Ford > Date: Thursday, September 15, 2016 at 12:06 PM To: Brian Rosen > Cc: Jon Peterson = >, "stir@ietf.org" >, Christer Holmberg > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi Brian, The problem is on the receiving end. I see a number as the source or destin= ation, and decide it=92s a tn: so try to construct a passport object with a= tn: and validate it as such, but this fails. This is because the sender se= nt it as a sip: URI instead. But because there=92s no canon, I don=92t know= how to reconstruct the passport so can=92t validate. Regards, Alan On 15 Sep 2016, at 20:01, Brian Rosen > wrote: Okay, got it. Pity the poor blokes who have to DTMF these extensions, but = I get it. So, what really is correct behavior here? The call is sent with an interna= l extension as a SIP URI, the mechanism tries to set an Identity header, an= d what? If it does not have a credential for that TN, it shouldn=92t be trying to s= ign using a TN credential. If it has a credential for the SIP ID, then the scope of that credential wo= uldn=92t be a telephone number, it would be a domain, and the recipient sho= uld be able to figure out what is happening. Where is the problem? Brian On Sep 15, 2016, at 2:40 PM, Alan Ford > wrote: Hi all, I=92m involved in the interop testing of early STIR implementations at Sipi= t, and we have quickly run into issues around understanding how the sender = has encoded the source/destination. One person=92s tn: is another person=92= s sip: URI; the rules from the draft simply assume that any purely-numeric = user part is a telephone number, which is not always the case in the real w= orld. Without any context, when you call a numeric alias in another domain,= you have no idea whether this maps to a telephone number or a SIP URI. If = the receiver thinks it=92s a tn:, but the sender thinks it=92s a SIP URI, t= hen the Identity will not validate. In short, I agree with Christer that the canon is far more important than t= he draft suggests, and is needed whenever there could be any ambiguity abou= t how a sender has encoded (or a receiver would encode) some of the data (w= hich, frankly, is most B2B scenarios). Indeed, I would go probably further and suggest the canon SHOULD always be = included, - i.e. MUST, unless it is known to be operating within a controll= ed environment where all entities that may be validating the Identity heade= r have a common understanding on its construction. The second reason I think that future implementers would thank you for guid= ance like this is to enable extensibility. Say we wanted to add protection = of Display Name - and in the SIP world this is very important since endpoin= ts will typically display only display name if it is present, so provides a= trivial way of bypassing human visual validation. Today, that would be ach= ieved by defining a new ppt that added this field. Which is all well and go= od, but both the sender and the receiver would need to support this new ppt= , and this is by no means guaranteed. So for maximum compatibility what wou= ld a sender do? Should a sender include multiple Identity headers of multip= le ppts, hoping one is supported by the far end? The overhead there would b= e huge. If canon was always included, then (and I=92m not saying this shoul= d necessarily be baseline spec, since it=92s too big a change at this stage= ) a receiver could validate the signature of the canon, rather than reconst= ructing it, and then validate field-by-field for the fields it cares/knows = about. Regards, Alan On 13 Sep 2016, at 23:30, Peterson, Jon > wrote: The more values there are in a SIP request that are candidates for the iden= tity of the caller, the more likely we are going to entertain corner cases = like this. There is no guarantee that the canonicalized identity in the Fro= m header field will be identical to one in PAI - why carry PAI if it would = be? - and similarly if there are multiple PAIs there's no guarantee that th= ey will all canonicalize to the same form. Somehow, though, in those RFC332= 4 trust environments, you are supposed to be able to know which PAI contain= s the identity that you care about for this purpose, the identity of the or= iginator of the call. STIR can't tell you how to find that, only local trus= t domain policy can. I don't think the burden is on STIR to make this unamb= iguous when apparently the trust domains already can and do. But, of course, when carrying the "canon" parameter, it will have one value= for the originating telephone number, say, and that will match the canonic= alized form of one of those identities and not the others. If your trust do= main introduces this ambiguity into every call, then your trust domain shou= ld probably set a local policy of sending "canon" with every call. I'm not = sure there's much more to say about it than that in the core specs, though. Jon Peterson Neustar, Inc. From: Christer Holmberg > Date: Monday, September 12, 2016 at 10:31 AM To: Jon Peterson = >, "stir@ietf.org" > Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Ok, maybe =93multiple identities=94 was the wrong wording. My point was that, even if you know you should derive the identity from PAI= instead of From, you can have two P-Asserted-Identity header fields, and a= s far as I understand there is no guarantee that the canonicalized form of = those match. Regards, Christer From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 09 September 2016 20:11 To: Christer Holmberg >; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? The only normative RECOMMEND in Section 8 is for cases "where local policy = canonicalizes the identity into a form different form how it appears in the= From header field." That doesn't have anything to do with multiple identit= ies. The text in the previous sentence notes that it is talking about a cas= e where "the canonical identity derives from the P-Asserted-Identity field = rather than the From header field," not a case where identities based on bo= th appear in different Identity headers. If P-Asserted-Identity is present, surely that's where you should be lookin= g for identity information. As I've argued several times in the past, this = is no more or less ambiguous than the practical use of P-Asserted-Identity = in the field today: nothing about the request tells you "use PAI instead of= From" other than the presence of PAI. Because of all the RFC3324 trust dom= ain stuff that Mark Watson talked us into back in the day, it's hard to say= anything more than that it's a matter of local policy, as nothing about th= e protocol tells you whether or not you are in an RFC3324 trust domain. Thu= s far, I gather this hasn't impeded the adoption of PAI. I did ask the WG i= n Berlin if we should include some more explicit indicator that would tell = you that an Identity header came from PAI rather than From, and the consens= us was not to. We are largely punting on why you might have multiple Identity headers pres= ent in the same request: this is included for forward compatibility. The mo= st likely use cases are ones where extensions will differentiate the Identi= ty headers. The recommendation to include "canon" here just enables some po= tential implementation optimizations (e.g. Verifier canonicalizes the ident= ity in PAI, then compares to value in "canon" to save cycles before computi= ng the identity string and checking for breakage). Jon Peterson Neustar, Inc. From: stir > on behalf = of Christer Holmberg > Date: Friday, September 9, 2016 at 4:32 AM To: "stir@ietf.org" > Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi, Section 8 of draft-4474bis says (or, that=92s at least my reading) that, if= the SIP request contains multiple identities (e.g. if the request in addit= ion to the From header field contains one or more P-Asserted-Identity heade= r fields), it is RECOMMENDED to include =93canon=94, so that the verifier k= nows which identity to verify. Why is this only RECOMMENDED? If there are more than one identity, shouldn= =92t it be a MUST? I don=92t think we want the verifier to try all identiti= es, and see which one (if any) works, do we? Now, the text DOES talk about =93local policy=94 when it comes to choosing = between From and PAI for deriving the identity, so perhaps we could say =93= MUST, unless local policy defines from where the identity is retrieved=94, = or something like that=85 Regards, Christer _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_D40065331B345Ajonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

I took Alan's mail to be speaking to the much more general problem of = why we perform two independent canonicalization passes at all, if in some c= ases it is impossible for the terminating side to know what the originating= side meant.

I don't disagree that the signing credential, and its scope of authori= ty, can give you an indication of which kind of identity the originating si= de thinks its signing for. I'm not sure even that will ever be entirely fre= e of potential ambiguity; I could construct some corner cases where a certificate has both a subjectAltName = and a TNAuthorizationList, say. But if you're saying it's worth mentioning = that the signing credential can provide a hint, we could put in some text t= o that effect.

Jon Peterson
Neustar, Inc.

From: Brian Rosen <br@brianrosen.net>
Date: Thursday, September 15, 2016 = at 2:28 PM
To: Jon Peterson <jon.peterson@neustar.biz>
Cc: Alan Ford <alan.ford@gmail.com>, "stir@ietf.org" <stir@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [stir] 4474bis: Why on= ly RECOMMEND when multiple identities?

I understood the problem to be:
sip:414428= 123@example.com is a perfectly valid SIP URI, which, if called would ge= t to the right person.  414428123 however, is not a telephone number, = it=92s a userId, and a valid userId within the example.com domain.  If = the receiving end tries to canonicalize that digit string, and use that as = the identity, it will fail. It has to use the entire SIP URI as the identit= y.

And I think the solution is the domain of the credential.

Brian


On Sep 15, 2016, at 4:51 PM, Peterson, Jon <jon.peterson@neustar.biz>= wrote:


I don't think I agree with either the framing of the proble= m or the proposed solution here (for the first problem in Alan's mail); but= to dig in to this, we need to go back to the first principles of canonical= izing phone numbers.

A From identity (or a PAI identity) is expected to contain = an address-of-record of the originator of the request. If some really unhel= pful URI that is only resolvable locally is used as the From, then we shoul= d expect there to be problems in ordinary SIP operations if the request escapes that local environment. The whole po= int of including an AoR as your public identity is that someone who sees it= can dereference it, and through standard routing procedures (in baseline S= IP we mean RFC3263) you'll end up reaching the right user agents(). If you aren't operating within those con= straints, I don't think that's really something that RFC4474bis can fix.

A To identity expresses the AoR you are trying to reach. We= already have a split in baseline SIP between the To and the Request-URI, b= ecause SIP recognizes that the target of a request is likely to be dynamic:= in baseline SIP, the To is supposed to be immutable, and the Request-URI is supposed to support hard changes.<= /div>

When it comes to rfc4474bis, the idea of having both sides = run their own independent canonicalization of the telephone number arose be= cause deployment experience suggests that intermediaries in fact modify tel= ephone numbers in transit in various ways, be they found in the To and From header field values or wherever els= e. This meddling includes thing like removing visual separators, but also i= ncludes adding and subtracting suffixes and prefixes as necessary to render= the telephone number or URI there globally reachable and meaningful. Or in some cases, it includes nulling t= hem out entirely because some other header (like PAI) is doing their job in= a way that the intermediary likes better. Nothing that we do on the origin= ating side will prevent intermediaries that want to alter these numbers form doing so -- including sticking them = in a PASSporT object we tunnel in the SIP request. All that would do is enc= ourage those intermediaries to change the numbers in the PASSporT object to= o. Like, years ago, we entertained just having a new SIP header field that would contain the canonical number= as the authentication service saw it - but merely adding another field can= not get around the intermediaries: they will know it's there and they will = do what they want to it. "canon" has no magic powers that would save it from the same fate.

At the end of the day, if you are on the receiving side, yo= u are left to inspect whatever is left after intermediaries get through wit= h the message. This remains one of the most important reasons that "ca= non" (which now means carrying the header and payload PASSporT objects) is optional: the philosophy behind canonical= ization is that what matters isn't some value that the authentication servi= ce mandates, but instead how the two sides understand the numbers as they r= eceive them. The originating side may initially direct the request to some local seven digital telephone num= ber: but by the time that gets to the terminating side, a country code and = area code might be added to it. They both "mean" the same number,= and the authentication service that signs the request exercises the canonicalization process in order to capture wha= t it thinks the originator "meant" for the global environment.

Moreover, to your specific argument, here's the rub: becaus= e this is a security function, carrying the canonical value in "canon&= quot; cannot really help unless the verification service already knows how = to turn the value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a = >From with "sip:00201= 21421@example.com" and the PASSporT object in canon says the orig = is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? If= the verification service just blindly trusted that the contents of the PAS= SporT object's orig were equivalent to the URI in the From, it would never = be able to tell whether or not the PASSporT object actually belonged with this call. The value of "canon= " is only there for debugging and optimization purposes, we say this m= any times in the spec. It is NOT there to tunnel some "secret" va= lue for the telephone number between the authentication service and verification service, as that would be a huge security hole. A= nd it wouldn't work anyway because as I said above intermediaries could jus= t change it. The neat thing about not including "canon" is that i= ntermediaries can't change something that isn't in the message. This was effectively the argument Hadriel and others= made back in the day.

You can argue that the verification service will sometimes = not have sufficient information to arrive at the same canonicalization as t= he authentication service, and I agree. In some cases it won't: like when c= alls escape from really opaque private branches, or in if one end is in some weird variable-length dialing plan, = or if a nationally-specific service number is used, or whatever. I just thi= nk that in order for those calls to realistically get routed and expect ide= ntity to work, they need to express identifiers in a way that is actually useful to the rest of the world. We = formerly had some text in rfc4474bis that recommended (against the normativ= e guidance of RFC3261, incidentally) that authentication services alter the= To and From header fields to conform with the canonicalizations that they performed if those changes warranted = notice. Ultimately, though, I took that out because the potential intermedi= ary interference after the fact makes it moot. The question is not whether = the verification service trusts the bits the authentication service claims it saw, the question is whether= or not the verification service can derive an identity equal to that from = the values it sees in the SIP request.

Ultimately, implementations need to use numbers in a sane w= ay in order to have any expectation that SIP will work. In those cases wher= e the use of numbers is sane enough that SIP will work, then I think Identi= ty will probably work too.

Jon Peterson
Neustar, Inc.

From: Alan Ford <alan.ford@gmail.com> Date: Thursday, Septembe= r 15, 2016 at 12:06 PM
To: Brian Rosen <br@brianrosen.net>
Cc: Jon Peterson <jon.peterson@neustar.bi= z>, "stir@ietf.org<= /a>" <stir@ietf.org= >, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [stir] 4474= bis: Why only RECOMMEND when multiple identities?

Hi Brian,

The problem is on the receiving end. I see a number as the = source or destination, and decide it=92s a tn: so try to construct a passpo= rt object with a tn: and validate it as such, but this fails. This is becau= se the sender sent it as a sip: URI instead. But because there=92s no canon, I don=92t know how to reconstruct= the passport so can=92t validate.

Regards,
Alan

On 15 Sep 2016, at 20:01, Brian Rosen <br@brianrosen.net> wrote:

Okay, got it.  Pity the poor blokes who have to DTMF these extensions,= but I get it.

So, what really is correct behavior here?  The call is= sent with an internal extension as a SIP URI, the mechanism tries to set a= n Identity header, and what?

If it does not have a credential for that TN, it shouldn=92= t be trying to sign using a TN credential.

If it has a credential for the SIP ID, then the scope of th= at credential wouldn=92t be a telephone number, it would be a domain, and t= he recipient should be able to figure out what is happening.

Where is the problem?

Brian

On Sep 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com> wrote:

Hi all,

I=92m involved in the interop testing of early STIR impleme= ntations at Sipit, and we have quickly run into issues around understanding= how the sender has encoded the source/destination. One person=92s tn: is a= nother person=92s sip: URI; the rules from the draft simply assume that any purely-numeric user part is a telephone n= umber, which is not always the case in the real world. Without any context,= when you call a numeric alias in another domain, you have no idea whether = this maps to a telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but the sender thinks i= t=92s a SIP URI, then the Identity will not validate.

In short, I agree with Christer that the canon is far more = important than the draft suggests, and is needed whenever there could be an= y ambiguity about how a sender has encoded (or a receiver would encode) som= e of the data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and suggest the canon S= HOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment whe= re all entities that may be validating the Identity header have a common un= derstanding on its construction.

The second reason I think that future implementers would th= ank you for guidance like this is to enable extensibility. Say we wanted to= add protection of Display Name - and in the SIP world this is very importa= nt since endpoints will typically display only display name if it is present, so prov= ides a trivial way of bypassing human visual validation. Today, that would = be achieved by defining a new ppt that added this field. Which is all well = and good, but both the sender and the receiver would need to support this new ppt, and this is by no means guaranteed. So= for maximum compatibility what would a sender do? Should a sender include = multiple Identity headers of multiple ppts, hoping one is supported by the = far end? The overhead there would be huge. If canon was always included, then (and I=92m not saying this sho= uld necessarily be baseline spec, since it=92s too big a change at this sta= ge) a receiver could validate the signature of the canon, rather than recon= structing it, and then validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wr= ote:


The more values there are in a SIP request that are candidates for the iden= tity of the caller, the more likely we are going to entertain corner cases = like this. There is no guarantee that the canonicalized identity in the Fro= m header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there are= multiple PAIs there's no guarantee that they will all canonicalize to the = same form. Somehow, though, in those RFC3324 trust environments, you are su= pposed to be able to know which PAI contains the identity that you care about for this purpose, the identi= ty of the originator of the call. STIR can't tell you how to find that, onl= y local trust domain policy can. I don't think the burden is on STIR to mak= e this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will have= one value for the originating telephone number, say, and that will match t= he canonicalized form of one of those identities and not the others. If you= r trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy of s= ending "canon" with every call. I'm not sure there's much more to= say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Monday, September 12, 2016 at 10:31 AM To: Jon Peterson <jon.peterson@neustar.biz>, "stir@i= etf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: Why only RECOMMEND= when multiple identities?

Hi,
 
Ok, maybe =93multiple identities=94 was the wro= ng wording.
 
My point was that, even if you know you should = derive the identity from PAI instead of From, you can have two P-Asserted-I= dentity header fields, and as far as I understand there is no guarantee that the canonicalized form of those ma= tch.
 
Regards,
 
Christer
 
From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
Sent: 0= 9 September 2016 20:11
To: Chr= ister Holmberg <christer.holmber= g@ericsson.com>; <= a href=3D"mailto:stir@ietf.org" style=3D"color: purple; text-decoration: un= derline;" class=3D"">stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?
 
 
The only normative RECOMMEND in Section 8 is for cases "where lo= cal policy canonicalizes the identity into a form different form how it app= ears in the From header field." That doesn't have anything to do with multiple identities. The text in the previous sen= tence notes that it is talking about a case where "the canonical ident= ity derives from the P-Asserted-Identity field rather than the From header = field," not a case where identities based on both appear in different Identity headers.=
 
If P-Asserted-Identity is present, surely that's where you should be = looking for identity information. As I've argued several times in the past,= this is no more or less ambiguous than the practical use of P-Asserted-Identity in the field today: nothing about= the request tells you "use PAI instead of From" other than the p= resence of PAI. Because of all the RFC3324 trust domain stuff that Mark Wat= son talked us into back in the day, it's hard to say anything more than that it's a matter of local policy, as nothing a= bout the protocol tells you whether or not you are in an RFC3324 trust doma= in. Thus far, I gather this hasn't impeded the adoption of PAI. I did ask t= he WG in Berlin if we should include some more explicit indicator that would tell you that an Identity header c= ame from PAI rather than From, and the consensus was not to.
 
We are largely punting on why you might have multiple Identity header= s present in the same request: this is included for forward compatibility. = The most likely use cases are ones where extensions will differentiate the Identity headers. The recommendation to = include "canon" here just enables some potential implementation o= ptimizations (e.g. Verifier canonicalizes the identity in PAI, then compare= s to value in "canon" to save cycles before computing the identity string and checking for breakage).<= /o:p>
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg <= christer.holmberg@ericsson.com>
Date: F= riday, September 9, 2016 at 4:32 AM
To: &qu= ot;stir@ietf.org" <= stir@ietf.org>
Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my reading) th= at, if the SIP request contains multiple identities (e.g. if the request in= addition to the From header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to inclu= de =93canon=94, so that the verifier knows which identity to verify.
 
Why is this only RECOMMENDED? If there are more than one identity, sh= ouldn=92t it be a MUST? I don=92t think we want the verifier to try all ide= ntities, and see which one (if any) works, do we?
 
Now, the text DOES talk about =93local policy=94 when it comes to cho= osing between From and PAI for deriving the identity, so perhaps we could s= ay =93MUST, unless local policy defines from where the identity is retrieved=94, or something like that=85
 
Regards,
 
Christer
_______________________________________________
stir mailing list
stir@ietf.org
https://www.i= etf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://w= ww.ietf.org/mailman/listinfo/stir



 --_000_D40065331B345Ajonpetersonneustarbiz_-- From nobody Thu Sep 15 19:18:25 2016 Return-Path: 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 0959112B11A for ; Thu, 15 Sep 2016 19:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cVAJqRSZGRnQ for ; Thu, 15 Sep 2016 19:18:18 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7B712B109 for ; Thu, 15 Sep 2016 19:18:17 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so76300416qkc.3 for ; Thu, 15 Sep 2016 19:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Z/XCSGvRubrCI2WFK9vBap17gh+kiXnjWbGbYNOYYsE=; b=gxoBhh9DcO4z68BrihD9kWH+eWJGwAsqrkTK6b9Gsuay6WjNJraeAQmE68ifLH6/Ua 5DtBygwgDuRnEA8JJCul18Gap/UXBONB7aqDX/Fpl5mqzy4xKfJiNM8bX0HHiecdeg8Y RHJG+bNnst0igu/TW3nTSgEAERyWpaUw5tojzEZkp/955jZZI6mS1rcibZiEnaFuW+mW cf9kzNoMlP7l63MVkZvt837Kz/yxaK25BtS7NbDWIkPyvXXtqv26DrFVLJflAkaAsOOD J7+II0d8boqIuF8u8pnodN7u8Lp4oBuYoDbyJl01Y5AwmTonhtVgofHKb/iBcN8AJlJ6 to+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Z/XCSGvRubrCI2WFK9vBap17gh+kiXnjWbGbYNOYYsE=; b=H287nZ6kDfHFUgNJGZuP5R4sukF3TPi7DrfsX0MHp+CWsZqemU4HpRPCNHwrvGMaxz F9SzpLpHD2bcSyH5awtKQPUC2RjtzjEQfSZ2VdIqBYP8z+fSVHKzPD8v5WCsIwwaJE8M b3hn1wXovayZCQGcib2QAhYMVS348u3YgNUHOtp/xtHUzqtpOdJQY0HmhHTHw+QzCG8A K4BE33Ga3H3c/r6aOBHKKib3fA1ErOmyzRSIasNuoMSgsJ2iO7jMx4sO6Pp34ThNCvcv zI3qyVa3vFZqqNNyTNHGWw53jGcqa08xbdYCrA5B2nFxvtJOucRpNa44Eto9p6wkDXeI 8+Og== X-Gm-Message-State: AE9vXwOj4+TdSDDvno3o9AXnJ4R7tV6BtEJtIGW+5SlczG72X+eis6m3eNheAGY3atrFPA== X-Received: by 10.55.180.2 with SMTP id d2mr13122747qkf.175.1473992296777; Thu, 15 Sep 2016 19:18:16 -0700 (PDT) Received: from [192.168.5.190] (50-199-227-29-static.hfc.comcastbusiness.net. [50.199.227.29]) by smtp.gmail.com with ESMTPSA id p26sm3466507qkh.42.2016.09.15.19.18.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Sep 2016 19:18:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_12465A1B-41A6-4E39-9E48-DFF7F04BD55C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Fri, 16 Sep 2016 03:18:13 +0100 Message-Id: <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 02:18:23 -0000 --Apple-Mail=_12465A1B-41A6-4E39-9E48-DFF7F04BD55C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the detailed clarifications, Jon. My issue is indeed with the = idea that two independent canonicalisation procedures may come up with = different answers, thus negating any benefit from this scheme. I had not = considered the idea of looking at the the signing CA and determining = behaviour based on this - if it looks like a cert that would authorise a = tn: then canonicalise as a tn:, else canonicalise as a sip: URI. I think = this would probably resolve most issues around my primary concern here, = although it=92s not particularly efficient, but if this was the case = then this is something that needs to be spelled out more clearly = (including the logic around determining whether a CA Is appropriate for = tn: canonicalisation). However, I still share Christer=92s original concerns about selection of = URIs for multiple identities. My view after our interop testing and = investigating real-world deployment is that mandating the use of canon = in these situations would significantly help validation. Jumping back to your earlier mail, some further thoughts inline: > A =46rom identity (or a PAI identity) is expected to contain an = address-of-record of the originator of the request. If some really = unhelpful URI that is only resolvable locally is used as the From, then = we should expect there to be problems in ordinary SIP operations if the = request escapes that local environment. The whole point of including an = AoR as your public identity is that someone who sees it can dereference = it, and through standard routing procedures (in baseline SIP we mean = RFC3263) you'll end up reaching the right user agents(). If you aren't = operating within those constraints, I don't think that's really = something that RFC4474bis can fix. This is a concern right here, however. Do you use =46rom or PAI? Which = PAI if there=92s more than one? Or do you include all of them? If so, in = what order? What about Remote-Party-ID? Without including a canon this = is very difficult to validate. [...] > At the end of the day, if you are on the receiving side, you are left = to inspect whatever is left after intermediaries get through with the = message. This remains one of the most important reasons that "canon" = (which now means carrying the header and payload PASSporT objects) is = optional: the philosophy behind canonicalization is that what matters = isn't some value that the authentication service mandates, but instead = how the two sides understand the numbers as they receive them. The = originating side may initially direct the request to some local seven = digital telephone number: but by the time that gets to the terminating = side, a country code and area code might be added to it. They both = "mean" the same number, and the authentication service that signs the = request exercises the canonicalization process in order to capture what = it thinks the originator "meant" for the global environment. I don=92t follow why this is an argument against carrying the canon. Or = are you saying that the receiver has its own canonicalisation process it = should be able to determine from the headers the source or destination = that the originator originally intended? If so, that=92s assuming a lot = of shared knowledge after headers have been mangled! But if the canon = was included, then this could provide hints in such a situation and the = receiver could know whether the field values it sees matches the = intended value as shown in the canon, rather than guessing! > Moreover, to your specific argument, here's the rub: because this is a = security function, carrying the canonical value in "canon" cannot really = help unless the verification service already knows how to turn the value = already in the =46rom (or PAI or whatever) into the canonical value = anyway. Why not? Because if I get a =46rom with = "sip:0020121421@example.com " and the = PASSporT object in canon says the orig is a tn value "12012142102", how = is the verification service supposed to know whether or not this is a = cut-and-paste attack? If the verification service just blindly trusted = that the contents of the PASSporT object's orig were equivalent to the = URI in the From, it would never be able to tell whether or not the = PASSporT object actually belonged with this call. I completely agree. I see the canon as a way of telling the receiver = =93this is what I encoded=94. This allows the receiver to easily verify = whether a) the values now present in the headers can be mapped to the = values in the PASSporT object (as shared by the canon) by local logic of = the verification service; and b) if there is the potential for confusion = (multiple source/dest options, or multiple encodings for source/dest), = this clarifies which one was chosen. > The value of "canon" is only there for debugging and optimization = purposes, we say this many times in the spec. It is NOT there to tunnel = some "secret" value for the telephone number between the authentication = service and verification service, as that would be a huge security hole. = And it wouldn't work anyway because as I said above intermediaries could = just change it. The neat thing about not including "canon" is that = intermediaries can't change something that isn't in the message. This = was effectively the argument Hadriel and others made back in the day. Sorry, I don=92t follow any of the above. Including canon does not add = any security hole, it does not allow intermediaries to change anything, = since it is protected by the signature. A receiver can receive the = canon, validate the signature against the canon, and then validate the = fields. This makes much more sense from an implementation point of view = than trying to guess the construction of the PASSporT object from the = fields in the SIP message, and then seeing if this validates. > You can argue that the verification service will sometimes not have = sufficient information to arrive at the same canonicalization as the = authentication service, and I agree. In some cases it won't: like when = calls escape from really opaque private branches, or in if one end is in = some weird variable-length dialing plan, or if a nationally-specific = service number is used, or whatever. I just think that in order for = those calls to realistically get routed and expect identity to work, = they need to express identifiers in a way that is actually useful to the = rest of the world. Absolutely agreed, and therefore in all these circumstances SIP URIs = would be used for the encoding. The problem I raised is more with = receivers. How do receivers know how the sender encoded it? Regards, Alan > On 15 Sep 2016, at 22:52, Peterson, Jon = wrote: >=20 >=20 > I took Alan's mail to be speaking to the much more general problem of = why we perform two independent canonicalization passes at all, if in = some cases it is impossible for the terminating side to know what the = originating side meant. >=20 > I don't disagree that the signing credential, and its scope of = authority, can give you an indication of which kind of identity the = originating side thinks its signing for. I'm not sure even that will = ever be entirely free of potential ambiguity; I could construct some = corner cases where a certificate has both a subjectAltName and a = TNAuthorizationList, say. But if you're saying it's worth mentioning = that the signing credential can provide a hint, we could put in some = text to that effect. >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Brian Rosen > > Date: Thursday, September 15, 2016 at 2:28 PM > To: Jon Peterson > > Cc: Alan Ford >, = "stir@ietf.org " >, Christer Holmberg = > > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >=20 >> I understood the problem to be: >> sip:414428123@example.com is a perfectly = valid SIP URI, which, if called would get to the right person. = 414428123 however, is not a telephone number, it=92s a userId, and a = valid userId within the example.com domain. If = the receiving end tries to canonicalize that digit string, and use that = as the identity, it will fail. It has to use the entire SIP URI as the = identity. >>=20 >> And I think the solution is the domain of the credential. >>=20 >> Brian >>=20 >>=20 >>> On Sep 15, 2016, at 4:51 PM, Peterson, Jon > wrote: >>>=20 >>>=20 >>> I don't think I agree with either the framing of the problem or the = proposed solution here (for the first problem in Alan's mail); but to = dig in to this, we need to go back to the first principles of = canonicalizing phone numbers. >>>=20 >>> A =46rom identity (or a PAI identity) is expected to contain an = address-of-record of the originator of the request. If some really = unhelpful URI that is only resolvable locally is used as the From, then = we should expect there to be problems in ordinary SIP operations if the = request escapes that local environment. The whole point of including an = AoR as your public identity is that someone who sees it can dereference = it, and through standard routing procedures (in baseline SIP we mean = RFC3263) you'll end up reaching the right user agents(). If you aren't = operating within those constraints, I don't think that's really = something that RFC4474bis can fix. >>>=20 >>> A To identity expresses the AoR you are trying to reach. We already = have a split in baseline SIP between the To and the Request-URI, because = SIP recognizes that the target of a request is likely to be dynamic: in = baseline SIP, the To is supposed to be immutable, and the Request-URI is = supposed to support hard changes. >>>=20 >>> When it comes to rfc4474bis, the idea of having both sides run their = own independent canonicalization of the telephone number arose because = deployment experience suggests that intermediaries in fact modify = telephone numbers in transit in various ways, be they found in the To = and =46rom header field values or wherever else. This meddling includes = thing like removing visual separators, but also includes adding and = subtracting suffixes and prefixes as necessary to render the telephone = number or URI there globally reachable and meaningful. Or in some cases, = it includes nulling them out entirely because some other header (like = PAI) is doing their job in a way that the intermediary likes better. = Nothing that we do on the originating side will prevent intermediaries = that want to alter these numbers form doing so -- including sticking = them in a PASSporT object we tunnel in the SIP request. All that would = do is encourage those intermediaries to change the numbers in the = PASSporT object too. Like, years ago, we entertained just having a new = SIP header field that would contain the canonical number as the = authentication service saw it - but merely adding another field cannot = get around the intermediaries: they will know it's there and they will = do what they want to it. "canon" has no magic powers that would save it = from the same fate. >>>=20 >>> At the end of the day, if you are on the receiving side, you are = left to inspect whatever is left after intermediaries get through with = the message. This remains one of the most important reasons that "canon" = (which now means carrying the header and payload PASSporT objects) is = optional: the philosophy behind canonicalization is that what matters = isn't some value that the authentication service mandates, but instead = how the two sides understand the numbers as they receive them. The = originating side may initially direct the request to some local seven = digital telephone number: but by the time that gets to the terminating = side, a country code and area code might be added to it. They both = "mean" the same number, and the authentication service that signs the = request exercises the canonicalization process in order to capture what = it thinks the originator "meant" for the global environment. >>>=20 >>> Moreover, to your specific argument, here's the rub: because this is = a security function, carrying the canonical value in "canon" cannot = really help unless the verification service already knows how to turn = the value already in the =46rom (or PAI or whatever) into the canonical = value anyway. Why not? Because if I get a =46rom with = "sip:0020121421@example.com " and the = PASSporT object in canon says the orig is a tn value "12012142102", how = is the verification service supposed to know whether or not this is a = cut-and-paste attack? If the verification service just blindly trusted = that the contents of the PASSporT object's orig were equivalent to the = URI in the From, it would never be able to tell whether or not the = PASSporT object actually belonged with this call. The value of "canon" = is only there for debugging and optimization purposes, we say this many = times in the spec. It is NOT there to tunnel some "secret" value for the = telephone number between the authentication service and verification = service, as that would be a huge security hole. And it wouldn't work = anyway because as I said above intermediaries could just change it. The = neat thing about not including "canon" is that intermediaries can't = change something that isn't in the message. This was effectively the = argument Hadriel and others made back in the day. >>>=20 >>> You can argue that the verification service will sometimes not have = sufficient information to arrive at the same canonicalization as the = authentication service, and I agree. In some cases it won't: like when = calls escape from really opaque private branches, or in if one end is in = some weird variable-length dialing plan, or if a nationally-specific = service number is used, or whatever. I just think that in order for = those calls to realistically get routed and expect identity to work, = they need to express identifiers in a way that is actually useful to the = rest of the world. We formerly had some text in rfc4474bis that = recommended (against the normative guidance of RFC3261, incidentally) = that authentication services alter the To and =46rom header fields to = conform with the canonicalizations that they performed if those changes = warranted notice. Ultimately, though, I took that out because the = potential intermediary interference after the fact makes it moot. The = question is not whether the verification service trusts the bits the = authentication service claims it saw, the question is whether or not the = verification service can derive an identity equal to that from the = values it sees in the SIP request. >>>=20 >>> Ultimately, implementations need to use numbers in a sane way in = order to have any expectation that SIP will work. In those cases where = the use of numbers is sane enough that SIP will work, then I think = Identity will probably work too. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> From: Alan Ford > >>> Date: Thursday, September 15, 2016 at 12:06 PM >>> To: Brian Rosen > >>> Cc: Jon Peterson >, "stir@ietf.org = " >, Christer = Holmberg > >>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>=20 >>>> Hi Brian, >>>>=20 >>>> The problem is on the receiving end. I see a number as the source = or destination, and decide it=92s a tn: so try to construct a passport = object with a tn: and validate it as such, but this fails. This is = because the sender sent it as a sip: URI instead. But because there=92s = no canon, I don=92t know how to reconstruct the passport so can=92t = validate. >>>>=20 >>>> Regards, >>>> Alan >>>>=20 >>>>> On 15 Sep 2016, at 20:01, Brian Rosen > wrote: >>>>>=20 >>>>> Okay, got it. Pity the poor blokes who have to DTMF these = extensions, but I get it. >>>>>=20 >>>>> So, what really is correct behavior here? The call is sent with = an internal extension as a SIP URI, the mechanism tries to set an = Identity header, and what? >>>>>=20 >>>>> If it does not have a credential for that TN, it shouldn=92t be = trying to sign using a TN credential. >>>>>=20 >>>>> If it has a credential for the SIP ID, then the scope of that = credential wouldn=92t be a telephone number, it would be a domain, and = the recipient should be able to figure out what is happening. >>>>>=20 >>>>> Where is the problem? >>>>>=20 >>>>> Brian >>>>>=20 >>>>>> On Sep 15, 2016, at 2:40 PM, Alan Ford > wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I=92m involved in the interop testing of early STIR = implementations at Sipit, and we have quickly run into issues around = understanding how the sender has encoded the source/destination. One = person=92s tn: is another person=92s sip: URI; the rules from the draft = simply assume that any purely-numeric user part is a telephone number, = which is not always the case in the real world. Without any context, = when you call a numeric alias in another domain, you have no idea = whether this maps to a telephone number or a SIP URI. If the receiver = thinks it=92s a tn:, but the sender thinks it=92s a SIP URI, then the = Identity will not validate. >>>>>>=20 >>>>>> In short, I agree with Christer that the canon is far more = important than the draft suggests, and is needed whenever there could be = any ambiguity about how a sender has encoded (or a receiver would = encode) some of the data (which, frankly, is most B2B scenarios). >>>>>>=20 >>>>>> Indeed, I would go probably further and suggest the canon SHOULD = always be included, - i.e. MUST, unless it is known to be operating = within a controlled environment where all entities that may be = validating the Identity header have a common understanding on its = construction. >>>>>>=20 >>>>>> The second reason I think that future implementers would thank = you for guidance like this is to enable extensibility. Say we wanted to = add protection of Display Name - and in the SIP world this is very = important since endpoints will typically display only display name if it = is present, so provides a trivial way of bypassing human visual = validation. Today, that would be achieved by defining a new ppt that = added this field. Which is all well and good, but both the sender and = the receiver would need to support this new ppt, and this is by no means = guaranteed. So for maximum compatibility what would a sender do? Should = a sender include multiple Identity headers of multiple ppts, hoping one = is supported by the far end? The overhead there would be huge. If canon = was always included, then (and I=92m not saying this should necessarily = be baseline spec, since it=92s too big a change at this stage) a = receiver could validate the signature of the canon, rather than = reconstructing it, and then validate field-by-field for the fields it = cares/knows about. >>>>>>=20 >>>>>> Regards, >>>>>> Alan >>>>>>=20 >>>>>>> On 13 Sep 2016, at 23:30, Peterson, Jon = > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> The more values there are in a SIP request that are candidates = for the identity of the caller, the more likely we are going to = entertain corner cases like this. There is no guarantee that the = canonicalized identity in the =46rom header field will be identical to = one in PAI - why carry PAI if it would be? - and similarly if there are = multiple PAIs there's no guarantee that they will all canonicalize to = the same form. Somehow, though, in those RFC3324 trust environments, you = are supposed to be able to know which PAI contains the identity that you = care about for this purpose, the identity of the originator of the call. = STIR can't tell you how to find that, only local trust domain policy = can. I don't think the burden is on STIR to make this unambiguous when = apparently the trust domains already can and do. >>>>>>>=20 >>>>>>> But, of course, when carrying the "canon" parameter, it will = have one value for the originating telephone number, say, and that will = match the canonicalized form of one of those identities and not the = others. If your trust domain introduces this ambiguity into every call, = then your trust domain should probably set a local policy of sending = "canon" with every call. I'm not sure there's much more to say about it = than that in the core specs, though. >>>>>>>=20 >>>>>>> Jon Peterson >>>>>>> Neustar, Inc. >>>>>>>=20 >>>>>>> From: Christer Holmberg > >>>>>>> Date: Monday, September 12, 2016 at 10:31 AM >>>>>>> To: Jon Peterson >, "stir@ietf.org = " > >>>>>>> Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>>>>>=20 >>>>>>>> Hi, >>>>>>>> =20 >>>>>>>> Ok, maybe =93multiple identities=94 was the wrong wording. >>>>>>>> =20 >>>>>>>> My point was that, even if you know you should derive the = identity from PAI instead of From, you can have two P-Asserted-Identity = header fields, and as far as I understand there is no guarantee that the = canonicalized form of those match. >>>>>>>> =20 >>>>>>>> Regards, >>>>>>>> =20 >>>>>>>> Christer >>>>>>>> =A0 <> >>>>>>>> From: Peterson, Jon [mailto:jon.peterson@neustar.biz = ]=20 >>>>>>>> Sent: 09 September 2016 20:11 >>>>>>>> To: Christer Holmberg >; stir@ietf.org = >>>>>>>> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> The only normative RECOMMEND in Section 8 is for cases "where = local policy canonicalizes the identity into a form different form how = it appears in the =46rom header field." That doesn't have anything to do = with multiple identities. The text in the previous sentence notes that = it is talking about a case where "the canonical identity derives from = the P-Asserted-Identity field rather than the =46rom header field," not = a case where identities based on both appear in different Identity = headers. >>>>>>>> =20 >>>>>>>> If P-Asserted-Identity is present, surely that's where you = should be looking for identity information. As I've argued several times = in the past, this is no more or less ambiguous than the practical use of = P-Asserted-Identity in the field today: nothing about the request tells = you "use PAI instead of From" other than the presence of PAI. Because of = all the RFC3324 trust domain stuff that Mark Watson talked us into back = in the day, it's hard to say anything more than that it's a matter of = local policy, as nothing about the protocol tells you whether or not you = are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded = the adoption of PAI. I did ask the WG in Berlin if we should include = some more explicit indicator that would tell you that an Identity header = came from PAI rather than From, and the consensus was not to. >>>>>>>> =20 >>>>>>>> We are largely punting on why you might have multiple Identity = headers present in the same request: this is included for forward = compatibility. The most likely use cases are ones where extensions will = differentiate the Identity headers. The recommendation to include = "canon" here just enables some potential implementation optimizations = (e.g. Verifier canonicalizes the identity in PAI, then compares to value = in "canon" to save cycles before computing the identity string and = checking for breakage). >>>>>>>> =20 >>>>>>>> Jon Peterson >>>>>>>> Neustar, Inc. >>>>>>>> =20 >>>>>>>> From: stir > on behalf of Christer Holmberg = > >>>>>>>> Date: Friday, September 9, 2016 at 4:32 AM >>>>>>>> To: "stir@ietf.org " > >>>>>>>> Subject: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >>>>>>>> =20 >>>>>>>>> Hi, >>>>>>>>> =20 >>>>>>>>> Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more = P-Asserted-Identity header fields), it is RECOMMENDED to include = =93canon=94, so that the verifier knows which identity to verify. >>>>>>>>> =20 >>>>>>>>> Why is this only RECOMMENDED? If there are more than one = identity, shouldn=92t it be a MUST? I don=92t think we want the verifier = to try all identities, and see which one (if any) works, do we? >>>>>>>>> =20 >>>>>>>>> Now, the text DOES talk about =93local policy=94 when it comes = to choosing between =46rom and PAI for deriving the identity, so perhaps = we could say =93MUST, unless local policy defines from where the = identity is retrieved=94, or something like that=85 >>>>>>>>> =20 >>>>>>>>> Regards, >>>>>>>>> =20 >>>>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> stir mailing list >>>>>>> stir@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/stir = >>>>>> _______________________________________________ >>>>>> stir mailing list >>>>>> stir@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/stir = >>>>>=20 >>>>=20 >>=20 --Apple-Mail=_12465A1B-41A6-4E39-9E48-DFF7F04BD55C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks for the detailed clarifications, Jon. My issue is = indeed with the idea that two independent canonicalisation procedures = may come up with different answers, thus negating any benefit from this = scheme. I had not considered the idea of looking at the the signing CA = and determining behaviour based on this - if it looks like a cert that = would authorise a tn: then canonicalise as a tn:, else canonicalise as a = sip: URI. I think this would probably resolve most issues around my = primary concern here, although it=92s not particularly efficient, but if = this was the case then this is something that needs to be spelled out = more clearly (including the logic around determining whether a CA Is = appropriate for tn: canonicalisation).

However, I still share Christer=92s = original concerns about selection of URIs for multiple identities. My = view after our interop testing and investigating real-world deployment = is that mandating the use of canon in these situations would = significantly help validation.

Jumping back to your earlier mail, some = further thoughts inline:

A =46rom identity (or = a PAI identity) is expected to contain an address-of-record of the = originator of the request. If some really unhelpful URI that is only = resolvable locally is used as the From, then we should expect there to = be problems in ordinary SIP operations if the request escapes that local = environment. The whole point of including an AoR as your public identity = is that someone who sees it can dereference it, and through standard = routing procedures (in baseline SIP we mean RFC3263) you'll end up = reaching the right user agents(). If you aren't operating within those = constraints, I don't think that's really something that RFC4474bis can = fix.

This is a concern right here, however. Do you use =46rom or = PAI? Which PAI if there=92s more than one? Or do you include all of = them? If so, in what order? What about Remote-Party-ID? Without = including a canon this is very difficult to validate.

[...]

At the end of the = day, if you are on the receiving side, you are left to inspect whatever = is left after intermediaries get through with the message. This remains = one of the most important reasons that "canon" (which now means carrying = the header and payload PASSporT objects) is optional: the philosophy = behind canonicalization is that what matters isn't some value that the = authentication service mandates, but instead how the two sides = understand the numbers as they receive them. The originating side may = initially direct the request to some local seven digital telephone = number: but by the time that gets to the terminating side, a country = code and area code might be added to it. They both "mean" the same = number, and the authentication service that signs the request exercises = the canonicalization process in order to capture what it thinks the = originator "meant" for the global environment.

I don=92t follow why = this is an argument against carrying the canon. Or are you saying that = the receiver has its own canonicalisation process it should be able to = determine from the headers the source or destination that the originator = originally intended? If so, that=92s assuming a lot of shared knowledge = after headers have been mangled! But if the canon was included, then = this could provide hints in such a situation and the receiver could know = whether the field values it sees matches the intended value as shown in = the canon, rather than guessing!

Moreover, to your specific argument, here's = the rub: because this is a security function, carrying the canonical = value in "canon" cannot really help unless the verification service = already knows how to turn the value already in the =46rom (or PAI or = whatever) into the canonical value anyway. Why not? Because if I get a = =46rom with "sip:0020121421@example.com" and the PASSporT object in = canon says the orig is a tn value "12012142102", how is the verification = service supposed to know whether or not this is a cut-and-paste attack? = If the verification service just blindly trusted that the contents of = the PASSporT object's orig were equivalent to the URI in the From, it = would never be able to tell whether or not the PASSporT object actually = belonged with this call.

I completely agree. I see the canon as = a way of telling the receiver =93this is what I encoded=94. This allows = the receiver to easily verify whether a) the values now present in the = headers can be mapped to the values in the PASSporT object (as shared by = the canon) by local logic of the verification service; and b) if there = is the potential for confusion (multiple source/dest options, or = multiple encodings for source/dest), this clarifies which one was = chosen.

The value of "canon" is only there for debugging and = optimization purposes, we say this many times in the spec. It is NOT = there to tunnel some "secret" value for the telephone number between the = authentication service and verification service, as that would be a huge = security hole. And it wouldn't work anyway because as I said above = intermediaries could just change it. The neat thing about not including = "canon" is that intermediaries can't change something that isn't in the = message. This was effectively the argument Hadriel and others made back = in the day.

Sorry, I don=92t follow any of the above. Including canon = does not add any security hole, it does not allow intermediaries to = change anything, since it is protected by the signature. A receiver can = receive the canon, validate the signature against the = canon, and then validate the fields. This makes much more sense from = an implementation point of view than trying to guess the construction of = the PASSporT object from the fields in the SIP message, and then seeing = if this validates.

You can argue that the verification service will = sometimes not have sufficient information to arrive at the same = canonicalization as the authentication service, and I agree. In some = cases it won't: like when calls escape from really opaque private = branches, or in if one end is in some weird variable-length dialing = plan, or if a nationally-specific service number is used, or whatever. I = just think that in order for those calls to realistically get routed and = expect identity to work, they need to express identifiers in a way that = is actually useful to the rest of the world.

Absolutely agreed, and = therefore in all these circumstances SIP URIs would be used for the = encoding. The problem I raised is more with receivers. How do receivers = know how the sender encoded it?

Regards,
Alan


On = 15 Sep 2016, at 22:52, Peterson, Jon <jon.peterson@neustar.biz> wrote:


I took Alan's mail to be speaking to the much more = general problem of why we perform two independent canonicalization = passes at all, if in some cases it is impossible for the terminating = side to know what the originating side meant.

I don't disagree that the signing credential, and its = scope of authority, can give you an indication of which kind of identity = the originating side thinks its signing for. I'm not sure even that will = ever be entirely free of potential ambiguity; I could construct some corner cases where a certificate has both a = subjectAltName and a TNAuthorizationList, say. But if you're saying it's = worth mentioning that the signing credential can provide a hint, we = could put in some text to that effect.

Jon Peterson
Neustar, Inc.

From: Brian Rosen = <br@brianrosen.net>
Date: Thursday, = September 15, 2016 at 2:28 PM
To: Jon Peterson = <jon.peterson@neustar.biz>
Cc: Alan Ford <alan.ford@gmail.com>, "stir@ietf.org" <stir@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [stir] = 4474bis: Why only RECOMMEND when multiple identities?

I understood the problem to be:
sip:414428123@example.com is a perfectly valid SIP URI, = which, if called would get to the right person.  414428123 however, = is not a telephone number, it=92s a userId, and a valid userId within = the example.com domain. =  If the receiving end tries to canonicalize that digit string, and = use that as the identity, it will fail. It has to use the entire SIP URI = as the identity.

And I think the solution is the domain of the = credential.

Brian


On Sep 15, 2016, at 4:51 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:


I don't think I agree with either the framing of the = problem or the proposed solution here (for the first problem in Alan's = mail); but to dig in to this, we need to go back to the first principles = of canonicalizing phone numbers.

A =46rom identity (or a PAI identity) is expected to = contain an address-of-record of the originator of the request. If some = really unhelpful URI that is only resolvable locally is used as the = From, then we should expect there to be problems in ordinary SIP operations if the request escapes that local environment. The whole = point of including an AoR as your public identity is that someone who = sees it can dereference it, and through standard routing procedures (in = baseline SIP we mean RFC3263) you'll end up reaching the right user agents(). If you aren't operating within those = constraints, I don't think that's really something that RFC4474bis can = fix.

A To identity expresses the AoR you are trying to reach. = We already have a split in baseline SIP between the To and the = Request-URI, because SIP recognizes that the target of a request is = likely to be dynamic: in baseline SIP, the To is supposed to be immutable, and the Request-URI is supposed to support hard = changes.

When it comes to rfc4474bis, the idea of having both = sides run their own independent canonicalization of the telephone number = arose because deployment experience suggests that intermediaries in fact = modify telephone numbers in transit in various ways, be they found in the To and =46rom header field values or = wherever else. This meddling includes thing like removing visual = separators, but also includes adding and subtracting suffixes and = prefixes as necessary to render the telephone number or URI there globally reachable and meaningful. Or in some cases, it includes = nulling them out entirely because some other header (like PAI) is doing = their job in a way that the intermediary likes better. Nothing that we = do on the originating side will prevent intermediaries that want to alter these numbers form doing so -- including sticking = them in a PASSporT object we tunnel in the SIP request. All that would = do is encourage those intermediaries to change the numbers in the = PASSporT object too. Like, years ago, we entertained just having a new SIP header field that would contain the canonical = number as the authentication service saw it - but merely adding another = field cannot get around the intermediaries: they will know it's there = and they will do what they want to it. "canon" has no magic powers that would save it from the same fate.

At the end of the day, if you are on the receiving side, = you are left to inspect whatever is left after intermediaries get = through with the message. This remains one of the most important reasons = that "canon" (which now means carrying the header and payload PASSporT objects) is optional: the philosophy behind = canonicalization is that what matters isn't some value that the = authentication service mandates, but instead how the two sides = understand the numbers as they receive them. The originating side may initially direct the request to some local seven digital telephone = number: but by the time that gets to the terminating side, a country = code and area code might be added to it. They both "mean" the same = number, and the authentication service that signs the request exercises the canonicalization process in order to capture = what it thinks the originator "meant" for the global environment.

Moreover, to your specific argument, here's the rub: = because this is a security function, carrying the canonical value in = "canon" cannot really help unless the verification service already knows = how to turn the value already in the =46rom (or PAI or whatever) into the canonical value anyway. Why not? Because if I get = a =46rom with "sip:0020121421@example.com" and the PASSporT object in = canon says the orig is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? = If the verification service just blindly trusted that the contents of = the PASSporT object's orig were equivalent to the URI in the From, it = would never be able to tell whether or not the PASSporT object actually belonged with this call. The value of "canon" = is only there for debugging and optimization purposes, we say this many = times in the spec. It is NOT there to tunnel some "secret" value for the = telephone number between the authentication service and verification service, as that would be a huge security = hole. And it wouldn't work anyway because as I said above intermediaries = could just change it. The neat thing about not including "canon" is that = intermediaries can't change something that isn't in the message. This was effectively the argument Hadriel and = others made back in the day.

You can argue that the verification service will = sometimes not have sufficient information to arrive at the same = canonicalization as the authentication service, and I agree. In some = cases it won't: like when calls escape from really opaque private branches, or in if one end is in some weird variable-length dialing = plan, or if a nationally-specific service number is used, or whatever. I = just think that in order for those calls to realistically get routed and = expect identity to work, they need to express identifiers in a way that is actually useful to the rest of the world. = We formerly had some text in rfc4474bis that recommended (against the = normative guidance of RFC3261, incidentally) that authentication = services alter the To and =46rom header fields to conform with the canonicalizations that they performed if those changes = warranted notice. Ultimately, though, I took that out because the = potential intermediary interference after the fact makes it moot. The = question is not whether the verification service trusts the bits the authentication service claims it saw, the question is = whether or not the verification service can derive an identity equal to = that from the values it sees in the SIP request.

Ultimately, implementations need to use numbers in a = sane way in order to have any expectation that SIP will work. In those = cases where the use of numbers is sane enough that SIP will work, then I = think Identity will probably work too.

Jon Peterson
Neustar, Inc.

From: Alan Ford = <alan.ford@gmail.com>
Date: Thursday, = September 15, 2016 at 12:06 PM
To: Brian Rosen = <br@brianrosen.net>
Cc: Jon Peterson = <jon.peterson@neustar.biz>, "stir@ietf.org" <stir@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [stir] = 4474bis: Why only RECOMMEND when multiple identities?

Hi Brian,

The problem is on the receiving end. I see a number as = the source or destination, and decide it=92s a tn: so try to construct a = passport object with a tn: and validate it as such, but this fails. This = is because the sender sent it as a sip: URI instead. But because there=92s no canon, I don=92t know how to = reconstruct the passport so can=92t validate.

Regards,
Alan

On 15 Sep 2016, at 20:01, Brian Rosen <br@brianrosen.net> = wrote:

Okay, got it.  Pity the poor blokes who have to DTMF these = extensions, but I get it.

So, what really is correct behavior here?  The call = is sent with an internal extension as a SIP URI, the mechanism tries to = set an Identity header, and what?

If it does not have a credential for that TN, it = shouldn=92t be trying to sign using a TN credential.

If it has a credential for the SIP ID, then the scope of = that credential wouldn=92t be a telephone number, it would be a domain, = and the recipient should be able to figure out what is happening.

Where is the problem?

Brian

On Sep 15, 2016, at 2:40 PM, Alan Ford <alan.ford@gmail.com>= wrote:

Hi all,

I=92m involved in the interop testing of early STIR = implementations at Sipit, and we have quickly run into issues around = understanding how the sender has encoded the source/destination. One = person=92s tn: is another person=92s sip: URI; the rules from the draft simply assume that any purely-numeric user part is a = telephone number, which is not always the case in the real world. = Without any context, when you call a numeric alias in another domain, = you have no idea whether this maps to a telephone number or a SIP URI. If the receiver thinks it=92s a tn:, but the sender = thinks it=92s a SIP URI, then the Identity will not validate.

In short, I agree with Christer that the canon is far = more important than the draft suggests, and is needed whenever there = could be any ambiguity about how a sender has encoded (or a receiver = would encode) some of the data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and suggest the = canon SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment = where all entities that may be validating the Identity header have a = common understanding on its construction.

The second reason I think that future implementers would = thank you for guidance like this is to enable extensibility. Say we = wanted to add protection of Display Name - and in the SIP world this is = very important since endpoints will typically display only display name if it is present, so = provides a trivial way of bypassing human visual validation. Today, that = would be achieved by defining a new ppt that added this field. Which is = all well and good, but both the sender and the receiver would need to support this new ppt, and this is by no means guaranteed. = So for maximum compatibility what would a sender do? Should a sender = include multiple Identity headers of multiple ppts, hoping one is = supported by the far end? The overhead there would be huge. If canon was always included, then (and I=92m not saying this = should necessarily be baseline spec, since it=92s too big a change at = this stage) a receiver could validate the signature of the canon, rather = than reconstructing it, and then validate field-by-field for the fields it cares/knows about.

Regards,
Alan

On 13 Sep 2016, at 23:30, Peterson, Jon <jon.peterson@neustar.biz> wrote:


The more values there are in a SIP request that are candidates for the = identity of the caller, the more likely we are going to entertain corner = cases like this. There is no guarantee that the canonicalized identity = in the =46rom header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there = are multiple PAIs there's no guarantee that they will all canonicalize = to the same form. Somehow, though, in those RFC3324 trust environments, = you are supposed to be able to know which PAI contains the identity that you care about for this purpose, the = identity of the originator of the call. STIR can't tell you how to find = that, only local trust domain policy can. I don't think the burden is on = STIR to make this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will have one = value for the originating telephone number, say, and that will match the = canonicalized form of one of those identities and not the others. If = your trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy = of sending "canon" with every call. I'm not sure there's much more to = say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Monday, September = 12, 2016 at 10:31 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] 4474bis: = Why only RECOMMEND when multiple identities?

Hi,
 
Ok, maybe =93multiple identities=94 was = the wrong wording.
 
My point was that, even if you know you = should derive the identity from PAI instead of From, you can have two = P-Asserted-Identity header fields, and as far as I understand there is no guarantee that the canonicalized form of those = match.
 
Regards,
 
Christer
 
From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
Sent: 09 September 2016 20:11
To: Christer Holmberg <christer.holmberg@ericsson.com>; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
 
The only normative RECOMMEND in Section 8 is for cases "where = local policy canonicalizes the identity into a form different form how = it appears in the =46rom header field." That doesn't have anything to do with multiple identities. The text in the previous = sentence notes that it is talking about a case where "the canonical = identity derives from the P-Asserted-Identity field rather than the =46rom= header field," not a case where identities based on both appear in different Identity headers.
 
If P-Asserted-Identity is present, surely that's where you = should be looking for identity information. As I've argued several times = in the past, this is no more or less ambiguous than the practical use of P-Asserted-Identity in the field today: nothing = about the request tells you "use PAI instead of From" other than the = presence of PAI. Because of all the RFC3324 trust domain stuff that Mark = Watson talked us into back in the day, it's hard to say anything more than that it's a matter of local policy, as = nothing about the protocol tells you whether or not you are in an = RFC3324 trust domain. Thus far, I gather this hasn't impeded the = adoption of PAI. I did ask the WG in Berlin if we should include some more explicit indicator that would tell you that an Identity = header came from PAI rather than From, and the consensus was not to.
 
We are largely punting on why you might have multiple = Identity headers present in the same request: this is included for = forward compatibility. The most likely use cases are ones where extensions will differentiate the Identity headers. The recommendation = to include "canon" here just enables some potential implementation = optimizations (e.g. Verifier canonicalizes the identity in PAI, then = compares to value in "canon" to save cycles before computing the identity string and checking for breakage).
 
Jon Peterson
Neustar, Inc.
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, September 9, = 2016 at 4:32 AM
To: "stir@ietf.org" <stir@ietf.org>
Subject: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi,
 
Section 8 of draft-4474bis says (or, that=92s at least my = reading) that, if the SIP request contains multiple identities (e.g. if = the request in addition to the =46rom header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to = include =93canon=94, so that the verifier knows which identity to = verify.
 
Why is this only RECOMMENDED? If there are more than one = identity, shouldn=92t it be a MUST? I don=92t think we want the verifier = to try all identities, and see which one (if any) works, do we?
 
Now, the text DOES talk about =93local policy=94 when it = comes to choosing between =46rom and PAI for deriving the identity, so = perhaps we could say =93MUST, unless local policy defines from where the identity is retrieved=94, or something like that=85
 
Regards,
 
Christer
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_12465A1B-41A6-4E39-9E48-DFF7F04BD55C-- From nobody Thu Sep 15 22:19:19 2016 Return-Path: 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 92D0B12B0C7 for ; Thu, 15 Sep 2016 22:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 6scmkE1auKHm for ; Thu, 15 Sep 2016 22:19:15 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAED12B0B6 for ; Thu, 15 Sep 2016 22:19:15 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8G5CikM022400; Fri, 16 Sep 2016 01:19:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=+domu4hagwQXHJPI8eO0CG1G50x+p9bFmOZP4qSMgdA=; b=o9YOf7127JazmRpSjMeWkWN1sjBjSHdyngVu2R455OcSih0n5CNjEdB8/FHx1Z2gdw2A 5eYYvTVpjn31tIZz2OIAkX4Y7kE5CGB/tYupNjwObrWQhsvSh5KiFRxRbck5xVfgsT2G pD6Nij8ByWVyKYSIknFKX0wYMf9DPRlCyrh0RsoyauBFF0vlAEkPbe92y0RLMDn4QDTh Tn79RqFd/uqHYyfdJU728/MgZ8tlovdWiTL/bM/xJII86b0I9smIsxzwEOTQsR8qL9kL kfKsRJHe2p5ebjagTzImOv58MAbqkafGiGA4AG6yS+e1qs9Bqg3tL+nmmj/QNKwCDZOV pw== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25ce9qrmsx-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Sep 2016 01:19:10 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Fri, 16 Sep 2016 01:19:08 -0400 From: "Peterson, Jon" To: Alan Ford Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAA1l8gIAABekAgAABcQD//6g2gIAAf5EA//+RW4CAAL9/gP//vV8A Date: Fri, 16 Sep 2016 05:19:08 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> In-Reply-To: <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.120] Content-Type: multipart/alternative; boundary="_000_D400BE811B3BFDjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-16_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609160067 Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 05:19:18 -0000 --_000_D400BE811B3BFDjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We're still not quite on the same page I fear. Thanks for the detailed clarifications, Jon. My issue is indeed with the id= ea that two independent canonicalisation procedures may come up with differ= ent answers, thus negating any benefit from this scheme. I had not consider= ed the idea of looking at the the signing CA and determining behaviour base= d on this - if it looks like a cert that would authorise a tn: then canonic= alise as a tn:, else canonicalise as a sip: URI. I think this would probabl= y resolve most issues around my primary concern here, although it=92s not p= articularly efficient, but if this was the case then this is something that= needs to be spelled out more clearly (including the logic around determini= ng whether a CA Is appropriate for tn: canonicalisation). Well like I said, if it helps, I don't see any reason not to mention it in = the spec. But... However, I still share Christer=92s original concerns about selection of UR= Is for multiple identities. My view after our interop testing and investiga= ting real-world deployment is that mandating the use of canon in these situ= ations would significantly help validation. ... I guess you are saying it does't help enough? There may be good reasons to include the entire PASSporT object in every SI= P request, but I still don't think the issues you enumerate here are it. Jumping back to your earlier mail, some further thoughts inline: A From identity (or a PAI identity) is expected to contain an address-of-re= cord of the originator of the request. If some really unhelpful URI that is= only resolvable locally is used as the From, then we should expect there t= o be problems in ordinary SIP operations if the request escapes that local = environment. The whole point of including an AoR as your public identity is= that someone who sees it can dereference it, and through standard routing = procedures (in baseline SIP we mean RFC3263) you'll end up reaching the rig= ht user agents(). If you aren't operating within those constraints, I don't= think that's really something that RFC4474bis can fix. This is a concern right here, however. Do you use From or PAI? Which PAI if= there=92s more than one? Or do you include all of them? If so, in what ord= er? What about Remote-Party-ID? Without including a canon this is very diff= icult to validate. I've previously noted that practical deployments require the sane use of id= entities. "Which PAI if there's more than one?" or worse, what if you have = RPID too? Well, which identifier does your deployment treat as the identity= of the user today? If you can't answer that question, you shouldn't be lay= ing this problem at the feet of rfc4474bis. SIP was not designed to let you= put fifteen originating identities into a request, and in terms of figurin= g out an identity for the purposes of defeating the attacks in our threat m= odel (robocalling etc) speculating about this proliferation of identities i= s counterproductive. "Difficult to validate" here presumably means that you have to know which i= dentity was used by the authentication service, which one it thought was th= e "real" identity. Well, today, in a pre-rfc44744bis world, SIP requests ap= pear with both From and PAI. How do you know which one contains the "real" = identity of the user? The short answer is that local policy tells you. Is t= his a practical problem? Given the prevalence of PAI in the field, I'd say = it isn't. And if there are multiple PAIs in the same request, how do you kn= ow? The same way. Again, casting this as a problem that rfc4474bis has to f= ix discounts the fact that this is literally the deployment reality today a= nd there isn't a problem. Nothing about adding rfc4474bis to the mix create= s a new problem that we need to address that I can see. Finally, I will reiterate for like the nth time on this list that in order = to close this issue, we presented this as a slide at the last IETF, and we = discussed it, and we took a consensus call, and the result was that the gro= up thought there was no problem. At that meeting, we even discussed as a st= rawman proposal that the PASSporT object would carry some explicit indicato= r saying which header in the SIP request an identity came form. No new info= rmation is being added to the discussion by these threads other than vague = "isn't there a problem?" sorts of questions. If there is new information he= re, if there is a problem with existing deployments today that cannot disam= biguate multiple uses of PAI, then we probably need to fix it in PAI rather= than in rfc4474bis. But no one has however offered any evidence that there= 's actually any ambiguity when using multiple PAIs in the absence of Identi= ty. [...] At the end of the day, if you are on the receiving side, you are left to in= spect whatever is left after intermediaries get through with the message. T= his remains one of the most important reasons that "canon" (which now means= carrying the header and payload PASSporT objects) is optional: the philoso= phy behind canonicalization is that what matters isn't some value that the = authentication service mandates, but instead how the two sides understand t= he numbers as they receive them. The originating side may initially direct = the request to some local seven digital telephone number: but by the time t= hat gets to the terminating side, a country code and area code might be add= ed to it. They both "mean" the same number, and the authentication service = that signs the request exercises the canonicalization process in order to c= apture what it thinks the originator "meant" for the global environment. I don=92t follow why this is an argument against carrying the canon. Or are= you saying that the receiver has its own canonicalisation process it shoul= d be able to determine from the headers the source or destination that the = originator originally intended? I am saying that, yes. It won't always work, but it'll work in the cases wh= ere SIP (and identity) has any hope of working anyway. If so, that=92s assuming a lot of shared knowledge after headers have been = mangled! I am making the stronger claim that if the receiver can't do that, the Iden= tity mechanism offers little security. But if the canon was included, then this could provide hints in such a situ= ation and the receiver could know whether the field values it sees matches = the intended value as shown in the canon, rather than guessing! The problem here is hiding behind "the field value it sees matches the inte= nded value." If "the intended value" was generated (or more likely cut-and-= pasted) by an attacker, then the verification service needs to be able to d= etect that this value does not conform with the values in the SIP request. = There is no guesswork required: the verifier performs a canonicalization pr= ocedure on the SIP request to determine that. The results of that procedure= either equal the value that the authentication service used when it signed= or they don't. Thus it doesn't matter whether "canon" provides the full PA= SSporT object or not: the presence of "canon" will never remove the obligat= ion of the verification service to actually look at the SIP message and can= onicalize the identity of the originator. Moreover, to your specific argument, here's the rub: because this is a secu= rity function, carrying the canonical value in "canon" cannot really help u= nless the verification service already knows how to turn the value already = in the From (or PAI or whatever) into the canonical value anyway. Why not? = Because if I get a From with "sip:0020121421@example.com" and the PASSporT = object in canon says the orig is a tn value "12012142102", how is the verif= ication service supposed to know whether or not this is a cut-and-paste att= ack? If the verification service just blindly trusted that the contents of = the PASSporT object's orig were equivalent to the URI in the From, it would= never be able to tell whether or not the PASSporT object actually belonged= with this call. I completely agree. I see the canon as a way of telling the receiver =93thi= s is what I encoded=94. This allows the receiver to easily verify whether a= ) the values now present in the headers can be mapped to the values in the = PASSporT object (as shared by the canon) by local logic of the verification= service; and b) if there is the potential for confusion (multiple source/d= est options, or multiple encodings for source/dest), this clarifies which o= ne was chosen. I understand that your primary impetus in discussing this is (b), that you = want to disambiguate a number of different headers that are potential carri= ers of identity. I at least get what you want from that. But (a) is a more = complicated matter, as I describe above. Again, a lot is hiding behind "can= be mapped" in the description of (a). The value used by the authentication= service either maps according to the canonicalization procedure performed = by the verifier or it doesn't. The presence of canon cannot influence the v= erification service decision: we want security to fail (which, I feel oblig= ed to say, doesn't necessarily mean rejecting the request) if the verificat= ion service canonicalization does not resolve to the same value that the au= th service used. That is what this mechanism is designed to do. The value of "canon" is only there for debugging and optimization purposes,= we say this many times in the spec. It is NOT there to tunnel some "secret= " value for the telephone number between the authentication service and ver= ification service, as that would be a huge security hole. And it wouldn't w= ork anyway because as I said above intermediaries could just change it. The= neat thing about not including "canon" is that intermediaries can't change= something that isn't in the message. This was effectively the argument Had= riel and others made back in the day. Sorry, I don=92t follow any of the above. Including canon does not add any = security hole, it does not allow intermediaries to change anything, since i= t is protected by the signature. ... the PASSport object is not a security hole in the sense that it lacks i= ntegrity protection. The security hole appears only if we stipulate that th= e verification service trusts that the orig tn value in the PASSporT object= is a canonicalization of whatever identity the SIP request carries. If the= authentication service is an attacker, it can set the orig tn in the PASSp= orT object to any value of its choosing. Ascertaining the relationship of t= hat value to the value of the TN in the From (or PAI) is a crucial security= function that the verification service performs. (Well, and as rfc4474bis noted, passing around the whole object can also in= troduce some privacy concerns when requests exit the boundaries of RFC3324 = trusted networks, but that's not the matter at hand here. A different secur= ity hole that is another reason why including the full PASSporT object is n= ot a MUST.) A receiver can receive the canon, validate the signature against the canon,= and then validate the fields. This makes much more sense from an implement= ation point of view than trying to guess the construction of the PASSporT o= bject from the fields in the SIP message, and then seeing if this validates= . The problem here is hiding behind what you mean by "validate the fields". T= he comparison operation that the verification service performs to do that v= alidation requires it to perform the entire canonicalization process itself= . rfc4474bis says that the verification service, *before* it bothers to val= idate the signature, optionally can perform this function, and compare the = value it gets as a result against the orig tn in PASSporT (when present), s= olely as an optimization - so if there's no match is won't need to do the c= rypto. So it's not that I disagree that there's an optimization pass we can= make, if "canon" is present. I just get very nervous when I hear this fram= ed the other way, as more than an optimization, but instead as a substitute= for having to "guess the construction of the PASSporT object from the fiel= ds of the SIP message," which is indeed an apt description of the procedure= s that rfc4474bis requires. You can argue that the verification service will sometimes not have suffici= ent information to arrive at the same canonicalization as the authenticatio= n service, and I agree. In some cases it won't: like when calls escape from= really opaque private branches, or in if one end is in some weird variable= -length dialing plan, or if a nationally-specific service number is used, o= r whatever. I just think that in order for those calls to realistically get= routed and expect identity to work, they need to express identifiers in a = way that is actually useful to the rest of the world. Absolutely agreed, and therefore in all these circumstances SIP URIs would = be used for the encoding. The problem I raised is more with receivers. How = do receivers know how the sender encoded it? By finding out for themselves by performing the canonicalization. If they t= rust the sender to tell them how it was encoded, then the PASSporT object h= as no practical reference integrity with the SIP request. Jon Peterson Neustar, Inc. --_000_D400BE811B3BFDjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

We're still not quite on the same page I fear.

Thanks for the detailed clarifications, Jon. My issue is indeed with the id= ea that two independent canonicalisation procedures may come up with differ= ent answers, thus negating any benefit from this scheme. I had not consider= ed the idea of looking at the the signing CA and determining behaviour based on this - if it looks like a ce= rt that would authorise a tn: then canonicalise as a tn:, else canonicalise= as a sip: URI. I think this would probably resolve most issues around my p= rimary concern here, although it=92s not particularly efficient, but if this was the case then this is somethin= g that needs to be spelled out more clearly (including the logic around det= ermining whether a CA Is appropriate for tn: canonicalisation).

Well like I said, if it helps, I don't see any reason not to mention i= t in the spec. But...

However, I still share Christer=92s original concerns about= selection of URIs for multiple identities. My view after our interop testi= ng and investigating real-world deployment is that mandating the use of can= on in these situations would significantly help validation.

... I guess you are saying it does't help enough? 

There may be good reasons to include the entire PASSporT object in eve= ry SIP request, but I still don't think the issues you enumerate here are i= t.

Jumping back to your earlier mail, some further thoughts in= line:

A From identity (or a PAI identity) is expected to contain an address-of-= record of the originator of the request. If some really unhelpful URI that = is only resolvable locally is used as the From, then we should expect there to be problems in ordinary SIP opera= tions if the request escapes that local environment. The whole point of inc= luding an AoR as your public identity is that someone who sees it can deref= erence it, and through standard routing procedures (in baseline SIP we mean RFC3263) you'll end up reachin= g the right user agents(). If you aren't operating within those constraints= , I don't think that's really something that RFC4474bis can fix.

This is a concern right here, however. Do you use From or P= AI? Which PAI if there=92s more than one? Or do you include all of them? If= so, in what order? What about Remote-Party-ID? Without including a canon t= his is very difficult to validate.

I've previously noted that practical deployments require the sane use = of identities. "Which PAI if there's more than one?" or worse, wh= at if you have RPID too? Well, which identifier does your deployment treat = as the identity of the user today? If you can't answer that question, you shouldn't be laying this problem at the fe= et of rfc4474bis. SIP was not designed to let you put fifteen originating i= dentities into a request, and in terms of figuring out an identity for the = purposes of defeating the attacks in our threat model (robocalling etc) speculating about this proliferation= of identities is counterproductive.

"Difficult to validate" here presumably means that you have = to know which identity was used by the authentication service, which one it= thought was the "real" identity. Well, today, in a pre-rfc44744b= is world, SIP requests appear with both From and PAI. How do you know which one contains the "real" identity of the us= er? The short answer is that local policy tells you. Is this a practical pr= oblem? Given the prevalence of PAI in the field, I'd say it isn't. And if t= here are multiple PAIs in the same request, how do you know? The same way. Again, casting this as a problem that rfc44= 74bis has to fix discounts the fact that this is literally the deployment r= eality today and there isn't a problem. Nothing about adding rfc4474bis to = the mix creates a new problem that we need to address that I can see.

Finally, I will reiterate for like the nth time on this list that in o= rder to close this issue, we presented this as a slide at the last IETF, an= d we discussed it, and we took a consensus call, and the result was that th= e group thought there was no problem. At that meeting, we even discussed as a strawman proposal that the PASSpor= T object would carry some explicit indicator saying which header in the SIP= request an identity came form. No new information is being added to the di= scussion by these threads other than vague "isn't there a problem?" sorts of questions. If there= is new information here, if there is a problem with existing deployments t= oday that cannot disambiguate multiple uses of PAI, then we probably need t= o fix it in PAI rather than in rfc4474bis. But no one has however offered any evidence that there's actually any ambi= guity when using multiple PAIs in the absence of Identity. 


[...]

At the end of the day, if you are on the receiving side, you are left to = inspect whatever is left after intermediaries get through with the message.= This remains one of the most important reasons that "canon" (which now means carrying the header and pa= yload PASSporT objects) is optional: the philosophy behind canonicalization= is that what matters isn't some value that the authentication service mand= ates, but instead how the two sides understand the numbers as they receive them. The originating side may initially direc= t the request to some local seven digital telephone number: but by the time= that gets to the terminating side, a country code and area code might be a= dded to it. They both "mean" the same number, and the authentication service that signs the request exercis= es the canonicalization process in order to capture what it thinks the orig= inator "meant" for the global environment.

I don=92t follow why this is an argument against carrying t= he canon. Or are you saying that the receiver has its own canonicalisation = process it should be able to determine from the headers the source or desti= nation that the originator originally intended?

I am saying that, yes. It won't always work, but it'll work in the cas= es where SIP (and identity) has any hope of working anyway.

If so, that=92s assuming a lot of shared knowledge after he= aders have been mangled!

I am making the stronger claim that if the receiver can't do that, the= Identity mechanism offers little security.

But if the canon was included, then this could provide hint= s in such a situation and the receiver could know whether the field values = it sees matches the intended value as shown in the canon, rather than guess= ing!

The problem here is hiding behind "the field value it sees matche= s the intended value." If "the intended value" was generated= (or more likely cut-and-pasted) by an attacker, then the verification serv= ice needs to be able to detect that this value does not conform with the values in the SIP request. There is no guesswork requ= ired: the verifier performs a canonicalization procedure on the SIP request= to determine that. The results of that procedure either equal the value th= at the authentication service used when it signed or they don't. Thus it doesn't matter whether "canon&q= uot; provides the full PASSporT object or not: the presence of "canon&= quot; will never remove the obligation of the verification service to actua= lly look at the SIP message and canonicalize the identity of the originator.


Moreover, to your specific argument, here's the rub: because this is a se= curity function, carrying the canonical value in "canon" cannot r= eally help unless the verification service already knows how to turn the value already in the From (or PAI or whatever) into = the canonical value anyway. Why not? Because if I get a From with "sip:0020121421@example.com" and the PASSporT object in canon says the orig is a tn value "12012142102", how is the verification se= rvice supposed to know whether or not this is a cut-and-paste attack? If th= e verification service just blindly trusted that the contents of the PASSpo= rT object's orig were equivalent to the URI in the From, it would never be able to tell whether or not the PASSporT ob= ject actually belonged with this call.

I completely agree. I see the canon as a way of telling the= receiver =93this is what I encoded=94. This allows the receiver to easily = verify whether a) the values now present in the headers can be mapped to th= e values in the PASSporT object (as shared by the canon) by local logic of the verification service; and b) if there = is the potential for confusion (multiple source/dest options, or multiple e= ncodings for source/dest), this clarifies which one was chosen.

I understand that your primary impetus in discussing this is (b), that= you want to disambiguate a number of different headers that are potential = carriers of identity. I at least get what you want from that. But (a) is a = more complicated matter, as I describe above. Again, a lot is hiding behind "can be mapped" in the desc= ription of (a). The value used by the authentication service either maps ac= cording to the canonicalization procedure performed by the verifier or it d= oesn't. The presence of canon cannot influence the verification service decision: we want security to fail (which, I feel= obliged to say, doesn't necessarily mean rejecting the request) if the ver= ification service canonicalization does not resolve to the same value that = the auth service used. That is what this mechanism is designed to do.


The value of "canon" is only there for debugging and optimizati= on purposes, we say this many times in the spec. It is NOT there to tunnel = some "secret" value for the telephone number between the authentication service and verification service, as that would be a hu= ge security hole. And it wouldn't work anyway because as I said above inter= mediaries could just change it. The neat thing about not including "ca= non" is that intermediaries can't change something that isn't in the message. This was effectively the argument Had= riel and others made back in the day.

Sorry, I don=92t follow any of the above. Including canon d= oes not add any security hole, it does not allow intermediaries to change a= nything, since it is protected by the signature.

... the PASSport object is not a security hole in the sense that it la= cks integrity protection. The security hole appears only if we stipulate th= at the verification service trusts that the orig tn value in the PASSporT o= bject is a canonicalization of whatever identity the SIP request carries. If the authentication service is an atta= cker, it can set the orig tn in the PASSporT object to any value of its cho= osing. Ascertaining the relationship of that value to the value of the TN i= n the From (or PAI) is a crucial security function that the verification service performs.

(Well, and as rfc4474bis noted, passing around the whole object can al= so introduce some privacy concerns when requests exit the boundaries of RFC= 3324 trusted networks, but that's not the matter at hand here. A different = security hole that is another reason why including the full PASSporT object is not a MUST.)

A receiver can receive the canon, validate the signature against the canon, and then validate the fields. This makes much more s= ense from an implementation point of view than trying to guess the construc= tion of the PASSporT object from the fields in the SIP message, and then se= eing if this validates.

The problem here is hiding behind what you mean by "validate the = fields". The comparison operation that the verification service perfor= ms to do that validation requires it to perform the entire canonicalization= process itself. rfc4474bis says that the verification service, *before* it bothers to validate the signature, optio= nally can perform this function, and compare the value it gets as a result = against the orig tn in PASSporT (when present), solely as an optimization -= so if there's no match is won't need to do the crypto. So it's not that I disagree that there's an optimiz= ation pass we can make, if "canon" is present. I just get very ne= rvous when I hear this framed the other way, as more than an optimization, = but instead as a substitute for having to "guess the construction of the PASSporT object from the fields of the= SIP message," which is indeed an apt description of the procedures th= at rfc4474bis requires.


You can argue that the verification service will sometimes not have suffi= cient information to arrive at the same canonicalization as the authenticat= ion service, and I agree. In some cases it won't: like when calls escape from really opaque private branches, or i= n if one end is in some weird variable-length dialing plan, or if a nationa= lly-specific service number is used, or whatever. I just think that in orde= r for those calls to realistically get routed and expect identity to work, they need to express identifiers i= n a way that is actually useful to the rest of the world.

Absolutely agreed, and therefore in all these circumstances= SIP URIs would be used for the encoding. The problem I raised is more with= receivers. How do receivers know how the sender encoded it?

By finding out for themselves by performing the canonicalization. If t= hey trust the sender to tell them how it was encoded, then the PASSporT obj= ect has no practical reference integrity with the SIP request.

Jon Peterson
Neustar, Inc.
--_000_D400BE811B3BFDjonpetersonneustarbiz_-- From nobody Fri Sep 16 08:21:56 2016 Return-Path: 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 4D18512B291 for ; Fri, 16 Sep 2016 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RBnzcRSTH-73 for ; Fri, 16 Sep 2016 08:21:53 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DEB12B244 for ; Fri, 16 Sep 2016 08:21:52 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id t7so91568107qkh.2 for ; Fri, 16 Sep 2016 08:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UNhb2CUxug45eudhBxQaKL/xuImf7MOiJnph6u0hVkQ=; b=sTC07MBIZTHZJ5LVdd1ohEp3NEpqFLeYTzujdZX+rUZu4K84fMBHJet3kSn3763BuX OCk52GmH/eg8mgwewzm9C74yrQQ9ZYqZlBhAYlwkdG+OPMo/DFbjlRbDNuFteYdCPAK2 c8o2Zy/jnIBhuFclCewxsmSTB7p5gWJosz6R8WyMhdpq46E8A2p4CGSwM5Qe8s1d9YPY ijz9zWflfGtq7EiibrLc+Fu/uJr3wuAS8esnuBZiN3kxURRmC0lejGB2WUk8Ipn/8MSL hMha1bho9LrCoPrltIz9ducblv1Sv2H383h6z1EDiTWVqZTkThBFWD/uVDfh8GhCXRnx P6oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UNhb2CUxug45eudhBxQaKL/xuImf7MOiJnph6u0hVkQ=; b=E7C/UiKKikkFtuGDToPr9NgeqHETIgAW+LPk163CJf/xMwaq94R84XO/2fbdHITBA3 Gc6OeSYpiheKvmQgEUiIuZ2ptrwHoKNtgQkxarJ5Id/jlmD/bUyb5UHpmEIxTEmaaqB6 P8awmsJcYointQlrTMlo5csVyfW0ZIG//HWIHVCiwbHj9cHL8BEEpuGG6yXWivJ1DGPB sn7s5DmGIDPTcXYXamILwC6heOVXy69xPSqrVNSGwyKOPaO8enwOaGVPbQNdpePymrx/ a/U/urNw/2VBGk0GovKtEr5z8hVE+FxT0mmHgC19uaeyl0tT5+WaMteeBKdQdZiDzGHr xVsg== X-Gm-Message-State: AE9vXwNoRn4WN2nrG8k5/GXza30N80eFJ24zlFMRB/jMYeRxefYkiQBb2iM8Lysy7ToMdA== X-Received: by 10.55.59.70 with SMTP id i67mr17433992qka.205.1474039311571; Fri, 16 Sep 2016 08:21:51 -0700 (PDT) Received: from 132-177-252-248.ip.sipit.net ([132.177.252.248]) by smtp.gmail.com with ESMTPSA id 9sm4984133qkc.0.2016.09.16.08.21.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 08:21:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4026120D-0757-4D06-8605-30AEE810C9C1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Fri, 16 Sep 2016 16:21:56 +0100 Message-Id: <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 15:21:56 -0000 --Apple-Mail=_4026120D-0757-4D06-8605-30AEE810C9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jon, all, > On 16 Sep 2016, at 06:19, Peterson, Jon = wrote: >=20 > We're still not quite on the same page I fear. >=20 >> Thanks for the detailed clarifications, Jon. My issue is indeed with = the idea that two independent canonicalisation procedures may come up = with different answers, thus negating any benefit from this scheme. I = had not considered the idea of looking at the the signing CA and = determining behaviour based on this - if it looks like a cert that would = authorise a tn: then canonicalise as a tn:, else canonicalise as a sip: = URI. I think this would probably resolve most issues around my primary = concern here, although it=92s not particularly efficient, but if this = was the case then this is something that needs to be spelled out more = clearly (including the logic around determining whether a CA Is = appropriate for tn: canonicalisation). >=20 >=20 > Well like I said, if it helps, I don't see any reason not to mention = it in the spec. But... >=20 >> However, I still share Christer=92s original concerns about selection = of URIs for multiple identities. My view after our interop testing and = investigating real-world deployment is that mandating the use of canon = in these situations would significantly help validation. >=20 >=20 > ... I guess you are saying it does't help enough?=20 No, it doesn=92t. I was a bit too optimistic when I wrote that, the real = problem is on the receiving side: How does the receiver know how the = sender has canonicalised the destination? That=92s the number #1 problem I think. You could use the cert to infer = how the sender may have canonicalised the source, but the destination = there is no clue. Unless you make an assumption that tn:s call tn:s with = a tn cert, otherwise it=92s a SIP URI. That I could live with but seems = unnecessarily limiting. > There may be good reasons to include the entire PASSporT object in = every SIP request, but I still don't think the issues you enumerate here = are it. >=20 >> Jumping back to your earlier mail, some further thoughts inline: >>=20 >>> A =46rom identity (or a PAI identity) is expected to contain an = address-of-record of the originator of the request. If some really = unhelpful URI that is only resolvable locally is used as the From, then = we should expect there to be problems in ordinary SIP operations if the = request escapes that local environment. The whole point of including an = AoR as your public identity is that someone who sees it can dereference = it, and through standard routing procedures (in baseline SIP we mean = RFC3263) you'll end up reaching the right user agents(). If you aren't = operating within those constraints, I don't think that's really = something that RFC4474bis can fix. >>=20 >> This is a concern right here, however. Do you use =46rom or PAI? = Which PAI if there=92s more than one? Or do you include all of them? If = so, in what order? What about Remote-Party-ID? Without including a canon = this is very difficult to validate. >=20 >=20 > I've previously noted that practical deployments require the sane use = of identities. "Which PAI if there's more than one?" or worse, what if = you have RPID too? Well, which identifier does your deployment treat as = the identity of the user today? If you can't answer that question, you = shouldn't be laying this problem at the feet of rfc4474bis. SIP was not = designed to let you put fifteen originating identities into a request, = and in terms of figuring out an identity for the purposes of defeating = the attacks in our threat model (robocalling etc) speculating about this = proliferation of identities is counterproductive. >=20 > "Difficult to validate" here presumably means that you have to know = which identity was used by the authentication service, which one it = thought was the "real" identity. Well, today, in a pre-rfc44744bis = world, SIP requests appear with both =46rom and PAI. How do you know = which one contains the "real" identity of the user? The short answer is = that local policy tells you. Is this a practical problem? Given the = prevalence of PAI in the field, I'd say it isn't. And if there are = multiple PAIs in the same request, how do you know? The same way. Again, = casting this as a problem that rfc4474bis has to fix discounts the fact = that this is literally the deployment reality today and there isn't a = problem. Nothing about adding rfc4474bis to the mix creates a new = problem that we need to address that I can see. This comes back to the same problem, fundamentally. =93Local policy = tells you=94 - that=92s great, but when applied to STIR this requires = both the sender and the receiver to have the same local policy. > Finally, I will reiterate for like the nth time on this list that in = order to close this issue, we presented this as a slide at the last = IETF, and we discussed it, and we took a consensus call, and the result = was that the group thought there was no problem. At that meeting, we = even discussed as a strawman proposal that the PASSporT object would = carry some explicit indicator saying which header in the SIP request an = identity came form. No new information is being added to the discussion = by these threads other than vague "isn't there a problem?" sorts of = questions. If there is new information here, if there is a problem with = existing deployments today that cannot disambiguate multiple uses of = PAI, then we probably need to fix it in PAI rather than in rfc4474bis. = But no one has however offered any evidence that there's actually any = ambiguity when using multiple PAIs in the absence of Identity.=20 Indeed. I didn=92t speak up in Berlin on this, and neither did I pick up = on this when reviewing an earlier version of the draft, since it all = made sense in my head - =93implementations would understand how to do = this based on the environments in which they were operating=94 was my = thought. However, having actually sat down with a colleague and started = to create running code, the real-world problems quickly become apparent. Our current real-world problem is the SIP/TN decision process at the = receiver, particularly for destination address(es), but it=92s also = becoming apparent that for compatibility the other issues raised here, = such as selection of PAI vs From, are likely to cause problems. >> But if the canon was included, then this could provide hints in such = a situation and the receiver could know whether the field values it sees = matches the intended value as shown in the canon, rather than guessing! >=20 >=20 > The problem here is hiding behind "the field value it sees matches the = intended value." If "the intended value" was generated (or more likely = cut-and-pasted) by an attacker, then the verification service needs to = be able to detect that this value does not conform with the values in = the SIP request. There is no guesswork required: the verifier performs a = canonicalization procedure on the SIP request to determine that. The = results of that procedure either equal the value that the authentication = service used when it signed or they don't. Thus it doesn't matter = whether "canon" provides the full PASSporT object or not: the presence = of "canon" will never remove the obligation of the verification service = to actually look at the SIP message and canonicalize the identity of the = originator. Indeed not. But, it tells the receiver which fields to look in, and what = form of canonicalisation to undertake. This is A Good Thing from an = implementation and interoperability point of view. >>> Moreover, to your specific argument, here's the rub: because this is = a security function, carrying the canonical value in "canon" cannot = really help unless the verification service already knows how to turn = the value already in the =46rom (or PAI or whatever) into the canonical = value anyway. Why not? Because if I get a =46rom with = "sip:0020121421@example.com " and the = PASSporT object in canon says the orig is a tn value "12012142102", how = is the verification service supposed to know whether or not this is a = cut-and-paste attack? If the verification service just blindly trusted = that the contents of the PASSporT object's orig were equivalent to the = URI in the From, it would never be able to tell whether or not the = PASSporT object actually belonged with this call. >>=20 >> I completely agree. I see the canon as a way of telling the receiver = =93this is what I encoded=94. This allows the receiver to easily verify = whether a) the values now present in the headers can be mapped to the = values in the PASSporT object (as shared by the canon) by local logic of = the verification service; and b) if there is the potential for confusion = (multiple source/dest options, or multiple encodings for source/dest), = this clarifies which one was chosen. >=20 >=20 > I understand that your primary impetus in discussing this is (b), that = you want to disambiguate a number of different headers that are = potential carriers of identity. I at least get what you want from that. = But (a) is a more complicated matter, as I describe above. Again, a lot = is hiding behind "can be mapped" in the description of (a). The value = used by the authentication service either maps according to the = canonicalization procedure performed by the verifier or it doesn=92t. And that is the crux of the matter. > The presence of canon cannot influence the verification service = decision: we want security to fail (which, I feel obliged to say, = doesn't necessarily mean rejecting the request) if the verification = service canonicalization does not resolve to the same value that the = auth service used. That is what this mechanism is designed to do. But this is the problem! When a sender does not know its target would = canonicalise the destination address as a TN, and thus encodes it as a = SIP URI in the PASSporT object, verification would fail. But with canon, = the verification service could be more intelligent, as it may be able to = pass all other verification logic if it knew how the field had been = canonicalised. Verification failing in this circumstance is surely bad? >>> The value of "canon" is only there for debugging and optimization = purposes, we say this many times in the spec. It is NOT there to tunnel = some "secret" value for the telephone number between the authentication = service and verification service, as that would be a huge security hole. = And it wouldn't work anyway because as I said above intermediaries could = just change it. The neat thing about not including "canon" is that = intermediaries can't change something that isn't in the message. This = was effectively the argument Hadriel and others made back in the day. >>=20 >> Sorry, I don=92t follow any of the above. Including canon does not = add any security hole, it does not allow intermediaries to change = anything, since it is protected by the signature. >=20 >=20 > ... the PASSport object is not a security hole in the sense that it = lacks integrity protection. The security hole appears only if we = stipulate that the verification service trusts that the orig tn value in = the PASSporT object is a canonicalization of whatever identity the SIP = request carries. I don=92t think anyone is suggesting that should be the logic. I = certainly am not. > If the authentication service is an attacker, it can set the orig tn = in the PASSporT object to any value of its choosing. Ascertaining the = relationship of that value to the value of the TN in the =46rom (or PAI) = is a crucial security function that the verification service performs. And passing the canon does not prevent the verification service from = providing this function. >> A receiver can receive the canon, validate the signature against the = canon, and then validate the fields. This makes much more sense from an = implementation point of view than trying to guess the construction of = the PASSporT object from the fields in the SIP message, and then seeing = if this validates. >=20 >=20 > The problem here is hiding behind what you mean by "validate the = fields". The comparison operation that the verification service performs = to do that validation requires it to perform the entire canonicalization = process itself. rfc4474bis says that the verification service, *before* = it bothers to validate the signature, optionally can perform this = function, and compare the value it gets as a result against the orig tn = in PASSporT (when present), solely as an optimization - so if there's no = match is won't need to do the crypto. So it's not that I disagree that = there's an optimization pass we can make, if "canon" is present. I just = get very nervous when I hear this framed the other way, as more than an = optimization, but instead as a substitute for having to "guess the = construction of the PASSporT object from the fields of the SIP message," = which is indeed an apt description of the procedures that rfc4474bis = requires. I may be being slow here, and apologies if so, but I still don=92t = understand what benefit is brought by not sharing the construction. >>> You can argue that the verification service will sometimes not have = sufficient information to arrive at the same canonicalization as the = authentication service, and I agree. In some cases it won't: like when = calls escape from really opaque private branches, or in if one end is in = some weird variable-length dialing plan, or if a nationally-specific = service number is used, or whatever. I just think that in order for = those calls to realistically get routed and expect identity to work, = they need to express identifiers in a way that is actually useful to the = rest of the world. >>=20 >> Absolutely agreed, and therefore in all these circumstances SIP URIs = would be used for the encoding. The problem I raised is more with = receivers. How do receivers know how the sender encoded it? >=20 >=20 > By finding out for themselves by performing the canonicalization. If = they trust the sender to tell them how it was encoded, then the PASSporT = object has no practical reference integrity with the SIP request. It sounds like you are arguing there are two binary options here: no = shared canon, so both parties trust the other to perform the same = process; or share a canon, and it sounds as if you believe that would = mean =93well the canon is signed so this is obviously a valid = canonicalisation of what=92s in the header=94. Which is obviously = completely insecure. I=92m saying there=92s a middle ground here. When there are multiple = possibilities for canonicalisation, providing the canon helps the = verification service decide which one to use. The security remains the = same, as long as the canonicalisation process being followed is one that = is trusted by the verification service anyway. My proposal, just to reiterate, is to mandate the presence of canon = unless STIR is being used between environments where both parties are = known to have a common canonicalisation scheme. Regards, Alan --Apple-Mail=_4026120D-0757-4D06-8605-30AEE810C9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jon, all,

On 16 Sep 2016, at 06:19, = Peterson, Jon <jon.peterson@neustar.biz> wrote:

We're still not quite on the same = page I fear.

Thanks for the detailed clarifications, Jon. My = issue is indeed with the idea that two independent canonicalisation = procedures may come up with different answers, thus negating any benefit = from this scheme. I had not considered the idea of looking at the the = signing CA and determining behaviour based on this - if it looks like a = cert that would authorise a tn: then canonicalise as a tn:, else = canonicalise as a sip: URI. I think this would probably resolve most = issues around my primary concern here, although it=92s not particularly = efficient, but if this was the case then this is something that needs to = be spelled out more clearly (including the logic around determining = whether a CA Is appropriate for tn: = canonicalisation).

Well like I said, if it = helps, I don't see any reason not to mention it in the spec. = But...

However, I still share Christer=92s original concerns about = selection of URIs for multiple identities. My view after our interop = testing and investigating real-world deployment is that mandating the = use of canon in these situations would significantly help = validation.

... I guess you are saying = it does't help enough? 

No, it doesn=92t. I was a bit too optimistic when = I wrote that, the real problem is on the receiving side: How does = the receiver know how the sender has canonicalised the = destination?

That=92s the number #1 = problem I think. You could use the cert to infer how the sender may have = canonicalised the source, but the destination there is no clue. Unless = you make an assumption that tn:s call tn:s with a tn cert, otherwise = it=92s a SIP URI. That I could live with but seems unnecessarily = limiting.

There may be good reasons to include the entire = PASSporT object in every SIP request, but I still don't think the issues = you enumerate here are it.

Jumping back to your earlier mail, some further thoughts = inline:

A =46rom = identity (or a PAI identity) is expected to contain an address-of-record = of the originator of the request. If some really unhelpful URI that is = only resolvable locally is used as the From, then we should expect there = to be problems in ordinary SIP operations if the request escapes that = local environment. The whole point of including an AoR as your public = identity is that someone who sees it can dereference it, and through = standard routing procedures (in baseline SIP we mean RFC3263) you'll end = up reaching the right user agents(). If you aren't operating within = those constraints, I don't think that's really something that RFC4474bis = can fix.

This is a concern right here, however. Do you use =46rom or = PAI? Which PAI if there=92s more than one? Or do you include all of = them? If so, in what order? What about Remote-Party-ID? Without = including a canon this is very difficult to = validate.

I've = previously noted that practical deployments require the sane use of = identities. "Which PAI if there's more than one?" or worse, what if you = have RPID too? Well, which identifier does your deployment treat as the = identity of the user today? If you can't answer that question, you = shouldn't be laying this problem at the feet of rfc4474bis. SIP was not = designed to let you put fifteen originating identities into a request, = and in terms of figuring out an identity for the purposes of defeating = the attacks in our threat model (robocalling etc) speculating about this = proliferation of identities is counterproductive.

"Difficult to validate" = here presumably means that you have to know which identity was used by = the authentication service, which one it thought was the "real" = identity. Well, today, in a pre-rfc44744bis world, SIP requests appear = with both =46rom and PAI. How do you know which one contains the "real" = identity of the user? The short answer is that local policy tells you. = Is this a practical problem? Given the prevalence of PAI in the field, = I'd say it isn't. And if there are multiple PAIs in the same request, = how do you know? The same way. Again, casting this as a problem that = rfc4474bis has to fix discounts the fact that this is literally the = deployment reality today and there isn't a problem. Nothing about adding = rfc4474bis to the mix creates a new problem that we need to address that = I can see.

This = comes back to the same problem, fundamentally. =93Local policy tells = you=94 - that=92s great, but when applied to STIR this requires both the = sender and the receiver to have the same local policy.

Finally, I will = reiterate for like the nth time on this list that in order to close this = issue, we presented this as a slide at the last IETF, and we discussed = it, and we took a consensus call, and the result was that the group = thought there was no problem. At that meeting, we even discussed as a = strawman proposal that the PASSporT object would carry some explicit = indicator saying which header in the SIP request an identity came form. = No new information is being added to the discussion by these threads = other than vague "isn't there a problem?" sorts of questions. If there = is new information here, if there is a problem with existing deployments = today that cannot disambiguate multiple uses of PAI, then we probably = need to fix it in PAI rather than in rfc4474bis. But no one has however = offered any evidence that there's actually any ambiguity when using = multiple PAIs in the absence of = Identity. 

Indeed. I didn=92t speak up in Berlin on this, and = neither did I pick up on this when reviewing an earlier version of the = draft, since it all made sense in my head - =93implementations would = understand how to do this based on the environments in which they were = operating=94 was my thought. However, having actually sat down with a = colleague and started to create running code, the real-world problems = quickly become apparent.

Our current = real-world problem is the SIP/TN decision process at the receiver, = particularly for destination address(es), but it=92s also becoming = apparent that for compatibility the other issues raised here, such as = selection of PAI vs From, are likely to cause problems.

But if the canon was = included, then this could provide hints in such a situation and the = receiver could know whether the field values it sees matches the = intended value as shown in the canon, rather than = guessing!

The problem here is hiding = behind "the field value it sees matches the intended value." If "the = intended value" was generated (or more likely cut-and-pasted) by an = attacker, then the verification service needs to be able to detect that = this value does not conform with the values in the SIP request. There is = no guesswork required: the verifier performs a canonicalization = procedure on the SIP request to determine that. The results of that = procedure either equal the value that the authentication service used = when it signed or they don't. Thus it doesn't matter whether "canon" = provides the full PASSporT object or not: the presence of "canon" will = never remove the obligation of the verification service to actually look = at the SIP message and canonicalize the identity of the = originator.

Indeed = not. But, it tells the receiver which fields to look in, and what form = of canonicalisation to undertake. This is A Good Thing from an = implementation and interoperability point of view.

Moreover, to your specific argument, here's the rub: = because this is a security function, carrying the canonical value in = "canon" cannot really help unless the verification service already knows = how to turn the value already in the =46rom (or PAI or whatever) into = the canonical value anyway. Why not? Because if I get a =46rom with "sip:0020121421@example.com" and the PASSporT object in = canon says the orig is a tn value "12012142102", how is the verification = service supposed to know whether or not this is a cut-and-paste attack? = If the verification service just blindly trusted that the contents of = the PASSporT object's orig were equivalent to the URI in the From, it = would never be able to tell whether or not the PASSporT object actually = belonged with this call.

I completely agree. I see the canon as = a way of telling the receiver =93this is what I encoded=94. This allows = the receiver to easily verify whether a) the values now present in the = headers can be mapped to the values in the PASSporT object (as shared by = the canon) by local logic of the verification service; and b) if there = is the potential for confusion (multiple source/dest options, or = multiple encodings for source/dest), this clarifies which one was = chosen.

I understand that your = primary impetus in discussing this is (b), that you want to disambiguate = a number of different headers that are potential carriers of identity. I = at least get what you want from that. But (a) is a more complicated = matter, as I describe above. Again, a lot is hiding behind "can be = mapped" in the description of (a). The value used by the authentication = service either maps according to the canonicalization procedure = performed by the verifier or it doesn=92t. =

And that is the = crux of the matter.

The presence of canon cannot influence the verification = service decision: we want security to fail (which, I feel obliged to = say, doesn't necessarily mean rejecting the request) if the verification = service canonicalization does not resolve to the same value that the = auth service used. That is what this mechanism is designed to = do.

But this is = the problem! When a sender does not know its target would canonicalise = the destination address as a TN, and thus encodes it as a SIP URI in the = PASSporT object, verification would fail. But with canon, the = verification service could be more intelligent, as it may be able to = pass all other verification logic if it knew how the field had been = canonicalised.

Verification failing = in this circumstance is surely bad?

The value of "canon" is only there for debugging and = optimization purposes, we say this many times in the spec. It is NOT = there to tunnel some "secret" value for the telephone number between the = authentication service and verification service, as that would be a huge = security hole. And it wouldn't work anyway because as I said above = intermediaries could just change it. The neat thing about not including = "canon" is that intermediaries can't change something that isn't in the = message. This was effectively the argument Hadriel and others made back = in the day.

Sorry, I don=92t follow any of the above. Including canon = does not add any security hole, it does not allow intermediaries to = change anything, since it is protected by the = signature.

... the PASSport object is = not a security hole in the sense that it lacks integrity protection. The = security hole appears only if we stipulate that the verification service = trusts that the orig tn value in the PASSporT object is a = canonicalization of whatever identity the SIP request carries. =

I don=92t think = anyone is suggesting that should be the logic. I certainly am = not.

If = the authentication service is an attacker, it can set the orig tn in the = PASSporT object to any value of its choosing. Ascertaining the = relationship of that value to the value of the TN in the =46rom (or PAI) = is a crucial security function that the verification service = performs.

And = passing the canon does not prevent the verification service from = providing this function.

A receiver can = receive the canon, validate the signature against the = canon, and then validate the fields. This makes much more sense from = an implementation point of view than trying to guess the construction of = the PASSporT object from the fields in the SIP message, and then seeing = if this validates.

The problem here is hiding = behind what you mean by "validate the fields". The comparison operation = that the verification service performs to do that validation requires it = to perform the entire canonicalization process itself. rfc4474bis says = that the verification service, *before* it bothers to validate the = signature, optionally can perform this function, and compare the value = it gets as a result against the orig tn in PASSporT (when present), = solely as an optimization - so if there's no match is won't need to do = the crypto. So it's not that I disagree that there's an optimization = pass we can make, if "canon" is present. I just get very nervous when I = hear this framed the other way, as more than an optimization, but = instead as a substitute for having to "guess the construction of the = PASSporT object from the fields of the SIP message," which is indeed an = apt description of the procedures that rfc4474bis = requires.

I may = be being slow here, and apologies if so, but I still don=92t understand = what benefit is brought by not = sharing the construction.

You can argue that the verification service will = sometimes not have sufficient information to arrive at the same = canonicalization as the authentication service, and I agree. In some = cases it won't: like when calls escape from really opaque private = branches, or in if one end is in some weird variable-length dialing = plan, or if a nationally-specific service number is used, or whatever. I = just think that in order for those calls to realistically get routed and = expect identity to work, they need to express identifiers in a way that = is actually useful to the rest of the world.

Absolutely agreed, and = therefore in all these circumstances SIP URIs would be used for the = encoding. The problem I raised is more with receivers. How do receivers = know how the = sender encoded it?

By finding out for = themselves by performing the canonicalization. If they trust the sender = to tell them how it was encoded, then the PASSporT object has no = practical reference integrity with the SIP = request.

It sounds = like you are arguing there are two binary options here: no shared canon, = so both parties trust the other to perform the same process; or share a = canon, and it sounds as if you believe that would mean =93well the canon = is signed so this is obviously a valid canonicalisation of what=92s in = the header=94. Which is obviously completely insecure.

I=92m saying there=92s a middle ground here. When = there are multiple possibilities for canonicalisation, providing the = canon helps the verification service decide which one to use. The = security remains the same, as long as the canonicalisation process being = followed is one that is trusted by the verification service = anyway.

My proposal, just to = reiterate, is to mandate the presence of canon unless STIR is being used = between environments where both parties are known to = have a common canonicalisation scheme.

Regards,
Alan

= --Apple-Mail=_4026120D-0757-4D06-8605-30AEE810C9C1-- From nobody Fri Sep 16 08:43:03 2016 Return-Path: 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 F3A7C12B252 for ; Fri, 16 Sep 2016 08:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 YeyKOvjc-1SP for ; Fri, 16 Sep 2016 08:43:00 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F70D12B25C for ; Fri, 16 Sep 2016 08:43:00 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with SMTP id kvGhbJ4fDxBKTkvI3bS9Ux; Fri, 16 Sep 2016 15:42:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with SMTP id kvI2bzNVUlRdokvI3bNNkK; Fri, 16 Sep 2016 15:42:59 +0000 To: stir@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> From: Paul Kyzivat Message-ID: Date: Fri, 16 Sep 2016 11:42:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfK7iGfgWYhHqNTFFccgg1dx7aNHgCJkkzfM++rMzPRZoJairh9pPNG/cBoHpm7wK3aBeiMSv1a36cN4ZSnL+jseRr2JCHiMh+EmQ0Phy1anjE7eLUznJ NL4LQiuecXpJpt9kWmEv124M5J++5Wc2qKAr7PdVgfLjph+CxE9mkKzdud3YMSCVUn8/SwAHpk9anQ== Archived-At: Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 15:43:02 -0000 On 9/16/16 11:21 AM, Alan Ford wrote: >> Finally, I will reiterate for like the nth time on this list that in >> order to close this issue, we presented this as a slide at the last >> IETF, and we discussed it, and we took a consensus call, and the >> result was that the group thought there was no problem. At that >> meeting, we even discussed as a strawman proposal that the PASSporT >> object would carry some explicit indicator saying which header in the >> SIP request an identity came form. No new information is being added >> to the discussion by these threads other than vague "isn't there a >> problem?" sorts of questions. If there is new information here, if >> there is a problem with existing deployments today that cannot >> disambiguate multiple uses of PAI, then we probably need to fix it in >> PAI rather than in rfc4474bis. But no one has however offered any >> evidence that there's actually any ambiguity when using multiple PAIs >> in the absence of Identity. > > Indeed. I didn’t speak up in Berlin on this, and neither did I pick up > on this when reviewing an earlier version of the draft, since it all > made sense in my head - “implementations would understand how to do this > based on the environments in which they were operating” was my thought. > However, having actually sat down with a colleague and started to create > running code, the real-world problems quickly become apparent. > > Our current real-world problem is the SIP/TN decision process at the > receiver, particularly for destination address(es), but it’s also > becoming apparent that for compatibility the other issues raised here, > such as selection of PAI vs From, are likely to cause problems. Surely the caller and signer bear some responsibility here. If they create a situation where there is ambiguity about which address is being signed then either they should do something to resolve it (e.g., in include canon) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call be validated, so they should be expected to make that feasible. This ultimately comes down to quality of implementation. But there is also a brute force solution available to the validator: try validation using each of the supplied identities in turn until one validates or none do. While that might cost a bit of extra computation, the cost of that might be less than the cost of carrying the canon parameter from end to end. Thanks, Paul From nobody Fri Sep 16 09:57:38 2016 Return-Path: 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 716FD12B234 for ; Fri, 16 Sep 2016 09:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1vSRNyEDMN-o for ; Fri, 16 Sep 2016 09:57:34 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33C712B068 for ; Fri, 16 Sep 2016 09:57:34 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 38so45873509qte.1 for ; Fri, 16 Sep 2016 09:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PFeWc18RyufsVyrqH3lEx6zlrtIxHhXCBw4KR/3bo+Y=; b=dB1cW2MzhCnlY/oYHr75Obm5JX3KwSWGUOXbz4qNXpaXvnK7wSuutf/MoxcmAsbB/X mA0Jvdq0IQzdlvwgXjiOVKUBoN5Dma3s315i3ZG1i7m21yGkjt4Hv6pTgbRsSbYM4sor pN7CKr8JEm/23Y83pY9AlK3xiA8UgjWufFbCwii4UjRefw6hEPYjA0Z9sD8+k3x8STqU AZw7axUuFNJ75jnWZVpRMHZvm7IUUXT1aujsLoWEDFowHqNVKtL6YkUVd35rPIe1YBM4 o34F77yJFlyYI93OwAjSry8WbS1VAWntO7na5dMQ8fw3Tuj6bfVi5J+fN6c3+bYRJfm2 b7jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PFeWc18RyufsVyrqH3lEx6zlrtIxHhXCBw4KR/3bo+Y=; b=bCzV0SC/vIcJ12aaVdfjONvd94JD+ROoMYINKIQz4764PGZwIVcVep161fyugMAX1D 57iGXmKWPzph5t4zyJ0ZIle8XqnC2fEf91KRaT9ybySeWY2hpeaGvnmImFgL+zDUCE2Y ok7TK/LRA1FDdY6R7o+QwNXQOZ/NJEQGoLVTu4FT7/MS0JT3ArCSBXHQZt/eyAAybyzo ZUpDYo0OgNbJK8GOdXpgadEPAGolJKOur1d6t9wMAPUIXCI0pxXicbMCVJGKxY8GPDvV qSexppJPEX6Z4CjZv0OZMMblTgYmIKm+cL1EN2Yt1+p0jozrKJH61Ov4mRyCT1TpLdeK TxgQ== X-Gm-Message-State: AE9vXwNFONi2xj2pVECyhKwKQ0+7uvuhN1yRyhExv+sDDy83Ntjdh04syl/8DqC8o+mgAw== X-Received: by 10.200.48.243 with SMTP id w48mr17011473qta.71.1474045053786; Fri, 16 Sep 2016 09:57:33 -0700 (PDT) Received: from ?IPv6:2606:4100:3880:2520:9053:f6ff:6b4e:31a1? ([2606:4100:3880:2520:9053:f6ff:6b4e:31a1]) by smtp.gmail.com with ESMTPSA id q68sm5216376qka.1.2016.09.16.09.57.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 09:57:33 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Fri, 16 Sep 2016 17:57:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 16:57:37 -0000 Hi Paul, > Surely the caller and signer bear some responsibility here. If they = create a situation where there is ambiguity about which address is being = signed then either they should do something to resolve it (e.g., in = include canon) or else be prepared for the consequences if the callee = can't validate. It is in the caller's interest that the call be = validated, so they should be expected to make that feasible. This = ultimately comes down to quality of implementation. The sender may or may not know that there would be ambiguity at the = receiving side. For example, the sender may only deal in SIP URIs and = not know the receiver is also a PSTN gateway. But in general, I agree, but feel this should be codified. This is why = my proposed resolution here would be to mandate canon unless the sender = knows for certain the receiving environment will follow the same = canonicalisation scheme - or words to that effect. > But there is also a brute force solution available to the validator: = try validation using each of the supplied identities in turn until one = validates or none do. While that might cost a bit of extra computation, = the cost of that might be less than the cost of carrying the canon = parameter from end to end. That=92s certainly true, but in my opinion the cost of bits is much = cheaper than the cost of computation. What=92s more, a brute-force = receiver could generate a modest denial-of-service attack vector - send = a signature for something completely different, and let the verification = service munch through cycles trying various combinations to see if any = validate (they won=92t, of course). Minimum would be four combinations = tried for just one src and one dest (trying tn: vs sip: combinations) - = and this could be many more if you start to include other identifiers = such as PAI or RPID. Whereas, if the canon was included, there would be = one single crypto operation to verify the signature against known data. Regards, Alan From nobody Fri Sep 16 10:27:33 2016 Return-Path: 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 21C9E12B0BE for ; Fri, 16 Sep 2016 10:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.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 shMTBKRIBWc5 for ; Fri, 16 Sep 2016 10:27:30 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B95412B036 for ; Fri, 16 Sep 2016 10:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Mm8ab+r6JFr3aog09lbcBMoRrhrNKtq4Z5s3KmwKFA=; b=RLma/Hl0OXoDw+xkV6FiZx6tIOnNVWjeqrBKdPAqP0bgaKENblKRxTNh39aJBY2d0/7M0pkIj4uhEi/1e3hveA0yDyDU4cD1iv2Yvx8L/ihtSNuzlCnsGO5DrMmJsUpDgzFoECmt9Sgf5q2OFQ+heefUORD6dS4C/nkqYx9+bvU= From: Henning Schulzrinne To: Alan Ford , Paul Kyzivat Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAAxZugIAABekAgAABcQCAAB1nAIAACmAAgAAGigCAAEpQgIAAMowAgACobACAAAXhAIAAFN2AgAAGG2A= Date: Fri, 16 Sep 2016 17:27:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 112a72f2-c67e-4293-e1e6-08d3de56bab3 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 6:2uJZfYlSOD3v7kYnCKBxF9AmywKl1dXprDRYhTyH6Q44W1NKB+tsBaheA8OjrPNuGsXk/HxmwJGgBggMU5JWL0sOtSZONTUdVV64YFFdqEi8umfE91K87PCorTcHnLOTlzIiMf0c3yYy1kAXhaK3v9sIJWxBGk010KWq1bSNnesyl8NakPcijZVqFHkuYYk8pyrLAwoi6HEka7SgF9RoAYrOf63eMxpTQCQddODe/3P/flgLLMb5zj4wVgjYelAMDCaEMhxJZmeo4VOoOurbmSzdYUXDleySH2PHPyhgLag=; 5:KJ//AAUUuvMGr6JN9b+d7tOnv8/KQukupEYhBGn/SlLpASxwtNdm8hWdn6XNBYS3YHDAXQLeLarU2Xehy+80fN1jzrUw30ESoeRr1XvAtsh6xnmNgux3i3fjWEEJrjIJ5j3GwCVUGFF7GWwRyn5igw==; 24:F4fveYVBuE7AO/RXpet/h9nyOIJlx4vJ9oS4g16mRttPyw7QlWQW0jOq1wx3TfA7kd+MtVZj41+Fou799Nkuf+2fljym4wUcKxu92aMQtHI=; 7:HfuCIMX8vNwZI64fim8IqFF/oNWwuVvQSyI5ffor29HOn/tcokXSC77nNfdmLVg1AMXrL6XAC0rI0izJQVG9wlZpjrSCfRJ7DrNGxp0xy6vVNTuXjW9BP1pobGLHiQjiBiIs9gc3tEG5XaU22etUsVc+lJxPvl3wec4hJK9Zo0GuXO2dAx6JnK3aEgsevfbq3CqOgFFGIEPIXaLhMffCHa+vbq+pw/gofT2jT03K1ngkpY6A8PsCJFHNZot/dVov x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(54094003)(189002)(9686002)(7696004)(3280700002)(2900100001)(76176999)(101416001)(4326007)(5001770100001)(5660300001)(33656002)(81156014)(81166006)(7906003)(19625215002)(2950100001)(99286002)(92566002)(102836003)(105586002)(74316002)(6116002)(8676002)(106356001)(11100500001)(68736007)(50986999)(189998001)(2906002)(97736004)(106116001)(54356999)(586003)(76576001)(93886004)(3660700001)(5002640100001)(86362001)(77096005)(87936001)(7736002)(15975445007)(19580395003)(19580405001)(122556002)(19617315012)(7846002)(16236675004)(10400500002)(2171001)(8936002)(3826002)(18121605002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06340A685CE5890FE14FC15BEAF30CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2016 17:27:26.8044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 17:27:33 -0000 --_000_CY1PR09MB06340A685CE5890FE14FC15BEAF30CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Without taking a position on whether to canon-ize or not (that's a papal th= ing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices wil= l largely moot this issue, i.e., within a particular context the use of PAI= vs. From and the encoding will be constant and ruled by best practices, so= that real devices will just have a configuration setting that says "Look a= t PAI; only if absent, look at From". Clearly, for calls within a carrier n= etwork, this is not likely to be an issue. Not ideal, but the good guys will have an incentive to adhere to common pra= ctice, as they want validation to work. I haven't looked at the details of the SIP NNI spec to see if that spec is = sufficiently precise or whether, say, the SHAKEN ATIS document could provid= e that level of specificity. Unless a parameter can short-circuit the exploration completely ("only look= at X"), I'm not sure 'canon' helps with the resource exhaustion issue. Henning ________________________________ From: stir on behalf of Alan Ford Sent: Friday, September 16, 2016 12:57:39 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi Paul, > Surely the caller and signer bear some responsibility here. If they creat= e a situation where there is ambiguity about which address is being signed = then either they should do something to resolve it (e.g., in include canon)= or else be prepared for the consequences if the callee can't validate. It = is in the caller's interest that the call be validated, so they should be e= xpected to make that feasible. This ultimately comes down to quality of imp= lementation. The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway. But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect. > But there is also a brute force solution available to the validator: try = validation using each of the supplied identities in turn until one validate= s or none do. While that might cost a bit of extra computation, the cost of= that might be less than the cost of carrying the canon parameter from end = to end. That=92s certainly true, but in my opinion the cost of bits is much cheaper= than the cost of computation. What=92s more, a brute-force receiver could = generate a modest denial-of-service attack vector - send a signature for so= mething completely different, and let the verification service munch throug= h cycles trying various combinations to see if any validate (they won=92t, = of course). Minimum would be four combinations tried for just one src and o= ne dest (trying tn: vs sip: combinations) - and this could be many more if = you start to include other identifiers such as PAI or RPID. Whereas, if the= canon was included, there would be one single crypto operation to verify t= he signature against known data. Regards, Alan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_CY1PR09MB06340A685CE5890FE14FC15BEAF30CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Without taking a position on whether to canon-ize or not (that's a papal= thing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices = will largely moot this issue, i.e., within a particular context the use of = PAI vs. From and the encoding will be constant and ruled by best practices, so that real devices will just ha= ve a configuration setting that says "Look at PAI; only if absent, loo= k at From". Clearly, for calls within a carrier network, this is not l= ikely to be an issue.


Not ideal, but the good guys will have an incentive to adhere to common = practice, as they want validation to work.


I haven't looked at the details of the SIP NNI spec to see if that spec = is sufficiently precise or whether, say, the SHAKEN ATIS document could pro= vide that level of specificity.


Unless a parameter can short-circuit the exploration completely ("o= nly look at X"), I'm not sure 'canon' helps with the resource exhausti= on issue.


Henning

From: stir <stir-bounc= es@ietf.org> on behalf of Alan Ford <alan.ford@gmail.com>
Sent: Friday, September 16, 2016 12:57:39 PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?
 
Hi Paul,

> Surely the caller and signer bear some responsibility here. If they cr= eate a situation where there is ambiguity about which address is being sign= ed then either they should do something to resolve it (e.g., in include can= on) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call= be validated, so they should be expected to make that feasible. This ultim= ately comes down to quality of implementation.

The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect.

> But there is also a brute force solution available to the validator: t= ry validation using each of the supplied identities in turn until one valid= ates or none do. While that might cost a bit of extra computation, the cost= of that might be less than the cost of carrying the canon parameter from end to end.

That=92s certainly true, but in my opinion the cost of bits is much cheaper= than the cost of computation. What=92s more, a brute-force receiver could = generate a modest denial-of-service attack vector - send a signature for so= mething completely different, and let the verification service munch through cycles trying various combinations = to see if any validate (they won=92t, of course). Minimum would be four com= binations tried for just one src and one dest (trying tn: vs sip: combinati= ons) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if= the canon was included, there would be one single crypto operation to veri= fy the signature against known data.

Regards,
Alan

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

 --_000_CY1PR09MB06340A685CE5890FE14FC15BEAF30CY1PR09MB0634namp_-- From nobody Fri Sep 16 10:35:45 2016 Return-Path: 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 30A5012B02B for ; Fri, 16 Sep 2016 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 JKUUkbYIM4fS for ; Fri, 16 Sep 2016 10:35:41 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E7A12B137 for ; Fri, 16 Sep 2016 10:35:41 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id w204so94053888qka.0 for ; Fri, 16 Sep 2016 10:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Gm1apDObN5+ixdRzWsQPSZlRHUIthSXnDrV4PVTF/hk=; b=tbHcY9A1mZAk3HhHB9DaXaX2Fwm8Ro8HIqSpdnSppXO/c18+jC3xm4zsV3boXUqzX3 n/J5PNzRmQZbLGImAXDFTyYuxBh9ZHCF7/3QbH6cjQL64wQv9NThmlnb1MbWlcRI0D77 VKax4ZyRdHlF6ip5So8eC/BG4fu/Z8GT3vnhSvySPtE0H2Rjrtn3H1kYY3ZqQBZemE0Y tVp+NXW6flHC/rmCfE8tK5nvmXu0+SO5dZIAablv6cIEXTl9aCvO9ZVpFmWedSH0qu1/ khuWohf0dc7xUr/5MjpWMT+p+wGjABDuwMKbRWIo3aeShJtn1cF3OoDd9xKN2xcDOIgB 6gEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Gm1apDObN5+ixdRzWsQPSZlRHUIthSXnDrV4PVTF/hk=; b=EU+Yj9/RgWH6fL2z3N4zP1oVMxHrzlZ5fdOPGoguu1uI/MXD4EBYvfPvRWlAb+qy8/ G3cJYCEfxZrk0XqZL4E8EiruTxvhXzt/9TqbbtHftHEQSaQ7hqfpgFJjjfN+O1HwxGDP h9IWIDd9KJTHwpiU8OAefdhkemqbhUm3hj3S3HIt63RTBZlZk01tOU3HEtQ1eEwjJfmv oaqTJ2+e62kJ3Yk09KkJgCb2jkJDkP9ruRimr2+VyRaxVS+6BNZqsMygweEygIiJcOGR 7912ofvJEglw8prTRbpRtL/Svbzeyc/zA25nElM7W9VfrRO0Tuc8/2UyeUJK7P1MjmgF 3Q8Q== X-Gm-Message-State: AE9vXwNBiiVzVgF0ipfu8/rt6b2YnOHPjSi3I8yCYjCAkI6un1zw8fpXXdYAQFVd/wwrgg== X-Received: by 10.55.3.193 with SMTP id 184mr16758460qkd.65.1474047340099; Fri, 16 Sep 2016 10:35:40 -0700 (PDT) Received: from [10.33.192.39] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id i65sm5246807qtb.18.2016.09.16.10.35.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 10:35:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_51D32360-0681-43DE-9D1E-775DDA82FDDC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 16 Sep 2016 13:35:35 -0400 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Paul Kyzivat , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 17:35:44 -0000 --Apple-Mail=_51D32360-0681-43DE-9D1E-775DDA82FDDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think it probably would within the ATIS kind of environment, but Alan = is talking about things that are beyond that: his example is a SIP URI = from an enterprise PBX that doesn=92t have a phone number in the = identity. I personally think we need to get the PBX vendors on board as fast as we = can in order to be able to support =93authorized spoofing=94, like call = centers calling on behalf of other enterprises. I think getting the = service providers to sign in those cases will be complicated, and if = they can push the problem off to the call center, it will work out = better. So, I think its worth solving all/most of the problems the PBX = folks think they have. Having said that, the only circumstance I can think of where there is an = identity like he is describing is an intra-enterprise call (possibly = between sites, but within the same enterprise). In those environments, = identity spoofing is much harder to mount because the intra-enterprise = traffic tends to be entirely within the corporate network, and they = don=92t allow calls from sources they don=92t know. Doesn=92t mean stir = should not work, but it=92s pretty far down in my list of things to = worry about. Brian > On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne = wrote: >=20 > Without taking a position on whether to canon-ize or not (that's a = papal thing and I'm not catholic), I wonder if ATIS/SIPForum NNI best = practices will largely moot this issue, i.e., within a particular = context the use of PAI vs. =46rom and the encoding will be constant and = ruled by best practices, so that real devices will just have a = configuration setting that says "Look at PAI; only if absent, look at = From". Clearly, for calls within a carrier network, this is not likely = to be an issue. >=20 > Not ideal, but the good guys will have an incentive to adhere to = common practice, as they want validation to work. >=20 > I haven't looked at the details of the SIP NNI spec to see if that = spec is sufficiently precise or whether, say, the SHAKEN ATIS document = could provide that level of specificity. >=20 > Unless a parameter can short-circuit the exploration completely ("only = look at X"), I'm not sure 'canon' helps with the resource exhaustion = issue. >=20 > Henning > From: stir on behalf of Alan Ford = > Sent: Friday, September 16, 2016 12:57:39 PM > To: Paul Kyzivat > Cc: stir@ietf.org > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? > =20 > Hi Paul, >=20 > > Surely the caller and signer bear some responsibility here. If they = create a situation where there is ambiguity about which address is being = signed then either they should do something to resolve it (e.g., in = include canon) or else be prepared for the consequences if the callee = can't validate. It is in the caller's interest that the call be = validated, so they should be expected to make that feasible. This = ultimately comes down to quality of implementation. >=20 > The sender may or may not know that there would be ambiguity at the = receiving side. For example, the sender may only deal in SIP URIs and = not know the receiver is also a PSTN gateway. >=20 > But in general, I agree, but feel this should be codified. This is why = my proposed resolution here would be to mandate canon unless the sender = knows for certain the receiving environment will follow the same = canonicalisation scheme - or words to that effect. >=20 > > But there is also a brute force solution available to the validator: = try validation using each of the supplied identities in turn until one = validates or none do. While that might cost a bit of extra computation, = the cost of that might be less than the cost of carrying the canon = parameter from end to end. >=20 > That=92s certainly true, but in my opinion the cost of bits is much = cheaper than the cost of computation. What=92s more, a brute-force = receiver could generate a modest denial-of-service attack vector - send = a signature for something completely different, and let the verification = service munch through cycles trying various combinations to see if any = validate (they won=92t, of course). Minimum would be four combinations = tried for just one src and one dest (trying tn: vs sip: combinations) - = and this could be many more if you start to include other identifiers = such as PAI or RPID. Whereas, if the canon was included, there would be = one single crypto operation to verify the signature against known data. >=20 > Regards, > Alan >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_51D32360-0681-43DE-9D1E-775DDA82FDDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I think it probably would within the ATIS kind of = environment, but Alan is talking about things that are beyond that: his = example is a SIP URI from an enterprise PBX that doesn=92t have a phone = number in the identity.

I personally think we need to get the PBX vendors on board as = fast as we can in order to be able to support =93authorized spoofing=94, = like call centers calling on behalf of other enterprises.  I think = getting the service providers to sign in those cases will be = complicated, and if they can push the problem off to the call center, it = will work out better.  So, I think its worth solving all/most of = the problems the PBX folks think they have.

Having said that, the only circumstance = I can think of where there is an identity like he is describing is an = intra-enterprise call (possibly between sites, but within the same = enterprise).  In those environments, identity spoofing is much = harder to mount because the intra-enterprise traffic tends to be = entirely within the corporate network, and they don=92t allow calls from = sources they don=92t know.  Doesn=92t mean stir should not work, = but it=92s pretty far down in my list of things to worry = about.

Brian

On = Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Without taking a position on whether to = canon-ize or not (that's a papal thing and I'm not catholic), I wonder = if ATIS/SIPForum NNI best practices will largely moot this issue, i.e., = within a particular context the use of PAI vs. =46rom and the encoding = will be constant and ruled by best practices, so that real devices will = just have a configuration setting that says "Look at PAI; only if = absent, look at From". Clearly, for calls within a carrier network, this = is not likely to be an issue.

Not ideal, but = the good guys will have an incentive to adhere to common practice, as = they want validation to work.

I haven't = looked at the details of the SIP NNI spec to see if that spec is = sufficiently precise or whether, say, the SHAKEN ATIS document could = provide that level of specificity.

Unless a = parameter can short-circuit the exploration completely ("only look at = X"), I'm not sure 'canon' helps with the resource exhaustion = issue.

Henning
From: stir <stir-bounces@ietf.org> on behalf of Alan Ford <alan.ford@gmail.com>
Sent: Friday, September 16, 2016 = 12:57:39 PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi = Paul,

> Surely the caller and signer = bear some responsibility here. If they create a situation where there is = ambiguity about which address is being signed then either they should do = something to resolve it (e.g., in include canon) or else be prepared for = the consequences if the callee can't validate. It is in the caller's = interest that the call be validated, so they should be expected to make = that feasible. This ultimately comes down to quality of = implementation.

The sender may or may not = know that there would be ambiguity at the receiving side. For example, = the sender may only deal in SIP URIs and not know the receiver is also a = PSTN gateway.

But in general, I agree, but = feel this should be codified. This is why my proposed resolution here = would be to mandate canon unless the sender knows for certain the = receiving environment will follow the same canonicalisation scheme - or = words to that effect.

> But there is = also a brute force solution available to the validator: try validation = using each of the supplied identities in turn until one validates or = none do. While that might cost a bit of extra computation, the cost of = that might be less than the cost of carrying the canon parameter from = end to end.

That=92s certainly true, but in = my opinion the cost of bits is much cheaper than the cost of = computation. What=92s more, a brute-force receiver could generate a = modest denial-of-service attack vector - send a signature for something = completely different, and let the verification service munch through = cycles trying various combinations to see if any validate (they won=92t, = of course). Minimum would be four combinations tried for just one src = and one dest (trying tn: vs sip: combinations) - and this could be many = more if you start to include other identifiers such as PAI or RPID. = Whereas, if the canon was included, there would be one single crypto = operation to verify the signature against known data.

Regards,
Alan

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing = list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_51D32360-0681-43DE-9D1E-775DDA82FDDC-- From nobody Fri Sep 16 10:45:47 2016 Return-Path: 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 A4CDB12B02B for ; Fri, 16 Sep 2016 10:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.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 gemKx8Rlqd09 for ; Fri, 16 Sep 2016 10:45:44 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E03112B0BE for ; Fri, 16 Sep 2016 10:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0PFizY8rCXQpW72r39EUcNEv4q1EfQdDPJF8CpRLLjc=; b=A3Dxq62RjD4MWoJiAJGECUtOUngf7ig7Y3lD8iI0hI8dkyqcfmRLkDx0UsWg+xxksnhikV3NNUq2pIGMBU9Emg+QH50eavSdRJAbuk5WXmg69nu7RxNrsNvEsquHQoXOujTShczeAVmfHBN3P1zNapt4JswD1beKGNKs4ZfQwQc= From: Henning Schulzrinne To: Brian Rosen Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAAxZugIAABekAgAABcQCAAB1nAIAACmAAgAAGigCAAEpQgIAAMowAgACobACAAAXhAIAAFN2AgAAGG2CAAAR+gIAAAFvn Date: Fri, 16 Sep 2016 17:45:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 0b55c135-57dd-4061-e45a-08d3de59457f x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:WhFUB40Oh+BvRCfyS3N6FvRlXlu1S7QHPAVDpFXqop0nCODjf2hYxiN7mdB1so0v+quJwbfB9Cxf/VWlLUXteVpIO3SC5MwExtql6e2FSkuvF8b28h7IskEllEgCf5ZAtcWR9svOu3bqYFBAv5tqfmAqFZUdfbr6lA2y0fv75KSBTIbitoTI2ptqruMzM9BrjVMVLT6gMSTEW/GlZ/an8CnOgWJMPlG/BFiody5NoOzXpL+ub2etZYUxnEUX/ZRAwFvFhqroEdBvonhU6eFqcLZ/uO/9zLSKadSZ3euy3tM=; 5:7BRjYSyj+jYexw1mWn7F7+zIjPrUliTg/n8modnhtzW0TnvmE4DX2orjq3QWLbX3/uhHlvEmaYtfLrDwcRb71RvVZcZeS8DpH4zEdaWY5oPFTGxXf8AC2gmc95OduYnkLAhzHsoIF4mi6hnHiI0Ezw==; 24:h41o6IaKtZGMLOifQ/I7nW6D42u6M3Lo3KD9miNKJHISdScAVGYvHNL6Kfr52yKtzqp+fRoqrefWy+lj7N1ePM+hq2uKKJzl64ubILEdO9E=; 7:WE40oB77ZTl7GGls8nlz75ocq9bWf765BRCoqXQb1VtQdYZlHpjCeujInrSMGocMBUmjLRtgolw6qUO4ZCiK/t2X5UVvLQSD/9BmcaS+4DAeNMM4QjSpQ68BbNiiv61wep0oO77Hb4BInCZGUZH+5ZzSRMOBAOdHd+++dPx+jpdeF9cigGIm5zEeYI98cj5yrqhSDIyolHRcCZ9WG33sLF81wWQDLwercc5vwf13iCvaz/Hp24Gn4XgFqFmbYP3x x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0067A8BA2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(199003)(54094003)(189002)(106356001)(10400500002)(19625215002)(7736002)(7846002)(7906003)(5660300001)(86362001)(5002640100001)(33656002)(8676002)(189998001)(76576001)(68736007)(81156014)(6116002)(586003)(81166006)(97736004)(102836003)(11100500001)(99286002)(50986999)(2906002)(106116001)(4326007)(54356999)(76176999)(7696004)(3660700001)(2950100001)(19580395003)(105586002)(93886004)(9686002)(3280700002)(16236675004)(19580405001)(8936002)(2900100001)(122556002)(15975445007)(87936001)(19627405001)(77096005)(19617315012)(101416001)(92566002)(74316002)(110136003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063491C2A7B48FCF9E078731EAF30CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2016 17:45:38.5984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Cc: "stir@ietf.org" , Paul Kyzivat , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 17:45:47 -0000 --_000_CY1PR09MB063491C2A7B48FCF9E078731EAF30CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Wouldn't this seem like something that SIPConnect 2.0 should address? My general impression is that there are a small number of ways to do things= well, and a near-infinite number of ways to make life difficult for everyb= ody else. Trying to accommodate and detect the latter seems like a fool's e= rrand, given that we want validation to work as close to 100% as possible. = This discussion seems to have yielded a number of reasonable guidelines, al= ong the lines of: * consistently use PAI or From (i.e., be clear what should be used within a= particular operating context, such as SIPConnect or SIP NNI) * only convey return-callable global (E.164) numbers outside your own close= d network * separators in tel URIs should be expected * short codes, N11 and similar numbers will likely only work within a natio= nal context Thus, "be predictable, boring and conservative in what you send, and don't = expect the receiver to be liberal". Here, we have a penalty function: Being "creative" will likely get your cal= l flagged as unvalidated. Henning ________________________________ From: Brian Rosen Sent: Friday, September 16, 2016 1:35:35 PM To: Henning Schulzrinne Cc: Alan Ford; Paul Kyzivat; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? I think it probably would within the ATIS kind of environment, but Alan is = talking about things that are beyond that: his example is a SIP URI from an= enterprise PBX that doesn=92t have a phone number in the identity. I personally think we need to get the PBX vendors on board as fast as we ca= n in order to be able to support =93authorized spoofing=94, like call cente= rs calling on behalf of other enterprises. I think getting the service pro= viders to sign in those cases will be complicated, and if they can push the= problem off to the call center, it will work out better. So, I think its = worth solving all/most of the problems the PBX folks think they have. Having said that, the only circumstance I can think of where there is an id= entity like he is describing is an intra-enterprise call (possibly between = sites, but within the same enterprise). In those environments, identity sp= oofing is much harder to mount because the intra-enterprise traffic tends t= o be entirely within the corporate network, and they don=92t allow calls fr= om sources they don=92t know. Doesn=92t mean stir should not work, but it= =92s pretty far down in my list of things to worry about. Brian On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne > wrote: Without taking a position on whether to canon-ize or not (that's a papal th= ing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices wil= l largely moot this issue, i.e., within a particular context the use of PAI= vs. From and the encoding will be constant and ruled by best practices, so= that real devices will just have a configuration setting that says "Look a= t PAI; only if absent, look at From". Clearly, for calls within a carrier n= etwork, this is not likely to be an issue. Not ideal, but the good guys will have an incentive to adhere to common pra= ctice, as they want validation to work. I haven't looked at the details of the SIP NNI spec to see if that spec is = sufficiently precise or whether, say, the SHAKEN ATIS document could provid= e that level of specificity. Unless a parameter can short-circuit the exploration completely ("only look= at X"), I'm not sure 'canon' helps with the resource exhaustion issue. Henning ________________________________ From: stir > on behalf = of Alan Ford > Sent: Friday, September 16, 2016 12:57:39 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi Paul, > Surely the caller and signer bear some responsibility here. If they creat= e a situation where there is ambiguity about which address is being signed = then either they should do something to resolve it (e.g., in include canon)= or else be prepared for the consequences if the callee can't validate. It = is in the caller's interest that the call be validated, so they should be e= xpected to make that feasible. This ultimately comes down to quality of imp= lementation. The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway. But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect. > But there is also a brute force solution available to the validator: try = validation using each of the supplied identities in turn until one validate= s or none do. While that might cost a bit of extra computation, the cost of= that might be less than the cost of carrying the canon parameter from end = to end. That=92s certainly true, but in my opinion the cost of bits is much cheaper= than the cost of computation. What=92s more, a brute-force receiver could = generate a modest denial-of-service attack vector - send a signature for so= mething completely different, and let the verification service munch throug= h cycles trying various combinations to see if any validate (they won=92t, = of course). Minimum would be four combinations tried for just one src and o= ne dest (trying tn: vs sip: combinations) - and this could be many more if = you start to include other identifiers such as PAI or RPID. Whereas, if the= canon was included, there would be one single crypto operation to verify t= he signature against known data. Regards, Alan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_CY1PR09MB063491C2A7B48FCF9E078731EAF30CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Wouldn't this seem like something that SIPConnect 2.0 should address?


My general impression is that there are a small number of ways to do thi= ngs well, and a near-infinite number of ways to make life difficult for eve= rybody else. Trying to accommodate and detect the latter seems like a fool'= s errand, given that we want validation to work as close to 100% as possible. This discussion seems to have yielde= d a number of reasonable guidelines, along the lines of:


* consistently use PAI or From (i.e., be clear what should be used withi= n a particular operating context, such as SIPConnect or SIP NNI)

* only convey return-callable global (E.164) numbers outside your own cl= osed network

* separators in tel URIs should be expected

* short codes, N11 and similar numbers will likely only work within= a national context


Thus, "be predictable, boring and conservative in what you sen= d, and don't expect the receiver to be liberal".


Here, we have a penalty function: Being "creative" will likely= get your call flagged as unvalidated.


Henning

From: Brian Rosen <br@br= ianrosen.net>
Sent: Friday, September 16, 2016 1:35:35 PM
To: Henning Schulzrinne
Cc: Alan Ford; Paul Kyzivat; stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?
 
I think it probably would within the ATIS kind of environment, but Ala= n is talking about things that are beyond that: his example is a SIP URI fr= om an enterprise PBX that doesn=92t have a phone number in the identity.

I personally think we need to get the PBX vendors on board = as fast as we can in order to be able to support =93authorized spoofing=94,= like call centers calling on behalf of other enterprises.  I think ge= tting the service providers to sign in those cases will be complicated, and if they can push the problem off to the cal= l center, it will work out better.  So, I think its worth solving all/= most of the problems the PBX folks think they have.

Having said that, the only circumstance I can think of wher= e there is an identity like he is describing is an intra-enterprise call (p= ossibly between sites, but within the same enterprise).  In those envi= ronments, identity spoofing is much harder to mount because the intra-enterprise traffic tends to be entirely within = the corporate network, and they don=92t allow calls from sources they don= =92t know.  Doesn=92t mean stir should not work, but it=92s pretty far= down in my list of things to worry about.

Brian

On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc= .gov> wrote:

Without taki= ng a position on whether to canon-ize or not (that's a papal thing and I'm = not catholic), I wonder if ATIS/SIPForum NNI best practices will largely mo= ot this issue, i.e., within a particular context the use of PAI vs. From and the encoding will be constant and rule= d by best practices, so that real devices will just have a configuration se= tting that says "Look at PAI; only if absent, look at From". Clea= rly, for calls within a carrier network, this is not likely to be an issue.

Not ideal, b= ut the good guys will have an incentive to adhere to common practice, as th= ey want validation to work.

I haven't lo= oked at the details of the SIP NNI spec to see if that spec is sufficiently= precise or whether, say, the SHAKEN ATIS document could provide that level= of specificity.

Unless a par= ameter can short-circuit the exploration completely ("only look at X&q= uot;), I'm not sure 'canon' helps with the resource exhaustion issue.

Henning
From: stir <stir-bounces@ietf.org> on behalf of Alan Ford <alan.ford@gmail.com>
Sent: F= riday, September 16, 2016 12:57:39 PM
To: Pau= l Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?
 
Hi Paul,

> Surely the caller and signer bear some responsibility here. If they cr= eate a situation where there is ambiguity about which address is being sign= ed then either they should do something to resolve it (e.g., in include can= on) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call= be validated, so they should be expected to make that feasible. This ultim= ately comes down to quality of implementation.

The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect.

> But there is also a brute force solution available to the validator: t= ry validation using each of the supplied identities in turn until one valid= ates or none do. While that might cost a bit of extra computation, the cost= of that might be less than the cost of carrying the canon parameter from end to end.

That=92s certainly true, but in my opinion the cost of bits is much cheaper= than the cost of computation. What=92s more, a brute-force receiver could = generate a modest denial-of-service attack vector - send a signature for so= mething completely different, and let the verification service munch through cycles trying various combinations = to see if any validate (they won=92t, of course). Minimum would be four com= binations tried for just one src and one dest (trying tn: vs sip: combinati= ons) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if= the canon was included, there would be one single crypto operation to veri= fy the signature against known data.

Regards,
Alan

_______________________________________________
stir mailing list
stir@ietf.org
https://w= ww.ietf.org/mailman/listinfo/stir

= _______________________________________________
stir mailing list
stir@ietf.org
https:= //www.ietf.org/mailman/listinfo/stir

--_000_CY1PR09MB063491C2A7B48FCF9E078731EAF30CY1PR09MB0634namp_-- From nobody Fri Sep 16 10:53:49 2016 Return-Path: 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 CBCAE12B2DA for ; Fri, 16 Sep 2016 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 Gc81bxj-V9db for ; Fri, 16 Sep 2016 10:53:45 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED0812B2E2 for ; Fri, 16 Sep 2016 10:53:45 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id t7so95668055qkh.2 for ; Fri, 16 Sep 2016 10:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AQ8bzmujyRr+LLPzrvty+Vedliki3yP3xgBad5v9u1E=; b=pjoyhE1dYJVHYVU7NUU8YRLuyLOXKKD+GFaInYihjuhkUXSp62JuO3Z3ohEj7see3B ApUqt7LeLNvQQ8oI4GrKNC79XzbkphLbpQU0Ko79apzpwrH04Wm63cUVFMfpMQPCQ4nk jSMt3ELtihBibTQcN/YjR4JqSlaqq9qVCrsA0255H0dPS94AYT0U59aqNDwi+plePsVm 1ijkL0Omxgm/o0HJ5B8asV6Gjlbw25PcCaaTCkz1Z+QevC/oodsGCz3EQ+hwr9pGyV+S nkxQoVdxCpCwOMop4S5xYEavNHhdxujYI2DQ7pZi+pnG1UlkU6rqk5KIopU6CyJVeNza OemQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AQ8bzmujyRr+LLPzrvty+Vedliki3yP3xgBad5v9u1E=; b=D1N99qlq2gnmSAD/7jgW5f3CPC6PpyJrmqLl2dG2kP6P65RtZU0fHIteWRz+zWwgNv 2Re90QgnN5Sxpvcz/B7p6HKJAVU6nA/rwAoyJWaH6nHjs02cmiTv61BnELgStEvREJJM Q1jAgVZOg4dMevfOUMpsNW5K/j5bN7KO7yGFPebWDPp4gXIdxCGNwvLtg3GT01XqPrAY HBe6l2+zMdtNltGTG9MiNoQvU87PlXq9AbRHfEMAZBOhiIZy9A7b70JxE6OQErqu1EgW PTMjhHLTXy/AH/JHtXGbX8MnssBVnD0fGMDN6xjrZshhnmnUioDpTHuUnn4D5AqxgIO6 0lNg== X-Gm-Message-State: AE9vXwNRPojT1ZsgG6FVWXG80vvpJeNmqGrsxY0gHJ4uu/pL8Q+uaRXj+nTv2tpPDGtGdA== X-Received: by 10.55.44.69 with SMTP id s66mr17882360qkh.174.1474048424314; Fri, 16 Sep 2016 10:53:44 -0700 (PDT) Received: from [10.33.192.39] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id s40sm5335664qtc.3.2016.09.16.10.53.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 10:53:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D73B169-3D8E-4CAC-925C-E32954C01ED8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 16 Sep 2016 13:53:40 -0400 Message-Id: <155C42F7-A9FA-47B6-8065-4CDC3B1AD3B9@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Paul Kyzivat , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 17:53:48 -0000 --Apple-Mail=_4D73B169-3D8E-4CAC-925C-E32954C01ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 My understanding of SIPconnect 2.0 is that it=92s still an enterprise to = service provider handoff interface, and thus would assume real telephone = numbers in the identity, but I=92m not directly involved. But I=92m in agreement with your points. Brian > On Sep 16, 2016, at 1:45 PM, Henning Schulzrinne = wrote: >=20 > Wouldn't this seem like something that SIPConnect 2.0 should address? >=20 > My general impression is that there are a small number of ways to do = things well, and a near-infinite number of ways to make life difficult = for everybody else. Trying to accommodate and detect the latter seems = like a fool's errand, given that we want validation to work as close to = 100% as possible. This discussion seems to have yielded a number of = reasonable guidelines, along the lines of: >=20 > * consistently use PAI or =46rom (i.e., be clear what should be used = within a particular operating context, such as SIPConnect or SIP NNI) > * only convey return-callable global (E.164) numbers outside your own = closed network > * separators in tel URIs should be expected > * short codes, N11 and similar numbers will likely only work within a = national context >=20 > Thus, "be predictable, boring and conservative in what you send, and = don't expect the receiver to be liberal". >=20 > Here, we have a penalty function: Being "creative" will likely get = your call flagged as unvalidated. >=20 > Henning > From: Brian Rosen > Sent: Friday, September 16, 2016 1:35:35 PM > To: Henning Schulzrinne > Cc: Alan Ford; Paul Kyzivat; stir@ietf.org > Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? > =20 > I think it probably would within the ATIS kind of environment, but = Alan is talking about things that are beyond that: his example is a SIP = URI from an enterprise PBX that doesn=92t have a phone number in the = identity. >=20 > I personally think we need to get the PBX vendors on board as fast as = we can in order to be able to support =93authorized spoofing=94, like = call centers calling on behalf of other enterprises. I think getting = the service providers to sign in those cases will be complicated, and if = they can push the problem off to the call center, it will work out = better. So, I think its worth solving all/most of the problems the PBX = folks think they have. >=20 > Having said that, the only circumstance I can think of where there is = an identity like he is describing is an intra-enterprise call (possibly = between sites, but within the same enterprise). In those environments, = identity spoofing is much harder to mount because the intra-enterprise = traffic tends to be entirely within the corporate network, and they = don=92t allow calls from sources they don=92t know. Doesn=92t mean stir = should not work, but it=92s pretty far down in my list of things to = worry about. >=20 > Brian >=20 >> On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne = > = wrote: >>=20 >> Without taking a position on whether to canon-ize or not (that's a = papal thing and I'm not catholic), I wonder if ATIS/SIPForum NNI best = practices will largely moot this issue, i.e., within a particular = context the use of PAI vs. =46rom and the encoding will be constant and = ruled by best practices, so that real devices will just have a = configuration setting that says "Look at PAI; only if absent, look at = From". Clearly, for calls within a carrier network, this is not likely = to be an issue. >>=20 >> Not ideal, but the good guys will have an incentive to adhere to = common practice, as they want validation to work. >>=20 >> I haven't looked at the details of the SIP NNI spec to see if that = spec is sufficiently precise or whether, say, the SHAKEN ATIS document = could provide that level of specificity. >>=20 >> Unless a parameter can short-circuit the exploration completely = ("only look at X"), I'm not sure 'canon' helps with the resource = exhaustion issue. >>=20 >> Henning >> From: stir > on = behalf of Alan Ford > >> Sent: Friday, September 16, 2016 12:57:39 PM >> To: Paul Kyzivat >> Cc: stir@ietf.org >> Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple = identities? >> =20 >> Hi Paul, >>=20 >> > Surely the caller and signer bear some responsibility here. If they = create a situation where there is ambiguity about which address is being = signed then either they should do something to resolve it (e.g., in = include canon) or else be prepared for the consequences if the callee = can't validate. It is in the caller's interest that the call be = validated, so they should be expected to make that feasible. This = ultimately comes down to quality of implementation. >>=20 >> The sender may or may not know that there would be ambiguity at the = receiving side. For example, the sender may only deal in SIP URIs and = not know the receiver is also a PSTN gateway. >>=20 >> But in general, I agree, but feel this should be codified. This is = why my proposed resolution here would be to mandate canon unless the = sender knows for certain the receiving environment will follow the same = canonicalisation scheme - or words to that effect. >>=20 >> > But there is also a brute force solution available to the = validator: try validation using each of the supplied identities in turn = until one validates or none do. While that might cost a bit of extra = computation, the cost of that might be less than the cost of carrying = the canon parameter from end to end. >>=20 >> That=92s certainly true, but in my opinion the cost of bits is much = cheaper than the cost of computation. What=92s more, a brute-force = receiver could generate a modest denial-of-service attack vector - send = a signature for something completely different, and let the verification = service munch through cycles trying various combinations to see if any = validate (they won=92t, of course). Minimum would be four combinations = tried for just one src and one dest (trying tn: vs sip: combinations) - = and this could be many more if you start to include other identifiers = such as PAI or RPID. Whereas, if the canon was included, there would be = one single crypto operation to verify the signature against known data. >>=20 >> Regards, >> Alan >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir = >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir = --Apple-Mail=_4D73B169-3D8E-4CAC-925C-E32954C01ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 My understanding of SIPconnect 2.0 is that it=92s still an = enterprise to service provider handoff interface, and thus would assume = real telephone numbers in the identity, but I=92m not directly = involved.

But I=92m = in agreement with your points.

Brian

On = Sep 16, 2016, at 1:45 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Wouldn't this seem like something that SIPConnect 2.0 should = address?

My general impression is that there are = a small number of ways to do things well, and a near-infinite number of = ways to make life difficult for everybody else. Trying to accommodate = and detect the latter seems like a fool's errand, given that we want = validation to work as close to 100% as possible. This discussion seems = to have yielded a number of reasonable guidelines, along the lines = of:

* consistently use PAI or =46rom (i.e., = be clear what should be used within a particular operating context, such = as SIPConnect or SIP NNI)
* only convey return-callable global = (E.164) numbers outside your own closed network
* separators = in tel URIs should be expected
* short codes, N11 and similar = numbers will likely only work within a national context

Thus, "be predictable, boring and conservative in what = you send, and don't expect the receiver to be liberal".

Here, we have a penalty function: Being "creative" will = likely get your call flagged as unvalidated.

Henning
From: Brian Rosen <br@brianrosen.net>
Sent: Friday, September 16, 2016 = 1:35:35 PM
To: Henning Schulzrinne
Cc: Alan Ford; Paul Kyzivat; stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
I think it probably would within the ATIS kind of = environment, but Alan is talking about things that are beyond that: his = example is a SIP URI from an enterprise PBX that doesn=92t have a phone = number in the identity.

I personally think we need to get the PBX vendors on board as = fast as we can in order to be able to support =93authorized spoofing=94, = like call centers calling on behalf of other enterprises.  I think = getting the service providers to sign in those cases will be = complicated, and if they can push the problem off to the call center, it = will work out better.  So, I think its worth solving all/most of = the problems the PBX folks think they have.

Having said that, the only circumstance = I can think of where there is an identity like he is describing is an = intra-enterprise call (possibly between sites, but within the same = enterprise).  In those environments, identity spoofing is much = harder to mount because the intra-enterprise traffic tends to be = entirely within the corporate network, and they don=92t allow calls from = sources they don=92t know.  Doesn=92t mean stir should not work, = but it=92s pretty far down in my list of things to worry = about.

Brian

On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

Without taking a = position on whether to canon-ize or not (that's a papal thing and I'm = not catholic), I wonder if ATIS/SIPForum NNI best practices will largely = moot this issue, i.e., within a particular context the use of PAI vs. = =46rom and the encoding will be constant and ruled by best practices, so = that real devices will just have a configuration setting that says "Look = at PAI; only if absent, look at From". Clearly, for calls within a = carrier network, this is not likely to be an issue.

Not ideal, but = the good guys will have an incentive to adhere to common practice, as = they want validation to work.

I haven't looked at the = details of the SIP NNI spec to see if that spec is sufficiently precise = or whether, say, the SHAKEN ATIS document could provide that level of = specificity.

Unless a parameter can = short-circuit the exploration completely ("only look at X"), I'm not = sure 'canon' helps with the resource exhaustion issue.

Henning
From: stir <stir-bounces@ietf.org> on behalf of Alan Ford <alan.ford@gmail.com>
Sent: Friday, September 16, 2016 = 12:57:39 PM
To: Paul Kyzivat
Cc: stir@ietf.org
Subject: Re: [stir] 4474bis: Why = only RECOMMEND when multiple identities?
 
Hi Paul,

> Surely = the caller and signer bear some responsibility here. If they create a = situation where there is ambiguity about which address is being signed = then either they should do something to resolve it (e.g., in include = canon) or else be prepared for the consequences if the callee can't = validate. It is in the caller's interest that the call be validated, so = they should be expected to make that feasible. This ultimately comes = down to quality of implementation.

The = sender may or may not know that there would be ambiguity at the = receiving side. For example, the sender may only deal in SIP URIs and = not know the receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. = This is why my proposed resolution here would be to mandate canon unless = the sender knows for certain the receiving environment will follow the = same canonicalisation scheme - or words to that effect.

> But there is also a brute force solution available to = the validator: try validation using each of the supplied identities in = turn until one validates or none do. While that might cost a bit of = extra computation, the cost of that might be less than the cost of = carrying the canon parameter from end to end.

That=92s certainly true, but in my opinion the cost of bits = is much cheaper than the cost of computation. What=92s more, a = brute-force receiver could generate a modest denial-of-service attack = vector - send a signature for something completely different, and let = the verification service munch through cycles trying various = combinations to see if any validate (they won=92t, of course). Minimum = would be four combinations tried for just one src and one dest (trying = tn: vs sip: combinations) - and this could be many more if you start to = include other identifiers such as PAI or RPID. Whereas, if the canon was = included, there would be one single crypto operation to verify the = signature against known data.

Regards,
Alan

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_4D73B169-3D8E-4CAC-925C-E32954C01ED8-- From nobody Fri Sep 16 11:00:45 2016 Return-Path: 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 2E37112B15C for ; Fri, 16 Sep 2016 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 WCwk9-xzkbJ0 for ; Fri, 16 Sep 2016 11:00:40 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785DC12B196 for ; Fri, 16 Sep 2016 11:00:40 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u8GHrYng024553; Fri, 16 Sep 2016 14:00:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=vzGYfNCXiJmiMkq1xnrfTipPBgXGOh5nvoNR+cNmau4=; b=OAkX9tLL91zfs4jeUb5/dy7bo2Ben5XBKZm0hRgnQU15nfi4XEWE4tmMkFyZbspFoNTj 1PApUvqjh0gc8zDBqijBuhdADBycXSCDqw0kNDNlG2qsaZeKts9GTqK4QRIrK7MEKsjz PYkcMzkfFJyXjgjOvoGTkaPOS5IaTxIcXJytPrjoRqtPiNRi4Yj0pDlimojksaqZaPd7 K5Yfi5qgo1kPUySxX+Pp6OTSS7tkeOc8kuZy78cknSQzDNeLZjzo8IBfxzxGbVrhDWQf 26LFRjSqVLPGhPOzwTAhZ3OT7ZveRKwTMn7Mt4vjbUpYGykUB6uRktbE+p+dLRm5V6Aa fA== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 25ceg9s5ap-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 16 Sep 2016 14:00:34 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Fri, 16 Sep 2016 14:00:33 -0400 From: "Peterson, Jon" To: Alan Ford Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAA1l8gIAABekAgAABcQD//6g2gIAAf5EA//+RW4CAAL9/gP//vV8AACOzNwD//7ckAA== Date: Fri, 16 Sep 2016 18:00:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> In-Reply-To: <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.120] Content-Type: multipart/alternative; boundary="_000_D40179DE1B58EAjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609160225 Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 18:00:43 -0000 --_000_D40179DE1B58EAjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This comes back to the same problem, fundamentally. =93Local policy tells y= ou=94 - that=92s great, but when applied to STIR this requires both the sen= der and the receiver to have the same local policy. It is a fundamental requirement of using PAI that it be true that the sende= r and receiver have the same local policy for this. That I what RFC3324 exi= sts to say. If we take that away, none of the mechanism around PAI really w= orks. This is why I've been saying if something is broken here, it's broken= in PAI. Our current real-world problem is the SIP/TN decision process at the receiv= er, particularly for destination address(es), but it=92s also becoming appa= rent that for compatibility the other issues raised here, such as selection= of PAI vs From, are likely to cause problems. If Brian's cert hint fixes the first problem, I am pretty comfortable sayin= g that I'm not worried about the second problem (at least for the purposes = of rfc4474bis). As Henning recently suggested, in the trusted networks wher= e PAI is used, there are probably going to be profiles that govern the loca= l policy that will at least make it clear to the participants in the trust = network. All we need to do is what rfc3325 tells us - to rely on those netw= orks to do their job. Indeed not. But, it tells the receiver which fields to look in, and what fo= rm of canonicalisation to undertake. This is A Good Thing from an implement= ation and interoperability point of view. Only if you think that the way that the state in which the authentication s= ervice saw these fields should determine for the verifier what the "real" i= dentity of the originator is. That is not an assumption we make, or should = make. Since we're still talking about this, maybe we should also bring this back = to the gatewaying and mixed-SIP cases that informed this decision. I hesita= te to move indications into PASSporT that say things like "I got this ident= ity from a PAI" because PASSporT shouldn't have those sorts of dependencies= on a using protocol. I similarly can imagine a case where a VoIP call star= ts in, say, Jingle, and lands eventually on a SIP endpoint, with some gatew= ay in the middle. The original Jingle authentication service didn't derive = its TN from any SIP header at all. Cases like that should be in our scope o= f consideration here. I would ultimately prefer not to festoon PASSporT with SIP-specific indicat= ors. The presence of canon cannot influence the verification service decision: w= e want security to fail (which, I feel obliged to say, doesn't necessarily = mean rejecting the request) if the verification service canonicalization do= es not resolve to the same value that the auth service used. That is what t= his mechanism is designed to do. But this is the problem! When a sender does not know its target would canon= icalise the destination address as a TN, and thus encodes it as a SIP URI i= n the PASSporT object, verification would fail. But with canon, the verific= ation service could be more intelligent, as it may be able to pass all othe= r verification logic if it knew how the field had been canonicalised. I am indeed saying that is a security bug, not a feature. Though surely an = attacker would like to make the verification service "more intelligent" by = telling it "try to see things my way." We both agree that "canon" should at least be allowed, and when it is prese= nt, I think it is meaningful for the verification service to compare the ca= nonicalized value(s) it found in the message with the orig value of the PAS= SporT object as a step in the verification process. That doesn't raise any = alarm bells for me. As soon as this becomes instead about how the verificat= ion service should decide based on the information in "canon" how its canon= icalization process should work., that trips the alarm loud and clear. Verification failing in this circumstance is surely bad? The value of "canon" is only there for debugging and optimization purposes,= we say this many times in the spec. It is NOT there to tunnel some "secret= " value for the telephone number between the authentication service and ver= ification service, as that would be a huge security hole. And it wouldn't w= ork anyway because as I said above intermediaries could just change it. The= neat thing about not including "canon" is that intermediaries can't change= something that isn't in the message. This was effectively the argument Had= riel and others made back in the day. Sorry, I don=92t follow any of the above. Including canon does not add any = security hole, it does not allow intermediaries to change anything, since i= t is protected by the signature. ... the PASSport object is not a security hole in the sense that it lacks i= ntegrity protection. The security hole appears only if we stipulate that th= e verification service trusts that the orig tn value in the PASSporT object= is a canonicalization of whatever identity the SIP request carries. I don=92t think anyone is suggesting that should be the logic. I certainly = am not. I cannot distinguish what you are recommending from this. A receiver can receive the canon, validate the signature against the canon,= and then validate the fields. This makes much more sense from an implement= ation point of view than trying to guess the construction of the PASSporT o= bject from the fields in the SIP message, and then seeing if this validates= . The problem here is hiding behind what you mean by "validate the fields". T= he comparison operation that the verification service performs to do that v= alidation requires it to perform the entire canonicalization process itself= . rfc4474bis says that the verification service, *before* it bothers to val= idate the signature, optionally can perform this function, and compare the = value it gets as a result against the orig tn in PASSporT (when present), s= olely as an optimization - so if there's no match is won't need to do the c= rypto. So it's not that I disagree that there's an optimization pass we can= make, if "canon" is present. I just get very nervous when I hear this fram= ed the other way, as more than an optimization, but instead as a substitute= for having to "guess the construction of the PASSporT object from the fiel= ds of the SIP message," which is indeed an apt description of the procedure= s that rfc4474bis requires. I may be being slow here, and apologies if so, but I still don=92t understa= nd what benefit is brought by not sharing the construction. Well, let me put it this way. When you have fourteen identities in a messag= e, there is a natural temptation to say that what we need is a new field th= at will let recipients know what the "real" identity is to remove ambiguity= . The result of that is inevitably that we now have fifteen identities in a= message. Make no mistake: the orig value in canon is just a fifteenth iden= tity. The kinds of intermediaries that change identities will not see the o= ne in canon any differently. Hadriel argued (and as the foremost SBC vendor at the time, I'd say persuas= ively) that including the value only makes it a target for intermediaries t= o modify, and consequently to break the signature in the PASSporT object - = or indeed to just remove the Identity header and PASSporT object altogether= . The policies that make intermediaries modify the identity in the From hea= der will not spare the contents of canon. This is how we came to the idea o= f allowing intermediaries to change the bits a little as they went by, unde= r the assumption that the two ends would be able to figure out what number = was meant. We studied this a bit at the time and came to the conclusion tha= t it would work in the cases where SIP is likely to work anyway. It sounds like you are arguing there are two binary options here: no shared= canon, so both parties trust the other to perform the same process; or sha= re a canon, and it sounds as if you believe that would mean =93well the can= on is signed so this is obviously a valid canonicalisation of what=92s in t= he header=94. Which is obviously completely insecure. I think what I've argued is that canon should be optional because its big a= nd and it probably doesn't help as much as one might think. And that it mig= ht even hurt in some cases (like the ones Hadriel spoke to). But that for d= ebugging or optimizations, it might still be useful in some transactions. I=92m saying there=92s a middle ground here. When there are multiple possib= ilities for canonicalisation, providing the canon helps the verification se= rvice decide which one to use. This is exactly not what canon is for, and if it were, it would be a proble= m. The security remains the same, as long as the canonicalisation process bein= g followed is one that is trusted by the verification service anyway. If the canonicalization process the verifier was going to follow would have= worked anyway, there's no need for the influence you're suggesting. My proposal, just to reiterate, is to mandate the presence of canon unless = STIR is being used between environments where both parties are known to hav= e a common canonicalisation scheme PAI has all sorts of funky assumptions about being in a trusted network and= knowing what the policies will be at the place you land. rfc4474bis does n= ot, and should not. The only reason we're even in this discussion is becaus= e we allowed Identity to sign PAI rather than From, and thus PAI's murkines= s is creeping into the edges of the rfc4474bis process. It should stay at t= he edges. If there are ambiguities this introduces, they should be fixed at= the PAI level (which probably means in profile documents for the trust net= works that use PAI). Jon Peterson Neustar, Inc. Regards, Alan --_000_D40179DE1B58EAjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2412E41363C9A2428223DCEBB0454F54@neustar.biz> Content-Transfer-Encoding: quoted-printable
This comes back to the same problem, fundamentally. =93Local policy te= lls you=94 - that=92s great, but when applied to STIR this requires both th= e sender and the receiver to have the same local policy.

It is a fundamental requirement of using PAI that it be true that the = sender and receiver have the same local policy for this. That I what RFC332= 4 exists to say. If we take that away, none of the mechanism around PAI rea= lly works. This is why I've been saying if something is broken here, it's broken in PAI. 

Our current real-world problem is the SIP/TN decision proce= ss at the receiver, particularly for destination address(es), but it=92s al= so becoming apparent that for compatibility the other issues raised here, s= uch as selection of PAI vs From, are likely to cause problems.

If Brian's cert hint fixes the first problem, I am pretty comfortable = saying that I'm not worried about the second problem (at least for the purp= oses of rfc4474bis). As Henning recently suggested, in the trusted networks= where PAI is used, there are probably going to be profiles that govern the local policy that will at least make = it clear to the participants in the trust network. All we need to do is wha= t rfc3325 tells us - to rely on those networks to do their job.

Indeed not. But, it tells the receiver which fields to look= in, and what form of canonicalisation to undertake. This is A Good Thing f= rom an implementation and interoperability point of view.

Only if you think that the way that the state in which the authenticat= ion service saw these fields should determine for the verifier what the &qu= ot;real" identity of the originator is. That is not an assumption we m= ake, or should make. 

Since we're still talking about this, maybe we should also bring this = back to the gatewaying and mixed-SIP cases that informed this decision. I h= esitate to move indications into PASSporT that say things like "I got = this identity from a PAI" because PASSporT shouldn't have those sorts of dependencies on a using protocol. I similarl= y can imagine a case where a VoIP call starts in, say, Jingle, and lands ev= entually on a SIP endpoint, with some gateway in the middle. The original J= ingle authentication service didn't derive its TN from any SIP header at all. Cases like that should be in our= scope of consideration here.

I would ultimately prefer not to festoon PASSporT with SIP-specific in= dicators.


The presence of canon cannot influence the verification service decision: w= e want security to fail (which, I feel obliged to say, doesn't necessarily = mean rejecting the request) if the verification service canonicalization do= es not resolve to the same value that the auth service used. That is what this mechanism is designed to do.=

But this is the problem! When a sender does not know its target would = canonicalise the destination address as a TN, and thus encodes it as a SIP = URI in the PASSporT object, verification would fail. But with canon, the ve= rification service could be more intelligent, as it may be able to pass all other verification logic if it = knew how the field had been canonicalised.

I am indeed saying that is a security bug, not a feature. Though surel= y an attacker would like to make the verification service "more intell= igent" by telling it "try to see things my way." 

We both agree that "canon" should at least be allowed, and w= hen it is present, I think it is meaningful for the verification service to= compare the canonicalized value(s) it found in the message with the orig v= alue of the PASSporT object as a step in the verification process. That doesn't raise any alarm bells for me. As soon a= s this becomes instead about how the verification service should decide bas= ed on the information in "canon" how its canonicalization process= should work., that trips the alarm loud and clear.


Verification failing in this circumstance is surely bad?


Sorry, I don=92t follow any of the above. Including canon d= oes not add any security hole, it does not allow intermediaries to change a= nything, since it is protected by the signature.

... the PASSport object is not a security hole in the sense that it lacks i= ntegrity protection. The security hole appears only if we stipulate that th= e verification service trusts that the orig tn value in the PASSporT object= is a canonicalization of whatever identity the SIP request carries.

I don=92t think anyone is suggesting that should be the logic. I certa= inly am not.

I cannot distinguish what you are recommending from this.



A receiver can receive the canon, validate the signature against the c= anon, and then validate the fields. This makes much more sense from an = implementation point of view than trying to guess the construction of the PASSporT object from the fields in the SIP m= essage, and then seeing if this validates.

The problem here is hiding behind what you mean by "validate the field= s". The comparison operation that the verification service performs to= do that validation requires it to perform the entire canonicalization proc= ess itself. rfc4474bis says that the verification service, *before* it bothers to validate the signature, optionally can per= form this function, and compare the value it gets as a result against the o= rig tn in PASSporT (when present), solely as an optimization - so if there'= s no match is won't need to do the crypto. So it's not that I disagree that there's an optimization pass we c= an make, if "canon" is present. I just get very nervous when I he= ar this framed the other way, as more than an optimization, but instead as = a substitute for having to "guess the construction of the PASSporT object from the fields of the SIP message," which is = indeed an apt description of the procedures that rfc4474bis requires.

I may be being slow here, and apologies if so, but I still don=92t und= erstand what benefit is brought by not sharing the c= onstruction.

Well, let me put it this way. When you have fourteen identities in a m= essage, there is a natural temptation to say that what we need is a new fie= ld that will let recipients know what the "real" identity is to r= emove ambiguity. The result of that is inevitably that we now have fifteen identities in a message. Make no mistake: the ori= g value in canon is just a fifteenth identity. The kinds of intermediaries = that change identities will not see the one in canon any differently.

Hadriel argued (and as the foremost SBC vendor at the time, I'd say pe= rsuasively) that including the value only makes it a target for intermediar= ies to modify, and consequently to break the signature in the PASSporT obje= ct - or indeed to just remove the Identity header and PASSporT object altogether. The policies that make int= ermediaries modify the identity in the From header will not spare the conte= nts of canon. This is how we came to the idea of allowing intermediaries to= change the bits a little as they went by, under the assumption that the two ends would be able to figure ou= t what number was meant. We studied this a bit at the time and came to the = conclusion that it would work in the cases where SIP is likely to work anyw= ay. 

It sounds like you are arguing there are two binary options here: no s= hared canon, so both parties trust the other to perform the same process; o= r share a canon, and it sounds as if you believe that would mean =93well th= e canon is signed so this is obviously a valid canonicalisation of what=92s in the header=94. Which is obviously = completely insecure.

I think what I've argued is that canon should be optional because its = big and and it probably doesn't help as much as one might think. And that i= t might even hurt in some cases (like the ones Hadriel spoke to). But that = for debugging or optimizations, it might still be useful in some transactions.

I=92m saying there=92s a middle ground here. When there are multiple p= ossibilities for canonicalisation, providing the canon helps the verificati= on service decide which one to use.

This is exactly not what canon is for, and if it were, it would be a p= roblem.

The security remains the same, as long as the canonicalisation process= being followed is one that is trusted by the verification service anyway.<= /div>

If the canonicalization process the verifier was going to follow would= have worked anyway, there's no need for the influence you're suggesting.

My proposal, just to reiterate, is to mandate the presence of canon un= less STIR is being used between environments where both parties are known to have a common canonicalisation scheme

PAI has all sorts of funky assumptions about being in a trusted networ= k and knowing what the policies will be at the place you land. rfc4474bis d= oes not, and should not. The only reason we're even in this discussion is b= ecause we allowed Identity to sign PAI rather than From, and thus PAI's murkiness is creeping into the edges = of the rfc4474bis process. It should stay at the edges. If there are ambigu= ities this introduces, they should be fixed at the PAI level (which probabl= y means in profile documents for the trust networks that use PAI).

Jon Peterson
Neustar, Inc.


Regards,
Alan

 --_000_D40179DE1B58EAjonpetersonneustarbiz_-- From nobody Fri Sep 16 11:11:59 2016 Return-Path: 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 0250512B15C for ; Fri, 16 Sep 2016 11:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 OP2-r22_taFa for ; Fri, 16 Sep 2016 11:11:53 -0700 (PDT) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 9D4BA12B091 for ; Fri, 16 Sep 2016 11:11:53 -0700 (PDT) Received: (qmail 24730 invoked by uid 0); 16 Sep 2016 18:11:49 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 16 Sep 2016 18:11:49 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id kJ6k1t00T1MNPNq01J6nuU; Fri, 16 Sep 2016 12:06:49 -0600 X-Authority-Analysis: v=2.1 cv=Hq7lRSjS c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=etTHQkYnwnYA:10 a=GW1xBdLrtEIA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=HLLxP2VMAAAA:8 a=pGLkceISAAAA:8 a=5Pww0n7xp8wCGTMjetIA:9 a=QcqpL-m4RAM3QgGw:21 a=qGR0FSLh1HWL3o1v:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=FKTECtPwPprl9QqCYmUA:9 a=34es5TxDbAfKjbzH:21 a=Ak6LU6PzdNldzVPO:21 a=FgAbE342HnSWkyrp:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=5oret6oapBRfLy7jekVI:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date; bh=2i6c+mKUFANhOlsEiESr//K2fiVdWEYtld4AarpRfys=; b=DISX OzS2Jla4TxsJjdzBf8hsz3Yk/30aijRQ6Fp/QcamG7hJcoSEy1O0HRVfmajhI6qqP+uBsYOMCfnfP PQVwHEci4wAcvhllYkxhFOKyp2/EvWlpwEn25MlxBvgRFz0; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:53575 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bkxXA-0005F0-0I; Fri, 16 Sep 2016 12:06:44 -0600 User-Agent: Microsoft-MacOutlook/f.1a.0.160910 Date: Fri, 16 Sep 2016 14:06:42 -0400 From: Richard Shockey To: Henning Schulzrinne , Brian Rosen Message-ID: Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3556879603_482358256" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.40.228 authed with richard+shockey.us} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-Source-IP: 100.36.40.228 X-Exim-ID: 1bkxXA-0005F0-0I X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:53575 X-Source-Auth: richard+shockey.us X-Email-Count: 0 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "stir@ietf.org" , Paul Kyzivat , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Fri, 16 Sep 2016 18:11:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3556879603_482358256 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 Probably more like SIP Connect 3.0.=C2=A0=C2=A0 2.0 is in ballot as we speak but bo= th points are well taken.=C2=A0=20 =20 These are exactly the kind of issues that can be dealt with in implementati= on profiles or BCP=E2=80=99s as the case may be. =C2=A0 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 =20 From: stir on behalf of Henning Schulzrinne Date: Friday, September 16, 2016 at 1:45 PM To: Brian Rosen Cc: "stir@ietf.org" , Paul Kyzivat , = Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? =20 Wouldn't this seem like something that SIPConnect 2.0 should address? =20 My general impression is that there are a small number of ways to do things= well, and a near-infinite number of ways to make life difficult for everybo= dy else. Trying to accommodate and detect the latter seems like a fool's err= and, given that we want validation to work as close to 100% as possible. Thi= s discussion seems to have yielded a number of reasonable guidelines, along = the lines of: =20 * consistently use PAI or From (i.e., be clear what should be used within a= particular operating context, such as SIPConnect or SIP NNI) * only convey return-callable global (E.164) numbers outside your own close= d network * separators in tel URIs should be expected * short codes, N11 and similar numbers will likely only work within a natio= nal context =20 Thus, "be predictable, boring and conservative in what you send, and don't = expect the receiver to be liberal". =20 Here, we have a penalty function: Being "creative" will likely get your cal= l flagged as unvalidated. =20 Henning From: Brian Rosen Sent: Friday, September 16, 2016 1:35:35 PM To: Henning Schulzrinne Cc: Alan Ford; Paul Kyzivat; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?=20 =20 I think it probably would within the ATIS kind of environment, but Alan is = talking about things that are beyond that: his example is a SIP URI from an = enterprise PBX that doesn=E2=80=99t have a phone number in the identity.=20 =20 I personally think we need to get the PBX vendors on board as fast as we ca= n in order to be able to support =E2=80=9Cauthorized spoofing=E2=80=9D, like call center= s calling on behalf of other enterprises. I think getting the service provi= ders to sign in those cases will be complicated, and if they can push the pr= oblem off to the call center, it will work out better. So, I think its wort= h solving all/most of the problems the PBX folks think they have. =20 Having said that, the only circumstance I can think of where there is an id= entity like he is describing is an intra-enterprise call (possibly between s= ites, but within the same enterprise). In those environments, identity spoo= fing is much harder to mount because the intra-enterprise traffic tends to b= e entirely within the corporate network, and they don=E2=80=99t allow calls from s= ources they don=E2=80=99t know. Doesn=E2=80=99t mean stir should not work, but it=E2=80=99s p= retty far down in my list of things to worry about. =20 Brian =20 On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne wrote: =20 Without taking a position on whether to canon-ize or not (that's a papal th= ing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices will= largely moot this issue, i.e., within a particular context the use of PAI v= s. From and the encoding will be constant and ruled by best practices, so th= at real devices will just have a configuration setting that says "Look at PA= I; only if absent, look at From". Clearly, for calls within a carrier networ= k, this is not likely to be an issue. =20 Not ideal, but the good guys will have an incentive to adhere to common pra= ctice, as they want validation to work. =20 I haven't looked at the details of the SIP NNI spec to see if that spec is = sufficiently precise or whether, say, the SHAKEN ATIS document could provide= that level of specificity. =20 Unless a parameter can short-circuit the exploration completely ("only look= at X"), I'm not sure 'canon' helps with the resource exhaustion issue. =20 Henning From: stir on behalf of Alan Ford Sent: Friday, September 16, 2016 12:57:39 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?=20 =20 Hi Paul, > Surely the caller and signer bear some responsibility here. If they creat= e a situation where there is ambiguity about which address is being signed t= hen either they should do something to resolve it (e.g., in include canon) o= r else be prepared for the consequences if the callee can't validate. It is = in the caller's interest that the call be validated, so they should be expec= ted to make that feasible. This ultimately comes down to quality of implemen= tation. The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the = receiver is also a PSTN gateway. But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows fo= r certain the receiving environment will follow the same canonicalisation sc= heme - or words to that effect. > But there is also a brute force solution available to the validator: try = validation using each of the supplied identities in turn until one validates= or none do. While that might cost a bit of extra computation, the cost of t= hat might be less than the cost of carrying the canon parameter from end to = end. That=E2=80=99s certainly true, but in my opinion the cost of bits is much cheaper= than the cost of computation. What=E2=80=99s more, a brute-force receiver could g= enerate a modest denial-of-service attack vector - send a signature for some= thing completely different, and let the verification service munch through c= ycles trying various combinations to see if any validate (they won=E2=80=99t, of c= ourse). Minimum would be four combinations tried for just one src and one de= st (trying tn: vs sip: combinations) - and this could be many more if you st= art to include other identifiers such as PAI or RPID. Whereas, if the canon = was included, there would be one single crypto operation to verify the signa= ture against known data. Regards, Alan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 _______________________________________________ stir mailing list stir@ietf= .org https://www.ietf.org/mailman/listinfo/stir=20 --B_3556879603_482358256 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

Probably more like SIP Connect 3.0.=C2=A0=C2=A0= 2.0 is in ballot as we speak but both points are well taken.=C2=A0 <= /span>

 

These are exactly the kind of issues that can be d= ealt with in implementation profiles or BCP’s as the case may be. =C2=A0

 

= — <= o:p>

Richar= d Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum<= /span>

www.shockey= .us

www.sipforum.org

richard<at>shockey.us

=

Skype-Linkedin-Facebook rsh= ockey101

PSTN +1 703-593-2683

 

 

From: stir <stir-bounces@ietf.org> on behalf of Henning Schu= lzrinne <Henning.Schulzrinne@fcc.gov>
Date: Friday, Septembe= r 16, 2016 at 1:45 PM
To: Brian Rosen <br@brianrosen.net>Cc: "stir@ietf.org" <stir@ietf.org>, Paul Kyzivat &l= t;pkyzivat@alum.mit.edu>, Alan Ford <alan.ford@gmail.com>
Sub= ject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

 

Wouldn't this seem like something that SIPConnec= t 2.0 should address?

 

My genera= l impression is that there are a small number of ways to do things well, and= a near-infinite number of ways to make life difficult for everybody else. T= rying to accommodate and detect the latter seems like a fool's errand, given= that we want validation to work as close to 100% as possible. This discussi= on seems to have yielded a number of reasonable guidelines, along the lines = of:

 

* consistently use PAI or F= rom (i.e., be clear what should be used within a particular operating contex= t, such as SIPConnect or SIP NNI)

* only convey return-ca= llable global (E.164) numbers outside your own closed network

* separators in tel URIs should be expected

* short = codes, N11 and similar numbers will likely only work within a national = context

 

Thus, "be predicta= ble, boring and conservative in what you send, and don't expect the rec= eiver to be liberal".

=  

Here= , we have a penalty function: Being "creative" will likely get you= r call flagged as unvalidated.

 

= Henning

From: Brian Rosen <br@brianrosen.net>
Sent: Fr= iday, September 16, 2016 1:35:35 PM
To: Henning Schulzrinne
= Cc: Alan Ford; Paul Kyzivat; stir@ietf.org
Subject: Re: [stir]= 4474bis: Why only RECOMMEND when multiple identities?

 

I think it probably would within the ATIS kind of environment, but Ala= n is talking about things that are beyond that: his example is a SIP URI fro= m an enterprise PBX that doesn’t have a phone number in the identity. =

 

I personally think we need to get the PBX vendors on board as = fast as we can in order to be able to support “authorized spoofingR= 21;, like call centers calling on behalf of other enterprises.  I think= getting the service providers to sign in those cases will be complicated, a= nd if they can push the problem off to the call center, it will work out bet= ter.  So, I think its worth solving all/most of the problems the PBX fo= lks think they have.

 =

Having said that, the only circumsta= nce I can think of where there is an identity like he is describing is an in= tra-enterprise call (possibly between sites, but within the same enterprise)= .  In those environments, identity spoofing is much harder to mount bec= ause the intra-enterprise traffic tends to be entirely within the corporate = network, and they don’t allow calls from sources they don’t know= .  Doesn’t mean stir should not work, but it’s pretty far d= own in my list of things to worry about.

 

Brian=

 

= On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:<= /p>

 

Without taking a position on whether to canon-ize or = not (that's a papal thing and I'm not catholic), I wonder if ATIS/SIPForum N= NI best practices will largely moot this issue, i.e., within a particular co= ntext the use of PAI vs. From and the encoding will be constant and ruled by= best practices, so that real devices will just have a configuration setting= that says "Look at PAI; only if absent, look at From". Clearly, f= or calls within a carrier network, this is not likely to be an issue.

 

Not ide= al, but the good guys will have an incentive to adhere to common practice, a= s they want validation to work.

 = ;

I haven't looked at the details of the SIP NN= I spec to see if that spec is sufficiently precise or whether, say, the SHAK= EN ATIS document could provide that level of specificity.<= /p>

 

Unless a parameter = can short-circuit the exploration completely ("only look at X"), I= 'm not sure 'canon' helps with the resource exhaustion issue.

 

Henning

From: stir <stir-b= ounces@ietf.org> on behalf of Alan Ford <alan.ford@gmail.com>
Sent: Friday, September 16, 2016 12:57:39 PM
To: Paul Kyzivat
Cc:<= span class=3Dapple-converted-space> stir@ietf.org
Subject: = ;Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

 

Hi Paul,

> Surely the caller and signer bear some responsibility= here. If they create a situation where there is ambiguity about which addre= ss is being signed then either they should do something to resolve it (e.g.,= in include canon) or else be prepared for the consequences if the callee ca= n't validate. It is in the caller's interest that the call be validated, so = they should be expected to make that feasible. This ultimately comes down to= quality of implementation.

The sender may or may not know that there= would be ambiguity at the receiving side. For example, the sender may only = deal in SIP URIs and not know the receiver is also a PSTN gateway.

Bu= t in general, I agree, but feel this should be codified. This is why my prop= osed resolution here would be to mandate canon unless the sender knows for c= ertain the receiving environment will follow the same canonicalisation schem= e - or words to that effect.

> But there is also a brute force sol= ution available to the validator: try validation using each of the supplied = identities in turn until one validates or none do. While that might cost a b= it of extra computation, the cost of that might be less than the cost of car= rying the canon parameter from end to end.

That’s certainly tru= e, but in my opinion the cost of bits is much cheaper than the cost of compu= tation. What’s more, a brute-force receiver could generate a modest de= nial-of-service attack vector - send a signature for something completely di= fferent, and let the verification service munch through cycles trying variou= s combinations to see if any validate (they won’t, of course). Minimum= would be four combinations tried for just one src and one dest (trying tn: = vs sip: combinations) - and this could be many more if you start to include = other identifiers such as PAI or RPID. Whereas, if the canon was included, t= here would be one single crypto operation to verify the signature against kn= own data.

Regards,
Alan

___________________________________= ____________
stir mailing list
stir@iet= f.org
https://ww= w.ietf.org/mailman/listinfo/stir

_________________= ______________________________
stir mailing list
stir@ie= tf.org
https://www.ietf.org/mailman/listinfo/stir<= /span>

&n= bsp;

_______________________________= ________________ stir mailing list stir@ietf.org https://www.ietf.org/mailma= n/listinfo/stir

--B_3556879603_482358256-- From nobody Fri Sep 16 18:22:46 2016 Return-Path: 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 F118212B0A8 for ; Fri, 16 Sep 2016 18:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6-olqXs0DDMQ for ; Fri, 16 Sep 2016 18:22:42 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E9812B067 for ; Fri, 16 Sep 2016 18:22:42 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 38so50835065qte.1 for ; Fri, 16 Sep 2016 18:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LLRCcuFiqiGQIUcbOUPZ/e+QIqNDsKFhqVnWm/9iRm8=; b=Lyzlb7KmTyhzHXlVqYxC35QgyEW4YeQ/fwjsmN6WSEdY+oxykfk7DSQIbFv+klPq7b TEC26z0x8MUAcZwKHDf0WoC9hDa6YjxtyKKoX/TolEmpBlG32wNaKSjUe+mEhBuUGmkt WTiAu2lp9cg4xtg2BwZEY6wcowV57cVuZX9fDOREa4nPAqP2zJjNie74gmbOFGzpYsB2 fRRM51F0udG9JBL45aWo5RSbtQl6j1Y5BU1GWaFDe2kWeSJb4rXs8Dx/Yy4oIpsIY8xT ez7I6xlE1NcnxsmiZkEFrDX7OCCQMun5R8Zle4nlRd7OvVrj6mFQwxm2viq9ohgfH3l+ EW5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LLRCcuFiqiGQIUcbOUPZ/e+QIqNDsKFhqVnWm/9iRm8=; b=ZhFvnlN0Lac+5x+5d+Wg8O7hwLqwu1x7VK6tdCFUt8hkR/ulVYJA6pob0p+IRYYaHr sS4OTDYdlVwbeWJ5iO67R/QoxKVKUMiniZfl8s2vRgTKbL5+/9g/0KhdkKy9+etM+8VT OgayqF0DogXYgNi33EAaRwv9YH0BNNl8NmVpbdfhwnLtP3Phc2KMkyVqDeExhObnXVcF DsRckI+csJawGNYgC44+EOnGJurgcynuJ2uiws5i6S4fUbV+QDpsRpMCr2IFr3QZlxD4 YFY1lojvqDKiD+pBsLx663w3Bvi9ztLvfHOoHuAm6G6lI0Cypo0+jT38XlhNPlSBbPcP kJig== X-Gm-Message-State: AE9vXwNHNwaMbpVI21eCANFD6Ds1sBBmBW024DzwTDI1mse/GVDpHcSofmgUEOrCcyb3Xw== X-Received: by 10.200.47.89 with SMTP id k25mr18677599qta.75.1474075361466; Fri, 16 Sep 2016 18:22:41 -0700 (PDT) Received: from [10.1.1.20] ([65.213.2.242]) by smtp.gmail.com with ESMTPSA id i5sm6251766qti.30.2016.09.16.18.22.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 18:22:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5A1255B4-E9D2-4947-AB6E-A84819F338CE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Sat, 17 Sep 2016 02:19:59 +0100 Message-Id: <9C2F67C0-DB7C-4EBC-88CE-A7BA00830C08@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Sat, 17 Sep 2016 01:22:45 -0000 --Apple-Mail=_5A1255B4-E9D2-4947-AB6E-A84819F338CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jon, I feel we=92re getting distracted by the PAI discussion here, and this = was not the initial driver behind my comments. I felt it was an = additional valid issue, stemming from the same problems of lack of clear = canonicalisation, and so latched on to the ongoing discussions here, but = let=92s leave this out for the moment. My primary concern was the SIP/TN distinction. Here is an example, = real-world which we ran into in SIPit: - Sender=92s PASSporT: { =93orig=94 : { =93uri=94 : =93sip:caller@source.net=94 }, =93dest=94 : = { =93uri=94 : [ =93sip:87654321@destination.net=94 ] } } The sender sends like this since it is in a SIP environment, e.g. a = large enterprise, with no distinction of internal and external calling. - Receiver=92s PASSporT: { =93orig=94 : { =93uri=94 : =93sip:caller@source.net=94 }, =93dest=94 : = { =93tn=94 : =9387654321" } } These are two different PASSporTs, which will not validate, because both = ends canonicalised a call in a different way. The receiver considers the = number a TN, but the sender did not. This is why I am proposing mandating canon in any circumstances where = you cannot guarantee the behaviour of the receiver. A few more replies inline; avoiding anything PAI-related... > On 16 Sep 2016, at 19:00, Peterson, Jon = wrote: >=20 >> Indeed not. But, it tells the receiver which fields to look in, and = what form of canonicalisation to undertake. This is A Good Thing from an = implementation and interoperability point of view. >=20 >=20 > Only if you think that the way that the state in which the = authentication service saw these fields should determine for the = verifier what the "real" identity of the originator is. That is not an = assumption we make, or should make.=20 >=20 > Since we're still talking about this, maybe we should also bring this = back to the gatewaying and mixed-SIP cases that informed this decision. = I hesitate to move indications into PASSporT that say things like "I got = this identity from a PAI" because PASSporT shouldn't have those sorts of = dependencies on a using protocol. I similarly can imagine a case where a = VoIP call starts in, say, Jingle, and lands eventually on a SIP = endpoint, with some gateway in the middle. The original Jingle = authentication service didn't derive its TN from any SIP header at all. = Cases like that should be in our scope of consideration here. >=20 > I would ultimately prefer not to festoon PASSporT with SIP-specific = indicators. That=92s perfectly understandable, and a new PASSporT could be defined = to provide this function if desired. However, to achieve deployability with STIR as defined today requires = people to canonicalise in the same way. To make this happen, we need to = share information. >>> The presence of canon cannot influence the verification service = decision: we want security to fail (which, I feel obliged to say, = doesn't necessarily mean rejecting the request) if the verification = service canonicalization does not resolve to the same value that the = auth service used. That is what this mechanism is designed to do. >>=20 >> But this is the problem! When a sender does not know its target would = canonicalise the destination address as a TN, and thus encodes it as a = SIP URI in the PASSporT object, verification would fail. But with canon, = the verification service could be more intelligent, as it may be able to = pass all other verification logic if it knew how the field had been = canonicalised. >=20 >=20 > I am indeed saying that is a security bug, not a feature. Though = surely an attacker would like to make the verification service "more = intelligent" by telling it "try to see things my way.=94=20 Then I fear there is misunderstanding here. A verification service has a = set of possible canonicalisations (e.g. to TN or not to TN). It could, = as Paul said in another mail, try all combinations, but that would be = computationally expensive. By providing the canon we are providing = information as to which of these possible canonicalisations to choose. = This is not adding any additional security risk - all canonicalisations = are those which the verification service would support anyway. > We both agree that "canon" should at least be allowed, and when it is = present, I think it is meaningful for the verification service to = compare the canonicalized value(s) it found in the message with the orig = value of the PASSporT object as a step in the verification process. That = doesn't raise any alarm bells for me. As soon as this becomes instead = about how the verification service should decide based on the = information in "canon" how its canonicalization process should work., = that trips the alarm loud and clear. Again, this is not saying =93what is in the canon is truth=94, it is = saying =93this is what I encoded, if you think this canonicalisation is = accurate then let=92s validate=94. >>> ... the PASSport object is not a security hole in the sense that it = lacks integrity protection. The security hole appears only if we = stipulate that the verification service trusts that the orig tn value in = the PASSporT object is a canonicalization of whatever identity the SIP = request carries. >>=20 >> I don=92t think anyone is suggesting that should be the logic. I = certainly am not. >=20 >=20 > I cannot distinguish what you are recommending from this. I hope my example at the start of this mail clarifies this. Regards, Alan --Apple-Mail=_5A1255B4-E9D2-4947-AB6E-A84819F338CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jon,

I = feel we=92re getting distracted by the PAI discussion here, and this was = not the initial driver behind my comments. I felt it was an additional = valid issue, stemming from the same problems of lack of clear = canonicalisation, and so latched on to the ongoing discussions here, but = let=92s leave this out for the moment.

My primary concern was the SIP/TN = distinction. Here is an example, real-world which we ran into in = SIPit:

- = Sender=92s PASSporT:

{ =93orig=94 : { =93uri=94 : =93sip:caller@source.net=94 = }, =93dest=94 : { =93uri=94 : [ =93sip:87654321@destination.net=94 ] } }

The sender sends like = this since it is in a SIP environment, e.g. a large enterprise, with no = distinction of internal and external calling.

- Receiver=92s PASSporT:

{ =93orig=94= : { =93uri=94 : =93sip:caller@source.net=94 }, =93dest=94 : { =93tn=94 : = =9387654321" } }

These are two different PASSporTs, which will not validate, = because both ends canonicalised a call in a different way. The receiver = considers the number a TN, but the sender did not.

This is why I am = proposing mandating canon in any circumstances where you cannot = guarantee the behaviour of the receiver.

A few more replies inline; avoiding = anything PAI-related...

On = 16 Sep 2016, at 19:00, Peterson, Jon <jon.peterson@neustar.biz> wrote:

Indeed not. But, it tells the receiver which fields to = look in, and what form of canonicalisation to undertake. This is A Good = Thing from an implementation and interoperability point of = view.

Only if you think that the way that the state in which = the authentication service saw these fields should determine for the = verifier what the "real" identity of the originator is. That is not an = assumption we make, or should make. 

Since we're still talking about this, maybe we should = also bring this back to the gatewaying and mixed-SIP cases that informed = this decision. I hesitate to move indications into PASSporT that say = things like "I got this identity from a PAI" because PASSporT shouldn't have those sorts of dependencies on a using protocol. I = similarly can imagine a case where a VoIP call starts in, say, Jingle, = and lands eventually on a SIP endpoint, with some gateway in the middle. = The original Jingle authentication service didn't derive its TN from any SIP header at all. Cases like that should be in = our scope of consideration here.

I would ultimately prefer not to festoon PASSporT with = SIP-specific indicators.

That=92s perfectly understandable, and a new = PASSporT could be defined to provide this function if = desired.

However, to achieve = deployability with STIR as defined today requires people to canonicalise = in the same way. To make this happen, we need to share = information.

The presence of canon cannot influence the verification service = decision: we want security to fail (which, I feel obliged to say, = doesn't necessarily mean rejecting the request) if the verification = service canonicalization does not resolve to the same value that the auth service used. That is what this mechanism is designed to = do.

But this is the problem! When a sender does not know its = target would canonicalise the destination address as a TN, and thus = encodes it as a SIP URI in the PASSporT object, verification would fail. = But with canon, the verification service could be more intelligent, as it may be able to pass all other verification logic if = it knew how the field had been canonicalised.

I am indeed saying that is a security bug, not a = feature. Though surely an attacker would like to make the verification = service "more intelligent" by telling it "try to see things my = way.=94 

Then I fear there is misunderstanding here. A = verification service has a set of possible canonicalisations (e.g. to TN = or not to TN). It could, as Paul said in another mail, try all = combinations, but that would be computationally expensive. By providing = the canon we are providing information as to which of these possible = canonicalisations to choose. This is not adding any additional security = risk - all canonicalisations are those which the verification service = would support anyway.

We both agree that "canon" should at least be allowed, = and when it is present, I think it is meaningful for the verification = service to compare the canonicalized value(s) it found in the message = with the orig value of the PASSporT object as a step in the verification process. That doesn't raise any alarm bells for me. As = soon as this becomes instead about how the verification service should = decide based on the information in "canon" how its canonicalization = process should work., that trips the alarm loud and clear.

Again, = this is not saying =93what is in the canon is truth=94, it is saying = =93this is what I encoded, if you think this canonicalisation is = accurate then let=92s validate=94.

... the PASSport object = is not a security hole in the sense that it lacks integrity protection. = The security hole appears only if we stipulate that the verification = service trusts that the orig tn value in the PASSporT object is a = canonicalization of whatever identity the SIP request carries.

I don=92t think anyone is suggesting that should be the = logic. I certainly am not.

I cannot distinguish what you are recommending from = this.

I = hope my example at the start of this mail clarifies this.

Regards,
Alan


= --Apple-Mail=_5A1255B4-E9D2-4947-AB6E-A84819F338CE-- From nobody Mon Sep 19 13:26:25 2016 Return-Path: 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 7C38112B4AD for ; Mon, 19 Sep 2016 13:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 flVo9-lj3hV9 for ; Mon, 19 Sep 2016 13:26:22 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B913112B167 for ; Mon, 19 Sep 2016 13:26:22 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8JKPcIT030206; Mon, 19 Sep 2016 16:26:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=tXouoMy/PSAg+7Od12PtVfrqKvdQ1Nxy9QaE9lM7kF4=; b=J7A3N0ogMz6KsQEOL1trorNLfIGCw6bUZT9dalpHiiVotDS+Ng2mMKvtd30W65w63unX s3yU1RAYADVo58eXiYDWn71n6dgTFs3tXFxg8qiHAPZ3a+S80TJT2X2zYGdYOyvbr3mv i2/dJ3+VF1LfTtJaNQ3RQLS4cya0I5gvGfN9NdP4htmkVhax6eGpdYbzh1J7yqAQasu7 dJIHw5bAK1hHKFp42BJZ7wcGiTiv6AKbQwtiu9G2oFJzJiK/6wlsmvnGq4kUUELGW8+0 HaXbhy1Z6tXloRScuM5syI9flJ7rql5isThpMs32idLiILwd+ChDNQiVmpOXWK4otJa4 OQ== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 25h0mhy6j5-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Sep 2016 16:26:16 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 19 Sep 2016 16:26:15 -0400 From: "Peterson, Jon" To: Alan Ford Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAA1l8gIAABekAgAABcQD//6g2gIAAf5EA//+RW4CAAL9/gP//vV8AACOzNwD//7ckAIAA7/OAgAPvyAA= Date: Mon, 19 Sep 2016 20:26:15 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> <9C2F67C0-DB7C-4EBC-88CE-A7BA00830C08@gmail.com> In-Reply-To: <9C2F67C0-DB7C-4EBC-88CE-A7BA00830C08@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.13.7] Content-Type: multipart/alternative; boundary="_000_D40593BE1B9E61jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609190274 Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Mon, 19 Sep 2016 20:26:24 -0000 --_000_D40593BE1B9E61jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My primary concern was the SIP/TN distinction. Here is an example, real-wor= ld which we ran into in SIPit: Can you explain then how Brian's hint doesn't resolve this? - Sender=92s PASSporT: { =93orig=94 : { =93uri=94 : =93sip:caller@source.net=94 }, =93dest=94 : { = =93uri=94 : [ =93sip:87654321@destination.net=94 ] } } The sender sends like this since it is in a SIP environment, e.g. a large e= nterprise, with no distinction of internal and external calling. Even without Brian's hint, cases like this don't actually keep me up at nig= ht. And not just because, well, "destination.net" probably isn't CompuServ = and thus there's little chance it issues entirely-numeric usernames. It doe= sn't especially concern me because in order for a SIP request to actually b= e routed, you need to know whether it's just a telephone number, in which c= ase you might drop it to any old gateway to the PSTN with equal effect, or = if in fact you're expected to perform RFC3263 routing on the domain name pa= rt. Somehow, this works today without us adding any indicator to SIP to res= olve any confusions. SIP routing has some core ambiguities around using telephone numbers that i= t isn't the Identity header's job to rectify. But the important question is= whether or not, in our threat model, we think that this particular ambigui= ty will arise enough that it justifies always including "canon." We opened = up the STIR working group to address problems with telephone numbers as ide= ntifiers in SIP; along the way, we decided that it was worth allowing that = the same mechanism would work for greenfield SIP URIs as well. I think the = common case for STIR will be to use telephone numbers for both orig and des= t, just as it is in SIP deployment today. I would, perhaps, grudgingly, be willing to entertain normative guidance th= at states that if either orig or dest does not contain a "tn" identity then= you MUST use "canon." That would avoid the rather weasel-y RFC3324ish prop= osed language about only sending "canon" when you psychically know the term= inating side shares your canonicalization scheme. Even in my proposed form,= I think it's overkill. But just hypothetically, would that resolve your co= ncern? Or anyone else's? Jon Peterson Neustar, Inc. --_000_D40593BE1B9E61jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <957309BA18F03A40A78BC72D16D5708E@neustar.biz> Content-Transfer-Encoding: quoted-printable

My primary concern was the SIP/TN distinction. Here is an e= xample, real-world which we ran into in SIPit:

Can you explain then how Brian's hint doesn't resolve this?

- Sender=92s PASSporT:

{ =93orig=94 : { =93uri=94 : =93sip:caller@source.net=94 }, =93dest=94 : { =93uri=94 = : [ =93sip:87654321@des= tination.net=94 ] } }

The sender sends like this since it is in a SIP environment= , e.g. a large enterprise, with no distinction of internal and external cal= ling.

Even without Brian's hint, cases like this don't actually keep me up a= t night. And not just because, well, "destination.net" probably i= sn't CompuServ and thus there's little chance it issues entirely-numeric us= ernames. It doesn't especially concern me because in order for a SIP request to actually be routed, you need to know= whether it's just a telephone number, in which case you might drop it to a= ny old gateway to the PSTN with equal effect, or if in fact you're expected= to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any indicato= r to SIP to resolve any confusions. 

SIP routing has some core ambiguities around using telephone numbers t= hat it isn't the Identity header's job to rectify. But the important questi= on is whether or not, in our threat model, we think that this particular am= biguity will arise enough that it justifies always including "canon." We opened up the STIR workin= g group to address problems with telephone numbers as identifiers in SIP; a= long the way, we decided that it was worth allowing that the same mechanism= would work for greenfield SIP URIs as well. I think the common case for STIR will be to use telephone numbers for both= orig and dest, just as it is in SIP deployment today. 

I would, perhaps, grudgingly, be willing to entertain normative guidan= ce that states that if either orig or dest does not contain a "tn"= ; identity then you MUST use "canon." That would avoid the rather= weasel-y RFC3324ish proposed language about only sending "canon" when you psychically know the terminating side shares yo= ur canonicalization scheme. Even in my proposed form, I think it's overkill= . But just hypothetically, would that resolve your concern? Or anyone else'= s?

Jon Peterson
Neustar, Inc.
--_000_D40593BE1B9E61jonpetersonneustarbiz_-- From nobody Mon Sep 19 16:05:40 2016 Return-Path: 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 37A8E12B010 for ; Mon, 19 Sep 2016 16:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 QR4GS-62S4Eb for ; Mon, 19 Sep 2016 16:05:33 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF4612B00C for ; Mon, 19 Sep 2016 16:05:09 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id l131so24126lfl.2 for ; Mon, 19 Sep 2016 16:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WXjuw1KyGHILJlmVjxLZeLHPHNQVCwG4XvMGR1QLqic=; b=ClOc4gLAPXXrm+54HhopNuz2dl1p+eK8ILKLVi90xOZbg0I9D7jibFQ+CdaTsPj8Bi 4KboE2LDod9xz9Za/5bkLgy0betCaEEiK0dRjotBJaW2g888V0ZlSHGwlm5PCHlUvfAU JA/RDdq0emWTGxAyZF7AHeZtszXLFVtqgRPvl5YS6995NUAbOefOwA+rFj14w07LBaRp hMJvvQIECqTjOkKcHVtZ2hgn47qUXLjCjplfyQfBxrKtepc0JjMocU/AA9O+AwFKC1QZ zRel9lBw8GLfP4AdHikeWlg8fqPDg4ufaCzj3+wIatUbVAO7JnGU8cpqrcyMvEEuxVin JDIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WXjuw1KyGHILJlmVjxLZeLHPHNQVCwG4XvMGR1QLqic=; b=GtxNLUBlryRHpxzVKWGPrrQ2uO2JP5yIpO9r93tyYR/axbFH3evy02AyBO2bt84rv2 cRTeJ+x9RyOftw2eglbcr7T66nW/lzFlvuZ1bBUul5uR2ZIShg2v0WntZC18MlaSl5Qm ss/QnQ5q5O+r6qmVORtPtHngYOKcwUV7p9jO8AKyuwfTBkLJL6DC7zrL9dsYFRhnHb69 1niZ34ZbhoYyr8pkj4mmfPlnE8tGRAfmS6l8QKyCamlp3J1SK9cnGLHo8/4cmnlXltSP yp8Ez500QmbVtNLI43Sjpn2YN821MWYesAT86+plYbdb4OnnnUlTwUogISfKwfLWYcO7 X+/g== X-Gm-Message-State: AE9vXwPl8c51K31QWqN9gDU1sJXcJXj5npcBUIMVBjtOsDbiWX0m48Ei/oxYBRy2btA5BPLrOqSzFXGYPlJS9A== X-Received: by 10.25.161.76 with SMTP id k73mr10812704lfe.26.1474326307353; Mon, 19 Sep 2016 16:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.144.203 with HTTP; Mon, 19 Sep 2016 16:05:06 -0700 (PDT) X-Originating-IP: [70.198.192.60] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> <9C2F67C0-DB7C-4EBC-88CE-A7BA00830C08@gmail.com> From: Brian Rosen Date: Mon, 19 Sep 2016 19:05:06 -0400 Message-ID: To: "Peterson, Jon" Content-Type: multipart/alternative; boundary=001a11402f1ad54fcb053ce45742 Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Alan Ford Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Mon, 19 Sep 2016 23:05:39 -0000 --001a11402f1ad54fcb053ce45742 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not to mention that you are supposed to use user=3Dphone when the user part is a phone number and a context when it's not a globally routable number. It's pretty tough to design sensible extensions to a protocol when implementations don't follow the original mechanisms and then demand to be treated as if what they implemented was correct. Brian On Monday, September 19, 2016, Peterson, Jon > wrote: > > My primary concern was the SIP/TN distinction. Here is an example, > real-world which we ran into in SIPit: > > > Can you explain then how Brian's hint doesn't resolve this? > > - Sender=E2=80=99s PASSporT: > > { =E2=80=9Corig=E2=80=9D : { =E2=80=9Curi=E2=80=9D : =E2=80=9Csip:caller@= source.net=E2=80=9D }, =E2=80=9Cdest=E2=80=9D : { =E2=80=9Curi=E2=80=9D : [= =E2=80=9C > sip:87654321@destination.net=E2=80=9D ] } } > > The sender sends like this since it is in a SIP environment, e.g. a large > enterprise, with no distinction of internal and external calling. > > > Even without Brian's hint, cases like this don't actually keep me up at > night. And not just because, well, "destination.net" probably isn't > CompuServ and thus there's little chance it issues entirely-numeric > usernames. It doesn't especially concern me because in order for a SIP > request to actually be routed, you need to know whether it's just a > telephone number, in which case you might drop it to any old gateway to t= he > PSTN with equal effect, or if in fact you're expected to perform RFC3263 > routing on the domain name part. Somehow, this works today without us > adding any indicator to SIP to resolve any confusions. > > SIP routing has some core ambiguities around using telephone numbers that > it isn't the Identity header's job to rectify. But the important question > is whether or not, in our threat model, we think that this particular > ambiguity will arise enough that it justifies always including "canon." W= e > opened up the STIR working group to address problems with telephone numbe= rs > as identifiers in SIP; along the way, we decided that it was worth allowi= ng > that the same mechanism would work for greenfield SIP URIs as well. I thi= nk > the common case for STIR will be to use telephone numbers for both orig a= nd > dest, just as it is in SIP deployment today. > > I would, perhaps, grudgingly, be willing to entertain normative guidance > that states that if either orig or dest does not contain a "tn" identity > then you MUST use "canon." That would avoid the rather weasel-y RFC3324is= h > proposed language about only sending "canon" when you psychically know th= e > terminating side shares your canonicalization scheme. Even in my proposed > form, I think it's overkill. But just hypothetically, would that resolve > your concern? Or anyone else's? > > Jon Peterson > Neustar, Inc. > --001a11402f1ad54fcb053ce45742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not to mention that you are supposed to use user=3Dphone when the user part= is a phone number and a context when it's not a globally routable numb= er. =C2=A0 It's pretty tough to design sensible extensions to a protoco= l when implementations don't follow the original mechanisms and then de= mand to be treated as if what they implemented was correct.=C2=A0

<= /div>
Brian

On Monday, September 19, 2016, Peterson= , Jon <jon.peterson@neustar.biz> wrot= e:

My primary concern was the SIP/TN distinction. Here is an example, rea= l-world which we ran into in SIPit:

Can you explain then how Brian's hint doesn't resolve this?

- Sender=E2=80=99s PASSporT:

{ =E2=80=9Corig=E2=80=9D : { =E2=80=9Curi=E2=80=9D : =E2=80=9Csip:c= aller@source.net=E2=80=9D }, =E2=80=9Cdest=E2=80=9D : { =E2=80=9Curi=E2= =80=9D : [ =E2=80=9Csip:87654321@destination.net=E2=80=9D ] } }

The sender sends like this since it is in a SIP environment, e.g. a la= rge enterprise, with no distinction of internal and external calling.

Even without Brian's hint, cases like this don't actually keep= me up at night. And not just because, well, "destination.net" probably isn't C= ompuServ and thus there's little chance it issues entirely-numeric user= names. It doesn't especially concern me because in order for a SIP request to actually be routed, you need to know= whether it's just a telephone number, in which case you might drop it = to any old gateway to the PSTN with equal effect, or if in fact you're = expected to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any indicato= r to SIP to resolve any confusions.=C2=A0

SIP routing has some core ambiguities around using telephone numbers t= hat it isn't the Identity header's job to rectify. But the importan= t question is whether or not, in our threat model, we think that this parti= cular ambiguity will arise enough that it justifies always including "canon." We opened up the STIR workin= g group to address problems with telephone numbers as identifiers in SIP; a= long the way, we decided that it was worth allowing that the same mechanism= would work for greenfield SIP URIs as well. I think the common case for STIR will be to use telephone numbers for both= orig and dest, just as it is in SIP deployment today.=C2=A0

I would, perhaps, grudgingly, be willing to entertain normative guidan= ce that states that if either orig or dest does not contain a "tn"= ; identity then you MUST use "canon." That would avoid the rather= weasel-y RFC3324ish proposed language about only sending "canon" when you psychically know the terminating side shares yo= ur canonicalization scheme. Even in my proposed form, I think it's over= kill. But just hypothetically, would that resolve your concern? Or anyone e= lse's?

Jon Peterson
Neustar, Inc.
--001a11402f1ad54fcb053ce45742-- From nobody Mon Sep 19 16:42:09 2016 Return-Path: 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 321E412B597 for ; Mon, 19 Sep 2016 16:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 wv90-aOg_Gpz for ; Mon, 19 Sep 2016 16:42:06 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC8212B568 for ; Mon, 19 Sep 2016 16:42:06 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id z190so659257qkc.3 for ; Mon, 19 Sep 2016 16:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8aO2PtmEW+CgTYRck+p4BQmItWEuLjTE405Mg//zpZM=; b=enztI1n3MCuLEI4xjqcMf7LCPmiCHlCInA2SogjbIz42Tu7rE1J6tPB01fgm6f5XzC CeDigrfERQav50dOIwr5pzrcNacN4iX/AvX5XRsGHoo5vdKhCqiEit7xqBg9zAgSLyYU qd3pr9W0dnztAfiWGb3ZtvBHeY+a6NvfqaDCQlhiFvTTv2Gw8LsEl1HpYK8O+KLQZUgt xANcNZQFHWKZplvLyNjf1ecmQHmvs997aW2LsxxMFeA7FHhq+6zsDDZ1CqY/Tlh1K5h1 +RP+tyIVrD9+WRrCDJXdnRXooses6Xk+p3QxSpPCsIp5sNd1DquxSkhxrK/sKcKa/BNN nwRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8aO2PtmEW+CgTYRck+p4BQmItWEuLjTE405Mg//zpZM=; b=gj24DYIHFocCF3rHktKnwt5hY4oz3TUOVlxqwbfI+TLa5RmxOAGXTt8UIhKgalebwN YRg9l/+SJJ9q1Bi/CibBCPKbHLD9twN1bjwnccDbrZ9Z05jIkp7dIzTYhZH9tIwzqFuD UIgfHar2C56mDSJPkus7EP1osOm/QcYfdbuJzFGBDz1jHRuE+rlKO+iOUi++e12yC8Me NjLODERwhqF180jjw37ITATvZ7EDJdQWjyFckq0+GXvCluxzT995dKO9VRrq3PJJL7BL C+eP8jUjqO6PWWFiOl7OxbEz5o4uuAkQ3nNody4tCc9c0Msz4/TRjmXWWLmQ88AclkY1 5ySw== X-Gm-Message-State: AE9vXwNGD/ZepBhCGVR7dwFDJWw1FzlTgAQFf3edGwTVbjgYxD2zC8yeDei7FdRhizKPHQ== X-Received: by 10.55.151.198 with SMTP id z189mr34230347qkd.70.1474328525492; Mon, 19 Sep 2016 16:42:05 -0700 (PDT) Received: from [10.199.7.248] (209-33-154-227.ip.mcleodusa.net. [209.33.154.227]) by smtp.gmail.com with ESMTPSA id g22sm14411034qta.1.2016.09.19.16.42.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 16:42:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_58798FB6-F7C1-47B9-B96F-30646C55FA28" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Mon, 19 Sep 2016 19:42:04 -0400 Message-Id: <3F3E03DE-35ED-4F79-8E5A-F5CAB8DFAA65@chriswendt.net> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> <9C2F67C0-DB7C-4EBC-88CE-A7BA00830C08@gmail.com> To: Brian Rosen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Alan Ford , "Peterson, Jon" , Christer Holmberg Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Mon, 19 Sep 2016 23:42:08 -0000 --Apple-Mail=_58798FB6-F7C1-47B9-B96F-30646C55FA28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Have to agree here, if you put digits in front of a SIP URI without = user=3Dphone/context, all bets are off for any chance of deterministic = behavior for =E2=80=9Ctelephone numbers=E2=80=9D for anything beyond a = private network. For both STIR and non-STIR. Just like you have some =E2=80=9Cspecial arrangement=E2=80=9D with all = of the clients in your network to interpret sip:123456@example.net = as a =E2=80=9Ctelephone number=E2=80=9D, you = could also have the same arrangement to mandate canon. > On Sep 19, 2016, at 7:05 PM, Brian Rosen wrote: >=20 > Not to mention that you are supposed to use user=3Dphone when the user = part is a phone number and a context when it's not a globally routable = number. It's pretty tough to design sensible extensions to a protocol = when implementations don't follow the original mechanisms and then = demand to be treated as if what they implemented was correct.=20 >=20 > Brian >=20 > On Monday, September 19, 2016, Peterson, Jon > wrote: >=20 > My primary concern was the SIP/TN distinction. Here is an example, = real-world which we ran into in SIPit: >=20 > Can you explain then how Brian's hint doesn't resolve this? >=20 > - Sender=E2=80=99s PASSporT: >=20 > { =E2=80=9Corig=E2=80=9D : { =E2=80=9Curi=E2=80=9D : = =E2=80=9Csip:caller@source.net <>=E2=80=9D }, =E2=80=9Cdest=E2=80=9D : { = =E2=80=9Curi=E2=80=9D : [ =E2=80=9Csip:87654321@destination.net <>=E2=80=9D= ] } } >=20 > The sender sends like this since it is in a SIP environment, e.g. a = large enterprise, with no distinction of internal and external calling. >=20 > Even without Brian's hint, cases like this don't actually keep me up = at night. And not just because, well, "destination.net = " probably isn't CompuServ and thus there's = little chance it issues entirely-numeric usernames. It doesn't = especially concern me because in order for a SIP request to actually be = routed, you need to know whether it's just a telephone number, in which = case you might drop it to any old gateway to the PSTN with equal effect, = or if in fact you're expected to perform RFC3263 routing on the domain = name part. Somehow, this works today without us adding any indicator to = SIP to resolve any confusions.=20 >=20 > SIP routing has some core ambiguities around using telephone numbers = that it isn't the Identity header's job to rectify. But the important = question is whether or not, in our threat model, we think that this = particular ambiguity will arise enough that it justifies always = including "canon." We opened up the STIR working group to address = problems with telephone numbers as identifiers in SIP; along the way, we = decided that it was worth allowing that the same mechanism would work = for greenfield SIP URIs as well. I think the common case for STIR will = be to use telephone numbers for both orig and dest, just as it is in SIP = deployment today.=20 >=20 > I would, perhaps, grudgingly, be willing to entertain normative = guidance that states that if either orig or dest does not contain a "tn" = identity then you MUST use "canon." That would avoid the rather weasel-y = RFC3324ish proposed language about only sending "canon" when you = psychically know the terminating side shares your canonicalization = scheme. Even in my proposed form, I think it's overkill. But just = hypothetically, would that resolve your concern? Or anyone else's? >=20 > Jon Peterson > Neustar, Inc. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_58798FB6-F7C1-47B9-B96F-30646C55FA28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Have to agree here, if you put digits in front of a SIP URI = without user=3Dphone/context, all bets are off for any chance of = deterministic behavior for =E2=80=9Ctelephone numbers=E2=80=9D for = anything beyond a private network.  For both STIR and non-STIR.

Just like you have some = =E2=80=9Cspecial arrangement=E2=80=9D with all of the clients in your = network to interpret sip:123456@example.net as a =E2=80=9Ctelephone = number=E2=80=9D, you could also have the same arrangement to mandate = canon.


On Sep 19, 2016, at 7:05 PM, Brian Rosen = <br@brianrosen.net> wrote:

Not to mention that = you are supposed to use user=3Dphone when the user part is a phone = number and a context when it's not a globally routable number.   = It's pretty tough to design sensible extensions to a protocol when = implementations don't follow the original mechanisms and then demand to = be treated as if what they implemented was correct. 

Brian

On Monday, September 19, = 2016, Peterson, Jon <jon.peterson@neustar.biz> wrote:

My primary concern was the SIP/TN distinction. Here is = an example, real-world which we ran into in SIPit:

Can you explain then how Brian's hint doesn't resolve = this?

- Sender=E2=80=99s PASSporT:

{ =E2=80=9Corig=E2=80=9D : { =E2=80=9Curi=E2=80=9D : = =E2=80=9Csip:caller@source.net=E2=80=9D }, =E2=80=9Cdest= =E2=80=9D : { =E2=80=9Curi=E2=80=9D : [ =E2=80=9Csip:87654321@destination.net=E2=80=9D ] } }

The sender sends like this since it is in a SIP = environment, e.g. a large enterprise, with no distinction of internal = and external calling.

Even without Brian's hint, cases like this don't = actually keep me up at night. And not just because, well, "destination.net" probably isn't CompuServ and thus = there's little chance it issues entirely-numeric usernames. It doesn't = especially concern me because in order for a SIP request to actually be routed, you need to = know whether it's just a telephone number, in which case you might drop = it to any old gateway to the PSTN with equal effect, or if in fact = you're expected to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any = indicator to SIP to resolve any confusions. 

SIP routing has some core ambiguities around using = telephone numbers that it isn't the Identity header's job to rectify. = But the important question is whether or not, in our threat model, we = think that this particular ambiguity will arise enough that it justifies always including "canon." We opened up the STIR working group = to address problems with telephone numbers as identifiers in SIP; along = the way, we decided that it was worth allowing that the same mechanism = would work for greenfield SIP URIs as well. I think the common case for STIR will be to use telephone numbers for = both orig and dest, just as it is in SIP deployment today. 

I would, perhaps, grudgingly, be willing to entertain = normative guidance that states that if either orig or dest does not = contain a "tn" identity then you MUST use "canon." That would avoid the = rather weasel-y RFC3324ish proposed language about only sending "canon" when you psychically know the terminating side shares your = canonicalization scheme. Even in my proposed form, I think it's = overkill. But just hypothetically, would that resolve your concern? Or = anyone else's?

Jon Peterson
Neustar, Inc.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_58798FB6-F7C1-47B9-B96F-30646C55FA28-- From nobody Tue Sep 20 05:38:25 2016 Return-Path: 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 2A67512B067 for ; Tue, 20 Sep 2016 05:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CWQErMc-Xbab for ; Tue, 20 Sep 2016 05:38:21 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7113A12B150 for ; Tue, 20 Sep 2016 05:38:21 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b130so33038698wmc.0 for ; Tue, 20 Sep 2016 05:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=qlyLp7qy3IDmdLi10xpr1i7HmrOlQzBn6Qy1ZZAv7bI=; b=jY+ahuMnF1phGV+G7VHkG25TAMjEIWvbGGHGNBYw+xakWQZ0R9PSfnzJkmJgFebY06 IUS3KhXmx6Pww5ZbIGpkJfbt5tQr3ZRQvXp6SQaomIdXPCG7cbDZQshbyI2Yl/F4hCAx GaXfS1Ks95SjRJO62CyTlXV0Y2nmnrkn0qIcNGkR7/i4RlOnU/9Ax6f4b2VRX6FPZBAH bvo5kyHn+kTRDfOubAyhtirG3VoCaXlrlTINE7kSfgsBkucXjf5+0eff2lUGtflN6lJp ifZamtcLXeuRkvjRUOl0wj/60dMRvupHtQBmBDssQJDE+zJKtYR+hEulBPCxoIAYKKeY vNtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qlyLp7qy3IDmdLi10xpr1i7HmrOlQzBn6Qy1ZZAv7bI=; b=JiiMsEG8F6nv8aKfc5d5/Yw2/udff9dnFbVKs+PXPm0XPx3bWNQq3L2hoSD9Dg7Lfl b44MDHu1rAqpBj3QbSdCDbN15YwdBSO5B9vl4aAZjcuBgnN1edQQiqysG8atAMQ/MNYf lyT4+4UCIN82F/W25hJclhnQV7+Czg9lyV6DQewvBL2retsXksM0f+l8CB/XnQ3+ZSlU F5OevIY7qu6iYkgNP0FuoX3Vnm8yy5ZWjpKlzKpIrRerjuU/7RvGC6LBGalupHC/7Bu2 cJNSw6JgVy/CoQs9O3UIcG4McD75HutJ6SFw1Sjy8gY5rG93gtLG+P5zFM5ADduNztC5 ZV4w== X-Gm-Message-State: AE9vXwPnOBTmBhhfpXrbHm/m1K3r2bth1tjOzP9eAmQbz++oi1RpnMXcXaccuUaYTuChCg== X-Received: by 10.194.20.167 with SMTP id o7mr28147292wje.70.1474375099811; Tue, 20 Sep 2016 05:38:19 -0700 (PDT) Received: from [10.44.28.203] (host81-142-89-185.in-addr.btopenworld.com. [81.142.89.185]) by smtp.gmail.com with ESMTPSA id gg10sm28281163wjd.4.2016.09.20.05.38.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Sep 2016 05:38:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1E64F553-1BC1-408C-8F5D-BA142461065E" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Tue, 20 Sep 2016 13:38:36 +0100 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> <9C2F67C0-DB7C-4EBC-88CE-A7BA00830C08@gmail.com> To: "Peterson, Jon" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" , Christer Holmberg , Brian Rosen Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Tue, 20 Sep 2016 12:38:24 -0000 --Apple-Mail=_1E64F553-1BC1-408C-8F5D-BA142461065E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jon, > On 19 Sep 2016, at 21:26, Peterson, Jon = wrote: >=20 >=20 >> My primary concern was the SIP/TN distinction. Here is an example, = real-world which we ran into in SIPit: >=20 >=20 > Can you explain then how Brian's hint doesn't resolve this? I=92m not sure which hint you are referring to here, if it=92s the = suggestion that the type of certificate should provide a clue, then that = could only reliably be used when considering the source URI and does not = guarantee how the destination URI would be canonicalised. If you=92re talking about user=3Dphone, I may be misreading what Brian = wrote, or misreading RFC3261/4967, but my understanding was that = user=3Dphone is to indicate a number really is a phone number? Sadly = there are many devices out there which slap user=3Dphone on every = vaguely telephonic URI, irrespective of global routability. It=92s = certainly not reliable today. Furthermore, the sender may still have no = idea whether the destination is a TN, so wouldn=92t know whether to put = user=3Dphone on it. Of course given we=92re defining something new here, there is the = (potential) opportunity to correct implementation and say user=3Dphone = MUST be present for it to be canonicalised as a TN, although sticking = parameters on a To: address would be uncharted territory AFAIK. >> - Sender=92s PASSporT: >>=20 >> { =93orig=94 : { =93uri=94 : =93sip:caller@source.net = =94 }, =93dest=94 : { =93uri=94 : [ = =93sip:87654321@destination.net =94 ] } } >>=20 >> The sender sends like this since it is in a SIP environment, e.g. a = large enterprise, with no distinction of internal and external calling. >=20 >=20 > Even without Brian's hint, cases like this don't actually keep me up = at night. And not just because, well, "destination.net" probably isn't = CompuServ and thus there's little chance it issues entirely-numeric = usernames. As I mentioned in an earlier mail, entirely-numeric user parts are = actually very common in enterprise SIP deployments. > It doesn't especially concern me because in order for a SIP request to = actually be routed, you need to know whether it's just a telephone = number, in which case you might drop it to any old gateway to the PSTN = with equal effect, or if in fact you're expected to perform RFC3263 = routing on the domain name part. Somehow, this works today without us = adding any indicator to SIP to resolve any confusions.=20 Indeed it does, given the receiving end only needs to look at the = Request-URI to know what to do with it. The sender does not necessarily = know what this action will be, however, or indeed what the receiver is. = Is it an endpoint? A PBX? A B2BUA? This is the particular scenario above = - the sender lives in a SIP-only world (enterprise with numeric aliases = on every desk), Identity is attached and call is made. Once it gets to = the far end, it=92s actually routed to a TN - but the sender didn=92t = know this. One specific example where this scenario could occur is in forking - if = you use a service which forks a call to multiple destinations, some SIP = endpoints, plus a PSTN number, then the verification service at the PSTN = gateway may assume a destination is canonicalised as a TN but in fact = was canonicalised as a SIP URI. > SIP routing has some core ambiguities around using telephone numbers = that it isn't the Identity header's job to rectify. But the important = question is whether or not, in our threat model, we think that this = particular ambiguity will arise enough that it justifies always = including "canon." We opened up the STIR working group to address = problems with telephone numbers as identifiers in SIP; along the way, we = decided that it was worth allowing that the same mechanism would work = for greenfield SIP URIs as well. I think the common case for STIR will = be to use telephone numbers for both orig and dest, just as it is in SIP = deployment today.=20 I freely admit we are looking at this from different angles. My = perspective is one of SIP ubiquity with external trunks and external = PSTN gateways. An improved, deployable SIP Identity header is very = appealing, but from a SIP-focused perspective to knowledge of what = reliably is or is not a TN simply isn=92t there at the sender. > I would, perhaps, grudgingly, be willing to entertain normative = guidance that states that if either orig or dest does not contain a "tn" = identity then you MUST use "canon." That would avoid the rather weasel-y = RFC3324ish proposed language about only sending "canon" when you = psychically know the terminating side shares your canonicalization = scheme. Even in my proposed form, I think it's overkill. But just = hypothetically, would that resolve your concern? Or anyone else=92s? I was proposing weasel words in the hope it would be acceptable to = everyone ;-) But I'd be certainly happy with the above instead, = although that seems a little overkill in comparison, with fewer get-out = clauses for environments which would be confident they didn=92t need = canon! Regards, Alan --Apple-Mail=_1E64F553-1BC1-408C-8F5D-BA142461065E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jon,

On 19 Sep 2016, at 21:26, = Peterson, Jon <jon.peterson@neustar.biz> wrote:


My primary concern was the SIP/TN distinction. Here is = an example, real-world which we ran into in SIPit:

Can you explain then how Brian's hint doesn't resolve = this?

I=92m = not sure which hint you are referring to here, if it=92s the suggestion = that the type of certificate should provide a clue, then that could only = reliably be used when considering the source URI and does not guarantee = how the destination URI would be canonicalised.

If you=92re talking about user=3Dphone, I may be = misreading what Brian wrote, or misreading RFC3261/4967, but my = understanding was that user=3Dphone is to indicate a number = really is a phone number? Sadly there are = many devices out there which slap user=3Dphone on every vaguely = telephonic URI, irrespective of global routability. It=92s certainly not = reliable today. Furthermore, the sender may still have no idea whether = the destination is a TN, so wouldn=92t know = whether to put user=3Dphone on it.

Of course given we=92re defining = something new here, there is the (potential) opportunity to correct = implementation and say user=3Dphone MUST be present for it to be = canonicalised as a TN, although sticking parameters on a To: address = would be uncharted territory AFAIK.

- Sender=92s PASSporT:

{ =93orig=94 : { =93uri=94 : =93sip:caller@source.net=94 = }, =93dest=94 : { =93uri=94 : [ =93sip:87654321@destination.net=94 ] } }

The sender sends like this since it is in a SIP = environment, e.g. a large enterprise, with no distinction of internal = and external calling.

Even without Brian's hint, cases like this don't = actually keep me up at night. And not just because, well, "destination.net" probably = isn't CompuServ and thus there's little chance it issues = entirely-numeric usernames.

As I mentioned in an earlier mail, = entirely-numeric user parts are actually very common in enterprise SIP = deployments.

It doesn't = especially concern me because in order for a SIP request to actually be routed, you need to = know whether it's just a telephone number, in which case you might drop = it to any old gateway to the PSTN with equal effect, or if in fact = you're expected to perform RFC3263 routing on the domain name part. Somehow, this works today without us adding any = indicator to SIP to resolve any = confusions. 

Indeed it does, given the receiving end only needs = to look at the Request-URI to know what to do with it. The sender does = not necessarily know what this action will be, however, or indeed what = the receiver is. Is it an endpoint? A PBX? A B2BUA? This is the = particular scenario above - the sender lives in a SIP-only world = (enterprise with numeric aliases on every desk), Identity is attached = and call is made. Once it gets to the far end, it=92s actually routed to = a TN - but the sender didn=92t know this.

One specific example where this scenario could = occur is in forking - if you use a service which forks a call to = multiple destinations, some SIP endpoints, plus a PSTN number, then the = verification service at the PSTN gateway may assume a destination is = canonicalised as a TN but in fact was canonicalised as a SIP = URI.

SIP routing has some core ambiguities around using = telephone numbers that it isn't the Identity header's job to rectify. = But the important question is whether or not, in our threat model, we = think that this particular ambiguity will arise enough that it justifies always including "canon." We opened up the STIR working group = to address problems with telephone numbers as identifiers in SIP; along = the way, we decided that it was worth allowing that the same mechanism = would work for greenfield SIP URIs as well. I think the common case for STIR will be to use telephone numbers for = both orig and dest, just as it is in SIP deployment = today. 

I freely admit we are looking at this from = different angles. My perspective is one of SIP ubiquity with external = trunks and external PSTN gateways. An improved, deployable SIP Identity = header is very appealing, but from a SIP-focused perspective to = knowledge of what reliably is or is not a TN simply isn=92t there at the = sender.

I would, perhaps, grudgingly, be willing to entertain = normative guidance that states that if either orig or dest does not = contain a "tn" identity then you MUST use "canon." That would avoid the = rather weasel-y RFC3324ish proposed language about only sending "canon" when you psychically know the terminating side shares your = canonicalization scheme. Even in my proposed form, I think it's = overkill. But just hypothetically, would that resolve your concern? Or = anyone else=92s?

I was proposing weasel words in = the hope it would be acceptable to everyone ;-)  But I'd be = certainly happy with the above instead, although that seems a little = overkill in comparison, with fewer get-out clauses for environments = which would be confident they didn=92t need canon!

Regards,
Alan

= --Apple-Mail=_1E64F553-1BC1-408C-8F5D-BA142461065E-- From nobody Tue Sep 20 08:20:20 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5870E12BA13; Tue, 20 Sep 2016 08:20:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147438481832.29077.2886419699122600365.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 08:20:18 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] stir - New Meeting Session Request for IETF 97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 15:20:18 -0000 A new meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: acme tls ecrit avtcore dane siprec p2psip rtcweb mmusic sipcore dispatch appsawg ice modern ipwave sipbrandy Second Priority: perc slim netvc clue tcpinc cose uta ace saag oauth Special Requests: --------------------------------------------------------- From nobody Tue Sep 20 08:32:50 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2326912B882; Tue, 20 Sep 2016 08:32:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147438556709.29097.6805052367139167200.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 08:32:47 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] stir - Update to a Meeting Session Request for IETF 97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 15:32:47 -0000 An update to a meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: acme tls ecrit avtcore dane siprec p2psip rtcweb mmusic sipcore dispatch appsawg ice modern ipwave sipbrandy lamps Second Priority: perc slim netvc clue tcpinc cose uta ace saag oauth Special Requests: --------------------------------------------------------- From nobody Tue Sep 20 12:55:06 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E261A12B4B6; Tue, 20 Sep 2016 12:55:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147440130388.27720.1307289028126901103.idtracker@ietfa.amsl.com> Date: Tue, 20 Sep 2016 12:55:03 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in, stir-chairs@ietf.org, rjsparks@nostrum.com Subject: [stir] stir - Update to a Meeting Session Request for IETF 97 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 19:55:04 -0000 An update to a meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Robert Sparks Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: sipbrandy ipwave modern ice appsawg dispatch sipcore mmusic rtcweb p2psip siprec dane avtcore ecrit tls acme lamps curdle Second Priority: perc slim netvc clue tcpinc cose uta ace saag oauth Special Requests: --------------------------------------------------------- From nobody Tue Sep 20 12:55:45 2016 Return-Path: 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 8FA6212B4CE for ; Tue, 20 Sep 2016 12:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no 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 njc-SokAbcoI for ; Tue, 20 Sep 2016 12:55:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AC212B4C5 for ; Tue, 20 Sep 2016 12:55:41 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u8KJteYg040200 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 20 Sep 2016 14:55:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local To: stir@ietf.org References: <147440130388.27720.1307289028126901103.idtracker@ietfa.amsl.com> From: Robert Sparks Message-ID: Date: Tue, 20 Sep 2016 14:55:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147440130388.27720.1307289028126901103.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [stir] stir - Update to a Meeting Session Request for IETF 97 X-BeenThere: stir@ietf.org 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: Tue, 20 Sep 2016 19:55:43 -0000 Sorry for the extra noise - tuning the conflict lists On 9/20/16 2:55 PM, "IETF Meeting Session Request Tool" wrote: > > An update to a meeting session request has just been submitted by Robert Sparks, a Chair of the stir working group. > > > --------------------------------------------------------- > Working Group Name: Secure Telephone Identity Revisited > Area Name: Applications and Real-Time Area > Session Requester: Robert Sparks > > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 60 > Conflicts to Avoid: > First Priority: sipbrandy ipwave modern ice appsawg dispatch sipcore mmusic rtcweb p2psip siprec dane avtcore ecrit tls acme lamps curdle > Second Priority: perc slim netvc clue tcpinc cose uta ace saag oauth > > > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Sep 20 18:41:30 2016 Return-Path: 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 EA9FB12B15F for ; Tue, 20 Sep 2016 18:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=tM0lhB5o; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=O9wIU40f 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 jryuAEPJ-DaA for ; Tue, 20 Sep 2016 18:41:27 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA3912B046 for ; Tue, 20 Sep 2016 18:41:26 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1EE14206ED; Tue, 20 Sep 2016 21:41:26 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 20 Sep 2016 21:41:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ysmWZcQoc2G7DEySYjKz4cY77OY=; b=tM0lhB 5oQJfxF9Z8G7UA8Bt/up9PxtoKf+6pT9tXDGxDcPF9/aHm8d5pE1mdYOGZp78Vu2 woAKJeAufVGJTqCxqMV35w0k4rureFnqWaxtIZP4ncmlNF+P+QlMlSkqDJzU+y5m /8q/IwPk0Niq9vjlICYYnUl7cP0YogThEWvJM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ysmWZcQoc2G7DEy SYjKz4cY77OY=; b=O9wIU40fohQmSnxs4+CutJRsv3fnvCv3TvJqMKg27uGt3XP 5Ogi8OB/ov/RIPvvN/ULrs8EvYzRHl6DZiW0hqY17Efxl25Ef8yPuNwluVCnNk7a bm2y11Vv3g67PsNEACh61Qq8rliTSjPY8ST0u9XjBHiB+ZgRjZIesEQWqwF8= X-Sasl-enc: yTNrJbH2iNCqiUmfDLy+GUQzMNnIEyHiB4SHVIeBLjec 1474422085 Received: from [10.24.25.193] (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 35BD6F2988; Tue, 20 Sep 2016 21:41:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> Date: Tue, 20 Sep 2016 21:41:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Wed, 21 Sep 2016 01:41:29 -0000 I did my AD review of this document early to try to expedite the = process. =3D General =3D Should this document obsolete RFC 4474? Apologies if this was discussed = and I'm failing to recall it. My answer would be yes I think, since new = implementations of RFC 4474 are discouraged and this document is = deprecating its syntax and its registries. =3D Section 4.1 =3D (1) "Third, the JSON key "iat" MUST appear, set to the value of a quoted encoding of the value of the SIP Date header field as a JSON NumericDate (as UNIX time, per [RFC7519] Section 2)." I think this needs one more sentence to explain that while RFC 7519 = specifies that "iat" reflect the time the JWT was issued, there may be = cases where an authorization service mints a JWT on behalf of an = endpoint at some point later than what the SIP Date reflects. Given that = the JWT is being created on behalf of the user (and how and why "iat" is = used by 4474bis implementations), using the SIP Date rather than the = time at which the JWT is actually created is acceptable. (2) "Defining how a SIP implementation would provision multiple originating or destination identities is left as a subject for future specification." I'm assuming this meant to say that defining how a STIR implementation = deals with multiple identities is what is left for future specification. = Is that correct? If so, it would be helpful to clarify. (3) "Also note that in some cases, the "orig" and "dest" arrays might be populated with more than one = value." The passport spec says that "orig" MUST only have one value. Should this = text align with that? Or is this meant to allow for future extensibility = of passport? =3D Section 8.3 =3D (1) "This will be the case, for example, for nationally-specific service numbers (e.g. 911, 112); however, the routing procedures associated with those numbers will likely make sure that the verification service understands the context of their use." I don't understand what is meant by the text after the semi-colon. Is = the point that the lack of canonicalization is ok because a verifier = that is asked to verify 112 will be designed to know that 112 is = special? (2) "If not, implementations SHOULD convert the number into E.164 format, adding a country code if necessary; this may involve transforming the number from a dial string (see [RFC3966]), removing any national or international dialing prefixes or performing similar procedures. ...=20 Other transformations during canonicalization MAY be made in accordance with specific policies used within a local domain." Aren't all of the "other transformations" subsumed under the umbrella of = converting to E.164 format? I find it confusing to see these discussed = as two separate requirements. I think it's fine to point out that some = domains will need to take their own unique steps to eventually get their = numbers into E.164 format, but that doesn't imply that there is one set = of transformations that SHOULD happen and another set of transformations = that MAY happen, right? =20 =3D Section 13.3 =3D Shouldn't the existing alg parameter have its reference updated to point = to this document? Nits: =3D Section 1 =3D A forward reference to Section 10 should be added to the last paragraph. =3D Section 2 =3D s/from an "identity field" a SIP request/from an "identity field" in a = SIP request/ =3D Section 4.1 =3D "the following elements message MUST be placed" -- I'm assuming = "message" is extraneous and should be deleted?=20 s/key "typ" key/key "typ"/ s/from addr-spec of the =46rom header/from the addr-spec component of = the =46rom header/ OLD This specification inherits from the PASSporT specification one value for the 'alg' parameter: 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 digital signature. All implementations of this specification MUST support the required signing algorithms of PASSporT. NEW All implementations of this specification MUST support the required = signing algorithms of PASSporT. At present there is one = mandatory-to-support value for the 'alg' parameter: 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 digital signature. =20 =20 =3D Section 6.2.1 =3D I think it would help to provide a little bit of rationale for this = recommendation: "As a guideline, this specification recommends that only = if a verifier determines all Identity header fields within a message are invalid should the request be considered to have an invalid = identity." =3D Section 6.2.2 =3D s/reason phase/reason phrase/ =3D Section 10 =3D OLD it would likely fail the request due to the absence of an Identity-Info header field with a 436 response code. NEW it would likely fail the request with a 436 response code due to the = absence of an Identity-Info header field. =3D Section 13.4 =3D I think this section should clearly instruct IANA to delete the = registry. Alissa > On Sep 10, 2016, at 12:01 PM, Russ Housley = wrote: >=20 >=20 > A revised document to address the issues raised in the first WG Last = Call > on this document was posted yesterday. > (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-12.txt). >=20 > This message starts a second two-week WG Last Call for this document, > which will end on 24 September 2016. >=20 > Please review the document and send comments on it to the STIR WG mail > list. Please clearly state your opinion as to whether the document is > ready for publication as a standards-track RFC. Remember that support > for publication is needed, so if you think the document is ready to go > forward, please say so. >=20 > Thanks, > Russ & Robert >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Sep 20 18:43:42 2016 Return-Path: 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 733E512B097 for ; Tue, 20 Sep 2016 18:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=3C2pSIU4; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=eAF3QCax 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 XRb2mupJzalL for ; Tue, 20 Sep 2016 18:43:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1E3127076 for ; Tue, 20 Sep 2016 18:43:37 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 61E34205D7 for ; Tue, 20 Sep 2016 21:43:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 20 Sep 2016 21:43:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=ugDbSlZ2hwOU3KkE3kEyS6ZMSyc=; b=3C2pSI U4aNB1MHdRhykb33gLaBn4EHEf0YEsIOhX5c9E4qcZ0DH6riKAr8b6UZ5wfFgRS7 gjKJTJLJzirV2WXRryduHrcIxv3NpcX1gelyNKWXCclgG/3/lO3l4Ki+XOMlcgp1 SSg5Ht4leO3v3121s6bnS5e/mQCHVxCCNc+bk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=ugDbSlZ2hwOU3Kk E3kEyS6ZMSyc=; b=eAF3QCaxWQ54KBxZcD791BElzOHjmmADuItU/XryFgGDcZ+ jPWhXv+2oQp6CkYgzYNocYXK2kZE2bia4Af4PAvpYPWuc2ztLoov1RNZr/CIdAy4 97hpUDlFmpd1BP5K1J67ETCyd9A6U7rFNJ4MqTuHgvmONSIHFCfegDAXrl38= X-Sasl-enc: VGcnnOQDlH/oBofmdZlEly/e5jVN7viMVamvOdSX/8fh 1474422216 Received: from [10.24.25.193] (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id AA017F29CD for ; Tue, 20 Sep 2016 21:43:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20388E22-CF03-4338-954B-B9BAFA33C4AF@vigilsec.com> Date: Tue, 20 Sep 2016 21:43:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F26F994-AE94-4C6E-B9F7-D5E6576E423E@cooperw.in> References: <20388E22-CF03-4338-954B-B9BAFA33C4AF@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] Second WG Last Call for PASSporT Document X-BeenThere: stir@ietf.org 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: Wed, 21 Sep 2016 01:43:40 -0000 I did my AD review of this document early to try to expedite the = process. Substantive comments and questions: =3D Section 3.2 =3D I have some suggested changes below which I think more accurately = reflect the intent of the WG as regards algorithm support. But if I'm = incorrect, let's discuss. OLD=20 For the creation and verification of PASSporT tokens and their digital = signatures ES256 MUST be implemented as defined in JWA Section 3.4 Note that JWA defines other algorithms that may be utilized or updated = in the future depending on cryptographic strength requirements guided by = current security best practice. NEW=20 For the creation and verification of PASSporT tokens and their digital = signatures, implementations MUST support ES256 as defined in JWA Section = 3.4. Implementations MAY support other algorithms registered in the JSON = Web Signature and Encryption Algorithms registry created by RFC 7518. = The contents of that registry may be updated in the future depending on = cryptographic strength requirements guided by current security best = practice. The mandatory-to-support algorithm for PASSporT tokens may = likewise be updated in future updates to this document. =3D Section 4.1.1 =3D "As defined this should be set to the date and time of the origination = of the personal communications." Actually, as defined in RFC 7519 this should be set to the time the JWT = is issued. I think that is all that needs to be said here. =3D Section 7 =3D I suggest the edit below, but note that it modifies the way the = normative MUST is to be interpreted. Does this match the intent of the = existing language? OLD=20 In order to make the digital signature verification work = deterministically, the JSON representation of the PASSporT Header and = Claims, particularly if PASSporT is used across multiple signaling = environments, specifically the JWS Protected Header object and JWS = Payload object MUST be computed as follows. NEW=20 In order to make the digital signature verification work = deterministically, the JSON representation of the PASSporT header and = claims MUST be computed as follows. =3D Section 8 =3D I think the security considerations need a different approach. Passport = tokens themselves do not provide defenses against replay or violations = of confidentiality or integrity. That is natural, as all that is being = specified is a format. The consequence of this is that those defenses, = to the extent they can be made available, need to be built into the ways = that applications make use of the tokens. I think this should be stated = up front and I think the requirements on applications making use of = passport tokens should be clearly listed and described with normative = language. For example, I would think that at least some of the recommendations in = 8.1 and 8.3 could be normative recommendations on applications: a = PASSporT token SHOULD only be sent together with application data fields = that correspond directly to fields in the token and MUST NOT be used by = applications to expose identifiers or other communications details that = the application does not otherwise already expose. =3D Section 8.2 =3D "However, applications that use PASSporT should ensure the signer is in = an authoritative position to represent the user and authenticate the = user onto the communications network and should be the responsible party = for protecting the destination party from potential identity spoofing in = addition to other abuse of the communications network outside of = PASSporT." This sounds like a rather hefty set of requirements to levy on = applications, especially if this is interpreted as a set of requirements = to be implemented programmatically (although "should be the responsible = party" is I guess clearly not a programmatic requirement). Perhaps what = you're aiming for here is, instead, that operators of implementations = that are verifying passport tokens should have some means of verifying = that signers are authoritative, possibly automated but possibly not? I = would recommend dropping the clause about the responsible party = altogether as it seems out of scope for this document. Nits: =3D Abstract =3D OLD=20 This document defines a canonical string object or 'token' including a = digital signature for verifying the author of the token, their authority = to author the token and the information asserted in the token, = minimally, the originating identity or 'persona' corresponding = specifically to the originator of 'personal communications', or = signalled communications between a set of parties with identities. The = PASSporT token is cryptographically signed to protect the integrity of = the identify the originator of a personal communications session (e.g. = the telephone number or URI) and verify the assertion of the identity = information at the destination. NEW=20 This document defines a method for creating and validating a token that = cryptographically verifies an originating identity, or more generally a = URI or telephone number representing the originator of personal = communications. The PASSporT token is cryptographically signed to = protect the integrity of the identity the originator and to verify the = assertion of the identity information at the destination. =3D Section 1 =3D s/for the signing and verification of telephone numbers./for the signing = and verification of telephone numbers and SIP URIs./ =3D Section 3 =3D Throughout this section, several of the references to sections of RFC = 7518 are not properly encoded, so, for example, a reference which is = intended to link to RFC 7518 Section 3.1 is actually referencing Section = 3.1 of this document. Please fix these. s/the following header parameters defined the the next three = subsections./the header parameters defined in the next three = subsections. =3D Section 4 =3D s/and be encoded/and are encoded/ =3D Section 4.2.1 =3D s/being called by the caller,/being called by the caller./ s/determined by the application must have the capability/determined by = the application need to have the capability =3D Section 4.2.1.1 =3D Same problem with the section reference as in Section 3. =3D Section 4.2.2 =3D s/If there are more that one fingerprint/If there is more than one = fingerprint/ =3D Section 7 =3D OLD=20 JSON, as a canonical format, can include spaces, line breaks and key = value pairs can occur in any order and therefore makes it, from a string = format, non-deterministic. NEW=20 JSON, as a canonical format, can include spaces and line breaks, and key = value pairs can occur in any order. It is therefore a non-deterministic = string format. Alissa > On Sep 10, 2016, at 12:04 PM, Russ Housley = wrote: >=20 >=20 > A revised document to address the issues raised in the first WG Last = Call > on this document was posted yesterday. > (https://www.ietf.org/id/draft-ietf-stir-passport-07.txt). >=20 > This message starts a second two-week WG Last Call for this document, > which will end on 24 September 2016. >=20 > Please review the document and send comments on it to the STIR WG mail > list. Please clearly state your opinion as to whether the document is > ready for publication as a standards-track RFC. Remember that support > for publication is needed, so if you think the document is ready to go > forward, please say so. >=20 > Thanks, > Russ & Robert >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Tue Sep 20 21:28:43 2016 Return-Path: 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 6835112B42D for ; Tue, 20 Sep 2016 21:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 D2BaovhTLaPs for ; Tue, 20 Sep 2016 21:28:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3913012B40E for ; Tue, 20 Sep 2016 21:28:38 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1A1728FA4B89; Wed, 21 Sep 2016 04:28:35 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8L4SauV024475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2016 04:28:36 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u8L4RP2A023083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Sep 2016 06:28:34 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.150]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 21 Sep 2016 06:27:33 +0200 From: "Drage, Keith (Nokia - GB)" To: Henning Schulzrinne , Brian Rosen Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAAvTngIAABekAgAABcQCAAB1nAIAACmAAgAAGigCAAEpQgIAAMowAgACobACAAAXgAIAAFN6AgAAIUgCAAAJHgIAAAs8AgAZLihA= Date: Wed, 21 Sep 2016 04:27:32 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF80123@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADF80123FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "stir@ietf.org" , Paul Kyzivat , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Wed, 21 Sep 2016 04:28:42 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADF80123FR712WXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are all sorts of reasons why some of these would not work. There are many reasons why one would use both PAI and From, and use them co= nsistently! But there are also strong reasons why PAI is not present, or th= at From is obfuscated, on specific calls. Networks may route calls on the the public network for eventually destinati= on at another point in the same private network. It is debatable whether short codes are actually telephone numbers, at leas= t within E.164. Keith From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: 16 September 2016 18:46 To: Brian Rosen Cc: stir@ietf.org; Paul Kyzivat; Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Wouldn't this seem like something that SIPConnect 2.0 should address? My general impression is that there are a small number of ways to do things= well, and a near-infinite number of ways to make life difficult for everyb= ody else. Trying to accommodate and detect the latter seems like a fool's e= rrand, given that we want validation to work as close to 100% as possible. = This discussion seems to have yielded a number of reasonable guidelines, al= ong the lines of: * consistently use PAI or From (i.e., be clear what should be used within a= particular operating context, such as SIPConnect or SIP NNI) * only convey return-callable global (E.164) numbers outside your own close= d network * separators in tel URIs should be expected * short codes, N11 and similar numbers will likely only work within a natio= nal context Thus, "be predictable, boring and conservative in what you send, and don't = expect the receiver to be liberal". Here, we have a penalty function: Being "creative" will likely get your cal= l flagged as unvalidated. Henning ________________________________ From: Brian Rosen > Sent: Friday, September 16, 2016 1:35:35 PM To: Henning Schulzrinne Cc: Alan Ford; Paul Kyzivat; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? I think it probably would within the ATIS kind of environment, but Alan is = talking about things that are beyond that: his example is a SIP URI from an= enterprise PBX that doesn't have a phone number in the identity. I personally think we need to get the PBX vendors on board as fast as we ca= n in order to be able to support "authorized spoofing", like call centers c= alling on behalf of other enterprises. I think getting the service provide= rs to sign in those cases will be complicated, and if they can push the pro= blem off to the call center, it will work out better. So, I think its wort= h solving all/most of the problems the PBX folks think they have. Having said that, the only circumstance I can think of where there is an id= entity like he is describing is an intra-enterprise call (possibly between = sites, but within the same enterprise). In those environments, identity sp= oofing is much harder to mount because the intra-enterprise traffic tends t= o be entirely within the corporate network, and they don't allow calls from= sources they don't know. Doesn't mean stir should not work, but it's pret= ty far down in my list of things to worry about. Brian On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne > wrote: Without taking a position on whether to canon-ize or not (that's a papal th= ing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices wil= l largely moot this issue, i.e., within a particular context the use of PAI= vs. From and the encoding will be constant and ruled by best practices, so= that real devices will just have a configuration setting that says "Look a= t PAI; only if absent, look at From". Clearly, for calls within a carrier n= etwork, this is not likely to be an issue. Not ideal, but the good guys will have an incentive to adhere to common pra= ctice, as they want validation to work. I haven't looked at the details of the SIP NNI spec to see if that spec is = sufficiently precise or whether, say, the SHAKEN ATIS document could provid= e that level of specificity. Unless a parameter can short-circuit the exploration completely ("only look= at X"), I'm not sure 'canon' helps with the resource exhaustion issue. Henning ________________________________ From: stir > on behalf = of Alan Ford > Sent: Friday, September 16, 2016 12:57:39 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi Paul, > Surely the caller and signer bear some responsibility here. If they creat= e a situation where there is ambiguity about which address is being signed = then either they should do something to resolve it (e.g., in include canon)= or else be prepared for the consequences if the callee can't validate. It = is in the caller's interest that the call be validated, so they should be e= xpected to make that feasible. This ultimately comes down to quality of imp= lementation. The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway. But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect. > But there is also a brute force solution available to the validator: try = validation using each of the supplied identities in turn until one validate= s or none do. While that might cost a bit of extra computation, the cost of= that might be less than the cost of carrying the canon parameter from end = to end. That's certainly true, but in my opinion the cost of bits is much cheaper t= han the cost of computation. What's more, a brute-force receiver could gene= rate a modest denial-of-service attack vector - send a signature for someth= ing completely different, and let the verification service munch through cy= cles trying various combinations to see if any validate (they won't, of cou= rse). Minimum would be four combinations tried for just one src and one des= t (trying tn: vs sip: combinations) - and this could be many more if you st= art to include other identifiers such as PAI or RPID. Whereas, if the canon= was included, there would be one single crypto operation to verify the sig= nature against known data. Regards, Alan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_949EF20990823C4C85C18D59AA11AD8BADF80123FR712WXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are all sorts of re= asons why some of these would not work.

 <= /p>

There are many reasons wh= y one would use both PAI and From, and use them consistently! But there are= also strong reasons why PAI is not present, or that From is obfuscated, on specific calls.

 <= /p>

Networks may route calls = on the the public network for eventually destination at another point in th= e same private network.

 <= /p>

It is debatable whether s= hort codes are actually telephone numbers, at least within E.164.

 <= /p>

Keith

 <= /p>

From: stir [ma= ilto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: 16 September 2016 18:46
To: Brian Rosen
Cc: stir@ietf.org; Paul Kyzivat; Alan Ford
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

Wouldn't this seem like something tha= t SIPConnect 2.0 should address?

 

My general impression is that there a= re a small number of ways to do things well, and a near-infinite number of = ways to make life difficult for everybody else. Trying to accommodate and detect the latter seems like a fool's errand, given that w= e want validation to work as close to 100% as possible. This discussion see= ms to have yielded a number of reasonable guidelines, along the lines of:

 

* consistently use PAI or From (i.e.,= be clear what should be used within a particular operating context, such a= s SIPConnect or SIP NNI)

* only convey return-callable global = (E.164) numbers outside your own closed network

* separators in tel URIs should be ex= pected

* short codes, N11 and similar n= umbers will likely only work within a national context

 

Thus, "be predictable, boring an= d conservative in what you send, and don't expect the receiver to be l= iberal".

 

Here, we have a penalty function: Bei= ng "creative" will likely get your call flagged as unvalidated.

 

Henning

From: Brian Rosen <br@b= rianrosen.net>
Sent: Friday, September 16, 2016 1:35:35 PM
To: Henning Schulzrinne
Cc: Alan Ford; Paul Kyzivat; stir@i= etf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

I think it probably would within the ATIS kind of en= vironment, but Alan is talking about things that are beyond that: his examp= le is a SIP URI from an enterprise PBX that doesn’t have a phone numb= er in the identity.

 

I personally think we need to get the PBX vendors on= board as fast as we can in order to be able to support “authorized s= poofing”, like call centers calling on behalf of other enterprises. &= nbsp;I think getting the service providers to sign in those cases will be complicated, and if they can push the problem off t= o the call center, it will work out better.  So, I think its worth sol= ving all/most of the problems the PBX folks think they have.

 

Having said that, the only circumstance I can think = of where there is an identity like he is describing is an intra-enterprise = call (possibly between sites, but within the same enterprise).  In tho= se environments, identity spoofing is much harder to mount because the intra-enterprise traffic tends to be entirely = within the corporate network, and they don’t allow calls from sources= they don’t know.  Doesn’t mean stir should not work, but = it’s pretty far down in my list of things to worry about.<= /p>

 

Brian

 

On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <= ;Henning.Schulzrinne@fcc.gov= > wrote:

 

Without taking a position on = whether to canon-ize or not (that's a papal thing and I'm not catholic), I = wonder if ATIS/SIPForum NNI best practices will largely moot this issue, i.e., within a particular context the use of PAI vs. From and = the encoding will be constant and ruled by best practices, so that real dev= ices will just have a configuration setting that says "Look at PAI; on= ly if absent, look at From". Clearly, for calls within a carrier network, this is not likely to be an issue.

 

Not ideal, but the good guys = will have an incentive to adhere to common practice, as they want validatio= n to work.

 

I haven't looked at the detai= ls of the SIP NNI spec to see if that spec is sufficiently precise or wheth= er, say, the SHAKEN ATIS document could provide that level of specificity.

 

Unless a parameter can short-= circuit the exploration completely ("only look at X"), I'm not su= re 'canon' helps with the resource exhaustion issue.

 

Henning

From: stir <stir-bounces@ietf.org>= on behalf of Alan Ford <alan.for= d@gmail.com>
Sent: Friday, Sept= ember 16, 2016 12:57:39 PM
To: Paul Kyzivat Cc: stir@ietf.org
Subject: Re: [stir= ] 4474bis: Why only RECOMMEND when multiple identities?

 

Hi Pau= l,

> Surely the caller and signer bear some responsibility here. If they cr= eate a situation where there is ambiguity about which address is being sign= ed then either they should do something to resolve it (e.g., in include can= on) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call= be validated, so they should be expected to make that feasible. This ultim= ately comes down to quality of implementation.

The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect.

> But there is also a brute force solution available to the validator: t= ry validation using each of the supplied identities in turn until one valid= ates or none do. While that might cost a bit of extra computation, the cost= of that might be less than the cost of carrying the canon parameter from end to end.

That’s certainly true, but in my opinion the cost of bits is much che= aper than the cost of computation. What’s more, a brute-force receive= r could generate a modest denial-of-service attack vector - send a signatur= e for something completely different, and let the verification service munch through cycles trying various combinations = to see if any validate (they won’t, of course). Minimum would be four= combinations tried for just one src and one dest (trying tn: vs sip: combi= nations) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if= the canon was included, there would be one single crypto operation to veri= fy the signature against known data.

Regards,
Alan

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

______________________________________= _________
stir mailing list
stir@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/stir

 

--_000_949EF20990823C4C85C18D59AA11AD8BADF80123FR712WXCHMBA11z_-- From nobody Wed Sep 21 05:26:09 2016 Return-Path: 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 121EA12B268 for ; Wed, 21 Sep 2016 05:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 Fo5PtRS1WEBA for ; Wed, 21 Sep 2016 05:26:05 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C0F12B26D for ; Wed, 21 Sep 2016 05:25:54 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u8LCPGeQ037279; Wed, 21 Sep 2016 08:25:19 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 25kt1srs9a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Sep 2016 08:25:17 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8LCP0mQ026297; Wed, 21 Sep 2016 08:25:00 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8LCOmn2026121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Sep 2016 08:24:52 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 21 Sep 2016 12:24:34 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.137]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0301.000; Wed, 21 Sep 2016 08:24:33 -0400 From: "DOLLY, MARTIN C" To: "Drage, Keith (Nokia - GB)" , Henning Schulzrinne , Brian Rosen Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities? Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAAvTngIAABekAgAABcQCAAB1nAIAACmAAgAAGigCAAEpQgIAAMowAgACobACAAAXgAIAAFN6AgAAIUgCAAAJHgIAAAs8AgAZLihCAAVauQA== Date: Wed, 21 Sep 2016 12:24:33 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BC9C3D6@ESESSMB209.ericsson.se> <4BAA06A3-B586-4623-859D-11BED14259DC@gmail.com> <4CCADA42-7919-4613-ABAC-F89ACD028484@brianrosen.net> <01AE9B64-F8E4-492A-B4F7-DEDE5A8565A4@brianrosen.net> <853CEC21-117D-4093-A0DE-4CAED384E325@gmail.com> <7C2E7C13-55A1-4259-B31C-8B24C78C42A3@gmail.com> , <949EF20990823C4C85C18D59AA11AD8BADF80123@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF80123@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.169.182] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E836564AA00C90MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609210226 Archived-At: Cc: "stir@ietf.org" , Paul Kyzivat , Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? X-BeenThere: stir@ietf.org 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: Wed, 21 Sep 2016 12:26:08 -0000 --_000_E42CCDDA6722744CB241677169E836564AA00C90MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sanity check, Carriers have been normalizing crap numbers from enterprises = since the dawn of time (older than me, and that's old) From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Drage, Keith (Nokia = - GB) Sent: Wednesday, September 21, 2016 12:28 AM To: Henning Schulzrinne ; Brian Rosen Cc: stir@ietf.org; Paul Kyzivat ; Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? There are all sorts of reasons why some of these would not work. There are many reasons why one would use both PAI and From, and use them co= nsistently! But there are also strong reasons why PAI is not present, or th= at From is obfuscated, on specific calls. Networks may route calls on the the public network for eventually destinati= on at another point in the same private network. It is debatable whether short codes are actually telephone numbers, at leas= t within E.164. Keith From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: 16 September 2016 18:46 To: Brian Rosen Cc: stir@ietf.org; Paul Kyzivat; Alan Ford Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Wouldn't this seem like something that SIPConnect 2.0 should address? My general impression is that there are a small number of ways to do things= well, and a near-infinite number of ways to make life difficult for everyb= ody else. Trying to accommodate and detect the latter seems like a fool's e= rrand, given that we want validation to work as close to 100% as possible. = This discussion seems to have yielded a number of reasonable guidelines, al= ong the lines of: * consistently use PAI or From (i.e., be clear what should be used within a= particular operating context, such as SIPConnect or SIP NNI) * only convey return-callable global (E.164) numbers outside your own close= d network * separators in tel URIs should be expected * short codes, N11 and similar numbers will likely only work within a natio= nal context Thus, "be predictable, boring and conservative in what you send, and don't = expect the receiver to be liberal". Here, we have a penalty function: Being "creative" will likely get your cal= l flagged as unvalidated. Henning ________________________________ From: Brian Rosen > Sent: Friday, September 16, 2016 1:35:35 PM To: Henning Schulzrinne Cc: Alan Ford; Paul Kyzivat; stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? I think it probably would within the ATIS kind of environment, but Alan is = talking about things that are beyond that: his example is a SIP URI from an= enterprise PBX that doesn't have a phone number in the identity. I personally think we need to get the PBX vendors on board as fast as we ca= n in order to be able to support "authorized spoofing", like call centers c= alling on behalf of other enterprises. I think getting the service provide= rs to sign in those cases will be complicated, and if they can push the pro= blem off to the call center, it will work out better. So, I think its wort= h solving all/most of the problems the PBX folks think they have. Having said that, the only circumstance I can think of where there is an id= entity like he is describing is an intra-enterprise call (possibly between = sites, but within the same enterprise). In those environments, identity sp= oofing is much harder to mount because the intra-enterprise traffic tends t= o be entirely within the corporate network, and they don't allow calls from= sources they don't know. Doesn't mean stir should not work, but it's pret= ty far down in my list of things to worry about. Brian On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne > wrote: Without taking a position on whether to canon-ize or not (that's a papal th= ing and I'm not catholic), I wonder if ATIS/SIPForum NNI best practices wil= l largely moot this issue, i.e., within a particular context the use of PAI= vs. From and the encoding will be constant and ruled by best practices, so= that real devices will just have a configuration setting that says "Look a= t PAI; only if absent, look at From". Clearly, for calls within a carrier n= etwork, this is not likely to be an issue. Not ideal, but the good guys will have an incentive to adhere to common pra= ctice, as they want validation to work. I haven't looked at the details of the SIP NNI spec to see if that spec is = sufficiently precise or whether, say, the SHAKEN ATIS document could provid= e that level of specificity. Unless a parameter can short-circuit the exploration completely ("only look= at X"), I'm not sure 'canon' helps with the resource exhaustion issue. Henning ________________________________ From: stir > on behalf = of Alan Ford > Sent: Friday, September 16, 2016 12:57:39 PM To: Paul Kyzivat Cc: stir@ietf.org Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities? Hi Paul, > Surely the caller and signer bear some responsibility here. If they creat= e a situation where there is ambiguity about which address is being signed = then either they should do something to resolve it (e.g., in include canon)= or else be prepared for the consequences if the callee can't validate. It = is in the caller's interest that the call be validated, so they should be e= xpected to make that feasible. This ultimately comes down to quality of imp= lementation. The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway. But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect. > But there is also a brute force solution available to the validator: try = validation using each of the supplied identities in turn until one validate= s or none do. While that might cost a bit of extra computation, the cost of= that might be less than the cost of carrying the canon parameter from end = to end. That's certainly true, but in my opinion the cost of bits is much cheaper t= han the cost of computation. What's more, a brute-force receiver could gene= rate a modest denial-of-service attack vector - send a signature for someth= ing completely different, and let the verification service munch through cy= cles trying various combinations to see if any validate (they won't, of cou= rse). Minimum would be four combinations tried for just one src and one des= t (trying tn: vs sip: combinations) - and this could be many more if you st= art to include other identifiers such as PAI or RPID. Whereas, if the canon= was included, there would be one single crypto operation to verify the sig= nature against known data. Regards, Alan _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E42CCDDA6722744CB241677169E836564AA00C90MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sanity check, Carriers have been norm= alizing crap numbers from enterprises since the dawn of time (older than me= , and that’s old)

 

From: stir [mailto:stir-bounces@ietf= .org] On Behalf Of Drage, Keith (Nokia - GB)
Sent: Wednesday, September 21, 2016 12:28 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; Brian R= osen <br@brianrosen.net>
Cc: stir@ietf.org; Paul Kyzivat <pkyzivat@alum.mit.edu>; Alan = Ford <alan.ford@gmail.com>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

There are all sorts of reasons why so= me of these would not work.

 

There are many reasons why one would = use both PAI and From, and use them consistently! But there are also strong= reasons why PAI is not present, or that From is obfuscated, on specific calls.

 

Networks may route calls on the the p= ublic network for eventually destination at another point in the same priva= te network.

 

It is debatable whether short codes a= re actually telephone numbers, at least within E.164.

 

Keith

 

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: 16 September 2016 18:46
To: Brian Rosen
Cc: stir@ietf.org; Paul Kyzivat= ; Alan Ford
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

Wouldn't this seem like something that SIPConnect= 2.0 should address?

 

My general impression is that there are a small n= umber of ways to do things well, and a near-infinite number of ways to make= life difficult for everybody else. Trying to accommodate and detect the latter seems like a fool's errand, given that w= e want validation to work as close to 100% as possible. This discussion see= ms to have yielded a number of reasonable guidelines, along the lines of:

 

* consistently use PAI or From (i.e., be clear wh= at should be used within a particular operating context, such as SIPConnect= or SIP NNI)

* only convey return-callable global (E.164) numb= ers outside your own closed network

* separators in tel URIs should be expected<= /o:p>

* short codes, N11 and similar numbers will = likely only work within a national context

 

Thus, "be predictable, boring and conse= rvative in what you send, and don't expect the receiver to be liberal"= .

 

Here, we have a penalty function: Being "cre= ative" will likely get your call flagged as unvalidated.

 

Henning

From: Brian = Rosen <br@brianrosen.net> Sent: Friday, September 16, 2016 1:35:35 PM
To: Henning Schulzrinne
Cc: Alan Ford; Paul Kyzivat; stir@i= etf.org
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identi= ties?

 

I think it probably would within the ATIS kind of en= vironment, but Alan is talking about things that are beyond that: his examp= le is a SIP URI from an enterprise PBX that doesn’t have a phone numb= er in the identity.

 

I personally think we need to get the PBX vendors on= board as fast as we can in order to be able to support “authorized s= poofing”, like call centers calling on behalf of other enterprises. &= nbsp;I think getting the service providers to sign in those cases will be complicated, and if they can push the problem off t= o the call center, it will work out better.  So, I think its worth sol= ving all/most of the problems the PBX folks think they have.

 

Having said that, the only circumstance I can think = of where there is an identity like he is describing is an intra-enterprise = call (possibly between sites, but within the same enterprise).  In tho= se environments, identity spoofing is much harder to mount because the intra-enterprise traffic tends to be entirely = within the corporate network, and they don’t allow calls from sources= they don’t know.  Doesn’t mean stir should not work, but = it’s pretty far down in my list of things to worry about.<= /p>

 

Brian

 

On Sep 16, 2016, at 1:27 PM, Henning Schulzrinne <= ;Henning.Schulzrinne@fcc.gov= > wrote:

 

Without taking a position on whether to c= anon-ize or not (that's a papal thing and I'm not catholic), I wonder if AT= IS/SIPForum NNI best practices will largely moot this issue, i.e., within a particular context the use of PAI vs. From and = the encoding will be constant and ruled by best practices, so that real dev= ices will just have a configuration setting that says "Look at PAI; on= ly if absent, look at From". Clearly, for calls within a carrier network, this is not likely to be an issue.

 

Not ideal, but the good guys will have an= incentive to adhere to common practice, as they want validation to work.

 

I haven't looked at the details of the SI= P NNI spec to see if that spec is sufficiently precise or whether, say, the= SHAKEN ATIS document could provide that level of specificity.

 

Unless a parameter can short-circuit the = exploration completely ("only look at X"), I'm not sure 'canon' h= elps with the resource exhaustion issue.

 

Henning

From: stir <stir-bounces@ietf.org>= on behalf of Alan Ford <alan.for= d@gmail.com>
Sent: Friday, Sept= ember 16, 2016 12:57:39 PM
To: Paul Kyzivat Cc: stir@ietf.org
Subject: Re: [stir= ] 4474bis: Why only RECOMMEND when multiple identities?

 

Hi Paul,

> Surely the caller and signer bear some responsibility here. If they cr= eate a situation where there is ambiguity about which address is being sign= ed then either they should do something to resolve it (e.g., in include can= on) or else be prepared for the consequences if the callee can't validate. It is in the caller's interest that the call= be validated, so they should be expected to make that feasible. This ultim= ately comes down to quality of implementation.

The sender may or may not know that there would be ambiguity at the receivi= ng side. For example, the sender may only deal in SIP URIs and not know the= receiver is also a PSTN gateway.

But in general, I agree, but feel this should be codified. This is why my p= roposed resolution here would be to mandate canon unless the sender knows f= or certain the receiving environment will follow the same canonicalisation = scheme - or words to that effect.

> But there is also a brute force solution available to the validator: t= ry validation using each of the supplied identities in turn until one valid= ates or none do. While that might cost a bit of extra computation, the cost= of that might be less than the cost of carrying the canon parameter from end to end.

That’s certainly true, but in my opinion the cost of bits is much che= aper than the cost of computation. What’s more, a brute-force receive= r could generate a modest denial-of-service attack vector - send a signatur= e for something completely different, and let the verification service munch through cycles trying various combinations = to see if any validate (they won’t, of course). Minimum would be four= combinations tried for just one src and one dest (trying tn: vs sip: combi= nations) - and this could be many more if you start to include other identifiers such as PAI or RPID. Whereas, if= the canon was included, there would be one single crypto operation to veri= fy the signature against known data.

Regards,
Alan

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

_______________________________________________ stir mailing list
stir@ietf.org
https://w= ww.ietf.org/mailman/listinfo/stir

 

--_000_E42CCDDA6722744CB241677169E836564AA00C90MISOUT7MSGUSRDB_-- From nobody Wed Sep 21 07:46:46 2016 Return-Path: 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 4E0C312B3AF for ; Wed, 21 Sep 2016 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=PhXmblmx; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=lgNoPUPZ 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 pRP7zj0doHoU for ; Wed, 21 Sep 2016 07:46:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6808512B38D for ; Wed, 21 Sep 2016 07:46:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D9CB52072B for ; Wed, 21 Sep 2016 10:46:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 21 Sep 2016 10:46:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=YpC7CHK1WdNEkWOVMN+VedJSqOU=; b=PhXmbl mxdQYyHLjtYXvX7kXiQuxp40qzFDlvCjNh9LnZET9HwWP1EZrKCwa+NnOQ0DIZpO 0EsxRUDT3otrRjd+US9z8kawJm98uAp03XcW/3frtiTRlkRU7PgSaxjXEGfwv6jk 0OqDMgVfjeeInW+RMpV1KIJFxoEpoLbABCihY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=YpC7CHK1WdNEkWO VMN+VedJSqOU=; b=lgNoPUPZF/M8ppDQqLB/1VUNlAdJiOxGYKiWth6fPCw9l6G AK8E/rScgR2WZ+aCtJcYWiK+krIQWCC26t0BTYoFDdD6CR2fNm8SJXPrhJJqE/gh 4NO3FnboCQOdVZcgB/l6bbo8lyLSn4mf0p6NHgzRLB6Qv4n//HTVXbMWUYrg= X-Sasl-enc: AshvgClHtMPopYGEyyNpUZ8Unl924egQI4Zo2T2rddXw 1474469200 Received: from [10.24.25.193] (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CECDF29D9 for ; Wed, 21 Sep 2016 10:46:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> Date: Wed, 21 Sep 2016 10:46:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org 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: Wed, 21 Sep 2016 14:46:45 -0000 This document looks in good shape to me. Few comments below. Couple of issues with normative language: =3D Section 9 =3D "This document therefore recommends relying on status information." I think this should either be written as a normative recommendation or = use a different word than "recommends." =3D Section 9.1 =3D "this document therefore recommends the use of OCSP in high-volume environments (HVE) for validating the freshness of certificates" I think this should be a normative recommendation. Nits: =3D Section 3 =3D delete "could serve as a subject as well" =3D Section 4 =3D I think the enumerated items would read more clearly if the name of each = item was followed by a colon rather than a period (e.g., " ... as well = as any special procedures required to dereference the URIs: ... "). =3D Section 9.2 =3D OLD why not reuse that mechanism, instead of creating a new service that requires additional round trips? NEW that mechanism can be reused instead of creating a new service that requires additional round trips. =3D Section 10 =3D s/to creae/to create/ > On Sep 10, 2016, at 12:02 PM, Russ Housley = wrote: >=20 >=20 > A revised document to address the issues raised in the first WG Last = Call > on this document was posted yesterday. > (https://www.ietf.org/id/draft-ietf-stir-certificates-08.txt). >=20 > This message starts a second two-week WG Last Call for this document, > which will end on 24 September 2016. >=20 > Please review the document and send comments on it to the STIR WG mail > list. Please clearly state your opinion as to whether the document is > ready for publication as a standards-track RFC. Remember that support > for publication is needed, so if you think the document is ready to go > forward, please say so. >=20 > Thanks, > Russ & Robert >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Sep 21 20:48:57 2016 Return-Path: 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 CFAC912BCA2 for ; Wed, 21 Sep 2016 20:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.016 X-Spam-Level: X-Spam-Status: No, score=-5.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 4PbLLud_5sos for ; Wed, 21 Sep 2016 20:48:53 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2907312BC52 for ; Wed, 21 Sep 2016 20:48:53 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id b130so124674576wmc.0 for ; Wed, 21 Sep 2016 20:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=1GhQzH4UdII/wXpdJSdwCsjyQDTzFaso2qxycSadJz4=; b=RULiRNIUJlB/Ab8QuS3UejqkyMC8+fXiEmpVpwxP+rMPLEVEjm+fYC17I6gLDdt8ik 11S1Zo0t95L1YrnU5NI/1svM75TcAAoH1P4Mq4jT7k1FLShRZFmKusfvm23+8o7+TkKo xv62o/QMKfLVi17gkyab9o7JvLwZ6z0Zg1nTkKtN4zzXzcBEoUie09gLzypAmF2bKu90 Yk8sR8oAQl6RSaa5BxBqpnqx9hz5Lc+TCaiOAQAbg9JdoM9taOsHO38ytUN350NALa3f Ij71mIvm6eZNqGhGoMc8HNA6AUWk7jzSyQKpPMiU8fL6ZlEjiDhhBbx1nVdRVuGtgNiJ k+7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1GhQzH4UdII/wXpdJSdwCsjyQDTzFaso2qxycSadJz4=; b=jO9V1TQEQKCssONZjA/UZESsy41Zje9gaeJKjF5irC33NNQ/0PbRLqfw9lSjRi6rB2 3kQB+nTPgF3rmQcHJNTgYLMs28FLPfr8GD6QwmeZgFrbugPNOLTcdjofpcKnJDwqeZ94 frBpmRcpVeClHvJSQAVbIRt2MMonXVM8bB0cxhP0fooehlf3RkXg6fCzcLyWm+OvQ8Sy P6pUaSrIJyIdfFPHoClQK7VePWmklwPBmW3OABPorekvJeiop1n3RYwB86DmeMeagsV3 H+vItDdctuk2Zg+Tuu9E33qUQ4bwatfwapq5oGf1IQO8DKBoGfTlQVNGO3ISAiGF6t3Z XuAQ== X-Gm-Message-State: AE9vXwNC6Vt/FjLamDWUakOK35Jqm9s6caJVDQirDgu75bCwKcG9ykOVHkxIyaP3fuz/v1UxL7DJBmGOVgGwBrOU X-Received: by 10.194.85.18 with SMTP id d18mr35441101wjz.43.1474516131151; Wed, 21 Sep 2016 20:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.29.137 with HTTP; Wed, 21 Sep 2016 20:48:50 -0700 (PDT) From: Anders Kristensen Date: Wed, 21 Sep 2016 20:48:50 -0700 Message-ID: To: stir@ietf.org Content-Type: multipart/alternative; boundary=089e0103e05c36d58d053d108a2b Archived-At: Subject: [stir] Minor comments on draft-ietf-stir-rfc4474bis-12 X-BeenThere: stir@ietf.org 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, 22 Sep 2016 03:48:56 -0000 --089e0103e05c36d58d053d108a2b Content-Type: text/plain; charset=UTF-8 4.1 says Third, the JSON key "x5u" MUST have a value equivalent to the quoted URI in the "info" parameter. I'm not sure exactly what equivalent means here. Maybe worth elaborating or adding a reference? Anyway, I don't think the URIs in the example in sec 5.1 would be considered equivalent: {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ passport.cer"} ... Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ info= Sec 6.2: s/that the that the/that the/ --089e0103e05c36d58d053d108a2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
4.1= says

      Third, the JSON key "x5u" MUST have a value =
equivalent to the
      quoted URI in the "info" parameter.

I'm not sure exactly what equivalent= means here. Maybe worth elaborating or adding a reference?

Anyway, I don't think the URIs in th= e example in sec 5.1 would be considered equivalent:

   {"alg=
":"ES256","typ":"passport","x5u&quo=
t;:"https://cert.example.org/
      passport.cer"}
...
<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0)">
   Identity: "rq3pjT=
1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
    lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \
    info=3D<https://bilo=
xi.example.org/biloxi.c>


Sec 6.2: s/= that the that the/that the/

=
--089e0103e05c36d58d053d108a2b-- From nobody Thu Sep 22 12:12:58 2016 Return-Path: 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 03F8F12BD08 for ; Thu, 22 Sep 2016 12:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 c7iNYXOKospq for ; Thu, 22 Sep 2016 12:12:54 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09FC12BCE4 for ; Thu, 22 Sep 2016 12:12:53 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.16.0.17/8.16.0.17) with SMTP id u8MJ46sQ014444; Thu, 22 Sep 2016 15:12:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar.biz; bh=B+3tWgB4+adqZYwC1VessMpMIY0ZVMRxLp4CfQAEVnw=; b=IQSIpPWQt2HPZH4nx1TnJBivT5tEAA6fyPm3L5KB4u179xK48PMaIiNU0b1QzyPCloKG /grHtW1+SBpY51v8s0p16D048orKfNuCGkbYTOxn0HveKiDi4vQZ1bUH+DauJEknNZ8Z 3DQ99i/UrLw97t6TdN/SxgsG6o+LAxGDCcNNOU9DyZf9U3zvzf7mf/A3vPjZnpCZ+3bi Ofk751gvAkvIaAFmSm+hP0G6gkB3g2nwZgvwwwmEhMe9gnTA/wwrQ6DfJez41ZsL0qpi OtmxaHtnIPG0gFjudfYqNOc6cIrPBGSTTCEl65Go/EHMy+aEH/qIDAdy+8KTY1Oy382C dw== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 25kabms7x9-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Sep 2016 15:12:50 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 22 Sep 2016 15:12:49 -0400 From: "Peterson, Jon" To: Alissa Cooper , Russ Housley Thread-Topic: [stir] Second WG Last Call for RFC4474bis Thread-Index: AQHSC3yUpcAXn9+uD0OZaEWmNt6JrqCDfpmAgAJCuwA= Date: Thu, 22 Sep 2016 19:12:49 +0000 Message-ID: References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> In-Reply-To: <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.74] Content-Type: text/plain; charset="us-ascii" Content-ID: <88D805BF2304E743A72A8B7F0B6FDDF9@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609220333 Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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, 22 Sep 2016 19:12:56 -0000 Thanks, we can get these cleaned up. A few notes below. Jon Peterson Neustar, Inc. On 9/20/16, 6:41 PM, "stir on behalf of Alissa Cooper" wrote: > >(1) >"Third, the JSON key "iat" MUST appear, set to the value of a > quoted encoding of the value of the SIP Date header field as a > JSON NumericDate (as UNIX time, per [RFC7519] Section 2)." > >I think this needs one more sentence to explain that while RFC 7519 >specifies that "iat" reflect the time the JWT was issued, there may be >cases where an authorization service mints a JWT on behalf of an endpoint >at some point later than what the SIP Date reflects. Given that the JWT >is being created on behalf of the user (and how and why "iat" is used by >4474bis implementations), using the SIP Date rather than the time at >which the JWT is actually created is acceptable. Okay, we can explain a bit - I think probably what the text needs to say is that the auth service should when adding "iat" inspect the Date and make sure it is within the freshness window before signing. Also, if for whatever reason the auth service wants to sign what it sees as the Date, rather than what the SIP header says is the Date, it is allowed to do so provided that it includes "canon". The text that supports this behavior is given in the verification service behavior (and in 12.1) but not really here. > >(2) >"Defining how a SIP implementation > would provision multiple originating or destination identities is > left as a subject for future specification." > >I'm assuming this meant to say that defining how a STIR implementation >deals with multiple identities is what is left for future specification. >Is that correct? If so, it would be helpful to clarify. Well, this means more aligning STIR with potential ways that SIP might signify that a request is "To" multiple destinations or "From" multiple parties, say. Even when PAI is present and is different from the From, there is still a general sense in personal communications that they are from some person (a persona even). We do have some vague notion that we want to work with meshed and centralized conferences, though, and don't want to close the door on that, which is why there's some forward-looking text about this here, and why the text is pretty broad. >(3) >"Also note that in some cases, the > "orig" and "dest" arrays might be populated with more than one value." > >The passport spec says that "orig" MUST only have one value. Should this >text align with that? Or is this meant to allow for future extensibility >of passport? This shows that we're not being entirely consistent in our future-proofing. I'd be willing to narrow this down to only one "orig" identity being allowed (and thus bring rfc4474bis into parity with PASSporT on this). Like I said, generally speaking personal communication are from like one person. >=3D Section 8.3 =3D > >(1) >"This will be the case, for > example, for nationally-specific service numbers (e.g. 911, 112); > however, the routing procedures associated with those numbers will > likely make sure that the verification service understands the > context of their use." > >I don't understand what is meant by the text after the semi-colon. Is the >point that the lack of canonicalization is ok because a verifier that is >asked to verify 112 will be designed to know that 112 is special? It means that routing procedures for service numbers are very unusual, and that the meaning of a service number is much more specific to its context than is an E.164 number. The process of successfully routing to 911 necessarily involves the hops (and any STIR intermediaries) being in a context where 911 will be understood. I can try to find a more helpful wording for that. >(2) >"If not, implementations SHOULD convert the number into E.164 format, > adding a country code if necessary; this may involve transforming > the number from a dial string (see [RFC3966]), removing any > national or international dialing prefixes or performing similar > procedures. ... > Other transformations during canonicalization MAY be made in > accordance with specific policies used within a local domain." > >Aren't all of the "other transformations" subsumed under the umbrella of >converting to E.164 format? I find it confusing to see these discussed as >two separate requirements. I think it's fine to point out that some >domains will need to take their own unique steps to eventually get their >numbers into E.164 format, but that doesn't imply that there is one set >of transformations that SHOULD happen and another set of transformations >that MAY happen, right? No, I think you're right. It is all effectively one set of transformations that we are RECOMMENDing: we can anticipate what some members of the set are, but not others. I'll reword accordingly. > >=3D Section 13.3 =3D > >Shouldn't the existing alg parameter have its reference updated to point >to this document? Sure, good point. Will fix the nits. Just one to comment on: > >=3D Section 6.2.1 =3D > >I think it would help to provide a little bit of rationale for this >recommendation: "As a guideline, this specification recommends that only >if a > verifier determines all Identity header fields within a message are > invalid should the request be considered to have an invalid identity." The idea here is that if you don't support a "ppt" or lack some private credential required to access one Identity header, that doesn't mean you still can't find another Identity header that you can understand and validate in the request, and that if you find at least one that looks valid, you can accept the identity it covers. Maybe it would help to rephrase this affirmatively that way, rather than describing the rainy day case. From nobody Thu Sep 22 12:16:59 2016 Return-Path: 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 DB5D612D611 for ; Thu, 22 Sep 2016 12:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AVpUEPU3B7uZ for ; Thu, 22 Sep 2016 12:16:54 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D90512D61F for ; Thu, 22 Sep 2016 12:16:54 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id t83so109382263oie.3 for ; Thu, 22 Sep 2016 12:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cdwd52xMOEsts33nPTq3Yie0Cs+8iOghkZXQ65+/Yes=; b=T3PUffv7VvzxmQJVnLF5VZ4hMcu1aa5sd0CO4s9YkZQZ1MVO3l1f4Uh0ig131f8Hjv 6JeRk5FX5WyeV9M5BOx6MJfV6QnHqaWcJGmWZna5a963UA3D7UWdR9CJASC/7NpHF6+B wvJaISd0l7lZtI49RmAUsrzMc5HkR6DJjJDZAkt86XvT0Vkyy9KYMDLBXPbQF9pw2b3S eIjUe/6OIuJUM3VzjYCxKPfeguDq01dLYMwzkmyrBz8YQRYjPLIu2OTGJ3hcLt2KASy9 xDIERfDcx3PTPuAxh5LR/idQ47ASDzVurJSDz7NaE1VQ1mb4NLGHwhwklln6JFEiyqNW Q81Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cdwd52xMOEsts33nPTq3Yie0Cs+8iOghkZXQ65+/Yes=; b=fijWkVBrZnS3MAndCNg7fv7sACgevA4cIfOXI27DeNLMjBdwhWV4dMQ1C6bJx3HHpC /RI3bHL4221g5cFizMkCVoBcL1GIQW1cYnmYHnHDdCkGuzKXZ9QCJl0CrbEuiCO/uv9p AGhusxr7LdNSd8YZkf1IEIueuthb2xz96sqZlnue9CWuoMwgWv4QWa3b1SXzUbcOjI75 NAYrxRLHZrMzPBOfU9IpIststwdcy1YjYs6W9BDPC8Z4lLRxjtDBS+biaYG0cJe0aIsV S4hSIcKLSHzzD4W8Hj9Pdxg9kplX4uAn7GcHVjlkfYyOkngaQg9g63Ph1mJo+8/Y/Zcx tTMg== X-Gm-Message-State: AE9vXwOZMGbzUlbfPvD773LYS/YhLl4T60xlaI+X+V7cPAp15qwPf4wdZv/sQGHvzf2quXsuG96c3vLterbWXw== X-Received: by 10.202.252.206 with SMTP id a197mr4807414oii.130.1474571813607; Thu, 22 Sep 2016 12:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.153 with HTTP; Thu, 22 Sep 2016 12:16:52 -0700 (PDT) In-Reply-To: <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> From: Mary Barnes Date: Thu, 22 Sep 2016 14:16:52 -0500 Message-ID: To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a113df21c255fe5053d1d819d Archived-At: Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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, 22 Sep 2016 19:16:58 -0000 --001a113df21c255fe5053d1d819d Content-Type: text/plain; charset=UTF-8 On Tue, Sep 20, 2016 at 8:41 PM, Alissa Cooper wrote: > I did my AD review of this document early to try to expedite the process. > > = General = > > Should this document obsolete RFC 4474? Apologies if this was discussed > and I'm failing to recall it. My answer would be yes I think, since new > implementations of RFC 4474 are discouraged and this document is > deprecating its syntax and its registries. > [MB] I made this comment a couple versions back and it hadn't yet been incorporated. I personally think it should be obsoletes as opposed to updates. [/MB] > > = Section 4.1 = > > (1) > "Third, the JSON key "iat" MUST appear, set to the value of a > quoted encoding of the value of the SIP Date header field as a > JSON NumericDate (as UNIX time, per [RFC7519] Section 2)." > > I think this needs one more sentence to explain that while RFC 7519 > specifies that "iat" reflect the time the JWT was issued, there may be > cases where an authorization service mints a JWT on behalf of an endpoint > at some point later than what the SIP Date reflects. Given that the JWT is > being created on behalf of the user (and how and why "iat" is used by > 4474bis implementations), using the SIP Date rather than the time at which > the JWT is actually created is acceptable. > > (2) > "Defining how a SIP implementation > would provision multiple originating or destination identities is > left as a subject for future specification." > > I'm assuming this meant to say that defining how a STIR implementation > deals with multiple identities is what is left for future specification. Is > that correct? If so, it would be helpful to clarify. > > (3) > "Also note that in some cases, the > "orig" and "dest" arrays might be populated with more than one value." > > The passport spec says that "orig" MUST only have one value. Should this > text align with that? Or is this meant to allow for future extensibility of > passport? > > = Section 8.3 = > > (1) > "This will be the case, for > example, for nationally-specific service numbers (e.g. 911, 112); > however, the routing procedures associated with those numbers will > likely make sure that the verification service understands the > context of their use." > > I don't understand what is meant by the text after the semi-colon. Is the > point that the lack of canonicalization is ok because a verifier that is > asked to verify 112 will be designed to know that 112 is special? > > (2) > "If not, implementations SHOULD convert the number into E.164 format, > adding a country code if necessary; this may involve transforming > the number from a dial string (see [RFC3966]), removing any > national or international dialing prefixes or performing similar > procedures. ... > Other transformations during canonicalization MAY be made in > accordance with specific policies used within a local domain." > > Aren't all of the "other transformations" subsumed under the umbrella of > converting to E.164 format? I find it confusing to see these discussed as > two separate requirements. I think it's fine to point out that some domains > will need to take their own unique steps to eventually get their numbers > into E.164 format, but that doesn't imply that there is one set of > transformations that SHOULD happen and another set of transformations that > MAY happen, right? > > = Section 13.3 = > > Shouldn't the existing alg parameter have its reference updated to point > to this document? > > > Nits: > > = Section 1 = > > A forward reference to Section 10 should be added to the last paragraph. > > = Section 2 = > > s/from an "identity field" a SIP request/from an "identity field" in a SIP > request/ > > = Section 4.1 = > > "the following elements message MUST be placed" -- I'm assuming "message" > is extraneous and should be deleted? > > s/key "typ" key/key "typ"/ > > s/from addr-spec of the From header/from the addr-spec component of the > From header/ > > OLD > This specification inherits > from the PASSporT specification one value for the 'alg' parameter: > 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 > digital signature. All implementations of this specification MUST > support the required signing algorithms of PASSporT. > > NEW > All implementations of this specification MUST support the required > signing algorithms of PASSporT. At present there is one > mandatory-to-support value for the 'alg' parameter: > 'ES256', as defined in [RFC7519], which connotes an ECDSA P-256 > digital signature. > > = Section 6.2.1 = > > I think it would help to provide a little bit of rationale for this > recommendation: "As a guideline, this specification recommends that only if > a > verifier determines all Identity header fields within a message are > invalid should the request be considered to have an invalid identity." > > = Section 6.2.2 = > > s/reason phase/reason phrase/ > > = Section 10 = > > OLD > it would likely fail the request due to the absence of an > Identity-Info header field with a 436 response code. > > NEW > it would likely fail the request with a 436 response code due to the > absence of an > Identity-Info header field. > > = Section 13.4 = > > I think this section should clearly instruct IANA to delete the registry. > > > Alissa > > > > On Sep 10, 2016, at 12:01 PM, Russ Housley wrote: > > > > > > A revised document to address the issues raised in the first WG Last Call > > on this document was posted yesterday. > > (https://www.ietf.org/id/draft-ietf-stir-rfc4474bis-12.txt). > > > > This message starts a second two-week WG Last Call for this document, > > which will end on 24 September 2016. > > > > Please review the document and send comments on it to the STIR WG mail > > list. Please clearly state your opinion as to whether the document is > > ready for publication as a standards-track RFC. Remember that support > > for publication is needed, so if you think the document is ready to go > > forward, please say so. > > > > Thanks, > > Russ & Robert > > > > > > _______________________________________________ > > stir mailing list > > stir@ietf.org > > https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > --001a113df21c255fe5053d1d819d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 20, 2016 at 8:41 PM, Alissa Cooper <alissa@cooperw.in> wrote:
I did my AD review of this docu= ment early to try to expedite the process.

=3D General =3D

Should this document obsolete RFC 4474? Apologies if this was discussed and= I'm failing to recall it. My answer would be yes I think, since new im= plementations of RFC 4474 are discouraged and this document is deprecating = its syntax and its registries.
[MB] I made this commen= t a couple versions back and it hadn't yet been incorporated.=C2=A0 I p= ersonally think it should be obsoletes as opposed to updates. =C2=A0[/MB]= =C2=A0

=3D Section 4.1 =3D

(1)
"Third, the JSON key "iat" MUST appear, set to the value of = a
=C2=A0 =C2=A0 =C2=A0 quoted encoding of the value of the SIP Date header fi= eld as a
=C2=A0 =C2=A0 =C2=A0 JSON NumericDate (as UNIX time, per [RFC7519] Section = 2)."

I think this needs one more sentence to explain that while RFC 7519 specifi= es that "iat" reflect the time the JWT was issued, there may be c= ases where an authorization service mints a JWT on behalf of an endpoint at= some point later than what the SIP Date reflects. Given that the JWT is be= ing created on behalf of the user (and how and why "iat" is used = by 4474bis implementations), using the SIP Date rather than the time at whi= ch the JWT is actually created is acceptable.

(2)
"Defining how a SIP implementation
=C2=A0 =C2=A0would provision multiple originating or destination identities= is
=C2=A0 =C2=A0left as a subject for future specification."

I'm assuming this meant to say that defining how a STIR implementation = deals with multiple identities is what is left for future specification. Is= that correct? If so, it would be helpful to clarify.

(3)
"Also note that in some cases, the
=C2=A0 =C2=A0"orig" and "dest" arrays might be populate= d with more than one value."

The passport spec says that "orig" MUST only have one value. Shou= ld this text align with that? Or is this meant to allow for future extensib= ility of passport?

=3D Section 8.3 =3D

(1)
"This will be the case, for
=C2=A0 =C2=A0 =C2=A0 example, for nationally-specific service numbers (e.g.= 911, 112);
=C2=A0 =C2=A0 =C2=A0 however, the routing procedures associated with those = numbers will
=C2=A0 =C2=A0 =C2=A0 likely make sure that the verification service underst= ands the
=C2=A0 =C2=A0 =C2=A0 context of their use."

I don't understand what is meant by the text after the semi-colon. Is t= he point that the lack of canonicalization is ok because a verifier that is= asked to verify 112 will be designed to know that 112 is special?

(2)
"If not, implementations SHOULD convert the number into E.164 format,<= br> =C2=A0 =C2=A0 =C2=A0 adding a country code if necessary; this may involve t= ransforming
=C2=A0 =C2=A0 =C2=A0 the number from a dial string (see [RFC3966]), removin= g any
=C2=A0 =C2=A0 =C2=A0 national or international dialing prefixes or performi= ng similar
=C2=A0 =C2=A0 =C2=A0 procedures.=C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 Other transformations during canonicalization MAY be m= ade in
=C2=A0 =C2=A0 =C2=A0 accordance with specific policies used within a local = domain."

Aren't all of the "other transformations" subsumed under the = umbrella of converting to E.164 format? I find it confusing to see these di= scussed as two separate requirements. I think it's fine to point out th= at some domains will need to take their own unique steps to eventually get = their numbers into E.164 format, but that doesn't imply that there is o= ne set of transformations that SHOULD happen and another set of transformat= ions that MAY happen, right?

=3D Section 13.3 =3D

Shouldn't the existing alg parameter have its reference updated to poin= t to this document?


Nits:

=3D Section 1 =3D

A forward reference to Section 10 should be added to the last paragraph.
=3D Section 2 =3D

s/from an "identity field" a SIP request/from an "identity f= ield" in a SIP request/

=3D Section 4.1 =3D

"the following elements message MUST be placed" -- I'm assumi= ng "message" is extraneous and should be deleted?

s/key "typ" key/key "typ"/

s/from addr-spec of the From header/from the addr-spec component of the Fro= m header/

OLD
This specification inherits
=C2=A0 =C2=A0from the PASSporT specification one value for the 'alg'= ; parameter:
=C2=A0 =C2=A0'ES256', as defined in [RFC7519], which connotes an EC= DSA P-256
=C2=A0 =C2=A0digital signature.=C2=A0 All implementations of this specifica= tion MUST
=C2=A0 =C2=A0support the required signing algorithms of PASSporT.

NEW
All implementations of this specification MUST support the required signing= algorithms of PASSporT. At present there is one mandatory-to-support value= for the 'alg' parameter:
=C2=A0 =C2=A0'ES256', as defined in [RFC7519], which connotes an EC= DSA P-256
=C2=A0 =C2=A0digital signature.

=3D Section 6.2.1 =3D

I think it would help to provide a little bit of rationale for this recomme= ndation: "As a guideline, this specification recommends that only if a=
=C2=A0 =C2=A0verifier determines all Identity header fields within a messag= e are
=C2=A0 =C2=A0invalid should the request be considered to have an invalid id= entity."

=3D Section 6.2.2 =3D

s/reason phase/reason phrase/

=3D Section 10 =3D

OLD
it would likely fail the request due to the absence of an
=C2=A0 =C2=A0Identity-Info header field with a 436 response code.

NEW
it would likely fail the request with a 436 response code due to the absenc= e of an
=C2=A0 =C2=A0Identity-Info header field.

=3D Section 13.4 =3D

I think this section should clearly instruct IANA to delete the registry.

Alissa


> On Sep 10, 2016, at 12:01 PM, Russ Housley <housley@vigilsec.com> wrote:
>
>
> A revised document to address the issues raised in the first WG Last C= all
> on this document was posted yesterday.
> (https://www.ietf.org/id/draft-ie= tf-stir-rfc4474bis-12.txt).
>
> This message starts a second two-week WG Last Call for this document,<= br> > which will end on 24 September 2016.
>
> Please review the document and send comments on it to the STIR WG mail=
> list.=C2=A0 Please clearly state your opinion as to whether the docume= nt is
> ready for publication as a standards-track RFC.=C2=A0 Remember that su= pport
> for publication is needed, so if you think the document is ready to go=
> forward, please say so.
>
> Thanks,
> Russ & Robert
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

--001a113df21c255fe5053d1d819d-- From nobody Thu Sep 22 12:35:45 2016 Return-Path: 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 BF1B312BA22 for ; Thu, 22 Sep 2016 12:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 1mwI4h9CQ8dd for ; Thu, 22 Sep 2016 12:35:42 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B233212BA1D for ; Thu, 22 Sep 2016 12:35:42 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8MJXm5F002949; Thu, 22 Sep 2016 15:35:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=Z1ZTDy9z5lFyt/tM3ec7nFAjlfFdyJ8YA1tGxyOU3iE=; b=u1URG8P6UX9eUTy2ggpmi0NMyHaJDxOCTpqLk3/959C16F5LyyRrnAstV2y7hrh13NHw izunBLwm4U6pU/52vTMdB3v1Nl8uCffm3SCdH77a6VyoHxwrNFzaEqH/8qk4qWm0sdCV oPP+MvOYae+d0tP2H/bCXq6upnQDd4Jl4JFvj6t+m+NX7s84oQLephDhx6gnwchRwEW1 roM4CJg0SL17jXLWSu3+Vv0jsSxx6Rla1FYkjqKdSWz23PqlXRh1tbpDYFku1kNj/L7Z QuFWSLUh+cEbCEZ0MIdD3mypJIglbZiJDnQ7SHqgf7RjAzG7ezDnvFZ9hpQ7t5o7mWOr 3A== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 25kabhrq33-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Sep 2016 15:35:39 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 22 Sep 2016 15:35:37 -0400 From: "Peterson, Jon" To: Mary Barnes , Alissa Cooper Thread-Topic: [stir] Second WG Last Call for RFC4474bis Thread-Index: AQHSC3yUpcAXn9+uD0OZaEWmNt6JrqCDfpmAgAK5OwD//4/ggA== Date: Thu, 22 Sep 2016 19:35:37 +0000 Message-ID: References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.74] Content-Type: multipart/alternative; boundary="_000_D4097CB71BA09Ajonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609220343 Archived-At: Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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, 22 Sep 2016 19:35:44 -0000 --_000_D4097CB71BA09Ajonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D General =3D Should this document obsolete RFC 4474? Apologies if this was discussed and= I'm failing to recall it. My answer would be yes I think, since new implem= entations of RFC 4474 are discouraged and this document is deprecating its = syntax and its registries. [MB] I made this comment a couple versions back and it hadn't yet been inco= rporated. I personally think it should be obsoletes as opposed to updates.= [/MB] Sorry, that is the plan, yes. Jon Peterson Neustar, Inc --_000_D4097CB71BA09Ajonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
=3D General =3D

Should this document obsolete RFC 4474? Apologies if this was discussed and= I'm failing to recall it. My answer would be yes I think, since new implem= entations of RFC 4474 are discouraged and this document is deprecating its = syntax and its registries.
[MB] I made this comment a couple versions back and it hadn't yet been= incorporated.  I personally think it should be obsoletes as opposed t= o updates.  [/MB]

Sorry, that is the plan, yes.

Jon Peterson
Neustar, Inc
 


--_000_D4097CB71BA09Ajonpetersonneustarbiz_-- From nobody Thu Sep 22 12:49:10 2016 Return-Path: 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 0C5BB12B219 for ; Thu, 22 Sep 2016 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 Stf0vGzxQ2by for ; Thu, 22 Sep 2016 12:49:07 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183B012B053 for ; Thu, 22 Sep 2016 12:49:07 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8MJYIBl022868 for ; Thu, 22 Sep 2016 15:49:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : content-type : mime-version; s=neustar.biz; bh=jKb0O6pxq5YoF37xqMOL9id/g+O1HgiFZ2dLUfqv/Oo=; b=Fqqh1DVysK9B8c1gXecYNw0KSeGg0/1Kzqt5DHfpnYAYcgOUWEJBX9lS1AWSnBJhC3JX DYoM9KNcpUtzcEAXOKJO5VJUJgMhSZUx/VL005KuLV4O2uc4hHihhI/0kgufEq1IUNjV 0y2kDMw3IuLoXXmZlCozJDi/rHAoh1y1lBbAE5PxVCtC/Qp1/2YP0D+SrOSvQunwaS0F V0nMSCogX7BCS7JaJCZyUaQAvwHkBIDylkdRAQa6eqr/kVdJIDsEvqvkQscL44zZMCIV t0MDHKkWIQrlZ1di+KNFEBTp2MV3VM7b8JeePqicWNlX9E2OQUcjjVVEjEHpBqWl6oYt mw== Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 25kabj9jkg-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Sep 2016 15:49:05 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 22 Sep 2016 15:49:05 -0400 From: "Peterson, Jon" To: IETF STIR Mail List Thread-Topic: a (proposed) syntax change Thread-Index: AQHSFQpfkuelPjClVkS0u+it8OBcXQ== Date: Thu, 22 Sep 2016 19:49:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.74] Content-Type: multipart/alternative; boundary="_000_D40983BD1BA0FAjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609220343 Archived-At: Subject: [stir] a (proposed) syntax change X-BeenThere: stir@ietf.org 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, 22 Sep 2016 19:49:09 -0000 --_000_D40983BD1BA0FAjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At this point in STIR's development, I am loathe to introduce any further c= hange to the rfc4474bis/PASSporT syntax and interaction. However, we hold e= vents like SIPit so we can learn from implementers what we need to fix, and= from that event, and surrounding discussion, we apparently still have some= qualms about "canon". To summarize the current situation briefly, a PASSporT object consistent of= three components: a JOSE header, a payload (containing the claims), and a = signature. In rfc4474bis-12, the Identity header begins with the signature = component, and optionally can include the header and payload in the "canon"= parameter. In order to form a full PASSporT object, a recipient of an Iden= tity header must therefore: a) when "canon" is present, concatenate the con= tents of "canon" and the signature at the beginning of the Identity header;= or b) when "canon" is not present, reconstruct the value of "canon" from t= he SIP request, and then concatenate that value with the signature at the b= eginning of the Identity header. We store the header and payload in "canon" for largely historical reasons: = "canon" was originally created as a parameter to store the optional canonic= alization of any originating or destination telephone number(s) in the requ= est, and when we migrated to PASSporT, we repurposed the parameter to store= the header and payload, as they contained a superset of that data. One cou= ld argue though that a better syntax for PASSporT would be to dispense with= "canon" and simply prepend the header and payload to the signature in the = Identity header when they are included in the request: this would effective= ly mean that the entire JWT object would appear in one place in the header,= rather than being broken in two the way it is in option (a) today. For opt= ion (b), then, we would need some way for the auth service to signify that = the header and claims are omitted: we could for example just put two leadin= g "."'s at the start of the header, the first representing the "." between = the header and payload, and the second the "." between the payload and the = signature. That would be in keeping with the spirit of RFC7515 Appendix F -= and let's face it, that section is heavy on spirit and light on letter. >From an rfc4474bis perspective, this is purely a syntactical change. It tra= des the six octets of "canon=3D" that we pay every time that the header and= payload are included in a request for the two octets of ".." that we would= pay under this proposal every time we did not include the header and paylo= ad in a request. For implementers, it shifts around the burden of who does = which concatenation operation a bit, but if any implementation out there wo= uld seriously be taxed by one additional concatenation operation, it probab= ly shouldn't be working with JSON or SIP at all. This proposal would also m= ove much of the specification of this over to the PASSporT document: that s= pecification would now define a "full" and "compact" mode for PASSporT, and= rfc4474bis would simply specify where you stick it and and when you need t= o use one or the other. But making this change would require substantial an= d pervasive changes in rfc4474bis, and significant additions to PASSporT as= well, which again at this late stage I am very hesitant to do for solely s= yntactical reasons. By the by, this issue is orthogonal to the question of when we recommend us= ing the full as opposed to compact form. This change would be neutral with = regard to that. This is simply a proposed change to the syntax. If anyone has any opinions about this, this would be the time to speak up. = When two syntax approaches are as similar as these, it can be very difficul= t to decide between them, because there simply aren't sufficient grounds to= prefer one over the other. From my perspective, the increase in clarity th= at comes from having the concept of a "full" and "compact" mode for PASSpor= T might be helpful for other using protocols as well as SIP, and it thus se= ems architecturally cleaner than having SIP define its own legacy-encumbere= d way to render PASSporT compact. The cost of this to rfc4474bis, though, w= ould be an onerous update that would require careful review before we proce= ed. It is difficult for me to justify any delay for the sake of tweaking th= e syntax. Jon Peterson Neustar, Inc. --_000_D40983BD1BA0FAjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <7612CA680F77084E84A8558B7DDC257F@neustar.biz> Content-Transfer-Encoding: quoted-printable

At this point in STIR's development, I am loathe to introduce any furt= her change to the rfc4474bis/PASSporT syntax and interaction. However, we h= old events like SIPit so we can learn from implementers what we need to fix= , and from that event, and surrounding discussion, we apparently still have some qualms about "canon".<= /div>

To summarize the current situation briefly, a PASSporT object consiste= nt of three components: a JOSE header, a payload (containing the claims), a= nd a signature. In rfc4474bis-12, the Identity header begins with the signa= ture component, and optionally can include the header and payload in the "canon" parameter. In orde= r to form a full PASSporT object, a recipient of an Identity header must th= erefore: a) when "canon" is present, concatenate the contents of = "canon" and the signature at the beginning of the Identity header; or b) when "canon" is not present, reconstruct the value= of "canon" from the SIP request, and then concatenate that value= with the signature at the beginning of the Identity header. 

We store the header and payload in "canon" for largely histo= rical reasons: "canon" was originally created as a parameter to s= tore the optional canonicalization of any originating or destination teleph= one number(s) in the request, and when we migrated to PASSporT, we repurposed the parameter to store the header and payload, as = they contained a superset of that data. One could argue though that a bette= r syntax for PASSporT would be to dispense with "canon" and simpl= y prepend the header and payload to the signature in the Identity header when they are included in the request: this would e= ffectively mean that the entire JWT object would appear in one place in the= header, rather than being broken in two the way it is in option (a) today.= For option (b), then, we would need some way for the auth service to signify that the header and claims a= re omitted: we could for example just put two leading "."'s at th= e start of the header, the first representing the "." between the= header and payload, and the second the "." between the payload and the signature. That would be in keeping with the spirit of= RFC7515 Appendix F - and let's face it, that section is heavy on spirit an= d light on letter. 

From an rfc4474bis perspective, this is purely a syntactical change. I= t trades the six octets of "canon=3D" that we pay every time that= the header and payload are included in a request for the two octets of &qu= ot;.." that we would pay under this proposal every time we did not include the header and payload in a request. For implement= ers, it shifts around the burden of who does which concatenation operation = a bit, but if any implementation out there would seriously be taxed by one = additional concatenation operation, it probably shouldn't be working with JSON or SIP at all. This proposal wo= uld also move much of the specification of this over to the PASSporT docume= nt: that specification would now define a "full" and "compac= t" mode for PASSporT, and rfc4474bis would simply specify where you stick it and and when you need to use one or the other. = But making this change would require substantial and pervasive changes in r= fc4474bis, and significant additions to PASSporT as well, which again at th= is late stage I am very hesitant to do for solely syntactical reasons.

By the by, this issue is orthogonal to the question of when we recomme= nd using the full as opposed to compact form. This change would be neutral = with regard to that. This is simply a proposed change to the syntax.

If anyone has any opinions about this, this would be the time to speak= up. When two syntax approaches are as similar as these, it can be very dif= ficult to decide between them, because there simply aren't sufficient groun= ds to prefer one over the other. From my perspective, the increase in clarity that comes from having the co= ncept of a "full" and "compact" mode for PASSporT might= be helpful for other using protocols as well as SIP, and it thus seems arc= hitecturally cleaner than having SIP define its own legacy-encumbered way to render PASSporT compact. The cost of this to rfc4= 474bis, though, would be an onerous update that would require careful revie= w before we proceed. It is difficult for me to justify any delay for the sa= ke of tweaking the syntax.

Jon Peterson
Neustar, Inc.
--_000_D40983BD1BA0FAjonpetersonneustarbiz_-- From nobody Thu Sep 22 12:53:27 2016 Return-Path: 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 3356512B2ED for ; Thu, 22 Sep 2016 12:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 l3h-_zp7vXNU for ; Thu, 22 Sep 2016 12:53:24 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8833812B2D5 for ; Thu, 22 Sep 2016 12:53:24 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8MJXnXB022808; Thu, 22 Sep 2016 15:53:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=neustar.biz; bh=W9Pi1v4wgYm9pPgJadjfsKIv44XI2dLsOSXC6j5g4vg=; b=feEJJPVedsq4ipMVnosAyJnW+MWTEakeVm3mblKVpIM0MiUZ7x0nsBDLKFaGo6pOf24q FBoQZ/egon2v/KUyN3ZW6dPWgpD9N8Q32alh7IrPGQb8fjnY0bgEgrTheeKVtuKvGpUH bbSgSzW28H8TkFUveFRv4nnYogsnIZLRLyC9UR/8MQSkuhsAvZI5txId68tTr+7XtrsG IaQT2fR433RblDatx4KK/+WA0XRGMh0Twxvq8ltpj4FUWsZysGU3OnAzrhWuBdjaviNa mUd/AFPr2KNAWz3xzm0EQz7nu/8v5OUyrAXNaIyqKpI4qTkaMP5Vx4m7b2O3n4lVz2k2 mg== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 25kabj9k8x-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Sep 2016 15:53:21 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Thu, 22 Sep 2016 15:53:21 -0400 From: "Peterson, Jon" To: Anders Kristensen , "stir@ietf.org" Thread-Topic: [stir] Minor comments on draft-ietf-stir-rfc4474bis-12 Thread-Index: AQHSFIRDwvv7iZx2s0ackheWr7ENo6CFupaA Date: Thu, 22 Sep 2016 19:53:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.74] Content-Type: multipart/alternative; boundary="_000_D40983F21BA0FCjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609220343 Archived-At: Subject: Re: [stir] Minor comments on draft-ietf-stir-rfc4474bis-12 X-BeenThere: stir@ietf.org 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, 22 Sep 2016 19:53:26 -0000 --_000_D40983F21BA0FCjonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are correct that the example URIs are conspicuously not at all the same= URI; we'll fix that. In this case the equivalence has to be strict, so ye= s we should be careful to specify what we mean here by equivalence. And we will zap that nit as well. Thanks! Jon Peterson Neustar, Inc. From: stir > on behalf = of Anders Kristensen > Date: Wednesday, September 21, 2016 at 8:48 PM To: "stir@ietf.org" > Subject: [stir] Minor comments on draft-ietf-stir-rfc4474bis-12 4.1 says Third, the JSON key "x5u" MUST have a value equivalent to the quoted URI in the "info" parameter. I'm not sure exactly what equivalent means here. Maybe worth elaborating or= adding a reference? Anyway, I don't think the URIs in the example in sec 5.1 would be considere= d equivalent: {"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/ passport.cer"} ... Identity: "rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \ lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \ info=3D Sec 6.2: s/that the that the/that the/ --_000_D40983F21BA0FCjonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <0E4FDB52CCBABB4B9CB8ED1A18EECF26@neustar.biz> Content-Transfer-Encoding: quoted-printable

You are correct that the example URIs are conspicuously not at all the= same URI; we'll fix that. In this case the equivalence has to be strict, &= nbsp;so yes we should be careful to specify what we mean here by equivalenc= e.

And we will zap that nit as well.

Thanks!

Jon Peterson
Neustar, Inc.

From: stir <stir-bounces@ietf.org> on behalf of Anders Kris= tensen <andersk@google.com>=
Date: Wednesday, September 21, 2016= at 8:48 PM
To: "stir@ietf.org" <stir@i= etf.org>
Subject: [stir] Minor comments on d= raft-ietf-stir-rfc4474bis-12

4.1 says

      Third, the JSON key "x5u"=
 MUST have a value equivalent to the
      quoted URI in the "info" parameter.

I'm not sure exactly= what equivalent means here. Maybe worth elaborating or adding a reference?=

Anyway, I don't thin= k the URIs in the example in sec 5.1 would be considered equivalent:

   {"alg":"ES256",&qu=
ot;typ":"passport","x5u":"https://cert.example.org/
      passport.cer"}
...
   Identity: "rq3pj=
T1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpj \
    lk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w"; \
    info=3D<https://bilo=
xi.example.org/biloxi.c>


Sec 6.2: s/that the that the/that the/

 --_000_D40983F21BA0FCjonpetersonneustarbiz_-- From nobody Fri Sep 23 05:29:27 2016 Return-Path: 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 B199E12B7B7 for ; Fri, 23 Sep 2016 05:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 NKJ8w5Hb_kd7 for ; Fri, 23 Sep 2016 05:29:23 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C9C12B7A1 for ; Fri, 23 Sep 2016 05:29:22 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 93so51496020qtg.2 for ; Fri, 23 Sep 2016 05:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=X6biHq6pxQPSASnrvypNDAWOXupNMeSRY12JRykyiaU=; b=IwUOTFem+/ewgH+IwqNLdHOHkmzM5K/iGTR0ch2XeebpgJU7T89JX72IRFxB+WsKMN gXp4zo4tM2ZKam59imkeQfQh4kKn8bjwRlCT8WBrpp+3+CgZd45UG9fGNRsiXAU/lOpB GRZhqO3rcgr+GT7G0rVFB1voPxKKzItSZJwet5r5wYe2oMOX9uGKG2h1xHth/AqSXVY3 +ayRVb5Da1Uh4OQBSxjdzp+Ab0daYa1Wh68aKHwYIoO0Ia9P0+O1qaYjJxkVuGX9BV5T wVMPml2jCu8QIpjd1P/qyYs5UEGsKqlZIzEaBzvnx7XxYRnPCvsCKzd/PNcQUGgE590V +zPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=X6biHq6pxQPSASnrvypNDAWOXupNMeSRY12JRykyiaU=; b=VojrjlvDNyZv2FawRc2FwHpjTlG+jYUPcejl6T/Ui1HBeoOOlB16Un8wzWKYttGVHm dHUyZFA1S9uUCCCBKM8jhQFKJQ6t0GEJ1CjxAyQQuQ+Z9KLahKEPYPeTh1uze3g5fp8v lM5H9GxAlKWB3DUZBnccXZytU2nHjTQciJnulsk8LDRPuzcNtkJR38U57rkawiHS9EPW sNqnXq/gdnfZCdS/sFxscpoSCPI483gcOwJGINVFCLGM3DLyKmYlAgSQ0TG+bFpkudH/ Z5iYMIky/s1VfDxTWdeF9RZgBn4xpmXTUxbLaI/e5ukuQ8Y/F/OOcFi6CcBq8ydpF5Dg jFMw== X-Gm-Message-State: AA6/9RlM8qIgSgPqCuW70eRj8nS4MZ1NDHtSCnVRH5fJUpInHOkcBFWbK2Tv7Tn3HvjOMQ== X-Received: by 10.200.39.29 with SMTP id g29mr7536565qtg.88.1474633762135; Fri, 23 Sep 2016 05:29:22 -0700 (PDT) Received: from [172.20.10.2] ([166.170.34.163]) by smtp.gmail.com with ESMTPSA id c44sm3692002qta.49.2016.09.23.05.29.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Sep 2016 05:29:21 -0700 (PDT) From: Chris Wendt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F3CCEC73-893C-4E29-A24B-9BA75359F139" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Fri, 23 Sep 2016 08:29:18 -0400 In-Reply-To: To: "Peterson, Jon" References: X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] a (proposed) syntax change X-BeenThere: stir@ietf.org 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: Fri, 23 Sep 2016 12:29:25 -0000 --Apple-Mail=_F3CCEC73-893C-4E29-A24B-9BA75359F139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jon, All, I do think this change has a few nice things about it: - removes the =E2=80=9Ccanon=E2=80=9D concept, which is not necessarily = complex or anything, but not as intuitive as the proposal Jon makes. = Consolidating the token into a single object right after identity: in = either compact or long form just makes things more straight forward and = avoids the need for concatenation, etc. - aligns better with the Appendix F that Christer brought up - saves a few bytes and parsing logic I think the general discussion that SIPit brought to a head with a few = of the implementers in the room, is why not do this, it just makes = sense. That said, we are also under pressure to get this out. So i=E2=80=99m favor in making this change but also want to make sure = this won=E2=80=99t alter timelines. Somehow i suspect that can=E2=80=99t = be strictly true, but maybe someone can prove me wrong. I am willing to make changes in the document quickly, i think Jon is = signing up for 4474bis changes quickly as well. But in any case, need some guidance, and in short order :) -Chris > On Sep 22, 2016, at 3:49 PM, Peterson, Jon = wrote: >=20 >=20 > At this point in STIR's development, I am loathe to introduce any = further change to the rfc4474bis/PASSporT syntax and interaction. = However, we hold events like SIPit so we can learn from implementers = what we need to fix, and from that event, and surrounding discussion, we = apparently still have some qualms about "canon". >=20 > To summarize the current situation briefly, a PASSporT object = consistent of three components: a JOSE header, a payload (containing the = claims), and a signature. In rfc4474bis-12, the Identity header begins = with the signature component, and optionally can include the header and = payload in the "canon" parameter. In order to form a full PASSporT = object, a recipient of an Identity header must therefore: a) when = "canon" is present, concatenate the contents of "canon" and the = signature at the beginning of the Identity header; or b) when "canon" is = not present, reconstruct the value of "canon" from the SIP request, and = then concatenate that value with the signature at the beginning of the = Identity header.=20 >=20 > We store the header and payload in "canon" for largely historical = reasons: "canon" was originally created as a parameter to store the = optional canonicalization of any originating or destination telephone = number(s) in the request, and when we migrated to PASSporT, we = repurposed the parameter to store the header and payload, as they = contained a superset of that data. One could argue though that a better = syntax for PASSporT would be to dispense with "canon" and simply prepend = the header and payload to the signature in the Identity header when they = are included in the request: this would effectively mean that the entire = JWT object would appear in one place in the header, rather than being = broken in two the way it is in option (a) today. For option (b), then, = we would need some way for the auth service to signify that the header = and claims are omitted: we could for example just put two leading "."'s = at the start of the header, the first representing the "." between the = header and payload, and the second the "." between the payload and the = signature. That would be in keeping with the spirit of RFC7515 Appendix = F - and let's face it, that section is heavy on spirit and light on = letter.=20 >=20 > =46rom an rfc4474bis perspective, this is purely a syntactical change. = It trades the six octets of "canon=3D" that we pay every time that the = header and payload are included in a request for the two octets of ".." = that we would pay under this proposal every time we did not include the = header and payload in a request. For implementers, it shifts around the = burden of who does which concatenation operation a bit, but if any = implementation out there would seriously be taxed by one additional = concatenation operation, it probably shouldn't be working with JSON or = SIP at all. This proposal would also move much of the specification of = this over to the PASSporT document: that specification would now define = a "full" and "compact" mode for PASSporT, and rfc4474bis would simply = specify where you stick it and and when you need to use one or the = other. But making this change would require substantial and pervasive = changes in rfc4474bis, and significant additions to PASSporT as well, = which again at this late stage I am very hesitant to do for solely = syntactical reasons. >=20 > By the by, this issue is orthogonal to the question of when we = recommend using the full as opposed to compact form. This change would = be neutral with regard to that. This is simply a proposed change to the = syntax. >=20 > If anyone has any opinions about this, this would be the time to speak = up. When two syntax approaches are as similar as these, it can be very = difficult to decide between them, because there simply aren't sufficient = grounds to prefer one over the other. =46rom my perspective, the = increase in clarity that comes from having the concept of a "full" and = "compact" mode for PASSporT might be helpful for other using protocols = as well as SIP, and it thus seems architecturally cleaner than having = SIP define its own legacy-encumbered way to render PASSporT compact. The = cost of this to rfc4474bis, though, would be an onerous update that = would require careful review before we proceed. It is difficult for me = to justify any delay for the sake of tweaking the syntax. >=20 > Jon Peterson > Neustar, Inc. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --Apple-Mail=_F3CCEC73-893C-4E29-A24B-9BA75359F139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Jon, All,

I do think this change has a few nice things about = it:

- removes = the =E2=80=9Ccanon=E2=80=9D concept, which is not necessarily complex or = anything, but not as intuitive as the proposal Jon makes. =  Consolidating the token into a single object right after identity: = in either compact or long form just makes things more straight forward = and avoids the need for concatenation, etc.
- = aligns better with the Appendix F that Christer brought up
- saves a few bytes and parsing logic

I think the general discussion that = SIPit brought to a head with a few of the implementers in the room, is = why not do this, it just makes sense.

That said, we are also under pressure = to get this out.

So i=E2=80=99m favor in making this change but also want to = make sure this won=E2=80=99t alter timelines.  Somehow i suspect = that can=E2=80=99t be strictly true, but maybe someone can prove me = wrong.

I am = willing to make changes in the document quickly, i think Jon is signing = up for 4474bis changes quickly as well.

But in any case, need some guidance, = and in short order :)

-Chris

On Sep 22, 2016, at 3:49 PM, = Peterson, Jon <jon.peterson@neustar.biz> wrote:


At this point in STIR's development, I am loathe to = introduce any further change to the rfc4474bis/PASSporT syntax and = interaction. However, we hold events like SIPit so we can learn from = implementers what we need to fix, and from that event, and surrounding discussion, we apparently still have some qualms about "canon".

To summarize the current situation briefly, a PASSporT = object consistent of three components: a JOSE header, a payload = (containing the claims), and a signature. In rfc4474bis-12, the Identity = header begins with the signature component, and optionally can include the header and payload in the "canon" parameter. In order to = form a full PASSporT object, a recipient of an Identity header must = therefore: a) when "canon" is present, concatenate the contents of = "canon" and the signature at the beginning of the Identity header; or b) when "canon" is not present, reconstruct the value of = "canon" from the SIP request, and then concatenate that value with the = signature at the beginning of the Identity header. 

We store the header and payload in "canon" for largely = historical reasons: "canon" was originally created as a parameter to = store the optional canonicalization of any originating or destination = telephone number(s) in the request, and when we migrated to PASSporT, we repurposed the parameter to store the header and payload, = as they contained a superset of that data. One could argue though that a = better syntax for PASSporT would be to dispense with "canon" and simply = prepend the header and payload to the signature in the Identity header when they are included in the request: this = would effectively mean that the entire JWT object would appear in one = place in the header, rather than being broken in two the way it is in = option (a) today. For option (b), then, we would need some way for the auth service to signify that the header and = claims are omitted: we could for example just put two leading "."'s at = the start of the header, the first representing the "." between the = header and payload, and the second the "." between the payload and the signature. That would be in keeping with the spirit = of RFC7515 Appendix F - and let's face it, that section is heavy on = spirit and light on letter. 

=46rom an rfc4474bis perspective, this is purely a = syntactical change. It trades the six octets of "canon=3D" that we pay = every time that the header and payload are included in a request for the = two octets of ".." that we would pay under this proposal every time we did not include the header and payload in a request. For = implementers, it shifts around the burden of who does which = concatenation operation a bit, but if any implementation out there would = seriously be taxed by one additional concatenation operation, it probably shouldn't be working with JSON or SIP at all. This proposal = would also move much of the specification of this over to the PASSporT = document: that specification would now define a "full" and "compact" = mode for PASSporT, and rfc4474bis would simply specify where you stick it and and when you need to use one or the = other. But making this change would require substantial and pervasive = changes in rfc4474bis, and significant additions to PASSporT as well, = which again at this late stage I am very hesitant to do for solely syntactical reasons.

By the by, this issue is orthogonal to the question of = when we recommend using the full as opposed to compact form. This change = would be neutral with regard to that. This is simply a proposed change = to the syntax.

If anyone has any opinions about this, this would be the = time to speak up. When two syntax approaches are as similar as these, it = can be very difficult to decide between them, because there simply = aren't sufficient grounds to prefer one over the other. =46rom my perspective, the increase in clarity that comes from having = the concept of a "full" and "compact" mode for PASSporT might be helpful = for other using protocols as well as SIP, and it thus seems = architecturally cleaner than having SIP define its own legacy-encumbered way to render PASSporT compact. The cost of this to = rfc4474bis, though, would be an onerous update that would require = careful review before we proceed. It is difficult for me to justify any = delay for the sake of tweaking the syntax.

Jon Peterson
Neustar, Inc.
_______________________________________________
stir = mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

= --Apple-Mail=_F3CCEC73-893C-4E29-A24B-9BA75359F139-- From nobody Fri Sep 23 06:16:48 2016 Return-Path: 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 25FD112B8AB for ; Fri, 23 Sep 2016 06:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YO0MF2ytl1Sf for ; Fri, 23 Sep 2016 06:16:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E7212B82D for ; Fri, 23 Sep 2016 06:16:44 -0700 (PDT) X-AuditID: c1b4fb25-14bff7000000793b-f8-57e52b3907d7 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 08.39.31035.93B25E75; Fri, 23 Sep 2016 15:16:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0301.000; Fri, 23 Sep 2016 15:16:41 +0200 From: Christer Holmberg To: Chris Wendt , "Peterson, Jon" Thread-Topic: [stir] a (proposed) syntax change Thread-Index: AQHSFQpfkuelPjClVkS0u+it8OBcXaCG4JkAgABBH4A= Date: Fri, 23 Sep 2016 13:16:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D40B038AFBF9christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7ga6V9tNwg2VdyhbTP+1mtjjTYGmx fO02Jgdmjwl9a1g9liz5yeSxo+E5cwBzFJdNSmpOZllqkb5dAlfGwkOzWApe5FZMXbWIsYHx Q1QXIyeHhICJxMP995m7GLk4hATWM0o8uvqBBcJZzCix9sVfti5GDg42AQuJ7n/aIA0iApES X/5sYgGxmQXUJV48esMOYgsL6El0P9vECFGjL/Fny19GkFYRASuJ9YccQcIsAqoSk45sYwWx eYHCbz7fAysXEsiTWPnhADOIzSngJPHu6zqwkYwCYhLfT61hglglLnHryXwmiJsFJJbsOc8M YYtKvHz8D2ymKNAJ37/OhoorSlydvhyqN17iy78eFoi9ghInZz5hmcAoOgvJ2FlIymYhKYOI G0i8PzefGcLWlli28DWUrS+x8ctZRgjbWmLTs0uMyGoWMHKsYhQtTi1Oyk03MtZLLcpMLi7O z9PLSy3ZxAiMy4NbfqvuYLz8xvEQowAHoxIP74PHj8OFWBPLiitzDzFKcDArifCqazwNF+JN SaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNTqoFR7P6LJLvTThNm 6R/e8ni33fVUDpPi65wrJ/lOsTVKOcXgxFa86AzDXPMTIfcCNz0zOqiXufTOi1PJ1p+emexM Z1E75tzY27vuQ3wmSyLv1U6n7OuxT82mhvzmV/qzyrLg337J+CUyEgZVWyXXrbtVPONeVZDv T5NHH/MP7S1ZdMqyrS9m+dI3SizFGYmGWsxFxYkAkLTlfMcCAAA= Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] a (proposed) syntax change X-BeenThere: stir@ietf.org 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: Fri, 23 Sep 2016 13:16:47 -0000 --_000_D40B038AFBF9christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >I do think this change has a few nice things about it: > >- removes the =93canon=94 concept, which is not necessarily complex or any= thing, but not as intuitive as the proposal Jon makes. Consolidating the t= oken into a single object right after identity: in either compact or long f= orm just makes things more straight forward and avoids the need for concate= nation, etc. >- aligns better with the Appendix F that Christer brought up It actually aligns with JWS in general, with or without Appendix F, because= we can include the base64 encoded JWS string directly (without splitting i= t into two different pieces). I indicated in Berlin that I can live with =93canon=94. But, as people are = now asked to give their opinion, my preference no =93canon=94 and use Jon= =92s =93dot suggestion=94 for omitting headers and/or claims. However, I wi= ll not object to =93canon=94 if the community wants to go that way. Regards, Christer On Sep 22, 2016, at 3:49 PM, Peterson, Jon > wrote: At this point in STIR's development, I am loathe to introduce any further c= hange to the rfc4474bis/PASSporT syntax and interaction. However, we hold e= vents like SIPit so we can learn from implementers what we need to fix, and= from that event, and surrounding discussion, we apparently still have some= qualms about "canon". To summarize the current situation briefly, a PASSporT object consistent of= three components: a JOSE header, a payload (containing the claims), and a = signature. In rfc4474bis-12, the Identity header begins with the signature = component, and optionally can include the header and payload in the "canon"= parameter. In order to form a full PASSporT object, a recipient of an Iden= tity header must therefore: a) when "canon" is present, concatenate the con= tents of "canon" and the signature at the beginning of the Identity header;= or b) when "canon" is not present, reconstruct the value of "canon" from t= he SIP request, and then concatenate that value with the signature at the b= eginning of the Identity header. We store the header and payload in "canon" for largely historical reasons: = "canon" was originally created as a parameter to store the optional canonic= alization of any originating or destination telephone number(s) in the requ= est, and when we migrated to PASSporT, we repurposed the parameter to store= the header and payload, as they contained a superset of that data. One cou= ld argue though that a better syntax for PASSporT would be to dispense with= "canon" and simply prepend the header and payload to the signature in the = Identity header when they are included in the request: this would effective= ly mean that the entire JWT object would appear in one place in the header,= rather than being broken in two the way it is in option (a) today. For opt= ion (b), then, we would need some way for the auth service to signify that = the header and claims are omitted: we could for example just put two leadin= g "."'s at the start of the header, the first representing the "." between = the header and payload, and the second the "." between the payload and the = signature. That would be in keeping with the spirit of RFC7515 Appendix F -= and let's face it, that section is heavy on spirit and light on letter. >From an rfc4474bis perspective, this is purely a syntactical change. It tra= des the six octets of "canon=3D" that we pay every time that the header and= payload are included in a request for the two octets of ".." that we would= pay under this proposal every time we did not include the header and paylo= ad in a request. For implementers, it shifts around the burden of who does = which concatenation operation a bit, but if any implementation out there wo= uld seriously be taxed by one additional concatenation operation, it probab= ly shouldn't be working with JSON or SIP at all. This proposal would also m= ove much of the specification of this over to the PASSporT document: that s= pecification would now define a "full" and "compact" mode for PASSporT, and= rfc4474bis would simply specify where you stick it and and when you need t= o use one or the other. But making this change would require substantial an= d pervasive changes in rfc4474bis, and significant additions to PASSporT as= well, which again at this late stage I am very hesitant to do for solely s= yntactical reasons. By the by, this issue is orthogonal to the question of when we recommend us= ing the full as opposed to compact form. This change would be neutral with = regard to that. This is simply a proposed change to the syntax. If anyone has any opinions about this, this would be the time to speak up. = When two syntax approaches are as similar as these, it can be very difficul= t to decide between them, because there simply aren't sufficient grounds to= prefer one over the other. From my perspective, the increase in clarity th= at comes from having the concept of a "full" and "compact" mode for PASSpor= T might be helpful for other using protocols as well as SIP, and it thus se= ems architecturally cleaner than having SIP define its own legacy-encumbere= d way to render PASSporT compact. The cost of this to rfc4474bis, though, w= ould be an onerous update that would require careful review before we proce= ed. It is difficult for me to justify any delay for the sake of tweaking th= e syntax. Jon Peterson Neustar, Inc. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_D40B038AFBF9christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2FCDCCA54285AC4F8DE751D4C700DF42@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>I do think this change has a few nice things about it:<= /div>
>
>- removes the =93canon=94 concept, which is not necessa= rily complex or anything, but not as intuitive as the proposal Jon makes. &= nbsp;Consolidating the token into a single object right after identity: in = either compact or long form just makes things more straight forward and avoids the need for concatenation, etc.
>- aligns better with the Appendix F that Christer broug= ht up

It actually aligns with JWS in general, with or without Appendix F, be= cause we can include the base64 encoded JWS string directly (without splitt= ing it into two different pieces).

I indicated in Berlin that I can live with =93canon=94. But, as people= are now asked to give their opinion, my preference no =93canon=94 and use = Jon=92s =93dot suggestion=94 for omitting headers and/or claims. However, I= will not object to =93canon=94 if the community wants to go that way.

Regards,

Christer
 

On Sep 22, 2016, at 3:49 PM, Peterson, Jon <jon.peterson@neustar.biz>= wrote:


At this point in STIR's development, I am loathe to introdu= ce any further change to the rfc4474bis/PASSporT syntax and interaction. Ho= wever, we hold events like SIPit so we can learn from implementers what we = need to fix, and from that event, and surrounding discussion, we apparently still have some qualms about &qu= ot;canon".

To summarize the current situation briefly, a PASSporT obje= ct consistent of three components: a JOSE header, a payload (containing the= claims), and a signature. In rfc4474bis-12, the Identity header begins wit= h the signature component, and optionally can include the header and payload in the "canon" parameter. In = order to form a full PASSporT object, a recipient of an Identity header mus= t therefore: a) when "canon" is present, concatenate the contents= of "canon" and the signature at the beginning of the Identity header; or b) when "canon" is not present, reconstruct = the value of "canon" from the SIP request, and then concatenate t= hat value with the signature at the beginning of the Identity header. =

We store the header and payload in "canon" for la= rgely historical reasons: "canon" was originally created as a par= ameter to store the optional canonicalization of any originating or destina= tion telephone number(s) in the request, and when we migrated to PASSporT, we repurposed the parameter to store the header and payload, = as they contained a superset of that data. One could argue though that a be= tter syntax for PASSporT would be to dispense with "canon" and si= mply prepend the header and payload to the signature in the Identity header when they are included in the request: th= is would effectively mean that the entire JWT object would appear in one pl= ace in the header, rather than being broken in two the way it is in option = (a) today. For option (b), then, we would need some way for the auth service to signify that the header and= claims are omitted: we could for example just put two leading "."= ;'s at the start of the header, the first representing the "." be= tween the header and payload, and the second the "." between the payload and the signature. That would be in keeping with the s= pirit of RFC7515 Appendix F - and let's face it, that section is heavy on s= pirit and light on letter. 

From an rfc4474bis perspective, this is purely a syntactica= l change. It trades the six octets of "canon=3D" that we pay ever= y time that the header and payload are included in a request for the two oc= tets of ".." that we would pay under this proposal every time we did not include the header and payload in a request. For imp= lementers, it shifts around the burden of who does which concatenation oper= ation a bit, but if any implementation out there would seriously be taxed b= y one additional concatenation operation, it probably shouldn't be working with JSON or SIP at all. This proposal wo= uld also move much of the specification of this over to the PASSporT docume= nt: that specification would now define a "full" and "compac= t" mode for PASSporT, and rfc4474bis would simply specify where you stick it and and when you need to use one or the other. = But making this change would require substantial and pervasive changes in r= fc4474bis, and significant additions to PASSporT as well, which again at th= is late stage I am very hesitant to do for solely syntactical reasons.

By the by, this issue is orthogonal to the question of when= we recommend using the full as opposed to compact form. This change would = be neutral with regard to that. This is simply a proposed change to the syn= tax.

If anyone has any opinions about this, this would be the ti= me to speak up. When two syntax approaches are as similar as these, it can = be very difficult to decide between them, because there simply aren't suffi= cient grounds to prefer one over the other. From my perspective, the increase in clarity that comes from having= the concept of a "full" and "compact" mode for PASSpor= T might be helpful for other using protocols as well as SIP, and it thus se= ems architecturally cleaner than having SIP define its own legacy-encumbered way to render PASSporT compact. The cost of this to = rfc4474bis, though, would be an onerous update that would require careful r= eview before we proceed. It is difficult for me to justify any delay for th= e sake of tweaking the syntax.

Jon Peterson
Neustar, Inc.
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir

 --_000_D40B038AFBF9christerholmbergericssoncom_-- From nobody Fri Sep 23 10:44:19 2016 Return-Path: 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 1F28712BAF7 for ; Fri, 23 Sep 2016 10:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zscwX3nkT2K8 for ; Fri, 23 Sep 2016 10:44:15 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51C212B549 for ; Fri, 23 Sep 2016 10:44:15 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id t83so142593637oie.3 for ; Fri, 23 Sep 2016 10:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BLRDyXwCDE531aiIx8tWR9hWEEC3FuxterSy+npJ8S8=; b=PY3tfRMPXWEgf51yJ2LEoS2enolt4cvXP7/dSyRrieNZeIjubSDbCToSQks6NH9kQ/ AZmgHLpbTcn4axqYhgsu9JYr3c6xR4AiDy51hxsKjhXqP1tTFdwxJ7/13SRRHIQjumTw l3S9eWHc+7YN83NjF0FeWmIIsnujX+ZpUoQRQeYmj7gC0FhlaWrrY+VqW4LeVSVpwFnV DgfLB7IR/UsTW+JfhPG6tXw+m/C3LM0WXnQmxAl5DQag23lp1lI0VZvgygOdHeK+Lh0o DMBoFk5j0SGu4KR4w3bcA6VkW1O28fhgkxJ69o+NeebcmUJSvjct87/2o6FPp0icsTSk OxHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BLRDyXwCDE531aiIx8tWR9hWEEC3FuxterSy+npJ8S8=; b=CbIk7t6svLMeX0kIESeHRRleieTmdWif8W7OfoHmLHxgHYJNl1E2x0rwsSMmEx+vAZ iOWW/XtnjMz+8wvSifWpO4dCMeqF3Ipzmi1xOUt1y1J0FbDaIwzh5qvBJZwrG7B8NfjE qb6vgKC8F40lQ2HZjxKnfr+ASTrGdie34VWRuR9Ukreq5yL45bgU7urBXHmnBE83pyOQ LGODq+sJp3061R3LM0RUTuzH3CntOnUCQ6FUbeikkl5RlqK6c0iwDkva2aJTegGu5tas k8DhFHr26QYAm5VS5qnBY8HfGaIAKQU+Ll6TXvJpuSceGLX/6z5OARiRgMrA8zA6MXVC FQog== X-Gm-Message-State: AE9vXwMSPCMVZekMnBMe2sGHlm8IRw63WLLtdh/GwjC3pfWhHyTRVTvF17XshNk2jJd9nYEiwJTvCjJXhBkQ7g== X-Received: by 10.202.236.195 with SMTP id k186mr12194984oih.122.1474652655114; Fri, 23 Sep 2016 10:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.153 with HTTP; Fri, 23 Sep 2016 10:44:14 -0700 (PDT) In-Reply-To: References: From: Mary Barnes Date: Fri, 23 Sep 2016 12:44:14 -0500 Message-ID: To: Chris Wendt Content-Type: multipart/alternative; boundary=001a1137c0f2acdcf4053d305319 Archived-At: Cc: IETF STIR Mail List , "Peterson, Jon" Subject: Re: [stir] a (proposed) syntax change X-BeenThere: stir@ietf.org 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: Fri, 23 Sep 2016 17:44:18 -0000 --001a1137c0f2acdcf4053d305319 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon, I totally understand your concern about making the change this late in the game. But, I think Chris made some really good points and now is the time to do it, otherwise, I can envision years of repeated discussion around this as new people come along. Hopefully, we're talking about a few weeks delay which is tolerable I think for a WG that just had it's 3rd birthday. Regards, Mary. On Fri, Sep 23, 2016 at 7:29 AM, Chris Wendt wrote: > Hi Jon, All, > > I do think this change has a few nice things about it: > > - removes the =E2=80=9Ccanon=E2=80=9D concept, which is not necessarily c= omplex or > anything, but not as intuitive as the proposal Jon makes. Consolidating > the token into a single object right after identity: in either compact or > long form just makes things more straight forward and avoids the need for > concatenation, etc. > - aligns better with the Appendix F that Christer brought up > - saves a few bytes and parsing logic > > I think the general discussion that SIPit brought to a head with a few of > the implementers in the room, is why not do this, it just makes sense. > > That said, we are also under pressure to get this out. > > So i=E2=80=99m favor in making this change but also want to make sure thi= s won=E2=80=99t > alter timelines. Somehow i suspect that can=E2=80=99t be strictly true, = but maybe > someone can prove me wrong. > > I am willing to make changes in the document quickly, i think Jon is > signing up for 4474bis changes quickly as well. > > But in any case, need some guidance, and in short order :) > > -Chris > > On Sep 22, 2016, at 3:49 PM, Peterson, Jon > wrote: > > > At this point in STIR's development, I am loathe to introduce any further > change to the rfc4474bis/PASSporT syntax and interaction. However, we hol= d > events like SIPit so we can learn from implementers what we need to fix, > and from that event, and surrounding discussion, we apparently still have > some qualms about "canon". > > To summarize the current situation briefly, a PASSporT object consistent > of three components: a JOSE header, a payload (containing the claims), an= d > a signature. In rfc4474bis-12, the Identity header begins with the > signature component, and optionally can include the header and payload in > the "canon" parameter. In order to form a full PASSporT object, a recipie= nt > of an Identity header must therefore: a) when "canon" is present, > concatenate the contents of "canon" and the signature at the beginning of > the Identity header; or b) when "canon" is not present, reconstruct the > value of "canon" from the SIP request, and then concatenate that value wi= th > the signature at the beginning of the Identity header. > > We store the header and payload in "canon" for largely historical reasons= : > "canon" was originally created as a parameter to store the optional > canonicalization of any originating or destination telephone number(s) in > the request, and when we migrated to PASSporT, we repurposed the paramete= r > to store the header and payload, as they contained a superset of that dat= a. > One could argue though that a better syntax for PASSporT would be to > dispense with "canon" and simply prepend the header and payload to the > signature in the Identity header when they are included in the request: > this would effectively mean that the entire JWT object would appear in on= e > place in the header, rather than being broken in two the way it is in > option (a) today. For option (b), then, we would need some way for the au= th > service to signify that the header and claims are omitted: we could for > example just put two leading "."'s at the start of the header, the first > representing the "." between the header and payload, and the second the "= ." > between the payload and the signature. That would be in keeping with the > spirit of RFC7515 Appendix F - and let's face it, that section is heavy o= n > spirit and light on letter. > > From an rfc4474bis perspective, this is purely a syntactical change. It > trades the six octets of "canon=3D" that we pay every time that the heade= r > and payload are included in a request for the two octets of ".." that we > would pay under this proposal every time we did not include the header an= d > payload in a request. For implementers, it shifts around the burden of wh= o > does which concatenation operation a bit, but if any implementation out > there would seriously be taxed by one additional concatenation operation, > it probably shouldn't be working with JSON or SIP at all. This proposal > would also move much of the specification of this over to the PASSporT > document: that specification would now define a "full" and "compact" mode > for PASSporT, and rfc4474bis would simply specify where you stick it and > and when you need to use one or the other. But making this change would > require substantial and pervasive changes in rfc4474bis, and significant > additions to PASSporT as well, which again at this late stage I am very > hesitant to do for solely syntactical reasons. > > By the by, this issue is orthogonal to the question of when we recommend > using the full as opposed to compact form. This change would be neutral > with regard to that. This is simply a proposed change to the syntax. > > If anyone has any opinions about this, this would be the time to speak up= . > When two syntax approaches are as similar as these, it can be very > difficult to decide between them, because there simply aren't sufficient > grounds to prefer one over the other. From my perspective, the increase i= n > clarity that comes from having the concept of a "full" and "compact" mode > for PASSporT might be helpful for other using protocols as well as SIP, a= nd > it thus seems architecturally cleaner than having SIP define its own > legacy-encumbered way to render PASSporT compact. The cost of this to > rfc4474bis, though, would be an onerous update that would require careful > review before we proceed. It is difficult for me to justify any delay for > the sake of tweaking the syntax. > > Jon Peterson > Neustar, Inc. > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --001a1137c0f2acdcf4053d305319 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jon,

I totally understand your concern = about making the change this late in the game.=C2=A0 But, I think Chris mad= e some really good points and now is the time to do it, otherwise, I can en= vision years of repeated discussion around this as new people come along. = =C2=A0 Hopefully, we're talking about a few weeks delay which is tolera= ble I think for a WG that just had it's 3rd birthday. =C2=A0=C2=A0

Regards,
Mary.=C2=A0

On Fri, Sep 23, 2016 at 7= :29 AM, Chris Wendt <chris-ietf@chriswendt.net> wrot= e:
Hi= Jon, All,

I do think this change has a few nice things = about it:

- removes the =E2=80=9Ccanon=E2=80=9D co= ncept, which is not necessarily complex or anything, but not as intuitive a= s the proposal Jon makes.=C2=A0 Consolidating the token into a single objec= t right after identity: in either compact or long form just makes things mo= re straight forward and avoids the need for concatenation, etc.
-= aligns better with the Appendix F that Christer brought up
- sav= es a few bytes and parsing logic

I think the gener= al discussion that SIPit brought to a head with a few of the implementers i= n the room, is why not do this, it just makes sense.

That said, we are also under pressure to get this out.

So i=E2=80=99m favor in making this change but also want to make su= re this won=E2=80=99t alter timelines.=C2=A0 Somehow i suspect that can=E2= =80=99t be strictly true, but maybe someone can prove me wrong.
<= br>
I am willing to make changes in the document quickly, i think= Jon is signing up for 4474bis changes quickly as well.

But in any case, need some guidance, and in short order :)
=
-Chris

On Sep 22, 2016, at 3:49 PM, Peterson, Jon <jon.peterson@neustar= .biz> wrote:


At this point in STIR's development, I am loathe to introduce any = further change to the rfc4474bis/PASSporT syntax and interaction. However, = we hold events like SIPit so we can learn from implementers what we need to= fix, and from that event, and surrounding discussion, we apparently still have some qualms about "canon".<= /div>

To summarize the current situation briefly, a PASSporT object consiste= nt of three components: a JOSE header, a payload (containing the claims), a= nd a signature. In rfc4474bis-12, the Identity header begins with the signa= ture component, and optionally can include the header and payload in the "canon" parameter. In orde= r to form a full PASSporT object, a recipient of an Identity header must th= erefore: a) when "canon" is present, concatenate the contents of = "canon" and the signature at the beginning of the Identity header; or b) when "canon" is not present, reconstruct the value= of "canon" from the SIP request, and then concatenate that value= with the signature at the beginning of the Identity header.=C2=A0

We store the header and payload in "canon" for largely histo= rical reasons: "canon" was originally created as a parameter to s= tore the optional canonicalization of any originating or destination teleph= one number(s) in the request, and when we migrated to PASSporT, we repurposed the parameter to store the header and payload, as = they contained a superset of that data. One could argue though that a bette= r syntax for PASSporT would be to dispense with "canon" and simpl= y prepend the header and payload to the signature in the Identity header when they are included in the request: this would e= ffectively mean that the entire JWT object would appear in one place in the= header, rather than being broken in two the way it is in option (a) today.= For option (b), then, we would need some way for the auth service to signify that the header and claims a= re omitted: we could for example just put two leading "."'s a= t the start of the header, the first representing the "." between= the header and payload, and the second the "." between the payload and the signature. That would be in keeping with the spirit of= RFC7515 Appendix F - and let's face it, that section is heavy on spiri= t and light on letter.=C2=A0

From an rfc4474bis perspective, this is purely a syntactical change. I= t trades the six octets of "canon=3D" that we pay every time that= the header and payload are included in a request for the two octets of &qu= ot;.." that we would pay under this proposal every time we did not include the header and payload in a request. For implement= ers, it shifts around the burden of who does which concatenation operation = a bit, but if any implementation out there would seriously be taxed by one = additional concatenation operation, it probably shouldn't be working with JSON or SIP at all. This proposa= l would also move much of the specification of this over to the PASSporT do= cument: that specification would now define a "full" and "co= mpact" mode for PASSporT, and rfc4474bis would simply specify where you stick it and and when you need to use one or the other. = But making this change would require substantial and pervasive changes in r= fc4474bis, and significant additions to PASSporT as well, which again at th= is late stage I am very hesitant to do for solely syntactical reasons.

By the by, this issue is orthogonal to the question of when we recomme= nd using the full as opposed to compact form. This change would be neutral = with regard to that. This is simply a proposed change to the syntax.

If anyone has any opinions about this, this would be the time to speak= up. When two syntax approaches are as similar as these, it can be very dif= ficult to decide between them, because there simply aren't sufficient g= rounds to prefer one over the other. From my perspective, the increase in clarity that comes from having the co= ncept of a "full" and "compact" mode for PASSporT might= be helpful for other using protocols as well as SIP, and it thus seems arc= hitecturally cleaner than having SIP define its own legacy-encumbered way to render PASSporT compact. The cost of this to rfc4= 474bis, though, would be an onerous update that would require careful revie= w before we proceed. It is difficult for me to justify any delay for the sa= ke of tweaking the syntax.

Jon Peterson
Neustar, Inc.
_______________________________________________
stir mailing liststir@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/stir" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/stir


_______________________________________________<= br> stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


--001a1137c0f2acdcf4053d305319-- From nobody Fri Sep 23 11:03:17 2016 Return-Path: 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 27C8F12B1D8 for ; Fri, 23 Sep 2016 11:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 gZvpOWnQe3fk for ; Fri, 23 Sep 2016 11:03:11 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 1D1F612B103 for ; Fri, 23 Sep 2016 11:03:11 -0700 (PDT) Received: (qmail 7863 invoked by uid 0); 23 Sep 2016 18:03:09 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 23 Sep 2016 18:03:09 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id n5y61t00S1MNPNq015y98T; Fri, 23 Sep 2016 11:58:09 -0600 X-Authority-Analysis: v=2.1 cv=aaryw3Yt c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=GW1xBdLrtEIA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=w1VtefKfAAAA:8 a=hGBaWAWWAAAA:8 a=-zdwuFqnnyKg7-s93BsA:9 a=Hy7e4GvB067Dr_et:21 a=44xcRwPKI35DSnpF:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=j5dtb1cgqWTQW4gr:21 a=T4Ba3gdG_XUwY3_R:21 a=FPsSEKN3YtqAMBD2:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=xm8PXHvXF9WL09pmvKgj:22 a=Q-ofuW86YyylptHqTH-7:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date; bh=LRFiF1ZC7yQgxtsmwnuMpJgYs/UPWysQQxcKPtRusL0=; b=bmJX dN+/unbr3jyxf3U6NkCZzatALo6uUToIWEskW1HrkWF0j837LfyW12OUSCSCnxD5uj3HIElEhjPfY 5eiLwl8V+HhumJ5ZYOJo1qqktxeQTVKjQWAqa7xPJtsh7En; Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:58465 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1bnUje-0000Wc-6h; Fri, 23 Sep 2016 11:58:06 -0600 User-Agent: Microsoft-MacOutlook/f.1a.1.160916 Date: Fri, 23 Sep 2016 13:58:04 -0400 From: Richard Shockey To: Mary Barnes , Chris Wendt Message-ID: <4D891F36-EFDB-47C7-AAB0-39579E3B14E8@shockey.us> Thread-Topic: [stir] a (proposed) syntax change References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3557483886_1836946105" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.40.228 X-Exim-ID: 1bnUje-0000Wc-6h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:58465 X-Source-Auth: richard+shockey.us X-Email-Count: 7 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF STIR Mail List , "Peterson, Jon" Subject: Re: [stir] a (proposed) syntax change X-BeenThere: stir@ietf.org 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: Fri, 23 Sep 2016 18:03:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3557483886_1836946105 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 +1=C2=A0 Lets do it now.=20 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 =20 From: stir on behalf of Mary Barnes Date: Friday, September 23, 2016 at 1:44 PM To: Chris Wendt Cc: IETF STIR Mail List , "Peterson, Jon" Subject: Re: [stir] a (proposed) syntax change =20 Jon, =20 I totally understand your concern about making the change this late in the = game. But, I think Chris made some really good points and now is the time t= o do it, otherwise, I can envision years of repeated discussion around this = as new people come along. Hopefully, we're talking about a few weeks delay= which is tolerable I think for a WG that just had it's 3rd birthday. =20 =20 Regards, Mary.=20 =20 On Fri, Sep 23, 2016 at 7:29 AM, Chris Wendt wr= ote: Hi Jon, All, =20 I do think this change has a few nice things about it: =20 - removes the =E2=80=9Ccanon=E2=80=9D concept, which is not necessarily complex or anyt= hing, but not as intuitive as the proposal Jon makes. Consolidating the tok= en into a single object right after identity: in either compact or long form= just makes things more straight forward and avoids the need for concatenati= on, etc. - aligns better with the Appendix F that Christer brought up - saves a few bytes and parsing logic =20 I think the general discussion that SIPit brought to a head with a few of t= he implementers in the room, is why not do this, it just makes sense. =20 That said, we are also under pressure to get this out. =20 So i=E2=80=99m favor in making this change but also want to make sure this won=E2=80=99= t alter timelines. Somehow i suspect that can=E2=80=99t be strictly true, but may= be someone can prove me wrong. =20 I am willing to make changes in the document quickly, i think Jon is signin= g up for 4474bis changes quickly as well. =20 But in any case, need some guidance, and in short order :) =20 -Chris =20 On Sep 22, 2016, at 3:49 PM, Peterson, Jon wrote= : =20 =20 At this point in STIR's development, I am loathe to introduce any further c= hange to the rfc4474bis/PASSporT syntax and interaction. However, we hold ev= ents like SIPit so we can learn from implementers what we need to fix, and f= rom that event, and surrounding discussion, we apparently still have some qu= alms about "canon". =20 To summarize the current situation briefly, a PASSporT object consistent of= three components: a JOSE header, a payload (containing the claims), and a s= ignature. In rfc4474bis-12, the Identity header begins with the signature co= mponent, and optionally can include the header and payload in the "canon" pa= rameter. In order to form a full PASSporT object, a recipient of an Identity= header must therefore: a) when "canon" is present, concatenate the contents= of "canon" and the signature at the beginning of the Identity header; or b)= when "canon" is not present, reconstruct the value of "canon" from the SIP = request, and then concatenate that value with the signature at the beginning= of the Identity header.=20 =20 We store the header and payload in "canon" for largely historical reasons: = "canon" was originally created as a parameter to store the optional canonica= lization of any originating or destination telephone number(s) in the reques= t, and when we migrated to PASSporT, we repurposed the parameter to store th= e header and payload, as they contained a superset of that data. One could a= rgue though that a better syntax for PASSporT would be to dispense with "can= on" and simply prepend the header and payload to the signature in the Identi= ty header when they are included in the request: this would effectively mean= that the entire JWT object would appear in one place in the header, rather = than being broken in two the way it is in option (a) today. For option (b), = then, we would need some way for the auth service to signify that the header= and claims are omitted: we could for example just put two leading "."'s at = the start of the header, the first representing the "." between the header a= nd payload, and the second the "." between the payload and the signature. Th= at would be in keeping with the spirit of RFC7515 Appendix F - and let's fac= e it, that section is heavy on spirit and light on letter.=20 =20 >From an rfc4474bis perspective, this is purely a syntactical change. It tra= des the six octets of "canon=3D" that we pay every time that the header and pa= yload are included in a request for the two octets of ".." that we would pay= under this proposal every time we did not include the header and payload in= a request. For implementers, it shifts around the burden of who does which = concatenation operation a bit, but if any implementation out there would ser= iously be taxed by one additional concatenation operation, it probably shoul= dn't be working with JSON or SIP at all. This proposal would also move much = of the specification of this over to the PASSporT document: that specificati= on would now define a "full" and "compact" mode for PASSporT, and rfc4474bis= would simply specify where you stick it and and when you need to use one or= the other. But making this change would require substantial and pervasive c= hanges in rfc4474bis, and significant additions to PASSporT as well, which a= gain at this late stage I am very hesitant to do for solely syntactical reas= ons. =20 By the by, this issue is orthogonal to the question of when we recommend us= ing the full as opposed to compact form. This change would be neutral with r= egard to that. This is simply a proposed change to the syntax. =20 If anyone has any opinions about this, this would be the time to speak up. = When two syntax approaches are as similar as these, it can be very difficult= to decide between them, because there simply aren't sufficient grounds to p= refer one over the other. From my perspective, the increase in clarity that = comes from having the concept of a "full" and "compact" mode for PASSporT mi= ght be helpful for other using protocols as well as SIP, and it thus seems a= rchitecturally cleaner than having SIP define its own legacy-encumbered way = to render PASSporT compact. The cost of this to rfc4474bis, though, would be= an onerous update that would require careful review before we proceed. It i= s difficult for me to justify any delay for the sake of tweaking the syntax. =20 Jon Peterson Neustar, Inc. _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir =20 _______________________________________________ stir mailing list stir@ietf= .org https://www.ietf.org/mailman/listinfo/stir=20 --B_3557483886_1836946105 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

+1=C2=A0 Lets do it now. =

 

— 

Richard Shockey

Shocke= y 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 <stir-bounces@ietf.org> on behalf of Mary Barnes <mary.ietf.ba= rnes@gmail.com>
Date: Friday, September 23, 2016 at 1:44 PM
= To: Chris Wendt <chris-ietf@chriswendt.net>
Cc: IETF = STIR Mail List <stir@ietf.org>, "Peterson, Jon" <jon.pete= rson@neustar.biz>
Subject: Re: [stir] a (proposed) syntax chang= e

 

Jon,

=  

I totally understand your conc= ern about making the change this late in the game.  But, I think Chris = made some really good points and now is the time to do it, otherwise, I can = envision years of repeated discussion around this as new people come along. =   Hopefully, we're talking about a few weeks delay which is tolerable I= think for a WG that just had it's 3rd birthday.   

=

 

Regards,

Mary. 

 

On Fri, Sep 23, 2016 at 7:29 AM, Chris Wendt <chris-ietf@chriswendt.net&g= t; wrote:

Hi Jon, All,

 

I do think this change has a = few nice things about it:

&= nbsp;

- removes the “canon̶= 1; concept, which is not necessarily complex or anything, but not as intuiti= ve as the proposal Jon makes.  Consolidating the token into a single ob= ject right after identity: in either compact or long form just makes things = more straight forward and avoids the need for concatenation, etc.=

- aligns better with the Appendix F that C= hrister brought up

- saves a few= bytes and parsing logic

&n= bsp;

I think the general discussion t= hat SIPit brought to a head with a few of the implementers in the room, is w= hy not do this, it just makes sense.

 

That said, we are al= so under pressure to get this out.

 

So i’m favor in = making this change but also want to make sure this won’t alter timelin= es.  Somehow i suspect that can’t be strictly true, but maybe som= eone can prove me wrong.

&n= bsp;

I am willing to make changes in = the document quickly, i think Jon is signing up for 4474bis changes quickly = as well.

 

But in any case, need some guidance, and in shor= t order :)

 

=

-Chris

 

On Sep 22, 2016, at 3:49 PM, P= eterson, Jon <j= on.peterson@neustar.biz> wrote:

 

 

At this point in STIR's development, I am loathe to introduce any= further change to the rfc4474bis/PASSporT syntax and interaction. However, = we hold events like SIPit so we can learn from implementers what we need to = fix, and from that event, and surrounding discussion, we apparently still ha= ve some qualms about "canon".

 = ;

To summarize the current situation briefly, a PASSpor= T object consistent of three components: a JOSE header, a payload (containin= g the claims), and a signature. In rfc4474bis-12, the Identity header begins= with the signature component, and optionally can include the header and pay= load in the "canon" parameter. In order to form a full PASSporT ob= ject, a recipient of an Identity header must therefore: a) when "canon&= quot; is present, concatenate the contents of "canon" and the sign= ature at the beginning of the Identity header; or b) when "canon" = is not present, reconstruct the value of "canon" from the SIP requ= est, and then concatenate that value with the signature at the beginning of = the Identity header. 

 

We store the header and payload in "canon" for largely h= istorical reasons: "canon" was originally created as a parameter t= o store the optional canonicalization of any originating or destination tele= phone number(s) in the request, and when we migrated to PASSporT, we repurpo= sed the parameter to store the header and payload, as they contained a super= set of that data. One could argue though that a better syntax for PASSporT w= ould be to dispense with "canon" and simply prepend the header and= payload to the signature in the Identity header when they are included in t= he request: this would effectively mean that the entire JWT object would app= ear in one place in the header, rather than being broken in two the way it i= s in option (a) today. For option (b), then, we would need some way for the = auth service to signify that the header and claims are omitted: we could for= example just put two leading "."'s at the start of the header, th= e first representing the "." between the header and payload, and t= he second the "." between the payload and the signature. That woul= d be in keeping with the spirit of RFC7515 Appendix F - and let's face it, t= hat section is heavy on spirit and light on letter. <= /p>

 

From an rfc4474bis perspective, thi= s is purely a syntactical change. It trades the six octets of "canon=3D&q= uot; that we pay every time that the header and payload are included in a re= quest for the two octets of ".." that we would pay under this prop= osal every time we did not include the header and payload in a request. For = implementers, it shifts around the burden of who does which concatenation op= eration a bit, but if any implementation out there would seriously be taxed = by one additional concatenation operation, it probably shouldn't be working = with JSON or SIP at all. This proposal would also move much of the specifica= tion of this over to the PASSporT document: that specification would now def= ine a "full" and "compact" mode for PASSporT, and rfc447= 4bis would simply specify where you stick it and and when you need to use on= e or the other. But making this change would require substantial and pervasi= ve changes in rfc4474bis, and significant additions to PASSporT as well, whi= ch again at this late stage I am very hesitant to do for solely syntactical = reasons.

 

By the b= y, this issue is orthogonal to the question of when we recommend using the f= ull as opposed to compact form. This change would be neutral with regard to = that. This is simply a proposed change to the syntax.

<= /div>

 

If anyone has any opinions about this, = this would be the time to speak up. When two syntax approaches are as simila= r as these, it can be very difficult to decide between them, because there s= imply aren't sufficient grounds to prefer one over the other. From my perspe= ctive, the increase in clarity that comes from having the concept of a "= ;full" and "compact" mode for PASSporT might be helpful for o= ther using protocols as well as SIP, and it thus seems architecturally clean= er than having SIP define its own legacy-encumbered way to render PASSporT c= ompact. The cost of this to rfc4474bis, though, would be an onerous update t= hat would require careful review before we proceed. It is difficult for me t= o justify any delay for the sake of tweaking the syntax.

 

Jon Peterson

Neustar, Inc.

_______________________________________________
stir mailing liststir@ietf.org
https://www.ie= tf.org/mailman/listinfo/stir

 


_______________________________________________
s= tir mailing list
stir@ietf.org
https://www= .ietf.org/mailman/listinfo/stir

 

__________________= _____________________________ stir mailing list stir@ietf.org https://www.ie= tf.org/mailman/listinfo/stir

--B_3557483886_1836946105-- From nobody Fri Sep 23 12:07:44 2016 Return-Path: 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 3B27212B8D9 for ; Fri, 23 Sep 2016 12:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 j20nQdUbzhDX for ; Fri, 23 Sep 2016 12:07:40 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B56C12B8C8 for ; Fri, 23 Sep 2016 12:07:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7CCB1300A16 for ; Fri, 23 Sep 2016 15:07:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yaDiiYkK2m74 for ; Fri, 23 Sep 2016 15:07:37 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 2B82D3005C5; Fri, 23 Sep 2016 15:07:37 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_90B9C8CB-F343-458D-9D0F-B095312FB96A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Fri, 23 Sep 2016 15:07:36 -0400 Message-Id: <40257FFD-F52A-4FAB-A9F1-349B8FCA2584@vigilsec.com> References: <186E1060-A929-4712-85FA-7DEE8172D60A@vigilsec.com> To: Mary Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for STIR Certificates Document X-BeenThere: stir@ietf.org 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: Fri, 23 Sep 2016 19:07:42 -0000 --Apple-Mail=_90B9C8CB-F343-458D-9D0F-B095312FB96A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mary: The object identifiers should be published somewhere so that everyone = interprets them the same way, but that should probably be a new = first-come-first-serve registry. Russ On Sep 15, 2016, at 5:43 PM, Mary Barnes = wrote: > Hi Russ, >=20 > Your proposal makes a lot of sense to me. So, this then removes the = dependency on the LoA Registry defined for SAML, correct?=20 >=20 > Regards, > Mary. =20 >=20 > On Thu, Sep 15, 2016 at 11:07 AM, Russ Housley = wrote: > I have found a place where additional clarity is needed in Section = 5.1. The current text is: >=20 > 5.1. Levels Of Assurance >=20 > This specification supports different level of assurance (LOA). = The > LOA indications, which are Object Identifiers (OIDs) included in = the > certificate's certificate policies extension [RFC5280], allow CAs = to > differentiate those enrolled from proof-of-possession versus > delegation. A Certification Policy and a Certification Practice > Statement [RFC3647] are produced as part of the normal PKI > bootstrapping process (i.e., the CP is written first and then the = CAs > say how they conform to the CP in the CPS). OIDs are used to > reference the CP and if the CA wishes it can also include a = reference > to the CPS with the certificate policies extension. CAs that wish = to > express different LOAs MUST include the certificate policies > extension in issued certificates. See Section 11 for additional > information about the LOA registry. >=20 > This all makes sense to me, but it does not say whether the LOA is = inferred from the CertPolicyId or explicitly carried in the = PolicyQualifierInfo. I think that the later is intended because of the = reference to an LOA registry. Please confirm that I got that right. >=20 > For background, RFC 5280 specifies the following ASN.1 for the = PolicyQualifierInfo: >=20 > PolicyQualifierInfo ::=3D SEQUENCE { > policyQualifierId PolicyQualifierId, > qualifier ANY DEFINED BY policyQualifierId } >=20 > So, I think we need to specify a single OID for the LOA = policyQualifierId that is used in all certificates, and then have the = qualifier carry an object identifier for the LOA. Each certificate = policy would list the LOA object identifiers that are supported. If = this is the intent, then the IANA considerations should ask for the = assignment of the policyQualifierId object identifier. >=20 > That would result in something like this: >=20 > id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 } >=20 > id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 } > id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 } > id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 } >=20 > Comments? >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 --Apple-Mail=_90B9C8CB-F343-458D-9D0F-B095312FB96A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Mary:

The object identifiers = should be published somewhere so that everyone interprets them the same = way, but that should probably be a new first-come-first-serve = registry.

Russ


=
On Sep 15, 2016, at 5:43 PM, Mary Barnes <mary.ietf.barnes@gmail.com&= gt; wrote:

Hi Russ,

Your proposal = makes a lot of sense to me.  So, this then removes the dependency = on the LoA Registry defined for SAML, = correct? 

Regards,
Mary. =  

On Thu, Sep 15, 2016 at 11:07 AM, Russ Housley = <housley@vigilsec.com> = wrote:
I have found a place = where additional clarity is needed in Section 5.1.  The current = text is:

5.1.  Levels Of Assurance

   This specification supports different level of assurance = (LOA).  The
   LOA indications, which are Object Identifiers (OIDs) = included in the
   certificate's certificate policies extension [RFC5280], = allow CAs to
   differentiate those enrolled from proof-of-possession = versus
   delegation.  A Certification Policy and a = Certification Practice
   Statement [RFC3647] are produced as part of the normal = PKI
   bootstrapping process (i.e., the CP is written first and = then the CAs
   say how they conform to the CP in the CPS).  OIDs are = used to
   reference the CP and if the CA wishes it can also include a = reference
   to the CPS with the certificate policies extension.  = CAs that wish to
   express different LOAs MUST include the certificate = policies
   extension in issued certificates.  See Section 11 for = additional
   information about the LOA registry.

This all makes sense to me, but it does not say whether the LOA is = inferred from the CertPolicyId or explicitly carried in the = PolicyQualifierInfo.  I think that the later is intended because of = the reference to an LOA registry.  Please confirm that I got that = right.

For background, RFC 5280 specifies the following ASN.1 for the = PolicyQualifierInfo:

   PolicyQualifierInfo ::=3D SEQUENCE {
        policyQualifierId  = PolicyQualifierId,
        qualifier          = ANY DEFINED BY policyQualifierId }

So, I think we need to specify a single OID for the LOA = policyQualifierId that is used in all certificates, and then have the = qualifier carry an object identifier for the LOA.  Each certificate = policy would list the LOA object identifiers that are supported.  = If this is the intent, then the IANA considerations should ask for the = assignment of the policyQualifierId object identifier.

That would result in something like this:

   id-qt-loa OBJECT IDENTIFIER ::=3D { id-qt TBD1 }

   id-loa-full OBJECT IDENTIFIER ::=3D { TBD2 }
   id-loa-partial OBJECT IDENTIFIER ::=3D { TBD3 }
   id-loa-none OBJECT IDENTIFIER ::=3D { TBD4 }

Comments?

Russ

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


= --Apple-Mail=_90B9C8CB-F343-458D-9D0F-B095312FB96A-- From nobody Sun Sep 25 09:06:30 2016 Return-Path: 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 72AF612B252 for ; Sun, 25 Sep 2016 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 I7psYYm_hhy1 for ; Sun, 25 Sep 2016 09:06:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EB7712B250 for ; Sun, 25 Sep 2016 09:06:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7B414300596 for ; Sun, 25 Sep 2016 12:06:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vfGIcZzOTd-M for ; Sun, 25 Sep 2016 12:06:25 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id B6984300547 for ; Sun, 25 Sep 2016 12:06:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> Date: Sun, 25 Sep 2016 12:06:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [stir] Second WG Last Call for ... X-BeenThere: stir@ietf.org 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: Sun, 25 Sep 2016 16:06:28 -0000 The Second WG Last Call has completed for: - draft-ietf-stir-rfc4474bis-12,=20 - draft-ietf-stir-certificates-08, and - draft-ietf-stir-passport-07. A significant change was proposed. Many people spoke is support of that = change, and no one spoke against it. This change impacts both = draft-ietf-stir-rfc4474bis an draft-ietf-stir-passport. In addition, many clarifications were suggested that impact all three = documents. Authors, can updates to all three document get posted in the next few = days? Russ From nobody Mon Sep 26 06:21:55 2016 Return-Path: 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 A691E12B215 for ; Mon, 26 Sep 2016 06:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 S_32xnhQ5aye for ; Mon, 26 Sep 2016 06:21:50 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF83612B214 for ; Mon, 26 Sep 2016 06:21:50 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id g67so102453198qkd.0 for ; Mon, 26 Sep 2016 06:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=60356iRTV0UHyKD0T6oJ9DHwwsCyB/GqDEZhQ9lMk/k=; b=wqNfFHspw2OfvHXfcmmH12FyCuCbqPqdz0B4XPT1iI6zWvcDGvjM43CQoGH8jyllZv pG5xAT6CgPUbSJWTBxmXetxDOHlEedHRxVSir30gYTIlk047hXv4DXMhStq0jAamX7qB 7aBgHaXlBAY6HwVjyh2Pl9z6owLX31GIhb80acc65MPI+wyLFBpyrIddkJfs7kFE7Dhi vppKoQBs/pzTCl/LWFgvpbz3CxPx687VkaiEyXFhaOhmFfVq54pBwcwDoK3kKiQCJmQq ZtXiQx3DMu7sLOt5hwQ/96tIbyHfQz4iYJZgLSnQ4wDexoJL1p2Ho/ABJN3uTiS6XHss o9dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=60356iRTV0UHyKD0T6oJ9DHwwsCyB/GqDEZhQ9lMk/k=; b=idludXTm/JOmknXqNvjjwad2Hse3Dl/vvr3tYMeMye9BK2oIOZoZeT4eRsW3eSvkwZ MdrVvoHZCHLcQjqHVawIxNOTNmj2hlyI7HgoABUZkq3DEHsCEJHEi2lk1CPTgQ4Ynz67 FOEO5gaP6L9G2tIjeZ+iWidyHcPe8zKjoiVUYi4AwBIpHWOoF56YrQY9CFXUNmxjj5dP BNEPoEoPY0MQPR/yep2xtzDPoROrTWbFCycqG6Lj2BN4X7pKDDcgNxVVrsg3JSVPVMbO f0k76qz40fwAAjKZVUt0bnb95miaxWs53AjZ9uCrzRB6r5IT6qS4+AbjqxGYjBf6A55Y Ajbw== X-Gm-Message-State: AA6/9RkiCQLBLwcjJ61tXjgm6IDvN48ITiJtNadgHyW2hzfvOawtFxgqwqx8o+oO/1JMQw== X-Received: by 10.55.12.6 with SMTP id 6mr22962416qkm.109.1474896109769; Mon, 26 Sep 2016 06:21:49 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:347a:3289:1082:32b0? ([2601:a40:100:d3:347a:3289:1082:32b0]) by smtp.gmail.com with ESMTPSA id r15sm11574001qtc.17.2016.09.26.06.21.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2016 06:21:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Chris Wendt In-Reply-To: Date: Mon, 26 Sep 2016 09:21:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for ... X-BeenThere: stir@ietf.org 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: Mon, 26 Sep 2016 13:21:54 -0000 Yes i can do that as well as incorporate changes for AD review comments > On Sep 25, 2016, at 12:06 PM, Russ Housley = wrote: >=20 > The Second WG Last Call has completed for: > - draft-ietf-stir-rfc4474bis-12,=20 > - draft-ietf-stir-certificates-08, and > - draft-ietf-stir-passport-07. >=20 > A significant change was proposed. Many people spoke is support of = that change, and no one spoke against it. This change impacts both = draft-ietf-stir-rfc4474bis an draft-ietf-stir-passport. >=20 > In addition, many clarifications were suggested that impact all three = documents. >=20 > Authors, can updates to all three document get posted in the next few = days? >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Mon Sep 26 08:43:40 2016 Return-Path: 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 749E912B2D3 for ; Mon, 26 Sep 2016 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=xq6ohvhD; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=KKM/GE/M 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 KhDYBU-s6GST for ; Mon, 26 Sep 2016 08:43:38 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28AE12B04A for ; Mon, 26 Sep 2016 08:43:37 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4E448206D1; Mon, 26 Sep 2016 11:43:37 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 26 Sep 2016 11:43:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=Mu7u1w1odZzZRjnwbF7OqKukOdw=; b=xq6ohv hD+C4EEi6Rau0YIsbnoIpLoABgS5O7jfnMiPW/SCm4rMaNVYp8k3jTBMFpceMbF/ jkBhqhKHQr+V5gm7EiH65gFtBpPO4zkTJiIIDkpl+PdL6BsnbpXQCxdqmgCZVNpb 4kktp2kL50EO0oIlPUA/w82cSXZ1diDXwilOo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Mu7u1w1odZzZRjn wbF7OqKukOdw=; b=KKM/GE/McaAUPsyYg4Q1vAjglQ1IAKWvsBU8UlAfqeo4SIW gGLa1Udo4B3tHj2JcZZDjZGWucg/N1LzGfm8Nye7DkX8faDRgZybyM1JV8dHpTCL PAepAfztP5GGndCdQBefjwm4e3mBwcUhrYR0wMu68keYM//f6vmq8liBJPPE= X-Sasl-enc: ++k4ip7zWIFX/fxh8hNc14r0EidKulXFRxsofupI7b1O 1474904616 Received: from dhcp-10-150-9-154.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id D39B6CCEB0; Mon, 26 Sep 2016 11:43:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 26 Sep 2016 11:43:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6713660A-6B29-46A2-816B-3F143DCD0093@cooperw.in> References: <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <7D464687-370D-43CA-8AFA-2DE5C9C576E8@cooperw.in> To: Jon Peterson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Second WG Last Call for RFC4474bis X-BeenThere: stir@ietf.org 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: Mon, 26 Sep 2016 15:43:39 -0000 > On Sep 22, 2016, at 3:12 PM, Peterson, Jon = wrote: >=20 >>=20 >> (2) >> "Defining how a SIP implementation >> would provision multiple originating or destination identities is >> left as a subject for future specification." >>=20 >> I'm assuming this meant to say that defining how a STIR = implementation >> deals with multiple identities is what is left for future = specification. >> Is that correct? If so, it would be helpful to clarify. >=20 > Well, this means more aligning STIR with potential ways that SIP might > signify that a request is "To" multiple destinations or "From" = multiple > parties, say. Even when PAI is present and is different from the From, > there is still a general sense in personal communications that they = are > from some person (a persona even). We do have some vague notion that = we > want to work with meshed and centralized conferences, though, and = don't > want to close the door on that, which is why there's some = forward-looking > text about this here, and why the text is pretty broad. Ok. I was reading this to mean the From+PAI case in current deployment, = which is why it sounded confusing to me. Thanks, Alissa= From nobody Mon Sep 26 16:25:44 2016 Return-Path: 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 E7C1112B05C; Mon, 26 Sep 2016 16:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lvZEkIWiLk_c; Mon, 26 Sep 2016 16:25:41 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3586112B260; Mon, 26 Sep 2016 16:25:38 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Sep 2016 16:38:58 -0700 From: Jim Schaad To: Date: Mon, 26 Sep 2016 16:25:29 -0700 Message-ID: <01fe01d2184d$46f75b50$d4e611f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdIYS5+SiTYckaDWTLCy18rq4kpv4A== X-Originating-IP: [192.168.1.152] Archived-At: Cc: stir@ietf.org Subject: [stir] draft-ietf-stir-passport JOSE Registrations X-BeenThere: stir@ietf.org 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: Mon, 26 Sep 2016 23:25:43 -0000 So I just got this pointed to me I am unsure of what the value of "ppt" is supposed to be in one case. Is the intention that extensions will only be done serially or can they be done in parallel? The first case allows for a high water mark to be used until the next one. In the second case the question comes up if one wants to use both extension 'a' and extension 'b' in some sense. (Consider the case where the extensions are orthogonal to each other by requiring different JWT claims to be present.) In the second case it does not appear to be expressible in the current syntax. Jim From nobody Thu Sep 29 18:08:52 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5D312B020; Thu, 29 Sep 2016 18:08:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147519772937.18597.13650607940211719194.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 18:08:49 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-08.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 01:08:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Personal Assertion Token (PASSporT) Authors : Chris Wendt Jon Peterson Filename : draft-ietf-stir-passport-08.txt Pages : 21 Date : 2016-09-29 Abstract: This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator of personal communications. The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-passport-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 29 18:13:14 2016 Return-Path: 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 E560912B023 for ; Thu, 29 Sep 2016 18:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 azan29s29ycH for ; Thu, 29 Sep 2016 18:13:11 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4297112B09C for ; Thu, 29 Sep 2016 18:13:09 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id j129so86508542qkd.1 for ; Thu, 29 Sep 2016 18:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=K6C5X9t0ZWUgK5JMwu0+Y8RkokE+izo0T8aAEyz+WBU=; b=Pg9JhuNl1J/jp48X9WzHLw6hpXKVj18zc+L5b1BthtL49qWyPYh7gr3Yo60GDj23a7 2JXCkylp04aIK7czlfnln+rcpbPVG30vSQClMattWLdDcnbfBuei1lZHcyBn8hCrnoM6 J23nP4jBeDYzJ4y6nFKhgMt5J76pLFmW0TkIb0wKvhcT1OvVJZYNFXKeyGc0Ubex3lEm w3U/1UcBMGPzKBYqRq96iDkaNcVkom4+atYUoGBY/lvf9pk4S+39aCR4v48V0Zm6xqgx r4bnwOQ03UgXdNM3gGCMyHXEEnWmBw3k/oFqFWEhAmuxV9tlJPxMvz2FbZF/9JZMJv1z pkOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=K6C5X9t0ZWUgK5JMwu0+Y8RkokE+izo0T8aAEyz+WBU=; b=PDooMK8WcgLifk2JTfjcudSvSaQb58qbXPWEGyiS2kvJZ2bajRE8BzHaNpTaF88dqV quVPklIT1WWoidn0ZK5vl+Ut/DbZIbAaXcp/WKI0mBOmgFqugLNz3BeigJ5GgKNitYOc UcCLQ2LNziqBu/lbdCi/WE7gTuO1gGiGTvxc8QCzAGsJFaLKcpUhjVIIS0pxhiQAi7u2 r34ZpsSqb63KfYZqEH6Pm8g4aovU6/rm9jYBGWnh4UU0GwtJHZ8XPGm2JarGcgRQ8+aB aL+wCYsLbfkaKDG8PQWUyLTPAPFMtTOTjaCagrhw8WUPaxXxwgPOl96tWeY6tRItRItW GPbw== X-Gm-Message-State: AA6/9Rk7w8anirwVmAdb8hGgb7QiDZDEwvNlwpDREmkfT99uiBR/TPUR0+UGklleCroedA== X-Received: by 10.55.144.71 with SMTP id s68mr4748842qkd.290.1475197988342; Thu, 29 Sep 2016 18:13:08 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:bd33:abaf:f17d:b6e3? ([2601:41:c101:9364:bd33:abaf:f17d:b6e3]) by smtp.gmail.com with ESMTPSA id r15sm8456550qtc.17.2016.09.29.18.13.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Sep 2016 18:13:08 -0700 (PDT) From: Chris Wendt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 29 Sep 2016 21:13:07 -0400 References: <147519772937.18597.13650607940211719194.idtracker@ietfa.amsl.com> To: IETF STIR Mail List In-Reply-To: <147519772937.18597.13650607940211719194.idtracker@ietfa.amsl.com> Message-Id: <19E5328B-ACEA-4D0F-AC68-33C5BE410AA6@chriswendt.net> X-Mailer: Apple Mail (2.3226) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-08.txt X-BeenThere: stir@ietf.org 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: Fri, 30 Sep 2016 01:13:13 -0000 Hi All, We have updated passport draft to incorporate the discussed compact form = of passport to align with the ..signature format as an option for = 4474bis-13. There was a missing IANA request for =E2=80=98ppt=E2=80=99 that is now = included as well. I have also incorporated edits to address Alissa=E2=80=99s AD review = comments. Thanks! -Chris > On Sep 29, 2016, at 9:08 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Telephone Identity Revisited = of the IETF. >=20 > Title : Personal Assertion Token (PASSporT) > Authors : Chris Wendt > Jon Peterson > Filename : draft-ietf-stir-passport-08.txt > Pages : 21 > Date : 2016-09-29 >=20 > Abstract: > This document defines a method for creating and validating a token > that cryptographically verifies an originating identity, or more > generally a URI or telephone number representing the originator of > personal communications. The PASSporT token is cryptographically > signed to protect the integrity of the identity the originator and = to > verify the assertion of the identity information at the destination. > The cryptographic signature is defined with the intention that it = can > confidently verify the originating persona even when the signature = is > sent to the destination party over an insecure channel. PASSporT is > particularly useful for many personal communications applications > over IP networks and other multi-hop interconnection scenarios where > the originating and destination parties may not have a direct = trusted > relationship. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stir-passport-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Sep 29 18:13:30 2016 Return-Path: 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 8228F12B0DB for ; Thu, 29 Sep 2016 18:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.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 rDjipuuR9iMr for ; Thu, 29 Sep 2016 18:13:21 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324E112B0AB for ; Thu, 29 Sep 2016 18:13:21 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id t7so94500333qkh.2 for ; Thu, 29 Sep 2016 18:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QH5kVUTiliZob3XM9jMsb+BQaaIkJwxDbfJqiEnR88Y=; b=TJtf1k17DBWamkmji3QB79tAzJW6PcDFoT9L3knaSLghGI6Ej9DxS2Tgi51KOLRDFg DVUGbR+tcy+REyhE5klqkL37W5W+AMPMeavm2GEV4KF//lrXzOHOay+Ojo2BzhF1Okii b7iohLavqkdimTU7tWNgDKs9iSnWxFLBdMecSG+kwCHzBk9A88BFB5aHC0iV8m4ueROo 2dgvPZZxiSwcpgyBb/MgThV4m093t5mONjC9QgUv7LVtHysoN6MbQ3r+CXIdcOhg3/UQ 0QWXfKV3C/Gp9jhW4wLuPII4Qk9Sgq9So5ZzACTlFRz2u98EWZqj73sjU92QZiq7kuoB pUrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QH5kVUTiliZob3XM9jMsb+BQaaIkJwxDbfJqiEnR88Y=; b=YLPH1DgLX1oIxcc30+SqfXqi+xQXoB1wWq+0ZZ6cKzpw3VL3iEiX9zMm0YxSC2FyDZ Nd92eFdoCsBA9VejvKnrwW72GB5XJ83Oo7iN61jLp96o6dJ0Z9O0fXbW97qTSTB6yE74 lEXuz2hp4qSVZTIdBRfARRAT11dkLHQ3nHycnxzHqyV6rxuM9A7G8c2cnuCZUB5PJC79 pjLaJfdD0HC3YlBtgzj7arnWKzdGxsJNB+P6BE9Q8Dwe5HPUSJe03kHOi5BYi2NF2oXK FVZ9Gh31da85I6pSVkq/K3hB/oTpHNWjbqJ063rHACpgSGTXbJbbjWK4VjzqYix8UM7u qpUA== X-Gm-Message-State: AA6/9RmG8+tAW++UZv7l4jONBNmdwGygqNOqkPBiBWa7Q4/DqimbYw1uhguP7ADIZ/yiYw== X-Received: by 10.55.212.221 with SMTP id s90mr4753664qks.169.1475198000359; Thu, 29 Sep 2016 18:13:20 -0700 (PDT) Received: from ?IPv6:2601:41:c101:9364:bd33:abaf:f17d:b6e3? ([2601:41:c101:9364:bd33:abaf:f17d:b6e3]) by smtp.gmail.com with ESMTPSA id r15sm8456550qtc.17.2016.09.29.18.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Sep 2016 18:13:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Chris Wendt In-Reply-To: <9F26F994-AE94-4C6E-B9F7-D5E6576E423E@cooperw.in> Date: Thu, 29 Sep 2016 21:13:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F93A8E6-99E1-49DF-A16E-6BE2A213067C@chriswendt.net> References: <20388E22-CF03-4338-954B-B9BAFA33C4AF@vigilsec.com> <9F26F994-AE94-4C6E-B9F7-D5E6576E423E@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] Second WG Last Call for PASSporT Document X-BeenThere: stir@ietf.org 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: Fri, 30 Sep 2016 01:13:27 -0000 Hi Alissa, Thanks very much for the review. I have gone through your comments and = noted inline the fixes i have made. They are reflected in the draft-ietf-stir-passport-08 update. -Chris > On Sep 20, 2016, at 9:43 PM, Alissa Cooper wrote: >=20 > I did my AD review of this document early to try to expedite the = process. >=20 >=20 > Substantive comments and questions: >=20 > =3D Section 3.2 =3D >=20 > I have some suggested changes below which I think more accurately = reflect the intent of the WG as regards algorithm support. But if I'm = incorrect, let's discuss. >=20 > OLD=20 > For the creation and verification of PASSporT tokens and their digital = signatures ES256 MUST be implemented as defined in JWA Section 3.4 >=20 > Note that JWA defines other algorithms that may be utilized or updated = in the future depending on cryptographic strength requirements guided by = current security best practice. >=20 > NEW=20 > For the creation and verification of PASSporT tokens and their digital = signatures, implementations MUST support ES256 as defined in JWA Section = 3.4. Implementations MAY support other algorithms registered in the JSON = Web Signature and Encryption Algorithms registry created by RFC 7518. = The contents of that registry may be updated in the future depending on = cryptographic strength requirements guided by current security best = practice. The mandatory-to-support algorithm for PASSporT tokens may = likewise be updated in future updates to this document. I am ok with this, i think the text appropriate. >=20 >=20 > =3D Section 4.1.1 =3D >=20 > "As defined this should be set to the date and time of the origination = of the personal communications." >=20 > Actually, as defined in RFC 7519 this should be set to the time the = JWT is issued. I think that is all that needs to be said here. Yes will add this. >=20 > =3D Section 7 =3D >=20 > I suggest the edit below, but note that it modifies the way the = normative MUST is to be interpreted. Does this match the intent of the = existing language? >=20 > OLD=20 > In order to make the digital signature verification work = deterministically, the JSON representation of the PASSporT Header and = Claims, particularly if PASSporT is used across multiple signaling = environments, specifically the JWS Protected Header object and JWS = Payload object MUST be computed as follows. >=20 > NEW=20 > In order to make the digital signature verification work = deterministically, the JSON representation of the PASSporT header and = claims MUST be computed as follows. Agree it=E2=80=99s a little wordy, we do mention the idea of gatewaying = between signaling in the introduction, so i can remove that here. >=20 >=20 > =3D Section 8 =3D >=20 > I think the security considerations need a different approach. = Passport tokens themselves do not provide defenses against replay or = violations of confidentiality or integrity. That is natural, as all that = is being specified is a format. The consequence of this is that those = defenses, to the extent they can be made available, need to be built = into the ways that applications make use of the tokens. I think this = should be stated up front and I think the requirements on applications = making use of passport tokens should be clearly listed and described = with normative language. >=20 > For example, I would think that at least some of the recommendations = in 8.1 and 8.3 could be normative recommendations on applications: a = PASSporT token SHOULD only be sent together with application data fields = that correspond directly to fields in the token I did update this text a bit to clear up the logic including a normative = SHOULD > and MUST NOT be used by applications to expose identifiers or other = communications details that the application does not otherwise already = expose. I would probably just remove 8.3, it is admittedly not really stating = anything useful, particularly since i added text similar to what you = have above that says ONLY include application data fields, so exposing = identifier that aren=E2=80=99t already exposed is not possible. >=20 >=20 > =3D Section 8.2 =3D >=20 > "However, applications that use PASSporT should ensure the signer is = in an authoritative position to represent the user and authenticate the = user onto the communications network and should be the responsible party = for protecting the destination party from potential identity spoofing in = addition to other abuse of the communications network outside of = PASSporT." >=20 > This sounds like a rather hefty set of requirements to levy on = applications, especially if this is interpreted as a set of requirements = to be implemented programmatically (although "should be the responsible = party" is I guess clearly not a programmatic requirement). Perhaps what = you're aiming for here is, instead, that operators of implementations = that are verifying passport tokens should have some means of verifying = that signers are authoritative, possibly automated but possibly not? I = would recommend dropping the clause about the responsible party = altogether as it seems out of scope for this document. I=E2=80=99ve reworded this section to hopefully provide better guidance = vs. requirements. >=20 >=20 > Nits: >=20 > =3D Abstract =3D >=20 > OLD=20 > This document defines a canonical string object or 'token' including a = digital signature for verifying the author of the token, their authority = to author the token and the information asserted in the token, = minimally, the originating identity or 'persona' corresponding = specifically to the originator of 'personal communications', or = signalled communications between a set of parties with identities. The = PASSporT token is cryptographically signed to protect the integrity of = the identify the originator of a personal communications session (e.g. = the telephone number or URI) and verify the assertion of the identity = information at the destination. >=20 > NEW=20 > This document defines a method for creating and validating a token = that cryptographically verifies an originating identity, or more = generally a URI or telephone number representing the originator of = personal communications. The PASSporT token is cryptographically signed = to protect the integrity of the identity the originator and to verify = the assertion of the identity information at the destination. Fixed. >=20 > =3D Section 1 =3D >=20 > s/for the signing and verification of telephone numbers./for the = signing and verification of telephone numbers and SIP URIs./ >=20 > =3D Section 3 =3D >=20 > Throughout this section, several of the references to sections of RFC = 7518 are not properly encoded, so, for example, a reference which is = intended to link to RFC 7518 Section 3.1 is actually referencing Section = 3.1 of this document. Please fix these. Fixed. >=20 > s/the following header parameters defined the the next three = subsections./the header parameters defined in the next three = subsections. >=20 Fixed. > =3D Section 4 =3D >=20 > s/and be encoded/and are encoded/ Fixed. >=20 > =3D Section 4.2.1 =3D >=20 > s/being called by the caller,/being called by the caller./ Fixed. >=20 > s/determined by the application must have the capability/determined by = the application need to have the capability Fixed. >=20 > =3D Section 4.2.1.1 =3D >=20 > Same problem with the section reference as in Section 3. I think this is ok, it points to 4474bis section 8.3 which is the intent = i believe. >=20 > =3D Section 4.2.2 =3D >=20 > s/If there are more that one fingerprint/If there is more than one = fingerprint/ Fixed. >=20 > =3D Section 7 =3D >=20 > OLD=20 > JSON, as a canonical format, can include spaces, line breaks and key = value pairs can occur in any order and therefore makes it, from a string = format, non-deterministic. >=20 > NEW=20 > JSON, as a canonical format, can include spaces and line breaks, and = key value pairs can occur in any order. It is therefore a = non-deterministic string format. >=20 Fixed. >=20 > Alissa >=20 >=20 >> On Sep 10, 2016, at 12:04 PM, Russ Housley = wrote: >>=20 >>=20 >> A revised document to address the issues raised in the first WG Last = Call >> on this document was posted yesterday. >> (https://www.ietf.org/id/draft-ietf-stir-passport-07.txt). >>=20 >> This message starts a second two-week WG Last Call for this document, >> which will end on 24 September 2016. >>=20 >> Please review the document and send comments on it to the STIR WG = mail >> list. Please clearly state your opinion as to whether the document = is >> ready for publication as a standards-track RFC. Remember that = support >> for publication is needed, so if you think the document is ready to = go >> forward, please say so. >>=20 >> Thanks, >> Russ & Robert >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Fri Sep 30 06:54:35 2016 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E894712B133; Fri, 30 Sep 2016 06:54:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147524367394.20448.544709464135771586.idtracker@ietfa.amsl.com> Date: Fri, 30 Sep 2016 06:54:33 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-13.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 13:54:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited of the IETF. Title : Authenticated Identity Management in the Session Initiation Protocol (SIP) Authors : Jon Peterson Cullen Jennings Eric Rescorla Chris Wendt Filename : draft-ietf-stir-rfc4474bis-13.txt Pages : 43 Date : 2016-09-30 Abstract: The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 30 09:45:49 2016 Return-Path: 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 C2E9F12B199; Fri, 30 Sep 2016 09:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 Je2rqjXwVt8w; Fri, 30 Sep 2016 09:45:46 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A52912B1B4; Fri, 30 Sep 2016 09:45:46 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8UGhM3Y008370; Fri, 30 Sep 2016 12:45:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=neustar.biz; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=neustar.biz; bh=9WEsGZkLlIuz7LkGq+B1Z9Rptl8o2HYzer0jnGPiHDU=; b=poRiCTzGzv0M+aOyvQazxTb3ij7rWs1tpgc5N/hSHE0CR/UYJZRhni0/10EysoVr9X1X qNg50GFXeDoj0urwQxP3HWEh3WWhNLtGxpNdVPVZN+Hmlnwq1t9wpFEl+fcMJD/rsanm ryryGCjgqlMhSYlKuaNrHEVEJrSgOotPfKYAQ7lax5IXAuCFQ6C1nd81+K8idzQ72TLF UsCFp0u6o1MHkdn7ic04Yw8b01GrpJ6Fqy66lPf7kxSEHa63VrdPyAB4VQQioleZvbYk BcqNEECPIe3yYkuOO3+G1biiTsUV4wTD4aaWyZAJ9h3RT8mA3GccGNeigpADY/2iS/i7 Vw== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 25s8svxqr0-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Sep 2016 12:45:29 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Fri, 30 Sep 2016 12:45:28 -0400 From: "Peterson, Jon" To: Jim Schaad , "draft-ietf-stir-passport@ietf.org" Thread-Topic: draft-ietf-stir-passport JOSE Registrations Thread-Index: AdIYS5+SiTYckaDWTLCy18rq4kpv4AC7mcIA Date: Fri, 30 Sep 2016 16:45:28 +0000 Message-ID: References: <01fe01d2184d$46f75b50$d4e611f0$@augustcellars.com> In-Reply-To: <01fe01d2184d$46f75b50$d4e611f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.24] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C8522DCEB7D4244B21084E977205257@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609280000 definitions=main-1609300304 Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] draft-ietf-stir-passport JOSE Registrations X-BeenThere: stir@ietf.org 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: Fri, 30 Sep 2016 16:45:48 -0000 First of all, beware, as there were some changes to the "ppt" text in the -08 version of PASSporT that fell out of the new specification of the "full" and "compact" (that is, Appendix F of 7515 as we spec it) form of the token. But speaking to the -08: the purpose of "ppt" is to subtype PASSporT with an indication that there are additional claims in the payload of the JWT beyond those specified in the baseline draft-ietf-stir-passport spec, and that support for this extension is mandatory for relying parties. If you just want to put a few extra optional claims in the JWT payload and you don't care if relying parties support them or not, you don't use "ppt" (though you do need to use the full as opposed to the compact form of PASSporT). You just stick in the claims and ship the object. You are correct that the spec only supports one mandatory extension per PASSporT, and that you'd have to send multiple PASSporTs (which in SIP would mean multiple Identity headers, which is permitted) if you wanted to use multiple mandatory extensions. We aren't envisioning a lot of extensions that would need to be mandatory today, but the ones that are will probably be profiles that specify multiple additional claims that will be present in the PASSporT payload. But we do understand that if you want to mandate relying party support for both profile A and profile B with a single PASSporT, that isn't possible in the current syntax - you'd have to send multiple PASSporTs. We're cool with that. Jon Peterson Neustar, Inc. On 9/26/16, 7:25 PM, "Jim Schaad" wrote: >So I just got this pointed to me=09 > >I am unsure of what the value of "ppt" is supposed to be in one case. Is >the intention that extensions will only be done serially or can they be >done >in parallel? The first case allows for a high water mark to be used until >the next one. In the second case the question comes up if one wants to >use >both extension 'a' and extension 'b' in some sense. (Consider the case >where the extensions are orthogonal to each other by requiring different >JWT >claims to be present.) > >In the second case it does not appear to be expressible in the current >syntax. > >Jim > > From nobody Fri Sep 30 18:07:46 2016 Return-Path: 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 34B5512B151 for ; Fri, 30 Sep 2016 18:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.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 mcjuf2q-dSSs for ; Fri, 30 Sep 2016 18:07:41 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D12C12B13D for ; Fri, 30 Sep 2016 18:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8/Mj1sS6UYA/3DmpsdQ8HtmAO6a+JrY4lADVrptJldo=; b=niPGr6cxCgy7j0+f/n2jvm8DC4g9/A6LJT/NdSQotOWfcgqrPUM7UOYP1nAcwprR8aned10ng3e45aCUqwhxboRe42fwl7Xn6SdZvbzaM3P2EcqcQHWp3GDS3IfjgsMfU9teJmmcTlPmoijfO/Dti4Ah2ipHgdppU3tlE27AARQ= From: Henning Schulzrinne To: "stir@ietf.org" Thread-Topic: FYI only: Two new VoIP spam drafts Thread-Index: AQHSG4AHdXDxA/hrj06MJ4pEMbL5uw== Date: Sat, 1 Oct 2016 01:07:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: fd023e9d-e1f0-484a-3df1-08d3e9975605 x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:yHzfnleA4UaMUsBtaP9KVvEh0MUz06YJo9wKtQE6IjNdIQm7wlpQYn1AVPt/718d21umdC/L6K5T6IUOi6ThZhO/kJ3G9fBZBeJW7Zu2yDO0ZB/88/OYpSoSaxS2xuMMx+xRpI8rEOQcl424dv5kgsyWGyvWxexxsspn03IX8Vq20zO5hUh6N71gqis4z54Uhpl1eK9LGig4vZBpZGgcMAZPqaXyDurL8OMHwo8SsBTP+ibpaDYFvryPFn352rFk/M6icUJtgoHbznNPCFhRrTM9D3XQktiPuRhjBspVm5I=; 5:WDwffOXLMmWRkhj9FS5v8/BjkTGCTtaUJfa6BInLZcpq3Hj2nLWRW1i6jvpepZU7jXuvNxm3/g5WUdKCY+EUALTcJejCfLIFrcKY/WDUSmNGvQo4jeWWmrwRuUi/C1xHGvaNnnREWvR7O/805HsMMw==; 24:G6i6Iq3WU/1vw/3ceZqM+eje5+xgagkyGdBbH7Gj+R+ShnwSxsbW4ImXETIoFvxAVrben4bXyyckHIecl23UbOg1OeuC2fMZBlEtgEgXVlA=; 7:GKg3PcC9SSHqSer1o2iGP/3TP1dCUyI21CF1GeD7Sgw40P2FzjSkS2CyPFuDbPzkaxDNJFKSorNCWAJtobqvsNe0ruQBzWHYX/BBkPpHmvBhmzIDCySiYFTNH1ogAYhu34lkvn7eDPolKbYr20cHNTHjhYVy+0ARGF9yaxHJug12WLnGnGajsVZeO7cCfBobOuI/Lx5zqlYVT+j1vshnhzbcvO63VDuZpeF+nAiD83FQkiWW3ZBrNSMaJXP9WrF7nI41rvMFc9CWhYJRCe8WHMrmMKQOxtI/yCbdk64OJ5EmtzYrpKh4HwMH12RH4ZtO x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(69234005)(199003)(19580395003)(9686002)(450100001)(86362001)(189998001)(122556002)(101416001)(1730700003)(54356999)(81156014)(6916009)(81166006)(33656002)(76576001)(8676002)(110136003)(50986999)(19625215002)(5660300001)(16236675004)(7696004)(19617315012)(2906002)(586003)(3846002)(5640700001)(102836003)(107886002)(2900100001)(8936002)(74316002)(6116002)(10400500002)(7906003)(15975445007)(77096005)(7846002)(7736002)(87936001)(97736004)(106356001)(106116001)(66066001)(3660700001)(19627405001)(11100500001)(68736007)(5002640100001)(105586002)(99286002)(2501003)(229853001)(92566002)(2351001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634D8B39756549280B2F686EAC00CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2016 01:07:38.0478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Subject: [stir] FYI only: Two new VoIP spam drafts X-BeenThere: stir@ietf.org 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: Sat, 01 Oct 2016 01:07:44 -0000 --_000_CY1PR09MB0634D8B39756549280B2F686EAC00CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please address comments to the DISPATCH list; this copy is FYI only since = I forgot to bcc the list.] In collaboration with members of the Robocall Strike Force (https://www.fcc= .gov/news-events/events/2016/08/first-meeting-industry-led-robocall-strike-= force), I have submitted two I-D's: https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted= / https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ that fill in operational needs for dealing with SIP spam. The first defines= a new status code (666) that users can use to mark unwanted calls, either = as a response code to an INVITE or in a Reason header in a BYE response. (T= his will likely be supplemented in practice by API-based mechanisms for pos= t-call spam reports.) The second defines a set of Call-Info parameters that allow the carrier or = other UE-trusted SIP entity in the path to indicate the spam probability, t= ype of call and other related information that will allow the UE and user t= o make better call handling decisions. This complements the 'verstat' work being submitted to 3GPP (by others), fo= r indicating the level of trust in the From/PAI tel URI. Henning --_000_CY1PR09MB0634D8B39756549280B2F686EAC00CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[Please address comments to the DISPATCH list; this copy is FYI only= since I forgot to bcc the list.]


In collaboration with members of the Robocall Strike Force (https://www.fcc.gov/news-events/events/= 2016/08/first-meeting-industry-led-robocall-strike-force), I have submitted two I-D's:


https://datatracker.ietf.org/doc/draft-schul= zrinne-dispatch-status-unwanted/

https://datatracker.ietf.org/doc/draft-schulzr= inne-dispatch-callinfo-spam/


that fill in operational needs for dealing with SIP spam. The first = defines a new status code (666) that users can use to mark unwanted calls, = either as a response code to an INVITE or in a Reason header in a BYE response. (This will likely be supplemented= in practice by API-based mechanisms for post-call spam reports.)


The second defines a set of Call-Info parameters that allow the carr= ier or other UE-trusted SIP entity in the path to indicate the spam probabi= lity, type of call and other related information that will allow the UE and user to make better call handling d= ecisions.


This complements the 'verstat' work being submitted to 3GPP (by othe= rs), for indicating the level of trust in the From/PAI tel URI.


Henning


--_000_CY1PR09MB0634D8B39756549280B2F686EAC00CY1PR09MB0634namp_-- From nobody Fri Sep 30 21:57:10 2016 Return-Path: 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 9FE6612B19E; Fri, 30 Sep 2016 21:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5qkCyPcDUm_3; Fri, 30 Sep 2016 21:57:06 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF3112B008; Fri, 30 Sep 2016 21:57:06 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 30 Sep 2016 22:10:14 -0700 From: Jim Schaad To: "'Peterson, Jon'" , References: <01fe01d2184d$46f75b50$d4e611f0$@augustcellars.com> In-Reply-To: Date: Fri, 30 Sep 2016 21:56:48 -0700 Message-ID: <068a01d21ba0$395fc260$ac1f4720$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQF2CGt8c7l6aEkIHzrrgQxdISYIhgHaVgxJoTxcl1A= X-Originating-IP: [24.21.96.37] Archived-At: Cc: stir@ietf.org Subject: Re: [stir] draft-ietf-stir-passport JOSE Registrations X-BeenThere: stir@ietf.org 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: Sat, 01 Oct 2016 04:57:08 -0000 Things look reasonable. It is not laid out the way that I would have done it but other than that it looks fine. Is there any plan to have some type of centralized list of ppt values? jim > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, September 30, 2016 9:45 AM > To: Jim Schaad ; draft-ietf-stir-passport@ietf.org > Cc: stir@ietf.org > Subject: Re: draft-ietf-stir-passport JOSE Registrations > > First of all, beware, as there were some changes to the "ppt" text in the > -08 version of PASSporT that fell out of the new specification of the "full" and > "compact" (that is, Appendix F of 7515 as we spec it) form of the token. > > > But speaking to the -08: the purpose of "ppt" is to subtype PASSporT with an > indication that there are additional claims in the payload of the JWT beyond > those specified in the baseline draft-ietf-stir-passport spec, and that support for > this extension is mandatory for relying parties. If you just want to put a few > extra optional claims in the JWT payload and you don't care if relying parties > support them or not, you don't use "ppt" > (though you do need to use the full as opposed to the compact form of > PASSporT). You just stick in the claims and ship the object. > > You are correct that the spec only supports one mandatory extension per > PASSporT, and that you'd have to send multiple PASSporTs (which in SIP would > mean multiple Identity headers, which is permitted) if you wanted to use > multiple mandatory extensions. We aren't envisioning a lot of extensions that > would need to be mandatory today, but the ones that are will probably be > profiles that specify multiple additional claims that will be present in the > PASSporT payload. But we do understand that if you want to mandate relying > party support for both profile A and profile B with a single PASSporT, that isn't > possible in the current syntax - you'd have to send multiple PASSporTs. We're > cool with that. > > Jon Peterson > Neustar, Inc. > > On 9/26/16, 7:25 PM, "Jim Schaad" wrote: > > >So I just got this pointed to me > > > >I am unsure of what the value of "ppt" is supposed to be in one case. > >Is the intention that extensions will only be done serially or can they > >be done in parallel? The first case allows for a high water mark to be > >used until the next one. In the second case the question comes up if > >one wants to use both extension 'a' and extension 'b' in some sense. > >(Consider the case where the extensions are orthogonal to each other by > >requiring different JWT claims to be present.) > > > >In the second case it does not appear to be expressible in the current > >syntax. > > > >Jim > > > >