From nobody Wed Jun 1 02:10: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 8107512D154 for ; Wed, 1 Jun 2016 02:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tlQdrrW3gNGF for ; Wed, 1 Jun 2016 02:10:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F5E12B009 for ; Wed, 1 Jun 2016 02:10:02 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-34-574ea66861b7 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.2A.12516.866AE475; Wed, 1 Jun 2016 11:10:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 11:10:00 +0200 From: Christer Holmberg To: "Peterson, Jon" , Chris Wendt , IETF STIR Mail List Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1QyoYpKCRWukGCcfM/wDhgL5/ToDcAgADFnYA= Date: Wed, 1 Jun 2016 09:09:59 +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.4.160422 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7lm7GMr9wg6VHpSymf9rNbHGmwdJi +dptTA7MHhP61rB6LFnyk8ljR8Nz5gDmKC6blNSczLLUIn27BK6MqbtECxqMKzbO6mZsYLxh 2MXIySEhYCJxprONCcIWk7hwbz1bFyMXh5DAEUaJCa/XMUI4ixklpnWvZu1i5OBgE7CQ6P6n DdIgIlAncefeG3YQW1jAS+Lu/1/MEHFvie835jBB2FYSk/fvBKthEVCRuPH5MQuIzQsUf/7v I1hcSCBPoudlF5jNKWAusfTZUUYQmxHooO+n1oDNYRYQl7j1ZD7UoQISS/acZ4awRSVePv7H CmKLCuhJfLk3jxHkTAkBRYnl/XIQrVoSX37sY4OwrSW6r9xmhLAVJaZ0P2SHOEdQ4uTMJywT GMVnIdk2C0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYPQd3PJb dwfj6teOhxgFOBiVeHgTOP3ChVgTy4orcw8xSnAwK4nwCk4GCvGmJFZWpRblxxeV5qQWH2KU 5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamC0ONZUFvjmteIJyatFvLN/ybNc+fWAW7dj L2smv8Jf/3NO25fxzLh4p+PFilMBWyUdBEPX/57ltkUotNtc+ciVqOUvVJpit9VPv/Elqi38 hIjmsmf9J7kj7y/ZPuPK7IVtW05Z7u/X/KFrJuQmc7LycPP3fw+/Clxv26Jks1lX+P46XeUJ qYp7lViKMxINtZiLihMBs8C0P7oCAAA= Archived-At: Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 09:10:05 -0000 SGksDQoNCklmIEkgdW5kZXJzdGFuZCB0aGUgcHJvcG9zYWwgY29ycmVjdGx5LCB0aGUgcmVhc29u IHdlIG1heSBub3Qgd2FudCB0byBzZW5kDQp0aGUgSldUIGNsYWltcyBpcyBiZWNhdXNlIHlvdaGv bGwgZmluZCB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiBTSVAgaGVhZGVyDQpmaWVsZHMsIGFuZCB3 ZSB3aWxsIHVzZSB0aGUgU0lQIGhlYWRlciBmaWVsZCBpbmZvcm1hdGlvbiB3aGVuIGNhbGN1bGF0 aW5nDQooc2VuZGVyKSBhbmQgdmVyaWZ5aW5nIChyZWNlaXZlcikgdGhlIEpXVCBzaWduYXR1cmUu DQoNCk5vdywga2VlcCBpbiBtaW5kIHRoYXQsIHdoZW4geW91IGNhbGN1bGF0ZSB0aGUgSldUIHNp Z25hdHVyZSB1c2luZyB0aGUgSldUDQpjbGFpbXMsIGVhY2ggY2xhaW0gdmFsdWUgaXMgY29uc2lk ZXJlZCBhIHN0cmluZywgd2hpY2ggbWVhbnMgZXZlcnkNCmNoYXJhY3RlciAoaW5jbHVkaW5nIHNw YWNlIGNoYXJhY3RlcnMpIGNvdW50IHdoZW4gY2FsY3VsYXRpbmcgdGhlDQpzaWduYXR1cmUuDQoN CkZvciBleGFtcGxlLCBpZiBvbmUgY2xhaW0gcmVwcmVzZW50cyB0aGUgU0lQIENzZXEgdmFsdWU6 DQoNCnsNCgmhsENTZXEiOiChsDEyMzQ8U1A+SU5WSVRFobENCn0NCg0KoaZ3aWxsIG5vdCAoYWZh aWspIHByb2R1Y2UgdGhlIHNhbWUgc2lnbmF0dXJlIHZhbHVlIGFzOg0KDQp7DQogICAgICAgIKGw Q1NlcSI6IKGwMTIzNDxTUD48U1A+PFNQPklOVklURaGxDQp9DQoNCg0KDQoNCkluIFNJUCBoZWFk ZXJzLCB5b3UgY2FuIG5vdCBndWFyYW50ZWUgdGhhdCB3aGF0IGlzIHNlbnQgaXMgd2hhdCB3aWxs IGJlDQpyZWNlaXZlZC4gVGhlcmUgbWF5IGJlIGFkZGl0aW9uYWwgc3BhY2UgY2hhcmFjdGVycywg dGhlcmUgbWF5IGJlIGxpbmVhcg0Kd2hpdGVzcGFjZXMgZXRjLiBTbywgd2hlbiB0aGUgcmVjZWl2 ZXIgdHJpZXMgdG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUsIGl0DQptYXkgZmFpbC4NCg0KRm9yIGV4 YW1wbGUsIGlmIHRoZSBzZW5kZXIgc2VuZHM6DQoNCkNTZXE6IDEyMzQ8U1A+SU5WSVRFDQoNCqGm aXQgbWF5IHJlY2VpdmU6DQoNCkNTZXE6IDEyMzQ8TFdTPklOVklURQ0KDQqhpmluIHdoaWNoIGNh c2UgdGhlIHNpZ25hdHVyZSBjYWxjdWxhdGVkIGJ5IHRoZSByZWNlaXZlciB3aWxsIG5vdCBtYXRj aA0KdmFsdWUgc2lnbmF0dXJlIGNhbGN1bGF0ZWQgYnkgdGhlIHNlbmRlciAoYXNzdW1pbmcgc3Bh Y2UgY2hhcmFjdGVycyBldGMNCmFyZSBhbHNvIHVzZWQgd2hlbiBjYWxjdWxhdGluZyB0aGUgc2ln bmF0dXJlKS4NCg0KU28sIElGIHdlIHdhbnQgdG8gY2FsY3VsYXRlIHRoZSBzaWduYXR1cmUgYmFz ZWQgb24gU0lQIGhlYWRlciBmaWxlZA0KdmFsdWVzLCBJIHRoaW5rIHdlIG5lZWQgdG8gZGVmaW5l IGEgd2F5IG9mIGNhbm9uaWNhbGlzaW5nIHRoZW0uDQoNCk9yLCBoYXZlIEkgbWlzdW5kZXJzdG9v ZCBzb21ldGhpbmc/IDopDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAwMS8wNi8x NiAwMzoyNSwgInN0aXIgb24gYmVoYWxmIG9mIFBldGVyc29uLCBKb24iDQo8c3Rpci1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXo+IHdyb3RlOg0K DQo+DQo+VGhpcyBpcyBhIHBvaW50IHRoYXQgQ2hyaXMgYW5kIEkgaGF2ZSBkaXNjdXNzZWQgYSBi aXQgYmVmb3JlLCBhbmQgaXMgb25lDQo+b2YgdGhvc2UgaXNzdWVzIHRoYXQgaXMgaGFyZCB0byBy ZXNvbHZlIGJlY2F1c2UgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4NCj50aGUgdHdvIGNob2ljZXMg YXJlIHNvIHNtYWxsLg0KPg0KPj5Gcm9tIG15IHBlcnNwZWN0aXZlLCBtYWtpbmcgaW1wbGVtZW50 YXRpb25zIHNlbmQgImNhbm9uIiBieSBkZWZhdWx0LA0KPj53aGlsZQ0KPmxlYXZpbmcgdGhlIG9w dGlvbiB0byBleGNsdWRlIGl0LCByZXF1aXJlcyB0aGUgc2FtZSB0d28gY29kZSBwYXRocyB0bw0K PmV4aXN0IGFzIHdlIGRvIHdoZW4gd2UgZG9uJ3Qgc2VuZCAiY2Fub24iIGJ5IGRlZmF1bHQsIGFu ZCBsZWF2ZSB0aGUgb3B0aW9uDQo+dG8gaW5jbHVkZSBpdC4gQW5kIHllcywgdGhlIGFyZ3VtZW50 IG5vdCB0byBzZW5kIGl0IGJlIGRlZmF1bHQgaXMgc2ltcGx5DQo+dG8gcmVkdWNlIG1lc3NhZ2Ug c2l6ZSwgZ2l2ZW4gdGhlIGZpZWxkcyBpbiBjYW5vbiBhcmUgbmVjZXNzYXJpbHkNCj5yZWR1bmRh bnQgd2l0aCB2YXJpb3VzIGhlYXJlciBmaWVsZCB2YWx1ZXMgYW5kIHBhcmFtZXRlcnMgaW4gU0lQ LiBJbiBzb21lDQo+ZW52aXJvbm1lbnRzLCBJIHN0aWxsIGhlYXIgdGhhdCBtZXNzYWdlIHNpemUg aXMgYSBjb25jZXJuLiBUaGF0J3Mgd2h5DQo+d2UndmUgc2V0IGl0IHRoaXMgd2F5IG5vdy4gSXQg bWlnaHQgdHVybiBvdXQgaW4gZGVwbG95bWVudCB0aGF0IHdlIG5lZWQNCj4iY2Fub24iIG1vcmUg b2Z0ZW4gdGhhdCB3ZSdkIHRoaW5rLCBiZWNhdXNlIG9mIHRoaW5ncyBsaWtlIERhdGUgaGVhZGVy DQo+Y2hhbmdlcywgc2F5LiBJJ2QgYmUgd2lsbGluZyB0byByZXZpc2l0IHRoaXMgd2hlbiB3ZSBo YXZlIGEgYml0IG1vcmUNCj5leHBlcmllbmNlIHVuZGVyIG91ciBjb2xsZWN0aXZlIGJlbHRzLg0K Pg0KPlVsdGltYXRlbHksIGFzIENocmlzIHNheXMsIGEgdmVyaWZpY2F0aW9uIHNlcnZpY2Ugd2ls bCBuZWVkIHRvIGJhc2ljYWxseQ0KPnJlY29uc3RydWN0IHRoZSBoZWFkZXIgYW5kIGNsYWltcyBp dHNlbGYgYW55d2F5IGZyb20gdGhlIFNJUCByZXF1ZXN0IC0gb3INCj5hdCBsZWFzdCB0aGF0IHRo ZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHJlY29uc3RydWN0aW5nIHRoZW0gb24gdGhlIG9uZSBoYW5k DQo+YW5kIGV4dHJhY3RpbmcgZWFjaCBpbmRpdmlkdWFsIGZpZWxkIHRvIGNvbXBhcmUgdGhlbSB0 byB0aGUgY29ycmVzcG9uZGluZw0KPmhlYWRlcnMgYW5kIGNsYWltcyBvZiB0aGUgY2Fub25pY2Fs IEpXVCBvYmplY3Qgb24gdGhlIG90aGVyIGhhbmQgc2VlbQ0KPnVubGlrZWx5IHRvIGdlbnVpbmVs eSBpbXBhY3QgZWl0aGVyIHRoZSBkaWZmaWN1bHR5IG9mIGltcGxlbWVudGF0aW9uIG9yDQo+dGhl IGNvbXB1dGUgY3ljbGVzIHJlcXVpcmVkLg0KPg0KPkJ1dCBsaWtlIENocmlzLCBJJ20gaW50ZXJl c3RlZCB0byBoZWFyIHBlb3BsZSdzIHRob3VnaHRzIG9uIHRoaXMsIGFuZCBJJ20NCj5ub3QgZGVl cGx5IGNvbW1pdHRlZCB0byBlaXRoZXIgYXBwcm9hY2guDQo+DQo+Sm9uIFBldGVyc29uDQo+TmV1 c3RhciwgSW5jLg0KPg0KPk9uIDUvMzEvMTYsIDY6MDYgQU0sICJzdGlyIG9uIGJlaGFsZiBvZiBD aHJpcyBXZW5kdCINCj48c3Rpci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpcy1p ZXRmQGNocmlzd2VuZHQubmV0PiB3cm90ZToNCj4NCj4+SGkgQWxsLA0KPj4NCj4+VGhlcmUgd2Fz IGEgZGlzY3Vzc2lvbiBvbiB0aGUgU1RJUiBpbnRlcmltIGNhbGwgYWJvdXQgd2hldGhlciB0aGVy ZSBpcw0KPj5hbnkgc3Ryb25nIHJlYXNvbnMgdG8gY29uc2lkZXIgdXNpbmcgdGhlIGZ1bGwgUEFT U3BvclQNCj4+KGhlYWRlci5jbGFpbXMuc2lnbmF0dXJlKSBhcyB0aGUgZGVmYXVsdCBmb3IgdGhl IGlkZW50aXR5IGhlYWRlciBpbg0KPj40NDc0YmlzLg0KPj4NCj4+VGhlIHByaW1hcnkgYXJndW1l bnQgZm9yIHRoZSBmdWxsIHRva2VuIGJlaW5nIGRlZmF1bHQgd291bGQgYmUsIGl0IG1heSBiZQ0K Pj5tb3JlIGVmZmljaWVudCBmcm9tIGFuIGltcGxlbWVudGF0aW9uIHBvaW50IG9mIHZpZXcgdG8g aGF2ZSB0aGUNCj4+Y29uc3RydWN0ZWQgdG9rZW4gYXZhaWxhYmxlIHRvIHRoZSB2ZXJpZmljYXRp b24gc2VydmljZSB0byBkaXJlY3RseQ0KPj52YWxpZGF0ZSBzaWduYXR1cmUuICBXaXRoIHRoZSBj YXZlYXQgdGhhdCBpbiBlaXRoZXIgY2FzZSB5b3UgZWl0aGVyIG5lZWQNCj4+dG8gcmUtY29uc3Ry dWN0IHRoZSBoZWFkZXIuY2xhaW1zIG9yIHlvdSBuZWVkIHRvIGRlY29kZSB0aGUgQmFzZTY0IHRv IGdldA0KPj50aGUgSlNPTiBoZWFkZXIgYW5kIGNsYWltcyB0byB2ZXJpZnkgdGhhdCB0aGUgdmFs dWVzIGNvcnJlc3BvbmQgdG8gdmFsdWVzDQo+PmluIHRoZSBTSVAgaGVhZGVyLg0KPj4NCj4+VGhl IHByaW1hcnkgYXJndW1lbnQgZm9yIHRoZSBjdXJyZW50IGRlZmF1bHQgb2Ygb25seSBpbmNsdWRp bmcgdGhlDQo+PnNpZ25hdHVyZSwgaXMgdG8gc2F2ZSB0aGUgODAtMTAwIGJ5dGVzIG9mIKn4ZHVw bGljYXRlqfcgaW5mb3JtYXRpb24gaW4gdGhlDQo+PlNJUCBwYXlsb2FkLg0KPj4NCj4+RmVlbCBm cmVlIHRvIHJld29yZCBpZiBpIGRpZG6p9nQgY2FwdHVyZSB0aGUgbWFpbiBhcmd1bWVudHMgY29y cmVjdGx5Lg0KPj4NCj4+V291bGQgbGlrZSB0byBnZXQgb3RoZXIgb3BpbmlvbnMgb3Igb3RoZXIg YXJndW1lbnRzIGZvciBvciBhZ2FpbnN0DQo+PmtlZXBpbmcgdGhpbmdzIHRoZSB3YXkgdGhleSBh cmUgb3IgY29uc2lkZXJpbmcganVzdCB1c2luZyB0aGUgZnVsbA0KPj5QQVNTcG9yVCB0b2tlbiBp biB0aGUgaWRlbnRpdHkgaGVhZGVyLg0KPj4NCj4+VGhhbmtzLg0KPj4NCj4+LUNocmlzDQo+Pl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnN0aXIgbWFp bGluZyBsaXN0DQo+PnN0aXJAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zdGlyDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5zdGlyIG1haWxpbmcgbGlzdA0KPnN0aXJAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg0K From nobody Wed Jun 1 05:35: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 612A612D1A6 for ; Wed, 1 Jun 2016 05:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktKy8516m2IQ for ; Wed, 1 Jun 2016 05:34:57 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8947E12D184 for ; Wed, 1 Jun 2016 05:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Cc:Date: In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=MRAW9ISjyOCqgqz0lKDBB2+3fFKchR8c0ZFK/CL0/Yg=; b=iqExcZsY4EV/ATXuPi+3bMD+Mr oLwe2YXi0eISSli6swy29NZsxBN03MbcaPI3AyUQljUzxPHOr4nVK11h0/f/PIocfKfarWo/Wv+Wy CSqRUAbea/7Gvp9UEf9bhiKgHKD76RMSj2BoR2vonodvZw3x7WQ43tLWxswyBap42AU0=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:52991 helo=[192.168.15.108]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b85MK-0001uA-Vl; Wed, 01 Jun 2016 05:34:57 -0700 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7F91BC4B-4E83-4A23-A0F5-03A2EEEDD0C2"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: Date: Wed, 1 Jun 2016 08:35:01 -0400 Message-Id: References: To: Holmberg Christer X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 12:34:59 -0000 --Apple-Mail=_7F91BC4B-4E83-4A23-A0F5-03A2EEEDD0C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is the munging of SP to LWS real or theoretical? If real, no wonder = end-to-end signed signaling NEVER worked. If theoretical, we can safely = ignore it. > On Jun 1, 2016, at 5:09 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > If I understand the proposal correctly, the reason we may not want to = send > the JWT claims is because you=E2=80=99ll find the same information in = SIP header > fields, and we will use the SIP header field information when = calculating > (sender) and verifying (receiver) the JWT signature. >=20 > Now, keep in mind that, when you calculate the JWT signature using the = JWT > claims, each claim value is considered a string, which means every > character (including space characters) count when calculating the > signature. >=20 > For example, if one claim represents the SIP Cseq value: >=20 > { > =E2=80=9CCSeq": =E2=80=9C1234INVITE=E2=80=9D > } >=20 > =E2=80=A6will not (afaik) produce the same signature value as: >=20 > { > =E2=80=9CCSeq": =E2=80=9C1234INVITE=E2=80=9D > } >=20 >=20 >=20 >=20 > In SIP headers, you can not guarantee that what is sent is what will = be > received. There may be additional space characters, there may be = linear > whitespaces etc. So, when the receiver tries to verify the signature, = it > may fail. >=20 > For example, if the sender sends: >=20 > CSeq: 1234INVITE >=20 > =E2=80=A6it may receive: >=20 > CSeq: 1234INVITE >=20 > =E2=80=A6in which case the signature calculated by the receiver will = not match > value signature calculated by the sender (assuming space characters = etc > are also used when calculating the signature). >=20 > So, IF we want to calculate the signature based on SIP header filed > values, I think we need to define a way of canonicalising them. >=20 > Or, have I misunderstood something? :) >=20 >=20 > Regards, >=20 > Christer >=20 >=20 > On 01/06/16 03:25, "stir on behalf of Peterson, Jon" > wrote: >=20 >>=20 >> This is a point that Chris and I have discussed a bit before, and is = one >> of those issues that is hard to resolve because the differences = between >> the two choices are so small. >>=20 >>> =46rom my perspective, making implementations send "canon" by = default, >>> while >> leaving the option to exclude it, requires the same two code paths to >> exist as we do when we don't send "canon" by default, and leave the = option >> to include it. And yes, the argument not to send it be default is = simply >> to reduce message size, given the fields in canon are necessarily >> redundant with various hearer field values and parameters in SIP. In = some >> environments, I still hear that message size is a concern. That's why >> we've set it this way now. It might turn out in deployment that we = need >> "canon" more often that we'd think, because of things like Date = header >> changes, say. I'd be willing to revisit this when we have a bit more >> experience under our collective belts. >>=20 >> Ultimately, as Chris says, a verification service will need to = basically >> reconstruct the header and claims itself anyway from the SIP request = - or >> at least that the differences between reconstructing them on the one = hand >> and extracting each individual field to compare them to the = corresponding >> headers and claims of the canonical JWT object on the other hand seem >> unlikely to genuinely impact either the difficulty of implementation = or >> the compute cycles required. >>=20 >> But like Chris, I'm interested to hear people's thoughts on this, and = I'm >> not deeply committed to either approach. >>=20 >> Jon Peterson >> Neustar, Inc. >>=20 >> On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt" >> wrote: >>=20 >>> Hi All, >>>=20 >>> There was a discussion on the STIR interim call about whether there = is >>> any strong reasons to consider using the full PASSporT >>> (header.claims.signature) as the default for the identity header in >>> 4474bis. >>>=20 >>> The primary argument for the full token being default would be, it = may be >>> more efficient from an implementation point of view to have the >>> constructed token available to the verification service to directly >>> validate signature. With the caveat that in either case you either = need >>> to re-construct the header.claims or you need to decode the Base64 = to get >>> the JSON header and claims to verify that the values correspond to = values >>> in the SIP header. >>>=20 >>> The primary argument for the current default of only including the >>> signature, is to save the 80-100 bytes of =C2=B3duplicate=C2=B2 = information in the >>> SIP payload. >>>=20 >>> Feel free to reword if i didn=C2=B9t capture the main arguments = correctly. >>>=20 >>> Would like to get other opinions or other arguments for or against >>> keeping things the way they are or considering just using the full >>> PASSporT token in the identity header. >>>=20 >>> Thanks. >>>=20 >>> -Chris >>> _______________________________________________ >>> 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 --Apple-Mail=_7F91BC4B-4E83-4A23-A0F5-03A2EEEDD0C2 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 iQIcBAEBCAAGBQJXTtZ1AAoJEORoZaSQsc1IB3MQAJRLvf6lJtWzjz1PZoO91l18 wWIf6upuay4xrktdVTJxx4ZwOC98D91GB0EMv67gG5NL9c8Y4PsNYokIEcRWdr5g HImxZId5THijiM7WRsKi8dqieNNh8XD2ZxqurqxdCaA18GZNybCKSIeS1T7xChvo 2D+VAY/oJCjWT9kRsieuc9AjB8MvZgKKPNfdlCu8sRtdvAx1er2b8Uj2FdTZgUBv RvvLld3hW9x4qoqHyg76GhLYFBNsvs7i1flY3oQjaFaBeDHvZh/IIKKu5UJbteow 8o8Ao4tjR0gypXgc7vtz+xHT8bA+8o/M+Lz9im2gCFsS/9UnmAP/ZVPIxUsGNIEO ZQKfaeeaInZRk9QHP+wEzIorYg4KSqTZDRINyFtmYBez9cn5X5fLVudNjawOWeMs 5/Y/k/9PQVS1pTXhi9aV36MYL6Ri+k+T1qLM9srJl1k/QPPl8QVQmJRwt6hHUrLy QVKMkS0UQhbTFJtyb6wOluVqXXifH0XqnpZ/1gy/qu/ev8hOGKXx3w2UNFxvK9Oi 1JxnzT3rfyS7vTb+FGzCc1s5CIl/zirUZ3hI05eFo+a6OZC9UCz9X+2NrGq/qMPU ZWPLzEAjXOLGcT2KqtgjtF+BNpOFy8fqtX9Zr/KCcuiP5mez2yKjX6OHwzJPWPfX Dsg35ZwK7KW2OgGl5TgV =BuU/ -----END PGP SIGNATURE----- --Apple-Mail=_7F91BC4B-4E83-4A23-A0F5-03A2EEEDD0C2-- From nobody Wed Jun 1 05:57: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 7E73A12D1AF for ; Wed, 1 Jun 2016 05:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 kGFl3xRHryvD for ; Wed, 1 Jun 2016 05:56:53 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 822E712D1B7 for ; Wed, 1 Jun 2016 05:56:53 -0700 (PDT) Received: (qmail 4392 invoked by uid 0); 1 Jun 2016 12:56:52 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 1 Jun 2016 12:56:52 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 1Qwj1t01N1MNPNq01Qwm4Y; Wed, 01 Jun 2016 06:56:51 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=fGh7L_e3oJcA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=w1VtefKfAAAA:8 a=NeqspbrH7xDAEFVF6UAA:9 a=QlDm5W_8UTLP-pl7:21 a=oifHL6h82L4ST7h_:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Q-ofuW86YyylptHqTH-7:22 a=xm8PXHvXF9WL09pmvKgj:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=CcxeCn3p/AHsypeoYoLX5P7yNSmSAVyS44ZHL4mR06s=; b=i6xqqnsa3nxNgjg4NZ4qXHNmbk LFfJCaewfUdyCzMMfZDx6uw8ubMtgYkL9O10Zkl9PkmkP3SE9YojkY1SY+KhtJBLNRKOrwlm9ajge Gby55C6PGjWqthrSfyij5xLo8; Received: from [100.36.21.178] (port=50057 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b85hU-0003oU-KZ; Wed, 01 Jun 2016 06:56:44 -0600 User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Wed, 01 Jun 2016 08:56:37 -0400 From: Richard Shockey To: "Peterson, Jon" , Chris Wendt , IETF STIR Mail List Message-ID: <6237EF46-1233-4023-A172-D8A78B4A2EAE@shockey.us> Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.21.178 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.21.178 X-Exim-ID: 1b85hU-0003oU-KZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.152]) [100.36.21.178]:50057 X-Source-Auth: richard+shockey.us X-Email-Count: 0 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 12:56:59 -0000 Well if the size of the INVITE is the concern, I would argue that we have c= rossed that Rubicon years ago or as Caesar said, =C4=81lea iacta est ("the die h= as been cast"). My concern, as Chris points out, are implementation issues = and that seems to argue that the full token should be the default. Speaking of implementation, my concern with these documents are that there = are insufficient examples to guide implementers on what to expect or at the = very least what a STIR enabled INVITE would look like as it reaches the Vali= dation service and eventually as it reaches the UA. We don=E2=80=99t need a full = 5359 but something more than what we have now. Based on what I see now I w= ouldn=E2=80=99t know how to code a product to make this work. On 5/31/16, 8:25 PM, "stir on behalf of Peterson, Jon" wrote: > >This is a point that Chris and I have discussed a bit before, and is one >of those issues that is hard to resolve because the differences between >the two choices are so small. > >>From my perspective, making implementations send "canon" by default, whil= e >leaving the option to exclude it, requires the same two code paths to >exist as we do when we don't send "canon" by default, and leave the option >to include it. And yes, the argument not to send it be default is simply >to reduce message size, given the fields in canon are necessarily >redundant with various hearer field values and parameters in SIP. In some >environments, I still hear that message size is a concern. That's why >we've set it this way now. It might turn out in deployment that we need >"canon" more often that we'd think, because of things like Date header >changes, say. I'd be willing to revisit this when we have a bit more >experience under our collective belts. > >Ultimately, as Chris says, a verification service will need to basically >reconstruct the header and claims itself anyway from the SIP request - or >at least that the differences between reconstructing them on the one hand >and extracting each individual field to compare them to the corresponding >headers and claims of the canonical JWT object on the other hand seem >unlikely to genuinely impact either the difficulty of implementation or >the compute cycles required. > >But like Chris, I'm interested to hear people's thoughts on this, and I'm >not deeply committed to either approach. > >Jon Peterson >Neustar, Inc. > >On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt" > wrote: > >>Hi All, >> >>There was a discussion on the STIR interim call about whether there is >>any strong reasons to consider using the full PASSporT >>(header.claims.signature) as the default for the identity header in >>4474bis. >> >>The primary argument for the full token being default would be, it may be >>more efficient from an implementation point of view to have the >>constructed token available to the verification service to directly >>validate signature. With the caveat that in either case you either need >>to re-construct the header.claims or you need to decode the Base64 to get >>the JSON header and claims to verify that the values correspond to values >>in the SIP header. >> >>The primary argument for the current default of only including the >>signature, is to save the 80-100 bytes of =C2=B3duplicate=C2=B2 information in th= e >>SIP payload. >> >>Feel free to reword if i didn=C2=B9t capture the main arguments correctly. >> >>Would like to get other opinions or other arguments for or against >>keeping things the way they are or considering just using the full >>PASSporT token in the identity header. >> >>Thanks. >> >>-Chris >>_______________________________________________ >>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 From nobody Wed Jun 1 05:58: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 0F7AC12D1B6 for ; Wed, 1 Jun 2016 05:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3ckOTUuhnpBh for ; Wed, 1 Jun 2016 05:58:15 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 5497912D1AF for ; Wed, 1 Jun 2016 05:58:15 -0700 (PDT) Received: (qmail 19470 invoked by uid 0); 1 Jun 2016 12:58:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 1 Jun 2016 12:58:15 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 1QyA1t00c1MNPNq01QyDvR; Wed, 01 Jun 2016 06:58:14 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=fGh7L_e3oJcA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=bfLuiRfvAAAA:8 a=0FD05c-RAAAA:8 a=hGBaWAWWAAAA:8 a=w1VtefKfAAAA:8 a=KMi6XqmRiYTtrzCyJVAA:9 a=TSm2g3n0vgJxeyuO:21 a=LqD77t26GrZxqrfA:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=u7KogQI6p9ntt2sFUKYF:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=Q-ofuW86YyylptHqTH-7:22 a=xm8PXHvXF9WL09pmvKgj:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:CC:To:From:Subject:Date; bh=Yej/cMQ4jDeLh3fFpoJxgbuSCKrMNbyL1Q65c3OqIUw=; b=C6UPgghrg+DPgrbbEi7HgcMkae 0tVAHFmExgLb0K8QDcOjIBwnEGLFZY9JeIOwidplKxq6Wl6NKECtzsN1BdhLz26kcnXo5boFZZJ46 P8X6fSS/6vfPTjOVA5pdUN+Jn; Received: from [100.36.21.178] (port=50057 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1b85is-0003oU-19; Wed, 01 Jun 2016 06:58:10 -0600 User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Wed, 01 Jun 2016 08:58:09 -0400 From: Richard Shockey To: Eric Burger , Holmberg Christer Message-ID: <11D6D651-B98A-4F87-9A3B-CBEA9F3B6200@shockey.us> Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.21.178 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.21.178 X-Exim-ID: 1b85is-0003oU-19 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.152]) [100.36.21.178]:50057 X-Source-Auth: richard+shockey.us X-Email-Count: 0 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 12:58:18 -0000 Thank you Eric .. I was thinking the same thing. =20 On 6/1/16, 8:35 AM, "stir on behalf of Eric Burger" wrote: >Is the munging of SP to LWS real or theoretical? If real, no wonder end-to= -end signed signaling NEVER worked. If theoretical, we can safely ignore it. > >> On Jun 1, 2016, at 5:09 AM, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >> If I understand the proposal correctly, the reason we may not want to se= nd >> the JWT claims is because you=E2=80=99ll find the same information in SIP head= er >> fields, and we will use the SIP header field information when calculatin= g >> (sender) and verifying (receiver) the JWT signature. >>=20 >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >>=20 >> For example, if one claim represents the SIP Cseq value: >>=20 >> { >> =E2=80=9CCSeq": =E2=80=9C1234INVITE=E2=80=9D >> } >>=20 >> =E2=80=A6will not (afaik) produce the same signature value as: >>=20 >> { >> =E2=80=9CCSeq": =E2=80=9C1234INVITE=E2=80=9D >> } >>=20 >>=20 >>=20 >>=20 >> In SIP headers, you can not guarantee that what is sent is what will be >> received. There may be additional space characters, there may be linear >> whitespaces etc. So, when the receiver tries to verify the signature, it >> may fail. >>=20 >> For example, if the sender sends: >>=20 >> CSeq: 1234INVITE >>=20 >> =E2=80=A6it may receive: >>=20 >> CSeq: 1234INVITE >>=20 >> =E2=80=A6in which case the signature calculated by the receiver will not match >> value signature calculated by the sender (assuming space characters etc >> are also used when calculating the signature). >>=20 >> So, IF we want to calculate the signature based on SIP header filed >> values, I think we need to define a way of canonicalising them. >>=20 >> Or, have I misunderstood something? :) >>=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> On 01/06/16 03:25, "stir on behalf of Peterson, Jon" >> wrote: >>=20 >>>=20 >>> This is a point that Chris and I have discussed a bit before, and is on= e >>> of those issues that is hard to resolve because the differences between >>> the two choices are so small. >>>=20 >>>> From my perspective, making implementations send "canon" by default, >>>> while >>> leaving the option to exclude it, requires the same two code paths to >>> exist as we do when we don't send "canon" by default, and leave the opt= ion >>> to include it. And yes, the argument not to send it be default is simpl= y >>> to reduce message size, given the fields in canon are necessarily >>> redundant with various hearer field values and parameters in SIP. In so= me >>> environments, I still hear that message size is a concern. That's why >>> we've set it this way now. It might turn out in deployment that we need >>> "canon" more often that we'd think, because of things like Date header >>> changes, say. I'd be willing to revisit this when we have a bit more >>> experience under our collective belts. >>>=20 >>> Ultimately, as Chris says, a verification service will need to basicall= y >>> reconstruct the header and claims itself anyway from the SIP request - = or >>> at least that the differences between reconstructing them on the one ha= nd >>> and extracting each individual field to compare them to the correspondi= ng >>> headers and claims of the canonical JWT object on the other hand seem >>> unlikely to genuinely impact either the difficulty of implementation or >>> the compute cycles required. >>>=20 >>> But like Chris, I'm interested to hear people's thoughts on this, and I= 'm >>> not deeply committed to either approach. >>>=20 >>> Jon Peterson >>> Neustar, Inc. >>>=20 >>> On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt" >>> wrote: >>>=20 >>>> Hi All, >>>>=20 >>>> There was a discussion on the STIR interim call about whether there is >>>> any strong reasons to consider using the full PASSporT >>>> (header.claims.signature) as the default for the identity header in >>>> 4474bis. >>>>=20 >>>> The primary argument for the full token being default would be, it may= be >>>> more efficient from an implementation point of view to have the >>>> constructed token available to the verification service to directly >>>> validate signature. With the caveat that in either case you either ne= ed >>>> to re-construct the header.claims or you need to decode the Base64 to = get >>>> the JSON header and claims to verify that the values correspond to val= ues >>>> in the SIP header. >>>>=20 >>>> The primary argument for the current default of only including the >>>> signature, is to save the 80-100 bytes of =C2=B3duplicate=C2=B2 information in= the >>>> SIP payload. >>>>=20 >>>> Feel free to reword if i didn=C2=B9t capture the main arguments correctly. >>>>=20 >>>> Would like to get other opinions or other arguments for or against >>>> keeping things the way they are or considering just using the full >>>> PASSporT token in the identity header. >>>>=20 >>>> Thanks. >>>>=20 >>>> -Chris >>>> _______________________________________________ >>>> 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 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Wed Jun 1 07:16: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 D51FF12D590 for ; Wed, 1 Jun 2016 07:16:36 -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 8m1amy6M-Vug for ; Wed, 1 Jun 2016 07:16:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AFC12D511 for ; Wed, 1 Jun 2016 07:16:33 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-6d-574eee3f0b17 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.1C.27088.F3EEE475; Wed, 1 Jun 2016 16:16:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 16:16:30 +0200 From: Christer Holmberg To: Richard Shockey , Eric Burger Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1QyoYpKCRWukGCcfM/wDhgL5/ToDcAgADFnYCAAAYxgIAABneAgAA3bKA= Date: Wed, 1 Jun 2016 14:16:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3802AB31@ESESSMB209.ericsson.se> References: , <11D6D651-B98A-4F87-9A3B-CBEA9F3B6200@shockey.us> In-Reply-To: <11D6D651-B98A-4F87-9A3B-CBEA9F3B6200@shockey.us> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3802AB31ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7lK79O79wg5Wf1Cym7epltZjxw8Bi +dptTA7MHkuW/GTymPjxDLNHU+di9gDmKC6blNSczLLUIn27BK6MzmbvgoYuxop1m/azNzA2 l3QxcnJICJhIHGhrZ4SwxSQu3FvP1sXIxSEkcIRR4uGJKywQzmJGicP9Z4AyHBxsAhYS3f+0 QRpEBEIkfq1pYAaxmQXUJV48esMOUiIs4CWx4rcyRIm3xPcbc5hAwiICfhKr2sCqWQRUJL5O OQW2llfAV+L2/wVQa3uZJPb+/gNWxClgJ/Hr3Q4mEJsR6Lbvp9YwQawSl2j6spIV4mYBiSV7 zjND2KISLx//Y4WoyZdY9OkN1AJBiZMzn7BMYBSZhaR9FpKyWUjKIOIGEl/e34aytSWWLXzN DGHrS3S/P82ELL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmCcHdzy22AH48vnjocY BTgYlXh4Ezj9woVYE8uKK3MPMUpwMCuJ8HK+AArxpiRWVqUW5ccXleakFh9ilOZgURLn9X+p GC4kkJ5YkpqdmlqQWgSTZeLglGpgTGDcOEsh929Lyo3nOxx/ZUVn+Gqt3G0v6K8eK2+gsPnz ASMbz9ktGp8KEg/HSCQ+nzPxdr7owRfOL61M+fyn+KafrBds6Ni86OuCgt/iK1PC12neltLz aF2s67/4B7eBtXb0qTj/A+sf7T2Zzya8cd1pLtuK9Dcq7D6pDjvYmR1yj51bZPJAiaU4I9FQ i7moOBEAkN+wIK8CAAA= Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 14:16:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3802AB31ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, SP/LWS was just one example. Another example is when you have case-insensit= ive header field values. The case can be changed by intermediates. This is what you get with the liberal encoding rules of SIP - which back in= the days was one of the reasons why SIP was so much better than H.323... := ) Also, if we would only use the signature, what's then left of JWT? Regards, Christer Sent from my Windows Phone ________________________________ From: Richard Shockey Sent: =FD01/=FD06/=FD2016 15:58 To: Eric Burger; Christer Holmberg Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon Thank you Eric .. I was thinking the same thing. On 6/1/16, 8:35 AM, "stir on behalf of Eric Burger" wrote: >Is the munging of SP to LWS real or theoretical? If real, no wonder end-to= -end signed signaling NEVER worked. If theoretical, we can safely ignore it= . > >> On Jun 1, 2016, at 5:09 AM, Christer Holmberg wrote: >> >> Hi, >> >> If I understand the proposal correctly, the reason we may not want to se= nd >> the JWT claims is because you=92ll find the same information in SIP head= er >> fields, and we will use the SIP header field information when calculatin= g >> (sender) and verifying (receiver) the JWT signature. >> >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >> >> For example, if one claim represents the SIP Cseq value: >> >> { >> =93CSeq": =931234INVITE=94 >> } >> >> =85will not (afaik) produce the same signature value as: >> >> { >> =93CSeq": =931234INVITE=94 >> } >> >> >> >> >> In SIP headers, you can not guarantee that what is sent is what will be >> received. There may be additional space characters, there may be linear >> whitespaces etc. So, when the receiver tries to verify the signature, it >> may fail. >> >> For example, if the sender sends: >> >> CSeq: 1234INVITE >> >> =85it may receive: >> >> CSeq: 1234INVITE >> >> =85in which case the signature calculated by the receiver will not match >> value signature calculated by the sender (assuming space characters etc >> are also used when calculating the signature). >> >> So, IF we want to calculate the signature based on SIP header filed >> values, I think we need to define a way of canonicalising them. >> >> Or, have I misunderstood something? :) >> >> >> Regards, >> >> Christer >> >> >> On 01/06/16 03:25, "stir on behalf of Peterson, Jon" >> wrote: >> >>> >>> This is a point that Chris and I have discussed a bit before, and is on= e >>> of those issues that is hard to resolve because the differences between >>> the two choices are so small. >>> >>>> From my perspective, making implementations send "canon" by default, >>>> while >>> leaving the option to exclude it, requires the same two code paths to >>> exist as we do when we don't send "canon" by default, and leave the opt= ion >>> to include it. And yes, the argument not to send it be default is simpl= y >>> to reduce message size, given the fields in canon are necessarily >>> redundant with various hearer field values and parameters in SIP. In so= me >>> environments, I still hear that message size is a concern. That's why >>> we've set it this way now. It might turn out in deployment that we need >>> "canon" more often that we'd think, because of things like Date header >>> changes, say. I'd be willing to revisit this when we have a bit more >>> experience under our collective belts. >>> >>> Ultimately, as Chris says, a verification service will need to basicall= y >>> reconstruct the header and claims itself anyway from the SIP request - = or >>> at least that the differences between reconstructing them on the one ha= nd >>> and extracting each individual field to compare them to the correspondi= ng >>> headers and claims of the canonical JWT object on the other hand seem >>> unlikely to genuinely impact either the difficulty of implementation or >>> the compute cycles required. >>> >>> But like Chris, I'm interested to hear people's thoughts on this, and I= 'm >>> not deeply committed to either approach. >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt" >>> wrote: >>> >>>> Hi All, >>>> >>>> There was a discussion on the STIR interim call about whether there is >>>> any strong reasons to consider using the full PASSporT >>>> (header.claims.signature) as the default for the identity header in >>>> 4474bis. >>>> >>>> The primary argument for the full token being default would be, it may= be >>>> more efficient from an implementation point of view to have the >>>> constructed token available to the verification service to directly >>>> validate signature. With the caveat that in either case you either ne= ed >>>> to re-construct the header.claims or you need to decode the Base64 to = get >>>> the JSON header and claims to verify that the values correspond to val= ues >>>> in the SIP header. >>>> >>>> The primary argument for the current default of only including the >>>> signature, is to save the 80-100 bytes of =B3duplicate=B2 information = in the >>>> SIP payload. >>>> >>>> Feel free to reword if i didn=B9t capture the main arguments correctly= . >>>> >>>> Would like to get other opinions or other arguments for or against >>>> keeping things the way they are or considering just using the full >>>> PASSporT token in the identity header. >>>> >>>> Thanks. >>>> >>>> -Chris >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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_7594FB04B1934943A5C02806D1A2204B3802AB31ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

SP/LWS was just one example. Another example is when you have case-insensit= ive header field values. The case can be changed by intermediates.

This is what you get with the liberal encoding rules of SIP - which back in= the days was one of the reasons why SIP was so much better than H.323... := )

