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

Roman Shpount <roman@telurix.com> Wed, 10 July 2019 00:53 UTC

Return-Path: <roman@telurix.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 487E11200F6 for <sipcore@ietfa.amsl.com>; Tue, 9 Jul 2019 17:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.593
X-Spam-Level:
X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 GmwZ_FwuqF7a for <sipcore@ietfa.amsl.com>; Tue, 9 Jul 2019 17:53:52 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B646D120048 for <sipcore@ietf.org>; Tue, 9 Jul 2019 17:53:52 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id b13so210109pfo.1 for <sipcore@ietf.org>; Tue, 09 Jul 2019 17:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Yhdnr3k+SChEjhgE4qVyWmbg6XNg+mS91tEfbCTkVw=; b=ju23g1LTC7byFf0FVcKKfDJtwD6GLTB3MLUZ+2b1lavj3Cqhnc7SVaozJaO0xyIuuW 9SAsZKpN7xoyJopROa6xyZ/0AogoixNMn2xcIe/lpL5u+PatLjZkE+wmkkqv3vloccB0 XbM1hWGG/oZqCd1ApJbPHR6292+cc9AblWBXQQOtT6HIdqh80Lyfprh+4/3bDVBSI/O8 friq79DPzd+UOBpNhAVC0prcDN0Tor1b0muv2rXhTxIUyBMWcIUaPqRXZoNy6w00q+DF YS+R0M15aG5eua+iStJWMDWKJcsmlMl82xeHoalarBFX9au5kQb7pGpj/wY16cvP3o+E 6eWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Yhdnr3k+SChEjhgE4qVyWmbg6XNg+mS91tEfbCTkVw=; b=t+5BSNsm0qiARxzCNYDn6IpTWnjf87LM/shq6UXU3qviyjPiUIMj/jBYcCHYkoOCyp dpBaVkKkZe5IhtL6H99lvdBOOWafB1Dafav5gAywwQUx4v26pEb9Bbz/6na1EmT5lGjk QRDnpgjmNt9mazqXsqLNDZVhKyEsiwHmVRecsgWQl3jCn4VQpOHFDz3extzF3iD9hyJU FUdYW7KhE2eREzxcfLwA60LWlY7M1S3YYyJ4SZUOdTUzvSsga16zGBrsuakgUORpDMjy QQIhly38ghn46CkjUoPWXKNMScYz/79yhA21lZCoPeUILjDUGDUGZhGYgvdF0cJqLrqx T0jQ==
X-Gm-Message-State: APjAAAVnxxklk3uxlhLGf73qEga06GhnyLVodlfJcO7y0hbduvP5C61T v4k6CJj9kwkuKg+j1hd78NAKs9/vze0=
X-Google-Smtp-Source: APXvYqxAdm/N3ARaARZ3TSrR5EJwCg4LIZ/OskQlfLgkc4Ycy8jXlAloD1Y3f7RLt5TVuoEBNc49Rg==
X-Received: by 2002:a65:5c0a:: with SMTP id u10mr34115197pgr.410.1562720031714; Tue, 09 Jul 2019 17:53:51 -0700 (PDT)
Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com. [209.85.214.180]) by smtp.gmail.com with ESMTPSA id x22sm274435pff.5.2019.07.09.17.53.50 for <sipcore@ietf.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 17:53:50 -0700 (PDT)
Received: by mail-pl1-f180.google.com with SMTP id cl9so261928plb.10 for <sipcore@ietf.org>; Tue, 09 Jul 2019 17:53:50 -0700 (PDT)
X-Received: by 2002:a17:902:a40c:: with SMTP id p12mr35529751plq.146.1562720030084; Tue, 09 Jul 2019 17:53:50 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAGL6epJWXBTcnNk3nMN3Yfsh5y6+pddQSW_MbkAdNZbmWf6_Gg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 09 Jul 2019 20:53:40 -0400
X-Gmail-Original-Message-ID: <CAD5OKxt=sJhKGRRFPUon=JokbJ2Vb=P7GcfJ8LpXt_Yp-eOg3Q@mail.gmail.com>
Message-ID: <CAD5OKxt=sJhKGRRFPUon=JokbJ2Vb=P7GcfJ8LpXt_Yp-eOg3Q@mail.gmail.com>
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000046d5c1058d491c8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/XC7uaVSB3KoLiYsmSYsWwZ-7uhg>
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: Wed, 10 Jul 2019 00:53:54 -0000

On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <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?
>
>
Typically, for SIP, user authentication is not tied to the TLS connection.
One of the reasons for this is that multiple users can use the same TLS
connection in federated systems. This is especially true for Confidential
UA, which have trust relationship with a proxy and can maintain a secure
connection to the registrar/proxy on behalf of multiple clients.

Once again, it would be much easier to discuss if you can provide a use
specific case for OAuth with confidential UA. I can easily think of a OAuth
use case for Public User Agent, but only have a vague idea what OAuth with
Confidential UA would be.

The example I can think of, would be some sort of hot desk application,
where user allows a Local PBX to register with User Home PBX to accept
calls on behalf of user in a remote location. In this case, Local PBX and
User Home PBX will be federated systems which will use a single TLS
connection for multiple calls or end user devices. Local PBX and User Home
PBX will have a trust relationship, possibly with mutual TLS certificate
authentications. A company wide directory server will be used to store
actual user credentials and will be used to authenticate the user and
generate the token.

Best Regards,
_____________
Roman Shpount