From nobody Wed Apr 1 07:02:26 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF533A0FD6; Wed, 1 Apr 2020 07:02:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk CC: superuser@gmail.com, Jean Mahoney , sipcore-chairs@ietf.org, draft-ietf-sipcore-sip-token-authnz@ietf.org, mahoney@nostrum.com, sipcore@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158574974391.30773.6545584405944524603@ietfa.amsl.com> Date: Wed, 01 Apr 2020 07:02:24 -0700 Archived-At: Subject: [sipcore] Last Call: (Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 14:02:24 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Apr 14 14:07:15 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFF3A0FD9; Tue, 14 Apr 2020 14:07:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: draft-ietf-sipcore-sip-token-authnz.all@ietf.org, last-call@ietf.org, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158689842488.27716.15541584374764439587@ietfa.amsl.com> Reply-To: Derrell Piper Date: Tue, 14 Apr 2020 14:07:04 -0700 Archived-At: Subject: [sipcore] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 21:07:05 -0000 Reviewer: Derrell Piper Review result: Has Nits Reviewer: Derrell Piper Review result: Ready With Nits I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents entering the IESG. These comments are directed at the security area director(s). Document editors and WG chairs should treat these comments like any other last call comments. This document defines a third-party token authentication scheme for authentication to SIP services using "bearer" tokens from the OAuth 2.0 framework and the OpenID Connect Core 1.0 to support native application assisted (or proxy-based) token-based authentication and authorization. pp. 3, 1., nit "...enables the single-sign-on features, which allows the user to..." "...enables single sign-on, which allows the user to..." pp. 5, last sentence "previously" means "from the out-of-scope mechanism", just say that. pp. 7, 2.1.1 "(or with invalid credentials)" Why continue when a UAC presents invalid credentials? [See below.] pp. 8, 2.1.3 2.1.1 says if you get invalid credentials to go REGISTER, and here in REGISTER, it says if you get invalid credentials, go to 2.1.1. This seems recursive though I'm assuming this ultimately terminates when all the schemes are exhausted without success. Derrell From nobody Wed Apr 15 00:58:18 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6BF3A1113; Wed, 15 Apr 2020 00:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jjLvUExLbp40; Wed, 15 Apr 2020 00:58:07 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.71]) (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 8A1CD3A1111; Wed, 15 Apr 2020 00:58:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LhOwBkw3+Pysue0PdzoWdJUzL3Ei+b+OjrjF1atIXZdnZZyDeNB+NNJOjBRO725244+f5HnuajO2LHbQHr430uAcDBwMhH5FZi2qKBiTGcRNfkbaxCv3MDU3r+nq6qxezKYGqwyFl6cFPAsPqKQ/C26lddk43D0QzZQ4/DZWRoKfK/MRBwsv/rvpovx2Uoelm5ZXtygQbGaDSV17MBOdAmEsW9dyUqm5e5IxU6p1TRA17zs4LIt8pphLrVJeMBRaITEJ6qJfZI1QCal82FKgu2Ub1s1hZtjVTCfX10xgkNFSLJLxVxVKmq8w7w1RqT1vdg5wDQ8mZvDd5oaLikJWoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RO+kaMSq7ewAQHaCCC9iUxUSR7/BgnCmepeQ+IRgIRo=; b=g3/gIoL0JtsSEgzDwaf/BwcPed0NraNeht0Ewc9JMLFve18VnxdKPSxoUTC0+nfUH7bCnyA1NYb/osbMN4Y3j3gXRTelJYv/apETDh7lurEMTjzUUUAkBVqMrUdGljdwz8nLmKMsJRroGkzwfyLmLh8HLZj+9FJgvf/nuH3+Z0jVbUeoZk/EWIlNL50poqBygUfU/9jQ28XBSDnXECBWADOuu+T0Hjwv7YT1ifGN/krNIW8cjcichHmaU30I5okM+velCmMpYBT/BtswUDoC9eVS0ElBG7GBVjcfoN1ci8S8ewA5LLPCfmcC7Pb2503INGY2nf5CsqqdgqQrVFd/rQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RO+kaMSq7ewAQHaCCC9iUxUSR7/BgnCmepeQ+IRgIRo=; b=ML+lbNTTMusdNGFgd28YhmNP+IRhHVMeWmRFlzP6f6HopJ4dts6VWPh2azsDKvkzoDsfQDbe1Izdr0fphlIcUtV458AR2mQfOf7CxmKt04z9ag2oLRVeT6PiR72hyz6IM97NpJUQTJWfFqwLX9RE76GtoNLu5ZgWBM0uwiK1QgQ= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB5953.eurprd07.prod.outlook.com (2603:10a6:208:108::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.24; Wed, 15 Apr 2020 07:58:01 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 07:58:01 +0000 From: Christer Holmberg To: Derrell Piper , "secdir@ietf.org" CC: "draft-ietf-sipcore-sip-token-authnz.all@ietf.org" , "last-call@ietf.org" , "sipcore@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 Thread-Index: AQHWEqCqVuV0L/UOg0qwY4WPA18OQ6h6BDMA Date: Wed, 15 Apr 2020 07:58:01 +0000 Message-ID: <5BABF46F-6BF2-4296-B035-099BF57E0EBE@ericsson.com> References: <158689842488.27716.15541584374764439587@ietfa.amsl.com> In-Reply-To: <158689842488.27716.15541584374764439587@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec9f0c78-5fc6-4ea6-e5e2-08d7e112b84a x-ms-traffictypediagnostic: AM0PR07MB5953: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(396003)(136003)(376002)(39860400002)(2906002)(26005)(44832011)(478600001)(64756008)(2616005)(66556008)(71200400001)(6512007)(8936002)(8676002)(110136005)(81156014)(6486002)(36756003)(33656002)(86362001)(6506007)(4326008)(316002)(54906003)(66446008)(186003)(5660300002)(66946007)(66476007)(76116006); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XyOsopPx1y5CtV4aI4fvSE1eQ8DXjKwiJtwxadJNudnB7RdcjPwQpdvpBLXgLxlo+qtcUuo8gvw/Z5/7N0rLCcororYiLx+GlXBI1XE+lj9lqZLkj8jYjjgaZT9S4uRDo//BXhok7leGhDee0HGNPuGt5b14Mn7+Jd54ohzE4ozhS5iI1L1RNiSKjblisQ7p31NEnbG0gpbZ8bf0mPKDZnlHwRQjd3rxJzkqNikq/hdmkBXEQrCzGfXNayO3Upfpw7nz/TqLRRbGvL70TKp+Y671Ll6US1TX7ByyzFADCZguG6gzTjnU9M81MLN78Sjl1ng2BNnDPe7bdQmOqbmQ/3MMOltuRLQeZysObKFnRdyPwsCQ5yVZdWvlY/1szI8tEKq6lTymQE/Xzv65ZTPmwWQDE3Mr5i9+nYwmJVwg9C+cPYPot3DO58YPjGuSpEOa x-ms-exchange-antispam-messagedata: 1+6clEOTZ6FWNjhjd2jxo3/vNm4kEi6dx7HwOf7JeVNt8eXf4wyH0HE9BNZhNjDUrjZwm6m2RFz3UonnsUJiQI7L93q6KfDZv5tlI5VwYv/SEc3jcxhQ+tBG+NYj/V6Q+Qt5oI4tC5B4QwUBKRm8ug== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec9f0c78-5fc6-4ea6-e5e2-08d7e112b84a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 07:58:01.2882 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: puKI799SAUQnDNRSwaSP9iQfn+c/zRQIWr5HaGK68IoeIAGQnTNSVMGiylwN5q9fUmLpja1vC0i+TT8NLEJinUHhG1CSD8frImU6ZGSAQnA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5953 Archived-At: Subject: Re: [sipcore] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 07:58:08 -0000 SGkgRGVycmVsbCwNCg0KVGhhbmsgWW91IGZvciB0aGUgcmV2aWV3ISBQbGVhc2Ugc2VlIGlubGlu ZS4NCiAgICANCj4gICAgcHAuIDMsIDEuLCBuaXQNCj4gICAgDQo+ICAgICIuLi5lbmFibGVzIHRo ZSBzaW5nbGUtc2lnbi1vbiBmZWF0dXJlcywgd2hpY2ggYWxsb3dzIHRoZSB1c2VyIHRvLi4uIg0K PiAgICANCj4gICAgIi4uLmVuYWJsZXMgc2luZ2xlIHNpZ24tb24sIHdoaWNoIGFsbG93cyB0aGUg dXNlciB0by4uLiINCiAgDQpXZSBjYW4gZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQogIA0KPiAg ICBwcC4gNSwgbGFzdCBzZW50ZW5jZQ0KPiAgICANCj4gICAgInByZXZpb3VzbHkiIG1lYW5zICJm cm9tIHRoZSBvdXQtb2Ytc2NvcGUgbWVjaGFuaXNtIiwganVzdCBzYXkgdGhhdC4NCiAgDQpJIHRo aW5rIHRoYXQgc291bmRzIGEgbGl0dGxlICJjbHVtc3kiIHRvIHJlcGVhdCBpdC4gV291bGQgaXQg d29yayBpZiB3ZSBzYWlkICJvYnRhaW5lZCBpbiB0aGUgc3RlcCBhYm92ZSIsIG9yIHNvbWV0aGlu ZyBsaWtlIHRoYXQ/DQoNCi0tLQ0KICANCj4gICAgcHAuIDcsIDIuMS4xDQo+ICAgIA0KPiAgICAi KG9yIHdpdGggaW52YWxpZCBjcmVkZW50aWFscykiDQo+ICAgIA0KPiAgICBXaHkgY29udGludWUg d2hlbiBhIFVBQyBwcmVzZW50cyBpbnZhbGlkIGNyZWRlbnRpYWxzPyAgW1NlZSBiZWxvdy5dDQo+ DQo+ICANCj4gICAgcHAuIDgsIDIuMS4zDQo+ICAgIA0KPiAgICAyLjEuMSBzYXlzIGlmIHlvdSBn ZXQgaW52YWxpZCBjcmVkZW50aWFscyB0byBnbyBSRUdJU1RFUiwgYW5kIGhlcmUgaW4NCj4gICAg UkVHSVNURVIsIGl0IHNheXMgaWYgeW91IGdldCBpbnZhbGlkIGNyZWRlbnRpYWxzLCBnbyB0byAy LjEuMS4gIFRoaXMNCj4gICAgc2VlbXMgcmVjdXJzaXZlIHRob3VnaCBJJ20gYXNzdW1pbmcgdGhp cyB1bHRpbWF0ZWx5IHRlcm1pbmF0ZXMgd2hlbiBhbGwNCj4gICAgdGhlIHNjaGVtZXMgYXJlIGV4 aGF1c3RlZCB3aXRob3V0IHN1Y2Nlc3MuDQogIA0KU2VjdGlvbiAyLjEuMSBkZWZpbmVzIGdlbmVy aWMgcHJvY2VkdXJlcywgd2hpbGUgc2VjdGlvbiAyLjEuMyBkZWZpbmVzIHRoZSBwcm9jZWR1cmVz IHNwZWNpZmljIGZvciB0aGUgUkVHSVNURVIgcmVxdWVzdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Wed Apr 15 11:22:58 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021A93A0F12; Wed, 15 Apr 2020 11:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 rWQAUVE8AM1K; Wed, 15 Apr 2020 11:21:42 -0700 (PDT) Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [IPv6:2604:4ec0:0:2::d]) by ietfa.amsl.com (Postfix) with SMTP id 628413A0F0F; Wed, 15 Apr 2020 11:21:42 -0700 (PDT) Received: from [IPv6:2603:3024:1767:6000:549:1025:182e:ed50] ([2603:3024:1767:6000:549:1025:182e:ed50]) by Mail.Yoyodyne.COM via Internet for (and others); Wed, 15 Apr 2020 11:21:35 PDT From: Derrell Piper Message-Id: <43AFD2E4-0486-4CEB-BBBC-8C7C72B84E09@electric-loft.org> Content-Type: multipart/signed; boundary="Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Apr 2020 11:21:34 -0700 In-Reply-To: <5BABF46F-6BF2-4296-B035-099BF57E0EBE@ericsson.com> Cc: "secdir@ietf.org" , "draft-ietf-sipcore-sip-token-authnz.all@ietf.org" , "last-call@ietf.org" , "sipcore@ietf.org" To: Christer Holmberg References: <158689842488.27716.15541584374764439587@ietfa.amsl.com> <5BABF46F-6BF2-4296-B035-099BF57E0EBE@ericsson.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 18:21:44 -0000 --Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 15, 2020, at 12:58 AM, Christer Holmberg = wrote: >=20 > Hi Derrell, >=20 > Thank You for the review! Please see inline. >=20 >> pp. 3, 1., nit >>=20 >> "...enables the single-sign-on features, which allows the user = to..." >>=20 >> "...enables single sign-on, which allows the user to..." >=20 > We can fix as suggested. >=20 > --- >=20 >> pp. 5, last sentence >>=20 >> "previously" means "from the out-of-scope mechanism", just say = that. >=20 > I think that sounds a little "clumsy" to repeat it. Would it work if = we said "obtained in the step above", or something like that? =E2=80=9Cthe step above=E2=80=9D works too. > --- >=20 >> pp. 7, 2.1.1 >>=20 >> "(or with invalid credentials)" >>=20 >> Why continue when a UAC presents invalid credentials? [See below.] >>=20 >>=20 >> pp. 8, 2.1.3 >>=20 >> 2.1.1 says if you get invalid credentials to go REGISTER, and here = in >> REGISTER, it says if you get invalid credentials, go to 2.1.1. = This >> seems recursive though I'm assuming this ultimately terminates when = all >> the schemes are exhausted without success. >=20 > Section 2.1.1 defines generic procedures, while section 2.1.3 defines = the procedures specific for the REGISTER request. >=20 > Regards, >=20 > Christer Okay. Derrell= --Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCqUw ggUuMIIEFqADAgECAhBuYWaYcrycMAAAAABR05MeMA0GCSqGSIb3DQEBCwUAMIG+MQswCQYDVQQG EwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5l dC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMDkgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRo b3JpemVkIHVzZSBvbmx5MTIwMAYDVQQDEylFbnRydXN0IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgLSBHMjAeFw0xOTA0MTYxNTM1NTJaFw0zMDExMTYxNjA1NTJaMIG3MQswCQYDVQQGEwJV UzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9s ZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRob3Jp emVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENsYXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2DmtXj1lwZOXaWXvERtOSP7QMI+Ts82R Qc2etqDeYwctILXqkwsQrZB6YjKa1BQnBmLHxn3cWxKJtqCT7ZP95YVxc0MXjP5ifP9xD/f59jlY d/7SPIxQUjX1+vsV6aY4tTzPiaOu3VHVGbD70si3WdUvJh367CMOU2o0mXi9MwW1fBwMHK99NKgp wpr4QhyT2aZ+os/hGGQLUYmse5Dfshq79eelXyFC1FIrvM0AhAk+T3NKFPmckKwyk30jkFMElSne TR7ganOTMeT1OEqVomyJsMzJugVaMzuSt4vhJFSt/XXRMPcPT9PEx39X78NNkWeTTkL1Ghq9O2We AStQNwIDAQABo4IBKzCCAScwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUH MAGGF2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0MDAGA1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmwu ZW50cnVzdC5uZXQvZzJjYS5jcmwwHQYDVR0OBBYEFOJJuewl3rcM3uVQGFtIzAyOFfKmMB8GA1Ud IwQYMBaAFGpyJnrQHu995ztpUdRsjZ+QEmarMA0GCSqGSIb3DQEBCwUAA4IBAQBVuaCwN5r85cQp hcyUe+RXqaYyUmVEqTWG/a98UJdX44vkCgzdD/+Cn4o6wbRun7Ak0kdCR3qfFA17/5QOQ8DLOyR5 X37Ytxby24lTLKKehNlc3japM8XQQFaJqLMq3MXXFYhWlFk4UHwXYLcDR7XyA3hYuaL6HU92h+uG SDEcBeV+nXrk4FRgEfGvilHfd+8ozBjSVKOF6L1+fuJNkaFWYvJ4Qi64nlmXDsk6K9f6P4FT8hXA 2Cn6tQGAqCz8t6bn7ljtaxCMJ10LE+omiZDfWXv4PrkvgWnNqZEzQw+E09HwEc7DjV9/fGqUhLR2 AKkjYE/78rlymYPvOf7bmpSYMIIFbzCCBFegAwIBAgIRAI534qzDm7xdAAAAAFVjsOwwDQYJKoZI hvcNAQELBQAwgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYwHhcNMTkwODE1MTgyMDAyWhcNMjAwODE0MTg1MDAwWjCB nzEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQLEy5FbnRydXN0IENsYXNz IDEgSWRlbnRpdHkgQ2VydGlmaWNhdGlvbiBTZXJ2aWNlMR4wHAYDVQQDDBVkZHBAZWxlY3RyaWMt bG9mdC5vcmcxJDAiBgkqhkiG9w0BCQEWFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANBA7jjvZSATUxJEdJNmz6N1fnajqmdDkVHOxA0yllROaJPo MNM03XQFa24aJ7fJ9wQhq9NXHq2w5xO2KK2PBJW8vxw38wuPdE14bHzuxtGKWnDhJ/SIEWtA7pB0 fFMua7OAtgTMvekxx0st8qw6yKufNtdv7Q2U3OWUYCWNdvZudJxHXkqHdCj6WTBE24sGSL/UrGLj H98ebxfANbX8Wfp/Sg34OtbFe305CyXlwNWplILN4UKg+r4EWRKgJ3ZLsxj2WH/tWdn7KU6eK315 F/PjH2NscqzNTSwZbHcwynAYd6239FQiombVk4PGnHRJq1NOi4n5M1lvl8mnrsQLYNkCAwEAAaOC AYowggGGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQgYD VR0gBDswOTA3BgtghkgBhvpsCgEEATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1c3Qu bmV0L3JwYTAJBgNVHRMEAjAAMGkGCCsGAQUFBwEBBF0wWzAjBggrBgEFBQcwAYYXaHR0cDovL29j c3AuZW50cnVzdC5uZXQwNAYIKwYBBQUHMAKGKGh0dHA6Ly9haWEuZW50cnVzdC5uZXQvY2xhc3Mx LXNoYTI1Ni5jZXIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5lbnRydXN0Lm5ldC9jbGFz czEtc2hhMjU2LmNybDAgBgNVHREEGTAXgRVkZHBAZWxlY3RyaWMtbG9mdC5vcmcwHwYDVR0jBBgw FoAU4km57CXetwze5VAYW0jMDI4V8qYwHQYDVR0OBBYEFA3/q3e5a+oKODwIaREHDhpaK0YRMA0G CSqGSIb3DQEBCwUAA4IBAQCPmXPwIGtfjvyqW7WFgrG/mBV1KWgorjrzgDYZmZfI466I6zEurSnI 0pLAbkXrhuTfEYkm4lertjRBSkd9W3iRaBUUfOntAdANX8/3onjQI/WEvszc6tPUTfS/CixsR69M mE0/o5UmYzSBcHzF2ff01ceD8IrsPhyzf87xJvfWonFyGB3gt8kN9K5S1eCAj6WdgC1ZrFMXp8fR ezAA2BHiJCbj4T2e3Zg4xDoTH4r4Y9u+czDikS5InJL+Z0iqsNR50d7YgAEAeU3iYQx5GvO7Dqou vM9JajPccnpqDClNXP1sqIOvAE6GHSopTy6mEUB6phLVeWW342rsUvtgUntVMYIEKjCCBCYCAQEw gc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUg d3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJ bmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBD bGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCWCGSAFlAwQCAQUAoIICLTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MTUxODIxMzRaMC8G CSqGSIb3DQEJBDEiBCCa9evgrGS04kjztTooMYm+NCR34MRSOYwE3FStmixU/TCB3gYJKwYBBAGC NxAEMYHQMIHNMIG3MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UE CxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50 cnVzdCwgSW5jLiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENs YXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2AhEAjnfirMObvF0AAAAAVWOw7DCB4AYLKoZIhvcNAQkQ AgsxgdCggc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCSqGSIb3DQEBAQUA BIIBABDifBb166R3RTl3EYj+vTPur0yWdBJZ9okp5CRslesTTdQA+tglPTMoNbOCRznW3xWztpFn Va+jcf3lQd33bUPrqS88u1Kx+80/L55sd23k8YB2/WXf52cz99uX6etOxVlhQWbeSTnYbyIKHLPp ZYwaBHE8SGq3V4UUcX5VZ5A6J4ZGuIiQ4UhgHtWf3banODt0mv8+hMcBt0D3Y5HDuydL+dcvAPX9 8gUIyglzNpflcM6rvUevyQ0/GTvuflkq071C9AfbwtS3o9QOdtjv6fjWzdDFVHL8UjZXoCBvyxqc qEEILtJNKZjlVFasl9Xrl4/j10tfJ7XOHoZI/lE7jNEAAAAAAAA= --Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE-- From nobody Wed Apr 15 15:14:58 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BDD3A0AD5; Wed, 15 Apr 2020 15:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <158698889341.28250.13653200684591801020@ietfa.amsl.com> Date: Wed, 15 Apr 2020 15:14:53 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-13.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 22:14:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-13.txt Pages : 14 Date : 2020-04-15 Abstract: This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-13 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 15 15:19:01 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0103A0AD5 for ; Wed, 15 Apr 2020 15:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6IMwurt1ZeH for ; Wed, 15 Apr 2020 15:18:57 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 9E4703A0AD8 for ; Wed, 15 Apr 2020 15:18:57 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id f19so18943886iog.5 for ; Wed, 15 Apr 2020 15:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6qd0WSWxnIbxym6ARu5L4QGNtck955Ntz2pD38gytLg=; b=Ptww1vDdDHNiadRarE+WWi7wmDR8QX8iARQiENHKS66r54fBYV98qa0ptUZPWkCBRY EZrF0nASSIQCvhXKA5znpSr0psOTlDbyzF5fOXObyP/MFgK+glPfTc3tVuEnkm3msL6y t7jlTpFpyUT6uNr7RP1D54yoEwSTXCcOdAFCVvSSGR7YitQ2hfBOvhfZCVGomm8NuRIZ 2bsURtr2hCBV6cGQOYKQgHfCbkM6IiXMZwPTlmddGkg1+QgNh0ps81Tf3a1MKH9Ew9vt oja8EGRsw7Q44BEFREbQY7OK3qu/aBFUjkNDmZodjzkv3rRJYmpn4hphMVg0JZLWs+d5 0zZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6qd0WSWxnIbxym6ARu5L4QGNtck955Ntz2pD38gytLg=; b=ZT1aNaq8XMyUaZgtTeV2iWaW0MDVw2VPaFw7A2waotO+Hctf7LZja1eFsP+HZud/NU 5KKb/Q4E/4YYTHGyCr+fE5x8edGFm6zeeCmOtmJLx0Kb5ru7MwkOSGtRGbaqCOYUd10x 6Bp2bTw6SbmrZzBygeUKzFqzgTVlQlAGk2cZDcznu7e1Ru393WGcWG+/fqqYR1S/dkxr PCJxXOwS/Yl7JBdTrcvLS/d/2VqajHX/2/0xCOcljFkKKB7g3iJjK+gBrLUgw70beAs6 JbReL+VsTLCwGBetQb81cFemSi6/nSEheRjIG7Ep1LCW9fhA1EEl3vpnH8QuEW1v+ebj acqw== X-Gm-Message-State: AGi0PuZDHaECguXtiJ1281QxJf6VGzbr1QPntczzwfhfKJ0S7QERoc6e 0YDKiLvociFMrgePuuKjRQCGG4rWVSjjfBlqojXW0Nwg X-Google-Smtp-Source: APiQypJlUM5fC5FdGEwQE5zJ/8oKmONx05Yas+VntUNKMTSJOI8ec4dSp95pnZA+l2zUnflFkQO2UXeHm8yhYpPkf2A= X-Received: by 2002:a5d:8946:: with SMTP id b6mr28089987iot.51.1586989136468; Wed, 15 Apr 2020 15:18:56 -0700 (PDT) MIME-Version: 1.0 References: <158698889341.28250.13653200684591801020@ietfa.amsl.com> In-Reply-To: <158698889341.28250.13653200684591801020@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Wed, 15 Apr 2020 18:18:45 -0400 Message-ID: To: SIPCORE , superuser@gmail.com Content-Type: multipart/alternative; boundary="000000000000bde03905a35bb3b4" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-13.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 22:18:59 -0000 --000000000000bde03905a35bb3b4 Content-Type: text/plain; charset="UTF-8" All, We have addressed the latest comments from the GENART and SECDIR reviews with this latest version of the draft. Please, take a look and let us know if we missed anything. Regards, Rifaat On Wed, Apr 15, 2020 at 6:15 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG of > the IETF. > > Title : Third-Party Token-based Authentication and > Authorization for Session Initiation Protocol (SIP) > Authors : Rifaat Shekh-Yusef > Christer Holmberg > Victor Pascual > Filename : draft-ietf-sipcore-sip-token-authnz-13.txt > Pages : 14 > Date : 2020-04-15 > > Abstract: > This document defines the "Bearer" authentication scheme for the > Session Initiation Protocol (SIP), and a mechanism by which user > authentication and SIP registration authorization is delegated to a > third party, using the OAuth 2.0 framework and OpenID Connect Core > 1.0. This document updates RFC 3261 to provide guidance on how a SIP > User Agent Client (UAC) responds to a SIP 401/407 response that > contains multiple WWW-Authenticate/Proxy-Authenticate header fields. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-13 > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-13 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000bde03905a35bb3b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have addressed the latest comme= nts from the GENART and SECDIR reviews with this latest version of the draf= t.
Please, take a look and let us know if we missed=C2=A0anything= .

Regards,
=C2=A0Rifaat



On Wed, Apr 15, 2020 at 6:15 PM <internet-drafts@ietf= .org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core WG of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Third-Party Token-based Authentication and Authorization for Session Initi= ation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rifa= at Shekh-Yusef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christer Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Victor Pascual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sipcore-sip-token-authnz-13.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-04-15

Abstract:
=C2=A0 =C2=A0This document defines the "Bearer" authentication sc= heme for the
=C2=A0 =C2=A0Session Initiation Protocol (SIP), and a mechanism by which us= er
=C2=A0 =C2=A0authentication and SIP registration authorization is delegated= to a
=C2=A0 =C2=A0third party, using the OAuth 2.0 framework and OpenID Connect = Core
=C2=A0 =C2=A01.0.=C2=A0 This document updates RFC 3261 to provide guidance = on how a SIP
=C2=A0 =C2=A0User Agent Client (UAC) responds to a SIP 401/407 response tha= t
=C2=A0 =C2=A0contains multiple WWW-Authenticate/Proxy-Authenticate header f= ields.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-sipcore-sip-token-authnz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-sipcore-sip-token-authnz-13
https://datatracker.ietf= .org/doc/html/draft-ietf-sipcore-sip-token-authnz-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-sipcore-sip-token-authnz-13


Please note that it may take a couple of minutes from the time of submissio= n
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/


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000bde03905a35bb3b4-- From nobody Mon Apr 20 22:49:52 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B173A0A2E; Mon, 20 Apr 2020 22:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158744819049.23997.5059457122698360691@ietfa.amsl.com> Date: Mon, 20 Apr 2020 22:49:50 -0700 Archived-At: Subject: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 05:49:51 -0000 Barry Leiba has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. Enabling Open-ID and OAUTH with SIP is quite useful. This document specifically calls out single sign-on as a reason to use this mechanism, and SSO has a host of serious security and privacy issues. As those issues are not discussed in the referenced documents, I think they need to be raised here. Recommended usage/configuration to avoid or mitigate the issues would be ideal, but at the very least I think they need to be documented, as it’s clear that implementors are not aware of them or don’t think they’re important enough to worry about. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 1.1 — Please copy the BCP 14 boilerplate exactly from RFC 8174. — Section 1.3 — Refresh Tokens usualy are represented in a reference format Typo: “usually”. — Section 3 — The methods used and the access provided by the token is based on local policy “are based”, to match the plural subject. Examples of such other mechanisms are introspection [RFC7662], user profile lookups, etc. “Examples” and “etc.” are mutually redundant. I would remive the latter and replace the comma before “user profile lookups” with “and”. — Section 6 — This can’t be empty. It should say that there are no IANA actions needed for this document. From nobody Tue Apr 21 03:03:57 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA60A3A0B3F; Tue, 21 Apr 2020 03:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 SzO_OvALg0ux; Tue, 21 Apr 2020 03:01:44 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80075.outbound.protection.outlook.com [40.107.8.75]) (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 2F32A3A0B3C; Tue, 21 Apr 2020 03:01:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bSg5YG0VMrlFqyKsm3T0H4CP/WtanzGAIHyIBkJO40RmUihaZhfaE57XF3TBnuqLOEWwJJWtlr8z/mkaCXId+HdST0h3xngOPYxvaLTD4G50BYZwnFVyEMQPtJ9nsWoN9Ckjmmdlqw9nxmDCMmW00ronmnRUhqEX2HlWKVUna+DeS/jbzbNlgDMHAxCEXbHjmYRxmnHLvu5pToScZL5IKIVPqfAmij7T3PUDAPRyaegOlCwab7FDuWFUmnWOMNHhhwsiBSg41NlzSqhyJU6fG/+ZWUM3AYTDz9clvMnHP138kWuyPc1LdnlBWIlIyUDAxT/lwjyoVRuqwHbHR9SrrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b3jxQQTy9O2+SBVZCwEg/oGVIGZIZ1nKTjT19est6Xs=; b=QPbnMgMuThR6Vw3HYaanmfQKTdl931w4LGgGhEEh+6CI56fJPx3v3SXm2sEm18C/Wa5HwA6jgigCWwA779gzvBdC65H+izbJErkOsCfme0zHUMuiM0nYov/2GFJxg1p0FQpi1B1pgpjqG3xd8wXQUPHKlY9RdPJ0kcnooD35uR1ZD2954AZQIKy3ondIsdpFyeSEGyWZCd+XeKJ4qbrCWMTo05cxjMvwz/xUKITMhrIo2H9NEOvTkW+mPs7coXiB4BGZOwv/qoNmV4rmMO6M+K4ummHuXEEqhp8Fpx0pU//uHOca3G10s14FdvYPXThRXF2i4lLfy83fRHtEI6rauw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b3jxQQTy9O2+SBVZCwEg/oGVIGZIZ1nKTjT19est6Xs=; b=tTaRE/bVPQDpkB66nE925adhcB6X8tm0EqVd0EqMIy1NvPQOh41kE5vhMTvtYKDNqlPeMqTyvBMBaLOGAt+HVHarSi7nKAN5C2xhRMHP9a0TvgD3wkvYE8mQXTwRjfrs5N8OYeMBf5eyhTBX0siHA/7UThT/mtVuB+p4oHX7PLQ= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB3890.eurprd07.prod.outlook.com (2603:10a6:208:4e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Tue, 21 Apr 2020 10:01:41 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.012; Tue, 21 Apr 2020 10:01:41 +0000 From: Christer Holmberg To: Barry Leiba , The IESG CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - Barry's COMMENT Thread-Index: AQHWF8PbhKmFX3XPYkmfnuXBhPEWhQ== Date: Tue, 21 Apr 2020 10:01:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a3ddb84-4821-4268-81a9-08d7e5dafda8 x-ms-traffictypediagnostic: AM0PR07MB3890: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 038002787A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(376002)(366004)(136003)(6506007)(26005)(81156014)(71200400001)(966005)(2616005)(36756003)(8676002)(8936002)(316002)(4326008)(5660300002)(44832011)(76116006)(91956017)(6486002)(66446008)(64756008)(66556008)(66476007)(66946007)(6512007)(2906002)(478600001)(186003)(86362001)(54906003)(110136005)(33656002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bF4ORr4TtOU2IAOmEK/2+M7d5PvA4Bdl+ZQ7FUEzDNH2s6iaHY0IXZrEdc0DFtK5MPuSfBr6OSDBeLNaukNPofUqFXdjxmyteVuWZFGoVOIR8MVUEK5T7vlKC2/JMiA6cbTMZ8oLPKyxxnKPOtbrtMw7iH0dnIwmxazu990PjTCKlEQ7aV9qMhloTny5QZ5j2dtSaNOBff3ag1j7eDj0Ybs7tbgSig/nnWauh9vmy7BXh8F4tLcMGVj1JstWI0wBJO/8visMVTNd0YjiWfm4lpVqGxGYkbOKHRMlNC+F8zgPGazuK0/y6AJHVXtN0iFIqJ6Jisw8vsFNc9scDhwRMw7dfq+vKipYRCVWiN8B+77WZNSNeTFb8AdlmkChb1C4+vez1QQrn8nzUzDqrSItsWsjOJX3KrYHah4oNz0hiQCs+Lked+pG57Bx43UDJingUQFYaNaJzVHgkG1qhmpjOwKKG0KLlRaGsbMT85+tntKWxn184BRk+OD7bjGWtGpwnHQzeDtE+UzNaErEnAjBKQ== x-ms-exchange-antispam-messagedata: 3WjssZvyEcJ5O2Nr0UsVD/y59kAaQOH9qf8hrmlQ9AoY9FwE+EyhTTXDbbTwiGoc0K2doOIjs47t+d4VIv+lYISLy86BdxWn622PznkuXekGlV9OecXiDX8xUOGkddqlnaNysFF5bjenK3pVVZPkdA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <06B5E03C274B814AA35FB0CD0EB7FC92@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a3ddb84-4821-4268-81a9-08d7e5dafda8 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 10:01:41.7134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vyZDlB+mYN2ZYX3268Q8NomMPOzqYqEydpXhThOIo4jXdpNgBrCW7Dlad/nvgTJJheHKElpTBio+msXcbSj3VvHkVBmg/f2W4HJlpB2Jn2c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3890 Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - Barry's COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 10:01:53 -0000 SGkgQmFycnksDQoNClRoYW5rIFlvdSBmb3IgdGhlIHJldmlldyENCg0KSW4gdGhpcyByZXBseSBJ IHdpbGwgYWRkcmVzcyB5b3VyIENPTU1FTlQuIFRoZSBESVNDVVNTIHdpbGwgYmUgYWRkcmVzc2Vk IGluIGEgc2VwYXJhdGUgcmVwbHkuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgDQo+ICAgIOKAlCBTZWN0aW9uIDEuMSDigJQNCj4gICAgUGxlYXNlIGNvcHkg dGhlIEJDUCAxNCBib2lsZXJwbGF0ZSBleGFjdGx5IGZyb20gUkZDIDgxNzQuDQogIA0KV2lsbCBk by4NCg0KLS0tDQogIA0KPiAgICDigJQgU2VjdGlvbiAxLjMg4oCUDQo+ICAgIA0KPiAgICAgICBS ZWZyZXNoIFRva2VucyB1c3VhbHkgYXJlIHJlcHJlc2VudGVkIGluIGEgcmVmZXJlbmNlIGZvcm1h dA0KPiAgICANCj4gICAgVHlwbzog4oCcdXN1YWxseeKAnS4NCiAgDQpXaWxsIGZpeC4NCg0KLS0t DQoNCj4gICAg4oCUIFNlY3Rpb24gMyDigJQNCj4gICAgDQo+ICAgICAgIFRoZSBtZXRob2RzIHVz ZWQgYW5kIHRoZSBhY2Nlc3MNCj4gICAgICAgcHJvdmlkZWQgYnkgdGhlIHRva2VuIGlzIGJhc2Vk IG9uIGxvY2FsIHBvbGljeQ0KPiAgICANCj4gICAg4oCcYXJlIGJhc2Vk4oCdLCB0byBtYXRjaCB0 aGUgcGx1cmFsIHN1YmplY3QuDQogIA0KV2lsbCBmaXguDQoNCi0tLQ0KDQo+ICAgICAgIEV4YW1w bGVzIG9mIHN1Y2ggb3RoZXINCj4gICAgICAgbWVjaGFuaXNtcyBhcmUgaW50cm9zcGVjdGlvbiBb UkZDNzY2Ml0sIHVzZXIgcHJvZmlsZSBsb29rdXBzLCBldGMuDQo+ICAgIA0KPiAgICDigJxFeGFt cGxlc+KAnSBhbmQg4oCcZXRjLuKAnSBhcmUgbXV0dWFsbHkgcmVkdW5kYW50LiAgSSB3b3VsZCBy ZW1pdmUgdGhlIGxhdHRlciBhbmQNCj4gICAgcmVwbGFjZSB0aGUgY29tbWEgYmVmb3JlIOKAnHVz ZXIgcHJvZmlsZSBsb29rdXBz4oCdIHdpdGgg4oCcYW5k4oCdLg0KICANCkkgc3VnZ2VzdDoNCg0K IkV4YW1wbGVzIG9mIHN1Y2ggb3RoZXIgbWVjaGFuaXNtcyBhcmUgaW50cm9zcGVjdGlvbiBbUkZD NzY2Ml0gYW5kIHVzZXIgcHJvZmlsZSBsb29rdXBzLiINCiAgDQotLS0NCg0KPiAgICDigJQgU2Vj dGlvbiA2IOKAlA0KPiAgICBUaGlzIGNhbuKAmXQgYmUgZW1wdHkuICBJdCBzaG91bGQgc2F5IHRo YXQgdGhlcmUgYXJlIG5vIElBTkEgYWN0aW9ucyBuZWVkZWQgZm9yDQo+ICAgIHRoaXMgZG9jdW1l bnQuDQogIA0KV2UgZGlzY3Vzc2VkIHRoaXMgd2l0aCBJQU5BLCBhbmQgdGhlIGlkZWEgaXMgdG8g cmVtb3ZlIHRoZSB3aG9sZSBzZWN0aW9uICh0aGV5IHNhaWQgaXQgaXMgdXAgdG8gdXMgdG8gZWl0 aGVyIHJlbW92ZSBpdCwgb3IgdG8ga2VlcCBpdCBhbmQgYWRkIHRleHQgc2F5aW5nIHRoZXJlIGFy ZSBubyBJQU5BIHJlcXVlc3RzKS4NCg0KLS0tDQoNCkJlbG93IGlzIGEgbGluayB0byBhIEdpdEh1 YiBwdWxsIHJlcXVlc3Qgd2l0aCB0aGUgY2hhbmdlcyBiYXNlZCBvbiB0aGUgQ09NTUVOVCBpc3N1 ZXM6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9yaWZhYXQtaWV0Zi9kcmFmdC1pZXRmLXNpcGNvcmUt c2lwLXRva2VuLWF1dGhuei9wdWxsLzYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KICANCiAg ICANCiAgICANCiAgICANCg0K From nobody Tue Apr 21 03:54:39 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7630D3A081E; Tue, 21 Apr 2020 03:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iezaezycVUUp; Tue, 21 Apr 2020 03:54:34 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 C526F3A0816; Tue, 21 Apr 2020 03:54:33 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id f3so14570213ioj.1; Tue, 21 Apr 2020 03:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oan5Ot4CKvOXJPHE5WeV9mY1beTEMOKDVegVVlIS9L0=; b=efkl68SCZsT3G2Ke9UIS5tRVl4L1GLrG4BPjbmgCgxHFEXU58nGms6Q94I6p2/RFak YgVxHvndFXdqpxXysSCPPpvSxMYJVroTwDEgdTudjTx9FUpGpsREHJxyChQWUdSHPFXk vvRHkgxJ+b4i8WJogn+heuvknCgWA6JSOCaM0tF3zX9drv6ojsL4ZYVjHYoWXtmRuH2e IH7uOi3YmyCh0qIHjrQgmOKr3aTer1Kq6Xg5rWl6iYs4RnCcNnSVRUeveEzjqqfL4ww7 lOycVnDDBT9p5c8N4sk5EDTjWaGWOnYgJ8KhW81aEGhNbW2RR+6TzH7qClko3eXTAXUG Fdfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oan5Ot4CKvOXJPHE5WeV9mY1beTEMOKDVegVVlIS9L0=; b=E9ll2A5l7DED9eveT2uV3OHNGI8WmjxmqrmBsK6r6CQQD2LAvPfv29uNWWkUhovsJB 5vszL5rDdvkubE9s5duEIXJVOwqIF3rm7yRZZ+jMcbroaKXrdc2CWl54NZHFelWJc3RU xOzVo+tgb+DUisUP46e3TvvVn32T61WsjEceynV9lAlT4d7erlO5l9qXG5LjNMyMaGLZ IVOIA8vglAl4VRY0skzWY5lzlSOritjWi8jqIyxU7C6j09lAhBA0X/1YPuXzv1u9hc0Z AjCFOdDGlHTmvqdTmQeDKLW2MqiLyVykIuVSxBSn/S3eDH7uM7wO+BlYQlaKosQFHquh S7Vg== X-Gm-Message-State: AGi0PubqHsNam/T+qtbfqMpzL1LCQ756cjcfM1k8XgwTod9VtYLkX8Qe /Tbk7Mp6kNlqQNvhvY81CQsCfEEZZaMl0uWT3x0= X-Google-Smtp-Source: APiQypKrjHR6f1q3X60BuEA+y55TdtOraSoqboZS/BcEantpaVavBNrkPvaP83KHdtXUnkKghJvWzqt4EGbjzYXgqAc= X-Received: by 2002:a02:cb8a:: with SMTP id u10mr19827399jap.73.1587466472893; Tue, 21 Apr 2020 03:54:32 -0700 (PDT) MIME-Version: 1.0 References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: <158744819049.23997.5059457122698360691@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Tue, 21 Apr 2020 06:54:22 -0400 Message-ID: To: Barry Leiba Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="00000000000035bac105a3cad7b8" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 10:54:38 -0000 --00000000000035bac105a3cad7b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Barry, Thanks for your the review. Regarding the DISCUSS, how about adding the following text to the security considerations section: Single Sing-On enables the user to use one set of credentials to authenticate once and gain access to multiple SIP and non-SIP services using access token(s). Because of that, it is critical to make sure that extra security measures b= e taken to guards these credentials. Examples of such measures include long passphrase instead of a password, enabling multi-factor factor authentication, and the use of embedded browser when possible, as defined in RFC8252. Although this is out of scope for this document, it is important to carefully consider the claims provided in the tokens used to access these services to make sure of the privacy of the user accessing these services. As mentioned above, this document calls for encrypting JWT representing the access token. Regards, Rifaat On Tue, Apr 21, 2020 at 1:49 AM Barry Leiba via Datatracker < noreply@ietf.org> wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-sipcore-sip-token-authnz-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this document. Enabling Open-ID and OAUTH with SIP is quite > useful. > > This document specifically calls out single sign-on as a reason to use th= is > mechanism, and SSO has a host of serious security and privacy issues. As > those > issues are not discussed in the referenced documents, I think they need t= o > be > raised here. Recommended usage/configuration to avoid or mitigate the > issues > would be ideal, but at the very least I think they need to be documented, > as > it=E2=80=99s clear that implementors are not aware of them or don=E2=80= =99t think they=E2=80=99re > important enough to worry about. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > =E2=80=94 Section 1.1 =E2=80=94 > Please copy the BCP 14 boilerplate exactly from RFC 8174. > > =E2=80=94 Section 1.3 =E2=80=94 > > Refresh Tokens usualy are represented in a reference format > > Typo: =E2=80=9Cusually=E2=80=9D. > > =E2=80=94 Section 3 =E2=80=94 > > The methods used and the access > provided by the token is based on local policy > > =E2=80=9Care based=E2=80=9D, to match the plural subject. > > Examples of such other > mechanisms are introspection [RFC7662], user profile lookups, etc. > > =E2=80=9CExamples=E2=80=9D and =E2=80=9Cetc.=E2=80=9D are mutually redund= ant. I would remive the latter > and > replace the comma before =E2=80=9Cuser profile lookups=E2=80=9D with =E2= =80=9Cand=E2=80=9D. > > =E2=80=94 Section 6 =E2=80=94 > This can=E2=80=99t be empty. It should say that there are no IANA action= s needed > for > this document. > > > > --00000000000035bac105a3cad7b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Barry,

Thanks for your the revi= ew.
Regarding the DISCUSS, how about adding the following text to= the security considerations section:

Single Sing-On ena= bles the user to use one set of credentials to authenticate
once and gain access to multiple SIP and non-SIP services using acces= s token(s).
Because of that, it is critical to make su= re that extra security measures be
taken to guards the= se credentials.

Examples of such measur= es include long passphrase instead of a password, enabling
=
multi-factor factor authentication, and the use of embedded browser wh= en possible,
as defined in RFC8252.

Although this is out of scope for this documen= t, it is important to carefully
consider the claims pr= ovided in the tokens used to access these services to make
=
sure of the privacy of the user accessing these services. As mentioned= above,
this document calls for encrypting JWT represe= nting the access token.

Regards= ,
=C2=A0Rifaat


On Tue, Apr 21, 2020 at 1:49 A= M Barry Leiba via Datatracker <norep= ly@ietf.org> wrote:
Barry Leiba has entered the following ballot position for
draft-ietf-sipcore-sip-token-authnz-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-sipcore-sip-token-authnz/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document.=C2=A0 Enabling Open-ID and OAUTH with SIP is quit= e useful.

This document specifically calls out single sign-on as a reason to use this=
mechanism, and SSO has a host of serious security and privacy issues.=C2=A0= As those
issues are not discussed in the referenced documents, I think they need to = be
raised here.=C2=A0 Recommended usage/configuration to avoid or mitigate the= issues
would be ideal, but at the very least I think they need to be documented, a= s
it=E2=80=99s clear that implementors are not aware of them or don=E2=80=99t= think they=E2=80=99re
important enough to worry about.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

=E2=80=94 Section 1.1 =E2=80=94
Please copy the BCP 14 boilerplate exactly from RFC 8174.

=E2=80=94 Section 1.3 =E2=80=94

=C2=A0 =C2=A0Refresh Tokens usualy are represented in a reference format
Typo: =E2=80=9Cusually=E2=80=9D.

=E2=80=94 Section 3 =E2=80=94

=C2=A0 =C2=A0The methods used and the access
=C2=A0 =C2=A0provided by the token is based on local policy

=E2=80=9Care based=E2=80=9D, to match the plural subject.

=C2=A0 =C2=A0Examples of such other
=C2=A0 =C2=A0mechanisms are introspection [RFC7662], user profile lookups, = etc.

=E2=80=9CExamples=E2=80=9D and =E2=80=9Cetc.=E2=80=9D are mutually redundan= t.=C2=A0 I would remive the latter and
replace the comma before =E2=80=9Cuser profile lookups=E2=80=9D with =E2=80= =9Cand=E2=80=9D.

=E2=80=94 Section 6 =E2=80=94
This can=E2=80=99t be empty.=C2=A0 It should say that there are no IANA act= ions needed for
this document.



--00000000000035bac105a3cad7b8-- From nobody Tue Apr 21 04:36:57 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FA13A0930; Tue, 21 Apr 2020 04:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 t9Lymh4a2hUd; Tue, 21 Apr 2020 04:36:46 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 A194B3A0927; Tue, 21 Apr 2020 04:36:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L4zL05V6q+Iu1L9N28/Vf1xw+08GAZEvk4c4HqxGc65lD/uGU/+EjbNr0F13od8NWj3KbEYOTMhCdovz+PYrzxJlT4P7YZOFg4Pln55WwwROtPrVSilCRffzGHtBrCGnhqDvk2TaHeo8NWdXSX9NA0JukgR1fHgL5bF3n+Bm+LYaydl9VTDtQAdYHwb3/GNeBj6/Q1HzjqlzOYFKcix2QZm8RV5nqg+69mY4m/lwuDGtUOyRbV4WzmV1iRQlAifrOTmOQ4+2KugZpgRNoSRRKJxM6r8OkjZRYr9JRZOlLJ3FfqlKPpcFNLZfKIwy+byxPOu9v4tQuoUU9HX143EiQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oJouIo0ifhsadGT1NFv8DeJq/OFNSZOSognmjV3SDRg=; b=FJwnwNHuAlw6T83K+uPMATeGEtInAyC0FURmL9c5R6mdHWTN6CbX8xwnergXKSn/wYrLR5URvqhxosvQBXhUNLxYdNIf74SH3xPNMLJ4686Ha/RkeyRBM3BvNJ4BI6UpSsnHBDOO5YfygEiZqXnjLgIbl0F8RWwTFzxMBkgAHBxyqvOolvHU6hZiFCJRudfjwCAzQw7OX2Zaw4n45Vt2FY+LridjJjnMi5WeF+qeB07eCipdccBCimztjxfEhsEYLqludpQN6NTZydi+4/uD47NiKm8pJQdiRkTI7Mg4DuHl0whj2vsGmTK2bd8LuHuU1wnQ1FTsSuBxfKBOUvwj6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oJouIo0ifhsadGT1NFv8DeJq/OFNSZOSognmjV3SDRg=; b=E8FGBVbI9CnZV9/D8SGExgjGkc14UmIU7rIiWM0YA83fyBENYu7a3X1hw2fAAGRc7bKtCL6Rc3C/W1K1/pzo2xUu9lGdaNN8UkpeGdGp7dT+ezmwfFMEMfY68gJJUy9D+8BNZI9belBvcSmv+P5nGKTlmSiOB7HRwSY+jRfkO5g= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6228.eurprd07.prod.outlook.com (2603:10a6:20b:15f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Tue, 21 Apr 2020 11:36:42 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.012; Tue, 21 Apr 2020 11:36:42 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Barry Leiba CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Thread-Topic: Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) Thread-Index: AQHWF6Cz+WlBMDlRJECoP3jg2Sy266iDZywAgAA+HgA= Date: Tue, 21 Apr 2020 11:36:42 +0000 Message-ID: References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 298d7025-d3c4-4aa3-31a5-08d7e5e843ac x-ms-traffictypediagnostic: AM0PR07MB6228: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 038002787A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(186003)(36756003)(33656002)(2616005)(6512007)(478600001)(76116006)(66476007)(91956017)(110136005)(66946007)(54906003)(64756008)(6486002)(71200400001)(66446008)(316002)(2906002)(44832011)(5660300002)(21615005)(4326008)(66556008)(966005)(81156014)(6506007)(8676002)(53546011)(26005)(8936002)(86362001)(66574012); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sgqnWxbjO8acK4P5cat3ENJIugB1n9CEhYmEEGqXXevNJyHzPxcBh+LdzBkcjvlBG+LZiprH+8BTw1VKMvs5jr9jjgfDeSAhSYWle77G5LGJDFpyxJLNCC6vD6wVsh/GfpjQl//fImnp+RZDUTJb1dvxQntzIiVVFbRpvkphnTaCNEat4Cy3Fdp7ClvLxO0ZvcTHTrE0kEy2XwEyTKQpXjGbY7zPYWikQJ6YpFP0wCyRpYHEwp7CF1FThsQgX2YA4ktt7LYLQdwm1ZMFArfSB42RqbgiyvQlGMCihpFjC6DvKjwh/ZfRKiU9HZ8oiTed+4gIcn3DfCCjLpkDIYj5A3ezZeAj7pnlNWJhTpRvFWR9XHRMppBdKaC4lgS1hUG+vJiOKDoLcIZh/cYO+vNhK5vecaei1a7WYU4az40uXeDbPSvKhlJFLaZ0mFUYx52v8OqynjvppSkRMB9AyGfFA9BuE75MJcajUdxrQk0xuTjlKVITZmDBzmJpF2CqFRsDupBhxQnY5Ko9XsmkenAA+A== x-ms-exchange-antispam-messagedata: xEVpEpxYlCAZNXrWta7AzFu/+diSF1QV7eaXXflRRpvEU+70DDlt5WCa4H/moAp6OMEel+MYFst27phhNzUdAhXbUnrS4VkmJel90QPdQ7jpetXbqGtaoazRG3QATxOvWO3dowE5m7GnOel7AxpOwQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E5AA94031BC64B648BB18216201818E2ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 298d7025-d3c4-4aa3-31a5-08d7e5e843ac X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 11:36:42.5566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3Qg6KeIooXDNICNrwGBAc5b+PAq91d465nAukQTm0RA4Eg61yYUkA1rM/d0+tlaQxOj+NXpxjMgYk0iH7H7o5EkdhaRkWvVhT1tl+nQD8Sk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6228 Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 11:36:49 -0000 --_000_E5AA94031BC64B648BB18216201818E2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHB1bGwgcmVxdWVzdDogaHR0cHM6Ly9naXRodWIuY29tL3JpZmFhdC1pZXRmL2RyYWZ0LWll dGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56L3B1bGwvNw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQpGcm9tOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT4NCkRh dGU6IFR1ZXNkYXksIDIxIEFwcmlsIDIwMjAgYXQgMTMuNTQNClRvOiBCYXJyeSBMZWliYSA8YmFy cnlsZWliYUBjb21wdXRlci5vcmc+DQpDYzogImllc2dAaWV0Zi5vcmciIDxpZXNnQGlldGYub3Jn PiwgImRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56QGlldGYub3JnIiA8ZHJhZnQt aWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnpAaWV0Zi5vcmc+LCAic2lwY29yZS1jaGFpcnNA aWV0Zi5vcmciIDxzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZz4sICJzaXBjb3JlQGlldGYub3JnIiA8 c2lwY29yZUBpZXRmLm9yZz4sICJBLiBNYWhvbmV5IiA8bWFob25leUBub3N0cnVtLmNvbT4NClN1 YmplY3Q6IFJlOiBCYXJyeSBMZWliYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXNp cC10b2tlbi1hdXRobnotMTM6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQpSZXNlbnQgZnJv bTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQgdG86IFJpZmFhdCBTaGVraC1ZdXNl ZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPiwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4sIFZpY3RvciBQYXNjdWFsIDx2aWN0b3IucGFzY3VhbC5hdmls YUBnbWFpbC5jb20+DQpSZXNlbnQgZGF0ZTogVHVlc2RheSwgMjEgQXByaWwgMjAyMCBhdCAxMy41 NA0KDQpIaSBCYXJyeSwNCg0KVGhhbmtzIGZvciB5b3VyIHRoZSByZXZpZXcuDQpSZWdhcmRpbmcg dGhlIERJU0NVU1MsIGhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOg0KDQpTaW5nbGUgU2luZy1PbiBlbmFibGVz IHRoZSB1c2VyIHRvIHVzZSBvbmUgc2V0IG9mIGNyZWRlbnRpYWxzIHRvIGF1dGhlbnRpY2F0ZQ0K b25jZSBhbmQgZ2FpbiBhY2Nlc3MgdG8gbXVsdGlwbGUgU0lQIGFuZCBub24tU0lQIHNlcnZpY2Vz IHVzaW5nIGFjY2VzcyB0b2tlbihzKS4NCkJlY2F1c2Ugb2YgdGhhdCwgaXQgaXMgY3JpdGljYWwg dG8gbWFrZSBzdXJlIHRoYXQgZXh0cmEgc2VjdXJpdHkgbWVhc3VyZXMgYmUNCnRha2VuIHRvIGd1 YXJkcyB0aGVzZSBjcmVkZW50aWFscy4NCg0KRXhhbXBsZXMgb2Ygc3VjaCBtZWFzdXJlcyBpbmNs dWRlIGxvbmcgcGFzc3BocmFzZSBpbnN0ZWFkIG9mIGEgcGFzc3dvcmQsIGVuYWJsaW5nDQptdWx0 aS1mYWN0b3IgZmFjdG9yIGF1dGhlbnRpY2F0aW9uLCBhbmQgdGhlIHVzZSBvZiBlbWJlZGRlZCBi cm93c2VyIHdoZW4gcG9zc2libGUsDQphcyBkZWZpbmVkIGluIFJGQzgyNTIuDQoNCkFsdGhvdWdo IHRoaXMgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LCBpdCBpcyBpbXBvcnRhbnQg dG8gY2FyZWZ1bGx5DQpjb25zaWRlciB0aGUgY2xhaW1zIHByb3ZpZGVkIGluIHRoZSB0b2tlbnMg dXNlZCB0byBhY2Nlc3MgdGhlc2Ugc2VydmljZXMgdG8gbWFrZQ0Kc3VyZSBvZiB0aGUgcHJpdmFj eSBvZiB0aGUgdXNlciBhY2Nlc3NpbmcgdGhlc2Ugc2VydmljZXMuIEFzIG1lbnRpb25lZCBhYm92 ZSwNCnRoaXMgZG9jdW1lbnQgY2FsbHMgZm9yIGVuY3J5cHRpbmcgSldUIHJlcHJlc2VudGluZyB0 aGUgYWNjZXNzIHRva2VuLg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIFR1ZSwgQXByIDIx LCAyMDIwIGF0IDE6NDkgQU0gQmFycnkgTGVpYmEgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGll dGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpCYXJyeSBMZWliYSBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtc2lw Y29yZS1zaXAtdG9rZW4tYXV0aG56LTEzOiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnovDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFua3MgZm9yIHRoaXMgZG9j dW1lbnQuICBFbmFibGluZyBPcGVuLUlEIGFuZCBPQVVUSCB3aXRoIFNJUCBpcyBxdWl0ZSB1c2Vm dWwuDQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWNhbGx5IGNhbGxzIG91dCBzaW5nbGUgc2lnbi1v biBhcyBhIHJlYXNvbiB0byB1c2UgdGhpcw0KbWVjaGFuaXNtLCBhbmQgU1NPIGhhcyBhIGhvc3Qg b2Ygc2VyaW91cyBzZWN1cml0eSBhbmQgcHJpdmFjeSBpc3N1ZXMuICBBcyB0aG9zZQ0KaXNzdWVz IGFyZSBub3QgZGlzY3Vzc2VkIGluIHRoZSByZWZlcmVuY2VkIGRvY3VtZW50cywgSSB0aGluayB0 aGV5IG5lZWQgdG8gYmUNCnJhaXNlZCBoZXJlLiAgUmVjb21tZW5kZWQgdXNhZ2UvY29uZmlndXJh dGlvbiB0byBhdm9pZCBvciBtaXRpZ2F0ZSB0aGUgaXNzdWVzDQp3b3VsZCBiZSBpZGVhbCwgYnV0 IGF0IHRoZSB2ZXJ5IGxlYXN0IEkgdGhpbmsgdGhleSBuZWVkIHRvIGJlIGRvY3VtZW50ZWQsIGFz DQppdOKAmXMgY2xlYXIgdGhhdCBpbXBsZW1lbnRvcnMgYXJlIG5vdCBhd2FyZSBvZiB0aGVtIG9y IGRvbuKAmXQgdGhpbmsgdGhleeKAmXJlDQppbXBvcnRhbnQgZW5vdWdoIHRvIHdvcnJ5IGFib3V0 Lg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCuKAlCBTZWN0 aW9uIDEuMSDigJQNClBsZWFzZSBjb3B5IHRoZSBCQ1AgMTQgYm9pbGVycGxhdGUgZXhhY3RseSBm cm9tIFJGQyA4MTc0Lg0KDQrigJQgU2VjdGlvbiAxLjMg4oCUDQoNCiAgIFJlZnJlc2ggVG9rZW5z IHVzdWFseSBhcmUgcmVwcmVzZW50ZWQgaW4gYSByZWZlcmVuY2UgZm9ybWF0DQoNClR5cG86IOKA nHVzdWFsbHnigJ0uDQoNCuKAlCBTZWN0aW9uIDMg4oCUDQoNCiAgIFRoZSBtZXRob2RzIHVzZWQg YW5kIHRoZSBhY2Nlc3MNCiAgIHByb3ZpZGVkIGJ5IHRoZSB0b2tlbiBpcyBiYXNlZCBvbiBsb2Nh bCBwb2xpY3kNCg0K4oCcYXJlIGJhc2Vk4oCdLCB0byBtYXRjaCB0aGUgcGx1cmFsIHN1YmplY3Qu DQoNCiAgIEV4YW1wbGVzIG9mIHN1Y2ggb3RoZXINCiAgIG1lY2hhbmlzbXMgYXJlIGludHJvc3Bl Y3Rpb24gW1JGQzc2NjJdLCB1c2VyIHByb2ZpbGUgbG9va3VwcywgZXRjLg0KDQrigJxFeGFtcGxl c+KAnSBhbmQg4oCcZXRjLuKAnSBhcmUgbXV0dWFsbHkgcmVkdW5kYW50LiAgSSB3b3VsZCByZW1p dmUgdGhlIGxhdHRlciBhbmQNCnJlcGxhY2UgdGhlIGNvbW1hIGJlZm9yZSDigJx1c2VyIHByb2Zp bGUgbG9va3Vwc+KAnSB3aXRoIOKAnGFuZOKAnS4NCg0K4oCUIFNlY3Rpb24gNiDigJQNClRoaXMg Y2Fu4oCZdCBiZSBlbXB0eS4gIEl0IHNob3VsZCBzYXkgdGhhdCB0aGVyZSBhcmUgbm8gSUFOQSBh Y3Rpb25zIG5lZWRlZCBmb3INCnRoaXMgZG9jdW1lbnQuDQoNCg0K --_000_E5AA94031BC64B648BB18216201818E2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <06BECC5B5F054B4DB6EB2D295E8049C8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGUgcHVsbCByZXF1ZXN0Og0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0 aHViLmNvbS9yaWZhYXQtaWV0Zi9kcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei9w dWxsLzciPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20vcmlmYWF0LWlldGYv ZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnovcHVsbC83PC9zcGFuPjwvYT48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5SaWZhYXQgU2hla2gtWXVzZWYg Jmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwg MjEgQXByaWwgMjAyMCBhdCAxMy41NDxicj4NCjxiPlRvOiA8L2I+QmFycnkgTGVpYmEgJmx0O2Jh cnJ5bGVpYmFAY29tcHV0ZXIub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7aWVzZ0BpZXRm Lm9yZyZxdW90OyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYtc2lwY29y ZS1zaXAtdG9rZW4tYXV0aG56QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLXNpcGNvcmUt c2lwLXRva2VuLWF1dGhuekBpZXRmLm9yZyZndDssICZxdW90O3NpcGNvcmUtY2hhaXJzQGlldGYu b3JnJnF1b3Q7ICZsdDtzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O3NpcGNvcmVA aWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtBLiBNYWhvbmV5 JnF1b3Q7ICZsdDttYWhvbmV5QG5vc3RydW0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S ZTogQmFycnkgTGVpYmEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4t YXV0aG56LTEzOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxicj4NCjxiPlJlc2VudCBmcm9t OiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50IHRvOiA8 L2I+UmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywgVmlj dG9yIFBhc2N1YWwgJmx0O3ZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbSZndDs8YnI+DQo8 Yj5SZXNlbnQgZGF0ZTogPC9iPlR1ZXNkYXksIDIxIEFwcmlsIDIwMjAgYXQgMTMuNTQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp Jm5ic3A7QmFycnksIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhbmtzIGZvciB5b3VyIHRoZSByZXZpZXcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgdGhlIERJU0NVU1MsIGhvdyBhYm91 dCBhZGRpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNpbmdsZSBTaW5nLU9uIGVuYWJsZXMgdGhlIHVzZXIgdG8gdXNlIG9u ZSBzZXQgb2YgY3JlZGVudGlhbHMgdG8gYXV0aGVudGljYXRlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vbmNlIGFuZCBn YWluIGFjY2VzcyB0byBtdWx0aXBsZSBTSVAgYW5kIG5vbi1TSVAgc2VydmljZXMgdXNpbmcgYWNj ZXNzIHRva2VuKHMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVjYXVzZSBvZiB0aGF0LCBpdCBpcyBjcml0aWNhbCB0 byBtYWtlIHN1cmUgdGhhdCBleHRyYSBzZWN1cml0eSBtZWFzdXJlcyBiZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGFr ZW4gdG8gZ3VhcmRzIHRoZXNlIGNyZWRlbnRpYWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGFtcGxlcyBvZiBz dWNoIG1lYXN1cmVzIGluY2x1ZGUgbG9uZyBwYXNzcGhyYXNlIGluc3RlYWQgb2YgYSBwYXNzd29y ZCwgZW5hYmxpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPm11bHRpLWZhY3RvciBmYWN0b3IgYXV0aGVudGljYXRpb24s IGFuZCB0aGUgdXNlIG9mIGVtYmVkZGVkIGJyb3dzZXIgd2hlbiBwb3NzaWJsZSw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFzIGRlZmluZWQgaW4gUkZDODI1Mi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx0aG91 Z2ggdGhpcyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQsIGl0IGlzIGltcG9ydGFu dCB0byBjYXJlZnVsbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbnNpZGVyIHRoZSBjbGFpbXMgcHJvdmlkZWQgaW4g dGhlIHRva2VucyB1c2VkIHRvIGFjY2VzcyB0aGVzZSBzZXJ2aWNlcyB0byBtYWtlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5zdXJlIG9mIHRoZSBwcml2YWN5IG9mIHRoZSB1c2VyIGFjY2Vzc2luZyB0aGVzZSBzZXJ2aWNl cy4gQXMgbWVudGlvbmVkIGFib3ZlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpcyBkb2N1bWVudCBjYWxscyBmb3Ig ZW5jcnlwdGluZyBKV1QgcmVwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDIxLCAyMDIwIGF0IDE6NDkgQU0g QmFycnkgTGVpYmEgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBp ZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5CYXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei0x MzogRGlzY3Vzczxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJy Pg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0KUGxl YXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu PGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KRElTQ1VTUzo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0K VGhhbmtzIGZvciB0aGlzIGRvY3VtZW50LiZuYnNwOyBFbmFibGluZyBPcGVuLUlEIGFuZCBPQVVU SCB3aXRoIFNJUCBpcyBxdWl0ZSB1c2VmdWwuPGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCBzcGVj aWZpY2FsbHkgY2FsbHMgb3V0IHNpbmdsZSBzaWduLW9uIGFzIGEgcmVhc29uIHRvIHVzZSB0aGlz PGJyPg0KbWVjaGFuaXNtLCBhbmQgU1NPIGhhcyBhIGhvc3Qgb2Ygc2VyaW91cyBzZWN1cml0eSBh bmQgcHJpdmFjeSBpc3N1ZXMuJm5ic3A7IEFzIHRob3NlPGJyPg0KaXNzdWVzIGFyZSBub3QgZGlz Y3Vzc2VkIGluIHRoZSByZWZlcmVuY2VkIGRvY3VtZW50cywgSSB0aGluayB0aGV5IG5lZWQgdG8g YmU8YnI+DQpyYWlzZWQgaGVyZS4mbmJzcDsgUmVjb21tZW5kZWQgdXNhZ2UvY29uZmlndXJhdGlv biB0byBhdm9pZCBvciBtaXRpZ2F0ZSB0aGUgaXNzdWVzPGJyPg0Kd291bGQgYmUgaWRlYWwsIGJ1 dCBhdCB0aGUgdmVyeSBsZWFzdCBJIHRoaW5rIHRoZXkgbmVlZCB0byBiZSBkb2N1bWVudGVkLCBh czxicj4NCml04oCZcyBjbGVhciB0aGF0IGltcGxlbWVudG9ycyBhcmUgbm90IGF3YXJlIG9mIHRo ZW0gb3IgZG9u4oCZdCB0aGluayB0aGV54oCZcmU8YnI+DQppbXBvcnRhbnQgZW5vdWdoIHRvIHdv cnJ5IGFib3V0Ljxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQrigJQgU2VjdGlvbiAxLjEg4oCUPGJyPg0KUGxl YXNlIGNvcHkgdGhlIEJDUCAxNCBib2lsZXJwbGF0ZSBleGFjdGx5IGZyb20gUkZDIDgxNzQuPGJy Pg0KPGJyPg0K4oCUIFNlY3Rpb24gMS4zIOKAlDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtSZWZy ZXNoIFRva2VucyB1c3VhbHkgYXJlIHJlcHJlc2VudGVkIGluIGEgcmVmZXJlbmNlIGZvcm1hdDxi cj4NCjxicj4NClR5cG86IOKAnHVzdWFsbHnigJ0uPGJyPg0KPGJyPg0K4oCUIFNlY3Rpb24gMyDi gJQ8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIG1ldGhvZHMgdXNlZCBhbmQgdGhlIGFjY2Vz czxicj4NCiZuYnNwOyAmbmJzcDtwcm92aWRlZCBieSB0aGUgdG9rZW4gaXMgYmFzZWQgb24gbG9j YWwgcG9saWN5PGJyPg0KPGJyPg0K4oCcYXJlIGJhc2Vk4oCdLCB0byBtYXRjaCB0aGUgcGx1cmFs IHN1YmplY3QuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0V4YW1wbGVzIG9mIHN1Y2ggb3RoZXI8 YnI+DQombmJzcDsgJm5ic3A7bWVjaGFuaXNtcyBhcmUgaW50cm9zcGVjdGlvbiBbUkZDNzY2Ml0s IHVzZXIgcHJvZmlsZSBsb29rdXBzLCBldGMuPGJyPg0KPGJyPg0K4oCcRXhhbXBsZXPigJ0gYW5k IOKAnGV0Yy7igJ0gYXJlIG11dHVhbGx5IHJlZHVuZGFudC4mbmJzcDsgSSB3b3VsZCByZW1pdmUg dGhlIGxhdHRlciBhbmQ8YnI+DQpyZXBsYWNlIHRoZSBjb21tYSBiZWZvcmUg4oCcdXNlciBwcm9m aWxlIGxvb2t1cHPigJ0gd2l0aCDigJxhbmTigJ0uPGJyPg0KPGJyPg0K4oCUIFNlY3Rpb24gNiDi gJQ8YnI+DQpUaGlzIGNhbuKAmXQgYmUgZW1wdHkuJm5ic3A7IEl0IHNob3VsZCBzYXkgdGhhdCB0 aGVyZSBhcmUgbm8gSUFOQSBhY3Rpb25zIG5lZWRlZCBmb3I8YnI+DQp0aGlzIGRvY3VtZW50Ljxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E5AA94031BC64B648BB18216201818E2ericssoncom_-- From nobody Tue Apr 21 06:42:47 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386EA3A0C9B; Tue, 21 Apr 2020 06:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnidFSFEIxF7; Tue, 21 Apr 2020 06:42:19 -0700 (PDT) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 DCE363A0C94; Tue, 21 Apr 2020 06:42:18 -0700 (PDT) Received: by mail-vs1-xe41.google.com with SMTP id h30so7987442vsr.5; Tue, 21 Apr 2020 06:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/AGnQ0Kb5VDWgqAzuaQ0x6VszqEkIAMlaUjBUbcXWLk=; b=KKYBVryfQcoNTFVC9I1QjD7qV9r4DExaQ7GHP1rQIDDfhZIcsIzFQb8+Fgh/wv5QPB TPGlxm0vIDdoc26tTHgPt3hltRUjt5IUudZXt+ehwKsffWTzh7Eye/ft1S88Gvu9rv0p 88ACvwm4YV8CXCVBEKHaQg6GR43kbluIaWWCVMJ2l7E0Oyq0LwPHBMRmzuh8ajN55nv8 cJVUV49MpJK+l+oeQSi83hi4SuRlwl7WRorMyhYsGCBFxAXW281unJQSMT7Y6Zy9gtWD iAiGoOpBgwtb4yKBXkPapm4IlBtk7RCGEyzrTySPaYgsNXucYtBMPPTlnOFV5oI8OH44 6rAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/AGnQ0Kb5VDWgqAzuaQ0x6VszqEkIAMlaUjBUbcXWLk=; b=KDLZkmL5OGg5BRdfHLX+NRNuM1aBV4XOIYD3VGGvWhESQeTM8bH3LiGomEV4f7rRCq cGzxTkL0xHOAHN7Ru/CAPIyGh5UCOyyFBYWBkPCCxxpy8/r9ojvqOTm/+ELhqMw6ZHqR G2UN5a7LHmjrNQcfnN9eMBxqFZoO8cCy8BhGz2gJ5LG6amq4k/wAe8lJWeZvOaYYp8Xl go3VnQrE7bFdwD5yrcw2bo3vBHBHouWeRGqQ2IzKlxwTv5/YoCYZvnrW6lgifnApZd3p zWcrUQXckcI0KvwryQ/rKi2LdsZ0YtvrZd1zfwM5FgtWJYL4BOOD9GU00VfwD9rvhIXF JK3w== X-Gm-Message-State: AGi0PubVm4Mu9bjEtgHF+7Cm4atIAA6P7oddPcpQexLY5zuXKUYD6Akb K4dtdC5i+5ADTK9SYdXLORNLOenMsYqtbVfOIOo= X-Google-Smtp-Source: APiQypKBSPNpBizyvPpjQ7A2vqC7hxGQUDcY8bndM3DeEAXOGilTeZBRhzmzwiP1KnPNDb6ouCdCoO2hcN7ARJtSt30= X-Received: by 2002:a67:eb84:: with SMTP id e4mr15769638vso.8.1587476537674; Tue, 21 Apr 2020 06:42:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 21 Apr 2020 06:42:05 -0700 Message-ID: To: Christer Holmberg Cc: Barry Leiba , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , Jean Mahoney , "sipcore-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e10ac05a3cd2fcc" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - Barry's COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 13:42:25 -0000 --0000000000001e10ac05a3cd2fcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 21, 2020 at 3:02 AM Christer Holmberg wrote: > > =E2=80=94 Section 6 =E2=80=94 > > This can=E2=80=99t be empty. It should say that there are no IANA a= ctions > needed for > > this document. > > We discussed this with IANA, and the idea is to remove the whole section > (they said it is up to us to either remove it, or to keep it and add text > saying there are no IANA requests). > This is pretty common, but going along with that is a section that just contains: "This document has no actions for IANA." ...sometimes accompanied by: "[RFC Editor: Please delete this section before publication.]" (Dunno how I missed this, frankly. Must've been going too fast.) -MSK --0000000000001e10ac05a3cd2fcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 21, 2020 at 3:02 AM Christer = Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote:
>=C2=A0 = =C2=A0 =E2=80=94 Section 6 =E2=80=94
>=C2=A0 =C2=A0 This can=E2=80=99t be empty.=C2=A0 It should say that the= re are no IANA actions needed for
>=C2=A0 =C2=A0 this document.

We discussed this with IANA, and the idea is to remove the whole section (t= hey said it is up to us to either remove it, or to keep it and add text say= ing there are no IANA requests).

This i= s pretty common, but going along with that is a section that just contains:=

"This document has no actions for IANA."
...sometimes accompanied by:

"[RFC Edit= or: Please delete this section before publication.]"

(Dunno how I missed this, frankly.=C2=A0 Must've been going too fast.)=

-MSK
--0000000000001e10ac05a3cd2fcc-- From nobody Tue Apr 21 06:52:52 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B923A0CCC; Tue, 21 Apr 2020 06:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 QGZzG3BNNRPk; Tue, 21 Apr 2020 06:52:38 -0700 (PDT) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 815A33A0CC2; Tue, 21 Apr 2020 06:52:38 -0700 (PDT) Received: by mail-io1-f66.google.com with SMTP id b12so15030428ion.8; Tue, 21 Apr 2020 06:52:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IVNBQQk+V/o2ft4fnj/Ef9WAZR8ZQPVAsQGhlERTSO0=; b=ilijYntRThzqH+gv9i2I2lAsLLY60qmPjnrOPYwc1lxZFEnWT5WzXOBJjZR7D30EBy Kou4hP70DxpwksRlPmzTfraV1dayg3zALW9lD/NLekFZJYf7Tk7jXiQwGIF4bgQLL0z0 BXZu6OyJ9LMiKwT/44d6P3bAFjM9FQmqyaGH5q/YCuXWu7yVXZN2SFiV3/K84Wg/Tvbq LDPGC1GIWMWhmMUM81pzbQBayDV/dxK05VyZ1aPPRdbibN0CCz829QYft84ztsSpY5IT cbttX8c5vUToXMzxA9CBT38/1np98gA0ZULGU5cuK23gVg0ANlVsR0o1cy6E1yxbf2wH ur+w== X-Gm-Message-State: AGi0PubStb1GKTgiHVQvlsf21mfsrtntaHZ6pGXeth58QkvQk9hCKswR 4mypDhywU3dxLlTLGTCarxPiui+o4TefmD+Y1185VKft X-Google-Smtp-Source: APiQypKboJMdgkZXBN+J7spAb5Gc/rSe3GSgYFzJ2Z8qPcottDlraSwaBqjOQS5orM0LEBoJE16CIfw3widZHrx9Iy0= X-Received: by 2002:a02:ac1:: with SMTP id 184mr19401020jaw.140.1587477157596; Tue, 21 Apr 2020 06:52:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Tue, 21 Apr 2020 09:52:26 -0400 Message-ID: To: Christer Holmberg Cc: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - Barry's COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 13:52:46 -0000 All good here, and thanks for the quick response. On the IANA section, yes, as Murray notes, we do usually put in a single "nothing to see here" sentence, even if the RFC Editor will remove the section later. But it's not a big deal, as it'll be removed anyway. Barry On Tue, Apr 21, 2020 at 6:01 AM Christer Holmberg wrote: > > Hi Barry, > > Thank You for the review! > > In this reply I will address your COMMENT. The DISCUSS will be addressed = in a separate reply. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > =E2=80=94 Section 1.1 =E2=80=94 > > Please copy the BCP 14 boilerplate exactly from RFC 8174. > > Will do. > > --- > > > =E2=80=94 Section 1.3 =E2=80=94 > > > > Refresh Tokens usualy are represented in a reference format > > > > Typo: =E2=80=9Cusually=E2=80=9D. > > Will fix. > > --- > > > =E2=80=94 Section 3 =E2=80=94 > > > > The methods used and the access > > provided by the token is based on local policy > > > > =E2=80=9Care based=E2=80=9D, to match the plural subject. > > Will fix. > > --- > > > Examples of such other > > mechanisms are introspection [RFC7662], user profile lookups, etc= . > > > > =E2=80=9CExamples=E2=80=9D and =E2=80=9Cetc.=E2=80=9D are mutually r= edundant. I would remive the latter and > > replace the comma before =E2=80=9Cuser profile lookups=E2=80=9D with= =E2=80=9Cand=E2=80=9D. > > I suggest: > > "Examples of such other mechanisms are introspection [RFC7662] and user p= rofile lookups." > > --- > > > =E2=80=94 Section 6 =E2=80=94 > > This can=E2=80=99t be empty. It should say that there are no IANA a= ctions needed for > > this document. > > We discussed this with IANA, and the idea is to remove the whole section = (they said it is up to us to either remove it, or to keep it and add text s= aying there are no IANA requests). > > --- > > Below is a link to a GitHub pull request with the changes based on the CO= MMENT issues: > > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/6 > > Regards, > > Christer > > > > > > From nobody Tue Apr 21 07:46:45 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014813A03EB; Tue, 21 Apr 2020 07:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWnGFnl4QQTN; Tue, 21 Apr 2020 07:46:08 -0700 (PDT) Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (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 B3DD93A0115; Tue, 21 Apr 2020 07:46:07 -0700 (PDT) Received: by mail-il1-x142.google.com with SMTP id u5so13640032ilb.5; Tue, 21 Apr 2020 07:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oMl/4YmqWWi5iXmuNhVJShoGW0xE1YvTMfafwfjwqgk=; b=l1ruvFaIjVk4cqlUl3wRgMBvlcVoxowVvvg1ioFu6wXg2uW9cjhbKJkAQ32bo/MPwF hcteHNhLE2vjGxEuTcPeR02+2MTTsdFhUWKnYZxlje1B52PCj2AL4rVH+rAIxCXPnl29 5uPu8YXO3wmGVjZQqFkfxbcP4zeN0XMsHs9PqerpBYr1sq+Ozzuj5inr1QP2Fl1KFmre cRojmyrqo1d7NmnG/wbCS4D8b1C3OrIvZjTySW/wQEB3rWkPvdVWD9tT92A+ZYneqs+6 e2JQHyM50ndAb9PVuYcm8Lfi8lgYScjK1WCTq9bdwZKbmB6PSXNvfG4gZab7qqOn49Gc 8vNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oMl/4YmqWWi5iXmuNhVJShoGW0xE1YvTMfafwfjwqgk=; b=SdL/GVPKG+Z8lAXGhGeWW0ow/ge6zeF6g+yMCyOZt2IiaQw3XSvYZcgyZI1Wd0R/My 1Up9CL8VfOath2uERG+ehgLS4ISkwPwuPuvCiyD+GTxI+gW9D3aYL44V5uz837v3k9Dz R7PsL/TWuSKp0nW0pse3u+jLXaN6DuB8Q9M/cMCRqIY6MZfdcZJCOjubE/1q3+uL6gEs /AH0YEsZ9Cpgj7i/XkX4vXuTXQKpni+j080M0jORKtc0g/KB8Klbxdurx/2uVCQtR9Ph ejTQRy2zWFShBLfrJNnVcWC2dYd87FvVJ96RcS8wKB82o9lIapcQf/qrTyS+y7xgx0ry 0jlQ== X-Gm-Message-State: AGi0PubqrUdvVOn5WzGDuNOPb3CNrRWEXyz2J0ZdwnDlJMSPKemrnDIN bAd/274kxOfyhX1N1hxMdt0i7ZwGWCWejSdXkRI= X-Google-Smtp-Source: APiQypKQjVfv7S+sIoukNvI/9EHi8AIUmSpG+VVB+5EzSrIAYxBq2EOFd/S1aYHehMf9CrqmEC4wCLm2riyPwv0Ff3w= X-Received: by 2002:a92:d3c5:: with SMTP id c5mr21740842ilh.73.1587480365827; Tue, 21 Apr 2020 07:46:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 21 Apr 2020 10:45:55 -0400 Message-ID: To: Barry Leiba Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: multipart/alternative; boundary="0000000000004b0dbe05a3ce1308" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - Barry's COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 14:46:11 -0000 --0000000000004b0dbe05a3ce1308 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Barry, Just to make sure we are all on the same page, does the "All good here" include the answer to the DISCUSS? Regards, Rifaat On Tue, Apr 21, 2020 at 9:52 AM Barry Leiba wrote= : > All good here, and thanks for the quick response. > On the IANA section, yes, as Murray notes, we do usually put in a > single "nothing to see here" sentence, even if the RFC Editor will > remove the section later. But it's not a big deal, as it'll be > removed anyway. > > Barry > > On Tue, Apr 21, 2020 at 6:01 AM Christer Holmberg > wrote: > > > > Hi Barry, > > > > Thank You for the review! > > > > In this reply I will address your COMMENT. The DISCUSS will be addresse= d > in a separate reply. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > =E2=80=94 Section 1.1 =E2=80=94 > > > Please copy the BCP 14 boilerplate exactly from RFC 8174. > > > > Will do. > > > > --- > > > > > =E2=80=94 Section 1.3 =E2=80=94 > > > > > > Refresh Tokens usualy are represented in a reference format > > > > > > Typo: =E2=80=9Cusually=E2=80=9D. > > > > Will fix. > > > > --- > > > > > =E2=80=94 Section 3 =E2=80=94 > > > > > > The methods used and the access > > > provided by the token is based on local policy > > > > > > =E2=80=9Care based=E2=80=9D, to match the plural subject. > > > > Will fix. > > > > --- > > > > > Examples of such other > > > mechanisms are introspection [RFC7662], user profile lookups, e= tc --0000000000004b0dbe05a3ce1308 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Barry,

Just to make sure we= are all on the same page, does the "All good here" include the a= nswer to the DISCUSS?

Regards,
=C2=A0Rif= aat


On Tue, Apr 21, 2020 at 9:52 AM Barry Leiba <barryleiba@computer.org> wro= te:
All good her= e, and thanks for the quick response.
On the IANA section, yes, as Murray notes, we do usually put in a
single "nothing to see here" sentence, even if the RFC Editor wil= l
remove the section later.=C2=A0 But it's not a big deal, as it'll b= e
removed anyway.

Barry

On Tue, Apr 21, 2020 at 6:01 AM Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
>
> Hi Barry,
>
> Thank You for the review!
>
> In this reply I will address your COMMENT. The DISCUSS will be address= ed in a separate reply.
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> >=C2=A0 =C2=A0 =E2=80=94 Section 1.1 =E2=80=94
> >=C2=A0 =C2=A0 Please copy the BCP 14 boilerplate exactly from RFC = 8174.
>
> Will do.
>
> ---
>
> >=C2=A0 =C2=A0 =E2=80=94 Section 1.3 =E2=80=94
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Refresh Tokens usualy are represented i= n a reference format
> >
> >=C2=A0 =C2=A0 Typo: =E2=80=9Cusually=E2=80=9D.
>
> Will fix.
>
> ---
>
> >=C2=A0 =C2=A0 =E2=80=94 Section 3 =E2=80=94
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0The methods used and the access
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0provided by the token is based on local= policy
> >
> >=C2=A0 =C2=A0 =E2=80=9Care based=E2=80=9D, to match the plural sub= ject.
>
> Will fix.
>
> ---
>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Examples of such other
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanisms are introspection [RFC7662],= user profile lookups, etc
--0000000000004b0dbe05a3ce1308-- From nobody Tue Apr 21 10:36:51 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4010A3A084A; Tue, 21 Apr 2020 10:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, 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 xMVohrlCO1Tu; Tue, 21 Apr 2020 10:36:42 -0700 (PDT) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) (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 2A15E3A0841; Tue, 21 Apr 2020 10:36:28 -0700 (PDT) Received: by mail-io1-f65.google.com with SMTP id u11so15915499iow.4; Tue, 21 Apr 2020 10:36:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MlikvZLBYT6lFQLy8krSZhM2pKf9SgioeaH5T5+9Lkg=; b=LYtw0kTus8f9SJAP/SfHYenbhkMi3EhM3NF62wWOOH2iZ4ejf6d+PqJjSGtHoUoQja GLC6LG/+QOZJe95yXqqR31rColfo2gw5d7xDmceGBrP9nbct/L4w1ioTP+RLlWVLbN7X DwivoWbeMBQIK2+idCDk+ALMuh6mIERUVtii1Mw15nQtc0IKGk8kSSEA0aNgr7OQj1vW dkmb7yELlsbo8rZaHKSoxO5UbO11bv85dpc0ZQcaOyWgQ2a9nT9hp7Tic+pBIoD/mlXe FrlVhRV4NhP6wVGrmbbD+evF4sMqyQvjz/xTcs1XsKZXMk7lYWP6ukukFv6UP2qoEiZB 8poA== X-Gm-Message-State: AGi0PubXO3thyxC8l64xI/Me+MqTHz5pkpXM/UlmKjWBeOfhR/0WAj0C 5K1DVyWs7tOuRzQxyn4BtHuom8YwE7pLMjkLtgs= X-Google-Smtp-Source: APiQypIvuIxn/WTxET/RgOsLzByLGDHiqzQmwg1VtepfNodKLKuAEyBaoz6aOvOsga/kTE7ehVgXVSYE840lOnWvZ98= X-Received: by 2002:a02:b794:: with SMTP id f20mr21077836jam.118.1587490586629; Tue, 21 Apr 2020 10:36:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Tue, 21 Apr 2020 13:36:15 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - Barry's COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 17:36:46 -0000 > Just to make sure we are all on the same page, does the "All good here" include the answer to the DISCUSS? No; that's in a separate message, so I'll reply to that separately. Getting to that now. b From nobody Tue Apr 21 11:18:35 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33353A0968; Tue, 21 Apr 2020 11:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, 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 G7u-3ENRBNAe; Tue, 21 Apr 2020 11:18:30 -0700 (PDT) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) (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 834283A096E; Tue, 21 Apr 2020 11:18:05 -0700 (PDT) Received: by mail-il1-f196.google.com with SMTP id x2so12977941ilp.13; Tue, 21 Apr 2020 11:18:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlHG0xqQyRGFWKX8vGTJgB9OcvMDLqr+ggGzRiVx/qI=; b=Dpn/TApEb5cWflcGXzlU/opZbJ1oHfUY1E9PW3aqO3NHtup7nzoqAO6ifj7fqOHqgJ KZAZe1HQ3WDt1U/URGaE+o9ETZnwZlg3tajZHY0onpAyeUA6rejWMnxRw4CvhHgBfN5r b+X+R0Xq9VxCakaDDSxrAKocALEsJuzt3FXzrLev9wkbCA8Myw7ntYibFctRsacCLf20 t/ZTQBtpKGKV6NH2jBpuQQoCCHbL5iftCEyE5B1wdtKoi9cP0l8YnLkoKA9WnVADVYrY VPlW8rBDPZWUx8RLnYk6B6rlYGngq0VAnFDjvhj5ajU6PQP7kUgibhge56rsrhk13s3H +BhA== X-Gm-Message-State: AGi0PuZRsAuy2oesuKi+SBvvZia1yfMCosWbbE6lfZLKrLvheYjU/GVE NkhwDFLsQFSDL9w+T6w+tuZbMT/slWqjfOjOsH3Gur24an4= X-Google-Smtp-Source: APiQypLJ9PIYlZ9WJD/902PrDaASv8lbTcx0yHC+i+li3ZUwPIZqMYAqrSPtfKJt16zTGCRTx1XQ/k2ZkyZEYJA4mME= X-Received: by 2002:a92:200f:: with SMTP id j15mr23137588ile.266.1587493084054; Tue, 21 Apr 2020 11:18:04 -0700 (PDT) MIME-Version: 1.0 References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Tue, 21 Apr 2020 14:17:52 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 18:18:33 -0000 Thanks for the reply, Rifaat. We're on the right track, though there's more involved. We just have to figure out the best way to handle it, because this document doesn't have the full responsibility to lay out best practices for SSO. So let's see if we can come up with a reasonable compromise. Let me start by laying out, quickly, some of the issues with SSO: The biggest problems include: - privacy exposures: if I "login with Facebook" everywhere, Facebook gets a lot of information about what I do and where I log in, and users are generally not aware of that - exposure on many services if my SSO (Facebook or whatever) login is compromised: now that the SSO login is used in other places, that single point of compromise has a far broader effect -- you get to that in your first suggested paragraph - if my SSO login is compromised, an attacker can use it to create new SSOs on sites that I haven't even used, and sometimes they can switch my existing separate accounts to SSO, adding compromises that I didn't sign up for - inability to extricate myself from the situation: most sites don't make it easy to undo SSO once I've enabled it, and many don't allow it at all It's clearly well beyond the scope of this document to cover all that in any detail, but it might be worth a brief overview of the problems. Let me see if I can add a paragraph or two to what you've already suggested, to cover the other three issues. << Single Sign-On (SSO) enables the user to use one set of credentials to authenticate once and gain access to multiple SIP and non-SIP services using access token(s). If the SSO login is compromised, that single point of compromise has a much broader effect than is the case without SSO. Further, an attacker can often use a compromised account to set up Single Sign-On for other services that the victim has not established an account with, and sometimes can even switch a dedicated account into Single-Sign-On mode, creating a still broader attack. Because of that, it is critical to make sure that extra security measures be taken to safeguard credentials used for Single Sign-On. Examples of such measures include long passphrase instead of a password, enabling multi-factor factor authentication, and the use of embedded browser when possible, as defined in RFC8252. Although this is out of scope for this document, it is important to carefully consider the claims provided in the tokens used to access these services to make sure of the privacy of the user accessing these services. As mentioned above, this document calls for encrypting JWT representing the access token. It is important that both parties participating in SSO provide mechanisms for users to sever the SSO relationship, so that it is possible without undue difficulty to mitigate a compromise that has already happened. The operator of a Single-Sign-On authentication system has access to private information about sites and services that their users log into, and even, to some extent, about their usage patterns. It's important to call these out in privacy disclosures and policies, and to make sure that users can be aware of the tradeoffs between convenience and privacy when they choose to use SSO. >> Does that work? And then it would be good for us (the IETF community as a whole, not ICE) to figure out whether to write a BCP related to SSO security/privacy issues. Barry > Regarding the DISCUSS, how about adding the following text to the security considerations section: > > Single Sing-On enables the user to use one set of credentials to authenticate > once and gain access to multiple SIP and non-SIP services using access token(s). > Because of that, it is critical to make sure that extra security measures be > taken to guards these credentials. > > Examples of such measures include long passphrase instead of a password, enabling > multi-factor factor authentication, and the use of embedded browser when possible, > as defined in RFC8252. > > Although this is out of scope for this document, it is important to carefully > consider the claims provided in the tokens used to access these services to make > sure of the privacy of the user accessing these services. As mentioned above, > this document calls for encrypting JWT representing the access token. From nobody Tue Apr 21 12:25:51 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C953A0863; Tue, 21 Apr 2020 12:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qr3IZuHXX4k; Tue, 21 Apr 2020 12:25:42 -0700 (PDT) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 BF4163A085F; Tue, 21 Apr 2020 12:25:42 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id r2so7859295ilo.6; Tue, 21 Apr 2020 12:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T1QaxLTlaWYd4Gu0jeTK+1xDMLFCLP4bLHDH6QnSaPY=; b=V9+bI7SWUQjGt5TXkqjNOVj+eQJH/mVpRTQGq6PW/YpqauBPdif+Qa77UuR8EiAf81 uZfUA5NDzXH8q1LMDP1qxtAL42s7I89GKva+W0rJyI47hg6uqMiGJaDQDPeYl4Zztp/5 r7UvOpgiG6bteYl7GONZCnbm7mDo3nVsKrqMU14AyTEFhDvpmZMshD+WlHPWIn3pas8z WkneG1G+yisa2VHblqEHuj1PdrGYE9RAJA1dbiFfKxXm3JGCtx/CSzO6UKQUOPB+RAtz 9rJaZ/vw8XkdOVKd4ZatxNaT1lie+kvLLhxOz+wQ0MJN69su8SGuj3XgawxGiV5qRl3G cMGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T1QaxLTlaWYd4Gu0jeTK+1xDMLFCLP4bLHDH6QnSaPY=; b=O4tNv7gruyCte+NwQWSk2xrN7udMXl2m28eYJy52E9ZVGvbUOUG0jf3/2JA5ukq1Rk 7bKb5mv/YLFu2kE+az8yc02OBf8eChF2nWFoYL6BAf6Radome+R2JItBVvT0Z0s4KB4U m2AdqXg0phFbmb+qETvt7QDceVW59TEnaN77te4AT3nqs6ZqXqo9h9XKSR/mmYNGDmtC z8pYY9EoyFA4yARmHiPI8bgsSqdb8yl7+SPieKRALCi2eugBZCFovalhP2Ld3QkSSldk 3VR2fiNBniA8ftZTMK9jaOckj/LspKvf1LVuCcNSY48nhHnBHMpnWxDXSve8uLK7VFyu XqdQ== X-Gm-Message-State: AGi0PuadLYZFW69WA1gdsg+4Uk0uF9C90DyGCifVdxHm8OcZ9Q9CODWx pCKP9w7jdKg8J8K8V0YFGCEDj8z+7F42zOU+7Q0= X-Google-Smtp-Source: APiQypLkwlmqqy585dMn7CvkgFf2KrvYsqM77lNmBjXruUQm9SwDAL00/ORpzEvpHv/05+77Xi9Z7H4M2DX6VmtkOkk= X-Received: by 2002:a92:d3c5:: with SMTP id c5mr23075680ilh.73.1587497141536; Tue, 21 Apr 2020 12:25:41 -0700 (PDT) MIME-Version: 1.0 References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 21 Apr 2020 15:25:30 -0400 Message-ID: To: Barry Leiba Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="000000000000340e9c05a3d1fb2a" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 19:25:46 -0000 --000000000000340e9c05a3d1fb2a Content-Type: text/plain; charset="UTF-8" Thanks Barry! As you pointed out, this is way beyond the scope of this document and the SIPCore WG (not ICE), as I was trying to focus on things that this document controls. Having said that, I am fine with adding the updated text to the security consideration section if that addresses your concerns and clears the DISCUSS. I will add your proposed text to the next version of the draft. Regards, Rifaat On Tue, Apr 21, 2020 at 2:18 PM Barry Leiba wrote: > Thanks for the reply, Rifaat. We're on the right track, though > there's more involved. We just have to figure out the best way to > handle it, because this document doesn't have the full responsibility > to lay out best practices for SSO. So let's see if we can come up > with a reasonable compromise. > > Let me start by laying out, quickly, some of the issues with SSO: > > The biggest problems include: > - privacy exposures: if I "login with Facebook" everywhere, Facebook > gets a lot of information about what I do and where I log in, and > users are generally not aware of that > - exposure on many services if my SSO (Facebook or whatever) login is > compromised: now that the SSO login is used in other places, that > single point of compromise has a far broader effect -- you get to that > in your first suggested paragraph > - if my SSO login is compromised, an attacker can use it to create new > SSOs on sites that I haven't even used, and sometimes they can switch > my existing separate accounts to SSO, adding compromises that I didn't > sign up for > - inability to extricate myself from the situation: most sites don't > make it easy to undo SSO once I've enabled it, and many don't allow it > at all > > It's clearly well beyond the scope of this document to cover all that > in any detail, but it might be worth a brief overview of the problems. > Let me see if I can add a paragraph or two to what you've already > suggested, to cover the other three issues. > > << > Single Sign-On (SSO) enables the user to use one set of credentials to > authenticate once and gain access to multiple SIP and non-SIP services > using access token(s). If the SSO login is compromised, that single > point of compromise has a much broader effect than is the case without > SSO. Further, an attacker can often use a compromised account to set > up Single Sign-On for other services that the victim has not > established an account with, and sometimes can even switch a dedicated > account into Single-Sign-On mode, creating a still broader attack. > > Because of that, it is critical to make sure that extra security > measures be taken to safeguard credentials used for Single Sign-On. > Examples of such measures include long passphrase instead of a > password, enabling multi-factor factor authentication, and the use of > embedded browser when possible, as defined in RFC8252. > > Although this is out of scope for this document, it is important to > carefully consider the claims provided in the tokens used to access > these services to make sure of the privacy of the user accessing these > services. As mentioned above, this document calls for encrypting JWT > representing the access token. > > It is important that both parties participating in SSO provide > mechanisms for users to sever the SSO relationship, so that it is > possible without undue difficulty to mitigate a compromise that has > already happened. > > The operator of a Single-Sign-On authentication system has access to > private information about sites and services that their users log > into, and even, to some extent, about their usage patterns. It's > important to call these out in privacy disclosures and policies, and > to make sure that users can be aware of the tradeoffs between > convenience and privacy when they choose to use SSO. > >> > > Does that work? > > And then it would be good for us (the IETF community as a whole, not > ICE) to figure out whether to write a BCP related to SSO > security/privacy issues. > > Barry > > > Regarding the DISCUSS, how about adding the following text to the > security considerations section: > > > > Single Sing-On enables the user to use one set of credentials to > authenticate > > once and gain access to multiple SIP and non-SIP services using access > token(s). > > Because of that, it is critical to make sure that extra security > measures be > > taken to guards these credentials. > > > > Examples of such measures include long passphrase instead of a password, > enabling > > multi-factor factor authentication, and the use of embedded browser when > possible, > > as defined in RFC8252. > > > > Although this is out of scope for this document, it is important to > carefully > > consider the claims provided in the tokens used to access these services > to make > > sure of the privacy of the user accessing these services. As mentioned > above, > > this document calls for encrypting JWT representing the access token. > --000000000000340e9c05a3d1fb2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Barry!

As you p= ointed out, this is way beyond the scope of this document and the SIPCore W= G (not ICE), as I was trying to focus on things that this document controls= .
Having said that, I am fine with adding the updated text to the= security consideration section if that addresses your concerns and clears = the DISCUSS.

I will add your=C2=A0proposed text to= the next version of the draft.
Regards,
=C2=A0Rifaat


On Tue, Apr 21, 2020 at 2:18 PM Barry Leiba <barryleiba@computer.org> wrote:<= br>
Thanks for the r= eply, Rifaat.=C2=A0 We're on the right track, though
there's more involved.=C2=A0 We just have to figure out the best way to=
handle it, because this document doesn't have the full responsibility to lay out best practices for SSO.=C2=A0 So let's see if we can come up=
with a reasonable compromise.

Let me start by laying out, quickly, some of the issues with SSO:

The biggest problems include:
- privacy exposures: if I "login with Facebook" everywhere, Faceb= ook
gets a lot of information about what I do and where I log in, and
users are generally not aware of that
- exposure on many services if my SSO (Facebook or whatever) login is
compromised: now that the SSO login is used in other places, that
single point of compromise has a far broader effect -- you get to that
in your first suggested paragraph
- if my SSO login is compromised, an attacker can use it to create new
SSOs on sites that I haven't even used, and sometimes they can switch my existing separate accounts to SSO, adding compromises that I didn't<= br> sign up for
- inability to extricate myself from the situation: most sites don't make it easy to undo SSO once I've enabled it, and many don't allow= it
at all

It's clearly well beyond the scope of this document to cover all that in any detail, but it might be worth a brief overview of the problems.
Let me see if I can add a paragraph or two to what you've already
suggested, to cover the other three issues.

<<
Single Sign-On (SSO) enables the user to use one set of credentials to
authenticate once and gain access to multiple SIP and non-SIP services
using access token(s). If the SSO login is compromised, that single
point of compromise has a much broader effect than is the case without
SSO.=C2=A0 Further, an attacker can often use a compromised account to set<= br> up Single Sign-On for other services that the victim has not
established an account with, and sometimes can even switch a dedicated
account into Single-Sign-On mode, creating a still broader attack.

Because of that, it is critical to make sure that extra security
measures be taken to safeguard credentials used for Single Sign-On.
Examples of such measures include long passphrase instead of a
password, enabling multi-factor factor authentication, and the use of
embedded browser when possible, as defined in RFC8252.

Although this is out of scope for this document, it is important to
carefully consider the claims provided in the tokens used to access
these services to make sure of the privacy of the user accessing these
services. As mentioned above, this document calls for encrypting JWT
representing the access token.

It is important that both parties participating in SSO provide
mechanisms for users to sever the SSO relationship, so that it is
possible without undue difficulty to mitigate a compromise that has
already happened.

The operator of a Single-Sign-On authentication system has access to
private information about sites and services that their users log
into, and even, to some extent, about their usage patterns.=C2=A0 It's<= br> important to call these out in privacy disclosures and policies, and
to make sure that users can be aware of the tradeoffs between
convenience and privacy when they choose to use SSO.
>>

Does that work?

And then it would be good for us (the IETF community as a whole, not
ICE) to figure out whether to write a BCP related to SSO
security/privacy issues.

Barry

> Regarding the DISCUSS, how about adding the following text to the secu= rity considerations section:
>
> Single Sing-On enables the user to use one set of credentials to authe= nticate
> once and gain access to multiple SIP and non-SIP services using access= token(s).
> Because of that, it is critical to make sure that extra security measu= res be
> taken to guards these credentials.
>
> Examples of such measures include long passphrase instead of a passwor= d, enabling
> multi-factor factor authentication, and the use of embedded browser wh= en possible,
> as defined in RFC8252.
>
> Although this is out of scope for this document, it is important to ca= refully
> consider the claims provided in the tokens used to access these servic= es to make
> sure of the privacy of the user accessing these services. As mentioned= above,
> this document calls for encrypting JWT representing the access token.<= br>
--000000000000340e9c05a3d1fb2a-- From nobody Tue Apr 21 12:53:59 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0CA3A0900; Tue, 21 Apr 2020 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, 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 5jOIeVUrRHhL; Tue, 21 Apr 2020 12:53:55 -0700 (PDT) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) (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 099BD3A08FD; Tue, 21 Apr 2020 12:53:55 -0700 (PDT) Received: by mail-il1-f195.google.com with SMTP id u189so9969737ilc.4; Tue, 21 Apr 2020 12:53:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FJb2v1y3BO+2K9hmQNk6vRl6HZn9Bx6sHt7JEVxHyq0=; b=YVPIx+tXvlOFK0zhPv7AUYKB8Eu7QRIHljYU1FaQB/UudSPI38q5oU5EWg9c1zYSjF pLMRer0I1u4xQ/xBpdcNdw+J4pD7h5NGb2PzYOObHWnt5Tzm+0aPlpg5W+31iA2wGAc0 5JvIRWQtjIhqW9c//U0WEm6PBA80UWg7opP6e4HhHgjBZMWAH1IxUJqYmqI0sKSus63l Gsc2OgbfjFN2qD3qlSjMM7MU72UjIuoOfAqd5gyR0L876fTKXaaOEktRgQFOtQ03Pb4j iWzm1qDlVMs9SyPu3s6tJxZ5OEnMwqFmgBrfRMZqCH7HH9dQvQ20Ur5xkOfzGZqZp6H4 AhYQ== X-Gm-Message-State: AGi0PuYkHM5laeLhMjHd3mjRXLmXQBfuJ6oQzfJ02toTdlZDl7KHSiLi hURJBXlh73HMZeTz/UDkQQuccjfBvb98NsvddCs= X-Google-Smtp-Source: APiQypIGqFR2hJ0g02mDG1PYNw+4J8h4e09dGW9uU6wbZoO2vVokQxR5oNRixHjSj61xHewDP22JXGxLWpZX4C+Xhgs= X-Received: by 2002:a92:200f:: with SMTP id j15mr23548455ile.266.1587498833694; Tue, 21 Apr 2020 12:53:53 -0700 (PDT) MIME-Version: 1.0 References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Tue, 21 Apr 2020 15:53:42 -0400 Message-ID: To: Rifaat Shekh-Yusef Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 19:53:57 -0000 > As you pointed out, this is way beyond the scope of this document and the SIPCore WG (not ICE), Urk... I had also just reviewed an ICE document. This is all so confusing! :-) > Having said that, I am fine with adding the updated text to the security consideration section > if that addresses your concerns and clears the DISCUSS. To be clear: we've had the discussion, so the DISCUSS will be cleared in any case. I do think it's important for this document to put a stake in the ground with respect to SSO issues, so I'd like to see the suggested text in the document, and I appreciate your willingness to put it in. Thanks! At the same time, I do not want to do it over the objections of the working group, if that should be the case -- this isn't just a "make the AD happy" thing. Thanks for discussing this with me, and I will go clear my DISCUSS now. Barry From nobody Tue Apr 21 12:59:37 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9E3A0903; Tue, 21 Apr 2020 12:59:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158749916926.1517.10875046772249161125@ietfa.amsl.com> Date: Tue, 21 Apr 2020 12:59:29 -0700 Archived-At: Subject: [sipcore] Barry Leiba's No Objection on draft-ietf-sipcore-sip-token-authnz-13: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 19:59:30 -0000 Barry Leiba has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. Enabling Open-ID and OAUTH with SIP is quite useful. This document specifically calls out single sign-on as a reason to use this mechanism, and SSO has a host of serious security and privacy issues. As those issues are not discussed in the referenced documents, I think they need to be raised here. Recommended usage/configuration to avoid or mitigate the issues would be ideal, but at the very least I think they need to be documented, as it’s clear that implementors are not aware of them or don’t think they’re important enough to worry about. Rifaat and I have discussed the above comment and have come up with some text for the Security Considerations that calls out some of the issues, briefly. Something with more scope than that -- perhaps a BCP about security/privacy concerns with respect to SSO -- is in order, but, clearly, that's way out of scope for this document. Other, editorial points. — Section 1.1 — Please copy the BCP 14 boilerplate exactly from RFC 8174. — Section 1.3 — Refresh Tokens usualy are represented in a reference format Typo: “usually”. — Section 3 — The methods used and the access provided by the token is based on local policy “are based”, to match the plural subject. Examples of such other mechanisms are introspection [RFC7662], user profile lookups, etc. “Examples” and “etc.” are mutually redundant. I would remove the latter and replace the comma before “user profile lookups” with “and”. — Section 6 — This can’t be empty. It should say that there are no IANA actions needed for this document. From nobody Tue Apr 21 13:03:45 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9073A0914; Tue, 21 Apr 2020 13:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K71fEFHzkLXj; Tue, 21 Apr 2020 13:03:39 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 868893A0911; Tue, 21 Apr 2020 13:03:39 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id w20so16376249iob.2; Tue, 21 Apr 2020 13:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IOlwcmy2YcFdFuMEBx5H44HaMsR5vCWWER+4/A4SbMY=; b=Rdce/RmiPUUSLm843Y0tXQ0zbONHSQSAXTqrye2LPbwz0kYXwpJz5p9thkC3Jn5ycE GccS6j0nk2Hz+tsDS7V9YKDarFuuUEUQMdRymt19AoPro6NoTCY6BVi6TrLkN0vtE0yR Bx+YtK6vAlRmO9+gdVwUuKK4WiYGMZNNEbVY3EA2VC2peOgkOYvms4nYZkpERHlW8EBn a/mtG5kmNJxyo/hnNK2B119sHtO/RChDFMosqNkjToPhWXXH9Pje+BPGsqaWLkkvtcU6 T3QKZwiJFXV0qaeFRXAp0fhJf/mr6AJ6cCXZNkcmzqKcTqwCIM3AwvJlz84r0kHz3fpL 25Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IOlwcmy2YcFdFuMEBx5H44HaMsR5vCWWER+4/A4SbMY=; b=U1ZvdaT7d/AMVdN7DTU4AOH/3iczpwAGx/sWMlGdD/ce8U3RAfYVMZ/kWxnqUR8JxV 9hp10My40hUE9QuuyiDTyCj1Y3nvAaZR98e8C83Ye1nbeYYWTM6PDnKNCvMnD4vpKKJO aj/eMbH0EqqdaeN93GWbykhJiwu8N/m48QpzU1joa2ysMsg9t9Vtm/rDyU8alL3+QIIS N6aqGMio7AQuQ8jWT6ft9XKZ2Oe71Cl0kTGPUGDsS6qVn0IGotnVMbAxyFTShPY7UrVq XE5gRY/M9G09Iq04xhmQlKfFK9r/Mq71mAB70H5VXPGCgH+xDog/CljTlRE+DQdUQvNC Zk1Q== X-Gm-Message-State: AGi0PuaakqdmXmV2Q0hPZ9dSb6sKkEL0PGKXXi1OzlsBqzOyqOTUQaxz 9655kOdL29exzslHTYtvz7RHPtflteMMaxpnMco= X-Google-Smtp-Source: APiQypIH8xYDtrATZS2sPWZFz7/8i5BdFFpcaNHOl+ClMkc1bqUrqyidlRMldbNWxRC4SPkFIYUPcR9kNifdwSIIHIQ= X-Received: by 2002:a02:aa93:: with SMTP id u19mr22179354jai.70.1587499417621; Tue, 21 Apr 2020 13:03:37 -0700 (PDT) MIME-Version: 1.0 References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 21 Apr 2020 16:03:26 -0400 Message-ID: To: Barry Leiba Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="000000000000de584105a3d282ca" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 20:03:43 -0000 --000000000000de584105a3d282ca Content-Type: text/plain; charset="UTF-8" Hi Barry, Sorry if I came across as just trying to clear the DISCUSS. I think the suggested text is useful as a general advise and reminder, but as you know this is not something that this document controls. In any case, I am happy to add it to the security consideration section and hope that this will remind people to think and consider these issues. Regards, Rifaat On Tue, Apr 21, 2020 at 3:53 PM Barry Leiba wrote: > > As you pointed out, this is way beyond the scope of this document and > the SIPCore WG (not ICE), > > Urk... I had also just reviewed an ICE document. This is all so > confusing! :-) > > > Having said that, I am fine with adding the updated text to the security > consideration section > > if that addresses your concerns and clears the DISCUSS. > > To be clear: we've had the discussion, so the DISCUSS will be cleared > in any case. I do think it's important for this document to put a > stake in the ground with respect to SSO issues, so I'd like to see the > suggested text in the document, and I appreciate your willingness to > put it in. Thanks! At the same time, I do not want to do it over the > objections of the working group, if that should be the case -- this > isn't just a "make the AD happy" thing. > > Thanks for discussing this with me, and I will go clear my DISCUSS now. > > Barry > --000000000000de584105a3d282ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Barry,

Sorry if I came across=C2=A0a= s just trying to clear the DISCUSS.
I think the suggested text is= useful as a general advise=C2=A0and reminder, but as you know=C2=A0this is= not something that this document controls.

In any= case, I am happy to add it to the security consideration section and hope = that this will remind=C2=A0people to think and consider these issues.
=

Regards,
=C2=A0Rifaat



On Tue, Apr 21, 2020 at 3:53 PM Barry Leiba <barryleiba@computer.org&g= t; wrote:
> A= s you pointed out, this is way beyond the scope of this document and the SI= PCore WG (not ICE),

Urk... I had also just reviewed an ICE document.=C2=A0 This is all so confu= sing!=C2=A0 :-)

> Having said that, I am fine with adding the updated text to the securi= ty consideration section
> if that addresses your concerns and clears the DISCUSS.

To be clear: we've had the discussion, so the DISCUSS will be cleared in any case.=C2=A0 I do think it's important for this document to put a=
stake in the ground with respect to SSO issues, so I'd like to see the<= br> suggested text in the document, and I appreciate your willingness to
put it in.=C2=A0 Thanks!=C2=A0 At the same time, I do not want to do it ove= r the
objections of the working group, if that should be the case -- this
isn't just a "make the AD happy" thing.

Thanks for discussing this with me, and I will go clear my DISCUSS now.

Barry
--000000000000de584105a3d282ca-- From nobody Tue Apr 21 14:39:44 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088A13A0AE8; Tue, 21 Apr 2020 14:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zMhz4iWi1HqQ; Tue, 21 Apr 2020 14:39:32 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2076.outbound.protection.outlook.com [40.107.22.76]) (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 28E093A0B26; Tue, 21 Apr 2020 14:39:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O9CGIbYCXXLyiU9TI8MbCpSJa+aE4AjkmqfV/rGvBlzuz7rKGSXzPaGQmyCfzUafiC4fcUozo3/+84WyH+QSQaoidX9hRYemqeHC2b2QWewDU9AyhnPxUSFjpx0sLWKb+CHokCy4vcR7kkUi5RsU0YA9+SvzZ0M8rbNLvdd+B4AdbA2d4pRhwBPXpXPgz5vpP8RgTERqSz+p5OtqUI6zkIm833Y1Db94OjORn8HA1tLvCPm5ZTEtxdmZZNrCfwSDY4aOIJq++T+jp21EGGVtvMiUVqF6Q/KG3l5TRY5vxZUmJV0BYl+erstC2VCyVhh/nzU7UeoJ/aGB+JoydX8/Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LjbvQZhCH3qjyYG93O8vMDnfHBP7w/D9guqiNbkvAik=; b=fqt5g9eWW5Mz94CidAK7dFplB2iX3Z9lI9Aqnj4M+7mA9l7dVIIzjATyfhiU9eX9L6S17200DAn8fez7fGk3JFfrgxymgDPhe9QsfEVdv5lyBilGWxfu6BRSRaf0K0Hf6meicdI5gginqn8YMlzZVLkFqvwnBB8CSwQI7psN+e03aQO+de9ImMLqzj2b9LhJmS0IfGYFzI3hAZQqXFFqaT6tdJcP0bFj6A6+imdCPXTcnP+L2E+srsc94SGTH7p9XYdOVW/CP26wHiCjnDl6G2v5rovIkle0pUemod6q3txS5E78Ik6wHknRBs/3RU2G5PVbRL3XCL8DKjtKF8eF6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LjbvQZhCH3qjyYG93O8vMDnfHBP7w/D9guqiNbkvAik=; b=g9uzs75M1bcI0O4JNtLzAinDTtJb5DhsKKW+q/BCITxjUZ68Fq1WHBvff/QXTe+qEB1ZiJAwZeiXaQqR80ZrgS/oW5l0eccWrYwTqSBIFsRDtwSNJd4DALN0wGAETLWqyp/7BHWUSm6u354iZPSHUF8ZMnQrdFWmBQNfp2l2fT0= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB4628.eurprd07.prod.outlook.com (2603:10a6:208:76::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Tue, 21 Apr 2020 21:39:29 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.012; Tue, 21 Apr 2020 21:39:29 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Barry Leiba CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , SIPCORE , The IESG , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) Thread-Index: AQHWF6Cz+WlBMDlRJECoP3jg2Sy266iDZywAgAB76QCAABLmAIAAV7qA Date: Tue, 21 Apr 2020 21:39:29 +0000 Message-ID: References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e004ec54-5f59-4b43-75ce-08d7e63c78e1 x-ms-traffictypediagnostic: AM0PR07MB4628: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 038002787A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(66946007)(53546011)(6512007)(54906003)(76116006)(91956017)(110136005)(66556008)(26005)(81156014)(5660300002)(36756003)(71200400001)(2906002)(8676002)(66574012)(8936002)(66476007)(186003)(498600001)(6506007)(86362001)(966005)(33656002)(44832011)(2616005)(6486002)(4326008)(66446008)(64756008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NVbayJ+Kcx5ZzGHRW+nNJ52qZ24O98LEvsYxb8R2iL7y/xTETE4Kcm4molnktjOXxN6KlMAK/GZsUf87zjeNr+YtH5OzKLq9tQSbffJcCzo+bs82JCwCPVy1Z6yTZsFuWOAgxwfsePdLHKMbksxXeemIg6VB0dER98Ja/ojmM50UumwcAPqN0o2bJJYs2szBtEyZhPytAtV63vWj/nkcwKd1T/8XJuO4Z8RtzWFH4lVsLhVu8IGlMxwQpXBEOFb4qWGAM7q3Ij/TFD2TS+9Mxr/fVYmR2BcXRikJldWE6YXSYSMF1sPW80jQ5Whjs08QOJ25riSA82OOsrg13V2p/wiCo/6189fYw7zvOB0JGECYV+QXl5opzoaHjbf2onbVZfFkvMtxNilTCgVmiE+1yVxV1dDwVCx9piYBWej3SjoZlNBkjrpxvOrn5aeLluuJryg+0KyfqDKzVfCKO37+c/NuIYaS8Rd5yBxeGllf1WysrLrj01VhdOLLwe3VzsTFHdn/LxL3dBWggEMJ9UBEtw== x-ms-exchange-antispam-messagedata: 3DFqsoA1L7oWir8/RFwbtd/orD8kyX+p4o+nAZd1Ij14/9yDTtO7KDZnQQgUQF0x1Rxyhox2NzRDxr+TJ29AJO1aYCrROK3JCuSNvmKmKTZwCoRxD95HhaugKXNaIlW3J9jmJEr4oo3BWM1vGTeazw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C8B9BFC326784E3BB6D84CEDA4976D15ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e004ec54-5f59-4b43-75ce-08d7e63c78e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 21:39:29.6082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Srx3rXJJOUWrEbK8AFsGUuHO7xm4gd57lKaS7NeMet3vRmDv81P6l+kGuDn1yP/j4+fwXfbumfUMwqr5Ltk12qNw7je4eQ2/lB1ey3K+KAg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4628 Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 21:39:36 -0000 --_000_C8B9BFC326784E3BB6D84CEDA4976D15ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJlbG93IGlzIGEgbGluayB0byBhIHB1bGwgcmVxdWVzdCB3aXRoIHRoZSBTU08gdGV4 dCBmb3IgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLg0KDQpodHRwczovL2dpdGh1Yi5jb20v cmlmYWF0LWlldGYvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnovcHVsbC83DQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21h aWwuY29tPg0KRGF0ZTogVHVlc2RheSwgMjEgQXByaWwgMjAyMCBhdCAyMi4yNg0KVG86IEJhcnJ5 IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4NCkNjOiAiZHJhZnQtaWV0Zi1zaXBjb3Jl LXNpcC10b2tlbi1hdXRobnpAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2Vu LWF1dGhuekBpZXRmLm9yZz4sICJzaXBjb3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4s ICJpZXNnQGlldGYub3JnIiA8aWVzZ0BpZXRmLm9yZz4sICJzaXBjb3JlLWNoYWlyc0BpZXRmLm9y ZyIgPHNpcGNvcmUtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBCYXJy eSBMZWliYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnot MTM6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNClRoYW5rcyBCYXJyeSENCg0KQXMgeW91 IHBvaW50ZWQgb3V0LCB0aGlzIGlzIHdheSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQgYW5kIHRoZSBTSVBDb3JlIFdHIChub3QgSUNFKSwgYXMgSSB3YXMgdHJ5aW5nIHRvIGZvY3Vz IG9uIHRoaW5ncyB0aGF0IHRoaXMgZG9jdW1lbnQgY29udHJvbHMuLg0KSGF2aW5nIHNhaWQgdGhh dCwgSSBhbSBmaW5lIHdpdGggYWRkaW5nIHRoZSB1cGRhdGVkIHRleHQgdG8gdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBpZiB0aGF0IGFkZHJlc3NlcyB5b3VyIGNvbmNlcm5zIGFu ZCBjbGVhcnMgdGhlIERJU0NVU1MuDQoNCkkgd2lsbCBhZGQgeW91ciBwcm9wb3NlZCB0ZXh0IHRv IHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KUmVnYXJkcywNCiBSaWZhYXQNCg0KDQpP biBUdWUsIEFwciAyMSwgMjAyMCBhdCAyOjE4IFBNIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNv bXB1dGVyLm9yZzxtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+PiB3cm90ZToNClRoYW5r cyBmb3IgdGhlIHJlcGx5LCBSaWZhYXQuICBXZSdyZSBvbiB0aGUgcmlnaHQgdHJhY2ssIHRob3Vn aA0KdGhlcmUncyBtb3JlIGludm9sdmVkLiAgV2UganVzdCBoYXZlIHRvIGZpZ3VyZSBvdXQgdGhl IGJlc3Qgd2F5IHRvDQpoYW5kbGUgaXQsIGJlY2F1c2UgdGhpcyBkb2N1bWVudCBkb2Vzbid0IGhh dmUgdGhlIGZ1bGwgcmVzcG9uc2liaWxpdHkNCnRvIGxheSBvdXQgYmVzdCBwcmFjdGljZXMgZm9y IFNTTy4gIFNvIGxldCdzIHNlZSBpZiB3ZSBjYW4gY29tZSB1cA0Kd2l0aCBhIHJlYXNvbmFibGUg Y29tcHJvbWlzZS4NCg0KTGV0IG1lIHN0YXJ0IGJ5IGxheWluZyBvdXQsIHF1aWNrbHksIHNvbWUg b2YgdGhlIGlzc3VlcyB3aXRoIFNTTzoNCg0KVGhlIGJpZ2dlc3QgcHJvYmxlbXMgaW5jbHVkZToN Ci0gcHJpdmFjeSBleHBvc3VyZXM6IGlmIEkgImxvZ2luIHdpdGggRmFjZWJvb2siIGV2ZXJ5d2hl cmUsIEZhY2Vib29rDQpnZXRzIGEgbG90IG9mIGluZm9ybWF0aW9uIGFib3V0IHdoYXQgSSBkbyBh bmQgd2hlcmUgSSBsb2cgaW4sIGFuZA0KdXNlcnMgYXJlIGdlbmVyYWxseSBub3QgYXdhcmUgb2Yg dGhhdA0KLSBleHBvc3VyZSBvbiBtYW55IHNlcnZpY2VzIGlmIG15IFNTTyAoRmFjZWJvb2sgb3Ig d2hhdGV2ZXIpIGxvZ2luIGlzDQpjb21wcm9taXNlZDogbm93IHRoYXQgdGhlIFNTTyBsb2dpbiBp cyB1c2VkIGluIG90aGVyIHBsYWNlcywgdGhhdA0Kc2luZ2xlIHBvaW50IG9mIGNvbXByb21pc2Ug aGFzIGEgZmFyIGJyb2FkZXIgZWZmZWN0IC0tIHlvdSBnZXQgdG8gdGhhdA0KaW4geW91ciBmaXJz dCBzdWdnZXN0ZWQgcGFyYWdyYXBoDQotIGlmIG15IFNTTyBsb2dpbiBpcyBjb21wcm9taXNlZCwg YW4gYXR0YWNrZXIgY2FuIHVzZSBpdCB0byBjcmVhdGUgbmV3DQpTU09zIG9uIHNpdGVzIHRoYXQg SSBoYXZlbid0IGV2ZW4gdXNlZCwgYW5kIHNvbWV0aW1lcyB0aGV5IGNhbiBzd2l0Y2gNCm15IGV4 aXN0aW5nIHNlcGFyYXRlIGFjY291bnRzIHRvIFNTTywgYWRkaW5nIGNvbXByb21pc2VzIHRoYXQg SSBkaWRuJ3QNCnNpZ24gdXAgZm9yDQotIGluYWJpbGl0eSB0byBleHRyaWNhdGUgbXlzZWxmIGZy b20gdGhlIHNpdHVhdGlvbjogbW9zdCBzaXRlcyBkb24ndA0KbWFrZSBpdCBlYXN5IHRvIHVuZG8g U1NPIG9uY2UgSSd2ZSBlbmFibGVkIGl0LCBhbmQgbWFueSBkb24ndCBhbGxvdyBpdA0KYXQgYWxs DQoNCkl0J3MgY2xlYXJseSB3ZWxsIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCB0 byBjb3ZlciBhbGwgdGhhdA0KaW4gYW55IGRldGFpbCwgYnV0IGl0IG1pZ2h0IGJlIHdvcnRoIGEg YnJpZWYgb3ZlcnZpZXcgb2YgdGhlIHByb2JsZW1zLg0KTGV0IG1lIHNlZSBpZiBJIGNhbiBhZGQg YSBwYXJhZ3JhcGggb3IgdHdvIHRvIHdoYXQgeW91J3ZlIGFscmVhZHkNCnN1Z2dlc3RlZCwgdG8g Y292ZXIgdGhlIG90aGVyIHRocmVlIGlzc3Vlcy4NCg0KPDwNClNpbmdsZSBTaWduLU9uIChTU08p IGVuYWJsZXMgdGhlIHVzZXIgdG8gdXNlIG9uZSBzZXQgb2YgY3JlZGVudGlhbHMgdG8NCmF1dGhl bnRpY2F0ZSBvbmNlIGFuZCBnYWluIGFjY2VzcyB0byBtdWx0aXBsZSBTSVAgYW5kIG5vbi1TSVAg c2VydmljZXMNCnVzaW5nIGFjY2VzcyB0b2tlbihzKS4gSWYgdGhlIFNTTyBsb2dpbiBpcyBjb21w cm9taXNlZCwgdGhhdCBzaW5nbGUNCnBvaW50IG9mIGNvbXByb21pc2UgaGFzIGEgbXVjaCBicm9h ZGVyIGVmZmVjdCB0aGFuIGlzIHRoZSBjYXNlIHdpdGhvdXQNClNTTy4gIEZ1cnRoZXIsIGFuIGF0 dGFja2VyIGNhbiBvZnRlbiB1c2UgYSBjb21wcm9taXNlZCBhY2NvdW50IHRvIHNldA0KdXAgU2lu Z2xlIFNpZ24tT24gZm9yIG90aGVyIHNlcnZpY2VzIHRoYXQgdGhlIHZpY3RpbSBoYXMgbm90DQpl c3RhYmxpc2hlZCBhbiBhY2NvdW50IHdpdGgsIGFuZCBzb21ldGltZXMgY2FuIGV2ZW4gc3dpdGNo IGEgZGVkaWNhdGVkDQphY2NvdW50IGludG8gU2luZ2xlLVNpZ24tT24gbW9kZSwgY3JlYXRpbmcg YSBzdGlsbCBicm9hZGVyIGF0dGFjay4NCg0KQmVjYXVzZSBvZiB0aGF0LCBpdCBpcyBjcml0aWNh bCB0byBtYWtlIHN1cmUgdGhhdCBleHRyYSBzZWN1cml0eQ0KbWVhc3VyZXMgYmUgdGFrZW4gdG8g c2FmZWd1YXJkIGNyZWRlbnRpYWxzIHVzZWQgZm9yIFNpbmdsZSBTaWduLU9uLg0KRXhhbXBsZXMg b2Ygc3VjaCBtZWFzdXJlcyBpbmNsdWRlIGxvbmcgcGFzc3BocmFzZSBpbnN0ZWFkIG9mIGENCnBh c3N3b3JkLCBlbmFibGluZyBtdWx0aS1mYWN0b3IgZmFjdG9yIGF1dGhlbnRpY2F0aW9uLCBhbmQg dGhlIHVzZSBvZg0KZW1iZWRkZWQgYnJvd3NlciB3aGVuIHBvc3NpYmxlLCBhcyBkZWZpbmVkIGlu IFJGQzgyNTIuDQoNCkFsdGhvdWdoIHRoaXMgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3Vt ZW50LCBpdCBpcyBpbXBvcnRhbnQgdG8NCmNhcmVmdWxseSBjb25zaWRlciB0aGUgY2xhaW1zIHBy b3ZpZGVkIGluIHRoZSB0b2tlbnMgdXNlZCB0byBhY2Nlc3MNCnRoZXNlIHNlcnZpY2VzIHRvIG1h a2Ugc3VyZSBvZiB0aGUgcHJpdmFjeSBvZiB0aGUgdXNlciBhY2Nlc3NpbmcgdGhlc2UNCnNlcnZp Y2VzLiBBcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1lbnQgY2FsbHMgZm9yIGVuY3J5cHRp bmcgSldUDQpyZXByZXNlbnRpbmcgdGhlIGFjY2VzcyB0b2tlbi4NCg0KSXQgaXMgaW1wb3J0YW50 IHRoYXQgYm90aCBwYXJ0aWVzIHBhcnRpY2lwYXRpbmcgaW4gU1NPIHByb3ZpZGUNCm1lY2hhbmlz bXMgZm9yIHVzZXJzIHRvIHNldmVyIHRoZSBTU08gcmVsYXRpb25zaGlwLCBzbyB0aGF0IGl0IGlz DQpwb3NzaWJsZSB3aXRob3V0IHVuZHVlIGRpZmZpY3VsdHkgdG8gbWl0aWdhdGUgYSBjb21wcm9t aXNlIHRoYXQgaGFzDQphbHJlYWR5IGhhcHBlbmVkLg0KDQpUaGUgb3BlcmF0b3Igb2YgYSBTaW5n bGUtU2lnbi1PbiBhdXRoZW50aWNhdGlvbiBzeXN0ZW0gaGFzIGFjY2VzcyB0bw0KcHJpdmF0ZSBp bmZvcm1hdGlvbiBhYm91dCBzaXRlcyBhbmQgc2VydmljZXMgdGhhdCB0aGVpciB1c2VycyBsb2cN CmludG8sIGFuZCBldmVuLCB0byBzb21lIGV4dGVudCwgYWJvdXQgdGhlaXIgdXNhZ2UgcGF0dGVy bnMuICBJdCdzDQppbXBvcnRhbnQgdG8gY2FsbCB0aGVzZSBvdXQgaW4gcHJpdmFjeSBkaXNjbG9z dXJlcyBhbmQgcG9saWNpZXMsIGFuZA0KdG8gbWFrZSBzdXJlIHRoYXQgdXNlcnMgY2FuIGJlIGF3 YXJlIG9mIHRoZSB0cmFkZW9mZnMgYmV0d2Vlbg0KY29udmVuaWVuY2UgYW5kIHByaXZhY3kgd2hl biB0aGV5IGNob29zZSB0byB1c2UgU1NPLg0KPj4NCg0KRG9lcyB0aGF0IHdvcms/DQoNCkFuZCB0 aGVuIGl0IHdvdWxkIGJlIGdvb2QgZm9yIHVzICh0aGUgSUVURiBjb21tdW5pdHkgYXMgYSB3aG9s ZSwgbm90DQpJQ0UpIHRvIGZpZ3VyZSBvdXQgd2hldGhlciB0byB3cml0ZSBhIEJDUCByZWxhdGVk IHRvIFNTTw0Kc2VjdXJpdHkvcHJpdmFjeSBpc3N1ZXMuDQoNCkJhcnJ5DQoNCj4gUmVnYXJkaW5n IHRoZSBESVNDVVNTLCBob3cgYWJvdXQgYWRkaW5nIHRoZSBmb2xsb3dpbmcgdGV4dCB0byB0aGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbjoNCj4NCj4gU2luZ2xlIFNpbmctT24gZW5h YmxlcyB0aGUgdXNlciB0byB1c2Ugb25lIHNldCBvZiBjcmVkZW50aWFscyB0byBhdXRoZW50aWNh dGUNCj4gb25jZSBhbmQgZ2FpbiBhY2Nlc3MgdG8gbXVsdGlwbGUgU0lQIGFuZCBub24tU0lQIHNl cnZpY2VzIHVzaW5nIGFjY2VzcyB0b2tlbihzKS4NCj4gQmVjYXVzZSBvZiB0aGF0LCBpdCBpcyBj cml0aWNhbCB0byBtYWtlIHN1cmUgdGhhdCBleHRyYSBzZWN1cml0eSBtZWFzdXJlcyBiZQ0KPiB0 YWtlbiB0byBndWFyZHMgdGhlc2UgY3JlZGVudGlhbHMuDQo+DQo+IEV4YW1wbGVzIG9mIHN1Y2gg bWVhc3VyZXMgaW5jbHVkZSBsb25nIHBhc3NwaHJhc2UgaW5zdGVhZCBvZiBhIHBhc3N3b3JkLCBl bmFibGluZw0KPiBtdWx0aS1mYWN0b3IgZmFjdG9yIGF1dGhlbnRpY2F0aW9uLCBhbmQgdGhlIHVz ZSBvZiBlbWJlZGRlZCBicm93c2VyIHdoZW4gcG9zc2libGUsDQo+IGFzIGRlZmluZWQgaW4gUkZD ODI1Mi4NCj4NCj4gQWx0aG91Z2ggdGhpcyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1l bnQsIGl0IGlzIGltcG9ydGFudCB0byBjYXJlZnVsbHkNCj4gY29uc2lkZXIgdGhlIGNsYWltcyBw cm92aWRlZCBpbiB0aGUgdG9rZW5zIHVzZWQgdG8gYWNjZXNzIHRoZXNlIHNlcnZpY2VzIHRvIG1h a2UNCj4gc3VyZSBvZiB0aGUgcHJpdmFjeSBvZiB0aGUgdXNlciBhY2Nlc3NpbmcgdGhlc2Ugc2Vy dmljZXMuIEFzIG1lbnRpb25lZCBhYm92ZSwNCj4gdGhpcyBkb2N1bWVudCBjYWxscyBmb3IgZW5j cnlwdGluZyBKV1QgcmVwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uDQo= --_000_C8B9BFC326784E3BB6D84CEDA4976D15ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5EEE94BE3D7032478CC09C9D64A7B120@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVsb3cgaXMgYSBsaW5rIHRvIGEgcHVsbCByZXF1ZXN0IHdp dGggdGhlIFNTTyB0ZXh0IGZvciB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Jp ZmFhdC1pZXRmL2RyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56L3B1bGwvNyI+PHNw YW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS9yaWZhYXQtaWV0Zi9kcmFmdC1pZXRm LXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei9wdWxsLzc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNpcGNvcmUgJmx0O3NpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0Lmll dGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCAyMSBBcHJpbCAyMDIw IGF0IDIyLjI2PGJyPg0KPGI+VG86IDwvYj5CYXJyeSBMZWliYSAmbHQ7YmFycnlsZWliYUBjb21w dXRlci5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtkcmFmdC1pZXRmLXNpcGNvcmUtc2lw LXRva2VuLWF1dGhuekBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10 b2tlbi1hdXRobnpAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZs dDtzaXBjb3JlQGlldGYub3JnJmd0OywgJnF1b3Q7aWVzZ0BpZXRmLm9yZyZxdW90OyAmbHQ7aWVz Z0BpZXRmLm9yZyZndDssICZxdW90O3NpcGNvcmUtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtz aXBjb3JlLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzaXBj b3JlXSBCYXJyeSBMZWliYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tl bi1hdXRobnotMTM6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz IEJhcnJ5ISA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IHlvdSBwb2ludGVkIG91dCwgdGhpcyBpcyB3YXkgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50IGFuZCB0aGUgU0lQQ29yZSBXRyAobm90IElDRSksIGFzIEkgd2FzIHRyeWluZyB0byBm b2N1cyBvbiB0aGluZ3MgdGhhdCB0aGlzIGRvY3VtZW50IGNvbnRyb2xzLi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmluZyBzYWlkIHRoYXQs IEkgYW0gZmluZSB3aXRoIGFkZGluZyB0aGUgdXBkYXRlZCB0ZXh0IHRvIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9uIHNlY3Rpb24gaWYgdGhhdCBhZGRyZXNzZXMgeW91ciBjb25jZXJucyBhbmQg Y2xlYXJzIHRoZSBESVNDVVNTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgYWRkIHlvdXImbmJzcDtwcm9wb3NlZCB0ZXh0IHRvIHRo ZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDIxLCAy MDIwIGF0IDI6MTggUE0gQmFycnkgTGVpYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiYXJyeWxlaWJh QGNvbXB1dGVyLm9yZyI+YmFycnlsZWliYUBjb21wdXRlci5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyBmb3IgdGhlIHJlcGx5LCBSaWZhYXQuJm5ic3A7IFdlJ3JlIG9uIHRoZSByaWdodCB0cmFj aywgdGhvdWdoPGJyPg0KdGhlcmUncyBtb3JlIGludm9sdmVkLiZuYnNwOyBXZSBqdXN0IGhhdmUg dG8gZmlndXJlIG91dCB0aGUgYmVzdCB3YXkgdG88YnI+DQpoYW5kbGUgaXQsIGJlY2F1c2UgdGhp cyBkb2N1bWVudCBkb2Vzbid0IGhhdmUgdGhlIGZ1bGwgcmVzcG9uc2liaWxpdHk8YnI+DQp0byBs YXkgb3V0IGJlc3QgcHJhY3RpY2VzIGZvciBTU08uJm5ic3A7IFNvIGxldCdzIHNlZSBpZiB3ZSBj YW4gY29tZSB1cDxicj4NCndpdGggYSByZWFzb25hYmxlIGNvbXByb21pc2UuPGJyPg0KPGJyPg0K TGV0IG1lIHN0YXJ0IGJ5IGxheWluZyBvdXQsIHF1aWNrbHksIHNvbWUgb2YgdGhlIGlzc3VlcyB3 aXRoIFNTTzo8YnI+DQo8YnI+DQpUaGUgYmlnZ2VzdCBwcm9ibGVtcyBpbmNsdWRlOjxicj4NCi0g cHJpdmFjeSBleHBvc3VyZXM6IGlmIEkgJnF1b3Q7bG9naW4gd2l0aCBGYWNlYm9vayZxdW90OyBl dmVyeXdoZXJlLCBGYWNlYm9vazxicj4NCmdldHMgYSBsb3Qgb2YgaW5mb3JtYXRpb24gYWJvdXQg d2hhdCBJIGRvIGFuZCB3aGVyZSBJIGxvZyBpbiwgYW5kPGJyPg0KdXNlcnMgYXJlIGdlbmVyYWxs eSBub3QgYXdhcmUgb2YgdGhhdDxicj4NCi0gZXhwb3N1cmUgb24gbWFueSBzZXJ2aWNlcyBpZiBt eSBTU08gKEZhY2Vib29rIG9yIHdoYXRldmVyKSBsb2dpbiBpczxicj4NCmNvbXByb21pc2VkOiBu b3cgdGhhdCB0aGUgU1NPIGxvZ2luIGlzIHVzZWQgaW4gb3RoZXIgcGxhY2VzLCB0aGF0PGJyPg0K c2luZ2xlIHBvaW50IG9mIGNvbXByb21pc2UgaGFzIGEgZmFyIGJyb2FkZXIgZWZmZWN0IC0tIHlv dSBnZXQgdG8gdGhhdDxicj4NCmluIHlvdXIgZmlyc3Qgc3VnZ2VzdGVkIHBhcmFncmFwaDxicj4N Ci0gaWYgbXkgU1NPIGxvZ2luIGlzIGNvbXByb21pc2VkLCBhbiBhdHRhY2tlciBjYW4gdXNlIGl0 IHRvIGNyZWF0ZSBuZXc8YnI+DQpTU09zIG9uIHNpdGVzIHRoYXQgSSBoYXZlbid0IGV2ZW4gdXNl ZCwgYW5kIHNvbWV0aW1lcyB0aGV5IGNhbiBzd2l0Y2g8YnI+DQpteSBleGlzdGluZyBzZXBhcmF0 ZSBhY2NvdW50cyB0byBTU08sIGFkZGluZyBjb21wcm9taXNlcyB0aGF0IEkgZGlkbid0PGJyPg0K c2lnbiB1cCBmb3I8YnI+DQotIGluYWJpbGl0eSB0byBleHRyaWNhdGUgbXlzZWxmIGZyb20gdGhl IHNpdHVhdGlvbjogbW9zdCBzaXRlcyBkb24ndDxicj4NCm1ha2UgaXQgZWFzeSB0byB1bmRvIFNT TyBvbmNlIEkndmUgZW5hYmxlZCBpdCwgYW5kIG1hbnkgZG9uJ3QgYWxsb3cgaXQ8YnI+DQphdCBh bGw8YnI+DQo8YnI+DQpJdCdzIGNsZWFybHkgd2VsbCBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnQgdG8gY292ZXIgYWxsIHRoYXQ8YnI+DQppbiBhbnkgZGV0YWlsLCBidXQgaXQgbWln aHQgYmUgd29ydGggYSBicmllZiBvdmVydmlldyBvZiB0aGUgcHJvYmxlbXMuPGJyPg0KTGV0IG1l IHNlZSBpZiBJIGNhbiBhZGQgYSBwYXJhZ3JhcGggb3IgdHdvIHRvIHdoYXQgeW91J3ZlIGFscmVh ZHk8YnI+DQpzdWdnZXN0ZWQsIHRvIGNvdmVyIHRoZSBvdGhlciB0aHJlZSBpc3N1ZXMuPGJyPg0K PGJyPg0KJmx0OyZsdDs8YnI+DQpTaW5nbGUgU2lnbi1PbiAoU1NPKSBlbmFibGVzIHRoZSB1c2Vy IHRvIHVzZSBvbmUgc2V0IG9mIGNyZWRlbnRpYWxzIHRvPGJyPg0KYXV0aGVudGljYXRlIG9uY2Ug YW5kIGdhaW4gYWNjZXNzIHRvIG11bHRpcGxlIFNJUCBhbmQgbm9uLVNJUCBzZXJ2aWNlczxicj4N CnVzaW5nIGFjY2VzcyB0b2tlbihzKS4gSWYgdGhlIFNTTyBsb2dpbiBpcyBjb21wcm9taXNlZCwg dGhhdCBzaW5nbGU8YnI+DQpwb2ludCBvZiBjb21wcm9taXNlIGhhcyBhIG11Y2ggYnJvYWRlciBl ZmZlY3QgdGhhbiBpcyB0aGUgY2FzZSB3aXRob3V0PGJyPg0KU1NPLiZuYnNwOyBGdXJ0aGVyLCBh biBhdHRhY2tlciBjYW4gb2Z0ZW4gdXNlIGEgY29tcHJvbWlzZWQgYWNjb3VudCB0byBzZXQ8YnI+ DQp1cCBTaW5nbGUgU2lnbi1PbiBmb3Igb3RoZXIgc2VydmljZXMgdGhhdCB0aGUgdmljdGltIGhh cyBub3Q8YnI+DQplc3RhYmxpc2hlZCBhbiBhY2NvdW50IHdpdGgsIGFuZCBzb21ldGltZXMgY2Fu IGV2ZW4gc3dpdGNoIGEgZGVkaWNhdGVkPGJyPg0KYWNjb3VudCBpbnRvIFNpbmdsZS1TaWduLU9u IG1vZGUsIGNyZWF0aW5nIGEgc3RpbGwgYnJvYWRlciBhdHRhY2suPGJyPg0KPGJyPg0KQmVjYXVz ZSBvZiB0aGF0LCBpdCBpcyBjcml0aWNhbCB0byBtYWtlIHN1cmUgdGhhdCBleHRyYSBzZWN1cml0 eTxicj4NCm1lYXN1cmVzIGJlIHRha2VuIHRvIHNhZmVndWFyZCBjcmVkZW50aWFscyB1c2VkIGZv ciBTaW5nbGUgU2lnbi1Pbi48YnI+DQpFeGFtcGxlcyBvZiBzdWNoIG1lYXN1cmVzIGluY2x1ZGUg bG9uZyBwYXNzcGhyYXNlIGluc3RlYWQgb2YgYTxicj4NCnBhc3N3b3JkLCBlbmFibGluZyBtdWx0 aS1mYWN0b3IgZmFjdG9yIGF1dGhlbnRpY2F0aW9uLCBhbmQgdGhlIHVzZSBvZjxicj4NCmVtYmVk ZGVkIGJyb3dzZXIgd2hlbiBwb3NzaWJsZSwgYXMgZGVmaW5lZCBpbiBSRkM4MjUyLjxicj4NCjxi cj4NCkFsdGhvdWdoIHRoaXMgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LCBpdCBp cyBpbXBvcnRhbnQgdG88YnI+DQpjYXJlZnVsbHkgY29uc2lkZXIgdGhlIGNsYWltcyBwcm92aWRl ZCBpbiB0aGUgdG9rZW5zIHVzZWQgdG8gYWNjZXNzPGJyPg0KdGhlc2Ugc2VydmljZXMgdG8gbWFr ZSBzdXJlIG9mIHRoZSBwcml2YWN5IG9mIHRoZSB1c2VyIGFjY2Vzc2luZyB0aGVzZTxicj4NCnNl cnZpY2VzLiBBcyBtZW50aW9uZWQgYWJvdmUsIHRoaXMgZG9jdW1lbnQgY2FsbHMgZm9yIGVuY3J5 cHRpbmcgSldUPGJyPg0KcmVwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4uPGJyPg0KPGJyPg0K SXQgaXMgaW1wb3J0YW50IHRoYXQgYm90aCBwYXJ0aWVzIHBhcnRpY2lwYXRpbmcgaW4gU1NPIHBy b3ZpZGU8YnI+DQptZWNoYW5pc21zIGZvciB1c2VycyB0byBzZXZlciB0aGUgU1NPIHJlbGF0aW9u c2hpcCwgc28gdGhhdCBpdCBpczxicj4NCnBvc3NpYmxlIHdpdGhvdXQgdW5kdWUgZGlmZmljdWx0 eSB0byBtaXRpZ2F0ZSBhIGNvbXByb21pc2UgdGhhdCBoYXM8YnI+DQphbHJlYWR5IGhhcHBlbmVk Ljxicj4NCjxicj4NClRoZSBvcGVyYXRvciBvZiBhIFNpbmdsZS1TaWduLU9uIGF1dGhlbnRpY2F0 aW9uIHN5c3RlbSBoYXMgYWNjZXNzIHRvPGJyPg0KcHJpdmF0ZSBpbmZvcm1hdGlvbiBhYm91dCBz aXRlcyBhbmQgc2VydmljZXMgdGhhdCB0aGVpciB1c2VycyBsb2c8YnI+DQppbnRvLCBhbmQgZXZl biwgdG8gc29tZSBleHRlbnQsIGFib3V0IHRoZWlyIHVzYWdlIHBhdHRlcm5zLiZuYnNwOyBJdCdz PGJyPg0KaW1wb3J0YW50IHRvIGNhbGwgdGhlc2Ugb3V0IGluIHByaXZhY3kgZGlzY2xvc3VyZXMg YW5kIHBvbGljaWVzLCBhbmQ8YnI+DQp0byBtYWtlIHN1cmUgdGhhdCB1c2VycyBjYW4gYmUgYXdh cmUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuPGJyPg0KY29udmVuaWVuY2UgYW5kIHByaXZhY3kg d2hlbiB0aGV5IGNob29zZSB0byB1c2UgU1NPLjxicj4NCiZndDsmZ3Q7PGJyPg0KPGJyPg0KRG9l cyB0aGF0IHdvcms/PGJyPg0KPGJyPg0KQW5kIHRoZW4gaXQgd291bGQgYmUgZ29vZCBmb3IgdXMg KHRoZSBJRVRGIGNvbW11bml0eSBhcyBhIHdob2xlLCBub3Q8YnI+DQpJQ0UpIHRvIGZpZ3VyZSBv dXQgd2hldGhlciB0byB3cml0ZSBhIEJDUCByZWxhdGVkIHRvIFNTTzxicj4NCnNlY3VyaXR5L3By aXZhY3kgaXNzdWVzLjxicj4NCjxicj4NCkJhcnJ5PGJyPg0KPGJyPg0KJmd0OyBSZWdhcmRpbmcg dGhlIERJU0NVU1MsIGhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOjxicj4NCiZndDs8YnI+DQomZ3Q7IFNpbmds ZSBTaW5nLU9uIGVuYWJsZXMgdGhlIHVzZXIgdG8gdXNlIG9uZSBzZXQgb2YgY3JlZGVudGlhbHMg dG8gYXV0aGVudGljYXRlPGJyPg0KJmd0OyBvbmNlIGFuZCBnYWluIGFjY2VzcyB0byBtdWx0aXBs ZSBTSVAgYW5kIG5vbi1TSVAgc2VydmljZXMgdXNpbmcgYWNjZXNzIHRva2VuKHMpLjxicj4NCiZn dDsgQmVjYXVzZSBvZiB0aGF0LCBpdCBpcyBjcml0aWNhbCB0byBtYWtlIHN1cmUgdGhhdCBleHRy YSBzZWN1cml0eSBtZWFzdXJlcyBiZTxicj4NCiZndDsgdGFrZW4gdG8gZ3VhcmRzIHRoZXNlIGNy ZWRlbnRpYWxzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEV4YW1wbGVzIG9mIHN1Y2ggbWVhc3VyZXMg aW5jbHVkZSBsb25nIHBhc3NwaHJhc2UgaW5zdGVhZCBvZiBhIHBhc3N3b3JkLCBlbmFibGluZzxi cj4NCiZndDsgbXVsdGktZmFjdG9yIGZhY3RvciBhdXRoZW50aWNhdGlvbiwgYW5kIHRoZSB1c2Ug b2YgZW1iZWRkZWQgYnJvd3NlciB3aGVuIHBvc3NpYmxlLDxicj4NCiZndDsgYXMgZGVmaW5lZCBp biBSRkM4MjUyLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFsdGhvdWdoIHRoaXMgaXMgb3V0IG9mIHNj b3BlIGZvciB0aGlzIGRvY3VtZW50LCBpdCBpcyBpbXBvcnRhbnQgdG8gY2FyZWZ1bGx5PGJyPg0K Jmd0OyBjb25zaWRlciB0aGUgY2xhaW1zIHByb3ZpZGVkIGluIHRoZSB0b2tlbnMgdXNlZCB0byBh Y2Nlc3MgdGhlc2Ugc2VydmljZXMgdG8gbWFrZTxicj4NCiZndDsgc3VyZSBvZiB0aGUgcHJpdmFj eSBvZiB0aGUgdXNlciBhY2Nlc3NpbmcgdGhlc2Ugc2VydmljZXMuIEFzIG1lbnRpb25lZCBhYm92 ZSw8YnI+DQomZ3Q7IHRoaXMgZG9jdW1lbnQgY2FsbHMgZm9yIGVuY3J5cHRpbmcgSldUIHJlcHJl c2VudGluZyB0aGUgYWNjZXNzIHRva2VuLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C8B9BFC326784E3BB6D84CEDA4976D15ericssoncom_-- From nobody Tue Apr 21 14:52:08 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C583A0B23; Tue, 21 Apr 2020 14:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7JyI8TD1_vH6; Tue, 21 Apr 2020 14:51:50 -0700 (PDT) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 681433A0B25; Tue, 21 Apr 2020 14:51:50 -0700 (PDT) Received: by mail-io1-f44.google.com with SMTP id e9so201287iok.9; Tue, 21 Apr 2020 14:51:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z41AzFeyD69jBd//li6CjyOSE6spy/A1uHn8A3qNQZE=; b=WFtdcLyucu4bapQdbT5sp1Fn7SA0ZviGqkjVlt0UxN9WnS/RSwF1AOAt4RRk89ok8S lWgGBUww3AyUpBEgT2RwiUUk4NIFMYEk5eTfG69XAgvo5Gu/Vm9U0BG8eCvpr7PweLdI 31bWWLZGEM/h/2VI6jYBzdZY+gmHo8E/KaEaEJRqlfgNJAkQIURO5lGW0IeSkXPQHMDa 5AGYQ8Ic3W+iy5SA5LpjaUMTww0pi82ss7jhVkgsj09nBxSkTSrh8S92MRbyfTX9ACUz E/PtVLpiTS7QhFcqtrz5IVAPmxSYlKzuejowKx7I2cHdUPAEMzPKBII3N3aAS+glHiKa kYWQ== X-Gm-Message-State: AGi0PubvYGxxZiBKy01XUdmJxk79gMDd1vSMTLfOnEpjmiQfYcYrT5FG u9W8zy6OZU32iY1SATwWY8jJMo2LkT6TsmX/hk0= X-Google-Smtp-Source: APiQypJQ1OvtYMyhwVXoXcSHsLbnLBw2eRzlfDrAyyNQA+AmR1W1A8eTLcuT+jq7xI/t8a5Znz5zEBnm77VKAOkngwo= X-Received: by 2002:a5e:9806:: with SMTP id s6mr22956929ioj.59.1587505909320; Tue, 21 Apr 2020 14:51:49 -0700 (PDT) MIME-Version: 1.0 References: <158744819049.23997.5059457122698360691@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Tue, 21 Apr 2020 17:51:38 -0400 Message-ID: To: Christer Holmberg Cc: Rifaat Shekh-Yusef , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , SIPCORE , The IESG , "sipcore-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 21:51:53 -0000 > Below is a link to a pull request with the SSO text for the Security Considerations. > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7 Parfait; merci beaucoups! Barry > From: sipcore on behalf of Rifaat Shekh-Yusef > Date: Tuesday, 21 April 2020 at 22.26 > To: Barry Leiba > Cc: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "iesg@ietf.org" , "sipcore-chairs@ietf.org" > Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) > > > > Thanks Barry! > > > > As you pointed out, this is way beyond the scope of this document and the SIPCore WG (not ICE), as I was trying to focus on things that this document controls.. > > Having said that, I am fine with adding the updated text to the security consideration section if that addresses your concerns and clears the DISCUSS. > > > > I will add your proposed text to the next version of the draft. > > Regards, > > Rifaat > > > > > > On Tue, Apr 21, 2020 at 2:18 PM Barry Leiba wrote: > > Thanks for the reply, Rifaat. We're on the right track, though > there's more involved. We just have to figure out the best way to > handle it, because this document doesn't have the full responsibility > to lay out best practices for SSO. So let's see if we can come up > with a reasonable compromise. > > Let me start by laying out, quickly, some of the issues with SSO: > > The biggest problems include: > - privacy exposures: if I "login with Facebook" everywhere, Facebook > gets a lot of information about what I do and where I log in, and > users are generally not aware of that > - exposure on many services if my SSO (Facebook or whatever) login is > compromised: now that the SSO login is used in other places, that > single point of compromise has a far broader effect -- you get to that > in your first suggested paragraph > - if my SSO login is compromised, an attacker can use it to create new > SSOs on sites that I haven't even used, and sometimes they can switch > my existing separate accounts to SSO, adding compromises that I didn't > sign up for > - inability to extricate myself from the situation: most sites don't > make it easy to undo SSO once I've enabled it, and many don't allow it > at all > > It's clearly well beyond the scope of this document to cover all that > in any detail, but it might be worth a brief overview of the problems. > Let me see if I can add a paragraph or two to what you've already > suggested, to cover the other three issues. > > << > Single Sign-On (SSO) enables the user to use one set of credentials to > authenticate once and gain access to multiple SIP and non-SIP services > using access token(s). If the SSO login is compromised, that single > point of compromise has a much broader effect than is the case without > SSO. Further, an attacker can often use a compromised account to set > up Single Sign-On for other services that the victim has not > established an account with, and sometimes can even switch a dedicated > account into Single-Sign-On mode, creating a still broader attack. > > Because of that, it is critical to make sure that extra security > measures be taken to safeguard credentials used for Single Sign-On. > Examples of such measures include long passphrase instead of a > password, enabling multi-factor factor authentication, and the use of > embedded browser when possible, as defined in RFC8252. > > Although this is out of scope for this document, it is important to > carefully consider the claims provided in the tokens used to access > these services to make sure of the privacy of the user accessing these > services. As mentioned above, this document calls for encrypting JWT > representing the access token. > > It is important that both parties participating in SSO provide > mechanisms for users to sever the SSO relationship, so that it is > possible without undue difficulty to mitigate a compromise that has > already happened. > > The operator of a Single-Sign-On authentication system has access to > private information about sites and services that their users log > into, and even, to some extent, about their usage patterns. It's > important to call these out in privacy disclosures and policies, and > to make sure that users can be aware of the tradeoffs between > convenience and privacy when they choose to use SSO. > >> > > Does that work? > > And then it would be good for us (the IETF community as a whole, not > ICE) to figure out whether to write a BCP related to SSO > security/privacy issues. > > Barry > > > Regarding the DISCUSS, how about adding the following text to the security considerations section: > > > > Single Sing-On enables the user to use one set of credentials to authenticate > > once and gain access to multiple SIP and non-SIP services using access token(s). > > Because of that, it is critical to make sure that extra security measures be > > taken to guards these credentials. > > > > Examples of such measures include long passphrase instead of a password, enabling > > multi-factor factor authentication, and the use of embedded browser when possible, > > as defined in RFC8252. > > > > Although this is out of scope for this document, it is important to carefully > > consider the claims provided in the tokens used to access these services to make > > sure of the privacy of the user accessing these services. As mentioned above, > > this document calls for encrypting JWT representing the access token. From nobody Wed Apr 22 08:01:48 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EFB3A0E44; Wed, 22 Apr 2020 08:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158756770265.29423.4519297355803165822@ietfa.amsl.com> Date: Wed, 22 Apr 2020 08:01:42 -0700 Archived-At: Subject: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 15:01:43 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The use of the OpenID ID token appears to be underspecified. Section 1.3 notes the possibility of using it as one of the three possible tokens. However, the SIP procedures in Section 2 makes no note of it, only covering the use of the “access token” and the “refresh token”. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the update based on the SECDIR review (and thanks to Derrell Piper for providing it). ** Section 1.3. Per “Access Tokens could be represented in one of the above two formats.”, if not one of these two formats, then which other ones? ** Section 2.1.1. Per “An OpenID Connect server …”, based on the flows depicted in Figure 1 and 2, how the OpenID Connect server fits isn’t clear. ** Section 2.1.2. Per “Endpoints that support this specification MUST support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access tokens when they are included in SIP requests, unless some other mechanism is used to guarantee that only authorized SIP endpoints have access to the access token.” -- is it the “use of” or “support for” JWT that is required if there isn’t an alternative? Section 5 uses similar language. ** Section 2.1.3. Per “Note that, if there were multiple challenges with different schemes, then the UAC may be able to successfully retry the request using non-Bearer credentials.”, would that decision be made based on local policy? ** Section 5. Should the use of the scope parameter be noted (or RECOMMENDED) to narrow the utility of the token? ** Editorial Nits: Section 1.3. Typo. s/usualy/usually/ Section 7. Typo. s/coversion/conversion/ From nobody Wed Apr 22 09:28:36 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2CB3A0FAB; Wed, 22 Apr 2020 09:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ZTKkStgvyOrd; Wed, 22 Apr 2020 09:28:32 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60056.outbound.protection.outlook.com [40.107.6.56]) (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 2FC693A0FAC; Wed, 22 Apr 2020 09:28:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VpxhV6Zv+fFbYTl9mz9GA7v38NedR9YeLfNUhbFocnT/0skEffVj9Mdw7QEqbR6AHA0XaakKY+GQT3lJX4zWVCClFxpxssPEX/cPYMAj9QBO+E0NR1Z+gf2tCW1O119hFAbAFI4lNf5HNW/otu4vVd0+jiAj5TNL8adfZLEpsxinMT3bZ15HjL+JXaYWm4oDneW0XwgDOyfQ5Qw7nxgK5yPjgv+nR7f0P/i/s76yD11Df8pqHA7Vo8aCvd21EJBGgQmdBpB04tVlXPn/BTBzFh1ow8rwaICzbYZ6IbwKQyfKyuJwT2ZyZ1OfbrcUx1f9KmzJL6xmBZhq5dw/kbh9dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s/MBYYKIM/Is6FiOJMc6WCSPXBtNJhy6qnaKEfmCDKU=; b=TMoRIwM5j4puNR4mPmLZXq1xU0te58U6EKEv6XLRJ5JlxbTjvZRQxBoOh+Ufnm0PEYiOGiwzUeLRKnB6cya+pizOQ9/qSVPseWZCHhZGJzjHpa18xBC7R+o/FDLiBm8EyUHoFeZ34qYtrVZ+OQFVomYQ5XWIXl28RtfNUbAKSEFtvH30VyqVqZfy1oeJ0K9qCufxYwDAJ5oRsqJZYB6/oWiQDZjp5AgkV+Ne3BTMgB+3cxt+krdEMtR3IPDcYqSfwbGmrGs4zz53GPwB0aiy7wmN0UDjP9cJlU7IJd4eU/tEToBgUF0cIbE4nmgsdjgcx7PwVPu4dKYt2ScRTldf3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s/MBYYKIM/Is6FiOJMc6WCSPXBtNJhy6qnaKEfmCDKU=; b=MEOTzo+Cv2ywTp9/RnRsID2GZznl7S9xh/3s1IwFAXJYlB0uQLbyzvZTozGXisvWdiLyN6rvEWKIyuOjH9/LOUfKYqh0J/PtnUIx4Hr0FJcf8URvhJsk6mEZcfhx+VZn1G+jpjlCT+qMdYMoAnswo6cXMylGlwn18PknnHd/As4= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6275.eurprd07.prod.outlook.com (2603:10a6:20b:156::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Wed, 22 Apr 2020 16:28:30 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 16:28:30 +0000 From: Christer Holmberg To: Roman Danyliw , The IESG CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT Thread-Index: AQHWGMMOtxZIT3jHHk6raCfflxfIDg== Date: Wed, 22 Apr 2020 16:28:29 +0000 Message-ID: <469529BD-F254-4B45-9000-E1F5B8463A08@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3bee45a-b680-48d7-dfe1-08d7e6da3148 x-ms-traffictypediagnostic: AM0PR07MB6275: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 03818C953D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(396003)(39860400002)(136003)(86362001)(4326008)(5660300002)(71200400001)(6506007)(110136005)(66946007)(54906003)(8676002)(76116006)(66556008)(44832011)(2616005)(66446008)(66476007)(36756003)(81156014)(64756008)(8936002)(478600001)(2906002)(186003)(316002)(26005)(6512007)(6486002)(33656002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RBP2CTaAB9WWJjKFCv5cn5ec9zKJ8YYE1JNXrABV4e18/Qj4WPZTsnmD/vZthAclRFz/jL1uQHpqbTOjdDdvwBgGNK4obk3GuytWtsdaLTvQsQ2DhX+wkwYIWzCWZF1oKrmeIyOdveS2lto43B+HBs5cNGOayVc+mMU9+WgsALcg+DUnCgJaGQXqIdY/PpCYcziptg14nzTnzG9q82CuUklz+B0uhH0YDXs/CK3MplDnWjZcBKabsHUBYiWhoCwZfjBz/GKcrHPpSMNiQXymI2jB+IM+RdeOEALOCZjpGI+lF9cgHq88h+Zix2KT/bRQLzFkRrarRVhcnAeMyp5RnZFnO6CbxJl2KBZBKrqfIGL2thCu10V5zx+z5fhPrKr3BbgSSPFEmX7QM0ucGTn/4fOtGNuE42zGGBag5H0yo8YyAGUZ0FaITd8vCa2x5R3a x-ms-exchange-antispam-messagedata: mb8KpLWB9Le5MXdWAhSINM+EGoS8zj1gpiXi/PTNEq+/ySrCdVb8QhCpS3EqzIqrmLeEKVPckCEGpuvHWGCjA2rCGOjoRDfH0LIIdehttINxpO9bw4hnnkTfknoU8y9//IW2BmsZVvd9V24GFnb+Yg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2627736610D9534393490698B10F647F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3bee45a-b680-48d7-dfe1-08d7e6da3148 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 16:28:29.9383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EpdGndn7o1W6rRSttxeCQwFdKXrUehkYuI3aP0pZygr+8BPKwE5sNBcbYfKOChjAMD7q/QURUqORZNGmzdCoWpZrZXdqCH8G0fvAhozNo1g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6275 Archived-At: Subject: Re: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 16:28:34 -0000 SEkgUm9tYW4sDQoNClRoYW5rIFlvdSBmb3IgdGhlIHJldmlldyEgSW4gdGhpcyByZXBseSBJIHdp bGwgYWRkcmVzcyBtb3N0IG9mIHlvdXIgQ09NTUVOVCBpc3N1ZXMuIFRoZSBESVNDVVNTIGlzc3Vl LCBhbmQgYSBjb3VwbGUgb2YgQ09NTUVOVCBpc3N1ZXMsIHdpbGwgYmUgYWRkcmVzc2VkIGluIGEg c2VwYXJhdGUgcmVwbHkuDQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQog ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICANCiAgICA+KiogU2VjdGlvbiAxLjMuICBQZXIg4oCc QWNjZXNzIFRva2VucyBjb3VsZCBiZSByZXByZXNlbnRlZCBpbiBvbmUgb2YgdGhlIGFib3ZlDQog ICAgPnR3byBmb3JtYXRzLuKAnSwgaWYgbm90IG9uZSBvZiB0aGVzZSB0d28gZm9ybWF0cywgdGhl biB3aGljaCBvdGhlciBvbmVzPw0KICAgIA0KICAgIEkgc3VnZ2VzdCB0byBjaGFuZ2UgImNvdWxk IiB0byAiY2FuIi4NCg0KLS0tDQoNCiAgICA+ICoqIFNlY3Rpb24gMi4xLjEuICBQZXIg4oCcQW4g T3BlbklEIENvbm5lY3Qgc2VydmVyIOKApuKAnSwgYmFzZWQgb24gdGhlIGZsb3dzDQogICAgPiBk ZXBpY3RlZCBpbiBGaWd1cmUgMSBhbmQgMiwgaG93IHRoZSBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXIg Zml0cyBpc27igJl0IGNsZWFyLg0KDQpXZSB3aWxsIGFkZHJlc3MgdGhpcyBpbiB0aGUgcmVwbHkg dGhhdCBhZGRyZXNzZXMgdGhlIERJU0NVU1MsIGFzIHRoZSBpc3N1ZXMgYXJlIHJlbGF0ZWQuDQoN Ci0tLQ0KDQogICAgPiAqKiBTZWN0aW9uIDIuMS4yLiAgUGVyIOKAnEVuZHBvaW50cyB0aGF0IHN1 cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1Qgc3VwcG9ydA0KICAgID4gZW5jcnlwdGVkIEpT T04gV2ViIFRva2VucyAoSldUKSBbUkZDNzUxOV0gZm9yIGVuY29kaW5nIGFuZCBwcm90ZWN0aW5n IGFjY2Vzcw0KICAgID4gdG9rZW5zIHdoZW4gdGhleSBhcmUgaW5jbHVkZWQgaW4gU0lQIHJlcXVl c3RzLCB1bmxlc3Mgc29tZSBvdGhlciBtZWNoYW5pc20gaXMNCiAgICA+IHVzZWQgdG8gZ3VhcmFu dGVlIHRoYXQgb25seSBhdXRob3JpemVkIFNJUCBlbmRwb2ludHMgaGF2ZSBhY2Nlc3MgdG8gdGhl IGFjY2Vzcw0KICAgID4gdG9rZW4u4oCdIC0tIGlzIGl0IHRoZSDigJx1c2Ugb2bigJ0gb3Ig4oCc c3VwcG9ydCBmb3LigJ0gSldUIHRoYXQgaXMgcmVxdWlyZWQgaWYgdGhlcmUNCiAgICA+IGlzbuKA mXQgYW4gYWx0ZXJuYXRpdmU/ICBTZWN0aW9uIDUgdXNlcyBzaW1pbGFyIGxhbmd1YWdlLg0KDQoi TVVTVCB1c2UiIGlzIG1vcmUgY29ycmVjdC4NCg0KLS0tDQogICAgDQogICAgPiAqKiBTZWN0aW9u IDIuMS4zLiAgUGVyIOKAnE5vdGUgdGhhdCwgaWYgdGhlcmUgd2VyZSBtdWx0aXBsZSBjaGFsbGVu Z2VzIHdpdGgNCiAgICA+IGRpZmZlcmVudCBzY2hlbWVzLCB0aGVuIHRoZSBVQUMgbWF5IGJlIGFi bGUgdG8gc3VjY2Vzc2Z1bGx5IHJldHJ5IHRoZSByZXF1ZXN0DQogICAgPiB1c2luZyBub24tQmVh cmVyIGNyZWRlbnRpYWxzLuKAnSwgd291bGQgdGhhdCBkZWNpc2lvbiBiZSBtYWRlIGJhc2VkIG9u IGxvY2FsDQogICAgPiBwb2xpY3k/DQogICAgDQpZZXMuIFRoYXQgaXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMi4xLjEuOg0KDQogICAiSWYgdGhlIFVBQyByZWNlaXZlcyBhIDQwMS80MDcgcmVzcG9u c2Ugd2l0aCBtdWx0aXBsZSBXV1ctDQogICBBdXRoZW50aWNhdGUvUHJveHktQXV0aGVudGljYXRl IGhlYWRlciBmaWVsZHMsIHByb3ZpZGluZyBjaGFsbGVuZ2VzDQogICB1c2luZyBkaWZmZXJlbnQg YXV0aGVudGljYXRpb24gc2NoZW1lcyBmb3IgdGhlIHNhbWUgcmVhbG0sIHRoZSBVQUMNCiAgIHNl bGVjdHMgb25lIG9yIG1vcmUgb2YgdGhlIHByb3ZpZGVkIHNjaGVtZXMgKGJhc2VkIG9uIGxvY2Fs IHBvbGljeSkNCiAgIGFuZCBwcm92aWRlcyBjcmVkZW50aWFscyBmb3IgdGhvc2Ugc2NoZW1lcy4i DQoNCi0tLQ0KDQogICAgPiAqKiBTZWN0aW9uIDUuICBTaG91bGQgdGhlIHVzZSBvZiB0aGUgc2Nv cGUgcGFyYW1ldGVyIGJlIG5vdGVkIChvciBSRUNPTU1FTkRFRCkNCiAgICA+IHRvIG5hcnJvdyB0 aGUgdXRpbGl0eSBvZiB0aGUgdG9rZW4/DQoNCiAgICBJIHdpbGwgcmVmZXIgdGhpcyB0byBSaWZh YXQuDQoNCi0tLQ0KICAgIA0KICAgID4gKiogRWRpdG9yaWFsIE5pdHM6DQogICAgPiBTZWN0aW9u IDEuMy4gIFR5cG8uIHMvdXN1YWx5L3VzdWFsbHkvDQogICAgDQogICAgV2lsbCBmaXguDQoNCiAg ICA+IFNlY3Rpb24gNy4gIFR5cG8uICBzL2NvdmVyc2lvbi9jb252ZXJzaW9uLw0KICAgIA0KICAg IFdpbGwgZml4Lg0KDQotLS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCiAgICANCiAgICANCg0K From nobody Wed Apr 22 10:58:35 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B313A11BB; Wed, 22 Apr 2020 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIaVOtOSc_Bt; Wed, 22 Apr 2020 10:58:19 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 C7BF73A11BA; Wed, 22 Apr 2020 10:58:19 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id k6so3409260iob.3; Wed, 22 Apr 2020 10:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wWGs6xwps1izlzxOIhwQdhXHiFFJIeE/+rkDIakwz2U=; b=YxN2sMTgKuHtufhHTevkMLA72veR3tnYateWY7QBHkLkWE48k8kZ4g44L7c0VvQSDE fw/fzWexOJidigC3Lcx8jz68Ri1epREMhyA/746d8zH3MsJlzFhXNJglXAy5xrPO+6PF 4traZ88d8UZKz00Zhi5GIaLFQZ/Qf8vuwazT6rQWDnMChFycr4nTh8NGxXhxijv1acEQ 8vG55Eusdg1zSJmrxahs+aLndq+qhnzYjxJmYywor4Wsnd4DqN6A1WYfKH7u+8k7rLLu GGb5DPK9JRCmuvnX+VBw/9fZpXpF7IMgU4fedwXQhAtBE/CJ8gI2LhTLhVx1ZFxW+Ga3 ct5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wWGs6xwps1izlzxOIhwQdhXHiFFJIeE/+rkDIakwz2U=; b=V3eTvknAtJMa325FuEdAKVItYjhMmpW15zjbHmXIvZP9TYdr1Yj/fpD4koPdjIE9ZG FeAA0TF2jWezJpKPejaJ12hmZEWs4JGVxYk8qu/s9aewhgivQq9olnUvWIYjxE+1i5es MdutollIQIkfHSnH2IJLLmfy1kusBiIpfB39P8WHykb6JKWIIl/rPHdGz22URz3S/+ny 4DWhd83zWckz6dZLwWE3Zge4p4wUzyqLYdguo6J19yTJuOEMl4HpkCQ/c8q2zmGTU3RF 3tp4ETHM2H8AQuEEY6NABb5DwiOgNe+mjB2/w8gixuOUgvvIbtF4002p5XnNpMW78r7H h7wA== X-Gm-Message-State: AGi0PuZ7FZdNI/yJiGBysu0WeryJtBTJaYF9eQ6aRDGLUDXxvtaeb7i4 1clcZNRR3YocpAoZ7q+mtW4N+5IbL5zlr2jfanHBFoL3 X-Google-Smtp-Source: APiQypKWVjOEIxM+1shxIggi3Sy8RoxRaxf3n/lixXWyoSA1yCzZUTm36OjIfpZjEwt+lHDAIJSpjkQoHyGf482UvuI= X-Received: by 2002:a02:cb8a:: with SMTP id u10mr26443340jap.73.1587578298914; Wed, 22 Apr 2020 10:58:18 -0700 (PDT) MIME-Version: 1.0 References: <469529BD-F254-4B45-9000-E1F5B8463A08@ericsson.com> In-Reply-To: <469529BD-F254-4B45-9000-E1F5B8463A08@ericsson.com> From: Rifaat Shekh-Yusef Date: Wed, 22 Apr 2020 13:58:08 -0400 Message-ID: To: Christer Holmberg Cc: Roman Danyliw , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: multipart/alternative; boundary="0000000000008f5c7e05a3e4e0d0" Archived-At: Subject: Re: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:58:29 -0000 --0000000000008f5c7e05a3e4e0d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks for the review! Regarding the DISCUSS: Section 2.1.1, 3rd paragraph, last sentence, has a bit more about the usage of the ID Token. How about extending that as follows: An OpenID Connect server returns an additional ID Token that contains claims about the authentication of the user by an Authorization Server. The ID Token can potentially include other optional claims about the user, e.g. the SIP URI, that will be consumed by the UAC and later used to register with the SIP Registrar. More inline regarding some of the comments. Regards, Rifaat On Wed, Apr 22, 2020 at 12:28 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > HI Roman, > > Thank You for the review! In this reply I will address most of your > COMMENT issues. The DISCUSS issue, and a couple of COMMENT issues, will b= e > addressed in a separate reply. > > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - > > >** Section 1.3. Per =E2=80=9CAccess Tokens could be represented in = one of > the above > >two formats.=E2=80=9D, if not one of these two formats, then which o= ther ones? > > I suggest to change "could" to "can". > How about replacing "could be" with "are"? > --- > > > ** Section 2.1.1. Per =E2=80=9CAn OpenID Connect server =E2=80=A6= =E2=80=9D, based on the > flows > > depicted in Figure 1 and 2, how the OpenID Connect server fits isn= =E2=80=99t > clear. > > We will address this in the reply that addresses the DISCUSS, as the > issues are related. > > The AS could be a typical OAuth Authorization Server or an OpenID Provide= r (OP). Would changing the "AS" column in the figures to "AS/OP" help? > --- > > > ** Section 2.1.2. Per =E2=80=9CEndpoints that support this specifi= cation > MUST support > > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and > protecting access > > tokens when they are included in SIP requests, unless some other > mechanism is > > used to guarantee that only authorized SIP endpoints have access to > the access > > token.=E2=80=9D -- is it the =E2=80=9Cuse of=E2=80=9D or =E2=80=9Cs= upport for=E2=80=9D JWT that is required > if there > > isn=E2=80=99t an alternative? Section 5 uses similar language. > > "MUST use" is more correct. > > --- > > > ** Section 2.1.3. Per =E2=80=9CNote that, if there were multiple c= hallenges > with > > different schemes, then the UAC may be able to successfully retry > the request > > using non-Bearer credentials.=E2=80=9D, would that decision be made= based on > local > > policy? > > Yes. That is described in Section 2.1.1.: > > "If the UAC receives a 401/407 response with multiple WWW- > Authenticate/Proxy-Authenticate header fields, providing challenges > using different authentication schemes for the same realm, the UAC > selects one or more of the provided schemes (based on local policy) > and provides credentials for those schemes." > > --- > > > ** Section 5. Should the use of the scope parameter be noted (or > RECOMMENDED) > > to narrow the utility of the token? > > I will refer this to Rifaat. > > How about adding the following sentence to this section: The SIP Registrar SHOULD include a Scope parameter to control the minimum level of service access the client is required to obtain from the Authorization Server to be able to register with the SIP Registrar. Regards, Rifaat > --- > > > ** Editorial Nits: > > Section 1.3. Typo. s/usualy/usually/ > > Will fix. > > > Section 7. Typo. s/coversion/conversion/ > > Will fix. > > --- > > Regards, > > Christer > > > > --0000000000008f5c7e05a3e4e0d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Thanks for t= he review!

Regarding the DISCUSS:

Section 2.1.1, 3rd paragraph, last sentence, has a bit more about = the usage of the ID Token. How about extending that as follows:

An OpenID Connect server returns an additional ID Token that contain= s claims about
the authentication of the user by an A= uthorization Server. The ID Token can potentially
inc= lude other optional claims about the user, e.g. the SIP URI, that will be c= onsumed by
the UAC and later used to register with th= e SIP Registrar.

More inli= ne regarding some of the comments.

Regards,
<= div>=C2=A0Rifaat



On Wed, Apr 22, 2020 at 12:28 PM Ch= rister Holmberg <chris= ter.holmberg@ericsson.com> wrote:
HI Roman,

Thank You for the review! In this reply I will address most of your COMMENT= issues. The DISCUSS issue, and a couple of COMMENT issues, will be address= ed in a separate reply.

=C2=A0 =C2=A0 -------------------------------------------------------------= ---------
=C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 -------------------------------------------------------------= ---------

=C2=A0 =C2=A0 >** Section 1.3.=C2=A0 Per =E2=80=9CAccess Tokens could be= represented in one of the above
=C2=A0 =C2=A0 >two formats.=E2=80=9D, if not one of these two formats, t= hen which other ones?

=C2=A0 =C2=A0 I suggest to change "could" to "can".
=

How about replacing "could be" w= ith "are"?=C2=A0


---

=C2=A0 =C2=A0 > ** Section 2.1.1.=C2=A0 Per =E2=80=9CAn OpenID Connect s= erver =E2=80=A6=E2=80=9D, based on the flows
=C2=A0 =C2=A0 > depicted in Figure 1 and 2, how the OpenID Connect serve= r fits isn=E2=80=99t clear.

We will address this in the reply that addresses the DISCUSS, as the issues= are related.

The AS could be a typical OAuth Authorization Server or an= OpenID Provider (OP).
Would changing the "AS" column in the f= igures to "AS/OP" help?

= =C2=A0
---

=C2=A0 =C2=A0 > ** Section 2.1.2.=C2=A0 Per =E2=80=9CEndpoints that supp= ort this specification MUST support
=C2=A0 =C2=A0 > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding a= nd protecting access
=C2=A0 =C2=A0 > tokens when they are included in SIP requests, unless so= me other mechanism is
=C2=A0 =C2=A0 > used to guarantee that only authorized SIP endpoints hav= e access to the access
=C2=A0 =C2=A0 > token.=E2=80=9D -- is it the =E2=80=9Cuse of=E2=80=9D or= =E2=80=9Csupport for=E2=80=9D JWT that is required if there
=C2=A0 =C2=A0 > isn=E2=80=99t an alternative?=C2=A0 Section 5 uses simil= ar language.

"MUST use" is more correct.

---

=C2=A0 =C2=A0 > ** Section 2.1.3.=C2=A0 Per =E2=80=9CNote that, if there= were multiple challenges with
=C2=A0 =C2=A0 > different schemes, then the UAC may be able to successfu= lly retry the request
=C2=A0 =C2=A0 > using non-Bearer credentials.=E2=80=9D, would that decis= ion be made based on local
=C2=A0 =C2=A0 > policy?

Yes. That is described in Section 2.1.1.:

=C2=A0 =C2=A0"If the UAC receives a 401/407 response with multiple WWW= -
=C2=A0 =C2=A0Authenticate/Proxy-Authenticate header fields, providing chall= enges
=C2=A0 =C2=A0using different authentication schemes for the same realm, the= UAC
=C2=A0 =C2=A0selects one or more of the provided schemes (based on local po= licy)
=C2=A0 =C2=A0and provides credentials for those schemes."

---

=C2=A0 =C2=A0 > ** Section 5.=C2=A0 Should the use of the scope paramete= r be noted (or RECOMMENDED)
=C2=A0 =C2=A0 > to narrow the utility of the token?

=C2=A0 =C2=A0 I will refer this to Rifaat.


How about adding the following sentenc= e to this section:

The SIP R= egistrar SHOULD include a Scope parameter to control the minimum level of s= ervice access=C2=A0
the client i= s required to obtain from the Authorization Server to be able to register w= ith the SIP Registrar.
<= div>
Regards,
=C2=A0Rifaat

=C2=A0
---

=C2=A0 =C2=A0 > ** Editorial Nits:
=C2=A0 =C2=A0 > Section 1.3.=C2=A0 Typo. s/usualy/usually/

=C2=A0 =C2=A0 Will fix.

=C2=A0 =C2=A0 > Section 7.=C2=A0 Typo.=C2=A0 s/coversion/conversion/

=C2=A0 =C2=A0 Will fix.

---

Regards,

Christer



--0000000000008f5c7e05a3e4e0d0-- From nobody Thu Apr 23 05:25:19 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9CE3A19F3; Thu, 23 Apr 2020 05:25:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158764471329.2667.9393862154508419446@ietfa.amsl.com> Date: Thu, 23 Apr 2020 05:25:13 -0700 Archived-At: Subject: [sipcore] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sipcore-sip-token-authnz-13=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 12:25:14 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- hank you for the work put into this document. The document is clear, easy to read and quite useful even if examples would be welcome. Please find below just two NITs. I hope that this helps to improve the document, Regards, -éric == NITS == -- section 1.3 -- Expanding "JWT" on first use will be improve readability. And, it is expanded in section 5 ;) -- section 6 -- Probably better to write "This document has no IANA consideration; just to be clear." From nobody Thu Apr 23 05:29:31 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C633A1A0D; Thu, 23 Apr 2020 05:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 YoMTVRIEm6Fa; Thu, 23 Apr 2020 05:29:23 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60044.outbound.protection.outlook.com [40.107.6.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D203A1A09; Thu, 23 Apr 2020 05:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eNYOWSeUg+yHEpchAmFuQ9BVZalqNqtKJh8M3x0jL2KupbGG4TiBlvP7UG3JmKp0FfTlEq208gZMPQ2PE0H/E/keOYbYJxz7ZpaA4MT+VH0gZohqP0wNiNxS+sAiYmD29YpxmQ75c3uV4oRokExm7RHXr/g1fAEty1rUR3FCH7+/bmYCwh9bb+Dtti+e3JtwyWUPbb+m753v2Bhg4ocsMLpj99JGYwS8kpbtgZYWdVP3kSMOBrHw7nJHm65AUE6wkYiNoQpVaR2oMwPwF2XBKAHWYqtH5iNpKHtzttejnvDXJZC861jvNRHOd/avYX1IfZnTGFlP+gtla6JBKyCMZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e+u+7tJ1UBt7HW2KRfv6s5W4MtfIoFaSB3wS8wxqd4I=; b=OKyctmJQy6wKkjbWmerZbR+IY/hrllTp8OCfjZUi2xQJWSFPYLrMt6ZH0QtrG/igAbB5FoHxIEHfRxefVM1oBoGsDfR6wCYy4L2IYOX8ilmYSA9De6LkNrFf8bipWu9GRe7TbrGrAUb8nQSI69BiM2ast8MAf2sQ2DucynLQg0e4hUYIwj3vGasMQ3/dTxN81oc5F/WmJFSffJQSpBw9XPzTmMsUqKndjcK/IipnOObzhCbln0KxFTmXshZV2mdmNNfL1PpFRKdgZhM7WtEbqH6Td5BfQbuSHFWsKNqr4qCHaxXFI+nWKSWlTyiwAikfNgbovLc2HiismLzq7chitw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e+u+7tJ1UBt7HW2KRfv6s5W4MtfIoFaSB3wS8wxqd4I=; b=meUw9Omr7CDyVk+9ElZipjDns2mSwAnACU8o10WBXA3lceysiP4GzQreFaQr4AfgVL5679JqwQkb+49vCb8LN8OLA48n0aXMJHiUCQOrJzbMO+bEE6Y7NjGF0VeAa90krXDwdzo6eodBK0JDqgLNYLjIFUCziX/EQUxVw5jcqc8= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6050.eurprd07.prod.outlook.com (2603:10a6:208:11c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Thu, 23 Apr 2020 12:29:20 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.012; Thu, 23 Apr 2020 12:29:20 +0000 From: Christer Holmberg To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtc2lw?= =?utf-8?Q?core-sip-token-authnz-13:_(with_COMMENT)?= Thread-Index: AQHWGWpFNi/4qF2+kki/ev0CiEt4+aiG1RUA Date: Thu, 23 Apr 2020 12:29:20 +0000 Message-ID: <67CFA224-826D-4D2F-B1FD-B82F7C6F6008@ericsson.com> References: <158764471329.2667.9393862154508419446@ietfa.amsl.com> In-Reply-To: <158764471329.2667.9393862154508419446@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98afda3f-a054-4ea3-8a7c-08d7e781f2f6 x-ms-traffictypediagnostic: AM0PR07MB6050: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(376002)(346002)(396003)(4744005)(76116006)(91956017)(6506007)(4326008)(6486002)(33656002)(66476007)(66946007)(86362001)(26005)(66556008)(44832011)(54906003)(64756008)(66446008)(110136005)(2616005)(2906002)(316002)(36756003)(478600001)(71200400001)(5660300002)(186003)(6512007)(224303003)(8936002)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bf0NkWLNm/WQ1DG5zydB3fP05PwmcET79XVZhPYVLAUeAYPaOuilqqdp8hPymwOQJr8m34GhfsX7/B93xEgY9WqE8cUMqduRGKmwxDP/qcaqJKYW59uY+u+0upv5RqTdBgd2fowqcs01LkEr+cR2KOf/YwLzTtKgCYb7QyDAV4DPIxTD87rshAljv4gJlbehHOUVtUtHuSozvRwB5pZA7djsDHgsSNPBuIFK+M+ro3XXdUormjYNFJI3nly1NQcRb9o8e7jcHK+Gu0AL5l7wmk3Ut4XaIqg+CvbX2IMX9FMOeFezcGRcjKzDTBu3mFEWZg2lxpT1Jga33gjiFh74Gh9liII3s4S0ClRm9mohUAgYTpMFvcSbwOK7TA7/DVrwzyEGN+AArYWmNY5gMbRTACHGDv5QAND+DnV+mhdKewDmqk2nJMuFLDiyITA3jXTP x-ms-exchange-antispam-messagedata: ieqcugFgmRxDJTw2Aw2PAXdxT3flF9Sm+xtpY6eBpuMySp8WEM78sYo3oRc30QEg6Pioxkx45MU03Y8+yi8Nz82s0Z2pKTF+czkv8dDLQpznd4j7o6yGh+CsSJOwsNkGk/fZh/hn1fBWF9ODaw8OFA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <939C98B1EC2E614A86C967100010089E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98afda3f-a054-4ea3-8a7c-08d7e781f2f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 12:29:20.8485 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Eut6UiwRiaUN0wna/IQD6GmFF9YH7oCf8rk+TuQBDg+woOdFsxqE3jfzlzE9d59GL0S5iSqj/bLygsqHcoaJOJxVqdVMVwTDFi+3UltH86s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6050 Archived-At: Subject: Re: [sipcore] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sipcore-sip-token-authnz-13=3A_=28with_COMMENT=29?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 12:29:26 -0000 SGkgw4lyaWMsDQoNClRoYW5rIFlvdSBmb3IgdGhlIHJldmlldyEgUGxlYXNlIHNlZSBpbmxpbmUu DQogICAgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICAgIA0KICAgID4gaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9jdW1l bnQuIFRoZSBkb2N1bWVudCBpcyBjbGVhciwgZWFzeSB0bw0KICAgID4gcmVhZCBhbmQgcXVpdGUg dXNlZnVsIGV2ZW4gaWYgZXhhbXBsZXMgd291bGQgYmUgd2VsY29tZS4NCiAgICA+DQogICAgPiBQ bGVhc2UgZmluZCBiZWxvdyBqdXN0IHR3byBOSVRzLg0KICAgID4gDQogICAgPiBJIGhvcGUgdGhh dCB0aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KICAgID4NCiAgICA+IFJlZ2Fy ZHMsDQogICAgPg0KICAgID4gLcOpcmljDQogICAgPg0KICAgID4gPT0gTklUUyA9PQ0KICAgID4N CiAgICA+IC0tIHNlY3Rpb24gMS4zIC0tDQogICAgPiBFeHBhbmRpbmcgIkpXVCIgb24gZmlyc3Qg dXNlIHdpbGwgYmUgaW1wcm92ZSByZWFkYWJpbGl0eS4gQW5kLCBpdCBpcyBleHBhbmRlZA0KICAg ID4gaW4gc2VjdGlvbiA1IDspDQogICAgDQogICAgV2lsbCBkby4NCg0KICAgID4gLS0gc2VjdGlv biA2IC0tDQogICAgPiBQcm9iYWJseSBiZXR0ZXIgdG8gd3JpdGUgIlRoaXMgZG9jdW1lbnQgaGFz IG5vIElBTkEgY29uc2lkZXJhdGlvbjsganVzdCB0byBiZQ0KICAgID4gY2xlYXIuIg0KDQogICAg QmFzZWQgb24gdGhlIElBTkEgcmV2aWV3LCB3ZSBpbnRlbmQgdG8gcmVtb3ZlIHRoZSBTZWN0aW9u IGFsbCB0b2dldGhlci4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KDQo= From nobody Thu Apr 23 06:32:07 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4393A05A7; Thu, 23 Apr 2020 06:31:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158764871303.10314.304431984379935875@ietfa.amsl.com> Date: Thu, 23 Apr 2020 06:31:53 -0700 Archived-At: Subject: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 13:31:53 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think these resolution for this is rather straight forward, however the implications of one is going to break deployed implementations. 1. Section 4: This is rather straight forward to resolve but you do have a SIP syntax violation in these rules. challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) bearer-cln = realm / scope / authz-server / error / auth-param authz-server = "authz_server" EQUAL authz-server-value authz-server-value = https-URI realm = auth-param = scope = error = https-URI = So RFC 3261 defines the Challenge construct as: challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge Where this extension needs to match the syntax of the other-challenge: other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) Where we need to look at: auth-param = auth-param-name EQUAL ( token / quoted-string ) Please note what is included in the "token" rule. token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) the allowed syntax for https-URI in RFC 7230 is: https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Which include both "/", "?" and "#" that are not allowed in token. Thus, the URI included in the authz-server-value MUST be converted into a quoted-string matching syntax rule. 2. In addition should not the "authz_server" be registered in the https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 registry? From nobody Thu Apr 23 06:46:37 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1824D3A07A2; Thu, 23 Apr 2020 06:46:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158764958890.26081.9155918989165894263@ietfa.amsl.com> Date: Thu, 23 Apr 2020 06:46:28 -0700 Archived-At: Subject: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 13:46:30 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think these resolution for this is rather straight forward, however the implications of one is going to break deployed implementations. 1. Section 4: This is rather straight forward to resolve but you do have a SIP syntax violation in these rules. challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) bearer-cln = realm / scope / authz-server / error / auth-param authz-server = "authz_server" EQUAL authz-server-value authz-server-value = https-URI realm = auth-param = scope = error = https-URI = So RFC 3261 defines the Challenge construct as: challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge Where this extension needs to match the syntax of the other-challenge: other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) Where we need to look at: auth-param = auth-param-name EQUAL ( token / quoted-string ) Please note what is included in the "token" rule. token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) the allowed syntax for https-URI in RFC 7230 is: https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Which include both "/", "?" and "#" that are not allowed in token. Thus, the URI included in the authz-server-value MUST be converted into a quoted-string matching syntax rule. 2. In addition should not the "authz_server" be registered in the https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 registry? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- An additional thing. Is SIP directly using the HTTP Authentication Schemes IANA registry (https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#authschemes) or does it have its own tucked away somewhere? And if it is the former, should its references for the "bearer" add this RFC as a reference? From nobody Thu Apr 23 12:25:21 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E11B33A12BD; Thu, 23 Apr 2020 12:25:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158766991009.32224.6031347936963900326@ietfa.amsl.com> Date: Thu, 23 Apr 2020 12:25:10 -0700 Archived-At: Subject: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 19:25:15 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss. The "Bearer" authentication challenge includes the address (or name?) of an authorization server to contact to obtain tokens, as mentioned in multiple places in the document (noted in the COMMENT section). Our experience in the OAuth world has shown that several classes of vulnerabilities are possible when the client blindly attempt to use any provided AS, and that a whitelist of "allowed" or "trusted" ASes is needed for secure operation. I believe that the same is true for the SIP usage, and we should mention this requirement explicitly. Section 1.2 tries to apply the OAuth confidential/public client distinction to SIP UACs, but it does so in a non-analogous fashion: the OAuth distinction is for the client's ability to protect credentials that identify the client itself; the usage in this document refers to protecting *user* credentials and obtained tokens. I don't think that it's appropriate to invoke the OAuth terminology when using it for a different meaning. Both Public and Confidential OAuth clients are capable of providing the necessary protections for *user* credentials (though they are of course not guaranteed to do so), which leaves me unclear on what the intended requirements actually are. Section 2.3 states that: When a proxy wishes to authenticate a received request, it MUST search the request for Proxy-Authorization header fields with 'realm' parameters that match its realm. It then MUST successfully validate https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not expected to have a sequence or list of Proxy-Authorization header fields present in a single request that are intended to be interpreted by different proxies. Is this text compatible with that part of RFC 7235? Furthermore, I didn't find much guidance in 7235 or 3261 about when to include the "realm" parameter in Proxy-Authorization; do we want to give any guidance here? (That is to say, I almost didn't find where it was even defined as possible to do so...) I'm also not sure if we're attempting to profile RFC 6749 and always require a refresh token to be issued, or just have some editorial tweaks to make to avoid suggesting that we do have such a requirement (noted in the COMMENT). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 The OpenID Connect 1.0 specification [OPENID] defines a simple identity layer on top of the OAuth 2.0 protocol, which enables clients to verify the identity of the user based on the Please make it clear that these are OAuth/OIDC clients, not SIP clients. Section 1.3 OAuth 2.0 doesn't require the issuance of a Refresh token, but the discussion here implies that for the SIP case there will always be a refresh token. If we're profiling 6749 in this manner, we should be more explicit about the requirement to issue refresh tokens. * ID Token: this token contains the SIP URI and other user-specific details that will be consumed by the UAC. nit: I don't think we should use the definite article in "the SIP URI" since we haven't discussed any such SIP URI usage yet. That is, we should say what it's used for, e.g., "a SIP URI associated with the user". * Structured Token: a token that consists of a structured object that contains the claims associated with the token, e.g. JWT as defined in [RFC7519]. nit: comma after "e.g.". * Reference Token: a token that consists of a random string that is used to obtain the details of the token and its associated claims, as defined in [RFC6749]. It doesn't technically have to be random (though in practice it should contain signficant random elements); "opaque" might be better wording. Section 1.4.1 Perhaps Figure 1 could include some indication that steps 5 and 6 are optional/do not always occur (in the case when the access token is a self-contained JWT)? In step [2], the registrar challenges the UA, by sending a SIP 401 (Unauthorized) response to the REGISTER request. In the response, the registrar includes information about the AS to contact in order to obtain a token. The UAC needs to have a preconfigured whitelist of acceptable ASes in order to avoid directing the user's credentials to malicious sites. The registrar validates the access token. If the access token is a reference token, the registrar MAY perform an introspection [RFC7662], as in steps [5] and [6], in order to obtain more information about the access token and its scope, per [RFC7662]. I think we could tighten up the normative language a bit here. In particular, the registrar MUST validate the token in some fashion; for reference tokens, the main ways to do that are either inspection or (essentially) being the party that issued the token in the first place. Otherwise, after the registrar validates the token to make sure it was signed by a trusted entity, it inspects its claims and acts upon it. I think we can also be more specific than "a trusted entity" -- in this flow, it looks like the registrar should know exactly which entity should have signed the token in question (for the user in question), and should not accept a signed token from a different entity that happens to be trusted to issue other tokens. Section 1.4.2 (Similarly, Figure 2 could note that steps 3 and 4 do not always occur, and the text about token validation should remain parallel between examples.) Section 2 I note that RFC 3261 explicitly disclaims any definition of authorization systems, which is not true for this document, given that OAuth is an authorization system :) Section 2.1.1 Required) response with a Proxy-Authenticate header field. If the WWW-Authenticate or Proxy-Authenticate header field indicates "Bearer" scheme authentication and contains an address to an authorization server, the UAC contacts the authorization server in order to obtain tokens, and includes the requested scopes, based on a local configuration (Figure 1). [whitelist of allowed ASes, again] The detailed OAuth2 procedure to authenticate the user and obtain these tokens is out of scope of this document. The address of the authorization server might already be known to the UAC via configuration. In which case, the UAC can contact the authorization server for tokens before it sends a SIP request (Figure 2). nit: I think that "in which case" functions as a conjunction, which makes this an incomplete sentence. The tokens returned to the UAC depend on the type of authorization server (AS): an OAuth AS provides an access token and refresh token [RFC6749]. The UAC provides the access token to the SIP servers to Again, this implies that refresh tokens are always issued; RFC 6749 is quite clear that "issuing a refresh token is optional at the discretion of the authorization server". authorize UAC's access to the service. The UAC uses the refresh token only with the AS to get a new access token and refresh token before the expiry of the current access token (see [RFC6749], section (New refresh token is also optional.) 1.5 Refresh Token for details). An OpenID Connect server returns an additional ID-Token containing the SIP URI and other user-specific details that will be consumed by the UAC. [same comment as above about "the SIP URI".] If the UAC receives a 401/407 response with multiple WWW- Authenticate/Proxy-Authenticate header fields, providing challenges using different authentication schemes for the same realm, the UAC selects one or more of the provided schemes (based on local policy) and provides credentials for those schemes. RFC 3261 seems to be written in a world that assumed that Basic and Digest are the only defined HTTP authentication schemes, and since it prohibits Basic, that there would only be one authentication challenge (type) possible. This text righly acknowledges that we are opening the field up and could have cases where multiple authentication schemes are possible; however, it goes even further and admits the possibility of using them simultaneously. It seems like this places an onus on us to give some indication of the semantics when multiple schemes are used at the same time. Do the authenticated identities need to match? Or are we asserting that both/all identities are consenting to the request in question? (If we don't have a concrete use case in mind, perhaps the "or more" is just opening a box that we don't need to open right now.) Section 2.1.2 access to it. Endpoints that support this specification MUST support encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access tokens when they are included in SIP requests, unless some other mechanism is used to guarantee that only authorized SIP endpoints have access to the access token. I think we may want "MUST support" (always) and "MUST use, unless some other mechanism". I'd also suggest a quick note that TLS remains fine for protecting the UAC/AS interaction where the refresh token is used. Whatever is done, please harmonize with Section 5 that has essentially the same text. Section 2.1.3 Based on local policy, the UAC MAY include an access token that has been used for another binding associated with the same Address Of Record (AOR) in the request. Just to check: there's no real privacy considerations with such use, as its the same parties interacting and there are other identifiers (e.g., IP addresses) to confirm that it's the same client communicating to the server? Also, is it clear what will be done (new token request) when the MAY is not heeded? Section 2.1.4 The text here just talks about "a valid access token" and similar, without saying a whole lot about it being related in any way to the specifics of the authentication challenge. Is there something useful to say about, e.g., the token in question having been issued by the authorization server indicated in the challenge? Section 2.2 authorization credentials acceptable to it, it SHOULD challenge the request by sending a 401 (Unauthorized) response. To indicate that it is willing to accept an access token as a credential, the UAS/ Registrar MUST include a Proxy-Authentication header field in the response that indicates "Bearer" scheme and includes an address of an nit(?): I'd consider just making this a declarative statement, a la "the UAS/registrar includes a Proxy-Authentication header field with the "Bearer" scheme to indicate that it is willing to accept an access token as a credential" (but that wording is incomplete and would need to be fleshed out a bit more). authorization server from which the originator can obtain an access token. nit: "address of" an AS, does that mean bare IP address only or is a DNS name okay? [RFC7519]. If the token provided is an expired access token, then the UAS MUST reply with 401 Unauthorized, as defined in section 3 of [RFC6750]. If the validation is successful, the UAS/Registrar can continue to process the request using normal SIP procedures. If the validation fails, the UAS/Registrar MUST reject the request. Is "expired" the only case that should get a 401 vs. outright rejection, as stated here? Section 2.3 sending a 407 (Proxy Authentication Required) response. To indicate that it is willing to accept an access token as a credential, the proxy MUST include a Proxy-Authentication header field in the response that indicates "Bearer" scheme and includes an address to an [same comment as above about normative vs. declarative statement] Also, please keep the text parallel between sections -- this copy has at least one nit ("address to an" vs. "address of an"). Section 3 If an access token is encoded as a JWT, it might contain a list of claims [RFC7519], some registered and some application-specific. The I don't think there's a question of whether a JWT will contain a list of claims :) Maybe "If the access token is encoded as a JWT, it will contain a list of claims [RFC7519], which may include both registered and application-specific claims"? Section 4 This section claims to cover WWW-Authenticate. What specification will the SIP use of Bearer for Authorization operate under? challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) side note: is there a mnemonic for the "cln" in "bearer-cln"? bearer-cln = realm / scope / authz-server / error / auth-param nit: realm is already included in auth-param, though I don't see a harm in calling it out explicitly. realm = auth-param = RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of these; we could perhaps short-circuit the chain and say "defined in RFC 7235". Section 5 We should probably note that SIP makes much heavier use of proxies than is common in the web world of OAuth. I'm happy to see that some privacy considerations are being added in response to Barry's review. Section 8 I think RFCs 8252 and 8414 could be just informative. From nobody Thu Apr 23 12:51:51 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237093A12E0; Thu, 23 Apr 2020 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 FcgO8g_i_GR4; Thu, 23 Apr 2020 12:51:47 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130088.outbound.protection.outlook.com [40.107.13.88]) (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 945B43A12DF; Thu, 23 Apr 2020 12:51:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YA63X7LqONii0ofNtmIrFd75ll1OBdwTpEOjVNgNdf/i2Zz+GU2p5fb4PQrbUNaLx0T2IuI3p5KFM04ce6iicFtEHc2w8tZOEU2NXQ6FiucTu+178ICLKVQNRALyWcFaM/IcrCqIb7q3ZpDazxDinfZ1sWR7kaDjAdNcmKcxhmArxYv/5/MHCYiaZWN/5Fv6TTdEV/d12UQ1lBrdVtd7uXYLpVGmA3C33Jb/Qyn4/25gLPQVBHX9Zz4UYZDl3/ep+nMBmbhw6zDDAMt03tzsNphumIeHXXB+FNed+IvhhRg8u6QIFaYQ8Z/BpJJg8BRk4Klj58VXW8TsYvdtSA0fXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kMjwLA+rcVI1xx+yAeRxjN++9G00LFy1B1h7VnR1XCU=; b=iisVQkXYGfwW9bW9Aus4wZ0uYd3B7CvBPbSEC+Bls4jZLcDTxrl2wDOsUrnMkIGbVS0RlW/5U0jg6w/8KfnMZtkNZKl8Px7bQs4WwmThkC2lQsSCot91mfT1cCr4a27FvLU77p/5iKEC59ZsQMpeWpZgjTxlzF6BvT9CzoZEXgGmd71rYTIj8+xOh0DpwHZQSPLSeVJFfC28ckImtlNUmt0H9d6icnw/brRYc2EdWXJCmZQ8x8H1SQ+vzpR1TshJrbyvNwkcc5qkQZwLdBq9QpsnboSSBwn9mHXiy0u7GEq2YLdP+1zC+O+woKzTw0Ol7aB0bMPHBAWa/95nIrJzWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kMjwLA+rcVI1xx+yAeRxjN++9G00LFy1B1h7VnR1XCU=; b=lGngz58/QUq7vGsB6JHtKUaLzrHTYf4QSkYZuOYhQLT5kHAhu0JFnZ0LZ7VdVFFLhTE4cnTFneoEspMqLJmT7wlafT2eOmasD/g4VOtohICHSt62vYZ+kPiA0d9n5VYBfeoMNktPT7KeqGJd1cP4y+eSa8ZQ3403Z4GxcYMUrco= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB4004.eurprd07.prod.outlook.com (2603:10a6:208:47::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Thu, 23 Apr 2020 19:51:43 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.020; Thu, 23 Apr 2020 19:51:43 +0000 From: Christer Holmberg To: Magnus Westerlund , The IESG CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) Thread-Index: AQHWGXWcgJbZMnSFkkaFWKmg220ZdaiHUJiA Date: Thu, 23 Apr 2020 19:51:43 +0000 Message-ID: <2927EF2C-8BF7-44EB-ABEB-63BD52EE9ADC@ericsson.com> References: <158764958890.26081.9155918989165894263@ietfa.amsl.com> In-Reply-To: <158764958890.26081.9155918989165894263@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a226b16a-d2bd-4c05-ae49-08d7e7bfbfc7 x-ms-traffictypediagnostic: AM0PR07MB4004:|AM0PR07MB4004: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(186003)(26005)(966005)(5660300002)(54906003)(110136005)(316002)(81156014)(86362001)(91956017)(33656002)(8936002)(2906002)(66946007)(76116006)(66476007)(71200400001)(66446008)(64756008)(66556008)(8676002)(6486002)(478600001)(6512007)(2616005)(4326008)(44832011)(36756003)(6506007)(21314003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LWFm3lbcWsEri6YZrT9jZOK6K9RCXu0Xxxbr4GkxWkPy2BfdB2TnTmWc5IaLeskYFWsPmeSYVgphiD9b0PeD0gjzOiKJS+g731GD3kX2xtVZEOrCrhiyY/wFUHYo0hHiOY16e7H4RkabgKNE+iwM+ql2P5igdFR0x7S88ap8ebqt6M4oFnTEhOQ3qkwZgvjxXPP+EKnzq9aofCG6lm+Yna3KqFtmSBQZx7cj3oet2s1XIKdtgE6ed0abx4lRuSEJqYzGURQ+t/CGOEE8LWxIQRlKlCAQlM/CX3gPip8B5M9tZFuS4l6+3k1EIghR+KAMDiCoMdTPG1HNFjLJyS0jfej0suJ9ze1zlLr70+psYILGrBZXK/8lc0PdKpubDGIKpMRpcO5/tNxYhoB12/EZVZlRSWKv50V/jrNVPS4LU+ahaCPXjb5E32EeXXMy70zSa+gM8B7izXmROp5Yj0YR6Dur7vixqJSVjF8UCDRj3bloY5TrHPazJlazxhHVItoCdBuJ8GM82bc9a6pBgTixvUbG0HV227qpdkiZfhZc7f/WsTQ0hksCtslsWh2NYGCi x-ms-exchange-antispam-messagedata: aRf81Eykc5h3XDT8xJE6QLLuvAkBGtY2HyATxwjLav/kx3axcaUOMbl7fMvpAEXVW23qPXUI8q53k8euMFP0HaiDgLoT/Ml60OOWnJzTGR00/zrLP+i0GwqSnCNBAKtX0/DbO95qrJsW7Ha7aP136g== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a226b16a-d2bd-4c05-ae49-08d7e7bfbfc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 19:51:43.7279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: syEAgHDs9PZ5JyQBsGO8KQ70Q0VQKTiVTihcFfkMf2zMwTlnYw34AftLuHvTx92C5nLTO/OF4icdtDV0sriF9cUtDVBsndVbkyaHB4bycOc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4004 Archived-At: Subject: Re: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 19:51:50 -0000 SGkgTWFnbnVzLA0KDQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXchIFBsZWFzZSBzZWUgaW5saW5l Lg0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBESVNDVVNTOg0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICANCiAgICA+IEkgdGhpbmsgdGhlc2UgcmVzb2x1dGlvbiBmb3IgdGhpcyBpcyByYXRo ZXIgc3RyYWlnaHQgZm9yd2FyZCwgaG93ZXZlciB0aGUNCiAgICA+IGltcGxpY2F0aW9ucyBvZiBv bmUgaXMgZ29pbmcgdG8gYnJlYWsgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zLg0KICAgID4NCiAg ICA+IDEuIFNlY3Rpb24gNDoNCiAgICA+DQogICAgPiBUaGlzIGlzIHJhdGhlciBzdHJhaWdodCBm b3J3YXJkIHRvIHJlc29sdmUgYnV0IHlvdSBkbyBoYXZlIGEgU0lQIHN5bnRheA0KICAgID4gdmlv bGF0aW9uIGluIHRoZXNlIHJ1bGVzLg0KICAgID4NCiAgICA+ICAgICAgIGNoYWxsZW5nZSAgPS8g ICgiQmVhcmVyIiBMV1MgYmVhcmVyLWNsbiAqKENPTU1BIGJlYXJlci1jbG4pKQ0KICAgID4gICAg ICAgYmVhcmVyLWNsbiA9IHJlYWxtIC8gc2NvcGUgLyBhdXRoei1zZXJ2ZXIgLyBlcnJvciAvIGF1 dGgtcGFyYW0NCiAgICA+ICAgICAgIGF1dGh6LXNlcnZlciA9ICJhdXRoel9zZXJ2ZXIiIEVRVUFM IGF1dGh6LXNlcnZlci12YWx1ZQ0KICAgID4gICAgICAgYXV0aHotc2VydmVyLXZhbHVlID0gaHR0 cHMtVVJJDQogICAgPiAgICAgICByZWFsbSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQogICAgPiAg ICAgICBhdXRoLXBhcmFtID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCiAgICA+ICAgICAgIHNjb3Bl ID0gPGRlZmluZWQgaW4gUkZDNjc0OT4NCiAgICA+ICAgICAgIGVycm9yID0gPGRlZmluZWQgaW4g UkZDNjc0OT4NCiAgICA+ICAgICAgIGh0dHBzLVVSSSA9IDxkZWZpbmVkIGluIFJGQzcyMzA+DQog ICAgPg0KICAgID4gU28gUkZDIDMyNjEgZGVmaW5lcyB0aGUgQ2hhbGxlbmdlIGNvbnN0cnVjdCBh czoNCiAgICA+DQogICAgPiBjaGFsbGVuZ2UgICAgICAgICAgID0gICgiRGlnZXN0IiBMV1MgZGln ZXN0LWNsbiAqKENPTU1BIGRpZ2VzdC1jbG4pKSAgLyBvdGhlci1jaGFsbGVuZ2UNCiAgICA+DQog ICAgPiBXaGVyZSB0aGlzIGV4dGVuc2lvbiBuZWVkcyB0byBtYXRjaCB0aGUgc3ludGF4IG9mIHRo ZSBvdGhlci1jaGFsbGVuZ2U6DQogICAgPg0KICAgID4gb3RoZXItY2hhbGxlbmdlICAgICA9ICBh dXRoLXNjaGVtZSBMV1MgYXV0aC1wYXJhbSAgKihDT01NQSBhdXRoLXBhcmFtKQ0KICAgID4NCiAg ICA+IFdoZXJlIHdlIG5lZWQgdG8gbG9vayBhdDoNCiAgICA+IGF1dGgtcGFyYW0gICAgICAgID0g IGF1dGgtcGFyYW0tbmFtZSBFUVVBTCAgKCB0b2tlbiAvIHF1b3RlZC1zdHJpbmcgKQ0KICAgID4N CiAgICA+IFBsZWFzZSBub3RlIHdoYXQgaXMgaW5jbHVkZWQgaW4gdGhlICJ0b2tlbiIgcnVsZS4N CiAgICA+ICAgICAgdG9rZW4gICAgICAgPSAgMSooYWxwaGFudW0gLyAiLSIgLyAiLiIgLyAiISIg LyAiJSIgLyAiKiINCiAgICA+ICAgICAgICAgICAgICAgICAgICAgLyAiXyIgLyAiKyIgLyAiYCIg LyAiJyIgLyAifiIgKQ0KICAgID4NCiAgICA+IHRoZSBhbGxvd2VkIHN5bnRheCBmb3IgaHR0cHMt VVJJIGluIFJGQyA3MjMwIGlzOg0KICAgID4NCiAgICA+ICAgIGh0dHBzLVVSSSA9ICJodHRwczoi ICIvLyIgYXV0aG9yaXR5IHBhdGgtYWJlbXB0eSBbICI/IiBxdWVyeSBdICBbICIjIiBmcmFnbWVu dCBdDQogICAgPg0KICAgID4gV2hpY2ggaW5jbHVkZSBib3RoICIvIiwgIj8iIGFuZCAiIyIgdGhh dCBhcmUgbm90IGFsbG93ZWQgaW4gdG9rZW4uIFRodXMsIHRoZQ0KICAgID4gVVJJIGluY2x1ZGVk IGluIHRoZSBhdXRoei1zZXJ2ZXItdmFsdWUgIE1VU1QgYmUgY29udmVydGVkIGludG8gYSBxdW90 ZWQtc3RyaW5nDQogICAgPiBtYXRjaGluZyBzeW50YXggcnVsZS4NCiAgICANCiAgICBZb3UgYXJl IGNvcnJlY3QuIFdlIGN1cnJlbnRseSByZWZlcmVuY2UgaHR0cHMtVVJJIGluIFJGQyA3MjMwLCBi dXQgdGhlIGRlZmluaXRpb24gaW4gNzIzMCBkb2VzIG5vdCBwbGFjZSBxdW90ZXMgYXJvdW5kIGl0 Lg0KDQogICAgVGhlIHNhbWUgYXBwbGllcyB0byBzY29wZSBhbmQgZXJyb3IuDQoNCiAgICBTbywg d2UgbmVlZCB0byBmaXg6DQoNCk9MRDoNCg0KICAgICBhdXRoei1zZXJ2ZXIgPSAiYXV0aHpfc2Vy dmVyIiBFUVVBTCBhdXRoei1zZXJ2ZXItdmFsdWUNCg0KICAgICBzY29wZSA9IDxkZWZpbmVkIGlu IFJGQzY3NDk+DQogICAgICBlcnJvciA9IDxkZWZpbmVkIGluIFJGQzY3NDk+DQoNCk5FVzoNCg0K ICAgICBhdXRoei1zZXJ2ZXIgPSAiYXV0aHpfc2VydmVyIiBFUVVBTCBEUVVPVEUgYXV0aHotc2Vy dmVyLXZhbHVlIERRVU9URQ0KDQogICAgIHNjb3BlLWNsbiA9IERRVU9URSBzY29wZSBEUVVPVEUN CiAgICAgc2NvcGUgPSA8ZGVmaW5lZCBpbiBSRkM2NzQ5Pg0KICAgICBlcnJvci1jbG4gPSBEUVVQ VEUgZXJyb3IgRFFVT1RFDQogICAgIGVycm9yID0gPGRlZmluZWQgaW4gUkZDNjc0OT4NCg0KDQoo SSBub3RlZCB0aGF0IHRoYXQgQmVuamFtaW4gaGFzIHNvbWUgY29tbWVudHMgcmVnYXJkaW5nIHRo ZSByZWZlcmVuY2VkIFJGQ3MgZm9yIHRoZSBwYXJhbWV0ZXIgdmFsdWVzLCBidXQgSSB3aWxsIGFk ZHJlc3MgdGhhdCBpbiB0aGUgcmVwbHkgdG8gaGlzIHJldmlldy4pDQoNCg0KLS0tLS0NCg0KICAg ID4gMi4gSW4gYWRkaXRpb24gc2hvdWxkIG5vdCB0aGUgImF1dGh6X3NlcnZlciIgYmUgcmVnaXN0 ZXJlZCBpbiB0aGUNCiAgICA+IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3NpcC1w YXJhbWV0ZXJzL3NpcC1wYXJhbWV0ZXJzLnhodG1sI3NpcC1wYXJhbWV0ZXJzLTEyDQogICAgPiBy ZWdpc3RyeT8NCiAgICANCiAgICBJIGd1ZXNzIHNvLiBBbmQsIHRoZW4gSSBndWVzcyB3ZSBhbHNv IG5lZWQgdG8gcmVnaXN0ZXIgInNjb3BlIiBhbmQgImVycm9yIi4NCg0KICAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICBDT01NRU5UOg0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICA+IEFuIGFkZGl0 aW9uYWwgdGhpbmcuDQogICAgPg0KICAgID4gSXMgU0lQIGRpcmVjdGx5IHVzaW5nIHRoZSBIVFRQ IEF1dGhlbnRpY2F0aW9uIFNjaGVtZXMgSUFOQSByZWdpc3RyeQ0KICAgID4gKGh0dHBzOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2h0dHAtYXV0aHNjaGVtZXMvaHR0cC1hdXRoc2NoZW1lcy54 aHRtbCNhdXRoc2NoZW1lcykNCiAgICA+IG9yIGRvZXMgaXQgaGF2ZSBpdHMgb3duIHR1Y2tlZCBh d2F5IHNvbWV3aGVyZT8gQW5kIGlmIGl0IGlzIHRoZSBmb3JtZXIsIHNob3VsZA0KICAgID4gaXRz IHJlZmVyZW5jZXMgZm9yIHRoZSAiYmVhcmVyIiBhZGQgdGhpcyBSRkMgYXMgYSByZWZlcmVuY2U/ DQogICAgDQogICAgU0lQIHVzZXMgdGhlIEhUVFAgcmVnaXN0cnkuDQoNCiAgIChUaGUgU0lQIHJl Z2lzdHJ5IGRvZXMgcmVnaXN0ZXIgYSAiZGlnZXN0IiB2YWx1ZSwgYnV0IHRoYXQgaXMgZm9yIHRo ZSBTZWN1cml0eS1YWFggaGVhZGVycyBkZWZpbmVkIGluIFJGQyAzMzI5KQ0KDQpSZWdhcmRzLA0K DQpDaHJpc3RlciAgICAgICAgICANCiAgICANCiAgICANCg0K From nobody Thu Apr 23 13:52:35 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F533A0842; Thu, 23 Apr 2020 13:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=kM+0fZjU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wU5wVr9a 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 4cYukjl3oBPH; Thu, 23 Apr 2020 13:52:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB913A0849; Thu, 23 Apr 2020 13:52:30 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 68AC05C0859; Thu, 23 Apr 2020 16:52:29 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 23 Apr 2020 16:52:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=T sYPsoZgzELI3rD9UVW1JcRunO5Q6AWRDCsxRRoVc+M=; b=kM+0fZjUUuO3xkTD+ s1rFyZM4UIEOxymDmZniWKgmIRcD9jxBGweavM3N0dJGEkwCx0leOF0n99/5EVsC YHvmXxb7ng7L4Muvbqs08W4PXIiPv8pt7pSZxQYVxH3ArbipFCkFYm33pS6N8/cJ cX79YADjw28Q5+b4H5Xzkcy5nlGchzLvGYMJCsbvu36rG9VOV6u8GMGD6WaWjoFe x+Y+Ef87nZbvO4xssQmAjx3cb1prIxMAW10e/6iv1c+2TVDPipBlGxKPOZyYIF81 gqVsjAZXESoBhuY2wDIw2aRFNtt45unVy+Pn8L624GikjkOP+ZEItoIEcjJC1e3f yRtfQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=TsYPsoZgzELI3rD9UVW1JcRunO5Q6AWRDCsxRRoVc +M=; b=wU5wVr9aq0XGuUPJfxynFdNdwMHN9/fdGVlKjPHaBw9TTEEG7TtyhRH/m oXbfIGWlKnnQP7QVZBSyJEaCol4Y7VJGQN+tKw6z9EEktPmEbjurIyuuxZY0WX1n PA4HG1iNtz0uORnhQzWkJRak24YYboA9kvCLFj1KiBQWtyggnA8OzB2E9bPW45Gm A6XEEXDtqxKtvKkqnEBh7JkzG855KCygbZsGc1X0MvrMycgg670XGgAK6CPxSH/N cbkqkkz4BcfYr5jVk0CU7r8+4RdhlkZxve1WD9QrGOa2C0qealhJVRBLNGjUz6WM gSMlgAvVnGgqlrJRVeqKO2MK0+9Pw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeelgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeeknecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtoh hophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.78]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B2003065CAC; Thu, 23 Apr 2020 16:52:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: Date: Thu, 23 Apr 2020 16:52:28 -0400 Cc: Christer Holmberg , "gen-art@ietf.org" , last-call@ietf.org, SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: References: <158682405513.12380.9514894653338982196@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [sipcore] [Gen-art] Genart last call review of draft-ietf-sipcore-sip-token-authnz-12 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 20:52:33 -0000 Linda, thanks for your review. Christer, thanks for your response. I = entered a No Objection ballot. Alissa > On Apr 14, 2020, at 2:41 PM, Linda Dunbar = wrote: >=20 > Christer,=20 >=20 > Thank you for the quick response. Your updated wording are much more = clear.=20 >=20 > Linda >=20 > -----Original Message----- > From: Christer Holmberg =20 > Sent: Tuesday, April 14, 2020 9:25 AM > To: Linda Dunbar ; gen-art@ietf.org > Subject: Re: [Gen-art] Genart last call review of = draft-ietf-sipcore-sip-token-authnz-12 >=20 > Hi Linda, >=20 > Thank You for the review! Please see inline. >=20 >> Section 1.4.1: the first paragraph is very confusing. The steps = after the >> figure is much clear on what to be done. It is better to delete the = the >> sub-phrase "... where the registrar informs the UAC about the = authorization ... >> ". The actual step is actually the UAC sends the request to = Registrar and get >> the response .. as described in the steps after the Figure. >=20 > The purpose of the first sentence is to highlight the difference = between 1.4.1 and 1.4.2: In 1.4.1 we describe the case where Registrars = informs the UAC about the AS, while in 1.4.2 we describe the case where = the AS is preconfigured in the UAC. >=20 > However, I do agree that the sentence is very long and confusing. = Perhaps we could remove the "in a 401 response to the REGISTER request" = part?=20 >=20 > --- >=20 >> Section 2.1.2 the paragraph before the last one (Page 8), I can' = parse the >> sentence. What do you want to say? >=20 > I assume you mean Section 2.1.1? >=20 >> "If the UAC receives a 401/407 response with multiple = WWWAuthenticate/ >> Proxy-Authenticate header fields, providing challenges >> using different authentication schemes for the same realm, the UAC >> provides credentials for one or more of the schemes that it = supports, >> based on local policy." >=20 > We want to say that, if the UAC receives multiple challenges, with = different authentication schemes, for the same realm, the UAC picks one = (and provides credentials) based on local policy. >=20 > Would it be more clear if we said something like: >=20 > "....for the same realm, the UAC selects one or more of the provided = schemes (based on local policy) and provides credentials for those = schemes." >=20 > --- >=20 >> Section 2.1.3: What is AOR? >=20 > Address-of-Record. >=20 > We will enhance the abbreviation, and add a reference to RFC 3261. >=20 > --- >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Apr 23 13:55:19 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8343A085A; Thu, 23 Apr 2020 13:55:17 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 l2xOnFSglohr; Thu, 23 Apr 2020 13:55:15 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770075.outbound.protection.outlook.com [40.107.77.75]) (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 ED7433A0858; Thu, 23 Apr 2020 13:55:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ka1fQub1pSqewuf8Y63ncF/scJMcDeK3188VdNsFpgUsuXNZiccs7iqo0VDRDfrpKUf+EE15ttC2V0Opx4tDz4CSXJ24ym4dXPtWJz2us0f5K6tEbdIaRVVJ2roTNX74dzD4XySYSnzjEKI/zOZZod5Lf2IfX7f00GGs9WLSWYz4p+q+DGypKCEx8zufp8lNFIL7VnRtNdLLoH8QjQrbMOIM0FAL4p810YsGo/RWwUXMXLdRFNYIjMOyUelWx00klybjtcjaZjYHFmU4/juOuYoaSG4M5C8IjR/OY0naznnKdpdfkEyC5/IDiUOfiPpCgCKJHCHB2L+388Hg1bI/3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y3VvQ+uVKh4olEqMrALWDnxCEEw/G0U9vBwt0Y0Dm6w=; b=gKV8836c3Z6cH8wXsBzBITHHrNdYfNPyLBdR7rhPNwLbhuH3I+1fYPIqBrkiGTMWpiW8UOipNzL/oDTjEi1ZijLI4yrBayVvJoumsiIhv/Tv5By/SjXQqBaHvC/N4ViHVcHHPbragOLLygZZxdwZe/KWhgzop0Uq1yGEIgFbInnNZcTdRQACtgXLFeRJyZPIEC6ZRlQjS35gB/Z1AvfxyP4pe4+XgWD9KnSvzZBScJxqXeSoKqiGoEYU/h6zPcjdVto6LGgXdwhR5KVQwp5y3fRtciWfZBATuuwNVs8XfqibS8zAXnq1M+OikGUE3Yp7h7AAXs1GXrsKm22TBoOnuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=mit.edu smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y3VvQ+uVKh4olEqMrALWDnxCEEw/G0U9vBwt0Y0Dm6w=; b=i5/+Z/EksyUvkvK67HleF6F5Op8Wo4tzTr/mwRtgk8pS8LfxB/v5uoANS5zvCWFS7u9VtvKxASof7GvnG2ay77HnuQ2NNbdAUGhM0VH2eFVdHsYR9G49v5Qm+SXjHvgvFJneZG5eBRshgoLBK6/3+bQYKQORIPb9d/6e+BvnqW8= Received: from SN4PR0401CA0009.namprd04.prod.outlook.com (2603:10b6:803:21::19) by DM5PR12MB1833.namprd12.prod.outlook.com (2603:10b6:3:111::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Thu, 23 Apr 2020 20:55:13 +0000 Received: from SN1NAM02FT012.eop-nam02.prod.protection.outlook.com (2603:10b6:803:21:cafe::dd) by SN4PR0401CA0009.outlook.office365.com (2603:10b6:803:21::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Thu, 23 Apr 2020 20:55:13 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT012.mail.protection.outlook.com (10.152.72.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Thu, 23 Apr 2020 20:55:12 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 03NKtAl2026722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2020 16:55:10 -0400 To: Benjamin Kaduk , The IESG Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> Date: Thu, 23 Apr 2020 16:55:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158766991009.32224.6031347936963900326@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(10009020)(136003)(376002)(39860400002)(396003)(346002)(46966005)(7596003)(70586007)(70206006)(186003)(2906002)(956004)(336012)(2616005)(82740400003)(47076004)(26005)(4326008)(5660300002)(31686004)(786003)(110136005)(8936002)(356005)(53546011)(36906005)(478600001)(316002)(86362001)(8676002)(75432002)(246002)(31696002)(82310400002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4bd70fae-a461-47a2-ebbc-08d7e7c89e14 X-MS-TrafficTypeDiagnostic: DM5PR12MB1833: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 03827AF76E X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ADmjEegTs/xS8xidHFGW40DM86H8M2+xL5NRKYUpBErutcte99Z27P14rzW+AfjunQzALeL0MaIVk7DF6KS6YOH21hpG0ArCqHVJy/Coc8uXpkOumB4mVxpxvVR2+pyHWlvrvuKeYJY5kPXfJrdUnKhw2eaHfq8Ncx0t94BBHk/LaMvAXWSuAC5cy0jAlhmrzdxO36rUrFfQZm4vTii3qQaR0S1AU3jpG4mcY1pejlmR2709/QnGde8xsdH20X8rGcorrm+648oxEgjqVtjZBZog/WtxEj6O1KVTve4jYkEUlVV5JO5t3ZJtmQZrpJXe/sThFgYC2C9SwT2LQf6JEpjMXBkXsB9eQ4jSyZVEC+MPN7m6HpepZllX4E4CHl8Guc32hr065eg9aKbGn56RQnp1637AS2k0pQ3Yf4dusC5F6DUy6/dpWSS2mh2ZPu+PNOAJtWuKWW0FV96edkKGB7PdyPEKsgS2xFwQXXmg0GeaD0J/Eg1DI1emuaqvwdX28yq9IuKezIwr/Y0N5vt9Nw== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 20:55:12.5111 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4bd70fae-a461-47a2-ebbc-08d7e7c89e14 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1833 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 20:55:18 -0000 On 4/23/20 3:25 PM, Benjamin Kaduk via Datatracker wrote: > RFC 3261 seems to be written in a world that assumed that Basic and Digest > are the only defined HTTP authentication schemes, and since it prohibits > Basic, that there would only be one authentication challenge (type) > possible. This text righly acknowledges that we are opening the field up > and could have cases where multiple authentication schemes are possible; > however, it goes even further and admits the possibility of using them > simultaneously. It seems like this places an onus on us to give some > indication of the semantics when multiple schemes are used at the same time. > Do the authenticated identities need to match? Or are we asserting that > both/all identities are consenting to the request in question? (If we don't > have a concrete use case in mind, perhaps the "or more" is just opening a > box that we don't need to open right now.) I pushed quite a bit on this area during the development of this draft. As you note we are definitely expanding into an area that wasn't anticipated in RFC3261. The whole topic of how authentication works in the presence of multiple schemes and realms could use some elaboration. The authors of this draft were reluctant to get into those weeds. It isn't clear what the right mechanism is to do that. I had a (non-sip) use case in mind: a site I visit allows you register directly with the site, resulting in an ability to use Digest credentials. The login page on the site offers that as an option, along with the alternatives of Facebook, Google, and maybe some others. I can see something just like that for SIP. Presumably it would be achieved by challenging with Digest and also with Bearer for Facebook, Google, etc. The UAC then "chooses" by delegating the choice to the user through the UI. This is also the case where the "whitelist" really resides within the end user's head rather than in the UAC. It gets harder for devices that might be connecting when there is no end user present. This can happen with a "phone" that attempts to be permanently registered to its sip server so that in can receive incoming calls. If it reboots in the middle of the night there is no user handy to interact in the authentication process. It all has to take place using credentials preconfigured (or cached) in the UAC. Thanks, Paul From nobody Thu Apr 23 14:05:27 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699A43A13C6; Thu, 23 Apr 2020 14:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 SAfHWn0p7Vef; Thu, 23 Apr 2020 14:03:57 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2088.outbound.protection.outlook.com [40.107.22.88]) (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 763943A13C5; Thu, 23 Apr 2020 14:03:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d5J89bjFPXiiT/vlYgpHIXKOMtWd6l7JGbZub35E0eQuI4R496HM9W3RYYDrvJvMcp2oEMGQ96pmeoyctMeMZRvKCWo8a0p716+XeYQC5KwRGP+N694pxJ1CIeXgDdKKuhTx79y0Fal0kE/Zz20giNMEvFAyQAWYFz8JH8v9jdFgDIOxTpy6Eptyf9f3ezQJb3+06A4Z4jl5rL1tKkrzJaW1nYLVck0AsIAqUGu+UrkCq1AnGAJPNN0SEvPNG97FNEiQtPd8KEfzANeFOuysHeNXuKH/xk//615HduoSRm7a9zFeEg+2wtVDL7hZiYGTkUSnMdb13BnWEWsoCf/eRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7o2vGqCCpWVx1gKIKxJFNybqCEK7C8K3hkmURIK1X7E=; b=GuMBb0/mx9TrVmM+KzpBxmD8B1LhXlBM0lzxP8kZY2wcoSplNr+RK7UCRTKqAqH41NOTn0ZukCkw8y+97FKETZUxladd5KdbBzZHuvg7t1x91FXb2b7jJZRrxCKZQHua4fZxA9cBDgiQyP7/tSDZO1gSqBbjy3LGesCzHt8Kqfl5ZwVmCAbBMv8gpkJzxIMnfYB7BfmbDM0sQ71N17i1OUDIWyvnTRkGOSp5IUA6EVeDcmHjD9e4/80/WHK1MKGSuJUliXqcW8QRNGk0RLtcgaoLTce6ekEufmez18qeObaLI2pj9h5wcfPz0O/hce0Y7OpFBxgCQ25OeUnVnVF5Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7o2vGqCCpWVx1gKIKxJFNybqCEK7C8K3hkmURIK1X7E=; b=lDcxMnABWcZ5DBWazjlNXYfcshN87WZbCT2i0kw/fWISUaN/+7tfcoHGhUKLn5DhyYdXi1aBIK0sPrpAEnaQjNzxTJN/a7z+r1+zyR9Cef/zX/LIIMbzzuYQGJFKw8twVpX6wb9WNRjO963EMl2eorHOYh2rN9l7hxK5LttrW5E= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6162.eurprd07.prod.outlook.com (2603:10a6:208:f8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Thu, 23 Apr 2020 21:03:54 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.020; Thu, 23 Apr 2020 21:03:54 +0000 From: Christer Holmberg To: Benjamin Kaduk , The IESG CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT Thread-Index: AQHWGbKxu2gQq0gnZkyF4LBa/O+0ag== Date: Thu, 23 Apr 2020 21:03:53 +0000 Message-ID: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5679fd6-0e89-4034-bcbe-08d7e7c9d4c3 x-ms-traffictypediagnostic: AM0PR07MB6162: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03827AF76E x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(186003)(110136005)(86362001)(5660300002)(2616005)(44832011)(6486002)(36756003)(316002)(26005)(91956017)(54906003)(478600001)(76116006)(66556008)(64756008)(66446008)(66476007)(6506007)(66946007)(6512007)(2906002)(30864003)(4326008)(33656002)(71200400001)(8676002)(81156014)(8936002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q0eDvapGUMHv6hcqlg2GlnVNPK6Iy9CC4r9VwKe8xoE5bAMQ+t++SR8OdZQbPKE4EVnPNHV+zB5mzikTZ/24ImqpPyL7GGOEowNdb0CBeVWBgY5WfLhPNp6+eNf6ENgSzviKqC3wcCY24evMiPO0+Dg+P33pLH21uTwrTQVObXH3HevH4NUF+viuM6Un9yTV8xQ8Rioxa8asbzz4DJn8sKuMt7XBsjGud860kMF+qb4jMkACfJc0m7poAsn+dzstxRBypSCgVMwcORnt4R6dSW0QOrNt7cNgBIo5+V6UN+zxS/ILbf+ANgOiz1JgrFtpp1c9S2EXwgmGdYZw6xVmBqQUkhiv9/dOQGtTgZDkppQwv9ciPCaO8HomaD9nwHFqiPfc2m4DVeGml/p3r1UQx22fVvJL4t31PM+d6PJFEBMHM00e6bCkjW8Hj0WYJQG8 x-ms-exchange-antispam-messagedata: o/MZegi7RhgJBvQ77hjXQ0SzRd3wGWpfe7ONqOogWpa9Y4k/Toh3mcdb2kUdaysjYcYw98CtrD03C+a5Q4ReM5lNtMlIeX04ceeiXwchnEebIHGB0t7J2Agz/iezRasnLf+vOGAfCA6m8LqGbtHhdg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <13245F0DC1831C4BAF004E32896CBC36@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5679fd6-0e89-4034-bcbe-08d7e7c9d4c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2020 21:03:53.8585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RblpseXrA+TTpdvLdlhTdn8qazr6+fdx5QU1EnVb3ME1lybc5MwG7m2W9rkICgyleoP4DO5aB0lLya1rbTPsfTrvVwD6aP0eFaAy2aZUOEY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6162 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 21:04:00 -0000 SGkgQmVuamFtaW4sDQoNClRoYW5rIFlvdSBmb3IgdGhlIHJldmlldyEgSW4gdGhpcyByZXBseSBJ IHdpbGwgYWRkcmVzcyBzb21lIG9mIHlvdXIgQ09NTUVOVCBpc3N1ZXMsIGFuZCBpbmRpY2F0ZSB0 aGUgb25lcyB0aGF0IEkgd2FudCBSaWZhYXQgdG8gYWRkcmVzcy4gWW91ciBESVNDVVNTIHdpbGwg YmUgYWRkcmVzc2VkIGluIGEgc2VwYXJhdGUgcmVhbHkuDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQo+ICAgIFNlY3Rpb24gMQ0KPiAg ICANCj4gICAgICAgVGhlIE9wZW5JRCBDb25uZWN0IDEuMCBzcGVjaWZpY2F0aW9uIFtPUEVOSURd IGRlZmluZXMgYSBzaW1wbGUNCj4gICAgICAgaWRlbnRpdHkgbGF5ZXIgb24gdG9wIG9mIHRoZSBP QXV0aCAyLjAgcHJvdG9jb2wsIHdoaWNoIGVuYWJsZXMNCj4gICAgICAgY2xpZW50cyB0byB2ZXJp ZnkgdGhlIGlkZW50aXR5IG9mIHRoZSB1c2VyIGJhc2VkIG9uIHRoZQ0KPiAgICANCj4gICAgUGxl YXNlIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGVzZSBhcmUgT0F1dGgvT0lEQyBjbGllbnRzLCBub3Qg U0lQIGNsaWVudHMuDQogIA0KSSdsbCBsZWF2ZSB0aGlzIGZvciBSaWZhYXQuDQoNCi0tLQ0KICAN Cj4gICAgU2VjdGlvbiAxLjMNCj4gICAgDQo+ICAgIE9BdXRoIDIuMCBkb2Vzbid0IHJlcXVpcmUg dGhlIGlzc3VhbmNlIG9mIGEgUmVmcmVzaCB0b2tlbiwgYnV0IHRoZQ0KPiAgICBkaXNjdXNzaW9u IGhlcmUgaW1wbGllcyB0aGF0IGZvciB0aGUgU0lQIGNhc2UgdGhlcmUgd2lsbCBhbHdheXMgYmUg YSByZWZyZXNoDQo+ICAgIHRva2VuLiAgSWYgd2UncmUgcHJvZmlsaW5nIDY3NDkgaW4gdGhpcyBt YW5uZXIsIHdlIHNob3VsZCBiZSBtb3JlIGV4cGxpY2l0DQo+ICAgIGFib3V0IHRoZSByZXF1aXJl bWVudCB0byBpc3N1ZSByZWZyZXNoIHRva2Vucy4NCg0KSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRo ZSBpbnRlbnRpb24gaXMgdG8gc2F5IHRoYXQgdGhlcmUgd2lsbCBhbHdheXMgYmUgYSByZWZyZXNo IHRva2VuLiBCdXQsIEknbGwgbGVhdmUgdGhpcyBmb3IgUmlmYWF0Lg0KDQo+ICAgICAgICogIElE IFRva2VuOiB0aGlzIHRva2VuIGNvbnRhaW5zIHRoZSBTSVAgVVJJIGFuZCBvdGhlciB1c2VyLXNw ZWNpZmljDQo+ICAgICAgICAgIGRldGFpbHMgdGhhdCB3aWxsIGJlIGNvbnN1bWVkIGJ5IHRoZSBV QUMuDQo+ICAgIA0KPiAgICBuaXQ6IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHVzZSB0aGUgZGVm aW5pdGUgYXJ0aWNsZSBpbiAidGhlIFNJUCBVUkkiIHNpbmNlDQo+ICAgIHdlIGhhdmVuJ3QgZGlz Y3Vzc2VkIGFueSBzdWNoIFNJUCBVUkkgdXNhZ2UgeWV0LiAgVGhhdCBpcywgd2Ugc2hvdWxkIHNh eQ0KPiAgICB3aGF0IGl0J3MgdXNlZCBmb3IsIGUuZy4sICJhIFNJUCBVUkkgYXNzb2NpYXRlZCB3 aXRoIHRoZSB1c2VyIi4NCiAgICANCkknbGwgbGVhdmUgdGhpcyBmb3IgUmlmYWF0Lg0KDQo+ICAg ICAgICogIFN0cnVjdHVyZWQgVG9rZW46IGEgdG9rZW4gdGhhdCBjb25zaXN0cyBvZiBhIHN0cnVj dHVyZWQgb2JqZWN0DQo+ICAgICAgICAgIHRoYXQgY29udGFpbnMgdGhlIGNsYWltcyBhc3NvY2lh dGVkIHdpdGggdGhlIHRva2VuLCBlLmcuICBKV1QgYXMNCj4gICAgICAgICAgZGVmaW5lZCBpbiBb UkZDNzUxOV0uDQo+ICAgIA0KPiAgICBuaXQ6IGNvbW1hIGFmdGVyICJlLmcuIi4NCiAgDQpXaWxs IGJlIGZpeGVkLg0KICANCj4gICAgICAgKiAgUmVmZXJlbmNlIFRva2VuOiBhIHRva2VuIHRoYXQg Y29uc2lzdHMgb2YgYSByYW5kb20gc3RyaW5nIHRoYXQgaXMNCj4gICAgICAgICAgdXNlZCB0byBv YnRhaW4gdGhlIGRldGFpbHMgb2YgdGhlIHRva2VuIGFuZCBpdHMgYXNzb2NpYXRlZCBjbGFpbXMs DQo+ICAgICAgICAgIGFzIGRlZmluZWQgaW4gW1JGQzY3NDldLg0KPiAgICANCj4gICAgSXQgZG9l c24ndCB0ZWNobmljYWxseSBoYXZlIHRvIGJlIHJhbmRvbSAodGhvdWdoIGluIHByYWN0aWNlIGl0 IHNob3VsZA0KPiAgICBjb250YWluIHNpZ25maWNhbnQgcmFuZG9tIGVsZW1lbnRzKTsgIm9wYXF1 ZSIgbWlnaHQgYmUgYmV0dGVyIHdvcmRpbmcuDQogIA0KSSdsbCBsZWF2ZSB0aGlzIGZvciBSaWZh YXQuDQogIA0KPiAgICBTZWN0aW9uIDEuNC4xDQo+ICAgIA0KPiAgICBQZXJoYXBzIEZpZ3VyZSAx IGNvdWxkIGluY2x1ZGUgc29tZSBpbmRpY2F0aW9uIHRoYXQgc3RlcHMgNSBhbmQgNiBhcmUNCj4g ICAgb3B0aW9uYWwvZG8gbm90IGFsd2F5cyBvY2N1ciAoaW4gdGhlIGNhc2Ugd2hlbiB0aGUgYWNj ZXNzIHRva2VuIGlzIGENCj4gICAgc2VsZi1jb250YWluZWQgSldUKT8NCiAgDQpJJ2xsIGxlYXZl IHRoaXMgZm9yIFJpZmFhdC4NCiAgDQo+ICAgICAgIEluIHN0ZXAgWzJdLCB0aGUgcmVnaXN0cmFy IGNoYWxsZW5nZXMgdGhlIFVBLCBieSBzZW5kaW5nIGEgU0lQIDQwMQ0KPiAgICAgICAoVW5hdXRo b3JpemVkKSByZXNwb25zZSB0byB0aGUgUkVHSVNURVIgcmVxdWVzdC4gIEluIHRoZSByZXNwb25z ZSwNCj4gICAgICAgdGhlIHJlZ2lzdHJhciBpbmNsdWRlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUg QVMgdG8gY29udGFjdCBpbiBvcmRlcg0KPiAgICAgICB0byBvYnRhaW4gYSB0b2tlbi4NCj4gICAg DQo+ICAgIFRoZSBVQUMgbmVlZHMgdG8gaGF2ZSBhIHByZWNvbmZpZ3VyZWQgd2hpdGVsaXN0IG9m IGFjY2VwdGFibGUgQVNlcyBpbiBvcmRlcg0KPiAgICB0byBhdm9pZCBkaXJlY3RpbmcgdGhlIHVz ZXIncyBjcmVkZW50aWFscyB0byBtYWxpY2lvdXMgc2l0ZXMuDQogIA0KVGhpcyBpcyByZWxhdGVk IHRvIHlvdXIgRElTQ1VTUywgc28gaXQgd2lsbCBiZSBhZGRyZXNzZWQgYXMgcGFydCBvZiB0aGF0 Lg0KDQo+ICAgICAgIFRoZSByZWdpc3RyYXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4uICBJ ZiB0aGUgYWNjZXNzIHRva2VuIGlzIGENCj4gICAgICAgcmVmZXJlbmNlIHRva2VuLCB0aGUgcmVn aXN0cmFyIE1BWSBwZXJmb3JtIGFuIGludHJvc3BlY3Rpb24NCj4gICAgICAgW1JGQzc2NjJdLCBh cyBpbiBzdGVwcyBbNV0gYW5kIFs2XSwgaW4gb3JkZXIgdG8gb2J0YWluIG1vcmUNCj4gICAgICAg aW5mb3JtYXRpb24gYWJvdXQgdGhlIGFjY2VzcyB0b2tlbiBhbmQgaXRzIHNjb3BlLCBwZXIgW1JG Qzc2NjJdLg0KPiAgICANCj4gICAgSSB0aGluayB3ZSBjb3VsZCB0aWdodGVuIHVwIHRoZSBub3Jt YXRpdmUgbGFuZ3VhZ2UgYSBiaXQgaGVyZS4NCj4gICAgSW4gcGFydGljdWxhciwgdGhlIHJlZ2lz dHJhciBNVVNUIHZhbGlkYXRlIHRoZSB0b2tlbiBpbiBzb21lIGZhc2hpb247IGZvcg0KPiAgICBy ZWZlcmVuY2UgdG9rZW5zLCB0aGUgbWFpbiB3YXlzIHRvIGRvIHRoYXQgYXJlIGVpdGhlciBpbnNw ZWN0aW9uIG9yDQo+ICAgIChlc3NlbnRpYWxseSkgYmVpbmcgdGhlIHBhcnR5IHRoYXQgaXNzdWVk IHRoZSB0b2tlbiBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+ICANCj4gICAgICAgT3RoZXJ3aXNlLCBh ZnRlciB0aGUgcmVnaXN0cmFyIHZhbGlkYXRlcyB0aGUgdG9rZW4gdG8gbWFrZSBzdXJlIGl0DQo+ ICAgICAgIHdhcyBzaWduZWQgYnkgYSB0cnVzdGVkIGVudGl0eSwgaXQgaW5zcGVjdHMgaXRzIGNs YWltcyBhbmQgYWN0cyB1cG9uDQo+ICAgICAgIGl0Lg0KPiAgICANCj4gICAgSSB0aGluayB3ZSBj YW4gYWxzbyBiZSBtb3JlIHNwZWNpZmljIHRoYW4gImEgdHJ1c3RlZCBlbnRpdHkiIC0tIGluIHRo aXMNCj4gICAgZmxvdywgaXQgbG9va3MgbGlrZSB0aGUgcmVnaXN0cmFyIHNob3VsZCBrbm93IGV4 YWN0bHkgd2hpY2ggZW50aXR5IHNob3VsZA0KPiAgICBoYXZlIHNpZ25lZCB0aGUgdG9rZW4gaW4g cXVlc3Rpb24gKGZvciB0aGUgdXNlciBpbiBxdWVzdGlvbiksIGFuZCBzaG91bGQgbm90DQo+ICAg IGFjY2VwdCBhIHNpZ25lZCB0b2tlbiBmcm9tIGEgZGlmZmVyZW50IGVudGl0eSB0aGF0IGhhcHBl bnMgdG8gYmUgdHJ1c3RlZCB0bw0KPiAgICBpc3N1ZSBvdGhlciB0b2tlbnMuDQogICAgDQpUaGUg dGV4dCBpbiBTZWN0aW9uIDIuMi4gbWFuZGF0ZXMgdGhlIHZhbGlkYXRpb246DQoNCiAgICJXaGVu IGEgVUFTL1JlZ2lzdHJhciByZWNlaXZlcyBhIFNJUCByZXF1ZXN0IHRoYXQgY29udGFpbnMgYW4N CiAgIEF1dGhvcml6YXRpb24gaGVhZGVyIGZpZWxkIHdpdGggYW4gYWNjZXNzIHRva2VuLCB0aGUg VUFTL1JlZ2lzdHJhcg0KICAgTVVTVCB2YWxpZGF0ZSB0aGUgYWNjZXNzIHRva2VuLC4uLiINCg0K SSBkb24ndCB0aGluayB3ZSBzaG91bGQgcHV0IHRvbyBtdWNoIG5vcm1hdGl2ZSB0ZXh0IGludG8g dGhlIGV4YW1wbGUgZmxvd3MuDQoNCj4gICAgU2VjdGlvbiAxLjQuMg0KPiAgICANCj4gICAgKFNp bWlsYXJseSwgRmlndXJlIDIgY291bGQgbm90ZSB0aGF0IHN0ZXBzIDMgYW5kIDQgZG8gbm90IGFs d2F5cyBvY2N1ciwgYW5kDQo+ICAgIHRoZSB0ZXh0IGFib3V0IHRva2VuIHZhbGlkYXRpb24gc2hv dWxkIHJlbWFpbiBwYXJhbGxlbCBiZXR3ZWVuIGV4YW1wbGVzLikNCiAgICANCkknbGwgbGVhdmUg dGhpcyBmb3IgUmlmYWF0Lg0KDQotLS0tDQoNCj4gICAgU2VjdGlvbiAyDQo+ICAgIA0KPiAgICBJ IG5vdGUgdGhhdCBSRkMgMzI2MSBleHBsaWNpdGx5IGRpc2NsYWltcyBhbnkgZGVmaW5pdGlvbiBv ZiBhdXRob3JpemF0aW9uDQo+ICAgIHN5c3RlbXMsIHdoaWNoIGlzIG5vdCB0cnVlIGZvciB0aGlz IGRvY3VtZW50LCBnaXZlbiB0aGF0IE9BdXRoIGlzIGFuDQo+ICAgIGF1dGhvcml6YXRpb24gc3lz dGVtIDopDQoNClJGQyAzMjYxIG9ubHkgc2F5cyB0aGF0IHRoZSBSRkMgZG9lcyBub3QgcmVjb21t ZW5kIG9yIGRpc2N1c3MgYW55IGF1dGhvcml6YXRpb24gc3lzdGVtLg0KDQo+ICAgIFNlY3Rpb24g Mi4xLjENCj4gICAgDQo+ICAgICAgIFJlcXVpcmVkKSByZXNwb25zZSB3aXRoIGEgUHJveHktQXV0 aGVudGljYXRlIGhlYWRlciBmaWVsZC4gIElmIHRoZQ0KPiAgICAgICBXV1ctQXV0aGVudGljYXRl IG9yIFByb3h5LUF1dGhlbnRpY2F0ZSBoZWFkZXIgZmllbGQgaW5kaWNhdGVzDQo+ICAgICAgICJC ZWFyZXIiIHNjaGVtZSBhdXRoZW50aWNhdGlvbiBhbmQgY29udGFpbnMgYW4gYWRkcmVzcyB0byBh bg0KPiAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIFVBQyBjb250YWN0cyB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgaW4NCj4gICAgICAgb3JkZXIgdG8gb2J0YWluIHRva2VucywgYW5k IGluY2x1ZGVzIHRoZSByZXF1ZXN0ZWQgc2NvcGVzLCBiYXNlZCBvbiBhDQo+ICAgICAgIGxvY2Fs IGNvbmZpZ3VyYXRpb24gKEZpZ3VyZSAxKS4NCj4gICAgDQo+ICAgIFt3aGl0ZWxpc3Qgb2YgYWxs b3dlZCBBU2VzLCBhZ2Fpbl0NCiAgDQpXaWxsIGJlIGFkZHJlc3NlZCB3aGVuIHRoZSBESVNDVVNT IGlzIGFkZHJlc3NlZC4NCg0KPiAgICAgICBUaGUgZGV0YWlsZWQgT0F1dGgyIHByb2NlZHVyZSB0 byBhdXRoZW50aWNhdGUgdGhlIHVzZXIgYW5kIG9idGFpbg0KPiAgICAgICB0aGVzZSB0b2tlbnMg aXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuICBUaGUgYWRkcmVzcyBvZiB0aGUNCj4g ICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbWlnaHQgYWxyZWFkeSBiZSBrbm93biB0byB0aGUg VUFDIHZpYQ0KPiAgICAgICBjb25maWd1cmF0aW9uLiAgSW4gd2hpY2ggY2FzZSwgdGhlIFVBQyBj YW4gY29udGFjdCB0aGUgYXV0aG9yaXphdGlvbg0KPiAgICAgICBzZXJ2ZXIgZm9yIHRva2VucyBi ZWZvcmUgaXQgc2VuZHMgYSBTSVAgcmVxdWVzdCAoRmlndXJlIDIpLg0KPiAgICANCj4gICAgbml0 OiBJIHRoaW5rIHRoYXQgImluIHdoaWNoIGNhc2UiIGZ1bmN0aW9ucyBhcyBhIGNvbmp1bmN0aW9u LCB3aGljaCBtYWtlcw0KPiAgICB0aGlzIGFuIGluY29tcGxldGUgc2VudGVuY2UuDQogIA0KVGhl IHRleHQgd2FzIHN1Z2dlc3RlZCBieSBvbmUgb2YgdGhlIHJldmlld2VycywgYnV0IEkgYWdyZWUg aXQgc291bmRzIGluY29tcGxldGUuDQoNClBlcmhhcHMgIkluIHN1Y2ggY2FzZXMiPw0KICANCj4g ICAgICAgVGhlIHRva2VucyByZXR1cm5lZCB0byB0aGUgVUFDIGRlcGVuZCBvbiB0aGUgdHlwZSBv ZiBhdXRob3JpemF0aW9uDQo+ICAgICAgIHNlcnZlciAoQVMpOiBhbiBPQXV0aCBBUyBwcm92aWRl cyBhbiBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4NCj4gICAgICAgW1JGQzY3NDldLiAg VGhlIFVBQyBwcm92aWRlcyB0aGUgYWNjZXNzIHRva2VuIHRvIHRoZSBTSVAgc2VydmVycyB0bw0K PiAgICANCj4gICAgQWdhaW4sIHRoaXMgaW1wbGllcyB0aGF0IHJlZnJlc2ggdG9rZW5zIGFyZSBh bHdheXMgaXNzdWVkOyBSRkMgNjc0OSBpcyBxdWl0ZQ0KPiAgICBjbGVhciB0aGF0ICJpc3N1aW5n IGEgcmVmcmVzaCB0b2tlbiBpcyBvcHRpb25hbCBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUNCj4g ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIiLg0KICAgIA0KSSdsbCBsZWF2ZSB0aGlzIGZvciBSaWZh YXQuDQoNCj4gICAgICAgYXV0aG9yaXplIFVBQydzIGFjY2VzcyB0byB0aGUgc2VydmljZS4gIFRo ZSBVQUMgdXNlcyB0aGUgcmVmcmVzaA0KPiAgICAgICB0b2tlbiBvbmx5IHdpdGggdGhlIEFTIHRv IGdldCBhIG5ldyBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4NCj4gICAgICAgYmVmb3Jl IHRoZSBleHBpcnkgb2YgdGhlIGN1cnJlbnQgYWNjZXNzIHRva2VuIChzZWUgW1JGQzY3NDldLCBz ZWN0aW9uDQo+ICAgIA0KPiAgICAoTmV3IHJlZnJlc2ggdG9rZW4gaXMgYWxzbyBvcHRpb25hbC4p DQogIA0KSSdsbCBsZWF2ZSB0aGlzIGZvciBSaWZhYXQuDQoNCj4gICAgICAgMS41IFJlZnJlc2gg VG9rZW4gZm9yIGRldGFpbHMpLiAgQW4gT3BlbklEIENvbm5lY3Qgc2VydmVyIHJldHVybnMgYW4N Cj4gICAgICAgYWRkaXRpb25hbCBJRC1Ub2tlbiBjb250YWluaW5nIHRoZSBTSVAgVVJJIGFuZCBv dGhlciB1c2VyLXNwZWNpZmljDQo+ICAgICAgIGRldGFpbHMgdGhhdCB3aWxsIGJlIGNvbnN1bWVk IGJ5IHRoZSBVQUMuDQo+ICAgIA0KPiAgICBbc2FtZSBjb21tZW50IGFzIGFib3ZlIGFib3V0ICJ0 aGUgU0lQIFVSSSIuXQ0KICANCkknbGwgbGVhdmUgdGhpcyBmb3IgUmlmYWF0Lg0KDQo+ICAgICAg IElmIHRoZSBVQUMgcmVjZWl2ZXMgYSA0MDEvNDA3IHJlc3BvbnNlIHdpdGggbXVsdGlwbGUgV1dX LQ0KPiAgICAgICBBdXRoZW50aWNhdGUvUHJveHktQXV0aGVudGljYXRlIGhlYWRlciBmaWVsZHMs IHByb3ZpZGluZyBjaGFsbGVuZ2VzDQo+ICAgICAgIHVzaW5nIGRpZmZlcmVudCBhdXRoZW50aWNh dGlvbiBzY2hlbWVzIGZvciB0aGUgc2FtZSByZWFsbSwgdGhlIFVBQw0KPiAgICAgICBzZWxlY3Rz IG9uZSBvciBtb3JlIG9mIHRoZSBwcm92aWRlZCBzY2hlbWVzIChiYXNlZCBvbiBsb2NhbCBwb2xp Y3kpDQo+ICAgICAgIGFuZCBwcm92aWRlcyBjcmVkZW50aWFscyBmb3IgdGhvc2Ugc2NoZW1lcy4N Cj4gICAgDQo+ICAgIFJGQyAzMjYxIHNlZW1zIHRvIGJlIHdyaXR0ZW4gaW4gYSB3b3JsZCB0aGF0 IGFzc3VtZWQgdGhhdCBCYXNpYyBhbmQgRGlnZXN0DQo+ICAgIGFyZSB0aGUgb25seSBkZWZpbmVk IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcywgYW5kIHNpbmNlIGl0IHByb2hpYml0cw0KPiAg ICBCYXNpYywgdGhhdCB0aGVyZSB3b3VsZCBvbmx5IGJlIG9uZSBhdXRoZW50aWNhdGlvbiBjaGFs bGVuZ2UgKHR5cGUpDQo+ICAgIHBvc3NpYmxlLiAgVGhpcyB0ZXh0IHJpZ2hseSBhY2tub3dsZWRn ZXMgdGhhdCB3ZSBhcmUgb3BlbmluZyB0aGUgZmllbGQgdXANCj4gICAgYW5kIGNvdWxkIGhhdmUg Y2FzZXMgd2hlcmUgbXVsdGlwbGUgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhcmUgcG9zc2libGU7 DQo+ICAgIGhvd2V2ZXIsIGl0IGdvZXMgZXZlbiBmdXJ0aGVyIGFuZCBhZG1pdHMgdGhlIHBvc3Np YmlsaXR5IG9mIHVzaW5nIHRoZW0NCj4gICAgc2ltdWx0YW5lb3VzbHkuICBJdCBzZWVtcyBsaWtl IHRoaXMgcGxhY2VzIGFuIG9udXMgb24gdXMgdG8gZ2l2ZSBzb21lDQo+ICAgIGluZGljYXRpb24g b2YgdGhlIHNlbWFudGljcyB3aGVuIG11bHRpcGxlIHNjaGVtZXMgYXJlIHVzZWQgYXQgdGhlIHNh bWUgdGltZS4NCj4gICAgRG8gdGhlIGF1dGhlbnRpY2F0ZWQgaWRlbnRpdGllcyBuZWVkIHRvIG1h dGNoPyAgT3IgYXJlIHdlIGFzc2VydGluZyB0aGF0DQo+ICAgIGJvdGgvYWxsIGlkZW50aXRpZXMg YXJlIGNvbnNlbnRpbmcgdG8gdGhlIHJlcXVlc3QgaW4gcXVlc3Rpb24/ICAoSWYgd2UgZG9uJ3QN Cj4gICAgaGF2ZSBhIGNvbmNyZXRlIHVzZSBjYXNlIGluIG1pbmQsIHBlcmhhcHMgdGhlICJvciBt b3JlIiBpcyBqdXN0IG9wZW5pbmcgYQ0KPiAgICBib3ggdGhhdCB3ZSBkb24ndCBuZWVkIHRvIG9w ZW4gcmlnaHQgbm93LikNCg0KSSBjYW4gbW9kaWZ5IGFzIHN1Z2dlc3RlZC4NCg0KKFBlcnNvbmFs bHksIEkgaGF2ZSBuZXZlciBzZWVuIG11bHRpcGxlIHNjaGVtZXMgaW4gYSBkZXBsb3ltZW50LikN CiAgICANCj4gICAgU2VjdGlvbiAyLjEuMg0KPiAgICANCj4gICAgICAgYWNjZXNzIHRvIGl0LiAg RW5kcG9pbnRzIHRoYXQgc3VwcG9ydCB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBzdXBwb3J0DQo+ ICAgICAgIGVuY3J5cHRlZCBKU09OIFdlYiBUb2tlbnMgKEpXVCkgW1JGQzc1MTldIGZvciBlbmNv ZGluZyBhbmQgcHJvdGVjdGluZw0KPiAgICAgICBhY2Nlc3MgdG9rZW5zIHdoZW4gdGhleSBhcmUg aW5jbHVkZWQgaW4gU0lQIHJlcXVlc3RzLCB1bmxlc3Mgc29tZQ0KPiAgICAgICBvdGhlciBtZWNo YW5pc20gaXMgdXNlZCB0byBndWFyYW50ZWUgdGhhdCBvbmx5IGF1dGhvcml6ZWQgU0lQDQo+ICAg ICAgIGVuZHBvaW50cyBoYXZlIGFjY2VzcyB0byB0aGUgYWNjZXNzIHRva2VuLg0KPiAgICANCj4g ICAgSSB0aGluayB3ZSBtYXkgd2FudCAiTVVTVCBzdXBwb3J0IiAoYWx3YXlzKSBhbmQgIk1VU1Qg dXNlLCB1bmxlc3Mgc29tZSBvdGhlcg0KPiAgICBtZWNoYW5pc20iLg0KICANCkJhc2VkIG9uIGFu b3RoZXIgcmV2aWV3LCBJIHN1Z2dlc3RlZCB0byBjaGFuZ2UgdG8gIk1VU1QgdXNlIi4gSSBhbSBu b3Qgc3VyZSB3aGV0aGVyIHdlIG5lZWQgdG8ga2VlcCAiTVVTVCBzdXBwb3J0Ii4NCg0KPiAgICBJ J2QgYWxzbyBzdWdnZXN0IGEgcXVpY2sgbm90ZSB0aGF0IFRMUyByZW1haW5zIGZpbmUgZm9yIHBy b3RlY3RpbmcgdGhlDQo+ICAgIFVBQy9BUyBpbnRlcmFjdGlvbiB3aGVyZSB0aGUgcmVmcmVzaCB0 b2tlbiBpcyB1c2VkLg0KICANCkkgY2FuIGRvIHRoYXQuDQoNCkkgY291bGQgYWxzbyBzYXkgIipT SVAqIGVuZHBvaW50cyB0aGF0IHN1cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9uLi4uIi4NCg0KPiAg ICBXaGF0ZXZlciBpcyBkb25lLCBwbGVhc2UgaGFybW9uaXplIHdpdGggU2VjdGlvbiA1IHRoYXQg aGFzIGVzc2VudGlhbGx5IHRoZQ0KPiAgICBzYW1lIHRleHQuDQogIA0KV2lsbCBkby4NCg0KPiAg ICBTZWN0aW9uIDIuMS4zDQo+ICAgIA0KPiAgICAgICBCYXNlZCBvbiBsb2NhbCBwb2xpY3ksIHRo ZSBVQUMgTUFZIGluY2x1ZGUgYW4gYWNjZXNzIHRva2VuIHRoYXQgaGFzDQo+ICAgICAgIGJlZW4g dXNlZCBmb3IgYW5vdGhlciBiaW5kaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBBZGRyZXNz IE9mDQo+ICAgICAgIFJlY29yZCAoQU9SKSBpbiB0aGUgcmVxdWVzdC4NCj4gICAgDQo+ICAgIEp1 c3QgdG8gY2hlY2s6IHRoZXJlJ3Mgbm8gcmVhbCBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHdpdGgg c3VjaCB1c2UsIGFzIGl0cw0KPiAgICB0aGUgc2FtZSBwYXJ0aWVzIGludGVyYWN0aW5nIGFuZCB0 aGVyZSBhcmUgb3RoZXIgaWRlbnRpZmllcnMgKGUuZy4sIElQDQo+ICAgIGFkZHJlc3NlcykgdG8g Y29uZmlybSB0aGF0IGl0J3MgdGhlIHNhbWUgY2xpZW50IGNvbW11bmljYXRpbmcgdG8gdGhlIHNl cnZlcj8NCiAgICANCkknbGwgbGVhdmUgdGhpcyBmb3IgUmlmYWF0Lg0KDQo+ICAgIEFsc28sIGlz IGl0IGNsZWFyIHdoYXQgd2lsbCBiZSBkb25lIChuZXcgdG9rZW4gcmVxdWVzdCkgd2hlbiB0aGUg TUFZIGlzIG5vdA0KPiAgICBoZWVkZWQ/DQogIA0KSSdsbCBsZWF2ZSB0aGlzIGZvciBSaWZhYXQu DQoNCj4gICAgU2VjdGlvbiAyLjEuNA0KPiAgICANCj4gICAgVGhlIHRleHQgaGVyZSBqdXN0IHRh bGtzIGFib3V0ICJhIHZhbGlkIGFjY2VzcyB0b2tlbiIgYW5kIHNpbWlsYXIsIHdpdGhvdXQNCj4g ICAgc2F5aW5nIGEgd2hvbGUgbG90IGFib3V0IGl0IGJlaW5nIHJlbGF0ZWQgaW4gYW55IHdheSB0 byB0aGUgc3BlY2lmaWNzIG9mIHRoZQ0KPiAgICBhdXRoZW50aWNhdGlvbiBjaGFsbGVuZ2UuICBJ cyB0aGVyZSBzb21ldGhpbmcgdXNlZnVsIHRvIHNheSBhYm91dCwgZS5nLiwgdGhlDQo+ICAgIHRv a2VuIGluIHF1ZXN0aW9uIGhhdmluZyBiZWVuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgaW5kaWNhdGVkDQo+ICAgIGluIHRoZSBjaGFsbGVuZ2U/DQogIA0KSSdsbCBsZWF2ZSB0 aGlzIGZvciBSaWZhYXQuDQoNCj4gICAgU2VjdGlvbiAyLjINCj4gICAgDQo+ICAgICAgIGF1dGhv cml6YXRpb24gY3JlZGVudGlhbHMgYWNjZXB0YWJsZSB0byBpdCwgaXQgU0hPVUxEIGNoYWxsZW5n ZSB0aGUNCj4gICAgICAgcmVxdWVzdCBieSBzZW5kaW5nIGEgNDAxIChVbmF1dGhvcml6ZWQpIHJl c3BvbnNlLiAgVG8gaW5kaWNhdGUgdGhhdA0KPiAgICAgICBpdCBpcyB3aWxsaW5nIHRvIGFjY2Vw dCBhbiBhY2Nlc3MgdG9rZW4gYXMgYSBjcmVkZW50aWFsLCB0aGUgVUFTLw0KPiAgICAgICBSZWdp c3RyYXIgTVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGljYXRpb24gaGVhZGVyIGZpZWxkIGlu IHRoZQ0KPiAgICAgICByZXNwb25zZSB0aGF0IGluZGljYXRlcyAiQmVhcmVyIiBzY2hlbWUgYW5k IGluY2x1ZGVzIGFuIGFkZHJlc3Mgb2YgYW4NCj4gICAgDQo+ICAgIG5pdCg/KTogSSdkIGNvbnNp ZGVyIGp1c3QgbWFraW5nIHRoaXMgYSBkZWNsYXJhdGl2ZSBzdGF0ZW1lbnQsIGEgbGEgInRoZQ0K PiAgICBVQVMvcmVnaXN0cmFyIGluY2x1ZGVzIGEgUHJveHktQXV0aGVudGljYXRpb24gaGVhZGVy IGZpZWxkIHdpdGggdGhlICJCZWFyZXIiDQo+ICAgIHNjaGVtZSB0byBpbmRpY2F0ZSB0aGF0IGl0 IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIGFjY2VzcyB0b2tlbiBhcyBhDQo+ICAgIGNyZWRlbnRp YWwiICAoYnV0IHRoYXQgd29yZGluZyBpcyBpbmNvbXBsZXRlIGFuZCB3b3VsZCBuZWVkIHRvIGJl IGZsZXNoZWQNCj4gICAgb3V0IGEgYml0IG1vcmUpLg0KDQpJIHRoaW5rIHRoYXQgd291bGQgYmUg d2VpcmQuIEJlY2F1c2UsIGZpcnN0IHdlIHNheSB0aGF0IHRoZSBVQVMvUmVnaXN0cmFyIFNIT1VM RCBjaGFsbGVuZ2UsIGFuZCB3aXRoIHlvdXIgc3VnZ2VzdGlvbiB0aGUgdGV4dCB3b3VsZCBzYXkg dGhhdCB0aGUgVUFTL1JlZ2lzdHJhciBNVVNUIGluY2x1ZGUgYSBQcm94eS1BdXRoZW50aWNhdGlv biBoZWFkZXIgZmllbGQgZXZlbiBpZiBpdCBkb2VzIE5PVCBjaGFsbGVuZ2UgdGhlIHJlcXVlc3Qu DQoNClBlcmhhcHM6DQoNCiJJZiB0aGUgVUFTL1JlZ2lzdHJhciBjaG9vc2VzIHRvIGNoYWxsZW5n ZSB0aGUgcmVxdWVzdCwgYW5kIGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIGFjY2VzcyB0b2tlbiBh cyBhIGNyZWRlbnRpYWwsIHRoZSBVQVMvUmVnaXN0cmFyIE1VU1QgaW5jbHVkZSBhLi4uIg0KIA0K PiAgICAgICBhdXRob3JpemF0aW9uIHNlcnZlciBmcm9tIHdoaWNoIHRoZSBvcmlnaW5hdG9yIGNh biBvYnRhaW4gYW4gYWNjZXNzDQo+ICAgICAgIHRva2VuLg0KPiAgICANCj4gICAgbml0OiAiYWRk cmVzcyBvZiIgYW4gQVMsIGRvZXMgdGhhdCBtZWFuIGJhcmUgSVAgYWRkcmVzcyBvbmx5IG9yIGlz IGEgRE5TDQo+ICAgIG5hbWUgb2theT8NCiAgDQpJJ2xsIGxlYXZlIHRoaXMgZm9yIFJpZmFhdC4N CiAgDQo+ICAgICAgIFtSRkM3NTE5XS4gIElmIHRoZSB0b2tlbiBwcm92aWRlZCBpcyBhbiBleHBp cmVkIGFjY2VzcyB0b2tlbiwgdGhlbg0KPiAgICAgICB0aGUgVUFTIE1VU1QgcmVwbHkgd2l0aCA0 MDEgVW5hdXRob3JpemVkLCBhcyBkZWZpbmVkIGluIHNlY3Rpb24gMyBvZg0KPiAgICAgICBbUkZD Njc1MF0uICBJZiB0aGUgdmFsaWRhdGlvbiBpcyBzdWNjZXNzZnVsLCB0aGUgVUFTL1JlZ2lzdHJh ciBjYW4NCj4gICAgICAgY29udGludWUgdG8gcHJvY2VzcyB0aGUgcmVxdWVzdCB1c2luZyBub3Jt YWwgU0lQIHByb2NlZHVyZXMuICBJZiB0aGUNCj4gICAgICAgdmFsaWRhdGlvbiBmYWlscywgdGhl IFVBUy9SZWdpc3RyYXIgTVVTVCByZWplY3QgdGhlIHJlcXVlc3QuDQo+ICAgIA0KPiAgICBJcyAi ZXhwaXJlZCIgdGhlIG9ubHkgY2FzZSB0aGF0IHNob3VsZCBnZXQgYSA0MDEgdnMuIG91dHJpZ2h0 IHJlamVjdGlvbiwgYXMNCj4gICAgc3RhdGVkIGhlcmU/DQoNCjQwMSBpcyBzZW50IGFsc28gaW4g dGhlIGNhc2Ugd2hlcmUgdGhlIHZhbGlkYXRpb24gZmFpbHMuIEkgd2lsbCBjbGFyaWZ5IHRoYXQu DQogIA0KPiAgICBTZWN0aW9uIDIuMw0KPiAgICANCj4gICAgICAgc2VuZGluZyBhIDQwNyAoUHJv eHkgQXV0aGVudGljYXRpb24gUmVxdWlyZWQpIHJlc3BvbnNlLiAgVG8gaW5kaWNhdGUNCj4gICAg ICAgdGhhdCBpdCBpcyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBhY2Nlc3MgdG9rZW4gYXMgYSBjcmVk ZW50aWFsLCB0aGUNCj4gICAgICAgcHJveHkgTVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGlj YXRpb24gaGVhZGVyIGZpZWxkIGluIHRoZQ0KPiAgICAgICByZXNwb25zZSB0aGF0IGluZGljYXRl cyAiQmVhcmVyIiBzY2hlbWUgYW5kIGluY2x1ZGVzIGFuIGFkZHJlc3MgdG8gYW4NCj4gICAgDQo+ ICAgIFtzYW1lIGNvbW1lbnQgYXMgYWJvdmUgYWJvdXQgbm9ybWF0aXZlIHZzLiBkZWNsYXJhdGl2 ZSBzdGF0ZW1lbnRdDQo+ICAgIEFsc28sIHBsZWFzZSBrZWVwIHRoZSB0ZXh0IHBhcmFsbGVsIGJl dHdlZW4gc2VjdGlvbnMgLS0gdGhpcyBjb3B5IGhhcyBhdA0KPiAgICBsZWFzdCBvbmUgbml0ICgi YWRkcmVzcyB0byBhbiIgdnMuICJhZGRyZXNzIG9mIGFuIikuDQogIA0KSSB3aWxsIGZpeCB0aGlz IGluIHRoZSBzYW1lIHdheS4NCg0KPiAgICBTZWN0aW9uIDMNCj4gICAgDQo+ICAgICAgIElmIGFu IGFjY2VzcyB0b2tlbiBpcyBlbmNvZGVkIGFzIGEgSldULCBpdCBtaWdodCBjb250YWluIGEgbGlz dCBvZg0KPiAgICAgICBjbGFpbXMgW1JGQzc1MTldLCBzb21lIHJlZ2lzdGVyZWQgYW5kIHNvbWUg YXBwbGljYXRpb24tc3BlY2lmaWMuICBUaGUNCj4gICAgDQo+ICAgIEkgZG9uJ3QgdGhpbmsgdGhl cmUncyBhIHF1ZXN0aW9uIG9mIHdoZXRoZXIgYSBKV1Qgd2lsbCBjb250YWluIGEgbGlzdCBvZg0K PiAgICBjbGFpbXMgOikNCg0KRmFpciBlbm91Z2ggOikNCg0KPiAgICBNYXliZSAiSWYgdGhlIGFj Y2VzcyB0b2tlbiBpcyBlbmNvZGVkIGFzIGEgSldULCBpdCB3aWxsIGNvbnRhaW4gYSBsaXN0IG9m DQo+ICAgIGNsYWltcyBbUkZDNzUxOV0sIHdoaWNoIG1heSBpbmNsdWRlIGJvdGggcmVnaXN0ZXJl ZCBhbmQgYXBwbGljYXRpb24tc3BlY2lmaWMNCj4gICAgY2xhaW1zIj8NCiAgDQpMb29rcyBnb29k IHRvIG1lLCBidXQgSSdsbCBsZWF2ZSB0aGlzIGZvciBSaWZhYXQuDQoNCi0tLS0NCg0KPiAgICBT ZWN0aW9uIDQNCj4gICAgDQo+ICAgIFRoaXMgc2VjdGlvbiBjbGFpbXMgdG8gY292ZXIgV1dXLUF1 dGhlbnRpY2F0ZS4gIFdoYXQgc3BlY2lmaWNhdGlvbiB3aWxsIHRoZQ0KPiAgICBTSVAgdXNlIG9m IEJlYXJlciBmb3IgQXV0aG9yaXphdGlvbiBvcGVyYXRlIHVuZGVyPw0KICANClJGQyA2NzUwLg0K DQpTZWN0aW9uIDIuMS4zIHNheXM6DQoNCiAgICJUaGUgVUFDIHNlbmRzIGEgUkVHSVNURVIgcmVx dWVzdCB3aXRoIGFuIEF1dGhvcml6YXRpb24gaGVhZGVyIGZpZWxkDQogICBjb250YWluaW5nIHRo ZSByZXNwb25zZSB0byB0aGUgY2hhbGxlbmdlLCBpbmNsdWRpbmcgdGhlIEJlYXJlciBzY2hlbWUN CiAgIGNhcnJ5aW5nIGEgdmFsaWQgYWNjZXNzIHRva2VuIGluIHRoZSByZXF1ZXN0LCBhcyBzcGVj aWZpZWQgaW4NCiAgIFtSRkM2NzUwXS4iDQoNCj4gICAgICAgICAgIGNoYWxsZW5nZSAgPS8gICgi QmVhcmVyIiBMV1MgYmVhcmVyLWNsbiAqKENPTU1BIGJlYXJlci1jbG4pKQ0KPiAgICANCj4gICAg c2lkZSBub3RlOiBpcyB0aGVyZSBhIG1uZW1vbmljIGZvciB0aGUgImNsbiIgaW4gImJlYXJlci1j bG4iPw0KDQpSRkMgMzI2MSB1c2VzICJjbG4iIGZvciBkaWdlc3QuDQoNCj4gICAgICAgICAgIGJl YXJlci1jbG4gPSByZWFsbSAvIHNjb3BlIC8gYXV0aHotc2VydmVyIC8gZXJyb3IgLw0KPiAgICAg ICAgICAgICAgICAgICAgICAgIGF1dGgtcGFyYW0NCj4gICAgDQo+ICAgIG5pdDogcmVhbG0gaXMg YWxyZWFkeSBpbmNsdWRlZCBpbiBhdXRoLXBhcmFtLCB0aG91Z2ggSSBkb24ndCBzZWUgYSBoYXJt IGluDQo+ICAgIGNhbGxpbmcgaXQgb3V0IGV4cGxpY2l0bHkuDQoNCmF1dGgtcGFyYW0gaXMgdXNl ZCB0byBhbGxvdyBwb3NzaWJsZSBuZXcgcGFyYW1ldGVycyBpbiB0aGUgZnV0dXJlLiAgDQoNCj4g ICAgICAgICAgIHJlYWxtID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCj4gICAgICAgICAgIGF1dGgt cGFyYW0gPSA8ZGVmaW5lZCBpbiBSRkMzMjYxPg0KPiAgICANCj4gICAgUkZDIDMyNjEgZGVmZXJz IHRvIFJGQyAyNjE3IChub3cgb2Jzb2xldGVkIGJ5IDcyMzUpIGZvciBib3RoIG9mIHRoZXNlOyB3 ZQ0KPiAgICBjb3VsZCBwZXJoYXBzIHNob3J0LWNpcmN1aXQgdGhlIGNoYWluIGFuZCBzYXkgImRl ZmluZWQgaW4gUkZDIDcyMzUiLg0KICANCldlIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBXRywgYW5k IHRoZSBvdXRjb21lIHdhcyB0byBrZWVwIHRoZSBzYW1lIHJlZmVyZW5jZXMgYXMgUkZDIDMyNjEs IHNpbmNlIHRoYXQgaXMgd2hhdCBwZW9wbGUgYXJlIGltcGxlbWVudGluZy4NCg0KVGhlbiwgYXMg YSBzZXBhcmF0ZSB0YXNrLCBzb21lb25lIGNvdWxkIHVwZGF0ZSBSRkMgMzI2MSB3aXRoIHRoZSBu ZXcgcmVmZXJlbmNlcy4NCg0KLS0tDQogIA0KPiAgICBTZWN0aW9uIDUNCj4gICAgDQo+ICAgIFdl IHNob3VsZCBwcm9iYWJseSBub3RlIHRoYXQgU0lQIG1ha2VzIG11Y2ggaGVhdmllciB1c2Ugb2Yg cHJveGllcyB0aGFuIGlzDQo+ICAgIGNvbW1vbiBpbiB0aGUgd2ViIHdvcmxkIG9mIE9BdXRoLg0K DQpNYXliZSBzb21ldGhpbmcgbGlrZToNCg0KIkhvd2V2ZXIsIFNJUCBtYWtlcyBoYXZlIHVzZSBv ZiBpbnRlcm1lZGlhcnkgU0lQIHByb3hpZXMsIGFuZCBUTFMgb25seSBndWFyYW50ZWVzIGhvcC10 by1ob3AgcHJvdGVjdGlvbiB3aGVuIHVzZWQgdG8NCiAgIHByb3RlY3QgU0lQIHNpZ25hbGluZy4i DQoNCj4gICAgSSdtIGhhcHB5IHRvIHNlZSB0aGF0IHNvbWUgcHJpdmFjeSBjb25zaWRlcmF0aW9u cyBhcmUgYmVpbmcgYWRkZWQgaW4NCj4gICAgcmVzcG9uc2UgdG8gQmFycnkncyByZXZpZXcuDQog IA0KR29vZCA6KQ0KDQotLS0NCg0KPiAgICBTZWN0aW9uIDgNCj4gICAgDQo+ICAgIEkgdGhpbmsg UkZDcyA4MjUyIGFuZCA4NDE0IGNvdWxkIGJlIGp1c3QgaW5mb3JtYXRpdmUuDQogIA0KSSBjYW4g Zml4IHRoYXQuDQoNCi0tLQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KICANCiAgICANCiAgICAN CiAgICANCg0K From nobody Thu Apr 23 23:10:20 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1FF3A0CBD; Thu, 23 Apr 2020 23:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 LgVlXcCxwnzY; Thu, 23 Apr 2020 23:09:56 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 CE56E3A0CB0; Thu, 23 Apr 2020 23:09:01 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 5732621C2; Fri, 24 Apr 2020 08:08:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: "Olle E. Johansson" In-Reply-To: <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> Date: Fri, 24 Apr 2020 08:08:56 +0200 Cc: Olle E Johansson , Benjamin Kaduk , The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore@ietf.org, sipcore-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 06:10:02 -0000 > On 23 Apr 2020, at 22:55, Paul Kyzivat wrote: >=20 > On 4/23/20 3:25 PM, Benjamin Kaduk via Datatracker wrote: >=20 >> RFC 3261 seems to be written in a world that assumed that Basic and = Digest >> are the only defined HTTP authentication schemes, and since it = prohibits >> Basic, that there would only be one authentication challenge (type) >> possible. This text righly acknowledges that we are opening the = field up >> and could have cases where multiple authentication schemes are = possible; >> however, it goes even further and admits the possibility of using = them >> simultaneously. It seems like this places an onus on us to give some >> indication of the semantics when multiple schemes are used at the = same time. >> Do the authenticated identities need to match? Or are we asserting = that >> both/all identities are consenting to the request in question? (If = we don't >> have a concrete use case in mind, perhaps the "or more" is just = opening a >> box that we don't need to open right now.) >=20 > I pushed quite a bit on this area during the development of this = draft. As you note we are definitely expanding into an area that wasn't = anticipated in RFC3261. The whole topic of how authentication works in = the presence of multiple schemes and realms could use some elaboration. = The authors of this draft were reluctant to get into those weeds. It = isn't clear what the right mechanism is to do that. >=20 > I had a (non-sip) use case in mind: a site I visit allows you register = directly with the site, resulting in an ability to use Digest = credentials. The login page on the site offers that as an option, along = with the alternatives of Facebook, Google, and maybe some others. I can = see something just like that for SIP. Presumably it would be achieved by = challenging with Digest and also with Bearer for Facebook, Google, etc. = The UAC then "chooses" by delegating the choice to the user through the = UI. >=20 > This is also the case where the "whitelist" really resides within the = end user's head rather than in the UAC. >=20 > It gets harder for devices that might be connecting when there is no = end user present. This can happen with a "phone" that attempts to be = permanently registered to its sip server so that in can receive incoming = calls. If it reboots in the middle of the night there is no user handy = to interact in the authentication process. It all has to take place = using credentials preconfigured (or cached) in the UAC. >=20 I think it=E2=80=99s critical - and I=E2=80=99ve also raised the issue = before like Paul - that we develop a BCP for the various combinations we = have - both two types of digest algorithms and now the OAuth2/OpenID = Connect. There are huge risks of mis-configured platforms allowing for = downgrade attacks, so even if you=E2=80=99ve added stronger = authentication, someone will misuse your system because MD5 was still = open with simple passwords for some very old SIP phones. /O From nobody Thu Apr 23 23:41:09 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7062F3A0D40; Thu, 23 Apr 2020 23:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 KZ5W1diNRc7X; Thu, 23 Apr 2020 23:40:43 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40066.outbound.protection.outlook.com [40.107.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84323A0D2F; Thu, 23 Apr 2020 23:40:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FoCyQS8ufeICHSDRexIq88LlnvC99CrbDZmzm0vi42p7udD4pMJTMuInCRC3GH/cKSZTiJ70frNKv1XOM0cE1+fbXecQK5ePdZoUrLnmfXqASuAAvjoZKWyhcG2rPVZYLm3CzPqPpiJcYDdJ7pHPanH73qV3DoFSdrYJL1tQwaxQnYh0s3ikQDv3D2icLYLO2IvMJfiRCiYHxjYbh6y4tbctwmd6R0rsGd0RfWwPjAKOIX7cf35ptUuGO/Opd/OuYtvcEyRU0gTYj88cJ3+g8USA4Yg6dTp5Ej5tTqL1qEc5uVRdchR1c9AmeHFcOWpGs3aof2wszrQ1UXZwjB7m0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U2ZJE2SnlBRc4Bgv3PrJMa71FfeppjE5CZ/iAk8xpjo=; b=dOV/jCNfdXT3+6/Tr9otiY1BQkfxvhscfEYXDJJB0opXqb/4v3j/mispuQ1xC8F32D83ISY4MzUUn6n+Gk0ZpoQ4hfAEe0qu2zCVl7Pp1flKKOXiTS+3VucXJRXVloeaMXFbQoEMyiaiUtSJeNZTc0MW6fsmr55DVHuhvA9clwt+qeINZiMFfdfTTOD3iKyG1417oNj8l7WcVZwdnvo53W4bt+7f0iQlayE4TIfEdppLTG20n/cDdXMI88MA/uUEuPeOBT8zeIvSl1ydjmPBWrw1TixXKZ7hvV/uDUsHMQRaFJewslNlVULf01M8uKMVybPttz6eIE21JGGUlgZdvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U2ZJE2SnlBRc4Bgv3PrJMa71FfeppjE5CZ/iAk8xpjo=; b=qyu/9h99z8FHjMBshNzX6xXVfG2vMr+dCiRWZ1HOcDHkKEpGmz/f9tMr3dsjRArYE+W7wz9E6ZKHWK4CAWcjrrdyYl78WPOaxDXff+Q1EuMbMOpcz2NnbcOmYXfTUP1qdXScnbnKx8Gt5WP/3mJeMOXlKTEw/Qk3zCllsh0o0mM= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB4226.eurprd07.prod.outlook.com (2603:10a6:208:b5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Fri, 24 Apr 2020 06:40:14 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 06:40:14 +0000 From: Christer Holmberg To: "Olle E. Johansson" , Paul Kyzivat CC: Benjamin Kaduk , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) Thread-Index: AQHWGaTv/W/UMLKp7ECr0CNaSmCuWKiHL6oAgACauACAADsIgA== Date: Fri, 24 Apr 2020 06:40:14 +0000 Message-ID: <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4e452bc-286a-4e1c-c233-08d7e81a583e x-ms-traffictypediagnostic: AM0PR07MB4226: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(39860400002)(366004)(376002)(136003)(6512007)(2616005)(8936002)(6486002)(2906002)(44832011)(26005)(186003)(81156014)(8676002)(71200400001)(5660300002)(4326008)(110136005)(316002)(66556008)(91956017)(64756008)(54906003)(86362001)(36756003)(66446008)(6506007)(76116006)(66946007)(478600001)(66476007)(33656002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T09W6nt4rtOCpLAl2cZQxsL+Im1O6hjv4w0r70D3TKz5QhSFow3ARURFWxU1nX21pNT1hE80eXbhWeIi5qQCVCD7en4vR7pDOKFb+HvLPuzNydyIp9D9fTHKr5L8FL/1kwD1E44Jxz6/wjS4Al3unorVfpB3fXbOESAE/6lR5m+9QxzeED9zDXC9E+7nuEbalPDKDSAUAM+OUUFHbdRzm1Q64HdlAKcYrXh7iCPRpSURnh20//QIpNHcPXrPTCry+i/sxOXxDEu/SHGwQfKhKO2RowYGLdGbsRHsAOXbJi4ob6YG/BJUJq0wobYTvVS5j5ZWOX+5j6IErsF+qrJLL2M3xKZa8HAZMCM5fjUxrCixHLMkgJrBNI0QYXcepchvLbvSvTBdZyszkaEz8HuXBjmK4SfkksDldsh66Oijbnh2BHoWdfzXht+PvYnp4FmC x-ms-exchange-antispam-messagedata: bz0c287AI4xYshIQ+iLyv1mO/8+ji5V+2uoIyWnGSlyT+TGXlDyBLfc8t0OqBwZnLfSGZs3q3kBDtmhDR1tNdreaqD+FmO0zeLw1xpgUO48tI1ScZzcWKKenSQBW4jEbWIi751MiILrWAnSnrTUqrQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4e452bc-286a-4e1c-c233-08d7e81a583e X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 06:40:14.2266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J6J77beHRKNEdxtnLq3dJHzytVCGEtkf+izSZV2m/7qwygvjeZd30qCkQoz07yJmRvg+GTLk0YysJrR0tTJ5Z6vGjzsLYsHReAyMkGYn9uQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4226 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 06:40:46 -0000 SGksDQoNCiAgICA+Pj4gUkZDIDMyNjEgc2VlbXMgdG8gYmUgd3JpdHRlbiBpbiBhIHdvcmxkIHRo YXQgYXNzdW1lZCB0aGF0IEJhc2ljIGFuZCBEaWdlc3QNCiAgICA+Pj4gYXJlIHRoZSBvbmx5IGRl ZmluZWQgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLCBhbmQgc2luY2UgaXQgcHJvaGliaXRz DQogICAgPj4+IEJhc2ljLCB0aGF0IHRoZXJlIHdvdWxkIG9ubHkgYmUgb25lIGF1dGhlbnRpY2F0 aW9uIGNoYWxsZW5nZSAodHlwZSkNCiAgICA+Pj4gcG9zc2libGUuICBUaGlzIHRleHQgcmlnaGx5 IGFja25vd2xlZGdlcyB0aGF0IHdlIGFyZSBvcGVuaW5nIHRoZSBmaWVsZCB1cA0KICAgID4+PiBh bmQgY291bGQgaGF2ZSBjYXNlcyB3aGVyZSBtdWx0aXBsZSBhdXRoZW50aWNhdGlvbiBzY2hlbWVz IGFyZSBwb3NzaWJsZTsNCiAgICA+Pj4gaG93ZXZlciwgaXQgZ29lcyBldmVuIGZ1cnRoZXIgYW5k IGFkbWl0cyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgdGhlbQ0KICAgID4+PiBzaW11bHRhbmVv dXNseS4gIEl0IHNlZW1zIGxpa2UgdGhpcyBwbGFjZXMgYW4gb251cyBvbiB1cyB0byBnaXZlIHNv bWUNCiAgICA+Pj4gaW5kaWNhdGlvbiBvZiB0aGUgc2VtYW50aWNzIHdoZW4gbXVsdGlwbGUgc2No ZW1lcyBhcmUgdXNlZCBhdCB0aGUgc2FtZSB0aW1lLg0KICAgID4+PiBEbyB0aGUgYXV0aGVudGlj YXRlZCBpZGVudGl0aWVzIG5lZWQgdG8gbWF0Y2g/ICBPciBhcmUgd2UgYXNzZXJ0aW5nIHRoYXQN CiAgICA+Pj4gYm90aC9hbGwgaWRlbnRpdGllcyBhcmUgY29uc2VudGluZyB0byB0aGUgcmVxdWVz dCBpbiBxdWVzdGlvbj8gIChJZiB3ZSBkb24ndA0KICAgID4+PiBoYXZlIGEgY29uY3JldGUgdXNl IGNhc2UgaW4gbWluZCwgcGVyaGFwcyB0aGUgIm9yIG1vcmUiIGlzIGp1c3Qgb3BlbmluZyBhDQog ICAgPj4+IGJveCB0aGF0IHdlIGRvbid0IG5lZWQgdG8gb3BlbiByaWdodCBub3cuKQ0KICAgID4+ IA0KICAgID4+IEkgcHVzaGVkIHF1aXRlIGEgYml0IG9uIHRoaXMgYXJlYSBkdXJpbmcgdGhlIGRl dmVsb3BtZW50IG9mIHRoaXMgZHJhZnQuIEFzIHlvdSBub3RlIHdlIGFyZSBkZWZpbml0ZWx5IGV4 cGFuZGluZyBpbnRvIGFuIGFyZWEgdGhhdCB3YXNuJ3QgYW50aWNpcGF0ZWQgaW4gUkZDMzI2MS4N CiAgICA+PiBUaGUgd2hvbGUgdG9waWMgb2YgaG93IGF1dGhlbnRpY2F0aW9uIHdvcmtzIGluIHRo ZSBwcmVzZW5jZSBvZiBtdWx0aXBsZSBzY2hlbWVzIGFuZCByZWFsbXMgY291bGQgdXNlIHNvbWUg ZWxhYm9yYXRpb24uIFRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgd2VyZQ0KICAgID4+IHJlbHVj dGFudCB0byBnZXQgaW50byB0aG9zZSB3ZWVkcy4gSXQgaXNuJ3QgY2xlYXIgd2hhdCB0aGUgcmln aHQgbWVjaGFuaXNtIGlzIHRvIGRvIHRoYXQuDQogICAgPj4gDQogICAgPj4gSSBoYWQgYSAobm9u LXNpcCkgdXNlIGNhc2UgaW4gbWluZDogYSBzaXRlIEkgdmlzaXQgYWxsb3dzIHlvdSByZWdpc3Rl ciBkaXJlY3RseSB3aXRoIHRoZSBzaXRlLCByZXN1bHRpbmcgaW4gYW4gYWJpbGl0eSB0byB1c2Ug RGlnZXN0IGNyZWRlbnRpYWxzLiBUaGUgbG9naW4gcGFnZSBvbiB0aGUNCiAgICA+PiBzaXRlIG9m ZmVycyB0aGF0IGFzIGFuIG9wdGlvbiwgYWxvbmcgd2l0aCB0aGUgYWx0ZXJuYXRpdmVzIG9mIEZh Y2Vib29rLCBHb29nbGUsIGFuZCBtYXliZSBzb21lIG90aGVycy4gSSBjYW4gc2VlIHNvbWV0aGlu ZyBqdXN0IGxpa2UgdGhhdCBmb3IgU0lQLiBQcmVzdW1hYmx5IGl0DQogICAgPj4gd291bGQgYmUg YWNoaWV2ZWQgYnkgY2hhbGxlbmdpbmcgd2l0aCBEaWdlc3QgYW5kIGFsc28gd2l0aCBCZWFyZXIg Zm9yIEZhY2Vib29rLCBHb29nbGUsIGV0Yy4gVGhlIFVBQyB0aGVuICJjaG9vc2VzIiBieSBkZWxl Z2F0aW5nIHRoZSBjaG9pY2UgdG8gdGhlIHVzZXIgdGhyb3VnaCB0aGUgVUkuDQogICAgPj4gDQog ICAgPj4gVGhpcyBpcyBhbHNvIHRoZSBjYXNlIHdoZXJlIHRoZSAid2hpdGVsaXN0IiByZWFsbHkg cmVzaWRlcyB3aXRoaW4gdGhlIGVuZCB1c2VyJ3MgaGVhZCByYXRoZXIgdGhhbiBpbiB0aGUgVUFD Lg0KICAgID4+IA0KICAgID4+IEl0IGdldHMgaGFyZGVyIGZvciBkZXZpY2VzIHRoYXQgbWlnaHQg YmUgY29ubmVjdGluZyB3aGVuIHRoZXJlIGlzIG5vIGVuZCB1c2VyIHByZXNlbnQuIFRoaXMgY2Fu IGhhcHBlbiB3aXRoIGEgInBob25lIiB0aGF0IGF0dGVtcHRzIHRvIGJlIHBlcm1hbmVudGx5IHJl Z2lzdGVyZWQNCiAgICA+PiB0byBpdHMgc2lwIHNlcnZlciBzbyB0aGF0IGluIGNhbiByZWNlaXZl IGluY29taW5nIGNhbGxzLiBJZiBpdCByZWJvb3RzIGluIHRoZSBtaWRkbGUgb2YgdGhlIG5pZ2h0 IHRoZXJlIGlzIG5vIHVzZXIgaGFuZHkgdG8gaW50ZXJhY3QgaW4gdGhlIGF1dGhlbnRpY2F0aW9u IHByb2Nlc3MuIEl0IGFsbA0KICAgID4+IGhhcyB0byB0YWtlIHBsYWNlIHVzaW5nIGNyZWRlbnRp YWxzIHByZWNvbmZpZ3VyZWQgKG9yIGNhY2hlZCkgaW4gdGhlIFVBQy4NCiAgICA+IA0KICAgID4g SSB0aGluayBpdOKAmXMgY3JpdGljYWwgLSBhbmQgSeKAmXZlIGFsc28gcmFpc2VkIHRoZSBpc3N1 ZSBiZWZvcmUgbGlrZSBQYXVsIC0gdGhhdCB3ZSBkZXZlbG9wIGEgQkNQIGZvciB0aGUgdmFyaW91 cyBjb21iaW5hdGlvbnMgd2UgaGF2ZSAtIGJvdGggdHdvIHR5cGVzIG9mIGRpZ2VzdCBhbGdvcml0 aG1zIGFuZCBub3cgdGhlIE9BdXRoMi9PcGVuSUQgQ29ubmVjdC4NCiAgICA+IFRoZXJlIGFyZSBo dWdlIHJpc2tzIG9mIG1pcy1jb25maWd1cmVkIHBsYXRmb3JtcyBhbGxvd2luZyBmb3IgZG93bmdy YWRlIGF0dGFja3MsIHNvIGV2ZW4gaWYgeW914oCZdmUgYWRkZWQgc3Ryb25nZXIgYXV0aGVudGlj YXRpb24sIHNvbWVvbmUgd2lsbCBtaXN1c2UgeW91ciBzeXN0ZW0gYmVjYXVzZSBNRDUgd2FzIHN0 aWxsIG9wZW4gd2l0aCBzaW1wbGUgcGFzc3dvcmRzIGZvciBzb21lIHZlcnkgb2xkIFNJUCBwaG9u ZXMuDQoNCiAgICBJIGFncmVlIHRoYXQgc3VjaCBCQ1AgKG9yIHdoYXRldmVyIGZvcm0gaXQgd291 bGQgdGFrZSkgd291bGQgYmUgdXNlZnVsLiBBcyBJIHNhaWQgYmVmb3JlLCBJIHRoaW5rIGl0IHNo b3VsZCBiZSBkb25lIGFzIGEgc2VwYXJhdGUgdGFzay4NCg0KICAgIFRoZXJlZm9yZSwgaW4gdGhl IGF1dGhueiBkcmFmdCB0aGUgc3VnZ2VzdGlvbiBpcyB0byBzYXkgdGhhdCB0aGUgcHJvY2Vzc2lu ZyBpcyBiYXNlZCBvbiAibG9jYWwgcG9saWN5Ii4NCg0KICAgIElmIHBlb3BsZSB3YW50LCB3ZSBj YW4gYWRkIGEgbm90ZSBzYXlpbmcgdGhhdCBhIGZ1dHVyZSBzcGVjaWZpY2F0aW9uIG1heSBwcm92 aWRlIG1vcmUgZGV0YWlsZWQgcHJvY2VkdXJlcyBhbmQgZ3VpZGFuY2UgcmVnYXJkaW5nIHByb2Nl c3NpbmcgbXVsdGlwbGUgc2NoZW1lcy4NCg0KICAgIFJlZ2FyZHMsDQoNCiAgICBDaHJpc3Rlcg0K DQogICAgDQogICAgDQoNCg== From nobody Fri Apr 24 13:13:40 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B8F3A0A41; Fri, 24 Apr 2020 13:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 7QJuUcRWkto4; Fri, 24 Apr 2020 13:13:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 90DBC3A0A3F; Fri, 24 Apr 2020 13:13:36 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03OKDHO9009058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 16:13:19 -0400 Date: Fri, 24 Apr 2020 13:13:16 -0700 From: Benjamin Kaduk To: Christer Holmberg Cc: "Olle E. Johansson" , Paul Kyzivat , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Message-ID: <20200424201316.GX27494@kduck.mit.edu> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 20:13:38 -0000 On Fri, Apr 24, 2020 at 06:40:14AM +0000, Christer Holmberg wrote: > Hi, > > >>> RFC 3261 seems to be written in a world that assumed that Basic and Digest > >>> are the only defined HTTP authentication schemes, and since it prohibits > >>> Basic, that there would only be one authentication challenge (type) > >>> possible. This text righly acknowledges that we are opening the field up > >>> and could have cases where multiple authentication schemes are possible; > >>> however, it goes even further and admits the possibility of using them > >>> simultaneously. It seems like this places an onus on us to give some > >>> indication of the semantics when multiple schemes are used at the same time. > >>> Do the authenticated identities need to match? Or are we asserting that > >>> both/all identities are consenting to the request in question? (If we don't > >>> have a concrete use case in mind, perhaps the "or more" is just opening a > >>> box that we don't need to open right now.) > >> > >> I pushed quite a bit on this area during the development of this draft. As you note we are definitely expanding into an area that wasn't anticipated in RFC3261. > >> The whole topic of how authentication works in the presence of multiple schemes and realms could use some elaboration. The authors of this draft were > >> reluctant to get into those weeds. It isn't clear what the right mechanism is to do that. > >> > >> I had a (non-sip) use case in mind: a site I visit allows you register directly with the site, resulting in an ability to use Digest credentials. The login page on the > >> site offers that as an option, along with the alternatives of Facebook, Google, and maybe some others. I can see something just like that for SIP. Presumably it > >> would be achieved by challenging with Digest and also with Bearer for Facebook, Google, etc. The UAC then "chooses" by delegating the choice to the user through the UI. > >> > >> This is also the case where the "whitelist" really resides within the end user's head rather than in the UAC. > >> > >> It gets harder for devices that might be connecting when there is no end user present. This can happen with a "phone" that attempts to be permanently registered > >> to its sip server so that in can receive incoming calls. If it reboots in the middle of the night there is no user handy to interact in the authentication process. It all > >> has to take place using credentials preconfigured (or cached) in the UAC. > > > > I think it’s critical - and I’ve also raised the issue before like Paul - that we develop a BCP for the various combinations we have - both two types of digest algorithms and now the OAuth2/OpenID Connect. > > There are huge risks of mis-configured platforms allowing for downgrade attacks, so even if you’ve added stronger authentication, someone will misuse your system because MD5 was still open with simple passwords for some very old SIP phones. > > I agree that such BCP (or whatever form it would take) would be useful. As I said before, I think it should be done as a separate task. How much do you think would be SIP-specific in such a document, vs. being applicable to both SIP and HTTP? > Therefore, in the authnz draft the suggestion is to say that the processing is based on "local policy". I'm happy to leave the choice of which one to use as up to local policy, but would object to giving local policy the ability to use multiple mechanisms in combination without defining the semantics of such combinations. > If people want, we can add a note saying that a future specification may provide more detailed procedures and guidance regarding processing multiple schemes. That seems reasonable, if consistent with the above. -Ben From nobody Fri Apr 24 13:20:09 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C33A0A5F; Fri, 24 Apr 2020 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 C75ztMqsqCht; Fri, 24 Apr 2020 13:20:04 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4E0493A0A5E; Fri, 24 Apr 2020 13:20:04 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03OKJsHm011362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Apr 2020 16:19:56 -0400 Date: Fri, 24 Apr 2020 13:19:54 -0700 From: Benjamin Kaduk To: Christer Holmberg Cc: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Message-ID: <20200424201954.GY27494@kduck.mit.edu> References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 20:20:07 -0000 Hi Christer, On Thu, Apr 23, 2020 at 09:03:53PM +0000, Christer Holmberg wrote: > Hi Benjamin, > > Thank You for the review! In this reply I will address some of your COMMENT issues, and indicate the ones that I want Rifaat to address. Your DISCUSS will be addressed in a separate realy. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 1 > > > > The OpenID Connect 1.0 specification [OPENID] defines a simple > > identity layer on top of the OAuth 2.0 protocol, which enables > > clients to verify the identity of the user based on the > > > > Please make it clear that these are OAuth/OIDC clients, not SIP clients. > > I'll leave this for Rifaat. > > --- > > > Section 1.3 > > > > OAuth 2.0 doesn't require the issuance of a Refresh token, but the > > discussion here implies that for the SIP case there will always be a refresh > > token. If we're profiling 6749 in this manner, we should be more explicit > > about the requirement to issue refresh tokens. > > I am not sure whether the intention is to say that there will always be a refresh token. But, I'll leave this for Rifaat. > > > * ID Token: this token contains the SIP URI and other user-specific > > details that will be consumed by the UAC. > > > > nit: I don't think we should use the definite article in "the SIP URI" since > > we haven't discussed any such SIP URI usage yet. That is, we should say > > what it's used for, e.g., "a SIP URI associated with the user". > > I'll leave this for Rifaat. > > > * Structured Token: a token that consists of a structured object > > that contains the claims associated with the token, e.g. JWT as > > defined in [RFC7519]. > > > > nit: comma after "e.g.". > > Will be fixed. > > > * Reference Token: a token that consists of a random string that is > > used to obtain the details of the token and its associated claims, > > as defined in [RFC6749]. > > > > It doesn't technically have to be random (though in practice it should > > contain signficant random elements); "opaque" might be better wording. > > I'll leave this for Rifaat. > > > Section 1.4.1 > > > > Perhaps Figure 1 could include some indication that steps 5 and 6 are > > optional/do not always occur (in the case when the access token is a > > self-contained JWT)? > > I'll leave this for Rifaat. > > > In step [2], the registrar challenges the UA, by sending a SIP 401 > > (Unauthorized) response to the REGISTER request. In the response, > > the registrar includes information about the AS to contact in order > > to obtain a token. > > > > The UAC needs to have a preconfigured whitelist of acceptable ASes in order > > to avoid directing the user's credentials to malicious sites. > > This is related to your DISCUSS, so it will be addressed as part of that. > > > The registrar validates the access token. If the access token is a > > reference token, the registrar MAY perform an introspection > > [RFC7662], as in steps [5] and [6], in order to obtain more > > information about the access token and its scope, per [RFC7662]. > > > > I think we could tighten up the normative language a bit here. > > In particular, the registrar MUST validate the token in some fashion; for > > reference tokens, the main ways to do that are either inspection or > > (essentially) being the party that issued the token in the first place. > > > > Otherwise, after the registrar validates the token to make sure it > > was signed by a trusted entity, it inspects its claims and acts upon > > it. > > > > I think we can also be more specific than "a trusted entity" -- in this > > flow, it looks like the registrar should know exactly which entity should > > have signed the token in question (for the user in question), and should not > > accept a signed token from a different entity that happens to be trusted to > > issue other tokens. > > The text in Section 2.2. mandates the validation: > > "When a UAS/Registrar receives a SIP request that contains an > Authorization header field with an access token, the UAS/Registrar > MUST validate the access token,..." > > I don't think we should put too much normative text into the example flows. Perhaps we should just say "validates the token" (and not "to ") in this example? > > Section 1.4.2 > > > > (Similarly, Figure 2 could note that steps 3 and 4 do not always occur, and > > the text about token validation should remain parallel between examples.) > > I'll leave this for Rifaat. > > ---- > > > Section 2 > > > > I note that RFC 3261 explicitly disclaims any definition of authorization > > systems, which is not true for this document, given that OAuth is an > > authorization system :) > > RFC 3261 only says that the RFC does not recommend or discuss any authorization system. > > > Section 2.1.1 > > > > Required) response with a Proxy-Authenticate header field. If the > > WWW-Authenticate or Proxy-Authenticate header field indicates > > "Bearer" scheme authentication and contains an address to an > > authorization server, the UAC contacts the authorization server in > > order to obtain tokens, and includes the requested scopes, based on a > > local configuration (Figure 1). > > > > [whitelist of allowed ASes, again] > > Will be addressed when the DISCUSS is addressed. > > > The detailed OAuth2 procedure to authenticate the user and obtain > > these tokens is out of scope of this document. The address of the > > authorization server might already be known to the UAC via > > configuration. In which case, the UAC can contact the authorization > > server for tokens before it sends a SIP request (Figure 2). > > > > nit: I think that "in which case" functions as a conjunction, which makes > > this an incomplete sentence. > > The text was suggested by one of the reviewers, but I agree it sounds incomplete. > > Perhaps "In such cases"? I think that works. > > The tokens returned to the UAC depend on the type of authorization > > server (AS): an OAuth AS provides an access token and refresh token > > [RFC6749]. The UAC provides the access token to the SIP servers to > > > > Again, this implies that refresh tokens are always issued; RFC 6749 is quite > > clear that "issuing a refresh token is optional at the discretion of the > > authorization server". > > I'll leave this for Rifaat. > > > authorize UAC's access to the service. The UAC uses the refresh > > token only with the AS to get a new access token and refresh token > > before the expiry of the current access token (see [RFC6749], section > > > > (New refresh token is also optional.) > > I'll leave this for Rifaat. > > > 1.5 Refresh Token for details). An OpenID Connect server returns an > > additional ID-Token containing the SIP URI and other user-specific > > details that will be consumed by the UAC. > > > > [same comment as above about "the SIP URI".] > > I'll leave this for Rifaat. > > > If the UAC receives a 401/407 response with multiple WWW- > > Authenticate/Proxy-Authenticate header fields, providing challenges > > using different authentication schemes for the same realm, the UAC > > selects one or more of the provided schemes (based on local policy) > > and provides credentials for those schemes. > > > > RFC 3261 seems to be written in a world that assumed that Basic and Digest > > are the only defined HTTP authentication schemes, and since it prohibits > > Basic, that there would only be one authentication challenge (type) > > possible. This text righly acknowledges that we are opening the field up > > and could have cases where multiple authentication schemes are possible; > > however, it goes even further and admits the possibility of using them > > simultaneously. It seems like this places an onus on us to give some > > indication of the semantics when multiple schemes are used at the same time. > > Do the authenticated identities need to match? Or are we asserting that > > both/all identities are consenting to the request in question? (If we don't > > have a concrete use case in mind, perhaps the "or more" is just opening a > > box that we don't need to open right now.) > > I can modify as suggested. > > (Personally, I have never seen multiple schemes in a deployment.) > > > Section 2.1.2 > > > > access to it. Endpoints that support this specification MUST support > > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting > > access tokens when they are included in SIP requests, unless some > > other mechanism is used to guarantee that only authorized SIP > > endpoints have access to the access token. > > > > I think we may want "MUST support" (always) and "MUST use, unless some other > > mechanism". > > Based on another review, I suggested to change to "MUST use". I am not sure whether we need to keep "MUST support". I think "MUST use" implies "MUST support", yes. > > I'd also suggest a quick note that TLS remains fine for protecting the > > UAC/AS interaction where the refresh token is used. > > I can do that. > > I could also say "*SIP* endpoints that support this specification...". Either sounds good. > > Whatever is done, please harmonize with Section 5 that has essentially the > > same text. > > Will do. > > > Section 2.1.3 > > > > Based on local policy, the UAC MAY include an access token that has > > been used for another binding associated with the same Address Of > > Record (AOR) in the request. > > > > Just to check: there's no real privacy considerations with such use, as its > > the same parties interacting and there are other identifiers (e.g., IP > > addresses) to confirm that it's the same client communicating to the server? > > I'll leave this for Rifaat. > > > Also, is it clear what will be done (new token request) when the MAY is not > > heeded? > > I'll leave this for Rifaat. > > > Section 2.1.4 > > > > The text here just talks about "a valid access token" and similar, without > > saying a whole lot about it being related in any way to the specifics of the > > authentication challenge. Is there something useful to say about, e.g., the > > token in question having been issued by the authorization server indicated > > in the challenge? > > I'll leave this for Rifaat. > > > Section 2.2 > > > > authorization credentials acceptable to it, it SHOULD challenge the > > request by sending a 401 (Unauthorized) response. To indicate that > > it is willing to accept an access token as a credential, the UAS/ > > Registrar MUST include a Proxy-Authentication header field in the > > response that indicates "Bearer" scheme and includes an address of an > > > > nit(?): I'd consider just making this a declarative statement, a la "the > > UAS/registrar includes a Proxy-Authentication header field with the "Bearer" > > scheme to indicate that it is willing to accept an access token as a > > credential" (but that wording is incomplete and would need to be fleshed > > out a bit more). > > I think that would be weird. Because, first we say that the UAS/Registrar SHOULD challenge, and with your suggestion the text would say that the UAS/Registrar MUST include a Proxy-Authentication header field even if it does NOT challenge the request. > > Perhaps: > > "If the UAS/Registrar chooses to challenge the request, and is willing to accept an access token as a credential, the UAS/Registrar MUST include a..." This version does get rid of the confusion about whether the MUST is conditional that I wanted to address, thanks. (I see I didn't actually say why I proposed the change I did, whoops.) > > authorization server from which the originator can obtain an access > > token. > > > > nit: "address of" an AS, does that mean bare IP address only or is a DNS > > name okay? > > I'll leave this for Rifaat. > > > [RFC7519]. If the token provided is an expired access token, then > > the UAS MUST reply with 401 Unauthorized, as defined in section 3 of > > [RFC6750]. If the validation is successful, the UAS/Registrar can > > continue to process the request using normal SIP procedures. If the > > validation fails, the UAS/Registrar MUST reject the request. > > > > Is "expired" the only case that should get a 401 vs. outright rejection, as > > stated here? > > 401 is sent also in the case where the validation fails. I will clarify that. > > > Section 2.3 > > > > sending a 407 (Proxy Authentication Required) response. To indicate > > that it is willing to accept an access token as a credential, the > > proxy MUST include a Proxy-Authentication header field in the > > response that indicates "Bearer" scheme and includes an address to an > > > > [same comment as above about normative vs. declarative statement] > > Also, please keep the text parallel between sections -- this copy has at > > least one nit ("address to an" vs. "address of an"). > > I will fix this in the same way. > > > Section 3 > > > > If an access token is encoded as a JWT, it might contain a list of > > claims [RFC7519], some registered and some application-specific. The > > > > I don't think there's a question of whether a JWT will contain a list of > > claims :) > > Fair enough :) > > > Maybe "If the access token is encoded as a JWT, it will contain a list of > > claims [RFC7519], which may include both registered and application-specific > > claims"? > > Looks good to me, but I'll leave this for Rifaat. > > ---- > > > Section 4 > > > > This section claims to cover WWW-Authenticate. What specification will the > > SIP use of Bearer for Authorization operate under? > > RFC 6750. > > Section 2.1.3 says: > > "The UAC sends a REGISTER request with an Authorization header field > containing the response to the challenge, including the Bearer scheme > carrying a valid access token in the request, as specified in > [RFC6750]." Okay, thanks for the reminder. > > challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) > > > > side note: is there a mnemonic for the "cln" in "bearer-cln"? > > RFC 3261 uses "cln" for digest. > > > bearer-cln = realm / scope / authz-server / error / > > auth-param > > > > nit: realm is already included in auth-param, though I don't see a harm in > > calling it out explicitly. > > auth-param is used to allow possible new parameters in the future. > > > realm = > > auth-param = > > > > RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of these; we > > could perhaps short-circuit the chain and say "defined in RFC 7235". > > We discussed this in the WG, and the outcome was to keep the same references as RFC 3261, since that is what people are implementing. > > Then, as a separate task, someone could update RFC 3261 with the new references. > > --- > > > Section 5 > > > > We should probably note that SIP makes much heavier use of proxies than is > > common in the web world of OAuth. > > Maybe something like: > > "However, SIP makes have use of intermediary SIP proxies, and TLS only guarantees hop-to-hop protection when used to > protect SIP signaling." Sure, that should work. > > I'm happy to see that some privacy considerations are being added in > > response to Barry's review. > > Good :) > > --- > > > Section 8 > > > > I think RFCs 8252 and 8414 could be just informative. > > I can fix that. Thanks for the updates, and I'll look for the additional threads. -Ben From nobody Fri Apr 24 14:51:43 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0523A0D12; Fri, 24 Apr 2020 14:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 WqZ9-BwkQ7tf; Fri, 24 Apr 2020 14:51:38 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30063.outbound.protection.outlook.com [40.107.3.63]) (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 6B73C3A0D0F; Fri, 24 Apr 2020 14:51:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TOsnf/PwZtyOKeFzjlnoNbFjxdZIa3Q1sPnR+wmYYrprJBsKUfIaLmQ5K3wyx/bf0NN3gPp7wlk3fsRhHE0UUC9bgotVfyOOjP2xv9Xid0LyLUtNXF1pdhdp3TZ7Mjc9q+kLqtOZ57Tn7yf4/uMDFSXZn/G5+GJZEgNYdKvFXvILecebw2euyarzJabn4fPzo6TCKCGNFJIaCilz47ZjAu7ivUhYhMbmKTs+ts06412iJREYN0Sc7w8vfXgq9O/CfKFhPNFk7tu1/gQBUraziXcZN1F1SoRj4QFPyCtO2xcfkB5u3tXfLVuVAT1X+d7QLSeNqusrN7rqCl8VRp1Qpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wi7Dsk4bqD+zkZTU0/XHHf5Q22ewXqtCO80YgMXe0iw=; b=SqyHcoF0+4KCGhcrxwWeofWQwQHikDnrEyUP4E1gBhS8mQfZSh/7yGINUdi05pWvfxI5GrQw61/lb7LDaogLrJTlJxQNyfL2A7f38Ia+eUbqupXNoWPVFAkYeUiYEVy8mCqabUgXl3+MGQqmOPUiy5msSrG2bp9WdwP+cer6su6v/zUk1CVjRIywPt//gsPFhJIMyn+85sXBMO+6foYvPDfGMeloUzCvzDE97aKirUq1+ZmNHV2Yx6pkYJAPDRbfKfo0EPE4Ef4ff7uWwfDPxEf7/e5PYUKod6NZRvW4tJ8XJGUZrGiy73OydeWyjmOcKXglSukonLd/myrN2vefsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wi7Dsk4bqD+zkZTU0/XHHf5Q22ewXqtCO80YgMXe0iw=; b=ZFXKkJ8COrLyOLZzpbo+yu1Pv1EB2NXG/gysWZ1fxHBDYlmWhRRSYjY9jclV/sOEkrzoC4o16Rf1EdM4+M8s9mqZla5GNRQ8Vgpn3UIPUxzfQ25NueucuWnKSF3pcs9MtxN5mCzc/H2PaNGfWajXlYXSDfCIUM7EIJZndZRKLhg= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB5489.eurprd07.prod.outlook.com (2603:10a6:208:102::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Fri, 24 Apr 2020 21:51:35 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 21:51:35 +0000 From: Christer Holmberg To: Benjamin Kaduk CC: "Olle E. Johansson" , Paul Kyzivat , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) Thread-Index: AQHWGaTv/W/UMLKp7ECr0CNaSmCuWKiHL6oAgACauACAADsIgIAAsN8AgABNwgA= Date: Fri, 24 Apr 2020 21:51:35 +0000 Message-ID: <34A7E724-6E92-4C66-95B5-22F3A22F8CE3@ericsson.com> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> <20200424201316.GX27494@kduck.mit.edu> In-Reply-To: <20200424201316.GX27494@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2c7cb4d-5f88-40e2-cedd-08d7e899a88d x-ms-traffictypediagnostic: AM0PR07MB5489: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(39860400002)(346002)(376002)(366004)(6512007)(2906002)(186003)(66446008)(36756003)(6486002)(76116006)(91956017)(66476007)(6506007)(66556008)(44832011)(64756008)(26005)(86362001)(66946007)(33656002)(2616005)(8676002)(8936002)(81156014)(4326008)(6916009)(478600001)(316002)(5660300002)(71200400001)(54906003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: am7MSU1hI/1IMqLFBTtEGGyBiXuXSf2CBlsmyPB95i+1mMWC14e4Qc/cgJW0JaScIfM+5kirIDWq37H2PPpB1Enyip9VHhi4ugpUcZc4lMaHt2eS700fqjt6a2MLzfVl0Dd8jubQNcLvvMxyaD2fKOvNvYO5Dh5G6joY9thV275Bm8e+V8rj+8I1Kb8zY8sR2U/dl5zq7QfcHcYkmXeXTqL7PRYTTvD4xJ7o5S4hjwBltyjIO9tovAB5EdhZH6xqB2ZVAta5s+SjxYm+nzfr4PHgt04MUpx7/RirC6YNmj1vVVYXlMjbYDu5e09zwvSYI3XmMChHqF0Fvstk5spffAc8tv47EPo4WZfACMZLx2qpM0BDJ6zPNmTopg68oZYWHDXzahRNMcu0lCGR2XMg6o7rp2P9hyZAmKInxb35XnLzGmjJ6knKfcudtG1Vx7kg x-ms-exchange-antispam-messagedata: 1rNVzo+8d365hAk3CV02q2WqDd/aoIOc2gV8ECGtCpGsYuS0ET+uPcwoeBbJAqAvjSHj5bt780qa5B2gUsQZBrGO5r7s/Ad6JNXvey8ow2X7TYq2hP+oOutz+jUFebUHqrEjXdNAvlMp3pQ4OACIoXF2N4wApPwxEhDqWkdd8ANh4sUNImj1cL6zbq3cw+tmvLXuJIikt2AWEFgndQOPPyPVIo0evm8ppNuF3IbRugefRy4Ife2TsEA5JY/0rnLqleCthza8bgNNWCtXPOwsbhB//l9JUfiqoeZMvRMtsoKXyQI2cK83uk262ye7PcyLEKtzvDpGIzTam2M+O+1YV+XWyzJC0dQPSoum/BYb3di+J67jGKlhghH/maztub0Kh3Z0KozCr19hcDDuO1kaO0qox/0UE7atJqDdMVNijMeUrwPCtiDoVLBZqTenB+e9zIOYJHPvqHs8AKs+mky716BZ5LY+g1zjDeyEkxkM8aMxTqBI41Q6qGmhast6AM/z+afGO21DOsslRS4l6Sjyy87nTeN609F9GHrHb7xUTZJKIAAmCjFjF9JI5alNWB5H53iU+qv92N9lunb76fujhJsL61+MNxlA+3KKkB0G1AUtDf5fvW3TkqJK7diHXx5qPDJ1MP57wu0vjvslDUXu2OknLjCpGWeW57tbmqg95eQYQ1xDBlMXmts84AiURVPNU5Aazh4QXqboJ+VELMLfZSYho8sS2ZMTd505SBrMhhPLkfrmGuLPSVQ7NCSERUmHa90cXZQf6OYeAY6XKyujsL0nBcHsd3V5mUEeYth2Iug= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2c7cb4d-5f88-40e2-cedd-08d7e899a88d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 21:51:35.1151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mfbWR/60DMJaURnuwqbGp7lIBpNujnIbRX1Cz125xKG6yki2eucpA6DAIqe+692cFAf+1rr7Q7gXb5QckMwSiAweQLZB9FpQWsUhhU/tiF4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5489 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 21:51:41 -0000 SGksDQoNCiAgICA+Pj4+PiBSRkMgMzI2MSBzZWVtcyB0byBiZSB3cml0dGVuIGluIGEgd29ybGQg dGhhdCBhc3N1bWVkIHRoYXQgQmFzaWMgYW5kIERpZ2VzdA0KICAgID4+Pj4+IGFyZSB0aGUgb25s eSBkZWZpbmVkIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcywgYW5kIHNpbmNlIGl0IHByb2hp Yml0cw0KICAgID4+Pj4+IEJhc2ljLCB0aGF0IHRoZXJlIHdvdWxkIG9ubHkgYmUgb25lIGF1dGhl bnRpY2F0aW9uIGNoYWxsZW5nZSAodHlwZSkNCiAgICA+Pj4+PiBwb3NzaWJsZS4gIFRoaXMgdGV4 dCByaWdobHkgYWNrbm93bGVkZ2VzIHRoYXQgd2UgYXJlIG9wZW5pbmcgdGhlIGZpZWxkIHVwDQog ICAgPj4+Pj4gYW5kIGNvdWxkIGhhdmUgY2FzZXMgd2hlcmUgbXVsdGlwbGUgYXV0aGVudGljYXRp b24gc2NoZW1lcyBhcmUgcG9zc2libGU7DQogICAgPj4+Pj4gaG93ZXZlciwgaXQgZ29lcyBldmVu IGZ1cnRoZXIgYW5kIGFkbWl0cyB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgdGhlbQ0KICAgID4+ Pj4+IHNpbXVsdGFuZW91c2x5LiAgSXQgc2VlbXMgbGlrZSB0aGlzIHBsYWNlcyBhbiBvbnVzIG9u IHVzIHRvIGdpdmUgc29tZQ0KICAgID4+Pj4+IGluZGljYXRpb24gb2YgdGhlIHNlbWFudGljcyB3 aGVuIG11bHRpcGxlIHNjaGVtZXMgYXJlIHVzZWQgYXQgdGhlIHNhbWUgdGltZS4NCiAgICA+Pj4+ PiBEbyB0aGUgYXV0aGVudGljYXRlZCBpZGVudGl0aWVzIG5lZWQgdG8gbWF0Y2g/ICBPciBhcmUg d2UgYXNzZXJ0aW5nIHRoYXQNCiAgICA+Pj4+PiBib3RoL2FsbCBpZGVudGl0aWVzIGFyZSBjb25z ZW50aW5nIHRvIHRoZSByZXF1ZXN0IGluIHF1ZXN0aW9uPyAgKElmIHdlIGRvbid0DQogICAgPj4+ Pj4gaGF2ZSBhIGNvbmNyZXRlIHVzZSBjYXNlIGluIG1pbmQsIHBlcmhhcHMgdGhlICJvciBtb3Jl IiBpcyBqdXN0IG9wZW5pbmcgYQ0KICAgID4+Pj4+IGJveCB0aGF0IHdlIGRvbid0IG5lZWQgdG8g b3BlbiByaWdodCBub3cuKQ0KICAgID4+Pj4gDQogICAgPj4+PiBJIHB1c2hlZCBxdWl0ZSBhIGJp dCBvbiB0aGlzIGFyZWEgZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvZiB0aGlzIGRyYWZ0LiBBcyB5 b3Ugbm90ZSB3ZSBhcmUgZGVmaW5pdGVseSBleHBhbmRpbmcgaW50byBhbiBhcmVhIHRoYXQgd2Fz bid0IGFudGljaXBhdGVkIGluIFJGQzMyNjEuDQogICAgPj4+PiBUaGUgd2hvbGUgdG9waWMgb2Yg aG93IGF1dGhlbnRpY2F0aW9uIHdvcmtzIGluIHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBsZSBzY2hl bWVzIGFuZCByZWFsbXMgY291bGQgdXNlIHNvbWUgZWxhYm9yYXRpb24uIFRoZSBhdXRob3JzIG9m IHRoaXMgZHJhZnQgd2VyZQ0KICAgID4+Pj4gcmVsdWN0YW50IHRvIGdldCBpbnRvIHRob3NlIHdl ZWRzLiBJdCBpc24ndCBjbGVhciB3aGF0IHRoZSByaWdodCBtZWNoYW5pc20gaXMgdG8gZG8gdGhh dC4NCiAgICA+Pj4+IA0KICAgID4+Pj4gSSBoYWQgYSAobm9uLXNpcCkgdXNlIGNhc2UgaW4gbWlu ZDogYSBzaXRlIEkgdmlzaXQgYWxsb3dzIHlvdSByZWdpc3RlciBkaXJlY3RseSB3aXRoIHRoZSBz aXRlLCByZXN1bHRpbmcgaW4gYW4gYWJpbGl0eSB0byB1c2UgRGlnZXN0IGNyZWRlbnRpYWxzLiBU aGUgbG9naW4gcGFnZSBvbiB0aGUNCiAgICA+Pj4+IHNpdGUgb2ZmZXJzIHRoYXQgYXMgYW4gb3B0 aW9uLCBhbG9uZyB3aXRoIHRoZSBhbHRlcm5hdGl2ZXMgb2YgRmFjZWJvb2ssIEdvb2dsZSwgYW5k IG1heWJlIHNvbWUgb3RoZXJzLiBJIGNhbiBzZWUgc29tZXRoaW5nIGp1c3QgbGlrZSB0aGF0IGZv ciBTSVAuIFByZXN1bWFibHkgaXQNCiAgICA+Pj4+IHdvdWxkIGJlIGFjaGlldmVkIGJ5IGNoYWxs ZW5naW5nIHdpdGggRGlnZXN0IGFuZCBhbHNvIHdpdGggQmVhcmVyIGZvciBGYWNlYm9vaywgR29v Z2xlLCBldGMuIFRoZSBVQUMgdGhlbiAiY2hvb3NlcyIgYnkgZGVsZWdhdGluZyB0aGUgY2hvaWNl IHRvIHRoZSB1c2VyIHRocm91Z2ggdGhlIFVJLg0KICAgID4+Pj4gDQogICAgPj4+PiBUaGlzIGlz IGFsc28gdGhlIGNhc2Ugd2hlcmUgdGhlICJ3aGl0ZWxpc3QiIHJlYWxseSByZXNpZGVzIHdpdGhp biB0aGUgZW5kIHVzZXIncyBoZWFkIHJhdGhlciB0aGFuIGluIHRoZSBVQUMuDQogICAgPj4+PiAN CiAgICA+Pj4+IEl0IGdldHMgaGFyZGVyIGZvciBkZXZpY2VzIHRoYXQgbWlnaHQgYmUgY29ubmVj dGluZyB3aGVuIHRoZXJlIGlzIG5vIGVuZCB1c2VyIHByZXNlbnQuIFRoaXMgY2FuIGhhcHBlbiB3 aXRoIGEgInBob25lIiB0aGF0IGF0dGVtcHRzIHRvIGJlIHBlcm1hbmVudGx5IHJlZ2lzdGVyZWQN CiAgICA+Pj4+IHRvIGl0cyBzaXAgc2VydmVyIHNvIHRoYXQgaW4gY2FuIHJlY2VpdmUgaW5jb21p bmcgY2FsbHMuIElmIGl0IHJlYm9vdHMgaW4gdGhlIG1pZGRsZSBvZiB0aGUgbmlnaHQgdGhlcmUg aXMgbm8gdXNlciBoYW5keSB0byBpbnRlcmFjdCBpbiB0aGUgYXV0aGVudGljYXRpb24gcHJvY2Vz cy4gSXQgYWxsDQogICAgPj4+PiBoYXMgdG8gdGFrZSBwbGFjZSB1c2luZyBjcmVkZW50aWFscyBw cmVjb25maWd1cmVkIChvciBjYWNoZWQpIGluIHRoZSBVQUMuDQogICAgPj4+IA0KICAgID4+PiBJ IHRoaW5rIGl04oCZcyBjcml0aWNhbCAtIGFuZCBJ4oCZdmUgYWxzbyByYWlzZWQgdGhlIGlzc3Vl IGJlZm9yZSBsaWtlIFBhdWwgLSB0aGF0IHdlIGRldmVsb3AgYSBCQ1AgZm9yIHRoZSB2YXJpb3Vz IGNvbWJpbmF0aW9ucyB3ZSBoYXZlIC0gYm90aCB0d28gdHlwZXMgb2YgZGlnZXN0IGFsZ29yaXRo bXMgYW5kIG5vdyB0aGUgT0F1dGgyL09wZW5JRCBDb25uZWN0Lg0KICAgID4+PiBUaGVyZSBhcmUg aHVnZSByaXNrcyBvZiBtaXMtY29uZmlndXJlZCBwbGF0Zm9ybXMgYWxsb3dpbmcgZm9yIGRvd25n cmFkZSBhdHRhY2tzLCBzbyBldmVuIGlmIHlvdeKAmXZlIGFkZGVkIHN0cm9uZ2VyIGF1dGhlbnRp Y2F0aW9uLCBzb21lb25lIHdpbGwgbWlzdXNlIHlvdXIgc3lzdGVtIGJlY2F1c2UgTUQ1IHdhcyBz dGlsbCBvcGVuIHdpdGggc2ltcGxlIHBhc3N3b3JkcyBmb3Igc29tZSB2ZXJ5IG9sZCBTSVAgcGhv bmVzLg0KICAgID4+IA0KICAgID4+ICBJIGFncmVlIHRoYXQgc3VjaCBCQ1AgKG9yIHdoYXRldmVy IGZvcm0gaXQgd291bGQgdGFrZSkgd291bGQgYmUgdXNlZnVsLiBBcyBJIHNhaWQgYmVmb3JlLCBJ IHRoaW5rIGl0IHNob3VsZCBiZSBkb25lIGFzIGEgc2VwYXJhdGUgdGFzay4NCiAgICA+DQogICAg PiBIb3cgbXVjaCBkbyB5b3UgdGhpbmsgd291bGQgYmUgU0lQLXNwZWNpZmljIGluIHN1Y2ggYSBk b2N1bWVudCwgdnMuIGJlaW5nDQogICAgPiBhcHBsaWNhYmxlIHRvIGJvdGggU0lQIGFuZCBIVFRQ Pw0KICAgIA0KICAgIEkgZG9uJ3Qga25vdyAtIHBlcmhhcHMgdGhlcmUgd291bGQgYmUgbm90aGlu ZyBTSVAtc3BlY2lmaWMuIA0KDQogICAgPj4gICAgIFRoZXJlZm9yZSwgaW4gdGhlIGF1dGhueiBk cmFmdCB0aGUgc3VnZ2VzdGlvbiBpcyB0byBzYXkgdGhhdCB0aGUgcHJvY2Vzc2luZyBpcyBiYXNl ZCBvbiAibG9jYWwgcG9saWN5Ii4NCiAgICA+DQogICAgPiBJJ20gaGFwcHkgdG8gbGVhdmUgdGhl IGNob2ljZSBvZiB3aGljaCBvbmUgdG8gdXNlIGFzIHVwIHRvIGxvY2FsIHBvbGljeSwNCiAgICA+ IGJ1dCB3b3VsZCBvYmplY3QgdG8gZ2l2aW5nIGxvY2FsIHBvbGljeSB0aGUgYWJpbGl0eSB0byB1 c2UgbXVsdGlwbGUNCiAgICA+IG1lY2hhbmlzbXMgaW4gY29tYmluYXRpb24gd2l0aG91dCBkZWZp bmluZyB0aGUgc2VtYW50aWNzIG9mIHN1Y2gNCiAgICA+IGNvbWJpbmF0aW9ucy4NCiAgICA+DQog ICAgPj4gSWYgcGVvcGxlIHdhbnQsIHdlIGNhbiBhZGQgYSBub3RlIHNheWluZyB0aGF0IGEgZnV0 dXJlIHNwZWNpZmljYXRpb24gbWF5IHByb3ZpZGUgbW9yZSBkZXRhaWxlZCBwcm9jZWR1cmVzIGFu ZCBndWlkYW5jZSByZWdhcmRpbmcgcHJvY2Vzc2luZyBtdWx0aXBsZSBzY2hlbWVzLg0KICAgID4N CiAgICA+IFRoYXQgc2VlbXMgcmVhc29uYWJsZSwgaWYgY29uc2lzdGVudCB3aXRoIHRoZSBhYm92 ZS4NCiAgICANCiAgICBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZzoNCg0KT0xEOg0KDQogICBJZiB0 aGUgVUFDIHJlY2VpdmVzIGEgNDAxLzQwNyByZXNwb25zZSB3aXRoIG11bHRpcGxlIFdXVy0NCiAg IEF1dGhlbnRpY2F0ZS9Qcm94eS1BdXRoZW50aWNhdGUgaGVhZGVyIGZpZWxkcywgcHJvdmlkaW5n IGNoYWxsZW5nZXMNCiAgIHVzaW5nIGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGZv ciB0aGUgc2FtZSByZWFsbSwgdGhlIFVBQw0KICAgcHJvdmlkZXMgY3JlZGVudGlhbHMgZm9yIG9u ZSBvciBtb3JlIG9mIHRoZSBzY2hlbWVzIHRoYXQgaXQgc3VwcG9ydHMsDQogICBiYXNlZCBvbiBs b2NhbCBwb2xpY3kuDQoNCk5FVzoNCg0KICAgSWYgdGhlIFVBQyByZWNlaXZlcyBhIDQwMS80MDcg cmVzcG9uc2Ugd2l0aCBtdWx0aXBsZSBXV1ctDQogICBBdXRoZW50aWNhdGUvUHJveHktQXV0aGVu dGljYXRlIGhlYWRlciBmaWVsZHMsIHByb3ZpZGluZyBjaGFsbGVuZ2VzDQogICB1c2luZyBkaWZm ZXJlbnQgYXV0aGVudGljYXRpb24gc2NoZW1lcyBmb3IgdGhlIHNhbWUgcmVhbG0sIHRoZSBVQUMN CiAgIHByb3ZpZGVzIGNyZWRlbnRpYWxzIGZvciBvbmUgb2YgdGhlIHNjaGVtZXMgdGhhdCBpdCBz dXBwb3J0cywNCiAgIGJhc2VkIG9uIGxvY2FsIHBvbGljeS4NCg0KICAgTk9URTogQXQgdGhlIHRp bWUgb2Ygd3JpdGluZyB0aGlzIHNwZWNpZmljYXRpb24sIGRldGFpbGVkIHByb2NlZHVyZXMgZm9y IHRoZSBjYXNlcyB3aGVyZSBhIFVBQyByZWNlaXZlcyBtdWx0aXBsZSANCiAgIGRpZmZlcmVudCBh dXRoZW50aWNhdGlvbiBzY2hlbWVzIGhhZCBub3QgYmVlbiBkZWZpbmVkLiBBIGZ1dHVyZSBzcGVj aWZpY2F0aW9uIG1pZ2h0IGRlZmluZSBzdWNoIHByb2NlZHVyZXMuDQoNCiAgIFJlZ2FyZHMsDQoN CiAgIENocmlzdGVyDQogICAgICAgDQoNCg== From nobody Fri Apr 24 16:14:00 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505F93A0F5A; Fri, 24 Apr 2020 16:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 qiSQsXQeDcbR; Fri, 24 Apr 2020 16:13:46 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40079.outbound.protection.outlook.com [40.107.4.79]) (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 274173A0F55; Fri, 24 Apr 2020 16:13:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BxJxsMxqPuVTPlSL8VnF3opPeOwbEMDaU5hhDHJOhnBo/zRNBhxaaf24oiGhCCJOEVZP5N7Z0643aaFrITvOeCuNIG6/+pWmrxHwa5kuYZjfNvhcty7ZSMdL5L3JP6P/UPukrlteBdE+0M592BkaSExigieZCvi1YTrVn96ntmjZqDCawJJX5XFQdLXaF4Aq0s7ULzuoeArxukSwx74p60pf1Z/MsDkJNksXHp3g4TxH/zzy54SbnLK0p95jJ9tGVkCg1FR6T1oEXDXVAvCIWMWjdfQz66QaHezIAhA/Hf6CmuTSPihjlJrl2s9piRSCBpihms0d9E3sJlO1Fc/+JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w53S8rK1WXFqgOxRw43VRrXFZSWFvucnj7RZcehGun8=; b=DvjD/aWASmtsTZzdaSt5fPpBc1DBHRss5HtQKaRUUEJOhSVzw3ScgkZXeXOAHca1cPUNDN8A77fXiHrSF7zBApcX3tFjRJToyE4vj+pSGhwkeJVGR/Do8R/+noLGcK9cPCOGbS+41Y/JHaw2KIPiHL1NNtTn+bsdlm0r47Nlkcem4qKYs1uLXJCY9KJUNcHeBA22yh9Kj/2wg8Jen0wh2iPXHTcQLolUNDGdEOp4nXVSf3KcBVtxXzLHbNEoe9YfD8uVb/tYYIB1ZOkHWEN3j75SWo5W3kY3tfTxs2ZXsc8xuFJUscdcZRI6QRZuPljWfG+4GE2SsdKiwKwrJGzWXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w53S8rK1WXFqgOxRw43VRrXFZSWFvucnj7RZcehGun8=; b=ZTWeIe3HzJAPByO0jND4lR7zRD+vuvoCB1vMP0Z9zNCMxvaA9iuFkwdOEVLIdTPMQAEhDE9HNw+PpgmDrYstHzfM2DZbEQb2lCvfcc/n6CcAAzjRDFJAcqPwqqoAinyoqcKtIGsv5jE9AC7ZvUJPD9hqUz30pDDYza9yxpA/YS0= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB3843.eurprd07.prod.outlook.com (2603:10a6:208:3f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Fri, 24 Apr 2020 23:13:41 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 23:13:41 +0000 From: Christer Holmberg To: Benjamin Kaduk CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT Thread-Index: AQHWGbKxu2gQq0gnZkyF4LBa/O+0aqiIuAgAgABi2YA= Date: Fri, 24 Apr 2020 23:13:41 +0000 Message-ID: References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> <20200424201954.GY27494@kduck.mit.edu> In-Reply-To: <20200424201954.GY27494@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ae25ed20-69dc-41a4-9d93-08d7e8a52101 x-ms-traffictypediagnostic: AM0PR07MB3843: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03838E948C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(366004)(376002)(136003)(6506007)(26005)(2906002)(2616005)(6512007)(6486002)(186003)(5660300002)(316002)(8936002)(71200400001)(81156014)(8676002)(44832011)(6916009)(54906003)(36756003)(66946007)(76116006)(33656002)(86362001)(4326008)(478600001)(91956017)(966005)(66476007)(66556008)(64756008)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vwEX62McjPirLyGbjcNsWT97WLMfZUcMRWlfwDPufQPYU3uZRSV+xEkTa7MGMSA01QetM4uAfMsKfyWGExP4J8+030+48qHeQoAEEJLYyZLwYzI5XRq07qAOdk8J50RgVA37PiKWB76qz13vSN/iTIEQ2ohMhJ5FxOrWK/NUkRBxcmJWkU9GJuMwLbJbyVUL0nlP5oBkNoDEi5B0HAOEPqvsyps9Tcb3z+9w4SWq1N0Yp3J/ZR94bBFa6O71xmvQhwVX/b8LxeyqaKP4Rho7ugs1MhWvZKaQ3ZJBvLuQk3lBvY0m7naCp+ygwAN6rf0clfxYAlOrOlM+M6ThHsKkSdQIXzwVTMbUnWXooMfW/dF5NkZfiF/LSgB/M1WdzsFy/qlwvXyQbGOKBsiGu3BNHo4F8czF3Fv4VU8WbA1lVkyIzxb502dlYKMrt46wspTbL2l9ki2rP69etIxckLHUJ+sWtnoRqtpXCOx7sEVdbG69iMo19KXDD5+ytm2VZk87bscKD/dGwOfDUbL1/ih/qw== x-ms-exchange-antispam-messagedata: nobt9eHOgbamXCLuL8DZvAIOq/uj6ai32OQFqf4DJPi0yg2pt4pLWAknCl4n13h6ZAQzZ9xHAu1nhP9HBPHQazjBCg9sPtJLC7n/k/GGj1pM8J8EphkImEg4l1Bw6RQMF/AY/a9hTFFlSjTExmaKAYXl2jwXSaiYTP35YlN6Df0IXHtWWPB0v97u1QV2NWa+Z+oXQY4vXkbbCnVwisybUSqJH9TpQyNh4deeW7+RtMO0gDph+eyVeRtvl44SfAoABazjueP2SZg1ls69bmiMDUxni+kQuS3ByIeEqPTBzGp8Xt4SJWpfWgJgxRriHiT9scXvzmIAR1Z2dcGfJThmIH66UOszfKO6Rx+0E7EUY1wZeiVf97huJg8xrWr3kmISR7tT54gZ5lO12ZpsA4VthoY83hqn0QeAMvxnVXXzJIeaFeR4MsNkffsviE9SjyKcvPsisek42p3yulqJrTzbIRTxV3WhWsmG1c5FdSWsQtC3OExmZ9X5tqeEbZiaoa5Mxw56O9LG+MVEmIpRsRYCY/dVqrfc2Hac2vI7SA/BNbVvDZPQ8YN0Y4uRUKhGO3mgfFldFWPirJ6ukXgvk7DENgzuSCclHB7kc/9Nk6LAffCMln6X2hvXW1sHBlJmihq/kVqBLyqs2REwg2JnYTFIucKLO0IvWjltnf9nQoXu3r9EKJb/cuRd9yXn3+zKYNCGwBqhEvv3I/TXGkb62pa2mqXopWpnZ8xQgkwKU0alQ73T2vCpHHatXmqgyLAAbUcqLfXNrJuUr2dzjAYWJg/nLlconUwTGei7xTu/m3qj48E= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae25ed20-69dc-41a4-9d93-08d7e8a52101 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 23:13:41.5797 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 39tovFpopUbWwC16RsNCucTkp5EvxF98o0S7mmM8XzBGYjLnzNcFa+TTkyEb2p89Oy2j6MBcUaqaX3QMYox8zNUqpRoH4uQjF6HPQrRh9ZU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3843 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 23:13:50 -0000 SGkgQmVuamFtaW4sDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICBDT01NRU5UOg0KICAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICAuLi4NCiAgDQogICAgU2VjdGlvbiAxLjQuMQ0KICAg IC4uLg0KDQogICAgPj4+ICAgICAgIFRoZSByZWdpc3RyYXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3Mg dG9rZW4uICBJZiB0aGUgYWNjZXNzIHRva2VuIGlzIGENCiAgICA+Pj4gICAgICAgcmVmZXJlbmNl IHRva2VuLCB0aGUgcmVnaXN0cmFyIE1BWSBwZXJmb3JtIGFuIGludHJvc3BlY3Rpb24NCiAgICA+ Pj4gICAgICAgW1JGQzc2NjJdLCBhcyBpbiBzdGVwcyBbNV0gYW5kIFs2XSwgaW4gb3JkZXIgdG8g b2J0YWluIG1vcmUNCiAgICA+Pj4gICAgICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGFjY2VzcyB0 b2tlbiBhbmQgaXRzIHNjb3BlLCBwZXIgW1JGQzc2NjJdLg0KICAgID4+PiAgICANCiAgICA+Pj4g ICAgSSB0aGluayB3ZSBjb3VsZCB0aWdodGVuIHVwIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgYSBi aXQgaGVyZS4NCiAgICA+Pj4gICAgSW4gcGFydGljdWxhciwgdGhlIHJlZ2lzdHJhciBNVVNUIHZh bGlkYXRlIHRoZSB0b2tlbiBpbiBzb21lIGZhc2hpb247IGZvcg0KICAgID4+PiAgICByZWZlcmVu Y2UgdG9rZW5zLCB0aGUgbWFpbiB3YXlzIHRvIGRvIHRoYXQgYXJlIGVpdGhlciBpbnNwZWN0aW9u IG9yDQogICAgPj4+ICAgIChlc3NlbnRpYWxseSkgYmVpbmcgdGhlIHBhcnR5IHRoYXQgaXNzdWVk IHRoZSB0b2tlbiBpbiB0aGUgZmlyc3QgcGxhY2UuDQogICAgPj4+ICANCiAgICA+Pj4gICAgICAg T3RoZXJ3aXNlLCBhZnRlciB0aGUgcmVnaXN0cmFyIHZhbGlkYXRlcyB0aGUgdG9rZW4gdG8gbWFr ZSBzdXJlIGl0DQogICAgPj4+ICAgICAgIHdhcyBzaWduZWQgYnkgYSB0cnVzdGVkIGVudGl0eSwg aXQgaW5zcGVjdHMgaXRzIGNsYWltcyBhbmQgYWN0cyB1cG9uDQogICAgPj4+ICAgICAgIGl0Lg0K ICAgID4+PiAgICANCiAgICA+Pj4gICAgSSB0aGluayB3ZSBjYW4gYWxzbyBiZSBtb3JlIHNwZWNp ZmljIHRoYW4gImEgdHJ1c3RlZCBlbnRpdHkiIC0tIGluIHRoaXMNCiAgICA+Pj4gICAgZmxvdywg aXQgbG9va3MgbGlrZSB0aGUgcmVnaXN0cmFyIHNob3VsZCBrbm93IGV4YWN0bHkgd2hpY2ggZW50 aXR5IHNob3VsZA0KICAgID4+PiAgICBoYXZlIHNpZ25lZCB0aGUgdG9rZW4gaW4gcXVlc3Rpb24g KGZvciB0aGUgdXNlciBpbiBxdWVzdGlvbiksIGFuZCBzaG91bGQgbm90DQogICAgPj4+ICAgIGFj Y2VwdCBhIHNpZ25lZCB0b2tlbiBmcm9tIGEgZGlmZmVyZW50IGVudGl0eSB0aGF0IGhhcHBlbnMg dG8gYmUgdHJ1c3RlZCB0bw0KICAgID4+PiAgICBpc3N1ZSBvdGhlciB0b2tlbnMuDQogICAgPj4g ICAgIA0KICAgID4+IFRoZSB0ZXh0IGluIFNlY3Rpb24gMi4yLiBtYW5kYXRlcyB0aGUgdmFsaWRh dGlvbjoNCiAgICA+PiANCiAgICA+PiAgICAiV2hlbiBhIFVBUy9SZWdpc3RyYXIgcmVjZWl2ZXMg YSBTSVAgcmVxdWVzdCB0aGF0IGNvbnRhaW5zIGFuDQogICAgPj4gICAgQXV0aG9yaXphdGlvbiBo ZWFkZXIgZmllbGQgd2l0aCBhbiBhY2Nlc3MgdG9rZW4sIHRoZSBVQVMvUmVnaXN0cmFyDQogICAg Pj4gICAgTVVTVCB2YWxpZGF0ZSB0aGUgYWNjZXNzIHRva2VuLC4uLiINCiAgICA+PiANCiAgICA+ PiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBwdXQgdG9vIG11Y2ggbm9ybWF0aXZlIHRleHQgaW50 byB0aGUgZXhhbXBsZSBmbG93cy4NCiAgICA+DQogICAgPiBQZXJoYXBzIHdlIHNob3VsZCBqdXN0 IHNheSAidmFsaWRhdGVzIHRoZSB0b2tlbiIgKGFuZCBub3QgInRvIDxkbyB0aGluZyBYPiIpIGlu IHRoaXMgZXhhbXBsZT8NCiANCiAgICBTbywgc29tZXRoaW5nIGxpa2UgdGhpczoNCg0KT0xEOg0K DQogICBUaGUgcmVnaXN0cmFyIHZhbGlkYXRlcyB0aGUgYWNjZXNzIHRva2VuLiAgSWYgdGhlIGFj Y2VzcyB0b2tlbiBpcyBhDQogICByZWZlcmVuY2UgdG9rZW4sIHRoZSByZWdpc3RyYXIgTUFZIHBl cmZvcm0gYW4gaW50cm9zcGVjdGlvbg0KICAgW1JGQzc2NjJdLCBhcyBpbiBzdGVwcyBbNV0gYW5k IFs2XSwgaW4gb3JkZXIgdG8gb2J0YWluIG1vcmUNCiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBh Y2Nlc3MgdG9rZW4gYW5kIGl0cyBzY29wZSwgcGVyIFtSRkM3NjYyXS4NCiAgIE90aGVyd2lzZSwg YWZ0ZXIgdGhlIHJlZ2lzdHJhciB2YWxpZGF0ZXMgdGhlIHRva2VuIHRvIG1ha2Ugc3VyZSBpdA0K ICAgd2FzIHNpZ25lZCBieSBhIHRydXN0ZWQgZW50aXR5LCBpdCBpbnNwZWN0cyBpdHMgY2xhaW1z IGFuZCBhY3RzIHVwb24NCiAgIGl0Lg0KDQpORVc6DQoNCiAgIEluIHN0ZXAgWzRdIGFuZCBbNV0s IHRoZSByZWdpc3RyYXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4uDQoNCiAgIC0tLQ0KDQog ICAgU2VjdGlvbiAyLjEuMQ0KICAgIC4uLiAgICANCg0KICAgID4+PiAgICAgICBUaGUgZGV0YWls ZWQgT0F1dGgyIHByb2NlZHVyZSB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIgYW5kIG9idGFpbg0K ICAgID4+PiAgICAgICB0aGVzZSB0b2tlbnMgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnQuICBUaGUgYWRkcmVzcyBvZiB0aGUNCiAgICA+Pj4gICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgbWlnaHQgYWxyZWFkeSBiZSBrbm93biB0byB0aGUgVUFDIHZpYQ0KICAgID4+PiAgICAgICBj b25maWd1cmF0aW9uLiAgSW4gd2hpY2ggY2FzZSwgdGhlIFVBQyBjYW4gY29udGFjdCB0aGUgYXV0 aG9yaXphdGlvbg0KICAgID4+PiAgICAgICBzZXJ2ZXIgZm9yIHRva2VucyBiZWZvcmUgaXQgc2Vu ZHMgYSBTSVAgcmVxdWVzdCAoRmlndXJlIDIpLg0KICAgID4+PiAgICANCiAgICA+Pj4gICAgbml0 OiBJIHRoaW5rIHRoYXQgImluIHdoaWNoIGNhc2UiIGZ1bmN0aW9ucyBhcyBhIGNvbmp1bmN0aW9u LCB3aGljaCBtYWtlcw0KICAgID4+PiAgICB0aGlzIGFuIGluY29tcGxldGUgc2VudGVuY2UuDQog ICAgPj4gICANCiAgICA+PiBUaGUgdGV4dCB3YXMgc3VnZ2VzdGVkIGJ5IG9uZSBvZiB0aGUgcmV2 aWV3ZXJzLCBidXQgSSBhZ3JlZSBpdCBzb3VuZHMgaW5jb21wbGV0ZS4NCiAgICA+PiANCiAgICA+ PiBQZXJoYXBzICJJbiBzdWNoIGNhc2VzIj8NCiAgICA+DQogICAgPiBJIHRoaW5rIHRoYXQgd29y a3MuDQoNCiAgICAuLi4NCiAgICAgICAgIA0KICAgIFNlY3Rpb24gMi4xLjINCiAgICAuLi4NCiAg ICAgICAgDQogICAgPj4+ICAgICAgIGFjY2VzcyB0byBpdC4gIEVuZHBvaW50cyB0aGF0IHN1cHBv cnQgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1Qgc3VwcG9ydA0KICAgID4+PiAgICAgICBlbmNyeXB0 ZWQgSlNPTiBXZWIgVG9rZW5zIChKV1QpIFtSRkM3NTE5XSBmb3IgZW5jb2RpbmcgYW5kIHByb3Rl Y3RpbmcNCiAgICA+Pj4gICAgICAgYWNjZXNzIHRva2VucyB3aGVuIHRoZXkgYXJlIGluY2x1ZGVk IGluIFNJUCByZXF1ZXN0cywgdW5sZXNzIHNvbWUNCiAgICA+Pj4gICAgICAgb3RoZXIgbWVjaGFu aXNtIGlzIHVzZWQgdG8gZ3VhcmFudGVlIHRoYXQgb25seSBhdXRob3JpemVkIFNJUA0KICAgID4+ PiAgICAgICBlbmRwb2ludHMgaGF2ZSBhY2Nlc3MgdG8gdGhlIGFjY2VzcyB0b2tlbi4NCiAgICA+ Pj4gICAgDQogICAgPj4+ICAgIEkgdGhpbmsgd2UgbWF5IHdhbnQgIk1VU1Qgc3VwcG9ydCIgKGFs d2F5cykgYW5kICJNVVNUIHVzZSwgdW5sZXNzIHNvbWUgb3RoZXINCiAgICA+Pj4gICAgbWVjaGFu aXNtIi4NCiAgICA+PiAgIA0KICAgID4+IEJhc2VkIG9uIGFub3RoZXIgcmV2aWV3LCBJIHN1Z2dl c3RlZCB0byBjaGFuZ2UgdG8gIk1VU1QgdXNlIi4gSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHdlIG5l ZWQgdG8ga2VlcCAiTVVTVCBzdXBwb3J0Ii4NCiAgICA+DQogICAgPiBJIHRoaW5rICJNVVNUIHVz ZSIgaW1wbGllcyAiTVVTVCBzdXBwb3J0IiwgeWVzLg0KDQogICAgLi4uDQogICAgDQogICAgPj4+ ICAgIEknZCBhbHNvIHN1Z2dlc3QgYSBxdWljayBub3RlIHRoYXQgVExTIHJlbWFpbnMgZmluZSBm b3IgcHJvdGVjdGluZyB0aGUNCiAgICA+Pj4gICAgVUFDL0FTIGludGVyYWN0aW9uIHdoZXJlIHRo ZSByZWZyZXNoIHRva2VuIGlzIHVzZWQuDQogICAgPj4gICANCiAgICA+PiBJIGNhbiBkbyB0aGF0 Lg0KICAgID4+IA0KICAgID4+IEkgY291bGQgYWxzbyBzYXkgIipTSVAqIGVuZHBvaW50cyB0aGF0 IHN1cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9uLi4uIi4NCiAgICA+DQogICAgPiBFaXRoZXIgc291 bmRzIGdvb2QuDQogICAgDQogICBNeSBzdWdnZXN0aW9uIHdhcyB0byBkbyBib3RoIGNoYW5nZXMg OikgU29tZXRoaW5nIGxpa2U6DQoNCiAgICJTSVAgZW5kcG9pbnRzIHRoYXQgc3VwcG9ydCB0aGlz IHNwZWNpZmljYXRpb24gTVVTVCB1c2UgZW5jcnlwdGVkIA0KICAgSlNPTiBXZWIgVG9rZW5zIChK V1QpIFtSRkM3NTE5XSBmb3IgZW5jb2RpbmcgYW5kIHByb3RlY3RpbmcgDQogICBhY2Nlc3MgdG9r ZW5zIHdoZW4gdGhleSBhcmUgaW5jbHVkZWQgaW4gU0lQIHJlcXVlc3RzLCB1bmxlc3Mgc29tZSBv dGhlciBtZWNoYW5pc20gDQogICBpcyB1c2VkIHRvIGd1YXJhbnRlZSB0aGF0IG9ubHkgYXV0aG9y aXplZCBTSVAgZW5kcG9pbnRzIGhhdmUgYWNjZXNzIHRvIA0KICAgIHRoZSBhY2Nlc3MgdG9rZW4u IFRMUyBjYW4gc3RpbGwgYmUgdXNlZCBmb3IgcHJvdGVjdGluZyB0cmFmZmljIGJldHdlZW4NCiAg ICBTSVAgZW5kcG9pbnRzIGFuZCB0aGUgQVMuIg0KDQogICAgLi4uDQogDQogICAgU2VjdGlvbiAy LjINCiAgICAgICAgDQogICAgPj4+ICAgICAgIGF1dGhvcml6YXRpb24gY3JlZGVudGlhbHMgYWNj ZXB0YWJsZSB0byBpdCwgaXQgU0hPVUxEIGNoYWxsZW5nZSB0aGUNCiAgICA+Pj4gICAgICAgcmVx dWVzdCBieSBzZW5kaW5nIGEgNDAxIChVbmF1dGhvcml6ZWQpIHJlc3BvbnNlLiAgVG8gaW5kaWNh dGUgdGhhdA0KICAgID4+PiAgICAgICBpdCBpcyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBhY2Nlc3Mg dG9rZW4gYXMgYSBjcmVkZW50aWFsLCB0aGUgVUFTLw0KICAgID4+PiAgICAgICBSZWdpc3RyYXIg TVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGljYXRpb24gaGVhZGVyIGZpZWxkIGluIHRoZQ0K ICAgID4+PiAgICAgICByZXNwb25zZSB0aGF0IGluZGljYXRlcyAiQmVhcmVyIiBzY2hlbWUgYW5k IGluY2x1ZGVzIGFuIGFkZHJlc3Mgb2YgYW4NCiAgICA+Pj4gICAgDQogICAgPj4+ICAgIG5pdCg/ KTogSSdkIGNvbnNpZGVyIGp1c3QgbWFraW5nIHRoaXMgYSBkZWNsYXJhdGl2ZSBzdGF0ZW1lbnQs IGEgbGEgInRoZQ0KICAgID4+PiAgICBVQVMvcmVnaXN0cmFyIGluY2x1ZGVzIGEgUHJveHktQXV0 aGVudGljYXRpb24gaGVhZGVyIGZpZWxkIHdpdGggdGhlICJCZWFyZXIiDQogICAgPj4+ICAgIHNj aGVtZSB0byBpbmRpY2F0ZSB0aGF0IGl0IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIGFjY2VzcyB0 b2tlbiBhcyBhDQogICAgPj4+ICAgIGNyZWRlbnRpYWwiICAoYnV0IHRoYXQgd29yZGluZyBpcyBp bmNvbXBsZXRlIGFuZCB3b3VsZCBuZWVkIHRvIGJlIGZsZXNoZWQNCiAgICA+Pj4gICAgb3V0IGEg Yml0IG1vcmUpLg0KICAgID4+IA0KICAgID4+IEkgdGhpbmsgdGhhdCB3b3VsZCBiZSB3ZWlyZC4g QmVjYXVzZSwgZmlyc3Qgd2Ugc2F5IHRoYXQgdGhlIFVBUy9SZWdpc3RyYXIgU0hPVUxEIGNoYWxs ZW5nZSwgYW5kIHdpdGggeW91cg0KICAgID4+IHN1Z2dlc3Rpb24gdGhlIHRleHQgd291bGQgc2F5 IHRoYXQgdGhlIFVBUy9SZWdpc3RyYXIgTVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGljYXRp b24gaGVhZGVyIGZpZWxkIGV2ZW4NCiAgICA+PiBpZiBpdCBkb2VzIE5PVCBjaGFsbGVuZ2UgdGhl IHJlcXVlc3QuDQogICAgPj4gDQogICAgPj4gUGVyaGFwczoNCiAgICA+PiANCiAgICA+PiAiSWYg dGhlIFVBUy9SZWdpc3RyYXIgY2hvb3NlcyB0byBjaGFsbGVuZ2UgdGhlIHJlcXVlc3QsIGFuZCBp cyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBhY2Nlc3MgdG9rZW4gYXMgYSBjcmVkZW50aWFsLCB0aGUg VUFTL1JlZ2lzdHJhciBNVVNUIGluY2x1ZGUgYS4uLiINCiAgICA+DQogICAgPiBUaGlzIHZlcnNp b24gZG9lcyBnZXQgcmlkIG9mIHRoZSBjb25mdXNpb24gYWJvdXQgd2hldGhlciB0aGUgTVVTVCBp cw0KICAgID4gY29uZGl0aW9uYWwgdGhhdCBJIHdhbnRlZCB0byBhZGRyZXNzLCB0aGFua3MuICAo SSBzZWUgSSBkaWRuJ3QgYWN0dWFsbHkgc2F5DQogICAgPiB3aHkgSSBwcm9wb3NlZCB0aGUgY2hh bmdlIEkgZGlkLCB3aG9vcHMuKQ0KDQogICAuLi4NCg0KICAgID4+PiAgICAgICBbUkZDNzUxOV0u ICBJZiB0aGUgdG9rZW4gcHJvdmlkZWQgaXMgYW4gZXhwaXJlZCBhY2Nlc3MgdG9rZW4sIHRoZW4N CiAgICA+Pj4gICAgICAgdGhlIFVBUyBNVVNUIHJlcGx5IHdpdGggNDAxIFVuYXV0aG9yaXplZCwg YXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMgb2YNCiAgICA+Pj4gICAgICAgW1JGQzY3NTBdLiAgSWYg dGhlIHZhbGlkYXRpb24gaXMgc3VjY2Vzc2Z1bCwgdGhlIFVBUy9SZWdpc3RyYXIgY2FuDQogICAg Pj4+ICAgICAgIGNvbnRpbnVlIHRvIHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNpbmcgbm9ybWFsIFNJ UCBwcm9jZWR1cmVzLiAgSWYgdGhlDQogICAgPj4+ICAgICAgIHZhbGlkYXRpb24gZmFpbHMsIHRo ZSBVQVMvUmVnaXN0cmFyIE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0Lg0KICAgID4+PiAgICANCiAg ICA+Pj4gICAgSXMgImV4cGlyZWQiIHRoZSBvbmx5IGNhc2UgdGhhdCBzaG91bGQgZ2V0IGEgNDAx IHZzLiBvdXRyaWdodCByZWplY3Rpb24sIGFzDQogICAgPj4+ICAgIHN0YXRlZCBoZXJlPw0KICAg ID4+IA0KICAgID4+IDQwMSBpcyBzZW50IGFsc28gaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIHZhbGlk YXRpb24gZmFpbHMuIEkgd2lsbCBjbGFyaWZ5IHRoYXQuDQogICAgDQogICAuLi4NCg0KICAgIFNl Y3Rpb24gMi4zDQogICAgICAgIA0KICAgID4+PiAgICAgICBzZW5kaW5nIGEgNDA3IChQcm94eSBB dXRoZW50aWNhdGlvbiBSZXF1aXJlZCkgcmVzcG9uc2UuICBUbyBpbmRpY2F0ZQ0KICAgID4+PiAg ICAgICB0aGF0IGl0IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIGFjY2VzcyB0b2tlbiBhcyBhIGNy ZWRlbnRpYWwsIHRoZQ0KICAgID4+PiAgICAgICBwcm94eSBNVVNUIGluY2x1ZGUgYSBQcm94eS1B dXRoZW50aWNhdGlvbiBoZWFkZXIgZmllbGQgaW4gdGhlDQogICAgPj4+ICAgICAgIHJlc3BvbnNl IHRoYXQgaW5kaWNhdGVzICJCZWFyZXIiIHNjaGVtZSBhbmQgaW5jbHVkZXMgYW4gYWRkcmVzcyB0 byBhbg0KICAgID4+PiAgICANCiAgICA+Pj4gICAgW3NhbWUgY29tbWVudCBhcyBhYm92ZSBhYm91 dCBub3JtYXRpdmUgdnMuIGRlY2xhcmF0aXZlIHN0YXRlbWVudF0NCiAgICA+Pj4gICAgQWxzbywg cGxlYXNlIGtlZXAgdGhlIHRleHQgcGFyYWxsZWwgYmV0d2VlbiBzZWN0aW9ucyAtLSB0aGlzIGNv cHkgaGFzIGF0DQogICAgPj4+ICAgIGxlYXN0IG9uZSBuaXQgKCJhZGRyZXNzIHRvIGFuIiB2cy4g ImFkZHJlc3Mgb2YgYW4iKS4NCiAgICA+PiAgIA0KICAgID4+IEkgd2lsbCBmaXggdGhpcyBpbiB0 aGUgc2FtZSB3YXkuDQogICAgICANCiAgIC0tLS0NCiAgICAgICANCiAgICBTZWN0aW9uIDUNCiAg ICAgICAgDQogICAgPj4+ICAgIFdlIHNob3VsZCBwcm9iYWJseSBub3RlIHRoYXQgU0lQIG1ha2Vz IG11Y2ggaGVhdmllciB1c2Ugb2YgcHJveGllcyB0aGFuIGlzDQogICAgPj4+ICAgIGNvbW1vbiBp biB0aGUgd2ViIHdvcmxkIG9mIE9BdXRoLg0KICAgID4+IA0KICAgID4+IE1heWJlIHNvbWV0aGlu ZyBsaWtlOg0KICAgID4+IA0KICAgID4+ICJIb3dldmVyLCBTSVAgbWFrZXMgaGF2ZSB1c2Ugb2Yg aW50ZXJtZWRpYXJ5IFNJUCBwcm94aWVzLCBhbmQgVExTIG9ubHkgZ3VhcmFudGVlcyBob3AtdG8t aG9wIHByb3RlY3Rpb24gd2hlbiB1c2VkIHRvDQogICAgPj4gICAgcHJvdGVjdCBTSVAgc2lnbmFs aW5nLiINCiAgICA+DQogICAgPiBTdXJlLCB0aGF0IHNob3VsZCB3b3JrLg0KDQogICAgLS0tDQoN CiAgICA+ID4gICAgU2VjdGlvbiA4DQogICAgPiA+ICAgIA0KICAgID4gPiAgICBJIHRoaW5rIFJG Q3MgODI1MiBhbmQgODQxNCBjb3VsZCBiZSBqdXN0IGluZm9ybWF0aXZlLg0KICAgID4gICANCiAg ICA+IEkgY2FuIGZpeCB0aGF0Lg0KICAgIA0KICAgIC0tLQ0KDQpUaGUgY2hhbmdlcyBkb25lIHNv IGZhciBiYXNlZCBvbiB5b3VyIElFU0cgcmV2aWV3IGNhbiBiZSBmb3VuZCBpbiB0aGUgZm9sbG93 aW5nIHB1bGwgcmVxdWVzdCBjb21taXQ6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9yaWZhYXQtaWV0 Zi9kcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei9wdWxsLzcvY29tbWl0cy8wZmM2 NTU3MTlkN2UzY2VmYzc0MTdiMzgyZTc2NjJjMWQ5YzEyZGJiDQoNCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KICAgIA0KDQo= From nobody Fri Apr 24 23:42:37 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB1A3A0B3C; Fri, 24 Apr 2020 23:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ONxfAidSiiYT; Fri, 24 Apr 2020 23:42:33 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 31E333A0B3A; Fri, 24 Apr 2020 23:42:32 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 35EAB2182; Sat, 25 Apr 2020 08:42:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: "Olle E. Johansson" In-Reply-To: <34A7E724-6E92-4C66-95B5-22F3A22F8CE3@ericsson.com> Date: Sat, 25 Apr 2020 08:42:27 +0200 Cc: Olle E Johansson , Benjamin Kaduk , Paul Kyzivat , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> <20200424201316.GX27494@kduck.mit.edu> <34A7E724-6E92-4C66-95B5-22F3A22F8CE3@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 06:42:36 -0000 > On 24 Apr 2020, at 23:51, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>> RFC 3261 seems to be written in a world that assumed that Basic = and Digest >>>>>> are the only defined HTTP authentication schemes, and since it = prohibits >>>>>> Basic, that there would only be one authentication challenge = (type) >>>>>> possible. This text righly acknowledges that we are opening the = field up >>>>>> and could have cases where multiple authentication schemes are = possible; >>>>>> however, it goes even further and admits the possibility of using = them >>>>>> simultaneously. It seems like this places an onus on us to give = some >>>>>> indication of the semantics when multiple schemes are used at the = same time. >>>>>> Do the authenticated identities need to match? Or are we = asserting that >>>>>> both/all identities are consenting to the request in question? = (If we don't >>>>>> have a concrete use case in mind, perhaps the "or more" is just = opening a >>>>>> box that we don't need to open right now.) >>>>>=20 >>>>> I pushed quite a bit on this area during the development of this = draft. As you note we are definitely expanding into an area that wasn't = anticipated in RFC3261. >>>>> The whole topic of how authentication works in the presence of = multiple schemes and realms could use some elaboration. The authors of = this draft were >>>>> reluctant to get into those weeds. It isn't clear what the right = mechanism is to do that. >>>>>=20 >>>>> I had a (non-sip) use case in mind: a site I visit allows you = register directly with the site, resulting in an ability to use Digest = credentials. The login page on the >>>>> site offers that as an option, along with the alternatives of = Facebook, Google, and maybe some others. I can see something just like = that for SIP. Presumably it >>>>> would be achieved by challenging with Digest and also with Bearer = for Facebook, Google, etc. The UAC then "chooses" by delegating the = choice to the user through the UI. >>>>>=20 >>>>> This is also the case where the "whitelist" really resides within = the end user's head rather than in the UAC. >>>>>=20 >>>>> It gets harder for devices that might be connecting when there is = no end user present. This can happen with a "phone" that attempts to be = permanently registered >>>>> to its sip server so that in can receive incoming calls. If it = reboots in the middle of the night there is no user handy to interact in = the authentication process. It all >>>>> has to take place using credentials preconfigured (or cached) in = the UAC. >>>>=20 >>>> I think it=E2=80=99s critical - and I=E2=80=99ve also raised the = issue before like Paul - that we develop a BCP for the various = combinations we have - both two types of digest algorithms and now the = OAuth2/OpenID Connect. >>>> There are huge risks of mis-configured platforms allowing for = downgrade attacks, so even if you=E2=80=99ve added stronger = authentication, someone will misuse your system because MD5 was still = open with simple passwords for some very old SIP phones. >>>=20 >>> I agree that such BCP (or whatever form it would take) would be = useful. As I said before, I think it should be done as a separate task. >>=20 >> How much do you think would be SIP-specific in such a document, vs. = being >> applicable to both SIP and HTTP? >=20 > I don't know - perhaps there would be nothing SIP-specific.=20 Food for thought. As mentioned earlier SIP has more proxys, ingress = proxys between the authenticating part and the client. Let=E2=80=99s start and see where it goes. >=20 >>> Therefore, in the authnz draft the suggestion is to say that the = processing is based on "local policy". >>=20 >> I'm happy to leave the choice of which one to use as up to local = policy, >> but would object to giving local policy the ability to use multiple >> mechanisms in combination without defining the semantics of such >> combinations. Based on personal experience, referring to local policy results in =E2=80=9C= do whatever you want=E2=80=9D which in all likelyhood means opening for problems. We need guidelines here. >>=20 >>> If people want, we can add a note saying that a future specification = may provide more detailed procedures and guidance regarding processing = multiple schemes. >>=20 >> That seems reasonable, if consistent with the above. >=20 > I suggest the following: >=20 > OLD: >=20 > If the UAC receives a 401/407 response with multiple WWW- > Authenticate/Proxy-Authenticate header fields, providing challenges > using different authentication schemes for the same realm, the UAC > provides credentials for one or more of the schemes that it = supports, > based on local polic > NEW: >=20 > If the UAC receives a 401/407 response with multiple WWW- > Authenticate/Proxy-Authenticate header fields, providing challenges > using different authentication schemes for the same realm, the UAC > provides credentials for one of the schemes that it supports, > based on local policy. >=20 > NOTE: At the time of writing this specification, detailed procedures = for the cases where a UAC receives multiple=20 > different authentication schemes had not been defined. A future = specification might define such procedures. >=20 Until we have a point where we know we can securely handle multiple = authentication schemes from the same UAS, I think we should recommend one policy per realm and/or domain. That will mean that until we have the BCP we determine method per device = - new devices gets the challenge that they support and we limit the possibilities of downgrade attacks. /O From nobody Sat Apr 25 05:58:16 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AA03A0D96; Sat, 25 Apr 2020 05:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb9IcJT-XHa4; Sat, 25 Apr 2020 05:58:03 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 585823A0BA9; Sat, 25 Apr 2020 05:58:03 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id u5so12000200ilb.5; Sat, 25 Apr 2020 05:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mkCLF7zVVmKzF4faSY/9cyLIQU8eZjYkOZThnHraRpo=; b=Z1Jt583BVdDxQ24SA5w5Ec+Qb5h9hLAfM7RoG8dRaQQBTesTzdBzA4ZudEKPTAp0w1 ietZfe+rhKt2VAQ6zD8Q0WE38rZsxmZZ+jY89x8yppcjTJJCS90Ktd/u915ig66IIN8E Xhmukbx6N1bcP5obzL67ng0m3YjjE3a0md3MY5ledvUNDdi19LKoBEtuIRvOo4sbiTOK Y2/tPSvG3mPiWxxsmvrIwqIX5Bs01iGrqVZceNvADdO7IENO5r8EXw8aHdYMLn4HLipL /PoH2CrJYRj5jwv6LIRXyIP3CdEhMTDcjXleKE8E6jSeHjE9Elzq79GvpVd1nnje9PHT KRsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mkCLF7zVVmKzF4faSY/9cyLIQU8eZjYkOZThnHraRpo=; b=UoFRnIZElQJj+jqZReTSevyOZ8gALL4sazwge69HLVVM/t88dCTqCCwygY+JJS1PKe Ds4rT6jhIzcrjfv8O3xFnRQvAudI8Vs8OhF82ZhpnCnXSmrYfp78VlY8Tg2v7AxnZMY1 iJmQOaE+ZvXri9SPQmHaxHauhBgf3M8t81sGvQmHUqo2igbFSVC1X4g3xkaAxcntr77f alo0reGIoedDnRanQ2MfPGZWUBvhZyfW/Xusdbbvcpgm/RV2sJNW/szyRC6p21jAgNfF pk49lLqkejIlxk+869lxG67H6LYiPzySHM00hNcWPJ2DKR1Ahgiq/OTfSiyCLhA9RbTn G0lg== X-Gm-Message-State: AGi0Puaka+vE1OatRkoeJiZeAbSthAfxOMfIbWrVMwyY4STlhhtoPURK PpjafMPadg2Xk36xaql0i2XvfNSIxG3LMiSNreI= X-Google-Smtp-Source: APiQypLnuiNDzZUUiLHYPxWtJe8647g7DEamOlTHL6TbVTsWdSeKAS+beniQKvIftFZTgbFFsp82wrsha5uOw93AaVo= X-Received: by 2002:a05:6e02:cc4:: with SMTP id c4mr12766110ilj.31.1587819482674; Sat, 25 Apr 2020 05:58:02 -0700 (PDT) MIME-Version: 1.0 References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> In-Reply-To: <158766991009.32224.6031347936963900326@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Sat, 25 Apr 2020 08:57:51 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="0000000000003b7b7705a41d08f8" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 12:58:06 -0000 --0000000000003b7b7705a41d08f8 Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks for the detailed and comprehensive review. I will try to address the DISCUSS in this email with my inline comments below. Regards, Rifaat On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sipcore-sip-token-authnz-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I support Roman's Discuss. > > > The "Bearer" authentication challenge includes the address (or name?) of an > authorization server to contact to obtain tokens, as mentioned in multiple > places in the document (noted in the COMMENT section). Our experience in > the OAuth world has shown that several classes of vulnerabilities are > possible when the client blindly attempt to use any provided AS, and that a > whitelist of "allowed" or "trusted" ASes is needed for secure operation. I > believe that the same is true for the SIP usage, and we should mention this > requirement explicitly. > > Yeah, good point. I will add some text to address that. > Section 1.2 tries to apply the OAuth confidential/public client distinction > to SIP UACs, but it does so in a non-analogous fashion: the OAuth > distinction is for the client's ability to protect credentials that > identify > the client itself; the usage in this document refers to protecting *user* > credentials and obtained tokens. I don't think that it's appropriate to > invoke the OAuth terminology when using it for a different meaning. > Both Public and Confidential OAuth clients are capable of providing the > necessary protections for *user* credentials (though they are of course not > guaranteed to do so), which leaves me unclear on what the intended > requirements actually are. > > Well, a browser-based client apps do not have client credentials at all, and they are considered public clients. I think the clarification needed here is to make it clear that we are talking about persistent storage of credentials. What I am trying to do with these two definitions is to differentiate between a browser-based UAC and non-browser based UAC. Because a browser-based UAC should be using a different flow, the authorization code grant flow, which is not covered by this document. Would adding such clarification address this comment? > > Section 2.3 states that: > > When a proxy wishes to authenticate a received request, it MUST > search the request for Proxy-Authorization header fields with 'realm' > parameters that match its realm. It then MUST successfully validate > > https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not > expected to have a sequence or list of Proxy-Authorization header fields > present in a single request that are intended to be interpreted by > different > proxies. Is this text compatible with that part of RFC 7235? Furthermore, > I didn't find much guidance in 7235 or 3261 about when to include the > "realm" parameter in Proxy-Authorization; do we want to give any guidance > here? (That is to say, I almost didn't find where it was even defined as > possible to do so...) > > There is a separate thread already on this one. > > I'm also not sure if we're attempting to profile RFC 6749 and always > require > a refresh token to be issued, or just have some editorial tweaks to make to > avoid suggesting that we do have such a requirement (noted in the COMMENT). > > This part is out of scope for this document, as it is related to the interaction between the UAC and the AS. This document is not trying to deviate from the OAuth 2.0 recommendations; we will clarify this. --0000000000003b7b7705a41d08f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for the detai= led and comprehensive review.
I will try to address the DISCUSS i= n this email with my inline=C2=A0comments below.

R= egards,
=C2=A0Rifaat


On Thu, Apr 23, 2020 at 3:25 P= M Benjamin Kaduk via Datatracker <no= reply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot position for<= br> draft-ietf-sipcore-sip-token-authnz-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-sipcore-sip-token-authnz/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's Discuss.


The "Bearer" authentication challenge includes the address (or na= me?) of an
authorization server to contact to obtain tokens, as mentioned in multiple<= br> places in the document (noted in the COMMENT section).=C2=A0 Our experience= in
the OAuth world has shown that several classes of vulnerabilities are
possible when the client blindly attempt to use any provided AS, and that a=
whitelist of "allowed" or "trusted" ASes is needed for = secure operation.=C2=A0 I
believe that the same is true for the SIP usage, and we should mention this=
requirement explicitly.

=C2=A0Yeah, good point. I will add some text to addre= ss that.


Section 1.2 tries to apply the OAuth confidential/public client distinction=
to SIP UACs, but it does so in a non-analogous fashion: the OAuth
distinction is for the client's ability to protect credentials that ide= ntify
the client itself; the usage in this document refers to protecting *user* credentials and obtained tokens.=C2=A0 I don't think that it's appr= opriate to
invoke the OAuth terminology when using it for a different meaning.
Both Public and Confidential OAuth clients are capable of providing the
necessary protections for *user* credentials (though they are of course not=
guaranteed to do so), which leaves me unclear on what the intended
requirements actually are.

Well, a browser-based client ap= ps do not have client credentials at all, and they are considered public cl= ients.
I think the clarification needed here is to make it clear t= hat we are talking about persistent storage of credentials.
What I am tr= ying to do with these two definitions is to differentiate between a browser= -based UAC and non-browser based UAC.
Because a browser-based UAC should= be using a different flow, the authorization code grant flow, which is not= covered by this document.
Would adding such clarification address this = comment?
=C2=A0

Section 2.3 states that:

=C2=A0 =C2=A0When a proxy wishes to authenticate a received request, it MUS= T
=C2=A0 =C2=A0search the request for Proxy-Authorization header fields with = 'realm'
=C2=A0 =C2=A0parameters that match its realm.=C2=A0 It then MUST successful= ly validate

https://tools.ietf.org/html/rfc7235#section-4.4 s= uggests that it is not
expected to have a sequence or list of Proxy-Authorization header fields present in a single request that are intended to be interpreted by differen= t
proxies.=C2=A0 Is this text compatible with that part of RFC 7235?=C2=A0 Fu= rthermore,
I didn't find much guidance in 7235 or 3261 about when to include the "realm" parameter in Proxy-Authorization; do we want to give any = guidance
here?=C2=A0 (That is to say, I almost didn't find where it was even def= ined as
possible to do so...)

There is a separate thread already on this one.
=
=C2=A0

I'm also not sure if we're attempting to profile RFC 6749 and alway= s require
a refresh token to be issued, or just have some editorial tweaks to make to=
avoid suggesting that we do have such a requirement (noted in the COMMENT).=

This part is out of scope for this document, as it is= related to the interaction between the UAC and the AS.
This document = is not trying to deviate from the OAuth 2.0 recommendations; we will clarif= y this.


--0000000000003b7b7705a41d08f8-- From nobody Sat Apr 25 08:11:12 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426C73A112F; Sat, 25 Apr 2020 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wDJQwMrPBVI; Sat, 25 Apr 2020 08:11:02 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 D3F1D3A112E; Sat, 25 Apr 2020 08:11:01 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id u11so13894380iow.4; Sat, 25 Apr 2020 08:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bGjbBQb1SvDlpQP3WzzWjefC1QHZImmMbYhija/m4ng=; b=mYo6G70+FOch4pFPRsh3Hu3fA5bY9HcO/JzmevdU87vtXzyEWIgglr1eiP6vo3wVq1 aj4NCiU1iSiMBp+2nHBcaTjV4OGVUVUwkikrRhm+xDqauUGCsFOa1uyXemGmDfAfVSYY EuMeu/5n0OdDycd7hgEH8N9VpCMSfrh65hFHUPbDXimHYpuY77g6H5eRRByZbp16Z0I0 RtqpM4asDnnetU+W7bXkhFpWD4jfiUA8W8Q6QaJmDvM1jfLSC+Il3YVGw769AAQRIG// cM7A0ZyMwMCeqIP8TTKV5A8z5/xHf6d0WZg/+iFmts4a5pi0SU7fhSbnaIcdrcdMEmhe hFDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bGjbBQb1SvDlpQP3WzzWjefC1QHZImmMbYhija/m4ng=; b=enR/dHcp47ryhSwyjjlfEfntg7R8NNt870SAGf0zJAsxeJay/z9IqR0m3/R+Gged9G ZyllAlOqFLA8uiA/mNY1BCqNygjbpmaTnZSuC17TP/BqIuCHRQQfbA0pAFvvDUmZqKQp sNSIIdQ0QGBgLTn8vL/0xr9xZyM34Yu/5cpjMq60sxGiM8NTlE8/KLgRYTAo15Xdb6vZ QkSMfLKF8CMUPYKnXER/x2BYKSevuIRPUCzCJ64D1SZVg0qr4VpOam/yRLgMCcd8qpnI 8FlFfb1SLtKPCpWozE+eCBwg9juAi4AIdJSaihhuSxPSviLUAuUOsZJ6/rZBV9BVhXxD Am+A== X-Gm-Message-State: AGi0PubIZ1OCwJr20fQJJvmR37i0/kpHpDws/64sD/OZygXlCzvj/FeF xAY6V+wigFy60dTssu8DgyogsRRsi9VIZkuw4Yk= X-Google-Smtp-Source: APiQypK88yVxCYj6tUQi3+15Zoau+GlKwYtQ4BJ3vD5ZmCkenET/0zF8cNrtiwDdYT0BweUxgripGXg//Gg6a1j+TJk= X-Received: by 2002:a02:5249:: with SMTP id d70mr13357550jab.121.1587827461074; Sat, 25 Apr 2020 08:11:01 -0700 (PDT) MIME-Version: 1.0 References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> In-Reply-To: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> From: Rifaat Shekh-Yusef Date: Sat, 25 Apr 2020 11:10:50 -0400 Message-ID: To: Christer Holmberg Cc: Benjamin Kaduk , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: multipart/alternative; boundary="000000000000c830e005a41ee316" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 15:11:06 -0000 --000000000000c830e005a41ee316 Content-Type: text/plain; charset="UTF-8" Inline... On Thu, Apr 23, 2020 at 5:04 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Benjamin, > > Thank You for the review! In this reply I will address some of your > COMMENT issues, and indicate the ones that I want Rifaat to address. Your > DISCUSS will be addressed in a separate realy. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 1 > > > > The OpenID Connect 1.0 specification [OPENID] defines a simple > > identity layer on top of the OAuth 2.0 protocol, which enables > > clients to verify the identity of the user based on the > > > > Please make it clear that these are OAuth/OIDC clients, not SIP > clients. > > I'll leave this for Rifaat. > > Sure. > --- > > > Section 1.3 > > > > OAuth 2.0 doesn't require the issuance of a Refresh token, but the > > discussion here implies that for the SIP case there will always be a > refresh > > token. If we're profiling 6749 in this manner, we should be more > explicit > > about the requirement to issue refresh tokens. > > I am not sure whether the intention is to say that there will always be a > refresh token. But, I'll leave this for Rifaat. > I answered in this the reply to the DISCUSS > > > * ID Token: this token contains the SIP URI and other > user-specific > > details that will be consumed by the UAC. > > > > nit: I don't think we should use the definite article in "the SIP > URI" since > > we haven't discussed any such SIP URI usage yet. That is, we should > say > > what it's used for, e.g., "a SIP URI associated with the user". > > I'll leave this for Rifaat. > > Sure. > > * Structured Token: a token that consists of a structured object > > that contains the claims associated with the token, e.g. JWT as > > defined in [RFC7519]. > > > > nit: comma after "e.g.". > > Will be fixed. > > > * Reference Token: a token that consists of a random string that > is > > used to obtain the details of the token and its associated > claims, > > as defined in [RFC6749]. > > > > It doesn't technically have to be random (though in practice it should > > contain signficant random elements); "opaque" might be better wording. > > I'll leave this for Rifaat. > > How about "opaque random string"? > > Section 1.4.1 > > > > Perhaps Figure 1 could include some indication that steps 5 and 6 are > > optional/do not always occur (in the case when the access token is a > > self-contained JWT)? > > I'll leave this for Rifaat. > > This is explicitly mentioned in the text, but I agree that it would be helpful to include it in the figure. > > In step [2], the registrar challenges the UA, by sending a SIP 401 > > (Unauthorized) response to the REGISTER request. In the response, > > the registrar includes information about the AS to contact in order > > to obtain a token. > > > > The UAC needs to have a preconfigured whitelist of acceptable ASes in > order > > to avoid directing the user's credentials to malicious sites. > > This is related to your DISCUSS, so it will be addressed as part of that. > > > The registrar validates the access token. If the access token is a > > reference token, the registrar MAY perform an introspection > > [RFC7662], as in steps [5] and [6], in order to obtain more > > information about the access token and its scope, per [RFC7662]. > > > > I think we could tighten up the normative language a bit here. > > In particular, the registrar MUST validate the token in some fashion; > for > > reference tokens, the main ways to do that are either inspection or > > (essentially) being the party that issued the token in the first > place. > > > > Otherwise, after the registrar validates the token to make sure it > > was signed by a trusted entity, it inspects its claims and acts > upon > > it. > > > > I think we can also be more specific than "a trusted entity" -- in > this > > flow, it looks like the registrar should know exactly which entity > should > > have signed the token in question (for the user in question), and > should not > > accept a signed token from a different entity that happens to be > trusted to > > issue other tokens. > > The text in Section 2.2. mandates the validation: > > "When a UAS/Registrar receives a SIP request that contains an > Authorization header field with an access token, the UAS/Registrar > MUST validate the access token,..." > > I don't think we should put too much normative text into the example flows. > > > Section 1.4.2 > > > > (Similarly, Figure 2 could note that steps 3 and 4 do not always > occur, and > > the text about token validation should remain parallel between > examples.) > > I'll leave this for Rifaat. > > Again, this is explicitly mentioned in the text, but I agree that it would be helpful to include it in the figure. > ---- > > > Section 2 > > > > I note that RFC 3261 explicitly disclaims any definition of > authorization > > systems, which is not true for this document, given that OAuth is an > > authorization system :) > > RFC 3261 only says that the RFC does not recommend or discuss any > authorization system. > > > Section 2.1.1 > > > > Required) response with a Proxy-Authenticate header field. If the > > WWW-Authenticate or Proxy-Authenticate header field indicates > > "Bearer" scheme authentication and contains an address to an > > authorization server, the UAC contacts the authorization server in > > order to obtain tokens, and includes the requested scopes, based > on a > > local configuration (Figure 1). > > > > [whitelist of allowed ASes, again] > > Will be addressed when the DISCUSS is addressed. > > > The detailed OAuth2 procedure to authenticate the user and obtain > > these tokens is out of scope of this document. The address of the > > authorization server might already be known to the UAC via > > configuration. In which case, the UAC can contact the > authorization > > server for tokens before it sends a SIP request (Figure 2). > > > > nit: I think that "in which case" functions as a conjunction, which > makes > > this an incomplete sentence. > > The text was suggested by one of the reviewers, but I agree it sounds > incomplete. > > Perhaps "In such cases"? > > > The tokens returned to the UAC depend on the type of authorization > > server (AS): an OAuth AS provides an access token and refresh token > > [RFC6749]. The UAC provides the access token to the SIP servers to > > > > Again, this implies that refresh tokens are always issued; RFC 6749 > is quite > > clear that "issuing a refresh token is optional at the discretion of > the > > authorization server". > > I'll leave this for Rifaat. > > As I mentioned in the reply to the DISCUSS, we will clarify this. > > authorize UAC's access to the service. The UAC uses the refresh > > token only with the AS to get a new access token and refresh token > > before the expiry of the current access token (see [RFC6749], > section > > > > (New refresh token is also optional.) > > I'll leave this for Rifaat. > > As I mentioned in the reply to the DISCUSS, we will clarify this. > > 1.5 Refresh Token for details). An OpenID Connect server returns > an > > additional ID-Token containing the SIP URI and other user-specific > > details that will be consumed by the UAC. > > > > [same comment as above about "the SIP URI".] > > I'll leave this for Rifaat. > > Ok > > If the UAC receives a 401/407 response with multiple WWW- > > Authenticate/Proxy-Authenticate header fields, providing challenges > > using different authentication schemes for the same realm, the UAC > > selects one or more of the provided schemes (based on local policy) > > and provides credentials for those schemes. > > > > RFC 3261 seems to be written in a world that assumed that Basic and > Digest > > are the only defined HTTP authentication schemes, and since it > prohibits > > Basic, that there would only be one authentication challenge (type) > > possible. This text righly acknowledges that we are opening the > field up > > and could have cases where multiple authentication schemes are > possible; > > however, it goes even further and admits the possibility of using them > > simultaneously. It seems like this places an onus on us to give some > > indication of the semantics when multiple schemes are used at the > same time. > > Do the authenticated identities need to match? Or are we asserting > that > > both/all identities are consenting to the request in question? (If > we don't > > have a concrete use case in mind, perhaps the "or more" is just > opening a > > box that we don't need to open right now.) > > I can modify as suggested. > > (Personally, I have never seen multiple schemes in a deployment.) > > > Section 2.1.2 > > > > access to it. Endpoints that support this specification MUST > support > > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and > protecting > > access tokens when they are included in SIP requests, unless some > > other mechanism is used to guarantee that only authorized SIP > > endpoints have access to the access token. > > > > I think we may want "MUST support" (always) and "MUST use, unless > some other > > mechanism". > > Based on another review, I suggested to change to "MUST use". I am not > sure whether we need to keep "MUST support". > > > I'd also suggest a quick note that TLS remains fine for protecting the > > UAC/AS interaction where the refresh token is used. > > I can do that. > > I could also say "*SIP* endpoints that support this specification...". > > > Whatever is done, please harmonize with Section 5 that has > essentially the > > same text. > > Will do. > > > Section 2.1.3 > > > > Based on local policy, the UAC MAY include an access token that has > > been used for another binding associated with the same Address Of > > Record (AOR) in the request. > > > > Just to check: there's no real privacy considerations with such use, > as its > > the same parties interacting and there are other identifiers (e.g., IP > > addresses) to confirm that it's the same client communicating to the > server? > > I'll leave this for Rifaat. > > I would not rely only on an IP address, but the answer is yes. > > Also, is it clear what will be done (new token request) when the MAY > is not > > heeded? > > I'll leave this for Rifaat. > > The Client would need to obtain a new access token. I will clarify this. > > Section 2.1.4 > > > > The text here just talks about "a valid access token" and similar, > without > > saying a whole lot about it being related in any way to the specifics > of the > > authentication challenge. Is there something useful to say about, > e.g., the > > token in question having been issued by the authorization server > indicated > > in the challenge? > > I'll leave this for Rifaat. > > Sure. > Section 2.2 > > > > authorization credentials acceptable to it, it SHOULD challenge the > > request by sending a 401 (Unauthorized) response. To indicate that > > it is willing to accept an access token as a credential, the UAS/ > > Registrar MUST include a Proxy-Authentication header field in the > > response that indicates "Bearer" scheme and includes an address of > an > > > > nit(?): I'd consider just making this a declarative statement, a la > "the > > UAS/registrar includes a Proxy-Authentication header field with the > "Bearer" > > scheme to indicate that it is willing to accept an access token as a > > credential" (but that wording is incomplete and would need to be > fleshed > > out a bit more). > > I think that would be weird. Because, first we say that the UAS/Registrar > SHOULD challenge, and with your suggestion the text would say that the > UAS/Registrar MUST include a Proxy-Authentication header field even if it > does NOT challenge the request. > > Perhaps: > > "If the UAS/Registrar chooses to challenge the request, and is willing to > accept an access token as a credential, the UAS/Registrar MUST include a..." > > > authorization server from which the originator can obtain an access > > token. > > > > nit: "address of" an AS, does that mean bare IP address only or is a > DNS > > name okay? > > I'll leave this for Rifaat. > > I do not think that an IP address is appropriate, and what I have in mind is a DNS name. I will clarify it. > [RFC7519]. If the token provided is an expired access token, then > > the UAS MUST reply with 401 Unauthorized, as defined in section 3 > of > > [RFC6750]. If the validation is successful, the UAS/Registrar can > > continue to process the request using normal SIP procedures. If > the > > validation fails, the UAS/Registrar MUST reject the request. > > > > Is "expired" the only case that should get a 401 vs. outright > rejection, as > > stated here? > > 401 is sent also in the case where the validation fails. I will clarify > that. > > > Section 2.3 > > > > sending a 407 (Proxy Authentication Required) response. To > indicate > > that it is willing to accept an access token as a credential, the > > proxy MUST include a Proxy-Authentication header field in the > > response that indicates "Bearer" scheme and includes an address to > an > > > > [same comment as above about normative vs. declarative statement] > > Also, please keep the text parallel between sections -- this copy has > at > > least one nit ("address to an" vs. "address of an"). > > I will fix this in the same way. > > > Section 3 > > > > If an access token is encoded as a JWT, it might contain a list of > > claims [RFC7519], some registered and some application-specific. > The > > > > I don't think there's a question of whether a JWT will contain a list > of > > claims :) > > Fair enough :) > > > Maybe "If the access token is encoded as a JWT, it will contain a > list of > > claims [RFC7519], which may include both registered and > application-specific > > claims"? > > Looks good to me, but I'll leave this for Rifaat. > > Looks good to me too. Regards, Rifaat > ---- > > > Section 4 > > > > This section claims to cover WWW-Authenticate. What specification > will the > > SIP use of Bearer for Authorization operate under? > > RFC 6750. > > Section 2.1.3 says: > > "The UAC sends a REGISTER request with an Authorization header field > containing the response to the challenge, including the Bearer scheme > carrying a valid access token in the request, as specified in > [RFC6750]." > > > challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) > > > > side note: is there a mnemonic for the "cln" in "bearer-cln"? > > RFC 3261 uses "cln" for digest. > > > bearer-cln = realm / scope / authz-server / error / > > auth-param > > > > nit: realm is already included in auth-param, though I don't see a > harm in > > calling it out explicitly. > > auth-param is used to allow possible new parameters in the future. > > > realm = > > auth-param = > > > > RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of > these; we > > could perhaps short-circuit the chain and say "defined in RFC 7235". > > We discussed this in the WG, and the outcome was to keep the same > references as RFC 3261, since that is what people are implementing. > > Then, as a separate task, someone could update RFC 3261 with the new > references. > > --- > > > Section 5 > > > > We should probably note that SIP makes much heavier use of proxies > than is > > common in the web world of OAuth. > > Maybe something like: > > "However, SIP makes have use of intermediary SIP proxies, and TLS only > guarantees hop-to-hop protection when used to > protect SIP signaling." > > > I'm happy to see that some privacy considerations are being added in > > response to Barry's review. > > Good :) > > --- > > > Section 8 > > > > I think RFCs 8252 and 8414 could be just informative. > > I can fix that. > > --- > > Regards, > > Christer > > > > > > --000000000000c830e005a41ee316 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline...

On Thu, Apr 23, 2020 at 5:04= PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Benjamin,

Thank You for the review! In this reply I will address some of your COMMENT= issues, and indicate the ones that I want Rifaat to address. Your DISCUSS = will be addressed in a separate realy.

=C2=A0 =C2=A0 -------------------------------------------------------------= ---------
=C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 -------------------------------------------------------------= ---------

>=C2=A0 =C2=A0 Section 1
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The OpenID Connect 1.0 specification [OPENID= ] defines a simple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity layer on top of the OAuth 2.0 proto= col, which enables
>=C2=A0 =C2=A0 =C2=A0 =C2=A0clients to verify the identity of the user b= ased on the
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Please make it clear that these are OAuth/OIDC clients, n= ot SIP clients.

I'll leave this for Rifaat.

Sure.
=C2=A0
---

>=C2=A0 =C2=A0 Section 1.3
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 OAuth 2.0 doesn't require the issuance of a Refresh t= oken, but the
>=C2=A0 =C2=A0 discussion here implies that for the SIP case there will = always be a refresh
>=C2=A0 =C2=A0 token.=C2=A0 If we're profiling 6749 in this manner, = we should be more explicit
>=C2=A0 =C2=A0 about the requirement to issue refresh tokens.

I am not sure whether the intention is to say that there will always be a r= efresh token. But, I'll leave this for Rifaat.
I answered in this the reply to the DISCUSS
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 ID Token: this token contains the SI= P URI and other user-specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 details that will be consumed by the= UAC.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 nit: I don't think we should use the definite article= in "the SIP URI" since
>=C2=A0 =C2=A0 we haven't discussed any such SIP URI usage yet.=C2= =A0 That is, we should say
>=C2=A0 =C2=A0 what it's used for, e.g., "a SIP URI associated = with the user".

I'll leave this for Rifaat.

Sure.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Structured Token: a token that consi= sts of a structured object
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that contains the claims associated = with the token, e.g.=C2=A0 JWT as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defined in [RFC7519].
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 nit: comma after "e.g.".

Will be fixed.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Reference Token: a token that consis= ts of a random string that is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used to obtain the details of the to= ken and its associated claims,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as defined in [RFC6749].
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 It doesn't technically have to be random (though in p= ractice it should
>=C2=A0 =C2=A0 contain signficant random elements); "opaque" m= ight be better wording.

I'll leave this for Rifaat.

How about "opaque random string"?

=C2=A0
>=C2=A0 =C2=A0 Section 1.4.1
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Perhaps Figure 1 could include some indication that steps= 5 and 6 are
>=C2=A0 =C2=A0 optional/do not always occur (in the case when the access= token is a
>=C2=A0 =C2=A0 self-contained JWT)?

I'll leave this for Rifaat.

This is explicitly mentioned in the text, but I agree= that it would be helpful to include it in the figure.

=
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In step [2], the registrar challenges the UA= , by sending a SIP 401
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Unauthorized) response to the REGISTER requ= est.=C2=A0 In the response,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the registrar includes information about the= AS to contact in order
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to obtain a token.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 The UAC needs to have a preconfigured whitelist of accept= able ASes in order
>=C2=A0 =C2=A0 to avoid directing the user's credentials to maliciou= s sites.

This is related to your DISCUSS, so it will be addressed as part of that.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The registrar validates the access token.=C2= =A0 If the access token is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reference token, the registrar MAY perform a= n introspection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7662], as in steps [5] and [6], in order= to obtain more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0information about the access token and its s= cope, per [RFC7662].
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I think we could tighten up the normative language a bit = here.
>=C2=A0 =C2=A0 In particular, the registrar MUST validate the token in s= ome fashion; for
>=C2=A0 =C2=A0 reference tokens, the main ways to do that are either ins= pection or
>=C2=A0 =C2=A0 (essentially) being the party that issued the token in th= e first place.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, after the registrar validates the= token to make sure it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0was signed by a trusted entity, it inspects = its claims and acts upon
>=C2=A0 =C2=A0 =C2=A0 =C2=A0it.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I think we can also be more specific than "a trusted= entity" -- in this
>=C2=A0 =C2=A0 flow, it looks like the registrar should know exactly whi= ch entity should
>=C2=A0 =C2=A0 have signed the token in question (for the user in questi= on), and should not
>=C2=A0 =C2=A0 accept a signed token from a different entity that happen= s to be trusted to
>=C2=A0 =C2=A0 issue other tokens.

The text in Section 2.2. mandates the validation:

=C2=A0 =C2=A0"When a UAS/Registrar receives a SIP request that contain= s an
=C2=A0 =C2=A0Authorization header field with an access token, the UAS/Regis= trar
=C2=A0 =C2=A0MUST validate the access token,..."

I don't think we should put too much normative text into the example fl= ows.

>=C2=A0 =C2=A0 Section 1.4.2
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 (Similarly, Figure 2 could note that steps 3 and 4 do not= always occur, and
>=C2=A0 =C2=A0 the text about token validation should remain parallel be= tween examples.)

I'll leave this for Rifaat.

Again, this is explicitly mentioned in the text, but = I agree that it would be helpful to include it in the figure.=C2=A0
=C2=A0=C2=A0
----

>=C2=A0 =C2=A0 Section 2
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I note that RFC 3261 explicitly disclaims any definition = of authorization
>=C2=A0 =C2=A0 systems, which is not true for this document, given that = OAuth is an
>=C2=A0 =C2=A0 authorization system :)

RFC 3261 only says that the RFC does not recommend or discuss any authoriza= tion system.

>=C2=A0 =C2=A0 Section 2.1.1
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Required) response with a Proxy-Authenticate= header field.=C2=A0 If the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0WWW-Authenticate or Proxy-Authenticate heade= r field indicates
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bearer" scheme authentication and= contains an address to an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization server, the UAC contacts the a= uthorization server in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0order to obtain tokens, and includes the req= uested scopes, based on a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0local configuration (Figure 1).
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 [whitelist of allowed ASes, again]

Will be addressed when the DISCUSS is addressed.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0The detailed OAuth2 procedure to authenticat= e the user and obtain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0these tokens is out of scope of this documen= t.=C2=A0 The address of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization server might already be known = to the UAC via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration.=C2=A0 In which case, the UAC = can contact the authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0server for tokens before it sends a SIP requ= est (Figure 2).
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 nit: I think that "in which case" functions as = a conjunction, which makes
>=C2=A0 =C2=A0 this an incomplete sentence.

The text was suggested by one of the reviewers, but I agree it sounds incom= plete.

Perhaps "In such cases"?

>=C2=A0 =C2=A0 =C2=A0 =C2=A0The tokens returned to the UAC depend on the= type of authorization
>=C2=A0 =C2=A0 =C2=A0 =C2=A0server (AS): an OAuth AS provides an access = token and refresh token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6749].=C2=A0 The UAC provides the access= token to the SIP servers to
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Again, this implies that refresh tokens are always issued= ; RFC 6749 is quite
>=C2=A0 =C2=A0 clear that "issuing a refresh token is optional at t= he discretion of the
>=C2=A0 =C2=A0 authorization server".

I'll leave this for Rifaat.

As I mentioned in the reply to the DISCUSS, we will c= larify this.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorize UAC's access to the service.= =C2=A0 The UAC uses the refresh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0token only with the AS to get a new access t= oken and refresh token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0before the expiry of the current access toke= n (see [RFC6749], section
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 (New refresh token is also optional.)

I'll leave this for Rifaat.

As I mentioned in the reply to the DISCUSS, we will clarify this.=C2=A0

=C2=A0=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A01.5 Refresh Token for details).=C2=A0 An Ope= nID Connect server returns an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional ID-Token containing the SIP URI a= nd other user-specific
>=C2=A0 =C2=A0 =C2=A0 =C2=A0details that will be consumed by the UAC. >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 [same comment as above about "the SIP URI".]
I'll leave this for Rifaat.

Ok
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If the UAC receives a 401/407 response with = multiple WWW-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Authenticate/Proxy-Authenticate header field= s, providing challenges
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using different authentication schemes for t= he same realm, the UAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0selects one or more of the provided schemes = (based on local policy)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and provides credentials for those schemes.<= br> >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 RFC 3261 seems to be written in a world that assumed that= Basic and Digest
>=C2=A0 =C2=A0 are the only defined HTTP authentication schemes, and sin= ce it prohibits
>=C2=A0 =C2=A0 Basic, that there would only be one authentication challe= nge (type)
>=C2=A0 =C2=A0 possible.=C2=A0 This text righly acknowledges that we are= opening the field up
>=C2=A0 =C2=A0 and could have cases where multiple authentication scheme= s are possible;
>=C2=A0 =C2=A0 however, it goes even further and admits the possibility = of using them
>=C2=A0 =C2=A0 simultaneously.=C2=A0 It seems like this places an onus o= n us to give some
>=C2=A0 =C2=A0 indication of the semantics when multiple schemes are use= d at the same time.
>=C2=A0 =C2=A0 Do the authenticated identities need to match?=C2=A0 Or a= re we asserting that
>=C2=A0 =C2=A0 both/all identities are consenting to the request in ques= tion?=C2=A0 (If we don't
>=C2=A0 =C2=A0 have a concrete use case in mind, perhaps the "or mo= re" is just opening a
>=C2=A0 =C2=A0 box that we don't need to open right now.)

I can modify as suggested.

(Personally, I have never seen multiple schemes in a deployment.)

>=C2=A0 =C2=A0 Section 2.1.2
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access to it.=C2=A0 Endpoints that support t= his specification MUST support
>=C2=A0 =C2=A0 =C2=A0 =C2=A0encrypted JSON Web Tokens (JWT) [RFC7519] fo= r encoding and protecting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access tokens when they are included in SIP = requests, unless some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0other mechanism is used to guarantee that on= ly authorized SIP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0endpoints have access to the access token. >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I think we may want "MUST support" (always) and= "MUST use, unless some other
>=C2=A0 =C2=A0 mechanism".

Based on another review, I suggested to change to "MUST use". I a= m not sure whether we need to keep "MUST support".

>=C2=A0 =C2=A0 I'd also suggest a quick note that TLS remains fine f= or protecting the
>=C2=A0 =C2=A0 UAC/AS interaction where the refresh token is used.

I can do that.

I could also say "*SIP* endpoints that support this specification...&q= uot;.

>=C2=A0 =C2=A0 Whatever is done, please harmonize with Section 5 that ha= s essentially the
>=C2=A0 =C2=A0 same text.

Will do.

>=C2=A0 =C2=A0 Section 2.1.3
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Based on local policy, the UAC MAY include a= n access token that has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0been used for another binding associated wit= h the same Address Of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Record (AOR) in the request.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Just to check: there's no real privacy considerations= with such use, as its
>=C2=A0 =C2=A0 the same parties interacting and there are other identifi= ers (e.g., IP
>=C2=A0 =C2=A0 addresses) to confirm that it's the same client commu= nicating to the server?

I'll leave this for Rifaat.

I would not rely only on an IP address, but the answe= r is yes.
=C2=A0
=C2=A0
>=C2=A0 =C2=A0 Also, is it clear what will be done (new token request) w= hen the MAY is not
>=C2=A0 =C2=A0 heeded?

I'll leave this for Rifaat.


The Client would need to obtain a new = access token. I will clarify this.

=C2=A0
>=C2=A0 =C2=A0 Section 2.1.4
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 The text here just talks about "a valid access token= " and similar, without
>=C2=A0 =C2=A0 saying a whole lot about it being related in any way to t= he specifics of the
>=C2=A0 =C2=A0 authentication challenge.=C2=A0 Is there something useful= to say about, e.g., the
>=C2=A0 =C2=A0 token in question having been issued by the authorization= server indicated
>=C2=A0 =C2=A0 in the challenge?

I'll leave this for Rifaat.

Sure.
=C2=A0

>=C2=A0 =C2=A0 Section 2.2
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization credentials acceptable to it, = it SHOULD challenge the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0request by sending a 401 (Unauthorized) resp= onse.=C2=A0 To indicate that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0it is willing to accept an access token as a= credential, the UAS/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Registrar MUST include a Proxy-Authenticatio= n header field in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0response that indicates "Bearer" s= cheme and includes an address of an
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 nit(?): I'd consider just making this a declarative s= tatement, a la "the
>=C2=A0 =C2=A0 UAS/registrar includes a Proxy-Authentication header fiel= d with the "Bearer"
>=C2=A0 =C2=A0 scheme to indicate that it is willing to accept an access= token as a
>=C2=A0 =C2=A0 credential"=C2=A0 (but that wording is incomplete an= d would need to be fleshed
>=C2=A0 =C2=A0 out a bit more).

I think that would be weird. Because, first we say that the UAS/Registrar S= HOULD challenge, and with your suggestion the text would say that the UAS/R= egistrar MUST include a Proxy-Authentication header field even if it does N= OT challenge the request.

Perhaps:

"If the UAS/Registrar chooses to challenge the request, and is willing= to accept an access token as a credential, the UAS/Registrar MUST include = a..."

>=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization server from which the originat= or can obtain an access
>=C2=A0 =C2=A0 =C2=A0 =C2=A0token.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 nit: "address of" an AS, does that mean bare IP= address only or is a DNS
>=C2=A0 =C2=A0 name okay?

I'll leave this for Rifaat.


I do not think that an IP address is a= ppropriate, and what I have in mind is a DNS name.
I will cla= rify it.


>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7519].=C2=A0 If the token provided is an= expired access token, then
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the UAS MUST reply with 401 Unauthorized, as= defined in section 3 of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6750].=C2=A0 If the validation is succes= sful, the UAS/Registrar can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0continue to process the request using normal= SIP procedures.=C2=A0 If the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0validation fails, the UAS/Registrar MUST rej= ect the request.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Is "expired" the only case that should get a 40= 1 vs. outright rejection, as
>=C2=A0 =C2=A0 stated here?

401 is sent also in the case where the validation fails. I will clarify tha= t.

>=C2=A0 =C2=A0 Section 2.3
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sending a 407 (Proxy Authentication Required= ) response.=C2=A0 To indicate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it is willing to accept an access token= as a credential, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0proxy MUST include a Proxy-Authentication he= ader field in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0response that indicates "Bearer" s= cheme and includes an address to an
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 [same comment as above about normative vs. declarative st= atement]
>=C2=A0 =C2=A0 Also, please keep the text parallel between sections -- t= his copy has at
>=C2=A0 =C2=A0 least one nit ("address to an" vs. "addres= s of an").

I will fix this in the same way.

>=C2=A0 =C2=A0 Section 3
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If an access token is encoded as a JWT, it m= ight contain a list of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0claims [RFC7519], some registered and some a= pplication-specific.=C2=A0 The
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I don't think there's a question of whether a JWT= will contain a list of
>=C2=A0 =C2=A0 claims :)

Fair enough :)

>=C2=A0 =C2=A0 Maybe "If the access token is encoded as a JWT, it w= ill contain a list of
>=C2=A0 =C2=A0 claims [RFC7519], which may include both registered and a= pplication-specific
>=C2=A0 =C2=A0 claims"?

Looks good to me, but I'll leave this for Rifaat.

Looks good to me too.

Regard= s,
=C2=A0Rifaat
=C2=A0
----

>=C2=A0 =C2=A0 Section 4
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 This section claims to cover WWW-Authenticate.=C2=A0 What= specification will the
>=C2=A0 =C2=A0 SIP use of Bearer for Authorization operate under?

RFC 6750.

Section 2.1.3 says:

=C2=A0 =C2=A0"The UAC sends a REGISTER request with an Authorization h= eader field
=C2=A0 =C2=A0containing the response to the challenge, including the Bearer= scheme
=C2=A0 =C2=A0carrying a valid access token in the request, as specified in<= br> =C2=A0 =C2=A0[RFC6750]."

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0challenge=C2=A0 =3D/=C2=A0 (&q= uot;Bearer" LWS bearer-cln *(COMMA bearer-cln))
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 side note: is there a mnemonic for the "cln" in= "bearer-cln"?

RFC 3261 uses "cln" for digest.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bearer-cln =3D realm / scope /= authz-server / error /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 auth-param
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 nit: realm is already included in auth-param, though I do= n't see a harm in
>=C2=A0 =C2=A0 calling it out explicitly.

auth-param is used to allow possible new parameters in the future.=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0realm =3D <defined in RFC32= 61>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auth-param =3D <defined in = RFC3261>
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for b= oth of these; we
>=C2=A0 =C2=A0 could perhaps short-circuit the chain and say "defin= ed in RFC 7235".

We discussed this in the WG, and the outcome was to keep the same reference= s as RFC 3261, since that is what people are implementing.

Then, as a separate task, someone could update RFC 3261 with the new refere= nces.

---

>=C2=A0 =C2=A0 Section 5
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 We should probably note that SIP makes much heavier use o= f proxies than is
>=C2=A0 =C2=A0 common in the web world of OAuth.

Maybe something like:

"However, SIP makes have use of intermediary SIP proxies, and TLS only= guarantees hop-to-hop protection when used to
=C2=A0 =C2=A0protect SIP signaling."

>=C2=A0 =C2=A0 I'm happy to see that some privacy considerations are= being added in
>=C2=A0 =C2=A0 response to Barry's review.

Good :)

---

>=C2=A0 =C2=A0 Section 8
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I think RFCs 8252 and 8414 could be just informative.

I can fix that.

---

Regards,

Christer





--000000000000c830e005a41ee316-- From nobody Sat Apr 25 11:43:15 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D071A3A12F7; Sat, 25 Apr 2020 11:43:13 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 XfbTiYrgriSe; Sat, 25 Apr 2020 11:43:12 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2058.outbound.protection.outlook.com [40.107.92.58]) (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 9B1233A12F6; Sat, 25 Apr 2020 11:43:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=liJZxWprXmZHw7/sBE96fYJtDvQIe2uwBDH7iy45JHvw9fFZX9WrgevS+NT4U6vpPGQEdHVGoJ/tvk3IwDoBRyOxj7mTXzwROjuZXS37AtdMYyoNpvkNr4Hr/EmuMSbOeJ61ENDg3ukRVE+5wQKc/RJH2bVZDOMRIDjh+QMHkd1J2Ik+eUgTC/HOmH6LwOGlonhxQ8Q0s3u2QVnmZCXEHXMdDOa9UZAjmo4jyDkrWJwSlvtz4IhtRq7gWRRN/HJNjbFEmMXWzlGV7VEvv9OocaCOMGF4DNARcbMurdps5yoQiJERmzpas+rNA2qmojuQ2N2m70rSZ2DMRJwDAT9x6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vIbEhKHDX4CEpCbbJA486RL2sv6ffwme2EmQ6hFf7/8=; b=F+xDgHSUlN0DBLXIj1RBh5gLH+HubCGS1JyJ61xE2Haibs2bje1p7QzDplkLb29U8iYPgSUYEM1NpceMVFqb+LHob8Y48IHPB15C6Yr1aT2GtNiiA3NBN+I/pskDIpAfUXNQVyKk7j1GXT/vdbSI+Du4koOyo0DJTCAdY415DhYgfBD0VU4Z71EtFilhlrE2S/aqr9PlRrQALozpMaNzYgozb1tCwLjK9Pgrtzi83THJSSeUs4x3Vd+sknukvIN33o5axJg7X9MY3avUx5gH5NlBfXZVF5R7LSQE5BTq4WtyEr22jkyfgPUWKCxNZmT9n6xr+NkND3rD/VJk+ERFEw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=edvina.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vIbEhKHDX4CEpCbbJA486RL2sv6ffwme2EmQ6hFf7/8=; b=ILwXFB8wzwNhetCo0A5bbiTSWEIIWqkIgNbTOzya3zZ6F7v3opnfKN70y451fQ/3j2cMRB+74J9pMFOXMfLUhzfYNwFugzqqtu1YIPzI0itedtwoJLPAQeY0q0jodL7rEzsX/zxbGob2OPthK1gfTmCkjKhh4G8nq8JUTkzdZPI= Received: from DM5PR18CA0056.namprd18.prod.outlook.com (2603:10b6:3:22::18) by DM5PR12MB1706.namprd12.prod.outlook.com (2603:10b6:3:10f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sat, 25 Apr 2020 18:43:09 +0000 Received: from CY1NAM02FT011.eop-nam02.prod.protection.outlook.com (2603:10b6:3:22:cafe::38) by DM5PR18CA0056.outlook.office365.com (2603:10b6:3:22::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sat, 25 Apr 2020 18:43:09 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT011.mail.protection.outlook.com (10.152.75.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sat, 25 Apr 2020 18:43:07 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 03PIh46W029266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 25 Apr 2020 14:43:05 -0400 To: "Olle E. Johansson" , Christer Holmberg Cc: Benjamin Kaduk , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> <20200424201316.GX27494@kduck.mit.edu> <34A7E724-6E92-4C66-95B5-22F3A22F8CE3@ericsson.com> From: Paul Kyzivat Message-ID: Date: Sat, 25 Apr 2020 14:43:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(396003)(39860400002)(346002)(136003)(376002)(46966005)(356005)(47076004)(478600001)(186003)(4326008)(82740400003)(2906002)(336012)(75432002)(86362001)(31696002)(31686004)(246002)(8676002)(8936002)(7596003)(110136005)(54906003)(70586007)(316002)(786003)(70206006)(36906005)(2616005)(956004)(5660300002)(82310400002)(53546011)(26005); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bb84e561-0605-4b18-c82b-08d7e9487f4d X-MS-TrafficTypeDiagnostic: DM5PR12MB1706: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 0384275935 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nagbpeRAc5U6ggUpw0eP0BXetdcuP2SwNLYuQh+hfFmt1cnJLFUJsypTJM/1K3XFmZ/glQcjV5IVx+x1EXkQmJjo/uwveJJmUchI4opM/WvhttJ0Ur1o6W6uMtR0dM6A8YZfeaq0ZM2hOm6v7qMsyLU9MZRjyML6/P8t8W2PyTMz5Qya1axo21a18hVKvd11XxawPsPCPvPA+GK/b1dj8sRGs+AH+ui6jtltwzZ1tXvewRxU/xV57dUEEjfIw4AO9PdwoSVMG/DlNtkrg7mUyPxI8O1oI4stcSpewOZrH7NCMPCojKSObTCqSzV/0ccKTqoeWD3waavbsanogOkQoi1baHWos6cBFEXR1Sg14Jdpa7sTpgwNbYisMOPchouiz0Umh2j0Epo6Whlq9EnzQ/P1EZ+5AP7RJTQCHHht2VKMJlBDpBNYnvv+oqG+bM7AS1tcUPzNYsdo3i6ykDYfgPRBhbbOsrsxGVyEKFmcAE0S/tRowVQKQiFgIxgvRlahDPRo9Q4W3PUwzeSdWVv93w== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2020 18:43:07.6166 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bb84e561-0605-4b18-c82b-08d7e9487f4d X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1706 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 18:43:14 -0000 On 4/25/20 2:42 AM, Olle E. Johansson wrote: >> NOTE: At the time of writing this specification, detailed procedures for the cases where a UAC receives multiple >> different authentication schemes had not been defined. A future specification might define such procedures. >> > Until we have a point where we know we can securely handle multiple authentication schemes from the same UAS, > I think we should recommend one policy per realm and/or domain. > > That will mean that until we have the BCP we determine method per device - new devices gets the challenge > that they support and we limit the possibilities of downgrade attacks. I don't understand what you are suggesting here. Is it that the UAS should only challenge with one scheme? That could be problematic, since it means either only use Digest, or else use Bearer and fail to work with any device that doesn't support it. (Can you say "flag day"?) Or do you mean that the UAC should only respond with credentials for one of the schemes it receives challenges for? Thanks, Paul From nobody Sat Apr 25 13:56:45 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169FF3A040E; Sat, 25 Apr 2020 13:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ZDK0VOZTjaT6; Sat, 25 Apr 2020 13:56:20 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00069.outbound.protection.outlook.com [40.107.0.69]) (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 1711E3A040B; Sat, 25 Apr 2020 13:56:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CXjRThPlXYHChe6/vLSJEB5O3XauWBgHuK74hcxhd3v4e09CV8TO+ryS7h5On0qPX963Vqp3x6aSmJjtvEEG+7W8ISa1IumScRycCIEqQe/gNEp39rU7UnUUZlAnellosN3hF3HyqpQx/JBIUU7rwhFXt9BdRxv/WGtKQQlgmHaA0Gg59mzh1WtB0rc83R2WbPRQ05eYfcmSjzvaQtB0nauJfTRiAT5eQ4Ppqmbw+V6WCykax4D9tEj8YKvvSFMX4JLcY3Vu3RL7pUboYH+jEt9Jny0tbvhc8QlhOyjYY7AhKeWzd16UzTByYheffbQkUHmCyqYPfgLoduntKWO/Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=olFpVXljAj6RUITCitgHWgYQeEzEnUchksBK/FVTcCQ=; b=kecPQC5V3poX+w1AIHu8Raf3m3lEplYMSyCDoOgF/MordX9m8a3ujF/LB00t8vwqw1CyWqvrllRStI0UKEWLzAZikLH+brkQQ4jnH/7SYrwm97t7CJIHfBspRG+0X0uO33cCPDv2MUQ9DXJVhe/DSiXm2E7Qyl1mz6PnKnbPi2qhg6upd5JKH9/FivmUzl8CJ6KMbUKHof0pxMe5CdJxRf0qObK2tdDTlFzmU2VV1HsdBP0v9t/jYPddMlhFA7SNQu+87dE7KKwAtS+oniQ6N0GPJJgWtrmnofMMWE29Hn4cQrPWh6TD9iOiJsqjP8we9lo7oQiQ+NCEiapJYWFxKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=olFpVXljAj6RUITCitgHWgYQeEzEnUchksBK/FVTcCQ=; b=KFj6OwKpAXJ3O+8VxoqCGLZvPgzPvNXDoBoiNwbBKLO0dGHNlXqTK/8kn55QpDlIwIragCV6d7Ob9oc+3hVdxiV8lwV9WXC7VKm1dkXrOh/sbQwXNV7MVtmbtonB9RABdDhUgWmspS2FN05kM1EWKpiF0OKhSaA+46TrOLYuaeU= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB5217.eurprd07.prod.outlook.com (2603:10a6:208:ed::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Sat, 25 Apr 2020 20:56:16 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2958.014; Sat, 25 Apr 2020 20:56:16 +0000 From: Christer Holmberg To: Paul Kyzivat , "Olle E. Johansson" CC: Benjamin Kaduk , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore@ietf.org" , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) Thread-Index: AQHWGaTv/W/UMLKp7ECr0CNaSmCuWKiHL6oAgACauACAADsIgIAAsN8AgABNwgCAAGIJgIAAyVcAgABXfwA= Date: Sat, 25 Apr 2020 20:56:16 +0000 Message-ID: <06B3574C-B01B-45E2-A0D8-17D26ADDF462@ericsson.com> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <60a98de4-a8cd-5910-17f9-6849d71f4d8e@alum.mit.edu> <79245079-4BE2-4CA1-9B8F-E7E71AD38458@ericsson.com> <20200424201316.GX27494@kduck.mit.edu> <34A7E724-6E92-4C66-95B5-22F3A22F8CE3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6aeb9c60-15d1-429f-5fcb-08d7e95b190c x-ms-traffictypediagnostic: AM0PR07MB5217: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0384275935 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(346002)(39860400002)(376002)(33656002)(8676002)(81156014)(2906002)(8936002)(86362001)(36756003)(5660300002)(26005)(6506007)(54906003)(71200400001)(478600001)(6486002)(110136005)(316002)(4326008)(2616005)(6512007)(186003)(76116006)(64756008)(91956017)(44832011)(66556008)(66946007)(66476007)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sBx9X0ftPMIBV13upiFwy2Wg6NXTRd802A7Vnsumbz4c4XxwWrbNZ3oyRJDeEQc/XG7aXqYgcAN02xwWjbrVK7h78i1az6aWx/WRRLChPYZBOtl3qrQ2I5VWx9/hQaeJ/wcApgzsZ09GPXbSA6N2FwPPRPoWtCm/1RoOyVJR7V8lPfYpaEuUGtKj3mtHNsyvbYxMx2VhjkICnmGrJKBaIW0rtybYMJgfm/A2Ffu9kiKqXTkTyTUoSxDH/0pxjd8TB9mvU7hwuzMMEazt3uySoLMCFIn0f3PQpQrSNGVKnLO0NiTGcI/3F4OcRag+YwiktnW+x1Taoo2TZre56gZE7xSU18xY17HixPlNSUDiqRnaHy2+3s6FNm3kzbsLDgQCX6E5iOeAAGfPQ6SUAZe3+lqtEv1ivlHvYQGC5osyis5VNl7XnVr5+bM+deBSlthq x-ms-exchange-antispam-messagedata: rYwbq2UXMr2sLHP/McRmCg4yRH6BHYwSljYaieUPuG1VIS5XqmNpbQT2T3zy+CP23uZnlYZRSCX14ZhuFFpkzlK6X4WC1KTlcLNobWWsA51gyh/Fk3CtbkVNC7wvUWPJ0FF/2DB8rK/62I0JIvtaM3ruCni1YtHsjNaoH/yNKrz8bSCPl6Fn2pgAhZephEzY/zDja/b+bQoEmcKOGc7nOSBJEovfwyQ/3seXHhf09PL92Vw1Baz6Y3hrvavZAtAJAw9908lqwtH/MbJT/8zSRS0Y525GLDjurv63yrKlIXGXr4apKKAT0GAutaxP0VW4ConOYfhdJWLcx7p+9X5RQHdxusva3NyY7JH8sbl1pu6oMxV+YOMz+pJp14g+AR0AsldfOmT3TnpGJOuARNaaM2Gg3s5RPDPGLZ/ReAbOksD5V5p/jqjkjO/4+gqM+pOpMsYPs01DFWlO8IwVeNYunUfd7vuMr9q0MjpZZPdHdIngnTUHlNL5STV0DVBiYrqgQfvzm1/3BQgepX/kv+QjdOdgkheQB/0OcF6UrPZ6eHY19j//fzfUPZMCn2uTJfIyG2WRt6F0RwsoJdYQ7RLyG5vHzswETh9FKfNuTiMUcRgNzU2AoI4DVHnv5CqDKyTRaCLjO6Msi0mE1LO9aDccYaaOU3LXjDcLHMsNrZRsnaB340njlORG2J5RyDRSwls+TVtGyJtLUsmsROfTdgRiCkKHzfIYp91i3a7csc/6TIi/3L4tzTSTaJsdz627/DHb9ns/17uWM2Ri3LV6CIAMN+ibCOlXHOHu1qEEF+Vxdqk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6aeb9c60-15d1-429f-5fcb-08d7e95b190c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2020 20:56:16.6202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b0LnvAY96AZmGmNxYQf8QVHKJccKU/3oaLhQ02HZKV3DA17TnAaz9juOMIG+FvtgWJOWuf5CuFZ8vDGRtTnG1WSR+alMFhwONQhfd+mudFo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5217 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 20:56:22 -0000 ICAgIA0KICAgID4+PiAgICBOT1RFOiBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoaXMgc3BlY2lm aWNhdGlvbiwgZGV0YWlsZWQgcHJvY2VkdXJlcyBmb3IgdGhlIGNhc2VzIHdoZXJlIGEgVUFDIHJl Y2VpdmVzIG11bHRpcGxlDQogICAgPj4+ICAgIGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBzY2hl bWVzIGhhZCBub3QgYmVlbiBkZWZpbmVkLiBBIGZ1dHVyZSBzcGVjaWZpY2F0aW9uIG1pZ2h0IGRl ZmluZSBzdWNoIHByb2NlZHVyZXMuDQogICAgPj4+DQogICAgPj4gVW50aWwgd2UgaGF2ZSBhIHBv aW50IHdoZXJlIHdlIGtub3cgd2UgY2FuIHNlY3VyZWx5IGhhbmRsZSBtdWx0aXBsZSBhdXRoZW50 aWNhdGlvbiBzY2hlbWVzIGZyb20gdGhlIHNhbWUgVUFTLA0KICAgID4+IEkgdGhpbmsgd2Ugc2hv dWxkIHJlY29tbWVuZCBvbmUgcG9saWN5IHBlciByZWFsbSBhbmQvb3IgZG9tYWluLg0KICAgID4+ IA0KICAgID4+IFRoYXQgd2lsbCBtZWFuIHRoYXQgdW50aWwgd2UgaGF2ZSB0aGUgQkNQIHdlIGRl dGVybWluZSBtZXRob2QgcGVyIGRldmljZSAtIG5ldyBkZXZpY2VzIGdldHMgdGhlIGNoYWxsZW5n ZQ0KICAgID4+IHRoYXQgdGhleSBzdXBwb3J0IGFuZCB3ZSBsaW1pdCB0aGUgcG9zc2liaWxpdGll cyBvZiBkb3duZ3JhZGUgYXR0YWNrcy4NCiAgICA+DQogICAgPiBJIGRvbid0IHVuZGVyc3RhbmQg d2hhdCB5b3UgYXJlIHN1Z2dlc3RpbmcgaGVyZS4NCiAgICA+DQogICAgPiBJcyBpdCB0aGF0IHRo ZSBVQVMgc2hvdWxkIG9ubHkgY2hhbGxlbmdlIHdpdGggb25lIHNjaGVtZT8gVGhhdCBjb3VsZCBi ZSANCiAgICA+IHByb2JsZW1hdGljLCBzaW5jZSBpdCBtZWFucyBlaXRoZXIgb25seSB1c2UgRGln ZXN0LCBvciBlbHNlIHVzZSBCZWFyZXIgDQogICAgPiBhbmQgZmFpbCB0byB3b3JrIHdpdGggYW55 IGRldmljZSB0aGF0IGRvZXNuJ3Qgc3VwcG9ydCBpdC4gKENhbiB5b3Ugc2F5IA0KICAgID4iZmxh ZyBkYXkiPykNCiAgICA+DQogICAgPiBPciBkbyB5b3UgbWVhbiB0aGF0IHRoZSBVQUMgc2hvdWxk IG9ubHkgcmVzcG9uZCB3aXRoIGNyZWRlbnRpYWxzIGZvciBvbmUgDQogICAgPiBvZiB0aGUgc2No ZW1lcyBpdCByZWNlaXZlcyBjaGFsbGVuZ2VzIGZvcj8NCiANCiAgICBUaGUgVUFDIG9ubHkgcmVz cG9uZGluZyB3aXRoIGNyZWRlbnRpYWxzIGZvciBvbmUgc2NoZW1lIGlzIHRoZSBzdWdnZXN0aW9u IGJhc2VkIG9uIEJlbmphbWluJ3MgcmV2aWV3Lg0KDQogICAgUmVnYXJkcywNCg0KICAgIENocmlz dGVyDQogICAgDQoNCg== From nobody Sat Apr 25 16:27:59 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7AF3A0D32; Sat, 25 Apr 2020 16:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 VbTwpN9l6s_F; Sat, 25 Apr 2020 16:27:39 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2053.outbound.protection.outlook.com [40.107.20.53]) (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 C839A3A0D2D; Sat, 25 Apr 2020 16:27:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7d+YanM2znvIzg+mXProybEWzw6aNgZ4neJq3pQ3kU3gJXi6+UWuBLfkNPt7zXiYjSzm3cbD67Irk+Buvx0yshq6fkfCJ5HpsMcQvpxnZYDYLUelnmZK5smvCMxLSRzF9l6vxbmVAuWl+vFiondkB/ENxBx/a+izDOeClQnNjrI7PsfmenU6MmH/jQ5yq1OQ/Wx8xI04AzB/ediFcA+0GN9QG4k/DR93zzfKGRUOKMjvaiRID2tQzuLD0A4CWz5HB+rIosVsg3UV19gEh3+dw86gcw/cb5NVcrQq76qYi4261qMs3rLu4Brk2jR22N/tZqJIJfRY3IIZGmnCb4Q4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E7cy8JcoRYsl1+fl5lhc+fzyOq37vz+stFqo20cW2d0=; b=I3mcVdPSFz64pphQrp8xj07iirUR/8Jfpm2thS1UeWRTv0xVlrZ5b5Klmaog2M3AWBmKrYMxq59J/gXuEh+v9qKyq/lRnFB6ELsiYnMyl4Es3gMxwfalNe+7/7eqpJFGRwKHC0TiTEvlp3S2PT6D9Yi7wDNRARLrEYcSZr05Uzs1/RoOkIrf4KR25VRsS/lvIj0jGjFDLTvZvUC41YuO0waaHDmMzCLdaBhpEJrdoEmWenZ1PIkxQglVR5t9AdXXP1RvUfs9qkMPF7qSZDiulFfkKPIawNVmAC8MnjqKUpB851qefhItVF76yOrq8lTy4HD6J4yB0ZMi7KvvVLTYRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E7cy8JcoRYsl1+fl5lhc+fzyOq37vz+stFqo20cW2d0=; b=cDx4a9k8odLSnOsBAlpgvpNget3od0fKLjaBGPHmCMh+eKRpO6CbHcaWZpk/x71Pwcp4gqY6xbW6QdiUxmaPCHXnaB/maNslVLWvm2UGn4QE3MSYWoblYQwQqRHyWHPAGw4Z9QSUKI94XXvGQixSCb2ql7dwKc2Ybbr0NhOX0zw= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6242.eurprd07.prod.outlook.com (2603:10a6:20b:152::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Sat, 25 Apr 2020 23:27:35 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2958.014; Sat, 25 Apr 2020 23:27:35 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Benjamin Kaduk CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply Thread-Index: AQHWGwEtfH/bpP2YLUqlNdqU6ZLbLaiKrnoA Date: Sat, 25 Apr 2020 23:27:34 +0000 Message-ID: <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85bd2aa3-a683-40a2-89cd-08d7e9703c27 x-ms-traffictypediagnostic: AM0PR07MB6242: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0384275935 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(66476007)(26005)(64756008)(66556008)(91956017)(66446008)(66946007)(966005)(71200400001)(86362001)(478600001)(4326008)(76116006)(2906002)(81156014)(44832011)(186003)(316002)(6506007)(110136005)(2616005)(6512007)(33656002)(8936002)(36756003)(54906003)(8676002)(5660300002)(6486002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AVse0AuruRkXFpCcO93uSzm04tAwfd2kUL9VCtspaBoKpAeRTi5YNzbIdM+TLbXgYgqUU+4STN3xBrpg+DzaZtkJyvrvoEDwU4Kxng2a3wcOnc7ApVJGGKtdrXVAIZlCobrHJF1/N3r3+Tkq2O4tyKsfakpQj74TS1frCIGyaJKDyt5zrHeTRMvuZKCQgX8cgr11YxExLPR/Za0cD3hQy+i87HU2rfBVqqjAzWcoBIwad4UquJ6blzaK71MIlJIxyVQQlGVkheLIhPkvCYfvDtoPHgQT5XpYQbMsFz9NajDC/PAP/E2lZkgqWvRjpxeaY2j36W0FYRhrc2GaVbTXBVUeTAldEOYKYWC9phczc0dAKeEoBud7Pye/JM2Qz1bAtaCyhJEBj206yvysXpK9Khx2+rMwAUYwdWsA6d8Q8tvAHtryL4UUPQ6NQE/2b0FKPcufFi+JLbscEYz+xOY1D2poYQURucXPwYxhsiV8fY4lIfCLDmQ7bkchERR9l9GiWZ71u8KaYzd5vPRS+iOfQA== x-ms-exchange-antispam-messagedata: qeVkXxCUKxu4xkq8EukCO7fJ9pucaEVmJxIIj6IR7V1aJh9rD9m6gFj3hMLOR5nysb6sTr1qkQTPsyVRpNxECE5yjN32zImSckYk8mOK+iM/mYjqhPm+T+b5rJuyGTKOdugRkqPmQuu+LLHuLvyP2HgwK2VSYyRhplLN7Sih9v5fi1LMJnkUbD/7rgYNwxwAGJ30/vC6b+pTAu/o4SoP9ufz8EG+VnV4Iqszq3icpvW6OtQhjgfQadgrZrONkhVP9B18as/ebTK+gp9b84vl31MJDenyua1O+Z9QhetwOQ+OM2/gnj5S21OR/uZD0OWxYhXS9hpV2UK1zPP+gbce+Sbgl2lviVsR1h85jrfBMzSVDn7uFfIWJOYYCbrL3bIM6jqBYLiMoA4xazvzwYrj38FHEqHStdRObppUg0yZwLTt1JlG01amTmG2kTRA7ZmNw9qsmHPxkCcgIJMsIktKuet1q0/eMq3G8oU+Nbc8IdnXoNwGJOQL8uDm8bNei7iviu1Ey/Q+m+wwyU5vd5nW/t1Hjg/ePPeUy1ATc9kK1nmaWftt8aVqIFFWCY/Ol9xVK7NiGNUxtXLwvCbsrToO+WYVVfTZb9ZlNghra3qE12dm4p6iddudTbl9mREyI4m6sfQ1AfFwktENo1oX3XYqcVKvvhCCS0AHbDvpm06MNP7UCFW4cliIitIjFzK/0xmJBJUTsrTuCUSKjuK1xtUPG6p51dYWcUzb/lduItt1Q94DG0obGcT6rT15eRYcRfhl3km3zhKxANmG67dAy9mFt17OIwpJEz90jT1bKd34t+U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1F9D9F169724694D9DE4B2EBC166C5FF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85bd2aa3-a683-40a2-89cd-08d7e9703c27 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2020 23:27:34.9978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5IyaIuJjeOeWJtYHzmRYHZFAvwcos/emlw/BFqNegO0wJnE7bcWlBIDmsyXTY5OPDIVuWogrY8t0NRj+Terv3PEe+z/BnzBDte9b9On3p7E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6242 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 23:27:41 -0000 SGkgQmVuamFtaW4sDQrCoA0KPj4gU2VjdGlvbiAyLjMgc3RhdGVzIHRoYXQ6DQo+Pg0KPj7CoCDC oFdoZW4gYSBwcm94eSB3aXNoZXMgdG8gYXV0aGVudGljYXRlIGEgcmVjZWl2ZWQgcmVxdWVzdCwg aXQgTVVTVA0KPj7CoCDCoHNlYXJjaCB0aGUgcmVxdWVzdCBmb3IgUHJveHktQXV0aG9yaXphdGlv biBoZWFkZXIgZmllbGRzIHdpdGggJ3JlYWxtJw0KPj7CoCDCoHBhcmFtZXRlcnMgdGhhdCBtYXRj aCBpdHMgcmVhbG0uwqAgSXQgdGhlbiBNVVNUIHN1Y2Nlc3NmdWxseSB2YWxpZGF0ZQ0KPj4NCj4+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MjM1I3NlY3Rpb24tNC40IHN1Z2dlc3Rz IHRoYXQgaXQgaXMgbm90DQo+PiBleHBlY3RlZCB0byBoYXZlIGEgc2VxdWVuY2Ugb3IgbGlzdCBv ZiBQcm94eS1BdXRob3JpemF0aW9uIGhlYWRlciBmaWVsZHMNCj4+IHByZXNlbnQgaW4gYSBzaW5n bGUgcmVxdWVzdCB0aGF0IGFyZSBpbnRlbmRlZCB0byBiZSBpbnRlcnByZXRlZCBieSBkaWZmZXJl bnQNCj4gcHJveGllcy7CoCBJcyB0aGlzIHRleHQgY29tcGF0aWJsZSB3aXRoIHRoYXQgcGFydCBv ZiBSRkMgNzIzNT/CoA0KDQpSRkMgMzI2MSBhbGxvd3MgbXVsdGlwbGUgUHJveHktQXV0aG9yaXph dGlvbiBoZWFkZXIgZmllbGRzLg0KDQo+IEZ1cnRoZXJtb3JlLCBJIGRpZG4ndCBmaW5kIG11Y2gg Z3VpZGFuY2UgaW4gNzIzNSBvciAzMjYxIGFib3V0IHdoZW4gdG8gaW5jbHVkZSB0aGUNCj4gInJl YWxtIiBwYXJhbWV0ZXIgaW4gUHJveHktQXV0aG9yaXphdGlvbjsgZG8gd2Ugd2FudCB0byBnaXZl IGFueSBndWlkYW5jZQ0KPiBoZXJlP8KgIChUaGF0IGlzIHRvIHNheSwgSSBhbG1vc3QgZGlkbid0 IGZpbmQgd2hlcmUgaXQgd2FzIGV2ZW4gZGVmaW5lZCBhcw0KPiBwb3NzaWJsZSB0byBkbyBzby4u LikNCg0KSSB0aGluayBpdCBpcyBjbGVhciBmcm9tIFNlY3Rpb24gMjIuMyAoYW5kIHRoZSBleGFt cGxlIGluIFNlY3Rpb24gMjAuMjgpIGluIFJGQyAzMjYxIHRoYXQgdGhlICJyZWFsbSIgaXMgaW5j bHVkZWQgaW4gdGhlIFByb3h5LUF1dGhvcml6YXRpb24gaGVhZGVyIGZpZWxkLg0KDQpJZiB3ZSB0 aGluayA3MjM1IGFuZC9vciAzMjYxIG5lZWRzIHRvIGJlIGltcHJvdmVkIHJlZ2FyZGluZyB0aGF0 IEkgdGhpbmsgaXQgaXMgYSBzZXBhcmF0ZSB0YXNrLCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50Lg0KwqANCihUaGUgdGhyZWFkIFJpZmFhdCBtZW50aW9uZWQgaXMgbm90IHJlYWxs eSByZWxhdGVkIHRvIHRoaXMuIEl0IGlzIHdoZXRoZXIgdGhlIFVBQyBwcm92aWRlcyBjcmVkZW50 aWFscyBmb3Igb25lIG9yIG1vcmUgc2NoZW1lcy4pDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQoNCg== From nobody Sun Apr 26 07:28:47 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7BE3A044F for ; Sun, 26 Apr 2020 07:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 MUOxQ-W0gUQJ for ; Sun, 26 Apr 2020 07:28:41 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2047.outbound.protection.outlook.com [40.107.223.47]) (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 90C303A044E for ; Sun, 26 Apr 2020 07:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LqqamtNyo6y+qspoN+WjOdH/Mq+BeiUw3SUqZdoTwKJJlGGlCSTkTSgNIsggMWr0feTGKoe9LsVXLuLzPJZqatnaASbSPjxsFIWPlK3wyamMqs48233mdql46cWgNi6DKnPqN0IMWluGDQuiSnlxg0FtZ73LzQAgQu16K8vsGvtLTGPPraHsbM3PZ8pxvt/+KO5w9P5PdMNp4yW2xp+qqjAv97OiSBIJ8oW9OsPfVO/ewZdl+lrXMfGdvkIBPd/A1l90sRHkxnmQW1EQ0mewn4N5g4tmsrT0lnVs7sVbBYLatcbC6YqOzZiUg3HzLCEHC2toVC4JT44fM+nQxYnx0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WS0L6dFBlabNt+Djb4mJJCNupoNAFf0PNjwfmAANEWI=; b=KJ7PgKvSoZtfJRM4i1+oh3Q74n9he4JZmLFSC+ODmFo6l3oueYowsGaK+iWmQ3lJSG6ckgXk9BK6gKnjB4HTMEiXK7hzNWOfq/tasDxX9KeNW9QQ2jVgjTvRMNs2etPkGjAA3+sV2ss267AT5WCQazYdADCQRRWhcs+g1fG6SjeTu4av8npAbDuvOBo8HJN1qFBT1MXL0JqMxmn1RxCXZLWHmrFYvrKBwXOsYzC9AvWsNl+yQoiA6O76hm8u1PrFPV6HSeud/ScE1HHX/WVSugU6pkAHdVl1dT5qiImq4C7tDbEmgiO7lqY7yJeDHE3oVflQigpK7zb3oedhM/0G3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WS0L6dFBlabNt+Djb4mJJCNupoNAFf0PNjwfmAANEWI=; b=gmFULCMGrpu2rUDLbIaCXl6rbYp++nmiDpAhnECpUFhLIEYhLlYWlBDpO/ZvjuzIu29oymJNCBbHHxQPIuR7ILoKrF4MBfLSB/5klhwwW3/jFLhq+mebtO2lJGO5SX/cXmNk3tUy7i3HF4qP41vgKi0S1FJZDNR5d5icyPymlts= Received: from MN2PR18CA0024.namprd18.prod.outlook.com (2603:10b6:208:23c::29) by DM6PR12MB4547.namprd12.prod.outlook.com (2603:10b6:5:2a9::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sun, 26 Apr 2020 14:28:39 +0000 Received: from BL2NAM02FT038.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23c:cafe::31) by MN2PR18CA0024.outlook.office365.com (2603:10b6:208:23c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sun, 26 Apr 2020 14:28:38 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT038.mail.protection.outlook.com (10.152.77.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sun, 26 Apr 2020 14:28:38 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 03QESaDq007600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 26 Apr 2020 10:28:37 -0400 To: sipcore@ietf.org References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> From: Paul Kyzivat Message-ID: Date: Sun, 26 Apr 2020 10:28:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(376002)(39860400002)(396003)(346002)(46966005)(31686004)(336012)(2616005)(956004)(7596003)(356005)(8676002)(31696002)(316002)(786003)(8936002)(82310400002)(86362001)(75432002)(246002)(36906005)(478600001)(70206006)(82740400003)(53546011)(26005)(70586007)(6916009)(2906002)(47076004)(966005)(186003)(5660300002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b7a76f47-fbdc-4a4f-b20f-08d7e9ee1c4c X-MS-TrafficTypeDiagnostic: DM6PR12MB4547: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 03853D523D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IKBn7kF0VMYTeP0HfFYovjJh7KYTIL2pPBelgvpxHA8YSwr1nikq2BX87wwcxNUtSobPLy+sNC87UD3wA6kxRbCDOqLhWOijumSpaei9WwU9obaxwdoEAVbsTZPFsA1VPAzgREx7xhttlwlS5u8wACl0n8vSdbNEzPL0Pjg527hQY1pXPM798VV8pihZ8+GSbBXmGIi6GrDYLzDHXmuDfPEExYRU/fy4FxfCIyIRylrjTpcl/HjMrPd5+0PHNCz7me0joaTjEgU1Gf3yZKw/KMbYBb7qUv9/zCIBkZ3GMBrNueBMzHMUcWVZ9Bp+3THPxaTtfSXmvSIOus4btaZ7OyNFGeXjpNYubTMt2b21xzLi17yHo5tCKuLKdudDof2CRIVunKWk3xLPXy81wastd9ex/F6ci4JAqAOhU+XK3/eD8o05W5yUnNMUCf1kOCaUcJ/4jGz1wCM5mTmzOJbhox7zJHWiK3mFcSWKWTMJEX4IZC0ayB1yON82imKFa59qkXDgXQOvzH82XNcy6d3mlSH6Whd6wgaweY1JEGgcdS3V4idWG+GI7zskSwSgaFT7Qhk1p+bRy1Q24LmSNcJdYQ== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2020 14:28:38.1911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b7a76f47-fbdc-4a4f-b20f-08d7e9ee1c4c X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4547 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 14:28:44 -0000 On 4/25/20 7:27 PM, Christer Holmberg wrote: > Hi Benjamin, > >>> Section 2.3 states that: >>> >>>    When a proxy wishes to authenticate a received request, it MUST >>>    search the request for Proxy-Authorization header fields with 'realm' >>>    parameters that match its realm.  It then MUST successfully validate >>> >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not >>> expected to have a sequence or list of Proxy-Authorization header fields >>> present in a single request that are intended to be interpreted by different >> proxies.  Is this text compatible with that part of RFC 7235? > > RFC 3261 allows multiple Proxy-Authorization header fields. * Here is a situation when they come into play: UAC ----- P1 ------- P2 ------- UAS On the first request from UAC toward UAS, P1 challenges with a Proxy-Authenticate containing realm P1. UAC retries, including Proxy-Authorization for realm P1. P1 is happy and passes the request along. P2 challenges with realm P2. UAC retries again. It adds Proxy-Authorization for realm P2, but also including the credentials for P1. P1 is happy and passes the request along. P2 is also happy and passes the request along to UAS. Note that UAC must *remember* to include the P1 credentials in the second retry because there is no Proxy-Authenticate for P1 in the 407 from P2. Similarly, in future messages toward UAS the UAC should remember to include credentials for P1 and P1. * A more complex case is: UAC ----- P1 -|------ P2 ------ UAS-A | |------ P3 ------ UAS-B On the first request from UAC toward UAS, P1 challenges with a Proxy-Authenticate containing realm P1. UAC retries, including Proxy-Authorization for realm P1. P1 is happy. If it does parallel forking then it passes the request along to both P2 and P3. P2 challenges by returning a Proxy-Authenticate for realm P2. P1 buffers that response while awaiting a response from P3. P3 challenges by returning a Proxy-Authenticate for realm P3. P2 passes a response back to UAC with Proxy-Authenticates for realms P2 and P3. UAC retries again. It adds Proxy-Authorization for realms P2 and P3, but also including the credentials for P1. P1 is happy and passes the request along to both P2 and P3. P2 finds its Proxy-Authorization and happily passes the request along to UAS-A. P3 finds its Proxy-Authorization and happily passes the request along to UAS-B. Thanks, Paul From nobody Sun Apr 26 08:58:53 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76F3A03EC for ; Sun, 26 Apr 2020 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1GYSalu3VZ2 for ; Sun, 26 Apr 2020 08:58:45 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 923DF3A0A34 for ; Sun, 26 Apr 2020 08:58:45 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id r2so14359184ilo.6 for ; Sun, 26 Apr 2020 08:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CbKCgwrqUO4CZ7xvR7ovXjF8XbiDKXD1sm2wKmOXCzA=; b=dW01RjCcQ7a17Xdggt9nnpF1iLYSnZHJHtza7IZzhGUmvlMPDr3JWTan0CW9XOZ7Hf bF5bOqCAJCQZhKCY76qhw3J51P8a01nSqvI2+XMERTI434ws203QYGIIbZgN40jZ5PCj yhZMZvWfWMFmoCU+CPzo1NaCqAAMKTOoZ6jt5+HQLne5p8mYt0ATM5DE+bXLXTLEuVtu +oGMtrL/UZGLaMsmG3sB5qjxAUinPbOepxJv12b9WSqtUJLVM0B14leoO0u9vQMm3XJP FKnX8RGTQ9MBlJ7lgcQfp4JQvdBYxfqmjzGS1Msk3IB4aeiss1yLaPw5oHJDRxLNq796 4WSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CbKCgwrqUO4CZ7xvR7ovXjF8XbiDKXD1sm2wKmOXCzA=; b=AMHqhknBCGj34qTMRQogfuJW/z2/jvaH7eJ7ONIYov+7MefipBOlpGIIKxOcqqUnmW m0H/+vz5qXOfdt8eTKqD9sWsWWYmWbCcq2vSTFd25AX2sFyEJA6DD9v8m/UNdG9xxuLz M9Vne3dV8OhliNahf/73fvIZA1Sk0hrNHIuje+YU5gD5T2rcEDGnfSUIasbG8I+YD6sf HxGll4wmXM908emWphcnNGmatwEmAAPf7m7euRs4fEP9pgSffyiIkCuENCMa7TXBMdYT PFt7Dq5b9YWTvIjhlnoOnlNrcdde65UQMYQCgbonbkCjcULzCRREsqqOhWcTnzy3BIdj LvEQ== X-Gm-Message-State: AGi0PuYHi0CDjWN4vT/9AINqk+xqWxoA3OYnVtibqYgL5/av/cUOV//w ioteCDJcbeftY3QrGyS7KLIP5L0vtsFhFGkeCUE= X-Google-Smtp-Source: APiQypI+YGZ3dfyL+xiKxzM4Vh9/q772yfu0sTsF+Mwjlthss3dL2nGseVYLqN2Tco7BTwVafOF9Urz1GXarWRETekU= X-Received: by 2002:a92:d3c5:: with SMTP id c5mr17750304ilh.73.1587916724723; Sun, 26 Apr 2020 08:58:44 -0700 (PDT) MIME-Version: 1.0 References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 26 Apr 2020 11:58:34 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000004f67f505a433ac4e" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 15:58:52 -0000 --0000000000004f67f505a433ac4e Content-Type: text/plain; charset="UTF-8" Paul, What you described is the theory; have you seen this deployed in practice? Regards, Rifaat On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat wrote: > On 4/25/20 7:27 PM, Christer Holmberg wrote: > > Hi Benjamin, > > > >>> Section 2.3 states that: > >>> > >>> When a proxy wishes to authenticate a received request, it MUST > >>> search the request for Proxy-Authorization header fields with > 'realm' > >>> parameters that match its realm. It then MUST successfully > validate > >>> > >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is > not > >>> expected to have a sequence or list of Proxy-Authorization header > fields > >>> present in a single request that are intended to be interpreted by > different > >> proxies. Is this text compatible with that part of RFC 7235? > > > > RFC 3261 allows multiple Proxy-Authorization header fields. > > * Here is a situation when they come into play: > > UAC ----- P1 ------- P2 ------- UAS > > On the first request from UAC toward UAS, P1 challenges with a > Proxy-Authenticate containing realm P1. > > UAC retries, including Proxy-Authorization for realm P1. P1 is happy and > passes the request along. P2 challenges with realm P2. > > UAC retries again. It adds Proxy-Authorization for realm P2, but also > including the credentials for P1. P1 is happy and passes the request > along. P2 is also happy and passes the request along to UAS. > > Note that UAC must *remember* to include the P1 credentials in the > second retry because there is no Proxy-Authenticate for P1 in the 407 > from P2. Similarly, in future messages toward UAS the UAC should > remember to include credentials for P1 and P1. > > * A more complex case is: > > UAC ----- P1 -|------ P2 ------ UAS-A > | > |------ P3 ------ UAS-B > > On the first request from UAC toward UAS, P1 challenges with a > Proxy-Authenticate containing realm P1. > > UAC retries, including Proxy-Authorization for realm P1. P1 is happy. > If it does parallel forking then it passes the request along to both P2 > and P3. > > P2 challenges by returning a Proxy-Authenticate for realm P2. > > P1 buffers that response while awaiting a response from P3. > > P3 challenges by returning a Proxy-Authenticate for realm P3. > > P2 passes a response back to UAC with Proxy-Authenticates for realms P2 > and P3. > > UAC retries again. It adds Proxy-Authorization for realms P2 and P3, but > also including the credentials for P1. P1 is happy and passes the > request along to both P2 and P3. > > P2 finds its Proxy-Authorization and happily passes the request along to > UAS-A. > > P3 finds its Proxy-Authorization and happily passes the request along to > UAS-B. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000004f67f505a433ac4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

What you described is the theory;= have you seen this deployed in practice?

Regards,=
=C2=A0Rifaat


On Sun, Apr 26, 2020 at 10:28 A= M Paul Kyzivat <pkyzivat@alum.m= it.edu> wrote:
On 4/25/20 7:27 PM, Christer Holmberg wrote:
> Hi Benjamin,
>=C2=A0 =C2=A0
>>> Section 2.3 states that:
>>>
>>>=C2=A0 =C2=A0 =C2=A0When a proxy wishes to authenticate a recei= ved request, it MUST
>>>=C2=A0 =C2=A0 =C2=A0search the request for Proxy-Authorization = header fields with 'realm'
>>>=C2=A0 =C2=A0 =C2=A0parameters that match its realm.=C2=A0 It t= hen MUST successfully validate
>>>
>>> https://tools.ietf.org/html/rfc7235#sect= ion-4.4 suggests that it is not
>>> expected to have a sequence or list of Proxy-Authorization hea= der fields
>>> present in a single request that are intended to be interprete= d by different
>> proxies.=C2=A0 Is this text compatible with that part of RFC 7235?=
>
> RFC 3261 allows multiple Proxy-Authorization header fields.

* Here is a situation when they come into play:

UAC ----- P1 ------- P2 ------- UAS

On the first request from UAC toward UAS, P1 challenges with a
Proxy-Authenticate containing realm P1.

UAC retries, including Proxy-Authorization for realm P1. P1 is happy and passes the request along. P2 challenges with realm P2.

UAC retries again. It adds Proxy-Authorization for realm P2, but also
including the credentials for P1. P1 is happy and passes the request
along. P2 is also happy and passes the request along to UAS.

Note that UAC must *remember* to include the P1 credentials in the
second retry because there is no Proxy-Authenticate for P1 in the 407
from P2. Similarly, in future messages toward UAS the UAC should
remember to include credentials for P1 and P1.

* A more complex case is:

UAC ----- P1 -|------ P2 ------ UAS-A
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------ P3 ------ UA= S-B

On the first request from UAC toward UAS, P1 challenges with a
Proxy-Authenticate containing realm P1.

UAC retries, including Proxy-Authorization for realm P1. P1 is happy.
If it does parallel forking then it passes the request along to both P2 and P3.

P2 challenges by returning a Proxy-Authenticate for realm P2.

P1 buffers that response while awaiting a response from P3.

P3 challenges by returning a Proxy-Authenticate for realm P3.

P2 passes a response back to UAC with Proxy-Authenticates for realms P2 and P3.

UAC retries again. It adds Proxy-Authorization for realms P2 and P3, but also including the credentials for P1. P1 is happy and passes the
request along to both P2 and P3.

P2 finds its Proxy-Authorization and happily passes the request along to UAS-A.

P3 finds its Proxy-Authorization and happily passes the request along to UAS-B.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--0000000000004f67f505a433ac4e-- From nobody Sun Apr 26 10:13:05 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35983A09FB for ; Sun, 26 Apr 2020 10:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 kp8J3r8JXgXO for ; Sun, 26 Apr 2020 10:13:00 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140055.outbound.protection.outlook.com [40.107.14.55]) (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 3D9273A09F7 for ; Sun, 26 Apr 2020 10:12:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GQiAIW1Ytc5ZYa1ar4pjGMM+dgFjXWCmHi0RGYC+knhcrvEeGDlxtNj42jfZ92O8km7qA5WIot5r/G0Q5mIdYZLZ0h/5tfxKNZNUUEcfu0u/HYIU6o9H/THSLE0AUfpPs3pb4IY2hdZqE9j2eCqDQ35oX8QmGep44xDzxe0mkiOV+GHKHVBIkPa6un0Dtq5luJ9sFm+5i3qooSwns4lpTC/HvnJRM4xvhfx6WwckGoBdX/+AKvS47/lafA4cDphtfFGuRLUAsBVtNWfnACRVMjQItQPbN80vBT29G3BFOBwI1ZAHOhIfN64wjR5baqluTS5NH3DIc77h/IMllybLbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GlrKbr0A6ky6ijtSDHD+5oUnQZlvcIAs/2BEdu9sZO0=; b=WOXj5iQDwz3szZWWjFg3xLsKvyXUGKprhzTYO/tvP2rhN2QpADyMdyIo+jMiDLK53fF+dMrAMg0pPXT0JpcF7uqtWA00GUbh9nd/UUP1Ls/O7yQiET6WfctJVIAjvF3Pu0V614I9fZK7vcw/IxuBOVQTfhacZWqIHD/v8eeJwK6IYu/2OQLMGNr1quJJMqhrqt+jq5/3rnpLsh4e/Pbbi6umQLploS8HqSsdRIoVdbCeSVjZHycTxRoVA/iR0XB7H9imsUVlDvG9nUY+eA5zPzu/D8j8tpMU9VYaeo9TdTrP3xlvRg4MM8quQ2YXCyStJuJFMdDRTKboaXOeY+kNXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GlrKbr0A6ky6ijtSDHD+5oUnQZlvcIAs/2BEdu9sZO0=; b=htWqahdfh8wEjSQxQhoS4woa977HSRRd/dTMXuaRDrzFNR3ltsAdJg1CtZ5/cD2xQsXMSDFtYyCPNEpm61qZsoVSlPnWdHXxSUE7TeLtKZBwmuLjtVs2LvfdHTBibwBe0vHCcQO7/88e5nzQUlRLZJtjBFZ3mxWrK54cJ2B3+1s= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6867.eurprd07.prod.outlook.com (2603:10a6:20b:1be::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.12; Sun, 26 Apr 2020 17:12:56 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Sun, 26 Apr 2020 17:12:56 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Paul Kyzivat CC: SIPCORE Thread-Topic: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply Thread-Index: AQHWGwEtfH/bpP2YLUqlNdqU6ZLbLaiKrnoAgADJdACAABkjAIAARxIA Date: Sun, 26 Apr 2020 17:12:56 +0000 Message-ID: <262816DF-8F09-43B4-BC5F-4F0544CFDF80@ericsson.com> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 024aef6e-997f-4ec2-4b31-08d7ea051068 x-ms-traffictypediagnostic: AM7PR07MB6867: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03853D523D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(86362001)(5660300002)(8936002)(44832011)(2906002)(91956017)(6512007)(26005)(76116006)(66946007)(36756003)(186003)(71200400001)(4326008)(33656002)(2616005)(6486002)(478600001)(966005)(66476007)(66556008)(64756008)(66446008)(6506007)(53546011)(110136005)(316002)(81156014)(8676002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J8rGhlGtIr7epSPHsAqiOGRyQwwAHTmndKnMxMSs14xJgR1EJHzA/x6QaJmJuz7rGKgq67EfCwUVC/DFCKPbiHzm1Y3vTAcenfdyiadhBJo5u5h0q5rngceIGZSnnIHpv+vXAyrbvOMtcRFuta2BxvxqEcvU4Lp42LmN9va2BnTzQFpXi63fsj/1LQaVytoWJHHlVNVhQAVJeiagr7Wkm/8Cx3a/QceycpgXA6+LqVYUgHuuo3RJtAAvvm4r+u2l5bdmoedzdwnWiAHVhX2NbZ6CEQiKyB4JN/7pJxpknj8vSK+Cxz0wXR/fE7DK/g9eRbubAbNrqi4Pik0a8q6SnNlqGBPl/Ohll1iBt1YLr9LHE3TVdHVeRBwu292V7kEzb9mRmHnW+3TKVd+qQhLhuHC6l6b3UYnEIp/K9r/3/SfRcjwVZDd7PTNVoq1x9DEIqL0ki6TKGhFStDXgTgiD3UDc+G9cu0YtGRN97Cd6GwMPOUsko1lLzcfFm8sVgrLQkY02i039KkhIoLuqknHBtw== x-ms-exchange-antispam-messagedata: dsWfpXeqC0vMzQI5aPlWKNRuDiiOBMswyoStAdkbvPTe5Z6h7SmCHEd+foQSCjx3oaZOytAXSxe7JPUuBV+Qja1jaDRI0QCzmiz4FA02rpk7UVOEZzHjcmadLF90kGkY8jL6xOlYDbxzdPUMno+5Sjto7PZfT2DfB5lmFGZ8QyDWayq9wJ+ggSlwZJM2Sl7aujPuOyoa5wSCHSaNpDYqVZsJqUNELVKeWIHomkmSmmQQg0kEmwOJsbzfY+pNPaExIp/5YUrWAOztC+H8YCibZyK7BQsrGH/8elQSm+kHGQTMFu/YSE7uKReUO5G2X+vVYE61UsBMVtYtoycgdUqJfUtFSLWShW+QCs8ViKFTrpRZBIQQP4w9NF/k5Fa8Nq6RkW8hd4I+bGeel2kN4VtaNCccZJpL/CJuu4oQ7awCNCIP2leDRD+wGDeJ4LUF9JA2cM53G8QJztSq18iyGVcIHM3jNd7fMPSOuYSuBAMzKRv2gaKt3jjPUPjKuUHt3mL1U7GVjNYLNqSp5+h6alnAqMHIwRYoLVItaqI85P3atZVPOxoFvIbu3v/JXHhVmdG0fVf6IcOBKKICS9cq2ATIpzZ+WdOJkwacZBU//4xslr56jJOTeOS/hlzNZzvjCcBCc2K6UkboigdW8qqvkxI68npemF3WjlmFJ6Y2J3Qe03Pn8BFyNPFIGCdaOSSBbiDYk4HtcOg5Q8Qmlb20bjj1JPgQlN4T2azp0zUBidfGdKIDGlS2f/IvZqn1PGYUsoOgVYJwyZ/Xvj3TThmoZxhkhHWmfqJ7YCY5CGjkHYIHpiU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_262816DF8F0943B4BC5F4F0544CFDF80ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 024aef6e-997f-4ec2-4b31-08d7ea051068 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2020 17:12:56.6016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gK00OF8877/EXcjL94DXAoVqnm/nofUJFVebZsbReKCenVlVWoZifERI4qqrimn/Nu/aKHZffgcUoQQgn2GipyvZjBmz5CrRHlyIJVxOLo8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6867 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 17:13:04 -0000 --_000_262816DF8F0943B4BC5F4F0544CFDF80ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVywgSSBjYW7igJl0IHJlbWVtYmVyIHRoYXQgd291bGQgZXZlbiBoYXZlIHNlZW4gUHJveHkt QXV0aGVudGljYXRlIGluIGEgcmVhbCBkZXBsb3ltZW50LCBhbmQgSSBoYXZlIGRlZmluaXRlbHkg bmV2ZXIgc2VlbiBhIGNoYWluIG9mIHByb3hpZXMgYXV0aGVudGljYXRpbmcgdGhlIFVBQy4NCg0K SW4gbXkgZXhwZXJpZW5jZSwgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIGRvbmUgYnkgdGhlIGhvbWUg cmVnaXN0cmFyLCBhbmQgaXQgaXMgZG9uZSBiZWZvcmUgYSByZXF1ZXN0IGhhcyBiZWVuIGZvcmtl ZC4NCg0KSW4gYW55IGNhc2UsIFJGQyAzMjYxIGFsbG93cyBmb3Igb3RoZXIgc2NlbmFyaW9zLCBz byB0aGFua3MgdG8gUGF1bCBmb3IgZXhwbGFpbmluZyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFN1bmRh eSwgMjYgQXByaWwgMjAyMCBhdCAxOC41OQ0KVG86ICJwa3l6aXZhdEBhbHVtLm1pdC5lZHUiIDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpDYzogInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnotMTMgLSBESVNDVVNTIFJlcGx5 DQoNClBhdWwsDQoNCldoYXQgeW91IGRlc2NyaWJlZCBpcyB0aGUgdGhlb3J5OyBoYXZlIHlvdSBz ZWVuIHRoaXMgZGVwbG95ZWQgaW4gcHJhY3RpY2U/DQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0K T24gU3VuLCBBcHIgMjYsIDIwMjAgYXQgMTA6MjggQU0gUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBh bHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KT24gNC8y NS8yMCA3OjI3IFBNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGkgQmVuamFtaW4sDQo+ DQo+Pj4gU2VjdGlvbiAyLjMgc3RhdGVzIHRoYXQ6DQo+Pj4NCj4+PiAgICAgV2hlbiBhIHByb3h5 IHdpc2hlcyB0byBhdXRoZW50aWNhdGUgYSByZWNlaXZlZCByZXF1ZXN0LCBpdCBNVVNUDQo+Pj4g ICAgIHNlYXJjaCB0aGUgcmVxdWVzdCBmb3IgUHJveHktQXV0aG9yaXphdGlvbiBoZWFkZXIgZmll bGRzIHdpdGggJ3JlYWxtJw0KPj4+ICAgICBwYXJhbWV0ZXJzIHRoYXQgbWF0Y2ggaXRzIHJlYWxt LiAgSXQgdGhlbiBNVVNUIHN1Y2Nlc3NmdWxseSB2YWxpZGF0ZQ0KPj4+DQo+Pj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzUjc2VjdGlvbi00LjQgc3VnZ2VzdHMgdGhhdCBpdCBp cyBub3QNCj4+PiBleHBlY3RlZCB0byBoYXZlIGEgc2VxdWVuY2Ugb3IgbGlzdCBvZiBQcm94eS1B dXRob3JpemF0aW9uIGhlYWRlciBmaWVsZHMNCj4+PiBwcmVzZW50IGluIGEgc2luZ2xlIHJlcXVl c3QgdGhhdCBhcmUgaW50ZW5kZWQgdG8gYmUgaW50ZXJwcmV0ZWQgYnkgZGlmZmVyZW50DQo+PiBw cm94aWVzLiAgSXMgdGhpcyB0ZXh0IGNvbXBhdGlibGUgd2l0aCB0aGF0IHBhcnQgb2YgUkZDIDcy MzU/DQo+DQo+IFJGQyAzMjYxIGFsbG93cyBtdWx0aXBsZSBQcm94eS1BdXRob3JpemF0aW9uIGhl YWRlciBmaWVsZHMuDQoNCiogSGVyZSBpcyBhIHNpdHVhdGlvbiB3aGVuIHRoZXkgY29tZSBpbnRv IHBsYXk6DQoNClVBQyAtLS0tLSBQMSAtLS0tLS0tIFAyIC0tLS0tLS0gVUFTDQoNCk9uIHRoZSBm aXJzdCByZXF1ZXN0IGZyb20gVUFDIHRvd2FyZCBVQVMsIFAxIGNoYWxsZW5nZXMgd2l0aCBhDQpQ cm94eS1BdXRoZW50aWNhdGUgY29udGFpbmluZyByZWFsbSBQMS4NCg0KVUFDIHJldHJpZXMsIGlu Y2x1ZGluZyBQcm94eS1BdXRob3JpemF0aW9uIGZvciByZWFsbSBQMS4gUDEgaXMgaGFwcHkgYW5k DQpwYXNzZXMgdGhlIHJlcXVlc3QgYWxvbmcuIFAyIGNoYWxsZW5nZXMgd2l0aCByZWFsbSBQMi4N Cg0KVUFDIHJldHJpZXMgYWdhaW4uIEl0IGFkZHMgUHJveHktQXV0aG9yaXphdGlvbiBmb3IgcmVh bG0gUDIsIGJ1dCBhbHNvDQppbmNsdWRpbmcgdGhlIGNyZWRlbnRpYWxzIGZvciBQMS4gUDEgaXMg aGFwcHkgYW5kIHBhc3NlcyB0aGUgcmVxdWVzdA0KYWxvbmcuIFAyIGlzIGFsc28gaGFwcHkgYW5k IHBhc3NlcyB0aGUgcmVxdWVzdCBhbG9uZyB0byBVQVMuDQoNCk5vdGUgdGhhdCBVQUMgbXVzdCAq cmVtZW1iZXIqIHRvIGluY2x1ZGUgdGhlIFAxIGNyZWRlbnRpYWxzIGluIHRoZQ0Kc2Vjb25kIHJl dHJ5IGJlY2F1c2UgdGhlcmUgaXMgbm8gUHJveHktQXV0aGVudGljYXRlIGZvciBQMSBpbiB0aGUg NDA3DQpmcm9tIFAyLiBTaW1pbGFybHksIGluIGZ1dHVyZSBtZXNzYWdlcyB0b3dhcmQgVUFTIHRo ZSBVQUMgc2hvdWxkDQpyZW1lbWJlciB0byBpbmNsdWRlIGNyZWRlbnRpYWxzIGZvciBQMSBhbmQg UDEuDQoNCiogQSBtb3JlIGNvbXBsZXggY2FzZSBpczoNCg0KVUFDIC0tLS0tIFAxIC18LS0tLS0t IFAyIC0tLS0tLSBVQVMtQQ0KICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfC0tLS0t LSBQMyAtLS0tLS0gVUFTLUINCg0KT24gdGhlIGZpcnN0IHJlcXVlc3QgZnJvbSBVQUMgdG93YXJk IFVBUywgUDEgY2hhbGxlbmdlcyB3aXRoIGENClByb3h5LUF1dGhlbnRpY2F0ZSBjb250YWluaW5n IHJlYWxtIFAxLg0KDQpVQUMgcmV0cmllcywgaW5jbHVkaW5nIFByb3h5LUF1dGhvcml6YXRpb24g Zm9yIHJlYWxtIFAxLiBQMSBpcyBoYXBweS4NCklmIGl0IGRvZXMgcGFyYWxsZWwgZm9ya2luZyB0 aGVuIGl0IHBhc3NlcyB0aGUgcmVxdWVzdCBhbG9uZyB0byBib3RoIFAyDQphbmQgUDMuDQoNClAy IGNoYWxsZW5nZXMgYnkgcmV0dXJuaW5nIGEgUHJveHktQXV0aGVudGljYXRlIGZvciByZWFsbSBQ Mi4NCg0KUDEgYnVmZmVycyB0aGF0IHJlc3BvbnNlIHdoaWxlIGF3YWl0aW5nIGEgcmVzcG9uc2Ug ZnJvbSBQMy4NCg0KUDMgY2hhbGxlbmdlcyBieSByZXR1cm5pbmcgYSBQcm94eS1BdXRoZW50aWNh dGUgZm9yIHJlYWxtIFAzLg0KDQpQMiBwYXNzZXMgYSByZXNwb25zZSBiYWNrIHRvIFVBQyB3aXRo IFByb3h5LUF1dGhlbnRpY2F0ZXMgZm9yIHJlYWxtcyBQMg0KYW5kIFAzLg0KDQpVQUMgcmV0cmll cyBhZ2Fpbi4gSXQgYWRkcyBQcm94eS1BdXRob3JpemF0aW9uIGZvciByZWFsbXMgUDIgYW5kIFAz LCBidXQNCmFsc28gaW5jbHVkaW5nIHRoZSBjcmVkZW50aWFscyBmb3IgUDEuIFAxIGlzIGhhcHB5 IGFuZCBwYXNzZXMgdGhlDQpyZXF1ZXN0IGFsb25nIHRvIGJvdGggUDIgYW5kIFAzLg0KDQpQMiBm aW5kcyBpdHMgUHJveHktQXV0aG9yaXphdGlvbiBhbmQgaGFwcGlseSBwYXNzZXMgdGhlIHJlcXVl c3QgYWxvbmcgdG8NClVBUy1BLg0KDQpQMyBmaW5kcyBpdHMgUHJveHktQXV0aG9yaXphdGlvbiBh bmQgaGFwcGlseSBwYXNzZXMgdGhlIHJlcXVlc3QgYWxvbmcgdG8NClVBUy1CLg0KDQogICAgICAg IFRoYW5rcywNCiAgICAgICAgUGF1bA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCg== --_000_262816DF8F0943B4BC5F4F0544CFDF80ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5GV0lXLCBJIGNhbuKAmXQgcmVtZW1iZXIgdGhhdCB3b3VsZCBldmVuIGhhdmUg c2VlbiBQcm94eS1BdXRoZW50aWNhdGUgaW4gYSByZWFsIGRlcGxveW1lbnQsIGFuZCBJIGhhdmUg ZGVmaW5pdGVseSBuZXZlciBzZWVuIGEgY2hhaW4gb2YgcHJveGllcyBhdXRoZW50aWNhdGluZyB0 aGUgVUFDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkluIG15IGV4cGVyaWVuY2Us IHRoZSBhdXRoZW50aWNhdGlvbiBpcyBkb25lIGJ5IHRoZSBob21lIHJlZ2lzdHJhciwgYW5kIGl0 IGlzIGRvbmUgYmVmb3JlIGEgcmVxdWVzdCBoYXMgYmVlbiBmb3JrZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SW4gYW55IGNhc2UsIFJGQyAzMjYxIGFsbG93cyBmb3Igb3RoZXIg c2NlbmFyaW9zLCBzbyB0aGFua3MgdG8gUGF1bCBmb3IgZXhwbGFpbmluZyA6KQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5zaXBjb3JlICZsdDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9u IGJlaGFsZiBvZiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCAyNiBBcHJpbCAyMDIwIGF0IDE4LjU5PGJyPg0K PGI+VG86IDwvYj4mcXVvdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmcXVvdDsgJmx0O3BreXppdmF0 QGFsdW0ubWl0LmVkdSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NpcGNvcmVAaWV0Zi5vcmcm cXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb c2lwY29yZV0gQmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1z aXAtdG9rZW4tYXV0aG56LTEzIC0gRElTQ1VTUyBSZXBseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF1bCwgPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHlvdSBkZXNjcmliZWQgaXMg dGhlIHRoZW9yeTsgaGF2ZSB5b3Ugc2VlbiB0aGlzIGRlcGxveWVkIGluIHByYWN0aWNlPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gU3VuLCBBcHIgMjYsIDIwMjAgYXQgMTA6MjggQU0gUGF1bCBLeXppdmF0ICZs dDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1p dC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQvMjUvMjAgNzoyNyBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgd3JvdGU6PGJyPg0KJmd0OyBIaSBCZW5qYW1pbiw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOzxi cj4NCiZndDsmZ3Q7Jmd0OyBTZWN0aW9uIDIuMyBzdGF0ZXMgdGhhdDo8YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1doZW4gYSBwcm94eSB3aXNo ZXMgdG8gYXV0aGVudGljYXRlIGEgcmVjZWl2ZWQgcmVxdWVzdCwgaXQgTVVTVDxicj4NCiZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c2VhcmNoIHRoZSByZXF1ZXN0IGZvciBQcm94eS1B dXRob3JpemF0aW9uIGhlYWRlciBmaWVsZHMgd2l0aCAncmVhbG0nPGJyPg0KJmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtwYXJhbWV0ZXJzIHRoYXQgbWF0Y2ggaXRzIHJlYWxtLiZuYnNw OyBJdCB0aGVuIE1VU1Qgc3VjY2Vzc2Z1bGx5IHZhbGlkYXRlPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3 MjM1I3NlY3Rpb24tNC40IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzcyMzUjc2VjdGlvbi00LjQ8L2E+IHN1Z2dlc3RzIHRoYXQgaXQgaXMgbm90PGJyPg0K Jmd0OyZndDsmZ3Q7IGV4cGVjdGVkIHRvIGhhdmUgYSBzZXF1ZW5jZSBvciBsaXN0IG9mIFByb3h5 LUF1dGhvcml6YXRpb24gaGVhZGVyIGZpZWxkczxicj4NCiZndDsmZ3Q7Jmd0OyBwcmVzZW50IGlu IGEgc2luZ2xlIHJlcXVlc3QgdGhhdCBhcmUgaW50ZW5kZWQgdG8gYmUgaW50ZXJwcmV0ZWQgYnkg ZGlmZmVyZW50PGJyPg0KJmd0OyZndDsgcHJveGllcy4mbmJzcDsgSXMgdGhpcyB0ZXh0IGNvbXBh dGlibGUgd2l0aCB0aGF0IHBhcnQgb2YgUkZDIDcyMzU/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJG QyAzMjYxIGFsbG93cyBtdWx0aXBsZSBQcm94eS1BdXRob3JpemF0aW9uIGhlYWRlciBmaWVsZHMu PGJyPg0KPGJyPg0KKiBIZXJlIGlzIGEgc2l0dWF0aW9uIHdoZW4gdGhleSBjb21lIGludG8gcGxh eTo8YnI+DQo8YnI+DQpVQUMgLS0tLS0gUDEgLS0tLS0tLSBQMiAtLS0tLS0tIFVBUzxicj4NCjxi cj4NCk9uIHRoZSBmaXJzdCByZXF1ZXN0IGZyb20gVUFDIHRvd2FyZCBVQVMsIFAxIGNoYWxsZW5n ZXMgd2l0aCBhIDxicj4NClByb3h5LUF1dGhlbnRpY2F0ZSBjb250YWluaW5nIHJlYWxtIFAxLjxi cj4NCjxicj4NClVBQyByZXRyaWVzLCBpbmNsdWRpbmcgUHJveHktQXV0aG9yaXphdGlvbiBmb3Ig cmVhbG0gUDEuIFAxIGlzIGhhcHB5IGFuZCA8YnI+DQpwYXNzZXMgdGhlIHJlcXVlc3QgYWxvbmcu IFAyIGNoYWxsZW5nZXMgd2l0aCByZWFsbSBQMi48YnI+DQo8YnI+DQpVQUMgcmV0cmllcyBhZ2Fp bi4gSXQgYWRkcyBQcm94eS1BdXRob3JpemF0aW9uIGZvciByZWFsbSBQMiwgYnV0IGFsc28gPGJy Pg0KaW5jbHVkaW5nIHRoZSBjcmVkZW50aWFscyBmb3IgUDEuIFAxIGlzIGhhcHB5IGFuZCBwYXNz ZXMgdGhlIHJlcXVlc3QgPGJyPg0KYWxvbmcuIFAyIGlzIGFsc28gaGFwcHkgYW5kIHBhc3NlcyB0 aGUgcmVxdWVzdCBhbG9uZyB0byBVQVMuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IFVBQyBtdXN0ICpy ZW1lbWJlciogdG8gaW5jbHVkZSB0aGUgUDEgY3JlZGVudGlhbHMgaW4gdGhlIDxicj4NCnNlY29u ZCByZXRyeSBiZWNhdXNlIHRoZXJlIGlzIG5vIFByb3h5LUF1dGhlbnRpY2F0ZSBmb3IgUDEgaW4g dGhlIDQwNyA8YnI+DQpmcm9tIFAyLiBTaW1pbGFybHksIGluIGZ1dHVyZSBtZXNzYWdlcyB0b3dh cmQgVUFTIHRoZSBVQUMgc2hvdWxkIDxicj4NCnJlbWVtYmVyIHRvIGluY2x1ZGUgY3JlZGVudGlh bHMgZm9yIFAxIGFuZCBQMS48YnI+DQo8YnI+DQoqIEEgbW9yZSBjb21wbGV4IGNhc2UgaXM6PGJy Pg0KPGJyPg0KVUFDIC0tLS0tIFAxIC18LS0tLS0tIFAyIC0tLS0tLSBVQVMtQTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wt LS0tLS0gUDMgLS0tLS0tIFVBUy1CPGJyPg0KPGJyPg0KT24gdGhlIGZpcnN0IHJlcXVlc3QgZnJv bSBVQUMgdG93YXJkIFVBUywgUDEgY2hhbGxlbmdlcyB3aXRoIGEgPGJyPg0KUHJveHktQXV0aGVu dGljYXRlIGNvbnRhaW5pbmcgcmVhbG0gUDEuPGJyPg0KPGJyPg0KVUFDIHJldHJpZXMsIGluY2x1 ZGluZyBQcm94eS1BdXRob3JpemF0aW9uIGZvciByZWFsbSBQMS4gUDEgaXMgaGFwcHkuPGJyPg0K SWYgaXQgZG9lcyBwYXJhbGxlbCBmb3JraW5nIHRoZW4gaXQgcGFzc2VzIHRoZSByZXF1ZXN0IGFs b25nIHRvIGJvdGggUDIgPGJyPg0KYW5kIFAzLjxicj4NCjxicj4NClAyIGNoYWxsZW5nZXMgYnkg cmV0dXJuaW5nIGEgUHJveHktQXV0aGVudGljYXRlIGZvciByZWFsbSBQMi48YnI+DQo8YnI+DQpQ MSBidWZmZXJzIHRoYXQgcmVzcG9uc2Ugd2hpbGUgYXdhaXRpbmcgYSByZXNwb25zZSBmcm9tIFAz Ljxicj4NCjxicj4NClAzIGNoYWxsZW5nZXMgYnkgcmV0dXJuaW5nIGEgUHJveHktQXV0aGVudGlj YXRlIGZvciByZWFsbSBQMy48YnI+DQo8YnI+DQpQMiBwYXNzZXMgYSByZXNwb25zZSBiYWNrIHRv IFVBQyB3aXRoIFByb3h5LUF1dGhlbnRpY2F0ZXMgZm9yIHJlYWxtcyBQMiA8YnI+DQphbmQgUDMu PGJyPg0KPGJyPg0KVUFDIHJldHJpZXMgYWdhaW4uIEl0IGFkZHMgUHJveHktQXV0aG9yaXphdGlv biBmb3IgcmVhbG1zIFAyIGFuZCBQMywgYnV0IDxicj4NCmFsc28gaW5jbHVkaW5nIHRoZSBjcmVk ZW50aWFscyBmb3IgUDEuIFAxIGlzIGhhcHB5IGFuZCBwYXNzZXMgdGhlIDxicj4NCnJlcXVlc3Qg YWxvbmcgdG8gYm90aCBQMiBhbmQgUDMuPGJyPg0KPGJyPg0KUDIgZmluZHMgaXRzIFByb3h5LUF1 dGhvcml6YXRpb24gYW5kIGhhcHBpbHkgcGFzc2VzIHRoZSByZXF1ZXN0IGFsb25nIHRvIDxicj4N ClVBUy1BLjxicj4NCjxicj4NClAzIGZpbmRzIGl0cyBQcm94eS1BdXRob3JpemF0aW9uIGFuZCBo YXBwaWx5IHBhc3NlcyB0aGUgcmVxdWVzdCBhbG9uZyB0byA8YnI+DQpVQVMtQi48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBQYXVsPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2lwY29yZUBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_262816DF8F0943B4BC5F4F0544CFDF80ericssoncom_-- From nobody Sun Apr 26 11:54:08 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809D33A0DF2 for ; Sun, 26 Apr 2020 11:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 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_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 F5W4uCpp3FS4 for ; Sun, 26 Apr 2020 11:54:02 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2041.outbound.protection.outlook.com [40.107.236.41]) (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 71D453A0DF1 for ; Sun, 26 Apr 2020 11:54:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lZSzBFPcprFVOK/mkba+T/3xvt2yaxEGNMoAkcflvp84700AB/hBtpwArmlccCnzUcVwRDRZJ/1w58qs1aOLUe8zj/X4sDJ06O3iGyTStjfBck82vYWmHkk0TqnO0xfSKHO+FPHxIl9OfNfumGDDXCUH08ygWC9eglCgNtN3Z9pMrX/lnUKMHwg75a8QjOYcEa4KeHtVnfaxeZCeMdg86jcE6pMXh3NcBlDz3MGEQAxO72R/8k2Nz0ykwMLiLkEySq2Wqza/tFhtqYyXkgr5bXObHPaAiaCxv26EMrqFNh7Z/4uGDDtORm3DZRxgxXsS4gLu7Dci4PV4zlLLL3MNwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4/ZM4DX5IoXeC4wib51lMDGx3zSM8mIc6QCgFPmiQOw=; b=EuJMUb+unb4HoY7i1vwNeWiDqiFIOkq79TBqIpul28zoFZn9fABdwVYykWvNLIDKAKrqPQ+MQsH5oEFNclbzAJgnSnlaxRxr1CuXtE0kXxsPZX0Qd0p37Lly+zK2OaKAvjqc5Jdpsorf8aIAMRtip0YaTL0cKjRCZnGCqIdMsf0JGrQP0J4Jdzpj+KXowCp8N4hYAI05faV+Ne/BSnV4peI4PC6eJz4T1CAmoHRU0KSRqcUiuItFG8gjg4KJwv7jUev19TgJau7r9lYBfZhqZ+B+K4sJpguK3ew5wO4hGZBr9QDHL1WhEOiMve82fmhyEz/FEFTg9IzPasuR8F4kKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4/ZM4DX5IoXeC4wib51lMDGx3zSM8mIc6QCgFPmiQOw=; b=Qnvw1+19rWl6zPID2xTbd/6eH7kNrDUXAtXV9xhO0LR43MyEduJwOQRyVtP4+4gI65YHWfI0gXNSNKuJmjVRzhBkgIEgMkvjSAhjrJBBsjEgnbGlszDyKEZg1qUhmy60Y7q45rmacl1e9OtAH0x9vbRCcxCRjVuGRUCqL1QvSYs= Received: from SN6PR04CA0107.namprd04.prod.outlook.com (2603:10b6:805:f2::48) by BYAPR12MB2966.namprd12.prod.outlook.com (2603:10b6:a03:df::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sun, 26 Apr 2020 18:54:00 +0000 Received: from SN1NAM02FT015.eop-nam02.prod.protection.outlook.com (2603:10b6:805:f2:cafe::b5) by SN6PR04CA0107.outlook.office365.com (2603:10b6:805:f2::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sun, 26 Apr 2020 18:53:59 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT015.mail.protection.outlook.com (10.152.72.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sun, 26 Apr 2020 18:53:59 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 03QIru0C026433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Apr 2020 14:53:57 -0400 To: Rifaat Shekh-Yusef Cc: SIPCORE References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> From: Paul Kyzivat Message-ID: <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> Date: Sun, 26 Apr 2020 14:53:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(346002)(396003)(39860400002)(376002)(46966005)(8676002)(31696002)(246002)(8936002)(2616005)(4326008)(70586007)(70206006)(75432002)(47076004)(336012)(53546011)(186003)(956004)(31686004)(5660300002)(86362001)(82740400003)(356005)(6916009)(966005)(7596003)(82310400002)(2906002)(26005)(36906005)(478600001)(786003)(316002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 42ee9382-4bd0-4f9f-b90d-08d7ea132df8 X-MS-TrafficTypeDiagnostic: BYAPR12MB2966: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 03853D523D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YNBk+GL7fSV1RB3KOIkPRSbhn8NWQQ+X1GG5lPsAS7HbJnp6f88LsdhFQFBlDgFJ5q3AijViF9zYAAiL5NL4QITVIXIvDauiH1158nlpK2boHeOrbRkMN6voFPSfje40mWi97ot46XVLmZyFfj+VwJ5z+BHY1M6Ze+2ct3X3iyjRWKZMA/pOl9byFU4ASgPzQQa3lwfQuTUyrkrFCzMV+GsGNhYQvJGUEVKqpwyHQrSPQ/E8SaPC8XX0VoZtpRv28EACswEwN4WKUEG3YKCeOd9cRY+haTKXL6+pxizY4bXtH9fTSAppT9czYN2oSG5Y/hdda3g7i2qRM/dRKJXMKveu+oTbfqS2nzmtKGvUvrZoVCddB4BPwtHDDDIRCObQljWcfujL0ph9AvexMwJNIny+edlZu9Qfp1yBwC/chBNVi/L+LveAa52h4jcU7HJGTJ3OKItqGfBeWkCd8jvlGp6qlSC9/4sSjL7+hODWICvBNgq32FxIKw5LNZhSuc2oJ5bdQ5M8ZYJNPtC92hnqsdKcCIls9KUDxHfE1jUYDsL7MQO7lb3Ne7Dmu8RPAwwM//u21jQTJtuPzivnhdpA6g== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2020 18:53:59.0968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 42ee9382-4bd0-4f9f-b90d-08d7ea132df8 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB2966 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 18:54:06 -0000 On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wrote: > Paul, > > What you described is the theory; have you seen this deployed in practice? Its just theory. But the specs should cover all the theoretical cases. Thanks, Paul > Regards, >  Rifaat > > > On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat > wrote: > > On 4/25/20 7:27 PM, Christer Holmberg wrote: > > Hi Benjamin, > > > >>> Section 2.3 states that: > >>> > >>>     When a proxy wishes to authenticate a received request, it MUST > >>>     search the request for Proxy-Authorization header fields > with 'realm' > >>>     parameters that match its realm.  It then MUST successfully > validate > >>> > >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that > it is not > >>> expected to have a sequence or list of Proxy-Authorization > header fields > >>> present in a single request that are intended to be interpreted > by different > >> proxies.  Is this text compatible with that part of RFC 7235? > > > > RFC 3261 allows multiple Proxy-Authorization header fields. > > * Here is a situation when they come into play: > > UAC ----- P1 ------- P2 ------- UAS > > On the first request from UAC toward UAS, P1 challenges with a > Proxy-Authenticate containing realm P1. > > UAC retries, including Proxy-Authorization for realm P1. P1 is happy > and > passes the request along. P2 challenges with realm P2. > > UAC retries again. It adds Proxy-Authorization for realm P2, but also > including the credentials for P1. P1 is happy and passes the request > along. P2 is also happy and passes the request along to UAS. > > Note that UAC must *remember* to include the P1 credentials in the > second retry because there is no Proxy-Authenticate for P1 in the 407 > from P2. Similarly, in future messages toward UAS the UAC should > remember to include credentials for P1 and P1. > > * A more complex case is: > > UAC ----- P1 -|------ P2 ------ UAS-A >                | >                |------ P3 ------ UAS-B > > On the first request from UAC toward UAS, P1 challenges with a > Proxy-Authenticate containing realm P1. > > UAC retries, including Proxy-Authorization for realm P1. P1 is happy. > If it does parallel forking then it passes the request along to both P2 > and P3. > > P2 challenges by returning a Proxy-Authenticate for realm P2. > > P1 buffers that response while awaiting a response from P3. > > P3 challenges by returning a Proxy-Authenticate for realm P3. > > P2 passes a response back to UAC with Proxy-Authenticates for realms P2 > and P3. > > UAC retries again. It adds Proxy-Authorization for realms P2 and P3, > but > also including the credentials for P1. P1 is happy and passes the > request along to both P2 and P3. > > P2 finds its Proxy-Authorization and happily passes the request > along to > UAS-A. > > P3 finds its Proxy-Authorization and happily passes the request > along to > UAS-B. > >         Thanks, >         Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sun Apr 26 12:22:22 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFCF3A0EF5 for ; Sun, 26 Apr 2020 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee5sm-yXGW9Y for ; Sun, 26 Apr 2020 12:22:18 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 D536A3A0EEC for ; Sun, 26 Apr 2020 12:22:17 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id e8so14665996ilm.7 for ; Sun, 26 Apr 2020 12:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+mhOIIM/DLY7SS2DKMHR7Um4hGxP1QkZHNDYgjF6zgA=; b=VUqpT5D6HkZyOIPo1hPEAJf3B5qvyMF0+PBZeLIhY3djSrIXYqI6lEPIgh1jfY+ob5 VznIT9mwxBSokZ5Mi7GoNa6ciU5vKYvjbBFCNcypOlLfivc7xj3uXMAC9MxK/ab5XLOv 8qZxQO8fsfAsK97IZYX49qWQUucL3Xy84tOtdQCDsV3T0d21S52jByOH+eDIOCJ3vO7e H1qiOmR3KJmstkqTf5xD+7wjM9Hs6n4T7nLMD8iozwkbFlpIgKPHwyN8MR3kqrIaMDw1 EjQSPSbaxBuu5ILj3AmDJdp1VSyP9aCTghs+WoeRalZhjgGbaLfEoNRif/+muMBAnt2p N+0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+mhOIIM/DLY7SS2DKMHR7Um4hGxP1QkZHNDYgjF6zgA=; b=mSWmIQaEHvpHXYH4cHBD4CdVu/BdSwlpYg5WlNsTNX0uhYcahTYb6VrbJ4xHenhMae jxKvy0DKw7/qZpnrSO2N+xukhSj8lwsVH1py0AZ6Hs/9FC8SABfNm0QGhrtg2stHSKwM rg59ZL6xAbkfk/t/zZhZl5SKUFXQOlEaL//2nvXE7uDVhziCPRaRZDLKJnwUL+a3IxEV vXsq2ow5QrAXkXOnyhbkLhb7grt00JbJ6VMO3e1u0qXZSck9ibF3TLyeWth/lSYEnU86 m+UgN1CzupZhn6Okkksf/zN1uI8SsGcgfSgT8f0XjYgK58CjbuiUKL7yNTe3m1xbQ825 2BXg== X-Gm-Message-State: AGi0PuZyij8fIUK2Jl9vcBovO4cGENfsgoXIb8WYFwJwiHUO7USusLF7 NyEgWQ/kO1vZgxsJYJHrn+8pI1qYoh+yd6bBz7g= X-Google-Smtp-Source: APiQypKPq4pTNvCFlZ1QZsLXD3lIEhsd3JOzVtu3Ou/f9R3vLZZos/ZYzgQjUgUbKvs8xSwNfBtlIOkuD69jaP0KUjI= X-Received: by 2002:a05:6e02:cc4:: with SMTP id c4mr17460085ilj.31.1587928936975; Sun, 26 Apr 2020 12:22:16 -0700 (PDT) MIME-Version: 1.0 References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> In-Reply-To: <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> From: Rifaat Shekh-Yusef Date: Sun, 26 Apr 2020 15:22:07 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000003793a805a43684c3" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 19:22:21 -0000 --0000000000003793a805a43684c3 Content-Type: text/plain; charset="UTF-8" Why should we do that? Why can't we just acknowledge that this was a nice idea in theory that never materialized in practice because they was never a need for it? Why can't this document explicitly state that this theoretical case is *not *cover and move on to do something more useful that people actually care about? Regards, Rifaat On Sun, Apr 26, 2020 at 2:54 PM Paul Kyzivat wrote: > On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wrote: > > Paul, > > > > What you described is the theory; have you seen this deployed in > practice? > > Its just theory. But the specs should cover all the theoretical cases. > > Thanks, > Paul > > > Regards, > > Rifaat > > > > > > On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat > > wrote: > > > > On 4/25/20 7:27 PM, Christer Holmberg wrote: > > > Hi Benjamin, > > > > > >>> Section 2.3 states that: > > >>> > > >>> When a proxy wishes to authenticate a received request, it > MUST > > >>> search the request for Proxy-Authorization header fields > > with 'realm' > > >>> parameters that match its realm. It then MUST successfully > > validate > > >>> > > >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that > > it is not > > >>> expected to have a sequence or list of Proxy-Authorization > > header fields > > >>> present in a single request that are intended to be interpreted > > by different > > >> proxies. Is this text compatible with that part of RFC 7235? > > > > > > RFC 3261 allows multiple Proxy-Authorization header fields. > > > > * Here is a situation when they come into play: > > > > UAC ----- P1 ------- P2 ------- UAS > > > > On the first request from UAC toward UAS, P1 challenges with a > > Proxy-Authenticate containing realm P1. > > > > UAC retries, including Proxy-Authorization for realm P1. P1 is happy > > and > > passes the request along. P2 challenges with realm P2. > > > > UAC retries again. It adds Proxy-Authorization for realm P2, but also > > including the credentials for P1. P1 is happy and passes the request > > along. P2 is also happy and passes the request along to UAS. > > > > Note that UAC must *remember* to include the P1 credentials in the > > second retry because there is no Proxy-Authenticate for P1 in the 407 > > from P2. Similarly, in future messages toward UAS the UAC should > > remember to include credentials for P1 and P1. > > > > * A more complex case is: > > > > UAC ----- P1 -|------ P2 ------ UAS-A > > | > > |------ P3 ------ UAS-B > > > > On the first request from UAC toward UAS, P1 challenges with a > > Proxy-Authenticate containing realm P1. > > > > UAC retries, including Proxy-Authorization for realm P1. P1 is happy. > > If it does parallel forking then it passes the request along to both > P2 > > and P3. > > > > P2 challenges by returning a Proxy-Authenticate for realm P2. > > > > P1 buffers that response while awaiting a response from P3. > > > > P3 challenges by returning a Proxy-Authenticate for realm P3. > > > > P2 passes a response back to UAC with Proxy-Authenticates for realms > P2 > > and P3. > > > > UAC retries again. It adds Proxy-Authorization for realms P2 and P3, > > but > > also including the credentials for P1. P1 is happy and passes the > > request along to both P2 and P3. > > > > P2 finds its Proxy-Authorization and happily passes the request > > along to > > UAS-A. > > > > P3 finds its Proxy-Authorization and happily passes the request > > along to > > UAS-B. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > --0000000000003793a805a43684c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why should we do that?
Why can't we just acknowled= ge that this was a nice idea in theory that never materialized in practice = because they was never a need for it?
Why can't this document= explicitly state that this theoretical=C2=A0case is not cover and m= ove on to do something more useful that people actually care about?

Regards,
=C2=A0Rifaat


On Su= n, Apr 26, 2020 at 2:54 PM Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wr= ote:
> Paul,
>
> What you described is the theory; have you seen this deployed in pract= ice?

Its just theory. But the specs should cover all the theoretical cases.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
> On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:= pkyzivat@alum.mit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 4/25/20 7:27 PM, Christer Holmberg wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Benjamin,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>> Section 2.3 states that:
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0When a proxy wishe= s to authenticate a received request, it MUST
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0search the request= for Proxy-Authorization header fields
>=C2=A0 =C2=A0 =C2=A0with 'realm'
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0parameters that ma= tch its realm.=C2=A0 It then MUST successfully
>=C2=A0 =C2=A0 =C2=A0validate
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> https://tools.i= etf.org/html/rfc7235#section-4.4 suggests that
>=C2=A0 =C2=A0 =C2=A0it is not
>=C2=A0 =C2=A0 =C2=A0 >>> expected to have a sequence or list o= f Proxy-Authorization
>=C2=A0 =C2=A0 =C2=A0header fields
>=C2=A0 =C2=A0 =C2=A0 >>> present in a single request that are = intended to be interpreted
>=C2=A0 =C2=A0 =C2=A0by different
>=C2=A0 =C2=A0 =C2=A0 >> proxies.=C2=A0 Is this text compatible wi= th that part of RFC 7235?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > RFC 3261 allows multiple Proxy-Authorization = header fields.
>
>=C2=A0 =C2=A0 =C2=A0* Here is a situation when they come into play:
>
>=C2=A0 =C2=A0 =C2=A0UAC ----- P1 ------- P2 ------- UAS
>
>=C2=A0 =C2=A0 =C2=A0On the first request from UAC toward UAS, P1 challe= nges with a
>=C2=A0 =C2=A0 =C2=A0Proxy-Authenticate containing realm P1.
>
>=C2=A0 =C2=A0 =C2=A0UAC retries, including Proxy-Authorization for real= m P1. P1 is happy
>=C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0passes the request along. P2 challenges with realm = P2.
>
>=C2=A0 =C2=A0 =C2=A0UAC retries again. It adds Proxy-Authorization for = realm P2, but also
>=C2=A0 =C2=A0 =C2=A0including the credentials for P1. P1 is happy and p= asses the request
>=C2=A0 =C2=A0 =C2=A0along. P2 is also happy and passes the request alon= g to UAS.
>
>=C2=A0 =C2=A0 =C2=A0Note that UAC must *remember* to include the P1 cre= dentials in the
>=C2=A0 =C2=A0 =C2=A0second retry because there is no Proxy-Authenticate= for P1 in the 407
>=C2=A0 =C2=A0 =C2=A0from P2. Similarly, in future messages toward UAS t= he UAC should
>=C2=A0 =C2=A0 =C2=A0remember to include credentials for P1 and P1.
>
>=C2=A0 =C2=A0 =C2=A0* A more complex case is:
>
>=C2=A0 =C2=A0 =C2=A0UAC ----- P1 -|------ P2 ------ UAS-A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|------ P3 ------ UAS-B
>
>=C2=A0 =C2=A0 =C2=A0On the first request from UAC toward UAS, P1 challe= nges with a
>=C2=A0 =C2=A0 =C2=A0Proxy-Authenticate containing realm P1.
>
>=C2=A0 =C2=A0 =C2=A0UAC retries, including Proxy-Authorization for real= m P1. P1 is happy.
>=C2=A0 =C2=A0 =C2=A0If it does parallel forking then it passes the requ= est along to both P2
>=C2=A0 =C2=A0 =C2=A0and P3.
>
>=C2=A0 =C2=A0 =C2=A0P2 challenges by returning a Proxy-Authenticate for= realm P2.
>
>=C2=A0 =C2=A0 =C2=A0P1 buffers that response while awaiting a response = from P3.
>
>=C2=A0 =C2=A0 =C2=A0P3 challenges by returning a Proxy-Authenticate for= realm P3.
>
>=C2=A0 =C2=A0 =C2=A0P2 passes a response back to UAC with Proxy-Authent= icates for realms P2
>=C2=A0 =C2=A0 =C2=A0and P3.
>
>=C2=A0 =C2=A0 =C2=A0UAC retries again. It adds Proxy-Authorization for = realms P2 and P3,
>=C2=A0 =C2=A0 =C2=A0but
>=C2=A0 =C2=A0 =C2=A0also including the credentials for P1. P1 is happy = and passes the
>=C2=A0 =C2=A0 =C2=A0request along to both P2 and P3.
>
>=C2=A0 =C2=A0 =C2=A0P2 finds its Proxy-Authorization and happily passes= the request
>=C2=A0 =C2=A0 =C2=A0along to
>=C2=A0 =C2=A0 =C2=A0UAS-A.
>
>=C2=A0 =C2=A0 =C2=A0P3 finds its Proxy-Authorization and happily passes= the request
>=C2=A0 =C2=A0 =C2=A0along to
>=C2=A0 =C2=A0 =C2=A0UAS-B.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/sipcore
>

--0000000000003793a805a43684c3-- From nobody Sun Apr 26 12:31:03 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543E13A0F34 for ; Sun, 26 Apr 2020 12:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 mtNMJ-bXSTqI for ; Sun, 26 Apr 2020 12:30:59 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2071.outbound.protection.outlook.com [40.107.21.71]) (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 AE20D3A0F32 for ; Sun, 26 Apr 2020 12:30:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CJHkXquYKYmKOyYmHAo4JZoOn11slA45BEmBXO4ag5NWO+LlV9AQbEs4q6D5fM7QRfkX/8xijBmzsS+U6sZoychIK32ci5mkeZLW6nAkQo4Ztmxtjx6RYr1Z1hFkjH8eMeuHUE49nJdIV5l58QMwh81Ro5IMU8w4l3Ex1knfc97dd4G99f/tFvlIvnocgq1txAdYUuJlYIn8kdtFvK2mJ9IyM7a4/I2mRk2bkiMczEmo/eIO4+4/4aDntL7fddw+k/chsagP+jngxX6mn3fcxq27yr7oboqILDMl845cGFVJhogAqx+00MlwCr8e1bKhSebaGrYL3mSSp25KQioSoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rm1iJOmi1FQYGv9pLAuORb5E2ymmW7Rhg6ZUCq8x+90=; b=kylcirGVeaDYktO8IBlO/grwO9gxYxzP1caIxKdffaY1FwqWkUvg/y3KVD0Q1w9u58aqW3E9rehNxazPUhb+/PVDV7i9JarzLA0epKs59T/qt+yoCdwKPbZsVsXOLYIHvdTJSgzheDzWMHxeLTcRp+sFC95zTZvpa5DJ+fhKHcNk4aEMtr8kBa10NvpueRztpPQJdPwhV3j3FbBq8jSZIpYjrAA52QAS26izKhBJvLZR1CUuFAv6XG5MaTIz9escJh1zg+QvheGuS5pkq7Dsvn633TG+Zrppb7RH6p2BAO4lSaaGDfidt8vVSTi1EUHeaTI5joX336qpfbqTO+UWhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rm1iJOmi1FQYGv9pLAuORb5E2ymmW7Rhg6ZUCq8x+90=; b=E6EsCCYM5wNZhnzSQ/jIBz+kMDoI/JESdvh6a+eXJTk/4dqEC3a5eQc7r0i0PqWebqbEPCZgNQMZuzFuYZbjMQqBOMMAobDF9lW1bNUQrEuRdZW3OuACoTxV59z5g5LlQ2BbHqYuTZ8imBId5Kcj93Ah/PAQvqD89ckE2aupXdA= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6359.eurprd07.prod.outlook.com (2603:10a6:20b:139::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Sun, 26 Apr 2020 19:30:56 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Sun, 26 Apr 2020 19:30:56 +0000 From: Christer Holmberg To: Paul Kyzivat , Rifaat Shekh-Yusef CC: SIPCORE Thread-Topic: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply Thread-Index: AQHWGwEtfH/bpP2YLUqlNdqU6ZLbLaiKrnoAgADJdACAABkjAIAAMP8AgAA8oIA= Date: Sun, 26 Apr 2020 19:30:56 +0000 Message-ID: <1D4811E5-A977-4126-AE88-B934BAFA1418@ericsson.com> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> In-Reply-To: <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6c4e73ae-a53d-424d-aceb-08d7ea18576d x-ms-traffictypediagnostic: AM7PR07MB6359: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03853D523D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(396003)(346002)(136003)(366004)(316002)(8676002)(6486002)(71200400001)(86362001)(6512007)(2616005)(64756008)(91956017)(76116006)(8936002)(66556008)(66476007)(4326008)(66946007)(81156014)(66446008)(478600001)(966005)(44832011)(186003)(53546011)(26005)(2906002)(5660300002)(36756003)(110136005)(33656002)(6506007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6/ae5B1oTrpgY7E0vGrv6Jik9gWJo5L5zALaor2g3bqeDh2lXAVFBHOZ1Uc3DGsRgGPwbYUKeNg668M60mauaewj2vj0pGYOWDH/CPdWjp04R98PJJyyWRYNlL04sH2lWXTObQ1cGrLXFmIPLwk+4atTrqARtUB+5bek3dZYM5lRztNEVEJAZIMseifra9l1XGV6wM//t4KY8bvYCrwTivoDIAyoknI7PkgXcMPOfsgOj5t7ZyMeZh+OfFVjGgHLj3En6w95FGmdGuARiln5L3lAIhvU+VDyc8xv8EW0v+RBHjJFlzxy5107qwh2I8ud7zjEOezCGiUlnLgkE1lQ1LD64Ek+FnFbOsjmyMzKoy+dQwmGqxYkKYBt5Yv4cmZEIVQViOZDqnUwcEq/06BSXId41Z7Jvq+pCGIFsGVDWZ+BzsqHJKAClNBzLDxwlY875DpOWYQT2g7vnNV5qlQLOb8n19NGr4hkATJTtrIc1BAt4/s04J0hx3SJc6ES75zlop0+YtGZIHbKRQwkG0OJaQ== x-ms-exchange-antispam-messagedata: 0CqSKyy59GC/vIrk7ZYJWdgLYnCSueYw21q2vyJIL3fHJVj1A3P3m8lEyDtNCancypWg9gdHGvWar7V/SA9tm6qWicOhb7kO1uKoKWWKU5oZfyQRXoXPUXc0vjTdKJ8AlF7QUoy1wtwI9huVC2FnfvluqR+VNX0r18+ShmXJELev3wtJ3qXQ2pf6Oe6YBJIAdee8m92ns/aqpv+nf2mykYl6fm+Bu3/vrHrzLvZ4Ss7oOiV+5y6uYXJF8wspU9UZTaaO0FMLR+dUusuKhFUCMJpYe6pKyFt8eEpJl2eGM0/m12mH62w+t63PAEMqjJalvwgez0HQ4+Rc7t+0sAGSWFpRDpaFROPBgNWSoPJ+/a3ZUac3srg+zETlunZzQ4dEjD8UaarUYwKJKtrD7Ps0ieHcj8irXmLx4p4z/rvsoT2mD/hmHTcZBSbS3TFgoXke8+x+fnij2WaDU3iiBhWNq6qqEnsC+IsFOMema/EmOz35u7lCWl+3RysoJJN1RMsjz+UQZcDXOCQkTon+2n+jJxsYRhE4/9BQ3McC0MGbYXsYmnZ8tcJkaRkeXz8uHPgfZkzAMBjJuti//iLxOWwoeeWjQT6VT9F3ub4SnoUsW2wPLfR6QrUgkbterCLrQQyDJewV/w6Tl/GOOTxJ9Xw3NDKxnMBokKtAYGajqFflC5/k9dgssXZZG5xWM5NHs5orVcpJzLj14fk6DbmLMcfbOfNYJw67HznqXA6wNc9u4/5bk6bRO/+VJvN6HFeCHLK0qougJLVd4ac3x/oNQK37ca1RXND1UFCCWytKmAwtrE8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c4e73ae-a53d-424d-aceb-08d7ea18576d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2020 19:30:56.2149 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8MatkR/Y482fVEqaFZuQFo8tgB0j5lluBZ8ERGvJNZnBtW1wE/39bWQkp28/bc2acH0bVb/O8yDqKSmvd2ItXKioHIBYQmoDaKfRZ27etiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6359 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 19:31:02 -0000 UGF1bCwNCiANCj4+IFdoYXQgeW91IGRlc2NyaWJlZCBpcyB0aGUgdGhlb3J5OyBoYXZlIHlvdSBz ZWVuIHRoaXMgZGVwbG95ZWQgaW4gcHJhY3RpY2U/DQo+ICANCj4gSXRzIGp1c3QgdGhlb3J5LiBC dXQgdGhlIHNwZWNzIHNob3VsZCBjb3ZlciBhbGwgdGhlIHRoZW9yZXRpY2FsIGNhc2VzLg0KICAg DQpBRkFJSywgd2hhdCB5b3UgZXhwbGFpbmVkIGluIGdlbmVyaWMgU0lQLCBhbmQgbm90IHNwZWNp ZmljIHRvIHRoaXMgZHJhZnQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQogICAgPiBP biBTdW4sIEFwciAyNiwgMjAyMCBhdCAxMDoyOCBBTSBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFs dW0ubWl0LmVkdSANCiAgICA+IDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6 DQogICAgPiANCiAgICA+ICAgICBPbiA0LzI1LzIwIDc6MjcgUE0sIENocmlzdGVyIEhvbG1iZXJn IHdyb3RlOg0KICAgID4gICAgICA+IEhpIEJlbmphbWluLA0KICAgID4gICAgICA+DQogICAgPiAg ICAgID4+PiBTZWN0aW9uIDIuMyBzdGF0ZXMgdGhhdDoNCiAgICA+ICAgICAgPj4+DQogICAgPiAg ICAgID4+PiAgICAgV2hlbiBhIHByb3h5IHdpc2hlcyB0byBhdXRoZW50aWNhdGUgYSByZWNlaXZl ZCByZXF1ZXN0LCBpdCBNVVNUDQogICAgPiAgICAgID4+PiAgICAgc2VhcmNoIHRoZSByZXF1ZXN0 IGZvciBQcm94eS1BdXRob3JpemF0aW9uIGhlYWRlciBmaWVsZHMNCiAgICA+ICAgICB3aXRoICdy ZWFsbScNCiAgICA+ICAgICAgPj4+ICAgICBwYXJhbWV0ZXJzIHRoYXQgbWF0Y2ggaXRzIHJlYWxt LiAgSXQgdGhlbiBNVVNUIHN1Y2Nlc3NmdWxseQ0KICAgID4gICAgIHZhbGlkYXRlDQogICAgPiAg ICAgID4+Pg0KICAgID4gICAgICA+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcy MzUjc2VjdGlvbi00LjQgc3VnZ2VzdHMgdGhhdA0KICAgID4gICAgIGl0IGlzIG5vdA0KICAgID4g ICAgICA+Pj4gZXhwZWN0ZWQgdG8gaGF2ZSBhIHNlcXVlbmNlIG9yIGxpc3Qgb2YgUHJveHktQXV0 aG9yaXphdGlvbg0KICAgID4gICAgIGhlYWRlciBmaWVsZHMNCiAgICA+ICAgICAgPj4+IHByZXNl bnQgaW4gYSBzaW5nbGUgcmVxdWVzdCB0aGF0IGFyZSBpbnRlbmRlZCB0byBiZSBpbnRlcnByZXRl ZA0KICAgID4gICAgIGJ5IGRpZmZlcmVudA0KICAgID4gICAgICA+PiBwcm94aWVzLiAgSXMgdGhp cyB0ZXh0IGNvbXBhdGlibGUgd2l0aCB0aGF0IHBhcnQgb2YgUkZDIDcyMzU/DQogICAgPiAgICAg ID4NCiAgICA+ICAgICAgPiBSRkMgMzI2MSBhbGxvd3MgbXVsdGlwbGUgUHJveHktQXV0aG9yaXph dGlvbiBoZWFkZXIgZmllbGRzLg0KICAgID4gDQogICAgPiAgICAgKiBIZXJlIGlzIGEgc2l0dWF0 aW9uIHdoZW4gdGhleSBjb21lIGludG8gcGxheToNCiAgICA+IA0KICAgID4gICAgIFVBQyAtLS0t LSBQMSAtLS0tLS0tIFAyIC0tLS0tLS0gVUFTDQogICAgPiANCiAgICA+ICAgICBPbiB0aGUgZmly c3QgcmVxdWVzdCBmcm9tIFVBQyB0b3dhcmQgVUFTLCBQMSBjaGFsbGVuZ2VzIHdpdGggYQ0KICAg ID4gICAgIFByb3h5LUF1dGhlbnRpY2F0ZSBjb250YWluaW5nIHJlYWxtIFAxLg0KICAgID4gDQog ICAgPiAgICAgVUFDIHJldHJpZXMsIGluY2x1ZGluZyBQcm94eS1BdXRob3JpemF0aW9uIGZvciBy ZWFsbSBQMS4gUDEgaXMgaGFwcHkNCiAgICA+ICAgICBhbmQNCiAgICA+ICAgICBwYXNzZXMgdGhl IHJlcXVlc3QgYWxvbmcuIFAyIGNoYWxsZW5nZXMgd2l0aCByZWFsbSBQMi4NCiAgICA+IA0KICAg ID4gICAgIFVBQyByZXRyaWVzIGFnYWluLiBJdCBhZGRzIFByb3h5LUF1dGhvcml6YXRpb24gZm9y IHJlYWxtIFAyLCBidXQgYWxzbw0KICAgID4gICAgIGluY2x1ZGluZyB0aGUgY3JlZGVudGlhbHMg Zm9yIFAxLiBQMSBpcyBoYXBweSBhbmQgcGFzc2VzIHRoZSByZXF1ZXN0DQogICAgPiAgICAgYWxv bmcuIFAyIGlzIGFsc28gaGFwcHkgYW5kIHBhc3NlcyB0aGUgcmVxdWVzdCBhbG9uZyB0byBVQVMu DQogICAgPiANCiAgICA+ICAgICBOb3RlIHRoYXQgVUFDIG11c3QgKnJlbWVtYmVyKiB0byBpbmNs dWRlIHRoZSBQMSBjcmVkZW50aWFscyBpbiB0aGUNCiAgICA+ICAgICBzZWNvbmQgcmV0cnkgYmVj YXVzZSB0aGVyZSBpcyBubyBQcm94eS1BdXRoZW50aWNhdGUgZm9yIFAxIGluIHRoZSA0MDcNCiAg ICA+ICAgICBmcm9tIFAyLiBTaW1pbGFybHksIGluIGZ1dHVyZSBtZXNzYWdlcyB0b3dhcmQgVUFT IHRoZSBVQUMgc2hvdWxkDQogICAgPiAgICAgcmVtZW1iZXIgdG8gaW5jbHVkZSBjcmVkZW50aWFs cyBmb3IgUDEgYW5kIFAxLg0KICAgID4gDQogICAgPiAgICAgKiBBIG1vcmUgY29tcGxleCBjYXNl IGlzOg0KICAgID4gDQogICAgPiAgICAgVUFDIC0tLS0tIFAxIC18LS0tLS0tIFAyIC0tLS0tLSBV QVMtQQ0KICAgID4gICAgICAgICAgICAgICAgICAgICB8DQogICAgPiAgICAgICAgICAgICAgICAg ICAgIHwtLS0tLS0gUDMgLS0tLS0tIFVBUy1CDQogICAgPiANCiAgICA+ICAgICBPbiB0aGUgZmly c3QgcmVxdWVzdCBmcm9tIFVBQyB0b3dhcmQgVUFTLCBQMSBjaGFsbGVuZ2VzIHdpdGggYQ0KICAg ID4gICAgIFByb3h5LUF1dGhlbnRpY2F0ZSBjb250YWluaW5nIHJlYWxtIFAxLg0KICAgID4gDQog ICAgPiAgICAgVUFDIHJldHJpZXMsIGluY2x1ZGluZyBQcm94eS1BdXRob3JpemF0aW9uIGZvciBy ZWFsbSBQMS4gUDEgaXMgaGFwcHkuDQogICAgPiAgICAgSWYgaXQgZG9lcyBwYXJhbGxlbCBmb3Jr aW5nIHRoZW4gaXQgcGFzc2VzIHRoZSByZXF1ZXN0IGFsb25nIHRvIGJvdGggUDINCiAgICA+ICAg ICBhbmQgUDMuDQogICAgPiANCiAgICA+ICAgICBQMiBjaGFsbGVuZ2VzIGJ5IHJldHVybmluZyBh IFByb3h5LUF1dGhlbnRpY2F0ZSBmb3IgcmVhbG0gUDIuDQogICAgPiANCiAgICA+ICAgICBQMSBi dWZmZXJzIHRoYXQgcmVzcG9uc2Ugd2hpbGUgYXdhaXRpbmcgYSByZXNwb25zZSBmcm9tIFAzLg0K ICAgID4gDQogICAgPiAgICAgUDMgY2hhbGxlbmdlcyBieSByZXR1cm5pbmcgYSBQcm94eS1BdXRo ZW50aWNhdGUgZm9yIHJlYWxtIFAzLg0KICAgID4gDQogICAgPiAgICAgUDIgcGFzc2VzIGEgcmVz cG9uc2UgYmFjayB0byBVQUMgd2l0aCBQcm94eS1BdXRoZW50aWNhdGVzIGZvciByZWFsbXMgUDIN CiAgICA+ICAgICBhbmQgUDMuDQogICAgPiANCiAgICA+ICAgICBVQUMgcmV0cmllcyBhZ2Fpbi4g SXQgYWRkcyBQcm94eS1BdXRob3JpemF0aW9uIGZvciByZWFsbXMgUDIgYW5kIFAzLA0KICAgID4g ICAgIGJ1dA0KICAgID4gICAgIGFsc28gaW5jbHVkaW5nIHRoZSBjcmVkZW50aWFscyBmb3IgUDEu IFAxIGlzIGhhcHB5IGFuZCBwYXNzZXMgdGhlDQogICAgPiAgICAgcmVxdWVzdCBhbG9uZyB0byBi b3RoIFAyIGFuZCBQMy4NCiAgICA+IA0KICAgID4gICAgIFAyIGZpbmRzIGl0cyBQcm94eS1BdXRo b3JpemF0aW9uIGFuZCBoYXBwaWx5IHBhc3NlcyB0aGUgcmVxdWVzdA0KICAgID4gICAgIGFsb25n IHRvDQogICAgPiAgICAgVUFTLUEuDQogICAgPiANCiAgICA+ICAgICBQMyBmaW5kcyBpdHMgUHJv eHktQXV0aG9yaXphdGlvbiBhbmQgaGFwcGlseSBwYXNzZXMgdGhlIHJlcXVlc3QNCiAgICA+ICAg ICBhbG9uZyB0bw0KICAgID4gICAgIFVBUy1CLg0KICAgID4gDQogICAgPiAgICAgICAgICAgICAg VGhhbmtzLA0KICAgID4gICAgICAgICAgICAgIFBhdWwNCiAgICA+IA0KICAgID4gICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgc2lw Y29yZSBtYWlsaW5nIGxpc3QNCiAgICA+ICAgICBzaXBjb3JlQGlldGYub3JnIDxtYWlsdG86c2lw Y29yZUBpZXRmLm9yZz4NCiAgICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCiAgICA+IA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICBz aXBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQogICAgDQoNCg== From nobody Sun Apr 26 12:44:09 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC3B3A0FE3 for ; Sun, 26 Apr 2020 12:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 wzDuFrJqtvzV for ; Sun, 26 Apr 2020 12:43:32 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2078.outbound.protection.outlook.com [40.107.236.78]) (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 953D93A0FE7 for ; Sun, 26 Apr 2020 12:43:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nBgZSS6wnuyyvO+AiTJ2RyVdQYT8SHRPrIqu9esZ5okbiytsOCDIDus36xF4RyqnqPjJ21OfOChK8gIwQhEY1pFP1eB2v2VNUp/4HlnnV+sRq11+Y2b30UdsrUxnGg3QTA1ugIkQmxvmYEM4s3buU7Giq0a9ZP50QBkjj+aN0pOBfCSuz+Rl5pKYeENj5ADUYha9tqvE/w5DMzv5PniKEBmjdr3W3AutpSY9VFTFdk0MuX+sfOjPCPZSREnOzoJzh8ayg6cJeFF6tGKFyXB4gWBlkaHvdk9tfkrN10UzQPkgX+luwahqQtkJnjHkQlKOj9rIMv+pdLRqMsfAdorkiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F78vhpYSilQRdEpg9LBmKwKmWFmjwLSRDLmaP7jVcfU=; b=PnTX5EGVZtSQau5/vn0nfscG6T8By6MK5c19KCtsx1pTGyg7RUcxYDx9H9QELQEY8FPnXdsBkpdml8Ul+Ch7YGZ18hVcsW26l6lJ03bENO3d8lzwRoGYGbTCo6x3375oB9PElrR7l3+kRlNPuCj8tbeSJwHSGH9gZDL6dwO4s8SKmzZhBd2AwjKIUyf0rvBrKmoN8P2GN07r0t7lwC+EVKYNOfxlcUrLj0k3+TdlVcxk6w06brgXZNAYpv2G8t/ac6HRS2Lw1YOp6u8RseWF1JBRXfyL1qouoMnPbleXFegKwkkgl4qByVHMi5FMYRJtGNy5jzUTVUl64pPi50HRIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F78vhpYSilQRdEpg9LBmKwKmWFmjwLSRDLmaP7jVcfU=; b=glUI2mvCKXvAiZAzcBdoH84Hod9SN8+AA+68pGXDb6HpO1nJg8fleBLPR32syluMYC3T2hBs/XeL+M8HR9Cvw/XVjXxMBlH/vQYJTvS0sToUSI3uYLJYeVSW/F5m7PfkyxznF5Ihc1+ii4ZhOAGY3jYQHPzqlr0D3GE/tqLnwEk= Received: from SN2PR01CA0062.prod.exchangelabs.com (2603:10b6:800::30) by MN2PR12MB3390.namprd12.prod.outlook.com (2603:10b6:208:c9::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sun, 26 Apr 2020 19:43:30 +0000 Received: from SN1NAM02FT052.eop-nam02.prod.protection.outlook.com (2603:10b6:800:0:cafe::38) by SN2PR01CA0062.outlook.office365.com (2603:10b6:800::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sun, 26 Apr 2020 19:43:30 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT052.mail.protection.outlook.com (10.152.72.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sun, 26 Apr 2020 19:43:29 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 03QJhRPd030160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Apr 2020 15:43:28 -0400 To: Rifaat Shekh-Yusef Cc: SIPCORE References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Sun, 26 Apr 2020 15:43:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(376002)(136003)(346002)(39860400002)(396003)(46966005)(7596003)(246002)(8936002)(8676002)(31686004)(82310400002)(26005)(5660300002)(2616005)(956004)(53546011)(70586007)(36906005)(316002)(786003)(70206006)(356005)(4326008)(186003)(2906002)(336012)(966005)(478600001)(82740400003)(75432002)(86362001)(6916009)(31696002)(47076004); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6a430bf8-5452-48f5-38e9-08d7ea1a18bf X-MS-TrafficTypeDiagnostic: MN2PR12MB3390: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 03853D523D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KzDc42shf1LF6DiSaspi9IbTdjQ4B1T2uGDIRtFjKnxuKoUxbAw99VP/lKVLkTFoL7nFECGDnCDfWniuw1rSLLnfC7dfI51BC4Qfxv5+Wb02OWTWfy50UaClnNY5+9RX9nPAcawd0Ph5QO+lYvfrITZEjZh0Cye76XlGTYLGDV4g8Lm/MmACbRZA8hBSbD/FZwlDOGvl2lGQ+hQKibIubfTufmtucJ/oFCBENf8Zc5+aWM4UcJTcqba4f4Xc+tU9nJzhZ1H9gxAd/qfST7w+ryGmrY1lmIxIYNNP4pCRKWNiaNZQcZM2AE9xGC/2G6kJ2OqV1hvBaFnmuveT4DoQytle8j5ykdCJVBJ2W2nwZKVuCPr7NfnYdkdV4Uwm8t9KMsUygDVd7e0Wm4fosARFIrTdYrt8wsgVf2bXmUlsyxQYr0y2r9xcosnfg3g8UphbkXFVgWMH+xEW0sTKgKyHqXw2jTh1JvUwpIPK7vcywCby6k+eC9Tt7+LtW1FPobG4FNVAzoxoyRacNQay3E1Hp2DxZifJrUZrL11FOUqN+LwKYlTcn/y0z1zK25gSsGvN2wfOB/LNrABN3YzLyeDymQ== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2020 19:43:29.8760 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6a430bf8-5452-48f5-38e9-08d7ea1a18bf X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3390 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 19:43:40 -0000 On 4/26/20 3:22 PM, Rifaat Shekh-Yusef wrote: > Why should we do that? > Why can't we just acknowledge that this was a nice idea in theory that > never materialized in practice because they was never a need for it? > Why can't this document explicitly state that this theoretical case is > *not *cover and move on to do something more useful that people actually > care about? I didn't say what we should do about it. I was just explaining the use case. I generally agree that this document isn't the place to discuss such cases. (Especially since the case I describe doesn't even involve multiple schemes, and is scheme independent, so it is nothing that this document impacts.) This is something that is implicit in 3261, and something that implementors ought to support as a matter of course. Somebody can argue that it isn't used and so shouldn't have to be supported. If so, then there is a need to define exactly what *should* be supported. But again, this isn't the right document for that. Thanks, Paul > Regards, >  Rifaat > > > On Sun, Apr 26, 2020 at 2:54 PM Paul Kyzivat > wrote: > > On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wrote: > > Paul, > > > > What you described is the theory; have you seen this deployed in > practice? > > Its just theory. But the specs should cover all the theoretical cases. > >         Thanks, >         Paul > > > Regards, > >   Rifaat > > > > > > On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat > > > >> wrote: > > > >     On 4/25/20 7:27 PM, Christer Holmberg wrote: > >      > Hi Benjamin, > >      > > >      >>> Section 2.3 states that: > >      >>> > >      >>>     When a proxy wishes to authenticate a received > request, it MUST > >      >>>     search the request for Proxy-Authorization header fields > >     with 'realm' > >      >>>     parameters that match its realm.  It then MUST > successfully > >     validate > >      >>> > >      >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests > that > >     it is not > >      >>> expected to have a sequence or list of Proxy-Authorization > >     header fields > >      >>> present in a single request that are intended to be > interpreted > >     by different > >      >> proxies.  Is this text compatible with that part of RFC 7235? > >      > > >      > RFC 3261 allows multiple Proxy-Authorization header fields. > > > >     * Here is a situation when they come into play: > > > >     UAC ----- P1 ------- P2 ------- UAS > > > >     On the first request from UAC toward UAS, P1 challenges with a > >     Proxy-Authenticate containing realm P1. > > > >     UAC retries, including Proxy-Authorization for realm P1. P1 > is happy > >     and > >     passes the request along. P2 challenges with realm P2. > > > >     UAC retries again. It adds Proxy-Authorization for realm P2, > but also > >     including the credentials for P1. P1 is happy and passes the > request > >     along. P2 is also happy and passes the request along to UAS. > > > >     Note that UAC must *remember* to include the P1 credentials > in the > >     second retry because there is no Proxy-Authenticate for P1 in > the 407 > >     from P2. Similarly, in future messages toward UAS the UAC should > >     remember to include credentials for P1 and P1. > > > >     * A more complex case is: > > > >     UAC ----- P1 -|------ P2 ------ UAS-A > >                     | > >                     |------ P3 ------ UAS-B > > > >     On the first request from UAC toward UAS, P1 challenges with a > >     Proxy-Authenticate containing realm P1. > > > >     UAC retries, including Proxy-Authorization for realm P1. P1 > is happy. > >     If it does parallel forking then it passes the request along > to both P2 > >     and P3. > > > >     P2 challenges by returning a Proxy-Authenticate for realm P2. > > > >     P1 buffers that response while awaiting a response from P3. > > > >     P3 challenges by returning a Proxy-Authenticate for realm P3. > > > >     P2 passes a response back to UAC with Proxy-Authenticates for > realms P2 > >     and P3. > > > >     UAC retries again. It adds Proxy-Authorization for realms P2 > and P3, > >     but > >     also including the credentials for P1. P1 is happy and passes the > >     request along to both P2 and P3. > > > >     P2 finds its Proxy-Authorization and happily passes the request > >     along to > >     UAS-A. > > > >     P3 finds its Proxy-Authorization and happily passes the request > >     along to > >     UAS-B. > > > >              Thanks, > >              Paul > > > >     _______________________________________________ > >     sipcore mailing list > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Sun Apr 26 12:54:02 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DA03A1037 for ; Sun, 26 Apr 2020 12:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJWKW4rRfsJX for ; Sun, 26 Apr 2020 12:53:57 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 5C1D93A103E for ; Sun, 26 Apr 2020 12:53:57 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id y26so6721478ioj.2 for ; Sun, 26 Apr 2020 12:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uW5VtvK3rR9hJKGFQYqj+I+HdCZ6t9i7a0GKg1PuvZk=; b=rt+zsxgsGfy9Yx023vxcV+zdF3XrwVKDKJcaor7zGx9M5W3Bz2n5ogS5fjt7h+Yo9e 2tpAv4wCldciiAC2vsUXY/jj2ntDssQxF4N67E8K75/PoTuEbjiGbWjDG3LaHO1kxdKR bv0WCKEBG/dC8Jvs+f4yKGbfUW+CAwWI124SgbxkQsyFsMx2d+3zR+FPRLwRjlDcOVhG 3XpFjrRs90TrXpGMwQxbw5XtH6SITdiz7iJ+NwFfELl+zK9LdzuVX6RfvMTqivmnaO+P qfUFX+zTjydYhZhAoYFx6zP14ijN5uSeh0bxYOv2QubCCDcTou6bAUGDV7O3TsXCZ6xd q05w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uW5VtvK3rR9hJKGFQYqj+I+HdCZ6t9i7a0GKg1PuvZk=; b=qTZc65UVRU+uLU+ZewFxxmosLZJu3Wi85afF1xPoOoorSoPx1y7zOGevNzHI6BzTON /lAy4VikXjalhUWwUJLyvCD/aqVsPwQi/tO0oZFWwrEJYzzMvQH7O7WPouzTZOR6EdVC HdtuFek3ezdutlsKZZmacSkQgTB/2dXCmdJ52qbQ//NzRQlndgHIqustjyfDFuJhBy7W lfFy6vEERQN2SncLqU6p1BbhKVdMJDdkfjmGXSR/HOa5E1vcexSgALzWfcoAA+OzBx1S M8CNwoaZrHwVUX1qi17H+kt6cygap1WleyY/AtMVHJJ7S56HLyXnjQ1ZJJIynsXqQjHS lxgQ== X-Gm-Message-State: AGi0PuaIjF8mNZpeXFelkMbXDLXAYMjq3V2WCDx4hTgx9kljiIPKw81K 0mUplG8CT74oItM+jNphnPmCWucRBwT5l6nfnro= X-Google-Smtp-Source: APiQypIl/uCRguDBYZTpTx8y8T9Oqxm/woNHOsofCi+lMBRBXMv6s9BRilTJt8449+52v7D4KIedFQHCP4Fg3di5prM= X-Received: by 2002:a5d:8155:: with SMTP id f21mr18531984ioo.151.1587930836357; Sun, 26 Apr 2020 12:53:56 -0700 (PDT) MIME-Version: 1.0 References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> <46e9dd50-0ccf-cb06-1eca-8df245f214b4@alum.mit.edu> In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 26 Apr 2020 15:53:46 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000006dd9df05a436f550" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2020 19:54:01 -0000 --0000000000006dd9df05a436f550 Content-Type: text/plain; charset="UTF-8" Thanks Paul! I guess I misunderstood your statement about this, as I thought you were arguing for this to be covered in this document. Regards, Rifaat On Sun, Apr 26, 2020 at 3:43 PM Paul Kyzivat wrote: > On 4/26/20 3:22 PM, Rifaat Shekh-Yusef wrote: > > Why should we do that? > > Why can't we just acknowledge that this was a nice idea in theory that > > never materialized in practice because they was never a need for it? > > Why can't this document explicitly state that this theoretical case is > > *not *cover and move on to do something more useful that people actually > > care about? > > I didn't say what we should do about it. I was just explaining the use > case. > > I generally agree that this document isn't the place to discuss such > cases. (Especially since the case I describe doesn't even involve > multiple schemes, and is scheme independent, so it is nothing that this > document impacts.) > > This is something that is implicit in 3261, and something that > implementors ought to support as a matter of course. Somebody can argue > that it isn't used and so shouldn't have to be supported. If so, then > there is a need to define exactly what *should* be supported. But again, > this isn't the right document for that. > > Thanks, > Paul > > > Regards, > > Rifaat > > > > > > On Sun, Apr 26, 2020 at 2:54 PM Paul Kyzivat > > wrote: > > > > On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wrote: > > > Paul, > > > > > > What you described is the theory; have you seen this deployed in > > practice? > > > > Its just theory. But the specs should cover all the theoretical > cases. > > > > Thanks, > > Paul > > > > > Regards, > > > Rifaat > > > > > > > > > On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat > > > > > >> > wrote: > > > > > > On 4/25/20 7:27 PM, Christer Holmberg wrote: > > > > Hi Benjamin, > > > > > > > >>> Section 2.3 states that: > > > >>> > > > >>> When a proxy wishes to authenticate a received > > request, it MUST > > > >>> search the request for Proxy-Authorization header > fields > > > with 'realm' > > > >>> parameters that match its realm. It then MUST > > successfully > > > validate > > > >>> > > > >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests > > that > > > it is not > > > >>> expected to have a sequence or list of > Proxy-Authorization > > > header fields > > > >>> present in a single request that are intended to be > > interpreted > > > by different > > > >> proxies. Is this text compatible with that part of RFC > 7235? > > > > > > > > RFC 3261 allows multiple Proxy-Authorization header fields. > > > > > > * Here is a situation when they come into play: > > > > > > UAC ----- P1 ------- P2 ------- UAS > > > > > > On the first request from UAC toward UAS, P1 challenges with a > > > Proxy-Authenticate containing realm P1. > > > > > > UAC retries, including Proxy-Authorization for realm P1. P1 > > is happy > > > and > > > passes the request along. P2 challenges with realm P2. > > > > > > UAC retries again. It adds Proxy-Authorization for realm P2, > > but also > > > including the credentials for P1. P1 is happy and passes the > > request > > > along. P2 is also happy and passes the request along to UAS. > > > > > > Note that UAC must *remember* to include the P1 credentials > > in the > > > second retry because there is no Proxy-Authenticate for P1 in > > the 407 > > > from P2. Similarly, in future messages toward UAS the UAC > should > > > remember to include credentials for P1 and P1. > > > > > > * A more complex case is: > > > > > > UAC ----- P1 -|------ P2 ------ UAS-A > > > | > > > |------ P3 ------ UAS-B > > > > > > On the first request from UAC toward UAS, P1 challenges with a > > > Proxy-Authenticate containing realm P1. > > > > > > UAC retries, including Proxy-Authorization for realm P1. P1 > > is happy. > > > If it does parallel forking then it passes the request along > > to both P2 > > > and P3. > > > > > > P2 challenges by returning a Proxy-Authenticate for realm P2. > > > > > > P1 buffers that response while awaiting a response from P3. > > > > > > P3 challenges by returning a Proxy-Authenticate for realm P3. > > > > > > P2 passes a response back to UAC with Proxy-Authenticates for > > realms P2 > > > and P3. > > > > > > UAC retries again. It adds Proxy-Authorization for realms P2 > > and P3, > > > but > > > also including the credentials for P1. P1 is happy and passes > the > > > request along to both P2 and P3. > > > > > > P2 finds its Proxy-Authorization and happily passes the > request > > > along to > > > UAS-A. > > > > > > P3 finds its Proxy-Authorization and happily passes the > request > > > along to > > > UAS-B. > > > > > > Thanks, > > > Paul > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > --0000000000006dd9df05a436f550 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0Paul!

I guess I misundersto= od your statement about this, as I thought you were arguing for this to be = covered in this document.

Regards,
=C2= =A0Rifaat


On Sun, Apr 26, 2020 at 3:43 PM Paul Kyzivat = <pkyzivat@alum.mit.edu> = wrote:
On 4/26/2= 0 3:22 PM, Rifaat Shekh-Yusef wrote:
> Why should we do that?
> Why can't we just acknowledge that this was a nice idea in theory = that
> never materialized in practice because they was never a need for it? > Why can't this document explicitly state that this theoretical=C2= =A0case is
> *not *cover and move on to do something more useful that people actual= ly
> care about?

I didn't say what we should do about it. I was just explaining the use = case.

I generally agree that this document isn't the place to discuss such cases. (Especially since the case I describe doesn't even involve
multiple schemes, and is scheme independent, so it is nothing that this document impacts.)

This is something that is implicit in 3261, and something that
implementors ought to support as a matter of course. Somebody can argue that it isn't used and so shouldn't have to be supported. If so, th= en
there is a need to define exactly what *should* be supported. But again, this isn't the right document for that.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
> On Sun, Apr 26, 2020 at 2:54 PM Paul Kyzivat <pkyzivat@alum.mit.edu
> <mailto:= pkyzivat@alum.mit.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 4/26/20 11:58 AM, Rifaat Shekh-Yusef wrote:
>=C2=A0 =C2=A0 =C2=A0 > Paul,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > What you described is the theory; have you se= en this deployed in
>=C2=A0 =C2=A0 =C2=A0practice?
>
>=C2=A0 =C2=A0 =C2=A0Its just theory. But the specs should cover all the= theoretical cases.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul
>
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0Rifaat
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Sun, Apr 26, 2020 at 10:28 AM Paul Kyzivat=
>=C2=A0 =C2=A0 =C2=A0<pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>= >> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 4/25/20 7:27 PM, Christ= er Holmberg wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi Benjamin,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> Section 2.3 = states that:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0= =C2=A0When a proxy wishes to authenticate a received
>=C2=A0 =C2=A0 =C2=A0request, it MUST
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0= =C2=A0search the request for Proxy-Authorization header fields
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0with 'realm'
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0= =C2=A0parameters that match its realm.=C2=A0 It then MUST
>=C2=A0 =C2=A0 =C2=A0successfully
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0validate
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> https://tools.ietf.org/html/rfc7235#section-4.4 suggests >=C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0it is not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> expected to = have a sequence or list of Proxy-Authorization
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0header fields
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >>> present in a= single request that are intended to be
>=C2=A0 =C2=A0 =C2=A0interpreted
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0by different
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >> proxies.=C2=A0 I= s this text compatible with that part of RFC 7235?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > RFC 3261 allows mult= iple Proxy-Authorization header fields.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0* Here is a situation when= they come into play:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAC ----- P1 ------- P2 --= ----- UAS
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On the first request from = UAC toward UAS, P1 challenges with a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Proxy-Authenticate contain= ing realm P1.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAC retries, including Pro= xy-Authorization for realm P1. P1
>=C2=A0 =C2=A0 =C2=A0is happy
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0passes the request along. = P2 challenges with realm P2.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAC retries again. It adds= Proxy-Authorization for realm P2,
>=C2=A0 =C2=A0 =C2=A0but also
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0including the credentials = for P1. P1 is happy and passes the
>=C2=A0 =C2=A0 =C2=A0request
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0along. P2 is also happy an= d passes the request along to UAS.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Note that UAC must *rememb= er* to include the P1 credentials
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0second retry because there= is no Proxy-Authenticate for P1 in
>=C2=A0 =C2=A0 =C2=A0the 407
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0from P2. Similarly, in fut= ure messages toward UAS the UAC should
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0remember to include creden= tials for P1 and P1.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0* A more complex case is:<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAC ----- P1 -|------ P2 -= ----- UAS-A
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|------ P3 ------ UAS-B
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On the first request from = UAC toward UAS, P1 challenges with a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Proxy-Authenticate contain= ing realm P1.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAC retries, including Pro= xy-Authorization for realm P1. P1
>=C2=A0 =C2=A0 =C2=A0is happy.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0If it does parallel forkin= g then it passes the request along
>=C2=A0 =C2=A0 =C2=A0to both P2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and P3.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P2 challenges by returning= a Proxy-Authenticate for realm P2.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P1 buffers that response w= hile awaiting a response from P3.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P3 challenges by returning= a Proxy-Authenticate for realm P3.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P2 passes a response back = to UAC with Proxy-Authenticates for
>=C2=A0 =C2=A0 =C2=A0realms P2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and P3.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAC retries again. It adds= Proxy-Authorization for realms P2
>=C2=A0 =C2=A0 =C2=A0and P3,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0but
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0also including the credent= ials for P1. P1 is happy and passes the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0request along to both P2 a= nd P3.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P2 finds its Proxy-Authori= zation and happily passes the request
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0along to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAS-A.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P3 finds its Proxy-Authori= zation and happily passes the request
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0along to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0UAS-B.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Thanks,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Paul
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0__________________________= _____________________
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0 > sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mail= man/listinfo/sipcore
>=C2=A0 =C2=A0 =C2=A0 >
>

--0000000000006dd9df05a436f550-- From nobody Mon Apr 27 09:12:16 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF163A0E1A; Mon, 27 Apr 2020 09:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 tcy0FgSJ9L3g; Mon, 27 Apr 2020 09:11:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4981D3A0E18; Mon, 27 Apr 2020 09:11:57 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03RGBnVh016300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 12:11:52 -0400 Date: Mon, 27 Apr 2020 09:11:49 -0700 From: Benjamin Kaduk To: Christer Holmberg Cc: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Message-ID: <20200427161149.GX27494@kduck.mit.edu> References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> <20200424201954.GY27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:12:01 -0000 On Fri, Apr 24, 2020 at 11:13:41PM +0000, Christer Holmberg wrote: > Hi Benjamin, > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ... > > Section 1.4.1 > ... > > >>> The registrar validates the access token. If the access token is a > >>> reference token, the registrar MAY perform an introspection > >>> [RFC7662], as in steps [5] and [6], in order to obtain more > >>> information about the access token and its scope, per [RFC7662]. > >>> > >>> I think we could tighten up the normative language a bit here. > >>> In particular, the registrar MUST validate the token in some fashion; for > >>> reference tokens, the main ways to do that are either inspection or > >>> (essentially) being the party that issued the token in the first place. > >>> > >>> Otherwise, after the registrar validates the token to make sure it > >>> was signed by a trusted entity, it inspects its claims and acts upon > >>> it. > >>> > >>> I think we can also be more specific than "a trusted entity" -- in this > >>> flow, it looks like the registrar should know exactly which entity should > >>> have signed the token in question (for the user in question), and should not > >>> accept a signed token from a different entity that happens to be trusted to > >>> issue other tokens. > >> > >> The text in Section 2.2. mandates the validation: > >> > >> "When a UAS/Registrar receives a SIP request that contains an > >> Authorization header field with an access token, the UAS/Registrar > >> MUST validate the access token,..." > >> > >> I don't think we should put too much normative text into the example flows. > > > > Perhaps we should just say "validates the token" (and not "to ") in this example? > > So, something like this: > > OLD: > > The registrar validates the access token. If the access token is a > reference token, the registrar MAY perform an introspection > [RFC7662], as in steps [5] and [6], in order to obtain more > information about the access token and its scope, per [RFC7662]. > Otherwise, after the registrar validates the token to make sure it > was signed by a trusted entity, it inspects its claims and acts upon > it. > > NEW: > > In step [4] and [5], the registrar validates the access token. > That might be trimming down too far -- we lose the explanation of steps [5] and [6]. I was thinking more like: % The registrar validates the access token. If the access token is a % reference token, the registrar MAY perform an introspection % [RFC7662], as in steps [5] and [6], in order to obtain more % information about the access token and its scope, per [RFC7662]. % Otherwise, after the registrar validates the token, it inspects its % claims and acts upon it. This level of detail seems okay to me because the dichotomy between "reference token" and "self-contained claims" is established earlier in the document. > --- > > Section 2.1.1 > ... > > >>> The detailed OAuth2 procedure to authenticate the user and obtain > >>> these tokens is out of scope of this document. The address of the > >>> authorization server might already be known to the UAC via > >>> configuration. In which case, the UAC can contact the authorization > >>> server for tokens before it sends a SIP request (Figure 2). > >>> > >>> nit: I think that "in which case" functions as a conjunction, which makes > >>> this an incomplete sentence. > >> > >> The text was suggested by one of the reviewers, but I agree it sounds incomplete. > >> > >> Perhaps "In such cases"? > > > > I think that works. > > ... > > Section 2.1.2 > ... > > >>> access to it. Endpoints that support this specification MUST support > >>> encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting > >>> access tokens when they are included in SIP requests, unless some > >>> other mechanism is used to guarantee that only authorized SIP > >>> endpoints have access to the access token. > >>> > >>> I think we may want "MUST support" (always) and "MUST use, unless some other > >>> mechanism". > >> > >> Based on another review, I suggested to change to "MUST use". I am not sure whether we need to keep "MUST support". > > > > I think "MUST use" implies "MUST support", yes. > > ... > > >>> I'd also suggest a quick note that TLS remains fine for protecting the > >>> UAC/AS interaction where the refresh token is used. > >> > >> I can do that. > >> > >> I could also say "*SIP* endpoints that support this specification...". > > > > Either sounds good. > > My suggestion was to do both changes :) Something like: > > "SIP endpoints that support this specification MUST use encrypted > JSON Web Tokens (JWT) [RFC7519] for encoding and protecting > access tokens when they are included in SIP requests, unless some other mechanism > is used to guarantee that only authorized SIP endpoints have access to > the access token. TLS can still be used for protecting traffic between > SIP endpoints and the AS." > Ah. Looks good! Thanks, Ben > > Section 2.2 > > >>> authorization credentials acceptable to it, it SHOULD challenge the > >>> request by sending a 401 (Unauthorized) response. To indicate that > >>> it is willing to accept an access token as a credential, the UAS/ > >>> Registrar MUST include a Proxy-Authentication header field in the > >>> response that indicates "Bearer" scheme and includes an address of an > >>> > >>> nit(?): I'd consider just making this a declarative statement, a la "the > >>> UAS/registrar includes a Proxy-Authentication header field with the "Bearer" > >>> scheme to indicate that it is willing to accept an access token as a > >>> credential" (but that wording is incomplete and would need to be fleshed > >>> out a bit more). > >> > >> I think that would be weird. Because, first we say that the UAS/Registrar SHOULD challenge, and with your > >> suggestion the text would say that the UAS/Registrar MUST include a Proxy-Authentication header field even > >> if it does NOT challenge the request. > >> > >> Perhaps: > >> > >> "If the UAS/Registrar chooses to challenge the request, and is willing to accept an access token as a credential, the UAS/Registrar MUST include a..." > > > > This version does get rid of the confusion about whether the MUST is > > conditional that I wanted to address, thanks. (I see I didn't actually say > > why I proposed the change I did, whoops.) > > ... > > >>> [RFC7519]. If the token provided is an expired access token, then > >>> the UAS MUST reply with 401 Unauthorized, as defined in section 3 of > >>> [RFC6750]. If the validation is successful, the UAS/Registrar can > >>> continue to process the request using normal SIP procedures. If the > >>> validation fails, the UAS/Registrar MUST reject the request. > >>> > >>> Is "expired" the only case that should get a 401 vs. outright rejection, as > >>> stated here? > >> > >> 401 is sent also in the case where the validation fails. I will clarify that. > > ... > > Section 2.3 > > >>> sending a 407 (Proxy Authentication Required) response. To indicate > >>> that it is willing to accept an access token as a credential, the > >>> proxy MUST include a Proxy-Authentication header field in the > >>> response that indicates "Bearer" scheme and includes an address to an > >>> > >>> [same comment as above about normative vs. declarative statement] > >>> Also, please keep the text parallel between sections -- this copy has at > >>> least one nit ("address to an" vs. "address of an"). > >> > >> I will fix this in the same way. > > ---- > > Section 5 > > >>> We should probably note that SIP makes much heavier use of proxies than is > >>> common in the web world of OAuth. > >> > >> Maybe something like: > >> > >> "However, SIP makes have use of intermediary SIP proxies, and TLS only guarantees hop-to-hop protection when used to > >> protect SIP signaling." > > > > Sure, that should work. > > --- > > > > Section 8 > > > > > > I think RFCs 8252 and 8414 could be just informative. > > > > I can fix that. > > --- > > The changes done so far based on your IESG review can be found in the following pull request commit: > > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7/commits/0fc655719d7e3cefc7417b382e7662c1d9c12dbb > > > Regards, > > Christer > > > From nobody Mon Apr 27 09:19:55 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50E03A0EEF; Mon, 27 Apr 2020 09:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TgyRlHAxjNVn; Mon, 27 Apr 2020 09:19:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 520F43A0F18; Mon, 27 Apr 2020 09:19:38 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03RGJUpo019076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 12:19:32 -0400 Date: Mon, 27 Apr 2020 09:19:30 -0700 From: Benjamin Kaduk To: Rifaat Shekh-Yusef Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Message-ID: <20200427161930.GY27494@kduck.mit.edu> References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:19:48 -0000 Also inline, though the quoting situation doesn't look great in this MUA. Apologies if I miss something... On Sat, Apr 25, 2020 at 11:10:50AM -0400, Rifaat Shekh-Yusef wrote: > Inline... > On Thu, Apr 23, 2020 at 5:04 PM Christer Holmberg > wrote: > > Hi Benjamin, > > Thank You for the review! In this reply I will address some of your > COMMENT issues, and indicate the ones that I want Rifaat to address. > Your DISCUSS will be addressed in a separate realy. > > > ---------------------------------------------------------------------- > COMMENT: > > ---------------------------------------------------------------------- > > > Section 1 > > > > The OpenID Connect 1.0 specification [OPENID] defines a simple > > identity layer on top of the OAuth 2.0 protocol, which enables > > clients to verify the identity of the user based on the > > > > Please make it clear that these are OAuth/OIDC clients, not SIP > clients. > > I'll leave this for Rifaat. > > Sure. > > > --- > > > Section 1.3 > > > > OAuth 2.0 doesn't require the issuance of a Refresh token, but the > > discussion here implies that for the SIP case there will always be > a refresh > > token. If we're profiling 6749 in this manner, we should be more > explicit > > about the requirement to issue refresh tokens. > > I am not sure whether the intention is to say that there will always be > a refresh token. But, I'll leave this for Rifaat. > > I answered in this the reply to the DISCUSS > > > > * ID Token: this token contains the SIP URI and other > user-specific > > details that will be consumed by the UAC. > > > > nit: I don't think we should use the definite article in "the SIP > URI" since > > we haven't discussed any such SIP URI usage yet. That is, we > should say > > what it's used for, e.g., "a SIP URI associated with the user". > > I'll leave this for Rifaat. > > Sure. > > > > * Structured Token: a token that consists of a structured > object > > that contains the claims associated with the token, e.g. JWT > as > > defined in [RFC7519]. > > > > nit: comma after "e.g.". > > Will be fixed. > > > * Reference Token: a token that consists of a random string > that is > > used to obtain the details of the token and its associated > claims, > > as defined in [RFC6749]. > > > > It doesn't technically have to be random (though in practice it > should > > contain signficant random elements); "opaque" might be better > wording. > > I'll leave this for Rifaat. > > How about "opaque random string"? I'm still not entirely comfortable about that since it implies too much (lack of) structure. We sometimes see this sort of thing described as an "opaque handle", if that sounds better to you. > > > Section 1.4.1 > > > > Perhaps Figure 1 could include some indication that steps 5 and 6 > are > > optional/do not always occur (in the case when the access token is > a > > self-contained JWT)? > > I'll leave this for Rifaat. > > This is explicitly mentioned in the text, but I agree that it would be > helpful to include it in the figure. > > > > In step [2], the registrar challenges the UA, by sending a SIP > 401 > > (Unauthorized) response to the REGISTER request. In the > response, > > the registrar includes information about the AS to contact in > order > > to obtain a token. > > > > The UAC needs to have a preconfigured whitelist of acceptable ASes > in order > > to avoid directing the user's credentials to malicious sites. > > This is related to your DISCUSS, so it will be addressed as part of > that. > > > The registrar validates the access token. If the access token > is a > > reference token, the registrar MAY perform an introspection > > [RFC7662], as in steps [5] and [6], in order to obtain more > > information about the access token and its scope, per [RFC7662]. > > > > I think we could tighten up the normative language a bit here. > > In particular, the registrar MUST validate the token in some > fashion; for > > reference tokens, the main ways to do that are either inspection or > > (essentially) being the party that issued the token in the first > place. > > > > Otherwise, after the registrar validates the token to make sure > it > > was signed by a trusted entity, it inspects its claims and acts > upon > > it. > > > > I think we can also be more specific than "a trusted entity" -- in > this > > flow, it looks like the registrar should know exactly which entity > should > > have signed the token in question (for the user in question), and > should not > > accept a signed token from a different entity that happens to be > trusted to > > issue other tokens. > > The text in Section 2.2. mandates the validation: > > "When a UAS/Registrar receives a SIP request that contains an > Authorization header field with an access token, the UAS/Registrar > MUST validate the access token,..." > > I don't think we should put too much normative text into the example > flows. > > > Section 1.4.2 > > > > (Similarly, Figure 2 could note that steps 3 and 4 do not always > occur, and > > the text about token validation should remain parallel between > examples.) > > I'll leave this for Rifaat. > > Again, this is explicitly mentioned in the text, but I agree that it would > be helpful to include it in the figure. Yes, I agree that the text is clear, but if it's easy to put something in the figure as well, it seems worth doing so. > > ---- > > > Section 2 > > > > I note that RFC 3261 explicitly disclaims any definition of > authorization > > systems, which is not true for this document, given that OAuth is > an > > authorization system :) > > RFC 3261 only says that the RFC does not recommend or discuss any > authorization system. > > > Section 2.1.1 > > > > Required) response with a Proxy-Authenticate header field. If > the > > WWW-Authenticate or Proxy-Authenticate header field indicates > > "Bearer" scheme authentication and contains an address to an > > authorization server, the UAC contacts the authorization server > in > > order to obtain tokens, and includes the requested scopes, based > on a > > local configuration (Figure 1). > > > > [whitelist of allowed ASes, again] > > Will be addressed when the DISCUSS is addressed. > > > The detailed OAuth2 procedure to authenticate the user and > obtain > > these tokens is out of scope of this document. The address of > the > > authorization server might already be known to the UAC via > > configuration. In which case, the UAC can contact the > authorization > > server for tokens before it sends a SIP request (Figure 2). > > > > nit: I think that "in which case" functions as a conjunction, which > makes > > this an incomplete sentence. > > The text was suggested by one of the reviewers, but I agree it sounds > incomplete. > > Perhaps "In such cases"? > > > The tokens returned to the UAC depend on the type of > authorization > > server (AS): an OAuth AS provides an access token and refresh > token > > [RFC6749]. The UAC provides the access token to the SIP servers > to > > > > Again, this implies that refresh tokens are always issued; RFC 6749 > is quite > > clear that "issuing a refresh token is optional at the discretion > of the > > authorization server". > > I'll leave this for Rifaat. > > As I mentioned in the reply to the DISCUSS, we will clarify this. > > > > authorize UAC's access to the service. The UAC uses the refresh > > token only with the AS to get a new access token and refresh > token > > before the expiry of the current access token (see [RFC6749], > section > > > > (New refresh token is also optional.) > > I'll leave this for Rifaat. > > As I mentioned in the reply to the DISCUSS, we will clarify this. > > > > 1.5 Refresh Token for details). An OpenID Connect server > returns an > > additional ID-Token containing the SIP URI and other > user-specific > > details that will be consumed by the UAC. > > > > [same comment as above about "the SIP URI".] > > I'll leave this for Rifaat. > > Ok > > > > If the UAC receives a 401/407 response with multiple WWW- > > Authenticate/Proxy-Authenticate header fields, providing > challenges > > using different authentication schemes for the same realm, the > UAC > > selects one or more of the provided schemes (based on local > policy) > > and provides credentials for those schemes. > > > > RFC 3261 seems to be written in a world that assumed that Basic and > Digest > > are the only defined HTTP authentication schemes, and since it > prohibits > > Basic, that there would only be one authentication challenge (type) > > possible. This text righly acknowledges that we are opening the > field up > > and could have cases where multiple authentication schemes are > possible; > > however, it goes even further and admits the possibility of using > them > > simultaneously. It seems like this places an onus on us to give > some > > indication of the semantics when multiple schemes are used at the > same time. > > Do the authenticated identities need to match? Or are we asserting > that > > both/all identities are consenting to the request in question? (If > we don't > > have a concrete use case in mind, perhaps the "or more" is just > opening a > > box that we don't need to open right now.) > > I can modify as suggested. > > (Personally, I have never seen multiple schemes in a deployment.) > > > Section 2.1.2 > > > > access to it. Endpoints that support this specification MUST > support > > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and > protecting > > access tokens when they are included in SIP requests, unless > some > > other mechanism is used to guarantee that only authorized SIP > > endpoints have access to the access token. > > > > I think we may want "MUST support" (always) and "MUST use, unless > some other > > mechanism". > > Based on another review, I suggested to change to "MUST use". I am not > sure whether we need to keep "MUST support". > > > I'd also suggest a quick note that TLS remains fine for protecting > the > > UAC/AS interaction where the refresh token is used. > > I can do that. > > I could also say "*SIP* endpoints that support this specification...". > > > Whatever is done, please harmonize with Section 5 that has > essentially the > > same text. > > Will do. > > > Section 2.1.3 > > > > Based on local policy, the UAC MAY include an access token that > has > > been used for another binding associated with the same Address > Of > > Record (AOR) in the request. > > > > Just to check: there's no real privacy considerations with such > use, as its > > the same parties interacting and there are other identifiers (e.g., > IP > > addresses) to confirm that it's the same client communicating to > the server? > > I'll leave this for Rifaat. > > I would not rely only on an IP address, but the answer is yes. Okay. > > > > Also, is it clear what will be done (new token request) when the > MAY is not > > heeded? > > I'll leave this for Rifaat. > > The Client would need to obtain a new access token. I will clarify this. Thanks. > > > Section 2.1.4 > > > > The text here just talks about "a valid access token" and similar, > without > > saying a whole lot about it being related in any way to the > specifics of the > > authentication challenge. Is there something useful to say about, > e.g., the > > token in question having been issued by the authorization server > indicated > > in the challenge? > > I'll leave this for Rifaat. > > Sure. > > > > Section 2.2 > > > > authorization credentials acceptable to it, it SHOULD challenge > the > > request by sending a 401 (Unauthorized) response. To indicate > that > > it is willing to accept an access token as a credential, the > UAS/ > > Registrar MUST include a Proxy-Authentication header field in > the > > response that indicates "Bearer" scheme and includes an address > of an > > > > nit(?): I'd consider just making this a declarative statement, a la > "the > > UAS/registrar includes a Proxy-Authentication header field with the > "Bearer" > > scheme to indicate that it is willing to accept an access token as > a > > credential" (but that wording is incomplete and would need to be > fleshed > > out a bit more). > > I think that would be weird. Because, first we say that the > UAS/Registrar SHOULD challenge, and with your suggestion the text would > say that the UAS/Registrar MUST include a Proxy-Authentication header > field even if it does NOT challenge the request. > > Perhaps: > > "If the UAS/Registrar chooses to challenge the request, and is willing > to accept an access token as a credential, the UAS/Registrar MUST > include a..." > > > authorization server from which the originator can obtain an > access > > token. > > > > nit: "address of" an AS, does that mean bare IP address only or is > a DNS > > name okay? > > I'll leave this for Rifaat. > > I do not think that an IP address is appropriate, and what I have in mind > is a DNS name. > I will clarify it. Ah, DNS name sounds better to me, too :) Thanks, Ben > > [RFC7519]. If the token provided is an expired access token, > then > > the UAS MUST reply with 401 Unauthorized, as defined in section > 3 of > > [RFC6750]. If the validation is successful, the UAS/Registrar > can > > continue to process the request using normal SIP procedures. If > the > > validation fails, the UAS/Registrar MUST reject the request. > > > > Is "expired" the only case that should get a 401 vs. outright > rejection, as > > stated here? > > 401 is sent also in the case where the validation fails. I will clarify > that. > > > Section 2.3 > > > > sending a 407 (Proxy Authentication Required) response. To > indicate > > that it is willing to accept an access token as a credential, > the > > proxy MUST include a Proxy-Authentication header field in the > > response that indicates "Bearer" scheme and includes an address > to an > > > > [same comment as above about normative vs. declarative statement] > > Also, please keep the text parallel between sections -- this copy > has at > > least one nit ("address to an" vs. "address of an"). > > I will fix this in the same way. > > > Section 3 > > > > If an access token is encoded as a JWT, it might contain a list > of > > claims [RFC7519], some registered and some > application-specific. The > > > > I don't think there's a question of whether a JWT will contain a > list of > > claims :) > > Fair enough :) > > > Maybe "If the access token is encoded as a JWT, it will contain a > list of > > claims [RFC7519], which may include both registered and > application-specific > > claims"? > > Looks good to me, but I'll leave this for Rifaat. > > Looks good to me too. > Regards, > Rifaat > > > ---- > > > Section 4 > > > > This section claims to cover WWW-Authenticate. What specification > will the > > SIP use of Bearer for Authorization operate under? > > RFC 6750. > > Section 2.1.3 says: > > "The UAC sends a REGISTER request with an Authorization header field > containing the response to the challenge, including the Bearer scheme > carrying a valid access token in the request, as specified in > [RFC6750]." > > > challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) > > > > side note: is there a mnemonic for the "cln" in "bearer-cln"? > > RFC 3261 uses "cln" for digest. > > > bearer-cln = realm / scope / authz-server / error / > > auth-param > > > > nit: realm is already included in auth-param, though I don't see a > harm in > > calling it out explicitly. > > auth-param is used to allow possible new parameters in the future. > > > realm = > > auth-param = > > > > RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of > these; we > > could perhaps short-circuit the chain and say "defined in RFC > 7235". > > We discussed this in the WG, and the outcome was to keep the same > references as RFC 3261, since that is what people are implementing. > > Then, as a separate task, someone could update RFC 3261 with the new > references. > > --- > > > Section 5 > > > > We should probably note that SIP makes much heavier use of proxies > than is > > common in the web world of OAuth. > > Maybe something like: > > "However, SIP makes have use of intermediary SIP proxies, and TLS only > guarantees hop-to-hop protection when used to > protect SIP signaling." > > > I'm happy to see that some privacy considerations are being added > in > > response to Barry's review. > > Good :) > > --- > > > Section 8 > > > > I think RFCs 8252 and 8414 could be just informative. > > I can fix that. > > --- > > Regards, > > Christer From nobody Mon Apr 27 09:23:54 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1A03A0E91; Mon, 27 Apr 2020 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 wXQMgJPj8_iq; Mon, 27 Apr 2020 09:23:44 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130050.outbound.protection.outlook.com [40.107.13.50]) (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 C240E3A0E85; Mon, 27 Apr 2020 09:23:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mPWKAEtJnYBYnQpA23kNPM/2YDYzqAVX3zYLY9MRRKS6u+La4tUQsA+q5lOdFjSJr6DCZ+t0BbpbUdcX003AWXHH0fzO9D6Mv5VErE6yECzEJNAmCgqhEpApwQVqBJyImBIVA6XIJX9zYOzLA5TSrxD3KBNnXzJQAcNYoxE4nZEzbO5cAuZjbN0jjNnj8qqZRIoGCivY3+7kMZt/tACRAA8Z9L5Iko/M5eqAfT6YUcTBgqh9v6nD2L2sv3LhPWfkf5L2VUmN+IDXngnmBBX5WIjz6tTzZVS2BVFX10+r+19E4oUEOy4S1IjDxzY3JvHVwCOpC7sSW4cg9aG1qKMhYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhgazEK26tkG8aXVqAVz+CHSozyBdl99S2WhMSGznkE=; b=gkMbubBj70qSdMCy3rfZAvflZiPcgmSBr/VioMGL6COZvoQ7FeoAER2nK7H0YnZJHAsTFhOZq2EPqkUiRxip8TMch9E54cFgYcbzesAlVPjtAP/2GlcQi4GhwZowzptY7pWmGEosvOzU1QlfOK5xRTEmLXVfWsStftt3PE+cJPZZS22FBm/smQTwCYHXFIhA4OJcys7/TTzLP4ml8Np6KghbB83QGxdjk/PaqOqDddSnl8TSUXTBSv1SPKnUPam4BizEa2+8I2XYXTp/cJ8Y7InA/9oyTPnOpSTC+Ae0dLsUYMQGew+5I8TylprOK7lK/K7+ppMcKpJadTiSPUX7pQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WhgazEK26tkG8aXVqAVz+CHSozyBdl99S2WhMSGznkE=; b=ruMqllAypebmQk/1HpSGFUDIde6sxyJJdfdQ8cD1rp207fFcDKvQSuHLycpYRIF1MnSNt0Oa0ITQn4q+K5OVQ58B1/XYZQR+FT2p3Xol2NDAbQTwy5wNpEuRI4NJJeIvQYudyOfhqKaB7jj2DUgD0T6FIwalrJOH85P+jNkTJ1E= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6706.eurprd07.prod.outlook.com (2603:10a6:20b:1a6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Mon, 27 Apr 2020 16:23:32 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 16:23:32 +0000 From: Christer Holmberg To: Benjamin Kaduk CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT Thread-Index: AQHWGbKxu2gQq0gnZkyF4LBa/O+0aqiIuAgAgABi2YCABA7WgIAANY+A Date: Mon, 27 Apr 2020 16:23:32 +0000 Message-ID: References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> <20200424201954.GY27494@kduck.mit.edu> <20200427161149.GX27494@kduck.mit.edu> In-Reply-To: <20200427161149.GX27494@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db03dcb4-d82b-4b3c-e8be-08d7eac753c4 x-ms-traffictypediagnostic: AM7PR07MB6706: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(376002)(346002)(39860400002)(91956017)(66946007)(76116006)(6506007)(6486002)(66476007)(66556008)(64756008)(66446008)(4326008)(33656002)(2616005)(44832011)(186003)(2906002)(8676002)(6916009)(478600001)(6512007)(26005)(966005)(8936002)(81156014)(86362001)(36756003)(54906003)(5660300002)(71200400001)(316002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sv4WrNyEwuKUkijOWSLSmMykM6I4FQhdbKvyBFxuXgbRzsmLNxgfhHlxjzTTVxTBRqy9ZelOM5h/3gAFX+LBezuubWPlClGCJ84ufFVyFGCRxiHYI3mh5dfCtLi2QrxqnHhExoLhChUJVIZgV2EfSl13XKDiFDsnBXbfBMkuEWcDYQPCuzd0EwToR8nb294KL+f2sw6Kq8UKULB455kK9EiMBvU+1LAJ24PHR2Vm4M479GuPG+7TrwUc9/2/8QG+8Bj3+KAhBApGw8Wd2dHxe1BV3RR81N3n+qS+rq2RcLoGZe8CnMEiRJq037XJEd7dOgVmL7ulnk/YLBg3MR3dLVjwIG083KXka12fmK0LN8wy4LapP17IMLJHRxr/9fUgGmm0ddPKH4Q4xovUiNkhuVxN2R1mHytzWD7awnYxwwQdTQjXdVepdi14DBKzMEdBQVGbkl7YHBTDaZBp/T6JesakdsKbEUqxsHeorsrVEGscRJdBdeh1lJ4rrIhvkuxPSm/24/aaBnOZiPePVLc19A== x-ms-exchange-antispam-messagedata: DARBbsO2QZqJRel88SP0Huo1z1SX6cBHj9vKmNvfW/p5nf0U2xryRMPB72g19V23gvoN609mdAhzgLGzNyKMzh5uWxhZrhdUAOTpowk2TTVCT2saL793wPOtfPqqq5A0cmRFROQC+bSC0ggl9w6cydoCCjfvyeLM4Ep5pOLNpU61c4KCSxRxi5IzG2XIdDK101IsOA3CG5X3Ni6HMgUC26/LLkflOBjfRiTw922pXct0teBVKvC9F8II3GVqi6pVtXxjLiTOR989WKb9Xw6zAZUBIJGWeWPJXWUKAHsiiakhEOcxYNhqmtlD8GJ5TnTbdZTUEIjBYFvhCCjJDI5JSogSFOEvS2XHE0ztAJzs/S+vW1/U7K+HMQCnvJSzL1YTxDrMCPZ9QZZrv0pIeH3dRG+mLbbae7IHxo03+F2SZPUoPfB57V26POE1vTuiKrm2RpqY4oYNuannof1gojhlWN088zxro3KNeoJkYzVAu0bJq/QhFlFuXww8csyjJQottvpbnxOZLPi6PF7jPoSFo6hvxS0KaaaLoyPAtRYNoH1ZvswNIHT0cImFo/3u96dWO/iLpNu8O34c6t/7w8l8LIsSiy5wu5L7GjTFopcjABxjVbuTQH84p9CTDu5VC0zgMe1aJU0HwKmoBgQzDnWnf6fO235iaZIjAZVBnyXIiB1/dCo1X2ftN3s65izHVR0bHx+1dEXP/qNGoa+lEkIK8KEzxm0DisoUslJGF60JrV5ZsP0RjkM8OiyFBEUXe7I7zlXMNa2ew4KsnoCMI+QitFlka7TF3Kwxq0agJu0grEk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: db03dcb4-d82b-4b3c-e8be-08d7eac753c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 16:23:32.0332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mZhw2SvSPSfFcYF1YHjo01nTonWfjn61c3iZkixrznNqulxl9ZFaP0jgV362DQazcK+V9HJwsJUwH6G3Gn7cg/bimcUxhDBkEZyk1Fjb54Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6706 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:23:47 -0000 SGkgQmVuamFtaW4sDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgQ09NTUVOVDoN CiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4gICAgIA0KICAgID4+ICAgICAuLi4NCiAgICA+PiAg IA0KICAgID4+ICAgICBTZWN0aW9uIDEuNC4xDQogICAgPj4gICAgIC4uLg0KICAgID4+IA0KICAg ID4+ICAgICA+Pj4gICAgICAgVGhlIHJlZ2lzdHJhciB2YWxpZGF0ZXMgdGhlIGFjY2VzcyB0b2tl bi4gIElmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYQ0KICAgID4+ICAgICA+Pj4gICAgICAgcmVmZXJl bmNlIHRva2VuLCB0aGUgcmVnaXN0cmFyIE1BWSBwZXJmb3JtIGFuIGludHJvc3BlY3Rpb24NCiAg ICA+PiAgICAgPj4+ICAgICAgIFtSRkM3NjYyXSwgYXMgaW4gc3RlcHMgWzVdIGFuZCBbNl0sIGlu IG9yZGVyIHRvIG9idGFpbiBtb3JlDQogICAgPj4gICAgID4+PiAgICAgICBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgYWNjZXNzIHRva2VuIGFuZCBpdHMgc2NvcGUsIHBlciBbUkZDNzY2Ml0uDQogICAg Pj4gICAgID4+PiAgICANCiAgICA+PiAgICAgPj4+ICAgIEkgdGhpbmsgd2UgY291bGQgdGlnaHRl biB1cCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGEgYml0IGhlcmUuDQogICAgPj4gICAgID4+PiAg ICBJbiBwYXJ0aWN1bGFyLCB0aGUgcmVnaXN0cmFyIE1VU1QgdmFsaWRhdGUgdGhlIHRva2VuIGlu IHNvbWUgZmFzaGlvbjsgZm9yDQogICAgPj4gICAgID4+PiAgICByZWZlcmVuY2UgdG9rZW5zLCB0 aGUgbWFpbiB3YXlzIHRvIGRvIHRoYXQgYXJlIGVpdGhlciBpbnNwZWN0aW9uIG9yDQogICAgPj4g ICAgID4+PiAgICAoZXNzZW50aWFsbHkpIGJlaW5nIHRoZSBwYXJ0eSB0aGF0IGlzc3VlZCB0aGUg dG9rZW4gaW4gdGhlIGZpcnN0IHBsYWNlLg0KICAgID4+ICAgICA+Pj4gIA0KICAgID4+ICAgICA+ Pj4gICAgICAgT3RoZXJ3aXNlLCBhZnRlciB0aGUgcmVnaXN0cmFyIHZhbGlkYXRlcyB0aGUgdG9r ZW4gdG8gbWFrZSBzdXJlIGl0DQogICAgPj4gICAgID4+PiAgICAgICB3YXMgc2lnbmVkIGJ5IGEg dHJ1c3RlZCBlbnRpdHksIGl0IGluc3BlY3RzIGl0cyBjbGFpbXMgYW5kIGFjdHMgdXBvbg0KICAg ID4+ICAgICA+Pj4gICAgICAgaXQuDQogICAgPj4gICAgID4+PiAgICANCiAgICA+PiAgICAgPj4+ ICAgIEkgdGhpbmsgd2UgY2FuIGFsc28gYmUgbW9yZSBzcGVjaWZpYyB0aGFuICJhIHRydXN0ZWQg ZW50aXR5IiAtLSBpbiB0aGlzDQogICAgPj4gICAgID4+PiAgICBmbG93LCBpdCBsb29rcyBsaWtl IHRoZSByZWdpc3RyYXIgc2hvdWxkIGtub3cgZXhhY3RseSB3aGljaCBlbnRpdHkgc2hvdWxkDQog ICAgPj4gICAgID4+PiAgICBoYXZlIHNpZ25lZCB0aGUgdG9rZW4gaW4gcXVlc3Rpb24gKGZvciB0 aGUgdXNlciBpbiBxdWVzdGlvbiksIGFuZCBzaG91bGQgbm90DQogICAgPj4gICAgID4+PiAgICBh Y2NlcHQgYSBzaWduZWQgdG9rZW4gZnJvbSBhIGRpZmZlcmVudCBlbnRpdHkgdGhhdCBoYXBwZW5z IHRvIGJlIHRydXN0ZWQgdG8NCiAgICA+PiAgICAgPj4+ICAgIGlzc3VlIG90aGVyIHRva2Vucy4N CiAgICA+PiAgICAgPj4gICAgIA0KICAgID4+ICAgICA+PiBUaGUgdGV4dCBpbiBTZWN0aW9uIDIu Mi4gbWFuZGF0ZXMgdGhlIHZhbGlkYXRpb246DQogICAgPj4gICAgID4+IA0KICAgID4+ICAgICA+ PiAgICAiV2hlbiBhIFVBUy9SZWdpc3RyYXIgcmVjZWl2ZXMgYSBTSVAgcmVxdWVzdCB0aGF0IGNv bnRhaW5zIGFuDQogICAgPj4gICAgID4+ICAgIEF1dGhvcml6YXRpb24gaGVhZGVyIGZpZWxkIHdp dGggYW4gYWNjZXNzIHRva2VuLCB0aGUgVUFTL1JlZ2lzdHJhcg0KICAgID4+ICAgICA+PiAgICBN VVNUIHZhbGlkYXRlIHRoZSBhY2Nlc3MgdG9rZW4sLi4uIg0KICAgID4+ICAgICA+PiANCiAgICA+ PiAgICAgPj4gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgcHV0IHRvbyBtdWNoIG5vcm1hdGl2ZSB0 ZXh0IGludG8gdGhlIGV4YW1wbGUgZmxvd3MuDQogICAgPj4gICAgID4NCiAgICA+PiAgICAgPiBQ ZXJoYXBzIHdlIHNob3VsZCBqdXN0IHNheSAidmFsaWRhdGVzIHRoZSB0b2tlbiIgKGFuZCBub3Qg InRvIDxkbyB0aGluZyBYPiIpIGluIHRoaXMgZXhhbXBsZT8NCiAgICA+PiAgDQogICAgPj4gICAg IFNvLCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KICAgID4+IA0KICAgID4+IE9MRDoNCiAgICA+PiAN CiAgICA+PiAgICBUaGUgcmVnaXN0cmFyIHZhbGlkYXRlcyB0aGUgYWNjZXNzIHRva2VuLiAgSWYg dGhlIGFjY2VzcyB0b2tlbiBpcyBhDQogICAgPj4gICAgcmVmZXJlbmNlIHRva2VuLCB0aGUgcmVn aXN0cmFyIE1BWSBwZXJmb3JtIGFuIGludHJvc3BlY3Rpb24NCiAgICA+PiAgICBbUkZDNzY2Ml0s IGFzIGluIHN0ZXBzIFs1XSBhbmQgWzZdLCBpbiBvcmRlciB0byBvYnRhaW4gbW9yZQ0KICAgID4+ ICAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBhY2Nlc3MgdG9rZW4gYW5kIGl0cyBzY29wZSwgcGVy IFtSRkM3NjYyXS4NCiAgICA+PiAgICBPdGhlcndpc2UsIGFmdGVyIHRoZSByZWdpc3RyYXIgdmFs aWRhdGVzIHRoZSB0b2tlbiB0byBtYWtlIHN1cmUgaXQNCiAgICA+PiAgICB3YXMgc2lnbmVkIGJ5 IGEgdHJ1c3RlZCBlbnRpdHksIGl0IGluc3BlY3RzIGl0cyBjbGFpbXMgYW5kIGFjdHMgdXBvbg0K ICAgID4+ICAgIGl0Lg0KICAgID4+IA0KICAgID4+IE5FVzoNCiAgICA+Pg0KICAgID4+ICAgIElu IHN0ZXAgWzRdIGFuZCBbNV0sIHRoZSByZWdpc3RyYXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9r ZW4uDQogICAgPj4gDQogICAgPj4NCiAgICA+IFRoYXQgbWlnaHQgYmUgdHJpbW1pbmcgZG93biB0 b28gZmFyIC0tIHdlIGxvc2UgdGhlIGV4cGxhbmF0aW9uIG9mIHN0ZXBzIFs1XQ0KICAgID4gYW5k IFs2XS4gIEkgd2FzIHRoaW5raW5nIG1vcmUgbGlrZToNCiAgICA+DQogICAgPiAlIFRoZSByZWdp c3RyYXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4uICBJZiB0aGUgYWNjZXNzIHRva2VuIGlz IGENCiAgICA+ICUgcmVmZXJlbmNlIHRva2VuLCB0aGUgcmVnaXN0cmFyIE1BWSBwZXJmb3JtIGFu IGludHJvc3BlY3Rpb24NCiAgICA+ICUgW1JGQzc2NjJdLCBhcyBpbiBzdGVwcyBbNV0gYW5kIFs2 XSwgaW4gb3JkZXIgdG8gb2J0YWluIG1vcmUNCiAgICA+ICUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IGFjY2VzcyB0b2tlbiBhbmQgaXRzIHNjb3BlLCBwZXIgW1JGQzc2NjJdLg0KICAgID4gJSBPdGhl cndpc2UsIGFmdGVyIHRoZSByZWdpc3RyYXIgdmFsaWRhdGVzIHRoZSB0b2tlbiwgaXQgaW5zcGVj dHMgaXRzDQogICAgPiAlIGNsYWltcyBhbmQgYWN0cyB1cG9uIGl0Lg0KICAgID4NCiAgICA+IFRo aXMgbGV2ZWwgb2YgZGV0YWlsIHNlZW1zIG9rYXkgdG8gbWUgYmVjYXVzZSB0aGUgZGljaG90b215 IGJldHdlZW4NCiAgICA+ICJyZWZlcmVuY2UgdG9rZW4iIGFuZCAic2VsZi1jb250YWluZWQgY2xh aW1zIiBpcyBlc3RhYmxpc2hlZCBlYXJsaWVyIGluIHRoZQ0KICAgID4gZG9jdW1lbnQuDQogICAg DQogICAgSSByZWFsaXplZCB0aGF0IG15IHN1Z2dlc3RlZCB0ZXh0IHRvb2sgYXdheSB0b28gbXVj aCwgYW5kIHdhcyBnb2luZyB0byBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6DQoNCiAgICAgICAgIlRo ZSByZWdpc3RyYXIgdmFsaWRhdGVzIHRoZSBhY2Nlc3MgdG9rZW4uIEluIHN0ZXBzIFs1XSBhbmQg WzZdLCB0aGUgcmVnaXN0cmFyDQogICAgICAgIHBlcmZvcm1zIGFuIGludHJvc3BlY3Rpb24gW1JG Qzc2NjJdLiBUaGUgaW50cm9zcGVjdGlvbiBwcm9jZWR1cmUgaXMgb3B0aW9uYWwsIGFuZCBtaWdo dA0KICAgICAgICBiZSBwZXJmb3JtZWQgYnkgdGhlIHJlZ2lzdHJhciBpZiB0aGUgYWNjZXNzIHRv a2VuIGlzIGEgcmVmZXJlbmNlIHRva2VuLiINCg0KICAgIEJ1dCwgSSB0aGluayB0aGUgdGV4dCB5 b3Ugc3VnZ2VzdCBpcyBiZXR0ZXIgOikNCg0KICAgIEluIGFkZGl0aW9uLCB3ZSB3ZXJlIHRoaW5r aW5nIGFib3V0IGFsc28gaW5kaWNhdGUgdGhlIG9wdGlvbmFsaXR5IGluIHRoZSBmbG93IGl0c2Vs ZjoNCiANCiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IFszXSBIVFRQIFBPU1Qg L2ludHJvc3BlY3QgICAgIHwNCiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICB7YWNjZXNzX3Rva2VufSAgICAgICAgICAgICAgICAgICAgIHwNCiAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgIChPUFRJT05BTCkgICAgICAgICAgICAgICAgICAgICAg ICB8DQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgWzRdIDIwMCBPSyB7bWV0YWRhdGF9 ICAgICAgICAgICB8DQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAo T1BUSU9OQUwpICAgICAgICAgICAgICAgICAgICAgICAgfA0KICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCg0K ICAgIC4uLg0KICAgICAgICAgDQogICAgPj4gICAgID4+PiAgICBJJ2QgYWxzbyBzdWdnZXN0IGEg cXVpY2sgbm90ZSB0aGF0IFRMUyByZW1haW5zIGZpbmUgZm9yIHByb3RlY3RpbmcgdGhlDQogICAg Pj4gICAgID4+PiAgICBVQUMvQVMgaW50ZXJhY3Rpb24gd2hlcmUgdGhlIHJlZnJlc2ggdG9rZW4g aXMgdXNlZC4NCiAgICA+PiAgICAgPj4gICANCiAgICA+PiAgICAgPj4gSSBjYW4gZG8gdGhhdC4N CiAgICA+PiAgICAgPj4gDQogICAgPj4gICAgID4+IEkgY291bGQgYWxzbyBzYXkgIipTSVAqIGVu ZHBvaW50cyB0aGF0IHN1cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9uLi4uIi4NCiAgICA+PiAgICAg Pg0KICAgID4+ICAgICA+IEVpdGhlciBzb3VuZHMgZ29vZC4NCiAgICA+PiAgICAgDQogICAgPj4g ICAgTXkgc3VnZ2VzdGlvbiB3YXMgdG8gZG8gYm90aCBjaGFuZ2VzIDopIFNvbWV0aGluZyBsaWtl Og0KICAgID4+IA0KICAgID4+ICAgICJTSVAgZW5kcG9pbnRzIHRoYXQgc3VwcG9ydCB0aGlzIHNw ZWNpZmljYXRpb24gTVVTVCB1c2UgZW5jcnlwdGVkIA0KICAgID4+ICAgIEpTT04gV2ViIFRva2Vu cyAoSldUKSBbUkZDNzUxOV0gZm9yIGVuY29kaW5nIGFuZCBwcm90ZWN0aW5nIA0KICAgID4+ICAg IGFjY2VzcyB0b2tlbnMgd2hlbiB0aGV5IGFyZSBpbmNsdWRlZCBpbiBTSVAgcmVxdWVzdHMsIHVu bGVzcyBzb21lIG90aGVyIG1lY2hhbmlzbSANCiAgICA+PiAgICBpcyB1c2VkIHRvIGd1YXJhbnRl ZSB0aGF0IG9ubHkgYXV0aG9yaXplZCBTSVAgZW5kcG9pbnRzIGhhdmUgYWNjZXNzIHRvIA0KICAg ID4+ICAgICB0aGUgYWNjZXNzIHRva2VuLiBUTFMgY2FuIHN0aWxsIGJlIHVzZWQgZm9yIHByb3Rl Y3RpbmcgdHJhZmZpYyBiZXR3ZWVuDQogICAgPj4gICAgIFNJUCBlbmRwb2ludHMgYW5kIHRoZSBB Uy4iDQogICAgPj4gDQogICAgPg0KICAgID4gQWguICBMb29rcyBnb29kIQ0KICAgIA0KICAgR29v ZCA6KQ0KDQogICAgUmVnYXJkcywNCg0KICAgIENocmlzdGVyDQoNCg0KDQoNCg0KDQogICAgDQog ICAgPiAgDQogICAgPiAgICAgU2VjdGlvbiAyLjINCiAgICA+ICAgICAgICAgDQogICAgPiAgICAg Pj4+ICAgICAgIGF1dGhvcml6YXRpb24gY3JlZGVudGlhbHMgYWNjZXB0YWJsZSB0byBpdCwgaXQg U0hPVUxEIGNoYWxsZW5nZSB0aGUNCiAgICA+ICAgICA+Pj4gICAgICAgcmVxdWVzdCBieSBzZW5k aW5nIGEgNDAxIChVbmF1dGhvcml6ZWQpIHJlc3BvbnNlLiAgVG8gaW5kaWNhdGUgdGhhdA0KICAg ID4gICAgID4+PiAgICAgICBpdCBpcyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBhY2Nlc3MgdG9rZW4g YXMgYSBjcmVkZW50aWFsLCB0aGUgVUFTLw0KICAgID4gICAgID4+PiAgICAgICBSZWdpc3RyYXIg TVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGljYXRpb24gaGVhZGVyIGZpZWxkIGluIHRoZQ0K ICAgID4gICAgID4+PiAgICAgICByZXNwb25zZSB0aGF0IGluZGljYXRlcyAiQmVhcmVyIiBzY2hl bWUgYW5kIGluY2x1ZGVzIGFuIGFkZHJlc3Mgb2YgYW4NCiAgICA+ICAgICA+Pj4gICAgDQogICAg PiAgICAgPj4+ICAgIG5pdCg/KTogSSdkIGNvbnNpZGVyIGp1c3QgbWFraW5nIHRoaXMgYSBkZWNs YXJhdGl2ZSBzdGF0ZW1lbnQsIGEgbGEgInRoZQ0KICAgID4gICAgID4+PiAgICBVQVMvcmVnaXN0 cmFyIGluY2x1ZGVzIGEgUHJveHktQXV0aGVudGljYXRpb24gaGVhZGVyIGZpZWxkIHdpdGggdGhl ICJCZWFyZXIiDQogICAgPiAgICAgPj4+ICAgIHNjaGVtZSB0byBpbmRpY2F0ZSB0aGF0IGl0IGlz IHdpbGxpbmcgdG8gYWNjZXB0IGFuIGFjY2VzcyB0b2tlbiBhcyBhDQogICAgPiAgICAgPj4+ICAg IGNyZWRlbnRpYWwiICAoYnV0IHRoYXQgd29yZGluZyBpcyBpbmNvbXBsZXRlIGFuZCB3b3VsZCBu ZWVkIHRvIGJlIGZsZXNoZWQNCiAgICA+ICAgICA+Pj4gICAgb3V0IGEgYml0IG1vcmUpLg0KICAg ID4gICAgID4+IA0KICAgID4gICAgID4+IEkgdGhpbmsgdGhhdCB3b3VsZCBiZSB3ZWlyZC4gQmVj YXVzZSwgZmlyc3Qgd2Ugc2F5IHRoYXQgdGhlIFVBUy9SZWdpc3RyYXIgU0hPVUxEIGNoYWxsZW5n ZSwgYW5kIHdpdGggeW91cg0KICAgID4gICAgID4+IHN1Z2dlc3Rpb24gdGhlIHRleHQgd291bGQg c2F5IHRoYXQgdGhlIFVBUy9SZWdpc3RyYXIgTVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGlj YXRpb24gaGVhZGVyIGZpZWxkIGV2ZW4NCiAgICA+ICAgICA+PiBpZiBpdCBkb2VzIE5PVCBjaGFs bGVuZ2UgdGhlIHJlcXVlc3QuDQogICAgPiAgICAgPj4gDQogICAgPiAgICAgPj4gUGVyaGFwczoN CiAgICA+ICAgICA+PiANCiAgICA+ICAgICA+PiAiSWYgdGhlIFVBUy9SZWdpc3RyYXIgY2hvb3Nl cyB0byBjaGFsbGVuZ2UgdGhlIHJlcXVlc3QsIGFuZCBpcyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBh Y2Nlc3MgdG9rZW4gYXMgYSBjcmVkZW50aWFsLCB0aGUgVUFTL1JlZ2lzdHJhciBNVVNUIGluY2x1 ZGUgYS4uLiINCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBUaGlzIHZlcnNpb24gZG9lcyBnZXQg cmlkIG9mIHRoZSBjb25mdXNpb24gYWJvdXQgd2hldGhlciB0aGUgTVVTVCBpcw0KICAgID4gICAg ID4gY29uZGl0aW9uYWwgdGhhdCBJIHdhbnRlZCB0byBhZGRyZXNzLCB0aGFua3MuICAoSSBzZWUg SSBkaWRuJ3QgYWN0dWFsbHkgc2F5DQogICAgPiAgICAgPiB3aHkgSSBwcm9wb3NlZCB0aGUgY2hh bmdlIEkgZGlkLCB3aG9vcHMuKQ0KICAgID4gDQogICAgPiAgICAuLi4NCiAgICA+IA0KICAgID4g ICAgID4+PiAgICAgICBbUkZDNzUxOV0uICBJZiB0aGUgdG9rZW4gcHJvdmlkZWQgaXMgYW4gZXhw aXJlZCBhY2Nlc3MgdG9rZW4sIHRoZW4NCiAgICA+ICAgICA+Pj4gICAgICAgdGhlIFVBUyBNVVNU IHJlcGx5IHdpdGggNDAxIFVuYXV0aG9yaXplZCwgYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMgb2YN CiAgICA+ICAgICA+Pj4gICAgICAgW1JGQzY3NTBdLiAgSWYgdGhlIHZhbGlkYXRpb24gaXMgc3Vj Y2Vzc2Z1bCwgdGhlIFVBUy9SZWdpc3RyYXIgY2FuDQogICAgPiAgICAgPj4+ICAgICAgIGNvbnRp bnVlIHRvIHByb2Nlc3MgdGhlIHJlcXVlc3QgdXNpbmcgbm9ybWFsIFNJUCBwcm9jZWR1cmVzLiAg SWYgdGhlDQogICAgPiAgICAgPj4+ICAgICAgIHZhbGlkYXRpb24gZmFpbHMsIHRoZSBVQVMvUmVn aXN0cmFyIE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0Lg0KICAgID4gICAgID4+PiAgICANCiAgICA+ ICAgICA+Pj4gICAgSXMgImV4cGlyZWQiIHRoZSBvbmx5IGNhc2UgdGhhdCBzaG91bGQgZ2V0IGEg NDAxIHZzLiBvdXRyaWdodCByZWplY3Rpb24sIGFzDQogICAgPiAgICAgPj4+ICAgIHN0YXRlZCBo ZXJlPw0KICAgID4gICAgID4+IA0KICAgID4gICAgID4+IDQwMSBpcyBzZW50IGFsc28gaW4gdGhl IGNhc2Ugd2hlcmUgdGhlIHZhbGlkYXRpb24gZmFpbHMuIEkgd2lsbCBjbGFyaWZ5IHRoYXQuDQog ICAgPiAgICAgDQogICAgPiAgICAuLi4NCiAgICA+IA0KICAgID4gICAgIFNlY3Rpb24gMi4zDQog ICAgPiAgICAgICAgIA0KICAgID4gICAgID4+PiAgICAgICBzZW5kaW5nIGEgNDA3IChQcm94eSBB dXRoZW50aWNhdGlvbiBSZXF1aXJlZCkgcmVzcG9uc2UuICBUbyBpbmRpY2F0ZQ0KICAgID4gICAg ID4+PiAgICAgICB0aGF0IGl0IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIGFjY2VzcyB0b2tlbiBh cyBhIGNyZWRlbnRpYWwsIHRoZQ0KICAgID4gICAgID4+PiAgICAgICBwcm94eSBNVVNUIGluY2x1 ZGUgYSBQcm94eS1BdXRoZW50aWNhdGlvbiBoZWFkZXIgZmllbGQgaW4gdGhlDQogICAgPiAgICAg Pj4+ICAgICAgIHJlc3BvbnNlIHRoYXQgaW5kaWNhdGVzICJCZWFyZXIiIHNjaGVtZSBhbmQgaW5j bHVkZXMgYW4gYWRkcmVzcyB0byBhbg0KICAgID4gICAgID4+PiAgICANCiAgICA+ICAgICA+Pj4g ICAgW3NhbWUgY29tbWVudCBhcyBhYm92ZSBhYm91dCBub3JtYXRpdmUgdnMuIGRlY2xhcmF0aXZl IHN0YXRlbWVudF0NCiAgICA+ICAgICA+Pj4gICAgQWxzbywgcGxlYXNlIGtlZXAgdGhlIHRleHQg cGFyYWxsZWwgYmV0d2VlbiBzZWN0aW9ucyAtLSB0aGlzIGNvcHkgaGFzIGF0DQogICAgPiAgICAg Pj4+ICAgIGxlYXN0IG9uZSBuaXQgKCJhZGRyZXNzIHRvIGFuIiB2cy4gImFkZHJlc3Mgb2YgYW4i KS4NCiAgICA+ICAgICA+PiAgIA0KICAgID4gICAgID4+IEkgd2lsbCBmaXggdGhpcyBpbiB0aGUg c2FtZSB3YXkuDQogICAgPiAgICAgICANCiAgICA+ICAgIC0tLS0NCiAgICA+ICAgICAgICANCiAg ICA+ICAgICBTZWN0aW9uIDUNCiAgICA+ICAgICAgICAgDQogICAgPiAgICAgPj4+ICAgIFdlIHNo b3VsZCBwcm9iYWJseSBub3RlIHRoYXQgU0lQIG1ha2VzIG11Y2ggaGVhdmllciB1c2Ugb2YgcHJv eGllcyB0aGFuIGlzDQogICAgPiAgICAgPj4+ICAgIGNvbW1vbiBpbiB0aGUgd2ViIHdvcmxkIG9m IE9BdXRoLg0KICAgID4gICAgID4+IA0KICAgID4gICAgID4+IE1heWJlIHNvbWV0aGluZyBsaWtl Og0KICAgID4gICAgID4+IA0KICAgID4gICAgID4+ICJIb3dldmVyLCBTSVAgbWFrZXMgaGF2ZSB1 c2Ugb2YgaW50ZXJtZWRpYXJ5IFNJUCBwcm94aWVzLCBhbmQgVExTIG9ubHkgZ3VhcmFudGVlcyBo b3AtdG8taG9wIHByb3RlY3Rpb24gd2hlbiB1c2VkIHRvDQogICAgPiAgICAgPj4gICAgcHJvdGVj dCBTSVAgc2lnbmFsaW5nLiINCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBTdXJlLCB0aGF0IHNo b3VsZCB3b3JrLg0KICAgID4gDQogICAgPiAgICAgLS0tDQogICAgPiANCiAgICA+ICAgICA+ID4g ICAgU2VjdGlvbiA4DQogICAgPiAgICAgPiA+ICAgIA0KICAgID4gICAgID4gPiAgICBJIHRoaW5r IFJGQ3MgODI1MiBhbmQgODQxNCBjb3VsZCBiZSBqdXN0IGluZm9ybWF0aXZlLg0KICAgID4gICAg ID4gICANCiAgICA+ICAgICA+IEkgY2FuIGZpeCB0aGF0Lg0KICAgID4gICAgIA0KICAgID4gICAg IC0tLQ0KICAgID4gDQogICAgPiBUaGUgY2hhbmdlcyBkb25lIHNvIGZhciBiYXNlZCBvbiB5b3Vy IElFU0cgcmV2aWV3IGNhbiBiZSBmb3VuZCBpbiB0aGUgZm9sbG93aW5nIHB1bGwgcmVxdWVzdCBj b21taXQ6DQogICAgPiANCiAgICA+IGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJs P2s9OGU2Mjk3Y2MtZDJlOGI1MDMtOGU2MmQ3NTctMGNjNDdhZDkzZWE0LWRlMzg0ZTcwMWE1MDgx OTImcT0xJmU9ZTYwMWJiYjQtNzY5NS00YzgyLWExMWMtMzRiNjhiNTEwOWRmJnU9aHR0cHMlM0El MkYlMkZnaXRodWIuY29tJTJGcmlmYWF0LWlldGYlMkZkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRv a2VuLWF1dGhueiUyRnB1bGwlMkY3JTJGY29tbWl0cyUyRjBmYzY1NTcxOWQ3ZTNjZWZjNzQxN2Iz ODJlNzY2MmMxZDljMTJkYmINCiAgICA+IA0KICAgID4gDQogICAgPiBSZWdhcmRzLA0KICAgID4g DQogICAgPiBDaHJpc3Rlcg0KICAgID4gDQogICAgPiAgICAgDQogICAgPiANCiAgICANCg0K From nobody Mon Apr 27 10:15:39 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB8E3A11DC; Mon, 27 Apr 2020 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHRPDPnXzaLf; Mon, 27 Apr 2020 10:15:34 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 981783A11D9; Mon, 27 Apr 2020 10:15:33 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id k6so19712235iob.3; Mon, 27 Apr 2020 10:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W/FE5FP8LErWF2WGRik6R3zCmCTKodbCAS3N1YfGP+M=; b=hEB4n9FZB25hl0uz8jATFmclm2zmbNChCgQ5lj8uoEVqExIjuN8dZ1JmodFxpTrI5U Bz5YlX5iShmWxer7lg7zacM1n4ljG5eYEAj/jXfpxiBNuILQg06XL0Lf3U0BbtBqgUBT zmUxYvsznLxzlwfzm6e67gJS7jdKDA9ibzexpQAl0bKF2lGl6evgOp0ykpwoJ73bfY0U Ewm1MGvGViogg8OcUcU4t+w2gky77Q/CpeOY5U3mQuH9T4yybWZlci1P8lVMpAdjPyJX fs1+af1/8BSLoU9Qvov+Ue0SJkBgeDMnI+tNqWuRHromIgf/fbvw52NmQxU9U9DnKNHp 0vgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W/FE5FP8LErWF2WGRik6R3zCmCTKodbCAS3N1YfGP+M=; b=XAFRTusfYRt2yH1WKeGlWn5S/U19uDY6FOKdo+nKxH6uHdIsejPmCW1XiI/2nHPWe2 jrtplhVa1Zyy1I1hBcH/Lx1e1F+e78A2mB1/t8zj8i2TfFK25tutZYMPO+Pf58yQN1tJ FbierMD92f+GZkR4+kCD8/CxxyPzdzQOVUiHG8nQAiaHAKAV7wsrFAc1v01atqDVNWhi P2hdQ1bmfWYiglE+SAY8Nkud2pUQ4Ea7o62M4V1A8QMY86kd+6OGvUwifR9XaMyFgyro e93tVyCpPMDOJHAWKD4qPKqUwMfnXubjVIQqnauyX7qzjud/Hfah+YB7lV8NPkG07ScT OMvg== X-Gm-Message-State: AGi0PuYns/1b78pldd/hl227JPE26uDroPM58qbvj+Fd0klMeYrkuwku rDNTqCawR0KiURiJKbov28WznKZ78yzE2GvHZ2Q= X-Google-Smtp-Source: APiQypIch5Yn/10e/FrbJUOH+W1JBi0YiJFunKaeKaQjUBM54VsEEBqi38Dm+64fuJdG15mvSpTfuTk0oLrZjR0csnE= X-Received: by 2002:a05:6602:15ca:: with SMTP id f10mr14815914iow.51.1588007732642; Mon, 27 Apr 2020 10:15:32 -0700 (PDT) MIME-Version: 1.0 References: <31B5AC00-A9C5-4F02-8111-2ED9EB1D10D9@ericsson.com> <20200427161930.GY27494@kduck.mit.edu> In-Reply-To: <20200427161930.GY27494@kduck.mit.edu> From: Rifaat Shekh-Yusef Date: Mon, 27 Apr 2020 13:15:21 -0400 Message-ID: To: Benjamin Kaduk Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: multipart/alternative; boundary="000000000000ce128005a448dc4b" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 17:15:39 -0000 --000000000000ce128005a448dc4b Content-Type: text/plain; charset="UTF-8" I am fine with "opaque string". We have already updated the figure to indicate that the introspection step is optional. Regards, Rifaat On Mon, Apr 27, 2020 at 12:19 PM Benjamin Kaduk wrote: > Also inline, though the quoting situation doesn't look great in this MUA. > Apologies if I miss something... > > On Sat, Apr 25, 2020 at 11:10:50AM -0400, Rifaat Shekh-Yusef wrote: > > Inline... > > On Thu, Apr 23, 2020 at 5:04 PM Christer Holmberg > > wrote: > > > > Hi Benjamin, > > > > Thank You for the review! In this reply I will address some of your > > COMMENT issues, and indicate the ones that I want Rifaat to address. > > Your DISCUSS will be addressed in a separate realy. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > > > ---------------------------------------------------------------------- > > > > > Section 1 > > > > > > The OpenID Connect 1.0 specification [OPENID] defines a > simple > > > identity layer on top of the OAuth 2.0 protocol, which > enables > > > clients to verify the identity of the user based on the > > > > > > Please make it clear that these are OAuth/OIDC clients, not SIP > > clients. > > > > I'll leave this for Rifaat. > > > > Sure. > > > > > > --- > > > > > Section 1.3 > > > > > > OAuth 2.0 doesn't require the issuance of a Refresh token, but > the > > > discussion here implies that for the SIP case there will > always be > > a refresh > > > token. If we're profiling 6749 in this manner, we should be > more > > explicit > > > about the requirement to issue refresh tokens. > > > > I am not sure whether the intention is to say that there will > always be > > a refresh token. But, I'll leave this for Rifaat. > > > > I answered in this the reply to the DISCUSS > > > > > > > * ID Token: this token contains the SIP URI and other > > user-specific > > > details that will be consumed by the UAC. > > > > > > nit: I don't think we should use the definite article in "the > SIP > > URI" since > > > we haven't discussed any such SIP URI usage yet. That is, we > > should say > > > what it's used for, e.g., "a SIP URI associated with the user". > > > > I'll leave this for Rifaat. > > > > Sure. > > > > > > > * Structured Token: a token that consists of a structured > > object > > > that contains the claims associated with the token, > e.g. JWT > > as > > > defined in [RFC7519]. > > > > > > nit: comma after "e.g.". > > > > Will be fixed. > > > > > * Reference Token: a token that consists of a random string > > that is > > > used to obtain the details of the token and its > associated > > claims, > > > as defined in [RFC6749]. > > > > > > It doesn't technically have to be random (though in practice it > > should > > > contain signficant random elements); "opaque" might be better > > wording. > > > > I'll leave this for Rifaat. > > > > How about "opaque random string"? > > I'm still not entirely comfortable about that since it implies too much > (lack of) structure. We sometimes see this sort of thing described as an > "opaque handle", if that sounds better to you. > > > > > > Section 1.4.1 > > > > > > Perhaps Figure 1 could include some indication that steps 5 > and 6 > > are > > > optional/do not always occur (in the case when the access > token is > > a > > > self-contained JWT)? > > > > I'll leave this for Rifaat. > > > > This is explicitly mentioned in the text, but I agree that it would be > > helpful to include it in the figure. > > > > > > > In step [2], the registrar challenges the UA, by sending a > SIP > > 401 > > > (Unauthorized) response to the REGISTER request. In the > > response, > > > the registrar includes information about the AS to contact > in > > order > > > to obtain a token. > > > > > > The UAC needs to have a preconfigured whitelist of acceptable > ASes > > in order > > > to avoid directing the user's credentials to malicious sites. > > > > This is related to your DISCUSS, so it will be addressed as part of > > that. > > > > > The registrar validates the access token. If the access > token > > is a > > > reference token, the registrar MAY perform an introspection > > > [RFC7662], as in steps [5] and [6], in order to obtain more > > > information about the access token and its scope, per > [RFC7662]. > > > > > > I think we could tighten up the normative language a bit here. > > > In particular, the registrar MUST validate the token in some > > fashion; for > > > reference tokens, the main ways to do that are either > inspection or > > > (essentially) being the party that issued the token in the > first > > place. > > > > > > Otherwise, after the registrar validates the token to make > sure > > it > > > was signed by a trusted entity, it inspects its claims and > acts > > upon > > > it. > > > > > > I think we can also be more specific than "a trusted entity" > -- in > > this > > > flow, it looks like the registrar should know exactly which > entity > > should > > > have signed the token in question (for the user in question), > and > > should not > > > accept a signed token from a different entity that happens to > be > > trusted to > > > issue other tokens. > > > > The text in Section 2.2. mandates the validation: > > > > "When a UAS/Registrar receives a SIP request that contains an > > Authorization header field with an access token, the > UAS/Registrar > > MUST validate the access token,..." > > > > I don't think we should put too much normative text into the example > > flows. > > > > > Section 1.4.2 > > > > > > (Similarly, Figure 2 could note that steps 3 and 4 do not > always > > occur, and > > > the text about token validation should remain parallel between > > examples.) > > > > I'll leave this for Rifaat. > > > > Again, this is explicitly mentioned in the text, but I agree that it > would > > be helpful to include it in the figure. > > Yes, I agree that the text is clear, but if it's easy to put something in > the figure as well, it seems worth doing so. > > > > > ---- > > > > > Section 2 > > > > > > I note that RFC 3261 explicitly disclaims any definition of > > authorization > > > systems, which is not true for this document, given that OAuth > is > > an > > > authorization system :) > > > > RFC 3261 only says that the RFC does not recommend or discuss any > > authorization system. > > > > > Section 2.1.1 > > > > > > Required) response with a Proxy-Authenticate header field. > If > > the > > > WWW-Authenticate or Proxy-Authenticate header field > indicates > > > "Bearer" scheme authentication and contains an address to an > > > authorization server, the UAC contacts the authorization > server > > in > > > order to obtain tokens, and includes the requested scopes, > based > > on a > > > local configuration (Figure 1). > > > > > > [whitelist of allowed ASes, again] > > > > Will be addressed when the DISCUSS is addressed. > > > > > The detailed OAuth2 procedure to authenticate the user and > > obtain > > > these tokens is out of scope of this document. The address > of > > the > > > authorization server might already be known to the UAC via > > > configuration. In which case, the UAC can contact the > > authorization > > > server for tokens before it sends a SIP request (Figure 2). > > > > > > nit: I think that "in which case" functions as a conjunction, > which > > makes > > > this an incomplete sentence. > > > > The text was suggested by one of the reviewers, but I agree it > sounds > > incomplete. > > > > Perhaps "In such cases"? > > > > > The tokens returned to the UAC depend on the type of > > authorization > > > server (AS): an OAuth AS provides an access token and > refresh > > token > > > [RFC6749]. The UAC provides the access token to the SIP > servers > > to > > > > > > Again, this implies that refresh tokens are always issued; RFC > 6749 > > is quite > > > clear that "issuing a refresh token is optional at the > discretion > > of the > > > authorization server". > > > > I'll leave this for Rifaat. > > > > As I mentioned in the reply to the DISCUSS, we will clarify this. > > > > > > > authorize UAC's access to the service. The UAC uses the > refresh > > > token only with the AS to get a new access token and refresh > > token > > > before the expiry of the current access token (see > [RFC6749], > > section > > > > > > (New refresh token is also optional.) > > > > I'll leave this for Rifaat. > > > > As I mentioned in the reply to the DISCUSS, we will clarify this. > > > > > > > 1.5 Refresh Token for details). An OpenID Connect server > > returns an > > > additional ID-Token containing the SIP URI and other > > user-specific > > > details that will be consumed by the UAC. > > > > > > [same comment as above about "the SIP URI".] > > > > I'll leave this for Rifaat. > > > > Ok > > > > > > > If the UAC receives a 401/407 response with multiple WWW- > > > Authenticate/Proxy-Authenticate header fields, providing > > challenges > > > using different authentication schemes for the same realm, > the > > UAC > > > selects one or more of the provided schemes (based on local > > policy) > > > and provides credentials for those schemes. > > > > > > RFC 3261 seems to be written in a world that assumed that > Basic and > > Digest > > > are the only defined HTTP authentication schemes, and since it > > prohibits > > > Basic, that there would only be one authentication challenge > (type) > > > possible. This text righly acknowledges that we are opening > the > > field up > > > and could have cases where multiple authentication schemes are > > possible; > > > however, it goes even further and admits the possibility of > using > > them > > > simultaneously. It seems like this places an onus on us to > give > > some > > > indication of the semantics when multiple schemes are used at > the > > same time. > > > Do the authenticated identities need to match? Or are we > asserting > > that > > > both/all identities are consenting to the request in > question? (If > > we don't > > > have a concrete use case in mind, perhaps the "or more" is just > > opening a > > > box that we don't need to open right now.) > > > > I can modify as suggested. > > > > (Personally, I have never seen multiple schemes in a deployment.) > > > > > Section 2.1.2 > > > > > > access to it. Endpoints that support this specification > MUST > > support > > > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and > > protecting > > > access tokens when they are included in SIP requests, unless > > some > > > other mechanism is used to guarantee that only authorized > SIP > > > endpoints have access to the access token. > > > > > > I think we may want "MUST support" (always) and "MUST use, > unless > > some other > > > mechanism". > > > > Based on another review, I suggested to change to "MUST use". I am > not > > sure whether we need to keep "MUST support". > > > > > I'd also suggest a quick note that TLS remains fine for > protecting > > the > > > UAC/AS interaction where the refresh token is used. > > > > I can do that. > > > > I could also say "*SIP* endpoints that support this > specification...". > > > > > Whatever is done, please harmonize with Section 5 that has > > essentially the > > > same text. > > > > Will do. > > > > > Section 2.1.3 > > > > > > Based on local policy, the UAC MAY include an access token > that > > has > > > been used for another binding associated with the same > Address > > Of > > > Record (AOR) in the request. > > > > > > Just to check: there's no real privacy considerations with such > > use, as its > > > the same parties interacting and there are other identifiers > (e.g., > > IP > > > addresses) to confirm that it's the same client communicating > to > > the server? > > > > I'll leave this for Rifaat. > > > > I would not rely only on an IP address, but the answer is yes. > > Okay. > > > > > > > > Also, is it clear what will be done (new token request) when > the > > MAY is not > > > heeded? > > > > I'll leave this for Rifaat. > > > > The Client would need to obtain a new access token. I will clarify > this. > > Thanks. > > > > > > Section 2.1.4 > > > > > > The text here just talks about "a valid access token" and > similar, > > without > > > saying a whole lot about it being related in any way to the > > specifics of the > > > authentication challenge. Is there something useful to say > about, > > e.g., the > > > token in question having been issued by the authorization > server > > indicated > > > in the challenge? > > > > I'll leave this for Rifaat. > > > > Sure. > > > > > > > Section 2.2 > > > > > > authorization credentials acceptable to it, it SHOULD > challenge > > the > > > request by sending a 401 (Unauthorized) response. To > indicate > > that > > > it is willing to accept an access token as a credential, the > > UAS/ > > > Registrar MUST include a Proxy-Authentication header field > in > > the > > > response that indicates "Bearer" scheme and includes an > address > > of an > > > > > > nit(?): I'd consider just making this a declarative statement, > a la > > "the > > > UAS/registrar includes a Proxy-Authentication header field > with the > > "Bearer" > > > scheme to indicate that it is willing to accept an access > token as > > a > > > credential" (but that wording is incomplete and would need to > be > > fleshed > > > out a bit more). > > > > I think that would be weird. Because, first we say that the > > UAS/Registrar SHOULD challenge, and with your suggestion the text > would > > say that the UAS/Registrar MUST include a Proxy-Authentication > header > > field even if it does NOT challenge the request. > > > > Perhaps: > > > > "If the UAS/Registrar chooses to challenge the request, and is > willing > > to accept an access token as a credential, the UAS/Registrar MUST > > include a..." > > > > > authorization server from which the originator can obtain an > > access > > > token. > > > > > > nit: "address of" an AS, does that mean bare IP address only > or is > > a DNS > > > name okay? > > > > I'll leave this for Rifaat. > > > > I do not think that an IP address is appropriate, and what I have in > mind > > is a DNS name. > > I will clarify it. > > Ah, DNS name sounds better to me, too :) > > Thanks, > > Ben > > > > [RFC7519]. If the token provided is an expired access > token, > > then > > > the UAS MUST reply with 401 Unauthorized, as defined in > section > > 3 of > > > [RFC6750]. If the validation is successful, the > UAS/Registrar > > can > > > continue to process the request using normal SIP > procedures. If > > the > > > validation fails, the UAS/Registrar MUST reject the request. > > > > > > Is "expired" the only case that should get a 401 vs. outright > > rejection, as > > > stated here? > > > > 401 is sent also in the case where the validation fails. I will > clarify > > that. > > > > > Section 2.3 > > > > > > sending a 407 (Proxy Authentication Required) response. To > > indicate > > > that it is willing to accept an access token as a > credential, > > the > > > proxy MUST include a Proxy-Authentication header field in > the > > > response that indicates "Bearer" scheme and includes an > address > > to an > > > > > > [same comment as above about normative vs. declarative > statement] > > > Also, please keep the text parallel between sections -- this > copy > > has at > > > least one nit ("address to an" vs. "address of an"). > > > > I will fix this in the same way. > > > > > Section 3 > > > > > > If an access token is encoded as a JWT, it might contain a > list > > of > > > claims [RFC7519], some registered and some > > application-specific. The > > > > > > I don't think there's a question of whether a JWT will contain > a > > list of > > > claims :) > > > > Fair enough :) > > > > > Maybe "If the access token is encoded as a JWT, it will > contain a > > list of > > > claims [RFC7519], which may include both registered and > > application-specific > > > claims"? > > > > Looks good to me, but I'll leave this for Rifaat. > > > > Looks good to me too. > > Regards, > > Rifaat > > > > > > ---- > > > > > Section 4 > > > > > > This section claims to cover WWW-Authenticate. What > specification > > will the > > > SIP use of Bearer for Authorization operate under? > > > > RFC 6750. > > > > Section 2.1.3 says: > > > > "The UAC sends a REGISTER request with an Authorization header > field > > containing the response to the challenge, including the Bearer > scheme > > carrying a valid access token in the request, as specified in > > [RFC6750]." > > > > > challenge =/ ("Bearer" LWS bearer-cln *(COMMA > bearer-cln)) > > > > > > side note: is there a mnemonic for the "cln" in "bearer-cln"? > > > > RFC 3261 uses "cln" for digest. > > > > > bearer-cln = realm / scope / authz-server / error / > > > auth-param > > > > > > nit: realm is already included in auth-param, though I don't > see a > > harm in > > > calling it out explicitly. > > > > auth-param is used to allow possible new parameters in the future. > > > > > realm = > > > auth-param = > > > > > > RFC 3261 defers to RFC 2617 (now obsoleted by 7235) for both of > > these; we > > > could perhaps short-circuit the chain and say "defined in RFC > > 7235". > > > > We discussed this in the WG, and the outcome was to keep the same > > references as RFC 3261, since that is what people are implementing. > > > > Then, as a separate task, someone could update RFC 3261 with the new > > references. > > > > --- > > > > > Section 5 > > > > > > We should probably note that SIP makes much heavier use of > proxies > > than is > > > common in the web world of OAuth. > > > > Maybe something like: > > > > "However, SIP makes have use of intermediary SIP proxies, and TLS > only > > guarantees hop-to-hop protection when used to > > protect SIP signaling." > > > > > I'm happy to see that some privacy considerations are being > added > > in > > > response to Barry's review. > > > > Good :) > > > > --- > > > > > Section 8 > > > > > > I think RFCs 8252 and 8414 could be just informative. > > > > I can fix that. > > > > --- > > > > Regards, > > > > Christer > > --000000000000ce128005a448dc4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am fine with "opaque string".=

We have already updated the figure to= indicate that the introspection step is optional.

Regards,
=C2=A0Rifaat


On Mon, Apr 27, 2020 at 12:1= 9 PM Benjamin Kaduk <kaduk@mit.edu&= gt; wrote:
Also = inline, though the quoting situation doesn't look great in this MUA. Apologies if I miss something...

On Sat, Apr 25, 2020 at 11:10:50AM -0400, Rifaat Shekh-Yusef wrote:
>=C2=A0 =C2=A0 Inline...
>=C2=A0 =C2=A0 On Thu, Apr 23, 2020 at 5:04 PM Christer Holmberg
>=C2=A0 =C2=A0 <christer.holmberg@ericsson.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 Hi Benjamin,
>
>=C2=A0 =C2=A0 =C2=A0 Thank You for the review! In this reply I will add= ress some of your
>=C2=A0 =C2=A0 =C2=A0 COMMENT issues, and indicate the ones that I want = Rifaat to address.
>=C2=A0 =C2=A0 =C2=A0 Your DISCUSS will be addressed in a separate realy= .
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 --------------------------------------------------= --------------------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 COMMENT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 --------------------------------------------------= --------------------
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 1
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0The OpenID Connect = 1.0 specification [OPENID] defines a simple
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0identity layer on t= op of the OAuth 2.0 protocol, which enables
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0clients to verify t= he identity of the user based on the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Please make it clear that these = are OAuth/OIDC clients, not SIP
>=C2=A0 =C2=A0 =C2=A0 clients.
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 Sure.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 ---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 1.3
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 OAuth 2.0 doesn't require th= e issuance of a Refresh token, but the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 discussion here implies that for= the SIP case there will always be
>=C2=A0 =C2=A0 =C2=A0 a refresh
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 token.=C2=A0 If we're profil= ing 6749 in this manner, we should be more
>=C2=A0 =C2=A0 =C2=A0 explicit
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 about the requirement to issue r= efresh tokens.
>
>=C2=A0 =C2=A0 =C2=A0 I am not sure whether the intention is to say that= there will always be
>=C2=A0 =C2=A0 =C2=A0 a refresh token. But, I'll leave this for Rifa= at.
>
>=C2=A0 =C2=A0 I answered in this the reply to the DISCUSS
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 ID Token: t= his token contains the SIP URI and other
>=C2=A0 =C2=A0 =C2=A0 user-specific
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 details tha= t will be consumed by the UAC.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 nit: I don't think we should= use the definite article in "the SIP
>=C2=A0 =C2=A0 =C2=A0 URI" since
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 we haven't discussed any suc= h SIP URI usage yet.=C2=A0 That is, we
>=C2=A0 =C2=A0 =C2=A0 should say
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 what it's used for, e.g., &q= uot;a SIP URI associated with the user".
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 Sure.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Structured = Token: a token that consists of a structured
>=C2=A0 =C2=A0 =C2=A0 object
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that contai= ns the claims associated with the token, e.g.=C2=A0 JWT
>=C2=A0 =C2=A0 =C2=A0 as
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 defined in = [RFC7519].
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 nit: comma after "e.g."= ;.
>
>=C2=A0 =C2=A0 =C2=A0 Will be fixed.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Reference T= oken: a token that consists of a random string
>=C2=A0 =C2=A0 =C2=A0 that is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used to obt= ain the details of the token and its associated
>=C2=A0 =C2=A0 =C2=A0 claims,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 as defined = in [RFC6749].
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 It doesn't technically have = to be random (though in practice it
>=C2=A0 =C2=A0 =C2=A0 should
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 contain signficant random elemen= ts); "opaque" might be better
>=C2=A0 =C2=A0 =C2=A0 wording.
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 How about "opaque random string"?

I'm still not entirely comfortable about that since it implies too much=
(lack of) structure.=C2=A0 We sometimes see this sort of thing described as= an
"opaque handle", if that sounds better to you.

>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 1.4.1
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Perhaps Figure 1 could include s= ome indication that steps 5 and 6
>=C2=A0 =C2=A0 =C2=A0 are
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 optional/do not always occur (in= the case when the access token is
>=C2=A0 =C2=A0 =C2=A0 a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 self-contained JWT)?
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 This is explicitly mentioned in the text, but I agree tha= t it would be
>=C2=A0 =C2=A0 helpful to include it in the figure.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0In step [2], the re= gistrar challenges the UA, by sending a SIP
>=C2=A0 =C2=A0 =C2=A0 401
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0(Unauthorized) resp= onse to the REGISTER request.=C2=A0 In the
>=C2=A0 =C2=A0 =C2=A0 response,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0the registrar inclu= des information about the AS to contact in
>=C2=A0 =C2=A0 =C2=A0 order
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0to obtain a token.<= br> >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 The UAC needs to have a preconfi= gured whitelist of acceptable ASes
>=C2=A0 =C2=A0 =C2=A0 in order
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 to avoid directing the user'= s credentials to malicious sites.
>
>=C2=A0 =C2=A0 =C2=A0 This is related to your DISCUSS, so it will be add= ressed as part of
>=C2=A0 =C2=A0 =C2=A0 that.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0The registrar valid= ates the access token.=C2=A0 If the access token
>=C2=A0 =C2=A0 =C2=A0 is a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0reference token, th= e registrar MAY perform an introspection
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7662], as in st= eps [5] and [6], in order to obtain more
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0information about t= he access token and its scope, per [RFC7662].
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I think we could tighten up the = normative language a bit here.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 In particular, the registrar MUS= T validate the token in some
>=C2=A0 =C2=A0 =C2=A0 fashion; for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 reference tokens, the main ways = to do that are either inspection or
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 (essentially) being the party th= at issued the token in the first
>=C2=A0 =C2=A0 =C2=A0 place.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Otherwise, after th= e registrar validates the token to make sure
>=C2=A0 =C2=A0 =C2=A0 it
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0was signed by a tru= sted entity, it inspects its claims and acts
>=C2=A0 =C2=A0 =C2=A0 upon
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0it.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I think we can also be more spec= ific than "a trusted entity" -- in
>=C2=A0 =C2=A0 =C2=A0 this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 flow, it looks like the registra= r should know exactly which entity
>=C2=A0 =C2=A0 =C2=A0 should
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 have signed the token in questio= n (for the user in question), and
>=C2=A0 =C2=A0 =C2=A0 should not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 accept a signed token from a dif= ferent entity that happens to be
>=C2=A0 =C2=A0 =C2=A0 trusted to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 issue other tokens.
>
>=C2=A0 =C2=A0 =C2=A0 The text in Section 2.2. mandates the validation:<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"When a UAS/Registrar receives a= SIP request that contains an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authorization header field with an ac= cess token, the UAS/Registrar
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST validate the access token,...&qu= ot;
>
>=C2=A0 =C2=A0 =C2=A0 I don't think we should put too much normative= text into the example
>=C2=A0 =C2=A0 =C2=A0 flows.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 1.4.2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 (Similarly, Figure 2 could note = that steps 3 and 4 do not always
>=C2=A0 =C2=A0 =C2=A0 occur, and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the text about token validation = should remain parallel between
>=C2=A0 =C2=A0 =C2=A0 examples.)
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 Again, this is explicitly mentioned in the text, but I ag= ree that it would
>=C2=A0 =C2=A0 be helpful to include it in the figure.

Yes, I agree that the text is clear, but if it's easy to put something = in
the figure as well, it seems worth doing so.

>
>=C2=A0 =C2=A0 =C2=A0 ----
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I note that RFC 3261 explicitly = disclaims any definition of
>=C2=A0 =C2=A0 =C2=A0 authorization
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 systems, which is not true for t= his document, given that OAuth is
>=C2=A0 =C2=A0 =C2=A0 an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 authorization system :)
>
>=C2=A0 =C2=A0 =C2=A0 RFC 3261 only says that the RFC does not recommend= or discuss any
>=C2=A0 =C2=A0 =C2=A0 authorization system.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2.1.1
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Required) response = with a Proxy-Authenticate header field.=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0WWW-Authenticate or= Proxy-Authenticate header field indicates
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0"Bearer" = scheme authentication and contains an address to an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization serve= r, the UAC contacts the authorization server
>=C2=A0 =C2=A0 =C2=A0 in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0order to obtain tok= ens, and includes the requested scopes, based
>=C2=A0 =C2=A0 =C2=A0 on a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0local configuration= (Figure 1).
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 [whitelist of allowed ASes, agai= n]
>
>=C2=A0 =C2=A0 =C2=A0 Will be addressed when the DISCUSS is addressed. >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0The detailed OAuth2= procedure to authenticate the user and
>=C2=A0 =C2=A0 =C2=A0 obtain
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0these tokens is out= of scope of this document.=C2=A0 The address of
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization serve= r might already be known to the UAC via
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration.=C2= =A0 In which case, the UAC can contact the
>=C2=A0 =C2=A0 =C2=A0 authorization
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0server for tokens b= efore it sends a SIP request (Figure 2).
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 nit: I think that "in which= case" functions as a conjunction, which
>=C2=A0 =C2=A0 =C2=A0 makes
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 this an incomplete sentence.
>
>=C2=A0 =C2=A0 =C2=A0 The text was suggested by one of the reviewers, bu= t I agree it sounds
>=C2=A0 =C2=A0 =C2=A0 incomplete.
>
>=C2=A0 =C2=A0 =C2=A0 Perhaps "In such cases"?
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0The tokens returned= to the UAC depend on the type of
>=C2=A0 =C2=A0 =C2=A0 authorization
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0server (AS): an OAu= th AS provides an access token and refresh
>=C2=A0 =C2=A0 =C2=A0 token
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6749].=C2=A0 Th= e UAC provides the access token to the SIP servers
>=C2=A0 =C2=A0 =C2=A0 to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Again, this implies that refresh= tokens are always issued; RFC 6749
>=C2=A0 =C2=A0 =C2=A0 is quite
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 clear that "issuing a refre= sh token is optional at the discretion
>=C2=A0 =C2=A0 =C2=A0 of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 authorization server".
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 As I mentioned in the reply to the DISCUSS, we will clari= fy this.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0authorize UAC's= access to the service.=C2=A0 The UAC uses the refresh
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0token only with the= AS to get a new access token and refresh
>=C2=A0 =C2=A0 =C2=A0 token
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0before the expiry o= f the current access token (see [RFC6749],
>=C2=A0 =C2=A0 =C2=A0 section
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 (New refresh token is also optio= nal.)
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 As I mentioned in the reply to the DISCUSS, we will clari= fy this.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A01.5 Refresh Token f= or details).=C2=A0 An OpenID Connect server
>=C2=A0 =C2=A0 =C2=A0 returns an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0additional ID-Token= containing the SIP URI and other
>=C2=A0 =C2=A0 =C2=A0 user-specific
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0details that will b= e consumed by the UAC.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 [same comment as above about &qu= ot;the SIP URI".]
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 Ok
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0If the UAC receives= a 401/407 response with multiple WWW-
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Authenticate/Proxy-= Authenticate header fields, providing
>=C2=A0 =C2=A0 =C2=A0 challenges
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0using different aut= hentication schemes for the same realm, the
>=C2=A0 =C2=A0 =C2=A0 UAC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0selects one or more= of the provided schemes (based on local
>=C2=A0 =C2=A0 =C2=A0 policy)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0and provides creden= tials for those schemes.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 RFC 3261 seems to be written in = a world that assumed that Basic and
>=C2=A0 =C2=A0 =C2=A0 Digest
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 are the only defined HTTP authen= tication schemes, and since it
>=C2=A0 =C2=A0 =C2=A0 prohibits
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Basic, that there would only be = one authentication challenge (type)
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 possible.=C2=A0 This text righly= acknowledges that we are opening the
>=C2=A0 =C2=A0 =C2=A0 field up
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 and could have cases where multi= ple authentication schemes are
>=C2=A0 =C2=A0 =C2=A0 possible;
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 however, it goes even further an= d admits the possibility of using
>=C2=A0 =C2=A0 =C2=A0 them
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 simultaneously.=C2=A0 It seems l= ike this places an onus on us to give
>=C2=A0 =C2=A0 =C2=A0 some
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 indication of the semantics when= multiple schemes are used at the
>=C2=A0 =C2=A0 =C2=A0 same time.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Do the authenticated identities = need to match?=C2=A0 Or are we asserting
>=C2=A0 =C2=A0 =C2=A0 that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 both/all identities are consenti= ng to the request in question?=C2=A0 (If
>=C2=A0 =C2=A0 =C2=A0 we don't
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 have a concrete use case in mind= , perhaps the "or more" is just
>=C2=A0 =C2=A0 =C2=A0 opening a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 box that we don't need to op= en right now.)
>
>=C2=A0 =C2=A0 =C2=A0 I can modify as suggested.
>
>=C2=A0 =C2=A0 =C2=A0 (Personally, I have never seen multiple schemes in= a deployment.)
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2.1.2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0access to it.=C2=A0= Endpoints that support this specification MUST
>=C2=A0 =C2=A0 =C2=A0 support
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0encrypted JSON Web = Tokens (JWT) [RFC7519] for encoding and
>=C2=A0 =C2=A0 =C2=A0 protecting
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0access tokens when = they are included in SIP requests, unless
>=C2=A0 =C2=A0 =C2=A0 some
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0other mechanism is = used to guarantee that only authorized SIP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0endpoints have acce= ss to the access token.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I think we may want "MUST s= upport" (always) and "MUST use, unless
>=C2=A0 =C2=A0 =C2=A0 some other
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 mechanism".
>
>=C2=A0 =C2=A0 =C2=A0 Based on another review, I suggested to change to = "MUST use". I am not
>=C2=A0 =C2=A0 =C2=A0 sure whether we need to keep "MUST support&qu= ot;.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I'd also suggest a quick not= e that TLS remains fine for protecting
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 UAC/AS interaction where the ref= resh token is used.
>
>=C2=A0 =C2=A0 =C2=A0 I can do that.
>
>=C2=A0 =C2=A0 =C2=A0 I could also say "*SIP* endpoints that suppor= t this specification...".
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Whatever is done, please harmoni= ze with Section 5 that has
>=C2=A0 =C2=A0 =C2=A0 essentially the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 same text.
>
>=C2=A0 =C2=A0 =C2=A0 Will do.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2.1.3
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Based on local poli= cy, the UAC MAY include an access token that
>=C2=A0 =C2=A0 =C2=A0 has
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0been used for anoth= er binding associated with the same Address
>=C2=A0 =C2=A0 =C2=A0 Of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Record (AOR) in the= request.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Just to check: there's no re= al privacy considerations with such
>=C2=A0 =C2=A0 =C2=A0 use, as its
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the same parties interacting and= there are other identifiers (e.g.,
>=C2=A0 =C2=A0 =C2=A0 IP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 addresses) to confirm that it= 9;s the same client communicating to
>=C2=A0 =C2=A0 =C2=A0 the server?
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 I would not rely only on an IP address, but the answer is= yes.

Okay.

>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Also, is it clear what will be d= one (new token request) when the
>=C2=A0 =C2=A0 =C2=A0 MAY is not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 heeded?
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 The Client would need to obtain a new access token. I wil= l clarify this.

Thanks.

>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2.1.4
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 The text here just talks about &= quot;a valid access token" and similar,
>=C2=A0 =C2=A0 =C2=A0 without
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 saying a whole lot about it bein= g related in any way to the
>=C2=A0 =C2=A0 =C2=A0 specifics of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 authentication challenge.=C2=A0 = Is there something useful to say about,
>=C2=A0 =C2=A0 =C2=A0 e.g., the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 token in question having been is= sued by the authorization server
>=C2=A0 =C2=A0 =C2=A0 indicated
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 in the challenge?
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 Sure.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2.2
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization crede= ntials acceptable to it, it SHOULD challenge
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0request by sending = a 401 (Unauthorized) response.=C2=A0 To indicate
>=C2=A0 =C2=A0 =C2=A0 that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0it is willing to ac= cept an access token as a credential, the
>=C2=A0 =C2=A0 =C2=A0 UAS/
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0Registrar MUST incl= ude a Proxy-Authentication header field in
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0response that indic= ates "Bearer" scheme and includes an address
>=C2=A0 =C2=A0 =C2=A0 of an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 nit(?): I'd consider just ma= king this a declarative statement, a la
>=C2=A0 =C2=A0 =C2=A0 "the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 UAS/registrar includes a Proxy-A= uthentication header field with the
>=C2=A0 =C2=A0 =C2=A0 "Bearer"
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 scheme to indicate that it is wi= lling to accept an access token as
>=C2=A0 =C2=A0 =C2=A0 a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 credential"=C2=A0 (but that= wording is incomplete and would need to be
>=C2=A0 =C2=A0 =C2=A0 fleshed
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 out a bit more).
>
>=C2=A0 =C2=A0 =C2=A0 I think that would be weird. Because, first we say= that the
>=C2=A0 =C2=A0 =C2=A0 UAS/Registrar SHOULD challenge, and with your sugg= estion the text would
>=C2=A0 =C2=A0 =C2=A0 say that the UAS/Registrar MUST include a Proxy-Au= thentication header
>=C2=A0 =C2=A0 =C2=A0 field even if it does NOT challenge the request. >
>=C2=A0 =C2=A0 =C2=A0 Perhaps:
>
>=C2=A0 =C2=A0 =C2=A0 "If the UAS/Registrar chooses to challenge th= e request, and is willing
>=C2=A0 =C2=A0 =C2=A0 to accept an access token as a credential, the UAS= /Registrar MUST
>=C2=A0 =C2=A0 =C2=A0 include a..."
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0authorization serve= r from which the originator can obtain an
>=C2=A0 =C2=A0 =C2=A0 access
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0token.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 nit: "address of" an A= S, does that mean bare IP address only or is
>=C2=A0 =C2=A0 =C2=A0 a DNS
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 name okay?
>
>=C2=A0 =C2=A0 =C2=A0 I'll leave this for Rifaat.
>
>=C2=A0 =C2=A0 I do not think that an IP address is appropriate, and wha= t I have in mind
>=C2=A0 =C2=A0 is a DNS name.
>=C2=A0 =C2=A0 I will clarify it.

Ah, DNS name sounds better to me, too :)

Thanks,

Ben

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC7519].=C2=A0 If= the token provided is an expired access token,
>=C2=A0 =C2=A0 =C2=A0 then
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0the UAS MUST reply = with 401 Unauthorized, as defined in section
>=C2=A0 =C2=A0 =C2=A0 3 of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6750].=C2=A0 If= the validation is successful, the UAS/Registrar
>=C2=A0 =C2=A0 =C2=A0 can
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0continue to process= the request using normal SIP procedures.=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0validation fails, t= he UAS/Registrar MUST reject the request.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Is "expired" the only = case that should get a 401 vs. outright
>=C2=A0 =C2=A0 =C2=A0 rejection, as
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 stated here?
>
>=C2=A0 =C2=A0 =C2=A0 401 is sent also in the case where the validation = fails. I will clarify
>=C2=A0 =C2=A0 =C2=A0 that.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 2.3
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0sending a 407 (Prox= y Authentication Required) response.=C2=A0 To
>=C2=A0 =C2=A0 =C2=A0 indicate
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0that it is willing = to accept an access token as a credential,
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0proxy MUST include = a Proxy-Authentication header field in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0response that indic= ates "Bearer" scheme and includes an address
>=C2=A0 =C2=A0 =C2=A0 to an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 [same comment as above about nor= mative vs. declarative statement]
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Also, please keep the text paral= lel between sections -- this copy
>=C2=A0 =C2=A0 =C2=A0 has at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 least one nit ("address to = an" vs. "address of an").
>
>=C2=A0 =C2=A0 =C2=A0 I will fix this in the same way.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 3
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0If an access token = is encoded as a JWT, it might contain a list
>=C2=A0 =C2=A0 =C2=A0 of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0claims [RFC7519], s= ome registered and some
>=C2=A0 =C2=A0 =C2=A0 application-specific.=C2=A0 The
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I don't think there's a = question of whether a JWT will contain a
>=C2=A0 =C2=A0 =C2=A0 list of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 claims :)
>
>=C2=A0 =C2=A0 =C2=A0 Fair enough :)
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Maybe "If the access token = is encoded as a JWT, it will contain a
>=C2=A0 =C2=A0 =C2=A0 list of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 claims [RFC7519], which may incl= ude both registered and
>=C2=A0 =C2=A0 =C2=A0 application-specific
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 claims"?
>
>=C2=A0 =C2=A0 =C2=A0 Looks good to me, but I'll leave this for Rifa= at.
>
>=C2=A0 =C2=A0 Looks good to me too.
>=C2=A0 =C2=A0 Regards,
>=C2=A0 =C2=A0 =C2=A0Rifaat
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 ----
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 4
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 This section claims to cover WWW= -Authenticate.=C2=A0 What specification
>=C2=A0 =C2=A0 =C2=A0 will the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 SIP use of Bearer for Authorizat= ion operate under?
>
>=C2=A0 =C2=A0 =C2=A0 RFC 6750.
>
>=C2=A0 =C2=A0 =C2=A0 Section 2.1.3 says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The UAC sends a REGISTER reques= t with an Authorization header field
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0containing the response to the challe= nge, including the Bearer scheme
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0carrying a valid access token in the = request, as specified in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6750]."
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chall= enge=C2=A0 =3D/=C2=A0 ("Bearer" LWS bearer-cln *(COMMA bearer-cln= ))
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 side note: is there a mnemonic f= or the "cln" in "bearer-cln"?
>
>=C2=A0 =C2=A0 =C2=A0 RFC 3261 uses "cln" for digest.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0beare= r-cln =3D realm / scope / authz-server / error /
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth-param
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 nit: realm is already included i= n auth-param, though I don't see a
>=C2=A0 =C2=A0 =C2=A0 harm in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 calling it out explicitly.
>
>=C2=A0 =C2=A0 =C2=A0 auth-param is used to allow possible new parameter= s in the future.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0realm= =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0auth-= param =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 RFC 3261 defers to RFC 2617 (now= obsoleted by 7235) for both of
>=C2=A0 =C2=A0 =C2=A0 these; we
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 could perhaps short-circuit the = chain and say "defined in RFC
>=C2=A0 =C2=A0 =C2=A0 7235".
>
>=C2=A0 =C2=A0 =C2=A0 We discussed this in the WG, and the outcome was t= o keep the same
>=C2=A0 =C2=A0 =C2=A0 references as RFC 3261, since that is what people = are implementing.
>
>=C2=A0 =C2=A0 =C2=A0 Then, as a separate task, someone could update RFC= 3261 with the new
>=C2=A0 =C2=A0 =C2=A0 references.
>
>=C2=A0 =C2=A0 =C2=A0 ---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 5
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 We should probably note that SIP= makes much heavier use of proxies
>=C2=A0 =C2=A0 =C2=A0 than is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 common in the web world of OAuth= .
>
>=C2=A0 =C2=A0 =C2=A0 Maybe something like:
>
>=C2=A0 =C2=A0 =C2=A0 "However, SIP makes have use of intermediary = SIP proxies, and TLS only
>=C2=A0 =C2=A0 =C2=A0 guarantees hop-to-hop protection when used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protect SIP signaling."
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I'm happy to see that some p= rivacy considerations are being added
>=C2=A0 =C2=A0 =C2=A0 in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 response to Barry's review.<= br> >
>=C2=A0 =C2=A0 =C2=A0 Good :)
>
>=C2=A0 =C2=A0 =C2=A0 ---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Section 8
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I think RFCs 8252 and 8414 could= be just informative.
>
>=C2=A0 =C2=A0 =C2=A0 I can fix that.
>
>=C2=A0 =C2=A0 =C2=A0 ---
>
>=C2=A0 =C2=A0 =C2=A0 Regards,
>
>=C2=A0 =C2=A0 =C2=A0 Christer

--000000000000ce128005a448dc4b-- From nobody Mon Apr 27 10:32:40 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC33A0B90; Mon, 27 Apr 2020 10:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RBV1OlBAHVG8; Mon, 27 Apr 2020 10:32:31 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D5B313A1231; Mon, 27 Apr 2020 10:32:30 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03RHWPKP014402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 13:32:27 -0400 Date: Mon, 27 Apr 2020 10:32:24 -0700 From: Benjamin Kaduk To: Rifaat Shekh-Yusef Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Message-ID: <20200427173224.GA27494@kduck.mit.edu> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 17:32:34 -0000 On Sat, Apr 25, 2020 at 08:57:51AM -0400, Rifaat Shekh-Yusef wrote: > Hi Ben, > Thanks for the detailed and comprehensive review. > I will try to address the DISCUSS in this email with my inline comments > below. > Regards, > Rifaat > On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatracker > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sipcore-sip-token-authnz-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I support Roman's Discuss. > > The "Bearer" authentication challenge includes the address (or name?) of > an > authorization server to contact to obtain tokens, as mentioned in > multiple > places in the document (noted in the COMMENT section). Our experience > in > the OAuth world has shown that several classes of vulnerabilities are > possible when the client blindly attempt to use any provided AS, and > that a > whitelist of "allowed" or "trusted" ASes is needed for secure > operation. I > believe that the same is true for the SIP usage, and we should mention > this > requirement explicitly. > > Yeah, good point. I will add some text to address that. > > Section 1.2 tries to apply the OAuth confidential/public client > distinction > to SIP UACs, but it does so in a non-analogous fashion: the OAuth > distinction is for the client's ability to protect credentials that > identify > the client itself; the usage in this document refers to protecting > *user* > credentials and obtained tokens. I don't think that it's appropriate to > invoke the OAuth terminology when using it for a different meaning. > Both Public and Confidential OAuth clients are capable of providing the > necessary protections for *user* credentials (though they are of course > not > guaranteed to do so), which leaves me unclear on what the intended > requirements actually are. > > Well, a browser-based client apps do not have client credentials at all, > and they are considered public clients. Yes. > I think the clarification needed here is to make it clear that we are > talking about persistent storage of credentials. > What I am trying to do with these two definitions is to differentiate > between a browser-based UAC and non-browser based UAC. > Because a browser-based UAC should be using a different flow, the > authorization code grant flow, which is not covered by this document. > Would adding such clarification address this comment? Well, this paragraph leaves me confused as to what we're trying to convey. To try to clarify my current understanding, let me consider the current text in the -13, which talks about "user credentials and any tokens obtained using these user credentials". Splitting that apart, I assume "user credentials" is a password or analogue, and the "tokens" are, well, the OAuth/OIDC tokens this document uses. My (admittedly not perfect) understanding of analogous cases in stock OAuth is that for a browser-based SPA the browser gets redirected to an IdP where the user enters credentials to authenticate, and is returned to the SPA along with the token(s). So in that case the SPA has the tokens but not the user credentials. Your paragraph quoted above seems to imply that the browser-based UAC would not have the tokens, either? But then how would anything work? > > Section 2.3 states that: > > When a proxy wishes to authenticate a received request, it MUST > search the request for Proxy-Authorization header fields with 'realm' > parameters that match its realm. It then MUST successfully validate > > https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not > expected to have a sequence or list of Proxy-Authorization header fields > present in a single request that are intended to be interpreted by > different > proxies. Is this text compatible with that part of RFC 7235? > Furthermore, > I didn't find much guidance in 7235 or 3261 about when to include the > "realm" parameter in Proxy-Authorization; do we want to give any > guidance > here? (That is to say, I almost didn't find where it was even defined > as > possible to do so...) > > There is a separate thread already on this one. > > > I'm also not sure if we're attempting to profile RFC 6749 and always > require > a refresh token to be issued, or just have some editorial tweaks to make > to > avoid suggesting that we do have such a requirement (noted in the > COMMENT). > > This part is out of scope for this document, as it is related to the > interaction between the UAC and the AS. > This document is not trying to deviate from the OAuth 2.0 recommendations; > we will clarify this. Okay, thanks. -Ben From nobody Mon Apr 27 10:36:03 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83FE3A123A; Mon, 27 Apr 2020 10:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 COb1GvV9SZ54; Mon, 27 Apr 2020 10:35:59 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 60ABE3A1237; Mon, 27 Apr 2020 10:35:58 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03RHZmwL015533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Apr 2020 13:35:50 -0400 Date: Mon, 27 Apr 2020 10:35:48 -0700 From: Benjamin Kaduk To: Christer Holmberg Cc: Rifaat Shekh-Yusef , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Message-ID: <20200427173548.GB27494@kduck.mit.edu> References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6EBE66ED-E26B-4B92-B776-1F799E095DB7@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 17:36:01 -0000 On Sat, Apr 25, 2020 at 11:27:34PM +0000, Christer Holmberg wrote: > Hi Benjamin, > > >> Section 2.3 states that: > >> > >> When a proxy wishes to authenticate a received request, it MUST > >> search the request for Proxy-Authorization header fields with 'realm' > >> parameters that match its realm. It then MUST successfully validate > >> > >> https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it is not > >> expected to have a sequence or list of Proxy-Authorization header fields > >> present in a single request that are intended to be interpreted by different > > proxies. Is this text compatible with that part of RFC 7235? > > RFC 3261 allows multiple Proxy-Authorization header fields. Ah, thanks. > > Furthermore, I didn't find much guidance in 7235 or 3261 about when to include the > > "realm" parameter in Proxy-Authorization; do we want to give any guidance > > here? (That is to say, I almost didn't find where it was even defined as > > possible to do so...) > > I think it is clear from Section 22.3 (and the example in Section 20.28) in RFC 3261 that the "realm" is included in the Proxy-Authorization header field. So it is, thanks for the pointer and sorry for having missed it. > If we think 7235 and/or 3261 needs to be improved regarding that I think it is a separate task, outside the scope of this document. Okay; in light of the above I don't see a pressing need to do anything in this document. Thanks, Ben > (The thread Rifaat mentioned is not really related to this. It is whether the UAC provides credentials for one or more schemes.) > > Regards, > > Christer > > > > From nobody Mon Apr 27 10:50:31 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083EA3A1335; Mon, 27 Apr 2020 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3D4NptBDqHH; Mon, 27 Apr 2020 10:48:39 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 09D563A12FC; Mon, 27 Apr 2020 10:48:37 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id c18so2288198ile.5; Mon, 27 Apr 2020 10:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NSKOsqd7soxVhJCTsMmDcakNd89QxHubLFdqwD7k1bE=; b=DyI2fElWHYiS+ePs+oi9iR2MVW9YGNFi5Bi2i99F6g+F3dyekvm1wJ7C6f0uDqMTfC aHLL0Jj8DkDCBQX9gkFNeKqeMFIXHrrvMPiH49jAp5sDeAHfrFRTGSU5GW/xaOLCNed+ 8lvs1IACg6pNyb69uq60iLPdn/cIVHyP+YrF0UAGPOUWRW5bEzIdmX5+gzNsYVPN53UK Krz77+XAmrjGE6IVLdQ34XhI0vIlx+dbPhhE1c7bHJDHepp3xufkcJpMKyZnvPPiN5xe Y0VeMJB65kAlfc3z2j63X3YBLKx11bl6+EeTCIRVjMTkqrozkLh8yzoMyl//7aDc700b 3Z1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NSKOsqd7soxVhJCTsMmDcakNd89QxHubLFdqwD7k1bE=; b=HNZV2j0ytx1GI3cdWY2HhSR/zQfDmQivlMFQzRWVkWQzXgx8rbGxCMCGlK00Pdouf6 sBIFQbhJgtXttyjhN4Ot16hAXzkT8Tljp+JjRQIkpFaA1ciA48aymFFIyGQk74JnOlTj dyyiRtmi2pmYKVzt9viXvlIHNTfqkP3+Cv43jE0R4hobmmG775t665XT30s4YvX/GqY7 R8xhyqB9HsH/BZsk1i6qHjkRKyg+yGuz7TeP3csISbzacNM02eHoN0oGoHVV0AvH00oa vqiKOAehGFb6gI0mDntokoQRc2qbXRft+ktocsn7E0dUN7cFyuaPHhrKyAS/0kva5r9T QQWw== X-Gm-Message-State: AGi0PuYOqZvDlcy9pcrBJDaNxghWdK22ETtKE3vJiApdXYpk+7WAqGmQ eBmVdbDzmfbl8HHT46+oTefoxgcJgzGzdJYEkDI= X-Google-Smtp-Source: APiQypLbZEkCLJqqtGMpi/k2p06KdSHUYcGFBB1zcj6rBzLFb18UpFGzfmQvucHfDykJpVSn6pPs99VemRx6IARUEm4= X-Received: by 2002:a92:d182:: with SMTP id z2mr21087165ilz.36.1588009717218; Mon, 27 Apr 2020 10:48:37 -0700 (PDT) MIME-Version: 1.0 References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <20200427173224.GA27494@kduck.mit.edu> In-Reply-To: <20200427173224.GA27494@kduck.mit.edu> From: Rifaat Shekh-Yusef Date: Mon, 27 Apr 2020 13:48:26 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="0000000000001841e205a4495382" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 17:49:01 -0000 --0000000000001841e205a4495382 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 27, 2020 at 1:32 PM Benjamin Kaduk wrote: > On Sat, Apr 25, 2020 at 08:57:51AM -0400, Rifaat Shekh-Yusef wrote: > > Hi Ben, > > Thanks for the detailed and comprehensive review. > > I will try to address the DISCUSS in this email with my inline > comments > > below. > > Regards, > > Rifaat > > On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatracker > > wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sipcore-sip-token-authnz-13: Discuss > > > > When responding, please keep the subject line intact and reply to > all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > I support Roman's Discuss. > > > > The "Bearer" authentication challenge includes the address (or > name?) of > > an > > authorization server to contact to obtain tokens, as mentioned in > > multiple > > places in the document (noted in the COMMENT section). Our > experience > > in > > the OAuth world has shown that several classes of vulnerabilities > are > > possible when the client blindly attempt to use any provided AS, and > > that a > > whitelist of "allowed" or "trusted" ASes is needed for secure > > operation. I > > believe that the same is true for the SIP usage, and we should > mention > > this > > requirement explicitly. > > > > Yeah, good point. I will add some text to address that. > > > > Section 1.2 tries to apply the OAuth confidential/public client > > distinction > > to SIP UACs, but it does so in a non-analogous fashion: the OAuth > > distinction is for the client's ability to protect credentials that > > identify > > the client itself; the usage in this document refers to protecting > > *user* > > credentials and obtained tokens. I don't think that it's > appropriate to > > invoke the OAuth terminology when using it for a different meaning. > > Both Public and Confidential OAuth clients are capable of providing > the > > necessary protections for *user* credentials (though they are of > course > > not > > guaranteed to do so), which leaves me unclear on what the intended > > requirements actually are. > > > > Well, a browser-based client apps do not have client credentials at > all, > > and they are considered public clients. > > Yes. > > > I think the clarification needed here is to make it clear that we are > > talking about persistent storage of credentials. > > What I am trying to do with these two definitions is to differentiate > > between a browser-based UAC and non-browser based UAC. > > Because a browser-based UAC should be using a different flow, the > > authorization code grant flow, which is not covered by this document. > > Would adding such clarification address this comment? > > Well, this paragraph leaves me confused as to what we're trying to convey. > To try to clarify my current understanding, let me consider the current > text in the -13, which talks about "user credentials and any tokens > obtained using these user credentials". Splitting that apart, I assume > "user credentials" is a password or analogue, and the "tokens" are, well, > the OAuth/OIDC tokens this document uses. My (admittedly not perfect) > understanding of analogous cases in stock OAuth is that for a browser-based > SPA the browser gets redirected to an IdP where the user enters credentials > to authenticate, and is returned to the SPA along with the token(s). So in > that case the SPA has the tokens but not the user credentials. > > Your paragraph quoted above seems to imply that the browser-based UAC would > not have the tokens, either? But then how would anything work? > What you described above is what happens with an SPA *without *a backend server. The case I am thinking about is for an SPA *with *a backend server, which would be the SIP registrar in this case. So, the SPA obtains a code form the AS, sends it to the registrar, which exchanges that with the AS to obtain access token that enables the registration and potentially access to down stream services. But all of this really out of scope for this document, and all I was trying to do is differentiate what we have covered in the document from this use case. If this is confusing and not helping, I do not mind removing this section completely. Regards, Rifaat > > > > Section 2.3 states that: > > > > When a proxy wishes to authenticate a received request, it MUST > > search the request for Proxy-Authorization header fields with > 'realm' > > parameters that match its realm. It then MUST successfully > validate > > > > https://tools.ietf.org/html/rfc7235#section-4.4 suggests that it > is not > > expected to have a sequence or list of Proxy-Authorization header > fields > > present in a single request that are intended to be interpreted by > > different > > proxies. Is this text compatible with that part of RFC 7235? > > Furthermore, > > I didn't find much guidance in 7235 or 3261 about when to include > the > > "realm" parameter in Proxy-Authorization; do we want to give any > > guidance > > here? (That is to say, I almost didn't find where it was even > defined > > as > > possible to do so...) > > > > There is a separate thread already on this one. > > > > > > I'm also not sure if we're attempting to profile RFC 6749 and always > > require > > a refresh token to be issued, or just have some editorial tweaks to > make > > to > > avoid suggesting that we do have such a requirement (noted in the > > COMMENT). > > > > This part is out of scope for this document, as it is related to the > > interaction between the UAC and the AS. > > This document is not trying to deviate from the OAuth 2.0 > recommendations; > > we will clarify this. > > Okay, thanks. > > -Ben > --0000000000001841e205a4495382 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 27, 2020 at 1:32 PM Benja= min Kaduk <kaduk@mit.edu> wrote:=
On Sat, Apr 25,= 2020 at 08:57:51AM -0400, Rifaat Shekh-Yusef wrote:
>=C2=A0 =C2=A0 Hi Ben,
>=C2=A0 =C2=A0 Thanks for the detailed and comprehensive review.
>=C2=A0 =C2=A0 I will try to address the DISCUSS in this email with my i= nline comments
>=C2=A0 =C2=A0 below.
>=C2=A0 =C2=A0 Regards,
>=C2=A0 =C2=A0 =C2=A0Rifaat
>=C2=A0 =C2=A0 On Thu, Apr 23, 2020 at 3:25 PM Benjamin Kaduk via Datatr= acker
>=C2=A0 =C2=A0 <noreply@ietf.org> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 Benjamin Kaduk has entered the following ballot po= sition for
>=C2=A0 =C2=A0 =C2=A0 draft-ietf-sipcore-sip-token-authnz-13: Discuss >
>=C2=A0 =C2=A0 =C2=A0 When responding, please keep the subject line inta= ct and reply to all
>=C2=A0 =C2=A0 =C2=A0 email addresses included in the To and CC lines. (= Feel free to cut this
>=C2=A0 =C2=A0 =C2=A0 introductory paragraph, however.)
>
>=C2=A0 =C2=A0 =C2=A0 Please refer to
>=C2=A0 =C2=A0 =C2=A0 https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>=C2=A0 =C2=A0 =C2=A0 for more information about IESG DISCUSS and COMMEN= T positions.
>
>=C2=A0 =C2=A0 =C2=A0 The document, along with other ballot positions, c= an be found here:
>=C2=A0 =C2=A0 =C2=A0 https:= //datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/
>
>=C2=A0 =C2=A0 =C2=A0 --------------------------------------------------= --------------------
>=C2=A0 =C2=A0 =C2=A0 DISCUSS:
>=C2=A0 =C2=A0 =C2=A0 --------------------------------------------------= --------------------
>
>=C2=A0 =C2=A0 =C2=A0 I support Roman's Discuss.
>
>=C2=A0 =C2=A0 =C2=A0 The "Bearer" authentication challenge in= cludes the address (or name?) of
>=C2=A0 =C2=A0 =C2=A0 an
>=C2=A0 =C2=A0 =C2=A0 authorization server to contact to obtain tokens, = as mentioned in
>=C2=A0 =C2=A0 =C2=A0 multiple
>=C2=A0 =C2=A0 =C2=A0 places in the document (noted in the COMMENT secti= on).=C2=A0 Our experience
>=C2=A0 =C2=A0 =C2=A0 in
>=C2=A0 =C2=A0 =C2=A0 the OAuth world has shown that several classes of = vulnerabilities are
>=C2=A0 =C2=A0 =C2=A0 possible when the client blindly attempt to use an= y provided AS, and
>=C2=A0 =C2=A0 =C2=A0 that a
>=C2=A0 =C2=A0 =C2=A0 whitelist of "allowed" or "trusted&= quot; ASes is needed for secure
>=C2=A0 =C2=A0 =C2=A0 operation.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0 believe that the same is true for the SIP usage, a= nd we should mention
>=C2=A0 =C2=A0 =C2=A0 this
>=C2=A0 =C2=A0 =C2=A0 requirement explicitly.
>
>=C2=A0 =C2=A0 =C2=A0Yeah, good point. I will add some text to address t= hat.
>
>=C2=A0 =C2=A0 =C2=A0 Section 1.2 tries to apply the OAuth confidential/= public client
>=C2=A0 =C2=A0 =C2=A0 distinction
>=C2=A0 =C2=A0 =C2=A0 to SIP UACs, but it does so in a non-analogous fas= hion: the OAuth
>=C2=A0 =C2=A0 =C2=A0 distinction is for the client's ability to pro= tect credentials that
>=C2=A0 =C2=A0 =C2=A0 identify
>=C2=A0 =C2=A0 =C2=A0 the client itself; the usage in this document refe= rs to protecting
>=C2=A0 =C2=A0 =C2=A0 *user*
>=C2=A0 =C2=A0 =C2=A0 credentials and obtained tokens.=C2=A0 I don't= think that it's appropriate to
>=C2=A0 =C2=A0 =C2=A0 invoke the OAuth terminology when using it for a d= ifferent meaning.
>=C2=A0 =C2=A0 =C2=A0 Both Public and Confidential OAuth clients are cap= able of providing the
>=C2=A0 =C2=A0 =C2=A0 necessary protections for *user* credentials (thou= gh they are of course
>=C2=A0 =C2=A0 =C2=A0 not
>=C2=A0 =C2=A0 =C2=A0 guaranteed to do so), which leaves me unclear on w= hat the intended
>=C2=A0 =C2=A0 =C2=A0 requirements actually are.
>
>=C2=A0 =C2=A0 Well, a browser-based client apps do not have client cred= entials at all,
>=C2=A0 =C2=A0 and they are considered public clients.

Yes.

>=C2=A0 =C2=A0 I think the clarification needed here is to make it clear= that we are
>=C2=A0 =C2=A0 talking about persistent storage of credentials.
>=C2=A0 =C2=A0 What I am trying to do with these two definitions is to d= ifferentiate
>=C2=A0 =C2=A0 between a browser-based UAC and non-browser based UAC. >=C2=A0 =C2=A0 Because a browser-based UAC should be using a different f= low, the
>=C2=A0 =C2=A0 authorization code grant flow, which is not covered by th= is document.
>=C2=A0 =C2=A0 Would adding such clarification address this comment?

Well, this paragraph leaves me confused as to what we're trying to conv= ey.
To try to clarify my current understanding, let me consider the current
text in the -13, which talks about "user credentials and any tokens obtained using these user credentials".=C2=A0 Splitting that apart, I = assume
"user credentials" is a password or analogue, and the "token= s" are, well,
the OAuth/OIDC tokens this document uses.=C2=A0 My (admittedly not perfect)=
understanding of analogous cases in stock OAuth is that for a browser-based=
SPA the browser gets redirected to an IdP where the user enters credentials=
to authenticate, and is returned to the SPA along with the token(s).=C2=A0 = So in
that case the SPA has the tokens but not the user credentials.

Your paragraph quoted above seems to imply that the browser-based UAC would=
not have the tokens, either?=C2=A0 But then how would anything work?

What you described above is what happens with= an SPA without a backend server.
The case I am thinking a= bout is for an SPA with a backend server, which would be the SIP reg= istrar in this case.
So, the SPA obtains a code form the AS, = sends it to the registrar, which exchanges that with the AS to obtain acces= s token that enables the registration and potentially access to down stream= services.

But all of this really out of scope for= this document, and all I was trying to do is differentiate what we have co= vered in the document from this use case.
If this is confusing an= d not helping, I do not mind removing this section completely.

Regards,
=C2=A0Rifaat

<= br>

=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 Section 2.3 states that:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When a proxy wishes to authenticate a= received request, it MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0search the request for Proxy-Authoriz= ation header fields with 'realm'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parameters that match its realm.=C2= =A0 It then MUST successfully validate
>
>=C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html/= rfc7235#section-4.4 suggests that it is not
>=C2=A0 =C2=A0 =C2=A0 expected to have a sequence or list of Proxy-Autho= rization header fields
>=C2=A0 =C2=A0 =C2=A0 present in a single request that are intended to b= e interpreted by
>=C2=A0 =C2=A0 =C2=A0 different
>=C2=A0 =C2=A0 =C2=A0 proxies.=C2=A0 Is this text compatible with that p= art of RFC 7235?
>=C2=A0 =C2=A0 =C2=A0 Furthermore,
>=C2=A0 =C2=A0 =C2=A0 I didn't find much guidance in 7235 or 3261 ab= out when to include the
>=C2=A0 =C2=A0 =C2=A0 "realm" parameter in Proxy-Authorization= ; do we want to give any
>=C2=A0 =C2=A0 =C2=A0 guidance
>=C2=A0 =C2=A0 =C2=A0 here?=C2=A0 (That is to say, I almost didn't f= ind where it was even defined
>=C2=A0 =C2=A0 =C2=A0 as
>=C2=A0 =C2=A0 =C2=A0 possible to do so...)
>
>=C2=A0 =C2=A0 There is a separate thread already on this one.
>=C2=A0 =C2=A0 =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 I'm also not sure if we're attempting to p= rofile RFC 6749 and always
>=C2=A0 =C2=A0 =C2=A0 require
>=C2=A0 =C2=A0 =C2=A0 a refresh token to be issued, or just have some ed= itorial tweaks to make
>=C2=A0 =C2=A0 =C2=A0 to
>=C2=A0 =C2=A0 =C2=A0 avoid suggesting that we do have such a requiremen= t (noted in the
>=C2=A0 =C2=A0 =C2=A0 COMMENT).
>
>=C2=A0 =C2=A0 This part is out of scope for this document, as it is rel= ated to the
>=C2=A0 =C2=A0 interaction between the UAC and the AS.
>=C2=A0 =C2=A0 This document is not trying to deviate from the OAuth 2.0= recommendations;
>=C2=A0 =C2=A0 we will clarify this.

Okay, thanks.

-Ben
--0000000000001841e205a4495382-- From nobody Mon Apr 27 12:50:53 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF23A1B60; Mon, 27 Apr 2020 12:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 mMqY90P0UT3F; Mon, 27 Apr 2020 12:50:48 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (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 B03FB3A1B5D; Mon, 27 Apr 2020 12:50:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jact51Mf1HGFBXFjdFOi0UzUCvCLXziekcY/DYTY5Z3YBX6ZfjFN3eGjTv6W2Z68heqV6Q76e8Rng+6xJgEnW/Xnk1WGkx5nxNcQql/tOJz3fANd3PnQxKQa0BVyVhzRG59gtgy2spou9Wg9sTw+uEqfbmarHeSR8MPYe8CCKqFHjP8MN4s9BNy9HBl2c8KilnrUuPXMmi4Sl0yu6im85R+zxeFUz74mudN/3o/m2tZnolh7+PozE8SQCv55DQUrHBGTBMVRS2OfOmy/SmeWaASPQXknhq7NKKLVMLHjrdJ0M4CBF5PhZwAJF7bGRG80m3exKgFM4bNyyYRwQbJBTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0P3QkekS5aB6xEVWwYdIcHQuxE+W6ZZU5GG1mgwo5rc=; b=jWq2YjZye4z0Yn23TF8FUWy9Hj44bzFkz6Wp6SVTtYj8BCOMUfdrv3gu3vr3f30tcH9OHpktlZjVBM2khzhu+QUrNrbJuAamSQ9jZBs/eAU8iR+t93UlaqLoZ9Tor4IeMSN+fg45iOPPqfBxhtbwk6i/+NeiYDAz87Uz5IKkAjPVvJ5YIhMacp1ln2VC2PgvkiA7eQ9mQ4tNWODf/QMsGQIqTg3s+TwHsWJuO13McT7uX/4f/VTK3UG/H3btidnQfwkYBG/ZZ1u4v3bm7ZpynZEAlZoJphOGmniiLOaFL4mQ7k2cZsG7RXTiQrgj3ormLg3DvqpgEUIQCaBcszkK9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0P3QkekS5aB6xEVWwYdIcHQuxE+W6ZZU5GG1mgwo5rc=; b=ttD0NPzdBb16CRshqZ9CmpwkBTGc7hy/X2KVA+Se1h6U/2nVFyK8qY6Nhi36IOJoUvHRG/Acxrmc0U+NTzHCCmlAJqjdZGDb2SqFLgjCHgcY2VaszKW0NJFliAVzs6oJLBrGQShobfhFtwUpOucGLSocrMSxNIMMB/HyewOn43E= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6659.eurprd07.prod.outlook.com (2603:10a6:20b:1ae::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Mon, 27 Apr 2020 19:50:44 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 19:50:44 +0000 From: Christer Holmberg To: Magnus Westerlund , The IESG , "pkyzivat@alum.mit.edu" CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request Thread-Index: AQHWHM0jGFXph8PsA0+ASqfFfMQaaQ== Date: Mon, 27 Apr 2020 19:50:44 +0000 Message-ID: <6BA45301-2E1D-4050-9C13-6B8BA7094B79@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42d62530-ba44-4517-c8b9-08d7eae4462d x-ms-traffictypediagnostic: AM7PR07MB6659:|AM7PR07MB6659: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(39860400002)(366004)(376002)(346002)(54906003)(66556008)(66476007)(4326008)(316002)(66446008)(64756008)(91956017)(110136005)(66946007)(6506007)(6486002)(76116006)(33656002)(36756003)(5660300002)(86362001)(2616005)(478600001)(26005)(186003)(8936002)(71200400001)(966005)(6512007)(44832011)(81156014)(2906002)(8676002)(21314003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c1QsW9zrvqpl/Ddu5fIqXlXfZL/XhG2+nkRH8Xl1Lwd+IMoipRmU1VSWqhQcmJaMmutsM36e5DPPcO9RLFFs3545n8iFYNnDxwE+F8DqcBRfGQNZQcL+3fIlREWTxwql9AOBDTDTnrt57TBLtIh+75gxOI7DDta6lqGBWBz/XPNXe38m2mTzBP9GApi3TuMXP8vrY9i6Er2NpJsiN5bwEpI+jJFGR+azlW60VYcX/PPzHrQl6k2YU7cfPYDFqkQ8fHDOhdkzSqyeEyH3irlwlVmqznO7P1irIx82qrbDfDCoAHUSupvH7PB8hcPeE1lulIeTiEewldYhQ4ET7V+UElO+yN8X5SWekkYazm3av8uteVETa29ICViBW2gB/swEIzqIFGH5XfM9h/ettYFqtsn/hlzPsIzT+v+9Pp2gnB5mEI1F4b1fIrfSXpYuLR61XVK644QI/CXrU6ICTq6FAPyqO3qPXXzTHRDBTytrBxyhvDV23huRq44itXxradWLmfVMqrMu5JS7pN61jjT/LBS7Yn2FCYuDGrPMt6DREmLR+sx8ou1afb4hacNyexcH x-ms-exchange-antispam-messagedata: gful48gVLJPQpdC7PSHJXSgJQTU1daI1HQslIOt1eJLDgErSEfSV7UJRqQtDWoSJuBL5tXHBcq+Eldk8Syor5YwUv/jABinC97IOsYjj2JfakX46pkSWS5myNYoTuYW1XxRwXM5OEssh3qk/Fte4ET4KsHEUSrTYQSCkTq1nuuh86d8DdO4cD67CNxXZiTWj14yc9782zXy9typ58E7MVb3ogLkUWi/kwuvAW7h12eBR+Ok4jx/gKGCKJbYGLKG8yZbBiT0+3ETM4MkinCyj+2Beh3LIz/x2j6O2poLCXyGoXgGNlX3LB2npEA3g6vqpnrpL/6Azf6Y1Fpz9eaMJqNcskq1JdEv7tsVEFl/xpvLLuCTUbCfW2GqZT6XF6exOz9/ORIJwN2g2tPwTkjqDPz001xEU8gBMc+UQWglHLtSMOvB13BKAe2Y0oiFJmDHbXfFeo20PNDmtikx618DrIjtz1f7hN4OWm2ZTxzznHAkmB4KeSDmjllybTPhg2rX6UyuDsHWg5PcIZ3/+DP62+Cyh1Y6Puz2y66guZkL6/wgzOhe8P876bSahq7SK8VvDW+WlULdY4bbCSWQCRwPZamSSMrA3Xp9RpPXVrr9vB1yRkqXORexoNIuCJIADLPCIDa0BC+j3mmBwFQk/hGCzbEBVd/3aIIXnCJXXC19vXFU/S6ndKlpAiYmex7fdJhNsgFRZyuSOXbd7goBFyvyKGNRO5oi3bYlmeo+ANQWWMmWwnw1KGebcU19+8iQf3lpuEEq86oaVoNdH4wi95Ccm4xAMZaJEq78pUjdJmg5FCu0= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42d62530-ba44-4517-c8b9-08d7eae4462d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 19:50:44.5978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HFMmii/7Zk8zw/EiLBTJ2Dxk9ol/VDCLh9x32my2hw2yGpBm2xFqkVaFxM11tgWsIzlwy8S756SGJeU//buCtdJ118/l3j2JBiKom1ophQc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6659 Archived-At: Subject: Re: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 19:50:52 -0000 SGksDQoNClRoZSBmb2xsb3dpbmcgcHVsbCByZXF1ZXN0IGNvbW1pdHMgY29udGFpbnMgdGhlIHN5 bnRheCBhbmQgSUFOQSBjaGFuZ2VzIGJhc2VkIG9uIE1hZ251cyBESVNDVVNTOg0KDQpodHRwczov L2dpdGh1Yi5jb20vcmlmYWF0LWlldGYvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRo bnovcHVsbC83L2NvbW1pdHMvMTY4MDg2YjRmMTIyMDYyMGQwNjNhZjA3YTMyOTJiNjY3ZTMwZWYz NyAoU3ludGF4KQ0KaHR0cHM6Ly9naXRodWIuY29tL3JpZmFhdC1pZXRmL2RyYWZ0LWlldGYtc2lw Y29yZS1zaXAtdG9rZW4tYXV0aG56L3B1bGwvNy9jb21taXRzLzIyZjgxMDAyNWQxYmY4ZGY0NTg3 NWU5MmU0ZDRjMTFkMGY1NzQ2OTMgKElBTkEgQ29uc2lkZXJhdGlvbnMpDQoNClBsZWFzZSBub3Rl IHRoZSBwYXJhbWV0ZXIgbmFtZSAiYXV0aHpfc2VydmVyIi4gRm9sbG93aW5nIHRoZSBuYW1pbmcg c3R5bGUgb2Ygb3RoZXIgaGVhZGVyIGZpZWxkIHBhcmFtZXRlcnMgaXQgc2hvdWxkIHBlcmhhcHMg YmUgImF1dGh6LXNlcnZlciIuIEhvd2V2ZXIsIGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IEkg d291bGQgcHJlZmVyIHRvIG5vdCBjaGFuZ2UgaXQgYXQgdGhpcyBwb2ludC4NCg0KUGF1bCwgSSB3 b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCBhbHNvIHRha2UgYSBsb29rIGF0IHRoZXNlLiBU aGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQrvu79PbiAyMy8wNC8yMDIwLCAy Mi41MSwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PiB3cm90ZToNCg0KICAgIEhpIE1hZ251cywNCiAgICANCiAgICBUaGFuayBZb3UgZm9yIHRoZSBy ZXZpZXchIFBsZWFzZSBzZWUgaW5saW5lLg0KICAgICAgICANCiAgICAgICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICAgICAgICBESVNDVVNTOg0KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgIA0KICAg ICAgICA+IEkgdGhpbmsgdGhlc2UgcmVzb2x1dGlvbiBmb3IgdGhpcyBpcyByYXRoZXIgc3RyYWln aHQgZm9yd2FyZCwgaG93ZXZlciB0aGUNCiAgICAgICAgPiBpbXBsaWNhdGlvbnMgb2Ygb25lIGlz IGdvaW5nIHRvIGJyZWFrIGRlcGxveWVkIGltcGxlbWVudGF0aW9ucy4NCiAgICAgICAgPg0KICAg ICAgICA+IDEuIFNlY3Rpb24gNDoNCiAgICAgICAgPg0KICAgICAgICA+IFRoaXMgaXMgcmF0aGVy IHN0cmFpZ2h0IGZvcndhcmQgdG8gcmVzb2x2ZSBidXQgeW91IGRvIGhhdmUgYSBTSVAgc3ludGF4 DQogICAgICAgID4gdmlvbGF0aW9uIGluIHRoZXNlIHJ1bGVzLg0KICAgICAgICA+DQogICAgICAg ID4gICAgICAgY2hhbGxlbmdlICA9LyAgKCJCZWFyZXIiIExXUyBiZWFyZXItY2xuICooQ09NTUEg YmVhcmVyLWNsbikpDQogICAgICAgID4gICAgICAgYmVhcmVyLWNsbiA9IHJlYWxtIC8gc2NvcGUg LyBhdXRoei1zZXJ2ZXIgLyBlcnJvciAvIGF1dGgtcGFyYW0NCiAgICAgICAgPiAgICAgICBhdXRo ei1zZXJ2ZXIgPSAiYXV0aHpfc2VydmVyIiBFUVVBTCBhdXRoei1zZXJ2ZXItdmFsdWUNCiAgICAg ICAgPiAgICAgICBhdXRoei1zZXJ2ZXItdmFsdWUgPSBodHRwcy1VUkkNCiAgICAgICAgPiAgICAg ICByZWFsbSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQogICAgICAgID4gICAgICAgYXV0aC1wYXJh bSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQogICAgICAgID4gICAgICAgc2NvcGUgPSA8ZGVmaW5l ZCBpbiBSRkM2NzQ5Pg0KICAgICAgICA+ICAgICAgIGVycm9yID0gPGRlZmluZWQgaW4gUkZDNjc0 OT4NCiAgICAgICAgPiAgICAgICBodHRwcy1VUkkgPSA8ZGVmaW5lZCBpbiBSRkM3MjMwPg0KICAg ICAgICA+DQogICAgICAgID4gU28gUkZDIDMyNjEgZGVmaW5lcyB0aGUgQ2hhbGxlbmdlIGNvbnN0 cnVjdCBhczoNCiAgICAgICAgPg0KICAgICAgICA+IGNoYWxsZW5nZSAgICAgICAgICAgPSAgKCJE aWdlc3QiIExXUyBkaWdlc3QtY2xuICooQ09NTUEgZGlnZXN0LWNsbikpICAvIG90aGVyLWNoYWxs ZW5nZQ0KICAgICAgICA+DQogICAgICAgID4gV2hlcmUgdGhpcyBleHRlbnNpb24gbmVlZHMgdG8g bWF0Y2ggdGhlIHN5bnRheCBvZiB0aGUgb3RoZXItY2hhbGxlbmdlOg0KICAgICAgICA+DQogICAg ICAgID4gb3RoZXItY2hhbGxlbmdlICAgICA9ICBhdXRoLXNjaGVtZSBMV1MgYXV0aC1wYXJhbSAg KihDT01NQSBhdXRoLXBhcmFtKQ0KICAgICAgICA+DQogICAgICAgID4gV2hlcmUgd2UgbmVlZCB0 byBsb29rIGF0Og0KICAgICAgICA+IGF1dGgtcGFyYW0gICAgICAgID0gIGF1dGgtcGFyYW0tbmFt ZSBFUVVBTCAgKCB0b2tlbiAvIHF1b3RlZC1zdHJpbmcgKQ0KICAgICAgICA+DQogICAgICAgID4g UGxlYXNlIG5vdGUgd2hhdCBpcyBpbmNsdWRlZCBpbiB0aGUgInRva2VuIiBydWxlLg0KICAgICAg ICA+ICAgICAgdG9rZW4gICAgICAgPSAgMSooYWxwaGFudW0gLyAiLSIgLyAiLiIgLyAiISIgLyAi JSIgLyAiKiINCiAgICAgICAgPiAgICAgICAgICAgICAgICAgICAgIC8gIl8iIC8gIisiIC8gImAi IC8gIiciIC8gIn4iICkNCiAgICAgICAgPg0KICAgICAgICA+IHRoZSBhbGxvd2VkIHN5bnRheCBm b3IgaHR0cHMtVVJJIGluIFJGQyA3MjMwIGlzOg0KICAgICAgICA+DQogICAgICAgID4gICAgaHR0 cHMtVVJJID0gImh0dHBzOiIgIi8vIiBhdXRob3JpdHkgcGF0aC1hYmVtcHR5IFsgIj8iIHF1ZXJ5 IF0gIFsgIiMiIGZyYWdtZW50IF0NCiAgICAgICAgPg0KICAgICAgICA+IFdoaWNoIGluY2x1ZGUg Ym90aCAiLyIsICI/IiBhbmQgIiMiIHRoYXQgYXJlIG5vdCBhbGxvd2VkIGluIHRva2VuLiBUaHVz LCB0aGUNCiAgICAgICAgPiBVUkkgaW5jbHVkZWQgaW4gdGhlIGF1dGh6LXNlcnZlci12YWx1ZSAg TVVTVCBiZSBjb252ZXJ0ZWQgaW50byBhIHF1b3RlZC1zdHJpbmcNCiAgICAgICAgPiBtYXRjaGlu ZyBzeW50YXggcnVsZS4NCiAgICAgICAgDQogICAgICAgIFlvdSBhcmUgY29ycmVjdC4gV2UgY3Vy cmVudGx5IHJlZmVyZW5jZSBodHRwcy1VUkkgaW4gUkZDIDcyMzAsIGJ1dCB0aGUgZGVmaW5pdGlv biBpbiA3MjMwIGRvZXMgbm90IHBsYWNlIHF1b3RlcyBhcm91bmQgaXQuDQogICAgDQogICAgICAg IFRoZSBzYW1lIGFwcGxpZXMgdG8gc2NvcGUgYW5kIGVycm9yLg0KICAgIA0KICAgICAgICBTbywg d2UgbmVlZCB0byBmaXg6DQogICAgDQogICAgT0xEOg0KICAgIA0KICAgICAgICAgYXV0aHotc2Vy dmVyID0gImF1dGh6X3NlcnZlciIgRVFVQUwgYXV0aHotc2VydmVyLXZhbHVlDQogICAgDQogICAg ICAgICBzY29wZSA9IDxkZWZpbmVkIGluIFJGQzY3NDk+DQogICAgICAgICAgZXJyb3IgPSA8ZGVm aW5lZCBpbiBSRkM2NzQ5Pg0KICAgIA0KICAgIE5FVzoNCiAgICANCiAgICAgICAgIGF1dGh6LXNl cnZlciA9ICJhdXRoel9zZXJ2ZXIiIEVRVUFMIERRVU9URSBhdXRoei1zZXJ2ZXItdmFsdWUgRFFV T1RFDQogICAgDQogICAgICAgICBzY29wZS1jbG4gPSBEUVVPVEUgc2NvcGUgRFFVT1RFDQogICAg ICAgICBzY29wZSA9IDxkZWZpbmVkIGluIFJGQzY3NDk+DQogICAgICAgICBlcnJvci1jbG4gPSBE UVVQVEUgZXJyb3IgRFFVT1RFDQogICAgICAgICBlcnJvciA9IDxkZWZpbmVkIGluIFJGQzY3NDk+ DQogICAgDQogICAgDQogICAgKEkgbm90ZWQgdGhhdCB0aGF0IEJlbmphbWluIGhhcyBzb21lIGNv bW1lbnRzIHJlZ2FyZGluZyB0aGUgcmVmZXJlbmNlZCBSRkNzIGZvciB0aGUgcGFyYW1ldGVyIHZh bHVlcywgYnV0IEkgd2lsbCBhZGRyZXNzIHRoYXQgaW4gdGhlIHJlcGx5IHRvIGhpcyByZXZpZXcu KQ0KICAgIA0KICAgIA0KICAgIC0tLS0tDQogICAgDQogICAgICAgID4gMi4gSW4gYWRkaXRpb24g c2hvdWxkIG5vdCB0aGUgImF1dGh6X3NlcnZlciIgYmUgcmVnaXN0ZXJlZCBpbiB0aGUNCiAgICAg ICAgPiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zaXAtcGFyYW1ldGVycy9zaXAt cGFyYW1ldGVycy54aHRtbCNzaXAtcGFyYW1ldGVycy0xMg0KICAgICAgICA+IHJlZ2lzdHJ5Pw0K ICAgICAgICANCiAgICAgICAgSSBndWVzcyBzby4gQW5kLCB0aGVuIEkgZ3Vlc3Mgd2UgYWxzbyBu ZWVkIHRvIHJlZ2lzdGVyICJzY29wZSIgYW5kICJlcnJvciIuDQogICAgDQogICAgICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgICAgICAgQ09NTUVOVDoNCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAg ICANCiAgICAgICAgPiBBbiBhZGRpdGlvbmFsIHRoaW5nLg0KICAgICAgICA+DQogICAgICAgID4g SXMgU0lQIGRpcmVjdGx5IHVzaW5nIHRoZSBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZXMgSUFO QSByZWdpc3RyeQ0KICAgICAgICA+IChodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9o dHRwLWF1dGhzY2hlbWVzL2h0dHAtYXV0aHNjaGVtZXMueGh0bWwjYXV0aHNjaGVtZXMpDQogICAg ICAgID4gb3IgZG9lcyBpdCBoYXZlIGl0cyBvd24gdHVja2VkIGF3YXkgc29tZXdoZXJlPyBBbmQg aWYgaXQgaXMgdGhlIGZvcm1lciwgc2hvdWxkDQogICAgICAgID4gaXRzIHJlZmVyZW5jZXMgZm9y IHRoZSAiYmVhcmVyIiBhZGQgdGhpcyBSRkMgYXMgYSByZWZlcmVuY2U/DQogICAgICAgIA0KICAg ICAgICBTSVAgdXNlcyB0aGUgSFRUUCByZWdpc3RyeS4NCiAgICANCiAgICAgICAoVGhlIFNJUCBy ZWdpc3RyeSBkb2VzIHJlZ2lzdGVyIGEgImRpZ2VzdCIgdmFsdWUsIGJ1dCB0aGF0IGlzIGZvciB0 aGUgU2VjdXJpdHktWFhYIGhlYWRlcnMgZGVmaW5lZCBpbiBSRkMgMzMyOSkNCiAgICANCiAgICBS ZWdhcmRzLA0KICAgIA0KICAgIENocmlzdGVyICAgICAgICAgIA0KICAgICAgICANCiAgICAgICAg DQogICAgDQogICAgDQoNCg== From nobody Mon Apr 27 23:57:33 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78253A0CA2; Mon, 27 Apr 2020 23:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 I11KUd9HFOQl; Mon, 27 Apr 2020 23:57:12 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130051.outbound.protection.outlook.com [40.107.13.51]) (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 3C5203A0CA5; Mon, 27 Apr 2020 23:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hgvHyVpU1DnCnFwYCKsKIL+Fwge6++NdO28ADdvJk+eCzU7fUZDCyLHOqRLoqpXkgTpeIbERZRFBCvtPJpkQwRit3rI8I1OJtUOJY8Tf0amP7l5JrcmXpABRkJc1mjsBFZiWqk0J2cZzBb1nFbRBFxNpimsFut/EaebWjHu8XTfCzhDwvCTfKD8U2EbElzuqn9mUthp4c3rgQNHIy4zlOqll28cDeiTq4PROWmavXlDPWv5M96YDIvaJ8IFG3MktxHnClFc4zsPqtUiNHw9f4DzjoZD9U5KNzU+6M0ejXpGz1VZthPa/1CDNkAyXnD5IohVJujwzHc1e35EUoAgNIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SzAzwvRlKCTxbTlO+TQnQBNRyMC1W01ZCNrioUgaWbw=; b=MM7BAGzootvxur6DOtEG1mojcKMDu80rAelf4W7IEddqeyZ5+4PZYtfFjOcANAlJq1Y4kydV2PsMSuKnC2UdY+BYJyqwsarh3CKiMus11/S/hHnReSJWxaaxrDmXrAR/348cnlYDBHcrwQ11NMjanz9jWlWNQcqL7TEbSWCKnDpYHToUULPiGbHjQ4P/+1xI86lpZ5/8voJ4hU146WkKjpK4LN5I0g4TUCiUtrRL10Y1cvDFim1rYvYyGknLcZHopyvjBZe13GwMKuX3LC/BvceJvm+8NPn7qZXnUIKxJgDq4UDAW04LZzruqqLyGv+tpiYZNJ0QiZonZgIUdiROXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SzAzwvRlKCTxbTlO+TQnQBNRyMC1W01ZCNrioUgaWbw=; b=RCJ9Wtge+49EBTeTZqRRtknqIKbkqJhdyAr4ux4CQTmPgpV5nP+nLhvqKUjqTMRkPwG2PlmqMqEVoxq7ffojmIsARn8OnCdlaXAnqEZxJKu3HGIROP3N6woOrNDKxthFg9htUK6mTg3S8OsIBUlxw1L/PqcMmfxIvC2+cypity4= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6834.eurprd07.prod.outlook.com (2603:10a6:20b:1b6::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Tue, 28 Apr 2020 06:57:08 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 06:57:08 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Benjamin Kaduk CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply Thread-Index: AQHWGwEtfH/bpP2YLUqlNdqU6ZLbLaiNPZ0AgAAEewCAAQ6mgA== Date: Tue, 28 Apr 2020 06:57:08 +0000 Message-ID: References: <158766991009.32224.6031347936963900326@ietfa.amsl.com> <20200427173224.GA27494@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e8977370-c79d-4f66-8f51-08d7eb415e24 x-ms-traffictypediagnostic: AM7PR07MB6834: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(33656002)(54906003)(91956017)(76116006)(110136005)(44832011)(26005)(66946007)(66574012)(81156014)(64756008)(8936002)(5660300002)(6506007)(36756003)(2616005)(6486002)(71200400001)(66476007)(8676002)(66556008)(316002)(66446008)(478600001)(186003)(6512007)(86362001)(4326008)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3zhA56EO8fyEqydRxEbGc6RFENn5ci9GIOt3Ox/j4LIbYQF+70WLoFNhqU0HoL7Ybnwlqc0JfX+qEth/XxSvFi5/gtOYnNlMoTZfpPZIG29OiuyQ7dUAHsIxQ18Q0nvtHv8vmxhHKfK5mhvHJhczTlXjD75NR2IBGnOdiWpKEUNAwNGQH5yGvZJtqtCMfKri27QnandzFcwoy7lmXs9Tu5Ti3bgfcZnGzIWnuRD3ASfSkA+DgyUfVVdjdaUgfv5krws2bEX79M26d7Vi8F+cMi14A2z4SiXRUB7rIX3Scq7zYdAKP18XNaIBN/YcO96tzseNZ2jI8pDOPcgwSAoo2gHv4lzig1WIQBmrpPTgQUXK9LhGDC1mROus3zvOfXKm3HLZ7UlS7fZvNMJp6/OXtgtb16uQsNnjsh/gqk5kJkLzQ7cbvSqLb2vJovpiDL/U x-ms-exchange-antispam-messagedata: 5wRsZ5urO/VnJxt6KsUHrC+L7iuyPgUwODYHFOb6tgkFnSYjTFw8W6G9/jE+zb7yRLGvPMr1RrldYeF6lLZ9faiqDcvJ0o8s4MF8bWDqb+ndq3bqvCHGNTXc2V3YOFJHV1kFHdGxGIeKBaajoWKM3I8dYFEw5/B74+vIVCjp4iO6Gnt5hzt05+SfAUEqBdUcYeSXdK2X/VaIabRjf4o6cMCMEKWUPk1WeWu8Z7GlLt+ToO4tqL0hQNdKyTBqVjuxUkNw+iBN8iCbmEbfVT4ctFIAc3rlJmPRpADQsGICgYwtIcl3pAPq+k+gzyFUAaFh+K427avCXOXO25G4ZvFBUN6/vQd+JuMrp5QPObZuF7WF521RU4t0vGlqJFhs0FDLZFPEq0L0HbGhnBfC/YXTUnyH8ZniZdVE6VspvbsWp7XpmrGuNs8yMrSUCG5jZU5wdwOvIAbOYAuSkXN71qukdxdQsj879cQ9w6JR56WL4hJZYop6Krk96Zo8rp21BtF8XPWuUJmnRbB/Huxk7olsNzbZOYjiT8V4eYBGWVi0ueIQSCJlRtVhlLPi4FcOkME8NBlvYMkA5fjnCPr1DiCoSDpIN6QO55QdJtbtBN5vULSKrY6ToyyAkPkLU87Uh0/xXiTxaCD+N63ezCYmMc4uyAeyh+JIrzDu/j/mAf/n1b/IEHuC8zqfpO/JX8mSTGWsHGtqNaGGV7+G1pjKQChg6Jiyn/sQTtnrumIB+hwKR0MtPxziY9/ZSWyxNffToY5h5EH5v0kwaB54ssDSWOKIQVjZq8xR8wqeHR5FCoGley4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e8977370-c79d-4f66-8f51-08d7eb415e24 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 06:57:08.0423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eRoyUr5EvIWr9fO4RFeBNmCVrW1Z4KpSoZ6tdmlfI2C+gIPcKjvjMNhCI8Pcty/PoGpqEB3t7pdyx42RbwBDeO+9eKnnwA0TvnKalvuFj1A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6834 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13 - DISCUSS Reply X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 06:57:14 -0000 SGksDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogDQo+Pj7CoCDC oCDCoCBTZWN0aW9uIDEuMiB0cmllcyB0byBhcHBseSB0aGUgT0F1dGggY29uZmlkZW50aWFsL3B1 YmxpYyBjbGllbnQNCj4+PsKgIMKgIMKgIGRpc3RpbmN0aW9uDQo+Pj7CoCDCoCDCoCB0byBTSVAg VUFDcywgYnV0IGl0IGRvZXMgc28gaW4gYSBub24tYW5hbG9nb3VzIGZhc2hpb246IHRoZSBPQXV0 aA0KPj4+wqAgwqAgwqAgZGlzdGluY3Rpb24gaXMgZm9yIHRoZSBjbGllbnQncyBhYmlsaXR5IHRv IHByb3RlY3QgY3JlZGVudGlhbHMgdGhhdA0KPj4+wqAgwqAgwqAgaWRlbnRpZnkNCj4+PsKgIMKg IMKgIHRoZSBjbGllbnQgaXRzZWxmOyB0aGUgdXNhZ2UgaW4gdGhpcyBkb2N1bWVudCByZWZlcnMg dG8gcHJvdGVjdGluZw0KPj4+wqAgwqAgwqAgKnVzZXIqDQo+Pj7CoCDCoCDCoCBjcmVkZW50aWFs cyBhbmQgb2J0YWluZWQgdG9rZW5zLsKgIEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIGFwcHJvcHJp YXRlIHRvDQo+Pj7CoCDCoCDCoCBpbnZva2UgdGhlIE9BdXRoIHRlcm1pbm9sb2d5IHdoZW4gdXNp bmcgaXQgZm9yIGEgZGlmZmVyZW50IG1lYW5pbmcuDQo+Pj7CoCDCoCDCoCBCb3RoIFB1YmxpYyBh bmQgQ29uZmlkZW50aWFsIE9BdXRoIGNsaWVudHMgYXJlIGNhcGFibGUgb2YgcHJvdmlkaW5nIHRo ZQ0KPj4+wqAgwqAgwqAgbmVjZXNzYXJ5IHByb3RlY3Rpb25zIGZvciAqdXNlciogY3JlZGVudGlh bHMgKHRob3VnaCB0aGV5IGFyZSBvZiBjb3Vyc2UNCj4+PsKgIMKgIMKgIG5vdMKgZ3VhcmFudGVl ZCB0byBkbyBzbyksIHdoaWNoIGxlYXZlcyBtZSB1bmNsZWFyIG9uIHdoYXQgdGhlIGludGVuZGVk DQo+Pj7CoCDCoCDCoCByZXF1aXJlbWVudHMgYWN0dWFsbHkgYXJlLg0KPj4gDQo+PsKgIMKgIFdl bGwsIGEgYnJvd3Nlci1iYXNlZCBjbGllbnQgYXBwcyBkbyBub3QgaGF2ZSBjbGllbnQgY3JlZGVu dGlhbHMgYXQgYWxsLA0KPj7CoCDCoCBhbmQgdGhleSBhcmUgY29uc2lkZXJlZCBwdWJsaWMgY2xp ZW50cy4NCj4NCj4gWWVzLg0KPg0KPj4+wqAgwqAgSSB0aGluayB0aGUgY2xhcmlmaWNhdGlvbiBu ZWVkZWQgaGVyZSBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgd2UgYXJlDQo+Pj7CoCDCoCB0YWxr aW5nIGFib3V0IHBlcnNpc3RlbnQgc3RvcmFnZSBvZiBjcmVkZW50aWFscy4NCj4+PsKgIMKgIFdo YXQgSSBhbSB0cnlpbmcgdG8gZG8gd2l0aCB0aGVzZSB0d28gZGVmaW5pdGlvbnMgaXMgdG8gZGlm ZmVyZW50aWF0ZQ0KPj4+wqAgwqAgYmV0d2VlbiBhIGJyb3dzZXItYmFzZWQgVUFDIGFuZCBub24t YnJvd3NlciBiYXNlZCBVQUMuDQo+Pj7CoCDCoCBCZWNhdXNlIGEgYnJvd3Nlci1iYXNlZCBVQUMg c2hvdWxkIGJlIHVzaW5nIGEgZGlmZmVyZW50IGZsb3csIHRoZQ0KPj4+wqAgwqAgYXV0aG9yaXph dGlvbiBjb2RlIGdyYW50IGZsb3csIHdoaWNoIGlzIG5vdCBjb3ZlcmVkIGJ5IHRoaXMgZG9jdW1l bnQuDQo+Pj7CoCDCoCBXb3VsZCBhZGRpbmcgc3VjaCBjbGFyaWZpY2F0aW9uIGFkZHJlc3MgdGhp cyBjb21tZW50Pw0KPj4NCj4+IFdlbGwsIHRoaXMgcGFyYWdyYXBoIGxlYXZlcyBtZSBjb25mdXNl ZCBhcyB0byB3aGF0IHdlJ3JlIHRyeWluZyB0byBjb252ZXkuDQo+PiBUbyB0cnkgdG8gY2xhcmlm eSBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcsIGxldCBtZSBjb25zaWRlciB0aGUgY3VycmVudA0K Pj4gdGV4dCBpbiB0aGUgLTEzLCB3aGljaCB0YWxrcyBhYm91dCAidXNlciBjcmVkZW50aWFscyBh bmQgYW55IHRva2Vucw0KPj4gb2J0YWluZWQgdXNpbmcgdGhlc2UgdXNlciBjcmVkZW50aWFscyIu wqAgU3BsaXR0aW5nIHRoYXQgYXBhcnQsIEkgYXNzdW1lDQo+PiAidXNlciBjcmVkZW50aWFscyIg aXMgYSBwYXNzd29yZCBvciBhbmFsb2d1ZSwgYW5kIHRoZSAidG9rZW5zIiBhcmUsIHdlbGwsDQo+ PiB0aGUgT0F1dGgvT0lEQyB0b2tlbnMgdGhpcyBkb2N1bWVudCB1c2VzLsKgIE15IChhZG1pdHRl ZGx5IG5vdCBwZXJmZWN0KQ0KPj4gdW5kZXJzdGFuZGluZyBvZiBhbmFsb2dvdXMgY2FzZXMgaW4g c3RvY2sgT0F1dGggaXMgdGhhdCBmb3IgYSBicm93c2VyLWJhc2VkDQo+PiBTUEEgdGhlIGJyb3dz ZXIgZ2V0cyByZWRpcmVjdGVkIHRvIGFuIElkUCB3aGVyZSB0aGUgdXNlciBlbnRlcnMgY3JlZGVu dGlhbHMNCj4+IHRvIGF1dGhlbnRpY2F0ZSwgYW5kIGlzIHJldHVybmVkIHRvIHRoZSBTUEEgYWxv bmcgd2l0aCB0aGUgdG9rZW4ocykuwqAgU28gaW4NCj4+IHRoYXQgY2FzZSB0aGUgU1BBIGhhcyB0 aGUgdG9rZW5zIGJ1dCBub3QgdGhlIHVzZXIgY3JlZGVudGlhbHMuDQo+DQo+IFlvdXIgcGFyYWdy YXBoIHF1b3RlZCBhYm92ZSBzZWVtcyB0byBpbXBseSB0aGF0IHRoZSBicm93c2VyLWJhc2VkIFVB QyB3b3VsZA0KPiBub3QgaGF2ZSB0aGUgdG9rZW5zLCBlaXRoZXI/wqAgQnV0IHRoZW4gaG93IHdv dWxkIGFueXRoaW5nIHdvcms/DQo+DQo+IFdoYXQgeW91IGRlc2NyaWJlZCBhYm92ZSBpcyB3aGF0 IGhhcHBlbnMgd2l0aCBhbiBTUEEgd2l0aG91dCBhIGJhY2tlbmQgc2VydmVyLg0KPiBUaGUgY2Fz ZSBJIGFtIHRoaW5raW5nIGFib3V0IGlzIGZvciBhbiBTUEEgd2l0aCBhIGJhY2tlbmQgc2VydmVy LCB3aGljaCB3b3VsZCBiZQ0KPiB0aGUgU0lQIHJlZ2lzdHJhciBpbiB0aGlzIGNhc2UuIFNvLCB0 aGUgU1BBIG9idGFpbnMgYSBjb2RlIGZvcm0gdGhlIEFTLCBzZW5kcyBpdCB0byB0aGUNCj4gcmVn aXN0cmFyLCB3aGljaCBleGNoYW5nZXMgdGhhdCB3aXRoIHRoZSBBUyB0byBvYnRhaW4gYWNjZXNz IHRva2VuIHRoYXQgZW5hYmxlcyB0aGUNCj4gcmVnaXN0cmF0aW9uIGFuZCBwb3RlbnRpYWxseSBh Y2Nlc3MgdG8gZG93biBzdHJlYW0gc2VydmljZXMuDQo+DQo+IEJ1dCBhbGwgb2YgdGhpcyByZWFs bHkgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LCBhbmQgYWxsIEkgd2FzIHRyeWluZyB0 byBkbyBpcyBkaWZmZXJlbnRpYXRlDQo+IHdoYXQgd2UgaGF2ZSBjb3ZlcmVkIGluIHRoZSBkb2N1 bWVudCBmcm9tIHRoaXMgdXNlIGNhc2UuDQo+SWYgdGhpcyBpcyBjb25mdXNpbmcgYW5kIG5vdCBo ZWxwaW5nLCBJIGRvIG5vdCBtaW5kIHJlbW92aW5nIHRoaXMgc2VjdGlvbiBjb21wbGV0ZWx5Lg0K DQpXaGF0IGFib3V0IHJlcGxhY2luZyB0aGUgY3VycmVudCB0ZXh0IGluIFNlY3Rpb24gMS4yIHdp dGggdGhlIGZvbGxvd2luZzoNCg0KLS0tDQoNCjEuMi4gIEFwcGxpY2FiaWxpdHkNCg0KICAgVGhp cyBkb2N1bWVudCBjb3ZlcnMgY2FzZXMgd2hlcmUgZ3JhbnRzIHRoYXQgYWxsb3cgdGhlIFVBQyB0 byBvYnRhaW4gYW4NCiAgIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBBUyBhcmUgdXNlZC4gQ2FzZXMg d2hlcmUgdGhlIFVBQyBpcyBub3QgYWJsZSB0byBvYnRhaW4NCiAgIGFuIGFjY2VzcyB0b2tlbiAo ZS5nLiwgaW4gdGhlIGNhc2Ugb2YgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50KSBhcmUgbm90 IGNvdmVyZWQuDQoNCi0tLQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Tue Apr 28 00:59:34 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C93A0E29 for ; Tue, 28 Apr 2020 00:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DFbo_wjy9nBS for ; Tue, 28 Apr 2020 00:59:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 68FE93A0E28 for ; Tue, 28 Apr 2020 00:59:28 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 49B1018F0; Tue, 28 Apr 2020 09:59:23 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> Date: Tue, 28 Apr 2020 09:59:22 +0200 Cc: Olle E Johansson To: sipcore@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 07:59:33 -0000 Just FYI I discovered that = https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html = aim to update 3261 and a lot of other RFCs. This means that SIP-compliant implementations will have to deprecate TLS = 1.0, 1.1 and earlier versions. The UTA wg is also upgrading their BCP for TLS, which means that TLS 1.3 = will be the recommended version (if their plans go through). Cheers, /O= From nobody Tue Apr 28 01:08:18 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B485E3A0E73 for ; Tue, 28 Apr 2020 01:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 H_ap9cWjVIkZ for ; Tue, 28 Apr 2020 01:08:15 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2085.outbound.protection.outlook.com [40.107.21.85]) (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 EBA973A0E62 for ; Tue, 28 Apr 2020 01:08:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ExiD6zdK7N+Gzy6o5vgYAEa98Wx3HNgax6b/Qno7fjyTlsgeurrzQNKv8gycXJJX2BLjRmiTa4j2xYbqAEjDGGK+cetTTXhPIIxci085h90JTGubnwS5g48JumBzTnnOjfbutJypbUDxAhNqe9WjBvOb3u/tu4u+MfOnqf6cV3TKYmMht0r+g5oeLAmoMlLse5hsFFzMBgC8m5Ba6AniO04Mypi5ZuCZj2IaOUynMI8G1zW5zpuHVNK4DQilS38bMHgfQeHq2pRV2cg3F/MSp9pi/pF2ZadcpvO4Zo+3fw/Xz1D0Wy/3h2Tg73YhBXEOvA9F4aUZFHGa6Vi/zQm3pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yc7nlBfYvnlZoVt0WofJOY2Ovi3YjdODrnuFD9YpMFA=; b=hnBP9mV/fvmvYVMoaG0U7/NXxKy0ac+HzkoG2mw1aO5bRde8yuXcVxB8KLiykaGBW1SIc+Kva1dI7ojgcpRqvnhrJwhvk9T9cIw6dHagHEnjR/BdmTnlIppl4R/oJ5dtl5ElTpSuGh6pjjoYCfb7Mq4rsRPpG5OJx2dS0BJguu7kD8CVmDivQLPY6r7ij87F6Ye5Ogd63ebVHy0TYIqdh+f+g7ses5SCswmLVc5vuNK4rkD8lGnCxbEjCfDcLBORAVWa0cWKxxrbGgdBChVbBuhAvJ7Q8TBcebkPUeCS9TVm9iXK+IbDjLVfWXEM0f5D0pZe1hyIzILAs0rWk1e/AQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yc7nlBfYvnlZoVt0WofJOY2Ovi3YjdODrnuFD9YpMFA=; b=Bg+4Za/3ZmeAxIdBeB76SYnUE9yD0AUEWE1FrkoMHyeHYG5RbLbE+4apHhWbwzqZU50W2hN8G+CoIPWi/gfLYEGP1xcySQG1sbdEFs5iYwzSJNcj7bobVC9R+/Ggq+o9sAYMtxnd3r/+dvQWv2DldLaR/Rck/qp8yHXo+IqSbAM= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6915.eurprd07.prod.outlook.com (2603:10a6:20b:1b3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Tue, 28 Apr 2020 08:08:12 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 08:08:12 +0000 From: Christer Holmberg To: "Olle E. Johansson" , "sipcore@ietf.org" Thread-Topic: [sipcore] Update for 3261 Thread-Index: AQHWHTL/a0NzRSlRQUSv5voBN49UhKiOYDWA Date: Tue, 28 Apr 2020 08:08:12 +0000 Message-ID: References: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> In-Reply-To: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32b7ec15-9a0a-4de9-234b-08d7eb4b4bbd x-ms-traffictypediagnostic: AM7PR07MB6915: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3173; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(396003)(346002)(39860400002)(64756008)(66446008)(66476007)(186003)(966005)(66556008)(15650500001)(316002)(8676002)(86362001)(76116006)(66946007)(81156014)(110136005)(6486002)(33656002)(8936002)(6506007)(478600001)(2906002)(26005)(36756003)(5660300002)(71200400001)(4744005)(44832011)(6512007)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Jp5iofYN+OBFtpUPsOb0PxUm6Vv72YbGWmdIUG8j07uXpgYlVUafRIzVL4vK2i1YRdwzSuBxLGJipkWt8/JNroJj6tdcX4dMa0yAiwvHtGggVT1MCTlLBFkHoKUeCG4CQHr1f4b7rUGYJxQS6KFglujCq7VGsFQO6AnSz4BRgFJvMzNxWyixxkD4RoVhBTZXL6e+CsiH0nUwWNlnJstgJQca3H7YwtO4ksAOrG/vvZ8pOVbFXInYJmUxDPEQgLuqJwDVfsW1fS60OAp3rOgNPxkjhoYuVs1OQWSDHDQwe8AUiEv7u3/Sz+GsFZ4HU4bzpS3F6DW9Q9G8tqSueWcrsCpEesDA9URXVTG/wMEncn8fvr2QOrTeV+dqiscDdd/S/AhI690odwk50Hh/tcUL+1CyTIAU2Dub7Mo0FIuoDfOW4Q7lgvSB7MS9TMs+bgFZVlvQCPP7yU6/OJfflAsmBD6j9Et0h5k13XQ148fAVo1ateZUsYeNyDmF12+2Urf9138Yv5XLLaq3Y/m9XX5vyQ== x-ms-exchange-antispam-messagedata: iPbFYMufbQJDxomVl1OY4ysxgGcAwpHA1OZxQtJLCfES95sVnHkAqth1rE564dvdLffiu9JbR6dvZ/odYvKxKePrQnJ4uKCxrtw8GUvPxnzF6leTYgGYSTqM514ocjQhlS7tdpKKeTlLHet30f3I3XN/twtGZ7b5ATSvqTaRvaNXGiMmI+LYQ4RN9yGclG2gc0CXwPE1jqTb3m6tXoZC9oADNquckhjfS26yTe5FLcAYZ6zgutqh1XsvujLgeBG8E9D1tdRGyrIfhra0rNyaQMR6v5co4h+NCxBBu0ILj6o4VzIKCMCW3T71ccDvvKKjjl1JAhMe0r84VFXRQMNAsg3PFcY8OXfzGNO9mSMNSopFvApAbUAaAOancKmz1r3HRtehelIz1cLaf7CWNE3s0puk9Jye5BFAq/fTou00MFRd1c81MTrE1vbFKjm+lIvIhgwN+Txqfcm7EuOl/LeK8Bk/ONJcAjD4HbR88N5WzONZXZODgsqyHKWRV2ilpgDvef282jr6nHH+P34DijDu3pGbpLb8/JNURf7biEIQi5zeOHa6lwCe6gxbEvpIU0rT146ceVKzI5iHTO+x7EBtTan6yRcLkBx7zGOhZ+YoOQ6lnux7PRFIV8VyygR5QrCvY71yI6KLaH4JvjeYCc4vAadJBJ9brBFK1zvucWtUXotAGcFldFRdyCq/qYSIX4nVcrsikK1GLUDIazmj7IkxZNcehJ9A4mHNU+LXaFvIQP6i0YkAqbeLBX4LmducSKMpd5kV7LWcSP8oU7S0uOmkQT0MndxLVwc+WYeqFX4fkBY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32b7ec15-9a0a-4de9-234b-08d7eb4b4bbd X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:08:12.1009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FJpDibGOOP3bRPJKlUohRhWvjnGZZGE8NM7kj47+1sHpB+o4JCY15M5PpfY2UoT/aM6BRKC8xsWwNMd2B3+waoB7pwibSNSocCLkoeanyjo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6915 Archived-At: Subject: Re: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:08:17 -0000 SGksDQogICAgDQo+ICBJIGRpc2NvdmVyZWQgdGhhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2lk L2RyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZS0wMi5odG1sIGFpbSB0byB1cGRh dGUgMzI2MSBhbmQgYSBsb3Qgb2Ygb3RoZXIgUkZDcy4NCj4gICAgDQo+ICBUaGlzIG1lYW5zIHRo YXQgU0lQLWNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZlIHRvIGRlcHJlY2F0ZSBU TFMgMS4wLCAxLjEgYW5kIGVhcmxpZXIgdmVyc2lvbnMuDQogIA0KVGhpcyBoYXMgYmVlbiBkaXNj dXNzZWQgb24gYW4gSUVURiBsZXZlbCBiZWZvcmUsIGFuZCBJIGRvbid0IHRoaW5rIHdoYXQgeW91 IHNheSBpcyB0cnVlLiANCg0KSnVzdCBiZWNhdXNlIFJGQyBZWVlZIHVwZGF0ZXMgUkZDIFhYWFgs IGl0IGRvZXNuJ3QgbWVhbiB0aGF0IGltcGxlbWVudGF0aW9ucyBvZiBSRkMgWFhYWCB3aWxsIHN1 ZGRlbmx5IGJlY29tZSBub24tY29tcGxpYW50IHVubGVzcyBpdCBpbXBsZW1lbnQgUkZDIFlZWVku IFN1Y2ggaW1wbGVtZW50YXRpb25zIGFyZSBzdGlsbCBjb21wbGlhbnQgdG8gUkZDIFhYWFguIA0K DQpJbXBsZW1lbnRhdGlvbnMgdGhhdCBhcmUgYWxzbyBjb21wbGlhbnQgdG8gUkZDIFlZWVkgbmVl ZCB0byBleHBsaWNpdGx5IGluZGljYXRlIHNvOiAiQXBwbGljYXRpb24gWiBpcyBjb21wbGlhbnQg dG8gUkZDIFhYWFggYW5kIFJGQyBZWVlZLiINCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCiANCg0K From nobody Tue Apr 28 01:12:11 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D13A0EB8 for ; Tue, 28 Apr 2020 01:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Yzc8Zcrequit for ; Tue, 28 Apr 2020 01:12:08 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 F2CC63A0EB6 for ; Tue, 28 Apr 2020 01:12:07 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 0072F18F0; Tue, 28 Apr 2020 10:12:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 28 Apr 2020 10:12:03 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:12:10 -0000 > On 28 Apr 2020, at 10:08, Christer Holmberg = wrote: >=20 > Hi, >=20 >> I discovered that = https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html = aim to update 3261 and a lot of other RFCs. >>=20 >> This means that SIP-compliant implementations will have to deprecate = TLS 1.0, 1.1 and earlier versions. >=20 > This has been discussed on an IETF level before, and I don't think = what you say is true.=20 >=20 > Just because RFC YYYY updates RFC XXXX, it doesn't mean that = implementations of RFC XXXX will suddenly become non-compliant unless it = implement RFC YYYY. Such implementations are still compliant to RFC = XXXX.=20 >=20 > Implementations that are also compliant to RFC YYYY need to explicitly = indicate so: "Application Z is compliant to RFC XXXX and RFC YYYY.=E2=80=9D= That=E2=80=99s interesting. Thanks for the feedback. So what=E2=80=99s = the point of =E2=80=9CUpdating an RFC=E2=80=9D and the references? /O From nobody Tue Apr 28 01:24:08 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA063A0F37 for ; Tue, 28 Apr 2020 01:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 XQiGiNzpIwoz for ; Tue, 28 Apr 2020 01:24:03 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2040.outbound.protection.outlook.com [40.107.21.40]) (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 60EDD3A0BD5 for ; Tue, 28 Apr 2020 01:24:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eTFuGFmguNX8Y5aqBYYHraovppnaJ3d6TcLbNvsniTpN5VfISU7LUx6FpgnAfe0lJulPkddxiwCrZRTxf+7PM0AT7RGqjzX1vFg3TxcRi6tE6JFmdTCf8Q7LWLZxdo1Xr8R+VnDilD8O0dmA/Cy+MZGn75vCDYOEt2tb6bMbrC6t00HrUqExjlBoY4VvFEXq1sDkt76zbk7LkNzqxywAG2lk3kuVn3VsLIxauXLX4j4F53wRu0OGZSSk4chAhWxUwW/sEHqw1F9pbhRoyOmcPmpAou0Jg8YokVEKIPLltS3XvpRLoktufdl+wS+57zGkzsKKusDJOL888tq1/r8umw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IqBta8tcN0rzjl6xKeSP83eXHhZEB03GeXFAkPDDNQk=; b=eJAvK8tIoq3lYgao6c1exLXOs3XTu01/LUG9TugIdAVBADc70IrymS3PXX9MKQUGgq/RsGMWz4v99TaFTKq+8Sw9bp9nk4ABB/MVw2Ug4GRn2z8wqAfvQS1PWf13zswlYdHGUrS0SyYMbNGTCKp8IaeNWXo2SbibHoctksLuTuW0EocNaoyWX1GvVco8BKeVOONA+UzKgNxb5kHSal+7Xxe75pNLyzWmIm8B27Pc4NQFTfUFQXS5Gp4ZzMY+DhDT33CfZnIzgjOEbBbr1JKODEwlERrmUe+1GRoCtLlG4wwoleh6ll3vffsP2d7I2OPwe48lQ6to9P/b7XemdWY3Vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IqBta8tcN0rzjl6xKeSP83eXHhZEB03GeXFAkPDDNQk=; b=UQR7HINfHasTBt7zhu0w7+W8o4BDg9BiGgiu58TtwAfHOkq5lORSI4ZZlYFObGHOIKhr5h28231OF1iH6PfAcalCCpTcYNZKM1Aly8bogQLiJq7ZJirGlmUg3ChA90tlkiHW8vYoXqm+MZfx0WH4NeSQedR4bwnATREEsQeCVwM= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6771.eurprd07.prod.outlook.com (2603:10a6:20b:1bd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.12; Tue, 28 Apr 2020 08:24:01 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 08:24:01 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Update for 3261 Thread-Index: AQHWHTL/a0NzRSlRQUSv5voBN49UhKiOYDWA///OyoCAADWiAA== Date: Tue, 28 Apr 2020 08:24:01 +0000 Message-ID: <0D6C66F0-CF13-492B-9640-0364FEA1E638@ericsson.com> References: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8470863a-6193-469f-d8e0-08d7eb4d815a x-ms-traffictypediagnostic: AM7PR07MB6771: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(5660300002)(6486002)(6512007)(6916009)(26005)(36756003)(2906002)(4326008)(33656002)(66946007)(64756008)(66556008)(6506007)(76116006)(66446008)(71200400001)(66476007)(2616005)(478600001)(8936002)(966005)(8676002)(316002)(186003)(15650500001)(44832011)(81156014)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TPlG9sOBSLtdNvCf8Z0HwdUAQWBVMJIO+VuvoBIH1XtmbpqTP+u8uN5odiQoQ3BQ7kuQFPyK62KAgZb7nV9WJvBTe3FCGasn3hFcW6yZGDygNz9Pz+Rc2hCdgIXrbnCzibJevLZ4nrj9znWxV26vdxywH4LhdnduSG8sYeeaezRikCsjT8HUlxq9iYE+0yoxZF6Ya0tZ7kEScMHW/edER/7h7pib5parG8Wcn/9WicDGDzpCcX8NxxUPjmlOhQUoDxC1y3GhaiisuDpEtUgnpI6kfoyGB6j6rmBTqKuWSfvmFoha7un4eiZTMvcYrShXf5mr6hDIgl1Mig7/q5/B2NebwBa0ErCsKTTuMOnJFFWLIaNJFlFE6SwSgDn7Jaaw2ZI8rdhpxFUMaIDq5Haq00SezDd7caWHJiIp/aTT/lFzT0I+qbZXgmsq4kgqLDILlZW7xCPzrZpo9N+AhXuUSWlhPkhTS567Oud4bmxyPAwInrCo1lryAhthSq6C3VK/FcRMhILsYO0plPy4+xNryQ== x-ms-exchange-antispam-messagedata: WvSG2Bu7ozgvPjZAJgxq0Kh8heFIN1zjR5PIZp9WtQUpJYDCCpVb+mG2ZJMxdbZEEqSazaTZIGb01Uu1DoVSnZrm9r2KorE6CLl/ewAq0zYLr/Coj9ttA+rtvtoOM0OntpvPjEN465fl+MrG8UGw+gYLIpDTsg0OE2GPiYxbLoJcNo1iTKUi9tGPy9jFVyLdqH0ggmuW30StVA6geg8o2WeBcrVGEc5yrfHsivP/QU5mHVOKeS7QGNnjnAcCQ98o6iVdccSXZ+5FfrOt2k+tG3TgGLosDJ3ZO9CgVr/taCyxkIfP19NBD8452RRTN8TH0qV+45xE5xnyXD1K6gZUKwH0BhuRztd3Jrtr8FAyN9AhfggqWXPTP/OMrkSAPntHTawMpeYfK+AUoihMB/yad1Qd0LnidpKTl34vIHSd8CgxLulMHgIm49V0g96etGu6ep0Qyr7aOtQsjdljrICJj0hxNBIlh8rAoTKkNEJLCKXUWJSsceeg4kVwyNZXsdJsHB6rMKjx8MOLQDwI241rntCxoNjwZ4izEnBSrG7ptSww2it0MMtnZREgR/vTxJbCUBcwnW8DaFQM349VmMOQMaGQpNpwozh+pWIwzxWLwdl94gsD0V4G004Mn9WzXL6zf2IkoLpwPgC54LwUpECrI/6UmMjhrKJv2LDfDLyrFrhjG1/mnpZJHTSuv9neNhPX6WEddx6DKqTkqb/ZPmVjSNLzYVlbH7jLam1gUUzb5rZ4Ww463YqAbjGIgZI8iKcjfNCyD4ZZ1DMEHyX++y2ldryFBQoH0s5LVNfhSPQhZ1k= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1E22D18790E6BD4D8B7F536270DC5925@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8470863a-6193-469f-d8e0-08d7eb4d815a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:24:01.0542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HtdoxJBsjss1oK7hdBp9Zyo+AV9W6oinP5+dnRwliQ/uzqEsnrv7aCrPwOyTGcvDhns+X9KrVITYIOfcJlgfRpN0s3KQ2DT8+gwApeTlsXA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6771 Archived-At: Subject: Re: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:24:07 -0000 SGksDQoNCj4+PiBJIGRpc2NvdmVyZWQgdGhhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZS0wMi5odG1sIGFpbSB0byB1cGRhdGUg MzI2MSBhbmQgYSBsb3Qgb2Ygb3RoZXIgUkZDcy4NCj4+PiANCj4+PiBUaGlzIG1lYW5zIHRoYXQg U0lQLWNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZlIHRvIGRlcHJlY2F0ZSBUTFMg MS4wLCAxLjEgYW5kIGVhcmxpZXIgdmVyc2lvbnMuDQo+PiANCj4+IFRoaXMgaGFzIGJlZW4gZGlz Y3Vzc2VkIG9uIGFuIElFVEYgbGV2ZWwgYmVmb3JlLCBhbmQgSSBkb24ndCB0aGluayB3aGF0IHlv dSBzYXkgaXMgdHJ1ZS4gDQo+PiANCj4+IEp1c3QgYmVjYXVzZSBSRkMgWVlZWSB1cGRhdGVzIFJG QyBYWFhYLCBpdCBkb2Vzbid0IG1lYW4gdGhhdCBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIFhYWFgg d2lsbCBzdWRkZW5seSBiZWNvbWUgbm9uLWNvbXBsaWFudA0KPj4gdW5sZXNzIGl0IGltcGxlbWVu dCBSRkMgWVlZWS4gU3VjaCBpbXBsZW1lbnRhdGlvbnMgYXJlIHN0aWxsIGNvbXBsaWFudCB0byBS RkMgWFhYWC4gDQo+PiANCj4+IEltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBhbHNvIGNvbXBsaWFu dCB0byBSRkMgWVlZWSBuZWVkIHRvIGV4cGxpY2l0bHkgaW5kaWNhdGUgc286ICJBcHBsaWNhdGlv biBaIGlzIGNvbXBsaWFudCB0byBSRkMgWFhYWCBhbmQgUkZDIFlZWVku4oCdDQo+ICAgICAgDQo+ ICAgIFRoYXTigJlzIGludGVyZXN0aW5nLiBUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gU28gd2hh dOKAmXMgdGhlIHBvaW50IG9mIOKAnFVwZGF0aW5nIGFuIFJGQ+KAnSBhbmQgdGhlIHJlZmVyZW5j ZXM/DQogIA0KVGhlIHJlYXNvbiB5b3UgdXBkYXRlIHNwZWNzIGlzIG5vcm1hbGx5IGJlY2F1c2Ug eW91IGltcHJvdmUgYXNwZWN0cyBvZiB0aGUgcHJvdG9jb2wsIHdoZXRoZXIgaXQncyB0aGUgcHJv dG9jb2wgaXRzZWxmLCB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtcyBpdCB1c2VzIGV0Yy4gT2Z0ZW4g aXQgbWFrZXMgc2Vuc2UgdG8gaW1wbGVtZW50IHRoZSB1cGRhdGVzLCBidXQgbm90IGRvaW5nIHNv IGRvZXMgbm90IG1lYW4gdGhhdCB5b3Ugc3VkZGVubHkgYmVjb21lIG5vbi1jb21wbGlhbnQuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCiAgICANCiAgICANCg0K From nobody Tue Apr 28 01:34:54 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6913A1098 for ; Tue, 28 Apr 2020 01:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wjdN4Q6AYWIB for ; Tue, 28 Apr 2020 01:34:50 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 5EC223A10F2 for ; Tue, 28 Apr 2020 01:34:49 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 15B8F18F0; Tue, 28 Apr 2020 10:34:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: "Olle E. Johansson" In-Reply-To: <0D6C66F0-CF13-492B-9640-0364FEA1E638@ericsson.com> Date: Tue, 28 Apr 2020 10:34:45 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <27A856B3-8204-414B-AFE3-67D63E6D05FF@edvina.net> References: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> <0D6C66F0-CF13-492B-9640-0364FEA1E638@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:34:53 -0000 > On 28 Apr 2020, at 10:24, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>> I discovered that = https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html = aim to update 3261 and a lot of other RFCs. >>>>=20 >>>> This means that SIP-compliant implementations will have to = deprecate TLS 1.0, 1.1 and earlier versions. >>>=20 >>> This has been discussed on an IETF level before, and I don't think = what you say is true.=20 >>>=20 >>> Just because RFC YYYY updates RFC XXXX, it doesn't mean that = implementations of RFC XXXX will suddenly become non-compliant >>> unless it implement RFC YYYY. Such implementations are still = compliant to RFC XXXX.=20 >>>=20 >>> Implementations that are also compliant to RFC YYYY need to = explicitly indicate so: "Application Z is compliant to RFC XXXX and RFC = YYYY.=E2=80=9D >>=20 >> That=E2=80=99s interesting. Thanks for the feedback. So what=E2=80=99= s the point of =E2=80=9CUpdating an RFC=E2=80=9D and the references? >=20 > The reason you update specs is normally because you improve aspects of = the protocol, whether it's the protocol itself, the security mechanisms = it uses etc. Often it makes sense to implement the updates, but not = doing so does not mean that you suddenly become non-compliant. So in order to really upgrade SIP we need to write a replacement that = makes 3261 obsolete?=20 /O= From nobody Tue Apr 28 01:39:26 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06F83A107B; Tue, 28 Apr 2020 01:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 w2OriCsbNHkK; Tue, 28 Apr 2020 01:39:22 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10042.outbound.protection.outlook.com [40.107.1.42]) (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 184FB3A1071; Tue, 28 Apr 2020 01:39:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qmt4+Vm1SqBmmt0o835vebGzP3RMukrGwUhc/EUfnSbzYQv30tWoEPG9nBifbFgEHs4XRo64HNJHzUsS735pzJvgIKQhv0cj3X1PlvMd3J0o15KflnzwDMm9Y8MooOtI17DeptOQt2nu2B3fmy/e4GGEJJ+XC94JAwbFrd7BoOtWpOPDPhCs7sJW0Ys7Sp09cmwii6/p9UnAWm/8g1xI1k+uKDZq5Z1I36PSJ+QPsKS3Axif/GCxT/I10oAEZ2jvhJHnqNkSzaw2t/yJigWqA1Xes5d/zEao07HR3OWQ+ShLoGuaXzSm/flr5mLFj9Dr6TXKMNGG8DLYT4lt3t1fCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rwxZvQwtFHRGcsY6lIcQMYjzxxkdRi5iNtODLibFDPc=; b=XA5Utf+lWFlWs6tdhpHDIOlOVkSeo5BpMGTtMQic/v+xHLujCidLg3EKCYo4kURbx/h6rK9tdo6pgW63tqtIejGwhsQ04gzK6mr1/qRXSF0c8vt/fLqeaPtex3ZKQ/EatNkFOsLbR1Bvir/s0Ld8QUEWAZ76OxPqPMcL0RsWe2qIM2xIKQJy+0UcJp6WuNuGkoqYBRRYP0x54XjbfZ6gXqyTLqgFvfUwmmUYuz3PdBaVoC3gCAoAJWrdtgViYzPWkGM/QiX8nFHi9V6cddift0nu6zfeHTFCxhCPYTlJlKCQYeuw5IViSxvw0Yif6i8gCBj5xSxYXuG8+dcNfESzaA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rwxZvQwtFHRGcsY6lIcQMYjzxxkdRi5iNtODLibFDPc=; b=Kfd7MnLwLADN5E8tQE0/EGJFSwr/QIic84lJTc4QjE9VYL3QQr3t+ifFSmP12xIOsGPwJnqIv1mRZl4N8DDqmFlflFq62aYW1byiTVwh/GDcjwMhp8+VShY75mihhcuPgitzvKuNnHd3x9OyErcliHQobVjQeYRWfpcOwDRePNo= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3754.eurprd07.prod.outlook.com (2603:10a6:7:7e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Tue, 28 Apr 2020 08:39:18 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 08:39:18 +0000 From: Magnus Westerlund To: Christer Holmberg , "iesg@ietf.org" , "pkyzivat@alum.mit.edu" CC: "sipcore-chairs@ietf.org" , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request Thread-Index: AQHWHM0jGFXph8PsA0+ASqfFfMQaaaiON3WA Date: Tue, 28 Apr 2020 08:39:18 +0000 Message-ID: References: <6BA45301-2E1D-4050-9C13-6B8BA7094B79@ericsson.com> In-Reply-To: <6BA45301-2E1D-4050-9C13-6B8BA7094B79@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [98.128.243.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b81ba8c3-2700-4277-2412-08d7eb4fa3ef x-ms-traffictypediagnostic: HE1PR0702MB3754:|HE1PR0702MB3754: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(6512007)(86362001)(6506007)(36756003)(186003)(44832011)(478600001)(6486002)(5660300002)(99936003)(26005)(316002)(2906002)(966005)(66946007)(66556008)(110136005)(66446008)(81156014)(8676002)(8936002)(54906003)(66476007)(4326008)(66616009)(76116006)(64756008)(71200400001)(2616005)(99106002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LzYguFeZoTXW8LSa006xWyXi+c81cTyEezasaorNEsJmRGWakUP+46blUzFjgN9NzNAM0TUAx1Kjn2tNDxC6hxfWK4zvA0Ua8qnM3OEbBlBbp7rLi4s+nvFHbBgvEeWE5INUdsPyWNoz8NgNMCSI4Gv/9cyxXZReZ712aqILMpjQYxgTRXMgDycKJTo0AjtrbWNk64Vb714ZYI7y7R3C7CLoR9hWCONuj8viMkeFDCrsl2i9syemUi5G7SsjZ/MfDFicl/K7s+yWwQ+usIydvqPBPprux6BNym9H7tDGtnofz7X6if/gCtPofJ54s3dFejpcQxzH3Fj68bTxhPJNX7+VS/4yD1BYtu6f1XnI08plMXR/u26VFZ8yCm7zS+/IBYp6/xzgwSvTifbUgOtNF5QXX6gnelNby95/kYv26gFp3d0kH4f77Pc/Tf335ZjnI3GT1/CZkTce1Bed5MaSvqNOL0zDqhmHkO0qr9gh+op3gfC1/gc83m8af5ygSGspANg2kvG00z3zuoP2B4eqxeYgaCjdXZOSoTfEdy6UlBxw2ZSeQySPhdK7US58MQo5M3VcD1q6/zXULou9in1Eeg== x-ms-exchange-antispam-messagedata: dqxUVL5GU4SLD1uRk8mQEp8HRt7hYq7vpW7tMLQqOyuuAUibnlz6cU4WLt3oaGT+15lbFdDk7y+zKjCq3iqCK5qk7Za5lVmudp0hC6MfFbLzn4xmYe5Lu0Xzo+SNRQdkGJg3dYg05sKBDmZaKeypeueGTUwha0b/o/2owHGwddAiOOTUhVvXl0tplA7BwFe8RZaS3IL9lKNU/Ov3kkGdVi6Q6XZ68l7hi67KR23s2+zX6JNXqBYiafXYiynCbQOcBwRF0Lmf7Eygt64MHTbmXzjDMJvQknTvbC57elo7wAFkFdYGvdXXyMMYnreizeh04xiuT7YwRldC1iXz/D5FhsrIWSmfdZh1atzuMizDR1ZS1nsI9wxG58HMUEfJMvbZGDNjFfZ5Swm9SujrdGSvIW4fpwOyTWEd/fq33XbT/W+ipZNOQ0YM1nUBgP/U3H8ajvXdVH26nycFnmPtz0G3ndqw8ZMaPJiegJ42DKwiW8v/ibHuN5pXwz2tygk13cdAlaJmNAkxbvtancfuV/kAFvYp5t6JDG+oiaLj8IvOMf3Mfeg0J2038tB18Gb4Ml9erUGFiJ/p04OJrWZyP61degTqYwOm0Os764x429B/ca4psXpAwSWjLzIVuH9KWW4wtRPd81ID4UQGYVJimTbbGybVQGxnbOi19hR8O79VsZc7HOX9p+2OTGmezlw7L8ONv9PLHWJ8QFG90H5Ez5aVjY468enn2febhnJutggFf+chlVV50hutcveKjQpXop7Wd973/HbxdKf93nIbIkRmtYuI4fcJaPaqVvoSTMfVk7o= Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-qr7jcuXfYDEicS2SMl0f" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b81ba8c3-2700-4277-2412-08d7eb4fa3ef X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:39:18.0667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VYjpu5VNByaGOjmceDHaRbWNiRugLifOkabol5N5Kpoo6yVJ0alMebNq2kckoH8CFfwa1GBy+Dfsp1sjhpjjQPjBIMoxv8QVxWJXyfxjyeo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3754 Archived-At: Subject: Re: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:39:24 -0000 --=-qr7jcuXfYDEicS2SMl0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think keeping _ in authz is okay to do, and allowed by the syntax. So if = the WG want to correct this to have it align with the norm or leave it as it is= is up to the WG.=20 However, the changes did may wonder one thing about the the inclusion of sc= ope and error. The ABNF constructs defined in RFC 6749 are only including the v= alue part. So to my understanding they really should have an parameter-name =3D = value construct defined. Like this.=20 scope-param =3D "scope" EQUAL DQUOTE scope DQUTE scope =3D error- param =3D "error" EQUAL DQUOTE error DQUOTE error =3D The IANA section looks good.=20 Cheers Magnus On Mon, 2020-04-27 at 19:50 +0000, Christer Holmberg wrote: > Hi, >=20 > The following pull request commits contains the syntax and IANA changes b= ased > on Magnus DISCUSS: >=20 >=20 https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7/c= ommits/168086b4f1220620d063af07a3292b667e30ef37 > (Syntax) >=20 https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7/c= ommits/22f810025d1bf8df45875e92e4d4c11d0f574693 > (IANA Considerations) >=20 > Please note the parameter name "authz_server". Following the naming style= of > other header field parameters it should perhaps be "authz-server". Howeve= r, > for backward compatibility I would prefer to not change it at this point. >=20 > Paul, I would appreciate if you could also take a look at these. Thanks! >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =EF=BB=BFOn 23/04/2020, 22.51, "Christer Holmberg" > wrote: >=20 > Hi Magnus, > =20 > Thank You for the review! Please see inline. > =20 > -----------------------------------------------------------------= ----- > DISCUSS: > -----------------------------------------------------------------= ----- > =20 > > I think these resolution for this is rather straight forward, > however the > > implications of one is going to break deployed implementations. > > > > 1. Section 4: > > > > This is rather straight forward to resolve but you do have a SI= P > syntax > > violation in these rules. > > > > challenge =3D/ ("Bearer" LWS bearer-cln *(COMMA bearer-= cln)) > > bearer-cln =3D realm / scope / authz-server / error / aut= h-param > > authz-server =3D "authz_server" EQUAL authz-server-value > > authz-server-value =3D https-URI > > realm =3D > > auth-param =3D > > scope =3D > > error =3D > > https-URI =3D > > > > So RFC 3261 defines the Challenge construct as: > > > > challenge =3D ("Digest" LWS digest-cln *(COMMA diges= t- > cln)) / other-challenge > > > > Where this extension needs to match the syntax of the other- > challenge: > > > > other-challenge =3D auth-scheme LWS auth-param *(COMMA au= th- > param) > > > > Where we need to look at: > > auth-param =3D auth-param-name EQUAL ( token / quoted-= string > ) > > > > Please note what is included in the "token" rule. > > token =3D 1*(alphanum / "-" / "." / "!" / "%" / "*" > > / "_" / "+" / "`" / "'" / "~" ) > > > > the allowed syntax for https-URI in RFC 7230 is: > > > > https-URI =3D "https:" "//" authority path-abempty [ "?" que= ry ] [ > "#" fragment ] > > > > Which include both "/", "?" and "#" that are not allowed in tok= en. > Thus, the > > URI included in the authz-server-value MUST be converted into = a > quoted-string > > matching syntax rule. > =20 > You are correct. We currently reference https-URI in RFC 7230, bu= t the > definition in 7230 does not place quotes around it. > =20 > The same applies to scope and error. > =20 > So, we need to fix: > =20 > OLD: > =20 > authz-server =3D "authz_server" EQUAL authz-server-value > =20 > scope =3D > error =3D > =20 > NEW: > =20 > authz-server =3D "authz_server" EQUAL DQUOTE authz-server-value = DQUOTE > =20 > scope-cln =3D DQUOTE scope DQUOTE > scope =3D > error-cln =3D DQUPTE error DQUOTE > error =3D > =20 > =20 > (I noted that that Benjamin has some comments regarding the reference= d > RFCs for the parameter values, but I will address that in the reply to hi= s > review.) > =20 > =20 > ----- > =20 > > 2. In addition should not the "authz_server" be registered in t= he > >=20 > https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-= parameters-12 > > registry? > =20 > I guess so. And, then I guess we also need to register "scope" an= d > "error". > =20 > -----------------------------------------------------------------= ----- > COMMENT: > -----------------------------------------------------------------= ----- > =20 > > An additional thing. > > > > Is SIP directly using the HTTP Authentication Schemes IANA regi= stry > > ( > https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#= authschemes > ) > > or does it have its own tucked away somewhere? And if it is the > former, should > > its references for the "bearer" add this RFC as a reference? > =20 > SIP uses the HTTP registry. > =20 > (The SIP registry does register a "digest" value, but that is for = the > Security-XXX headers defined in RFC 3329) > =20 > Regards, > =20 > Christer =20 > =20 > =20 > =20 > =20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-qr7jcuXfYDEicS2SMl0f Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyODA4MzkyOVowLwYJKoZIhvcN AQkEMSIEID6qtPQWRxH7x9umcHKQKctUutqsIOGxdUORyDyaaOLjMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAWiWrvwn3/o8b FPF9kDJU1hd5F19gsaVTHVywzG1Q/k6dTuM8q7ehuoPjWHiYzKki+MGsGEh7DsMZpHdPzNgAM6c4 XZ1H8ayjDqH7ud/OtI0OokKy3CHWAsctLwjnokmDmxcdNZBmk5J1mch0INAB3//cSQZp9Ig4P2pu AWnitC+xjJg4ZG9eckU4PCh0zv7q9KLlrO3/JukEgpw0KicQ98GaK7Qbuy1zDdzkSYSZHPOW9/FG g9reCFWAVAusbG9R16JnitC+1+oiehEwAwulmHvd+htITklZYygAs6U6icsUOAzHL1bFO152jBVQ 9IsLOWCrIRQAEZ/xEyLjaB1AkwAAAAAAAA== --=-qr7jcuXfYDEicS2SMl0f-- From nobody Tue Apr 28 01:39:43 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C663A1071 for ; Tue, 28 Apr 2020 01:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 sYs6P2QVOkR7 for ; Tue, 28 Apr 2020 01:39:32 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30064.outbound.protection.outlook.com [40.107.3.64]) (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 3E7143A1105 for ; Tue, 28 Apr 2020 01:39:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dfeFBk26CXOBDWhtj9oxOXcgESY8b7qnEdzUpRQyiHRIMuqYVkhunD1Vas5h3T4WisHWUQ7P0zZSaknBPekJJuVIVS4QCRZHuwSl9XFN6mRzaIBDdUKo/sFFBcyJByKyhcOYi6OD+mOekbbNsAKW4xy1R5Ok0zqfP14s2Hpr4iA+Kq90kk85trofJlUAR+dVoFbVmReJqZW2ma1eSiSd8jV4DlOya2FrpXKG6qy9aVS9P19Tp+7QcKuEEGNoveWsTUGAmXdFO/YORTHeuH+LZFUsSJAsip9lUF2N5l5VtTM2kkHCg/BzU084VQSk9NfwLeGhiF+VJmvz+BfL80+oog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jhdSnD9WiYZBYYalFSPbKrBw22uMLbKDli5gHF0WZ94=; b=PETzJSHvJJ1yKAWEFAYbOrj/AccbRNGqBeFEZSFquv8XQBD7kZ17wkzEMZlWLWEaMcBKaqZhYU+t6L77JRlWpdu57bP/JO69ywVElzuVFopmaJpg83ZtZYchMiWhRaffLMyqpK9r+URE6B+i39nr1WAOO+2e2/2lQEUSmIMITwJ0AK6NumyVyWkJ8GO5Vd52CzhPsX/3PnlZ9/+p0eboV3px7HhZKF/0pTaWR2hOwddxGOQ5KN+CBzAyLO+XI202PfDc+Ry5mVeRVbFrE0qlK7n9sBGVxWG/OVH1lKEEYO7DKgNOdsVKELFIUSehaRWNj8x2iFT7Eb4mmM2Ps4Le/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jhdSnD9WiYZBYYalFSPbKrBw22uMLbKDli5gHF0WZ94=; b=MyLVfJYR9lm8qoz+iuEtqU0OIfcDCMYvXfsvZnhzWsomPBdoGSUa/dYnrD0MnAugzKVbsG53raIJokf+94LVakAjWADEnpCnRcz21h6OLrZWwmz+gHU9wS4FMNphaU7HNX/tjr2i+tRs1XziMYqmVg93uOu5gwAs/vYErHQYg40= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6595.eurprd07.prod.outlook.com (2603:10a6:20b:1ad::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.9; Tue, 28 Apr 2020 08:39:25 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 08:39:25 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] Update for 3261 Thread-Index: AQHWHTL/a0NzRSlRQUSv5voBN49UhKiOYDWA///OyoCAADWiAP//0LaAgAAzmIA= Date: Tue, 28 Apr 2020 08:39:25 +0000 Message-ID: <0748D8A5-9BD8-44D5-ABEC-4603B9AD017C@ericsson.com> References: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> <0D6C66F0-CF13-492B-9640-0364FEA1E638@ericsson.com> <27A856B3-8204-414B-AFE3-67D63E6D05FF@edvina.net> In-Reply-To: <27A856B3-8204-414B-AFE3-67D63E6D05FF@edvina.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24a0ba9f-11a4-4eaa-f66b-08d7eb4fa86e x-ms-traffictypediagnostic: AM7PR07MB6595: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(346002)(376002)(39860400002)(66556008)(66476007)(6512007)(5660300002)(44832011)(66446008)(478600001)(76116006)(66946007)(64756008)(15650500001)(71200400001)(6916009)(8676002)(36756003)(6506007)(86362001)(316002)(4326008)(2906002)(6486002)(33656002)(81156014)(8936002)(186003)(26005)(966005)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XkdgZiLSV8NBubmSiv2k6E3FJSnx6p+pNbbABbzky93u2qK9IZBnrCzmKWr/fClHhBRonZnBN0Fsk2FT+numHHvzXUFcKdtV6BZC6Pbu9WWrtNMfcFv7alg/xdqOP6gw8rBeZ1yCrcYAhHL3VvHn/bQNcc2j3/f69foqzHKvmLGF5qVv4N32LzbStEyLlYCzJud+LkPC/Qql64nUrnFR0WvmyW7dpObHI6kvQKoiwRGzPJHwXGVfcr33CrV5+ayj5GOPEVZtQ92pz9UF0yDL56tu4P+yKz11Ds/yxrXa8Pc39kyv2NEVLMHDR/4WEB+d5i5GNIu4Xh6LSxvXzxPtPrdcnMc4j5AyVIESTaKj2VyFhclO9ifsCifJ+unPD/Ve6z+s01IXHsvuhNEhtzo50GY3Xl+TK3jz3+Ja+kj+ultn5TWOOlBEGqy+qyNX/QDLLDyWtY0gNcE3UWv0Qe7VKlbiQOgJbca0M9SjP37xHvQkUCYip9KFlQEp6oKBrXNEhk9aOvaIRjhvaJOrYjscag== x-ms-exchange-antispam-messagedata: 9Rh4bKhRXRu7BmmOZ2qTgaOsqXwcDwtPkodAgVoFRDWG6N+AZP33ShuGeexiQIPLL8aNNq+lSTsnE/Zc9z0mwtLtTIaOVUBFnZb5jyOs9Rlo+xsQEabd9uzc0HFLF5v3pjKHh/ug5SWQhk3dv8avkEARhkUutqrz9Ff6850J7uYlEAJtyB/UmZSJ+IyM4wg97LxmYgIo29KdIdJdGO8DMATf4Yd3sZIK2pgcSSwGhynKKc4h28OeZCG5bK38hKSRatcKJ7VlOkrNE7PeJggseezV8jDKXIMo6Vbq2aOb51jGdMu64Qzu18XR3rhdyz09sxT6N2ak1Pq6Q+HYg1lF73wuBFPZW7HbsihvySCcHrz5EWI1fJjKdf/enKx/JaHIRgHc5XE+LWRospyTpsYco8cCCfz/aU91vOEdW1JqWGec1soJ4AwfhcO5Oa/JUc1B2H6j29Mopj/nkHmDJaEbn1JeHhm8tZ/l1TET0Nae0W83mdu1b3+Rn6WKeuETpFAUct8C9zngEz2tVDFM4U0BPvh257UIfbNtzXabKqW8r8XJjb3HRcwUo0PEuFRJJ8vSqegCyFeUeTrjuMMJWRkad0ps35SpOqFB8vOUEsUtuYIZJ8x5yeC4qEkXTCjY0fsu/pX/slwjG0obAmPCUyWg0eDJ0Elbv9dmURYhJhKj3P3DN+Kpxy63NPoGW3uITHS2MXjKII1c7VZlhZYRZ+hBfRXGFC+2WWrPgHgiT1ny0Tg3ccKB1tZ6QRJ4X+ikbes0R2XUj59zuiNUjWMVudN9p6dIf4NtkfISRc/pxryKg9Y= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24a0ba9f-11a4-4eaa-f66b-08d7eb4fa86e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:39:25.6275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 82zgOP3B1lDr6lG5qT2R49llDpUv7c+IozGUS6SrvGaAyY3OibQl80USe+RMOl+5vdyVPIj2UHZ2U2M/q542J6ZbpUcDv8yt4BMvW8SyWwc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6595 Archived-At: Subject: Re: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:39:42 -0000 SGksDQogDQogICA+Pj4+PiBJIGRpc2NvdmVyZWQgdGhhdCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZS0wMi5odG1sIGFpbSB0byB1 cGRhdGUgMzI2MSBhbmQgYSBsb3Qgb2Ygb3RoZXIgUkZDcy4NCiAgID4+Pj4+IA0KICAgPj4+Pj4g VGhpcyBtZWFucyB0aGF0IFNJUC1jb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIHdpbGwgaGF2ZSB0 byBkZXByZWNhdGUgVExTIDEuMCwgMS4xIGFuZCBlYXJsaWVyIHZlcnNpb25zLg0KICAgPj4+PiAN CiAgID4+Pj4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgb24gYW4gSUVURiBsZXZlbCBiZWZvcmUs IGFuZCBJIGRvbid0IHRoaW5rIHdoYXQgeW91IHNheSBpcyB0cnVlLiANCiAgID4+Pj4gDQogICA+ Pj4+IEp1c3QgYmVjYXVzZSBSRkMgWVlZWSB1cGRhdGVzIFJGQyBYWFhYLCBpdCBkb2Vzbid0IG1l YW4gdGhhdCBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIFhYWFggd2lsbCBzdWRkZW5seSBiZWNvbWUg bm9uLWNvbXBsaWFudA0KICAgPj4+PiB1bmxlc3MgaXQgaW1wbGVtZW50IFJGQyBZWVlZLiBTdWNo IGltcGxlbWVudGF0aW9ucyBhcmUgc3RpbGwgY29tcGxpYW50IHRvIFJGQyBYWFhYLiANCiAgID4+ Pj4gDQogICA+Pj4+IEltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBhbHNvIGNvbXBsaWFudCB0byBS RkMgWVlZWSBuZWVkIHRvIGV4cGxpY2l0bHkgaW5kaWNhdGUgc286ICJBcHBsaWNhdGlvbiBaIGlz IGNvbXBsaWFudCB0byBSRkMgWFhYWCBhbmQgUkZDIFlZWVku4oCdDQogICA+Pj4gDQogICA+Pj4g ICBUaGF04oCZcyBpbnRlcmVzdGluZy4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suIFNvIHdoYXTi gJlzIHRoZSBwb2ludCBvZiDigJxVcGRhdGluZyBhbiBSRkPigJ0gYW5kIHRoZSByZWZlcmVuY2Vz Pw0KICAgPj4gDQogICA+PiBUaGUgcmVhc29uIHlvdSB1cGRhdGUgc3BlY3MgaXMgbm9ybWFsbHkg YmVjYXVzZSB5b3UgaW1wcm92ZSBhc3BlY3RzIG9mIHRoZSBwcm90b2NvbCwgd2hldGhlciBpdCdz IHRoZSBwcm90b2NvbCBpdHNlbGYsIHRoZQ0KICAgPj4gc2VjdXJpdHkgbWVjaGFuaXNtcyBpdCB1 c2VzIGV0Yy4gT2Z0ZW4gaXQgbWFrZXMgc2Vuc2UgdG8gaW1wbGVtZW50IHRoZSB1cGRhdGVzLCBi dXQgbm90IGRvaW5nIHNvIGRvZXMgbm90IG1lYW4gdGhhdCB5b3Ugc3VkZGVubHkgYmVjb21lIG5v bi1jb21wbGlhbnQuDQogICA+IA0KICAgPiBTbyBpbiBvcmRlciB0byByZWFsbHkgdXBncmFkZSBT SVAgd2UgbmVlZCB0byB3cml0ZSBhIHJlcGxhY2VtZW50IHRoYXQgbWFrZXMgMzI2MSBvYnNvbGV0 ZT8gDQogICAgDQogICBZb3UgY2FuIHN0YXJ0IHdyaXRpbmcgYSAzMjYxYmlzIGRyYWZ0LCB0aGF0 IHdvdWxkIGV2ZW50dWFsbHkgb2Jzb2xldGUgMzI2MS4gQnV0LCB0aGF0IHdvdWxkIHN0aWxsIG5v dCBtYWtlIDMyNjEtY29tcGxpYW50IGltcGxlbWVudGF0aW9ucyBub24tY29tcGxpYW50LiBTdXJl LCB0aGV5IHdvdWxkIGJlIGNvbXBsaWFudCB0byBhbiBvYnNvbGV0ZWQgICAgc3BlY2lmaWNhdGlv biwgYnV0IHRoZXkgd291bGQgc3RpbGwgYmUgY29tcGxpYW50IDopDQoNCiAgIFJlZ2FyZHMsDQoN CiAgIENocmlzdGVyDQoNCiAgDQoNCg== From nobody Tue Apr 28 01:52:14 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653673A10FD; Tue, 28 Apr 2020 01:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 uFqU03IcF7a4; Tue, 28 Apr 2020 01:51:58 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60059.outbound.protection.outlook.com [40.107.6.59]) (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 06F6A3A10FC; Tue, 28 Apr 2020 01:51:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RW2n4gB2HBFjydh3roxCr49bqqV1LyT7kr2q3sxH1g+7RnJKUJPwY1EXUgk3M7DeVwQ/pI37OH0SVRk76PZ7MHN5UK4Bo3Th4wYD/rr7J67ylPFgZzmQSy2cr2RDrowq+otGl/ckdApFxV1nBFPD5X7lOP7uFhARSohqcwZG82CwcJbe4P5h0DhEsFYxo6IpaCEvXcrenOt0QCAnRlXf4/KVGgg8OgRQp1vHwPY433qyYggH56iw+1pFgiCrCUltQRZEAxFfPrHBwdYmY4bgQNmjdnJ34x3Vb0+FWZg73VfVOqsIGyvtO1KwCoPGAG+91IWq515w5X4BNq9DGUsa0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IvNIizxbsqZGHNr1tGEIRUoxsWEiCZm/r570bQUkM4M=; b=HOtIr7gONe/ek6FUaZ5eSmdnpwj8p1jtx6Ll/lPICtxKW6SWdcz9WsddyTgOgar/Xrt4pxqDCoQucne39DpFmTE/ZCj/duCTb6rhgy/WsiragsFfJmPTA87eax2eEUJmdroCv/UX2chwxWL9tc4yK9Rqn/FMOnQC+09Mwbh/YGB6s+ktAJxJ3kHZnO2lhWr8yWFQXmUIvaIvP+0sN+GU0stUrrMpUYhfyHyz97ikLKJpVH/wQP/juqB/59z39c5E0T9KCT/3YBpU4GprjzGJVGiqLokrOvLA4tk7FY1p6xZOKXF4IpBMZWHSGnf6a8zuGh3sNzq76LfDBZXcahGBgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IvNIizxbsqZGHNr1tGEIRUoxsWEiCZm/r570bQUkM4M=; b=jCZFv6vU8x7jLwwjcEdhNlPHY5Jzc/drQ5wmACcWzrH3C4hInCf1fpb4vYbZCTtLu7Qx9ss2bxFRzCNEFa3Ao4FX+nUTtIjahnmSAsYDoon99qH9CaSa63owLRp1nCMuo6XhNTpM6ad4LBd8NmbuRhpJoD5apJJR9KoJBc7dZ1g= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6389.eurprd07.prod.outlook.com (2603:10a6:20b:134::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Tue, 28 Apr 2020 08:51:55 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 08:51:55 +0000 From: Christer Holmberg To: Magnus Westerlund , "iesg@ietf.org" , "pkyzivat@alum.mit.edu" CC: "sipcore-chairs@ietf.org" , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request Thread-Index: AQHWHM0jGFXph8PsA0+ASqfFfMQaaaiON3WAgAA1wwA= Date: Tue, 28 Apr 2020 08:51:55 +0000 Message-ID: <07CBCA10-4499-4FD1-A75C-97440906432F@ericsson.com> References: <6BA45301-2E1D-4050-9C13-6B8BA7094B79@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61bb7570-482c-424d-1592-08d7eb516762 x-ms-traffictypediagnostic: AM7PR07MB6389:|AM7PR07MB6389: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(4326008)(99936003)(316002)(6512007)(71200400001)(478600001)(2616005)(110136005)(966005)(44832011)(81156014)(6486002)(36756003)(8936002)(2906002)(66446008)(64756008)(54906003)(186003)(86362001)(5660300002)(66556008)(66946007)(33656002)(8676002)(6506007)(26005)(66616009)(66476007)(76116006)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: M22pCpU6m+2lFnMlHV7nDiaL2b5ASHlNkglNtK5NGBqWt3n1jkwv8vaErw2VcjN7Uptyvk8xt88ZFEWGg51s1ZVvCZIgBcafCqx7GvwB8a6Lx++rdVRnY2qvAy8HA0LIB9RTjoLMzU6OO0Rpm9QDzS3JIUG07VG5zUgIF9SlaWwQFH+c3vP3zA9A0b6WNelLzfT1CWZoVD5L4+4MgNVW0nMaIFC3Mslg8c4EBGQYH//4zKYTqlamxIa/9uxY9Ygw0N+3BpsHF5+/KoUGzYXfIV4n85SKB68WTkxECHM/fPeUe7S3o24OI7h0bA+JJxF1qSxxo+S2EIDObD0CztDn+/iB/dIIoJt+VR6IK91DKWnGbwAVuPExD5J0/TR03S3D5x5dI+c2W7JIaWTCRhbVQhEwcZftx6j6IQ3GbrhaP3jrT9q3mk9HDXhNW6uRFwdUkaHdEKoMOlK5GQbhjU2JkWQS66EaV8fI3ZBHOFoF1GiEFmg1PqHtpDf51tsczScGdA+kBtCnTiRkk0W9+yEKCRRfwhsbon74sO2S3N3qC6tenCMHOxvlGKg2/CPoybY5 x-ms-exchange-antispam-messagedata: e26tS309ryCZq/swk3NiCrULl5JByZ/DW1tTYZWNXimdIMvEzlWuZIgIlUVgSR10BHcKQGO5V6E6+0PWscBp5+QdZ87tvtBBGBZudToJDnZMQnDjIdMR101nfBZdiEPfvXzTCGNaAymP/3pckOnv4KbxeLyHAB02YmNKkKIVsqyCZGFiYKUBkdERK/DanuLg9rZq3opdAQ0TDC3XjYn9fuh66PxXfFR0p1WT8Kvgj18K8y58eztt5zy6Ibzv9i2joMFiljBj/pcNpIn95Eg6Phardlucaf0UjDgarrvb49zWYMoCiWgKVsgFJUj/QMEhbvHC+GmfKfAyVu47a1JmC60+/dP4AxaiDeQ0aQ2FoZ3SkyvRg5peuucRVUH+Xl8+fX4JixssvhvNDqtxFzMfOir6B0CTOgA7P4Q4i0HgXm8JoO2ULfv6hG6yNTHYjzTcXaUQ72L5eCXT5x7TRrGqpodpISNGkhQee3Ii5tiemENyoGJHHXgGFdRA6Db5+ZIj99U+xgmjW3+eefzcT1dXuw86vmT2Rf9SjjZO36rhoIllZ6Vs65L4QMlFBS598qAVv35T83TqXE2VSK1r4Q6zvy/ilziIgSKHp3eXGipz2u+0uR9u5UmiWpLLbv1W+ikCTQRieV6mwwSiLlvMV07VycXyVEVv+M+k/zCO7PONk0fYpcvu+lcUokRj2wLOPTQ7HRk9ioSM0AIdUFfw/u9Nz5eY1dotBV65l3upu6n0nZX5+Onm48u5wpT8uMJPoWpp2QLl+yUPSY8NdWPQFUr9jdGP8EUe7mt6EEWbp8P8a/0= Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3670919514_1073972943" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61bb7570-482c-424d-1592-08d7eb516762 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:51:55.5006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ixBKhklsHXsb7TwqZ77JNpLE3LvpboyKT73H3FBoSJ04GKhW6S62dmrkJE+MMMnKv4FUbrp2FOTCYb6LC4ZUxypS4fq9wPfN6Slf9Z/XvvY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6389 Archived-At: Subject: Re: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:52:01 -0000 --B_3670919514_1073972943 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Magnus, > I think keeping _ in authz is okay to do, and allowed by the syntax. S= o if the > WG want to correct this to have it align with the norm or leave it as = it is is > up to the WG.=20 > =20 > However, the changes did may wonder one thing about the the inclusion = of scope > and error. The ABNF constructs defined in RFC 6749 are only including = the value > part. So to my understanding they really should have an parameter-name= =3D value > construct defined. Like this.=20 > =20 > scope-param =3D "scope" EQUAL DQUOTE scope DQUTE > scope =3D > error- > param =3D "error" EQUAL DQUOTE error DQUOTE > error =3D =20 You are right. Good catch! :) =20 > The IANA section looks good.=20 =20 Good :) Fixed in this commit: https://github.com/rifaat-ietf/draft-ietf-sipcore-sip= -token-authnz/pull/7/commits/fb8a94084c5ef3490f3e6c2ba2f00550d79fbb2b Regards, Christer =20 =20 On Mon, 2020-04-27 at 19:50 +0000, Christer Holmberg wrote: > Hi, >=20 > The following pull request commits contains the syntax and IANA chang= es based > on Magnus DISCUSS: >=20 >=20 https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull= /7/commits/168086b4f1220620d063af07a3292b667e30ef37 > (Syntax) >=20 https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull= /7/commits/22f810025d1bf8df45875e92e4d4c11d0f574693 > (IANA Considerations) >=20 > Please note the parameter name "authz_server". Following the naming s= tyle of > other header field parameters it should perhaps be "authz-server". Ho= wever, > for backward compatibility I would prefer to not change it at this po= int. >=20 > Paul, I would appreciate if you could also take a look at these. Than= ks! >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =EF=BB=BFOn 23/04/2020, 22.51, "Christer Holmberg" > wrote: >=20 > Hi Magnus, > =20 > Thank You for the review! Please see inline. > =20 > -------------------------------------------------------------= --------- > DISCUSS: > -------------------------------------------------------------= --------- > =20 > > I think these resolution for this is rather straight forwar= d, > however the > > implications of one is going to break deployed implementati= ons. > > > > 1. Section 4: > > > > This is rather straight forward to resolve but you do have = a SIP > syntax > > violation in these rules. > > > > challenge =3D/ ("Bearer" LWS bearer-cln *(COMMA beare= r-cln)) > > bearer-cln =3D realm / scope / authz-server / error / a= uth-param > > authz-server =3D "authz_server" EQUAL authz-server-valu= e > > authz-server-value =3D https-URI > > realm =3D > > auth-param =3D > > scope =3D > > error =3D > > https-URI =3D > > > > So RFC 3261 defines the Challenge construct as: > > > > challenge =3D ("Digest" LWS digest-cln *(COMMA dig= est- > cln)) / other-challenge > > > > Where this extension needs to match the syntax of the other= - > challenge: > > > > other-challenge =3D auth-scheme LWS auth-param *(COMMA = auth- > param) > > > > Where we need to look at: > > auth-param =3D auth-param-name EQUAL ( token / quote= d-string > ) > > > > Please note what is included in the "token" rule. > > token =3D 1*(alphanum / "-" / "." / "!" / "%" / "= *" > > / "_" / "+" / "`" / "'" / "~" ) > > > > the allowed syntax for https-URI in RFC 7230 is: > > > > https-URI =3D "https:" "//" authority path-abempty [ "?" q= uery ] [ > "#" fragment ] > > > > Which include both "/", "?" and "#" that are not allowed in= token. > Thus, the > > URI included in the authz-server-value MUST be converted i= nto a > quoted-string > > matching syntax rule. > =20 > You are correct. We currently reference https-URI in RFC 7230= , but the > definition in 7230 does not place quotes around it. > =20 > The same applies to scope and error. > =20 > So, we need to fix: > =20 > OLD: > =20 > authz-server =3D "authz_server" EQUAL authz-server-value > =20 > scope =3D > error =3D > =20 > NEW: > =20 > authz-server =3D "authz_server" EQUAL DQUOTE authz-server-valu= e DQUOTE > =20 > scope-cln =3D DQUOTE scope DQUOTE > scope =3D > error-cln =3D DQUPTE error DQUOTE > error =3D > =20 > =20 > (I noted that that Benjamin has some comments regarding the refer= enced > RFCs for the parameter values, but I will address that in the reply t= o his > review.) > =20 > =20 > ----- > =20 > > 2. In addition should not the "authz_server" be registered = in the > >=20 > https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#= sip-parameters-12 > > registry? > =20 > I guess so. And, then I guess we also need to register "scope= " and > "error". > =20 > -------------------------------------------------------------= --------- > COMMENT: > -------------------------------------------------------------= --------- > =20 > > An additional thing. > > > > Is SIP directly using the HTTP Authentication Schemes IANA = registry > > ( > https://www.iana.org/assignments/http-authschemes/http-authschemes.xh= tml#authschemes > ) > > or does it have its own tucked away somewhere? And if it is= the > former, should > > its references for the "bearer" add this RFC as a reference= ? > =20 > SIP uses the HTTP registry. > =20 > (The SIP registry does register a "digest" value, but that is = for the > Security-XXX headers defined in RFC 3329) > =20 > Regards, > =20 > Christer =20 > =20 > =20 > =20 > =20 >=20 --=20 Cheers =20 Magnus Westerlund=20 =20 =20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- =20 =20 --B_3670919514_1073972943 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIINwYJKoZIhvcNAQcCoIIIKDCCCCQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggYKMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zGCAfEwggHtAgEBMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYzAhA3hiKmRy4CvX9kpuzD7V4xMA0GCWCGSAFlAwQCAQUAoGkw LwYJKoZIhvcNAQkEMSIEIKQ1pN8R9onmGgDtIyNZtttwwNrAtk9FL5Mk+gV6HOOqMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyODA4NTE1NFowDQYJ KoZIhvcNAQEBBQAEggEAP3361g5coDpfuLZtITv9Ogokl51H0TiZQP81TjxSrSAe6xCr7DYP sKxuuFqTrCRWEJvA8vQSZFhOqt/sBybu6UIats4u+3BAZNzZSd2XoydVRPJ/hUta1j75hiUl BZ3Bixyqak69g0tHN78pi4Q/F59y3SBYJqMsElmFqOxln76tIWURbR4A8LPZcCcKUW0RHmnD wVe/+hiS8IUOHS9N0wA0uYewaDhQuX9n6L8SY6d1N/bG9Ykm11oRQA7DeMIqD+qczzfd/d96 ++PeLOWRDgI7zQhFvsviPZAmv+6CeyH8TRvm3HKyQUmLOIqSMHyhesEQutfNtphAJ5C0R1ht DQ== --B_3670919514_1073972943-- From nobody Tue Apr 28 01:56:39 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DE93A1157; Tue, 28 Apr 2020 01:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 BBUkHv5buB1g; Tue, 28 Apr 2020 01:56:25 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130082.outbound.protection.outlook.com [40.107.13.82]) (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 2B25E3A113F; Tue, 28 Apr 2020 01:56:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=imhBVZ+/u7odSLcQwKwn91SPRfEzyEvooIXdwIofXNyNuqQhFRmfCPfgbITGe0tT6HMnbmGwUxt8BOdWNyfMYMBZbXkEevOE6TzK6Mgpw6+G0OteCz/P6IWJO03XCQgFK3ZFn1VHz0QEC7gveDuKojtlrAR2M+I0IfJs8PjUc0XfykEeFkC3kc2esY2z9IyyTsodRBNYsPrDlgUilJALPMfkwptRZlXUuKAx3nE+lNHsuKieBLVQ7AlcFbPCcwTgw+cgMvGgV/ytN2pGW4PZa12WpaTwJpqVNSH589obm6x5ClayB0/lBSVsPQCv3XqZe6cgm6lEAqsejhjNfXhmqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J8Nq4zS/EzRA6Ue/RM/JrAu2FdIaNCJqS2iDq2r1vTE=; b=lMQLTD9eY/pGl6H49TkxJnxvzvTKAeVJ0Auc+RUQU1K5TfkI40+OcL+QJB02NoyQuuNQTlML3oQzgubmVCa7fl0Z2J9wkUBWfAgWtYzvZsZ85fhy4YmrISHdAIjAD7mljxiBQ44MP6YMaT2R1U9CVHVZ5V5gDEMi+EuCrroJcK1dRaYwYV5zfntbE2rQesM9fgllu/hzTzpqXy2KP5LwS8vhZZ20qlH96DVAoG6fSO559Y8L9BXJ5WZjmO66u8WtHgP7KUlhltiPxICnUEgU2xzpe7g+sPoHJX032uELTcD/vwioEbIfNiBPHp2D3f12IP1MMJKyAKeHXv7lorT8Jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J8Nq4zS/EzRA6Ue/RM/JrAu2FdIaNCJqS2iDq2r1vTE=; b=Or5MKyZb1DZoXk0P66cd8lmeZx/Nn9Rgnu0JNlqIEDG4CTEIOHD1KmT46Uyy9eqRKbgla70s59AXPDxMXwrPOuiV3fk9+zAIpgv4tnxIPJ1zs0xkQ/u+kFo4/F1FLZNE9bqWUbVS1+ExrMikF97dmI0C85v074Jx9XZ6scQDhmw= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3801.eurprd07.prod.outlook.com (2603:10a6:7:80::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.10; Tue, 28 Apr 2020 08:56:21 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 08:56:21 +0000 From: Magnus Westerlund To: Christer Holmberg , "iesg@ietf.org" , "pkyzivat@alum.mit.edu" CC: "sipcore-chairs@ietf.org" , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request Thread-Index: AQHWHM0jGFXph8PsA0+ASqfFfMQaaaiON3WAgAA1wwD//88CgA== Date: Tue, 28 Apr 2020 08:56:21 +0000 Message-ID: <895b6f134965ed502a24591ae86a5943bb683781.camel@ericsson.com> References: <6BA45301-2E1D-4050-9C13-6B8BA7094B79@ericsson.com> <07CBCA10-4499-4FD1-A75C-97440906432F@ericsson.com> In-Reply-To: <07CBCA10-4499-4FD1-A75C-97440906432F@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [98.128.243.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b342ab20-14b3-422d-4ef3-08d7eb5205ee x-ms-traffictypediagnostic: HE1PR0702MB3801:|HE1PR0702MB3801: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(366004)(396003)(136003)(376002)(54906003)(316002)(110136005)(5660300002)(2906002)(2616005)(186003)(44832011)(99936003)(76116006)(71200400001)(66446008)(66556008)(4326008)(66476007)(66946007)(64756008)(66616009)(6512007)(6486002)(478600001)(966005)(8676002)(86362001)(8936002)(36756003)(81156014)(26005)(6506007)(99106002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1bPHWVAF04dZmj2QPaHIuvapHNckPDFzwBK07w5eS0KcFigt0HTmznfg1mvf3Xc/7dkYq/wHjn1mmtAFytMyl8YU7ZwQ7QbZAe2cBoigXVEV/S+uZmQChSJMgb60ZYHwDrkL+EeCqp33cMVAG4HDIddrkScBCTDNA2E1Okdbys1V5gTlayX1w0NRu8U78Bsi7131xe0IOJPHAc84MhvDSfsmNQBhsd6HEqRqNFAdaEDs2yJZhiAqsaGmYuMWA7bR8s2OSlin0DafSPy30Y2Cemf77lQVhV9bNZdm21arOJ03bWZLZO9ZQx1fEKS1+6AQ4QpLC+n4lUeetk3C/VSOE/H+5mfdMPzF3RxPniEXtyEqNe08b3odjlpGxQMbsqHOMrxyn7IngG/hJBf4q5A9yqd15bAhW/vJbFsz6co59+1yWQ/OkMDj1QVOV/6MErVQg9DDS3YA0ho2RwGLvuxW2KS5KTMyCzjlI6oelXIhS2TF9CbMKl13E1g8dWes3Dbl4ZPDu/605np+hC0HBxtTYw9/EwHy0ZlKRlZA6aOJUPVTvh2LBvPEZnD2tgj8aVLCt/eD/H5tVsz7UYxSMm7rhA== x-ms-exchange-antispam-messagedata: uGlmlj/tZI2gE6W1KfxXGy9F31831lGaI623ORGZhROx690gMsv6yr9+HlUNfYPGTAghsr9wBpBGcVw6faRRDjB2aLPeuFD+pFh4/RlnOKncfhk4mQaAiKWeZSNZJCbNiXVcUPDcEOVDYO+pHaDp41e3k/TazUWyNbjcw/lVmetTm/IYcQOaiOnrqnzfTK3ZSPRV7pnIQVXs92AQUCrPKg9n5Wj/VQUaFLbQh6eXo3K4HZIJXa03zMN9aZws3JDL+2eBpQtlJQX1fcp8DBuv0tj97uYGbzeZI3QLV/bokd6Bo1CxWfHeYdAHLujj352icqNcVSnBiBSpGrcSgxW7jdW3kXFXhkAdpAOedhvRLtlZNohAfWh3Q0NnJYBHzt14QFTAvEqCgSnXwpOtsRMkSBvpdEP5G+63jR+lx8RWn/Et2t/piX+5x6RLENqF2Ua3dOL7evpLKw8LnSTW3EROCh5HhkDSqALTMzTo4nqBqHVhs+khMxwAvZ8wipjU+9s3ubFGHzRnzFzyuxB7Ccq5zDa6KVJyud4NtJR0E35uzpbvj4P7hee0j2yEr6Ag+xaYyXU4buEvjSP3m6W53mSKLvcpBdd4t9YC1n7kmhiTLIPjR6/XakAgdYU351QkoOjPaI2CRgTuAfgWcqo49KfVxndSCd/Ub/u0jrEO0sbf6FQzZZxKCg5cjS1+c2dN615iPtnMjTbdhV/5CJWnW8iFiikTNn4rZc7kXlVZElKGPoI9/1iWG3qPhBrxBz9I660WhTLY3qmW4ZCbvZNyiOeu9tg/AOyGnNA6Fs41CwBnvk4= Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-OU+eDmiMaoRGTvsO9TdC" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b342ab20-14b3-422d-4ef3-08d7eb5205ee X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 08:56:21.4224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yFiR6AD4ESDeM/zZGJlrXxUrD877/Fb+tsqGFlF7q7aYrs6ypy/vO8QskqQ2bQirVplPZNMnKa02lI9PmsLq2udxEHLfjiKGEHUOhSz9tcw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3801 Archived-At: Subject: Re: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:56:36 -0000 --=-OU+eDmiMaoRGTvsO9TdC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think this addresses all my issues. I will clear with the assumption that= a new version will be submitted before the AD approves the publication. Cheers Magnus On Tue, 2020-04-28 at 08:51 +0000, Christer Holmberg wrote: > Hi Magnus, >=20 > > I think keeping _ in authz is okay to do, and allowed by the syntax.= So > > if the > > WG want to correct this to have it align with the norm or leave it a= s it > > is is > > up to the WG.=20 > > =20 > > However, the changes did may wonder one thing about the the inclusio= n of > > scope > > and error. The ABNF constructs defined in RFC 6749 are only includin= g the > > value > > part. So to my understanding they really should have an parameter-na= me =3D > > value > > construct defined. Like this.=20 > > =20 > > scope-param =3D "scope" EQUAL DQUOTE scope DQUTE > > scope =3D > > error- > > param =3D "error" EQUAL DQUOTE error DQUOTE > > error =3D >=20 > =20 > You are right. Good catch! :) > =20 > > The IANA section looks good.=20 >=20 > =20 > Good :) >=20 > Fixed in this commit:=20 > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7= /commits/fb8a94084c5ef3490f3e6c2ba2f00550d79fbb2b >=20 > Regards, >=20 > Christer >=20 > =20 > =20 > On Mon, 2020-04-27 at 19:50 +0000, Christer Holmberg wrote: > > Hi, > >=20 > > The following pull request commits contains the syntax and IANA cha= nges > based > > on Magnus DISCUSS: > >=20 > >=20 > =20 > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7= /commits/168086b4f1220620d063af07a3292b667e30ef37 > > (Syntax) > >=20 > =20 > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7= /commits/22f810025d1bf8df45875e92e4d4c11d0f574693 > > (IANA Considerations) > >=20 > > Please note the parameter name "authz_server". Following the naming > style of > > other header field parameters it should perhaps be "authz-server". > However, > > for backward compatibility I would prefer to not change it at this > point. > >=20 > > Paul, I would appreciate if you could also take a look at these. Th= anks! > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > =EF=BB=BFOn 23/04/2020, 22.51, "Christer Holmberg" < > christer.holmberg@ericsson.com> > > wrote: > >=20 > > Hi Magnus, > > =20 > > Thank You for the review! Please see inline. > > =20 > > -----------------------------------------------------------= --- > -------- > > DISCUSS: > > -----------------------------------------------------------= --- > -------- > > =20 > > > I think these resolution for this is rather straight forw= ard, > > however the > > > implications of one is going to break deployed > implementations. > > > > > > 1. Section 4: > > > > > > This is rather straight forward to resolve but you do hav= e a > SIP > > syntax > > > violation in these rules. > > > > > > challenge =3D/ ("Bearer" LWS bearer-cln *(COMMA b= earer- > cln)) > > > bearer-cln =3D realm / scope / authz-server / error= / > auth-param > > > authz-server =3D "authz_server" EQUAL authz-server-= value > > > authz-server-value =3D https-URI > > > realm =3D > > > auth-param =3D > > > scope =3D > > > error =3D > > > https-URI =3D > > > > > > So RFC 3261 defines the Challenge construct as: > > > > > > challenge =3D ("Digest" LWS digest-cln *(COMMA > digest- > > cln)) / other-challenge > > > > > > Where this extension needs to match the syntax of the oth= er- > > challenge: > > > > > > other-challenge =3D auth-scheme LWS auth-param *(CO= MMA > auth- > > param) > > > > > > Where we need to look at: > > > auth-param =3D auth-param-name EQUAL ( token / q= uoted- > string > > ) > > > > > > Please note what is included in the "token" rule. > > > token =3D 1*(alphanum / "-" / "." / "!" / "%"= / "*" > > > / "_" / "+" / "`" / "'" / "~" ) > > > > > > the allowed syntax for https-URI in RFC 7230 is: > > > > > > https-URI =3D "https:" "//" authority path-abempty [ "= ?" > query ] [ > > "#" fragment ] > > > > > > Which include both "/", "?" and "#" that are not allowed = in > token. > > Thus, the > > > URI included in the authz-server-value MUST be converted= into > a > > quoted-string > > > matching syntax rule. > > =20 > > You are correct. We currently reference https-URI in RFC 72= 30, > but the > > definition in 7230 does not place quotes around it. > > =20 > > The same applies to scope and error. > > =20 > > So, we need to fix: > > =20 > > OLD: > > =20 > > authz-server =3D "authz_server" EQUAL authz-server-value > > =20 > > scope =3D > > error =3D > > =20 > > NEW: > > =20 > > authz-server =3D "authz_server" EQUAL DQUOTE authz-server-= value > DQUOTE > > =20 > > scope-cln =3D DQUOTE scope DQUOTE > > scope =3D > > error-cln =3D DQUPTE error DQUOTE > > error =3D > > =20 > > =20 > > (I noted that that Benjamin has some comments regarding the > referenced > > RFCs for the parameter values, but I will address that in the reply= to > his > > review.) > > =20 > > =20 > > ----- > > =20 > > > 2. In addition should not the "authz_server" be registere= d in > the > > >=20 > >=20 > https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-= parameters-12 > > > registry? > > =20 > > I guess so. And, then I guess we also need to register "sco= pe" > and > > "error". > > =20 > > -----------------------------------------------------------= --- > -------- > > COMMENT: > > -----------------------------------------------------------= --- > -------- > > =20 > > > An additional thing. > > > > > > Is SIP directly using the HTTP Authentication Schemes IAN= A > registry > > > ( > >=20 > https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#= authschemes > > ) > > > or does it have its own tucked away somewhere? And if it = is > the > > former, should > > > its references for the "bearer" add this RFC as a referen= ce? > > =20 > > SIP uses the HTTP registry. > > =20 > > (The SIP registry does register a "digest" value, but that i= s for > the > > Security-XXX headers defined in RFC 3329) > > =20 > > Regards, > > =20 > > Christer =20 > > =20 > > =20 > > =20 > > =20 > >=20 > --=20 > Cheers > =20 > Magnus Westerlund=20 > =20 > =20 > ---------------------------------------------------------------------= - > Networks, Ericsson Research > ---------------------------------------------------------------------= - > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------= - > =20 > =20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-OU+eDmiMaoRGTvsO9TdC Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyODA4NTYzM1owLwYJKoZIhvcN AQkEMSIEIARUMNayZkroPLOW52bhKwlIGUQNPRTuUeT7bG1iTcRCMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAHSgpCodSK259 v8XfSaxCE6jzdYmDcxb5P1skRg6Q6SYRNmIIF1gdJrgWJpW3UC8/NJge0MLboA3/XNzQVadZFuxe 9F3HIoiXIFyPUlMWsxLbo6x4fKPaPSVcXdU58gY6iAPwWyI9FykhCJs8a+zhGVOETGkyhOZQyfDI j9kmTQMDNoLLDDUdFczDHpqKIRqlwR7LWK17B2XKxRQC9TrbPmVAkxt4vsD2WV9a5ZeIaT/CXNJk k3oIGtNTgCPNhUAmDzmCwX8Cpn/3cFSgUlm2T0bcX+h+jKl6Ja9Eiv+ca6qFRobQmnVHEcDPWM8g QXpKzTeNHPXY9Gdxy6GS2F81gQAAAAAAAA== --=-OU+eDmiMaoRGTvsO9TdC-- From nobody Tue Apr 28 02:01:49 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584593A1133; Tue, 28 Apr 2020 02:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Y9kZoTDS96LY; Tue, 28 Apr 2020 02:01:38 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30083.outbound.protection.outlook.com [40.107.3.83]) (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 136233A112F; Tue, 28 Apr 2020 02:01:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V/Z2hLot1maBLV0jjvR1LNW1XWGycgtlBi8ZNYl7otf63LhA0TGe40EMGVAdgxGxP2cd1TUjybO7oHCvhxTHiimf+PIG1wl/j3s7RsVKDNq1muLe1nR29+3VKPetu/GV/VnK4sSYCqwLz6g+WF9ziu6OGvIgARnTzcBnFBASeBBinG4Fr21sAOya250tRhp9Qubri92gjZ+ncT/bgaXrZyZpWNZs7+1zdoSCAa9+cRFelJkHWavnI0B6UNfgsnJDCs+pGiEgk7LizVzczZA63nNAReC/pHzMqf1qJo6zJGUYFg5gzf+11yUG+lG60YGihksKg5FVMyWEyG7ZnW8i5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S/umAOX5hjlENMXFIu6OKpFa1nyWZEEwrIVtUCgAdkA=; b=JzMaSEEIymTxeB9coop6ikaFk3HIT3uo2tqDlbnQQO/TLN9JQ9fcwWLOfAarfnScZLOgF9BytIt9la7LvYHhbDXWFeewhGV225zZ1mxEaPv/OLNHLJ8dXvkwYCAbarcYC5LGe+WYd/evNTtdRYP7AlNGndtCHbwBULaZx0srsuHXBI2xp3oBpA2eO7+QmonVYZV+LSmO/xaDXqmLu6wbnF53gQG/f4HjaCUgAmIvpVZxzqWYs+y60TQtpsUg4m62HBGwdhqCwsmF7a0yeAktHQQRsVxjezMteFR8AOolkSl+sdR2n410ubf3zD4ZsjvfeMXucU8G1cKYqWfSwZIXOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S/umAOX5hjlENMXFIu6OKpFa1nyWZEEwrIVtUCgAdkA=; b=RwPL4RtAbhQwSxclvPS5bKWm6iYl3/8+llaTr35FD05Gp4HJyRkxJad+rdH84kJiKJD9GhjY8ZnRY+WRoNHn/de2PFH331PaEbRbzViXuWUfGM1zc062NevAFEGUH6aqKS0M/8JywkkWMupOOmZDkUEXl7COHoM5iOnZQ5k3HxU= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6216.eurprd07.prod.outlook.com (2603:10a6:20b:132::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Tue, 28 Apr 2020 09:01:35 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.014; Tue, 28 Apr 2020 09:01:35 +0000 From: Christer Holmberg To: Magnus Westerlund , "iesg@ietf.org" , "pkyzivat@alum.mit.edu" CC: "sipcore-chairs@ietf.org" , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "mahoney@nostrum.com" , "sipcore@ietf.org" Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request Thread-Index: AQHWHM0jGFXph8PsA0+ASqfFfMQaaaiON3WAgAA1wwD//88CgIAAM7EA Date: Tue, 28 Apr 2020 09:01:35 +0000 Message-ID: References: <6BA45301-2E1D-4050-9C13-6B8BA7094B79@ericsson.com> <07CBCA10-4499-4FD1-A75C-97440906432F@ericsson.com> <895b6f134965ed502a24591ae86a5943bb683781.camel@ericsson.com> In-Reply-To: <895b6f134965ed502a24591ae86a5943bb683781.camel@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [178.55.150.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e5f03f0-9160-443c-79b6-08d7eb52c122 x-ms-traffictypediagnostic: AM7PR07MB6216:|AM7PR07MB6216: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(86362001)(2906002)(66946007)(54906003)(4326008)(33656002)(66476007)(64756008)(316002)(66556008)(66446008)(76116006)(6506007)(6512007)(36756003)(66616009)(110136005)(71200400001)(478600001)(6486002)(8676002)(26005)(5660300002)(2616005)(8936002)(99936003)(186003)(966005)(44832011)(81156014)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /Y1R8TEPCfR12Gc1OYzH0N8kLKmAp6LR2i09zBl4YGGhY+u3cxlFURznr5AM/v8zQ1pKcXrXYaYKQ3dQGdMHD7jbKGK/LqOHBCxkpvUIUN5qx2VTjVYcjCHu45mJMIMherbRtEegNe/4x0QfPKH9recFFrbIReAcZkLB5lZ+M21DXE/ea7eqqBsxPCsoKiYNHP8GgRssNG/34Z28Meiq2GTTBACW1sbxbfauj2Uj4Da0kVaTJpnwUN0dRc+LK4IjHtjMqGR+dSgdgKiJffiCV6DpLLhmn5JGtR5+uafYbYron16mS9txVZiPzG+Kuolx/tP36WPDWxkB/pSO0U+HG5hdJ7J5YBxBgtEcQsSoz/WO60fQuzHcEnDxUh537Muhi0uE6iaYJR1zIZ5dYLOmQc04SlGs/SzSkvbfAAOyBkNDN1y7uQ/xCqr5pGndBP+Wn1uv7TPrh5ByF10mIyGG92AJq2oRXWZNmoJOu/nflwJK1fgBGdpBAI+eTOBC48k90NwrWVz7AqM55adRkSMAQ3ftPC58nGrA8tEFT674jCU48ta404w9oxE2Pf2c8MlF x-ms-exchange-antispam-messagedata: STtKTB7uKHtAW7yUKpstMZ7mCYFqfRdGCDjlr3IdA4StFzvawpueYBvMDJRiGDkih1qxJgAgiJyjZJ/E5xrFxdRr+Pv6gXqWAlElHW5OvAyj//74F816s6DeliY6C/3w+fp3i4zqT6/7SdOxqWGtUtFuwVSXJuoqJLXxH2HTmjyLg95jb4qnoRHysJMJHksspViRhcjyECHxWgKVWWkU0T6z4aFWn5X4inATX7sjdOnNS1QR+YoaHPK2ESvq9Jo0aGztUMRWXfE85yFmTP7g6bMojhY67KWOz96vFwf5NtDA36FoCyPoCMZqs/BK3GMiSz+q1aI1gcmiKxp/pG1G727fXN2t3yUKAP1wGUFlo61tjDNWcz/DWlSqQZt6fA+knjGstGnVeU3Qh6I3tBtVIEdM/m5ntaEtB+DgcfOOtItZTjkX8oDTkCXdoCwx7zTf74cx0O8MJolZCsFcPRhdsfwMfgvGZo61L9Y9JeXORplEaU5COEFz9+ULaB5K5Jzcv4UdBSzfqMBkX04jrH62t9A2Y314V+948VOcHZchfBYAVJyfuWGb41kHmAr/TAOunzb9HkfY1KwJfM/9H/PkkXhFLZNDRo9P3tkigJg9qUpq0lG+n+5swAN5gLAOPqnJSgcX/ojzLWVy5cEsE+1f95ZCvWlBvTNzbuOn7Ea4zDEfw36hU7wiey7nx/3d8c+dquGFv5lz35zscFkBx8ZmrcWonbjx8OxynKhA5B5/sQjREtxr2bcSs70/8xXV+9nEPdMIoAJ8xdh7U5Sd4gwvZKymbauakszaspCOCa/FVXo= Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3670920094_1656577228" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e5f03f0-9160-443c-79b6-08d7eb52c122 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 09:01:35.5615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aIGpEW4tAQOoQcjssn9zQ9F4qcZfzkNQqMMdyHgK3TvnqubAPybJ1JOi+zrInASHyc1nZ0bG3XB/TzcxAxpgYfJVreWCr3eevZQGPK+tRFE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6216 Archived-At: Subject: Re: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 09:01:43 -0000 --B_3670920094_1656577228 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, There will be quite a bit of changes based on the IESG reviews, so there wi= ll definitely be a new version that people can look at before we move the dr= aft forward. Regards. Christer =EF=BB=BFOn 28/04/2020, 11.56, "Magnus Westerlund" wrote: Hi, =20 I think this addresses all my issues. I will clear with the assumption = that a new version will be submitted before the AD approves the publication. =20 Cheers =20 Magnus =20 On Tue, 2020-04-28 at 08:51 +0000, Christer Holmberg wrote: > Hi Magnus, >=20 > > I think keeping _ in authz is okay to do, and allowed by the syn= tax. So > > if the > > WG want to correct this to have it align with the norm or leave = it as it > > is is > > up to the WG.=20 > > =20 > > However, the changes did may wonder one thing about the the incl= usion of > > scope > > and error. The ABNF constructs defined in RFC 6749 are only incl= uding the > > value > > part. So to my understanding they really should have an paramete= r-name =3D > > value > > construct defined. Like this.=20 > > =20 > > scope-param =3D "scope" EQUAL DQUOTE scope DQUTE > > scope =3D > > error- > > param =3D "error" EQUAL DQUOTE error DQUOTE > > error =3D >=20 > =20 > You are right. Good catch! :) > =20 > > The IANA section looks good.=20 >=20 > =20 > Good :) >=20 > Fixed in this commit:=20 > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pu= ll/7/commits/fb8a94084c5ef3490f3e6c2ba2f00550d79fbb2b >=20 > Regards, >=20 > Christer >=20 > =20 > =20 > On Mon, 2020-04-27 at 19:50 +0000, Christer Holmberg wrote: > > Hi, > >=20 > > The following pull request commits contains the syntax and IANA= changes > based > > on Magnus DISCUSS: > >=20 > >=20 > =20 > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pu= ll/7/commits/168086b4f1220620d063af07a3292b667e30ef37 > > (Syntax) > >=20 > =20 > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pu= ll/7/commits/22f810025d1bf8df45875e92e4d4c11d0f574693 > > (IANA Considerations) > >=20 > > Please note the parameter name "authz_server". Following the na= ming > style of > > other header field parameters it should perhaps be "authz-serve= r". > However, > > for backward compatibility I would prefer to not change it at t= his > point. > >=20 > > Paul, I would appreciate if you could also take a look at these= . Thanks! > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > =EF=BB=BFOn 23/04/2020, 22.51, "Christer Holmberg" < > christer.holmberg@ericsson.com> > > wrote: > >=20 > > Hi Magnus, > > =20 > > Thank You for the review! Please see inline. > > =20 > > -------------------------------------------------------= ------- > -------- > > DISCUSS: > > -------------------------------------------------------= ------- > -------- > > =20 > > > I think these resolution for this is rather straight = forward, > > however the > > > implications of one is going to break deployed > implementations. > > > > > > 1. Section 4: > > > > > > This is rather straight forward to resolve but you do= have a > SIP > > syntax > > > violation in these rules. > > > > > > challenge =3D/ ("Bearer" LWS bearer-cln *(COMMA= bearer- > cln)) > > > bearer-cln =3D realm / scope / authz-server / err= or / > auth-param > > > authz-server =3D "authz_server" EQUAL authz-serve= r-value > > > authz-server-value =3D https-URI > > > realm =3D > > > auth-param =3D > > > scope =3D > > > error =3D > > > https-URI =3D > > > > > > So RFC 3261 defines the Challenge construct as: > > > > > > challenge =3D ("Digest" LWS digest-cln *(COM= MA > digest- > > cln)) / other-challenge > > > > > > Where this extension needs to match the syntax of the= other- > > challenge: > > > > > > other-challenge =3D auth-scheme LWS auth-param *(= COMMA > auth- > > param) > > > > > > Where we need to look at: > > > auth-param =3D auth-param-name EQUAL ( token /= quoted- > string > > ) > > > > > > Please note what is included in the "token" rule. > > > token =3D 1*(alphanum / "-" / "." / "!" / "= %" / "*" > > > / "_" / "+" / "`" / "'" / "~" ) > > > > > > the allowed syntax for https-URI in RFC 7230 is: > > > > > > https-URI =3D "https:" "//" authority path-abempty [= "?" > query ] [ > > "#" fragment ] > > > > > > Which include both "/", "?" and "#" that are not allo= wed in > token. > > Thus, the > > > URI included in the authz-server-value MUST be conve= rted into > a > > quoted-string > > > matching syntax rule. > > =20 > > You are correct. We currently reference https-URI in RF= C 7230, > but the > > definition in 7230 does not place quotes around it. > > =20 > > The same applies to scope and error. > > =20 > > So, we need to fix: > > =20 > > OLD: > > =20 > > authz-server =3D "authz_server" EQUAL authz-server-value > > =20 > > scope =3D > > error =3D > > =20 > > NEW: > > =20 > > authz-server =3D "authz_server" EQUAL DQUOTE authz-serve= r-value > DQUOTE > > =20 > > scope-cln =3D DQUOTE scope DQUOTE > > scope =3D > > error-cln =3D DQUPTE error DQUOTE > > error =3D > > =20 > > =20 > > (I noted that that Benjamin has some comments regarding the > referenced > > RFCs for the parameter values, but I will address that in the r= eply to > his > > review.) > > =20 > > =20 > > ----- > > =20 > > > 2. In addition should not the "authz_server" be regis= tered in > the > > >=20 > >=20 > https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#= sip-parameters-12 > > > registry? > > =20 > > I guess so. And, then I guess we also need to register = "scope" > and > > "error". > > =20 > > -------------------------------------------------------= ------- > -------- > > COMMENT: > > -------------------------------------------------------= ------- > -------- > > =20 > > > An additional thing. > > > > > > Is SIP directly using the HTTP Authentication Schemes= IANA > registry > > > ( > >=20 > https://www.iana.org/assignments/http-authschemes/http-authschemes.xh= tml#authschemes > > ) > > > or does it have its own tucked away somewhere? And if= it is > the > > former, should > > > its references for the "bearer" add this RFC as a ref= erence? > > =20 > > SIP uses the HTTP registry. > > =20 > > (The SIP registry does register a "digest" value, but th= at is for > the > > Security-XXX headers defined in RFC 3329) > > =20 > > Regards, > > =20 > > Christer =20 > > =20 > > =20 > > =20 > > =20 > >=20 > --=20 > Cheers > =20 > Magnus Westerlund=20 > =20 > =20 > -----------------------------------------------------------------= ----- > Networks, Ericsson Research > -----------------------------------------------------------------= ----- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.= com > -----------------------------------------------------------------= ----- > =20 > =20 --=20 Cheers =20 Magnus Westerlund=20 =20 =20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- =20 =20 =20 --B_3670920094_1656577228 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIINwYJKoZIhvcNAQcCoIIIKDCCCCQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggYKMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zGCAfEwggHtAgEBMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYzAhA3hiKmRy4CvX9kpuzD7V4xMA0GCWCGSAFlAwQCAQUAoGkw LwYJKoZIhvcNAQkEMSIEIHftlmv/1usc8VS3Q9T/JrkUxgRmvS45fBHNAioUGSszMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyODA5MDEzNFowDQYJ KoZIhvcNAQEBBQAEggEAp0t5744ZVZA74MJC1KNtpZS2ia05wrv7i1iT2nzu2NbgCLcra1V1 mA6nhU+tL/WhjSSUEsy3Jp2lrc/o2A7AKMS1Y7htTeYkRd1U9Si1TidoMa/PIM/tqVvpPj+q LJ6Gk6HjlVJvXNHYOdAgAd4WlQB06e3uGHCafbbx/Z7igPAC/dA4XZ15sCrFRGVR+WvFNMJT hWx1lE7KkZsH4UDkjNH3LxDW+H+FEnCMdCdGaZ2t9MGChuJbI+a2xaAIL5WcU0dy4qjURTFs bRngXWYfuy7rjiE6WZJjVbMoRQJvgLjrG3F4Go/9EMkhLcSXEoWLulLIqzCVV2KGtkxT3JCe Vw== --B_3670920094_1656577228-- From nobody Tue Apr 28 02:04:23 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB713A1132 for ; Tue, 28 Apr 2020 02:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 T3R7mSOmy3vS for ; Tue, 28 Apr 2020 02:04:20 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 0BEF83A113F for ; Tue, 28 Apr 2020 02:04:19 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 6E22C18F0; Tue, 28 Apr 2020 11:04:16 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <70DB41C8-8D03-4DA9-A849-0F920E3FB1B2@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_924A075B-35AC-4320-BED4-C88CA50DF4D5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 28 Apr 2020 11:04:16 +0200 In-Reply-To: <0748D8A5-9BD8-44D5-ABEC-4603B9AD017C@ericsson.com> Cc: Olle E Johansson , "sipcore@ietf.org" To: Christer Holmberg References: <8B16E9FE-BA10-4367-B271-F318E69AEBA0@edvina.net> <0D6C66F0-CF13-492B-9640-0364FEA1E638@ericsson.com> <27A856B3-8204-414B-AFE3-67D63E6D05FF@edvina.net> <0748D8A5-9BD8-44D5-ABEC-4603B9AD017C@ericsson.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] Update for 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 09:04:22 -0000 --Apple-Mail=_924A075B-35AC-4320-BED4-C88CA50DF4D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 28 Apr 2020, at 10:39, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>> I discovered that = https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html = aim to update 3261 and a lot of other RFCs. >>>>>>=20 >>>>>> This means that SIP-compliant implementations will have to = deprecate TLS 1.0, 1.1 and earlier versions. >>>>>=20 >>>>> This has been discussed on an IETF level before, and I don't think = what you say is true.=20 >>>>>=20 >>>>> Just because RFC YYYY updates RFC XXXX, it doesn't mean that = implementations of RFC XXXX will suddenly become non-compliant >>>>> unless it implement RFC YYYY. Such implementations are still = compliant to RFC XXXX.=20 >>>>>=20 >>>>> Implementations that are also compliant to RFC YYYY need to = explicitly indicate so: "Application Z is compliant to RFC XXXX and RFC = YYYY.=E2=80=9D >>>>=20 >>>> That=E2=80=99s interesting. Thanks for the feedback. So what=E2=80=99= s the point of =E2=80=9CUpdating an RFC=E2=80=9D and the references? >>>=20 >>> The reason you update specs is normally because you improve aspects = of the protocol, whether it's the protocol itself, the >>> security mechanisms it uses etc. Often it makes sense to implement = the updates, but not doing so does not mean that you suddenly become = non-compliant. >>=20 >> So in order to really upgrade SIP we need to write a replacement that = makes 3261 obsolete?=20 >=20 > You can start writing a 3261bis draft, that would eventually = obsolete 3261. But, that would still not make 3261-compliant = implementations non-compliant. Sure, they would be compliant to an = obsoleted specification, but they would still be compliant :) >=20 > =20 I agree that it=E2=80=99s actually more unclear than I thought. Check https://tools.ietf.org/id/draft-kuehlewind-update-tag-02.txt = for a = discussion and a proposal to fix the =E2=80=9Cupdated by=E2=80=9D meta = data tags. I don=E2=80=99t know where that=E2=80=99s going, but it documents the confusion. /O= --Apple-Mail=_924A075B-35AC-4320-BED4-C88CA50DF4D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 28 Apr 2020, at 10:39, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
I discovered that https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-= 02.html aim to update 3261 and a lot of other RFCs.

This means that SIP-compliant implementations will have to = deprecate TLS 1.0, 1.1 and earlier versions.

This has been discussed on an = IETF level before, and I don't think what you say is true.

Just because RFC YYYY updates RFC XXXX, it = doesn't mean that implementations of RFC XXXX will suddenly become = non-compliant
unless it implement RFC YYYY. Such = implementations are still compliant to RFC XXXX.

Implementations that are also compliant to RFC YYYY need to = explicitly indicate so: "Application Z is compliant to RFC XXXX and RFC = YYYY.=E2=80=9D

 That=E2=80= =99s interesting. Thanks for the feedback. So what=E2=80=99s the point = of =E2=80=9CUpdating an RFC=E2=80=9D and the references?

The reason you update specs is = normally because you improve aspects of the protocol, whether it's the = protocol itself, the
security mechanisms it uses etc. = Often it makes sense to implement the updates, but not doing so does not = mean that you suddenly become non-compliant.

So in order to really upgrade SIP = we need to write a replacement that makes 3261 obsolete?

  You can start = writing a 3261bis draft, that would eventually obsolete 3261. But, that = would still not make 3261-compliant implementations non-compliant. Sure, = they would be compliant to an obsoleted    specification, = but they would still be compliant :)

  =  
I agree that it=E2=80=99s actually more = unclear than I thought.


= --Apple-Mail=_924A075B-35AC-4320-BED4-C88CA50DF4D5-- From nobody Thu Apr 30 05:03:47 2020 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEE23A005B; Thu, 30 Apr 2020 05:03:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <158824822383.13018.2051250519535561523@ietfa.amsl.com> Date: Thu, 30 Apr 2020 05:03:43 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-14.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 12:03:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-14.txt Pages : 17 Date : 2020-04-30 Abstract: This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-14 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-14 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 Apr 30 05:09:12 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C61C3A00E0; Thu, 30 Apr 2020 05:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gZeEF1wznCxu; Thu, 30 Apr 2020 05:08:56 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00079.outbound.protection.outlook.com [40.107.0.79]) (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 BABDC3A00D3; Thu, 30 Apr 2020 05:08:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CH6F/Eiifq/6MP1fsy2/EMKdfFUAqEjwZzrUH55WuzZkKLKD4CukITZDazLeo1/RlFGOUrc7jN86JvnYXhBvvd9dDPj64sxbF1yyyPrSyM4RkpH0/hTFZog88y+mS2eY85tZfhjE19oR5C1psk3fqNDg6DL9GUu6x7++g9Cxvu4HfGVZb/Y3OybFm+CHzx+jjPcHGGA7ppDn3ODpZjErYoKPAF41kQHg3/AkPK5YmzhH3KcvaqwC9eoaAMy1Rq3FOq8YZYm2B7WMGBaKgxdvPhuDt0SqSwirfoR0i29ljPTw/8gMkFYb8DRl0TI99ZFCKwoWEDxXncMb6C9pv3pWfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gg7jcruAc0ylbUzf3fT/2Ky7rJkiQpIRGNLH23jDJUo=; b=mcMCFnYmfuoORKcyMUpfflsuYkvEOl3mvQ/bZh1cJO85qGBgwTj4VSpD/Ah9pF8W7xTqrDe1s1971NNThXyYuckAa02QDbSrexXUi9emofEGP5n11xfcuqEod0nWKr00Cnz39GaVH8TBAH/BKasmhoi6mIJDOQqmaSnQTnB0nWG2DMQlOg9vHBuDwT1xSpVKQ8dMYJvMS9giGfXcxUPrVRvoS8Tx05NvtoaPz9nDeUnSQRkLhLMFIK30TAl/c3gNNEYqGpgVwbueR5JhTpNhPKceh0DTTusYJtc73os4iahRZJ4QPOHAFiClzUWZ+MQUWGgrsaLQeF1ucIpE0fNnnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gg7jcruAc0ylbUzf3fT/2Ky7rJkiQpIRGNLH23jDJUo=; b=cSXkJf28n+OggVRjEkBc18OZcl7t2MgostTCuEz282zGv/vP8o+ngyhrwEeMTlivkf+nLOc5WDy9ibch/jCSTOnMIU1RCDvzcf3yUYfEBXvN1jNHb9RB2z/dSrLaCgTZ7uCJHVpOhaPUxh9xu2bJ6GURlactbxexlAC8Ei8qVNw= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6852.eurprd07.prod.outlook.com (2603:10a6:20b:1b3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Thu, 30 Apr 2020 12:08:53 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 12:08:53 +0000 From: Christer Holmberg To: Benjamin Kaduk , Roman Danyliw , "Murray S. Kucherawy" CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney , Rifaat Shekh-Yusef Thread-Topic: Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) Thread-Index: AQHWHugd3GnIoSQ2kUWAEgk7QKROLQ== Date: Thu, 30 Apr 2020 12:08:53 +0000 Message-ID: <27C3E7FD-D540-4846-9805-08358F39713A@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d49f7761-07c7-4cde-8f5a-08d7ecff4035 x-ms-traffictypediagnostic: AM7PR07MB6852: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0389EDA07F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1KwIb26eIPN5+RHm3iaPdSB6pyTLZ7uJNBtYSmbTNl5ET2wFhDBBknZUYn+vYD31ylTh7m9gm3FoUHgYi93LeonTociVkeMF+jleB420A/G3DVTM8Jc7h3hIWD5FWAI0Kk7k7Awx9kTYchSFTEIlNtzglAKZ2bUzviwMoJAZimdO6sli99bkWoQmmWGMBunXL93Bf0rsi3P8OlcvIfsRn73GGvr/SXweZXYvRvEDH8+eC8+WGcGmNXSWlFPMu9J9BMcO9lg8oOKLlzualKcxTenF4cQc3TWx6+w9BiW8sttu4i6leM5+4V0b1MCDytKxAvah5tGk7USLlj/a76RYBrd8F4okInzbWdDtodHuKZuJsun79qJ5DutR+zoGmUreJ5djWdB3osRbOj6MEXxN59rTs2RK1ri8YALLxGsu9v2xndMfb2xLd74iaV+uLTAx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(136003)(376002)(39860400002)(6512007)(44832011)(6506007)(36756003)(26005)(4326008)(8936002)(2906002)(6486002)(186003)(71200400001)(8676002)(558084003)(478600001)(86362001)(66476007)(64756008)(66946007)(76116006)(91956017)(54906003)(316002)(110136005)(66446008)(66556008)(2616005)(5660300002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DjmVo9B65RVp3msTZvNVNoBlKpzwUjU285Q7iPGxuhqt0dREFBC0zNn0cXGiQt7GVYyuJ5QRMYjyovsHAec8FFNzWXePC9I5FzUMHkKGeWrh5uaDYxmppK82Tz38ODku4/Lh3EoUHE1irfMHfw/grYkOiAnHzgkl+pPKe0SiUTeNV4Uii0QuuoUCm9OvaBb1WqOSsFNqHf4gPMhbwmZW/V/4+EW+NpbbKxUj3eOEb0g5gzc9+alaDpxUDpV5TFecX1fqEiXZzWd88tV1qAT6pYqVV6fKqnfM80SRvKcSOS7peZHZFSMizY/jD0492Lao8mCV/z1dxzhQohuJhAN+AukzCUi7kD1tbOBfF5BroEYfmEokqiXJ7Jp6+cc9lX7VWDebMnaRNwfoqx27lfxQ0th6oLXUO8O1T7egwxdu8fIAONp1hh29z4GKJHyEa8X2mJnknrvmnIAkkP2iukaxX496dheVwL8spDt8KYM5pJfIIVO/39ih3Y934MQ0fLSEgYeM7rWK0d+CHZHLsFd+JLAR1ejyiQfLXvTnmR3GIU3cPFNIbsFxLXAxLPzF5fN3NUWiCwrOuopCJUsf5t0whQC5XfSmRTp/RaQpE6nNB6W28Lk2NQRteljjCWPMEsQa6tljK+//Ie286OGfdbi5ef128nbsrkj3AxOFv25qtIWcT3rkXDmmqcMuyCUcMRFovLG8bwB1x2p5RkxURZK0DFrvcmwyDpQnhww/0oUp7oDASPHuvf5b3tMxcsXOA5I3mo2Es74i3d5HeQFmZr8y4sWRl3S+UCUmxGv3J369XkPtDBkgdVI4Qct9x/JVm6+L x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d49f7761-07c7-4cde-8f5a-08d7ecff4035 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 12:08:53.3704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aCKXuGDTwqebhKtHHCbjvkcNhBSfHhWyzPnNqASMJFTTdp9TeNuJArFcqyxR5VpES9jnL0iVCBbc28ZDCUE0DAVmAmkVlGY1Uqowvq1SZns= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6852 Archived-At: Subject: [sipcore] Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 12:08:57 -0000 SGksDQoNCkJhc2VkIG9uIHRoZSBJRVNHIHJldmlld3MsIHdlIGhhdmUgc3VibWl0dGVkIGEgbmV3 IHZlcnNpb24gKC0xNCkgb2YgZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnouDQoN CldlIGJlbGlldmUgYW5kIGhvcGUgdGhhdCBhbGwgaXNzdWVzIHJhaXNlZCBpbiB0aGUgSUVTRyBy ZXZpZXdzIGhhdmUgYmVlbiBhZGRyZXNzZWQsIGJ1dCBwbGVhc2UgdGFrZSBhIGxvb2suDQoNCkEg YmlnIFRoYW5rIFlvdSBmb3IgYWxsIHRoZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMhIDopDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==