Also, if we would only use the signature, what's then left of JWT?

Regards,

Christer

Sent from my Windows Phone
From: Richard Shockey
Sent: =FD01= /=FD06/=FD2016 15:58
To: Eric Burger; Christer Holmberg
Cc: IETF STIR Mail List
Subject: Re: [= stir] 4474bis identity header - full JWT by default vs canon


Thank you Eric .. I was thinking the same thing. 

On 6/1/16, 8:35 AM, "stir on behalf of Eric Burger" <stir-boun= ces@ietf.org on behalf of eburger@standardstrack.com> wrote:

>Is the munging of SP to LWS real or theoretical? If real, no wonder end= -to-end signed signaling NEVER worked. If theoretical, we can safely ignore= it.
>
>> On Jun 1, 2016, at 5:09 AM, Christer Holmberg <christer.holmber= g@ericsson.com> wrote:
>>
>> Hi,
>>
>> If I understand the proposal correctly, the reason we may not want= to send
>> the JWT claims is because you=92ll find the same information in SI= P header
>> fields, and we will use the SIP header field information when calc= ulating
>> (sender) and verifying (receiver) the JWT signature.
>>
>> Now, keep in mind that, when you calculate the JWT signature using= the JWT
>> claims, each claim value is considered a string, which means every=
>> character (including space characters) count when calculating the<= br> >> signature.
>>
>> For example, if one claim represents the SIP Cseq value:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;INVITE=94
>> }
>>
>> =85will not (afaik) produce the same signature value as:
>>
>> {
>>        =93CSeq": =931234&l= t;SP><SP><SP>INVITE=94
>> }
>>
>>
>>
>>
>> In SIP headers, you can not guarantee that what is sent is what wi= ll be
>> received. There may be additional space characters, there may be l= inear
>> whitespaces etc. So, when the receiver tries to verify the signatu= re, it
>> may fail.
>>
>> For example, if the sender sends:
>>
>> CSeq: 1234<SP>INVITE
>>
>> =85it may receive:
>>
>> CSeq: 1234<LWS>INVITE
>>
>> =85in which case the signature calculated by the receiver will not= match
>> value signature calculated by the sender (assuming space character= s etc
>> are also used when calculating the signature).
>>
>> So, IF we want to calculate the signature based on SIP header file= d
>> values, I think we need to define a way of canonicalising them. >>
>> Or, have I misunderstood something? :)
>>
>>
>> Regards,
>>
>> Christer
>>
>>
>> On 01/06/16 03:25, "stir on behalf of Peterson, Jon"
>> <stir-bounces@ietf.org on behalf of jon.peterson@neustar.biz>= ; wrote:
>>
>>>
>>> This is a point that Chris and I have discussed a bit before, = and is one
>>> of those issues that is hard to resolve because the difference= s between
>>> the two choices are so small.
>>>
>>>> From my perspective, making implementations send "can= on" by default,
>>>> while
>>> leaving the option to exclude it, requires the same two code p= aths to
>>> exist as we do when we don't send "canon" by default= , and leave the option
>>> to include it. And yes, the argument not to send it be default= is simply
>>> to reduce message size, given the fields in canon are necessar= ily
>>> redundant with various hearer field values and parameters in S= IP. In some
>>> environments, I still hear that message size is a concern. Tha= t's why
>>> we've set it this way now. It might turn out in deployment tha= t we need
>>> "canon" more often that we'd think, because of thing= s like Date header
>>> changes, say. I'd be willing to revisit this when we have a bi= t more
>>> experience under our collective belts.
>>>
>>> Ultimately, as Chris says, a verification service will need to= basically
>>> reconstruct the header and claims itself anyway from the SIP r= equest - or
>>> at least that the differences between reconstructing them on t= he one hand
>>> and extracting each individual field to compare them to the co= rresponding
>>> headers and claims of the canonical JWT object on the other ha= nd seem
>>> unlikely to genuinely impact either the difficulty of implemen= tation or
>>> the compute cycles required.
>>>
>>> But like Chris, I'm interested to hear people's thoughts on th= is, and I'm
>>> not deeply committed to either approach.
>>>
>>> Jon Peterson
>>> Neustar, Inc.
>>>
>>> On 5/31/16, 6:06 AM, "stir on behalf of Chris Wendt"=
>>> <stir-bounces@ietf.org on behalf of chris-ietf@chriswendt.n= et> wrote:
>>>
>>>> Hi All,
>>>>
>>>> There was a discussion on the STIR interim call about whet= her there is
>>>> any strong reasons to consider using the full PASSporT
>>>> (header.claims.signature) as the default for the identity = header in
>>>> 4474bis.
>>>>
>>>> The primary argument for the full token being default woul= d be, it may be
>>>> more efficient from an implementation point of view to hav= e the
>>>> constructed token available to the verification service to= directly
>>>> validate signature.  With the caveat that in either c= ase you either need
>>>> to re-construct the header.claims or you need to decode th= e Base64 to get
>>>> the JSON header and claims to verify that the values corre= spond to values
>>>> in the SIP header.
>>>>
>>>> The primary argument for the current default of only inclu= ding the
>>>> signature, is to save the 80-100 bytes of =B3duplicate=B2 = information in the
>>>> SIP payload.
>>>>
>>>> Feel free to reword if i didn=B9t capture the main argumen= ts correctly.
>>>>
>>>> Would like to get other opinions or other arguments for or= against
>>>> keeping things the way they are or considering just using = the full
>>>> PASSporT token in the identity header.
>>>>
>>>> Thanks.
>>>>
>>>> -Chris
>>>> _______________________________________________
>>>> stir mailing list
>>>> stir@ietf.org
>>>> htt= ps://www.ietf.org/mailman/listinfo/stir
>>>
>>> _______________________________________________
>>> 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
>
>_______________________________________________
>stir mailing list
>stir@ietf.org
>https://www.ietf= .org/mailman/listinfo/stir


 --_000_7594FB04B1934943A5C02806D1A2204B3802AB31ESESSMB209erics_-- From nobody Wed Jun 1 08:39:08 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 B67D912D5D6 for ; Wed, 1 Jun 2016 08:39:06 -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 ZdPDpamFA5KI for ; Wed, 1 Jun 2016 08:39:05 -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 8B43812D5D1 for ; Wed, 1 Jun 2016 08:39:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 83174309CC7 for ; Wed, 1 Jun 2016 11:39:03 -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 10024) with ESMTP id mMYC7ldGme_T for ; Wed, 1 Jun 2016 11:39:02 -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 9B329309C8A; Wed, 1 Jun 2016 11:39:01 -0400 (EDT) Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Wed, 1 Jun 2016 11:39:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 15:39:06 -0000 > Now, keep in mind that, when you calculate the JWT signature using the = JWT > claims, each claim value is considered a string, which means every > character (including space characters) count when calculating the > signature. >=20 > For example, if one claim represents the SIP Cseq value: >=20 > { > =A1=B0CSeq": =A1=B01234INVITE=A1=B1 > } >=20 > =A1=A6will not (afaik) produce the same signature value as: >=20 > { > =A1=B0CSeq": =A1=B01234INVITE=A1=B1 > } Correct. We find this all the time in security protocols. You need to be strict = in what you send, otherwise the receiver will not be able to verify it. If there is any ambiguity in the strings that can be produced, then the = canon procedure should eliminate the ambiguity. In the above, replace = multiple occurrence of with a single . Russ From nobody Wed Jun 1 08:59: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 6487E12D0DD for ; Wed, 1 Jun 2016 08:59:53 -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=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 YdfJz9oHnQ0q for ; Wed, 1 Jun 2016 08:59:51 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 0152412B042 for ; Wed, 1 Jun 2016 08:59:51 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id 52so44995190qgy.0 for ; Wed, 01 Jun 2016 08:59:50 -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 :content-transfer-encoding:message-id:references:to; bh=OuMlPWa8O3O9YkZJi3UkkDPxJzEwC5RLRwyAbA4a7dA=; b=Zbwgpa5+zfCnGzq/V81x3Jvt1FRJVIwYuefrT1CJNl8Vsj0CkEZPOg832v9uWBtuCT gBkd2Ohj3g1lEiPtSk6Zypgo3q9gx2UjBvz7k4l9uDr6vLXVlzEqum+yV0SXwgD+M2Dz 4sH5sBMXRlfRIflT3RlldYpjKuAx86DmUapc4s2uqPzVd6QiKtm1ffPSgPlvxlEa5HC2 NP6vgRIiLMSM6JYG5lRlFxANCs0atnjlkVA+azVPIzI325ygmoipqy6WmkLbkK64/hJ/ TQNO2+l7DHoBfJGFOOG0lkvBnedbU8PdSHffcYJHRDd2gCCW8ftTknEC8CyqhTsYXekf 5FkA== 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=OuMlPWa8O3O9YkZJi3UkkDPxJzEwC5RLRwyAbA4a7dA=; b=HfP6Ad41i2nK/a93SqmvOss+8t5qKmudljG5N3gJDgHc+3yzOUAIgBAlKhhAfvwH3j Zd2vpjH1HPOW8RuVKg+1g8MjAzZd0wVSV0YeHo2KaQbV3TcxXJ9ykMA/GsEWyzuzx/Mn o1sYDojq1NJV4Lw94f8SIRQUScZvEZuIWlzZ+TmVyM9ZXPYxWRfJM+8OlJ2NIhcx9Ckf j+UuURYM/KFDAcD1Q/19Aq2RkVjIUNlohHbO8ksM5WQ+Jf6tU7SeZZ0Tsl3yjyrFxhlO W6PZkui0HPpTgTaDv2zuCGrBzD8uwLVXMQCZjk0AV26OmYVPmpr66ifXKArtbmNVck/Q Lhag== X-Gm-Message-State: ALyK8tIytEomOfh31kfPWay0Yt1Vu1Yei6hoGRRqj09ZYyTh77qYJUQLjkrdML5pIyK7Mw== X-Received: by 10.140.109.198 with SMTP id l64mr35898211qgf.65.1464796789991; Wed, 01 Jun 2016 08:59:49 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id s106sm9895311qge.3.2016.06.01.08.59.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jun 2016 08:59:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Wed, 1 Jun 2016 11:59:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> References: To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Christer Holmberg Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 15:59:54 -0000 This would require a reasonable amount of work to document correctly. If we really want to do this, I might be willing to create a straw man = of what was needed. I am mostly responsible for the (crummy) ABNF in 3261 so I feel = obligated to volunteer :( Brian > On Jun 1, 2016, at 11:39 AM, Russ Housley = wrote: >=20 >=20 >> Now, keep in mind that, when you calculate the JWT signature using = the JWT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >>=20 >> For example, if one claim represents the SIP Cseq value: >>=20 >> { >> =E2=80=9CCSeq": =E2=80=9C1234INVITE=E2=80=9D >> } >>=20 >> =E2=80=A6will not (afaik) produce the same signature value as: >>=20 >> { >> =E2=80=9CCSeq": =E2=80=9C1234INVITE=E2=80=9D >> } >=20 > Correct. >=20 > We find this all the time in security protocols. You need to be = strict in what you send, otherwise the receiver will not be able to = verify it. >=20 > If there is any ambiguity in the strings that can be produced, then = the canon procedure should eliminate the ambiguity. In the above, = replace multiple occurrence of with a single . >=20 > Russ >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Wed Jun 1 09:05: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 207DD12B057 for ; Wed, 1 Jun 2016 09:05:08 -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 VQdBZEwYrDC9 for ; Wed, 1 Jun 2016 09:05:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CCAC12B063 for ; Wed, 1 Jun 2016 09:05:05 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-11-574f07af4dbc Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.28.12926.FA70F475; Wed, 1 Jun 2016 18:05:03 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 18:05:02 +0200 From: Christer Holmberg To: Brian Rosen , Russ Housley Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1QyoYpKCRWukGCcfM/wDhgL5/ToDcAgADFnYCAADmogIAABb4AgAAjAVM= Date: Wed, 1 Jun 2016 16:05:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> References: , <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> In-Reply-To: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3802BE3BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7ge56dv9wg88nVC2e3p/GZvHqxU12 i+VrtzE5MHvc//aX3WPJkp9MHqvufGENYI7isklJzcksSy3St0vgyuhqX8VY8MKo4tTX14wN jH3aXYwcHBICJhIXdsR3MXICmWISF+6tZ+ti5OIQEjjCKLF/4i4oZzGjRON+kAwHB5uAhUT3 P22QBhEBD4knXf9YQWxmAXWJF4/esIOUCAt4Saz4rQxR4i3x/cYcJgjbT+Jay2xmEJtFQEVi 7cP77CA2r4CvxNWL51khVnUzSfxr/Qi2ilPASWLeD0GQGkag276fWsMEsUpcounLSlaImwUk luw5zwxhi0q8fAxzTr7EkyULmCHmC0qcnPmEZQKjyCwk7bOQlM1CUgYRN5D48v42lK0tsWzh a2YIW1+i+/1pJmTxBYzsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjEC4+zglt+qOxgvv3E8 xCjAwajEw5vA6RcuxJpYVlyZe4hRgoNZSYTXkcU/XIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv /0vFcCGB9MSS1OzU1ILUIpgsEwenVAOjTHmU8d0w5VeZixpsPbl7E278kvvolcZ6ZekBjgcx QadZPEM6H556o+7Sz+m24rnfMY3Zgceff/R4cnzFIuFPyy6UbN6tK7IjTTnrwMtjySf1a289 UZY5fKHL/frzRw4SP9czbGD+8dWnX079bM5uCb0fgo+uZDAuruK6tvNtIXO8TT5DwSQ5JZbi jERDLeai4kQA8v+w368CAAA= Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 16:05:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3802BE3BESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind. If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: =FD01/=FD06/=FD2016 18:59 To: Russ Housley Cc: Christer Holmberg; IETF STIR Mai= l List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon This would require a reasonable amount of work to document correctly. If we really want to do this, I might be willing to create a straw man of w= hat was needed. I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :( Brian > On Jun 1, 2016, at 11:39 AM, Russ Housley wrote: > > >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >> >> For example, if one claim represents the SIP Cseq value: >> >> { >> =93CSeq": =931234INVITE=94 >> } >> >> =85will not (afaik) produce the same signature value as: >> >> { >> =93CSeq": =931234INVITE=94 >> } > > Correct. > > We find this all the time in security protocols. You need to be strict i= n what you send, otherwise the receiver will not be able to verify it. > > If there is any ambiguity in the strings that can be produced, then the c= anon procedure should eliminate the ambiguity. In the above, replace multi= ple occurrence of with a single . > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_7594FB04B1934943A5C02806D1A2204B3802BE3BESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind.

If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits.

Regards,

Christer

Sent from my Windows Phone
From: Brian Rosen
Sent: =FD01= /=FD06/=FD2016 18:59
To: Russ Housley
Cc: Christer Holmberg; IETF STIR Mail List
Subject: Re: [= stir] 4474bis identity header - full JWT by default vs canon

This would require a reasonable amount of work to = document correctly.

If we really want to do this, I might be willing to create a straw man of w= hat was needed.

I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <housley@vigilsec.com>= wrote:
>
>
>> Now, keep in mind that, when you calculate the JWT signature using= the JWT
>> claims, each claim value is considered a string, which means every=
>> character (including space characters) count when calculating the<= br> >> signature.
>>
>> For example, if one claim represents the SIP Cseq value:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;INVITE=94
>> }
>>
>> =85will not (afaik) produce the same signature value as:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;<SP><SP>INVITE=94
>> }
>
> Correct.
>
> We find this all the time in security protocols.  You need to be = strict in what you send, otherwise the receiver will not be able to verify = it.
>
> If there is any ambiguity in the strings that can be produced, then th= e canon procedure should eliminate the ambiguity.  In the above, repla= ce multiple occurrence of <SP> with a single <SP>.
>
> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.iet= f.org/mailman/listinfo/stir

 --_000_7594FB04B1934943A5C02806D1A2204B3802BE3BESESSMB209erics_-- From nobody Wed Jun 1 09:48: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 AC8C712D530 for ; Wed, 1 Jun 2016 09:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQGWBK7Gm6iT for ; Wed, 1 Jun 2016 09:48:26 -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 BB6A812D0E5 for ; Wed, 1 Jun 2016 09:48:26 -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 u51Gh6IF019544; Wed, 1 Jun 2016 12:48:21 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2375yvut3x-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Jun 2016 12:48:21 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Wed, 1 Jun 2016 12:48:19 -0400 From: "Peterson, Jon" To: Christer Holmberg , Brian Rosen , Russ Housley Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1eiVkbnTwgIUqW6iKnRchGG5/Tj3EAgAEH4ICAAGzAgIAABb4AgAABeQD//5a6gA== Date: Wed, 1 Jun 2016 16:48:18 +0000 Message-ID: References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3802BE3B@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.169] Content-Type: multipart/alternative; boundary="_000_D3745E6019ABBEjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-01_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-1604210000 definitions=main-1606010191 Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 16:48:30 -0000 --_000_D3745E6019ABBEjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This addresses a very different question than what Chris was asking when he= kicked off this thread, but to this point: the header and claim values in = baseline PASSporT do not take the entire content of any header field value = from SIP in such a way that whitespace concerns will arise. The claims all = take some single syntactical element: extracting the addr-spec, say, or the= contents of the "info" parameter of Identity, or what have you. Since "iat= " is used instead of the Date header field value, even that has no whitespa= ce concerns. That much said, it's probably worth noting in PASSporT that future extensio= n headers and claims should avoid this. Display name, for example, has diff= erent properties, and we'd need to put up some warning tape around that. Jon Peterson Neustar, Inc, From: stir > on behalf = of Christer Holmberg > Date: Wednesday, June 1, 2016 at 9:05 AM To: Brian Rosen >, Russ Housley= > Cc: IETF STIR Mail List > Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon Hi, We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind. If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: 01/06/2016 18:59 To: Russ Housley Cc: Christer Holmberg; IETF STIR Mai= l List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon This would require a reasonable amount of work to document correctly. If we really want to do this, I might be willing to create a straw man of w= hat was needed. I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :( Brian > On Jun 1, 2016, at 11:39 AM, Russ Housley > wrote: > > >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >> >> For example, if one claim represents the SIP Cseq value: >> >> { >> =93CSeq": =931234INVITE=94 >> } >> >> =85will not (afaik) produce the same signature value as: >> >> { >> =93CSeq": =931234INVITE=94 >> } > > Correct. > > We find this all the time in security protocols. You need to be strict i= n what you send, otherwise the receiver will not be able to verify it. > > If there is any ambiguity in the strings that can be produced, then the c= anon procedure should eliminate the ambiguity. In the above, replace multi= ple occurrence of with a single . > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_D3745E6019ABBEjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <16E76104B0702749B0EDD1AAD7E95D1D@neustar.biz> Content-Transfer-Encoding: quoted-printable

