IETF Logo Mail Archive

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

"Olle E. Johansson" <oej@edvina.net> Thu, 11 July 2019 07:45 UTC

Return-Path: <oej@edvina.net>
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 7BE0B120281 for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 00:45:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 E7ZpPzLOgX0G for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 00:45:22 -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 E76DE12025D for <sipcore@ietf.org>; Thu, 11 Jul 2019 00:45:21 -0700 (PDT)
Received: from [192.168.1.80] (static-212-247-19-62.cust.tele2.se [212.247.19.62]) (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 8E6CDA40; Thu, 11 Jul 2019 09:45:18 +0200 (CEST)
From: "Olle E. Johansson" <oej@edvina.net>
Message-Id: <8567C7DB-6E30-42EF-B509-76A65285CEAF@edvina.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB1152BB-BA42-478F-A698-C226F67513B8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 11 Jul 2019 09:45:17 +0200
In-Reply-To: <CAD5OKxs2Ji9P3n3kDxCrdfMQmB-JeovYZcNuJHEGj5RjqWdkSA@mail.gmail.com>
Cc: Olle E Johansson <oej@edvina.net>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, "sipcore@ietf.org" <sipcore@ietf.org>
To: Roman Shpount <roman@telurix.com>
References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <CAGL6epLsP_UfZMAcFLsORrR05Enu-vp=jnkgUFuKSttQm8swAw@mail.gmail.com> <c8d5c42e-ab21-80e8-3189-c8592dd02d3a@alum.mit.edu> <HE1PR07MB3161C55955B2FCED2C0F6A9993F60@HE1PR07MB3161.eurprd07.prod.outlook.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <HE1PR07MB3161D46B4A44FC7E789ADDB893F10@HE1PR07MB3161.eurprd07.prod.outlook.com> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <CAD5OKxuK_2+JcbGvo6LNeRbCYXWXQmhKQPNUzoZvZEOupPWyjw@mail.gmail.com> <HE1PR07MB3161612130F07C8F727A2BB693F10@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxtR-WBhfa4msbAfXoK7JowYaKK3fSCbw0cXm6SRGwkLxg@mail.gmail.com> <CAGL6epK8Z938pnMKVyWGBK=6fMzNq6+gmxro-AAO2nzvGT4jeg@mail.gmail.com> <CAD5OKxs6g+6mLbMRc9C0q5BSSn=+7HHzKf5Ya5uL-+RbhVfEaA@mail.gmail.com> <CAGL6epKfLWA=RW3T84feSud9sZ+TcpB=XRA6fvTzP-jL3h4+4A@mail.gmail.com> <CAD5OKxs3=XdOFYThY1gCu23M4nqJV-bJOSCU7-Ogn0J=xy+E3A@mail.gmail.com> <CAGL6epJWXBTcnNk3nMN3Yfsh5y6+pddQSW_MbkAdNZbmWf6_Gg@mail.gmail.com> <CAD5OKxt=sJhKGRRFPUon=JokbJ2Vb=P7GcfJ8LpXt_Yp-eOg3Q@mail.gmail.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <CAD5OKxs2Ji9P3n3kDxCrdfMQmB-JeovYZcNuJHEGj5RjqWdkSA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/cw0ujPRkMeNW84hJd_0bo_gA0rQ>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.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: Thu, 11 Jul 2019 07:45:26 -0000


> On 11 Jul 2019, at 01:10, Roman Shpount <roman@telurix.com> wrote:
> 
> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> wrote:
> 
> 
>> On 10 Jul 2019, at 02:53, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wrote:
>> 
>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com <mailto:rifaat.ietf@gmail.com>> wrote:
>> The document clearly allows the use of access token to authenticate non-REGISTER requests when challenged in the context of the same realm.
>> 
>> Whether that is needed or not is a different discussion.
>> Assuming the UA was able to authenticate the user and obtain an access token, then establish an authenticated TLS channel with the server, and register the user; is there a need for further challenges from server?
>> 
> When the token expires, you certainly need a new token from the user. With SIP Outbound, we’re more connection oriented than before, so we should propably consider what the
> server does with the connection when a token expires (if it’s not already in the draft).
> 
> 
> Keep in mind that proxy responsible for SIP Outbound or Web Sockets edge proxy and registrar can be two different servers. Connection from end user device to SIP Outbound Proxy can be unique, but connection from edge proxy to the registrar can be reused for multiple clients. I am sure this can be un-bundled and made to work but it is not always trivial.

Right, but the specific contacts with separate reg-id*s could be disabled in the registrar.

/O

v2.23.0 | Report a Bug | By Email