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

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 09 July 2019 16:26 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 04CD812022B for <sipcore@ietfa.amsl.com>; Tue, 9 Jul 2019 09:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zjgq-KcPUwoP for <sipcore@ietfa.amsl.com>; Tue, 9 Jul 2019 09:26:01 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 174511201E6 for <sipcore@ietf.org>; Tue, 9 Jul 2019 09:25:59 -0700 (PDT)
Received: from PaulKyzivatsMBP.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 x69GPsUV007994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Jul 2019 12:25:55 -0400
To: Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5bb63c0c-130d-7f69-10b0-1ed1b274cc58@alum.mit.edu>
Date: Tue, 09 Jul 2019 12:25:54 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/d2QK68ofNEWh2tQFMptE7j6FPyM>
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: Tue, 09 Jul 2019 16:26:03 -0000

On 7/9/19 11:42 AM, Christer Holmberg wrote:
> Hi,
>      
>>> As I said in another reply, if you by default place a REGISTER token in a non-REGISTER request the token may reach the remote peer, which could be a security concern.
>>     
>>     I would like to hear more about this. Is there something about the token
>>     that reveals stuff that might not be suitable to expose to everyone? I
>>     personally don't know. This seems like something that ought to be
>>     discussed in security considerations.
>    
> The token itself does not reveal anything, but in OAuth the token is used to access the requested resource, so it is considered sensitive information.
> 
> As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. I have never heard about anyone using it for non-REGISTER authentication, and I wonder whether we even need to cover it in the draft. We could limit the scope the REGISTER requests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separate draft can be written.

Yes, you can do that if you wish. But ISTM that the issues are largely 
the same so I don't know why you would do that.

	Thanks,
	Paul