This addresses a very different question than what Chris was asking wh= en he kicked off this thread, but to this point: the header and claim value= s in baseline PASSporT do not take the entire content of any header field v= alue from SIP in such a way that whitespace concerns will arise. The claims all take some single syntactica= l element: extracting the addr-spec, say, or the contents of the "info= " parameter of Identity, or what have you. Since "iat" is us= ed instead of the Date header field value, even that has no whitespace concerns.

That much said, it's probably worth noting in PASSporT that future ext= ension headers and claims should avoid this. Display name, for example, has= different properties, and we'd need to put up some warning tape around tha= t.

Jon Peterson
Neustar, Inc,

From: stir <stir-bounces@ietf.org> on behalf of Christer Ho= lmberg <christer.holmb= erg@ericsson.com>
Date: Wednesday, June 1, 2016 at 9:= 05 AM
To: Brian Rosen <br@brianrosen.net>, Russ Housley <housley@vigilsec.com>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] 4474bis identit= y header - full JWT by default vs canon

Hi,

We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind.

If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits.

Regards,

Christer

Sent from my Windows Phone
From: Brian Rosen
Sent: 01/06= /2016 18:59
To: Russ Housley
Cc: Christer Holmberg; IETF STIR Mail List
Subject: Re: [= stir] 4474bis identity header - full JWT by default vs canon

