From nobody Wed Feb 3 00:29:23 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 4AB601B33EA; Wed, 3 Feb 2016 00:29:21 -0800 (PST) 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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160203082921.3498.62135.idtracker@ietfa.amsl.com> Date: Wed, 03 Feb 2016 00:29:21 -0800 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-rfc4474bis-07.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 08:29:21 -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 Working Group 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-07.txt Pages : 35 Date : 2016-02-03 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rfc4474bis-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 Mon Feb 22 11:04:47 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 46F5B1ACDF7; Mon, 22 Feb 2016 11:04:45 -0800 (PST) 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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160222190445.7171.2163.idtracker@ietfa.amsl.com> Date: Mon, 22 Feb 2016 11:04:45 -0800 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-00.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 19:04:45 -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-00.txt Pages : 12 Date : 2016-02-21 Abstract: This document defines a token format for verifying with non- repudiation the sender of and authorization to send information related to the originator of personal communications. A cryptographic signature is defined to protect the integrity of the information used to identify the originator of a personal communications session toward a terminating entity. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the terminating party over a potentially unsecure channel. The Persona Assertion Token (PASSporT) is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and terminating 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-00 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 Mon Feb 22 15:25:25 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D791B2DDF for ; Mon, 22 Feb 2016 15:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.566 X-Spam-Level: X-Spam-Status: No, score=-99.566 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 DRedTH6T5r0s for ; Mon, 22 Feb 2016 15:25:23 -0800 (PST) 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 5B7941B2DCB for ; Mon, 22 Feb 2016 15:25:23 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.15.0.59/8.15.0.59) with SMTP id u1MNMXdW030421 for ; Mon, 22 Feb 2016 18:25:18 -0500 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 216nbfkvas-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 22 Feb 2016 18:25:18 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.140]) by stntexhc10.cis.neustar.com ([169.254.4.23]) with mapi id 14.03.0279.002; Mon, 22 Feb 2016 18:25:17 -0500 From: "Peterson, Jon" To: "stir@ietf.org" Thread-Topic: rfc4474bis and passport Thread-Index: AQHRbchKLvOXXrqxHEabha1wm0gDOw== Date: Mon, 22 Feb 2016 23:25:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [192.168.129.118] Content-Type: multipart/alternative; boundary="_000_D2F0D8DD17A956jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-22_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=1 spamscore=1 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1602220257 Archived-At: Subject: [stir] rfc4474bis and passport X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 23:25:24 -0000 --_000_D2F0D8DD17A956jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we said we would, Chris and I have split out the RFC4474bis text on the = token format into the new specification draft-ietf-stir-passport-00, which = replaces Chris's earlier verified token draft. Right now there's still some remaining alignment to be done between the spe= cifications, but the core mechanisms should be clear. The passport spec is = pretty new though, a -00, so there's still some stubs in it and probably so= me bugs for us to catch. We'd like to invite some comment to get this under= way, as we have a pretty aggressive schedule and we'd like to push to get t= his new spec into good shape by Buenos Aires. So give it a read! Jon Peterson Neustar, Inc. --_000_D2F0D8DD17A956jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <6AC6AFBF3AF842459114788068A9DF0B@neustar.biz> Content-Transfer-Encoding: quoted-printable

As we said we would, Chris and I have split out the RFC4474bis text on= the token format into the new specification draft-ietf-stir-passport-00, w= hich replaces Chris's earlier verified token draft.

Right now there's still some remaining alignment to be done between th= e specifications, but the core mechanisms should be clear. The passport spe= c is pretty new though, a -00, so there's still some stubs in it and probab= ly some bugs for us to catch. We'd like to invite some comment to get this underway, as we have a pretty aggr= essive schedule and we'd like to push to get this new spec into good shape = by Buenos Aires. So give it a read!

