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 13:06 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 48F8912011D for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 06:06:50 -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 f_uFbhnwBDyN for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 06:06:48 -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 A1096120114 for <sipcore@ietf.org>; Thu, 11 Jul 2019 06:06:47 -0700 (PDT)
Received: from [192.168.1.69] (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 7157EA40; Thu, 11 Jul 2019 15:06:43 +0200 (CEST)
From: "Olle E. Johansson" <oej@edvina.net>
Message-Id: <1521246D-E64A-4CB6-AA48-B90070E45575@edvina.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EE097341-F36F-470F-ABB1-3E1B0F48396C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 11 Jul 2019 15:06:43 +0200
In-Reply-To: <45418731-F319-4C03-B543-1398E2EF49E1@ericsson.com>
Cc: Olle E Johansson <oej@edvina.net>, "sipcore@ietf.org" <sipcore@ietf.org>
To: Christer Holmberg <christer.holmberg@ericsson.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> <5bb63c0c-130d-7f69-10b0-1ed1b274cc58@alum.mit.edu> <87AD4BB8-CE77-4FD7-BB72-6643DF513058@ericsson.com> <168b1354-b35b-edee-e5f9-d4ddbecfae40@alum.mit.edu> <607A513F-8616-4777-8B5E-59390E845709@ericsson.com> <b6ca4c79-5a17-10da-3882-20bc8b0e9b98@alum.mit.edu> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <BCFE43BD-86FF-457E-9006-1DA7C8F3F6BE@edvina.net> <C3BFE2FE-0797-4E54-BAD4-B24E32CB183F@ericsson.com> <BD0B9B14-1E35-42C4-BF51-430C7E052145@edvina.net> <C5597D63-1B58-44D0-A2CE-4170CC1BE23E@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <A5F3B221-86C3-48A8-8D2C-3C04838ABCCD@edvina.net> <45418731-F319-4C03-B543-1398E2EF49E1@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/Ksym8zlX70ERRtEYxfzkxgM34T0>
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 13:06:50 -0000


> On 11 Jul 2019, at 14:58, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi,
> 
>    ...
> 
>> Regardless, it is where we are and we have to find some sort of agreement on how to proceed. I would feel sad of having 
>> to support a poor document with too many compromises because of this implementation. 
> 
>    Not sure I agree with "too many compromises”.
Not yet, but in a few mail exchanges this topic kept coming up so I exaggerated a bit. Sorry…

> 
>    What we are discussing is standardizing scope information in the draft. If I understand correctly, you don't need that for the basic mechanism to work - you only need it if you want to include authorization information in the token. In case of registration, if the SIP server has that information, it is not needed.
> 
>    Also, in the case of SSO, couldn't you use the token for more things than SIP? In that case I assume you don't want to scope it to SIP only.

Please read section 3.3 of the Oauth 2.0 Security Best Current Practise.
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13>

"In particular, access tokens SHOULD be restricted to certain resource servers, preferably to a single resource server. “

So no, I don’t wan’t the access token used for SIP used for anything else. When the client requests authorization you propably want to request a specific resource server (SIP domain)
that this token applies to. Most examples in the docs refer to HTTPS URI’s, but the spec keeps saying “URI” so I assume a SIP domain uri or a sip server URI would work too. 
This is all in theory of course, I don’t know what kind of core dump or other hiccup a SIP URI would generate in current OAuth2 implementations ;-)

Any recommendations on Open Source Oauth2 servers to play around with, btw?

Gentle reminder: Let’s stop using “the token” :-)

/O

v2.23.0 | Report a Bug | By Email