This would require a reasonable amount of work to = document correctly.

If we really want to do this, I might be willing to create a straw man of w= hat was needed.

I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <housley@vigilsec.com> wrote:
>
>
>> Now, keep in mind that, when you calculate the JWT signature using= the JWT
>> claims, each claim value is considered a string, which means every=
>> character (including space characters) count when calculating the<= br> >> signature.
>>
>> For example, if one claim represents the SIP Cseq value:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;INVITE=94
>> }
>>
>> =85will not (afaik) produce the same signature value as:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;<SP><SP>INVITE=94
>> }
>
> Correct.
>
> We find this all the time in security protocols.  You need to be = strict in what you send, otherwise the receiver will not be able to verify = it.
>
> If there is any ambiguity in the strings that can be produced, then th= e canon procedure should eliminate the ambiguity.  In the above, repla= ce multiple occurrence of <SP> with a single <SP>.
>
> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.iet= f.org/mailman/listinfo/stir

 --_000_D3745E6019ABBEjonpetersonneustarbiz_-- From nobody Wed Jun 1 10:23: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 510BB12D5D7 for ; Wed, 1 Jun 2016 10:23: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 UqUw2SFwqRSu for ; Wed, 1 Jun 2016 10:23:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2A8212D533 for ; Wed, 1 Jun 2016 10:23:07 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-b6-574f19fae017 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.A6.27088.AF91F475; Wed, 1 Jun 2016 19:23:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0294.000; Wed, 1 Jun 2016 19:23:05 +0200 From: Christer Holmberg To: "Peterson, Jon" , Brian Rosen , Russ Housley Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1QyoYpKCRWukGCcfM/wDhgL5/ToDcAgADFnYCAADmogIAABb4AgAAjAVP//+qPAIAAJsbQ Date: Wed, 1 Jun 2016 17:23:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@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_7594FB04B1934943A5C02806D1A2204B3802C104ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7pe4vSf9wg30rhCye3p/GZvHqxU12 izMNlhbL125jcmDxuP/tL7vHkiU/mTx2NDxn9lh15wtrAEsUl01Kak5mWWqRvl0CV8bWzdvY Cj40MVYcO7yPtYHxcHEXIyeHhICJRNO9eWwQtpjEhXvrgWwuDiGBI4wSs3sWs0A4ixklJq/+ xtzFyMHBJmAh0f1PG6RBRKBM4k7nbBYQm1lAXeLFozfsICXCAl4SK34rQ5R4S3y/MYcJwo6S 2H7/ICOIzSKgItG97RZYnFfAV2Lvu4+MEKv+MUncf/0MLMEpYC7RdKGFFcRmBDru+6k1TBC7 xCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2EoSjUuesELU50u82fCQFWKZoMTJmU9YJjCKzkIy ahaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8 PL281JJNjMC4PLjlt8EOxpfPHQ8xCnAwKvHwJnD6hQuxJpYVV+YeYpTgYFYS4T0q7h8uxJuS WFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgXEj+7IJR84WTHk6 aSvzNY1rH6IXbX1/7cP2goxve7Z9LzFYkpnRHcL4ZPOclgr2S2fv7r59Jql+xv/ukkfmDssP Htl8fqIo1/VfQkJ+Gm+TwxasTa688P9h7/zbKau6ZzBPbd372i5ms03cdPb7z0+xPeSatKM8 yfv46Sa7soJG8bDa+XdO+mpHK7EUZyQaajEXFScCAI1Ud//HAgAA Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 17:23:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3802C104ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >This addresses a very different question than what Chris was asking when h= e kicked off this thread, but to this point: the header >and claim values in baseline PASSporT do not take the entire content of an= y header field value from SIP in such a way that whitespace >concerns will arise. The claims all take some single syntactical element: = extracting the addr-spec, say, The SIP(S)-URI is an instance of addr-spec, and it contains parts that can = be separated by whitespaces. In addition, some parts are also case-insensit= ive, some parts can be escaped, and I assume the order of URI parameters ca= n also change. See section 19.1.4 of RFC3261 for examples of URIs with different encodings= but equivalent values. >or the contents of the "info" parameter of Identity, or what have you. Sin= ce "iat" is used instead of the Date header field value, even that has no w= hitespace concerns. True. And, as "iat" is carried as a JWT claim, it can't be "legally" modifi= ed using the SIP encoding rules. Regards, Christer From: stir > on behalf = of Christer Holmberg > Date: Wednesday, June 1, 2016 at 9:05 AM To: Brian Rosen >, Russ Housley= > Cc: IETF STIR Mail List > Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon Hi, We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind. If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: 01/06/2016 18:59 To: Russ Housley Cc: Christer Holmberg; IETF STIR Mai= l List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon This would require a reasonable amount of work to document correctly. If we really want to do this, I might be willing to create a straw man of w= hat was needed. I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :( Brian > On Jun 1, 2016, at 11:39 AM, Russ Housley > wrote: > > >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >> >> For example, if one claim represents the SIP Cseq value: >> >> { >> "CSeq": "1234INVITE" >> } >> >> ...will not (afaik) produce the same signature value as: >> >> { >> "CSeq": "1234INVITE" >> } > > Correct. > > We find this all the time in security protocols. You need to be strict i= n what you send, otherwise the receiver will not be able to verify it. > > If there is any ambiguity in the strings that can be produced, then the c= anon procedure should eliminate the ambiguity. In the above, replace multi= ple occurrence of with a single . > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_7594FB04B1934943A5C02806D1A2204B3802C104ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

>This addresses a ve= ry different question than what Chris was asking when he kicked off this th= read, but to this point: the header

>and claim values in baselin= e PASSporT do not take the entire content of any header field value from SIP in such a way that whitespace

>concerns will arise. The cl= aims all take some single syntactical element: extracting the addr-spec, say,

 

The SIP(S)-URI is an instance of addr-spec, and it = contains parts that can be separated by whitespaces. In addition, some part= s are also case-insensitive, some parts can be escaped, and I assume the order of URI parameters can also change.

 

See section 19.1.4 of RFC3261 for examples of URIs = with different encodings but equivalent values.

 

>or the contents of = the "info" parameter of Identity, or what have you. Since "i= at" is used instead of the Date header field value, even that has no whitespace concerns.

 

True. And, as “iat” is carried as a JWT= claim, it can’t be “legally” modified using the SIP enco= ding rules.

 

Regards,

 

Christer

 

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Wednesday, June 1, 2016 at 9:05 AM
To: Brian Rosen <br@brianros= en.net>, Russ Housley <ho= usley@vigilsec.com>
Cc: IETF STIR Mail List <stir@ie= tf.org>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs= canon

 

Hi,

We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind.

If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits.

Regards,

Christer

Sent from my Windows Phone

From: Brian Rosen
Sent: 01/06/2016 18:59
To: Russ Housle= y
Cc: C= hrister Holmberg; IETF STIR Mail List
Subject: Re: [stir] 4474bis identity header - full JWT by de= fault vs canon

This wou= ld require a reasonable amount of work to document correctly.

If we really want to do this, I might be willing to create a straw man of w= hat was needed.

I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <housley@vigilsec.com> wrote:
>
>
>> Now, keep in mind that, when you calculate the JWT signature using= the JWT
>> claims, each claim value is considered a string, which means every=
>> character (including space characters) count when calculating the<= br> >> signature.
>>
>> For example, if one claim represents the SIP Cseq value:
>>
>> {
>>       “CSeq": “1234= <SP>INVITE”
>> }
>>
>> …will not (afaik) produce the same signature value as:
>>
>> {
>>       “CSeq": “1234= <SP><SP><SP>INVITE”
>> }
>
> Correct.
>
> We find this all the time in security protocols.  You need to be = strict in what you send, otherwise the receiver will not be able to verify = it.
>
> If there is any ambiguity in the strings that can be produced, then th= e canon procedure should eliminate the ambiguity.  In the above, repla= ce multiple occurrence of <SP> with a single <SP>.
>
> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.iet= f.org/mailman/listinfo/stir

--_000_7594FB04B1934943A5C02806D1A2204B3802C104ESESSMB209erics_-- From nobody Wed Jun 1 11:19: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 ED82312D0D1 for ; Wed, 1 Jun 2016 11:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDskaOVPJAmf for ; Wed, 1 Jun 2016 11:19:44 -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 7194D12D0A8 for ; Wed, 1 Jun 2016 11:19:44 -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 u51ID3Bc021726; Wed, 1 Jun 2016 14:19:40 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23764kwj9b-13 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Jun 2016 14:19:39 -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; Wed, 1 Jun 2016 14:19:38 -0400 From: "Peterson, Jon" To: Christer Holmberg , Brian Rosen , Russ Housley Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1eiVkbnTwgIUqW6iKnRchGG5/Tj3EAgAEH4ICAAGzAgIAABb4AgAABeQD//5a6gIAAfxWA//+acQA= Date: Wed, 1 Jun 2016 18:19:38 +0000 Message-ID: References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3802C104@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.169] Content-Type: multipart/alternative; boundary="_000_D374726719B0AFjonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-01_08:, , 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-1606010206 Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 01 Jun 2016 18:19:47 -0000 --_000_D374726719B0AFjonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This may then be a confusion that has crept in over the many steps we've ta= ken in transition to PASSporT, but the original intention was for the ouri/= duri not to contain parameters or other component of the SIP URI apart from= the scheme, the user part, the @ sign, and the host part. Indeed, a call r= ecently came from Cullen to consider just using an 822 email-style identifi= er without the scheme for better compatibility with WebRTC and through gate= ways. Whatever we end up using for ouri/duri, it should handle case sensiti= vity and so on. But again - this is a separate issue from the one Chris was trying to raise= . Jon Peterson Neustar, Inc. From: Christer Holmberg > Date: Wednesday, June 1, 2016 at 10:23 AM To: Jon Peterson = >, Brian Rosen >, Russ Housley = > Cc: IETF STIR Mail List > Subject: RE: [stir] 4474bis identity header - full JWT by default vs canon Hi, >This addresses a very different question than what Chris was asking when h= e kicked off this thread, but to this point: the header >and claim values in baseline PASSporT do not take the entire content of an= y header field value from SIP in such a way that whitespace >concerns will arise. The claims all take some single syntactical element: = extracting the addr-spec, say, The SIP(S)-URI is an instance of addr-spec, and it contains parts that can = be separated by whitespaces. In addition, some parts are also case-insensit= ive, some parts can be escaped, and I assume the order of URI parameters ca= n also change. See section 19.1.4 of RFC3261 for examples of URIs with different encodings= but equivalent values. >or the contents of the "info" parameter of Identity, or what have you. Sin= ce "iat" is used instead of the Date header field value, even that has no w= hitespace concerns. True. And, as =93iat=94 is carried as a JWT claim, it can=92t be =93legally= =94 modified using the SIP encoding rules. Regards, Christer From: stir > on behalf = of Christer Holmberg > Date: Wednesday, June 1, 2016 at 9:05 AM To: Brian Rosen >, Russ Housley= > Cc: IETF STIR Mail List > Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon Hi, We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind. If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: 01/06/2016 18:59 To: Russ Housley Cc: Christer Holmberg; IETF STIR Mai= l List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon This would require a reasonable amount of work to document correctly. If we really want to do this, I might be willing to create a straw man of w= hat was needed. I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :( Brian > On Jun 1, 2016, at 11:39 AM, Russ Housley > wrote: > > >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >> >> For example, if one claim represents the SIP Cseq value: >> >> { >> =93CSeq": =931234INVITE=94 >> } >> >> =85will not (afaik) produce the same signature value as: >> >> { >> =93CSeq": =931234INVITE=94 >> } > > Correct. > > We find this all the time in security protocols. You need to be strict i= n what you send, otherwise the receiver will not be able to verify it. > > If there is any ambiguity in the strings that can be produced, then the c= anon procedure should eliminate the ambiguity. In the above, replace multi= ple occurrence of with a single . > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_D374726719B0AFjonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <00F1240F2BE75347A79E1F86FEF0D2D7@neustar.biz> Content-Transfer-Encoding: quoted-printable

This may then be a confusion that has crept in over the many steps we'= ve taken in transition to PASSporT, but the original intention was for the = ouri/duri not to contain parameters or other component of the SIP URI apart= from the scheme, the user part, the @ sign, and the host part. Indeed, a call recently came from Cullen to= consider just using an 822 email-style identifier without the scheme for b= etter compatibility with WebRTC and through gateways. Whatever we end up us= ing for ouri/duri, it should handle case sensitivity and so on.

But again - this is a separate issue from the one Chris was trying to = raise.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Wednesday, June 1, 2016 at 10= :23 AM
To: Jon Peterson <jon.peterson@neustar.biz>, Brian Rosen= <br@brianrosen.net>, Russ H= ousley <housley@vigilsec.com= >
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: RE: [stir] 4474bis identit= y header - full JWT by default vs canon

Hi,

 

>This addresses a ve= ry different question than what Chris was asking when he kicked off this th= read, but to this point: the header

>and claim values in baselin= e PASSporT do not take the entire content of any header field value from SIP in such a way that whitespace

>concerns will arise. The cl= aims all take some single syntactical element: extracting the addr-spec, say,

 

The SIP(S)-URI is an instance of addr-spec, and it = contains parts that can be separated by whitespaces. In addition, some part= s are also case-insensitive, some parts can be escaped, and I assume the order of URI parameters can also change.

 

See section 19.1.4 of RFC3261 for examples of URIs = with different encodings but equivalent values.

 

>or the contents of = the "info" parameter of Identity, or what have you. Since "i= at" is used instead of the Date header field value, even that has no whitespace concerns.

 

True. And, as =93iat=94 is carried as a JWT claim, = it can=92t be =93legally=94 modified using the SIP encoding rules.

 

Regards,

 

Christer

 

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Wednesday, June 1, 2016 at 9:05 AM
To: Brian Rosen <br@brianros= en.net>, Russ Housley <ho= usley@vigilsec.com>
Cc: IETF STIR Mail List <stir@ie= tf.org>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs= canon

 

Hi,

We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind.

If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits.

Regards,

Christer

Sent from my Windows Phone

From: Brian Rosen
Sent: 01/06/2016 18:59
To: Russ Housle= y
Cc: C= hrister Holmberg; IETF STIR Mail List
Subject: Re: [stir] 4474bis identity header - full JWT by de= fault vs canon

This wou= ld require a reasonable amount of work to document correctly.

If we really want to do this, I might be willing to create a straw man of w= hat was needed.

I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <housley@vigilsec.com> wrote:
>
>
>> Now, keep in mind that, when you calculate the JWT signature using= the JWT
>> claims, each claim value is considered a string, which means every=
>> character (including space characters) count when calculating the<= br> >> signature.
>>
>> For example, if one claim represents the SIP Cseq value:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;INVITE=94
>> }
>>
>> =85will not (afaik) produce the same signature value as:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;<SP><SP>INVITE=94
>> }
>
> Correct.
>
> We find this all the time in security protocols.  You need to be = strict in what you send, otherwise the receiver will not be able to verify = it.
>
> If there is any ambiguity in the strings that can be produced, then th= e canon procedure should eliminate the ambiguity.  In the above, repla= ce multiple occurrence of <SP> with a single <SP>.
>
> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.iet= f.org/mailman/listinfo/stir

 --_000_D374726719B0AFjonpetersonneustarbiz_-- From nobody Thu Jun 2 00:12: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 D656412D63B for ; Thu, 2 Jun 2016 00:12:28 -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 UJlTR2HVNUcl for ; Thu, 2 Jun 2016 00:12:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8674012D63E for ; Thu, 2 Jun 2016 00:12:25 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-31-574fdc572fbd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.A6.27088.75CDF475; Thu, 2 Jun 2016 09:12:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0294.000; Thu, 2 Jun 2016 09:12:23 +0200 From: Christer Holmberg To: "Peterson, Jon" , Brian Rosen , Russ Housley Thread-Topic: [stir] 4474bis identity header - full JWT by default vs canon Thread-Index: AQHRuz1QyoYpKCRWukGCcfM/wDhgL5/ToDcAgADFnYCAADmogIAABb4AgAAjAVP//+qPAIAAJsbQ///yvgCAAQsCgA== Date: Thu, 2 Jun 2016 07:12:23 +0000 Message-ID: References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> 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.4.160422 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D375B59D9910christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUyM2K7k274Hf9wg/UHLSye3p/GZvHqxU12 izMNlhbL125jcmDxuP/tL7vHkiU/mTx2NDxn9lh15wtrAEsUl01Kak5mWWqRvl0CV8aj2SUF 3XsYK9bOWsDWwLhuCWMXIyeHhICJxKdL86FsMYkL99azdTFycQgJHGGUmNnynh3CWcwocef6 aeYuRg4ONgELie5/2iANIgJlEnc6Z7OA2MwC6hIvHr1hB7GFBbwk7v7/xQxR4y3x/cYcJpBW EYEsiVmrVUFMFgEViZU3pEEqeAWsJGa0vWSB2PSeWWLBrHY2kASngLnEqW9XWUFsRqDbvp9a wwSxSlzi1pP5TBA3C0gs2XOeGcIWlXj5+B9YvaiAnsSXe/MYQXZJCChJTNuaBtEaL7FpUQsz xF5BiZMzn7BMYBSbhWTqLCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjhG0tcffCFBZk NQsYOVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbwwS2/DXYwvnzueIhRgINRiYf3QZR/ uBBrYllxZe4hRgkOZiURXr0bQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNT UwtSi2CyTBycUg2MvUrLfnOwKcgzrnmou23f8msrbkQd+8RWuTD2/nmWuSX3p8dkB8zwatxy pO5c8N1vr5X2sJYrZ2RJOX3avudZ8ItZ/gku89KlTvnt50r4+2O3Tkbu3QvpX2W+8R7fwXUn rPhTvWFSnIIeo6/t3LPzNm2ZNWO7yoZpB1i111jJaN1aJxjnu81dR4mlOCPRUIu5qDgRAAEF +H7dAgAA Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 02 Jun 2016 07:12:29 -0000 --_000_D375B59D9910christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I think the encoding issue IS related to Chris=92s question =96 assuming th= e question was whether to include the JWT claims :) Including the claims in the JWT will show exactly what was used to calculat= e the signature . Then, when comparing the claims to the associated SIP hea= der field values, endpoints can check whether any deviations is because of = encoding differences, or whether the compared values are actually different= . Otherwise, we need to make sure that the sender and the receiver will use e= xactly the same values for calculating the signature. For SIP-URIs we can p= robably use the RFC 3261 canonicalisation rules for doing that. Just one question: are there other JWT use-cases where the claims aren=92t = included? Is it a valid JWT? Will off-the-shelf decoders be able to handle = such JWTs? Regards, Christer From: Jon Peterson > Date: Wednesday 1 June 2016 at 21:19 To: Christer Holmberg >, Brian Rosen >, Russ Housley > Cc: IETF STIR Mail List > Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon This may then be a confusion that has crept in over the many steps we've ta= ken in transition to PASSporT, but the original intention was for the ouri/= duri not to contain parameters or other component of the SIP URI apart from= the scheme, the user part, the @ sign, and the host part. Indeed, a call r= ecently came from Cullen to consider just using an 822 email-style identifi= er without the scheme for better compatibility with WebRTC and through gate= ways. Whatever we end up using for ouri/duri, it should handle case sensiti= vity and so on. But again - this is a separate issue from the one Chris was trying to raise= . Jon Peterson Neustar, Inc. From: Christer Holmberg > Date: Wednesday, June 1, 2016 at 10:23 AM To: Jon Peterson = >, Brian Rosen >, Russ Housley = > Cc: IETF STIR Mail List > Subject: RE: [stir] 4474bis identity header - full JWT by default vs canon Hi, >This addresses a very different question than what Chris was asking when h= e kicked off this thread, but to this point: the header >and claim values in baseline PASSporT do not take the entire content of an= y header field value from SIP in such a way that whitespace >concerns will arise. The claims all take some single syntactical element: = extracting the addr-spec, say, The SIP(S)-URI is an instance of addr-spec, and it contains parts that can = be separated by whitespaces. In addition, some parts are also case-insensit= ive, some parts can be escaped, and I assume the order of URI parameters ca= n also change. See section 19.1.4 of RFC3261 for examples of URIs with different encodings= but equivalent values. >or the contents of the "info" parameter of Identity, or what have you. Sin= ce "iat" is used instead of the Date header field value, even that has no w= hitespace concerns. True. And, as =93iat=94 is carried as a JWT claim, it can=92t be =93legally= =94 modified using the SIP encoding rules. Regards, Christer From: stir > on behalf = of Christer Holmberg > Date: Wednesday, June 1, 2016 at 9:05 AM To: Brian Rosen >, Russ Housley= > Cc: IETF STIR Mail List > Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon Hi, We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind. If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits. Regards, Christer Sent from my Windows Phone ________________________________ From: Brian Rosen Sent: 01/06/2016 18:59 To: Russ Housley Cc: Christer Holmberg; IETF STIR Mai= l List Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon This would require a reasonable amount of work to document correctly. If we really want to do this, I might be willing to create a straw man of w= hat was needed. I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :( Brian > On Jun 1, 2016, at 11:39 AM, Russ Housley > wrote: > > >> Now, keep in mind that, when you calculate the JWT signature using the J= WT >> claims, each claim value is considered a string, which means every >> character (including space characters) count when calculating the >> signature. >> >> For example, if one claim represents the SIP Cseq value: >> >> { >> =93CSeq": =931234INVITE=94 >> } >> >> =85will not (afaik) produce the same signature value as: >> >> { >> =93CSeq": =931234INVITE=94 >> } > > Correct. > > We find this all the time in security protocols. You need to be strict i= n what you send, otherwise the receiver will not be able to verify it. > > If there is any ambiguity in the strings that can be produced, then the c= anon procedure should eliminate the ambiguity. In the above, replace multi= ple occurrence of with a single . > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir --_000_D375B59D9910christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2D4F08EB148FC34DB8F69BC92ED4EC9D@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I think the encoding issue IS related to Chris=92s question =96 assumi= ng the question was whether to include the JWT claims :)

Including the claims in the JWT will show exactly what was used to cal= culate the signature . Then, when comparing the claims to the associated SI= P header field values, endpoints can check whether any deviations is becaus= e of encoding differences, or whether the compared values are actually different.

Otherwise, we need to make sure that the sender and the receiver will = use exactly the same values for calculating the signature. For SIP-URIs we = can probably use the RFC 3261 canonicalisation rules for doing that.

Just one question: are there other JWT use-cases where the claims aren= =92t included? Is it a valid JWT? Will off-the-shelf decoders be able to ha= ndle such JWTs?

Regards,

Christer

From: Jon Peterson <jon.peterson@neustar.biz>
Date: Wednesday 1 June 2016 at 21:1= 9
To: Christer Holmberg <christer.holmberg@ericsson.com>, Brian Rosen <br@brianrosen.= net>, Russ Housley <housl= ey@vigilsec.com>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] 4474bis identit= y header - full JWT by default vs canon


This may then be a confusion that has crept in over the many steps we'= ve taken in transition to PASSporT, but the original intention was for the = ouri/duri not to contain parameters or other component of the SIP URI apart= from the scheme, the user part, the @ sign, and the host part. Indeed, a call recently came from Cullen to= consider just using an 822 email-style identifier without the scheme for b= etter compatibility with WebRTC and through gateways. Whatever we end up us= ing for ouri/duri, it should handle case sensitivity and so on.

But again - this is a separate issue from the one Chris was trying to = raise.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Wednesday, June 1, 2016 at 10= :23 AM
To: Jon Peterson <jon.peterson@neustar.biz>, Brian Rosen= <br@brianrosen.net>, Russ H= ousley <housley@vigilsec.com= >
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: RE: [stir] 4474bis identit= y header - full JWT by default vs canon

Hi,

 

>This addresses a ve= ry different question than what Chris was asking when he kicked off this th= read, but to this point: the header

>and claim values in baselin= e PASSporT do not take the entire content of any header field value from SIP in such a way that whitespace

>concerns will arise. The cl= aims all take some single syntactical element: extracting the addr-spec, say,

 

The SIP(S)-URI is an instance of addr-spec, and it = contains parts that can be separated by whitespaces. In addition, some part= s are also case-insensitive, some parts can be escaped, and I assume the order of URI parameters can also change.

 

See section 19.1.4 of RFC3261 for examples of URIs = with different encodings but equivalent values.

 

>or the contents of = the "info" parameter of Identity, or what have you. Since "i= at" is used instead of the Date header field value, even that has no whitespace concerns.

 

True. And, as =93iat=94 is carried as a JWT claim, = it can=92t be =93legally=94 modified using the SIP encoding rules.

 

Regards,

 

Christer

 

 

From: stir <s= tir-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Wednesday, June 1, 2016 at 9:05 AM
To: Brian Rosen <br@brianros= en.net>, Russ Housley <ho= usley@vigilsec.com>
Cc: IETF STIR Mail List <stir@ie= tf.org>
Subject: Re: [stir] 4474bis identity header - full JWT by default vs= canon

 

Hi,

We obviously need to check whether the issues apply to the STIR usage of JW= T - my comments were general, and we need to keep them in mind.

If we e.g. are going to calculate the signature based on a phone number, th= ere will be no space characters etc between the digits.

Regards,

Christer

Sent from my Windows Phone

From: Brian Rosen
Sent: 01/06/2016 18:59
To: Russ Housle= y
Cc: C= hrister Holmberg; IETF STIR Mail List
Subject: Re: [stir] 4474bis identity header - full JWT by de= fault vs canon

This wou= ld require a reasonable amount of work to document correctly.

If we really want to do this, I might be willing to create a straw man of w= hat was needed.