Jon Peterson
Neustar, Inc.
--_000_D2F0D8DD17A956jonpetersonneustarbiz_-- From nobody Mon Feb 29 09:38:14 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD21B3857; Mon, 29 Feb 2016 09:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 NDg810YF7BRL; Mon, 29 Feb 2016 09:38:11 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A0E1B383B; Mon, 29 Feb 2016 09:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Mime-Version:To:Message-Id:Date:Subject: Content-Type:From; bh=oGPYfxMh3E3PvNRCw57IOeuTqDt9tP4Y7eCfQLlxfBY=; b=Vx0AqyG pWwjevZ3Uprd1FkNADV/JYzjuiPqUOeHzNJS+s/mLSbyG4hSTJV9mEzTva6eGDuqQ8+/za8CsTtR5 bG3hZC1NZazpE9SflieFUrp1a08ExuUC6FNWGcyYqtFvUfi4omYdycOiNCE6nBGhpamGx7qwtqFhj ENZcDOLPAo=; Received: from 237.sub-70-208-139.myvzw.com ([70.208.139.237]:8004 helo=[192.168.43.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aaRlo-0001Ya-JZ; Mon, 29 Feb 2016 09:38:10 -0800 From: Eric Burger X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_5FF246C9-7A35-422C-85E1-4D20AA81FB7F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Mon, 29 Feb 2016 12:38:05 -0500 Message-Id: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com> To: LURK BoF , stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com Archived-At: Subject: [stir] Way outside the "box" use case X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 17:38:12 -0000 --Apple-Mail=_5FF246C9-7A35-422C-85E1-4D20AA81FB7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the people on the STIR list: there is a potential WG being discussed = in BA, LURK, that is principally looking at the problem of a content = provider somehow allowing a CDN to sign on their behalf so that HTTPS = and browsers =E2=80=9Cdo the right thing.=E2=80=9D If this sounds = /similar/ to the STIR problem of delegated enterprise identity = attestation, it should. See: https://trac.tools.ietf.org/bof/trac/ and scroll down to =E2=80=9CSecurity=E2=80=9D or search for =E2=80=9CLURK=E2= =80=9D. PLEASE, if you care about this issue, continue the discussion on the = LURK list, not the STIR list. Thanks. See: https://www.ietf.org/mailman/listinfo/lurk For the people on the LURK list: I do not necessarily advocate for or = assume the STIR problem is in scope. However, if you and they have a = compelling case for why it should be in scope, or if it is kind of in = scope but appropriate for a later rechartering once we finish the HTTPS = (and possibly DTLS) use case, say so, too. If you are curious about what = STIR is, see: https://trac.tools.ietf.org/wg/stir/charters Thanks, Eric --Apple-Mail=_5FF246C9-7A35-422C-85E1-4D20AA81FB7F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW1IH9AAoJEORoZaSQsc1ItQIP/ihmU+ZBOq4VIenaZk2HI6MR BPttKGP3uZ8dUCgn6k2ZJffhvuGTBQqyhEWyleMsd7td1602qac+zFIePtPH4azL 7lIYwl49BXRmEsseMoPy9roGjJon447CyLgTL5SIn1j7toD+50zmnrdmui/q/m6f 8V/FcqrbypJrdfAv8PVSrB0il1l8PAj3/wAA37yDQsMdMPKp29VJ/XmVReWw0Yvi zV4rL+50sPrr63t84Xd4icxqNCxzjKHJQCSy7cwODUp7XRgwekIyYWnQW9n6HbUi BlpzCokeOvWbORCXupUy3bzx4IJpDCSuX26HegGgU8Mi11ihA4i60Jj1m5MGP/p3 GXxM4MiJ56oCbr33EJQfYvPmj0Rv688wHavkVUyMvj3Yj7am2d/2QSePA/C8iHbR Q/O44xv0cmJTh1VxQpIwain9bkjvB1xM2+N1XOBn0a9PGFw2+X71X0eSMY1wHNbh Sqs6pEJainjk03FuchtT4rBUdcxhwiT0D232kZDAVTi3NhbZWEYIicM5g+G+9cBW oDD+l4H0Uwcy4An27ztl2YSqox5N7dD4Hb+X+gJAU6+0AVhmgU3oYKhvTOxSxy6V +GSioR0Qc77bPyIrdogBNFstl73aF6er6J9EfVotLje5VXpogcN4P5aW4jr80BqW mfqgNAS+ea65hArfVwnh =mpxh -----END PGP SIGNATURE----- --Apple-Mail=_5FF246C9-7A35-422C-85E1-4D20AA81FB7F-- From nobody Mon Feb 29 10:46:58 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41C11B39CE for ; Mon, 29 Feb 2016 10:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 zudoyYoOukOv for ; Mon, 29 Feb 2016 10:46:55 -0800 (PST) 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 3A2381B39CD for ; Mon, 29 Feb 2016 10:46:55 -0800 (PST) Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1TIguSo012200; Mon, 29 Feb 2016 13:46:55 -0500 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 21b7b0g4d6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Feb 2016 13:46:54 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.140]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 29 Feb 2016 13:46:53 -0500 From: "Peterson, Jon" To: Eric Burger , "stir@ietf.org" Thread-Topic: [stir] Way outside the "box" use case Thread-Index: AQHRcxf6inTlLeNKdkiCyGn3/E73eJ9DKp2A Date: Mon, 29 Feb 2016 18:46:53 +0000 Message-ID: References: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com> In-Reply-To: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-originating-ip: [192.168.129.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3998E1B16E6B734F9E91FD2E733C6D42@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-29_07:, , 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-1601100000 definitions=main-1602290356 Archived-At: Subject: Re: [stir] Way outside the "box" use case X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 18:46:56 -0000 I do agree there's a general problem here, actually, and I've given some thought to the relationship between credential delegation in STIR and existing systems like Keyless SSL for CDNs. In SIP networks that have a "roaming" architecture like IMS, something like Keyless SSL could be one way to support STIR - not outside the box at all. Standards along those lines would be welcome. But I think more broadly, the thing we mean when we talk about delegation here in STIR encompasses something different than giving limited use of a private key to a remote administrative domain. There are really different trade offs to consider when there are multiple levels of delegation, when the security association is formed by a call recipient discovering the originator's credential rather than a standard HTTPS flow, and of course when you're dealing with something other than just a DNS name that you hope to delegate, as the properties of telephone numbers aren't the same. Again, not to say that the proposed LURK work wouldn't have some applicability here, for things like roaming and the transient "legitimate" spoofing use cases that we sometimes entertain. But the overlap may turn out to be narrow. Jon Peterson Neustar, Inc. On 2/29/16, 9:38 AM, "stir on behalf of Eric Burger" wrote: >For the people on the STIR list: there is a potential WG being discussed >in BA, LURK, that is principally looking at the problem of a content >provider somehow allowing a CDN to sign on their behalf so that HTTPS and >browsers =B3do the right thing.=B2 If this sounds /similar/ to the STIR >problem of delegated enterprise identity attestation, it should. See: >https://trac.tools.ietf.org/bof/trac/ >and scroll down to =B3Security=B2 or search for =B3LURK=B2. >PLEASE, if you care about this issue, continue the discussion on the LURK >list, not the STIR list. Thanks. See: >https://www.ietf.org/mailman/listinfo/lurk > > >For the people on the LURK list: I do not necessarily advocate for or >assume the STIR problem is in scope. However, if you and they have a >compelling case for why it should be in scope, or if it is kind of in >scope but appropriate for a later rechartering once we finish the HTTPS >(and possibly DTLS) use case, say so, too. If you are curious about what >STIR is, see: >https://trac.tools.ietf.org/wg/stir/charters > >Thanks, >Eric > From nobody Mon Feb 29 12:48:44 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1AA1B3BA7 for ; Mon, 29 Feb 2016 12:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 90_Fy82uNJfA for ; Mon, 29 Feb 2016 12:48:32 -0800 (PST) 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 840DA1B3BCA for ; Mon, 29 Feb 2016 12:48:32 -0800 (PST) X-AuditID: 12074413-f03ff7000000516b-22-56d4ae9fbc7e Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 74.C2.20843.F9EA4D65; Mon, 29 Feb 2016 15:48:31 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u1TKmU6C008764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 29 Feb 2016 15:48:31 -0500 To: stir@ietf.org References: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com> From: Paul Kyzivat Message-ID: <56D4AE9D.6030203@alum.mit.edu> Date: Mon, 29 Feb 2016 15:48:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqDt/3ZUwg4m7NC2Wr93G5MDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7oyrpzYyF+xlrzgx4T97A2MHWxcjJ4eEgInEuuVXgGwuDiGB rYwSXbs7GSGcn0wSjxZdA6sSFjCS6GyaxgxiiwgIStybcZoJxBYScJU4OvEPK4jNJqAlMefQ f5YuRg4OXgFtiRd3uEDCLAKqEldPTmAEsUUF0iRm9U1gAbF5gcacnPkErJxTwE3i9WsJkDCz gK3Enbm7mSFseYnmrbOZJzDyzULSMQtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusWJyfm5aUW 6Zrr5WaW6KWmlG5ihASZ8A7GXSflDjEKcDAq8fDOWHolTIg1say4MvcQoyQHk5Io75s1QCG+ pPyUyozE4oz4otKc1OJDjBIczEoivArtQDnelMTKqtSifJiUNAeLkjiv2hJ1PyGB9MSS1OzU 1ILUIpisDAeHkgQvGzCahASLUtNTK9Iyc0oQ0kwcnCDDuaREilPzUlKLEktLMuJBcRdfDIw8 kBQP0F6wdt7igsRcoChE6ylGXY4FP26vZRJiycvPS5US5w1ZC1QkAFKUUZoHtwKWUl4xigN9 LMy7D6SKB5iO4Ca9AlrCBLREYv0lkCUliQgpqQZGlf7/yrGZ0XnV9lendK+v5p4ffDy00ffB 0u27zs1+as4cYX+hjJtp2vHGa2IZ5/U+nIxYcyzge2iqQhi/jrgXo97+i7qXfRecPxiYGNT7 THUyS6Bu/QXv4HnbLY2CS8q1Lzl9Vl95v2qdiVeuJFur/3zt/Pc8b7/dKCywV2Xbv/o8j9on nvtKLMUZiYZazEXFiQBs8TqsBAMAAA== Archived-At: Subject: Re: [stir] Way outside the "box" use case X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:48:36 -0000 On 2/29/16 12:38 PM, Eric Burger wrote: > For the people on the STIR list: there is a potential WG being discussed in BA, LURK, that is principally looking at the problem of a content provider somehow allowing a CDN to sign on their behalf so that HTTPS and browsers “do the right thing.” If this sounds /similar/ to the STIR problem of delegated enterprise identity attestation, it should. See: > https://trac.tools.ietf.org/bof/trac/ > and scroll down to “Security” or search for “LURK”. > PLEASE, if you care about this issue, continue the discussion on the LURK list, not the STIR list. Thanks. See: > https://www.ietf.org/mailman/listinfo/lurk ISTM that these problems are different, because (I think) in the LURK case the identity is tied to the DNS naming hierarchy, while in STIR is is tied to E.164 numbers. So for LURK I would think there are solutions that naturally link to DNS, but for STIR that won't work. Thanks, Paul From nobody Mon Feb 29 13:26:01 2016 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524AF1B3C73 for ; Mon, 29 Feb 2016 13:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 KFsEQEeH6weP for ; Mon, 29 Feb 2016 13:25:58 -0800 (PST) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4BF1B3C72 for ; Mon, 29 Feb 2016 13:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sMtjgrkPPnXGtNiH75B793UgWLiuX5U3OhpNEUz9+N0=; b=UBpYWZ0I3qgMWp7ray5IlLgRWKyc8CH9Buqz6THBUOTh2cRyny6v1Mc1VdaBOVLlILZ3CcAAoUMDgpe7ZFKbvSJ1nEb06VMFUuxG7JeoE1AbTSKUyfquKsDTRKrHZfxv+hDnhIiOFDVLZAdc89NgFp8RpawC0WXkzNwqlOE8Xu4= From: Henning Schulzrinne To: Paul Kyzivat , "stir@ietf.org" Thread-Topic: [stir] Way outside the "box" use case Thread-Index: AQHRcxgFkCuIHF2RVUmF8nRSvLLkMJ9DfuaAgAAJ86U= Date: Mon, 29 Feb 2016 21:25:53 +0000 Message-ID: References: <6C117DC2-2F50-410C-81DD-4482B0A76D8F@standardstrack.com>, <56D4AE9D.6030203@alum.mit.edu> In-Reply-To: <56D4AE9D.6030203@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=fcc.gov; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 5:ARAks8e7r4ze5uAKmQYOaBNxOIEAefBDDWOJOQ5Wp1iA+M2zlb5J7pM4Cc7HO+q9dgaCMz8eecoEZL5elWeCLaIqAcfLe2lJlEaY3ujWf5ldjZecHruyLIBlVbLuFI2khrX64M3+lDnbpbbMSKIsQQ==; 24:B69KGjV4OAkvbhUrvGvkVbO+YdRACi0FmDWMkmfo8xtrdjKI94ddKeRG2pb746q5cRghCz+0gKBo/RM505tZbIJFHy4qJ64jFUeD3ZBiDMw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0633; x-ms-office365-filtering-correlation-id: bc3e1a08-88b3-4c7a-19eb-08d3414ee7cc x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0867F4F1AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(164054003)(479174004)(122556002)(19580395003)(15975445007)(86362001)(3660700001)(3280700002)(99286002)(5001770100001)(5008740100001)(40100003)(2900100001)(5003600100002)(2950100001)(11100500001)(5001960100003)(2501003)(74316001)(3900700001)(2906002)(92566002)(19580405001)(1096002)(1220700001)(33656002)(5004730100002)(586003)(6116002)(102836003)(189998001)(76576001)(50986999)(54356999)(77096005)(10400500002)(5002640100001)(2171001)(87936001)(107886002)(81156008)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Feb 2016 21:25:53.9664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [stir] Way outside the "box" use case X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 21:26:00 -0000 In addition, the SIP problem (STIR) problem has to manage what elements of = the request are to be signed and validated. This does not appear to be a co= ncern with the CDN case - it's just an HTTP cert. Thus, the intersection ma= y well be "both use PK crypto"... Henning ________________________________________ From: stir on behalf of Paul Kyzivat Sent: Monday, February 29, 2016 3:48 PM To: stir@ietf.org Subject: Re: [stir] Way outside the "box" use case On 2/29/16 12:38 PM, Eric Burger wrote: > For the people on the STIR list: there is a potential WG being discussed = in BA, LURK, that is principally looking at the problem of a content provid= er somehow allowing a CDN to sign on their behalf so that HTTPS and browser= s =93do the right thing.=94 If this sounds /similar/ to the STIR problem of= delegated enterprise identity attestation, it should. See: > https://trac.tools.ietf.org/bof/trac/ > and scroll down to =93Security=94 or search for =93LURK=94. > PLEASE, if you care about this issue, continue the discussion on the LURK= list, not the STIR list. Thanks. See: > https://www.ietf.org/mailman/listinfo/lurk ISTM that these problems are different, because (I think) in the LURK case the identity is tied to the DNS naming hierarchy, while in STIR is is tied to E.164 numbers. So for LURK I would think there are solutions that naturally link to DNS, but for STIR that won't work. Thanks, Paul _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir