IETF Logo Mail Archive

Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 29 June 2019 13:47 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 0B6DF12000E for <sipcore@ietfa.amsl.com>; Sat, 29 Jun 2019 06:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dmWTN6qy5_hB for <sipcore@ietfa.amsl.com>; Sat, 29 Jun 2019 06:47:38 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130055.outbound.protection.outlook.com [40.107.13.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA35120019 for <sipcore@ietf.org>; Sat, 29 Jun 2019 06:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eRbItSsksRU72/StQIB+cK1nbW1GfuzaOxM/P8iNzEs=; b=IzlC7R5CzFeLiJw2lIcIOlMQ2VJ2hzCI1XBciVY2IihtKEJ3Z4fimYX//4pn7tMImwEAQzLKGDFu1Lg99LOPd/yPfFlG0qyBXnni8fa/L0ACkXqVzoBlbLejiqheXJpDu2u9yi08mxOchV01zYR4XkTa3geG6PSD26pPT+vSP4U=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3433.eurprd07.prod.outlook.com (10.170.247.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.12; Sat, 29 Jun 2019 13:47:35 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec69:84fc:5339:d4fd%7]) with mapi id 15.20.2052.010; Sat, 29 Jun 2019 13:47:34 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
CC: SIPCORE <sipcore@ietf.org>
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt
Thread-Index: AQHVKq2VsyOy4sob90miFwLZxwfdy6arBqMAgAA9R4CAARQiAIAAHHQAgAAt8wCAADqGAIABd7SAgARUXlA=
Date: Sat, 29 Jun 2019 13:47:33 +0000
Message-ID: <HE1PR07MB3161D117D2F2A570512BD7F893FF0@HE1PR07MB3161.eurprd07.prod.outlook.com>
References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <CAGL6ep+xZaRX7vFDJxV4qrv57OF2QKbUEMgdW52Hf-RUySSDjQ@mail.gmail.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <CAGL6ep+RiBWLC_NNHdb2Fai=8sbeMiTD+8vQfknyUiTn4r1wRw@mail.gmail.com> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> <CAGL6epKpPQ8CD09RUry-Mj+ZyhKXCupumYbXddaLamux0TM1aA@mail.gmail.com> <d032df76-2b3e-194e-7bda-7d29b5ecf674@alum.mit.edu> <CAGL6epKebTeca3xFX6wBErTPdnS5SzCED9bfjmQOwji0Q77XXA@mail.gmail.com>
In-Reply-To: <CAGL6epKebTeca3xFX6wBErTPdnS5SzCED9bfjmQOwji0Q77XXA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [94.66.125.175]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 43c52831-0b37-4877-9c67-08d6fc985746
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3433;
x-ms-traffictypediagnostic: HE1PR07MB3433:
x-microsoft-antispam-prvs: <HE1PR07MB3433D4132098EF94F79BA6A993FF0@HE1PR07MB3433.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0083A7F08A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(189003)(199004)(476003)(3846002)(6116002)(486006)(52536014)(64756008)(2906002)(316002)(186003)(446003)(76116006)(66946007)(73956011)(11346002)(478600001)(66446008)(110136005)(14454004)(55016002)(33656002)(71190400001)(66476007)(66556008)(44832011)(86362001)(71200400001)(9686003)(8936002)(76176011)(7696005)(305945005)(68736007)(6436002)(6246003)(6506007)(14444005)(74316002)(2171002)(81166006)(53936002)(102836004)(25786009)(99286004)(5660300002)(7736002)(26005)(256004)(229853002)(8676002)(81156014)(4326008)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3433; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: JnNYT/HviLz19MlCT9ahgHnX5LqOOmJdzvfNxU5//UPpWxxDfUlTg7gkTs2tkD3i1uZV56X4jjy2CIC/YT0gE7DuV+a9goxo0G/EjdxvFWXOfQzhyOjlB79hOTYzr0RDWcySTWPPxlVJFtpjohwVZVXRczVunax5nrBUsRk3uJVhQylxbcNP3eUSxUPgaPHWu4hL55Fa1WRnV3UPfYZLNIgvtkFT5HR0/EqKoscHvA+M+LhCWEnuE72IhE7cd0r00zvCKJLX25YNyykzkE/FBfV3hSsV+0FDz9oeiQz6zfZWQlL6ffQl7MxQE4+Ut4nW4f/uHAXubLMe1DoNWDD5vGGvMxMZuAc79RigPYKs0Cm9cMg0tjegG6ehOhamo43F6ZjlL8VFKA1jLCPw2ZosDmZu12VkubDZRpcrMk1Tkbw=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43c52831-0b37-4877-9c67-08d6fc985746
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2019 13:47:34.0382 (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: christer.holmberg@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/TkoPiHCHc62xgwj2PZT1b8tfa3U>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jun 2019 13:47:40 -0000

Hi,
 
...

>> And a more fleshed out 
>> example that shows who puts up the UI to gather the needed info, what is 
>> included in the prompt, what comes back, and what is done with it then. 
>> Enough to relate it to real world experience.
>>
>> (AFAIK most real world experience is with web interfaces. For instance 
>> when hitting restricted web sites that require a login from Google, 
>> Facebook, Discus, etc. IIUC this could be much like that, including the 
>> choice of which of those to use. So a use case like that would be great.
>
> I think UI related issues and authentication using 3rd party IdPs are really out of scope of this document.

I agree.

...

>> Again, while it is probably true that SIP authentication is mostly used 
>> with registrars, it is also possible for other servers to require 
>> authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can 
>> send a challenge. So the UA needs to be prepared for this and do the 
>> right thing.
>>
>> Doing that right includes caching credentials and providing them 
>> appropriately to avoid unnecessarily prompting the user too often. And 
>> then preemptively sending credentials becomes an optimization to avoid 
>> extra round trips. This of course is very important for REGISTER since 
>> it at times is used very frequently as a keep-alive. But at the same 
>> time one needs to have some security guidance on when it is appropriate 
>> to send preemptively and when not.
>
> I will add text around this to indicate that non-REGISTER requests should always include the Access Token in the request.

I don't think we shall do that.

I think the token shall only be included in non-REGISTER requests only if such requests are being challenged (or, perhaps also based on local configuration), because otherwise the token may be sent to a non-trusted remote peer.

Regards,

Christer

v2.23.0 | Report a Bug | By Email