I am mostly responsible for the (crummy) ABNF in 3261 so I feel obligated t= o volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ Housley <housley@vigilsec.com> wrote:
>
>
>> Now, keep in mind that, when you calculate the JWT signature using= the JWT
>> claims, each claim value is considered a string, which means every=
>> character (including space characters) count when calculating the<= br> >> signature.
>>
>> For example, if one claim represents the SIP Cseq value:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;INVITE=94
>> }
>>
>> =85will not (afaik) produce the same signature value as:
>>
>> {
>>       =93CSeq": =931234<SP&g= t;<SP><SP>INVITE=94
>> }
>
> Correct.
>
> We find this all the time in security protocols.  You need to be = strict in what you send, otherwise the receiver will not be able to verify = it.
>
> If there is any ambiguity in the strings that can be produced, then th= e canon procedure should eliminate the ambiguity.  In the above, repla= ce multiple occurrence of <SP> with a single <SP>.
>
> Russ
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.iet= f.org/mailman/listinfo/stir

 --_000_D375B59D9910christerholmbergericssoncom_-- From nobody Thu Jun 2 04:40: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 E4BF912D6C0 for ; Thu, 2 Jun 2016 04:40:17 -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 8VGeN_r558k5 for ; Thu, 2 Jun 2016 04:40:15 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 B0E8B12D127 for ; Thu, 2 Jun 2016 04:40:14 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id 93so2069916qgx.2 for ; Thu, 02 Jun 2016 04:40:14 -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=lySiL5MX6YPwTWrtLpMSfWiANSjXzkqgn9tzaZF5SEE=; b=cQkPDEv1TWRKSIJBNjsjrAKVxDPJrVyKPM9WxvL3u2ufctsAlA6sVk8eEl1y1Ey7fO ZVNAv6wiiHImnckw3inHdjuOoSvWrZReFyKPlNICyyBv2pyKGzjtSSXqGgqFwwf0cDA+ vmzkfenw40pxsgSRV0ul2Dlcgy9XZRc5q06GfgIJv/4HKknUeQi5vxyxaxbMbfCJv/JG FJSGwWW7NodKL2uCahBKbf330AJJdCY85MWLKEoWpHIkLPpOstQfDd7uoQ1c1X1ZYqah U9dwWW7JZwwxO3N+pim5NNMf5WijlXBp0MqqMYJVqfDzP+IBTgAgB9BxtnGs+BNLOA6s 6JTA== 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=lySiL5MX6YPwTWrtLpMSfWiANSjXzkqgn9tzaZF5SEE=; b=eloAphPpf2Vx0M4xBDkyNHZNfk1r0L81dLOjsMw2JrWzjuFgYrkTFUwDsbt9XuwaV8 9tt+BNegR0HFLs6mYUQPRZfjquY3M7QSp5PzHJ1XR60A7z0LKA89552pc9ALA18j5l58 T2T7K14v0x8+5prIssDJHWLK4qxX4sk3wUREh1dDzVByx9P0MXT1YWN+TZb1aTe7DUc8 9WWh7+UV6VBRkuvxcRxRLWSLSloHsv+4JTr1tv/Luw/+gUgkNWbBbz9ni/nMtwGKlZI8 JeWpoCBGhbdoKyciQ1wOCrewu2G8tyXxU/20dpWSAS5XVVWjTN3Q98Q0hp3lDJvLkhUf b/bw== X-Gm-Message-State: ALyK8tILNX5g0fxvAx26cN1MQuJ9id7TKJ6EYvaBASrhw3lEVQUYfKAHMGApGKHjR350ag== X-Received: by 10.140.249.5 with SMTP id u5mr42994445qhc.24.1464867613678; Thu, 02 Jun 2016 04:40:13 -0700 (PDT) Received: from ?IPv6:2601:a40:100:d3:5422:d39a:331c:7262? ([2601:a40:100:d3:5422:d39a:331c:7262]) by smtp.gmail.com with ESMTPSA id o128sm13663868qkb.40.2016.06.02.04.40.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 04:40:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9141EE6E-EAF2-4FCC-83DA-80D48195D209" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Thu, 2 Jun 2016 07:40:10 -0400 Message-Id: References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF STIR Mail List , Russ Housley , "Peterson, Jon" , Brian Rosen Subject: Re: [stir] 4474bis identity header - full JWT by default vs canon 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, 02 Jun 2016 11:40:18 -0000 --Apple-Mail=_9141EE6E-EAF2-4FCC-83DA-80D48195D209 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Christer, Canonicalization rules in rfc4474bis are defined to either reconstruct = or verify values in the claim based on whether you use canon in identity = header or not. This was the intent of the original question and coming = up with more consensus on what folks think should be default. To address your specific concerns,=20 otn and ouri are intended to be about identity assertion, not SIP header = syntax validation. For telephone identities, it should be clear that otn/dtn should be = used, this is what rfc4474bis defines.=20 Beyond rfc4474bis, I would ask if folks think the reference to RFC3986 = in PASSporT draft is enough to avoid confusion for ouri and duri general = URI scheme/user/domain as Jon describes. I think so, but willing to = reconsider more text to clarify further. Additionally going forward, I would suspect there will likely be other = higher level documents that may describe specific URI usage either in = webrtc or non-telephone identity SIP deployments or XMPP or other = domains, so i think we are ok personally. -Chris > On Jun 2, 2016, at 3:12 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I think the encoding issue IS related to Chris=92s question =96 = assuming the question was whether to include the JWT claims :) >=20 > Including the claims in the JWT will show exactly what was used to = calculate the signature . Then, when comparing the claims to the = associated SIP header field values, endpoints can check whether any = deviations is because of encoding differences, or whether the compared = values are actually different. >=20 > Otherwise, we need to make sure that the sender and the receiver will = use exactly the same values for calculating the signature. For SIP-URIs = we can probably use the RFC 3261 canonicalisation rules for doing that. >=20 > Just one question: are there other JWT use-cases where the claims = aren=92t included? Is it a valid JWT? Will off-the-shelf decoders be = able to handle such JWTs? >=20 > Regards, >=20 > Christer >=20 > From: Jon Peterson > > Date: Wednesday 1 June 2016 at 21:19 > To: Christer Holmberg >, Brian Rosen >, Russ Housley > > Cc: IETF STIR Mail List > > Subject: Re: [stir] 4474bis identity header - full JWT by default vs = canon >=20 >=20 > This may then be a confusion that has crept in over the many steps = we've taken in transition to PASSporT, but the original intention was = for the ouri/duri not to contain parameters or other component of the = SIP URI apart from the scheme, the user part, the @ sign, and the host = part. Indeed, a call recently came from Cullen to consider just using an = 822 email-style identifier without the scheme for better compatibility = with WebRTC and through gateways. Whatever we end up using for = ouri/duri, it should handle case sensitivity and so on. >=20 > But again - this is a separate issue from the one Chris was trying to = raise. >=20 > Jon Peterson > Neustar, Inc. >=20 > From: Christer Holmberg > > Date: Wednesday, June 1, 2016 at 10:23 AM > To: Jon Peterson >, Brian Rosen >, Russ Housley > > Cc: IETF STIR Mail List > > Subject: RE: [stir] 4474bis identity header - full JWT by default vs = canon >=20 >> Hi, >> =20 >> >This addresses a very different question than what Chris was asking = when he kicked off this thread, but to this point: the header >> >and claim values in baseline PASSporT do not take the entire content = of any header field value from SIP in such a way that whitespace=20 >> >concerns will arise. The claims all take some single syntactical = element: extracting the addr-spec, say,=20 >> =20 >> The SIP(S)-URI is an instance of addr-spec, and it contains parts = that can be separated by whitespaces. In addition, some parts are also = case-insensitive, some parts can be escaped, and I assume the order of = URI parameters can also change.=20 >> =20 >> See section 19.1.4 of RFC3261 for examples of URIs with different = encodings but equivalent values. >> =20 >> >or the contents of the "info" parameter of Identity, or what have = you. Since "iat" is used instead of the Date header field value, even = that has no whitespace concerns. >> =20 >> True. And, as =93iat=94 is carried as a JWT claim, it can=92t be = =93legally=94 modified using the SIP encoding rules. >> =20 >> Regards, >> =20 >> Christer >> =20 >> =20 >> From: stir > on = behalf of Christer Holmberg > >> Date: Wednesday, June 1, 2016 at 9:05 AM >> To: Brian Rosen >, Russ = Housley > >> Cc: IETF STIR Mail List > >> Subject: Re: [stir] 4474bis identity header - full JWT by default vs = canon >> =20 >>> Hi, >>>=20 >>> We obviously need to check whether the issues apply to the STIR = usage of JWT - my comments were general, and we need to keep them in = mind. >>>=20 >>> If we e.g. are going to calculate the signature based on a phone = number, there will be no space characters etc between the digits. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> Sent from my Windows Phone >>> From: Brian Rosen >>> Sent: 01/06/2016 18:59 >>> To: Russ Housley >>> Cc: Christer Holmberg ; IETF = STIR Mail List >>> Subject: Re: [stir] 4474bis identity header - full JWT by default vs = canon >>>=20 >>> This would require a reasonable amount of work to document = correctly. >>>=20 >>> If we really want to do this, I might be willing to create a straw = man of what was needed. >>>=20 >>> I am mostly responsible for the (crummy) ABNF in 3261 so I feel = obligated to volunteer :( >>>=20 >>> Brian >>> > On Jun 1, 2016, at 11:39 AM, Russ Housley > wrote: >>> >=20 >>> >=20 >>> >> Now, keep in mind that, when you calculate the JWT signature = using the JWT >>> >> claims, each claim value is considered a string, which means = every >>> >> character (including space characters) count when calculating the >>> >> signature. >>> >>=20 >>> >> For example, if one claim represents the SIP Cseq value: >>> >>=20 >>> >> { >>> >> =93CSeq": =931234INVITE=94 >>> >> } >>> >>=20 >>> >> =85will not (afaik) produce the same signature value as: >>> >>=20 >>> >> { >>> >> =93CSeq": =931234INVITE=94 >>> >> } >>> >=20 >>> > Correct. >>> >=20 >>> > We find this all the time in security protocols. You need to be = strict in what you send, otherwise the receiver will not be able to = verify it. >>> >=20 >>> > If there is any ambiguity in the strings that can be produced, = then the canon procedure should eliminate the ambiguity. In the above, = replace multiple occurrence of with a single . >>> >=20 >>> > Russ >>> >=20 >>> > _______________________________________________ >>> > 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=_9141EE6E-EAF2-4FCC-83DA-80D48195D209 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Christer,

Canonicalization rules in rfc4474bis are defined to either = reconstruct or verify values in the claim based on whether you use canon = in identity header or not.  This was the intent of the original = question and coming up with more consensus on what folks think should be = default.

To = address your specific concerns, 
otn and ouri = are intended to be about identity assertion, not SIP header syntax = validation.

For = telephone identities, it should be clear that otn/dtn should be used, = this is what rfc4474bis defines. 

Beyond rfc4474bis, I would ask if folks = think the reference to RFC3986 in PASSporT draft is enough to avoid = confusion for ouri and duri general URI scheme/user/domain as Jon = describes.  I think so, but willing to reconsider more text to = clarify further.

Additionally going forward, I would suspect there will likely = be other higher level documents that may describe specific URI usage = either in webrtc or non-telephone identity SIP deployments or XMPP or = other domains, so i think we are ok personally.

-Chris


On Jun 2, 2016, at 3:12 AM, = Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

I think the encoding = issue IS related to Chris=92s question =96 assuming the question was = whether to include the JWT claims :)

Including the claims in = the JWT will show exactly what was used to calculate the signature . = Then, when comparing the claims to the associated SIP header field = values, endpoints can check whether any deviations is because of = encoding differences, or whether the compared values are actually = different.

Otherwise, we need to make sure that the sender and the = receiver will use exactly the same values for calculating the signature. = For SIP-URIs we can probably use the RFC 3261 canonicalisation rules for = doing that.

Just one question: are there other JWT use-cases where = the claims aren=92t included? Is it a valid JWT? Will off-the-shelf = decoders be able to handle such JWTs?

Regards,

Christer

From: Jon Peterson <jon.peterson@neustar.biz>
Date: Wednesday 1 June = 2016 at 21:19
To: Christer Holmberg = <christer.holmberg@ericsson.com>, Brian Rosen <br@brianrosen.net>, Russ = Housley <housley@vigilsec.com>
Cc: IETF STIR Mail List = <stir@ietf.org>
Subject: Re: [stir] 4474bis = identity header - full JWT by default vs canon


This may = then be a confusion that has crept in over the many steps we've taken in = transition to PASSporT, but the original intention was for the ouri/duri = not to contain parameters or other component of the SIP URI apart from = the scheme, the user part, the @ sign, and the host part. Indeed, a call = recently came from Cullen to consider just using an 822 email-style = identifier without the scheme for better compatibility with WebRTC and = through gateways. Whatever we end up using for ouri/duri, it should = handle case sensitivity and so on.

But again - this is a separate issue = from the one Chris was trying to raise.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Wednesday, June 1, = 2016 at 10:23 AM
To: Jon Peterson <jon.peterson@neustar.biz>, = Brian Rosen <br@brianrosen.net>,= Russ Housley <housley@vigilsec.com>
Cc: IETF STIR Mail List = <stir@ietf.org>
Subject: RE: [stir] 4474bis = identity header - full JWT by default vs canon

Hi,
 
>This addresses a very = different question than what Chris was asking when he kicked off this = thread, but to this point: the header
>and claim values in baseline PASSporT = do not take the entire content of any header field value from SIP in = such a way that whitespace 
>concerns will arise. The = claims all take some single syntactical element: extracting the = addr-spec, say, 
 
The SIP(S)-URI is an = instance of addr-spec, and it contains parts that can be separated by = whitespaces. In addition, some parts are also case-insensitive, some = parts can be escaped, and I assume the order of URI parameters can also = change. 
 
See section 19.1.4 of RFC3261 for examples of = URIs with different encodings but equivalent values.
 
>or the = contents of the "info" parameter of Identity, or what have you. Since = "iat" is used instead of the Date header field value, even that has no = whitespace concerns.
 
True. And, as =93iat=94 is carried as a JWT = claim, it can=92t be =93legally=94 modified using the SIP encoding = rules.
 
Regards,
 
Christer
 
 
From: stir <stir-bounces@ietf.org> on behalf of Christer Holmberg = <christer.holmberg@ericsson.com>
Date: Wednesday, June 1, 2016 = at 9:05 AM
To: Brian Rosen <br@brianrosen.net>, Russ = Housley <housley@vigilsec.com>
Cc: IETF = STIR Mail List <stir@ietf.org>
Subject: Re: [stir] 4474bis = identity header - full JWT by default vs canon
 
Hi,

We obviously need to check whether the issues apply to the = STIR usage of JWT - my comments were general, and we need to keep them = in mind.

If we e.g. are going to calculate = the signature based on a phone number, there will be no space characters = etc between the digits.

Regards,

Christer

Sent = from my Windows Phone

From: Brian Rosen
Sent: 01/06/2016 18:59
To: Russ Housley
Cc: Christer Holmberg; IETF STIR Mail List
Subject: Re: [stir] 4474bis identity header - full JWT by default vs = canon

This would require a reasonable amount of work to document = correctly.

If we really want to do this, I = might be willing to create a straw man of what was needed.

