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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 11 July 2019 14:24 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 C830112004E for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 07:24:53 -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 4hhgsCkqvzEB for <sipcore@ietfa.amsl.com>; Thu, 11 Jul 2019 07:24:52 -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 E89A0120047 for <sipcore@ietf.org>; Thu, 11 Jul 2019 07:24:51 -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 x6BEOhFk029024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jul 2019 10:24:44 -0400
To: Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
References: <156249821133.14592.1211919336596009446@ietfa.amsl.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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <D7218ABE-F204-407B-ADE1-39DAB98C2A98@ericsson.com> <cd23be26-c383-8b72-cdf1-4436a6bc175f@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <64b7d784-3f34-dd11-d7e2-b22fe621cd70@alum.mit.edu>
Date: Thu, 11 Jul 2019 10:24:43 -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: <59F235A8-2BD4-49B5-8890-E793E1CF40EC@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/cmIQjlEiMRACL0GShupY_FSb3eE>
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 14:24:54 -0000

On 7/11/19 10:07 AM, Christer Holmberg wrote:
> Hi,
> 
>      >>>> All I am saying is that one should not send a token to someone that it has NOT been issued for.
>      >>>
>      >>>     Then you are saying that a token should *never* be included in a request
>      >>>     to a target for which you have not received a challenge some time in the
>      >>>     past.
>      >>>
>      >>>     That is a bit extreme, but I guess you can specify that if you think it
>      >>>     is the right thing to do.
>      >>
>      >> That is my understanding of the generic OAuth security considerations: you don't give a token to someone it was not intended for.
>      >>
>      >> Of course, if you know (based on whatever configuration/policy) that it's ok to give the token to the target I guess you could do it.
>      >>
>      >>>     But note that this logic won't always work for Proxy-Authenticate. You
>      >>>     *might* know that a particular proxy will be visited (if it is mentioned
>      >>>     on a Route header), but it is pretty common for the request to visit
>      >>>     proxies unknown (at least in advance) to the UAC.
>      >>
>      >> It is important to remember that, since the token needs to be protected, a proxy needs to have the
>      >> associated protection credentials to be able to access the token.
>      >
>      > I'm lost here. How is the token protected? Is it because it is passed by
>      > reference, and other credentials are needed to dereference it? Or is it
>      > passed by value but encrypted?
> 
>      That depends on how your protect it.
> 
>      If the oauth2 token itself is encrypted, and only authorized entities can decrypt it, then I guess it does not matter if a non-authorized user gets it, as it will not be able to use it.

Is this going to be defined, or is the intent to leave it open?
I don't understand how things can work if it is left open.

>      But, if the oauth2 token is sent in "plain text", then the SIP signaling needs to be protected/encrypted. But, in that case, if I make a phone call to you, and the call itself is valid, then I should not send you the oauth2 token unless it's meant for you, because once you decrypt the signaling you will have access to it.
> 
>     What is important is that a non-authorized user should not have access to a non-protected oauth2 token.

I don't see how this can work. How does the UAC *know* if the server it 
is sending credentials to is authorized to receive those credentials?

In general the UAC doesn't know what proxies and UAS the request will 
visit. All it knows is the request-URI. Since there generally isn't a 
direct connection from UAC to UAS TLS authentication doesn't help.

	Thanks,
	Paul