I am mostly responsible for the (crummy) ABNF = in 3261 so I feel obligated to volunteer :(

Brian
> On Jun 1, 2016, at 11:39 AM, Russ = Housley <housley@vigilsec.com> wrote:
> 
> 
>> = Now, keep in mind that, when you calculate the JWT signature using the = JWT
>> claims, each claim value is considered a = string, which means every
>> character (including = space characters) count when calculating the
>> = signature.
>> 
>> For = example, if one claim represents the SIP Cseq value:
>> 
>> {
>>       =93CSeq": = =931234<SP>INVITE=94
>> }
>> 
>> =85will not (afaik) produce the same signature value = as:
>> 
>> = {
>>       =93CSeq": = =931234<SP><SP><SP>INVITE=94
>> = }
> > Correct.
> 
> We find = this all the time in security protocols.  You need to be strict in = what you send, otherwise the receiver will not be able to verify it.
> 
> If there is any ambiguity in the strings that can be = produced, then the canon procedure should eliminate the ambiguity.  = In the above, replace multiple occurrence of <SP> with a single = <SP>.
> 
> Russ
> 
> _______________________________________________
> 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=_9141EE6E-EAF2-4FCC-83DA-80D48195D209-- From nobody Thu Jun 2 07:16: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 C5D1412D73A for ; Thu, 2 Jun 2016 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 brbxFctB7lBe for ; Thu, 2 Jun 2016 07:16:26 -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 B8D0712D72E for ; Thu, 2 Jun 2016 07:16:25 -0700 (PDT) Received: from unnumerable.local (inet-141-146-6-188.oracle.com [137.254.4.60]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u52EGOZs094678 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 2 Jun 2016 09:16:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host inet-141-146-6-188.oracle.com [137.254.4.60] claimed to be unnumerable.local To: stir@ietf.org From: Robert Sparks Message-ID: Date: Thu, 2 Jun 2016 10:16:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [stir] Minutes: STIR Interim May 27 2016 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, 02 Jun 2016 14:16:28 -0000 Minutes are available at https://www.ietf.org/proceedings/interim/2016/05/27/stir/minutes/minutes-interim-2016-stir-1 Please send any necessary corrections to the chairs. RjS From nobody Mon Jun 6 14:44:08 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 9B75A12D94B for ; Mon, 6 Jun 2016 14:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 DzBO4OPuX3om for ; Mon, 6 Jun 2016 14:44:05 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 1AE1412D93C for ; Mon, 6 Jun 2016 14:44:05 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 23so17256817qtq.0 for ; Mon, 06 Jun 2016 14:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=gAKtcCu6q1lpRe+jW+PjVxeS3J3XQIBDx5hZLx/kHC4=; b=TtF9LiEMQTO/3e9at0YqpSTpFoWAXUKs+nSOZ4hLiVOMCZbMOhsTjeUFIwL3REeulb SpouDYqXW5b45YN8IvYYGJkQbI1epxr0Tn+n8wJfti/HZJRnem+489E587+B5jMl/kyY uvBSJHMPaNfpmqsp7C2snsvAnXwuByHR/iI5o= 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:subject :message-id:date:to:mime-version; bh=gAKtcCu6q1lpRe+jW+PjVxeS3J3XQIBDx5hZLx/kHC4=; b=ASU+h6qCY7LMdDRFtYIb8IgeQSAJGg4J4xcO9jgNeApfSt7GS0Cu8DUGhUO/a2ZC24 if61L7sgd5BAzmF9uUQhg2NFBeG5dTEf3QYVadqBOu1sBP0i6A27UY0veYeTJjxwe7KE nzhO9dis7036HF5RXfSUPIQz/ADKnZBU6YWXB8iaC/0eQPLtR1R8wLXK6vUoyjLmVcjG anmsFQ1Zp6jExVlaQuAFSg/I7nlH7e/7yV/w8eGTWRvAU6eVjwcwY7zuYrekL/+LaFnc 2zZm7wQeZWA0/1YG5+KPLSsc+68dmUr6bcFkHFAYDubWZBaBZyVU/ytso3CQWfvdQARw B+wQ== X-Gm-Message-State: ALyK8tJgawzn3NlxzxeGqPxkh2W/JbJuSGbLyaXddRUA0EyilyQk1O8VqFugQWnWjrccmQ== X-Received: by 10.200.44.5 with SMTP id d5mr5979814qta.77.1465249443474; Mon, 06 Jun 2016 14:44:03 -0700 (PDT) Received: from [5.5.33.185] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id p13sm5692896qke.7.2016.06.06.14.44.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Jun 2016 14:44:02 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 6 Jun 2016 13:18:00 -0400 To: stir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [stir] draft-ietf-stir-certificates: ASN.1 Module 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, 06 Jun 2016 21:44:06 -0000 At last virtual interim, I took the action item to do the ASN.1 module. = Here=E2=80=99s what I think we need to do get it done: 0) This is way in the ASN.1 weeds, but we need to decide whether the = ASN.1 tags will be explicit or implicit. I=E2=80=99m hoping that we can = just go with explicit because it=E2=80=99s the default, I think it makes = debugging slightly easier at the expense of two bytes if you use the = spid or range choices (see #1). Also, the OCSP module is EXPLICIT so = it=E2=80=99s kind of matchy-matchy there; X.509 certificates extensions = are both explicitly and implicitly tagged extensions so nothing really = to gain there. If anybody coded this up with an IMPLICIT ASN.1 module please speak up = now! 1) #0 was a bit of trick question because it turns out we need to add = some tags to the TNEntry choice; two of the choices are of the same type = and you would have gotten an error had you tried to compile the ASN.1 = with either implicit or explicit tags so =E2=80=A6 we need to add the = tags in s8: OLD: TNEntry ::=3D CHOICE { spid ServiceProviderIdentifierList, range TelephoneNumberRange, one E164Number } NEW: TNEntry ::=3D CHOICE { spid [0] ServiceProviderIdentifierList, range [1] TelephoneNumberRange, one E164Number } 2) Do the following in s8 (we know which arc this OID will come from): OLD: id-ce-TNAuthList OBJECT IDENTIFIER ::=3D { TBD } NEW: id-ce-TNAuthList OBJECT IDENTIFIER ::=3D { id-ce TBD } 3) We need four OIDs. Three of them are listed in the IANA section = already we just need to add some words to get the ASN.1 module OID so do = the following: 3.a) In s11, do the following replace: OLD .. and the TN by reference AIA access descriptor defined in Section 9.3. NEW:=20 .. the TN by reference AIA access descriptor defined in Section 9.3, and the ASN.1 module identifier defined in Appendix A. 3.b) Add the following to the bulleted list in s11: - The TN ASN.1 module in SMI Security for PKIX Module Identifier registry: http://www.iana.org/assignments/smi-numbers/ smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0 4) The following module needs to be added in Appendix A; it replaces the = TBD that=E2=80=99s there now. Note that Russ and I got this to compile = albeit with dummy numbers in place of the 4 TBDs. This ASN.1 module imports ASN.1 from [RFC5912]. TN-Module { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(TBD) } DEFINITIONS EXPLICIT TAGS ::=3D=20 BEGIN IMPORTS id-ad, id-ad-ocsp -- =46rom RFC = 5912 FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } id-ce -- =46rom RFC = 5912 FROM PKIX1Implicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } EXTENSION -- =46rom RFC = 5912 FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; -- TN Entry Certificate Extension ext-tnAuthList EXTENSION ::=3D { SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList } TNAuthorizationList ::=3D SEQUENCE SIZE (1..MAX) OF TNAuthorization TNAuthorization ::=3D SEQUENCE SIZE (1..MAX) OF TNEntry TNEntry ::=3D CHOICE { spid [0] ServiceProviderIdentifierList, range [1] TelephoneNumberRange, one E164Number } ServiceProviderIdentifierList ::=3D SEQUENCE SIZE (1..3) OF OCTET STRING -- When all three are present: SPID, Alt SPID, and Last Alt SPID TelephoneNumberRange ::=3D SEQUENCE { start E164Number, count INTEGER } E164Number ::=3D IA5String (SIZE (1..15)) (FROM ("0123456789")) -- TN OCSP Extension =20 re-ocsp-tn-query EXTENSION ::=3D { SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn } TNQuery ::=3D E164Number -- TN Access Descriptor =20 id-ad-stir-tn OBJECT IDENTIFIER ::=3D { id-ad TBD } -- -- Object Identifiers -- id-pkix-ocsp OBJECT IDENTIFIER ::=3D id-ad-ocsp id-ce-TNAuthList OBJECT IDENTIFIER ::=3D { id-ce TBD } id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::=3D { id-pkix-ocsp TBD } END 5) We should add a normative reference to RFC 5912. 6) We should also go ahead and get these OID-related TBDs: Chairs can this be considered the early IANA allocation request as per = RFC 7120 or would you prefer a separate email to get that going? spt= From nobody Mon Jun 6 15:04:53 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 DC7F412D62A for ; Mon, 6 Jun 2016 15:04:49 -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 iEvjGyxiiJZp for ; Mon, 6 Jun 2016 15:04:48 -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 D04C812D169 for ; Mon, 6 Jun 2016 15:04:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C97763002B9 for ; Mon, 6 Jun 2016 18:04:46 -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 clPCrEhr8A1G for ; Mon, 6 Jun 2016 18:04:46 -0400 (EDT) Received: from [172.20.9.181] (unknown [40.141.115.126]) by mail.smeinc.net (Postfix) with ESMTPSA id A886B300090; Mon, 6 Jun 2016 18:04:45 -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: Mon, 6 Jun 2016 18:04:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sean Turner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF STIR Mail List Subject: Re: [stir] draft-ietf-stir-certificates: ASN.1 Module 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, 06 Jun 2016 22:04:50 -0000 Sean: > Chairs can this be considered the early IANA allocation request as per = RFC 7120 or would you prefer a separate email to get that going? Once the ASN.1 module wis in an Internet-Draft, then we can ask the IESG = to assign the OIDs if there is WG consensus to do so. Russ From nobody Wed Jun 8 13:46: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 9B6AD12B02B for ; Wed, 8 Jun 2016 13:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_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=kingsmountain.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 jPqtknar3G8n for ; Wed, 8 Jun 2016 13:45:56 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 0058B12D5A4 for ; Wed, 8 Jun 2016 13:45:55 -0700 (PDT) Received: (qmail 7262 invoked by uid 0); 8 Jun 2016 20:45:54 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 8 Jun 2016 20:45:54 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id 4Llp1t0182UhLwi01LlsF7; Wed, 08 Jun 2016 14:45:53 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=6qHR6fFD4mAA:10 a=pD_ry4oyNxEA:10 a=aEwu485HAAAA:8 a=ggemEP80g0Jsq2rd4boA:9 a=rUjQ5dujbrkzKPoQ:21 a=Rzb0-1vbITROl3oJ:21 a=QEXdDO2ut3YA:10 a=tJsgAKyPG8QA:10 a=-YmywBibo81xt5K9TajD:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=ELSOILDBQ9FNxHWFyPot6L9xufyqTxhrK/JBi3yGRqM=; b=t4GMoQMRo/vYQ/gTgs393KjnSl UQMd/6CIiex3aviOjErGp7uWwXuOb8p+HALARcGUx8cTQQwr2PPxK7A3gN9QCjLTrqW+5r50GVUxu yntE6ktYmIMnpIO04/OwtHcL0; Received: from [70.197.11.205] (port=9804 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1bAkMH-00006V-G4 for stir@ietf.org; Wed, 08 Jun 2016 14:45:49 -0600 To: IETF STIR WG From: =JeffH Message-ID: <575883F0.5030800@KingsMountain.com> Date: Wed, 8 Jun 2016 13:45:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.11.205 authed with jeff.hodges+kingsmountain.com} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-Source-IP: 70.197.11.205 X-Exim-ID: 1bAkMH-00006V-G4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.0.0.1]) [70.197.11.205]:9804 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [stir] fyi: Characterizing the Security of, the SMS Ecosystem with Public Gateways 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, 08 Jun 2016 20:45:57 -0000 of possible interest.. Sending out an SMS: Characterizing the Security of the SMS Ecosystem with Public Gateways http://www.ieee-security.org/TC/SP2016/papers/0824a339.pdf Abstract Text messages sent via the Short Message Service (SMS) have revolutionized interpersonal communication. Recent years have also seen this service become a critical component of the security infrastructure, assisting with tasks including identity verification and second-factor authentication. At the same time, this messaging infrastructure has become dramatically more open and connected to public networks than ever before. However, the implications of this openness, the security practices of benign services, and the malicious misuse of this ecosystem are not well understood. In this paper, we provide the first longitudinal study to answer these questions, analyzing nearly 400,000 text messages sent to public online SMS gateways over the course of 14 months. From this data, we are able to identify not only a range of services sending extremely sensitive plaintext data and implementing low entropy solutions for one-use codes, but also offer insights into the prevalence of SMS spam and behaviors indicating that public gateways are primarily used for evading account creation policies that require verified phone numbers. This latter finding has significant implications for research combatting phone-verified account fraud and demonstrates that such evasion will continue to be difficult to detect and prevent. From nobody Mon Jun 13 20:27:07 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 5E1E512D586; Mon, 13 Jun 2016 20:27:04 -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.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160614032704.6896.5830.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 20:27:04 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-passport-03.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: Tue, 14 Jun 2016 03:27:05 -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-03.txt Pages : 17 Date : 2016-06-13 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 (e.g. the telephone number or URI) and verify the accuracy of this 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 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 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-passport-03 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 Jun 16 03:34: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 C5AD312B058 for ; Thu, 16 Jun 2016 03:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xe4VKMJPAfCM for ; Thu, 16 Jun 2016 03:33:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E54127078 for ; Thu, 16 Jun 2016 03:33:57 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-50-576280933159 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.BE.12926.39082675; Thu, 16 Jun 2016 12:33:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0294.000; Thu, 16 Jun 2016 12:33:55 +0200 From: Christer Holmberg To: "stir@ietf.org" Thread-Topic: [stir] I-D Action: draft-ietf-stir-passport-03.txt - reference nit Thread-Index: AQHRx7qUUeZQjTPW9UCdROzad1AXKw== Date: Thu, 16 Jun 2016 10:33:54 +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.4.160422 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C51CA640FD50740B7618A93C9C4F042@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7uO7khqRwg/u3rS2Wr93G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMd9K5kLropUXD/4gbmBcZ1AFyMHh4SAicTzA9VdjJxAppjE hXvr2boYuTiEBI4wSiw9uoIJwlnCKLH65QEmkAY2AQuJ7n/aIA0iAsoSW9bdYQexhQUCJbrO djBBxIMk9ux+D2XrSaxbMpsNpJVFQFXiZzcnSJhXwEpix4IbbCA2I9De76fWgJUzC4hL3Hoy nwniHgGJJXvOM0PYohIvH/9jBbFFgUZ+uTePESKuKLHzbDszRK+exI2pU9ggbGuJ78fWQc3U lli28DUzxF5BiZMzn7BMYBSdhWTdLCTts5C0z0LSPgtJ+wJG1lWMosWpxUm56UbGeqlFmcnF xfl5enmpJZsYgXFycMtv1R2Ml984HmIU4GBU4uF9cD4xXIg1say4MvcQowQHs5II77uapHAh 3pTEyqrUovz4otKc1OJDjNIcLErivP4vFcOFBNITS1KzU1MLUotgskwcnFINjNye3sn5P5N1 DpvMbdUoC/glfFtRNP1H6OepYZO5T/DM7+1c6seSKXg5zH2e4bLMf//O2q4tE9L0u7Dpxsv6 Q0Js5vMVV5UZfbzFtuiHa4OYOYtFZXb2esOFFhlLGG5ts/ZpztXylIiWkClM9lGc5lt73ait 5r/WxzmRj2zOKSyz6pyfkyqlxFKckWioxVxUnAgAyUy4DY8CAAA= Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-03.txt - reference nit 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, 16 Jun 2016 10:34:01 -0000 Hi, The text in section 3.2.2.1.1 says: "Telephone Number strings for "otn" and "dtn" claims MUST be canonicalized according to the procedures specified in [I-D.ietf-stir-rfc4474bis] Section 6.1.1.=B2 However, there is no section 6.1.1 in the latest version (-09) of 4474bis. I assume it should be section 7.1.1. Regards, Christer On 14/06/16 06:27, "stir on behalf of internet-drafts@ietf.org" wrote: > >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-03.txt > Pages : 17 > Date : 2016-06-13 > >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 (e.g. the telephone number or URI) and verify > the accuracy of this 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 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 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-03 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-03 > > >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/ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Tue Jun 21 21:05: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 53F7F12D1AD for ; Tue, 21 Jun 2016 21:05:15 -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 GsM63fEbgtgK for ; Tue, 21 Jun 2016 21:05:13 -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 22CA712D60E for ; Tue, 21 Jun 2016 21:05:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id c73so49498515qkg.2 for ; Tue, 21 Jun 2016 21:05:13 -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=sZccHFzVjhAZmll5XROb3M18tyce3XfIo0V1ONvsdEQ=; b=evPJ04PMPFaDONjZ9F0XjoW+RXVkipTgQ9/evda5qlsifKHUBa7pd30y+15pdVaXXG SwUqqq7ULqfGitc2qF8zEO1ZsBYrtNXHBgb83U+YDnQHMFrazlQ+YS8IuFe6AW240xHu GHkdLJcbQdsFbjjLsl7JWH1Rl7QoCqE+HP6q2hM3XND0l3UIz48aglai0LNK24RAxEqJ AWHgrs9Zn67e57ysH40w13vVEgUFADNZ2YEUHzhXxaAp3Dr3rm3zWt/soKYinIu2Be3S hqEhRDhMz/h3JotET896OQgKQwcSTlFThRFZTVPa3XI7bZhMCsOEIwI86BUH4y/Wpx5Q 9BuQ== 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=sZccHFzVjhAZmll5XROb3M18tyce3XfIo0V1ONvsdEQ=; b=EovPWzwvfkKgFFmTatdi77yheu60kUlTbrzelZtqdsZBZ+deFbcTawJzk8i3mfqa7K yHJCycsgq3sVMwK8yHDziBVf2tzkILa624zTlIbzlVGUwG6ZSljIGBjt6fnpiHOVb/xy pgyzZ0Eva1Vur80UIzwDWPYfwBR6vkz//JrzQBB88Zu7hTKvD4NLFmrBqy18Nki3L6C0 OToWUqBRwF7atVd7DHkoW42RIWRKuJgSVkFo6LsrXNZCjxRxxSVxcusGli8/tmr6OO/U FfuiU5wQRn9r2aHgS7BQcbgDz2eEPMs8CR6hyqCC5xyE0fe4SgoA1pIr/sbGwzIhqcnc wkDA== X-Gm-Message-State: ALyK8tLUgcIli5uDSkvDEhZwGn1oFxWjwI23cOPzZ0umCQuVrPqpT6MA9XkeNS737Lu/oA== X-Received: by 10.55.82.8 with SMTP id g8mr35238471qkb.133.1466568312255; Tue, 21 Jun 2016 21:05:12 -0700 (PDT) Received: from [192.168.4.178] (ip-64-134-241-150.public.wayport.net. [64.134.241.150]) by smtp.gmail.com with ESMTPSA id 23sm20111944qty.40.2016.06.21.21.05.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 21:05:11 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chris Wendt In-Reply-To: Date: Wed, 22 Jun 2016 00:05:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <96D82F69-D713-48BF-B023-CC2CC8E4ECAD@chriswendt.net> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "stir@ietf.org" Subject: Re: [stir] I-D Action: draft-ietf-stir-passport-03.txt - reference nit 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, 22 Jun 2016 04:05:15 -0000 Yes, thanks for that. Noted. -Chris > On Jun 16, 2016, at 6:33 AM, Christer Holmberg = wrote: >=20 >=20 > Hi, >=20 > The text in section 3.2.2.1.1 says: >=20 > "Telephone Number strings for "otn" and "dtn" claims MUST be > canonicalized according to the procedures specified in > [I-D.ietf-stir-rfc4474bis] Section 6.1.1.=B2 >=20 >=20 > However, there is no section 6.1.1 in the latest version (-09) of = 4474bis. >=20 > I assume it should be section 7.1.1. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On 14/06/16 06:27, "stir on behalf of 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 : Persona Assertion Token >> Authors : Chris Wendt >> Jon Peterson >> Filename : draft-ietf-stir-passport-03.txt >> Pages : 17 >> Date : 2016-06-13 >>=20 >> 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 (e.g. the telephone number or URI) and verify >> the accuracy of this 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 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 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-03 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-passport-03 >>=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 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Jun 23 14:12:22 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 4911312D80D for ; Thu, 23 Jun 2016 14:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.9 X-Spam-Level: X-Spam-Status: No, score=-100.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, USER_IN_WHITELIST=-100] 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 mQAfUIJPocxy for ; Thu, 23 Jun 2016 14:12:21 -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 CA60F12D180 for ; Thu, 23 Jun 2016 14:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 99A5330048F for ; Thu, 23 Jun 2016 17:12: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 2o1jpw6OKJ_u for ; Thu, 23 Jun 2016 17:12:17 -0400 (EDT) Received: from russellsleysmbp.home (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 81AED300263 for ; Thu, 23 Jun 2016 17:12:17 -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: <2fe6853c-8e83-77d1-e9fc-8848a1387ab9@nostrum.com> Date: Thu, 23 Jun 2016 17:12:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66BCE048-8119-46CF-ACB6-03E5ACEDC8FB@vigilsec.com> References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> <01f41eda-4484-e891-bbae-b85eabdf8254@nostrum.com> <2fe6853c-8e83-77d1-e9fc-8848a1387ab9@nostrum.com> To: IETF STIR Mail List X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [stir] Using PASSporT with things other than STIR 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, 23 Jun 2016 21:12:22 -0000 I think that the stir-passport document meets all of the needs for STIR. However, I do not think that the stir-passport document has enough information in it to help a developer use the PASSporT framework with other applications. I hope the addition of a bit more information can resolve this issue. Since the stir-passport document meets all of the needs for STIR, I do not think this should delay the start of Working Group Last Call on this document. In Section 4.3, the stir-passport document says: > Some applications may want to use the mechanism of the PASSporT > digital signature that is not a superset of the base set of claims of > the PASSporT token as defined in Section 3. I do not understand this sentence. Please explain it. I can imagine that other applications may want to generate PASSporT objects that are not a strict superset of the base set of headers and claims defined in Section 3. What does such an application need to specify? We get a hint in the next couple of sentences. > Rather, a specification > may use PASSporT with its own defined set of claims. > In this case, the specification SHOULD define its own MIME media type > [RFC2046] in the "Media Types=94 registry [IANA.MediaTypes]. I think that this means: "Such applications of PASSporT may want to operate from an entirely different set of claims. Those PASSporT-using applications may define their own set of claims by registering a new MIME media type in the "Media Types" registry.=94 I do not think that we can use normative language here. This section goes on to say: > The MIME > subtype SHOULD start with the string "passport-" to signify that it > is related to the PASSporT token. For example, for the "foo" > application the MIME type/sub-type could be defined as "application/ > passport-foo". I think tho part needs to be cast as advice to the developers on future PASSporT-using applications. Can we offer any advice to the developer to help them decide when it is necessary to use an alternate set of claims? Also, can we offer any advice regarding the properties that are needed to determine if an alternate claim set meets the security requirements? For example, during the development of STIR we wanted to prevent cut-and-paste attacks. Are there any implications on interoperability for adopting a different set of claims? Can we offer any guidance that tells the developer when it would be better to start fresh with JOSE JWS instead of trying to adjust PASSporT? In other words, where should one try to apply the PASSporT framework, and where should one not bother. Russ From nobody Fri Jun 24 09:06:21 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 32CC112DC5F; Fri, 24 Jun 2016 09:00:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160055.10933.82765.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:55 -0700 Archived-At: Cc: stir@ietf.org, alissa@cooperw.in Subject: [stir] stir - Requested session has been scheduled for IETF 96 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, 24 Jun 2016 16:00:56 -0000 Dear Robert Sparks, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. stir Session 1 (2:00:00) Tuesday, Afternoon Session I 1400-1600 Room Name: Schoeneberg size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- 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): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: acme tls ecrit avtcore dane siprec p2psip rtcweb mmusic sipcore dispatch appsawg ice modern Second Priority: perc slim netvc clue tcpinc cose uta ace saag jose oauth Special Requests: --------------------------------------------------------- From nobody Sat Jun 25 05:43:13 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 DA2A9127058; Sat, 25 Jun 2016 05:43:07 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160625124307.17196.4308.idtracker@ietfa.amsl.com> Date: Sat, 25 Jun 2016 05:43:07 -0700 Archived-At: Cc: stir@ietf.org Subject: [stir] I-D Action: draft-ietf-stir-certificates-05.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, 25 Jun 2016 12:43:08 -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-05.txt Pages : 20 Date : 2016-06-25 Abstract: 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. 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-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-certificates-05 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 Jun 25 05:52: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 D383D12B004 for ; Sat, 25 Jun 2016 05:52:04 -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 vk0F5INL_pux for ; Sat, 25 Jun 2016 05:52:02 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 B605C127058 for ; Sat, 25 Jun 2016 05:52:02 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id w59so5189227qtd.3 for ; Sat, 25 Jun 2016 05:52:02 -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 :content-transfer-encoding:message-id:references:to; bh=z+pV9vzhnW+pgaMFADwjl0RjIiwlU66oSbvd4azC8sQ=; b=BPregTP/0XU79gitWijMZal/VGFX6wPzZEqbBOUMj2VZ+aJHQGbB9OwFXr+7c1L9c7 YzJ3I/KAC2lqD/yI3OspcDOL0GFDT9bhRWFn3FPGfVC+f4rFCnDm+fJLKadc3qsKJOi6 1WsXV9wubApl3LXfTpf71bEY20S4+AOj9BPvQ= 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 :content-transfer-encoding:message-id:references:to; bh=z+pV9vzhnW+pgaMFADwjl0RjIiwlU66oSbvd4azC8sQ=; b=Om4oh3Os67lHGTwiavdeqLsgXnqeDOp9NtRiA2D97eDGLRp6rzCyTd78K1wwh+Vo2j FPawdEG7ALn+w1PZIPhAF7vH4Nfkki47/xeWh9Fk4UctLtn+g6nczpgiKyaYBjyyyWzq FM49dl4VF8uHM7oYzU8ezRGjJWNgzoeKyp2RYLCVU+sA5QjH94kz13dqTDnB1UXVl+5E d9mFuwXxhjTiRyTo0u2TJkIuXLkn2ZohFWjw8IceeuX+rLmiUvJHs7Kb9ilOO78mi5Ye tNm/scNh59OF8BZK3A08Me03AQAsYBI9DGGIwvdRafw5QCILBxROevUk2UAHxW1FBIro rk7g== X-Gm-Message-State: ALyK8tL9rayM9ozYw4k7M1z81UrEV7KCMQ7gvtypvOzy0MYCkqtbktPvHFC6SCnCNv434g== X-Received: by 10.237.36.220 with SMTP id u28mr11456722qtc.30.1466859121847; Sat, 25 Jun 2016 05:52:01 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id g69sm1746634qke.47.2016.06.25.05.52.00 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 05:52:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160625124307.17196.4308.idtracker@ietfa.amsl.com> Date: Sat, 25 Jun 2016 08:51:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66DAD4D8-FCC1-4080-893D-2A821F949473@sn3rd.com> References: <20160625124307.17196.4308.idtracker@ietfa.amsl.com> To: stir@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [stir] I-D Action: draft-ietf-stir-certificates-05.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: Sat, 25 Jun 2016 12:52:05 -0000 This version incorporates ASN.1-related changes I distributed on 6/6 = [0]; also includes minor changes as a result of some XML-futzing and = removes some dangling references. The next version will include some LOA-related text as well as = answering/stripping the remaining TBDs. [0] = https://mailarchive.ietf.org/arch/msg/stir/QzShoEZrFeXW4L0qIxG3jRzEipY > On Jun 25, 2016, at 08:43, 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 : Secure Telephone Identity Credentials: = Certificates > Authors : Jon Peterson > Sean Turner > Filename : draft-ietf-stir-certificates-05.txt > Pages : 20 > Date : 2016-06-25 >=20 > Abstract: > 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 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-stir-certificates-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-stir-certificates-05 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sat Jun 25 05:54:50 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 1F32012B047 for ; Sat, 25 Jun 2016 05:54:49 -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 oPnLMViJ93mS for ; Sat, 25 Jun 2016 05:54:47 -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 9A712127058 for ; Sat, 25 Jun 2016 05:54:47 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id c73so171513424qkg.2 for ; Sat, 25 Jun 2016 05:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=9oMrSILuOEXM7wHKJWKUJC3sht4WW3NzS24mibe6JGA=; b=RHoRfWzR/2eiLBGkuvPz7V1uT2GFLybB0CLwSf3DhjQhia1zFf26CneLe5u6x+rOzK gL64K/GT6ajZ9+RLGV/XhGlyv+6NiLm7/FH1ryCAMU6IZ0DbrjLlIm/kTEqwzKt0QQaX mQRprFvLbrSf5mhJx/wo7uzRCNBl03n25Wc3o= 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:subject:date :message-id:cc:to:mime-version; bh=9oMrSILuOEXM7wHKJWKUJC3sht4WW3NzS24mibe6JGA=; b=Eh8dNcOTGrVwsmQE25U1oqVzQFYAhTb+GW/XpMoMYZ5aOcKowW4r8j558IK2AK3tnu dezvJbIFKZSqGIi4l9AdFce0wCDM9FXNSlX9alFviPyrK+PaYUPi+yFY/kResJwTy2vi SDSwDZ3y0th9RkuBQG7E+VWi8Z7OtgJ/tDbmdZpIuYcfEKu5JD/SO29akPNw510hyFYZ J8L0PuriCrr8oyBhneS92OvzJmHyKMHyc00u2E4BMmWvSwemGgIMI3WZqotSMNS34ppQ Rp3B5EJG3WejBZukcrAz6ABWFhu4spD0wUGsYp4pIXH393q2js09IUt9zUYJE5c0CllM fFXA== X-Gm-Message-State: ALyK8tLgOqOC/ftRGcBhUYE0WL1gFxq0CEn1vd6wLluF7upKFCAR5dOG+RPxWDY5s8O4Fw== X-Received: by 10.55.26.102 with SMTP id a99mr7480197qka.145.1466859286780; Sat, 25 Jun 2016 05:54:46 -0700 (PDT) Received: from [172.16.0.112] ([96.231.230.69]) by smtp.gmail.com with ESMTPSA id u79sm4465147qka.8.2016.06.25.05.54.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 05:54:46 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Jun 2016 08:54:45 -0400 Message-Id: To: stir-chairs@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: stir@ietf.org Subject: [stir] early IANA code point assignment request 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, 25 Jun 2016 12:54:49 -0000 Chairs, I would like to request that we begin the early IANA code points = assignment process for the four Object Identifiers listed in s11? Thanks, spt From nobody Sun Jun 26 07:57: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 C93D212B05F for ; Sun, 26 Jun 2016 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 whzdvgHKS9Kk for ; Sun, 26 Jun 2016 07:57:26 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 DDD8A12B019 for ; Sun, 26 Jun 2016 07:57:25 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u5QErsIE009151; Sun, 26 Jun 2016 10:57:25 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 23tdqx34gq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Jun 2016 10:57:24 -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 u5QEvOJR014555; Sun, 26 Jun 2016 10:57:24 -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 u5QEvFMg014470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Jun 2016 10:57:20 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Sun, 26 Jun 2016 14:57:08 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.33]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0294.000; Sun, 26 Jun 2016 10:57:08 -0400 From: "DOLLY, MARTIN C" To: Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Using PASSporT with things other than STIR Thread-Index: AQHRzZP2gHOKJQAO8EmI4WJnrTEIAp/72pBA Date: Sun, 26 Jun 2016 14:57:08 +0000 Message-ID: References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> <01f41eda-4484-e891-bbae-b85eabdf8254@nostrum.com> <2fe6853c-8e83-77d1-e9fc-8848a1387ab9@nostrum.com> <66BCE048-8119-46CF-ACB6-03E5ACEDC8FB@vigilsec.com> In-Reply-To: <66BCE048-8119-46CF-ACB6-03E5ACEDC8FB@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.231.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-26_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1606260166 Archived-At: Subject: Re: [stir] Using PASSporT with things other than STIR 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, 26 Jun 2016 14:57:28 -0000 I agree that illustrating other applications, such as GETS, is needed -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, June 23, 2016 5:12 PM To: IETF STIR Mail List Subject: [stir] Using PASSporT with things other than STIR I think that the stir-passport document meets all of the needs for STIR. H= owever, I do not think that the stir-passport document has enough informati= on in it to help a developer use the PASSporT framework with other applicat= ions. I hope the addition of a bit more information can resolve this issue= . Since the stir-passport document meets all of the needs for STIR, I do not = think this should delay the start of Working Group Last Call on this docume= nt. In Section 4.3, the stir-passport document says: > Some applications may want to use the mechanism of the PASSporT=20 > digital signature that is not a superset of the base set of claims of=20 > the PASSporT token as defined in Section 3. I do not understand this sentence. Please explain it. I can imagine that other applications may want to generate PASSporT objects= that are not a strict superset of the base set of headers and claims defin= ed in Section 3. What does such an application need to specify? We get a = hint in the next couple of sentences. > Rather, a specification > may use PASSporT with its own defined set of claims. > In this case, the specification SHOULD define its own MIME media type=20 > [RFC2046] in the "Media Types" registry [IANA.MediaTypes]. I think that this means: "Such applications of PASSporT may want to operate from an entirely differe= nt set of claims. Those PASSporT-using applications may define their own s= et of claims by registering a new MIME media type in the "Media Types" regi= stry." I do not think that we can use normative language here. This section goes on to say: > The MIME > subtype SHOULD start with the string "passport-" to signify that it is=20 > related to the PASSporT token. For example, for the "foo" > application the MIME type/sub-type could be defined as "application/=20 > passport-foo". I think tho part needs to be cast as advice to the developers on future PAS= SporT-using applications. Can we offer any advice to the developer to help them decide when it is nec= essary to use an alternate set of claims? Also, can we offer any advice re= garding the properties that are needed to determine if an alternate claim s= et meets the security requirements? For example, during the development of= STIR we wanted to prevent cut-and-paste attacks. Are there any implications on interoperability for adopting a different set= of claims? Can we offer any guidance that tells the developer when it would be better = to start fresh with JOSE JWS instead of trying to adjust PASSporT? In othe= r words, where should one try to apply the PASSporT framework, and where sh= ould one not bother. Russ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Sun Jun 26 08:36: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 7A18112D0C8 for ; Sun, 26 Jun 2016 08:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xtqAY6FkGAne for ; Sun, 26 Jun 2016 08:36:07 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 038BC12D099 for ; Sun, 26 Jun 2016 08:36:06 -0700 (PDT) Received: (qmail 21824 invoked by uid 0); 26 Jun 2016 15:36:04 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 26 Jun 2016 15:36:04 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id BTby1t00B1MNPNq01Tc1P2; Sun, 26 Jun 2016 09:36:04 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=fGh7L_e3oJcA:10 a=pD_ry4oyNxEA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=NWCI9tsMW0PEbpwSCYkA:9 a=-MUmG_yslHiRaR1O:21 a=bX3hFxTsaFBoHPbU:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=obGFCI3_7AGB19sD6zJV:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=xmq4K1QY53nGl1Bwrce40YACyK8OLNVD6PqiLkbVCZA=; b=HJKuEAb2cI/IGERepT1cimLh5R UGecg/0yZPmL5bbV0OhP7tYQYFiNWejLBSQ2fDDIqqOWOcsQYBYzoMtHPPrzV4GD71a4l/GA2i+LT SuOIhadx2/Z5okg9UCiKgSn4A; Received: from [100.36.21.178] (port=54684 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bHC6I-0004Es-76; Sun, 26 Jun 2016 09:35:58 -0600 User-Agent: Microsoft-MacOutlook/f.17.0.160611 Date: Sun, 26 Jun 2016 11:35:50 -0400 From: Richard Shockey To: "DOLLY, MARTIN C" , Russ Housley , IETF STIR Mail List Message-ID: <5CD229F7-B305-4FAB-8844-03B799DABA68@shockey.us> Thread-Topic: [stir] Using PASSporT with things other than STIR References: <518D00E4-784D-499B-B989-265AFC579F08@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B3802BE3B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B3802C104@ESESSMB209.ericsson.se> <01f41eda-4484-e891-bbae-b85eabdf8254@nostrum.com> <2fe6853c-8e83-77d1-e9fc-8848a1387ab9@nostrum.com> <66BCE048-8119-46CF-ACB6-03E5ACEDC8FB@vigilsec.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.21.178 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.21.178 X-Exim-ID: 1bHC6I-0004Es-76 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.152]) [100.36.21.178]:54684 X-Source-Auth: richard+shockey.us X-Email-Count: 0 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [stir] Using PASSporT with things other than STIR 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, 26 Jun 2016 15:36:09 -0000 +1 to both Russ and Martin. Its vitally important to have clear examples in the text to guide the vendo= r community on what to expect. =20 I=E2=80=99m personally getting several questions on production and implementation= roadmap issues and some of us will have to begin briefing the NRA=E2=80=99s.=20 I have no doubt there will be a need for some form of STIR-PASSporT profile= once we can begin testing and deployment, but that is best handled in other= forums. =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 On 6/26/16, 10:57 AM, "stir on behalf of DOLLY, MARTIN C" wrote: I agree that illustrating other applications, such as GETS, is needed -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Russ Housley Sent: Thursday, June 23, 2016 5:12 PM To: IETF STIR Mail List Subject: [stir] Using PASSporT with things other than STIR I think that the stir-passport document meets all of the needs for STIR. H= owever, I do not think that the stir-passport document has enough informatio= n in it to help a developer use the PASSporT framework with other applicatio= ns. I hope the addition of a bit more information can resolve this issue. Since the stir-passport document meets all of the needs for STIR, I do not = think this should delay the start of Working Group Last Call on this documen= t. In Section 4.3, the stir-passport document says: > Some applications may want to use the mechanism of the PASSporT=20 > digital signature that is not a superset of the base set of claims of=20 > the PASSporT token as defined in Section 3. I do not understand this sentence. Please explain it. I can imagine that other applications may want to generate PASSporT objects= that are not a strict superset of the base set of headers and claims define= d in Section 3. What does such an application need to specify? We get a hi= nt in the next couple of sentences. > Rather, a specification > may use PASSporT with its own defined set of claims. > In this case, the specification SHOULD define its own MIME media type=20 > [RFC2046] in the "Media Types" registry [IANA.MediaTypes]. I think that this means: "Such applications of PASSporT may want to operate from an entirely differe= nt set of claims. Those PASSporT-using applications may define their own se= t of claims by registering a new MIME media type in the "Media Types" regist= ry." I do not think that we can use normative language here. This section goes on to say: > The MIME > subtype SHOULD start with the string "passport-" to signify that it is=20 > related to the PASSporT token. For example, for the "foo" > application the MIME type/sub-type could be defined as "application/=20 > passport-foo". I think tho part needs to be cast as advice to the developers on future PAS= SporT-using applications. Can we offer any advice to the developer to help them decide when it is nec= essary to use an alternate set of claims? Also, can we offer any advice reg= arding the properties that are needed to determine if an alternate claim set= meets the security requirements? For example, during the development of ST= IR we wanted to prevent cut-and-paste attacks. Are there any implications on interoperability for adopting a different set= of claims? Can we offer any guidance that tells the developer when it would be better = to start fresh with JOSE JWS instead of trying to adjust PASSporT? In other= words, where should one try to apply the PASSporT framework, and where shou= ld one not bother. Russ _______________________________________________ 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