From nobody Mon Jul 1 12:07:25 2019 Return-Path: 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 9E88B120A1E for ; Mon, 1 Jul 2019 12:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 1Lw-Dp4hudSF for ; Mon, 1 Jul 2019 12:07:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1E795120A0A for ; Mon, 1 Jul 2019 12:07:22 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x61J7FgP083805 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Jul 2019 14:07:16 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562008037; bh=CbhsoGFDBvW11f09ukUs1f2r6sVq+7M3s47Acm818Vo=; h=To:From:Subject:Date; b=tXrxtnCW6tzJyx23jU9ZaMqejoAZEJO0KhRczzF2AHvEhCjqCv4jvKSjvWE6JVCri 2ldeuvsaFpa9sOmcC6wzDkaeD/39GsN7JfzCZGV7T2t2aMhpICuzIuTzAt/9PehIj6 VzQbkwcThPUzy/CLgkkSsU66gOb12jcENXWxfBeY= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: Rifaat Shekh-Yusef , SIPCORE From: "A. Jean Mahoney" Message-ID: Date: Mon, 1 Jul 2019 14:07:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Doc Shepherd review of draft-ietf-sipcore-digest-scheme - Section 2.6 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 19:07:24 -0000 Hi Rifaat, As I was going through the draft on my Doc Shepherd pass, I found some issues in the text that was inherited from RFC3261 (section 2.6). Mainly the text talks about servers and clients and doesn't cover proxies well. The section talks about the Authorization header field but doesn't mention the Proxy-Authorization header field. Bullet 8 does use the phrase "any resulting authorization header field", which may cover Proxy-Authorization, but it's not explicit. I think using the terms UAC and UAS in this section would help, and the Proxy-Authorization header field should be mentioned explicitly. I'll send the rest of my comments on the draft (mostly nits) in another message. Thanks! Jean From nobody Mon Jul 1 12:30:46 2019 Return-Path: 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 31791120179 for ; Mon, 1 Jul 2019 12:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 kaenuA35ZCb0 for ; Mon, 1 Jul 2019 12:30:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 780B2120178 for ; Mon, 1 Jul 2019 12:30:42 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x61JUcZW087610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Jul 2019 14:30:39 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562009440; bh=aL0UAv5nB55IfnFcFgiLD6o4F4lEqnBtzXJlCAYl5wU=; h=To:From:Subject:Date; b=ofZcpDMHLFWG9X/4eaOCrYXuQtA3xsoDbXoIkK/6oFtNWJQn9s1/YopldskDaQ8Gq 2C+IVSJj+8Aj6RQ3s3/eTg7Mp93mHVpN+b2AIHxtvRC3YP3tCm5SF0nmh57fRvgUXj bOgLNhkgoUzw2bXXSQRZ3ZpqNMaVsnJH9qPmmkEE= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: Rifaat Shekh-Yusef , SIPCORE From: "A. Jean Mahoney" Message-ID: Date: Mon, 1 Jul 2019 14:30:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Doc Shepherd review of draft-ietf-sipcore-digest-scheme, cont. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 19:30:44 -0000 Hi Rifaat, Below are the rest of my Doc Shepherd review comments, mainly a few minor issues and nits. I have a suggested rework of the Introduction to clarify that MD5 is not collision resistant and that RFC3261 references the RFC obsoleted by RFC7616. Thanks! Jean General: There are some instances of "SIP protocol" and "HTTP protocol". These should be replaced with either "SIP"/"HTTP" or "Session Initiation Protocol"/"Hypertext Transfer Protocol". Abstract: Should explicitly mention that the document updates RFC 3261 (idnits flagged this). Should mention that MD5 is still available for backward availability. Introduction: Suggested rewording - The Session Initiation Protocol [RFC3261] uses the same mechanism that the Hypertext Transfer Protocol (HTTP) uses for authenticating users. This mechanism is called Digest Access Authentication, and it is a simple challenge-response mechanism that allows a server to challenge a client request and allows a client to provide authentication information in response to that challenge. The version of Digest Access Authentication that RFC 3261 references is specified in [RFC2617]. The default hash algorithm for Digest Access Authentication is MD5. However, it has been demonstrated that the MD5 algorithm is not collision resistant, and is now considered a bad choice for a hash function [RFC6151]. The HTTP Digest Access Authentication [RFC7616] document obsoletes [RFC2617] and adds stronger algorithms that can be used with the Digest Authentication scheme, and establishes a registry for these algorithms, known as the "Hash Algorithms for HTTP Digest Authentication" registry, so that algorithms can be added in the future. This document updates the Digest Access Authentication scheme used by SIP to support the algorithms listed in the "Hash Algorithms for HTTP Digest Authentication" registry defined by [RFC7616]. S2 p2: This section should also mention that the BNF for the URI included in the challenge has been changed and now allows more schemes than SIP and SIPS. S2 p2: UAC and UAS should be expanded on first use. S2 p2: s/"qop" option/"qop" parameter S2.1 p2: s/any registered algorithm/any algorithm listed in the "Hash Algorithms for HTTP Digest Authentication" registry. S2.4 p1: Remove the space in "Proxy- Authenticate" S2.5 p1: s/introduces some clarification to that/clarifies that S2.5 p2: s/proxy to the UA./proxy to the UAC. S2.6: I suggest changing the title to "HTTP Digest Authentication Scheme Modifications" to match better the section title in RFC 3261. S2.6 p1: There is also a change to the BNF in bullet 1 that allows more URI schemes, so "... specified in bullets, 1, 7 and 8." S2.6 p3: Add a reference to RFC7616 after HTTP. S2.6 #8: s/handle "qop"/handle the "qop" (occurs twice) S2.6 last p: s/continue/continues S2.7 p1: Insert a reference to [RFC5234] after "Augmented BNF". S3 p1: s/used to with/used with S4 p1: Add an explicit statement such as, "This document has no actions for IANA." S6: Add references to RFC 5234 and RFC 6151. From nobody Tue Jul 2 09:15:50 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D92120412; Tue, 2 Jul 2019 09:15:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: sipcore@ietf.org, draft-ietf-sipcore-rejected.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nancy Cam-Winget Message-ID: <156208413663.23908.7643344599862494056@ietfa.amsl.com> Date: Tue, 02 Jul 2019 09:15:36 -0700 Archived-At: Subject: [sipcore] Secdir last call review of draft-ietf-sipcore-rejected-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 16:15:37 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits SECDIR review of draft-ietf-sipcore-rejected-08 Reviewer: Nancy Cam-Winget Review result: Ready with Nits I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document defines the use of value 608 as the "rejected" SIP response code. More specifically, the intent is to define a code such that an intermediary (e.g. an analytics engine versus the target user server) can signal that it is rejecting the call. The following are general comments and suggestions (and editorial nits at the end): 3.1 "Proxies need to be mindful that a downstream intermediary may reject....", this seems too imply that there are other nodes in the path that can generate the 608 reject. What is the underlying key used to sign the JWT and how can this be validated as being a proper and identifiably authorized intermediary to issue such a 608 signal? What happens if multiple intermediaries want to reject the call? Perhaps adding a sentence here would be helpful. 6. "Yet another risk is a malicious intermediary.....strongly recommend the recipient validates to whom they are communicating"; it seems like perhaps this should be a MUST in that the recipient should validate that both the message is valid but also the sender can be trusted. Signing the jCard is actually a MUST. This paragraph is a bit long and hard to discern, it could benefit from breaking it into the different considerations: the need to at minimum sign the jCard, the need to also trust (verify the authorization or validity of the source). - there should also be considerations or how to handle multiple intermediaries sending the sip.608 signals Editorial nits: - I presume the [RFCXXXX] refers to this draft once it is RFC'ed.... 3.4 "The simple rule is a network element ....", this should be a stronger MUST that is the network element that is sip.608 "MUST convey at a minimum..." From nobody Tue Jul 2 11:37:36 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065B12010F; Tue, 2 Jul 2019 11:37:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156209265538.23895.13604901074279719119@ietfa.amsl.com> Date: Tue, 02 Jul 2019 11:37:35 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 18:37:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : The Session Initiation Protocol (SIP) Digest Authentication Scheme Author : Rifaat Shekh-Yusef Filename : draft-ietf-sipcore-digest-scheme-06.txt Pages : 9 Date : 2019-07-02 Abstract: This document updates [RFC3261] by updating the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the broken MD5 algorithm, which might be used for backward compatibility reasons only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-06 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 2 11:39:01 2019 Return-Path: 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 74E1112010F for ; Tue, 2 Jul 2019 11:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d66pFxoV-CSX for ; Tue, 2 Jul 2019 11:38:58 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 02EF21200D5 for ; Tue, 2 Jul 2019 11:38:58 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id h6so39513429ioh.3 for ; Tue, 02 Jul 2019 11:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Q2fbYcQ9HvOuobZc1/ji9vGA7mZRfdV+OR1j33ynrE=; b=D5qgS85Q/ONtNRe4vZS3r56I2daDJwNgw2ZRqPYBgDX+b/ymGXfSIj2t6ic4ZLk+s5 5ypgkekgqyjyUjK+VUeY5jaJFTN+bizzHZRe89xukMSZXgPK0PzreaVbmAv0dBt01smJ CEgheWmWULq2atVPd1DCOobooo1Nq7txppXMDXYFd9Bvpw41UOF2edRBPrLCmLvje5NW XUr5DoamYEb5eL79TGQOyVzh/8PYfR3iR3xCX7LeX5TP49T2N1ZK81NfebupjflseS1Z 5n0ZVMSLSumSttUHd6UcqS46AUaG3Y22ZpSt5KLgraxuiUv3o+MeIMUZWcfoSI5/z8OM Zkxw== 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=6Q2fbYcQ9HvOuobZc1/ji9vGA7mZRfdV+OR1j33ynrE=; b=Ee8HzTcKejWA2IXA/S1UttR0N1RffmQCxSj46rq/+QZLs3rhqc3A0LWmnBVkaOOZJm TFj+XETvRg4tGMi1PQ4KdWK79vY7UyDny7Oe/EPWqZhybYbOe8LiGbBjeFxbtRPcUsFC KCbPUCDKRcnNysoZ3hur0oBdBR/DnhOIj68aIsOtjx+xhktvtYbE3tYUHIpvsM40LNeQ Mb3CXDTQa8kIqCDLypOIayk22tHd8VJrCFVkLD1t2WFWDtbbJCwZ1hqF8JBPjjnmxeou 6SAK5GcDbT2RKgb8dTvGALWZApVOz9N/o0y9xUjW9Mt0cLxeABBO5WgDOQ+fDi5BOcyx Dubw== X-Gm-Message-State: APjAAAURrhKv68SAvPR89kF+UpNZuu+AvNLSs7U7UlmKmCEVnuXU1pSn gi3a+pb95QSGso9BYgU9z/JK2mc2+P14tSsxxWw= X-Google-Smtp-Source: APXvYqyvK5DBLM2Q3y8a2pwztoIDux2LLZYGB0mU1qY97lfd7qnQSdp3WxBYqhGZ4R/GBT8CJh/KAOqJgcznnw/i07c= X-Received: by 2002:a6b:e608:: with SMTP id g8mr6154436ioh.88.1562092737330; Tue, 02 Jul 2019 11:38:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 2 Jul 2019 14:38:46 -0400 Message-ID: To: "A. Jean Mahoney" Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000b702bb058cb70eb8" Archived-At: Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-digest-scheme - Section 2.6 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 18:39:00 -0000 --000000000000b702bb058cb70eb8 Content-Type: text/plain; charset="UTF-8" Thanks Jean! I submitted a new version that I believe addresses this comment. Please, take a look and let me know what you think. Regards, Rifaat On Mon, Jul 1, 2019 at 3:07 PM A. Jean Mahoney wrote: > Hi Rifaat, > > As I was going through the draft on my Doc Shepherd pass, I found some > issues in the text that was inherited from RFC3261 (section 2.6). > > Mainly the text talks about servers and clients and doesn't cover > proxies well. The section talks about the Authorization header field but > doesn't mention the Proxy-Authorization header field. Bullet 8 does use > the phrase "any resulting authorization header field", which may cover > Proxy-Authorization, but it's not explicit. I think using the terms UAC > and UAS in this section would help, and the Proxy-Authorization header > field should be mentioned explicitly. > > I'll send the rest of my comments on the draft (mostly nits) in another > message. > > Thanks! > > Jean > --000000000000b702bb058cb70eb8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jean!

I submitted a new version = that I believe addresses this comment.
Please, take a look and le= t me know what you think.

Regards,
=C2= =A0Rifaat


On Mon, Jul 1, 2019 at 3:07 PM A. Jean Mahone= y <mahoney@nostrum.com> wr= ote:
Hi Rifaat,<= br>
As I was going through the draft on my Doc Shepherd pass, I found some
issues in the text that was inherited from RFC3261 (section 2.6).

Mainly the text talks about servers and clients and doesn't cover
proxies well. The section talks about the Authorization header field but doesn't mention the Proxy-Authorization header field. Bullet 8 does use=
the phrase "any resulting authorization header field", which may = cover
Proxy-Authorization, but it's not explicit. I think using the terms UAC=
and UAS in this section would help, and the Proxy-Authorization header
field should be mentioned explicitly.

I'll send the rest of my comments on the draft (mostly nits) in another=
message.

Thanks!

Jean
--000000000000b702bb058cb70eb8-- From nobody Tue Jul 2 11:43:50 2019 Return-Path: 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 D7644120746 for ; Tue, 2 Jul 2019 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uUlck8hbynpX for ; Tue, 2 Jul 2019 11:43:38 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 BAB451206F3 for ; Tue, 2 Jul 2019 11:43:38 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id u13so39541713iop.0 for ; Tue, 02 Jul 2019 11:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A8XkLSf2rv43uAnsitt/4WbCQYtiEpxzIJpByoDld74=; b=mm5BJ78prZNzQ1ZzvHSJRxYoa3rqNFYS3bMJIgWf7bwazZZ9sLC0iZXwdVXDeNxpT0 MA/LsE7xF29z9XqW37Ov18QMI6XwLP6mg8VLINaEGS4WaqYPLemB8xCyoPT3EdLy0D5P kaXet7cavZz3fg7AA8uhMUBTj/P80dmPJcoIdivve2UdNpajiETpm5ogsGi9IgRsmkfL zafj0ocOX25D29kmsJ2Je6r2nfwj0xhTfCZrRHZa++gwEp8E0Yg7dzzT6LjZIk86qw3T PJTug2PhVqvGGjWd4sgRXB4riSOoeSclLhVOTldEeQ+BNv6O3CjHqLBv6A6UaYqS2V3/ YC6A== 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=A8XkLSf2rv43uAnsitt/4WbCQYtiEpxzIJpByoDld74=; b=cKCTNhMhZ+xcXczKjT4Aq6WFJx1QVEWJxu6p1h9ma6nhK9lJR42L1/Mi0XI3es67Z+ wSvcHD/1LFw2yxwpjRGGcb0MDcOI1H3zmskBdA0Lt9r9qjZyyH2UHpzduin5nDwlOwwX qbsRrWM6Zng/gyhNAIKysxWxZevD7hD/XWSi4mFCeaP+RBao9n44/nmnHEQMBCWFL/nQ 7+/OpE8Sq8dmtjrJ87ldsgSszYqYv5/ykDaKriCnQgGg/kn9MXR1McRG4xuh57Aq27cv eJWMm7oVwRIDvpG2GdPAf3VkARumhePNJxPS034Tu2YKajsvjzYZoT4Ib7OhbMfzGV5u 1wjw== X-Gm-Message-State: APjAAAXmIwa2Sda3e3B+WMa/WRPgdi7zdtph1YxXnWQ75gwu6FNN8xRW MaLee8exYIUstDjeCH/JFlM6/lZFcjcouxp67RuxWLgm X-Google-Smtp-Source: APXvYqzsdEN41n/FGye/w2aX6bu4OibKVjMBTEiIbfaKjpGxStDk3FXWsg+wOxpzAixFkIj+CaSLkT+LSAE+HfN4PR4= X-Received: by 2002:a6b:2bcd:: with SMTP id r196mr6126994ior.73.1562093018135; Tue, 02 Jul 2019 11:43:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 2 Jul 2019 14:43:27 -0400 Message-ID: To: "A. Jean Mahoney" Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000073c035058cb71f0a" Archived-At: Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-digest-scheme, cont. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 18:43:48 -0000 --00000000000073c035058cb71f0a Content-Type: text/plain; charset="UTF-8" Thanks Jean! I submitted a new version that addresses most of these comments. See few replies below inline. Regards, Rifaat On Mon, Jul 1, 2019 at 3:30 PM A. Jean Mahoney wrote: > Hi Rifaat, > > Below are the rest of my Doc Shepherd review comments, mainly a few > minor issues and nits. I have a suggested rework of the Introduction to > clarify that MD5 is not collision resistant and that RFC3261 references > the RFC obsoleted by RFC7616. > > Thanks! > > Jean > > > General: There are some instances of "SIP protocol" and "HTTP protocol". > These should be replaced with either "SIP"/"HTTP" or "Session Initiation > Protocol"/"Hypertext Transfer Protocol". > > Abstract: Should explicitly mention that the document updates RFC 3261 > (idnits flagged this). Should mention that MD5 is still available for > backward availability. > > Introduction: Suggested rewording - > > The Session Initiation Protocol [RFC3261] uses the same mechanism > that the Hypertext Transfer Protocol (HTTP) uses for authenticating > users. This mechanism is called Digest Access Authentication, and > it is a simple challenge-response mechanism that allows a server > to challenge a client request and allows a client to provide > authentication information in response to that challenge. The > version of Digest Access Authentication that RFC 3261 references > is specified in [RFC2617]. > > The default hash algorithm for Digest Access Authentication is MD5. > However, it has been demonstrated that the MD5 algorithm is not > collision resistant, and is now considered a bad choice for a hash > function [RFC6151]. > > The HTTP Digest Access Authentication [RFC7616] document obsoletes > [RFC2617] and adds stronger algorithms that can be used with > the Digest Authentication scheme, and establishes a registry for > these algorithms, known as the "Hash Algorithms for HTTP Digest > Authentication" registry, so that algorithms can be added in the > future. > > This document updates the Digest Access Authentication scheme used > by SIP to support the algorithms listed in the "Hash Algorithms > for HTTP Digest Authentication" registry defined by [RFC7616]. > > > S2 p2: This section should also mention that the BNF for the URI > included in the challenge has been changed and now allows > more schemes than SIP and SIPS. > > I am not clear on this comment. The update to the BNF by this document does not change the schemes, only the algorithms. Can you elaborate on what you meant by this? > S2 p2: UAC and UAS should be expanded on first use. > > S2 p2: s/"qop" option/"qop" parameter > > S2.1 p2: s/any registered algorithm/any algorithm listed in > the "Hash Algorithms for HTTP Digest Authentication" > registry. > > S2.4 p1: Remove the space in "Proxy- Authenticate" > > S2.5 p1: s/introduces some clarification to that/clarifies that > > S2.5 p2: s/proxy to the UA./proxy to the UAC. > > S2.6: I suggest changing the title to "HTTP Digest Authentication > Scheme Modifications" to match better the section title > in RFC 3261. > > S2.6 p1: There is also a change to the BNF in bullet 1 that allows > more URI schemes, so "... specified in bullets, 1, 7 and 8." > > Bullet 1 does not introduce any new semantic changes, that is the reason it is not listed here. Regards, Rifaat > S2.6 p3: Add a reference to RFC7616 after HTTP. > > S2.6 #8: s/handle "qop"/handle the "qop" (occurs twice) > > S2.6 last p: s/continue/continues > > S2.7 p1: Insert a reference to [RFC5234] after "Augmented BNF". > > S3 p1: s/used to with/used with > > S4 p1: Add an explicit statement such as, "This document has > no actions for IANA." > > S6: Add references to RFC 5234 and RFC 6151. > > > --00000000000073c035058cb71f0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jean!

I submitt= ed a new version that addresses most of these comments.
See few r= eplies below inline.

Regards,
=C2=A0Rifa= at


On Mon, Jul 1, 2019 at 3:30 PM A. Jean Mahoney <<= a href=3D"mailto:mahoney@nostrum.com">mahoney@nostrum.com> wrote:
Hi Rifaat,

Below are the rest of my Doc Shepherd review comments, mainly a few
minor issues and nits. I have a suggested rework of the Introduction to clarify that MD5 is not collision resistant and that RFC3261 references the RFC obsoleted by RFC7616.

Thanks!

Jean


General: There are some instances of "SIP protocol" and "HTT= P protocol".
These should be replaced with either "SIP"/"HTTP" or &q= uot;Session Initiation
Protocol"/"Hypertext Transfer Protocol".

Abstract:=C2=A0 Should explicitly mention that the document updates RFC 326= 1
(idnits flagged this). Should mention that MD5 is still available for
backward availability.

Introduction:=C2=A0 Suggested rewording -

=C2=A0 =C2=A0 The Session Initiation Protocol [RFC3261] uses the same mecha= nism
=C2=A0 =C2=A0 that the Hypertext Transfer Protocol (HTTP) uses for authenti= cating
=C2=A0 =C2=A0 users. This mechanism is called Digest Access Authentication,= and
=C2=A0 =C2=A0 it is a simple challenge-response mechanism that allows a ser= ver
=C2=A0 =C2=A0 to challenge a client request and allows a client to provide<= br> =C2=A0 =C2=A0 authentication information in response to that challenge. The=
=C2=A0 =C2=A0 version of Digest Access Authentication that RFC 3261 referen= ces
=C2=A0 =C2=A0 is specified in [RFC2617].

=C2=A0 =C2=A0 The default hash algorithm for Digest Access Authentication i= s MD5.
=C2=A0 =C2=A0 However, it has been demonstrated that the MD5 algorithm is n= ot
=C2=A0 =C2=A0 collision resistant, and is now considered a bad choice for a= hash
=C2=A0 =C2=A0 function [RFC6151].

=C2=A0 =C2=A0 The HTTP Digest Access Authentication [RFC7616] document obso= letes
=C2=A0 =C2=A0 [RFC2617] and adds stronger algorithms that can be used with<= br> =C2=A0 =C2=A0 the Digest Authentication scheme, and establishes a registry = for
=C2=A0 =C2=A0 these algorithms, known as the "Hash Algorithms for HTTP= Digest
=C2=A0 =C2=A0 Authentication" registry, so that algorithms can be adde= d in the
=C2=A0 =C2=A0 future.

=C2=A0 =C2=A0 This document updates the Digest Access Authentication scheme= used
=C2=A0 =C2=A0 by SIP to support the algorithms listed in the "Hash Alg= orithms
=C2=A0 =C2=A0 for HTTP Digest Authentication" registry defined by [RFC= 7616].


S2 p2:=C2=A0 =C2=A0 This section should also mention that the BNF for the U= RI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0included in the challenge has been= changed and now allows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more schemes than SIP and SIPS.

I am not clear on this comment.
<= div>The update to the BNF by this document does not change the schemes, onl= y the algorithms.

Can you elaborate on what yo= u meant by this?

=C2=A0
S2 p2:=C2=A0 =C2=A0 UAC and UAS should be expanded on first use.

S2 p2:=C2=A0 =C2=A0 s/"qop" option/"qop" parameter

S2.1 p2:=C2=A0 s/any registered algorithm/any algorithm listed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the "Hash Algorithms for HTTP= Digest Authentication"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registry.

S2.4 p1:=C2=A0 Remove the space in "Proxy- Authenticate"

S2.5 p1:=C2=A0 s/introduces some clarification to that/clarifies that

S2.5 p2:=C2=A0 s/proxy to the UA./proxy to the UAC.

S2.6:=C2=A0 =C2=A0 =C2=A0I suggest changing the title to "HTTP Digest = Authentication
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Scheme Modifications" to matc= h better the section title
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in RFC 3261.

S2.6 p1:=C2=A0 There is also a change to the BNF in bullet 1 that allows =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more URI schemes, so "... spe= cified in bullets, 1, 7 and 8."

Bullet 1 does not introduce any new semantic changes,= that is the reason it is not listed here.

Regards= ,
=C2=A0Rifaat


=C2=A0
S2.6 p3:=C2=A0 Add a reference to RFC7616 after HTTP.

S2.6 #8:=C2=A0 s/handle "qop"/handle the "qop" (occurs = twice)

S2.6 last p: s/continue/continues

S2.7 p1:=C2=A0 Insert a reference to [RFC5234] after "Augmented BNF&qu= ot;.

S3 p1:=C2=A0 =C2=A0 s/used to with/used with

S4 p1:=C2=A0 =C2=A0 Add an explicit statement such as, "This document = has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no actions for IANA."

S6:=C2=A0 =C2=A0 =C2=A0 =C2=A0Add references to RFC 5234 and RFC 6151.


--00000000000073c035058cb71f0a-- From nobody Tue Jul 2 12:43:13 2019 Return-Path: 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 6E38C120708 for ; Tue, 2 Jul 2019 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 RCGrd_Q9UgV7 for ; Tue, 2 Jul 2019 12:43:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5ECBD1206F9 for ; Tue, 2 Jul 2019 12:43:09 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x62Jh56X023386 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jul 2019 14:43:06 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562096586; bh=zv9XInSHgtb9yUyGj2hmtpItKoUuzr8kyoXoytyANRw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ZXOITS5yvl+Wk7FnoCaTwPtOIfGL/r+2jsm4hb9QW6TQByu11w5UTm0SvuSmCMaUs bqFfP+4GpNt7+kKLdMm71Nx9fqjF0YXP94NENEIbweJnHZ5DJRWcvePuRM2fyRYE9Y kbOL/8QoOlv8Hy19xEG2S60fzS7PzpNS60w8HLN8= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: Rifaat Shekh-Yusef Cc: SIPCORE References: From: "A. Jean Mahoney" Message-ID: Date: Tue, 2 Jul 2019 14:43:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-digest-scheme, cont. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:43:12 -0000 Hi Rifaat, On 7/2/19 1:43 PM, Rifaat Shekh-Yusef wrote: > Thanks Jean! > > I submitted a new version that addresses most of these comments. > See few replies below inline. > > Regards, >  Rifaat > > > On Mon, Jul 1, 2019 at 3:30 PM A. Jean Mahoney > wrote: > > Hi Rifaat, > > Below are the rest of my Doc Shepherd review comments, mainly a few > minor issues and nits. I have a suggested rework of the Introduction to > clarify that MD5 is not collision resistant and that RFC3261 references > the RFC obsoleted by RFC7616. > > Thanks! > > Jean > > > General: There are some instances of "SIP protocol" and "HTTP > protocol". > These should be replaced with either "SIP"/"HTTP" or "Session > Initiation > Protocol"/"Hypertext Transfer Protocol". > > Abstract:  Should explicitly mention that the document updates RFC 3261 > (idnits flagged this). Should mention that MD5 is still available for > backward availability. > > Introduction:  Suggested rewording - > >     The Session Initiation Protocol [RFC3261] uses the same mechanism >     that the Hypertext Transfer Protocol (HTTP) uses for authenticating >     users. This mechanism is called Digest Access Authentication, and >     it is a simple challenge-response mechanism that allows a server >     to challenge a client request and allows a client to provide >     authentication information in response to that challenge. The >     version of Digest Access Authentication that RFC 3261 references >     is specified in [RFC2617]. > >     The default hash algorithm for Digest Access Authentication is MD5. >     However, it has been demonstrated that the MD5 algorithm is not >     collision resistant, and is now considered a bad choice for a hash >     function [RFC6151]. > >     The HTTP Digest Access Authentication [RFC7616] document obsoletes >     [RFC2617] and adds stronger algorithms that can be used with >     the Digest Authentication scheme, and establishes a registry for >     these algorithms, known as the "Hash Algorithms for HTTP Digest >     Authentication" registry, so that algorithms can be added in the >     future. > >     This document updates the Digest Access Authentication scheme used >     by SIP to support the algorithms listed in the "Hash Algorithms >     for HTTP Digest Authentication" registry defined by [RFC7616]. > > > S2 p2:    This section should also mention that the BNF for the URI >            included in the challenge has been changed and now allows >            more schemes than SIP and SIPS. > > > I am not clear on this comment. > The update to the BNF by this document does not change the schemes, only > the algorithms. I'm talking about the URI scheme used in the challenge. Originally (3261 and earlier versions of the digest-scheme draft), the URI included in the challenge had the following BNF: URI = SIP-URI / SIPS-URI Where: SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = "sips:" [ userinfo ] hostport uri-parameters [ headers ] In the current version, the BNF has been changed to the following: URI = Request-URI Where: Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme ":" ( hier-part / opaque-part ) scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) And other schemes can now be used, like TEL or IM or HTTP. It's a change that should be called out. Thanks! Jean > Can you elaborate on what you meant by this? > > S2 p2:    UAC and UAS should be expanded on first use. > > S2 p2:    s/"qop" option/"qop" parameter > > S2.1 p2:  s/any registered algorithm/any algorithm listed in >            the "Hash Algorithms for HTTP Digest Authentication" >            registry. > > S2.4 p1:  Remove the space in "Proxy- Authenticate" > > S2.5 p1:  s/introduces some clarification to that/clarifies that > > S2.5 p2:  s/proxy to the UA./proxy to the UAC. > > S2.6:     I suggest changing the title to "HTTP Digest Authentication >            Scheme Modifications" to match better the section title >            in RFC 3261. > > S2.6 p1:  There is also a change to the BNF in bullet 1 that allows >            more URI schemes, so "... specified in bullets, 1, 7 and 8." > > Bullet 1 does not introduce any new semantic changes, that is the reason > it is not listed here. > > Regards, >  Rifaat > > > S2.6 p3:  Add a reference to RFC7616 after HTTP. > > S2.6 #8:  s/handle "qop"/handle the "qop" (occurs twice) > > S2.6 last p: s/continue/continues > > S2.7 p1:  Insert a reference to [RFC5234] after "Augmented BNF". > > S3 p1:    s/used to with/used with > > S4 p1:    Add an explicit statement such as, "This document has >            no actions for IANA." > > S6:       Add references to RFC 5234 and RFC 6151. > > From nobody Tue Jul 2 12:56:52 2019 Return-Path: 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 419E3120748 for ; Tue, 2 Jul 2019 12:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LlH62YQBmDpB for ; Tue, 2 Jul 2019 12:56:39 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 D5640120789 for ; Tue, 2 Jul 2019 12:56:38 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id k20so13644762ios.10 for ; Tue, 02 Jul 2019 12:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=61dqhtkQnSn/a2s/8VXgwQMciDMZI/1ocbP48iP+5yU=; b=b/PL/NUsrZ7UCSKshrhFvNP5KtHPWxBTP8IRtUdyvkOBoBn0oMZwyg5x8hXtH+ItTa pqnUMBtTT7IG4D9ZvBX+0pF8Xi7GDr4ACuty0OAOOSzDicFGf6skayiBTGhd0c9T9qZS +kcI9umuYbQsDP9zR4If3JI6kgWoDVVZJjx3In8FjV4Bw2AGJccN7Epi9Pby+juJ+p0A J9B9b10QtnGj84iOSyDcX1M6Ryq51WCsp1lY96RRYP0w2L4LVp++RSxehTbnjqimxVDj KRfY+9wCFvO65kEIPzGNML07IV6xAopdj4D2A5L36YYoDf8yBG1i4u4r6c0fVJg2223x Y+YQ== 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=61dqhtkQnSn/a2s/8VXgwQMciDMZI/1ocbP48iP+5yU=; b=flxLt9aitsGalyioeMObRKA5naU+kYdfWPhun3lrGH5wRmCl2GICSlhK06rovwOGT3 39KxAJQuaiBWzaoHqLfAb2X5DRNGuRmGHnO4f3D52ansGinT65dAxhD6TbB1nxb/fXmq MTZjhY1gsn42IN19Zs3CMtjGlQSGhUBsyHqJWoRCVk3uXJwYVxd2kKXy/M0CRPlQX69c B3GQ7jYpycditwn3jPYZ6Yhfyy1WQLRJnDs/LX9ft9cC5BW25sOPB3aOzWOPErUlT4nL zZTd6qG58f1CMHN5Wquaq2WeT3IqLgdqcObArKwvRwMEgKbc3E606ULeQ3SREB83ku5o mceA== X-Gm-Message-State: APjAAAWx8zJ/nvbScTSpLy3RWCMDaWKkwbPvqAMjPHEpzyGR4dqTqY5C 1z8T65eRwM8ibFEnr7zdpWmjUe9mmwMPoGAtvqE= X-Google-Smtp-Source: APXvYqxs0CEFZOs2NwdU7oNdiJp2g3h6VQTYsk0FzUD43gLZukQ+vFtGtFkcwlgG+V/8V+G7X6XkNcxVLvmmQMiEeHQ= X-Received: by 2002:a6b:7401:: with SMTP id s1mr7600324iog.67.1562097398113; Tue, 02 Jul 2019 12:56:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 2 Jul 2019 15:56:27 -0400 Message-ID: To: "A. Jean Mahoney" Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000084eb76058cb824d7" Archived-At: Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-digest-scheme, cont. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:56:52 -0000 --00000000000084eb76058cb824d7 Content-Type: text/plain; charset="UTF-8" Hi Jean, I now understand your comment. The document does not define any new scheme; I changed to Request-URI to not prevent that from happening in the future. I agree that this should be added to the list of bullets that introduce semantic changes. I will fix that. Thanks, Rifaat On Tue, Jul 2, 2019 at 3:43 PM A. Jean Mahoney wrote: > Hi Rifaat, > > On 7/2/19 1:43 PM, Rifaat Shekh-Yusef wrote: > > Thanks Jean! > > > > I submitted a new version that addresses most of these comments. > > See few replies below inline. > > > > Regards, > > Rifaat > > > > > > On Mon, Jul 1, 2019 at 3:30 PM A. Jean Mahoney > > wrote: > > > > Hi Rifaat, > > > > Below are the rest of my Doc Shepherd review comments, mainly a few > > minor issues and nits. I have a suggested rework of the Introduction > to > > clarify that MD5 is not collision resistant and that RFC3261 > references > > the RFC obsoleted by RFC7616. > > > > Thanks! > > > > Jean > > > > > > General: There are some instances of "SIP protocol" and "HTTP > > protocol". > > These should be replaced with either "SIP"/"HTTP" or "Session > > Initiation > > Protocol"/"Hypertext Transfer Protocol". > > > > Abstract: Should explicitly mention that the document updates RFC > 3261 > > (idnits flagged this). Should mention that MD5 is still available for > > backward availability. > > > > Introduction: Suggested rewording - > > > > The Session Initiation Protocol [RFC3261] uses the same > mechanism > > that the Hypertext Transfer Protocol (HTTP) uses for > authenticating > > users. This mechanism is called Digest Access Authentication, > and > > it is a simple challenge-response mechanism that allows a server > > to challenge a client request and allows a client to provide > > authentication information in response to that challenge. The > > version of Digest Access Authentication that RFC 3261 references > > is specified in [RFC2617]. > > > > The default hash algorithm for Digest Access Authentication is > MD5. > > However, it has been demonstrated that the MD5 algorithm is not > > collision resistant, and is now considered a bad choice for a > hash > > function [RFC6151]. > > > > The HTTP Digest Access Authentication [RFC7616] document > obsoletes > > [RFC2617] and adds stronger algorithms that can be used with > > the Digest Authentication scheme, and establishes a registry for > > these algorithms, known as the "Hash Algorithms for HTTP Digest > > Authentication" registry, so that algorithms can be added in the > > future. > > > > This document updates the Digest Access Authentication scheme > used > > by SIP to support the algorithms listed in the "Hash Algorithms > > for HTTP Digest Authentication" registry defined by [RFC7616]. > > > > > > S2 p2: This section should also mention that the BNF for the URI > > included in the challenge has been changed and now allows > > more schemes than SIP and SIPS. > > > > > > I am not clear on this comment. > > The update to the BNF by this document does not change the schemes, only > > the algorithms. > > > I'm talking about the URI scheme used in the challenge. Originally (3261 > and earlier versions of the digest-scheme draft), the URI included in > the challenge had the following BNF: > > URI = SIP-URI / SIPS-URI > > Where: > > SIP-URI = "sip:" [ userinfo ] hostport > uri-parameters [ headers ] > > SIPS-URI = "sips:" [ userinfo ] hostport > uri-parameters [ headers ] > > > > In the current version, the BNF has been changed to the following: > > URI = Request-URI > > Where: > > Request-URI = SIP-URI / SIPS-URI / absoluteURI > > absoluteURI = scheme ":" ( hier-part / opaque-part ) > > scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) > > And other schemes can now be used, like TEL or IM or HTTP. It's a change > that should be called out. > > Thanks! > > Jean > > > > Can you elaborate on what you meant by this? > > > > S2 p2: UAC and UAS should be expanded on first use. > > > > S2 p2: s/"qop" option/"qop" parameter > > > > S2.1 p2: s/any registered algorithm/any algorithm listed in > > the "Hash Algorithms for HTTP Digest Authentication" > > registry. > > > > S2.4 p1: Remove the space in "Proxy- Authenticate" > > > > S2.5 p1: s/introduces some clarification to that/clarifies that > > > > S2.5 p2: s/proxy to the UA./proxy to the UAC. > > > > S2.6: I suggest changing the title to "HTTP Digest Authentication > > Scheme Modifications" to match better the section title > > in RFC 3261. > > > > S2.6 p1: There is also a change to the BNF in bullet 1 that allows > > more URI schemes, so "... specified in bullets, 1, 7 and > 8." > > > > Bullet 1 does not introduce any new semantic changes, that is the reason > > it is not listed here. > > > > Regards, > > Rifaat > > > > > > S2.6 p3: Add a reference to RFC7616 after HTTP. > > > > S2.6 #8: s/handle "qop"/handle the "qop" (occurs twice) > > > > S2.6 last p: s/continue/continues > > > > S2.7 p1: Insert a reference to [RFC5234] after "Augmented BNF". > > > > S3 p1: s/used to with/used with > > > > S4 p1: Add an explicit statement such as, "This document has > > no actions for IANA." > > > > S6: Add references to RFC 5234 and RFC 6151. > > > > > --00000000000084eb76058cb824d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jean,

I now understand your comment.=

The document does not define any new scheme; I ch= anged to Request-URI to not prevent that from happening in the=C2=A0future.=

I agree that this should be added to the list of = bullets that introduce semantic changes. I will fix that.

Thanks,
=C2=A0Rifaat


On Tue, Jul 2, 2= 019 at 3:43 PM A. Jean Mahoney <m= ahoney@nostrum.com> wrote:
Hi Rifaat,

On 7/2/19 1:43 PM, Rifaat Shekh-Yusef wrote:
> Thanks Jean!
>
> I submitted a new version that addresses most of these comments.
> See few replies below inline.
>
> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
> On Mon, Jul 1, 2019 at 3:30 PM A. Jean Mahoney <mahoney@nostrum.com
> <mailto:ma= honey@nostrum.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Rifaat,
>
>=C2=A0 =C2=A0 =C2=A0Below are the rest of my Doc Shepherd review commen= ts, mainly a few
>=C2=A0 =C2=A0 =C2=A0minor issues and nits. I have a suggested rework of= the Introduction to
>=C2=A0 =C2=A0 =C2=A0clarify that MD5 is not collision resistant and tha= t RFC3261 references
>=C2=A0 =C2=A0 =C2=A0the RFC obsoleted by RFC7616.
>
>=C2=A0 =C2=A0 =C2=A0Thanks!
>
>=C2=A0 =C2=A0 =C2=A0Jean
>
>
>=C2=A0 =C2=A0 =C2=A0General: There are some instances of "SIP prot= ocol" and "HTTP
>=C2=A0 =C2=A0 =C2=A0protocol".
>=C2=A0 =C2=A0 =C2=A0These should be replaced with either "SIP"= ;/"HTTP" or "Session
>=C2=A0 =C2=A0 =C2=A0Initiation
>=C2=A0 =C2=A0 =C2=A0Protocol"/"Hypertext Transfer Protocol&qu= ot;.
>
>=C2=A0 =C2=A0 =C2=A0Abstract:=C2=A0 Should explicitly mention that the = document updates RFC 3261
>=C2=A0 =C2=A0 =C2=A0(idnits flagged this). Should mention that MD5 is s= till available for
>=C2=A0 =C2=A0 =C2=A0backward availability.
>
>=C2=A0 =C2=A0 =C2=A0Introduction:=C2=A0 Suggested rewording -
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Session Initiation Protocol [RFC= 3261] uses the same mechanism
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that the Hypertext Transfer Protocol= (HTTP) uses for authenticating
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 users. This mechanism is called Dige= st Access Authentication, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it is a simple challenge-response me= chanism that allows a server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to challenge a client request and al= lows a client to provide
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authentication information in respon= se to that challenge. The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 version of Digest Access Authenticat= ion that RFC 3261 references
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is specified in [RFC2617].
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The default hash algorithm for Diges= t Access Authentication is MD5.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 However, it has been demonstrated th= at the MD5 algorithm is not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collision resistant, and is now cons= idered a bad choice for a hash
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 function [RFC6151].
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The HTTP Digest Access Authenticatio= n [RFC7616] document obsoletes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC2617] and adds stronger algorith= ms that can be used with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the Digest Authentication scheme, an= d establishes a registry for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 these algorithms, known as the "= ;Hash Algorithms for HTTP Digest
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication" registry, so th= at algorithms can be added in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 future.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This document updates the Digest Acc= ess Authentication scheme used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 by SIP to support the algorithms lis= ted in the "Hash Algorithms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for HTTP Digest Authentication"= registry defined by [RFC7616].
>
>
>=C2=A0 =C2=A0 =C2=A0S2 p2:=C2=A0 =C2=A0 This section should also mentio= n that the BNF for the URI
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0included = in the challenge has been changed and now allows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more sche= mes than SIP and SIPS.
>
>
> I am not clear on this comment.
> The update to the BNF by this document does not change the schemes, on= ly
> the algorithms.


I'm talking about the URI scheme used in the challenge. Originally (326= 1
and earlier versions of the digest-scheme draft), the URI included in
the challenge had the following BNF:

=C2=A0 =C2=A0 URI=C2=A0 =3D=C2=A0 SIP-URI / SIPS-URI

Where:

=C2=A0 =C2=A0 SIP-URI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=C2=A0 "sip= :" [ userinfo ] hostport
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uri-parameters [ headers ]

=C2=A0 =C2=A0 SIPS-URI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 "sip= s:" [ userinfo ] hostport
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 uri-parameters [ headers ]



In the current version, the BNF has been changed to the following:

=C2=A0 =C2=A0 URI =3D Request-URI

Where:

=C2=A0 =C2=A0 Request-URI=C2=A0 =C2=A0 =3D=C2=A0 SIP-URI / SIPS-URI / absol= uteURI

=C2=A0 =C2=A0 absoluteURI=C2=A0 =C2=A0 =3D=C2=A0 scheme ":" ( hie= r-part / opaque-part )

=C2=A0 =C2=A0 scheme=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=C2=A0 ALPHA *( AL= PHA / DIGIT / "+" / "-" / "." )

And other schemes can now be used, like TEL or IM or HTTP. It's a chang= e
that should be called out.

Thanks!

Jean


> Can you elaborate on what you meant by this?
>
>=C2=A0 =C2=A0 =C2=A0S2 p2:=C2=A0 =C2=A0 UAC and UAS should be expanded = on first use.
>
>=C2=A0 =C2=A0 =C2=A0S2 p2:=C2=A0 =C2=A0 s/"qop" option/"= qop" parameter
>
>=C2=A0 =C2=A0 =C2=A0S2.1 p2:=C2=A0 s/any registered algorithm/any algor= ithm listed in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the "= ;Hash Algorithms for HTTP Digest Authentication"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registry.=
>
>=C2=A0 =C2=A0 =C2=A0S2.4 p1:=C2=A0 Remove the space in "Proxy- Aut= henticate"
>
>=C2=A0 =C2=A0 =C2=A0S2.5 p1:=C2=A0 s/introduces some clarification to t= hat/clarifies that
>
>=C2=A0 =C2=A0 =C2=A0S2.5 p2:=C2=A0 s/proxy to the UA./proxy to the UAC.=
>
>=C2=A0 =C2=A0 =C2=A0S2.6:=C2=A0 =C2=A0 =C2=A0I suggest changing the tit= le to "HTTP Digest Authentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Scheme Mo= difications" to match better the section title
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in RFC 32= 61.
>
>=C2=A0 =C2=A0 =C2=A0S2.6 p1:=C2=A0 There is also a change to the BNF in= bullet 1 that allows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more URI = schemes, so "... specified in bullets, 1, 7 and 8."
>
> Bullet 1 does not introduce any new semantic changes, that is the reas= on
> it is not listed here.
>
> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
>=C2=A0 =C2=A0 =C2=A0S2.6 p3:=C2=A0 Add a reference to RFC7616 after HTT= P.
>
>=C2=A0 =C2=A0 =C2=A0S2.6 #8:=C2=A0 s/handle "qop"/handle the = "qop" (occurs twice)
>
>=C2=A0 =C2=A0 =C2=A0S2.6 last p: s/continue/continues
>
>=C2=A0 =C2=A0 =C2=A0S2.7 p1:=C2=A0 Insert a reference to [RFC5234] afte= r "Augmented BNF".
>
>=C2=A0 =C2=A0 =C2=A0S3 p1:=C2=A0 =C2=A0 s/used to with/used with
>
>=C2=A0 =C2=A0 =C2=A0S4 p1:=C2=A0 =C2=A0 Add an explicit statement such = as, "This document has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no action= s for IANA."
>
>=C2=A0 =C2=A0 =C2=A0S6:=C2=A0 =C2=A0 =C2=A0 =C2=A0Add references to RFC= 5234 and RFC 6151.
>
>
--00000000000084eb76058cb824d7-- From nobody Wed Jul 3 05:33:43 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02885120072; Wed, 3 Jul 2019 05:33:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156215722196.14772.15398349306470111530@ietfa.amsl.com> Date: Wed, 03 Jul 2019 05:33:42 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:33:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : The Session Initiation Protocol (SIP) Digest Authentication Scheme Author : Rifaat Shekh-Yusef Filename : draft-ietf-sipcore-digest-scheme-07.txt Pages : 9 Date : 2019-07-03 Abstract: This document updates [RFC3261] by updating the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the broken MD5 algorithm, which might be used for backward compatibility reasons only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-07 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 3 05:37:19 2019 Return-Path: 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 40CCC120072 for ; Wed, 3 Jul 2019 05:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 t-ab--JEYD6L for ; Wed, 3 Jul 2019 05:37:15 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 30A811201D1 for ; Wed, 3 Jul 2019 05:37:15 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id k8so4421433iot.1 for ; Wed, 03 Jul 2019 05:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CRJo7vOg+pGhDupHeDZa3lnqSQTXGCxZQ65UgAupUwM=; b=eEQS7Iq9wPtoQsw9WjtApScHQFV2fhUVXmll83nLwVVWk8m9Zn7i0BraGiDjFZYdK2 kj5ERupo047pdSXr3y1DyuuZl9s97VVPaL8MzPA593pTqYUOEs4eFKIlh6lOBxhWi0xv 3HDhr9R+n6j5U9yNx79UBTa4WSgwBt9LZWQhC4n16muMQwDCL0iHtnpbwoc+8dlaInB2 FpUyjIhMtQpw731GFaGp/z6l0b4TmDnvOzdxHQtPln1mFA1ch+ofogxdtAcocezUjETE CLfoBjl9QOjfuBA84u+I3R0j0bdSyTDoHyY+FRyw2K/jHi5Ym7a+bkApCmu9XhLQTkal i6ug== 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; bh=CRJo7vOg+pGhDupHeDZa3lnqSQTXGCxZQ65UgAupUwM=; b=YAidLTUgZ0HgAOku09Ml6MRTye5jlHGzaDb8wD0V9d+EMAXGd3GmgseyfBVfIWIjh3 7yP3Xi0S70NUPvai0P1IcA/1L7V5RTfT/2IpvAiZaIggk2kqGoQVmikplmLVQFO/x7S0 rmGZBrNkPk77VbPM40MCYi//BtiXhNhVx+4elISopOiC0cIVQg0oUhqdzxoRnraJS5zO iznxso8EbZfo11/e/BBhvavH1voaWqUeHAhRt+ezYDaOJ/RhitAHQ0+Z0bLBwPtSbBrs pLWMnK9GPSC/0gY5L0SFyvb0Cs/ZPc82Ei+bnP6CoNo6lx1OuNWSVlmR1cGeTan7XH/k V8xQ== X-Gm-Message-State: APjAAAXDnOybHcOzqnlTuUmUKP6ylPe6bWTgEK2VlMp7nqNryxs7Ql2Q UyRIrQ9T+4y41DcFf+y8VwsahxxEfajwWftGRJi41sHJ X-Google-Smtp-Source: APXvYqwMIyYGJrmfu/pn6t0rvV+QwyjhvjyYvI1t1VoC9JOgzu4ODrOe/emzFUdstX4OMaOpX0Qy/kt1C2guhCC7SwQ= X-Received: by 2002:a6b:e608:: with SMTP id g8mr10856214ioh.88.1562157434256; Wed, 03 Jul 2019 05:37:14 -0700 (PDT) MIME-Version: 1.0 References: <156215722196.14772.15398349306470111530@ietfa.amsl.com> In-Reply-To: <156215722196.14772.15398349306470111530@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Wed, 3 Jul 2019 08:37:03 -0400 Message-ID: To: SIPCORE , "A. Jean Mahoney" Content-Type: multipart/alternative; boundary="000000000000f3c168058cc61e76" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 12:37:17 -0000 --000000000000f3c168058cc61e76 Content-Type: text/plain; charset="UTF-8" Hi Jean, Thanks you again for the detailed review, comments, and suggested text. I believe that with this version I have addressed all your comments; can you please take a look and let me know what you think? Thanks, Rifaat On Wed, Jul 3, 2019 at 8:33 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG of > the IETF. > > Title : The Session Initiation Protocol (SIP) Digest > Authentication Scheme > Author : Rifaat Shekh-Yusef > Filename : draft-ietf-sipcore-digest-scheme-07.txt > Pages : 9 > Date : 2019-07-03 > > Abstract: > This document updates [RFC3261] by updating the Digest Access > Authentication scheme used by the Session Initiation Protocol (SIP) > to add support for more secure digest algorithms, e.g. SHA-256 and > SHA-512-256, to replace the broken MD5 algorithm, which might be used > for backward compatibility reasons only. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000f3c168058cc61e76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jean,

Thanks you again for the detai= led review, comments, and suggested text.
I believe that with thi= s version I have addressed all your comments; can you please take a look an= d let me know what you think?

Thanks,
= =C2=A0Rifaat


On Wed, Jul 3, 2019 at 8:33 AM <internet-drafts@ietf.org> wrote= :

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core WG of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The Session Initiation Protocol (SIP) Digest Authentication Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Rifa= at Shekh-Yusef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sipcore-digest-scheme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-07-03

Abstract:
=C2=A0 =C2=A0This document updates [RFC3261] by updating the Digest Access<= br> =C2=A0 =C2=A0Authentication scheme used by the Session Initiation Protocol = (SIP)
=C2=A0 =C2=A0to add support for more secure digest algorithms, e.g.=C2=A0 S= HA-256 and
=C2=A0 =C2=A0SHA-512-256, to replace the broken MD5 algorithm, which might = be used
=C2=A0 =C2=A0for backward compatibility reasons only.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/d= raft-ietf-sipcore-digest-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-iet= f-sipcore-digest-scheme-07
https://datatracker.ietf.or= g/doc/html/draft-ietf-sipcore-digest-scheme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-sipcore-digest-scheme-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000f3c168058cc61e76-- From nobody Wed Jul 3 14:31:48 2019 Return-Path: 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 B0127120168 for ; Wed, 3 Jul 2019 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 q0snwkeG9Shn for ; Wed, 3 Jul 2019 14:31:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A73811200DB for ; Wed, 3 Jul 2019 14:31:44 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x63LVfxB067759 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Jul 2019 16:31:42 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562189502; bh=3HJVOrU7FsSOL39PW1nvt8Q1eVkBYubauV8/8TSgSQA=; h=Subject:To:References:From:Date:In-Reply-To; b=NOkdkzorKHABp22tU/w6F4beM/M+Yyis01WC8bcmplZqGR9HS45szBAa7xAeYylLX g8XNyJ9KRj1aH6w/QrMiwNw+IsuGKn6llYDfonjjeGKr3Zn2abLqfkcYKytLMsZ1RC pmNQCJVdogP1gph0fGI/1e4LhjMMHHwnlFCFQ+5Q= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: Rifaat Shekh-Yusef , SIPCORE References: <156215722196.14772.15398349306470111530@ietfa.amsl.com> From: "A. Jean Mahoney" Message-ID: <489f5d92-aa74-b59e-81bf-2819feb453e2@nostrum.com> Date: Wed, 3 Jul 2019 16:31:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 21:31:47 -0000 Hi Rifaat, Thanks for incorporating the feedback! Just two tiny nits left - Although idnits wants the Abstract to mention which RFC is being updated, it doesn't like the [RFCNNNN] reference format, so s/[RFC3261]/RFC 3261. S2.7 heading: remove "the" I will upload my Doc Shepherd write-up. Jean On 7/3/19 7:37 AM, Rifaat Shekh-Yusef wrote: > Hi Jean, > > Thanks you again for the detailed review, comments, and suggested text. > I believe that with this version I have addressed all your comments; can > you please take a look and let me know what you think? > > Thanks, >  Rifaat > > > On Wed, Jul 3, 2019 at 8:33 AM > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG > of the IETF. > >         Title           : The Session Initiation Protocol (SIP) > Digest Authentication Scheme >         Author          : Rifaat Shekh-Yusef >         Filename        : draft-ietf-sipcore-digest-scheme-07.txt >         Pages           : 9 >         Date            : 2019-07-03 > > Abstract: >    This document updates [RFC3261] by updating the Digest Access >    Authentication scheme used by the Session Initiation Protocol (SIP) >    to add support for more secure digest algorithms, e.g.  SHA-256 and >    SHA-512-256, to replace the broken MD5 algorithm, which might be > used >    for backward compatibility reasons only. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Jul 3 14:39:01 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5F8120100; Wed, 3 Jul 2019 14:38:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156218993399.14631.7077373119495881195@ietfa.amsl.com> Date: Wed, 03 Jul 2019 14:38:54 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 21:38:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : The Session Initiation Protocol (SIP) Digest Authentication Scheme Author : Rifaat Shekh-Yusef Filename : draft-ietf-sipcore-digest-scheme-08.txt Pages : 9 Date : 2019-07-03 Abstract: This document updates RFC 3261 by updating the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g. SHA-256 and SHA-512-256, to replace the broken MD5 algorithm, which might be used for backward compatibility reasons only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-08 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 3 14:40:54 2019 Return-Path: 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 11EE4120100 for ; Wed, 3 Jul 2019 14:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4x4vo9jZugSk for ; Wed, 3 Jul 2019 14:40:49 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 C49F61200DB for ; Wed, 3 Jul 2019 14:40:49 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id s7so8433794iob.11 for ; Wed, 03 Jul 2019 14:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oK20yFX1SB1XaAwEXlEmV8QatGB5WN66C9g+nv0jBaw=; b=GWfOFfxL3Q1Mf3ddyd4p3lt4MH1TenlV10wEVtcj7Fo4kHuFSqPqpfYv09YWVYQ9QU 2pF/8m34S80bobBZepEbYj3lEHpNVHwiEaLMQ7Z91/mFdbhFAWtfai83HpxJbiZD6n+4 FNovsfTsVOssfQygM5j2cBBZn7Yyt5vVm3QZC1xHvg5GT7Tx/aSnVn3R8KH+c3AX+l68 o7ukw40ExVMqKlGy/xhUv/KDTj8r5vHlWhUVPbxIneFQc0NUjgU/kD5MSGWzLtr8vBxH ihN+5AVUfi/RFhkNmUjxhsaERi9BCZEY6nRoyATUq4zkNQ339Fkus5XHSPBaTCwroiBN 6NWA== 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=oK20yFX1SB1XaAwEXlEmV8QatGB5WN66C9g+nv0jBaw=; b=LgXMFH4PARPsERdJQwQcaYt/v4Fkx6oz2cB72IKF2yDqp+eks9KKmGtbpDM0j73JuT 3LfgMGiLikhSVIL3954dgqGWPQWdbHzpKDN7oPg/HJOPfv/TW1i/WdkKbwBLGZr7rrRX P/2GvjeXHk1K7dijIPMQm06N1rteYvDZAbycjssTZFKG879sPY4PytcEcoRV5LckhrYM ghawwKjrNxR3evVj2IBW8v1O2ONLCvY90cN+KGzO0Tlj//3bN0I2vt1/178MYXoGzO+I MIQP+yl9kSXXiYya8lMhYRHsq2GtZPYgFP+W4lKWpp7okCGdn8mTWab+XqHVMe9LLIDN LS9g== X-Gm-Message-State: APjAAAXLbyyg7hbGHK2g3AE6v0TZlm6nL/o7uXLlIDkEQAppmeF5uKKf ES4rnrLNH4J9VMBjEsP44KWSeTZq2NYl+mX/gmIOrA== X-Google-Smtp-Source: APXvYqzZQPyH/aw8rUEAEkiti96HONQXQNQLWUH9Mx30wfrN5mIlEoZPdBUr93IAooisK5hu7kKRUsoitBPabQ4703I= X-Received: by 2002:a6b:9257:: with SMTP id u84mr10814441iod.278.1562190049065; Wed, 03 Jul 2019 14:40:49 -0700 (PDT) MIME-Version: 1.0 References: <156215722196.14772.15398349306470111530@ietfa.amsl.com> <489f5d92-aa74-b59e-81bf-2819feb453e2@nostrum.com> In-Reply-To: <489f5d92-aa74-b59e-81bf-2819feb453e2@nostrum.com> From: Rifaat Shekh-Yusef Date: Wed, 3 Jul 2019 17:40:38 -0400 Message-ID: To: "A. Jean Mahoney" Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000f23def058ccdb6df" Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 21:40:53 -0000 --000000000000f23def058ccdb6df Content-Type: text/plain; charset="UTF-8" Thanks Jean, I have just submitted a new version with these changes. Regards, Rifaat On Wed, Jul 3, 2019 at 5:31 PM A. Jean Mahoney wrote: > Hi Rifaat, > > Thanks for incorporating the feedback! Just two tiny nits left - > > Although idnits wants the Abstract to mention which RFC is being > updated, it doesn't like the [RFCNNNN] reference format, so > s/[RFC3261]/RFC 3261. > > S2.7 heading: remove "the" > > > I will upload my Doc Shepherd write-up. > > Jean > > > > On 7/3/19 7:37 AM, Rifaat Shekh-Yusef wrote: > > Hi Jean, > > > > Thanks you again for the detailed review, comments, and suggested text. > > I believe that with this version I have addressed all your comments; can > > you please take a look and let me know what you think? > > > > Thanks, > > Rifaat > > > > > > On Wed, Jul 3, 2019 at 8:33 AM > > wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Session Initiation Protocol Core WG > > of the IETF. > > > > Title : The Session Initiation Protocol (SIP) > > Digest Authentication Scheme > > Author : Rifaat Shekh-Yusef > > Filename : draft-ietf-sipcore-digest-scheme-07.txt > > Pages : 9 > > Date : 2019-07-03 > > > > Abstract: > > This document updates [RFC3261] by updating the Digest Access > > Authentication scheme used by the Session Initiation Protocol > (SIP) > > to add support for more secure digest algorithms, e.g. SHA-256 > and > > SHA-512-256, to replace the broken MD5 algorithm, which might be > > used > > for backward compatibility reasons only. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-07 > > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-07 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-07 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org > > . > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000f23def058ccdb6df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jean,

I have just submitted a new version with these=C2=A0changes.
=

Regards,
=C2=A0Rifaat

On Wed, J= ul 3, 2019 at 5:31 PM A. Jean Mahoney <mahoney@nostrum.com> wrote:
Hi Rifaat,

Thanks for incorporating the feedback! Just two tiny nits left -

Although idnits wants the Abstract to mention which RFC is being
updated, it doesn't like the [RFCNNNN] reference format, so
s/[RFC3261]/RFC 3261.

S2.7 heading: remove "the"


I will upload my Doc Shepherd write-up.

Jean



On 7/3/19 7:37 AM, Rifaat Shekh-Yusef wrote:
> Hi Jean,
>
> Thanks you again for the detailed review, comments, and suggested text= .
> I believe that with this version I have addressed all your comments; c= an
> you please take a look and let me know what you think?
>
> Thanks,
>=C2=A0 =C2=A0Rifaat
>
>
> On Wed, Jul 3, 2019 at 8:33 AM <internet-drafts@ietf.org
> <mailto:internet-drafts@ietf.org>> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0A New Internet-Draft is available from the on-line = Internet-Drafts
>=C2=A0 =C2=A0 =C2=A0directories.
>=C2=A0 =C2=A0 =C2=A0This draft is a work item of the Session Initiation= Protocol Core WG
>=C2=A0 =C2=A0 =C2=A0of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: The Session Initiation Protocol (SIP)
>=C2=A0 =C2=A0 =C2=A0Digest Authentication Scheme
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : Rifaat Shekh-Yusef
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 = =C2=A0 =C2=A0 : draft-ietf-sipcore-digest-scheme-07.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: 9
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : 2019-07-03
>
>=C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document updates [RFC3261] by up= dating the Digest Access
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authentication scheme used by the Ses= sion Initiation Protocol (SIP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to add support for more secure digest= algorithms, e.g.=C2=A0 SHA-256 and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHA-512-256, to replace the broken MD= 5 algorithm, which might be
>=C2=A0 =C2=A0 =C2=A0used
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for backward compatibility reasons on= ly.
>
>
>=C2=A0 =C2=A0 =C2=A0The IETF datatracker status page for this draft is:=
>=C2=A0 =C2=A0 =C2=A0https://da= tatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/
>
>=C2=A0 =C2=A0 =C2=A0There are also htmlized versions available at:
>=C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-sipcore-digest-scheme-07
>=C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-07<= br> >
>=C2=A0 =C2=A0 =C2=A0A diff from the previous version is available at: >=C2=A0 =C2=A0 =C2=A0https= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-digest-scheme-07
>
>
>=C2=A0 =C2=A0 =C2=A0Please note that it may take a couple of minutes fr= om the time of
>=C2=A0 =C2=A0 =C2=A0submission
>=C2=A0 =C2=A0 =C2=A0until the htmlized version and diff are available a= t to= ols.ietf.org
>=C2=A0 =C2=A0 =C2=A0<http://tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0Internet-Drafts are also available by anonymous FTP= at:
>=C2=A0 =C2=A0 =C2=A0ftp://ftp.ietf.org/internet-drafts/ >
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0sipcore mailing list
>=C2=A0 =C2=A0 =C2=A0sipcore@ietf.org <mailto:sipcore@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/sipcore
>
--000000000000f23def058ccdb6df-- From nobody Wed Jul 3 14:58:52 2019 Return-Path: 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 3DE1A12065E for ; Wed, 3 Jul 2019 14:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 7juKues1fu-d for ; Wed, 3 Jul 2019 14:58:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 925EF120170 for ; Wed, 3 Jul 2019 14:58:44 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x63Lweqe071946 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Jul 2019 16:58:41 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562191122; bh=CKWBQhOpr0/7ay76jZS4qJ08TmuWZkE5zPHimx1ITzM=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=HeJnhKjEWrkS1ZBeMw9ZnTTj3TQGya+qPBOiq7kXqfbtSXq28avUwHT+ao61pdibw pbQVxkxzv1QKLl7YRaWuGtlfeVhoMes8GqGXoIFPVNeZAYrtifc+Nn+pcYjZa7l14I GkLr4ksu7sSC2gTpQkKb5I8nEVjuHQKZRBiRGejM= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: Rifaat Shekh-Yusef Cc: SIPCORE References: <156215722196.14772.15398349306470111530@ietfa.amsl.com> <489f5d92-aa74-b59e-81bf-2819feb453e2@nostrum.com> From: "A. Jean Mahoney" Message-ID: <602612a7-dc39-32a0-f709-e7d4cf147f7e@nostrum.com> Date: Wed, 3 Jul 2019 16:58:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 21:58:49 -0000 And I have uploaded the Doc Shepherd write-up https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/shepherdwriteup/ Thanks! Jean On 7/3/19 4:40 PM, Rifaat Shekh-Yusef wrote: > Thanks Jean, > > I have just submitted a new version with these changes. > > Regards, >  Rifaat > > > On Wed, Jul 3, 2019 at 5:31 PM A. Jean Mahoney > wrote: > > Hi Rifaat, > > Thanks for incorporating the feedback! Just two tiny nits left - > > Although idnits wants the Abstract to mention which RFC is being > updated, it doesn't like the [RFCNNNN] reference format, so > s/[RFC3261]/RFC 3261. > > S2.7 heading: remove "the" > > > I will upload my Doc Shepherd write-up. > > Jean > > > > On 7/3/19 7:37 AM, Rifaat Shekh-Yusef wrote: > > Hi Jean, > > > > Thanks you again for the detailed review, comments, and suggested > text. > > I believe that with this version I have addressed all your > comments; can > > you please take a look and let me know what you think? > > > > Thanks, > >   Rifaat > > > > > > On Wed, Jul 3, 2019 at 8:33 AM > > >> wrote: > > > > > >     A New Internet-Draft is available from the on-line > Internet-Drafts > >     directories. > >     This draft is a work item of the Session Initiation Protocol > Core WG > >     of the IETF. > > > >              Title           : The Session Initiation Protocol (SIP) > >     Digest Authentication Scheme > >              Author          : Rifaat Shekh-Yusef > >              Filename        : > draft-ietf-sipcore-digest-scheme-07.txt > >              Pages           : 9 > >              Date            : 2019-07-03 > > > >     Abstract: > >         This document updates [RFC3261] by updating the Digest Access > >         Authentication scheme used by the Session Initiation > Protocol (SIP) > >         to add support for more secure digest algorithms, e.g. > SHA-256 and > >         SHA-512-256, to replace the broken MD5 algorithm, which > might be > >     used > >         for backward compatibility reasons only. > > > > > >     The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ > > > >     There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-07 > > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-07 > > > >     A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-07 > > > > > >     Please note that it may take a couple of minutes from the time of > >     submission > >     until the htmlized version and diff are available at > tools.ietf.org > >     . > > > >     Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > >     _______________________________________________ > >     sipcore mailing list > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Wed Jul 3 15:04:27 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1639412016D; Wed, 3 Jul 2019 15:04:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jean Mahoney via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Jean Mahoney , sipcore@ietf.org, iesg-secretary@ietf.org, mahoney@nostrum.com, sipcore-chairs@ietf.org Message-ID: <156219146399.14734.12270383768060542247.idtracker@ietfa.amsl.com> Date: Wed, 03 Jul 2019 15:04:23 -0700 Archived-At: Subject: [sipcore] Publication has been requested for draft-ietf-sipcore-digest-scheme-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 22:04:24 -0000 Jean Mahoney has requested publication of draft-ietf-sipcore-digest-scheme-08 as Proposed Standard on behalf of the SIPCORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/ From nobody Sun Jul 7 04:17:00 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AA412007C; Sun, 7 Jul 2019 04:16:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156249821133.14592.1211919336596009446@ietfa.amsl.com> Date: Sun, 07 Jul 2019 04:16:51 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 11:16:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-02.txt Pages : 12 Date : 2019-07-07 Abstract: This document defines a mechanism for SIP, that is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to enable the delegation of the user authentication and SIP registration authorization to a dedicated third-party entity that is separate from the SIP network elements that provide the SIP service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 7 04:20:07 2019 Return-Path: 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 95A6B1200A1 for ; Sun, 7 Jul 2019 04:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ydf9EQNrTOgo for ; Sun, 7 Jul 2019 04:20:03 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 5354212007C for ; Sun, 7 Jul 2019 04:20:03 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id o9so12970285iom.3 for ; Sun, 07 Jul 2019 04:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GWjsIrUTG/3XFjWwzWbUzLITba9pJhSrPVZSIjsZFPs=; b=S9ZtDjTvsO1BCRzzEUGKhaTga491qPF5/5MEKbCwBOX/DqxvWwdHTw4iPi+wi9H3uq zrk0uEHDJhRCrFwcQg86EsLnC64PegmrHlV0V0iM6604+ifjQHARwdWDG3fKksliheyP 3xLdgU4HqXK6ZmTHMiwaYscMIIbnJEJHA5qz8zwqQEqqopaFbLASdTiqwP7irID6nOm6 0DZdwRo720HYCYtzlm6yd5sXN7oZ0ugZwjSpVWhSmagihNjCTCxcf/ZMlJCuiJxKXK4T sOPEIAmEkd/icn6UKi8x/2JRm/GIX7yjEZoY/tqqOW/OkvdZ72y9jIJ+SvuKHF8hMTDv nNUQ== 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; bh=GWjsIrUTG/3XFjWwzWbUzLITba9pJhSrPVZSIjsZFPs=; b=aPA44KKOLAKQ9A3VqFRof47WHXJWymgeGprNKXyYJx4mrGhzeN/Hv6TUkLv4eL3Z8H +qyCdI6FmN6vb2cnyzSw3zngnGdCksV9lJbE84qltpPHYSY7fV0ySb46XNgjSk7mpZ7g p7ObsolG5lmYV0/sikd/oORSo8Jd9iGVzjdQ7fKCxdn2ickGUAUgKnlci8zU9wdsbn4P Sr5MPxw6j3SZ8ih+IoJ1Ns/HVX+ndlkPaCMyStZjhrS9p8E8OVwSNpu3ywEJUJmdtSeu BiEVg5Uex0xQowk2Eh77cSx1EgiawcdeOO4e6vgtWCmQaH+S3OzqfDXkmof5T699jw8V DThw== X-Gm-Message-State: APjAAAX9Ngea0aQ3/izzReY+B+Mc+o53mT8/i/bNHw/mLJM6ZfftlTLN Lqe/PHlOXh4J1+MFRPFZqQcw3pXlgDBUwNDISeORxA== X-Google-Smtp-Source: APXvYqzSqoZavxkWovd/1wkDj1FfmyPlQpIbt41X2ESiTlSg12Xn97+xWZwSZv1YKLqUT7yW9NLSSzHoPbmPXxIUIic= X-Received: by 2002:a6b:e608:: with SMTP id g8mr103277ioh.88.1562498402288; Sun, 07 Jul 2019 04:20:02 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> In-Reply-To: <156249821133.14592.1211919336596009446@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Sun, 7 Jul 2019 07:19:52 -0400 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary="0000000000003b0750058d158236" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 11:20:06 -0000 --0000000000003b0750058d158236 Content-Type: text/plain; charset="UTF-8" All, We have submitted a new version of the document based on the feedback provided so far. Please, take a look at let us know what you think. Regards, Rifaat On Sun, Jul 7, 2019 at 7:18 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG of > the IETF. > > Title : Third-Party Token-based Authentication and > Authorization for Session Initiation Protocol (SIP) > Authors : Rifaat Shekh-Yusef > Christer Holmberg > Victor Pascual > Filename : draft-ietf-sipcore-sip-token-authnz-02.txt > Pages : 12 > Date : 2019-07-07 > > Abstract: > This document defines a mechanism for SIP, that is based on the OAuth > 2.0 and OpenID Connect Core 1.0 specifications, to enable the > delegation of the user authentication and SIP registration > authorization to a dedicated third-party entity that is separate from > the SIP network elements that provide the SIP service. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000003b0750058d158236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We have submitted a new= version of the document based on the feedback provided so far.
P= lease, take a look at let us know what you think.

= Regards,
=C2=A0Rifaat


On Sun, = Jul 7, 2019 at 7:18 AM <inte= rnet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Session Initiation Protocol Core WG of the= IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Third-Party Token-based Authentication and Authorization for Session Initi= ation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rifa= at Shekh-Yusef
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christer Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Victor Pascual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sipcore-sip-token-authnz-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 12
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-07-07

Abstract:
=C2=A0 =C2=A0This document defines a mechanism for SIP, that is based on th= e OAuth
=C2=A0 =C2=A02.0 and OpenID Connect Core 1.0 specifications, to enable the<= br> =C2=A0 =C2=A0delegation of the user authentication and SIP registration
=C2=A0 =C2=A0authorization to a dedicated third-party entity that is separa= te from
=C2=A0 =C2=A0the SIP network elements that provide the SIP service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-sipcore-sip-token-authnz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-sipcore-sip-token-authnz-02
https://datatracker.ietf= .org/doc/html/draft-ietf-sipcore-sip-token-authnz-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-sipcore-sip-token-authnz-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--0000000000003b0750058d158236-- From nobody Mon Jul 8 08:58:34 2019 Return-Path: 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 B9CE61201F1 for ; Mon, 8 Jul 2019 08:58:20 -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 eB7eJbt9FSVD for ; Mon, 8 Jul 2019 08:58:18 -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 92CB6120256 for ; Mon, 8 Jul 2019 08:58:17 -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 x68FwBAI031199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Jul 2019 11:58:11 -0400 To: Christer Holmberg , Rifaat Shekh-Yusef Cc: SIPCORE References: <156139527419.17457.15161486253539766732@ietfa.amsl.com> <52296dbb-f1b6-f34f-9c43-70add154562e@alum.mit.edu> <00c02b2f-1515-d0df-edc8-4d2c7ca63655@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Mon, 8 Jul 2019 11:58:11 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 15:58:28 -0000 Inline On 6/29/19 9:47 AM, Christer Holmberg wrote: > > Hi, > > ... > >>> And a more fleshed out >>> example that shows who puts up the UI to gather the needed info, what is >>> included in the prompt, what comes back, and what is done with it then. >>> Enough to relate it to real world experience. >>> >>> (AFAIK most real world experience is with web interfaces. For instance >>> when hitting restricted web sites that require a login from Google, >>> Facebook, Discus, etc. IIUC this could be much like that, including the >>> choice of which of those to use. So a use case like that would be great. >> >> I think UI related issues and authentication using 3rd party IdPs are really out of scope of this document. > > I agree. I agree that there shouldn't be anything normative about UI. But I think some text or examples showing how the signaling might interact with the UI would be helpful, so people can relate the mechanism to the real world. > ... > >>> Again, while it is probably true that SIP authentication is mostly used >>> with registrars, it is also possible for other servers to require >>> authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can >>> send a challenge. So the UA needs to be prepared for this and do the >>> right thing. >>> >>> Doing that right includes caching credentials and providing them >>> appropriately to avoid unnecessarily prompting the user too often. And >>> then preemptively sending credentials becomes an optimization to avoid >>> extra round trips. This of course is very important for REGISTER since >>> it at times is used very frequently as a keep-alive. But at the same >>> time one needs to have some security guidance on when it is appropriate >>> to send preemptively and when not. >> >> I will add text around this to indicate that non-REGISTER requests should always include the Access Token in the request. > > I don't think we shall do that. > > I think the token shall only be included in non-REGISTER requests only if such requests are being challenged (or, perhaps also based on local configuration), because otherwise the token may be sent to a non-trusted remote peer. +1 Thanks, Paul From nobody Mon Jul 8 09:57:30 2019 Return-Path: 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 8680D1202B7 for ; Mon, 8 Jul 2019 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, 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 OR9TUKngGqbt for ; Mon, 8 Jul 2019 09:57:15 -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 ED5601202F7 for ; Mon, 8 Jul 2019 09:56:06 -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 x68Gu4rb002736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 8 Jul 2019 12:56:04 -0400 To: sipcore@ietf.org References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Mon, 8 Jul 2019 12:56:04 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:57:29 -0000 On 7/7/19 7:19 AM, Rifaat Shekh-Yusef wrote: > All, > > We have submitted a new version of the document based on the feedback > provided so far. > Please, take a look at let us know what you think. This is better. I still have a few thoughts: * Regarding WWW-Authenticate: I believe it will how be possible for a server to support both Digest and Bearer. I think this means that the client can use either depending on what sort of credentials it or its user happen to know. I think it would be good to mention this. I guess in principle the client could return credentials for both. In that case, I don't know whether both must be valid or if it is sufficient for one to be valid. Perhaps we need to discuss that. (Presumably only credentials for a/the realm that the server supports are to be considered, with those for other realms being ignored.) * Regarding non-registration requests (and maybe registration requests too): The UA MUST NOT insert a token in a non-REGISTER request, unless the non-REGISTER request has been challenged, or the peer is considered a trusted entity. What is a trusted entity? In any case I think this is too strong. Once a request has been challenged the client knows this target wants the credentials. We certainly don't want to force every subsequent request to the same target to take two round trips, one without credentials and then one with. So the client needs to associate these credentials with this target, for awhile. But that begs the question of how long to retain this association. In the case of Digest, a nonce eventually expires and the old credentials fail and get forgotten and replaced by new ones. I guess the life cycle will be somewhat different for Bearer. This needs some thought and discussion. Thanks, Paul > Regards, >  Rifaat > > > > On Sun, Jul 7, 2019 at 7:18 AM > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core WG > of the IETF. > >         Title           : Third-Party Token-based Authentication > and Authorization for Session Initiation Protocol (SIP) >         Authors         : Rifaat Shekh-Yusef >                           Christer Holmberg >                           Victor Pascual >         Filename        : draft-ietf-sipcore-sip-token-authnz-02.txt >         Pages           : 12 >         Date            : 2019-07-07 > > Abstract: >    This document defines a mechanism for SIP, that is based on the > OAuth >    2.0 and OpenID Connect Core 1.0 specifications, to enable the >    delegation of the user authentication and SIP registration >    authorization to a dedicated third-party entity that is separate > from >    the SIP network elements that provide the SIP service. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02 > https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-02 > > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Jul 8 12:30:33 2019 Return-Path: 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 A4750120365 for ; Mon, 8 Jul 2019 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 aG8AiEOiCWmr for ; Mon, 8 Jul 2019 12:30:19 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470491203E1 for ; Mon, 8 Jul 2019 12:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=htHMDXmGvzEO13ZFX3ePYhW2h2xatmRYVeiB8ww0elk=; b=n5YT8Y6dByQf8I/wxY6wF15aBa3I9AXkWtCU1pfkrsIFWWgZVeBqmDOJYgKG2Bkb4K9njx5knv1BM6iepmy1BaXuqmX8a9zcwUjhW/HD5LX7/ctlXF1NejNOqYtjM8Ks0AbKJyZ7EFEqLfaVLsjvkD++hXfF+dRHE+pdKQ3pzAk= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB0954.eurprd07.prod.outlook.com (10.162.27.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.15; Mon, 8 Jul 2019 19:30:16 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Mon, 8 Jul 2019 19:30:16 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QA== Date: Mon, 8 Jul 2019 19:30:16 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [62.113.190.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5be8d2b-1de6-47e1-a32b-08d703dab4d0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB0954; x-ms-traffictypediagnostic: HE1PR07MB0954: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(376002)(346002)(366004)(199004)(189003)(51444003)(74316002)(7696005)(446003)(68736007)(53936002)(71200400001)(14444005)(71190400001)(81166006)(7736002)(9686003)(81156014)(229853002)(44832011)(486006)(55016002)(8676002)(33656002)(256004)(6116002)(11346002)(8936002)(25786009)(305945005)(6436002)(99286004)(476003)(66066001)(478600001)(86362001)(5660300002)(2501003)(14454004)(73956011)(110136005)(76116006)(26005)(52536014)(186003)(102836004)(66556008)(316002)(66476007)(66446008)(64756008)(66946007)(2171002)(6246003)(76176011)(3846002)(2906002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0954; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1CLY5SPR6cSasWqhbaGADrevM4HRjFLZ+z3nKrJUR5oh5AbKxSpC6KKDbPo5/Z9Opw6irs3ED93JhduDoRha1aJJqYYzai7cPCGCCPlLaioDrHOSoCTXE6W4+OdhCXpHVDdQcgyXRLgeDSzg7ixu2Pv7AiMcmumiDZD1na2TTx7XyXesuyHxqXb2WGV9mmtZvSqInrgwDKRYk3UbpsYAvNmJdqBBhwVSUQOWieq620ShN/8U7CyY3XI/QdIZx7X4mT9O00asjy1MxbQvtP4yeH4/3zHY34ydBFxGrVHwnIjWIAJVFpu1LmlLnecSo2oyffpG0w4CYagSvA3JSJqS4fW2116R5dN/AfuEEJ3H+5pQEM0GN2nLxt68VOWsAUISIqqG/N4+AeGFStkaUKtn5mrI3Vvq8NFA1yQKzyxLwto= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5be8d2b-1de6-47e1-a32b-08d703dab4d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 19:30:16.5921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0954 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 19:30:32 -0000 SGksDQoNCj4qIFJlZ2FyZGluZyBXV1ctQXV0aGVudGljYXRlOg0KPg0KPkkgYmVsaWV2ZSBpdCB3 aWxsIGhvdyBiZSBwb3NzaWJsZSBmb3IgYSBzZXJ2ZXIgdG8gc3VwcG9ydCBib3RoIERpZ2VzdCBh bmQgQmVhcmVyLiBJIHRoaW5rIHRoaXMgbWVhbnMgdGhhdCB0aGUgY2xpZW50IA0KPmNhbiB1c2Ug ZWl0aGVyIGRlcGVuZGluZyBvbiB3aGF0IHNvcnQgb2YgY3JlZGVudGlhbHMgaXQgb3IgaXRzIHVz ZXIgaGFwcGVuIHRvIGtub3cuDQo+DQo+SSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIG1lbnRp b24gdGhpcy4gSSBndWVzcyBpbiBwcmluY2lwbGUgdGhlIGNsaWVudCBjb3VsZCByZXR1cm4gY3Jl ZGVudGlhbHMgZm9yIGJvdGguIEluIHRoYXQgY2FzZSwgSSBkb24ndCANCj5rbm93IHdoZXRoZXIg Ym90aCBtdXN0IGJlIHZhbGlkIG9yIGlmIGl0IGlzIHN1ZmZpY2llbnQgZm9yIG9uZSB0byBiZSB2 YWxpZC4gDQo+UGVyaGFwcyB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhhdC4gKFByZXN1bWFibHkgb25s eSBjcmVkZW50aWFscyBmb3IgYS90aGUgcmVhbG0gdGhhdCB0aGUgc2VydmVyIHN1cHBvcnRzIGFy ZSB0byANCj5iZSBjb25zaWRlcmVkLCB3aXRoIHRob3NlIGZvciBvdGhlciByZWFsbXMgYmVpbmcg aWdub3JlZC4pDQoNCkkgdGhpbmsgdGhhdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgZHJh ZnQuIFRoZXJlIGNvdWxkIGJlIG11bHRpcGxlIHZhcmlhbnRzIG9mIG11bHRpcGxlIGNoYWxsZW5n ZXMuDQoNCkFuZCwgUkZDIDMyNjEgYWxyZWFkeSB0YWxrcyBnZW5lcmFsbHkgYWJvdXQgbXVsdGlw bGUgY2hhbGxlbmdlcy4gSSBkbyB0aGluayBzb21lIG9mIHRoZSAzMjYxIHRleHQgY291bGQgYmUg aW1wcm92ZWQgYW5kIGNsYXJpZmllZCwgYnV0IHRoYXQgc2hvdWxkIGJlIGRvbmUgYXMgYSBzZXBh cmF0ZSB0YXNrLg0KDQoNCj4qIFJlZ2FyZGluZyBub24tcmVnaXN0cmF0aW9uIHJlcXVlc3RzIChh bmQgbWF5YmUgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIHRvbyk6DQo+DQo+ICAgIFRoZSBVQSBNVVNU IE5PVCBpbnNlcnQgYSB0b2tlbiBpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0LCB1bmxlc3MgdGhl DQo+ICAgIG5vbi1SRUdJU1RFUiByZXF1ZXN0IGhhcyBiZWVuIGNoYWxsZW5nZWQsIG9yIHRoZSBw ZWVyIGlzIGNvbnNpZGVyZWQgYQ0KPiAgICB0cnVzdGVkIGVudGl0eS4NCj4NCj4gV2hhdCBpcyBh IHRydXN0ZWQgZW50aXR5Pw0KDQpJIGFza2VkIHRoYXQgdG8gYmUgYWRkZWQsIGJ1dCBpdCBjYW4g YmUgcmVtb3ZlZC4NCg0KPiBJbiBhbnkgY2FzZSBJIHRoaW5rIHRoaXMgaXMgdG9vIHN0cm9uZy4g T25jZSBhIHJlcXVlc3QgaGFzIGJlZW4gY2hhbGxlbmdlZCB0aGUgY2xpZW50IGtub3dzIHRoaXMg dGFyZ2V0IHdhbnRzIHRoZSBjcmVkZW50aWFscy4gDQo+IFdlIGNlcnRhaW5seSBkb24ndCB3YW50 IHRvIGZvcmNlIGV2ZXJ5IHN1YnNlcXVlbnQgcmVxdWVzdCB0byB0aGUgc2FtZSB0YXJnZXQgdG8g dGFrZSB0d28gcm91bmQgdHJpcHMsIG9uZSB3aXRob3V0IGNyZWRlbnRpYWxzIA0KPiBhbmQgdGhl biBvbmUgd2l0aC4gU28gdGhlIGNsaWVudCBuZWVkcyB0byBhc3NvY2lhdGUgdGhlc2UgY3JlZGVu dGlhbHMgd2l0aCB0aGlzIHRhcmdldCwgZm9yIGF3aGlsZS4gQnV0IHRoYXQgYmVncyB0aGUgcXVl c3Rpb24gb2YgDQo+IGhvdyBsb25nIHRvIHJldGFpbiB0aGlzIGFzc29jaWF0aW9uLiBJbiB0aGUg Y2FzZSBvZiBEaWdlc3QsIGEgbm9uY2UgZXZlbnR1YWxseSBleHBpcmVzIGFuZCB0aGUgb2xkIGNy ZWRlbnRpYWxzIGZhaWwgYW5kIGdldCBmb3Jnb3R0ZW4gDQo+IGFuZCByZXBsYWNlZCBieSBuZXcg b25lcy4gSSBndWVzcyB0aGUgbGlmZSBjeWNsZSB3aWxsIGJlIHNvbWV3aGF0IGRpZmZlcmVudCBm b3IgQmVhcmVyLiANCj4gVGhpcyBuZWVkcyBzb21lIHRob3VnaHQgYW5kIGRpc2N1c3Npb24uDQoN CkZyb20gYSBnZW5lcmljIHBlcnNwZWN0aXZlIEkgdGhpbmsgMzI2MSBzaG91bGQgZGVzY3JpYmUg aG93IGNyZWRlbnRpYWxzIGFyZSBwcm92aWRlZCBpbiBzdWJzZXF1ZW50IHJlcXVlc3RzLg0KDQpB cyBmYXIgYXMgdG9rZW5zIGFyZSBjb25jZXJuZWQsIEkgYW0gbm90IHN1cmUgaXQncyB3aXRoaW4g dGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgdG8gZGVmaW5lIHRoZSBsaWZldGltZSBvZiB0b2tlbiBj cmVkZW50aWFscywgYXMgdGhleSBhcmUgbm90IFNJUCBzcGVjaWZpYy4NCg0KSGF2aW5nIHNhaWQg dGhhdCwgSSBETyBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBjdXJyZW50IGNhbWUgb3V0IHRvbyBz dHJvbmcgLSBhbmQgd3Jvbmc6IG15IGludGVudGlvbiB3YXMgdG8gc2F5IHRoYXQgY3JlZGVudGlh bHMgZnJvbSBhIFJFR0lTVEVSIHJlcXVlc3QgYXJlIG5vdCBwbGFjZWQgaW4gYSBub24tUkVHSVNU RVIgcmVxdWVzdC4NCg0KQlVULCBpZiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0cyBnZXRzIGNoYWxs ZW5nZWQsIHdlIHNob3VsZCBhbGxvdyB0aGUgY2xpZW50IHRvIGluY2x1ZGUgdGhlIGNyZWRlbnRp YWxzIGluIHN1YnNlcXVlbnQgbm9uLVJFR0lTVEVSIHJlcXVlc3RzIC0gYXQgbGVhc3Qgd2l0aGlu IHRoZSBzYW1lIHNlc3Npb24gKGluIGNhc2Ugb2Ygc2Vzc2lvbiByZWxhdGVkIHJlcXVlc3RzKS4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Mon Jul 8 15:45:57 2019 Return-Path: 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 83518120048 for ; Mon, 8 Jul 2019 15:45:48 -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 ALdvwQaP0kZ4 for ; Mon, 8 Jul 2019 15:45:43 -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 3F3B5120335 for ; Mon, 8 Jul 2019 15:45:43 -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 x68MjbjD027745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Jul 2019 18:45:38 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> Date: Mon, 8 Jul 2019 18:45:37 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 22:45:56 -0000 On 7/8/19 3:30 PM, Christer Holmberg wrote: > Hi, > >> * Regarding WWW-Authenticate: >> >> I believe it will how be possible for a server to support both Digest and Bearer. I think this means that the client >> can use either depending on what sort of credentials it or its user happen to know. >> >> I think it would be good to mention this. I guess in principle the client could return credentials for both. In that case, I don't >> know whether both must be valid or if it is sufficient for one to be valid. >> Perhaps we need to discuss that. (Presumably only credentials for a/the realm that the server supports are to >> be considered, with those for other realms being ignored.) > > I think that is outside the scope of the draft. There could be multiple variants of multiple challenges. > > And, RFC 3261 already talks generally about multiple challenges. I do think some of the 3261 text could be improved and clarified, but that should be done as a separate task. While I agree in principle that this is in some sense independent of the individual schemes, Bearer is what pushes this from one to two, which is when the issue appears. So IMO it makes sense to say something about it here. Saying that it *ought* to be in 3261 is fine, but in practice that is simply saying that it isn't going to be considered at all. >> * Regarding non-registration requests (and maybe registration requests too): >> >> The UA MUST NOT insert a token in a non-REGISTER request, unless the >> non-REGISTER request has been challenged, or the peer is considered a >> trusted entity. >> >> What is a trusted entity? > > I asked that to be added, but it can be removed. > >> In any case I think this is too strong. Once a request has been challenged the client knows this target wants the credentials. >> We certainly don't want to force every subsequent request to the same target to take two round trips, one without credentials >> and then one with. So the client needs to associate these credentials with this target, for awhile. But that begs the question of >> how long to retain this association. In the case of Digest, a nonce eventually expires and the old credentials fail and get forgotten >> and replaced by new ones. I guess the life cycle will be somewhat different for Bearer. >> This needs some thought and discussion. > > From a generic perspective I think 3261 should describe how credentials are provided in subsequent requests. See my comment above on what ought to go in 3261. > As far as tokens are concerned, I am not sure it's within the scope of this draft to define the lifetime of token credentials, as they are not SIP specific. I'm not too much concerned with the *lifetime* of the token, since that will pretty much take care of itself. (When it exceeds its lifetime it will stop working.) But I suspect there might be security concerns here, and that they may be different from those that apply to Digest. It *may* be that it would be fine to include the token in every request, regardless of target - that doing so won't cause any security concerns. Conversely, that might not be so. IIUC, similar tokens are used for single-signon, so perhaps there are guidelines that can be repurposed for use here. But I think *something* needs to be said or else implementors won't know what to do and the result will be interop problems. > Having said that, I DO agree with you that the current came out too strong - and wrong: my intention was to say that credentials from a REGISTER request are not placed in a non-REGISTER request. > > BUT, if a non-REGISTER requests gets challenged, we should allow the client to include the credentials in subsequent non-REGISTER requests - at least within the same session (in case of session related requests). ISTM that is also too strong. If I used a token for REGISTER, and then I do something else (e.g., SUBSCRIBE) with the same server, then it should be fine to use it in other requests directed to the same server. And possibly to other servers as well. You seem to be assuming that credentials for registration are somehow different from credentials for other things. It is up to the servers in question to decide that, not this protocol document. Thanks, Paul From nobody Tue Jul 9 00:18:29 2019 Return-Path: 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 93AC8120326 for ; Tue, 9 Jul 2019 00:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 PZMmF4Yn2Yyp for ; Tue, 9 Jul 2019 00:18:23 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130057.outbound.protection.outlook.com [40.107.13.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299031203A8 for ; Tue, 9 Jul 2019 00:18:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EtFATVPdCU5F0Xnr7FO8VdY2Us66IWXT8IAVSJgWhnUSzs6sGlKqyVJalgv2Yt8CED8z8wFCWVYpPYhLVp8dxG6j1eUGQVS6T+ukfU1Bb2DOqT1DmLN88u6NAzAQ43rDb5KNgPjtVLkl4vcAqs44G4uoBIguBAH7XUr+bhSlQ31ecR4iqzfDUJzlcRjwIu1O+usanAsh5/PB9pYpPD1QsmmBfCgmcI2FA/UwL5Vo2t+ZdDTplBiA0tM8QzTusJzX1M5/WBjH45qomzcg/hUYxmy6D6/NTjo+3PRBSTAtpn5aqDVe7HDxRVz92Z2ppMaGtAyuMAYxs0mj1uZbMRXkYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MvdZ3j+o5foaWGQxpIy3Sz+3RhTlRfPYc4MeCKh9AUs=; b=EyzviIUBzYkepz97eVMaieNT15bpj//OrgZom33ksF1CVfDuHTGHonf938ryHqXbV+Ub8uG+BIysndkFcoo9qU/AtkhwiTR/eK5EIqoIly7W9ayYwT3njh3LiQDJTTX15QjZWqmghHFbdQ0eSCaIT5AG+dnmWbZvxFNbv+YtvYCCn4n6ObBPLtS61BDkhM1qsKJIgpbF5oL8zcIImSSkLzYnp4AVpTMu2tiFhtmHWIKyppgyfLMsqUP7QjW4i19tCsrTGJCVekzwsM52DLI/qGUYZdWGQib/htVf+aWfwEgI4FZ9f7g6IPIHbe1i3CNKcVV84ztGzg+92Yg/UNZbJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MvdZ3j+o5foaWGQxpIy3Sz+3RhTlRfPYc4MeCKh9AUs=; b=ErIfQI5o3Sw4Y2kj6JH8/jwB/B36SaHrHvAOhPhkR2f+d2C3wSuLoZzvf6ftCnmHOX50mLMi4sx4GK6qGn1jXiTM0S2f1dhBVf/qC4pFrUWFRqrLaidVqUR0i/l7+7kDtI/13BR036oad26yb2Ti95inqf5ZgEZRSm9+UjkAkac= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4332.eurprd07.prod.outlook.com (20.176.167.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.6; Tue, 9 Jul 2019 07:18:19 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 07:18:19 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgA= Date: Tue, 9 Jul 2019 07:18:18 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> In-Reply-To: <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [62.113.190.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad84d33b-0459-4403-81ea-08d7043d9e3e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4332; x-ms-traffictypediagnostic: HE1PR07MB4332: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(346002)(136003)(396003)(43544003)(51444003)(199004)(189003)(102836004)(305945005)(6246003)(55016002)(76176011)(14444005)(256004)(52536014)(66946007)(66476007)(66556008)(66446008)(64756008)(76116006)(73956011)(86362001)(68736007)(478600001)(7696005)(486006)(9686003)(229853002)(2171002)(110136005)(33656002)(316002)(44832011)(74316002)(3846002)(8936002)(66066001)(6506007)(6116002)(14454004)(8676002)(81156014)(81166006)(99286004)(11346002)(26005)(446003)(71200400001)(71190400001)(186003)(25786009)(2501003)(7736002)(5660300002)(53936002)(2906002)(6436002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4332; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0Sg6DgcOGjuwq/YMvsYtLL6gx0VwyM3lFL4Nme4N0hFZFFp3u64kao5knjJ8juSQ8mD6TjGe3eIB82+aBMSKQ7HzMM6A1XMG6YMzbY5NcRN7JxAu1Zlb9/CFdmLUfs6CBOvf1gGHr9OMyyWkCoov0XKlAZ2Q7kBa1BHib0L62woP2688l0xuPUulAzCGPV4v9veeG+cE4OmC8Y5+xXXzBZAcKCXlUZd2d1F4Ner4k+P569Y0NvueVO1yctAB3X/PGtrSLMQMuPOR0CK5omx/3Q/W28Y3ent8a/2Hvit5OelCY+iIg/pjwVuumEWJkpyEJH0dV5cpm9Mz3giQGejEwKCJr6g3Fg6TfvULJ2/IFVswrkIqhTs0mXvTzKtE2uc9xL8Bj6LmyrlgDn/Qb2vI5XOD6iqGRkO4JioW90tD0rM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad84d33b-0459-4403-81ea-08d7043d9e3e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 07:18:18.9328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4332 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 07:18:27 -0000 SGksDQoNCj4+PiAqIFJlZ2FyZGluZyBXV1ctQXV0aGVudGljYXRlOg0KPj4+DQo+Pj4gSSBiZWxp ZXZlIGl0IHdpbGwgaG93IGJlIHBvc3NpYmxlIGZvciBhIHNlcnZlciB0byBzdXBwb3J0IGJvdGgg RGlnZXN0IA0KPj4+IGFuZCBCZWFyZXIuIEkgdGhpbmsgdGhpcyBtZWFucyB0aGF0IHRoZSBjbGll bnQgY2FuIHVzZSBlaXRoZXIgZGVwZW5kaW5nIG9uIHdoYXQgc29ydCBvZiBjcmVkZW50aWFscyBp dCBvciBpdHMgdXNlciBoYXBwZW4gdG8ga25vdy4NCj4+Pg0KPj4+IEkgdGhpbmsgaXQgd291bGQg YmUgZ29vZCB0byBtZW50aW9uIHRoaXMuIEkgZ3Vlc3MgaW4gcHJpbmNpcGxlIHRoZSANCj4+PiBj bGllbnQgY291bGQgcmV0dXJuIGNyZWRlbnRpYWxzIGZvciBib3RoLiBJbiB0aGF0IGNhc2UsIEkg ZG9uJ3Qga25vdyB3aGV0aGVyIGJvdGggbXVzdCBiZSB2YWxpZCBvciBpZiBpdCBpcyBzdWZmaWNp ZW50IGZvciBvbmUgdG8gYmUgdmFsaWQuDQo+Pj4gUGVyaGFwcyB3ZSBuZWVkIHRvIGRpc2N1c3Mg dGhhdC4gKFByZXN1bWFibHkgb25seSBjcmVkZW50aWFscyBmb3IgDQo+Pj4gYS90aGUgcmVhbG0g dGhhdCB0aGUgc2VydmVyIHN1cHBvcnRzIGFyZSB0byBiZSBjb25zaWRlcmVkLCB3aXRoIHRob3Nl IA0KPj4+IGZvciBvdGhlciByZWFsbXMgYmVpbmcgaWdub3JlZC4pDQo+PiANCj4+IEkgdGhpbmsg dGhhdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQuIFRoZXJlIGNvdWxkIGJlIG11 bHRpcGxlIHZhcmlhbnRzIG9mIG11bHRpcGxlIGNoYWxsZW5nZXMuDQo+PiANCj4+IEFuZCwgUkZD IDMyNjEgYWxyZWFkeSB0YWxrcyBnZW5lcmFsbHkgYWJvdXQgbXVsdGlwbGUgY2hhbGxlbmdlcy4g SSBkbyB0aGluayBzb21lIG9mIHRoZSAzMjYxIHRleHQgY291bGQgYmUgaW1wcm92ZWQgYW5kIGNs YXJpZmllZCwgYnV0IHRoYXQgc2hvdWxkIGJlIGRvbmUgYXMgYSBzZXBhcmF0ZSB0YXNrLg0KPg0K PiBXaGlsZSBJIGFncmVlIGluIHByaW5jaXBsZSB0aGF0IHRoaXMgaXMgaW4gc29tZSBzZW5zZSBp bmRlcGVuZGVudCBvZiB0aGUgaW5kaXZpZHVhbCBzY2hlbWVzLCBCZWFyZXIgaXMgd2hhdCBwdXNo ZXMgdGhpcyBmcm9tIG9uZSB0byB0d28sIHdoaWNoIA0KPiBpcyB3aGVuIHRoZSBpc3N1ZSBhcHBl YXJzLiBTbyBJTU8gaXQgbWFrZXMgc2Vuc2UgdG8gc2F5IHNvbWV0aGluZyBhYm91dCBpdCBoZXJl LiBTYXlpbmcgdGhhdCBpdCAqb3VnaHQqIHRvIGJlIGluIDMyNjEgaXMgZmluZSwgYnV0IGluIHBy YWN0aWNlIHRoYXQgaXMgDQo+IHNpbXBseSBzYXlpbmcgdGhhdCBpdCBpc24ndCBnb2luZyB0byBi ZSBjb25zaWRlcmVkIGF0IGFsbC4NCg0KSSBhbSBzYXlpbmcgdGhhdCB0aGUgcHJvY2VkdXJlcyBz aG91bGQgYmUgaW4gb25lIHBsYWNlLCBhbmQgdGhhdCdzIFJGQyAzMjYxLiANCg0KQW5kLCBhcyAz MjYxIGFscmVhZHkgdGFsa3MgYWJvdXQgbXVsdGlwbGUgY2hhbGxlbmdlcy9jcmVkZW50aWFscywg SSBkb24ndCB0aGluayBCZWFyZXIgaXMgcHVzaGluZyB0aGlzLg0KDQpIYXZpbmcgc2FpZCB0aGF0 LCB3ZSBjYW4gZm9yIHN1cmUgcmVmZXJlbmNlIHRoZSAzMjYxIHByb2NlZHVyZXMgaW4gdGhlIGRy YWZ0LCBidXQgSSBkb24ndCB0aGluayB0aGUgZHJhZnQgaXMgdGhlIHBsYWNlIHdoZXJlIHRvIGRl c2NyaWJlIFNJUCB1c2FnZSBvZiBtdWx0aXBsZSBjaGFsbGVuZ2VzL2NyZWRlbnRpYWxzLg0KDQo+ Pj4gKiBSZWdhcmRpbmcgbm9uLXJlZ2lzdHJhdGlvbiByZXF1ZXN0cyAoYW5kIG1heWJlIHJlZ2lz dHJhdGlvbiByZXF1ZXN0cyB0b28pOg0KPj4+DQo+Pj4gICAgIFRoZSBVQSBNVVNUIE5PVCBpbnNl cnQgYSB0b2tlbiBpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0LCB1bmxlc3MgdGhlDQo+Pj4gICAg IG5vbi1SRUdJU1RFUiByZXF1ZXN0IGhhcyBiZWVuIGNoYWxsZW5nZWQsIG9yIHRoZSBwZWVyIGlz IGNvbnNpZGVyZWQgYQ0KPj4+ICAgICB0cnVzdGVkIGVudGl0eS4NCj4+Pg0KPj4+IFdoYXQgaXMg YSB0cnVzdGVkIGVudGl0eT8NCj4+IA0KPj4gSSBhc2tlZCB0aGF0IHRvIGJlIGFkZGVkLCBidXQg aXQgY2FuIGJlIHJlbW92ZWQuDQo+PiANCj4+PiBJbiBhbnkgY2FzZSBJIHRoaW5rIHRoaXMgaXMg dG9vIHN0cm9uZy4gT25jZSBhIHJlcXVlc3QgaGFzIGJlZW4gY2hhbGxlbmdlZCB0aGUgY2xpZW50 IGtub3dzIHRoaXMgdGFyZ2V0IHdhbnRzIHRoZSBjcmVkZW50aWFscy4NCj4+PiBXZSBjZXJ0YWlu bHkgZG9uJ3Qgd2FudCB0byBmb3JjZSBldmVyeSBzdWJzZXF1ZW50IHJlcXVlc3QgdG8gdGhlIHNh bWUgDQo+Pj4gdGFyZ2V0IHRvIHRha2UgdHdvIHJvdW5kIHRyaXBzLCBvbmUgd2l0aG91dCBjcmVk ZW50aWFscyBhbmQgdGhlbiBvbmUgDQo+Pj4gd2l0aC4gU28gdGhlIGNsaWVudCBuZWVkcyB0byBh c3NvY2lhdGUgdGhlc2UgY3JlZGVudGlhbHMgd2l0aCB0aGlzIA0KPj4+IHRhcmdldCwgZm9yIGF3 aGlsZS4gQnV0IHRoYXQgYmVncyB0aGUgcXVlc3Rpb24gb2YgaG93IGxvbmcgdG8gcmV0YWluIHRo aXMgYXNzb2NpYXRpb24uIEluIHRoZSBjYXNlIG9mIERpZ2VzdCwgYSBub25jZSBldmVudHVhbGx5 IA0KPj4+IGV4cGlyZXMgYW5kIHRoZSBvbGQgY3JlZGVudGlhbHMgZmFpbCBhbmQgZ2V0IGZvcmdv dHRlbiBhbmQgcmVwbGFjZWQgYnkgbmV3IG9uZXMuIEkgZ3Vlc3MgdGhlIGxpZmUgY3ljbGUgd2ls bCBiZSBzb21ld2hhdCBkaWZmZXJlbnQgZm9yIEJlYXJlci4NCj4+PiBUaGlzIG5lZWRzIHNvbWUg dGhvdWdodCBhbmQgZGlzY3Vzc2lvbi4NCj4+IA0KPj4gIEZyb20gYSBnZW5lcmljIHBlcnNwZWN0 aXZlIEkgdGhpbmsgMzI2MSBzaG91bGQgZGVzY3JpYmUgaG93IGNyZWRlbnRpYWxzIGFyZSBwcm92 aWRlZCBpbiBzdWJzZXF1ZW50IHJlcXVlc3RzLg0KPg0KPiBTZWUgbXkgY29tbWVudCBhYm92ZSBv biB3aGF0IG91Z2h0IHRvIGdvIGluIDMyNjEuDQo+DQo+PiBBcyBmYXIgYXMgdG9rZW5zIGFyZSBj b25jZXJuZWQsIEkgYW0gbm90IHN1cmUgaXQncyB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoaXMgZHJh ZnQgdG8gZGVmaW5lIHRoZSBsaWZldGltZSBvZiB0b2tlbiBjcmVkZW50aWFscywgYXMgdGhleSBh cmUgbm90IFNJUCBzcGVjaWZpYy4NCj4NCj4gSSdtIG5vdCB0b28gbXVjaCBjb25jZXJuZWQgd2l0 aCB0aGUgKmxpZmV0aW1lKiBvZiB0aGUgdG9rZW4sIHNpbmNlIHRoYXQgd2lsbCBwcmV0dHkgbXVj aCB0YWtlIGNhcmUgb2YgaXRzZWxmLiAoV2hlbiBpdCBleGNlZWRzIGl0cyBsaWZldGltZSBpdCB3 aWxsIHN0b3Agd29ya2luZy4pDQo+DQo+IEJ1dCBJIHN1c3BlY3QgdGhlcmUgbWlnaHQgYmUgc2Vj dXJpdHkgY29uY2VybnMgaGVyZSwgYW5kIHRoYXQgdGhleSBtYXkgYmUgZGlmZmVyZW50IGZyb20g dGhvc2UgdGhhdCBhcHBseSB0byBEaWdlc3QuDQo+DQo+IEl0ICptYXkqIGJlIHRoYXQgaXQgd291 bGQgYmUgZmluZSB0byBpbmNsdWRlIHRoZSB0b2tlbiBpbiBldmVyeSByZXF1ZXN0LCByZWdhcmRs ZXNzIG9mIHRhcmdldCAtIHRoYXQgZG9pbmcgc28gd29uJ3QgY2F1c2UgYW55IHNlY3VyaXR5IGNv bmNlcm5zLiANCj4gQ29udmVyc2VseSwgdGhhdCBtaWdodCBub3QgYmUgc28uDQo+DQo+IElJVUMs IHNpbWlsYXIgdG9rZW5zIGFyZSB1c2VkIGZvciBzaW5nbGUtc2lnbm9uLCBzbyBwZXJoYXBzIHRo ZXJlIGFyZSBndWlkZWxpbmVzIHRoYXQgY2FuIGJlIHJlcHVycG9zZWQgZm9yIHVzZSBoZXJlLiBC dXQgSSB0aGluayAqc29tZXRoaW5nKiANCj4gbmVlZHMgdG8gYmUgc2FpZCBvciBlbHNlIGltcGxl bWVudG9ycyB3b24ndCBrbm93IHdoYXQgdG8gZG8gYW5kIHRoZSByZXN1bHQgd2lsbCBiZSBpbnRl cm9wIHByb2JsZW1zLg0KPg0KPj4gSGF2aW5nIHNhaWQgdGhhdCwgSSBETyBhZ3JlZSB3aXRoIHlv dSB0aGF0IHRoZSBjdXJyZW50IGNhbWUgb3V0IHRvbyBzdHJvbmcgLSBhbmQgd3Jvbmc6IG15IGlu dGVudGlvbiB3YXMgdG8gc2F5IHRoYXQgY3JlZGVudGlhbHMgDQo+PiBmcm9tIGEgUkVHSVNURVIg cmVxdWVzdCBhcmUgbm90IHBsYWNlZCBpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0Lg0KPj4gDQo+ PiBCVVQsIGlmIGEgbm9uLVJFR0lTVEVSIHJlcXVlc3RzIGdldHMgY2hhbGxlbmdlZCwgd2Ugc2hv dWxkIGFsbG93IHRoZSBjbGllbnQgdG8gaW5jbHVkZSB0aGUgY3JlZGVudGlhbHMgaW4gc3Vic2Vx dWVudCBub24tUkVHSVNURVIgDQo+PiByZXF1ZXN0cyAtIGF0IGxlYXN0IHdpdGhpbiB0aGUgc2Ft ZSBzZXNzaW9uIChpbiBjYXNlIG9mIHNlc3Npb24gcmVsYXRlZCByZXF1ZXN0cykuDQo+DQo+IElT VE0gdGhhdCBpcyBhbHNvIHRvbyBzdHJvbmcuIElmIEkgdXNlZCBhIHRva2VuIGZvciBSRUdJU1RF UiwgYW5kIHRoZW4gSSBkbyBzb21ldGhpbmcgZWxzZSAoZS5nLiwgU1VCU0NSSUJFKSB3aXRoIHRo ZSBzYW1lIHNlcnZlciwgDQo+IHRoZW4gaXQgc2hvdWxkIGJlIGZpbmUgdG8gdXNlIGl0IGluIG90 aGVyIHJlcXVlc3RzIGRpcmVjdGVkIHRvIHRoZSBzYW1lIHNlcnZlci4gDQoNCkZhaXIgZW5vdWdo LCBpZiB5b3Uga25vdyB0aGUgc2VydmVyIGlzIHRoZSBzYW1lLg0KDQo+IEFuZCBwb3NzaWJseSB0 byBvdGhlciBzZXJ2ZXJzIGFzIHdlbGwuIFlvdSBzZWVtIHRvIGJlIGFzc3VtaW5nIHRoYXQgY3Jl ZGVudGlhbHMgZm9yIHJlZ2lzdHJhdGlvbiBhcmUgc29tZWhvdyBkaWZmZXJlbnQgZnJvbSBjcmVk ZW50aWFscyANCj4gZm9yIG90aGVyIHRoaW5ncy4gSXQgaXMgdXAgdG8gdGhlIHNlcnZlcnMgaW4g cXVlc3Rpb24gdG8gZGVjaWRlIHRoYXQsIG5vdCB0aGlzIHByb3RvY29sIGRvY3VtZW50Lg0KDQpB cyBJIHNhaWQgaW4gYW5vdGhlciByZXBseSwgaWYgeW91IGJ5IGRlZmF1bHQgcGxhY2UgYSBSRUdJ U1RFUiB0b2tlbiBpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0IHRoZSB0b2tlbiBtYXkgcmVhY2gg dGhlIHJlbW90ZSBwZWVyLCB3aGljaCBjb3VsZCBiZSBhIHNlY3VyaXR5IGNvbmNlcm4uIA0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Tue Jul 9 07:29:26 2019 Return-Path: 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 E5C9E1203D6 for ; Tue, 9 Jul 2019 07:29:18 -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 1JyHtU0Vo6UL for ; Tue, 9 Jul 2019 07:29:17 -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 A23CC120179 for ; Tue, 9 Jul 2019 07:29:16 -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 x69ETBKb031643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Jul 2019 10:29:12 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> From: Paul Kyzivat Message-ID: <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> Date: Tue, 9 Jul 2019 10:29:11 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 14:29:25 -0000 On 7/9/19 3:18 AM, Christer Holmberg wrote: > 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. Thanks, Paul From nobody Tue Jul 9 08:42:38 2019 Return-Path: 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 1D92A1206FC for ; Tue, 9 Jul 2019 08:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 aHvQiFtakv2b for ; Tue, 9 Jul 2019 08:42:27 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50044.outbound.protection.outlook.com [40.107.5.44]) (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 5D0E71206EC for ; Tue, 9 Jul 2019 08:42:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DPw44L0BmBqrBzbs4xN+0pDNNmZ0xWayv1J6qPAZ1OQ4fXc9kpanNA/tIHFmTpg2WdniE1m+duS5dmWHqPOjbf7usGWqiJa/rvoZxfEVwvMe79/13OKRAgKXEbncaZSLncQ16C6tYaVGN4C1HJD2R/BJw2q51psztlHSqCFuGChZKfxdVMv1v/2vdgKSXNbA1xr8OPPsej4tRhlPOv68W/groEC7Es00aZQ6MDE6CCvAIFcjIaHuTpHIrz84ZTmrjQAa/f1JjBbJPfkoMf+q1MyHwTPepiw+FeHZqwLoDnMe9hPaV5x0Y97G3lBqgtXGu1uc5U5u8g9I1o9Q+vM8TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F1agCYmm0Hcf4wJJfb+OvCHQy79z9rB14aYyQMYCQ4k=; b=Oy9drDNMaWIjBfTbQ/81IRzDWq5ztNBYrjcqMTOHNHA+1srRw/VGdyVjei7MPX9UUGvwcla9imvQ+oiaGSdZJgaVHe/Bt227z7OKNNH84rH5NTQAq8Fl47iJFRheUKQ0yBakj/Dn7neIomq9+1G57lIVa6/xM5r5W3PTbCPbS1mHOwrdp0KxWPJCTJxx49mnbEdILyULD9I5Ijs2cEx8Q4fLcRk1TEkyijWFaan8+KyrJ0kdSWxwfzC5bW54TDapmvktf6YOboYuhWEuKIaZ7hZuuw25PUDPv1BKIlFHdCpLrCOCwXaEbz9p7aol6yBJ63QupA0jhImJXH74LUbB8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F1agCYmm0Hcf4wJJfb+OvCHQy79z9rB14aYyQMYCQ4k=; b=jRKchSo+ZtXCQJqcyvt0Fnj3yAeMhiSRva5LxC/YwGRB4fb5ohnQxpddwoAx8pfxMsbbOD+3ar/usRBAWe2sap9BASDUviqFpBolz8MW09mOd+5UJm8Ny8i2IUJ54alXeSq3RX6naygZM9gn4EtvJYJeAD4pCxY0mgSj804+9IM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4411.eurprd07.prod.outlook.com (20.176.167.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 15:42:02 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 15:42:02 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA Date: Tue, 9 Jul 2019 15:42:02 +0000 Message-ID: <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> In-Reply-To: <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da435cc9-ad07-4de4-fdc8-08d70483fcf9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4411; x-ms-traffictypediagnostic: HE1PR07MB4411: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(199004)(189003)(8936002)(53936002)(36756003)(8676002)(58126008)(33656002)(11346002)(229853002)(81166006)(110136005)(2906002)(6512007)(316002)(81156014)(7736002)(478600001)(2171002)(6246003)(2501003)(14444005)(2616005)(476003)(256004)(486006)(446003)(14454004)(6436002)(6486002)(305945005)(44832011)(68736007)(76116006)(71190400001)(86362001)(5660300002)(102836004)(66946007)(4744005)(99286004)(71200400001)(66066001)(3846002)(6116002)(186003)(66476007)(66556008)(6506007)(25786009)(76176011)(26005)(64756008)(66446008)(73956011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4411; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HefMG15e6Q5Z17wRKzBPbrNH+FAeUvYagygS0p4NGcEm3ORF0yECIgQwRDLzKyGTxTbbrso/p5zrRR/JCagM6not+xSydwhdKnA7foDUwU1sQRphdlalygA8vF0NhhKbLBl+JdvklVXyoRHLIuDbocXZUZuwNfrHq1TjeRVaeEpu2Sub7ZDnioKAbmyigSoO4iM3TOsKPJ/pyRr+7lCaFFMgzXoq6eG5nPGk3EWof/ffE9YDiPsirSLrIu+XdeKwbUpM09jIRdD+3Gq2QuCMg5YCPPdGMmA5/8PHdDkuiu0J8sJRDjvRo4DeslW+Lj2+6Jqcr/KUwkZkCykrMXiH0ru9eKGIXhbLviveZWPYAhq+T9YktTsleOuI8zgTVuEotqEycHONdlaiIz40DH2+7JxbRKHdODhV8EheOBq4bmU= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: da435cc9-ad07-4de4-fdc8-08d70483fcf9 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 15:42:02.6513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4411 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:42:37 -0000 SGksDQogICAgDQo+PiBBcyBJIHNhaWQgaW4gYW5vdGhlciByZXBseSwgaWYgeW91IGJ5IGRlZmF1 bHQgcGxhY2UgYSBSRUdJU1RFUiB0b2tlbiBpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0IHRoZSB0 b2tlbiBtYXkgcmVhY2ggdGhlIHJlbW90ZSBwZWVyLCB3aGljaCBjb3VsZCBiZSBhIHNlY3VyaXR5 IGNvbmNlcm4uDQo+ICAgIA0KPiAgICBJIHdvdWxkIGxpa2UgdG8gaGVhciBtb3JlIGFib3V0IHRo aXMuIElzIHRoZXJlIHNvbWV0aGluZyBhYm91dCB0aGUgdG9rZW4gDQo+ICAgIHRoYXQgcmV2ZWFs cyBzdHVmZiB0aGF0IG1pZ2h0IG5vdCBiZSBzdWl0YWJsZSB0byBleHBvc2UgdG8gZXZlcnlvbmU/ IEkgDQo+ICAgIHBlcnNvbmFsbHkgZG9uJ3Qga25vdy4gVGhpcyBzZWVtcyBsaWtlIHNvbWV0aGlu ZyB0aGF0IG91Z2h0IHRvIGJlIA0KPiAgICBkaXNjdXNzZWQgaW4gc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMuDQogIA0KVGhlIHRva2VuIGl0c2VsZiBkb2VzIG5vdCByZXZlYWwgYW55dGhpbmcsIGJ1 dCBpbiBPQXV0aCB0aGUgdG9rZW4gaXMgdXNlZCB0byBhY2Nlc3MgdGhlIHJlcXVlc3RlZCByZXNv dXJjZSwgc28gaXQgaXMgY29uc2lkZXJlZCBzZW5zaXRpdmUgaW5mb3JtYXRpb24uDQoNCkFzIGZh ciBhcyBJIGtub3csIE9BdXRoIGZvciBTSVAgaGFzIG9ubHkgYmVlbiB1c2VkIGZvciBSRUdJU1RF UiByZXF1ZXN0cywgYmV0d2VlbiB0aGUgVUEgYW5kIHRoZSByZWdpc3RyYXIuIEkgaGF2ZSBuZXZl ciBoZWFyZCBhYm91dCBhbnlvbmUgdXNpbmcgaXQgZm9yIG5vbi1SRUdJU1RFUiBhdXRoZW50aWNh dGlvbiwgYW5kIEkgd29uZGVyIHdoZXRoZXIgd2UgZXZlbiBuZWVkIHRvIGNvdmVyIGl0IGluIHRo ZSBkcmFmdC4gV2UgY291bGQgbGltaXQgdGhlIHNjb3BlIHRoZSBSRUdJU1RFUiByZXF1ZXN0cy4g VGhlbiwgaWYgYW55b25lIGV2ZXIgbmVlZHMgT0F1dGggZm9yIG5vbi1SRUdJU1RFUiByZXF1ZXN0 cywgYSBzZXBhcmF0ZSBkcmFmdCBjYW4gYmUgd3JpdHRlbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KICAgIA0KDQo= From nobody Tue Jul 9 09:24:39 2019 Return-Path: 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 EE4B4120295 for ; Tue, 9 Jul 2019 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9FPXqQ-ao7Dv for ; Tue, 9 Jul 2019 09:24:35 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 042131201D4 for ; Tue, 9 Jul 2019 09:24:35 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id o9so28863128iom.3 for ; Tue, 09 Jul 2019 09:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5II7BG+e8MDf+Rko+PSXmiT3nXj/zNiF+WCGP4EAxy4=; b=Ji0vdF/Q1QJaHJGSMMXKTHob0YBLSVIRDex61JM0zpeTXCirynVacGNuAz253vLiQN LozkbHq/FzHV8qsMFFVL/uapogmu0U58pDA7xRpgvUhkigYlIUroVCNlWIiCskUFZzrf 7OFXaXQwFMGSoNI4kg2Ve8sf61e4Z3oFFRjaqc7d7IIRUCh7K8pX7BXqeEp9FQvHkDGz Wy6SaKMDbpE35W+SUAT4H0OdBzDd9VHI/CBdeYcO7XWgy4N257JkePEfETVbPk4gl44z JHslEl6eWuNAzgOh8zVrcn52bfiSVPYohRucdyJhM4BkExxXWmUoNySZRg70QQWC/XvP x74w== 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=5II7BG+e8MDf+Rko+PSXmiT3nXj/zNiF+WCGP4EAxy4=; b=W5RdSLhUtN2IvAoXVIHNjBta8HGaZUIqCamOzF8yAEd8hCZnBNQdSZrfzA/tVMQ9/y zVUpAbHErdA7Qa7PtB7jO9ThSpnDt9uWNK7W1QxI0tEMrODhsCJsqFP880QryJbDOXOP +xUmvQarck4diAlmedVIKxBmYMv5P8kokYX0qEGd4XssmsTImxOgszW8ey/zuaY+dTyq xlI/Ox1+h8Ltx8E2BeEQOJEdCAB27XnjOBnmry4N/rqsGECupbg4ZTg5+HnoDL8aztBv YbmdcVm7IbOJreuYtKt4Ei2zXyVq5RXSpel5CDrzroGUahyQa7FE2ydr0DMf0GaqAg+g jVqA== X-Gm-Message-State: APjAAAXxFqzcN8+sxYsQLMou6dduarZiad122zvFxte5HPXWbzY2TltY 5+b1ia7yc6cZkg84NvLc0Y925SeW00kkuAlC/KE= X-Google-Smtp-Source: APXvYqxVAIcbCzaG8DRdOWSgrgm/fCov5dJnXx2VDh2/nLcd7F/oYV5MKUZ/zfCabdAlZ1w6IaeIdPelAVQODyqXRkw= X-Received: by 2002:a5d:9282:: with SMTP id s2mr440245iom.36.1562689474299; Tue, 09 Jul 2019 09:24:34 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> From: Rifaat Shekh-Yusef Date: Tue, 9 Jul 2019 12:24:23 -0400 Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000028fda058d41fffc" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:24:37 -0000 --000000000000028fda058d41fffc Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 11:43 AM Christer Holmberg < christer.holmberg@ericsson.com> 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, That depends on the type of token. A JWT might contain data that must be protected for privacy reasons. but in OAuth the token is used to access the requested resource, so it is > considered sensitive information. > > Yeah, because these are *bearer *tokens it means that they are not bind to a specific UA. There are ways to bind a token to a specific UA (see RFC7800), but this is out of scope for this document Regards, Rifaat > 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. > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000028fda058d41fffc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 9, 2019 at 11:43 AM Chris= ter Holmberg <christer= .holmberg@ericsson.com> wrote:
Hi,

>> As I said in another reply, if you by default place a REGISTER tok= en in a non-REGISTER request the token may reach the remote peer, which cou= ld be a security concern.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I would like to hear more about this. Is there something = about the token
>=C2=A0 =C2=A0 that reveals stuff that might not be suitable to expose t= o everyone? I
>=C2=A0 =C2=A0 personally don't know. This seems like something that= ought to be
>=C2=A0 =C2=A0 discussed in security considerations.

The token itself does not reveal anything,
=C2=A0
That depends on the type of token.
A JWT might contain data tha= t must be protected for privacy reasons.
=C2=A0

but in OAuth the token= is used to access the requested resource, so it is considered sensitive in= formation.


Yeah, because these are bearer = tokens it means that they are not bind to a specific UA.
There ar= e ways to bind a token to a specific UA (see RFC7800), but this is out of s= cope for this document

Regards,
=C2=A0Ri= faat


=C2=A0
As far as I know, OAuth for SIP has only been used for REGISTER requests, b= etween the UA and the registrar. I have never heard about anyone using it f= or 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 a= nyone ever needs OAuth for non-REGISTER requests, a separate draft can be w= ritten.

Regards,

Christer



_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000028fda058d41fffc-- From nobody Tue Jul 9 09:26:05 2019 Return-Path: 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 ; 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 ; 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 ; 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 , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> From: Paul Kyzivat Message-ID: <5bb63c0c-130d-7f69-10b0-1ed1b274cc58@alum.mit.edu> Date: Tue, 9 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue Jul 9 09:28:57 2019 Return-Path: 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 13646120658 for ; Tue, 9 Jul 2019 09:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 7LQ5-9fkNQzh for ; Tue, 9 Jul 2019 09:28:53 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30061.outbound.protection.outlook.com [40.107.3.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887DF12064E for ; Tue, 9 Jul 2019 09:28:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nkl8yldXPrJgPz1qh9syC3Wr8/1rYZbi6gNkU2rqNMdJb7ud0exwd90mFnUAeWaBPpuQ3LRUCm1dzL+wRwC1+AOEQYbsx+bobcwujIroT4XfjRiXJT5Zc2nA7gI1MN8iCpEfKIFrEUO6HcSZoKK0YYge6vZO7M79iYiqBzOc5EdCyiUnYXKU2CJ3EUfFYOiNpz5DW/b283gvwsXFa3HTbG9mZQbvLQ/+JegQlNFIWPeYBCuqbp2QyyIwm91TYdO9rJYA95j1gG+MoXTVLWtVK4XB6zDQLVryZCULQn0p6+hSq/6vcrr9zhMbWb6dl7BgRFEj6r1B58NhkIjNmBItbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aOYT0YN7v8nlmslXzm1Fcc5rURhsrQedATpYcNFUh70=; b=D9+yLLDO1zpMe41ukFuGpVcKphQmhJ1OhEaMit3ZAMVXzGpH3poz+bOIMX2Wz76Qg9I/Fnbn5bole8eg7GRX709MMIk4TkosZUWro+DZNZ4sA1r8Y13//bZt68kJ3Oo92d2tTrVG/99CEsvgtKlHR30+BbvonVJuSNIEi8NCmpFE/tyMzlLGWZRbfM0MqLO4bKZ5ffZWghAqd5ZeE0JEbo6T87gpFxqM/MfWyvT+SWT25GESaRhU7ecLIlOp3BRnk5fFVpB88iu/HQvWKwguxPDy+0QN+jDVbXdDvf1phnVV7xof6Xq5D+dAPggoAvH57zKvp9fAlbXCOqc7ky7Jvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aOYT0YN7v8nlmslXzm1Fcc5rURhsrQedATpYcNFUh70=; b=Tu59hLy1K3FvSnazcxk7fMDYKmEqgOOJSFwRGXA2kPL760VSD2cHT+Y4WztB43Z777GxWwNMJj1+/CHm+aTErP5CfeXJ9k+EwMdH+80RSmpuKzG7Z41HGFmOBHnZejdXvGJKGDO843ZjX2krCc10OmhyFRQTYjDBPCKkof3C6qc= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4393.eurprd07.prod.outlook.com (20.176.167.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.8; Tue, 9 Jul 2019 16:28:44 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 16:28:43 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgA== Date: Tue, 9 Jul 2019 16:28:43 +0000 Message-ID: <87AD4BB8-CE77-4FD7-BB72-6643DF513058@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <5bb63c0c-130d-7f69-10b0-1ed1b274cc58@alum.mit.edu> In-Reply-To: <5bb63c0c-130d-7f69-10b0-1ed1b274cc58@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1b3a200d-98a4-4b37-3081-08d7048a82a2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4393; x-ms-traffictypediagnostic: HE1PR07MB4393: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(376002)(346002)(366004)(189003)(199004)(5660300002)(36756003)(33656002)(2171002)(66476007)(7736002)(66446008)(64756008)(66556008)(305945005)(73956011)(66946007)(6246003)(76116006)(14444005)(256004)(99286004)(478600001)(2906002)(446003)(11346002)(2616005)(68736007)(44832011)(476003)(86362001)(76176011)(25786009)(53936002)(81156014)(8676002)(186003)(102836004)(26005)(6506007)(6436002)(81166006)(6512007)(229853002)(8936002)(14454004)(110136005)(58126008)(316002)(6116002)(3846002)(2501003)(486006)(6486002)(71200400001)(66066001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4393; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wRHOLkB8yiDgx+LVU+iH06f1CNg2gJnlBdUiIe3o+vgfcqVk29IACEF/L4wVAgVasjzfxWRJ7j+PULam0lETqgNjW07A5upd3WoZJvxj9YifWh7Hi1oCVj2ygqbHQhz8ncI32tF8UxIQOGf6IqUqgNEsI6xQlxlLmHpMAbMQwTOtjz8Jro6tB/hmeeD2X7XbhQrS7348e3Im9n/x5XYo9NKNEXD/oAQemsUM9USjPuWVoNRitHzOJ3qPdi8vuMKM1/qP//sWwA4REingNdLYSvbKAbTXWFKsFXCBHaH576yCGCCQHv2FzvyCzyn8xHphIfCHK+Dppl3A4xvFDUycnfJ1RFmpSLXDV/toY++YWPJlFsixy5G1QqOkbfT/W/2jr0v2rSrGmRUw7+AmYPLBtWQFNA6cTvKMxB890UriqYQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b3a200d-98a4-4b37-3081-08d7048a82a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 16:28:43.8910 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4393 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:28:56 -0000 SGksDQoNCj4+Pj4gQXMgSSBzYWlkIGluIGFub3RoZXIgcmVwbHksIGlmIHlvdSBieSBkZWZhdWx0 IHBsYWNlIGEgUkVHSVNURVIgdG9rZW4gaW4gYSBub24tUkVHSVNURVIgcmVxdWVzdCB0aGUgdG9r ZW4gbWF5IHJlYWNoIHRoZSByZW1vdGUgcGVlciwgd2hpY2ggY291bGQgYmUgYSBzZWN1cml0eSBj b25jZXJuLg0KPj4+ICAgICANCj4+PiAgICAgSSB3b3VsZCBsaWtlIHRvIGhlYXIgbW9yZSBhYm91 dCB0aGlzLiBJcyB0aGVyZSBzb21ldGhpbmcgYWJvdXQgdGhlIHRva2VuDQo+Pj4gICAgIHRoYXQg cmV2ZWFscyBzdHVmZiB0aGF0IG1pZ2h0IG5vdCBiZSBzdWl0YWJsZSB0byBleHBvc2UgdG8gZXZl cnlvbmU/IEkNCj4+PiAgICAgcGVyc29uYWxseSBkb24ndCBrbm93LiBUaGlzIHNlZW1zIGxpa2Ug c29tZXRoaW5nIHRoYXQgb3VnaHQgdG8gYmUNCj4+PiAgICAgZGlzY3Vzc2VkIGluIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zLg0KPj4+ICAgIA0KPj4gVGhlIHRva2VuIGl0c2VsZiBkb2VzIG5vdCBy ZXZlYWwgYW55dGhpbmcsIGJ1dCBpbiBPQXV0aCB0aGUgdG9rZW4gaXMgdXNlZCB0byBhY2Nlc3Mg dGhlIHJlcXVlc3RlZCByZXNvdXJjZSwgc28gaXQgaXMgY29uc2lkZXJlZCBzZW5zaXRpdmUgaW5m b3JtYXRpb24uDQo+PiANCj4+IEFzIGZhciBhcyBJIGtub3csIE9BdXRoIGZvciBTSVAgaGFzIG9u bHkgYmVlbiB1c2VkIGZvciBSRUdJU1RFUiByZXF1ZXN0cywgYmV0d2VlbiB0aGUgVUEgYW5kIHRo ZSByZWdpc3RyYXIuIEkgaGF2ZSBuZXZlciBoZWFyZCBhYm91dCBhbnlvbmUgdXNpbmcNCj4+IGl0 IGZvciBub24tUkVHSVNURVIgYXV0aGVudGljYXRpb24sIGFuZCBJIHdvbmRlciB3aGV0aGVyIHdl IGV2ZW4gbmVlZCB0byBjb3ZlciBpdCBpbiB0aGUgZHJhZnQuIFdlIGNvdWxkIGxpbWl0IHRoZSBz Y29wZSB0aGUgUkVHSVNURVIgcmVxdWVzdHMuIA0KPj4gVGhlbiwgaWYgYW55b25lIGV2ZXIgbmVl ZHMgT0F1dGggZm9yIG5vbi1SRUdJU1RFUiByZXF1ZXN0cywgYSBzZXBhcmF0ZSBkcmFmdCBjYW4g YmUgd3JpdHRlbi4NCj4gICAgDQo+ICAgIFllcywgeW91IGNhbiBkbyB0aGF0IGlmIHlvdSB3aXNo LiBCdXQgSVNUTSB0aGF0IHRoZSBpc3N1ZXMgYXJlIGxhcmdlbHkgDQo+ICAgIHRoZSBzYW1lIHNv IEkgZG9uJ3Qga25vdyB3aHkgeW91IHdvdWxkIGRvIHRoYXQuDQoNClRoZSBSRUdJU1RFUiByZXF1 ZXN0LCBhbmQgdGhlIHRva2VuLCB3aWxsIG9ubHkgcmVhY2ggdGhlIHJlZ2lzdHJhci4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCiAgDQoNCg0KDQoNCiAgDQogICAgCVRoYW5rcywNCiAgICAJUGF1 bA0KICAgIA0KDQo= From nobody Tue Jul 9 09:35:51 2019 Return-Path: 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 D3309120026 for ; Tue, 9 Jul 2019 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 3n-Be-SwhsLN for ; Tue, 9 Jul 2019 09:35:46 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D4C120292 for ; Tue, 9 Jul 2019 09:35:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HlqFzwunvXpdIFe2m/lyjKPQRnj/89NfaIB2IX5/eEd/130lhNMSW2eDyuVgR2o2XbAy4tLhRVum3bxOoCOeE6YbJC37eN2e8Dvg5Diq8t1Ae5f1qxvagHlFhi6pWKQttZr3/xSmNxbxN029O5pG8BbR+XYTMfdd8WOzvB2idd4a73UlC0dw1wwjBWDOBGgV++9+cN82ldk/ahY4LPOnJbFHNAe+BvV/HCgMqDCTPV+gCOEMGJXelxyxchK7pV0rqcTbuGkMa3ImM3jiE3VC0oDob2FPAwB3Szqu3yO6D2L5Dziwi88Nb/ingXAAkiUrPttQzn0HSUoDG1+HTdDO7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/FQ5aefnFbZhQoTLDP01AUQwzU/rDIZwgBG3/MvsuE=; b=WR4e5RTBAOHBcaMcudtqj5W2dJbF/ZDM924Rn1KljzHzu0eB2DN27a/5Vt7MJEtoMaLRPx4P8Hd5itvVh+8mrIo1CbwxOaqlDeVcE4cvvHMARNtJZnsBcYptH3/Uaz1R2FQtoiLBLdHG2jM3fzt6m/qs5iRbYGVSnMHbl1daPcUVNp7tj9BWJEHbZXO15ychlRzQtOSV76Ed/opvkMbucy1cS0GdUGX1wYVA45YBiM2Yjt757fV03na59jTY++dHPMim3REIutBjMivNFJojzuQlyRVqXbpGmHhSU/0dAwvBcyXzQLzif3iSrU0F9nTxLBBzn8axklS3dg9s/Vqn8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/FQ5aefnFbZhQoTLDP01AUQwzU/rDIZwgBG3/MvsuE=; b=lxgDwr/MX3/6mlQayHAqJG4FqDmDpZLJFcIw080yB811OUbB2TC76ngFmlhWD92eW42KCHDA1LQD/mOLhMNz6WHh/TupV8J1025IvBab68wIotV/b8WLQGnThx0K90b13E/VkCxE3MkFlqLfTt5KEEPqHv7ADQxca4GwoF0oRmk= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4393.eurprd07.prod.outlook.com (20.176.167.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.8; Tue, 9 Jul 2019 16:35:43 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 16:35:43 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Zi4CAADV0AA== Date: Tue, 9 Jul 2019 16:35:43 +0000 Message-ID: <850D0BC0-1068-4A13-9CEE-7751097171CA@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12d98dbd-c2ed-4aa8-7880-08d7048b7c93 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4393; x-ms-traffictypediagnostic: HE1PR07MB4393: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(376002)(346002)(366004)(189003)(199004)(5660300002)(36756003)(33656002)(66476007)(7736002)(66446008)(64756008)(66556008)(305945005)(73956011)(66946007)(6246003)(76116006)(14444005)(256004)(99286004)(478600001)(4326008)(2906002)(446003)(11346002)(2616005)(68736007)(44832011)(476003)(6916009)(86362001)(76176011)(25786009)(53936002)(81156014)(8676002)(186003)(102836004)(26005)(6506007)(4744005)(6436002)(81166006)(6512007)(229853002)(8936002)(14454004)(58126008)(316002)(6116002)(3846002)(486006)(6486002)(71200400001)(66066001)(71190400001)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4393; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gfsncJrZxLBcYBSkk9v0XWymDzVnAMwoe5NqRKWQ/xjdtd/f0vDn+myGaCM0c7BpcZLHIMvw3SgOxLQAPQ663/61hwuzijsIPGtRacRiNdohLKFxAluWr5Pyl5IUVFgJFwZCkydlI2I+g5IQ0AMc8bJx/rMOW6RbiNMrvgu1fM6u7xSYGmFhJ9ORTWjbyt/gYfDcSpscYzLla3lwiK7wOS44hnQa6mJ6YIsSSZmmFAMnkqjeKF8x/5jWM1uJ1Hlv70pikRUYJleMbDPAv8G5jia4aGOOFhHXb7nN9zGMPWoiSDzx5pZAbPNhGuCKjGDLgGgegrkt7hYe2SUqC4Em23CkzIMQUfXs1/ckfGvA0oii8rPT8VjChZwjIeXCc7iGZq+aEU0YkJTvNidupPWnU+KKxNHKhGp07heGRDPdedE= Content-Type: text/plain; charset="utf-8" Content-ID: <7526C82A24DAA44D8C2F59A068334BF8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12d98dbd-c2ed-4aa8-7880-08d7048b7c93 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 16:35:43.2379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4393 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:35:50 -0000 SGksDQoNCj4+Pj4gQXMgSSBzYWlkIGluIGFub3RoZXIgcmVwbHksIGlmIHlvdSBieSBkZWZhdWx0 IHBsYWNlIGEgUkVHSVNURVIgdG9rZW4gaW4gYSBub24tUkVHSVNURVIgcmVxdWVzdCB0aGUgdG9r ZW4gbWF5IHJlYWNoIHRoZSByZW1vdGUgcGVlciwgd2hpY2ggY291bGQgYmUgYSBzZWN1cml0eSBj b25jZXJuLg0KPj4+wqAgwqAgDQo+Pj7CoCDCoCBJIHdvdWxkIGxpa2UgdG8gaGVhciBtb3JlIGFi b3V0IHRoaXMuIElzIHRoZXJlIHNvbWV0aGluZyBhYm91dCB0aGUgdG9rZW4gDQo+Pj7CoCDCoCB0 aGF0IHJldmVhbHMgc3R1ZmYgdGhhdCBtaWdodCBub3QgYmUgc3VpdGFibGUgdG8gZXhwb3NlIHRv IGV2ZXJ5b25lPyBJIA0KPj4+wqAgwqAgcGVyc29uYWxseSBkb24ndCBrbm93LiBUaGlzIHNlZW1z IGxpa2Ugc29tZXRoaW5nIHRoYXQgb3VnaHQgdG8gYmUgDQo+Pj7CoCDCoCBkaXNjdXNzZWQgaW4g c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQo+Pj4NCj4+IFRoZSB0b2tlbiBpdHNlbGYgZG9lcyBu b3QgcmV2ZWFsIGFueXRoaW5nLA0KPsKgDQo+IFRoYXQgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZiB0 b2tlbi4NCj4gQSBKV1QgbWlnaHQgY29udGFpbiBkYXRhIHRoYXQgbXVzdCBiZSBwcm90ZWN0ZWQg Zm9yIHByaXZhY3kgcmVhc29ucy4NCsKgDQpDb3JyZWN0LiBNeSBtaXN0YWtlLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCg0K From nobody Tue Jul 9 09:55:39 2019 Return-Path: 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 E6D631201AA for ; Tue, 9 Jul 2019 09:55:36 -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 rcmy8F43N_p3 for ; Tue, 9 Jul 2019 09:55:35 -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 0A627120026 for ; Tue, 9 Jul 2019 09:55:34 -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 x69GtTew009993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Jul 2019 12:55:30 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> From: Paul Kyzivat Message-ID: <168b1354-b35b-edee-e5f9-d4ddbecfae40@alum.mit.edu> Date: Tue, 9 Jul 2019 12:55:29 -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: <87AD4BB8-CE77-4FD7-BB72-6643DF513058@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:55:37 -0000 On 7/9/19 12:28 PM, 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. > > The REGISTER request, and the token, will only reach the registrar. And any proxies on the path to the registrar. But if I send an INVITE, am challenged by the target of the INVITE, and then send the token in a retry of the INVITE then it only goes there, where it is supposed to go. How is that any different from the registrar case? Is it because I somehow trust the registrar more that I trust who I am calling? ISTM that what is more important is the relationship between the domain of the UAS I'm trying to contact and the realm of the challenge. (Do I think this server has any business claiming to be authenticate for this realm?) The other tricky part is deciding whether to send the cached credentials (token) in a new request that hasn't just immediately challenged. But note that the request "in response" to a challenge is indistinguishable from a request sent to the same target later other than by time delay. The security concerns should be the same. Sending the token to some other target before being challenged by that target is a different leap of faith, so has different concerns. My main point here is not to get you to explain it to me in this email thread. What I want is to see this discussed adequately in the security considerations of the document. If it isn't "safe" to send the token to everybody, then how do I decide who I can safely send it to? One partial answer might be: if a challenge results in asking the user to authenticate for the realm, then the user gets to decide if he wants to, and if so then the resulting token should be sent to the same target just then. But this doesn't address when the same token can be used preemptively later. That still needs discussion. Thanks, Paul From nobody Tue Jul 9 10:45:58 2019 Return-Path: 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 1E68E1200F7 for ; Tue, 9 Jul 2019 10:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 pBnGxhhElpSi for ; Tue, 9 Jul 2019 10:45:54 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A972412004E for ; Tue, 9 Jul 2019 10:45:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DaUqyYrN8R4DDedgq2D8xJsuGvvCGoXMfm6D76gi3B3PXOEHj9DtErLPJ8ishvTHr0a5sUjsg1xlVnVDl+ty6mjrbxV6f1aQSNQWm19TDQDMOipGhwFVfkaocb1Xm0OJD9I3EosbRJrDAtYSYzONEf54H7b2qxQ2BtRFs6PPyD8e30A3mJh+x5stluupmtOCxb5paH7qGJTN4v7ORNWr9RkeZB467x+s+n2Te4Cgs2GsFqpPGy0MDXBpkFXEqk/GLJQwFNJj8FFKVwrDMfvejg1aj1gX17sowVrd3R2LjZzlDBBvs+6l7WceqFhF0tBbiXOA1HqvJOGBbTOx8ZHs9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qQgzLaX84WLwegGuSdm/v4krXJ/aUFddTsY7bj6gtr8=; b=UH6c4+F25g1AfYUS5F5sfl8H6/Z2AjTFSto15rQ27uqLxQC4X7jzoZ1lVpF0qn8kaH6krQcNBBSFgOhFwUb8uxTWNZXr8rDqyEcJt3vNMdlJRrDAT1wI09EI/wiIrFR9cjJTzaNWDRb3L9F9BcsTzgAFOjW8LiJuSuoBVcwBmWuLw89OD05NKh4MlDGOCIifXdp6Vq0+WIPh4Kf/o8IB86a9Dr0X6249YawVDsKIXHFKUML6c2wLthmY6OovRU79OZijr5qTJtiWmLo4Tt8PNjZYcjzrTzgobywmyF5HyrAguhD/K3hb2Ue+N4X57rcNC+qoiobD1Nmq+uf4hJowjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qQgzLaX84WLwegGuSdm/v4krXJ/aUFddTsY7bj6gtr8=; b=gjxAc1OwJTPK1mPKZttS8Hgg2MGWALNeJ1Ca7gR5QpJeESWSFiYLqNfOK9glQCrhs7ha9aAyB1V1F8FlrZfibtJJyPzOmwyttv/Zs5T3N+PDFq7USTFwXlBrGAjfSYS3c6L24jy6wPKp2XPOrtT+0RQMZHD2kvnM2Cp3OX2ogug= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3114.eurprd07.prod.outlook.com (10.170.245.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 17:45:50 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 17:45:50 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXAA= Date: Tue, 9 Jul 2019 17:45:50 +0000 Message-ID: <607A513F-8616-4777-8B5E-59390E845709@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> In-Reply-To: <168b1354-b35b-edee-e5f9-d4ddbecfae40@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58d708ec-7572-475e-7f7d-08d704954873 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3114; x-ms-traffictypediagnostic: HE1PR07MB3114: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(376002)(366004)(189003)(199004)(66556008)(66946007)(44832011)(229853002)(68736007)(256004)(2171002)(2906002)(73956011)(76116006)(14444005)(102836004)(26005)(6506007)(66446008)(64756008)(186003)(7736002)(8676002)(81156014)(71190400001)(71200400001)(81166006)(53936002)(446003)(11346002)(486006)(5660300002)(86362001)(6246003)(6436002)(6116002)(6486002)(66476007)(6512007)(476003)(2616005)(3846002)(66066001)(2501003)(305945005)(33656002)(14454004)(110136005)(316002)(58126008)(478600001)(99286004)(76176011)(25786009)(8936002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3114; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Qr9yefmVgG9Cti4/pJOJOnIYyrsbE0NoNaJF+g+pkYYWy8g1lcNPbXHgLySDWz9U9pGWhfF4VTyaG3dFDISnBFVerpqCVmTyjoVoFMqW7zdU3oDC3teu4IfxHYYZKnwFSWtHJlpBbIWi7CXGq08ZJ3ZF5U9PBLtC5KlG1w0uq3BXS+ssMNjjrTsSz239yT6LAa+CwraMaOax/v+fWO1DMi0wA2Hl1+NxW6n1PAgVZQt5GWPj4hAWbX5tSG35dhs+6Bklr910cLwRvT7Hj6SNdlYyrXzCRRwUPHyZYMjsUZnZyZgBIqVKDSZu83iGgDOHyhSMUP05TyTj7+qtMAT7wepFhu8obQGKiw0Q1dklCJ5/kvBWgg+/zcY/OV8EIOL4B9WpccRN9ACENZmXBRPVQ5VSewOejsN6UWmEUDHeNDo= Content-Type: text/plain; charset="utf-8" Content-ID: <50D4CAE0E2AC654ABAC59D1D70184E40@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58d708ec-7572-475e-7f7d-08d704954873 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 17:45:50.6562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3114 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 17:45:57 -0000 SGksDQoNCj4+Pj4+PiBBcyBJIHNhaWQgaW4gYW5vdGhlciByZXBseSwgaWYgeW91IGJ5IGRlZmF1 bHQgcGxhY2UgYSBSRUdJU1RFUiB0b2tlbiBpbiBhIG5vbi1SRUdJU1RFUiByZXF1ZXN0IHRoZSB0 b2tlbiBtYXkgcmVhY2ggdGhlIHJlbW90ZSBwZWVyLCB3aGljaCBjb3VsZCBiZSBhIHNlY3VyaXR5 IGNvbmNlcm4uDQo+Pj4+PiAgICAgIA0KPj4+Pj4gICAgICBJIHdvdWxkIGxpa2UgdG8gaGVhciBt b3JlIGFib3V0IHRoaXMuIElzIHRoZXJlIHNvbWV0aGluZyBhYm91dCB0aGUgdG9rZW4NCj4+Pj4+ ICAgICAgdGhhdCByZXZlYWxzIHN0dWZmIHRoYXQgbWlnaHQgbm90IGJlIHN1aXRhYmxlIHRvIGV4 cG9zZSB0byBldmVyeW9uZT8gSQ0KPj4+Pj4gICAgICBwZXJzb25hbGx5IGRvbid0IGtub3cuIFRo aXMgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBvdWdodCB0byBiZQ0KPj4+Pj4gICAgICBkaXNj dXNzZWQgaW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQo+Pj4+PiAgICAgDQo+Pj4+IFRoZSB0 b2tlbiBpdHNlbGYgZG9lcyBub3QgcmV2ZWFsIGFueXRoaW5nLCBidXQgaW4gT0F1dGggdGhlIHRv a2VuIGlzIHVzZWQgdG8gYWNjZXNzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2UsIHNvIGl0IGlzIGNv bnNpZGVyZWQgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLg0KPj4+Pg0KPj4+PiBBcyBmYXIgYXMgSSBr bm93LCBPQXV0aCBmb3IgU0lQIGhhcyBvbmx5IGJlZW4gdXNlZCBmb3IgUkVHSVNURVIgcmVxdWVz dHMsIGJldHdlZW4gdGhlIFVBIGFuZCB0aGUgcmVnaXN0cmFyLiBJIGhhdmUgbmV2ZXIgaGVhcmQg YWJvdXQgYW55b25lIHVzaW5nDQo+Pj4+IGl0IGZvciBub24tUkVHSVNURVIgYXV0aGVudGljYXRp b24sIGFuZCBJIHdvbmRlciB3aGV0aGVyIHdlIGV2ZW4gbmVlZCB0byBjb3ZlciBpdCBpbiB0aGUg ZHJhZnQuIFdlIGNvdWxkIGxpbWl0IHRoZSBzY29wZSB0aGUgUkVHSVNURVIgcmVxdWVzdHMuDQo+ Pj4+IFRoZW4sIGlmIGFueW9uZSBldmVyIG5lZWRzIE9BdXRoIGZvciBub24tUkVHSVNURVIgcmVx dWVzdHMsIGEgc2VwYXJhdGUgZHJhZnQgY2FuIGJlIHdyaXR0ZW4uDQo+Pj4gICAgIA0KPj4+ICAg ICBZZXMsIHlvdSBjYW4gZG8gdGhhdCBpZiB5b3Ugd2lzaC4gQnV0IElTVE0gdGhhdCB0aGUgaXNz dWVzIGFyZSBsYXJnZWx5DQo+Pj4gICAgIHRoZSBzYW1lIHNvIEkgZG9uJ3Qga25vdyB3aHkgeW91 IHdvdWxkIGRvIHRoYXQuDQo+PiANCj4+IFRoZSBSRUdJU1RFUiByZXF1ZXN0LCBhbmQgdGhlIHRv a2VuLCB3aWxsIG9ubHkgcmVhY2ggdGhlIHJlZ2lzdHJhci4NCj4gICAgDQo+ICAgIEFuZCBhbnkg cHJveGllcyBvbiB0aGUgcGF0aCB0byB0aGUgcmVnaXN0cmFyLg0KICANClN1cmUsIGFuZCB0aGF0 IHdlIGRvIG5lZWQgdG8gY292ZXI6IHRoZSB0b2tlbiBuZWVkcyB0byBiZSBwcm90ZWN0ZWQuDQog IA0KPiAgICBCdXQgaWYgSSBzZW5kIGFuIElOVklURSwgYW0gY2hhbGxlbmdlZCBieSB0aGUgdGFy Z2V0IG9mIHRoZSBJTlZJVEUsIGFuZCANCj4gICAgdGhlbiBzZW5kIHRoZSB0b2tlbiBpbiBhIHJl dHJ5IG9mIHRoZSBJTlZJVEUgdGhlbiBpdCBvbmx5IGdvZXMgdGhlcmUsIA0KPiAgICB3aGVyZSBp dCBpcyBzdXBwb3NlZCB0byBnby4gSG93IGlzIHRoYXQgYW55IGRpZmZlcmVudCBmcm9tIHRoZSBy ZWdpc3RyYXIgDQo+ICAgIGNhc2U/IElzIGl0IGJlY2F1c2UgSSBzb21laG93IHRydXN0IHRoZSBy ZWdpc3RyYXIgbW9yZSB0aGF0IEkgdHJ1c3Qgd2hvIA0KPiAgICBJIGFtIGNhbGxpbmc/DQogIA0K SSBhc3N1bWUgbW9zdCBwZW9wbGUgdHJ1c3QgdGhlaXIgcmVnaXN0cmFyLiBJZiB5b3UgZG9uJ3Qs IHlvdSBvYnZpb3VzbHkgY2FuJ3QgdXNlIHRoZSBtZWNoYW5pc20uIFdlIGNhbiBmb3Igc3VyZSBh ZGQgdGV4dCB0byBjbGFyaWZ5IHRoYXQsIGlmIG5lZWRlZC4NCg0KQW5kLCB5b3UgY2FuIGZvciBz dXJlIGRlY2lkZSB0byB0cnVzdCB0aGUgb25lIHlvdSBhcmUgY2FsbGluZy4gQnV0LCBhZ2Fpbiwg SSBzdGlsbCB0aGluayB3ZSBjb3VsZCBsZWF2ZSB1c2VyLXRvLXVzZXIgYXV0aGVudGljYXRpb24g b3V0IG9mIHNjb3BlIG9mIHRoZSBkcmFmdC4gVGhlIHNjb3BlIGhhcyBiZWVuIHVzaW5nIE9BdXRo IGZvciByZWdpc3RyYXRpb25zIGZyb20gZGF5IG9uZSwgYW5kIHRoYXQgaXMgd2hhdCBwZW9wbGUg aGF2ZSBiZWVuIGFza2luZyBmb3IuIA0KDQpBbHNvLCBhZnRlciBwZW9wbGUgaGFkIHJhaXNlZCBp c3N1ZXMgd2l0aCB0aGUgcHJldmlvdXMgZHJhZnQsIHdlIGFncmVlZCB0byBvbmx5IG1vdmUgdGhl IGN1cnJlbnQgcGFydHMgaW50byB0aGUgbmV3IGRyYWZ0Lg0KDQo+ICAgIElTVE0gdGhhdCB3aGF0 IGlzIG1vcmUgaW1wb3J0YW50IGlzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZG9tYWlu IA0KPiAgICBvZiB0aGUgVUFTIEknbSB0cnlpbmcgdG8gY29udGFjdCBhbmQgdGhlIHJlYWxtIG9m IHRoZSBjaGFsbGVuZ2UuIChEbyBJIA0KPiAgICB0aGluayB0aGlzIHNlcnZlciBoYXMgYW55IGJ1 c2luZXNzIGNsYWltaW5nIHRvIGJlIGF1dGhlbnRpY2F0ZSBmb3IgdGhpcyANCj4gICAgcmVhbG0/ KQ0KPiAgICANCj4gICAgVGhlIG90aGVyIHRyaWNreSBwYXJ0IGlzIGRlY2lkaW5nIHdoZXRoZXIg dG8gc2VuZCB0aGUgY2FjaGVkIGNyZWRlbnRpYWxzIA0KPiAgICAodG9rZW4pIGluIGEgbmV3IHJl cXVlc3QgdGhhdCBoYXNuJ3QganVzdCBpbW1lZGlhdGVseSBjaGFsbGVuZ2VkLiBCdXQgDQo+ICAg IG5vdGUgdGhhdCB0aGUgcmVxdWVzdCAiaW4gcmVzcG9uc2UiIHRvIGEgY2hhbGxlbmdlIGlzIGlu ZGlzdGluZ3Vpc2hhYmxlIA0KPiAgICBmcm9tIGEgcmVxdWVzdCBzZW50IHRvIHRoZSBzYW1lIHRh cmdldCBsYXRlciBvdGhlciB0aGFuIGJ5IHRpbWUgZGVsYXkuIA0KPiAgICBUaGUgc2VjdXJpdHkg Y29uY2VybnMgc2hvdWxkIGJlIHRoZSBzYW1lLiBTZW5kaW5nIHRoZSB0b2tlbiB0byBzb21lIA0K PiAgICBvdGhlciB0YXJnZXQgYmVmb3JlIGJlaW5nIGNoYWxsZW5nZWQgYnkgdGhhdCB0YXJnZXQg aXMgYSBkaWZmZXJlbnQgbGVhcCANCj4gICAgb2YgZmFpdGgsIHNvIGhhcyBkaWZmZXJlbnQgY29u Y2VybnMuDQogICAgDQo+ICAgIE15IG1haW4gcG9pbnQgaGVyZSBpcyBub3QgdG8gZ2V0IHlvdSB0 byBleHBsYWluIGl0IHRvIG1lIGluIHRoaXMgZW1haWwgDQo+ICAgIHRocmVhZC4gV2hhdCBJIHdh bnQgaXMgdG8gc2VlIHRoaXMgZGlzY3Vzc2VkIGFkZXF1YXRlbHkgaW4gdGhlIHNlY3VyaXR5IA0K PiAgICBjb25zaWRlcmF0aW9ucyBvZiB0aGUgZG9jdW1lbnQuIElmIGl0IGlzbid0ICJzYWZlIiB0 byBzZW5kIHRoZSB0b2tlbiB0byANCj4gICAgZXZlcnlib2R5LCB0aGVuIGhvdyBkbyBJIGRlY2lk ZSB3aG8gSSBjYW4gc2FmZWx5IHNlbmQgaXQgdG8/DQo+DQo+ICAgIE9uZSBwYXJ0aWFsIGFuc3dl ciBtaWdodCBiZTogaWYgYSBjaGFsbGVuZ2UgcmVzdWx0cyBpbiBhc2tpbmcgdGhlIHVzZXIgDQo+ ICAgIHRvIGF1dGhlbnRpY2F0ZSBmb3IgdGhlIHJlYWxtLCB0aGVuIHRoZSB1c2VyIGdldHMgdG8g ZGVjaWRlIGlmIGhlIHdhbnRzIA0KPiAgICB0bywgYW5kIGlmIHNvIHRoZW4gdGhlIHJlc3VsdGlu ZyB0b2tlbiBzaG91bGQgYmUgc2VudCB0byB0aGUgc2FtZSB0YXJnZXQgDQo+ICAgIGp1c3QgdGhl bi4gQnV0IHRoaXMgZG9lc24ndCBhZGRyZXNzIHdoZW4gdGhlIHNhbWUgdG9rZW4gY2FuIGJlIHVz ZWQgDQo+ICAgIHByZWVtcHRpdmVseSBsYXRlci4gVGhhdCBzdGlsbCBuZWVkcyBkaXNjdXNzaW9u Lg0KICANCk9BdXRoIGFsbG93cyB5b3UgdG8gcmUtdXNlIHRoZSB0b2tlbiBhcyBtYW55IHRpbWVz IGFzIHlvdSB3YW50ICh1bnRpbCBpdCBleHBpcmVzKSBmb3IgdGhlIHNhbWUgc2VydmljZS4gU28s IGZvciBTSVAsIHJlLXVzaW5nIHRoZSB0b2tlbiBpbiBiaW5kaW5nIHJlZnJlc2ggUkVHSVNURVIg cmVxdWVzdHMgaXMgZmluZS4NCg0KQnV0LCB5b3Ugc2hvdWxkIG5vdCByZS11c2UgYSB0b2tlbiB5 b3UgZ290IGZvciBvbmUgInNlcnZpY2UiIChlLmcuLCB5b3VyIHJlZ2lzdHJhdGlvbiBhdXRoZW50 aWNhdGlvbikgd2l0aCBhbm90aGVyICJzZXJ2aWNlIiAoZS5nLiwgdXNlci10by11c2VyIGF1dGhl bnRpY2F0aW9uIGZvciBhIFNJUCBjYWxsKS4gSXQgbW9zdCBsaWtlbHkgd291bGRuJ3QgZXZlbiB3 b3JrLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Tue Jul 9 11:28:16 2019 Return-Path: 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 D54561209F0 for ; Tue, 9 Jul 2019 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 YTd-iiJKfinM for ; Tue, 9 Jul 2019 11:28:13 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 E8F671209FB for ; Tue, 9 Jul 2019 11:28:04 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id ay6so10516706plb.9 for ; Tue, 09 Jul 2019 11:28:04 -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=L6hUfcOmd4z925Gi5B2eMrMUna7eMcVTQcV9ZBUF+Ds=; b=CC2ad+cjfB0jc8DnEY1YpqWG/sgdYNM5RCtfLy4vyZJIku3Nn3XsFyNcvDD2Eead7V bcyRLH+xn9CLkobTMaU37cJQWEXG68LkTEd+cJaLXaEPI7PdQZtqamYma2jGzviMe1Kk 6Fo8c07GrNnF28o9BTU/dUBoA5amvm/8Oo8jG/UYsCX8LOHFpxESJnS8BvsskMBQEYoT 8zVUTrO5doYsPqthpFuVord03cNtvHwe2iMhG5kEesV/6pky/ttq1nbrPoncm/slQ46Y SuyisjMbUkuPttBy2bEnpG2dDABdYqKjzyPVZlLLGxbZ5vMtpTtjPVBUnNwrIyhP+J6h 5iOw== 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=L6hUfcOmd4z925Gi5B2eMrMUna7eMcVTQcV9ZBUF+Ds=; b=Br0KD+0s6HPIM1n/cz6EK3otx6sZxx1tKW4VqR8kEa1EpxjhTj5Sd7Sxq7Xv3GgOGr //PBOBvgBcHoNiKw9iYFAWkssVtEaSp2qMxFfDSAA2ZmMCGlo5YIgQl/Nhu4Q/szoLGk A9G05NFaqNj0+c8OqnBCWgotEP79ItdOdt9TzF7PX5lmp/TKHF/EOai9ZC9LrSTKqU5r hh2s9Tj3Lteobq70CyPrBsrCVPyGZMDlohji8BuGmjWZhG/nu6FBzzPgHgJCg2RRl5FQ oxNVgOhYXwIJhgE/MNvqujNWPylw1xEtGM8LB6DRbYHNJKopAE5PrHpvkbxuYlJ/nK3O dylQ== X-Gm-Message-State: APjAAAXaVnOzxjP5pPZ7iygiuSIV5nNZf1Hv6Q1r0EhnVAOkPiwhmENy 3jQ57abbK2E/ksXHYHYJtGMVLkwLf24= X-Google-Smtp-Source: APXvYqy2GrPK5TK9F/4TKVT4yMU0UPOMJLswDcapFOz1JZ5wzGSCmkGCb6I570KfMKNr/MLjpaG5GA== X-Received: by 2002:a17:902:2a29:: with SMTP id i38mr33996464plb.46.1562696883950; Tue, 09 Jul 2019 11:28:03 -0700 (PDT) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com. [209.85.215.169]) by smtp.gmail.com with ESMTPSA id k6sm22118940pfi.12.2019.07.09.11.28.02 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 11:28:02 -0700 (PDT) Received: by mail-pg1-f169.google.com with SMTP id g15so9875885pgi.4 for ; Tue, 09 Jul 2019 11:28:02 -0700 (PDT) X-Received: by 2002:a65:55c2:: with SMTP id k2mr32145443pgs.217.1562696881923; Tue, 09 Jul 2019 11:28:01 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> From: Roman Shpount Date: Tue, 9 Jul 2019 14:27:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000089ec93058d43b829" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 18:28:14 -0000 --00000000000089ec93058d43b829 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 11:43 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > 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. > > Really? Normally, for a secure solution, every SIP request, including requests sent by UA in dialog established from the server to the registered end point must be authenticated. OAuth for REGISTRER requests only is kind of useless since it does not allow UA to send any messages to the server without some additional authentication mechanism. Best Regards, _____________ Roman Shpount --00000000000089ec93058d43b829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 11:43 AM C= hrister Holmberg <chri= ster.holmberg@ericsson.com> wrote:
As far a= s I know, OAuth for SIP has only been used for REGISTER requests, between t= he UA and the registrar. I have never heard about anyone using it for non-R= EGISTER authentication, and I wonder whether we even need to cover it in th= e draft. We could limit the scope the REGISTER requests. Then, if anyone ev= er needs OAuth for non-REGISTER requests, a separate draft can be written.<= br>
=C2=A0
Really? Normally, for a secure so= lution, every SIP request, including requests sent by UA in dialog establis= hed from the server to the registered end point must be authenticated. OAut= h for REGISTRER requests only is kind of useless since it does not allow UA= to send any messages to the server without some additional authentication = mechanism.

Best Regards,
_____________
Roman Shpount
<= br>
=C2=A0
--00000000000089ec93058d43b829-- From nobody Tue Jul 9 12:11:26 2019 Return-Path: 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 7E63F120386 for ; Tue, 9 Jul 2019 12:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Bc3WKXA16Pit for ; Tue, 9 Jul 2019 12:11:22 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::630]) (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 548A212004A for ; Tue, 9 Jul 2019 12:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aRJvHvey70o7Eos0FBX7WZSknm6pwjwuNg9Us/IppcOwTr19KcqhEubSZKkuJyUBjVxEdnLFR9QawkMR6A9iYQ2uixBjqw+1kyM0l6N29Ao7OfZTswsLvdaujPyKyQa02/EUshasWrNUD7c0GjHUH34N4t72azlR2Har2qE3/KHSvI6tXTD45xPVG/TqREhAmu7cDJCLfvNKTpo820Jv0saW4uEg55z5Ew6HUZFXFIVbe8jJ+ujvD5UbW+dYAmY5s9WzMy1VxZ+tno9CPVhw/o/sAbL6gAb1MOnF6qAqTc7Li0kuPDQhgEPzd1yA67oW9EpVr8xnEWhsHMyooGMvBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0APNWAErfOYuDCYjKTOj1UhQwC2B91g53lIVVmUUbT8=; b=aG04F67WEh8JmH7IC6RCMEo11ae+ymhZ7JECdIgO7cbkmR4/5Xos8fHbLPpvYvcEfueUQ5by66MAuP37mWCmsa8l4ZWSFLrbHRgZ4dJln+h2otXpLD3BSZzn21cK9PVkYDDL8EE81DIs/LXkIJXDIuMGHguDLTog0b08iUAAmcwEnQSvgFC1K/TKa38O9sCRKtP4pnuT8wX29SQBrt0H8tVrRsphwTjoGfuMN8ZHmt73kLakRd2bsUcFdu2YiyHgu1usK4dZru9AMwwHeRM2ufGzzO5ISJlpzXvnRGw25Cg1m0j3PmaXKVhu4pw05PbsXcIxvVvMQlFSvDffckQffg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0APNWAErfOYuDCYjKTOj1UhQwC2B91g53lIVVmUUbT8=; b=Zm4uu97813xIS47eWxZyWoiKZy0YhDkp9lDmraXYW6ut8a4dieICvK9IWhHxsbU3CUPYZaPvJWsolupZD0twTyk4XgAGyTzzDtI/ExBnm6erkDl8T40JsZ0Cjkl5jPqg4UafyW6yb/e8I8uxVcqWjGKKPjdDBWFPB3dCHoR7jsU= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3481.eurprd07.prod.outlook.com (10.170.247.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.9; Tue, 9 Jul 2019 19:11:19 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 19:11:19 +0000 From: Christer Holmberg To: Roman Shpount CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0A== Date: Tue, 9 Jul 2019 19:11:19 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [62.113.190.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d79b6d49-9bbd-4b99-a1a1-08d704a13971 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3481; x-ms-traffictypediagnostic: HE1PR07MB3481: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(346002)(376002)(366004)(199004)(189003)(102836004)(26005)(9686003)(55016002)(99286004)(186003)(86362001)(14444005)(7696005)(6506007)(66066001)(6436002)(54906003)(478600001)(71190400001)(71200400001)(316002)(4326008)(76176011)(256004)(229853002)(33656002)(25786009)(66476007)(64756008)(66556008)(73956011)(76116006)(66446008)(66946007)(14454004)(6246003)(5660300002)(6916009)(53936002)(8936002)(476003)(52536014)(2906002)(11346002)(486006)(4744005)(68736007)(7736002)(3846002)(6116002)(74316002)(305945005)(8676002)(81156014)(81166006)(446003)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3481; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EURKD+u4KQABhq8eJj76knShA0cNt2+W0zferLHXGO988x/XK2bm6HLkPFepT8E8jWbsWH+kVQ9igRlgKwT4beJMNWtsKpDuwKi+AeqsPAYD0WGpRgdDZfiPGiQpZCiI3Qh2Gjg5TlxVAUNmU7K/vY8EbGEkxjlwhPyvUOXfFnPQAuSXAJ1HibWWrAFLlc4V71M6USUOXJbXVVCecoaymnND/ATQ5286zyQUOwHiZ+CgrZitJkqNdK+WI07azXfCsq/+zgFtJtNz9qEy1IfhWKfB/C8Xj5j1k5evjyZ1a9IwvVMX9jUWS4u7WfiNg7VymMySJZ2esY4k+jFPle4aS0wLLp7rlxT4GDLm+1mQa+EZy/XlU+4pEX8aY6OgXLDKSze9yGias9o+cOr4cCXTGP3dQ8FSfcZYYAsGVbxb1hU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d79b6d49-9bbd-4b99-a1a1-08d704a13971 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 19:11:19.4859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3481 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 19:11:24 -0000 SGksDQoNCj4+IEFzIGZhciBhcyBJIGtub3csIE9BdXRoIGZvciBTSVAgaGFzIG9ubHkgYmVlbiB1 c2VkIGZvciBSRUdJU1RFUiByZXF1ZXN0cywgYmV0d2VlbiB0aGUgVUEgYW5kIHRoZSByZWdpc3Ry YXIuIA0KPj4gSSBoYXZlIG5ldmVyIGhlYXJkIGFib3V0IGFueW9uZSB1c2luZyBpdCBmb3Igbm9u LVJFR0lTVEVSIGF1dGhlbnRpY2F0aW9uLCBhbmQgSSB3b25kZXIgd2hldGhlciB3ZSBldmVuIG5l ZWQgDQo+PiB0byBjb3ZlciBpdCBpbiB0aGUgZHJhZnQuIFdlIGNvdWxkIGxpbWl0IHRoZSBzY29w ZSB0aGUgUkVHSVNURVIgcmVxdWVzdHMuIFRoZW4sIGlmIGFueW9uZSBldmVyIG5lZWRzIE9BdXRo IGZvciBub24tUkVHSVNURVIgcmVxdWVzdHMsIGEgc2VwYXJhdGUgZHJhZnQgY2FuIGJlIHdyaXR0 ZW4uDQo+wqANCj4gUmVhbGx5PyBOb3JtYWxseSwgZm9yIGEgc2VjdXJlIHNvbHV0aW9uLCBldmVy eSBTSVAgcmVxdWVzdCwgaW5jbHVkaW5nIHJlcXVlc3RzIHNlbnQgYnkgVUEgaW4gZGlhbG9nIGVz dGFibGlzaGVkIGZyb20gdGhlIA0KPiBzZXJ2ZXIgdG8gdGhlIHJlZ2lzdGVyZWQgZW5kIHBvaW50 IG11c3QgYmUgYXV0aGVudGljYXRlZC4gT0F1dGggZm9yIFJFR0lTVFJFUiByZXF1ZXN0cyBvbmx5 IGlzIGtpbmQgb2YgdXNlbGVzcyBzaW5jZSBpdCANCj4gZG9lcyBub3QgYWxsb3cgVUEgdG8gc2Vu ZCBhbnkgbWVzc2FnZXMgdG8gdGhlIHNlcnZlciB3aXRob3V0IHNvbWUgYWRkaXRpb25hbCBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc20uDQoNCk5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgInNlY3Vy ZSBzb2x1dGlvbiIsIGJ1dCBVQXMgY2FuIHN0aWxsIHVzZSBTSVAgRGlnZXN0IGF1dGhlbnRpY2F0 aW9uLg0KDQpXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQgb25seSB1c2UtY2FzZSBmb3IgU0lQIE9B dXRoIEkgYW0gYXdhcmUgb2YgaXMgZm9yIFJFR0lTVEVSLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQrCoA0K From nobody Tue Jul 9 12:29:30 2019 Return-Path: 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 DF7F5120362 for ; Tue, 9 Jul 2019 12:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 fSeZqg1EDAwW for ; Tue, 9 Jul 2019 12:29:28 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 D778D12012A for ; Tue, 9 Jul 2019 12:29:28 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id w10so9948491pgj.7 for ; Tue, 09 Jul 2019 12:29:28 -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=MSam9XvUh4V5J7Kt74pcQ6HcC3MtUvGgoLtLbNIWSjE=; b=IjcJI9lp+UcRoW0mbyTMFDLhwXYCEwEtBuS5rUiLJESKnVRQYBA9Vs7rHOPGU8sn75 PGWq00ic0mEjz9YreZvS4Ju0JDRlCRTIwmp/EwOP/rfiwbkKraCTW1kDtJ0zqED2tzWe OKB7bXfYdY49zdiVcXO6Z67rscMrU3ag/MSQTFDuovogTG3LlxnDg8peTeXcewW2lCOs 25MxHHhkvIa2RI9mba5nFVNCHQwIObyLoAZYgEEMMvHYMJKJbx0c8UsxjHFvTripWRwv ZpIGVoHnYctSICM7mDvlS3gYIFMaVwpGLP8Ka86RUrM/iDiNKunTbjIhPoA8Tv/IqljT f9VQ== 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=MSam9XvUh4V5J7Kt74pcQ6HcC3MtUvGgoLtLbNIWSjE=; b=Ikrvq0sbk8wFitOBH5SDTRH2keCE+hNzPw67Udmmh/KUiX5mwBli5Rw43iRIsjwLR9 jsRW0RbRoEcWPVfPZheEYPgmml9g8iSEIgYQqZtZcsbvVy9fPtY/IaRzAbFc6k5fJt9l iKk7JjjQYYnJhUC2WmobJyiiKASgQX7RaZvabAGyn2XqCVj0a0gN1je/FCDR0FdXsvSR GscpANQwwAcoCVS04bkKzeVwxXliwTmAqIljuJOOcecgVyq/zbAs5w/j1FjZc7O+MAwy zwAbFsz+64Q0a2HP6CF7sTpz+dTsKHeVtwz0VxhuKBFsLnXT1OKe1fv3DeHm1KKFM3nX vDHA== X-Gm-Message-State: APjAAAVbkwXg6ie1/Sj3D5UNjt6UmAowuMua9222t5O60h2ohYsgjEsf lq4BFPpnUQOXYa1Hur6lC+toysHSBIE= X-Google-Smtp-Source: APXvYqy1D6n8XBTxpDkr4k1Scl/QTU4fdoWB81T4XhoxmoOnxVPDvbFw8yc75b2SpsF2MdNSdo/CiQ== X-Received: by 2002:a63:460c:: with SMTP id t12mr32343468pga.69.1562700567958; Tue, 09 Jul 2019 12:29:27 -0700 (PDT) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com. [209.85.214.175]) by smtp.gmail.com with ESMTPSA id a15sm17922835pgw.3.2019.07.09.12.29.26 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 12:29:27 -0700 (PDT) Received: by mail-pl1-f175.google.com with SMTP id a93so10604275pla.7 for ; Tue, 09 Jul 2019 12:29:26 -0700 (PDT) X-Received: by 2002:a17:902:a413:: with SMTP id p19mr28636244plq.134.1562700566671; Tue, 09 Jul 2019 12:29:26 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 15:29:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ab6dd058d449487" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 19:29:30 -0000 --0000000000002ab6dd058d449487 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >> 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. > > > > Really? Normally, for a secure solution, every SIP request, including > requests sent by UA in dialog established from the > > server to the registered end point must be authenticated. OAuth for > REGISTRER requests only is kind of useless since it > > does not allow UA to send any messages to the server without some > additional authentication mechanism. > > Not sure what you mean by "secure solution", but UAs can still use SIP > Digest authentication. > > What I am saying is that only use-case for SIP OAuth I am aware of is for > REGISTER. > > How do they get these SIP Digest credentials? I am looking at a very simple SIP-Over-Websockets client scenario: User logs into the web site which uses OAuth. UA, running in the browser gets a token which is used to Register UA with a SIP proxy. What credentials is UA using to place a call (send INVITE to the proxy)? If a call comes in from the proxy to UA, what credentials is UA using to hang up the call (send BYE message)? Best Regards, _____________ Roman Shpount --0000000000002ab6dd058d449487 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 3:11 PM Ch= rister Holmberg <chris= ter.holmberg@ericsson.com> wrote:
>> As= far as I know, OAuth for SIP has only been used for REGISTER requests, bet= ween the UA and the registrar.
>> I have never heard about anyone using it for non-REGISTER authenti= cation, and I wonder whether we even need
>> to cover it in the draft. We could limit the scope the REGISTER re= quests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separ= ate draft can be written.
>=C2=A0
> Really? Normally, for a secure solution, every SIP request, including = requests sent by UA in dialog established from the
> server to the registered end point must be authenticated. OAuth for RE= GISTRER requests only is kind of useless since it
> does not allow UA to send any messages to the server without some addi= tional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still us= e SIP Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is for R= EGISTER.

How do they get these SIP Digest credenti= als?

I am looking at a very simple SIP-Over-Websoc= kets client scenario:

User logs into the web site = which uses OAuth. UA, running in the browser gets a token which is used to = Register UA with a SIP proxy.

What credentials is = UA using to place a call (send INVITE to the proxy)?=C2=A0
If a c= all comes in from the proxy to UA, what credentials is UA using to hang up = the call (send BYE message)?

Best Regards,
__= ___________
Roman Shpount
<= div>=C2=A0
--0000000000002ab6dd058d449487-- From nobody Tue Jul 9 13:00:41 2019 Return-Path: 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 4CDA6120ADF for ; Tue, 9 Jul 2019 13:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 SDIUmnFwZCbm for ; Tue, 9 Jul 2019 13:00:27 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10043.outbound.protection.outlook.com [40.107.1.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B5B120A46 for ; Tue, 9 Jul 2019 13:00:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EUgWjvTNcq9bsY0TSZZxgQezCunpPSQlGUSIk3MrJat5pCfvE/c+YzX0ygT4rwaZTnl4sVaRdtS9ItE+StRTr9p0UXdMCzR4YcKG4/88yjjv6lo42qGUDOaIu2Ql+PbR9n5S/tqKdbSEzBFN3RlgpwgydYm2KgDGHR1CmYODIW0p9HbnnqP97Ca64ApCINkJo/IcQxsGUhIGUNFlJ1hUxLjitArlAgwT96ZGqawRJN+Hdb96EddhxUhVELkck7bsohoZeqvL4Qa1YAxzsMvcIa43DOwxxSPWv1wbSx1O4pS2c2LGLuV1vTv9svs3cui310wXh64Q0kylH/AgHQW5wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MoI3AXBakPdgW+wnZyzTsEm8cJeSnYUG17C5mB7MOYI=; b=JFmTWh4lRo0g2tCzJa/yU+JiIiqjkDL/n9D29/bhdBwmcc5hsNQKntbyQzE3LhSkwir0DxXDP64+LO58A3X6NLt0vwOyAzOTq2/J1OCCleDTW5s03ra+zDkz82rpSBgfOkGBKttYFKCy0fQWZYP8EL+FOaWyZSu/E30jtYq7sed9SC5z5Jz8k5go94zX2aODKPQOeGH3s1S5+v3yBS0nCasJ2bWcGPE5aNSJ+VVXpnxefXCL4N53BjOFkdOLk1fEZHt+PqZU8bMBJ40C+1YyVEGPLutl0gjtTO5LhimtnsD840MaunMQLK+wZmXoiK9bXnNzk3L48KiNOJiSS/lJzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MoI3AXBakPdgW+wnZyzTsEm8cJeSnYUG17C5mB7MOYI=; b=hJm5Q+NOlpkVxvdgBJP2D9zFniTyP3L6s4vvG/lL6CT7lloyXNcJ/Gwljm543XFCDC3FW6CowTlUWNCQRaiebf1EvAnLZSNpoFOR4HT105FOqM3d5Yua+07jc5mUddHxrp7Uj8qZk/YirmbXvfIest/udezxGhScV0wf+6G8vls= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4428.eurprd07.prod.outlook.com (20.176.167.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Tue, 9 Jul 2019 20:00:23 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Tue, 9 Jul 2019 20:00:23 +0000 From: Christer Holmberg To: Roman Shpount CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAADBKA= Date: Tue, 9 Jul 2019 20:00:23 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [62.113.190.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ce1528c3-2cbd-498c-2587-08d704a81452 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4428; x-ms-traffictypediagnostic: HE1PR07MB4428: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0093C80C01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(366004)(199004)(189003)(52536014)(26005)(7696005)(76176011)(6506007)(8676002)(186003)(99286004)(66446008)(64756008)(66556008)(66476007)(102836004)(86362001)(5660300002)(25786009)(2906002)(53936002)(66574012)(4326008)(14454004)(3846002)(8936002)(6116002)(6246003)(6436002)(71200400001)(71190400001)(14444005)(9686003)(55016002)(256004)(33656002)(316002)(44832011)(54906003)(6916009)(486006)(81166006)(66946007)(11346002)(476003)(446003)(81156014)(76116006)(7736002)(74316002)(229853002)(66066001)(68736007)(305945005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4428; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IZJ02HM5/w1JFYmLk85o1vWyjRUwveoj1JS/lbeucHzwpAIeD+h+G9gEIVJqAKXtmza06n3thwTzatIB0VJSG7fR4b5NIgHxi5NIDFUuwrSOcoPA1NZ2sAbTwdCOlEqLVMnftYpiVXfVlA2Jy5FQdEdwfeU+Ec3NGMiUGv5BQ4DvkzAp/waPm7YiPjGdiTntpuarZbe9r9q4HvIn8EvVwtl3dqpMpDgaC9pfqi92zcUBZkiBhf+UE5KcOyBYokvT/W7w5SwuRv4xQ6H+ZZLaslvG1q31P3IoQpAgsEFxiDtDKfzzHwEH30lx8/76c6fu4UofIpO5cts/cPobhXr/YEyFl0sms3HvhDFkRdovLZp4Ly583fNmYyGttbQYRsqiJ1HoRG0VaZOsmpECB+Nl0Y7T1K7y7PTz/H31mPXaIgU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce1528c3-2cbd-498c-2587-08d704a81452 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2019 20:00:23.6929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4428 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 20:00:36 -0000 SGksDQoNCj4+Pj4gQXMgZmFyIGFzIEkga25vdywgT0F1dGggZm9yIFNJUCBoYXMgb25seSBiZWVu IHVzZWQgZm9yIFJFR0lTVEVSIHJlcXVlc3RzLCBiZXR3ZWVuIHRoZSBVQSBhbmQgdGhlIHJlZ2lz dHJhci4gDQo+Pj4+IEkgaGF2ZSBuZXZlciBoZWFyZCBhYm91dCBhbnlvbmUgdXNpbmcgaXQgZm9y IG5vbi1SRUdJU1RFUiBhdXRoZW50aWNhdGlvbiwgYW5kIEkgd29uZGVyIHdoZXRoZXIgd2UgZXZl biBuZWVkIA0KPj4+PiB0byBjb3ZlciBpdCBpbiB0aGUgZHJhZnQuIFdlIGNvdWxkIGxpbWl0IHRo ZSBzY29wZSB0aGUgUkVHSVNURVIgcmVxdWVzdHMuIFRoZW4sIGlmIGFueW9uZSBldmVyIG5lZWRz IE9BdXRoIGZvciBub24tUkVHSVNURVIgcmVxdWVzdHMsIGEgc2VwYXJhdGUgZHJhZnQgY2FuIGJl IHdyaXR0ZW4uDQo+Pj7CoA0KPj4+IFJlYWxseT8gTm9ybWFsbHksIGZvciBhIHNlY3VyZSBzb2x1 dGlvbiwgZXZlcnkgU0lQIHJlcXVlc3QsIGluY2x1ZGluZyByZXF1ZXN0cyBzZW50IGJ5IFVBIGlu IGRpYWxvZyBlc3RhYmxpc2hlZCBmcm9tIHRoZSANCj4+PiBzZXJ2ZXIgdG8gdGhlIHJlZ2lzdGVy ZWQgZW5kIHBvaW50IG11c3QgYmUgYXV0aGVudGljYXRlZC4gT0F1dGggZm9yIFJFR0lTVFJFUiBy ZXF1ZXN0cyBvbmx5IGlzIGtpbmQgb2YgdXNlbGVzcyBzaW5jZSBpdCANCj4+PiBkb2VzIG5vdCBh bGxvdyBVQSB0byBzZW5kIGFueSBtZXNzYWdlcyB0byB0aGUgc2VydmVyIHdpdGhvdXQgc29tZSBh ZGRpdGlvbmFsIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbS4NCj4+DQo+PiBOb3Qgc3VyZSB3aGF0 IHlvdSBtZWFuIGJ5ICJzZWN1cmUgc29sdXRpb24iLCBidXQgVUFzIGNhbiBzdGlsbCB1c2UgU0lQ IERpZ2VzdCBhdXRoZW50aWNhdGlvbi4NCj4+DQo+PiBXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQg b25seSB1c2UtY2FzZSBmb3IgU0lQIE9BdXRoIEkgYW0gYXdhcmUgb2YgaXMgZm9yIFJFR0lTVEVS Lg0KPg0KPiBIb3cgZG8gdGhleSBnZXQgdGhlc2UgU0lQIERpZ2VzdCBjcmVkZW50aWFscz8NCj4N Cj4gSSBhbSBsb29raW5nIGF0IGEgdmVyeSBzaW1wbGUgU0lQLU92ZXItV2Vic29ja2V0cyBjbGll bnQgc2NlbmFyaW86DQo+DQo+IFVzZXIgbG9ncyBpbnRvIHRoZSB3ZWIgc2l0ZSB3aGljaCB1c2Vz IE9BdXRoLiBVQSwgcnVubmluZyBpbiB0aGUgYnJvd3NlciBnZXRzIGEgdG9rZW4gd2hpY2ggaXMg dXNlZCB0byBSZWdpc3RlciBVQSB3aXRoIGEgU0lQIHByb3h5Lg0KDQpXb3VsZG4ndCAgeW91IHVz ZSBPQXV0aCB0byBlc3RhYmxpc2ggdGhlIFdlYlNvY2tldCBjb25uZWN0aW9uPw0KDQo+V2hhdCBj cmVkZW50aWFscyBpcyBVQSB1c2luZyB0byBwbGFjZSBhIGNhbGwgKHNlbmQgSU5WSVRFIHRvIHRo ZSBwcm94eSk/wqANCj5JZiBhIGNhbGwgY29tZXMgaW4gZnJvbSB0aGUgcHJveHkgdG8gVUEsIHdo YXQgY3JlZGVudGlhbHMgaXMgVUEgdXNpbmcgdG8gaGFuZyB1cCB0aGUgY2FsbCAoc2VuZCBCWUUg bWVzc2FnZSk/DQoNCklmIHRoZSByZWdpc3RyeSBhbmQgdGhlIGNhbGwgaGFuZGxpbmcgaXMgcGFy dCBvZiB0aGUgc2FtZSBzZXJ2aWNlIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB0aGUgc2FtZSBjcmVk ZW50aWFscywgYXNzdW1pbmcgMzI2MSBnZW5lcmFsbHkgYWxsb3dzIHVzaW5nIHRoZSBzYW1lIGNy ZWRlbnRpYWxzIGZvciByZWdpc3RyYXRpb25zIGFuZCBjYWxscy4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KDQo= From nobody Tue Jul 9 14:16:53 2019 Return-Path: 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 5FF1D1200C7 for ; Tue, 9 Jul 2019 14:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 y_olFjTFaOtC for ; Tue, 9 Jul 2019 14:16:49 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 7281312006F for ; Tue, 9 Jul 2019 14:16:49 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id j6so97862ioa.5 for ; Tue, 09 Jul 2019 14:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LqLxrhekE+RTwYEOhIxmp2o/w3P+C3N/F78AmdKyFxI=; b=KKyqW52fgw//pQIeHLSiOcFrNq7S9LtszUAWGijdYQ8cYMMtC2hz6TnksltTdowOU4 gja3zeij6HeasaObDz788RFXLmIpvFeW2Ix88Kh1dwcPFGaUhgIkownigDksckSpflEW vaANAfeLyjsiSg2LRNofpP7AeXmzRcX+N5qIuM4b4y7AeJTqWOsI+/zfpJVcemdEXAVY E27UyvY9ZYe8AMQSpK6A5B53R7XJ4VdhprbaHaaRitSlBf7EolJD87/Zm8e/ZrQTAQve UnsojST4sVyLV0T3ah/32OuToy0cmXDWbLVTFbXNoIIeebQzfbiC0adh/T5+bKjLz5zi HWkA== 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=LqLxrhekE+RTwYEOhIxmp2o/w3P+C3N/F78AmdKyFxI=; b=XaCEuu9wQ0wV5iOKgrKIgbQoJTMfOrSInnzVyosSZOaZQKIxY6Gwxnc0AqnusDV7np f57vGBYPaEbapKPXVabaN/8Gns3C3phOxXpfFzVP+4qCpBl6v8rgwBHqACl2IStLG/5D I9GrYbh4mZb7ZnihSmlfEFcKcE89/aWJVstatMnm7wjH1613xxQ4q74hdLZxzrQTMjwB kRl9HwcxvHa1oeDRHRajMpDlsjsumQduSDwGknBB7KnvrhfRU8sTNwPbB58AgRU41v3U V0nzcEx9B9YnzUqQ8wHdKH7mKOfUL5GBjlcCR7clBq39QeDpe1yQFLh+KaBt4u+X0QRH gWWA== X-Gm-Message-State: APjAAAUNEHjp4HWhFWJFZAg76XOcir/jCXgEPX2TFgWDP9pRYH++E6AF xCcmXlw9M9E5l7U7vf9TK2Gn2Ams2hY1pujwWaQ= X-Google-Smtp-Source: APXvYqxHnwwOhtvG74oFOzWNp2+DVIKa4ZkKBKrwD3aZXRqxnmUHFwDMTB556xq/kumbFWlsFXbRxrwaxBt1gmfXkxg= X-Received: by 2002:a5d:9282:: with SMTP id s2mr1691632iom.36.1562707008790; Tue, 09 Jul 2019 14:16:48 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 9 Jul 2019 17:16:39 -0400 Message-ID: To: Roman Shpount Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000025a475058d46144d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 21:16:51 -0000 --00000000000025a475058d46144d Content-Type: text/plain; charset="UTF-8" This document is specifically focused on *confidential *UAs. UAs running in the browser, public UAs, will be addressed in a separate document. Regards, Rifaat On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount wrote: > On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >> 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. >> > >> > Really? Normally, for a secure solution, every SIP request, including >> requests sent by UA in dialog established from the >> > server to the registered end point must be authenticated. OAuth for >> REGISTRER requests only is kind of useless since it >> > does not allow UA to send any messages to the server without some >> additional authentication mechanism. >> >> Not sure what you mean by "secure solution", but UAs can still use SIP >> Digest authentication. >> >> What I am saying is that only use-case for SIP OAuth I am aware of is for >> REGISTER. >> >> How do they get these SIP Digest credentials? > > I am looking at a very simple SIP-Over-Websockets client scenario: > > User logs into the web site which uses OAuth. UA, running in the browser > gets a token which is used to Register UA with a SIP proxy. > > What credentials is UA using to place a call (send INVITE to the proxy)? > If a call comes in from the proxy to UA, what credentials is UA using to > hang up the call (send BYE message)? > > Best Regards, > _____________ > Roman Shpount > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00000000000025a475058d46144d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This document is specifically focused on confidential <= /b>UAs.
UAs running in the browser, public UAs, will be addressed in a = separate document.

Regards,
=C2=A0Rifaat=


On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount <roman@telurix.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg <christer.holmberg@er= icsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">>> 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 authenti= cation, and I wonder whether we even need
>> to cover it in the draft. We could limit the scope the REGISTER re= quests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separ= ate draft can be written.
>=C2=A0
> Really? Normally, for a secure solution, every SIP request, including = requests sent by UA in dialog established from the
> server to the registered end point must be authenticated. OAuth for RE= GISTRER requests only is kind of useless since it
> does not allow UA to send any messages to the server without some addi= tional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still us= e SIP Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is for R= EGISTER.

How do they get these SIP Digest credenti= als?

I am looking at a very simple SIP-Over-Websoc= kets client scenario:

User logs into the web site = which uses OAuth. UA, running in the browser gets a token which is used to = Register UA with a SIP proxy.

What credentials is = UA using to place a call (send INVITE to the proxy)?=C2=A0
If a c= all comes in from the proxy to UA, what credentials is UA using to hang up = the call (send BYE message)?

Best Regards,
__= ___________
Roman Shpount
=C2=A0
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000025a475058d46144d-- From nobody Tue Jul 9 15:57:59 2019 Return-Path: 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 83086120075 for ; Tue, 9 Jul 2019 15:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 LaicivLRnkO1 for ; Tue, 9 Jul 2019 15:57:56 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 722A5120059 for ; Tue, 9 Jul 2019 15:57:56 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id b7so142517pls.6 for ; Tue, 09 Jul 2019 15:57:56 -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=rDMUCjZzZPiBa7WlDRmUm5QWCJKFZVrLe2Gj9ntswVM=; b=sYiMO/JKxDiuRmhf8OquCx682tZo0480j1uim9qUUV2sPCNS9aYG+ErmUeACX3XBmu abeOddC8MDjHcjoB2GObBOfJJzZMODbD9NU4cNwOJtKHD6E1VZOG+KK1XyYT/8F+hwqp lgWrE9mV1hyhUI2Bei/akbnMhsII6CYpzRUHaEXC41lHSpVj5mVmsNSUnipRXBmNeg8B vKPndLvwEh9Ar4OwehxWfxGZQ584GihhBXLuShi+d2iMceuka9WwkDUL83y5RtZZ6sr+ hWZl63lBpy+/XQowRr8Owq4HKeu1GDGee1TkwOoGbeIFu0Zmq5dKU5fKeIgoTBRE5Pgb QqFg== 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=rDMUCjZzZPiBa7WlDRmUm5QWCJKFZVrLe2Gj9ntswVM=; b=pSOmAVVzHJprPatR4rzwCnOg88lzBk4KXvvfGQjDjAZtVnMnr2oBgKW/ZdK7SmoiB3 gqWE/SBZx6N92diCVAiRt/0rk5lRvWRl6z5SFj6c0G4Vj1GZedOzyL0nSXlHCdOLfbfB /TJrms6MPKug6egTpBOKvbV8vVaTYlwc9/PvsP8ztIx8Xy8ryCw4UgRPrEYeFJEasN98 CYgPahPvOYx6HuCNbLEC5FBgtwdmJ2EChAfb+1e75sbaw56Tkxm421nbCOEpkWXBcFe4 b/JOJJLuwV8wKrAvneYAKBgKpinFgKqpsbjI+QMKrPn/qmklAEMYrVs+zr8LBRmj1Ltn +vAA== X-Gm-Message-State: APjAAAW0hi5cvtav3kMz5ddjsXjAxoF3A/+edIxrmjfZH1D/j17bHDHs s6GbGLWReIDNEDYv2HdM2ekWpsf8hrw= X-Google-Smtp-Source: APXvYqxM9TcymqmIK0nq12yenXOMxQFIZ1NVKjzcPkmVQxTqStkd4uasEDuKBSj5tTf2aV4UShZBng== X-Received: by 2002:a17:902:2aab:: with SMTP id j40mr33474010plb.76.1562713075654; Tue, 09 Jul 2019 15:57:55 -0700 (PDT) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com. [209.85.215.181]) by smtp.gmail.com with ESMTPSA id p15sm139958pjf.27.2019.07.09.15.57.54 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 15:57:54 -0700 (PDT) Received: by mail-pg1-f181.google.com with SMTP id q4so183006pgj.8 for ; Tue, 09 Jul 2019 15:57:54 -0700 (PDT) X-Received: by 2002:a17:90a:b104:: with SMTP id z4mr2816084pjq.102.1562713074138; Tue, 09 Jul 2019 15:57:54 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 18:57:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ab8459058d477d36" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 22:57:58 -0000 --000000000000ab8459058d477d36 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 4:00 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >>>> 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. > >>> > >>> Really? Normally, for a secure solution, every SIP request, including > requests sent by UA in dialog established from the > >>> server to the registered end point must be authenticated. OAuth for > REGISTRER requests only is kind of useless since it > >>> does not allow UA to send any messages to the server without some > additional authentication mechanism. > >> > >> Not sure what you mean by "secure solution", but UAs can still use SIP > Digest authentication. > >> > >> What I am saying is that only use-case for SIP OAuth I am aware of is > for REGISTER. > > > > How do they get these SIP Digest credentials? > > > > I am looking at a very simple SIP-Over-Websockets client scenario: > > > > User logs into the web site which uses OAuth. UA, running in the browser > gets a token which is used to Register UA with a SIP proxy. > > Wouldn't you use OAuth to establish the WebSocket connection? > No, WebSocket connection is to a different server and typically does not require authentication. In this specific case, I was thinking OpenSIPS with SIP-over-WS support. Implementing OAuth authentication of SIP message would be trivial there, but OAuth authentication for WebSocket would be much less obvious. >What credentials is UA using to place a call (send INVITE to the proxy)? > >If a call comes in from the proxy to UA, what credentials is UA using to > hang up the call (send BYE message)? > > If the registry and the call handling is part of the same service I guess > you could use the same credentials, assuming 3261 generally allows using > the same credentials for registrations and calls. > Are you saying using OAuth token authentication for calls (INVITE) and in dialog messages (BYE)? _____________ Roman Shpount --000000000000ab8459058d477d36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 4:00 PM Ch= rister Holmberg <chris= ter.holmberg@ericsson.com> wrote:
>>>= ;> As far as I know, OAuth for SIP has only been used for REGISTER reque= sts, 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 REG= ISTER requests. Then, if anyone ever needs OAuth for non-REGISTER requests,= a separate draft can be written.
>>>=C2=A0
>>> Really? Normally, for a secure solution, every SIP request, in= cluding requests sent by UA in dialog established from the
>>> server to the registered end point must be authenticated. OAut= h for REGISTRER requests only is kind of useless since it
>>> does not allow UA to send any messages to the server without s= ome additional authentication mechanism.
>>
>> Not sure what you mean by "secure solution", but UAs can= still use SIP Digest authentication.
>>
>> What I am saying is that only use-case for SIP OAuth I am aware of= is for REGISTER.
>
> How do they get these SIP Digest credentials?
>
> I am looking at a very simple SIP-Over-Websockets client scenario:
>
> User logs into the web site which uses OAuth. UA, running in the brows= er gets a token which is used to Register UA with a SIP proxy.

Wouldn't=C2=A0 you use OAuth to establish the WebSocket connection?
=
=C2=A0
No, WebSocket connection is to a differe= nt server and typically does not require authentication. In this specific c= ase, I was thinking OpenSIPS with SIP-over-WS support. Implementing OAuth a= uthentication of SIP message would be trivial there, but OAuth authenticati= on for WebSocket would be much less obvious.

>What credentials is UA using to= place a call (send INVITE to the proxy)?=C2=A0
>If a call comes in from the proxy to UA, what credentials is UA using t= o hang up the call (send BYE message)?

If the registry and the call handling is part of the same service I guess y= ou could use the same credentials, assuming 3261 generally allows using the= same credentials for registrations and calls.

Are you saying using OAuth token authentication for calls (INVITE) = and in dialog messages (BYE)?
_____________
Roman Shpount
=C2=A0
--000000000000ab8459058d477d36-- From nobody Tue Jul 9 16:00:06 2019 Return-Path: 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 19AD0120059 for ; Tue, 9 Jul 2019 16:00:04 -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 DX-7noNda-Ad for ; Tue, 9 Jul 2019 16:00:02 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 CE9C7120019 for ; Tue, 9 Jul 2019 16:00:02 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id z75so192739pgz.5 for ; Tue, 09 Jul 2019 16:00:02 -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=N/HLNOg7Twa4A3BHdsFDGR6dxB04WcsKvS6/EMPT2Po=; b=IjmEf2EBeu2x0HqK9ghpS8dZC7DNewKEZJDhBmy8GhPoaQCcMNok0MrAh5yK/ea+jT 6uANmNgrmC9/ytR9/oWWzl2QL36O7PQeN27AMGWjD3sVhAcTl9U5rFoIgiUO5wz1/0n0 PhuIf+dYrrIdAg1icWg2IuE2dVlvZpX8LOt+mS7xjiJTD3exryMebes1oAEJb5xhSncI BPN3WWpXBynvPBmahQPKZNL1dlw2SBfmab7fH3JvhkVQmjiHpEOcaDl2ELgdQKrVSOK4 45B6kFqrxgzWyyVze8YVI6WuGlccyYhWrAlmbN3Dd+T24wCThPYW7T6ywWt//Xntj1Zn RsNQ== 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=N/HLNOg7Twa4A3BHdsFDGR6dxB04WcsKvS6/EMPT2Po=; b=FOyIbAhhyl59vkwEMZYLjIphQ9wNhQkthOrwbhbNYuNVmVj9sMmm2MYSeLQ0nRj0OG TVb7PZ7VRTct3jaEIsxE6GRp/dqY4Ni8XCiX9w99ytQzQa9DxvpY8KD4udhB64J3G3za NvkSUawJ0A0JgNMWjTQlFkN6SzSjzLafFgOBwP3y1G+FYuwbjqUH3kntt7jI2WWIlLfH 2nsSkDbts06YOneXTL8l2vwLfog58oschaDrw0rWSnsN0oqEGlUWoyzIdMQGubUo2KW3 b5wjrU0TyxJ2w/9luHv2tAPFBzX7Dvg6sLXU90L9DnU/kVjibQPoclSe124rtxZHH1jn LccQ== X-Gm-Message-State: APjAAAXYJi+w7zdmxe3TDjTqp/jCpRhVHU6daIioHFO5Kw/XKizLjvG8 NtztEbYf0RH0sOidrftfu1cmuLGcmyE= X-Google-Smtp-Source: APXvYqx7DAl2zx+E99zk2RbKuOsKY/IVec1J0zV0lRBcm7/cZp0Qr+eHiZBwZ9xN6t63v4w11EBS6Q== X-Received: by 2002:a63:101b:: with SMTP id f27mr32055595pgl.291.1562713201934; Tue, 09 Jul 2019 16:00:01 -0700 (PDT) Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com. [209.85.210.170]) by smtp.gmail.com with ESMTPSA id m101sm154437pjb.7.2019.07.09.16.00.01 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 16:00:01 -0700 (PDT) Received: by mail-pf1-f170.google.com with SMTP id b13so97447pfo.1 for ; Tue, 09 Jul 2019 16:00:01 -0700 (PDT) X-Received: by 2002:a63:7a06:: with SMTP id v6mr33623057pgc.115.1562713200671; Tue, 09 Jul 2019 16:00:00 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 18:59:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000363f98058d4785ca" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 23:00:04 -0000 --000000000000363f98058d4785ca Content-Type: text/plain; charset="UTF-8" Hi Riffat, On Tue, Jul 9, 2019 at 5:16 PM Rifaat Shekh-Yusef wrote: > This document is specifically focused on *confidential *UAs. > UAs running in the browser, public UAs, will be addressed in a separate > document. > Can you provide a real life example of confidential UA using OAuth for registration only and not generating calls or sending any messages in dialog (or using different authentication method for these actions)? I cannot quite figure out what this is. Thank You, _____________ Roman Shpount --000000000000363f98058d4785ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Riffat,

<= /div>
On Tue, Jul 9, 2019 at 5:16 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
This docum= ent is specifically focused on confidential UAs.
UAs running in = the browser, public UAs, will be addressed in a separate document.

Can you provide a real life example of = confidential UA using OAuth for registration only and not generating calls = or sending any messages in dialog (or using different authentication method= for these actions)?

I cannot quite figure out wha= t this is.

Thank You,
_____________
Roman = Shpount
=C2=A0
--000000000000363f98058d4785ca-- From nobody Tue Jul 9 16:18:00 2019 Return-Path: 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 226B91200C5 for ; Tue, 9 Jul 2019 16:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JFfEVm0x2tub for ; Tue, 9 Jul 2019 16:17:56 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 B9D78120059 for ; Tue, 9 Jul 2019 16:17:56 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u19so609491ior.9 for ; Tue, 09 Jul 2019 16:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HyNqaWC2HOlIOD8mZjmnMM+7uRxlLiNddl+Y9/iL2t4=; b=YqPVsaap3UWb8THf1uQNrOvdVRrEkZDx6VkKASYu4thLmbgiXI2Z0d0fnMRvsfYOG5 B3TLfJisNQ6AiJvxr47JZAQW7/OLI9AkBNXgEIoaEvC/jfPavIt+f49E5LC3dx4IojVa tsLtjkVJ6LFVdTP16sSFWQLNMI6NeSy3vFLJnOlAzfwscok1Q/HLsy3vG8EY8etV/g/y s4Gct8aEi672did9HjldVodAUlVbZ1PQrTBLV+IkV69eKSELH740kDEr91uVg1OKYeMM nSaLhDwUGDS9o7mMJe0DJt4IWnW+8u39iXNfwKowmbSrAuryK6KR6yuHghGIjdUwJ8d1 HKaA== 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=HyNqaWC2HOlIOD8mZjmnMM+7uRxlLiNddl+Y9/iL2t4=; b=YfY5QdDS4GIFOBIjZsNEBHogszPu2xKI+Mw4LcqOgNTrWYKF+dC7q3tNisCw+mVSDm FWHV2drZ5/u0HLtW1uZ9Ppl/eyYvB5klxhZ5utpslWb+czIYucN77aujekcyQ6dX2xwD ujqEmgFGNnuk0WABYLJNzuSRmKUELb1kZW92JFAN40UbdIzB/dr9PiI+rPNgLGjgoYwq zfRLs9nbNojUWDLTHowh8uau5CyfuT46ZA9m1ITTd10Y1rEoRpgCPdOdrV5N1cteg+B2 /sQo3sag0oEGeo33vythPbx1krv/BMl2FPHVPrO4tSGhjVT4a1SWtGdrIn/k+b6g0NHz UQYQ== X-Gm-Message-State: APjAAAU4e7S4En57tviQIx/xlgkMdRHcXp/MEzG6Pv/VlKWPoVpnGxae IgGMvfKbTIkIfQqeeX4TVNxosKpJcwqweJPXM4A= X-Google-Smtp-Source: APXvYqyWC+gQtL+nxWhvgh39pe1sre4TnPaC6mhb62N8yjfSy4IV/RgQeVN+D/ATEumFAyVtHYlcRVQtny6hOhiucj0= X-Received: by 2002:a5e:d618:: with SMTP id w24mr28617529iom.73.1562714275108; Tue, 09 Jul 2019 16:17:55 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 9 Jul 2019 19:17:45 -0400 Message-ID: To: Roman Shpount Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000040db28058d47c5f6" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 23:17:58 -0000 --00000000000040db28058d47c5f6 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 7:00 PM Roman Shpount wrote: > Hi Riffat, > > On Tue, Jul 9, 2019 at 5:16 PM Rifaat Shekh-Yusef > wrote: > >> This document is specifically focused on *confidential *UAs. >> UAs running in the browser, public UAs, will be addressed in a separate >> document. >> > > Can you provide a real life example of confidential UA using OAuth for > registration only and not generating calls or sending any messages in > dialog (or using different authentication method for these actions)? > What? why do you think that is the case? How did you get to the conclusion that the UA will not be able to make a call? Regards, Rifaat > > I cannot quite figure out what this is. > > Thank You, > _____________ > Roman Shpount > > --00000000000040db28058d47c5f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 9, 2019 at 7:00 PM Roman = Shpount <roman@telurix.com> = wrote:
Hi Riffat,

On Tue, = Jul 9, 2019 at 5:16 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
This do= cument is specifically focused on confidential UAs.
UAs running = in the browser, public UAs, will be addressed in a separate document.
=

Can you provide a real life example = of confidential UA using OAuth for registration only and not generating cal= ls or sending any messages in dialog (or using different authentication met= hod for these actions)?

W= hat? why do you think that is the case?
How did you get to the co= nclusion that the UA will not be able to make a call?

<= div>Regards,
=C2=A0Rifaat
=C2=A0

I cannot quite figure out what this is.
Thank You,
_____________
Roman Shpount
=C2=A0
<= /div>
--00000000000040db28058d47c5f6-- From nobody Tue Jul 9 16:27:40 2019 Return-Path: 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 584EB120075 for ; Tue, 9 Jul 2019 16:27:38 -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 Fafoc9stnvXJ for ; Tue, 9 Jul 2019 16:27:37 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 1B878120024 for ; Tue, 9 Jul 2019 16:27:37 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id c2so156350plz.13 for ; Tue, 09 Jul 2019 16:27:37 -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=jUQk7h72dQliIoxplSg6uGCmR/pGKkMxf1CWrQmO1Ao=; b=Fb2tsXk1mpvN8id2Yl1pJwWuHLe+I7TJfQdyZZanxZSEPx5FOCFbAeAUABsZgMdnef wSXVaeB9IiQ5zLbRhnTecX6MjDglna2QX3bTcsVAhb9E/DQZ22TDNqTAJOHx2kEj1aC/ Eyys8d8ZhDFRE4iMzmWJd35ZUJPlyMCRFkk3RFl8AFCfuyh4qQo9u5S2KMTAlYVMJMI8 fBVmu/OHc6gB3QTqHzF0MrrB6S8OiEcUW0F77iK4KlLfOFGZ/pe0EBhaXB8janjaiJTb vY8cK2xKwaDO2ulBf3I0/kH1SDzvIjq6UgPm4oBiZZ9SL8YQfDqXXRCt1i98uc29g2IJ 5XRw== 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=jUQk7h72dQliIoxplSg6uGCmR/pGKkMxf1CWrQmO1Ao=; b=DDkRPrW82IhUb0EvEE0QqNi182m1cbTvOYvEuwxrSB+OybUjpxIdN0FYVXxHy37ksp TUKvTQE5BH0VJZEo+uB1xvRGtFp3ZQJZSeJvhhFQlnKIg5GTprN//hoKjtVW+HTS7s/5 6czab3QoJyLFeAon5jqL4ioEkWOou9+2U3Ss4zyTOkvCCKf92Aj+qZu8DDQHZ17o3R7d XWf6GTi3Svb7tZBz9thr92mJ13P2Vce/gpAbFofCM8y3YGtKfEqY5AM6y+SXX0tljSbG 1bZhD5MXLOziFovnc3BqwHVjbAhcxko5FNNHOZSEFeklpZD2APRt81yLwaZ3q2vd+/LJ LRLw== X-Gm-Message-State: APjAAAWbbpJKR3ZEoT8Lei4lKRcFRBFva5+N5B7QaqU7qQRMIsoVoTUF gH5mfykzotjwOzO/X3MlyLpSfdGGjmc= X-Google-Smtp-Source: APXvYqxybBEEHWblxMO4rlNrI3JerkSaqYEmHt+NDGHhIGoXUrYkr2DP8TrSAjsGF15BfnztO/A64g== X-Received: by 2002:a17:902:2868:: with SMTP id e95mr32875807plb.319.1562714855258; Tue, 09 Jul 2019 16:27:35 -0700 (PDT) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com. [209.85.215.182]) by smtp.gmail.com with ESMTPSA id i15sm161275pfd.160.2019.07.09.16.27.34 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 16:27:34 -0700 (PDT) Received: by mail-pg1-f182.google.com with SMTP id o13so203937pgp.12 for ; Tue, 09 Jul 2019 16:27:34 -0700 (PDT) X-Received: by 2002:a17:90a:b104:: with SMTP id z4mr2949778pjq.102.1562714853764; Tue, 09 Jul 2019 16:27:33 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 19:27:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be740d058d47e7e9" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 23:27:38 -0000 --000000000000be740d058d47e7e9 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 7:17 PM Rifaat Shekh-Yusef wrote: > Can you provide a real life example of confidential UA using OAuth for >> registration only and not generating calls or sending any messages in >> dialog (or using different authentication method for these actions)? >> > > What? why do you think that is the case? > How did you get to the conclusion that the UA will not be able to make a > call? > > Quoting Christer: 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. So, I am trying to understand the use case where: 1. UA is confidential 2. OAuth is used for registration only 3. Other messages are not sent or different authentication method is used for them, i.e. calls and in dialog messages are not initiated or initiated using a different authentication method. So far, I cannot figure out what this is. Best Regards, _____________ Roman Shpount --000000000000be740d058d47e7e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 7:17 PM Ri= faat Shekh-Yusef <rifaat.ietf@g= mail.com> wrote:
Can you provide a real life exampl= e of confidential UA using OAuth for registration only and not generating c= alls or sending any messages in dialog (or using different authentication m= ethod for these actions)?

What? why do you think that is the case?
How did you get to the = conclusion that the UA will not be able to make a call?

=C2=A0
Quoting Christer:

<= div>As far as I know, OAuth for SIP has on= ly been used for REGISTER requests, between the UA and the registrar. I hav= e never heard about anyone using it for non-REGISTER authentication, and I = wonder whether we even need to cover it in the draft.=C2=A0
=C2=A0
So, I = am trying to understand the use case where:

1. UA = is confidential
2. OAuth is used for registration only
= 3. Other messages are not sent or different authentication method is used f= or them, i.e. calls and in dialog messages are not initiated or initiated u= sing a different authentication method.

So far, I = cannot figure out what this is.

Best Regards,
_____________
Roman Shp= ount

=C2=A0
--000000000000be740d058d47e7e9-- From nobody Tue Jul 9 17:30:49 2019 Return-Path: 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 05048120306 for ; Tue, 9 Jul 2019 17:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gtynjbIk1_BB for ; Tue, 9 Jul 2019 17:30:39 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 5C1B512011C for ; Tue, 9 Jul 2019 17:30:37 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id i10so844537iol.13 for ; Tue, 09 Jul 2019 17:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CkekE8di0C0G9VUFsll/Qyn8Hq4phDwRuium0NlES6M=; b=dESoGohSx3xPNFFrfmu+EfJkZczWzHQ4X0WCVIdud9Yxe0ny4lDztKZRs+MMKMlL3H /eXmQ8vQgbgrjJ/NjuRAEzmKX3wkB5uCntdGolONIzAUQQFoOOyRAukYSSjiIaSe6wkS VJDnOrqaswCLzGSLA3zRHvQXAGWFy861XvtwoA831nKtsbN+iAaDwnjzglYXSlCqjBUh J7X1Bt1qbT5uc8/4k0dpBbLqXvC2FFztjL6JhR/dfBelwbbGXIWcMMQqMteeNBLbXql/ YHK8+n2rSwLG/r+g1XrtUurDyKmc4MegJZA99wTLgesT88wPA7nBTdk9Y1R8wt5FQs9K hwUg== 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=CkekE8di0C0G9VUFsll/Qyn8Hq4phDwRuium0NlES6M=; b=dA4p+kSwfN+xGbaes/I79cSLxGNGjuRs1OqUyv/3Rer8ym8f6CTF6rSYyim5ceBYG9 GX81By3hV1cNH4XJCLugDDytY2GE6ZwWeuAc0sDRuSGkhzU49dRTsRQvWLsEKwAPSrjy +U0sSNWZmlUq59PF6itgplrntYn8FEZ1I83p26Mf6SyI2MVwnNjJKSkA4FnyD7jg5MOC LXMjYVT1Tbno1x8p9a7fGOfj9VL9tqAUf6Y17PSoNKfn0Wt3yQR3fDPsU5QvIQXWMSCh qfJuGlzQ8fnnyfaMzmVb3VJJZXKkvxl2wHaaZ6naHRT2Qxp3Oy0OLlBkmSds+RefQPd4 SkkQ== X-Gm-Message-State: APjAAAXZNkpfH9hJZW4b7lWgJ83UuR7hfuirzZccTWU7kEQt1W068569 WTe5sHDoc74XuRJSdZD4XpxYPIFs4CWnbOPiEhM= X-Google-Smtp-Source: APXvYqzfxdOVJqO5r4J+yexOpHRg2FVMUjE9oVVjyc8J++8mLcsr2UiKjN/ltcmC+jujSsnguUkQHi06reRqk3Hxz24= X-Received: by 2002:a5d:9642:: with SMTP id d2mr10808874ios.278.1562718636679; Tue, 09 Jul 2019 17:30:36 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 9 Jul 2019 20:30:26 -0400 Message-ID: To: Roman Shpount Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000392646058d48c976" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 00:30:47 -0000 --000000000000392646058d48c976 Content-Type: text/plain; charset="UTF-8" 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? Regards, Rifaat On Tue, Jul 9, 2019 at 7:27 PM Roman Shpount wrote: > On Tue, Jul 9, 2019 at 7:17 PM Rifaat Shekh-Yusef > wrote: > >> Can you provide a real life example of confidential UA using OAuth for >>> registration only and not generating calls or sending any messages in >>> dialog (or using different authentication method for these actions)? >>> >> >> What? why do you think that is the case? >> How did you get to the conclusion that the UA will not be able to make a >> call? >> >> > Quoting Christer: > > 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. > > > So, I am trying to understand the use case where: > > 1. UA is confidential > 2. OAuth is used for registration only > 3. Other messages are not sent or different authentication method is used > for them, i.e. calls and in dialog messages are not initiated or initiated > using a different authentication method. > > So far, I cannot figure out what this is. > > Best Regards, > _____________ > Roman Shpount > > > --000000000000392646058d48c976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The document clearly allows the use of access token to aut= henticate non-REGISTER requests when challenged in the context of the same = realm.

Whether that is needed or not is a different discu= ssion.
Assuming the UA was able to authenticate the = user and obtain an access token, then establish an authenticated TLS channe= l with the server, and register the user; is there a need for further chall= enges from server?

Regards,
=C2=A0Rifaat


=
On Tue, Ju= l 9, 2019 at 7:27 PM Roman Shpount <roman@telurix.com> wrote:
=
On Tue, Jul 9, 2019 at 7:17 PM Rifaat Shekh-Yusef &l= t;rifaat.ietf@gm= ail.com> wrote:
Can you provide a real life exampl= e of confidential UA using OAuth for registration only and not generating c= alls or sending any messages in dialog (or using different authentication m= ethod for these actions)?

What? why do you think that is the case?
How did you get to the = conclusion that the UA will not be able to make a call?

=C2=A0
Quoting Christer:

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.=C2=A0
=C2=A0
= So, I am trying to understand the use case where:

= 1. UA is confidential
2. OAuth is used for registration only
3. Other messages are not sent or different authentication method is = used for them, i.e. calls and in dialog messages are not initiated or initi= ated using a different authentication method.

So f= ar, I cannot figure out what this is.

Best Regards= ,
_____________
Roman Shpount

=C2=A0
--000000000000392646058d48c976-- From nobody Tue Jul 9 17:53:55 2019 Return-Path: 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 ; 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 ; 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 ; Tue, 9 Jul 2019 17:53:52 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id b13so210109pfo.1 for ; 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 (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 ; 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> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 20:53:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046d5c1058d491c8b" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 00:53:54 -0000 --00000000000046d5c1058d491c8b Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef 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 --00000000000046d5c1058d491c8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 8:30 PM Ri= faat Shekh-Yusef <rifaat.ietf@g= mail.com> wrote:
The documen= t clearly allows the use of access token to authenticate non-REGISTER reque= sts when challenged in the context of the same realm.

Whe= ther that is needed or not is a different discussion.
Assuming the UA was able to authenticate the user and obtain an access to= ken, then establish an authenticated TLS channel with the server, and regis= ter the user; is there a need for further challenges from server?


=
Typically, for SIP, user authentication is not tied to the TLS c= onnection. One of the reasons for this is that multiple users can use the s= ame TLS connection in federated systems. This is especially true for Confid= ential UA, which have trust relationship with a proxy and can maintain a se= cure connection to the registrar/proxy on behalf of multiple clients.
=

Once again, it would be much easier to discuss if you c= an 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 ide= a what OAuth with Confidential UA would be.=C2=A0

= The example I can think of, would be some sort of hot desk application, whe= re user allows a=C2=A0Local PBX to register with User Home PBX to accept ca= lls on behalf of user in a remote location. In this case, Local PBX and Use= r 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 h= ave a trust relationship, possibly with mutual TLS certificate authenticati= ons. A company wide directory server will be used to store actual user cred= entials and will be used to authenticate the user and generate the token.

Best Regards,
_____________
Roman Shpount
=C2=A0
--00000000000046d5c1058d491c8b-- From nobody Tue Jul 9 18:29:11 2019 Return-Path: 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 670D412013B for ; Tue, 9 Jul 2019 18:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 m9g_mVf8yNUJ for ; Tue, 9 Jul 2019 18:29:09 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 37F88120077 for ; Tue, 9 Jul 2019 18:29:09 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id j5so1124666ioj.8 for ; Tue, 09 Jul 2019 18:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Ji09Hkw2Wpjv9nYdB03KuK0SLYRJCI9CASPUcEnskw=; b=q+beUgqR2K00pwUjwzT8FtiE/GpSUwYN7gNLy6r2dlUM6ptxomUHDcZJQZcKZGJW1x sWpwA6twxwFl6Zc+p7OK2b7Miks0Zv9MHeEXBcvOXavBcD2wCIlbCadJ/aw4xQRIFKHJ i8hosFPkkfcvGSLvAbccv5Y0PYsekYiLr+i9Wrt3FQJ44F2VRCI8yqFGHjUiCS+6NvaI TdoxR88zLNU8phjCS0hgVowhpDQRK9JkImtgXF+Wd6UIjB52U1FMrSVmP7ZfAWdiFmFj ijPlgI/R2U2uCilRBGA1urYC78UKIXBQFrAxLgLpjJbsro85l4ltX//vzieKpRoGbM8u S/QA== 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=3Ji09Hkw2Wpjv9nYdB03KuK0SLYRJCI9CASPUcEnskw=; b=qJk+CDbYiVnxFUCuoMsxm4fLzU6t5vLE1sq4Ca1KRxmBNT8+GhQ6w/euZFq14IGNuC NxsQ633GwzSxLYHu1ZkbhJ1szroicWK3QSPSwJ2aXftS4e/3I9DVCH+bFPBi9sN10bzz xioMKaJEFbFeG5NDYhhoEuLPt824uxSuM9J93pUfGQ4/sufTOpuJdPzQyYJfTB0RprxY ArMP6ecHZsjRqUmvey2Cvip6jj7JN1wBhImor7AaljxBD/wzuLTJzCKl5lGYXxtMG4rP W8kCaEF+z95agTKE5mm/isvDYsY0lDR8DYN7s08b03Q5nC3G3PPacfzUgLdnuPbFkuoJ 2Ojw== X-Gm-Message-State: APjAAAWF3SfyJao/Ud9Y59k8/RP2tygm5Cr27qVhAJSH3TgyDyWFhdU3 ubXmP38o0xbYq6ex6hckaw8M4VAQAzZzfd6RxPM= X-Google-Smtp-Source: APXvYqw5iH2sNauHgwhx35d2r/CLZyedns/XLrVGYHRLqOYhAmDCQSx2p71sHRYacOgevqQucvtw9op8OSl5jCei4tM= X-Received: by 2002:a5d:9282:: with SMTP id s2mr2746669iom.36.1562722148559; Tue, 09 Jul 2019 18:29:08 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 9 Jul 2019 21:28:58 -0400 Message-ID: To: Roman Shpount Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008c3717058d499ab9" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 01:29:10 -0000 --0000000000008c3717058d499ab9 Content-Type: text/plain; charset="UTF-8" For me, the main motivation is SSO. The user would use one set of corporate credentials to authenticate, login to a deskphone, and get access to SIP and non-SIP services. I am not sure I am following your use case. How would the user authenticate and obtain a an access token in this case? Regards, Rifaat On Tue, Jul 9, 2019 at 8:53 PM Roman Shpount wrote: > On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef > 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 > > --0000000000008c3717058d499ab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For me, the main motivation is SSO.
The user would use= one set of corporate credentials to authenticate, login to a deskphone, an= d get access to SIP and non-SIP services.

I am not= sure I am following your use case.
How would the user authentica= te and obtain a an access token in this case?

Rega= rds,
=C2=A0Rifaat




On Tue, Jul 9, 2019 at 8:53 PM Roman Shpount <roman@telurix.com> wrote:
On Tue, = Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
The document clearly allows the use of acce= ss token to authenticate non-REGISTER requests when challenged in the conte= xt of the same realm.

Whether that is needed or not is a = different discussion.
Assuming the UA was able to au= thenticate the user and obtain an access token, then establish an authentic= ated TLS channel with the server, and register the user; is there a need fo= r further challenges from server?
<= br>

Typically, for SIP, u= ser authentication is not tied to the TLS connection. One of the reasons fo= r this is that multiple users can use the same TLS connection in federated = systems. This is especially true for Confidential UA, which have trust rela= tionship 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 f= or OAuth with confidential UA. I can easily think of a OAuth use case for P= ublic User Agent, but only have a vague idea what OAuth with Confidential U= A would be.=C2=A0

The example I can think of, woul= d be some sort of hot desk application, where user allows a=C2=A0Local PBX = to register with User Home PBX to accept calls on behalf of user in a remot= e location. In this case, Local PBX and User Home PBX will be federated sys= tems 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, possib= ly with mutual TLS certificate authentications. A company wide directory se= rver will be used to store actual user credentials and will be used to auth= enticate the user and generate the token.

Best Reg= ards,
_____________
Roman Shpount
=C2=A0
--0000000000008c3717058d499ab9-- From nobody Tue Jul 9 18:44:53 2019 Return-Path: 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 62167120048 for ; Tue, 9 Jul 2019 18:44:51 -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 e5lqQ2J1FXgq for ; Tue, 9 Jul 2019 18:44:50 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 220B312001E for ; Tue, 9 Jul 2019 18:44:50 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id t16so245534pfe.11 for ; Tue, 09 Jul 2019 18:44:50 -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=maiR/RE+hwn70ucZzZ+gWMc/U68JiEpKGGeZFFjJN2E=; b=HRFuVhtBxsetY5bZ4ITiZyb7SELyDTPhUVJI2uDLFI0x+xrOL1rLGB8do67nFZ+Af8 nm0u6t0jO+0I7+E5wW2Alah7K6yqKG59cnomDSJLUZ//15hecwsbVKkpSadviBHE9XXg Aj3hS2pO/44UAY9X7zQFqjzL3TXVau8M3AOYESDVI4Bi+z8jZwxdYczJrJ//jhG7q192 BGKAoslujEdDbUCEaBsAzb4VZPW+uTyKkEBfnwfBusRbcNfVQWsqCwarVNFpY3E3+RtS gurne6HfNqghvbCz6eef8RHRCJyM87kOzmj1t+ZgsVyPgw2b2Fk1Q2TGttZ8bxtF1uzQ MQWg== 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=maiR/RE+hwn70ucZzZ+gWMc/U68JiEpKGGeZFFjJN2E=; b=L3gazAxdSG12BNNsO8iSMCa9h3QpWYc5fHSzyAe9JxUJjDV2vJpJ3eqV8pRacE0CkC Sou6DAZtR57itcU5vciFNpX6Q/GdmFqKDvAndb4G68Jl9hbcUOOFtu14O9orseiC9ToX uqhC9CXX0VOtqbtc8hStkXzOl7QWYH9CksI4KNW19ojs6EDuXXb3eK5Wty0zbwM2YgMn UlON6EkoeGH3mx/WLo7ihMzw5nrkENPwa+aHcxjcvrdLV9cSfSndI4noHwscWakceI9V 0tt2qa7Zf5zDxyirOs1Lc4oY9lPu5pzXUmpOzB5MPXrIX8XPjWte4S+S2Ls4ajIS4SOD iMcg== X-Gm-Message-State: APjAAAWENJqGGP8pRWDlzthQFOsYLpf2XqjMtzhckRhPUck61aZtxMpS BSMCDGwqHRlHGQ/CKAsq7rSPkstQ X-Google-Smtp-Source: APXvYqyK9m7rLmy9/uvQuOws6FZf964Hro+u4/E+rtGg4mHIjDaT+VobK6w9wiek05Ar+mSy/1Yc8g== X-Received: by 2002:a17:90a:b903:: with SMTP id p3mr3465237pjr.79.1562723089055; Tue, 09 Jul 2019 18:44:49 -0700 (PDT) Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com. [209.85.215.178]) by smtp.gmail.com with ESMTPSA id j1sm312622pgl.12.2019.07.09.18.44.47 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 18:44:48 -0700 (PDT) Received: by mail-pg1-f178.google.com with SMTP id t132so356286pgb.9 for ; Tue, 09 Jul 2019 18:44:47 -0700 (PDT) X-Received: by 2002:a17:90a:bf92:: with SMTP id d18mr3661342pjs.128.1562723087010; Tue, 09 Jul 2019 18:44:47 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 21:44:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007bd160058d49d218" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 01:44:51 -0000 --0000000000007bd160058d49d218 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef wrote: > For me, the main motivation is SSO. > The user would use one set of corporate credentials to authenticate, login > to a deskphone, and get access to SIP and non-SIP services. > > I am not sure I am following your use case. > How would the user authenticate and obtain a an access token in this case? > > The use case is the same SSO in combination with hot desks and multiple PBXs. User picks a desk at a remote office, goes to a web page to login, enters his credentials and desk location. Expected result is that the phone on this temporary desk will ring when user gets a call on user's extension on the user home PBX. Internally, SSO system produces a token, which is sent to the PBX in the remote office. PBX in the remote office registers using this token with use home PBX, and configures that all the calls for this registration are forwarded to the phone on the user temporary desk. All the calls placed from that desk are also placed through user home PBX so that correct line is used and user home caller ID is displayed. Best Regards, _____________ Roman Shpount --0000000000007bd160058d49d218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2019 at 9:29 PM Rifaat She= kh-Yusef <rifaat.ietf@gmail.com= > wrote:
For me, the main motivation is = SSO.
The user would use one set of corporate credentials to authenticat= e, login to a deskphone, and get access to SIP and non-SIP services.
<= div>
I am not sure I am following your use case.
Ho= w would the user authenticate and obtain a an access token in this case?


The use case is th= e same SSO in combination with hot desks and multiple PBXs. User picks a de= sk at a remote office, goes to a web page to login, enters his credentials = and desk location. Expected result is that the phone on this temporary desk= will ring when user gets a call on user's extension on the user home P= BX. Internally, SSO system produces a token, which is sent to the PBX in th= e remote office. PBX in the remote office registers using this token with u= se home PBX,=C2=A0and configures that all the calls for this registration a= re forwarded to the phone on the user temporary desk. All the calls placed = from that desk are also placed through user home PBX so that correct line i= s used and user home caller ID is displayed.

Best = Regards,
_____________
Roman Shpount
=C2=A0
--0000000000007bd160058d49d218-- From nobody Tue Jul 9 18:59:08 2019 Return-Path: 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 8A7E3120096 for ; Tue, 9 Jul 2019 18:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E5XGccMEmjto for ; Tue, 9 Jul 2019 18:59:05 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 3D9CD120048 for ; Tue, 9 Jul 2019 18:59:05 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k20so1212227ios.10 for ; Tue, 09 Jul 2019 18:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iTFNtJaSpbz+P4EQ5acqkaIoHCZquoZxThHpmXv/Hso=; b=piL/0JwxQiG/7RKt4WQFYRQDpE98AiY6SZVOL/7HzR+7wu5jS1Aib6tKeEZWGcpUQI yHg/wje3B0pl8CNRrje1VwpU2RdzvrRZHtaopt6T86d5Yxa8XnF6OvtFT0KY/yzsspTH yzFdbYWp8y0Mzb+xnwUbOsjlgEvVs/GKy53qEm8Sj7qyfaUTzTeLZzcOlqXrqV10uVXi sFaQFXkFXobkxfWo5vBGDbnHC914+rHcJg8S9v3Lb/ol6R0ROlPElJwizvN8r9ROg7kV trUh9mQcjhNhfsFOOP5ffCYgekE48Jt2cHoSDasMH7MHQapLHkVp3L7/1w0kw1TjooCU ZkTg== 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=iTFNtJaSpbz+P4EQ5acqkaIoHCZquoZxThHpmXv/Hso=; b=J0/iSOb7eCTq7hjsOEDBKCsQg4SVDOLifiB2m1L65LPMg8j97a3xnjOerLGdjU4dk2 Z56drp66loNWcxLe6sUGkE0b1COXWPAVa4/dop7RmWDeo6Y9SVGzOkwrjmwVDn+TTltY No8H/pFVNNFVUvBya0qxXlenbiSbijfAAoI25O4yvys/p3iIW9bUU5oSmZGyaNZwtZup 547SxhXTyKU1hZaPDl88Lo/JSd2jKYxfRb0PbIDIMevQFQQ7EYUcLdtvN1v+Afe2bb1C P9mTjk6fTvv2NuFBmQKf+m1Q+SxygvEdwunmuzXbj9D1/ubsySP+n/AnDbH6sYvkM8iU 69pw== X-Gm-Message-State: APjAAAUy6UXJc9kuaXDQha2EjaW4sRpLCZsbkzVQ/ncZVM0NxnF6pt0l 6Ml3/TXToj8W4UfWAWa1nFA9cWLWl++G38MNhS0= X-Google-Smtp-Source: APXvYqxzOBMy/yJ1X4ZYdzez8oZGkeD6oXwCtj104fm7A3TX52LCXtpkPX4uRjYJNNk/cUssKEKcOTZcaUd3NzszLc4= X-Received: by 2002:a5d:9642:: with SMTP id d2mr11195701ios.278.1562723944415; Tue, 09 Jul 2019 18:59:04 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 9 Jul 2019 21:58:54 -0400 Message-ID: To: Roman Shpount Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000096c9ab058d4a05db" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 01:59:07 -0000 --00000000000096c9ab058d4a05db Content-Type: text/plain; charset="UTF-8" Such a use case is not covered by this document, and is out of scope. Regards, Rifaat On Tue, Jul 9, 2019 at 9:44 PM Roman Shpount wrote: > On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef > wrote: > >> For me, the main motivation is SSO. >> The user would use one set of corporate credentials to authenticate, >> login to a deskphone, and get access to SIP and non-SIP services. >> >> I am not sure I am following your use case. >> How would the user authenticate and obtain a an access token in this case? >> >> > The use case is the same SSO in combination with hot desks and multiple > PBXs. User picks a desk at a remote office, goes to a web page to login, > enters his credentials and desk location. Expected result is that the phone > on this temporary desk will ring when user gets a call on user's extension > on the user home PBX. Internally, SSO system produces a token, which is > sent to the PBX in the remote office. PBX in the remote office registers > using this token with use home PBX, and configures that all the calls for > this registration are forwarded to the phone on the user temporary desk. > All the calls placed from that desk are also placed through user home PBX > so that correct line is used and user home caller ID is displayed. > > Best Regards, > _____________ > Roman Shpount > > --00000000000096c9ab058d4a05db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Such a use case is not covered by this document, and is ou= t of scope.

Regards,
=C2=A0Rifaat

On Tue, Jul 9, 2019 at 9:44 PM Roman Shpount <roman@telurix.com> wrote:
On Tu= e, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
For me, the main motivation is SSO.
The user wou= ld use one set of corporate credentials to authenticate, login to a deskpho= ne, and get access to SIP and non-SIP services.

I = am not sure I am following your use case.
How would the user auth= enticate and obtain a an access token in this case?


The use case is the same SSO in combina= tion with hot desks and multiple PBXs. User picks a desk at a remote office= , goes to a web page to login, enters his credentials and desk location. Ex= pected result is that the phone on this temporary desk will ring when user = gets a call on user's extension on the user home PBX. Internally, SSO s= ystem produces a token, which is sent to the PBX in the remote office. PBX = in the remote office registers using this token with use home PBX,=C2=A0and= configures that all the calls for this registration are forwarded to the p= hone on the user temporary desk. All the calls placed from that desk are al= so placed through user home PBX so that correct line is used and user home = caller ID is displayed.

Best Regards,
_______= ______
Roman Shpount
=C2=A0
--00000000000096c9ab058d4a05db-- From nobody Tue Jul 9 20:29:08 2019 Return-Path: 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 CA0051200E5 for ; Tue, 9 Jul 2019 20:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 47HpL6enyRgJ for ; Tue, 9 Jul 2019 20:29:05 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 02E9C1200E3 for ; Tue, 9 Jul 2019 20:29:04 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id p184so372703pfp.7 for ; Tue, 09 Jul 2019 20:29:04 -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=0T+KLlBq5fLV2Zc9026K83DRPMhXPYMWPh9zjlacX4U=; b=qNFqPs7tj+BLOw0587fjbfim4gbwKO/4H3vByn4OlvmOcawb12R8Yoi59HThCGED8K u54WBJoPhjHbETIugNdEf0gK4c+4GN6YpnXBJ2B6tfZbFDCz2GcH4lClSsiYYq2DmQnU yIL39HAiLu0mK7LV+2OmNEiBqsj4lfseM5akpWyBya5GH5CwtNkzI+WvWl2Wq/wde8tw BhS9uO/FcaaWhAj6qA3oWZ6ZfQyBPACJhbqv2rtKEljdNUNm5Bohd2G60uKq/DbU4SKl 8ssRmhmD9X+MFsne5pVgWngKIWV0QedcVk3ksS8dwN8UuN1rqSY+FF7g6WMEGFGVswk6 L9CA== 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=0T+KLlBq5fLV2Zc9026K83DRPMhXPYMWPh9zjlacX4U=; b=qLgXhCfEMeLnC1jVgMrr0kK/yL9P6NjMhdMZsw/mHnKghOvD4vUNj6QSiXPecwArMc EHMHyi1A8eZgSpK1XWLPGKHumDF1vFS11nV8clcJEjhGRJ3bSTYORugl2G+QvELgnB1U 7XdCuQ14pf3yJGbF/wp7ZXaBnAPgp1+wh2bg3mx7RHnpoqXV6kAFvyRZbK7ct0rmFO9t oBYquGnjriEJ2qAP4AMaGBtfHhCbM41KVyhiqHjKibHoNzrph5caAByiB/UyAG3pVYKf lpASbmk6TCxNQp/Y0ydjfddT/68RoY1P+x4s6HLxYqtSa5CIGUIq+V7KtvkPhfmLnYhN s1/g== X-Gm-Message-State: APjAAAVJWxHTgenW8vRIXFgpc1K+y9uon8z3BXqNVoEWVclaFCwVFOi8 MGZeKOCHYUCvYICokiecS9KRmZMLBQA= X-Google-Smtp-Source: APXvYqwHQNe4WKR1pddvlyb1HDDeu61/UNrUPeqViXuStGnK6E+oolnIiDSuw4ykZtGhVFLUCYEO7A== X-Received: by 2002:a63:1c22:: with SMTP id c34mr24812079pgc.56.1562729343729; Tue, 09 Jul 2019 20:29:03 -0700 (PDT) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com. [209.85.210.176]) by smtp.gmail.com with ESMTPSA id c5sm438408pgq.80.2019.07.09.20.29.01 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 20:29:02 -0700 (PDT) Received: by mail-pf1-f176.google.com with SMTP id 19so379290pfa.4 for ; Tue, 09 Jul 2019 20:29:01 -0700 (PDT) X-Received: by 2002:a63:7a06:: with SMTP id v6mr34822323pgc.115.1562729341452; Tue, 09 Jul 2019 20:29:01 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 9 Jul 2019 23:28:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: Christer Holmberg , SIPCORE Content-Type: multipart/alternative; boundary="000000000000470549058d4b4758" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 03:29:07 -0000 --000000000000470549058d4b4758 Content-Type: text/plain; charset="UTF-8" Can you then explain, what is covered, ideally providing a real world use case? Roman Shpount On Tue, Jul 9, 2019, 21:59 Rifaat Shekh-Yusef wrote: > Such a use case is not covered by this document, and is out of scope. > > Regards, > Rifaat > > > On Tue, Jul 9, 2019 at 9:44 PM Roman Shpount wrote: > >> On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef >> wrote: >> >>> For me, the main motivation is SSO. >>> The user would use one set of corporate credentials to authenticate, >>> login to a deskphone, and get access to SIP and non-SIP services. >>> >>> I am not sure I am following your use case. >>> How would the user authenticate and obtain a an access token in this >>> case? >>> >>> >> The use case is the same SSO in combination with hot desks and multiple >> PBXs. User picks a desk at a remote office, goes to a web page to login, >> enters his credentials and desk location. Expected result is that the phone >> on this temporary desk will ring when user gets a call on user's extension >> on the user home PBX. Internally, SSO system produces a token, which is >> sent to the PBX in the remote office. PBX in the remote office registers >> using this token with use home PBX, and configures that all the calls for >> this registration are forwarded to the phone on the user temporary desk. >> All the calls placed from that desk are also placed through user home PBX >> so that correct line is used and user home caller ID is displayed. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> > --000000000000470549058d4b4758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you then explain, what is covered, ideally providing = a real world use case?

Roman= Shpount

On Tue, Jul 9, 2019, 21:59 Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= /div>
Such a use case is not= covered by this document, and is out of scope.

Regards,=
=C2=A0Rifaat


On Tue, Jul 9, 2019 at 9:44 PM = Roman Shpount <roman@telurix.com> wrote:
On Tue,= Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com= > wrote:
For me, the main motivation is SSO.=
The user would use one set of corporate credentials to authenticate, l= ogin to a deskphone, and get access to SIP and non-SIP services.
=
I am not sure I am following your use case.
How wo= uld the user authenticate and obtain a an access token in this case?
<= div>

The use case is the sa= me SSO in combination with hot desks and multiple PBXs. User picks a desk a= t a remote office, goes to a web page to login, enters his credentials and = desk location. Expected result is that the phone on this temporary desk wil= l ring when user gets a call on user's extension on the user home PBX. = Internally, SSO system produces a token, which is sent to the PBX in the re= mote office. PBX in the remote office registers using this token with use h= ome PBX,=C2=A0and configures that all the calls for this registration are f= orwarded to the phone on the user temporary desk. All the calls placed from= that desk are also placed through user home PBX so that correct line is us= ed and user home caller ID is displayed.

Best Rega= rds,
_____________
Roman Shpount
=C2=A0
--000000000000470549058d4b4758-- From nobody Tue Jul 9 23:36:40 2019 Return-Path: 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 524A4120103 for ; Tue, 9 Jul 2019 23:36:38 -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 Kt8WtqdH3HfF for ; Tue, 9 Jul 2019 23:36:35 -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 D259A120100 for ; Tue, 9 Jul 2019 23:36:34 -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 5A311A40; Wed, 10 Jul 2019 08:36:30 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <0DAD4015-3931-4E07-AF4A-092935FB31D1@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_A8A8D8BD-0B7B-48A9-A2E7-424DEF63B46C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 08:36:28 +0200 In-Reply-To: Cc: Olle E Johansson , Rifaat Shekh-Yusef , SIPCORE To: Roman Shpount References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 06:36:38 -0000 --Apple-Mail=_A8A8D8BD-0B7B-48A9-A2E7-424DEF63B46C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s one example: Many web apps and mobile apps already use OpenID connect for single sign = on. The tokens may now include a scope for the SIP platform, which means that the app can open SIP over WebSockets and authenticate = with the same set of tokens as for other backend services to the SIP service. The SIP service must now validate the tokens with the IDP.=20 /O > On 10 Jul 2019, at 05:28, Roman Shpount wrote: >=20 > Can you then explain, what is covered, ideally providing a real world = use case? >=20 > Roman Shpount >=20 > On Tue, Jul 9, 2019, 21:59 Rifaat Shekh-Yusef > wrote: > Such a use case is not covered by this document, and is out of scope. >=20 > Regards, > Rifaat >=20 >=20 > On Tue, Jul 9, 2019 at 9:44 PM Roman Shpount > wrote: > On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef = > wrote: > For me, the main motivation is SSO. > The user would use one set of corporate credentials to authenticate, = login to a deskphone, and get access to SIP and non-SIP services. >=20 > I am not sure I am following your use case. > How would the user authenticate and obtain a an access token in this = case? >=20 >=20 > The use case is the same SSO in combination with hot desks and = multiple PBXs. User picks a desk at a remote office, goes to a web page = to login, enters his credentials and desk location. Expected result is = that the phone on this temporary desk will ring when user gets a call on = user's extension on the user home PBX. Internally, SSO system produces a = token, which is sent to the PBX in the remote office. PBX in the remote = office registers using this token with use home PBX, and configures that = all the calls for this registration are forwarded to the phone on the = user temporary desk. All the calls placed from that desk are also placed = through user home PBX so that correct line is used and user home caller = ID is displayed. >=20 > Best Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_A8A8D8BD-0B7B-48A9-A2E7-424DEF63B46C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s one example:

Many web apps and mobile apps already use OpenID = connect for single sign on. The  tokens may now include a scope for = the SIP platform,
which means that the app can open SIP = over WebSockets and authenticate with the same set of tokens as for = other backend services to the
SIP = service.

The = SIP service must now validate the tokens with the IDP. 

/O


On 10 Jul 2019, at 05:28, Roman Shpount = <roman@telurix.com> wrote:

Can you then explain, what is covered, ideally providing a = real world use case?

Roman = Shpount

On Tue, Jul 9, 2019, 21:59 Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Such a use case is not covered by this document, and is out = of scope.

Regards,
 Rifaat


On Tue, Jul = 9, 2019 at 9:44 PM Roman Shpount <roman@telurix.com> = wrote:
On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:
For = me, the main motivation is SSO.
The user would use one = set of corporate credentials to authenticate, login to a deskphone, and = get access to SIP and non-SIP services.

I am not sure I am following your use = case.
How would the user authenticate and obtain a = an access token in this case?


The use case is the same SSO in = combination with hot desks and multiple PBXs. User picks a desk at a = remote office, goes to a web page to login, enters his credentials and = desk location. Expected result is that the phone on this temporary desk = will ring when user gets a call on user's extension on the user home = PBX. Internally, SSO system produces a token, which is sent to the PBX = in the remote office. PBX in the remote office registers using this = token with use home PBX, and configures that all the calls for this = registration are forwarded to the phone on the user temporary desk. All = the calls placed from that desk are also placed through user home PBX so = that correct line is used and user home caller ID is = displayed.

Best = Regards,
_____________
Roman Shpount
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_A8A8D8BD-0B7B-48A9-A2E7-424DEF63B46C-- From nobody Tue Jul 9 23:40:33 2019 Return-Path: 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 61386120103 for ; Tue, 9 Jul 2019 23:40:31 -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 Vtz-TOl2XZZ7 for ; Tue, 9 Jul 2019 23:40:29 -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 CA6971200D6 for ; Tue, 9 Jul 2019 23:40:28 -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 4322FA40; Wed, 10 Jul 2019 08:40:25 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <42F6AA81-773C-46DB-8BE7-D76951C24B47@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_CD869C58-610D-40E1-8AB7-8B33A3717210" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 08:40:23 +0200 In-Reply-To: Cc: Olle E Johansson , Rifaat Shekh-Yusef , "sipcore@ietf.org" To: Roman Shpount References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 06:40:32 -0000 --Apple-Mail=_CD869C58-610D-40E1-8AB7-8B33A3717210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 10 Jul 2019, at 03:44, Roman Shpount wrote: >=20 > On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef = > wrote: > For me, the main motivation is SSO. > The user would use one set of corporate credentials to authenticate, = login to a deskphone, and get access to SIP and non-SIP services. >=20 > I am not sure I am following your use case. > How would the user authenticate and obtain a an access token in this = case? >=20 >=20 > The use case is the same SSO in combination with hot desks and = multiple PBXs. User picks a desk at a remote office, goes to a web page = to login, enters his credentials and desk location. Expected result is = that the phone on this temporary desk will ring when user gets a call on = user's extension on the user home PBX. Internally, SSO system produces a = token, which is sent to the PBX in the remote office. PBX in the remote = office registers using this token with use home PBX, and configures that = all the calls for this registration are forwarded to the phone on the = user temporary desk. All the calls placed from that desk are also placed = through user home PBX so that correct line is used and user home caller = ID is displayed. That seems very complex. How is the token transferred from the web = browser to the phone? And how does the home PBX validate the token sent = on behalf of the user by the remove office PBX? Many chains of trust or many leaps of faith. But interesting. /O :-) --Apple-Mail=_CD869C58-610D-40E1-8AB7-8B33A3717210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 10 Jul 2019, at 03:44, Roman Shpount <roman@telurix.com> = wrote:

On Tue, Jul 9, 2019 = at 9:29 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
For me, = the main motivation is SSO.
The user would use one set of = corporate credentials to authenticate, login to a deskphone, and get = access to SIP and non-SIP services.

I am not sure I am following your use = case.
How would the user authenticate and obtain a = an access token in this case?


The use case is the same SSO in = combination with hot desks and multiple PBXs. User picks a desk at a = remote office, goes to a web page to login, enters his credentials and = desk location. Expected result is that the phone on this temporary desk = will ring when user gets a call on user's extension on the user home = PBX. Internally, SSO system produces a token, which is sent to the PBX = in the remote office. PBX in the remote office registers using this = token with use home PBX, and configures that all the calls for this = registration are forwarded to the phone on the user temporary desk. All = the calls placed from that desk are also placed through user home PBX so = that correct line is used and user home caller ID is = displayed.

That seems very complex. How is the token = transferred from the web browser to the phone? And how does the home PBX = validate the token sent on behalf of the user by the remove office = PBX?

Many chains of trust or many = leaps of faith.

But = interesting.

/O :-)

= --Apple-Mail=_CD869C58-610D-40E1-8AB7-8B33A3717210-- From nobody Tue Jul 9 23:44:18 2019 Return-Path: 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 1B74312033F for ; Tue, 9 Jul 2019 23:44:13 -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 ac1zLQI882FX for ; Tue, 9 Jul 2019 23:44:10 -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 0B6B31201C8 for ; Tue, 9 Jul 2019 23:44:07 -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 649FFA40; Wed, 10 Jul 2019 08:44:03 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B6CEEE4C-1E8C-4E74-83AE-194050C459F7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 08:44:03 +0200 In-Reply-To: Cc: Olle E Johansson , Rifaat Shekh-Yusef , "sipcore@ietf.org" To: Roman Shpount References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 06:44:16 -0000 --Apple-Mail=_B6CEEE4C-1E8C-4E74-83AE-194050C459F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 02:53, Roman Shpount wrote: >=20 > On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: > The document clearly allows the use of access token to authenticate = non-REGISTER requests when challenged in the context of the same realm. >=20 > 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? >=20 When the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the server does with the connection when a token expires (if it=E2=80=99s = not already in the draft). /O >=20 > 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. >=20 > 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.=20 >=20 > 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. >=20 > Best Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_B6CEEE4C-1E8C-4E74-83AE-194050C459F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 02:53, Roman Shpount <roman@telurix.com> = wrote:

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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does with the = connection when a token expires (if it=E2=80=99s not already in the = draft).
/O

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
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_B6CEEE4C-1E8C-4E74-83AE-194050C459F7-- From nobody Tue Jul 9 23:54:19 2019 Return-Path: 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 90EB6120105 for ; Tue, 9 Jul 2019 23:54:17 -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 n6GyitmoKaW5 for ; Tue, 9 Jul 2019 23:54:14 -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 0FE15120103 for ; Tue, 9 Jul 2019 23:54:13 -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 1F598A40; Wed, 10 Jul 2019 08:54:10 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7C1F8139-0795-451C-8850-C2495A74D477" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 08:54:08 +0200 In-Reply-To: Cc: Olle E Johansson , Christer Holmberg , "sipcore@ietf.org" To: Roman Shpount References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 06:54:18 -0000 --Apple-Mail=_7C1F8139-0795-451C-8850-C2495A74D477 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 00:57, Roman Shpount wrote: >=20 > On Tue, Jul 9, 2019 at 4:00 PM Christer Holmberg = > = wrote: > >>>> As far as I know, OAuth for SIP has only been used for REGISTER = requests, between the UA and the registrar.=20 > >>>> I have never heard about anyone using it for non-REGISTER = authentication, and I wonder whether we even need=20 > >>>> 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. > >>>=20 > >>> Really? Normally, for a secure solution, every SIP request, = including requests sent by UA in dialog established from the=20 > >>> server to the registered end point must be authenticated. OAuth = for REGISTRER requests only is kind of useless since it=20 > >>> does not allow UA to send any messages to the server without some = additional authentication mechanism. > >> > >> Not sure what you mean by "secure solution", but UAs can still use = SIP Digest authentication. > >> > >> What I am saying is that only use-case for SIP OAuth I am aware of = is for REGISTER. > > > > How do they get these SIP Digest credentials? > > > > I am looking at a very simple SIP-Over-Websockets client scenario: > > > > User logs into the web site which uses OAuth. UA, running in the = browser gets a token which is used to Register UA with a SIP proxy. >=20 > Wouldn't you use OAuth to establish the WebSocket connection? > =20 > No, WebSocket connection is to a different server and typically does = not require authentication. I don=E2=80=99t think that=E2=80=99s correct. See section 7 of RFC 7118 = - SIP over WS. https://tools.ietf.org/html/rfc7118#section-7 = > In this specific case, I was thinking OpenSIPS with SIP-over-WS = support. Implementing OAuth authentication of SIP message would be = trivial there, but OAuth authentication for WebSocket would be much less = obvious. That=E2=80=99s implementation. I am pretty sure that Kamailio can auth = the websocket, either by TLS client cert or HTTP digest auth. Guess I = need to test :-) >=20 > >What credentials is UA using to place a call (send INVITE to the = proxy)?=20 > >If a call comes in from the proxy to UA, what credentials is UA using = to hang up the call (send BYE message)? >=20 > If the registry and the call handling is part of the same service I = guess you could use the same credentials, assuming 3261 generally allows = using the same credentials for registrations and calls. >=20 > Are you saying using OAuth token authentication for calls (INVITE) and = in dialog messages (BYE)? Why not? It=E2=80=99s just a different Authorization header value. In my = view Oauth bearer tokens should be usable in all places where you today = have MD5 digest auth. /O --Apple-Mail=_7C1F8139-0795-451C-8850-C2495A74D477 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 00:57, Roman Shpount <roman@telurix.com> = wrote:

On Tue, Jul 9, 2019 at 4:00 PM = Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>>> 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.
>>> 
>>> Really? Normally, for a secure solution, every SIP request, = including requests sent by UA in dialog established from the
>>> server to the registered end point must be authenticated. = OAuth for REGISTRER requests only is kind of useless since it
>>> does not allow UA to send any messages to the server = without some additional authentication mechanism.
>>
>> Not sure what you mean by "secure solution", but UAs can still = use SIP Digest authentication.
>>
>> What I am saying is that only use-case for SIP OAuth I am aware = of is for REGISTER.
>
> How do they get these SIP Digest credentials?
>
> I am looking at a very simple SIP-Over-Websockets client = scenario:
>
> User logs into the web site which uses OAuth. UA, running in the = browser gets a token which is used to Register UA with a SIP proxy.

Wouldn't  you use OAuth to establish the WebSocket connection?
 
No, = WebSocket connection is to a different server and typically does not = require authentication.
I don=E2=80=99= t think that=E2=80=99s correct. See section 7 of RFC 7118 - SIP over = WS. https://tools.ietf.org/html/rfc7118#section-7
In = this specific case, I was thinking OpenSIPS with SIP-over-WS support. = Implementing OAuth authentication of SIP message would be trivial there, = but OAuth authentication for WebSocket would be much less = obvious.
That=E2=80=99s = implementation. I am pretty sure that Kamailio can auth the websocket, = either by TLS client cert or HTTP digest auth. Guess I need to test = :-)


>What credentials is UA using to = place a call (send INVITE to the proxy)? 
>If a call comes in from the proxy to UA, what credentials is UA = using to hang up the call (send BYE message)?

If the registry and the call handling is part of the same service I = guess you could use the same credentials, assuming 3261 generally allows = using the same credentials for registrations and calls.

Are you saying using OAuth token authentication for calls = (INVITE) and in dialog messages = (BYE)?
Why not? It=E2=80=99s just a = different Authorization header value. In my view Oauth bearer tokens = should be usable in all places where you today have MD5 digest = auth.

/O

= --Apple-Mail=_7C1F8139-0795-451C-8850-C2495A74D477-- From nobody Wed Jul 10 00:08:17 2019 Return-Path: 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 8F1BF12011C for ; Wed, 10 Jul 2019 00:08:14 -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 oerSN1frs1Zq for ; Wed, 10 Jul 2019 00:08:11 -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 DA454120105 for ; Wed, 10 Jul 2019 00:08:10 -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 3520DA40; Wed, 10 Jul 2019 09:08:07 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1D09B734-6563-4FC4-9524-8581C9284904" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 09:08:06 +0200 In-Reply-To: Cc: Olle E Johansson , Roman Shpount , "sipcore@ietf.org" To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 07:08:15 -0000 --Apple-Mail=_1D09B734-6563-4FC4-9524-8581C9284904 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef = wrote: >=20 > This document is specifically focused on confidential UAs. > UAs running in the browser, public UAs, will be addressed in a = separate document. Maybe you should make that more clear, as it is very confusing = terminology=E2=80=A6 I see that section 1.2 in your draft defines theses types, based on RFC 6749. You apply it to the term =E2=80=9CUA=E2=80=9D = which I think confuses things. A =E2=80=9Cpublic UA=E2=80=9D may have = support for confidentiality, but not from an Oauth point of view. I think we = should look for other terms for this. In addition, I don=E2=80=99t find any text in your draft indicating that = =E2=80=9CPublic UAs=E2=80=9D is out of scope. /O >=20 > Regards, > Rifaat >=20 >=20 > On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount > wrote: > On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg = > = wrote: > >> As far as I know, OAuth for SIP has only been used for REGISTER = requests, between the UA and the registrar.=20 > >> I have never heard about anyone using it for non-REGISTER = authentication, and I wonder whether we even need=20 > >> 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. > >=20 > > Really? Normally, for a secure solution, every SIP request, = including requests sent by UA in dialog established from the=20 > > server to the registered end point must be authenticated. OAuth for = REGISTRER requests only is kind of useless since it=20 > > does not allow UA to send any messages to the server without some = additional authentication mechanism. >=20 > Not sure what you mean by "secure solution", but UAs can still use SIP = Digest authentication. >=20 > What I am saying is that only use-case for SIP OAuth I am aware of is = for REGISTER. >=20 > How do they get these SIP Digest credentials? >=20 > I am looking at a very simple SIP-Over-Websockets client scenario: >=20 > User logs into the web site which uses OAuth. UA, running in the = browser gets a token which is used to Register UA with a SIP proxy. >=20 > What credentials is UA using to place a call (send INVITE to the = proxy)?=20 > If a call comes in from the proxy to UA, what credentials is UA using = to hang up the call (send BYE message)? >=20 > Best Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_1D09B734-6563-4FC4-9524-8581C9284904 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

This document is specifically focused on confidential UAs.
UAs running in the = browser, public UAs, will be addressed in a separate = document.
Maybe you should make that more = clear, as it is very confusing terminology=E2=80=A6 I see that section = 1.2 in your draft defines theses
types, based on RFC 6749. You = apply it to the term =E2=80=9CUA=E2=80=9D which I think confuses things. = A =E2=80=9Cpublic UA=E2=80=9D may have support
for = confidentiality, but not from an Oauth point of view. I think we should = look for other terms for this.

In = addition, I don=E2=80=99t find any text in your draft indicating that = =E2=80=9CPublic UAs=E2=80=9D is out of scope.

/O
Regards,
 Rifaat


On Tue, Jul 9, 2019 at 3:29 PM Roman = Shpount <roman@telurix.com> wrote:
On Tue, Jul 9, 2019 = at 3:11 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 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.
> 
> Really? Normally, for a secure solution, every SIP request, = including requests sent by UA in dialog established from the
> server to the registered end point must be authenticated. OAuth for = REGISTRER requests only is kind of useless since it
> does not allow UA to send any messages to the server without some = additional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still use SIP = Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is = for REGISTER.

How do they get these SIP Digest credentials?

I am looking at a very = simple SIP-Over-Websockets client scenario:

User logs into the web site which uses = OAuth. UA, running in the browser gets a token which is used to Register = UA with a SIP proxy.

What credentials is UA using to place a call (send INVITE to = the proxy)? 
If a call comes in from the proxy = to UA, what credentials is UA using to hang up the call (send BYE = message)?

Best = Regards,
_____________
Roman Shpount
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_1D09B734-6563-4FC4-9524-8581C9284904-- From nobody Wed Jul 10 00:18:05 2019 Return-Path: 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 98DB2120105 for ; Wed, 10 Jul 2019 00:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EokrfoNRds1Q for ; Wed, 10 Jul 2019 00:18:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150045.outbound.protection.outlook.com [40.107.15.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE77C120100 for ; Wed, 10 Jul 2019 00:17:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i3DTkNBxqs6w0ZIDEmZOaSDjP5KK+gkUq3Uetqz6xzGKVRyDcTPXvRVMqCEozXWEVyENNZChuygvesPp+KVu2vakJGGf+U47C1TQzZduY659QXltpLR64pzI6w1vkrcQk/7lK0wu/XrJD2q4FQ5tsTIDxbmM50I49rG6lOEvbFAhDMymGoMuDcijEE6LzrVf3Tfmz/p0is+9OezeSkCpLzhC6ZWfUSx8l6jtRBres9jxob7QiDL0TJvkM2xsYdnpgizunmKLqi6QQOa4irAaQtK1CBrgx3m+04Yzfa4/Ghectd9f7SttbBZ6YAM4z88DG9EnFGDHiPRjS5/8OP3qDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WZ1XYgvasxASlw/30pzDRxsXd1Gf1nAIxld+dplZekg=; b=RKXNjRGXd1D2rimPba4dEmDHTEh5I9e5VRGTU+tDREIbcekg5Gyk+rqtdnln1J10iwTPUCypOX239xque3ebD8K8Z7ltNoZDWSoZ+uBi8JlnZmY9/BGwGQNuO3e5wqR2Yn36vcThLL7T5I6AqKUs26RuYxXjU7RNSaKEJm+Xg/aj1E0umeCoEe0QDwVdISu5yLtME9GLlJoWGUTwe53ARFDvbL+UiQUKqNMGSTW9PDdo4ecO3IawVIDMvWth5lsQPqpCNpPSJ1As+608AoylbsJQ019pNnw6wy52IxUgyWf0APmT2IqhTab/IkidqWTql4yBNrLsFawFX1EkI8HIzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WZ1XYgvasxASlw/30pzDRxsXd1Gf1nAIxld+dplZekg=; b=XWRSbAfIexgsKOEwQsHzGSZIPP2FsuLeveNt6tAAejNFsWbXejKragM0Gy6QhOHJ+PyR6FZ386+7Z2bQqQM4XbkDAEXNk6wrXqYlHKlL6Fjxz6oxEnOvyRsnihDpzw2628fxtWsnvZa4V29ZLtGRXJvk3b2VawMTP6dPFs1nO2Q= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4409.eurprd07.prod.outlook.com (20.176.167.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.4; Wed, 10 Jul 2019 07:17:48 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 07:17:48 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Roman Shpount CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAAeAYCAABzUAIAABQKAgAACsgCAABGcAIAAcNxQ Date: Wed, 10 Jul 2019 07:17:47 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [62.113.190.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cfe11394-34fb-49c5-f6a5-08d70506b627 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4409; x-ms-traffictypediagnostic: HE1PR07MB4409: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(199004)(189003)(6306002)(54896002)(8936002)(8676002)(55016002)(53936002)(81156014)(81166006)(33656002)(316002)(186003)(2906002)(9686003)(68736007)(71200400001)(71190400001)(236005)(6436002)(110136005)(478600001)(9326002)(229853002)(26005)(486006)(44832011)(52536014)(6246003)(102836004)(74316002)(790700001)(6116002)(3846002)(6506007)(53546011)(86362001)(5660300002)(476003)(25786009)(446003)(11346002)(14454004)(76176011)(7696005)(76116006)(4326008)(66066001)(66476007)(66556008)(64756008)(66446008)(66946007)(14444005)(256004)(99286004)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4409; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qqQYrLVP7zvbCDrOuVJI9CZFDMVca7HMn872TAk0yrxdC7TdUPc5d7Tz6DoqpAq7hQkTfFr/XmSAsPHX2SB6vi1uZkm0qLzDfNOe3cG01YgnWMnuiE85IwxZCzHaLLgmn0bmLwvNGBrhvYmNdWhhFDeHx/yic4a3NXrjKvc/Wq8qVx8oUwNo+il8gGlfzTmyWD+WfJ47TrF4cL8ORZBOMeHbdmpF1tIy1ClVtXGONT5vjlV9h0Ipea/J0fOQJX40MLDg59O2PAtsRIgZ7d7AfVPVkwiYycMm7kayGOWJzP5M550d7yWKLISRTBOW9ZgmBUVcbEIKuv5EI608ojlDH4ZBS9gMujUecfUS6ceivNQ806UMRpsfi+cNR92jtABMVMOSaq0v4UYdrGKDrYJqhsaYlqzhsPe1xjYuMoncQ6A= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316136FF32614875E4F6379593F00HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfe11394-34fb-49c5-f6a5-08d70506b627 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 07:17:47.8190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4409 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 07:18:03 -0000 --_000_HE1PR07MB316136FF32614875E4F6379593F00HE1PR07MB3161eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRvIGNsYXJpZnkgbXkgY29tbWVudCwgYXMgUmlmYWF0IHNhaWQsIHRoZSBkb2N1bWVu dCBkb2VzIGFsbG93IHVzYWdlIG9mIGFjY2VzcyB0b2tlbiB0byBhdXRoZW50aWNhdGUgbm9uLVJF R0lTVEVSIHJlcXVlc3RzLg0KDQpJIHF1ZXN0aW9uZWQgd2hldGhlciB0aGUgZHJhZnQgbmVlZHMg dG8gY292ZXIgc3VjaCB1c2UtY2FzZXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJv bTogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+DQpTZW50OiAxMCBK dWx5IDIwMTkgMDM6MzANClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNj OiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgc2lw Y29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei0wMi50eHQNCg0KVGhlIGRvY3VtZW50IGNsZWFy bHkgYWxsb3dzIHRoZSB1c2Ugb2YgYWNjZXNzIHRva2VuIHRvIGF1dGhlbnRpY2F0ZSBub24tUkVH SVNURVIgcmVxdWVzdHMgd2hlbiBjaGFsbGVuZ2VkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBzYW1l IHJlYWxtLg0KDQpXaGV0aGVyIHRoYXQgaXMgbmVlZGVkIG9yIG5vdCBpcyBhIGRpZmZlcmVudCBk aXNjdXNzaW9uLg0KQXNzdW1pbmcgdGhlIFVBIHdhcyBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGUg dXNlciBhbmQgb2J0YWluIGFuIGFjY2VzcyB0b2tlbiwgdGhlbiBlc3RhYmxpc2ggYW4gYXV0aGVu dGljYXRlZCBUTFMgY2hhbm5lbCB3aXRoIHRoZSBzZXJ2ZXIsIGFuZCByZWdpc3RlciB0aGUgdXNl cjsgaXMgdGhlcmUgYSBuZWVkIGZvciBmdXJ0aGVyIGNoYWxsZW5nZXMgZnJvbSBzZXJ2ZXI/DQoN ClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24gVHVlLCBKdWwgOSwgMjAxOSBhdCA3OjI3IFBNIFJv bWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+ IHdyb3RlOg0KT24gVHVlLCBKdWwgOSwgMjAxOSBhdCA3OjE3IFBNIFJpZmFhdCBTaGVraC1ZdXNl ZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3 cm90ZToNCkNhbiB5b3UgcHJvdmlkZSBhIHJlYWwgbGlmZSBleGFtcGxlIG9mIGNvbmZpZGVudGlh bCBVQSB1c2luZyBPQXV0aCBmb3IgcmVnaXN0cmF0aW9uIG9ubHkgYW5kIG5vdCBnZW5lcmF0aW5n IGNhbGxzIG9yIHNlbmRpbmcgYW55IG1lc3NhZ2VzIGluIGRpYWxvZyAob3IgdXNpbmcgZGlmZmVy ZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBmb3IgdGhlc2UgYWN0aW9ucyk/DQoNCldoYXQ/IHdo eSBkbyB5b3UgdGhpbmsgdGhhdCBpcyB0aGUgY2FzZT8NCkhvdyBkaWQgeW91IGdldCB0byB0aGUg Y29uY2x1c2lvbiB0aGF0IHRoZSBVQSB3aWxsIG5vdCBiZSBhYmxlIHRvIG1ha2UgYSBjYWxsPw0K DQoNClF1b3RpbmcgQ2hyaXN0ZXI6DQoNCkFzIGZhciBhcyBJIGtub3csIE9BdXRoIGZvciBTSVAg aGFzIG9ubHkgYmVlbiB1c2VkIGZvciBSRUdJU1RFUiByZXF1ZXN0cywgYmV0d2VlbiB0aGUgVUEg YW5kIHRoZSByZWdpc3RyYXIuIEkgaGF2ZSBuZXZlciBoZWFyZCBhYm91dCBhbnlvbmUgdXNpbmcg aXQgZm9yIG5vbi1SRUdJU1RFUiBhdXRoZW50aWNhdGlvbiwgYW5kIEkgd29uZGVyIHdoZXRoZXIg d2UgZXZlbiBuZWVkIHRvIGNvdmVyIGl0IGluIHRoZSBkcmFmdC4NCg0KU28sIEkgYW0gdHJ5aW5n IHRvIHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlIHdoZXJlOg0KDQoxLiBVQSBpcyBjb25maWRlbnRp YWwNCjIuIE9BdXRoIGlzIHVzZWQgZm9yIHJlZ2lzdHJhdGlvbiBvbmx5DQozLiBPdGhlciBtZXNz YWdlcyBhcmUgbm90IHNlbnQgb3IgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpcyB1 c2VkIGZvciB0aGVtLCBpLmUuIGNhbGxzIGFuZCBpbiBkaWFsb2cgbWVzc2FnZXMgYXJlIG5vdCBp bml0aWF0ZWQgb3IgaW5pdGlhdGVkIHVzaW5nIGEgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1l dGhvZC4NCg0KU28gZmFyLCBJIGNhbm5vdCBmaWd1cmUgb3V0IHdoYXQgdGhpcyBpcy4NCg0KQmVz dCBSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQoNCg== --_000_HE1PR07MB316136FF32614875E4F6379593F00HE1PR07MB3161eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRvIGNsYXJpZnkgbXkgY29tbWVudCwgYXMgUmlmYWF0IHNh aWQsIHRoZSBkb2N1bWVudCBkb2VzIGFsbG93IHVzYWdlIG9mIGFjY2VzcyB0b2tlbiB0byBhdXRo ZW50aWNhdGUgbm9uLVJFR0lTVEVSIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHF1ZXN0aW9uZWQgd2hldGhl ciB0aGUgZHJhZnQgbmVlZHMgdG8gY292ZXIgc3VjaCB1c2UtY2FzZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWls LmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxMCBKdWx5IDIwMTkgMDM6MzA8YnI+DQo8Yj5U bzo8L2I+IFJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVyaXguY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSZndDs7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3Jl XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei0wMi50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQgY2xlYXJs eSBhbGxvd3MgdGhlIHVzZSBvZiBhY2Nlc3MgdG9rZW4gdG8gYXV0aGVudGljYXRlIG5vbi1SRUdJ U1RFUiByZXF1ZXN0cyB3aGVuIGNoYWxsZW5nZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNhbWUg cmVhbG0uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZXRo ZXIgdGhhdCBpcyBuZWVkZWQgb3Igbm90IGlzIGEgZGlmZmVyZW50IGRpc2N1c3Npb24uPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXNzdW1pbmcgdGhlIFVBIHdhcyBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlciBhbmQg b2J0YWluIGFuIGFjY2VzcyB0b2tlbiwgdGhlbiBlc3RhYmxpc2ggYW4gYXV0aGVudGljYXRlZCBU TFMgY2hhbm5lbCB3aXRoIHRoZSBzZXJ2ZXIsIGFuZCByZWdpc3RlciB0aGUgdXNlcjsgaXMgdGhl cmUgYSBuZWVkIGZvciBmdXJ0aGVyIGNoYWxsZW5nZXMgZnJvbSBzZXJ2ZXI/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IEp1bCA5LCAyMDE5IGF0IDc6MjcgUE0gUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCA5LCAy MDE5IGF0IDc6MTcgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlm YWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcHJvdmlkZSBhIHJlYWwgbGlm ZSBleGFtcGxlIG9mIGNvbmZpZGVudGlhbCBVQSB1c2luZyBPQXV0aCBmb3IgcmVnaXN0cmF0aW9u IG9ubHkgYW5kIG5vdCBnZW5lcmF0aW5nIGNhbGxzIG9yIHNlbmRpbmcgYW55IG1lc3NhZ2VzIGlu IGRpYWxvZyAob3IgdXNpbmcgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBmb3IgdGhl c2UgYWN0aW9ucyk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0PyB3aHkgZG8geW91 IHRoaW5rIHRoYXQgaXMgdGhlIGNhc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgZGlkIHlvdSBnZXQgdG8gdGhlIGNvbmNsdXNpb24gdGhh dCB0aGUgVUEgd2lsbCBub3QgYmUgYWJsZSB0byBtYWtlIGEgY2FsbD88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UXVvdGluZyBDaHJpc3Rlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QXMgZmFyIGFzIEkga25vdywgT0F1dGggZm9yIFNJUCBoYXMgb25seSBi ZWVuIHVzZWQgZm9yIFJFR0lTVEVSIHJlcXVlc3RzLCBiZXR3ZWVuIHRoZSBVQSBhbmQgdGhlIHJl Z2lzdHJhci4gSSBoYXZlIG5ldmVyIGhlYXJkIGFib3V0IGFueW9uZSB1c2luZyBpdCBmb3Igbm9u LVJFR0lTVEVSIGF1dGhlbnRpY2F0aW9uLCBhbmQgSSB3b25kZXIgd2hldGhlciB3ZSBldmVuDQog bmVlZCB0byBjb3ZlciBpdCBpbiB0aGUgZHJhZnQuPC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TbywgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2Ug d2hlcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjEuIFVBIGlzIGNvbmZpZGVudGlhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gT0F1dGggaXMgdXNlZCBmb3IgcmVnaXN0cmF0aW9uIG9u bHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMu IE90aGVyIG1lc3NhZ2VzIGFyZSBub3Qgc2VudCBvciBkaWZmZXJlbnQgYXV0aGVudGljYXRpb24g bWV0aG9kIGlzIHVzZWQgZm9yIHRoZW0sIGkuZS4gY2FsbHMgYW5kIGluIGRpYWxvZyBtZXNzYWdl cyBhcmUgbm90IGluaXRpYXRlZCBvciBpbml0aWF0ZWQgdXNpbmcgYSBkaWZmZXJlbnQgYXV0aGVu dGljYXRpb24gbWV0aG9kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TbyBmYXIsIEkgY2Fubm90IGZpZ3VyZSBvdXQgd2hhdCB0aGlzIGlzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0 IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR07MB316136FF32614875E4F6379593F00HE1PR07MB3161eurp_-- From nobody Wed Jul 10 00:23:50 2019 Return-Path: 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 9C245120115 for ; Wed, 10 Jul 2019 00:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] 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 EAv05g3CgjSN for ; Wed, 10 Jul 2019 00:23:47 -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 A3BAC1200D6 for ; Wed, 10 Jul 2019 00:23:45 -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 B3643A40; Wed, 10 Jul 2019 09:23:42 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8447638D-BAAC-4F55-8D3B-13BFE45955BB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 09:23:41 +0200 In-Reply-To: <168b1354-b35b-edee-e5f9-d4ddbecfae40@alum.mit.edu> Cc: Olle E Johansson , Christer Holmberg , "sipcore@ietf.org" To: Paul Kyzivat References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 07:23:49 -0000 --Apple-Mail=_8447638D-BAAC-4F55-8D3B-13BFE45955BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Jul 2019, at 18:55, Paul Kyzivat wrote: >=20 > On 7/9/19 12:28 PM, 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 = uppoabout 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. >>>>> =20 >>>> 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. >>>>=20 >>>> 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. >> The REGISTER request, and the token, will only reach the registrar. >=20 > And any proxies on the path to the registrar. >=20 > But if I send an INVITE, am challenged by the target of the INVITE, = and then send the token in a retry of the INVITE then it only goes = there, where it is supposed to go. How is that any different from the = registrar case? Is it because I somehow trust the registrar more that I = trust who I am calling? >=20 > ISTM that what is more important is the relationship between the = domain of the UAS I'm trying to contact and the realm of the challenge. = (Do I think this server has any business claiming to be authenticate for = this realm?) >=20 > The other tricky part is deciding whether to send the cached = credentials (token) in a new request that hasn't just immediately = challenged. But note that the request "in response" to a challenge is = indistinguishable from a request sent to the same target later other = than by time delay. The security concerns should be the same. Sending = the token to some other target before being challenged by that target is = a different leap of faith, so has different concerns. >=20 > My main point here is not to get you to explain it to me in this email = thread. What I want is to see this discussed adequately in the security = considerations of the document. If it isn't "safe" to send the token to = everybody, then how do I decide who I can safely send it to? >=20 > One partial answer might be: if a challenge results in asking the user = to authenticate for the realm, then the user gets to decide if he wants = to, and if so then the resulting token should be sent to the same target = just then. But this doesn't address when the same token can be used = preemptively later. That still needs discussion. This is an interesting topic that we really need to look into seriously. = Consider an access token that has a validity of one hour. That token can = be copied by any proxys or network elements on the path and be re-used = by others within the validity period to get access. RFC 6749 Section 10.3 clearly states the need for confidentiality of the = access token: "Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. " One solution would be that the challenge indicates a pointer to a valid = cert with a public key to use for encryption of the tokens. We have the = identity-info header in RFC 4474 as an example of pointing to a cert. = The implementation supporting this draft already supports https=E2=80=A6 /O --Apple-Mail=_8447638D-BAAC-4F55-8D3B-13BFE45955BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 9 Jul 2019, at 18:55, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On = 7/9/19 12:28 PM, 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 uppoabout 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.
The REGISTER request, and the token, = will only reach the registrar.

And any proxies on the path to the registrar.
But if I send an INVITE, am challenged by the target of the = INVITE, and then send the token in a retry of the INVITE then it only = goes there, where it is supposed to go. How is that any different from = the registrar case? Is it because I somehow trust the registrar more = that I trust who I am calling?

ISTM that = what is more important is the relationship between the domain of the UAS = I'm trying to contact and the realm of the challenge. (Do I think this = server has any business claiming to be authenticate for this realm?)

The other tricky part is deciding whether to = send the cached credentials (token) in a new request that hasn't just = immediately challenged. But note that the request "in response" to a = challenge is indistinguishable from a request sent to the same target = later other than by time delay. The security concerns should be the = same. Sending the token to some other target before being challenged by = that target is a different leap of faith, so has different concerns.

My main point here is not to get you to = explain it to me in this email thread. What I want is to see this = discussed adequately in the security considerations of the document. If = it isn't "safe" to send the token to everybody, then how do I decide who = I can safely send it to?

One partial answer = might be: if a challenge results in asking the user to authenticate for = the realm, then the user gets to decide if he wants to, and if so then = the resulting token should be sent to the same target just then. But = this doesn't address when the same token can be used preemptively later. = That still needs discussion.

This is an interesting topic that we really need to look into = seriously. Consider an access token that has a validity of one hour. = That token can be copied by any proxys or network elements on the path = and be re-used by others within the validity period to get = access.

RFC = 6749 Section 10.3 clearly states the need for confidentiality of the = access token:

"Access token credentials (as well as any confidential access = token
   attributes) MUST be kept confidential in transit and storage, =
and
   only shared among the authorization server, the resource servers the
   access token is valid for, and the client to whom the access token is
   issued.
"

One solution would be that the = challenge indicates a pointer to a valid cert with a public key to use = for encryption of the tokens. We have the identity-info header in RFC = 4474 as an example of pointing to a cert. The implementation supporting = this draft already supports https=E2=80=A6

/O


= --Apple-Mail=_8447638D-BAAC-4F55-8D3B-13BFE45955BB-- From nobody Wed Jul 10 02:28:30 2019 Return-Path: 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 DD705120099 for ; Wed, 10 Jul 2019 02:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 qeHB5txi0vfm for ; Wed, 10 Jul 2019 02:28:26 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40053.outbound.protection.outlook.com [40.107.4.53]) (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 75CC01200FA for ; Wed, 10 Jul 2019 02:28:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T4E6do7KLcnmMCTk2hviKY4/SJ6T7Rv8pXwfLwXMJ2nB+Xj8ItdllkdPSBTLmdfKNgPkms+ao4OZcqp3s8AWCrH5tK8P8UlnElTbYmQhDob0yM95a+F4l8qygUBiBYahuD9ZXUeNWVCCw6Vapi7O4KMtZ+2oN6z9fYFpA2zI5W1h4nF6kyKqTLQTcx0qF7RkcEncp1slr6Z9l+ZVHM4n0aMmZIbUr2ahDewUm9gCZPTdBgF5zZWUOB9zC0B1AkTu0zEYpWeh366q0TnExDeJN7rv64pKauQp52WPng7sZ60apbLfIco+168b+A9Ahu6zT5YEkU5k/ahlwcPWXfv/sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJ8Iu6qN9+7ijpq6Aho0UPILAeHEOHt7azRlyFBaxmw=; b=OLaLZbhgZnIV6SEWqEkpm5FojYVP0ZSK32fzPeEfcWBF9PiYB12wrTTVXjlR1TlDjWggfZfX36szvMPuw0vC8GfLdhqtaTQCdj2TeXDXaRVu6C7+CvhtA1NNeaKCAtrp6P+KdNr7Zox7EJVklCmS/Xw29RksdIz7npynPN0XumPHtmLUeOUbwjHTqhnVE3emUctaNZKz4KQGFi3RIEu67fX67QfH6+451ocD6FRvDBQmjA9bMC4uVtBy4QgOrFnEehDPH8tpY79O+nMhAK6YCvgtM390xE7ZVirSvOOJJpqc+kGz7X4CC5M07eR/mm5dbKqlv4t+CiDZgvQKDV7eoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJ8Iu6qN9+7ijpq6Aho0UPILAeHEOHt7azRlyFBaxmw=; b=bMmDd1OMqIoNNQ0wiQl1uV4DVR+WH02Ow4Bn68Y9xrMEMyH3FtRzIUzvKxpDMh9vWELQbTJ3I8O5qXQD9E9uUba8HAPI/wGiwxiD6p4iVkrmYlmCJt9KsvkPd5pOW68GQ5ZJgZRNeMoywMFHKDA0qoaOkDzDdfH+i5H0Wgq+KSs= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3163.eurprd07.prod.outlook.com (10.170.245.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.5; Wed, 10 Jul 2019 09:28:22 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 09:28:22 +0000 From: Christer Holmberg To: "Olle E. Johansson" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgADykoCAAFUggA== Date: Wed, 10 Jul 2019 09:28:22 +0000 Message-ID: <13F2FBCE-DBA3-4582-9CDF-6D6D4684952C@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08a8509b-1453-4b7b-eb6c-08d70518f3d4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3163; x-ms-traffictypediagnostic: HE1PR07MB3163: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(396003)(346002)(39860400002)(199004)(189003)(316002)(486006)(44832011)(58126008)(33656002)(476003)(6506007)(68736007)(2616005)(11346002)(110136005)(446003)(305945005)(76176011)(26005)(36756003)(71190400001)(71200400001)(186003)(2906002)(76116006)(102836004)(99286004)(3846002)(14454004)(53936002)(66476007)(66446008)(86362001)(6116002)(229853002)(5660300002)(6486002)(256004)(14444005)(25786009)(7736002)(4326008)(8676002)(478600001)(6512007)(66066001)(6246003)(6436002)(2171002)(64756008)(8936002)(81156014)(81166006)(66946007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3163; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wYLg43iy/gIwzME0t5n36Z9mdHCL2gpJUpBHCgPeY7ueFPwvaXofQjZHsCTSe2RF42ruIEejPS7YPVhExOeFwNL/UbsHCyUM7SaLOWAoC/7HVwSzPIcwWfBu0CkdlWkFhCZU1EVacrzbtjJsxK2yCVJPy5SuqrILyEfAKO7p27XmNur8TwQnm+NHqHTsUUbbMYCAa0lu2jMAgYMHEyZBUKKnmRsPx4iu8rjsqynXzSj7+Mli/K5zqQ4tcjwVc2S5p2LWbLK/o5ZyjRtkOJk9k0JAde8wW7NwsH3sNTgQeuhVAoOdWZjndeBsjB4voGuocxwpfikYEeO8Q1JnGvH9wpOIeNUkndfaxVrOYSF757yEmO+G4yIV8AI4hs3H3EyY/dQdnw5/u4FoHwUSfEJdmfaVpYV3+bKrSguUH5nISuc= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08a8509b-1453-4b7b-eb6c-08d70518f3d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 09:28:22.2826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3163 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 09:28:29 -0000 SGksDQoNCi4uLg0KDQo+PiBNeSBtYWluIHBvaW50IGhlcmUgaXMgbm90IHRvIGdldCB5b3UgdG8g ZXhwbGFpbiBpdCB0byBtZSBpbiB0aGlzIGVtYWlsIHRocmVhZC4gV2hhdCBJIHdhbnQgaXMgdG8g c2VlIHRoaXMgZGlzY3Vzc2VkIGFkZXF1YXRlbHkgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIG9mIHRoZSBkb2N1bWVudC4gSWYgaXQgaXNuJ3QgInNhZmUiIHRvIHNlbmQgdGhlIHRva2Vu IHRvIGV2ZXJ5Ym9keSwgdGhlbiBob3cgZG8gSSBkZWNpZGUgd2hvIEkgY2FuIHNhZmVseSBzZW5k IGl0IHRvPw0KPj4NCj4+IE9uZSBwYXJ0aWFsIGFuc3dlciBtaWdodCBiZTogaWYgYSBjaGFsbGVu Z2UgcmVzdWx0cyBpbiBhc2tpbmcgdGhlIHVzZXIgdG8gYXV0aGVudGljYXRlIGZvciB0aGUgcmVh bG0sIHRoZW4gdGhlIHVzZXIgZ2V0cyB0byBkZWNpZGUgaWYgaGUgd2FudHMgdG8sIGFuZCBpZiBz byB0aGVuIHRoZSByZXN1bHRpbmcgdG9rZW4gc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWUgdGFy Z2V0IGp1c3QgdGhlbi4gQnV0IHRoaXMgZG9lc24ndCBhZGRyZXNzIHdoZW4gdGhlIHNhbWUgdG9r ZW4gY2FuIGJlIHVzZWQgcHJlZW1wdGl2ZWx5IGxhdGVyLiBUaGF0IHN0aWxsIG5lZWRzIGRpc2N1 c3Npb24uDQo+Pg0KPiBUaGlzIGlzIGFuIGludGVyZXN0aW5nIHRvcGljIHRoYXQgd2UgcmVhbGx5 IG5lZWQgdG8gbG9vayBpbnRvIHNlcmlvdXNseS4gQ29uc2lkZXIgYW4gYWNjZXNzIHRva2VuIHRo YXQgaGFzIGEgdmFsaWRpdHkgb2Ygb25lIGhvdXIuIFRoYXQgdG9rZW4gY2FuIGJlIGNvcGllZCBi eSBhbnkgcHJveHlzIG9yIG5ldHdvcmsgZWxlbWVudHMgb24gdGhlIHBhdGggYW5kIGJlIHJlLXVz ZWQgYnkgb3RoZXJzIHdpdGhpbiB0aGUgdmFsaWRpdHkgcGVyaW9kIHRvIGdldCBhY2Nlc3MuDQo+ DQo+IFJGQyA2NzQ5IFNlY3Rpb24gMTAuMyBjbGVhcmx5IHN0YXRlcyB0aGUgbmVlZCBmb3IgY29u ZmlkZW50aWFsaXR5IG9mIHRoZSBhY2Nlc3MgdG9rZW46DQo+DQo+ICJBY2Nlc3MgdG9rZW4gY3Jl ZGVudGlhbHMgKGFzIHdlbGwgYXMgYW55IGNvbmZpZGVudGlhbCBhY2Nlc3MgdG9rZW4NCj4gICBh dHRyaWJ1dGVzKSBNVVNUIGJlIGtlcHQgY29uZmlkZW50aWFsIGluIHRyYW5zaXQgYW5kIHN0b3Jh Z2UsIGFuZA0KPiAgIG9ubHkgc2hhcmVkIGFtb25nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwg dGhlIHJlc291cmNlIHNlcnZlcnMgdGhlDQo+ICAgYWNjZXNzIHRva2VuIGlzIHZhbGlkIGZvciwg YW5kIHRoZSBjbGllbnQgdG8gd2hvbSB0aGUgYWNjZXNzIHRva2VuIGlzDQo+ICAgaXNzdWVkLiIN Cj4NCj4gT25lIHNvbHV0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIGNoYWxsZW5nZSBpbmRpY2F0ZXMg YSBwb2ludGVyIHRvIGEgdmFsaWQgY2VydCB3aXRoIGEgcHVibGljIGtleSB0byB1c2UgZm9yIGVu Y3J5cHRpb24gb2YgdGhlIHRva2Vucy4gV2UgaGF2ZSB0aGUgaWRlbnRpdHktaW5mbyBoZWFkZXIg aW4gUkZDIDQ0NzQgDQo+IGFzIGFuIGV4YW1wbGUgb2YgcG9pbnRpbmcgdG8gYSBjZXJ0LiBUaGUg aW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0aGlzIGRyYWZ0IGFscmVhZHkgc3VwcG9ydHMgaHR0 cHPigKYNCg0KQXMgSSBpbmRpY2F0ZWQgaW4gYW5vdGhlciBlLW1haWwsIHRoZSB0b2tlbiBuZWVk cyB0byBiZSBwcm90ZWN0ZWQsIHNvIHRoYXQgcHJveGllcyBiZXR3ZWVuIHRoZSBVQSBhbmQgcmVn aXN0cmFyIChpbiB0aGUgY2FzZSBvZiBSRUdJU1RFUikgY2FuJ3QgdXNlIGl0Lg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo= From nobody Wed Jul 10 02:35:07 2019 Return-Path: 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 3B1541200FA for ; Wed, 10 Jul 2019 02:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 T8F0ibrvf7ak for ; Wed, 10 Jul 2019 02:35:03 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40041.outbound.protection.outlook.com [40.107.4.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C19120099 for ; Wed, 10 Jul 2019 02:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F661H0tAO9Zdcnojj5bmd5wf/CwmM903S60DyRQEBUQ=; b=Z1BBWDMdWjF2qj4mMq1ANdN1uX9QYEdAsxsVJfStNo8fpvQONdYPlLg6vr1h9BCi2lJ7u48cZ5cynC7wZwA0OPhb434n7OXV8lE3Z+CFLBdF8wbmriFCmUvdM51w7sZwQOEyGIhBQAqmYAk2/Qag2BaGJjH/7TKTwtmuNqS3mRo= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB1034.eurprd07.prod.outlook.com (10.162.27.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.12; Wed, 10 Jul 2019 09:34:59 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 09:34:59 +0000 From: Christer Holmberg To: "Olle E. Johansson" , Roman Shpount CC: "sipcore@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAAeAYCAABzUAIAABQKAgAACsgCAABGcAIAABn4AgABh5YCAAGIMAA== Date: Wed, 10 Jul 2019 09:34:59 +0000 Message-ID: <09D82DB1-9372-4D61-A1F5-F2DD2347BF79@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> In-Reply-To: <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 015367e2-b28c-46a7-540a-08d70519e09d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB1034; x-ms-traffictypediagnostic: HE1PR07MB1034: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(346002)(376002)(366004)(189003)(199004)(33656002)(71190400001)(58126008)(6116002)(110136005)(54906003)(68736007)(36756003)(14454004)(478600001)(71200400001)(86362001)(4326008)(7736002)(25786009)(305945005)(8936002)(81156014)(5660300002)(66446008)(66556008)(2616005)(66476007)(6246003)(64756008)(186003)(44832011)(446003)(2906002)(8676002)(6512007)(66946007)(4744005)(486006)(6486002)(476003)(11346002)(6506007)(14444005)(76116006)(102836004)(53936002)(66066001)(229853002)(3846002)(26005)(316002)(6436002)(256004)(99286004)(81166006)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1034; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8XJWcytA9z3VlpTzibuO49dR9HXhjHS7SKOlfl+ddJYVMNHdyVRzFhXdX9WIpuuUIbitlPF2FPnEpXXo448UPkeF3VukkoA1CwGd7TKWJLHAjNMslpoPctJA0dkT5WoBFG5uctM+51BIsvXrS5SNbBSAdeozmA306S0wZZcdtjUA5Jcbg1RlAi5nj8E1zMcpXnGu7hCLj+3A3JKDLQCZbeYxChBFo+lPeNt9ByB0w8SRBiu9lcgis+3uShvmFZJDNHL4M0kGXiXbUtq1tfeUIebmZNOX1HUikKtT3aYU3JqJO2KSrJZyelRpkpWqi4ithwQv3hvb8nfwG+ZgWzcWLXY6WlwclFycGBmuyvw7Eh92dUNwKfk4kqmDJ7EqKxhNzxfmYKRC1rI2BVrqgTA7yFfMM8UX9IzF82x/7hCp92E= Content-Type: text/plain; charset="utf-8" Content-ID: <18D101FCC504684C9524EFC294C3AD6D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 015367e2-b28c-46a7-540a-08d70519e09d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 09:34:59.4274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1034 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 09:35:05 -0000 SGksDQoNCj4gV2hlbiB0aGUgdG9rZW4gZXhwaXJlcywgeW91IGNlcnRhaW5seSBuZWVkIGEgbmV3 IHRva2VuIGZyb20gdGhlIHVzZXIuIFdpdGggU0lQIE91dGJvdW5kLCB3ZeKAmXJlIG1vcmUgDQo+ IGNvbm5lY3Rpb24gb3JpZW50ZWQgdGhhbiBiZWZvcmUsIHNvIHdlIHNob3VsZCBwcm9wYWJseSBj b25zaWRlciB3aGF0IHRoZQ0KPiBzZXJ2ZXIgZG9lcyB3aXRoIHRoZSBjb25uZWN0aW9uIHdoZW4g YSB0b2tlbiBleHBpcmVzIChpZiBpdOKAmXMgbm90IGFscmVhZHkgaW4gdGhlIGRyYWZ0KS4NCg0K V2UgY2FuIGFkZCBzb21lIHdvcmRzIGFib3V0IHRoYXQuDQoNCkRvIHlvdSB0aGluayB0aGVyZSBp cyBzb21ldGhpbmcgT0F1dGggc3BlY2lmaWM/IENyZWRlbnRpYWxzIGNhbiBleHBpcmUgd2hlbiB5 b3UgdXNlIG90aGVyIHR5cGVzIG9mIGF1dGhlbnRpY2F0aW9uIHRvby4gRG9lcyAzMjYxIGFuZC9v ciBPdXRib3VuZCBzYXkgYW55dGhpbmcgYWJvdXQgdGhhdD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQoNCg== From nobody Wed Jul 10 04:50:59 2019 Return-Path: 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 6C1E31200A3 for ; Wed, 10 Jul 2019 04:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bxIVYorUBuCo for ; Wed, 10 Jul 2019 04:50:47 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 A95A51200E7 for ; Wed, 10 Jul 2019 04:50:47 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id z3so4088018iog.0 for ; Wed, 10 Jul 2019 04:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T/fYueD6PRGM1RbMJ2VnPZ4F4yeeSm29+w3no3DoPPA=; b=dhBKT7qVt716Egdyyg294WKZxPZV4kx7LdqXfWwfhf3pG2XraRc62z0QOaHvD+ek54 UFjUomZEa3u3IPTa1n7iF5AOdUkvcWZVRZRsIt+AR0fFbPgNjmmu/5dKCT/BuN1bBEh8 KlL5XtUntBMjm3uGwriksWFZZJh2cUpUiUvdfTg4J8g1eX08asY9CQmu012u7pGkwfMT FsP3qDF6NHHiBLw684IkZsXoH783x1pPkU9vffURrjIuBIt1f/UnvSMzi6Yov4rChwyb 2dCobo14ZmAdfvUIjdCNVeWCzz1I6FvvVtw6dEfkn8QMQTZBOU8z/3gPGJA3P/jjstPU DqWQ== 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=T/fYueD6PRGM1RbMJ2VnPZ4F4yeeSm29+w3no3DoPPA=; b=P6p6Tno9ioPp3SyNZ4/bJCK7z8zGSlqJgdcm7NTmqjKcI/9ZtBrCjotHhsjTLVnIwc m8KaiOEG9fxARa00cfPghjJhvUirr8TF3E1IphFCQInyWAQAU214Ay3HQmeAi9q0HVP9 5Oi3r/foE+uwWqjmI5YWcw9zjijIQufuQOE+27pUAcRnpJgEk/IEjhIc1RiLyS5uJgj1 ReYmkjSL/w0tkpi0TRSAhUVajAO11MjY+DCFbIwa7q/uMwsa4CvQC+9XCgQPsirKaxGQ sOdUYgWIuqkrKi4wh+govfw5Cfb8ivgd9ivRERgE7tf7yzXLLwl4weZWuzuAodZm2jA4 I0bQ== X-Gm-Message-State: APjAAAXurzzj9J8gbXh2VXLu7IBmVTLuKfaMq6KU36Yeq5vuYkecJxqa aXAMiTnfLI1CqzRKVMHVC/MfLslXHSmQeuUV2bYCPOEV X-Google-Smtp-Source: APXvYqyYL0uj25w8MqcF/IQZy6w0SPvB9/HPnPqWJHeyjkn+9PIrSyU+53yqY3HRXA3WEoaZPuq94ZCUsEw7gr4LMBA= X-Received: by 2002:a02:ac03:: with SMTP id a3mr35507896jao.132.1562759446908; Wed, 10 Jul 2019 04:50:46 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> In-Reply-To: <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 07:50:35 -0400 Message-ID: To: "Olle E. Johansson" Cc: Roman Shpount , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b3d28f058d5249b1" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 11:50:51 -0000 --000000000000b3d28f058d5249b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When the UA authenticates to the AS, it obtains a number of tokens: access token and refresh token, and depends on the AS, maybe ID token. It is the UAs responsibility to use the refresh token to obtain a new access token before the expiry of the existing access token. Regards, Rifaat On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson wrote: > > > On 10 Jul 2019, at 02:53, Roman Shpount wrote: > > On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef > 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=E2=80=99re more connection oriented than before, so= we should > propably consider what the > server does with the connection when a token expires (if it=E2=80=99s not= already > in the draft). > /O > > > 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 OAu= th > use case for Public User Agent, but only have a vague idea what OAuth wit= h > 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 Hom= e > 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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000b3d28f058d5249b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When the UA authenticates to the AS, it obtains a number o= f tokens: access token and refresh token, and depends on the AS, maybe ID t= oken.
It is the UAs responsibility to use the refresh token to obtain a= new access token before the expiry of the existing access token.

Regards,
=C2=A0Rifaat


On = Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <oej@edvina.net> wrote:

=
On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.co= m> wrote:

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 sa= me realm.

Whether that is needed or not is a different di= scussion.
Assuming the UA was able to authenticate t= he user and obtain an access token, then establish an authenticated TLS cha= nnel with the server, and register the user; is there a need for further ch= allenges from server?

When the token expires= , you certainly need a new token from the user. With SIP Outbound, we=E2=80= =99re more connection oriented than before, so we should propably consider = what the
server does with the connection when a token expires (if= it=E2=80=99s not already in the draft).
/O

<= div>Typically, for SIP, user authentication is not tied to the TLS connecti= on. 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 co= nnection to the registrar/proxy on behalf of multiple clients.
Once again, it would be much easier to discuss if you can prov= ide 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.=C2=A0

The exa= mple I can think of, would be some sort of hot desk application, where user= allows a=C2=A0Local 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 mu= ltiple calls or end user devices. Local PBX and User Home PBX will have a t= rust 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
=C2= =A0
_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

--000000000000b3d28f058d5249b1-- From nobody Wed Jul 10 04:52:02 2019 Return-Path: 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 D4F09120111 for ; Wed, 10 Jul 2019 04:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Tfzc0pXizEwx for ; Wed, 10 Jul 2019 04:51:57 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 A85911200A3 for ; Wed, 10 Jul 2019 04:51:57 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id i10so3954197iol.13 for ; Wed, 10 Jul 2019 04:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wWuDYTBGfUOM0iK2dOZRUtAl3XMPcNFdoHF04+CbS6c=; b=V55h+LY3g4SDlfhD7s1mErrOjcdr3sNOdixyPYw5TXbu5ygGKINLNey6wWPNSjqeR/ er/vlvy9OBtD7IEDHIQrxLSwo3rS7WjlrGOKYE3khnfjbFynwDltZ1hxZuSXTLiyzw0y 7UlDDkISV7pYaNc15Tc+th4EQ364nbzjcpK0soFYB4v1Rh/a+ms9uJggOAwa9Mf1kbw4 hgQo9Dc/4kEWt8oBoUv92hY6vaTTbivLjKbp6nb4e763Az9nbjwx5ijBiAdj2pI83+6f bJ92jHPfZ9Tl+XXStNWz+7izmKVXiF5OC01ox6P1ZTnWjouYU7rLMeLtw6nva46AOlzh aobw== 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=wWuDYTBGfUOM0iK2dOZRUtAl3XMPcNFdoHF04+CbS6c=; b=mJUTFnz+6NGFZ7Amx3ivLVxqTixsH5zrDPaZ0I7M4RjBN+DRufp1zltNX9H13EAgni q7kfNOSBuqbGy79CNJFrqVQ9TvYmda1UDbziOr1cY39Nexry0uIkQ/knxcvkNe6QZU7n A+8yUEtfMWI4mT7PdHIBJ09TlEG5h4hDBY6UOdF0iuZYDcLaaZ/Xp+WRxqyfiGi9kkpk WghopJ8AYJkefFP3BsNM27i120m69o4DmDUK/5Srw+wjeTpynbv8n/LO3uyr8RFU3oo2 SMJJ5zTx5N39VgS3T/TGDut+CIsxTY4BOZRcXk6Zr26D6CCnHlNAG57MkbWIHHIgQlP0 95Cg== X-Gm-Message-State: APjAAAWLwQrsYdFDRjITfKSN24re8N2WWFIPepQ3xb0xI+8BoPqfRDDN tA50yfcsRDL2myqpATT5LlpCgcJ1IabK+D04RuVbar1E X-Google-Smtp-Source: APXvYqxg2MolbVZ70xXvZbAekulR6tgdNwAUBX4UlrluWJusKgBDYzgb5xx7N5dS5eKKgCL1UlYJWI7gE3CDcVdrszw= X-Received: by 2002:a6b:7401:: with SMTP id s1mr6855256iog.67.1562759517024; Wed, 10 Jul 2019 04:51:57 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 07:51:46 -0400 Message-ID: To: "Olle E. Johansson" Cc: Roman Shpount , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e1b584058d524deb" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 11:52:01 -0000 --000000000000e1b584058d524deb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson wrote: > > > On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef wrote= : > > This document is specifically focused on *confidential *UAs. > UAs running in the browser, public UAs, will be addressed in a separate > document. > > Maybe you should make that more clear, as it is very confusing > terminology=E2=80=A6 I see that section 1.2 in your draft defines theses > types, based on RFC 6749. You apply it to the term =E2=80=9CUA=E2=80=9D w= hich I think > confuses things. A =E2=80=9Cpublic UA=E2=80=9D may have support > for confidentiality, but not from an Oauth point of view. I think we > should look for other terms for this. > > Any suggested text? > In addition, I don=E2=80=99t find any text in your draft indicating that = =E2=80=9CPublic > UAs=E2=80=9D is out of scope. > > I will fix that. Thanks, Rifaat > /O > > > Regards, > Rifaat > > > On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount wrote: > >> On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> >> 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. >>> > >>> > Really? Normally, for a secure solution, every SIP request, including >>> requests sent by UA in dialog established from the >>> > server to the registered end point must be authenticated. OAuth for >>> REGISTRER requests only is kind of useless since it >>> > does not allow UA to send any messages to the server without some >>> additional authentication mechanism. >>> >>> Not sure what you mean by "secure solution", but UAs can still use SIP >>> Digest authentication. >>> >>> What I am saying is that only use-case for SIP OAuth I am aware of is >>> for REGISTER. >>> >>> How do they get these SIP Digest credentials? >> >> I am looking at a very simple SIP-Over-Websockets client scenario: >> >> User logs into the web site which uses OAuth. UA, running in the browser >> gets a token which is used to Register UA with a SIP proxy. >> >> What credentials is UA using to place a call (send INVITE to the proxy)? >> If a call comes in from the proxy to UA, what credentials is UA using to >> hang up the call (send BYE message)? >> >> Best Regards, >> _____________ >> Roman Shpount >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000e1b584058d524deb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 10, 2019 at 3:08 AM Olle = E. Johansson <oej@edvina.net> w= rote:


On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=
This document is specifically focused on confidential = UAs.
UAs running in the browser, public UAs, will be addressed in a sep= arate document.
Maybe you should make that mo= re clear, as it is very confusing terminology=E2=80=A6 I see that section 1= .2 in your draft defines theses
types, based on RFC 6749. You app= ly it to the term =E2=80=9CUA=E2=80=9D which I think confuses things. A =E2= =80=9Cpublic UA=E2=80=9D may have support
for confidentiality, bu= t not from an Oauth point of view. I think we should look for other terms f= or this.


Any sug= gested text?

=C2=A0
In addition, I don=E2=80=99t find any text in your draft indicating= that =E2=80=9CPublic UAs=E2=80=9D is out of scope.


I will fix that.

Thanks,
=C2=A0Rifaat

=C2=A0
/O

Regards,
=C2=A0Rifaat

=

On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount <roman@telurix.com> wrote:
On Tue, Jul 9, 2019 at 3:11 PM Christ= er Holmberg <christer.holmberg@ericsson.com> wrote:
>> 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 authenti= cation, and I wonder whether we even need
>> to cover it in the draft. We could limit the scope the REGISTER re= quests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separ= ate draft can be written.
>=C2=A0
> Really? Normally, for a secure solution, every SIP request, including = requests sent by UA in dialog established from the
> server to the registered end point must be authenticated. OAuth for RE= GISTRER requests only is kind of useless since it
> does not allow UA to send any messages to the server without some addi= tional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still us= e SIP Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is for R= EGISTER.

How do they get these SIP Digest credenti= als?

I am looking at a very simple SIP-Over-Websoc= kets client scenario:

User logs into the web site = which uses OAuth. UA, running in the browser gets a token which is used to = Register UA with a SIP proxy.

What credentials is = UA using to place a call (send INVITE to the proxy)?=C2=A0
If a c= all comes in from the proxy to UA, what credentials is UA using to hang up = the call (send BYE message)?

Best Regards,
__= ___________
Roman Shpount
=C2=A0
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

--000000000000e1b584058d524deb-- From nobody Wed Jul 10 04:56:25 2019 Return-Path: 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 9D49E1202E8 for ; Wed, 10 Jul 2019 04:56:13 -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 Vkv7rvjxf4xw for ; Wed, 10 Jul 2019 04:56:09 -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 E87351202C5 for ; Wed, 10 Jul 2019 04:56:08 -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 BFD7DA40; Wed, 10 Jul 2019 13:56:04 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_212EEB0A-1B4C-4648-80D0-FED4DF9444E8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 13:56:04 +0200 In-Reply-To: Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 11:56:20 -0000 --Apple-Mail=_212EEB0A-1B4C-4648-80D0-FED4DF9444E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef = wrote: >=20 > When the UA authenticates to the AS, it obtains a number of tokens: = access token and refresh token, and depends on the AS, maybe ID token. > It is the UAs responsibility to use the refresh token to obtain a new = access token before the expiry of the existing access token. Absolutely - my thought was what the server is supposed to do. Reading = the STUN/Oauth docs, I see a requirement for expiry being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, = the expiry time in SIP should be less than the time the token is valid. If the token expires, the server needs to reauth or deny services. It = is important that no services are delivered to an expired = authentication. /O >=20 > Regards, > Rifaat >=20 >=20 > On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >=20 >=20 >> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>=20 >> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >> The document clearly allows the use of access token to authenticate = non-REGISTER requests when challenged in the context of the same realm. >>=20 >> 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? >>=20 > When the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the > server does with the connection when a token expires (if it=E2=80=99s = not already in the draft). > /O >>=20 >> 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. >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> Best Regards, >> _____________ >> Roman Shpount >> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore = >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_212EEB0A-1B4C-4648-80D0-FED4DF9444E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

When the UA authenticates to the AS, it obtains a number of = tokens: access token and refresh token, and depends on the AS, maybe ID = token.
It is the UAs responsibility to use the refresh = token to obtain a new access token before the expiry of the existing = access token.
Absolutely - my thought was = what the server is supposed to do. Reading the STUN/Oauth docs, I see a = requirement for expiry
being less than token validity time. In = SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP should be = less
than the time the token is valid.

 If the token expires, the server needs to = reauth or deny services. It is important that no services are delivered = to an expired authentication.

/O

Regards,
 Rifaat


On Wed, Jul 10, 2019 at 2:44 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 = Jul 2019, at 02:53, Roman Shpount <roman@telurix.com> wrote:

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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does = with the connection when a token expires (if it=E2=80=99s not already in = the draft).
/O

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
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_212EEB0A-1B4C-4648-80D0-FED4DF9444E8-- From nobody Wed Jul 10 05:02:33 2019 Return-Path: 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 493ED120120 for ; Wed, 10 Jul 2019 05:02:31 -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 5qYR9k62bN_H for ; Wed, 10 Jul 2019 05:02:28 -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 B8193120111 for ; Wed, 10 Jul 2019 05:02:27 -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 3DED7A40; Wed, 10 Jul 2019 14:02:24 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <9AFBBA7B-8B43-4F4B-A704-FB8FF881FA24@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_E98CA61B-1E5E-4AAB-9FB2-9C7DF38B0E48" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 14:02:22 +0200 In-Reply-To: Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:02:31 -0000 --Apple-Mail=_E98CA61B-1E5E-4AAB-9FB2-9C7DF38B0E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 13:51, Rifaat Shekh-Yusef = wrote: >=20 >=20 >=20 > On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson > wrote: >=20 >=20 >> On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef > wrote: >>=20 >> This document is specifically focused on confidential UAs. >> UAs running in the browser, public UAs, will be addressed in a = separate document. > Maybe you should make that more clear, as it is very confusing = terminology=E2=80=A6 I see that section 1..2 in your draft defines = theses > types, based on RFC 6749. You apply it to the term =E2=80=9CUA=E2=80=9D = which I think confuses things. A =E2=80=9Cpublic UA=E2=80=9D may have = support > for confidentiality, but not from an Oauth point of view. I think we = should look for other terms for this. >=20 >=20 > Any suggested text? I carefully avoided any suggestions=E2=80=A6 Was hoping someone on the = mailling list would step forward with some brilliant new terminology. :-) Maybe just reverting to OAuth terminology with =E2=80=9Cpublic clients = and confidential clients=E2=80=9D to avoid setting our own terms and directly refer terminology to Oauth specs. I still don=E2=80=99t = like =E2=80=9Cconfidential client=E2=80=9D when they really mean = =E2=80=9Csomething that at least doesn=E2=80=99t show what they do in source code but may = still be totally insecure=E2=80=9D... Yeah, I know that=E2=80=99s a boring suggestion. /O :-) >=20 > =20 > In addition, I don=E2=80=99t find any text in your draft indicating = that =E2=80=9CPublic UAs=E2=80=9D is out of scope. >=20 >=20 > I will fix that. >=20 > Thanks, > Rifaat >=20 > =20 > /O >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount > wrote: >> On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg = > = wrote: >> >> As far as I know, OAuth for SIP has only been used for REGISTER = requests, between the UA and the registrar.=20 >> >> I have never heard about anyone using it for non-REGISTER = authentication, and I wonder whether we even need=20 >> >> 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. >> >=20 >> > Really? Normally, for a secure solution, every SIP request, = including requests sent by UA in dialog established from the=20 >> > server to the registered end point must be authenticated. OAuth for = REGISTRER requests only is kind of useless since it=20 >> > does not allow UA to send any messages to the server without some = additional authentication mechanism. >>=20 >> Not sure what you mean by "secure solution", but UAs can still use = SIP Digest authentication. >>=20 >> What I am saying is that only use-case for SIP OAuth I am aware of is = for REGISTER. >>=20 >> How do they get these SIP Digest credentials? >>=20 >> I am looking at a very simple SIP-Over-Websockets client scenario: >>=20 >> User logs into the web site which uses OAuth. UA, running in the = browser gets a token which is used to Register UA with a SIP proxy. >>=20 >> What credentials is UA using to place a call (send INVITE to the = proxy)?=20 >> If a call comes in from the proxy to UA, what credentials is UA using = to hang up the call (send BYE message)? >>=20 >> Best Regards, >> _____________ >> Roman Shpount >> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore = >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore = >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_E98CA61B-1E5E-4AAB-9FB2-9C7DF38B0E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 13:51, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:



On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson = <oej@edvina.net> = wrote:


On 9 Jul = 2019, at 23:16, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

This document is specifically = focused on confidential UAs.
UAs = running in the browser, public UAs, will be addressed in a separate = document.
Maybe you should make that more = clear, as it is very confusing terminology=E2=80=A6 I see that section = 1..2 in your draft defines theses
types, based on = RFC 6749. You apply it to the term =E2=80=9CUA=E2=80=9D which I think = confuses things. A =E2=80=9Cpublic UA=E2=80=9D may have = support
for confidentiality, but not from an Oauth = point of view. I think we should look for other terms for = this.


Any suggested = text?
I carefully avoided any = suggestions=E2=80=A6 Was hoping someone on the mailling list would step = forward with
some brilliant new terminology. :-)

Maybe just reverting to OAuth terminology with = =E2=80=9Cpublic clients and confidential clients=E2=80=9D to avoid = setting our own terms
and directly refer terminology to Oauth = specs. I still don=E2=80=99t like =E2=80=9Cconfidential client=E2=80=9D = when they really mean =E2=80=9Csomething
that at least = doesn=E2=80=99t show what they do in source code but may still be = totally insecure=E2=80=9D...

Yeah, I = know that=E2=80=99s a boring suggestion.

/O :-)

 
In = addition, I don=E2=80=99t find any text in your draft indicating that = =E2=80=9CPublic UAs=E2=80=9D is out of scope.


I will fix that.
Thanks,
 Rifaat

 
/O

Regards,
 Rifaat


On Tue, Jul = 9, 2019 at 3:29 PM Roman Shpount <roman@telurix.com> wrote:
On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 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.
> 
> Really? Normally, for a secure solution, every SIP request, = including requests sent by UA in dialog established from the
> server to the registered end point must be authenticated. OAuth for = REGISTRER requests only is kind of useless since it
> does not allow UA to send any messages to the server without some = additional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still use SIP = Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is = for REGISTER.

How do they get these SIP Digest credentials?

I am looking at a very = simple SIP-Over-Websockets client scenario:

User logs into the web site which uses = OAuth. UA, running in the browser gets a token which is used to Register = UA with a SIP proxy.

What credentials is UA using to place a call (send INVITE to = the proxy)? 
If a call comes in from the proxy = to UA, what credentials is UA using to hang up the call (send BYE = message)?

Best = Regards,
_____________
Roman Shpount
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_E98CA61B-1E5E-4AAB-9FB2-9C7DF38B0E48-- From nobody Wed Jul 10 05:18:49 2019 Return-Path: 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 CB2D912012B for ; Wed, 10 Jul 2019 05:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l9yrTXEzFs8I for ; Wed, 10 Jul 2019 05:18:45 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 4E215120026 for ; Wed, 10 Jul 2019 05:18:45 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id g20so4145478ioc.12 for ; Wed, 10 Jul 2019 05:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LFKHqeh3UEqz4ktbtM37AbYsQo73CpcqZv0P5QJDyDI=; b=FYTDztPf0q6nXpPd8jDmrFd7E2ZO//k0XX3Oq1j3oKBNZeEPh6N6/qoWTse/VEDwL+ F9r15mUsys/Mn/PbIG4XyGg5lETCZix+S/+eFlJHrrwGRKa7U1G71e1wIkmWz7ylp4+9 uj/zbeVUvmumwwwAiNr8mpmVNjSwE9v8ynra0T+F4wzMReu8SQN1iu1Un8WmEq7woyLW 39jf51UFDwIOm+hKAbsiIhqNb74hCtabYo1YGFqWr+PQFr5hI/L/s+t53IHV1zXNklGQ 2fE8sIGmwzIDzm16x0yMUo8bIovuzBmv/guW9+LjWbXMyzptEcCq6uijcoInHmKec617 vVpQ== 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=LFKHqeh3UEqz4ktbtM37AbYsQo73CpcqZv0P5QJDyDI=; b=EQvlsnTsdyFLYcEFf//CdRyqleX75T4ueWNoPWo4cpN1laHTE/D5zS9l6I4pD6N0yK 9JKX3K+FAK5+Wd00bPfacfOFHt3gy2jN0v/cJQCUkymoy9xvdymaQ98rl+WvmXx9FXLe m1SIsWLK52gWrxmKU3tC2vEnR5sOGFOysnKniyxEa27QEcoBAQhg4h5bCwAjigZyKGp1 MYDpurbUlSMvZFsQ+eZYPzPYgUEYPjHfR6hEJYYVnJVp8DALblNHPb+ATP1KyQWA2UqD C0tcJj1aLmifNq9UVbWjwzblKMapM7YJzUFcCH2tavjwek3Q7J5wbvahtg8R1jgqoY9I Wgcw== X-Gm-Message-State: APjAAAVxIBJg7kHUO9PsydIyWIR/09zhz2cHEI81C8gm6RwezOSPvrhE a+J6Z9wmziVY3/IbQcxBBWgWDjn3QiOBPBS8Y2c= X-Google-Smtp-Source: APXvYqxE7xv6YNtFealrRCepSUol1lR4zCQE8smjdQMRRzQZbvYWch5HhMUQD6zBvRTJfCvZBcmMJEA+VdSMDOS7mfk= X-Received: by 2002:a5d:9642:: with SMTP id d2mr13900922ios.278.1562761124591; Wed, 10 Jul 2019 05:18:44 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 08:18:33 -0400 Message-ID: To: "Olle E. Johansson" Cc: "sipcore@ietf.org" , Roman Shpount Content-Type: multipart/alternative; boundary="000000000000b33d85058d52ad6c" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:18:48 -0000 --000000000000b33d85058d52ad6c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The UA is expected to obtain a valid access token to get service, and should be able to use that to refresh its registration when the registration expires. Is this coupling of expiry times needed? Regards, Rifaat On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson wrote: > > > On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef > wrote: > > When the UA authenticates to the AS, it obtains a number of tokens: acces= s > token and refresh token, and depends on the AS, maybe ID token. > It is the UAs responsibility to use the refresh token to obtain a new > access token before the expiry of the existing access token. > > Absolutely - my thought was what the server is supposed to do. Reading th= e > STUN/Oauth docs, I see a requirement for expiry > being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, the > expiry time in SIP should be less > than the time the token is valid. > > If the token expires, the server needs to reauth or deny services. It is > important that no services are delivered to an expired authentication. > > /O > > > Regards, > Rifaat > > > On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson wrote: > >> >> >> On 10 Jul 2019, at 02:53, Roman Shpount wrote: >> >> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef >> 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=E2=80=99re more connection oriented than before, s= o we should >> propably consider what the >> server does with the connection when a token expires (if it=E2=80=99s no= t already >> in the draft). >> /O >> >> >> Typically, for SIP, user authentication is not tied to the TLS >> connection. One of the reasons for this is that multiple users can use t= he >> 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 multipl= e >> 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 OA= uth >> use case for Public User Agent, but only have a vague idea what OAuth wi= th >> 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 an= d >> 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 Ho= me >> 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 >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000b33d85058d52ad6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The UA is expected to obtain a valid access token to = get service, and should be able to use that to refresh its registration whe= n the registration expires.
Is this coupling of expiry times need= ed?

Regards,
=C2=A0Rifaat

=

On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:
=

On 10 Jul 2019, at 13:50, Rifaa= t Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

When the UA auth= enticates to the AS, it obtains a number of tokens: access token and refres= h token, and depends on the AS, maybe ID token.
It is the UAs responsib= ility to use the refresh token to obtain a new access token before the expi= ry of the existing access token.
Absolutely -= my thought was what the server is supposed to do. Reading the STUN/Oauth d= ocs, I see a requirement for expiry
being less than token validit= y time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP should be l= ess
than the time the token is valid.

= =C2=A0If the token expires, the server needs to reauth or deny services. It= is important that no services are delivered to an expired authentication.<= /div>

/O

Regards,
=C2=A0Rifaat

<= /div>

On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <oej@edvina.net> wrote:
=


On 10 Jul 2019, at 02:53, Roman Shpount <roman@telurix.com> w= rote:

On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = <rifaat.ietf@= gmail.com> wrote:
The docume= nt clearly allows the use of access token to authenticate non-REGISTER requ= ests when challenged in the context of the same realm.

Wh= ether that is needed or not is a different discussion.
Assuming the UA was able to authenticate the user and obtain an access t= oken, then establish an authenticated TLS channel with the server, and regi= ster the user; is there a need for further challenges from server?

When the token expires, you certainly need a new tok= en from the user. With SIP Outbound, we=E2=80=99re more connection oriented= than before, so we should propably consider what the
server does= with the connection when a token expires (if it=E2=80=99s not already in t= he draft).
/O
=

Typically, for SIP, user aut= hentication 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 relationshi= p with a proxy and can maintain a secure connection to the registrar/proxy = on behalf of multiple clients.

Once again, it woul= d be much easier to discuss if you can provide a use specific case for OAut= h with confidential UA. I can easily think of a OAuth use case for Public U= ser Agent, but only have a vague idea what OAuth with Confidential UA would= be.=C2=A0

The example I can think of, would be so= me sort of hot desk application, where user allows a=C2=A0Local PBX to regi= ster with User Home PBX to accept calls on behalf of user in a remote locat= ion. In this case, Local PBX and User Home PBX will be federated systems wh= ich 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 wi= ll be used to store actual user credentials and will be used to authenticat= e the user and generate the token.

Best Regards,_____________
Roman Shpount
=C2=A0
_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

--000000000000b33d85058d52ad6c-- From nobody Wed Jul 10 05:20:48 2019 Return-Path: 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 067D3120026 for ; Wed, 10 Jul 2019 05:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Z72tiwdVPOsI for ; Wed, 10 Jul 2019 05:20:45 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 A9D381200FB for ; Wed, 10 Jul 2019 05:20:45 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id j5so4189576ioj.8 for ; Wed, 10 Jul 2019 05:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xG2h81aRncvZ83QF09a+Wv8P/nqeyI7qjpJMAaKkdlU=; b=HYVsF1qiE8QA0sPXTZC/ob6AoJUptP6pFKEPWR5vb7vSGzIQ2R2Zz5SQPFpDf6u+Tk VMsk3j6/Gtgw8VYW+ACuQ0p1WlRsfFs69I/N185AnvXp6PHu3OUnX6HgNq7GnR6sYKJf V0L5iZX4GsUCDmmdLhX3d+9YRAjkArH0Mzjt9Zr9Ru2A6Sf6f60K8MDDJnzh8S8PGhVe A2eZNSxnmfjyiJxJGibvHC/2RolH9YgJ3rsxjkeCbZZeq8Lw3sGxuYzJ549wKBZecLwm ORDXfDUCNPl74wBeGo6RyHZa8dxry8vBOoFfaNUvckFRNCEv2SC4LRN8rcUzVXCr/Jsg cLgA== 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=xG2h81aRncvZ83QF09a+Wv8P/nqeyI7qjpJMAaKkdlU=; b=eDgmXYSX1VJo1RLYPTUMJjYUnfN+FCaAtap3np+zAwVVMT8sSFfDMTKYZbE+IsaEg0 lJjlW8ZOvGyxOQL6jtQlxW9iz6WzBucL/OH7tIWSjPUzXESuyWsaYX00XBIQHsInwH5q Z87GWfxchCrhnpjw4FxNqnhpO2RNmYyMYNKaBZpZzqRnga3XYuR/rdalohbSxjT3d853 RX2jDeMY8a7q6DmtxmwZHxC9VhEp/yKqw9So1fsWrOXkPA+4HDTH1FZ0lylKIaJxzF6J tIsEkycaJGnYl2KYtVnVlXZ1U3a8RKhoCgwpJ8zZPsnqiUSALDVJsIOlRwTUWGP4okPX 7VAg== X-Gm-Message-State: APjAAAUHVu7k8BI7uzerXfomRkNWMbh3QNR563xrWD0q4FGUbKssGl12 6Y/Nzq6t2NkdfhLYhkd0z7dhuGSyG0AP84bOfZw= X-Google-Smtp-Source: APXvYqxBHKmVSWorA09jYJS5yI7VR2p1tjwO6fyeyDtGlBijnwK1TF0PoP5AtFlofR0ZVecXoIN2qh8pViKh8Ae11PU= X-Received: by 2002:a5d:9642:: with SMTP id d2mr13911067ios.278.1562761244676; Wed, 10 Jul 2019 05:20:44 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <9AFBBA7B-8B43-4F4B-A704-FB8FF881FA24@edvina.net> In-Reply-To: <9AFBBA7B-8B43-4F4B-A704-FB8FF881FA24@edvina.net> From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 08:20:33 -0400 Message-ID: To: "Olle E. Johansson" Cc: "sipcore@ietf.org" , Roman Shpount Content-Type: multipart/alternative; boundary="000000000000db97e9058d52b419" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:20:48 -0000 --000000000000db97e9058d52b419 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am fine with referring to the OAuth definition. Anybody has an issue with this? Regards, Rifaat On Wed, Jul 10, 2019 at 8:02 AM Olle E. Johansson wrote: > > > On 10 Jul 2019, at 13:51, Rifaat Shekh-Yusef > wrote: > > > > On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson wrote: > >> >> >> On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef >> wrote: >> >> This document is specifically focused on *confidential *UAs. >> UAs running in the browser, public UAs, will be addressed in a separate >> document. >> >> Maybe you should make that more clear, as it is very confusing >> terminology=E2=80=A6 I see that section 1..2 in your draft defines these= s >> types, based on RFC 6749. You apply it to the term =E2=80=9CUA=E2=80=9D = which I think >> confuses things. A =E2=80=9Cpublic UA=E2=80=9D may have support >> for confidentiality, but not from an Oauth point of view. I think we >> should look for other terms for this. >> >> > Any suggested text? > > I carefully avoided any suggestions=E2=80=A6 Was hoping someone on the ma= illing > list would step forward with > some brilliant new terminology. :-) > > Maybe just reverting to OAuth terminology with =E2=80=9Cpublic clients an= d > confidential clients=E2=80=9D to avoid setting our own terms > and directly refer terminology to Oauth specs. I still don=E2=80=99t like > =E2=80=9Cconfidential client=E2=80=9D when they really mean =E2=80=9Csome= thing > that at least doesn=E2=80=99t show what they do in source code but may st= ill be > totally insecure=E2=80=9D... > > Yeah, I know that=E2=80=99s a boring suggestion. > > /O :-) > > > > >> In addition, I don=E2=80=99t find any text in your draft indicating that= =E2=80=9CPublic >> UAs=E2=80=9D is out of scope. >> >> > I will fix that. > > Thanks, > Rifaat > > > >> /O >> >> >> Regards, >> Rifaat >> >> >> On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount wrote: >> >>> On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> >> 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. >>>> > >>>> > Really? Normally, for a secure solution, every SIP request, includin= g >>>> requests sent by UA in dialog established from the >>>> > server to the registered end point must be authenticated. OAuth for >>>> REGISTRER requests only is kind of useless since it >>>> > does not allow UA to send any messages to the server without some >>>> additional authentication mechanism. >>>> >>>> Not sure what you mean by "secure solution", but UAs can still use SIP >>>> Digest authentication. >>>> >>>> What I am saying is that only use-case for SIP OAuth I am aware of is >>>> for REGISTER. >>>> >>>> How do they get these SIP Digest credentials? >>> >>> I am looking at a very simple SIP-Over-Websockets client scenario: >>> >>> User logs into the web site which uses OAuth. UA, running in the browse= r >>> gets a token which is used to Register UA with a SIP proxy. >>> >>> What credentials is UA using to place a call (send INVITE to the proxy)= ? >>> If a call comes in from the proxy to UA, what credentials is UA using t= o >>> hang up the call (send BYE message)? >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --000000000000db97e9058d52b419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am fine with referring to the OAuth definition.
Anyb= ody has an issue with this?

Regards,
=C2= =A0Rifaat


On Wed, Jul 10, 2019 at 8:02 AM Olle E. Johan= sson <oej@edvina.net> wrote:


On 10 J= ul 2019, at 13:51, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:



On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansso= n <oej@edvina.net> wrote:



This document is specifically focused on confidential UAs.=
UAs running in the browser, public UAs, will be addressed in a separat= e document.
Maybe you should make that more c= lear, as it is very confusing terminology=E2=80=A6 I see that section 1..2 = in your draft defines theses
types, based on RFC 6749. You apply = it to the term =E2=80=9CUA=E2=80=9D which I think confuses things. A =E2=80= =9Cpublic UA=E2=80=9D may have support
for confidentiality, but n= ot from an Oauth point of view. I think we should look for other terms for = this.


Any sugges= ted text?
I carefully avoided any sugge= stions=E2=80=A6 Was hoping someone on the mailling list would step forward = with
some brilliant new terminology. :-)

Maybe just reverting to OAuth terminology with =E2=80=9Cpublic clients and= confidential clients=E2=80=9D to avoid setting our own terms
and= directly refer terminology to Oauth specs. I still don=E2=80=99t like =E2= =80=9Cconfidential client=E2=80=9D when they really mean =E2=80=9Csomething=
that at least doesn=E2=80=99t show what they do in source code b= ut may still be totally insecure=E2=80=9D...

Yeah,= I know that=E2=80=99s a boring suggestion.

/O :-)=

=C2=A0
In addition, I don=E2=80=99t find any text = in your draft indicating that =E2=80=9CPublic UAs=E2=80=9D is out of scope.=


I will fix that= .

Thanks,
=C2=A0Rifaat

=C2=A0
=
/O
=
Regards,
=C2=A0Rifaat

On Tue, = Jul 9, 2019 at 3:29 PM Roman Shpount <roman@telurix.com> wrote:
On Tue, Jul 9, 2019 at 3:= 11 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>> 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 authenti= cation, and I wonder whether we even need
>> to cover it in the draft. We could limit the scope the REGISTER re= quests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separ= ate draft can be written.
>=C2=A0
> Really? Normally, for a secure solution, every SIP request, including = requests sent by UA in dialog established from the
> server to the registered end point must be authenticated. OAuth for RE= GISTRER requests only is kind of useless since it
> does not allow UA to send any messages to the server without some addi= tional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still us= e SIP Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is for R= EGISTER.

How do they get these SIP Digest credenti= als?

I am looking at a very simple SIP-Over-Websoc= kets client scenario:

User logs into the web site = which uses OAuth. UA, running in the browser gets a token which is used to = Register UA with a SIP proxy.

What credentials is = UA using to place a call (send INVITE to the proxy)?=C2=A0
If a c= all comes in from the proxy to UA, what credentials is UA using to hang up = the call (send BYE message)?

Best Regards,
__= ___________
Roman Shpount
=C2=A0
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

--000000000000db97e9058d52b419-- From nobody Wed Jul 10 05:23:00 2019 Return-Path: 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 065911200FB for ; Wed, 10 Jul 2019 05:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tmXdO0J9RbZS for ; Wed, 10 Jul 2019 05:22:53 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on062c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::62c]) (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 02B01120129 for ; Wed, 10 Jul 2019 05:22:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eAEK8hprPaC6tSl64eqFM9SGTj3MX59pUNtOXUEHrK2J26iKgCytS1X/mW6XKoW0HNUMILC8aHIYnY2TtfoQNrqhLgyzVchUNukKgPEuDtBp161eC3Kw+4acHrQ78MhotSHALwY9KwkbxbclDqXaYHtB0fjVNqgN2hq+teKujbN5H37Sy6fhZ9V+X5qOW2EEFva5IMX0hDzgRz4lB+wZbHSHpJ0X7YFqdFAdF+dkFRK4fSGoNElwi6NsaKuKzVWB6dW8gvuLNYuRPat4UufSfN85/dwVjmF1Tt5SpTCj0K//upUMePUmj/sJUK+A46IQ3us0bfwq3a0GWyIIWveA9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pIrdacj+ru4tSvalt8/SWNbgPUoNLF5YjVNgY3aQ38E=; b=mWoj0VJ2hZSfuYPbV9rO5M1Z59jtIRY2siyXDvtRaUqxUKB88dyfL8q/aR9hvN7jnmisGdTt5gmxE2JX2Ix8JnFPGxWfcy2qlpoiHUIInGFBzqBzHh9HNz+i20u4pkHl6ycNYtSB8kMUXKWp2WXPRgJGVRYxq6p6LIiuuwhWx+b3C0M4eN2nLqepeOk4nL3tIBOhSrk9Ws2iciJoWkYuBJc3EnU23gaLPlM1ZqUXBTMWr/w6oNM8zwdh8rNHv72YUZFimFjVaj5Pd9SF61CEwRcRuCU7Jj+n8xahdY0t6VPwvulE129fZ+FvO551xeoYlmybKqBlNXQq1mWVS5+1BQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pIrdacj+ru4tSvalt8/SWNbgPUoNLF5YjVNgY3aQ38E=; b=GLxar9anL+ATIfmTpS/6aVKUt38Ji57cQ8myMNjZYi/6YMq+dWO4Ly/EimX6H75+y5OXZefBUmxX6AsrXF7NEFAeFbbUbSX5GLovecULI1iHs9t/ALQq5IPxEpGr2XqnD+0+rvkTbb9XqJ73OCCAJh4920HTbjBBgZPTn7AiWkw= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3114.eurprd07.prod.outlook.com (10.170.245.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 12:22:50 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 12:22:50 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , "Olle E. Johansson" CC: "sipcore@ietf.org" , Roman Shpount Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAAeAYCAABzUAIAABQKAgAACsgCAABGcAIAABn4AgABh5YCAAFWlgIAAAYkAgAAGSICAADN8gA== Date: Wed, 10 Jul 2019 12:22:49 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18ddc4c9-d026-46bc-7d03-08d70531530c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3114; x-ms-traffictypediagnostic: HE1PR07MB3114: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(396003)(39860400002)(189003)(199004)(229853002)(66556008)(66946007)(44832011)(76116006)(4326008)(2906002)(14444005)(256004)(53546011)(7736002)(68736007)(6506007)(64756008)(54896002)(26005)(186003)(102836004)(71190400001)(81156014)(71200400001)(81166006)(53936002)(236005)(446003)(66446008)(6306002)(8676002)(66066001)(5660300002)(86362001)(6246003)(6436002)(6486002)(6512007)(66476007)(476003)(2616005)(6116002)(3846002)(966005)(33656002)(110136005)(316002)(58126008)(14454004)(478600001)(99286004)(25786009)(76176011)(8936002)(486006)(36756003)(11346002)(54906003)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3114; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LMIeKMlFM9BUiu6JxsGSTEmBD6pRRA9hSwkahxbkjH/pUYt7EiWeIF7sFMoa68N8TuViHpnD1FSaYZ8cBOtvH0hthv9jcvZHSFkClVBUnHVMwcYt+wmJfqbbEyYK3YwgGr7M8ipwq+L6Gk273OvzGq5cr1AAWiMJQ7svVCdKto5zHcURbRVkPvT7Ng8haDaSoKwzG0Cll8um0xrFIESCn6WBoArgsyDcL9bFk9/fURKfkKisS5HsfJvxSGGKsBFbCTAN/SWc00MEdHhYpKABPvj+EkL+Smyuc3HSf8COh0WDLktHJ8F8ZtIH0yXo5bdXNHkgmc74is1jWjUH5ay79YnotCDrZDAua22c1PHd4tJeSXEpfFGKOA3mnKhJ1X1ufFS5LJQqkEQJEj5N8mgjQCK6s4QwblqZLIHej/CCkMo= Content-Type: multipart/alternative; boundary="_000_ED23A59908C64359B2CA4DF287E29608ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18ddc4c9-d026-46bc-7d03-08d70531530c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 12:22:49.7080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3114 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:22:58 -0000 --_000_ED23A59908C64359B2CA4DF287E29608ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk1heWJlIHdlIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgdG9rZW4gZXhwaXJhdGlvbiBh bmQgcmVnaXN0cmF0aW9uIGV4cGlyYXRpb24gYXJlIHR3byBzZXBhcmF0ZSB0aGluZ3MsIGJ1dCBJ IGRvbuKAmXQgdGhpbmsgdGhleSBzaG91bGQgYmUgY291cGxlZC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhh bGYgb2YgUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBX ZWRuZXNkYXksIDEwIEp1bHkgMjAxOSBhdCAxNS4xOQ0KVG86IE9sbGUgSm9oYW5zc29uIDxvZWpA ZWR2aW5hLm5ldD4NCkNjOiAic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0Zi5vcmc+LCBS b21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnotMDIudHh0DQoN ClRoZSBVQSBpcyBleHBlY3RlZCB0byBvYnRhaW4gYSB2YWxpZCBhY2Nlc3MgdG9rZW4gdG8gZ2V0 IHNlcnZpY2UsIGFuZCBzaG91bGQgYmUgYWJsZSB0byB1c2UgdGhhdCB0byByZWZyZXNoIGl0cyBy ZWdpc3RyYXRpb24gd2hlbiB0aGUgcmVnaXN0cmF0aW9uIGV4cGlyZXMuDQpJcyB0aGlzIGNvdXBs aW5nIG9mIGV4cGlyeSB0aW1lcyBuZWVkZWQ/DQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KT24g V2VkLCBKdWwgMTAsIDIwMTkgYXQgNzo1NiBBTSBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmlu YS5uZXQ8bWFpbHRvOm9lakBlZHZpbmEubmV0Pj4gd3JvdGU6DQoNCg0KDQpPbiAxMCBKdWwgMjAx OSwgYXQgMTM6NTAsIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1h aWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KV2hlbiB0aGUgVUEgYXV0aGVu dGljYXRlcyB0byB0aGUgQVMsIGl0IG9idGFpbnMgYSBudW1iZXIgb2YgdG9rZW5zOiBhY2Nlc3Mg dG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4sIGFuZCBkZXBlbmRzIG9uIHRoZSBBUywgbWF5YmUgSUQg dG9rZW4uDQpJdCBpcyB0aGUgVUFzIHJlc3BvbnNpYmlsaXR5IHRvIHVzZSB0aGUgcmVmcmVzaCB0 b2tlbiB0byBvYnRhaW4gYSBuZXcgYWNjZXNzIHRva2VuIGJlZm9yZSB0aGUgZXhwaXJ5IG9mIHRo ZSBleGlzdGluZyBhY2Nlc3MgdG9rZW4uDQpBYnNvbHV0ZWx5IC0gbXkgdGhvdWdodCB3YXMgd2hh dCB0aGUgc2VydmVyIGlzIHN1cHBvc2VkIHRvIGRvLiBSZWFkaW5nIHRoZSBTVFVOL09hdXRoIGRv Y3MsIEkgc2VlIGEgcmVxdWlyZW1lbnQgZm9yIGV4cGlyeQ0KYmVpbmcgbGVzcyB0aGFuIHRva2Vu IHZhbGlkaXR5IHRpbWUuIEluIFNJUCBSRUdJU1RFUi9TVUJTQ1JJQkUgdGVybXMsIHRoZSBleHBp cnkgdGltZSBpbiBTSVAgc2hvdWxkIGJlIGxlc3MNCnRoYW4gdGhlIHRpbWUgdGhlIHRva2VuIGlz IHZhbGlkLg0KDQogSWYgdGhlIHRva2VuIGV4cGlyZXMsIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gcmVh dXRoIG9yIGRlbnkgc2VydmljZXMuIEl0IGlzIGltcG9ydGFudCB0aGF0IG5vIHNlcnZpY2VzIGFy ZSBkZWxpdmVyZWQgdG8gYW4gZXhwaXJlZCBhdXRoZW50aWNhdGlvbi4NCg0KL08NCg0KDQpSZWdh cmRzLA0KIFJpZmFhdA0KDQoNCk9uIFdlZCwgSnVsIDEwLCAyMDE5IGF0IDI6NDQgQU0gT2xsZSBF LiBKb2hhbnNzb24gPG9lakBlZHZpbmEubmV0PG1haWx0bzpvZWpAZWR2aW5hLm5ldD4+IHdyb3Rl Og0KDQoNCg0KT24gMTAgSnVsIDIwMTksIGF0IDAyOjUzLCBSb21hbiBTaHBvdW50IDxyb21hbkB0 ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCg0KT24gVHVlLCBK dWwgOSwgMjAxOSBhdCA4OjMwIFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21h aWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBkb2N1bWVu dCBjbGVhcmx5IGFsbG93cyB0aGUgdXNlIG9mIGFjY2VzcyB0b2tlbiB0byBhdXRoZW50aWNhdGUg bm9uLVJFR0lTVEVSIHJlcXVlc3RzIHdoZW4gY2hhbGxlbmdlZCBpbiB0aGUgY29udGV4dCBvZiB0 aGUgc2FtZSByZWFsbS4NCg0KV2hldGhlciB0aGF0IGlzIG5lZWRlZCBvciBub3QgaXMgYSBkaWZm ZXJlbnQgZGlzY3Vzc2lvbi4NCkFzc3VtaW5nIHRoZSBVQSB3YXMgYWJsZSB0byBhdXRoZW50aWNh dGUgdGhlIHVzZXIgYW5kIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4sIHRoZW4gZXN0YWJsaXNoIGFu IGF1dGhlbnRpY2F0ZWQgVExTIGNoYW5uZWwgd2l0aCB0aGUgc2VydmVyLCBhbmQgcmVnaXN0ZXIg dGhlIHVzZXI7IGlzIHRoZXJlIGEgbmVlZCBmb3IgZnVydGhlciBjaGFsbGVuZ2VzIGZyb20gc2Vy dmVyPw0KDQpXaGVuIHRoZSB0b2tlbiBleHBpcmVzLCB5b3UgY2VydGFpbmx5IG5lZWQgYSBuZXcg dG9rZW4gZnJvbSB0aGUgdXNlci4gV2l0aCBTSVAgT3V0Ym91bmQsIHdl4oCZcmUgbW9yZSBjb25u ZWN0aW9uIG9yaWVudGVkIHRoYW4gYmVmb3JlLCBzbyB3ZSBzaG91bGQgcHJvcGFibHkgY29uc2lk ZXIgd2hhdCB0aGUNCnNlcnZlciBkb2VzIHdpdGggdGhlIGNvbm5lY3Rpb24gd2hlbiBhIHRva2Vu IGV4cGlyZXMgKGlmIGl04oCZcyBub3QgYWxyZWFkeSBpbiB0aGUgZHJhZnQpLg0KL08NCg0KDQpU eXBpY2FsbHksIGZvciBTSVAsIHVzZXIgYXV0aGVudGljYXRpb24gaXMgbm90IHRpZWQgdG8gdGhl IFRMUyBjb25uZWN0aW9uLiBPbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoaXMgaXMgdGhhdCBtdWx0 aXBsZSB1c2VycyBjYW4gdXNlIHRoZSBzYW1lIFRMUyBjb25uZWN0aW9uIGluIGZlZGVyYXRlZCBz eXN0ZW1zLi4gVGhpcyBpcyBlc3BlY2lhbGx5IHRydWUgZm9yIENvbmZpZGVudGlhbCBVQSwgd2hp Y2ggaGF2ZSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aCBhIHByb3h5IGFuZCBjYW4gbWFpbnRhaW4g YSBzZWN1cmUgY29ubmVjdGlvbiB0byB0aGUgcmVnaXN0cmFyL3Byb3h5IG9uIGJlaGFsZiBvZiBt dWx0aXBsZSBjbGllbnRzLg0KDQpPbmNlIGFnYWluLCBpdCB3b3VsZCBiZSBtdWNoIGVhc2llciB0 byBkaXNjdXNzIGlmIHlvdSBjYW4gcHJvdmlkZSBhIHVzZSBzcGVjaWZpYyBjYXNlIGZvciBPQXV0 aCB3aXRoIGNvbmZpZGVudGlhbCBVQS4gSSBjYW4gZWFzaWx5IHRoaW5rIG9mIGEgT0F1dGggdXNl IGNhc2UgZm9yIFB1YmxpYyBVc2VyIEFnZW50LCBidXQgb25seSBoYXZlIGEgdmFndWUgaWRlYSB3 aGF0IE9BdXRoIHdpdGggQ29uZmlkZW50aWFsIFVBIHdvdWxkIGJlLg0KDQpUaGUgZXhhbXBsZSBJ IGNhbiB0aGluayBvZiwgd291bGQgYmUgc29tZSBzb3J0IG9mIGhvdCBkZXNrIGFwcGxpY2F0aW9u LCB3aGVyZSB1c2VyIGFsbG93cyBhIExvY2FsIFBCWCB0byByZWdpc3RlciB3aXRoIFVzZXIgSG9t ZSBQQlggdG8gYWNjZXB0IGNhbGxzIG9uIGJlaGFsZiBvZiB1c2VyIGluIGEgcmVtb3RlIGxvY2F0 aW9uLiBJbiB0aGlzIGNhc2UsIExvY2FsIFBCWCBhbmQgVXNlciBIb21lIFBCWCB3aWxsIGJlIGZl ZGVyYXRlZCBzeXN0ZW1zIHdoaWNoIHdpbGwgdXNlIGEgc2luZ2xlIFRMUyBjb25uZWN0aW9uIGZv ciBtdWx0aXBsZSBjYWxscyBvciBlbmQgdXNlciBkZXZpY2VzLi4gTG9jYWwgUEJYIGFuZCBVc2Vy IEhvbWUgUEJYIHdpbGwgaGF2ZSBhIHRydXN0IHJlbGF0aW9uc2hpcCwgcG9zc2libHkgd2l0aCBt dXR1YWwgVExTIGNlcnRpZmljYXRlIGF1dGhlbnRpY2F0aW9ucy4gQSBjb21wYW55IHdpZGUgZGly ZWN0b3J5IHNlcnZlciB3aWxsIGJlIHVzZWQgdG8gc3RvcmUgYWN0dWFsIHVzZXIgY3JlZGVudGlh bHMgYW5kIHdpbGwgYmUgdXNlZCB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIgYW5kIGdlbmVyYXRl IHRoZSB0b2tlbi4NCg0KQmVzdCBSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lw Y29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFp bGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== --_000_ED23A59908C64359B2CA4DF287E29608ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8EC4138DF9627A498E0AC741EC3F8A92@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5N YXliZSB3ZSB3YW50IHRvIHBvaW50IG91dCB0aGF0IHRva2VuIGV4cGlyYXRpb24gYW5kIHJlZ2lz dHJhdGlvbiBleHBpcmF0aW9uIGFyZSB0d28gc2VwYXJhdGUgdGhpbmdzLCBidXQgSSBkb27igJl0 IHRoaW5rIHRoZXkgc2hvdWxkIGJlIGNvdXBsZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c2lwY29y ZSAmbHQ7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUmlmYWF0IFNo ZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PldlZG5lc2RheSwgMTAgSnVseSAyMDE5IGF0IDE1LjE5PGJyPg0KPGI+VG86IDwvYj5PbGxlIEpv aGFuc3NvbiAmbHQ7b2VqQGVkdmluYS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtzaXBj b3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OywgUm9tYW4gU2hwb3Vu dCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2lw Y29yZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnotMDIu dHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIFVBIGlzIGV4cGVjdGVkIHRvIG9idGFpbiBhIHZhbGlkIGFjY2Vz cyB0b2tlbiB0byBnZXQgc2VydmljZSwgYW5kIHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0aGF0IHRv IHJlZnJlc2ggaXRzIHJlZ2lzdHJhdGlvbiB3aGVuIHRoZSByZWdpc3RyYXRpb24gZXhwaXJlcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHRo aXMgY291cGxpbmcgb2YgZXhwaXJ5IHRpbWVzIG5lZWRlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg SnVsIDEwLCAyMDE5IGF0IDc6NTYgQU0gT2xsZSBFLiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1h aWx0bzpvZWpAZWR2aW5hLm5ldCI+b2VqQGVkdmluYS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDEwIEp1bCAyMDE5LCBhdCAxMzo1MCwgUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJt YWlsdG86cmlmYWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaGVuIHRoZSBVQSBhdXRoZW50aWNhdGVzIHRvIHRoZSBBUywgaXQgb2J0 YWlucyBhIG51bWJlciBvZiB0b2tlbnM6IGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiwg YW5kIGRlcGVuZHMgb24gdGhlIEFTLCBtYXliZSBJRCB0b2tlbi4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIHRoZSBVQXMgcmVzcG9uc2liaWxpdHkg dG8gdXNlIHRoZSByZWZyZXNoIHRva2VuIHRvIG9idGFpbiBhIG5ldyBhY2Nlc3MgdG9rZW4gYmVm b3JlIHRoZSBleHBpcnkgb2YgdGhlIGV4aXN0aW5nIGFjY2VzcyB0b2tlbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFic29sdXRlbHkgLSBteSB0aG91Z2h0IHdhcyB3aGF0IHRoZSBzZXJ2ZXIgaXMgc3Vw cG9zZWQgdG8gZG8uIFJlYWRpbmcgdGhlIFNUVU4vT2F1dGggZG9jcywgSSBzZWUgYSByZXF1aXJl bWVudCBmb3IgZXhwaXJ5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5iZWluZyBsZXNzIHRoYW4gdG9rZW4gdmFsaWRpdHkgdGltZS4gSW4gU0lQIFJF R0lTVEVSL1NVQlNDUklCRSB0ZXJtcywgdGhlIGV4cGlyeSB0aW1lIGluIFNJUCBzaG91bGQgYmUg bGVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dGhhbiB0aGUgdGltZSB0aGUgdG9rZW4gaXMgdmFsaWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0lmIHRoZSB0b2tlbiBleHBpcmVz LCB0aGUgc2VydmVyIG5lZWRzIHRvIHJlYXV0aCBvciBkZW55IHNlcnZpY2VzLiBJdCBpcyBpbXBv cnRhbnQgdGhhdCBubyBzZXJ2aWNlcyBhcmUgZGVsaXZlcmVkIHRvIGFuIGV4cGlyZWQgYXV0aGVu dGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi9PPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVsIDEw LCAyMDE5IGF0IDI6NDQgQU0gT2xsZSBFLiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpv ZWpAZWR2aW5hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPm9lakBlZHZpbmEubmV0PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAxMCBKdWwgMjAxOSwgYXQgMDI6NTMsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhy ZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVy aXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1bCA5LCAyMDE5IGF0IDg6 MzAgUE0gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlmYWF0LmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQgY2xlYXJs eSBhbGxvd3MgdGhlIHVzZSBvZiBhY2Nlc3MgdG9rZW4gdG8gYXV0aGVudGljYXRlIG5vbi1SRUdJ U1RFUiByZXF1ZXN0cyB3aGVuIGNoYWxsZW5nZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNhbWUg cmVhbG0uDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hl dGhlciB0aGF0IGlzIG5lZWRlZCBvciBub3QgaXMgYSBkaWZmZXJlbnQgZGlzY3Vzc2lvbi48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Bc3N1bWluZyB0aGUgVUEgd2FzIGFibGUgdG8gYXV0aGVudGljYXRlIHRoZSB1c2VyIGFu ZCBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLCB0aGVuIGVzdGFibGlzaCBhbiBhdXRoZW50aWNhdGVk IFRMUyBjaGFubmVsIHdpdGggdGhlIHNlcnZlciwgYW5kIHJlZ2lzdGVyIHRoZSB1c2VyOyBpcyB0 aGVyZSBhIG5lZWQgZm9yIGZ1cnRoZXIgY2hhbGxlbmdlcyBmcm9tIHNlcnZlcj88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gdGhlIHRva2VuIGV4cGlyZXMs IHlvdSBjZXJ0YWlubHkgbmVlZCBhIG5ldyB0b2tlbiBmcm9tIHRoZSB1c2VyLiBXaXRoIFNJUCBP dXRib3VuZCwgd2XigJlyZSBtb3JlIGNvbm5lY3Rpb24gb3JpZW50ZWQgdGhhbiBiZWZvcmUsIHNv IHdlIHNob3VsZCBwcm9wYWJseSBjb25zaWRlciB3aGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VydmVyIGRvZXMgd2l0aCB0aGUgY29u bmVjdGlvbiB3aGVuIGEgdG9rZW4gZXhwaXJlcyAoaWYgaXTigJlzIG5vdCBhbHJlYWR5IGluIHRo ZSBkcmFmdCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4vTzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UeXBpY2FsbHksIGZvciBTSVAsIHVzZXIg YXV0aGVudGljYXRpb24gaXMgbm90IHRpZWQgdG8gdGhlIFRMUyBjb25uZWN0aW9uLiBPbmUgb2Yg dGhlIHJlYXNvbnMgZm9yIHRoaXMgaXMgdGhhdCBtdWx0aXBsZSB1c2VycyBjYW4gdXNlIHRoZSBz YW1lIFRMUyBjb25uZWN0aW9uIGluIGZlZGVyYXRlZCBzeXN0ZW1zLi4gVGhpcyBpcyBlc3BlY2lh bGx5IHRydWUgZm9yIENvbmZpZGVudGlhbCBVQSwgd2hpY2ggaGF2ZQ0KIHRydXN0IHJlbGF0aW9u c2hpcCB3aXRoIGEgcHJveHkgYW5kIGNhbiBtYWludGFpbiBhIHNlY3VyZSBjb25uZWN0aW9uIHRv IHRoZSByZWdpc3RyYXIvcHJveHkgb24gYmVoYWxmIG9mIG11bHRpcGxlIGNsaWVudHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uY2UgYWdh aW4sIGl0IHdvdWxkIGJlIG11Y2ggZWFzaWVyIHRvIGRpc2N1c3MgaWYgeW91IGNhbiBwcm92aWRl IGEgdXNlIHNwZWNpZmljIGNhc2UgZm9yIE9BdXRoIHdpdGggY29uZmlkZW50aWFsIFVBLiBJIGNh biBlYXNpbHkgdGhpbmsgb2YgYSBPQXV0aCB1c2UgY2FzZSBmb3IgUHVibGljIFVzZXIgQWdlbnQs IGJ1dCBvbmx5IGhhdmUgYSB2YWd1ZSBpZGVhIHdoYXQgT0F1dGggd2l0aCBDb25maWRlbnRpYWwN CiBVQSB3b3VsZCBiZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGV4YW1wbGUgSSBjYW4gdGhpbmsgb2YsIHdvdWxkIGJlIHNv bWUgc29ydCBvZiBob3QgZGVzayBhcHBsaWNhdGlvbiwgd2hlcmUgdXNlciBhbGxvd3MgYSZuYnNw O0xvY2FsIFBCWCB0byByZWdpc3RlciB3aXRoIFVzZXIgSG9tZSBQQlggdG8gYWNjZXB0IGNhbGxz IG9uIGJlaGFsZiBvZiB1c2VyIGluIGEgcmVtb3RlIGxvY2F0aW9uLiBJbiB0aGlzIGNhc2UsIExv Y2FsIFBCWCBhbmQgVXNlciBIb21lIFBCWCB3aWxsDQogYmUgZmVkZXJhdGVkIHN5c3RlbXMgd2hp Y2ggd2lsbCB1c2UgYSBzaW5nbGUgVExTIGNvbm5lY3Rpb24gZm9yIG11bHRpcGxlIGNhbGxzIG9y IGVuZCB1c2VyIGRldmljZXMuLiBMb2NhbCBQQlggYW5kIFVzZXIgSG9tZSBQQlggd2lsbCBoYXZl IGEgdHJ1c3QgcmVsYXRpb25zaGlwLCBwb3NzaWJseSB3aXRoIG11dHVhbCBUTFMgY2VydGlmaWNh dGUgYXV0aGVudGljYXRpb25zLiBBIGNvbXBhbnkgd2lkZSBkaXJlY3Rvcnkgc2VydmVyIHdpbGwg YmUgdXNlZA0KIHRvIHN0b3JlIGFjdHVhbCB1c2VyIGNyZWRlbnRpYWxzIGFuZCB3aWxsIGJlIHVz ZWQgdG8gYXV0aGVudGljYXRlIHRoZSB1c2VyIGFuZCBnZW5lcmF0ZSB0aGUgdG9rZW4uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgUmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_ED23A59908C64359B2CA4DF287E29608ericssoncom_-- From nobody Wed Jul 10 05:25:05 2019 Return-Path: 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 51C6C1200FB for ; Wed, 10 Jul 2019 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yJMOdqyjWhlb for ; Wed, 10 Jul 2019 05:24:59 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130043.outbound.protection.outlook.com [40.107.13.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935BC120026 for ; Wed, 10 Jul 2019 05:24:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OzoHy6Sz1044Ef9usG3adC80nG77Wp83IWc83ziv4vDLWyf+bY6rH9fFHn61AZCmU3wcsCCU9ijvI0MMgjpxW08+M5VUrk8od9qCM8rPWEMG7VxRXi4AKMm7PA7KqJpVVOrIAG43qM2l152U7cc4pCGx9BhVprsmhx/Br1mv6K0MrxgEpGTW16KdTZcoRdVQpwigw4WK6MchAe5qe9DEeH70Kg/Tw5LXrUB0O0zOtGCB5FH2WaEIyNwkUylkevNA72zHvXPRcGeo1pwVLHuhmjpFcJUceQfe4GTVLgXc4NOcbsy/M8o1o5wVRJXbz8k6tO4rwmta4ZtO2VOGZ60BUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jLpiPtjYkEYLtE74YH1AGsricp3/zvUzIF3oHfyVpA8=; b=icVl2a6u4bkfSpsuO0tmWHWby9I/iM2GXQ7AMal1ifY1X45ghY5ocAVjod13D1FSc74UQNClsiWn2+YEoYlXZIo6XMTeXzN/rrzcmorKcW5jsNFzIhw8zrTwa+UuEiyfQS5x0Oz/aAqyeRB6Qlik9V4vkOZYc4RvnDXRDcA4EqZKKd+MWSS8ImAydHPLTvuJYid8K2oXFHMPFjxxN3zQIME+39/8GuT9Bq7L/avOLdqSldt6GawpIRQm3JpIhpChl4wTR9JS3PW5b559VfBvgmn8YEqf1asS2DGqMNB7j2C9fEe0qQUZSFNHKAp9SQY8KXEt4L1SevFrjLQGEyx9ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jLpiPtjYkEYLtE74YH1AGsricp3/zvUzIF3oHfyVpA8=; b=e4YII9xe6LdHwVWk8naT/5Sf+p71wiuEqyIkv2LZDGPoSGOvv8PLrtrV1BjT+Bqx6dSU43F11W9QWVbtmyPVRLhSUuAN91ilU65kE3opoUM7n6cY7X6XZ4sNdHiaM71aNUUf8piOOmvtVbvEHlyb21XGznFC9eQ9w6L4F7/iPlo= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4220.eurprd07.prod.outlook.com (20.176.166.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 12:24:55 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 12:24:55 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , "Olle E. Johansson" CC: "sipcore@ietf.org" , Roman Shpount Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAAeAYCAAKVAAIAAT0EAgAAC9gCAAAUVgIAAM4IA Date: Wed, 10 Jul 2019 12:24:55 +0000 Message-ID: <74F1125E-88B7-46C0-A4FD-F7E38FDD4FEE@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <9AFBBA7B-8B43-4F4B-A704-FB8FF881FA24@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f12b5da-4c9c-4686-ccfa-08d705319d9e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4220; x-ms-traffictypediagnostic: HE1PR07MB4220: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(396003)(366004)(39860400002)(199004)(189003)(14454004)(76176011)(66446008)(68736007)(4326008)(25786009)(66556008)(66476007)(64756008)(26005)(186003)(6506007)(53546011)(8676002)(102836004)(53936002)(99286004)(606006)(5660300002)(2906002)(86362001)(966005)(66574012)(3846002)(6116002)(6246003)(8936002)(478600001)(71200400001)(6306002)(256004)(54896002)(58126008)(14444005)(236005)(316002)(33656002)(71190400001)(44832011)(110136005)(6486002)(54906003)(486006)(229853002)(81156014)(11346002)(66946007)(446003)(2616005)(476003)(81166006)(76116006)(7736002)(36756003)(6512007)(66066001)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4220; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nyNDA1M6cyxWg9/RaD6++kPTsAXcfiHicTlDgQ9ts+d5IyDePxmR7v85Z8gLdRjrB8Ky9Aea/199UGOrt83NmxtZVi8keXmufOanTTIajUHEltfnGQEd+mX2t+PeVvjQ4W5fUfarIJcglKYlhp42+37aq/gJ6m+UFei/BqsYw733vOCt74k+DWBb/Irt2/Qm2s32nwcUM5bzP7wpqtz4Zvr8KAfyJJF97AfoyJmFapqK9qkDzPXTv31eRB00/hw4QLV7rs2Jp8Q658KInXYTusai+tnw6d+ywi61omAVA0ZYjDyH3eGpQyDrVqHhHqBAT2ctlNl2tSufTXFyBkBqnzIXoJ0NgbL4ToRa6IryXb8xj72QyScAZzizdm1wsnxDcMHlQ/jp+AX+8yMalPCe9eGL/BBYWMMEZlutkGQKcTI= Content-Type: multipart/alternative; boundary="_000_74F1125E88B746C0A4FDF7E38FDD4FEEericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f12b5da-4c9c-4686-ccfa-08d705319d9e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 12:24:55.0891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4220 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:25:04 -0000 --_000_74F1125E88B746C0A4FDF7E38FDD4FEEericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIGFtIGZpbmUgd2l0aCByZWZlcnJpbmcgdG8gdGhlIE9BdXRoIGRlZmluaXRpb24u DQo+QW55Ym9keSBoYXMgYW4gaXNzdWUgd2l0aCB0aGlzPw0KDQpJIHN1cHBvcnQgeW91ciBzdWdn ZXN0aW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KT24gV2VkLCBKdWwgMTAsIDIw MTkgYXQgODowMiBBTSBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ8bWFpbHRvOm9l akBlZHZpbmEubmV0Pj4gd3JvdGU6DQoNCg0KDQpPbiAxMCBKdWwgMjAxOSwgYXQgMTM6NTEsIFJp ZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0 ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoNCk9uIFdlZCwgSnVsIDEwLCAyMDE5IGF0IDM6MDgg QU0gT2xsZSBFLiBKb2hhbnNzb24gPG9lakBlZHZpbmEubmV0PG1haWx0bzpvZWpAZWR2aW5hLm5l dD4+IHdyb3RlOg0KDQoNCg0KT24gOSBKdWwgMjAxOSwgYXQgMjM6MTYsIFJpZmFhdCBTaGVraC1Z dXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNCg0KVGhpcyBkb2N1bWVudCBpcyBzcGVjaWZpY2FsbHkgZm9jdXNlZCBvbiBjb25m aWRlbnRpYWwgVUFzLg0KVUFzIHJ1bm5pbmcgaW4gdGhlIGJyb3dzZXIsIHB1YmxpYyBVQXMsIHdp bGwgYmUgYWRkcmVzc2VkIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQpNYXliZSB5b3Ugc2hvdWxk IG1ha2UgdGhhdCBtb3JlIGNsZWFyLCBhcyBpdCBpcyB2ZXJ5IGNvbmZ1c2luZyB0ZXJtaW5vbG9n eeKApiBJIHNlZSB0aGF0IHNlY3Rpb24gMS4uMiBpbiB5b3VyIGRyYWZ0IGRlZmluZXMgdGhlc2Vz DQp0eXBlcywgYmFzZWQgb24gUkZDIDY3NDkuIFlvdSBhcHBseSBpdCB0byB0aGUgdGVybSDigJxV QeKAnSB3aGljaCBJIHRoaW5rIGNvbmZ1c2VzIHRoaW5ncy4gQSDigJxwdWJsaWMgVUHigJ0gbWF5 IGhhdmUgc3VwcG9ydA0KZm9yIGNvbmZpZGVudGlhbGl0eSwgYnV0IG5vdCBmcm9tIGFuIE9hdXRo IHBvaW50IG9mIHZpZXcuIEkgdGhpbmsgd2Ugc2hvdWxkIGxvb2sgZm9yIG90aGVyIHRlcm1zIGZv ciB0aGlzLg0KDQoNCkFueSBzdWdnZXN0ZWQgdGV4dD8NCkkgY2FyZWZ1bGx5IGF2b2lkZWQgYW55 IHN1Z2dlc3Rpb25z4oCmIFdhcyBob3Bpbmcgc29tZW9uZSBvbiB0aGUgbWFpbGxpbmcgbGlzdCB3 b3VsZCBzdGVwIGZvcndhcmQgd2l0aA0Kc29tZSBicmlsbGlhbnQgbmV3IHRlcm1pbm9sb2d5LiA6 LSkNCg0KTWF5YmUganVzdCByZXZlcnRpbmcgdG8gT0F1dGggdGVybWlub2xvZ3kgd2l0aCDigJxw dWJsaWMgY2xpZW50cyBhbmQgY29uZmlkZW50aWFsIGNsaWVudHPigJ0gdG8gYXZvaWQgc2V0dGlu ZyBvdXIgb3duIHRlcm1zDQphbmQgZGlyZWN0bHkgcmVmZXIgdGVybWlub2xvZ3kgdG8gT2F1dGgg c3BlY3MuIEkgc3RpbGwgZG9u4oCZdCBsaWtlIOKAnGNvbmZpZGVudGlhbCBjbGllbnTigJ0gd2hl biB0aGV5IHJlYWxseSBtZWFuIOKAnHNvbWV0aGluZw0KdGhhdCBhdCBsZWFzdCBkb2VzbuKAmXQg c2hvdyB3aGF0IHRoZXkgZG8gaW4gc291cmNlIGNvZGUgYnV0IG1heSBzdGlsbCBiZSB0b3RhbGx5 IGluc2VjdXJl4oCdLi4uDQoNClllYWgsIEkga25vdyB0aGF04oCZcyBhIGJvcmluZyBzdWdnZXN0 aW9uLg0KDQovTyA6LSkNCg0KDQoNCkluIGFkZGl0aW9uLCBJIGRvbuKAmXQgZmluZCBhbnkgdGV4 dCBpbiB5b3VyIGRyYWZ0IGluZGljYXRpbmcgdGhhdCDigJxQdWJsaWMgVUFz4oCdIGlzIG91dCBv ZiBzY29wZS4NCg0KDQpJIHdpbGwgZml4IHRoYXQuLg0KDQpUaGFua3MsDQogUmlmYWF0DQoNCg0K L08NCg0KDQpSZWdhcmRzLA0KIFJpZmFhdA0KDQoNCk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgMzoy OSBQTSBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJp eC5jb20+PiB3cm90ZToNCk9uIFR1ZSwgSnVsIDksIDIwMTkgYXQgMzoxMSBQTSBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+IEFzIGZhciBhcyBJIGtub3csIE9BdXRo IGZvciBTSVAgaGFzIG9ubHkgYmVlbiB1c2VkIGZvciBSRUdJU1RFUiByZXF1ZXN0cywgYmV0d2Vl biB0aGUgVUEgYW5kIHRoZSByZWdpc3RyYXIuDQo+PiBJIGhhdmUgbmV2ZXIgaGVhcmQgYWJvdXQg YW55b25lIHVzaW5nIGl0IGZvciBub24tUkVHSVNURVIgYXV0aGVudGljYXRpb24sIGFuZCBJIHdv bmRlciB3aGV0aGVyIHdlIGV2ZW4gbmVlZA0KPj4gdG8gY292ZXIgaXQgaW4gdGhlIGRyYWZ0LiBX ZSBjb3VsZCBsaW1pdCB0aGUgc2NvcGUgdGhlIFJFR0lTVEVSIHJlcXVlc3RzLiBUaGVuLCBpZiBh bnlvbmUgZXZlciBuZWVkcyBPQXV0aCBmb3Igbm9uLVJFR0lTVEVSIHJlcXVlc3RzLCBhIHNlcGFy YXRlIGRyYWZ0IGNhbiBiZSB3cml0dGVuLg0KPg0KPiBSZWFsbHk/IE5vcm1hbGx5LCBmb3IgYSBz ZWN1cmUgc29sdXRpb24sIGV2ZXJ5IFNJUCByZXF1ZXN0LCBpbmNsdWRpbmcgcmVxdWVzdHMgc2Vu dCBieSBVQSBpbiBkaWFsb2cgZXN0YWJsaXNoZWQgZnJvbSB0aGUNCj4gc2VydmVyIHRvIHRoZSBy ZWdpc3RlcmVkIGVuZCBwb2ludCBtdXN0IGJlIGF1dGhlbnRpY2F0ZWQuIE9BdXRoIGZvciBSRUdJ U1RSRVIgcmVxdWVzdHMgb25seSBpcyBraW5kIG9mIHVzZWxlc3Mgc2luY2UgaXQNCj4gZG9lcyBu b3QgYWxsb3cgVUEgdG8gc2VuZCBhbnkgbWVzc2FnZXMgdG8gdGhlIHNlcnZlciB3aXRob3V0IHNv bWUgYWRkaXRpb25hbCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20uDQoNCk5vdCBzdXJlIHdoYXQg eW91IG1lYW4gYnkgInNlY3VyZSBzb2x1dGlvbiIsIGJ1dCBVQXMgY2FuIHN0aWxsIHVzZSBTSVAg RGlnZXN0IGF1dGhlbnRpY2F0aW9uLg0KDQpXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQgb25seSB1 c2UtY2FzZSBmb3IgU0lQIE9BdXRoIEkgYW0gYXdhcmUgb2YgaXMgZm9yIFJFR0lTVEVSLg0KSG93 IGRvIHRoZXkgZ2V0IHRoZXNlIFNJUCBEaWdlc3QgY3JlZGVudGlhbHM/DQoNCkkgYW0gbG9va2lu ZyBhdCBhIHZlcnkgc2ltcGxlIFNJUC1PdmVyLVdlYnNvY2tldHMgY2xpZW50IHNjZW5hcmlvOg0K DQpVc2VyIGxvZ3MgaW50byB0aGUgd2ViIHNpdGUgd2hpY2ggdXNlcyBPQXV0aC4gVUEsIHJ1bm5p bmcgaW4gdGhlIGJyb3dzZXIgZ2V0cyBhIHRva2VuIHdoaWNoIGlzIHVzZWQgdG8gUmVnaXN0ZXIg VUEgd2l0aCBhIFNJUCBwcm94eS4NCg0KV2hhdCBjcmVkZW50aWFscyBpcyBVQSB1c2luZyB0byBw bGFjZSBhIGNhbGwgKHNlbmQgSU5WSVRFIHRvIHRoZSBwcm94eSk/DQpJZiBhIGNhbGwgY29tZXMg aW4gZnJvbSB0aGUgcHJveHkgdG8gVUEsIHdoYXQgY3JlZGVudGlhbHMgaXMgVUEgdXNpbmcgdG8g aGFuZyB1cCB0aGUgY2FsbCAoc2VuZCBCWUUgbWVzc2FnZSk/DQoNCkJlc3QgUmVnYXJkcywNCl9f X19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYu b3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXBjb3JlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRv OnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcGNvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3Jl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQoNCg== --_000_74F1125E88B746C0A4FDF7E38FDD4FEEericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <56D48CC6B350B64ABE47E35C4A9BA360@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7SSBhbSBmaW5lIHdpdGggcmVmZXJyaW5nIHRv IHRoZSBPQXV0aCBkZWZpbml0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7QW55Ym9keSBoYXMgYW4g aXNzdWUgd2l0aCB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBzdXBw b3J0IHlvdXIgc3VnZ2VzdGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVsIDEwLCAy MDE5IGF0IDg6MDIgQU0gT2xsZSBFLiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpvZWpA ZWR2aW5hLm5ldCI+b2VqQGVkdmluYS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEwIEp1bCAy MDE5LCBhdCAxMzo1MSwgUmlmYWF0IFNoZWtoLVl1c2VmICZsdDs8YSBocmVmPSJtYWlsdG86cmlm YWF0LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmlmYWF0LmlldGZAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBXZWQsIEp1bCAxMCwgMjAxOSBhdCAzOjA4IEFNIE9sbGUgRS4gSm9oYW5zc29u ICZsdDs8YSBocmVmPSJtYWlsdG86b2VqQGVkdmluYS5uZXQiIHRhcmdldD0iX2JsYW5rIj5vZWpA ZWR2aW5hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOSBKdWwgMjAxOSwgYXQgMjM6MTYsIFJp ZmFhdCBTaGVraC1ZdXNlZiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJpZmFhdC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVu dCBpcyBzcGVjaWZpY2FsbHkgZm9jdXNlZCBvbiA8Yj5jb25maWRlbnRpYWwgPC9iPg0KVUFzLiA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VQXMgcnVubmluZyBp biB0aGUgYnJvd3NlciwgcHVibGljIFVBcywgd2lsbCBiZSBhZGRyZXNzZWQgaW4gYSBzZXBhcmF0 ZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIHlvdSBzaG91bGQgbWFrZSB0aGF0 IG1vcmUgY2xlYXIsIGFzIGl0IGlzIHZlcnkgY29uZnVzaW5nIHRlcm1pbm9sb2d54oCmIEkgc2Vl IHRoYXQgc2VjdGlvbiAxLi4yIGluIHlvdXIgZHJhZnQgZGVmaW5lcyB0aGVzZXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnR5cGVzLCBiYXNlZCBv biBSRkMgNjc0OS4gWW91IGFwcGx5IGl0IHRvIHRoZSB0ZXJtIOKAnFVB4oCdIHdoaWNoIEkgdGhp bmsgY29uZnVzZXMgdGhpbmdzLiBBIOKAnHB1YmxpYyBVQeKAnSBtYXkgaGF2ZSBzdXBwb3J0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgY29u ZmlkZW50aWFsaXR5LCBidXQgbm90IGZyb20gYW4gT2F1dGggcG9pbnQgb2Ygdmlldy4gSSB0aGlu ayB3ZSBzaG91bGQgbG9vayBmb3Igb3RoZXIgdGVybXMgZm9yIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Bbnkgc3VnZ2VzdGVkIHRleHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg Y2FyZWZ1bGx5IGF2b2lkZWQgYW55IHN1Z2dlc3Rpb25z4oCmIFdhcyBob3Bpbmcgc29tZW9uZSBv biB0aGUgbWFpbGxpbmcgbGlzdCB3b3VsZCBzdGVwIGZvcndhcmQgd2l0aDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c29tZSBicmlsbGlhbnQgbmV3 IHRlcm1pbm9sb2d5LiA6LSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TWF5YmUganVzdCByZXZlcnRpbmcgdG8gT0F1dGggdGVybWlub2xvZ3kg d2l0aCDigJxwdWJsaWMgY2xpZW50cyBhbmQgY29uZmlkZW50aWFsIGNsaWVudHPigJ0gdG8gYXZv aWQgc2V0dGluZyBvdXIgb3duIHRlcm1zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgZGlyZWN0bHkgcmVmZXIgdGVybWlub2xvZ3kgdG8gT2F1 dGggc3BlY3MuIEkgc3RpbGwgZG9u4oCZdCBsaWtlIOKAnGNvbmZpZGVudGlhbCBjbGllbnTigJ0g d2hlbiB0aGV5IHJlYWxseSBtZWFuIOKAnHNvbWV0aGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCBhdCBsZWFzdCBkb2VzbuKAmXQgc2hv dyB3aGF0IHRoZXkgZG8gaW4gc291cmNlIGNvZGUgYnV0IG1heSBzdGlsbCBiZSB0b3RhbGx5IGlu c2VjdXJl4oCdLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlllYWgsIEkga25vdyB0aGF04oCZcyBhIGJvcmluZyBzdWdnZXN0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vTyA6LSk8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGFkZGl0aW9u LCBJIGRvbuKAmXQgZmluZCBhbnkgdGV4dCBpbiB5b3VyIGRyYWZ0IGluZGljYXRpbmcgdGhhdCDi gJxQdWJsaWMgVUFz4oCdIGlzIG91dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg d2lsbCBmaXggdGhhdC4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L088YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgOSwgMjAxOSBhdCAzOjI5IFBN IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgOSwgMjAxOSBhdCAzOjExIFBNIENocmlzdGVy IEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+Jmd0OyZndDsgQXMgZmFyIGFzIEkga25vdywgT0F1dGggZm9yIFNJUCBoYXMgb25seSBi ZWVuIHVzZWQgZm9yIFJFR0lTVEVSIHJlcXVlc3RzLCBiZXR3ZWVuIHRoZSBVQSBhbmQgdGhlIHJl Z2lzdHJhci4NCjxicj4NCiZndDsmZ3Q7IEkgaGF2ZSBuZXZlciBoZWFyZCBhYm91dCBhbnlvbmUg dXNpbmcgaXQgZm9yIG5vbi1SRUdJU1RFUiBhdXRoZW50aWNhdGlvbiwgYW5kIEkgd29uZGVyIHdo ZXRoZXIgd2UgZXZlbiBuZWVkDQo8YnI+DQomZ3Q7Jmd0OyB0byBjb3ZlciBpdCBpbiB0aGUgZHJh ZnQuIFdlIGNvdWxkIGxpbWl0IHRoZSBzY29wZSB0aGUgUkVHSVNURVIgcmVxdWVzdHMuIFRoZW4s IGlmIGFueW9uZSBldmVyIG5lZWRzIE9BdXRoIGZvciBub24tUkVHSVNURVIgcmVxdWVzdHMsIGEg c2VwYXJhdGUgZHJhZnQgY2FuIGJlIHdyaXR0ZW4uPGJyPg0KJmd0OyZuYnNwOzxicj4NCiZndDsg UmVhbGx5PyBOb3JtYWxseSwgZm9yIGEgc2VjdXJlIHNvbHV0aW9uLCBldmVyeSBTSVAgcmVxdWVz dCwgaW5jbHVkaW5nIHJlcXVlc3RzIHNlbnQgYnkgVUEgaW4gZGlhbG9nIGVzdGFibGlzaGVkIGZy b20gdGhlDQo8YnI+DQomZ3Q7IHNlcnZlciB0byB0aGUgcmVnaXN0ZXJlZCBlbmQgcG9pbnQgbXVz dCBiZSBhdXRoZW50aWNhdGVkLiBPQXV0aCBmb3IgUkVHSVNUUkVSIHJlcXVlc3RzIG9ubHkgaXMg a2luZCBvZiB1c2VsZXNzIHNpbmNlIGl0DQo8YnI+DQomZ3Q7IGRvZXMgbm90IGFsbG93IFVBIHRv IHNlbmQgYW55IG1lc3NhZ2VzIHRvIHRoZSBzZXJ2ZXIgd2l0aG91dCBzb21lIGFkZGl0aW9uYWwg YXV0aGVudGljYXRpb24gbWVjaGFuaXNtLjxicj4NCjxicj4NCk5vdCBzdXJlIHdoYXQgeW91IG1l YW4gYnkgJnF1b3Q7c2VjdXJlIHNvbHV0aW9uJnF1b3Q7LCBidXQgVUFzIGNhbiBzdGlsbCB1c2Ug U0lQIERpZ2VzdCBhdXRoZW50aWNhdGlvbi48YnI+DQo8YnI+DQpXaGF0IEkgYW0gc2F5aW5nIGlz IHRoYXQgb25seSB1c2UtY2FzZSBmb3IgU0lQIE9BdXRoIEkgYW0gYXdhcmUgb2YgaXMgZm9yIFJF R0lTVEVSLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhvdyBkbyB0aGV5IGdldCB0aGVzZSBTSVAgRGlnZXN0IGNyZWRlbnRpYWxzPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFt IGxvb2tpbmcgYXQgYSB2ZXJ5IHNpbXBsZSBTSVAtT3Zlci1XZWJzb2NrZXRzIGNsaWVudCBzY2Vu YXJpbzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VXNlciBsb2dzIGludG8gdGhlIHdlYiBzaXRlIHdoaWNoIHVzZXMgT0F1dGguIFVBLCBydW5u aW5nIGluIHRoZSBicm93c2VyIGdldHMgYSB0b2tlbiB3aGljaCBpcyB1c2VkIHRvIFJlZ2lzdGVy IFVBIHdpdGggYSBTSVAgcHJveHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgY3JlZGVudGlhbHMgaXMgVUEgdXNpbmcgdG8gcGxhY2Ug YSBjYWxsIChzZW5kIElOVklURSB0byB0aGUgcHJveHkpPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYSBjYWxsIGNvbWVzIGluIGZy b20gdGhlIHByb3h5IHRvIFVBLCB3aGF0IGNyZWRlbnRpYWxzIGlzIFVBIHVzaW5nIHRvIGhhbmcg dXAgdGhlIGNhbGwgKHNlbmQgQllFIG1lc3NhZ2UpPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBT aHBvdW50PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBj b3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_74F1125E88B746C0A4FDF7E38FDD4FEEericssoncom_-- From nobody Wed Jul 10 05:25:31 2019 Return-Path: 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 02EA2120026 for ; Wed, 10 Jul 2019 05:25:30 -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 6EX__JBilg2n for ; Wed, 10 Jul 2019 05:25:26 -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 D9FFA120088 for ; Wed, 10 Jul 2019 05:25:25 -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 61693A40; Wed, 10 Jul 2019 14:25:22 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_60EA644A-BECF-433D-8FC2-21EED8033493" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 14:25:21 +0200 In-Reply-To: Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:25:30 -0000 --Apple-Mail=_60EA644A-BECF-433D-8FC2-21EED8033493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef = wrote: >=20 > The UA is expected to obtain a valid access token to get service, and = should be able to use that to refresh its registration when the = registration expires. > Is this coupling of expiry times needed? Absolutely. If we grant a REGISTER expiry time that is much longer than = the expiry of the token, we=E2=80=99re in deep waters. Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot = from: =E2=80=9C o The lifetime provided by the TURN server in the Allocate and Refresh responses MUST be less than or equal to the lifetime of the token. It is RECOMMENDED that the TURN server calculate the maximum allowed lifetime value using the formula: lifetime + Delta - abs(RDnew - TS) The RECOMMENDED value for the allowed Delta is 5 seconds. =E2=80=9C Note that they have a =E2=80=9CMUST=E2=80=9D on this. I think we MUST do = the same :-) /O >=20 > Regards, > Rifaat >=20 >=20 > On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson > wrote: >=20 >=20 >> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef > wrote: >>=20 >> When the UA authenticates to the AS, it obtains a number of tokens: = access token and refresh token, and depends on the AS, maybe ID token. >> It is the UAs responsibility to use the refresh token to obtain a new = access token before the expiry of the existing access token. > Absolutely - my thought was what the server is supposed to do. Reading = the STUN/Oauth docs, I see a requirement for expiry > being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, = the expiry time in SIP should be less > than the time the token is valid. >=20 > If the token expires, the server needs to reauth or deny services. It = is important that no services are delivered to an expired = authentication. >=20 > /O >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >>=20 >>=20 >>> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>>=20 >>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >>> The document clearly allows the use of access token to authenticate = non-REGISTER requests when challenged in the context of the same realm. >>>=20 >>> 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? >>>=20 >> When the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the >> server does with the connection when a token expires (if it=E2=80=99s = not already in the draft). >> /O >>>=20 >>> 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. >>>=20 >>> 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.=20 >>>=20 >>> 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. >>>=20 >>> Best Regards, >>> _____________ >>> Roman Shpount >>> =20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore = >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore = >=20 --Apple-Mail=_60EA644A-BECF-433D-8FC2-21EED8033493 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

The UA is expected to obtain a valid access = token to get service, and should be able to use that to refresh its = registration when the registration expires.
Is this = coupling of expiry times = needed?
Absolutely. If we grant a REGISTER = expiry time that is much longer than the expiry of the token, we=E2=80=99r= e in deep waters.

Example from RFC = 7635 Stun/Oauth - which I think we can borrow a lot from:

=E2=80=9C o The lifetime provided by the TURN = server in the Allocate and
      Refresh responses MUST be =
less than or equal to the lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 =
seconds.
=E2=80=9C

Note that they have a =E2=80=9CMUST=E2=80= =9D on this. I think we MUST do the same :-)
/O


Regards,
 Rifaat


On Wed, Jul 10, 2019 at 7:56 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 = Jul 2019, at 13:50, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

When the UA authenticates to the = AS, it obtains a number of tokens: access token and refresh token, and = depends on the AS, maybe ID token.
It is the UAs = responsibility to use the refresh token to obtain a new access token = before the expiry of the existing access = token.
Absolutely - my thought was what = the server is supposed to do. Reading the STUN/Oauth docs, I see a = requirement for expiry
being less than token = validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP = should be less
than the time the token is = valid.

 If = the token expires, the server needs to reauth or deny services. It is = important that no services are delivered to an expired = authentication.

/O

Regards,
 Rifaat


On Wed, Jul 10, 2019 at 2:44 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.com> wrote:

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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does = with the connection when a token expires (if it=E2=80=99s not already in = the draft).
/O

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
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


= --Apple-Mail=_60EA644A-BECF-433D-8FC2-21EED8033493-- From nobody Wed Jul 10 05:26:47 2019 Return-Path: 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 66CE3120088 for ; Wed, 10 Jul 2019 05:26:45 -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 itaHjGLT0r3D for ; Wed, 10 Jul 2019 05:26:42 -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 7A45E120026 for ; Wed, 10 Jul 2019 05:26:41 -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 1692AA40; Wed, 10 Jul 2019 14:26:38 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4F8F2685-0BC8-46FD-A6A2-3B545E3E90FE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 14:26:36 +0200 In-Reply-To: Cc: Olle E Johansson , Rifaat Shekh-Yusef , "sipcore@ietf.org" , Roman Shpount To: Christer Holmberg References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:26:46 -0000 --Apple-Mail=_4F8F2685-0BC8-46FD-A6A2-3B545E3E90FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 14:22, Christer Holmberg = wrote: >=20 > Hi, > =20 > Maybe we want to point out that token expiration and registration = expiration are two separate things, but I don=E2=80=99t think they = should be coupled. See separate response. I think the need to be coupled.=20 /O > =20 > Regards, > =20 > Christer > =20 > From: sipcore > on behalf of Rifaat Shekh-Yusef = > > Date: Wednesday, 10 July 2019 at 15.19 > To: Olle Johansson > > Cc: "sipcore@ietf.org " >, Roman Shpount > > Subject: Re: [sipcore] I-D Action: = draft-ietf-sipcore-sip-token-authnz-02.txt > =20 > The UA is expected to obtain a valid access token to get service, and = should be able to use that to refresh its registration when the = registration expires. > Is this coupling of expiry times needed? > =20 > Regards, > Rifaat > =20 > =20 > On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson > wrote: >> =20 >>=20 >>=20 >>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef > wrote: >>> =20 >>> When the UA authenticates to the AS, it obtains a number of tokens: = access token and refresh token, and depends on the AS, maybe ID token. >>> It is the UAs responsibility to use the refresh token to obtain a = new access token before the expiry of the existing access token. >> Absolutely - my thought was what the server is supposed to do. = Reading the STUN/Oauth docs, I see a requirement for expiry >> being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, = the expiry time in SIP should be less >> than the time the token is valid. >> =20 >> If the token expires, the server needs to reauth or deny services. = It is important that no services are delivered to an expired = authentication. >> =20 >> /O >>=20 >>> =20 >>> Regards, >>> Rifaat >>> =20 >>> =20 >>> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >>>> =20 >>>>=20 >>>>=20 >>>>> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>>>> =20 >>>>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >>>>>> The document clearly allows the use of access token to = authenticate non-REGISTER requests when challenged in the context of the = same realm. >>>>>> =20 >>>>>> 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? >>>>>> =20 >>>> When the token expires, you certainly need a new token from the = user. With SIP Outbound, we=E2=80=99re more connection oriented than = before, so we should propably consider what the >>>> server does with the connection when a token expires (if it=E2=80=99s= not already in the draft). >>>> /O >>>>=20 >>>>> =20 >>>>> 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. >>>>> =20 >>>>> 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.=20 >>>>> =20 >>>>> 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. >>>>> =20 >>>>> Best Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> =20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore = >>>> =20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_4F8F2685-0BC8-46FD-A6A2-3B545E3E90FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 14:22, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
 
Maybe we want to point out = that token expiration and registration expiration are two separate = things, but I don=E2=80=99t think they should be = coupled.
See separate response. I = think the need to be coupled. 

/O
 
Regards,
 
Christer
 
From: sipcore <sipcore-bounces@ietf.org> = on behalf of Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Wednesday, 10 July 2019 = at 15.19
To: Olle Johansson <oej@edvina.net>
Cc: "sipcore@ietf.org" <sipcore@ietf.org>, Roman = Shpount <roman@telurix.com>
Subject: Re: [sipcore] I-D = Action: draft-ietf-sipcore-sip-token-authnz-02.txt
 
The UA is expected to = obtain a valid access token to get service, and should be able to use = that to refresh its registration when the registration expires.
Is this coupling of expiry times needed?
 
Regards,
 Rifaat
 
 
On Wed, Jul 10, 2019 at = 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:
 


On 10 Jul 2019, at 13:50, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
 
When the UA authenticates to the AS, it = obtains a number of tokens: access token and refresh token, and depends = on the AS, maybe ID token.
It is the UAs responsibility to use the = refresh token to obtain a new access token before the expiry of the = existing access token.
Absolutely - my thought was what the = server is supposed to do. Reading the STUN/Oauth docs, I see a = requirement for expiry
being less than token = validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP = should be less
than the time the token is valid.
 
 If the token expires, the server = needs to reauth or deny services. It is important that no services are = delivered to an expired authentication.
 
/O

 
Regards,
 Rifaat
 
 
On Wed, = Jul 10, 2019 at 2:44 AM Olle E. Johansson <oej@edvina.net> = wrote:
 


On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.com>= wrote:
 
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?
 
When the token = expires, you certainly need a new token from the user. With SIP = Outbound, we=E2=80=99re more connection oriented than before, so we = should propably consider what the
server does with the = connection when a token expires (if it=E2=80=99s not already in the = draft).
/O

 
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
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
<= br class=3D"">= --Apple-Mail=_4F8F2685-0BC8-46FD-A6A2-3B545E3E90FE-- From nobody Wed Jul 10 05:30:23 2019 Return-Path: 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 CB1CD120088 for ; Wed, 10 Jul 2019 05:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 j-LjJ7LZjnk3 for ; Wed, 10 Jul 2019 05:30:17 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 B3C17120077 for ; Wed, 10 Jul 2019 05:30:17 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id k8so4336565iot.1 for ; Wed, 10 Jul 2019 05:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ceoSZNYtOcM7iQtKWJMktY6fCyNpIdELlOGi+MbRbFk=; b=MmLyOpjJsNqrVZCHjq3JT3DPabtQtM8cDtKaprVJkR7HIDV3qnNvLCTxQ7wtnphQ1b r4igS/UfNXmF+uYJVWADtIY6EufLZfFP0QTvgM0Ctjhdp+kaUpZNw6W8SBstmZNKZFK/ 7mPRpasl+RioCt5B7PYidWlqBEO2EUSFKOnDNwPj0hKw78hFMrGoKyp9rH2f3Vf7LLES hY/QXpWK7OJIm6mYJz5TlZnOtpMnbrAUjfv5DIjEhvZ95C/825ZUFjTh56ifJQmiR8b4 tottUo5geJmgXtuOShbNlch3Sz9eu56rQq5p70nj6vxEWdO66dOvHtBmfJb/Uwn0w5nR wH2g== 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=ceoSZNYtOcM7iQtKWJMktY6fCyNpIdELlOGi+MbRbFk=; b=GhqQqP5tD2aQLHNNCdemuo+StKk/241XOfa8r1k6KLdi35IvGgopVw4Y8K0RB7Mu2J xj+vVa13Wx8vfu0r9iMlg1yFs/8lqrCeDdYPc4ke5nOVtWseMLmAnaOlzHLVfZ2Ho9Tw jv96Mn/jq5qQmFUIPQoVFxzZ4DSz2SqG+mwkpACXCbxCf5wpE66S2FGjbxlkeZ5gU1WL LU61qxjG72BVkfDc2JzeYkyRz0Z8niNWwtP6CHGbgC8lwPL5YlHTlbMkXTjVGKV6TGSu vcitPp6+wKMMeTOa8QCd2+6aKhQQ3Y07U4JsCznzRz/lMLovF3WFn27MbYKQbzsuoVUQ XxCQ== X-Gm-Message-State: APjAAAV/nP2rWtZPA+b0tX0R4hoM9hdRG5xfSKdYzu8JGSV8f2UfqwBT Xtj+HearmmzJHJwyBV8oZHMZMIck23hpaRhKySZonsMp X-Google-Smtp-Source: APXvYqzVAAwSimg/jF8eLA9yRQzWjuXdjiKZ2cLj0bs8IHS44nw1K8LbEuNjJNuzbMds2xNiSi+fe/En6EDiLXuO3M0= X-Received: by 2002:a5d:9642:: with SMTP id d2mr13958725ios.278.1562761817021; Wed, 10 Jul 2019 05:30:17 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> In-Reply-To: <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 08:30:05 -0400 Message-ID: To: "Olle E. Johansson" Cc: "sipcore@ietf.org" , Roman Shpount Content-Type: multipart/alternative; boundary="000000000000f8e635058d52d622" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:30:21 -0000 --000000000000f8e635058d52d622 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This does not explain the reason for such a requirement. Why do you think we need to couple these together for SIP? Regards, Rifaat On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson wrote: > > > On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef > wrote: > > The UA is expected to obtain a valid access token to get service, and > should be able to use that to refresh its registration when the > registration expires. > Is this coupling of expiry times needed? > > Absolutely. If we grant a REGISTER expiry time that is much longer than > the expiry of the token, we=E2=80=99re in deep waters. > > Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot from= : > > =E2=80=9C o The lifetime provided by the TURN server in the Allocate and > > Refresh responses MUST be less than or equal to the lifetime of > the token. It is RECOMMENDED that the TURN server calculate the > maximum allowed lifetime value using the formula: > > lifetime + Delta - abs(RDnew - TS) > > The RECOMMENDED value for the allowed Delta is 5 seconds. > > =E2=80=9C > > Note that they have a =E2=80=9CMUST=E2=80=9D on this. I think we MUST do = the same :-) > /O > > > Regards, > Rifaat > > > On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson wrote: > >> >> >> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef >> wrote: >> >> When the UA authenticates to the AS, it obtains a number of tokens: >> access token and refresh token, and depends on the AS, maybe ID token. >> It is the UAs responsibility to use the refresh token to obtain a new >> access token before the expiry of the existing access token. >> >> Absolutely - my thought was what the server is supposed to do. Reading >> the STUN/Oauth docs, I see a requirement for expiry >> being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, th= e >> expiry time in SIP should be less >> than the time the token is valid. >> >> If the token expires, the server needs to reauth or deny services. It i= s >> important that no services are delivered to an expired authentication. >> >> /O >> >> >> Regards, >> Rifaat >> >> >> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson wrote= : >> >>> >>> >>> On 10 Jul 2019, at 02:53, Roman Shpount wrote: >>> >>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef >>> 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, an= d >>>> 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=E2=80=99re more connection oriented than before, = so we should >>> propably consider what the >>> server does with the connection when a token expires (if it=E2=80=99s n= ot >>> already in the draft). >>> /O >>> >>> >>> 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 multip= le >>> 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 O= Auth >>> use case for Public User Agent, but only have a vague idea what OAuth w= ith >>> 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 a= nd >>> 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 H= ome >>> PBX will have a trust relationship, possibly with mutual TLS certificat= e >>> 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 >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> > --000000000000f8e635058d52d622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This does not explain the reason for such a requirement.Why do you think we need to couple these together for SIP?
Regards,
=C2=A0Rifaat



On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at= 14:18, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

The UA is expected to obtain a valid access token to get service, and sho= uld be able to use that to refresh its registration when the registration e= xpires.
Is this coupling of expiry times needed?
Absolutely. If we grant a REGISTER expiry time that is much l= onger than the expiry of the token, we=E2=80=99re in deep waters.

Example from RFC 7635 Stun/Oauth - which I think we can bor= row a lot from:

=E2=80=9C=C2=A0o The lifetime provided by the TURN server in the Allocat= e and
      Refresh responses MUST be less than or equal to the lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 seconds.
= =E2=80=9C

Note that they have a =E2=80=9CMUST=E2= =80=9D on this. I think we MUST do the same :-)
/O

=

<= div>Regards,
=C2=A0Rifaat


On Wed, Jul 10, 201= 9 at 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:


= On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=
When the UA authenticates to the= AS, it obtains a number of tokens: access token and refresh token, and dep= ends on the AS, maybe ID token.
It is the UAs responsibility to use the= refresh token to obtain a new access token before the expiry of the existi= ng access token.
Absolutely - my thought was = what the server is supposed to do. Reading the STUN/Oauth docs, I see a req= uirement for expiry
being less than token validity time. In SIP R= EGISTER/SUBSCRIBE terms, the expiry time in SIP should be less
th= an the time the token is valid.

=C2=A0If the token= expires, the server needs to reauth or deny services. It is important that= no services are delivered to an expired authentication.

/O

Regards,
=C2=A0Rifaat


On Wed, Jul 1= 0, 2019 at 2:44 AM Olle E. Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 02:53, Roman Shpount <roman@telurix.com> wrote:

On Tue, J= ul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=
The document clearly allows the use of acces= s token to authenticate non-REGISTER requests when challenged in the contex= t of the same realm.

Whether that is needed or not is a d= ifferent discussion.
Assuming the UA was able to aut= henticate the user and obtain an access token, then establish an authentica= ted TLS channel with the server, and register the user; is there a need for= further challenges from server?
When the to= ken expires, you certainly need a new token from the user. With SIP Outboun= d, we=E2=80=99re more connection oriented than before, so we should propabl= y consider what the
server does with the connection when a token = expires (if it=E2=80=99s not already in the draft).
/O
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 Conf= idential 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 easi= ly think of a OAuth use case for Public User Agent, but only have a vague i= dea what OAuth with Confidential UA would be.=C2=A0

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

Best Regards,
_____________
Roman Shpount=
=C2=A0
_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore


--000000000000f8e635058d52d622-- From nobody Wed Jul 10 05:35:27 2019 Return-Path: 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 157E9120129 for ; Wed, 10 Jul 2019 05:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 pHQt4c4AcoUo for ; Wed, 10 Jul 2019 05:35:22 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40045.outbound.protection.outlook.com [40.107.4.45]) (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 D6E61120077 for ; Wed, 10 Jul 2019 05:35:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V2bdzP/9+AQs0/kTpvUd10bY7B3d7lXTVW573wcIExOSy09FkGF3jBHUCqu1G2wDl/iPks7v0i4YiGYzqLbsXquJIV74qbe5zEAhrF+ZztEoI5+dWkIQA0vd/Zkst4YmjLquwYXYNAp63cU9d3FSxFv/Y49MjsOmxb+HBniozJ6JwaysHym9O3ZVakrYPljg/Lw4xFN3jIVWuD041M1oX2UxNMYOnnXf2HwOZSrrq+gEHB4BHB1761GnhQGoQHM6sisiAdNfkqj+jf9kLRyoYAZcQ36ERCH6hj7GowhBTmNW/048hPucFDlE7wjz2nx8HKrSuHbRiHVIutsF0CPmwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NaAV3EAXns6wnkAvgSwFuE1Fq9WDKKOv0nBAiNnF1qY=; b=dM9FzKydmvG0DX5WYmr7FFlr986sWl/Ad7/Y6/VTZ1WA1fcm+biHeC0xZuqImpu30ua9T0XYAN0mOHlTGvHAweer22Nei0yHMJPEB8o6RPKyZQTn6Sbloltgsfmt1hT8LcaxSJv1q8kGlaZcV5i76NqjqSpFNn6rMi0l4upWa5BSySEa53rK3F3VZ0Pe5/2fIwwcXSwAFlwaJ63WMB6cc3l/YApveBxyUZh32wF6Lp4KddI7RtWwx1B8xN8K48Azr19e/io391nxcW9JbPE7bFlWaVdKNNS8RgCqBPqPEz6HA806EgPnZPzvx6vOtYbRptEdGL8afwq9TOpali2cLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NaAV3EAXns6wnkAvgSwFuE1Fq9WDKKOv0nBAiNnF1qY=; b=QG3fJDy+G75e+E4oKB2ebYc2zVBRu0ut3dq/SO3d+x4FMz8sp7RRJtaaiBtTlKgJQN5upQ45AA/0ciPnpK6Q0yw6SSvOVBgZuYgf2tLce096tisntATuA4MZZRQ4oy0uoOiDjEo1VGnaldd2oeuRHtetCs1/63qR3XVcvb4Vgfw= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4171.eurprd07.prod.outlook.com (20.176.166.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.7; Wed, 10 Jul 2019 12:35:18 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 12:35:18 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , "Olle E. Johansson" CC: "sipcore@ietf.org" , Roman Shpount Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAAeAYCAABzUAIAABQKAgAACsgCAABGcAIAABn4AgABh5YCAAFWlgIAAAYkAgAAGSICAAAHmgIAAAVOAgAAzvoA= Date: Wed, 10 Jul 2019 12:35:18 +0000 Message-ID: <215B2FEC-9F34-4BA3-96DA-B5CC9DF6590F@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2aee02f6-1881-4a5a-dfb6-08d70533112c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4171; x-ms-traffictypediagnostic: HE1PR07MB4171: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(189003)(199004)(7736002)(11346002)(2616005)(476003)(68736007)(446003)(3846002)(8936002)(186003)(6116002)(44832011)(486006)(8676002)(102836004)(26005)(66066001)(81166006)(305945005)(110136005)(54906003)(316002)(33656002)(53546011)(6506007)(58126008)(99286004)(76176011)(66476007)(478600001)(66556008)(6512007)(6486002)(86362001)(53936002)(6246003)(6436002)(76116006)(229853002)(66946007)(81156014)(5660300002)(2906002)(966005)(36756003)(14444005)(71200400001)(71190400001)(4326008)(256004)(25786009)(64756008)(66446008)(6306002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4171; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HysI9LbYAy5Y12VXEKfy7kDB6BDK2L01C6AMmOMvczgZFqih53kDPhZekinPrgrHdCsjQJT7GQp0fbttlJKFQ7aZ4dn1w47tz+uxepu6KJ4h7Jv4Og4n8QD3ATjJ+oiTneeJdBgI4fKHVkGkWWVRl6VJA+ORRYGuubFXuNpx2vgRcBHng1BAaaMIuJrVeZ9yOsEX2nIFTXc6rIgAvxiM+CHuui6LI7/xeR6mvMy9KnCbfPAsm65xY5i59Q1zEggjtxpkjOt3gs5fizRTgsCodTrzGWaN35ltsiMy/79hw2Y9HXBTf1GtMf1dZWTAnCoqIyWhk0QiT+uXmMcdpgv7qwXD34aZP/dy8v8KI3LzWWdELpgyTlQt2BNrnhdv+3LQ0O960YshQoe2FyDlmdaS5ughPp88hdEhvj0pGAPI9o0= Content-Type: text/plain; charset="utf-8" Content-ID: <70E6496E32BF9A43BCCDB67E6469BFFB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2aee02f6-1881-4a5a-dfb6-08d70533112c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 12:35:18.3620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4171 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 12:35:26 -0000 SGksDQoNCj5UaGlzIGRvZXMgbm90IGV4cGxhaW4gdGhlIHJlYXNvbiBmb3Igc3VjaCBhIHJlcXVp cmVtZW50LiANCj5XaHkgZG8geW91IHRoaW5rIHdlIG5lZWQgdG8gY291cGxlIHRoZXNlIHRvZ2V0 aGVyIGZvciBTSVA/DQoNCkkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIG1hbmRhdGUgdGhlbSB0byBi ZSBjb3VwbGVkLg0KDQpJZiB0aGUgdG9rZW4gZXhwaXJlcyBiZWZvcmUgdGhlIHJlZ2lzdHJhdGlv biwgYW4gVUEgY2FuIHN0aWxsIHNlbmQgYSBSRUdJU1RFUiB3aXRoIHRoZSBuZXcgdG9rZW4gLSBl dmVuIGlmIHRoZSByZWdpc3RyYXRpb24gaXMgbm90IGFib3V0IHRvIGV4cGlyZS4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpPbiBXZWQsIEp1bCAxMCwgMjAxOSBhdCA4OjI1IEFN IE9sbGUgRS4gSm9oYW5zc29uIDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+IHdyb3RlOg0KDQoNCg0K T24gMTAgSnVsIDIwMTksIGF0IDE0OjE4LCBSaWZhYXQgU2hla2gtWXVzZWYgPG1haWx0bzpyaWZh YXQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQpUaGUgVUEgaXMgZXhwZWN0ZWQgdG8gb2J0YWlu IGEgdmFsaWQgYWNjZXNzIHRva2VuIHRvIGdldCBzZXJ2aWNlLCBhbmQgc2hvdWxkIGJlIGFibGUg dG8gdXNlIHRoYXQgdG8gcmVmcmVzaCBpdHMgcmVnaXN0cmF0aW9uIHdoZW4gdGhlIHJlZ2lzdHJh dGlvbiBleHBpcmVzLg0KSXMgdGhpcyBjb3VwbGluZyBvZiBleHBpcnkgdGltZXMgbmVlZGVkPw0K QWJzb2x1dGVseS4gSWYgd2UgZ3JhbnQgYSBSRUdJU1RFUiBleHBpcnkgdGltZSB0aGF0IGlzIG11 Y2ggbG9uZ2VyIHRoYW4gdGhlIGV4cGlyeSBvZiB0aGUgdG9rZW4sIHdl4oCZcmUgaW4gZGVlcCB3 YXRlcnMuDQoNCkV4YW1wbGUgZnJvbSBSRkMgNzYzNSBTdHVuL09hdXRoIC0gd2hpY2ggSSB0aGlu ayB3ZSBjYW4gYm9ycm93IGEgbG90IGZyb206DQoNCuKAnMKgbyBUaGUgbGlmZXRpbWUgcHJvdmlk ZWQgYnkgdGhlIFRVUk4gc2VydmVyIGluIHRoZSBBbGxvY2F0ZSBhbmQNCiAgICAgIFJlZnJlc2gg cmVzcG9uc2VzIE1VU1QgYmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvIHRoZSBsaWZldGltZSBvZg0K ICAgICAgdGhlIHRva2VuLiAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgVFVSTiBzZXJ2ZXIg Y2FsY3VsYXRlIHRoZQ0KICAgICAgbWF4aW11bSBhbGxvd2VkIGxpZmV0aW1lIHZhbHVlIHVzaW5n IHRoZSBmb3JtdWxhOg0KDQogICAgICAgIGxpZmV0aW1lICsgRGVsdGEgLSBhYnMoUkRuZXcgLSBU UykNCg0KICAgICAgVGhlIFJFQ09NTUVOREVEIHZhbHVlIGZvciB0aGUgYWxsb3dlZCBEZWx0YSBp cyA1IHNlY29uZHMuDQrigJwNCg0KTm90ZSB0aGF0IHRoZXkgaGF2ZSBhIOKAnE1VU1TigJ0gb24g dGhpcy4gSSB0aGluayB3ZSBNVVNUIGRvIHRoZSBzYW1lIDotKQ0KL08NCg0KDQpSZWdhcmRzLA0K wqBSaWZhYXQNCg0KDQpPbiBXZWQsIEp1bCAxMCwgMjAxOSBhdCA3OjU2IEFNIE9sbGUgRS4gSm9o YW5zc29uIDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+IHdyb3RlOg0KDQoNCg0KT24gMTAgSnVsIDIw MTksIGF0IDEzOjUwLCBSaWZhYXQgU2hla2gtWXVzZWYgPG1haWx0bzpyaWZhYXQuaWV0ZkBnbWFp bC5jb20+IHdyb3RlOg0KDQpXaGVuIHRoZSBVQSBhdXRoZW50aWNhdGVzIHRvIHRoZSBBUywgaXQg b2J0YWlucyBhIG51bWJlciBvZiB0b2tlbnM6IGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tl biwgYW5kIGRlcGVuZHMgb24gdGhlIEFTLCBtYXliZSBJRCB0b2tlbi4gDQpJdCBpcyB0aGUgVUFz IHJlc3BvbnNpYmlsaXR5IHRvIHVzZSB0aGUgcmVmcmVzaCB0b2tlbiB0byBvYnRhaW4gYSBuZXcg YWNjZXNzIHRva2VuIGJlZm9yZSB0aGUgZXhwaXJ5IG9mIHRoZSBleGlzdGluZyBhY2Nlc3MgdG9r ZW4uDQpBYnNvbHV0ZWx5IC0gbXkgdGhvdWdodCB3YXMgd2hhdCB0aGUgc2VydmVyIGlzIHN1cHBv c2VkIHRvIGRvLiBSZWFkaW5nIHRoZSBTVFVOL09hdXRoIGRvY3MsIEkgc2VlIGEgcmVxdWlyZW1l bnQgZm9yIGV4cGlyeQ0KYmVpbmcgbGVzcyB0aGFuIHRva2VuIHZhbGlkaXR5IHRpbWUuIEluIFNJ UCBSRUdJU1RFUi9TVUJTQ1JJQkUgdGVybXMsIHRoZSBleHBpcnkgdGltZSBpbiBTSVAgc2hvdWxk IGJlIGxlc3MNCnRoYW4gdGhlIHRpbWUgdGhlIHRva2VuIGlzIHZhbGlkLg0KDQrCoElmIHRoZSB0 b2tlbiBleHBpcmVzLCB0aGUgc2VydmVyIG5lZWRzIHRvIHJlYXV0aCBvciBkZW55IHNlcnZpY2Vz LiBJdCBpcyBpbXBvcnRhbnQgdGhhdCBubyBzZXJ2aWNlcyBhcmUgZGVsaXZlcmVkIHRvIGFuIGV4 cGlyZWQgYXV0aGVudGljYXRpb24uDQoNCi9PDQoNCg0KUmVnYXJkcywNCsKgUmlmYWF0DQoNCg0K T24gV2VkLCBKdWwgMTAsIDIwMTkgYXQgMjo0NCBBTSBPbGxlIEUuIEpvaGFuc3NvbiA8bWFpbHRv Om9lakBlZHZpbmEubmV0PiB3cm90ZToNCg0KDQoNCk9uIDEwIEp1bCAyMDE5LCBhdCAwMjo1Mywg Um9tYW4gU2hwb3VudCA8bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPiB3cm90ZToNCg0KT24gVHVl LCBKdWwgOSwgMjAxOSBhdCA4OjMwIFBNIFJpZmFhdCBTaGVraC1ZdXNlZiA8bWFpbHRvOnJpZmFh dC5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQpUaGUgZG9jdW1lbnQgY2xlYXJseSBhbGxvd3MgdGhl IHVzZSBvZiBhY2Nlc3MgdG9rZW4gdG8gYXV0aGVudGljYXRlIG5vbi1SRUdJU1RFUiByZXF1ZXN0 cyB3aGVuIGNoYWxsZW5nZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIHNhbWUgcmVhbG0uIA0KDQpX aGV0aGVyIHRoYXQgaXMgbmVlZGVkIG9yIG5vdCBpcyBhIGRpZmZlcmVudCBkaXNjdXNzaW9uLg0K QXNzdW1pbmcgdGhlIFVBIHdhcyBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlciBhbmQgb2J0 YWluIGFuIGFjY2VzcyB0b2tlbiwgdGhlbiBlc3RhYmxpc2ggYW4gYXV0aGVudGljYXRlZCBUTFMg Y2hhbm5lbCB3aXRoIHRoZSBzZXJ2ZXIsIGFuZCByZWdpc3RlciB0aGUgdXNlcjsgaXMgdGhlcmUg YSBuZWVkIGZvciBmdXJ0aGVyIGNoYWxsZW5nZXMgZnJvbSBzZXJ2ZXI/DQoNCldoZW4gdGhlIHRv a2VuIGV4cGlyZXMsIHlvdSBjZXJ0YWlubHkgbmVlZCBhIG5ldyB0b2tlbiBmcm9tIHRoZSB1c2Vy LiBXaXRoIFNJUCBPdXRib3VuZCwgd2XigJlyZSBtb3JlIGNvbm5lY3Rpb24gb3JpZW50ZWQgdGhh biBiZWZvcmUsIHNvIHdlIHNob3VsZCBwcm9wYWJseSBjb25zaWRlciB3aGF0IHRoZQ0Kc2VydmVy IGRvZXMgd2l0aCB0aGUgY29ubmVjdGlvbiB3aGVuIGEgdG9rZW4gZXhwaXJlcyAoaWYgaXTigJlz IG5vdCBhbHJlYWR5IGluIHRoZSBkcmFmdCkuDQovTw0KDQoNClR5cGljYWxseSwgZm9yIFNJUCwg dXNlciBhdXRoZW50aWNhdGlvbiBpcyBub3QgdGllZCB0byB0aGUgVExTIGNvbm5lY3Rpb24uIE9u ZSBvZiB0aGUgcmVhc29ucyBmb3IgdGhpcyBpcyB0aGF0IG11bHRpcGxlIHVzZXJzIGNhbiB1c2Ug dGhlIHNhbWUgVExTIGNvbm5lY3Rpb24gaW4gZmVkZXJhdGVkIHN5c3RlbXMuIFRoaXMgaXMgZXNw ZWNpYWxseSB0cnVlIGZvciBDb25maWRlbnRpYWwgVUEsIHdoaWNoIGhhdmUgdHJ1c3QgcmVsYXRp b25zaGlwIHdpdGggYSBwcm94eSBhbmQgY2FuIG1haW50YWluIGEgc2VjdXJlIGNvbm5lY3Rpb24g dG8gdGhlIHJlZ2lzdHJhci9wcm94eSBvbiBiZWhhbGYgb2YgbXVsdGlwbGUgY2xpZW50cy4NCg0K T25jZSBhZ2FpbiwgaXQgd291bGQgYmUgbXVjaCBlYXNpZXIgdG8gZGlzY3VzcyBpZiB5b3UgY2Fu IHByb3ZpZGUgYSB1c2Ugc3BlY2lmaWMgY2FzZSBmb3IgT0F1dGggd2l0aCBjb25maWRlbnRpYWwg VUEuIEkgY2FuIGVhc2lseSB0aGluayBvZiBhIE9BdXRoIHVzZSBjYXNlIGZvciBQdWJsaWMgVXNl ciBBZ2VudCwgYnV0IG9ubHkgaGF2ZSBhIHZhZ3VlIGlkZWEgd2hhdCBPQXV0aCB3aXRoIENvbmZp ZGVudGlhbCBVQSB3b3VsZCBiZS7CoA0KDQpUaGUgZXhhbXBsZSBJIGNhbiB0aGluayBvZiwgd291 bGQgYmUgc29tZSBzb3J0IG9mIGhvdCBkZXNrIGFwcGxpY2F0aW9uLCB3aGVyZSB1c2VyIGFsbG93 cyBhwqBMb2NhbCBQQlggdG8gcmVnaXN0ZXIgd2l0aCBVc2VyIEhvbWUgUEJYIHRvIGFjY2VwdCBj YWxscyBvbiBiZWhhbGYgb2YgdXNlciBpbiBhIHJlbW90ZSBsb2NhdGlvbi4gSW4gdGhpcyBjYXNl LCBMb2NhbCBQQlggYW5kIFVzZXIgSG9tZSBQQlggd2lsbCBiZSBmZWRlcmF0ZWQgc3lzdGVtcyB3 aGljaCB3aWxsIHVzZSBhIHNpbmdsZSBUTFMgY29ubmVjdGlvbiBmb3IgbXVsdGlwbGUgY2FsbHMg b3IgZW5kIHVzZXIgZGV2aWNlcy4gTG9jYWwgUEJYIGFuZCBVc2VyIEhvbWUgUEJYIHdpbGwgaGF2 ZSBhIHRydXN0IHJlbGF0aW9uc2hpcCwgcG9zc2libHkgd2l0aCBtdXR1YWwgVExTIGNlcnRpZmlj YXRlIGF1dGhlbnRpY2F0aW9ucy4gQSBjb21wYW55IHdpZGUgZGlyZWN0b3J5IHNlcnZlciB3aWxs IGJlIHVzZWQgdG8gc3RvcmUgYWN0dWFsIHVzZXIgY3JlZGVudGlhbHMgYW5kIHdpbGwgYmUgdXNl ZCB0byBhdXRoZW50aWNhdGUgdGhlIHVzZXIgYW5kIGdlbmVyYXRlIHRoZSB0b2tlbi4NCg0KQmVz dCBSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KwqANCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlz dA0KbWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCm1haWx0bzpzaXBjb3JlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCg== From nobody Wed Jul 10 06:08:38 2019 Return-Path: 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 4430B120142 for ; Wed, 10 Jul 2019 06:08:37 -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 PP79NhV0AXZw for ; Wed, 10 Jul 2019 06:08:32 -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 B29C2120240 for ; Wed, 10 Jul 2019 06:08:31 -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 2F97AA40; Wed, 10 Jul 2019 15:08:27 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7DF246F-1961-49BF-8097-163D0860DB5B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 15:08:26 +0200 In-Reply-To: Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 13:08:37 -0000 --Apple-Mail=_C7DF246F-1961-49BF-8097-163D0860DB5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef = wrote: >=20 > This does not explain the reason for such a requirement. > Why do you think we need to couple these together for SIP? I don=E2=80=99t want to continue delivering services to clients that are = deleted or blocked in the customer database. With Oauth, the way to block an account is to remove it or change = authorization in the authentication server (IDP) data base. The idea with auth tokens and refresh tokens is to be able to revocate = authorization quickly. Delivering a service beyond revocation is not a good thing in my book. =46rom the definition of Access Token in section 1.4 in RFC 6749: "Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server. =E2=80=9C "Duration of access" is in my world coupled to SIP = registration/subscription expiry. Cheers /O >=20 > Regards, > Rifaat >=20 >=20 >=20 >=20 > On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson > wrote: >=20 >=20 >> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef > wrote: >>=20 >> The UA is expected to obtain a valid access token to get service, and = should be able to use that to refresh its registration when the = registration expires. >> Is this coupling of expiry times needed? > Absolutely. If we grant a REGISTER expiry time that is much longer = than the expiry of the token, we=E2=80=99re in deep waters. >=20 > Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot = from: >=20 > =E2=80=9C o The lifetime provided by the TURN server in the Allocate = and > Refresh responses MUST be less than or equal to the lifetime of > the token. It is RECOMMENDED that the TURN server calculate the > maximum allowed lifetime value using the formula: >=20 > lifetime + Delta - abs(RDnew - TS) >=20 > The RECOMMENDED value for the allowed Delta is 5 seconds. > =E2=80=9C >=20 > Note that they have a =E2=80=9CMUST=E2=80=9D on this. I think we MUST = do the same :-) > /O >=20 >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson > wrote: >>=20 >>=20 >>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef > wrote: >>>=20 >>> When the UA authenticates to the AS, it obtains a number of tokens: = access token and refresh token, and depends on the AS, maybe ID token. >>> It is the UAs responsibility to use the refresh token to obtain a = new access token before the expiry of the existing access token. >> Absolutely - my thought was what the server is supposed to do. = Reading the STUN/Oauth docs, I see a requirement for expiry >> being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, = the expiry time in SIP should be less >> than the time the token is valid. >>=20 >> If the token expires, the server needs to reauth or deny services. = It is important that no services are delivered to an expired = authentication. >>=20 >> /O >>>=20 >>> Regards, >>> Rifaat >>>=20 >>>=20 >>> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >>>=20 >>>=20 >>>> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>>>=20 >>>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >>>> The document clearly allows the use of access token to authenticate = non-REGISTER requests when challenged in the context of the same realm. >>>>=20 >>>> 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? >>>>=20 >>> When the token expires, you certainly need a new token from the = user. With SIP Outbound, we=E2=80=99re more connection oriented than = before, so we should propably consider what the >>> server does with the connection when a token expires (if it=E2=80=99s = not already in the draft). >>> /O >>>>=20 >>>> 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. >>>>=20 >>>> 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.=20 >>>>=20 >>>> 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. >>>>=20 >>>> Best Regards, >>>> _____________ >>>> Roman Shpount >>>> =20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore = >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore = >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_C7DF246F-1961-49BF-8097-163D0860DB5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

This does not explain the reason for such a requirement.
Why do you think we need to couple these together for = SIP?
I don=E2=80=99t want to continue = delivering services to clients that are deleted or blocked in the = customer database.
With Oauth, the way to block an account is = to remove it or change authorization in the authentication server (IDP) = data base.

The idea with auth tokens = and refresh tokens is to be able to revocate authorization = quickly.
Delivering a service beyond revocation is not a good = thing in my book.

=46rom the = definition of Access Token in section 1.4 in RFC 6749:

"Access tokens are credentials used to access protected = resources. An
   access token is a string representing an authorization issued =
to the
   client.  The string is usually opaque to the client.  Tokens
   represent specific scopes and durations of access, granted by the
   resource owner, and enforced by the resource server and authorization
   server.
=E2=80=9C

"Duration of access" is in my world = coupled to SIP registration/subscription expiry.

Cheers
/O


Regards,
 Rifaat




On Wed, Jul = 10, 2019 at 8:25 AM Olle E. Johansson <oej@edvina.net> = wrote:


On 10 = Jul 2019, at 14:18, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

The UA is = expected to obtain a valid access token to get service, and should be = able to use that to refresh its registration when the registration = expires.
Is this coupling of expiry times = needed?
Absolutely. If we grant a REGISTER = expiry time that is much longer than the expiry of the token, we=E2=80=99r= e in deep waters.

Example from RFC 7635 Stun/Oauth - which I think we can = borrow a lot from:

=E2=80=9C o= The lifetime provided by the TURN server in the Allocate = and
      Refresh responses MUST be less than or equal to the =
lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 =
seconds.
=E2=80=9C

Note that they have a =E2=80=9CMUST=E2=80= =9D on this. I think we MUST do the same :-)
/O


Regards,
 Rifaat


On Wed, Jul = 10, 2019 at 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:

When the = UA authenticates to the AS, it obtains a number of tokens: access token = and refresh token, and depends on the AS, maybe ID token.
It is the UAs responsibility to use the refresh token to = obtain a new access token before the expiry of the existing access = token.
Absolutely - my thought was what = the server is supposed to do. Reading the STUN/Oauth docs, I see a = requirement for expiry
being less than token = validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP = should be less
than the time the token is = valid.

 If = the token expires, the server needs to reauth or deny services. It is = important that no services are delivered to an expired = authentication.

/O

Regards,
 Rifaat


On Wed, Jul 10, 2019 at 2:44 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.com> wrote:

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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does = with the connection when a token expires (if it=E2=80=99s not already in = the draft).
/O

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
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_C7DF246F-1961-49BF-8097-163D0860DB5B-- From nobody Wed Jul 10 06:17:21 2019 Return-Path: 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 07B3812024B for ; Wed, 10 Jul 2019 06:17:19 -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 2yE_emOafaxm for ; Wed, 10 Jul 2019 06:17:15 -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 E20C3120240 for ; Wed, 10 Jul 2019 06:17:14 -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 497BAA40; Wed, 10 Jul 2019 15:17:11 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <5240BC21-613D-4C21-93A9-244C1AA3BAF4@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_326D1675-ED1A-4FBB-8D2B-0C5265EBCF1F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 15:17:09 +0200 In-Reply-To: Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 13:17:19 -0000 --Apple-Mail=_326D1675-ED1A-4FBB-8D2B-0C5265EBCF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2019, at 15:08, Olle E. Johansson wrote: >=20 >=20 >=20 >> On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef > wrote: >>=20 >> This does not explain the reason for such a requirement. >> Why do you think we need to couple these together for SIP? > I don=E2=80=99t want to continue delivering services to clients that = are deleted or blocked in the customer database. > With Oauth, the way to block an account is to remove it or change = authorization in the authentication server (IDP) data base. >=20 > The idea with auth tokens and refresh tokens is to be able to revocate = authorization quickly. > Delivering a service beyond revocation is not a good thing in my book. >=20 > =46rom the definition of Access Token in section 1.4 in RFC 6749: >=20 > "Access tokens are credentials used to access protected resources. An > access token is a string representing an authorization issued to = the > client. The string is usually opaque to the client. Tokens > represent specific scopes and durations of access, granted by the > resource owner, and enforced by the resource server and = authorization > server. > =E2=80=9C >=20 > "Duration of access" is in my world coupled to SIP = registration/subscription expiry. >=20 You have actually implicitly written that expiry time accords to token = expiry : "2.3 = . Subsequent Registrations All subsequent REGISTER requests from the UA MUST include a valid access token. The UA MUST obtain a new access token before the access token expiry period to continue to get service from the system.=20 =E2=80=9C You just need to add that the server MUST not allow an expiry that is = greater than the access token expiry time. /O > Cheers > /O >=20 >>=20 >> Regards, >> Rifaat >>=20 >>=20 >>=20 >>=20 >> On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson > wrote: >>=20 >>=20 >>> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef > wrote: >>>=20 >>> The UA is expected to obtain a valid access token to get service, = and should be able to use that to refresh its registration when the = registration expires. >>> Is this coupling of expiry times needed? >> Absolutely. If we grant a REGISTER expiry time that is much longer = than the expiry of the token, we=E2=80=99re in deep waters. >>=20 >> Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot = from: >>=20 >> =E2=80=9C o The lifetime provided by the TURN server in the Allocate = and >> Refresh responses MUST be less than or equal to the lifetime of >> the token. It is RECOMMENDED that the TURN server calculate = the >> maximum allowed lifetime value using the formula: >>=20 >> lifetime + Delta - abs(RDnew - TS) >>=20 >> The RECOMMENDED value for the allowed Delta is 5 seconds. >> =E2=80=9C >>=20 >> Note that they have a =E2=80=9CMUST=E2=80=9D on this. I think we MUST = do the same :-) >> /O >>=20 >>>=20 >>> Regards, >>> Rifaat >>>=20 >>>=20 >>> On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson > wrote: >>>=20 >>>=20 >>>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef > wrote: >>>>=20 >>>> When the UA authenticates to the AS, it obtains a number of tokens: = access token and refresh token, and depends on the AS, maybe ID token. >>>> It is the UAs responsibility to use the refresh token to obtain a = new access token before the expiry of the existing access token. >>> Absolutely - my thought was what the server is supposed to do. = Reading the STUN/Oauth docs, I see a requirement for expiry >>> being less than token validity time. In SIP REGISTER/SUBSCRIBE = terms, the expiry time in SIP should be less >>> than the time the token is valid. >>>=20 >>> If the token expires, the server needs to reauth or deny services. = It is important that no services are delivered to an expired = authentication. >>>=20 >>> /O >>>>=20 >>>> Regards, >>>> Rifaat >>>>=20 >>>>=20 >>>> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >>>>=20 >>>>=20 >>>>> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>>>>=20 >>>>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >>>>> The document clearly allows the use of access token to = authenticate non-REGISTER requests when challenged in the context of the = same realm. >>>>>=20 >>>>> 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? >>>>>=20 >>>> When the token expires, you certainly need a new token from the = user. With SIP Outbound, we=E2=80=99re more connection oriented than = before, so we should propably consider what the >>>> server does with the connection when a token expires (if it=E2=80=99s= not already in the draft). >>>> /O >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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.=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Best Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> =20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore = >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore = >>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 --Apple-Mail=_326D1675-ED1A-4FBB-8D2B-0C5265EBCF1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Jul 2019, at 15:08, Olle E. Johansson <oej@edvina.net> = wrote:



On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

This does not explain the reason for such a requirement.
Why do you think we need to couple these together for = SIP?
I don=E2=80=99t want to continue = delivering services to clients that are deleted or blocked in the = customer database.
With Oauth, the way to block an = account is to remove it or change authorization in the authentication = server (IDP) data base.

The idea with auth tokens and refresh tokens is to be able to = revocate authorization quickly.
Delivering a = service beyond revocation is not a good thing in my book.

=46rom the definition of = Access Token in section 1.4 in RFC 6749:

"Access tokens are credentials used to = access protected resources. An
   access token is a string =
representing an authorization issued to the
   client.  The string is usually opaque to the client.  Tokens
   represent specific scopes and durations of access, granted by the
   resource owner, and enforced by the resource server and authorization
   server.
=E2=80=9C

"Duration of access" is in my world = coupled to SIP registration/subscription expiry.


You have actually implicitly written that expiry = time accords to token expiry :

"2.3. Subsequent = Registrations
   All subsequent REGISTER requests from the UA MUST include a valid
   access token.  The UA MUST obtain a new access token before the
   access token expiry period to continue to get service from the
   system.
=E2=80=9C

You just need to add that the server = MUST not allow an expiry that is greater than
the = access token expiry time.

/O


Cheers
/O


Regards,
 Rifaat




On Wed, Jul = 10, 2019 at 8:25 AM Olle E. Johansson <oej@edvina.net> = wrote:


On 10 = Jul 2019, at 14:18, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

The UA is = expected to obtain a valid access token to get service, and should be = able to use that to refresh its registration when the registration = expires.
Is this coupling of expiry times = needed?
Absolutely. If we grant a REGISTER = expiry time that is much longer than the expiry of the token, we=E2=80=99r= e in deep waters.

Example from RFC 7635 Stun/Oauth - which I think we can = borrow a lot from:

=E2=80=9C o= The lifetime provided by the TURN server in the Allocate = and
      Refresh responses MUST be less than or equal to the =
lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 =
seconds.
=E2=80=9C

Note that they have a =E2=80=9CMUST=E2=80= =9D on this. I think we MUST do the same :-)
/O


Regards,
 Rifaat


On Wed, Jul = 10, 2019 at 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:

When the = UA authenticates to the AS, it obtains a number of tokens: access token = and refresh token, and depends on the AS, maybe ID token.
It is the UAs responsibility to use the refresh token to = obtain a new access token before the expiry of the existing access = token.
Absolutely - my thought was what = the server is supposed to do. Reading the STUN/Oauth docs, I see a = requirement for expiry
being less than token = validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP = should be less
than the time the token is = valid.

 If = the token expires, the server needs to reauth or deny services. It is = important that no services are delivered to an expired = authentication.

/O

Regards,
 Rifaat


On Wed, Jul 10, 2019 at 2:44 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.com> wrote:

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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does = with the connection when a token expires (if it=E2=80=99s not already in = the draft).
/O

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
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


= --Apple-Mail=_326D1675-ED1A-4FBB-8D2B-0C5265EBCF1F-- From nobody Wed Jul 10 06:21:30 2019 Return-Path: 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 6A73D120140 for ; Wed, 10 Jul 2019 06:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 RjcHaVuQo4Me for ; Wed, 10 Jul 2019 06:21:26 -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 76C251200DE for ; Wed, 10 Jul 2019 06:21:26 -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 373C0A40; Wed, 10 Jul 2019 15:21:23 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 10 Jul 2019 15:21:22 +0200 Cc: Olle E Johansson To: SIPCORE X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [sipcore] draft-ietf-sipcore-sip-token-authnz-02 - www and/or proxy auth X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 13:21:29 -0000 Why was proxy auth deemed out of scope for this document? Curious. /O From nobody Wed Jul 10 08:26:14 2019 Return-Path: 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 A35BE1202EF for ; Wed, 10 Jul 2019 08:26:11 -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 5hyA2oJ3sJn3 for ; Wed, 10 Jul 2019 08:26:10 -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 185B312010D for ; Wed, 10 Jul 2019 08:26:09 -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 x6AFQ5Et000880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Jul 2019 11:26:05 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> From: Paul Kyzivat Message-ID: Date: Wed, 10 Jul 2019 11:26:05 -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: <607A513F-8616-4777-8B5E-59390E845709@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 15:26:12 -0000 On 7/9/19 1:45 PM, Christer Holmberg wrote: > OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using the token in binding refresh REGISTER requests is fine. > > But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work. Is the token somehow bound to the "registration service"? (Whatever that is.) ISTM that the token is bound to the parameters from www-authenticate were used in the process of obtaining the token. And so presumably the token should be applicable to any other use that provokes a www-authenticate with the same values of those parameters. So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get challenged the same way I would expect to use the same token for that. And I might decide to preemptively use the same token in the SUBSCRIBE if it is being sent to the same target. Based on analogies to Digest, I would expect that after receiving a Bearer challenge and fetching a matching token I would then add that token to a key ring, indexed by some (which?) of the parameters from the www-authenticate. And then in the future for new requests I would look on the key ring for keys (credentials/tokens) suitable for use on this request. (When doing this I might find either Digest or Bearer credentials, or maybe both.) Am I missing something? Thanks, Paul From nobody Wed Jul 10 08:39:34 2019 Return-Path: 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 54A65120305 for ; Wed, 10 Jul 2019 08:39:33 -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 vvNNIi7cvxY1 for ; Wed, 10 Jul 2019 08:39:31 -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 6DF6F12029A for ; Wed, 10 Jul 2019 08:39:31 -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 x6AFdT7X001801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 10 Jul 2019 11:39:29 -0400 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: Date: Wed, 10 Jul 2019 11:39:29 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-sip-token-authnz-02 - www and/or proxy auth X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 15:39:33 -0000 Ollie, On 7/10/19 9:21 AM, Olle E. Johansson wrote: > Why was proxy auth deemed out of scope for this document? Are you aware of any deployed uses of Proxy-Authenticate? I have never heard of any. IMO Proxy-Authenticate is underspecified, at least for some obscure cases. Consider: - Alice sends a request - It is challenged (Proxy-Authenticate) by P1 - Alice resends with credentials for P1 - P1 accepts credentials and forwards to P2 - P2 challenges for a different realm - For request to succeed, Alice will now have to resend the request with credentials for both P1 & P2 What logic should Alice use to decide what credentials to include in requests to this target, both for the immediate resend, and in future requests to the same target? And another one: - Alice sends a request - It is challenged (Proxy-Authenticate) by P1 - Alice resends with credentials for P1 - P1 forks to P2A and P2B - Both P2A and P2B challenge, with different realms Now what happens? Ideally P1 would aggregate the www-authenticate from both P2A and P2B. And then Alice would gather credentials for both and include them both in a retry, along with the credentials for P1. None of this is well defined. I had suggested earlier that I wouldn't be too bent out of shape if this draft left that out of scope. OTOH, I would prefer that this all be well defined. Or else, if it isn't being used, then maybe Proxy-Authenticate should be deprecated. Thanks, Paul From nobody Wed Jul 10 08:53:25 2019 Return-Path: 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 128C4120241 for ; Wed, 10 Jul 2019 08:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NFsWnG3NlCe6 for ; Wed, 10 Jul 2019 08:53:20 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30089.outbound.protection.outlook.com [40.107.3.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572CC12023E for ; Wed, 10 Jul 2019 08:53:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mkUQtUdvXwmnUWONSLLeK093EZcFxRu39ukPSGTupON7LEjicS/J+ncQ+wtPTbIoqvgURNAPrHZOYLidcn/wuDf+hzHbHnYNdqggVMfjs6Rvpkf7aNK2e4TTx7Wx8OQKTou8K+JaNURoYxDntprixXoCqtXzyMUL5AvUb2PEy8wYsukUVgNmmQIXTcn+EeFyNjbTpMonR/UEzWdp+XDCUPzEVFRhvhmS28OKkAHGe6p4FyYUCszGICKiZa9YRjXvXbj/8M4TOeUlmfo26OLubU/0lRYVTzPqpI5+2ie4CRmLC+My0kzTmn0ZHUDJPWa21AT+lcgCPOxPO0j1m3+Naw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xEHloMTsz/6Edmomg1qZyomczErdL/9Ljxf6DPzrygA=; b=KOF9WsrWGqs++IsjVZpdBY8h+7GJn8vQqGcEFAVqoc92uXP18vpwp22qkgMoeCAZ0byoCNWe+bptiaqP2l/I9WAnqqWUAKUREPS7CEifF8xT0zbaMSqUN77vJd+w4K4thSxkrG7bF1qiN7YIVLyy8Kp9DX/sXoRafKDn8Rib5I5eFyKvmbI481CYCldgxL35/MFuQMoC0Q6qtj7ABDwk4xTK/SQnYb656F03f/no9viebKWgZEHQdhfyV8R1aOpUdP/ZbS9VQEyYFMJVR/lH+vUZXSQyGs5za7mYVOBRR2FuoO4YB01MmuI6S8ptjLDgqUbuB/ntMEP2fcN2xzt0qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xEHloMTsz/6Edmomg1qZyomczErdL/9Ljxf6DPzrygA=; b=gA3bXlOirGJKIe/qMClztwZDhCBMXfI87kliRloWKOZ0ZMBqmlyghmHa133gc1Mj2dZJWel3p6gbDhGOxGMFMkbvShbNzHu0EegnmFkNtoPdxvKMhZDbLulElTgPhgDJR+Vq6q8GkDTOQpB0vb3mKTp43jEDsxR0+1WS1I9yh2c= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB0955.eurprd07.prod.outlook.com (10.162.27.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 15:53:17 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 15:53:17 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSA Date: Wed, 10 Jul 2019 15:53:17 +0000 Message-ID: <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12521bed-662f-4da9-5ebf-08d7054eb9c0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB0955; x-ms-traffictypediagnostic: HE1PR07MB0955: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(136003)(396003)(376002)(346002)(189003)(199004)(3846002)(6116002)(478600001)(102836004)(25786009)(99286004)(66446008)(14454004)(2906002)(76176011)(66556008)(64756008)(68736007)(66476007)(66946007)(5660300002)(76116006)(26005)(36756003)(66066001)(186003)(256004)(14444005)(81166006)(229853002)(44832011)(33656002)(476003)(486006)(11346002)(2501003)(71200400001)(2616005)(6436002)(71190400001)(8936002)(8676002)(81156014)(446003)(58126008)(110136005)(6486002)(6512007)(86362001)(7736002)(6246003)(305945005)(316002)(6506007)(2171002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0955; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QEr11POn8M1MjWeZm/Gt6C0OieVAD9OmUReSb3mNw6JrK8B4Rk6Px8vPUIUHOHcLGKBkO6HPn2Oj58OnZcwnwp7ClQFv4BIxQbrspoUzSIeym7skMmZa3gcZsjDMmumCB2tL0iOjHxpSWA2qwIrCutt/QQxhIOCafBFoNQkp9L030R2SaIpMBhCw18PxKdt2pjZkXHkmjjSetWSi77joETv0g6s1AIxRkJAjiFay1qao5JcPv6P4ZFCWGyB5jgERXslQ8I7Tvnh5l+UBwDQRxeqrfamlmOahsjewbzwC2X66fck06KaF3hv1DThyAGaTlNsZpxSsEMBxCIxeanYmjK9+lhA8JCnbRyR9Ui6ry3BumfDQu926XL8Y1RLDfAFP8RvZMoHpc8XssSo2kqQ3BlwtOs9kaFqgDXcUnWZyK2c= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12521bed-662f-4da9-5ebf-08d7054eb9c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 15:53:17.6495 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0955 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 15:53:23 -0000 SGksDQoNCj4+IE9BdXRoIGFsbG93cyB5b3UgdG8gcmUtdXNlIHRoZSB0b2tlbiBhcyBtYW55IHRp bWVzIGFzIHlvdSB3YW50ICh1bnRpbCBpdCBleHBpcmVzKSBmb3IgdGhlIHNhbWUgc2VydmljZS4g U28sIGZvciBTSVAsIHJlLXVzaW5nIHRoZSB0b2tlbiBpbiBiaW5kaW5nIHJlZnJlc2ggUkVHSVNU RVIgcmVxdWVzdHMgaXMgZmluZS4NCj4+IA0KPj4gQnV0LCB5b3Ugc2hvdWxkIG5vdCByZS11c2Ug YSB0b2tlbiB5b3UgZ290IGZvciBvbmUgInNlcnZpY2UiIChlLmcuLCB5b3VyIHJlZ2lzdHJhdGlv biBhdXRoZW50aWNhdGlvbikgd2l0aCBhbm90aGVyICJzZXJ2aWNlIiAoZS5nLiwgdXNlci10by11 c2VyIGF1dGhlbnRpY2F0aW9uIGZvciBhIFNJUCBjYWxsKS4gSXQgbW9zdCBsaWtlbHkgd291bGRu J3QgZXZlbiB3b3JrLg0KPiAgICANCj4gICAgSXMgdGhlIHRva2VuIHNvbWVob3cgYm91bmQgdG8g dGhlICJyZWdpc3RyYXRpb24gc2VydmljZSI/IChXaGF0ZXZlciB0aGF0IGlzLikNCj4gIA0KPiAg ICBJU1RNIHRoYXQgdGhlIHRva2VuIGlzIGJvdW5kIHRvIHRoZSBwYXJhbWV0ZXJzIGZyb20gd3d3 LWF1dGhlbnRpY2F0ZSANCj4gICAgd2VyZSB1c2VkIGluIHRoZSBwcm9jZXNzIG9mIG9idGFpbmlu ZyB0aGUgdG9rZW4uIEFuZCBzbyBwcmVzdW1hYmx5IHRoZSANCj4gICAgdG9rZW4gc2hvdWxkIGJl IGFwcGxpY2FibGUgdG8gYW55IG90aGVyIHVzZSB0aGF0IHByb3Zva2VzIGEgDQo+ICAgIHd3dy1h dXRoZW50aWNhdGUgd2l0aCB0aGUgc2FtZSB2YWx1ZXMgb2YgdGhvc2UgcGFyYW1ldGVycy4NCg0K WWVzLg0KDQo+ICAgIFNvLCBpZiBJIHVzZSBhIHRva2VuIGluIFJFR0lTVEVSLCBhbmQgdGhlbiBJ IGRvIGEgU1VCU0NSSUJFIGFuZCBnZXQgDQo+ICAgIGNoYWxsZW5nZWQgdGhlIHNhbWUgd2F5IEkg d291bGQgZXhwZWN0IHRvIHVzZSB0aGUgc2FtZSB0b2tlbiBmb3IgdGhhdC4gDQo+ICAgIEFuZCBJ IG1pZ2h0IGRlY2lkZSB0byBwcmVlbXB0aXZlbHkgdXNlIHRoZSBzYW1lIHRva2VuIGluIHRoZSBT VUJTQ1JJQkUgDQo+ICAgIGlmIGl0IGlzIGJlaW5nIHNlbnQgdG8gdGhlIHNhbWUgdGFyZ2V0Lg0K DQpZZXMuDQoNCj4gICAgQmFzZWQgb24gYW5hbG9naWVzIHRvIERpZ2VzdCwgSSB3b3VsZCBleHBl Y3QgdGhhdCBhZnRlciByZWNlaXZpbmcgYSANCj4gICAgQmVhcmVyIGNoYWxsZW5nZSBhbmQgZmV0 Y2hpbmcgYSBtYXRjaGluZyB0b2tlbiBJIHdvdWxkIHRoZW4gYWRkIHRoYXQgDQo+ICAgIHRva2Vu IHRvIGEga2V5IHJpbmcsIGluZGV4ZWQgYnkgc29tZSAod2hpY2g/KSBvZiB0aGUgcGFyYW1ldGVy cyBmcm9tIHRoZSANCj4gICAgd3d3LWF1dGhlbnRpY2F0ZS4gQW5kIHRoZW4gaW4gdGhlIGZ1dHVy ZSBmb3IgbmV3IHJlcXVlc3RzIEkgd291bGQgbG9vayANCj4gICAgb24gdGhlIGtleSByaW5nIGZv ciBrZXlzIChjcmVkZW50aWFscy90b2tlbnMpIHN1aXRhYmxlIGZvciB1c2Ugb24gdGhpcyANCj4g ICAgcmVxdWVzdC4gKFdoZW4gZG9pbmcgdGhpcyBJIG1pZ2h0IGZpbmQgZWl0aGVyIERpZ2VzdCBv ciBCZWFyZXIgDQo+ICAgIGNyZWRlbnRpYWxzLCBvciBtYXliZSBib3RoLikNCj4gICAgDQo+ICAg IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQogIA0KTm8gX18NCg0KSW4gdGhlIGNhc2UgeW91IGRl c2NyaWJlLCB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gdXNlIHRoZSBzYW1lIHRva2VuLg0KDQpBbGwg SSBhbSBzYXlpbmcgaXMgdGhhdCBvbmUgc2hvdWxkIG5vdCBzZW5kIGEgdG9rZW4gdG8gc29tZW9u ZSB0aGF0IGl0IGhhcyBOT1QgYmVlbiBpc3N1ZWQgZm9yLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQogICAgDQoNCg== From nobody Wed Jul 10 15:52:19 2019 Return-Path: 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 06C0F12006A for ; Wed, 10 Jul 2019 15:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6Ve71NLBY1H1 for ; Wed, 10 Jul 2019 15:52:14 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 A8F8A120086 for ; Wed, 10 Jul 2019 15:52:14 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id z3so8424377iog.0 for ; Wed, 10 Jul 2019 15:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P/fS7l7r/ScU399T3+U5ZQMbtGyqh3ZEEdMkjdHVg+c=; b=X7jd9zdwDWiFV71Z7AjsVdj80HqTTr0ckugcmBBObG0Tyy50h2YvhBho1H9Pqw67MK bD7M1DJKjGoXYIDVoy05I7FGreky2JdNIWvCGiiIGbOYJ/b5gxh/8uncBaDqN4foLtWE iInW9W2h7sapd0Z0MnBNlR2obhW9LGt3AKoV1mHe2vbuVkQrbwfta7j3RrJ+hYLvpiMT dsGcZyDxpQOssIn2LqSjaLA+8AA9Va2RdMTXur6+nzEoGRoo5TwQTf2A53peV9FSfGiE RasPtDaR0eIobFmqtkQc9w2VJhi6JuOsnPxQC4zewKKWgiUSPjMdb2dEZE9Zw3BtbpHX FxgQ== 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=P/fS7l7r/ScU399T3+U5ZQMbtGyqh3ZEEdMkjdHVg+c=; b=GJaJ3itk2gz6ybemKxhSopRckAwDHoT0BDlFF4SAbJm7qfPbzJySmPLw+rniNN0zv8 uWpfcwql9b8yUMON8PNUUrYIiQYALmYRq8V+QsKXLAY1YdPkDeJN02AKOgaIhYtdboAb cke7hw8H73MCRc+wnBWpEAXM/1w9JpO1BcIFzRrkCyGWLPPKL/tkblSlhPmNC27WoWI4 NGJs6BuXj22iy0GE3zF54MuQE7TfNKudN7vyWTYRYCB2Ae/HsIyZi/o4A1MYinme59Pr MQuqSrnvZoxwDw1fer7gOd84nRjb744GB0nq0J1C/BLV+RenMKbLrfl6WI81IHRrXWeh LPLg== X-Gm-Message-State: APjAAAX5WLsr0Z89VWJTVQEs/Aj7LAtwBt/MzDWc4ZzPZRVHfezUTEGV /KmGjzcGZ7wKXKTlz+YTz4dlUECwcC0Uq84lDZovYFk09Kc= X-Google-Smtp-Source: APXvYqyfCUc/LX457zjVcuIXOuldGEh5+xxCKtndUP9hWNbK2lkNcH7m5ZVl8Mck3nNZ3s45ENnzY15PNH9Mdw/L1fI= X-Received: by 2002:a02:4005:: with SMTP id n5mr690299jaa.73.1562799133903; Wed, 10 Jul 2019 15:52:13 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> <5240BC21-613D-4C21-93A9-244C1AA3BAF4@edvina.net> In-Reply-To: <5240BC21-613D-4C21-93A9-244C1AA3BAF4@edvina.net> From: Rifaat Shekh-Yusef Date: Wed, 10 Jul 2019 18:52:02 -0400 Message-ID: To: "Olle E. Johansson" Cc: "sipcore@ietf.org" , Roman Shpount Content-Type: multipart/alternative; boundary="0000000000003b5269058d5b877d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 22:52:18 -0000 --0000000000003b5269058d5b877d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Typically, access token is short lived, and in this case it should be used only to allow the UA to register the user. When the time comes to refresh the registration, the UA should use the refresh token, which is long lived as it stays with the UA, to obtain a new access token to update the registration. If you tie it to the registration expiry, then the access token might be valid for a long time, which degrades the security of the token. There are better mechanisms for a proper indication of account revocation, like the mechanisms defined by the Security Events WG: https://datatracker.ietf.org/wg/secevent/documents/ Regards, Rifaat On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson wrote: > > > On 10 Jul 2019, at 15:08, Olle E. Johansson wrote: > > > > On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef > wrote: > > This does not explain the reason for such a requirement. > Why do you think we need to couple these together for SIP? > > I don=E2=80=99t want to continue delivering services to clients that are = deleted > or blocked in the customer database. > With Oauth, the way to block an account is to remove it or change > authorization in the authentication server (IDP) data base. > > The idea with auth tokens and refresh tokens is to be able to revocate > authorization quickly. > Delivering a service beyond revocation is not a good thing in my book. > > From the definition of Access Token in section 1.4 in RFC 6749: > > "Access tokens are credentials used to access protected resources. An > > access token is a string representing an authorization issued to the > client. The string is usually opaque to the client. Tokens > represent specific scopes and durations of access, granted by the > resource owner, and enforced by the resource server and authorization > server. > > =E2=80=9C > > "Duration of access" is in my world coupled to SIP > registration/subscription expiry. > > > You have actually implicitly written that expiry time accords to token > expiry : > > "2.3 > . > Subsequent Registrations > > All subsequent REGISTER requests from the UA MUST include a valid > access token. The UA MUST obtain a new access token before the > access token expiry period to continue to get service from the > system. > > =E2=80=9C > > You just need to add that the server MUST not allow an expiry that is > greater than > the access token expiry time. > > /O > > > Cheers > /O > > > Regards, > Rifaat > > > > > On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson wrote: > >> >> >> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef >> wrote: >> >> The UA is expected to obtain a valid access token to get service, and >> should be able to use that to refresh its registration when the >> registration expires. >> Is this coupling of expiry times needed? >> >> Absolutely. If we grant a REGISTER expiry time that is much longer than >> the expiry of the token, we=E2=80=99re in deep waters. >> >> Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot fro= m: >> >> =E2=80=9C o The lifetime provided by the TURN server in the Allocate and >> >> Refresh responses MUST be less than or equal to the lifetime of >> the token. It is RECOMMENDED that the TURN server calculate the >> maximum allowed lifetime value using the formula: >> >> lifetime + Delta - abs(RDnew - TS) >> >> The RECOMMENDED value for the allowed Delta is 5 seconds. >> >> =E2=80=9C >> >> Note that they have a =E2=80=9CMUST=E2=80=9D on this. I think we MUST do= the same :-) >> /O >> >> >> Regards, >> Rifaat >> >> >> On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson wrote= : >> >>> >>> >>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef >>> wrote: >>> >>> When the UA authenticates to the AS, it obtains a number of tokens: >>> access token and refresh token, and depends on the AS, maybe ID token. >>> It is the UAs responsibility to use the refresh token to obtain a new >>> access token before the expiry of the existing access token. >>> >>> Absolutely - my thought was what the server is supposed to do. Reading >>> the STUN/Oauth docs, I see a requirement for expiry >>> being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, >>> the expiry time in SIP should be less >>> than the time the token is valid. >>> >>> If the token expires, the server needs to reauth or deny services. It >>> is important that no services are delivered to an expired authenticatio= n. >>> >>> /O >>> >>> >>> Regards, >>> Rifaat >>> >>> >>> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson >>> wrote: >>> >>>> >>>> >>>> On 10 Jul 2019, at 02:53, Roman Shpount wrote: >>>> >>>> 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 real= m. >>>>> >>>>> Whether that is needed or not is a different discussion. >>>>> Assuming the UA was able to authenticate the user and obtain an acces= s >>>>> token, then establish an authenticated TLS channel with the server, a= nd >>>>> 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=E2=80=99re more connection oriented than before,= so we should >>>> propably consider what the >>>> server does with the connection when a token expires (if it=E2=80=99s = not >>>> already in the draft). >>>> /O >>>> >>>> >>>> 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 multi= ple >>>> clients. >>>> >>>> Once again, it would be much easier to discuss if you can provide a us= e >>>> 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 certifica= te >>>> 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 >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >> _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > --0000000000003b5269058d5b877d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Typically, access token is short lived, and in this case i= t should be used only to allow the UA to register the user.
When the ti= me comes to refresh the registration, the UA should use the refresh token, = which is long lived as it stays with the UA, to obtain a new access token t= o update the registration.
If you tie it to the registration expiry= , then the access token might be valid for a long time, which degrades the = security of the token.

There are better mech= anisms for a proper indication of account revocation, like the mechanisms d= efined by the Security Events WG:

Regards,
= =C2=A0Rifaat

=C2=A0

On Wed, Jul 10, 2019= at 9:17 AM Olle E. Johansson <oej@edv= ina.net> wrote:


On 10 Jul 2019, at 15:08, Olle E. Johansson <oej@edvina.net> wrote:<= /div>


On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&g= t; wrote:

This does not explain the reason for such a re= quirement.
Why do you think we need to couple these together for SIP?
I don=E2=80=99t want to continue delivering se= rvices to clients that are deleted or blocked in the customer database.
With Oauth, the way to block an account is to remove it or change au= thorization in the authentication server (IDP) data base.

The idea with auth tokens and refresh tokens is to be able to revoc= ate authorization quickly.
Delivering a service beyond revocation= is not a good thing in my book.

From the definiti= on of Access Token in section 1.4 in RFC 6749:

&qu= ot;Access tokens are credentials used t= o access protected resources. An
   access token is a string representing an auth=
orization issued to the
   client.  The string is usually opaque to the client.  Tokens
   represent specific scopes and durations of access, granted by the
   resource owner, and enforced by the resource server and authorization
   server.
=E2=80=9C

"Duration of a= ccess" is in my world coupled to SIP registration/subscription expiry.=


You have = actually implicitly written that expiry time accords to token expiry :

"2= .3. Subsequent Registra= tions
   All subsequent REGISTER requests from the UA MUST include a valid
   access token.  The UA MUST obtain a new access token before the
   access token expiry period to continue to get service from the
   system.
=E2=80=9C

You just need to a= dd that the server MUST not allow an expiry that is greater than
= the access token expiry time.

/O


Cheers
/O


Regards,
=C2=A0Rifaat
<= br>



On Wed, Jul 10, 2019 at 8:25 AM Olle= E. Johansson <oej@e= dvina.net> wrote:


On 10 Jul 2019,= at 14:18, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

The UA is expected to obtain a valid access= token to get service, and should be able to use that to refresh its regist= ration when the registration expires.
Is this coupling of expiry = times needed?
Absolutely. If we grant a REGIS= TER expiry time that is much longer than the expiry of the token, we=E2=80= =99re in deep waters.

Example from RFC 7635 Stun/O= auth - which I think we can borrow a lot from:

=E2= =80=9C=C2=A0o The lifetime provided by= the TURN server in the Allocate and
      Refresh res=
ponses MUST be less than or equal to the lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 seconds.
= =E2=80=9C

Note that they have a =E2=80=9CMUST=E2= =80=9D on this. I think we MUST do the same :-)
/O

=

<= div>Regards,
=C2=A0Rifaat


On Wed, Jul 10, 201= 9 at 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:


= On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
=
When = the UA authenticates to the AS, it obtains a number of tokens: access token= and refresh token, and depends on the AS, maybe ID token.
It is the UA= s responsibility to use the refresh token to obtain a new access token befo= re the expiry of the existing access token.
A= bsolutely - my thought was what the server is supposed to do. Reading the S= TUN/Oauth docs, I see a requirement for expiry
being less than to= ken validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP = should be less
than the time the token is valid.

=C2=A0If the token expires, the server needs to reauth or deny ser= vices. It is important that no services are delivered to an expired authent= ication.

/O

Regards,
=C2=A0Rifaat
<= div>

On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <oej@edvina.net> wrote= :

=
On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.co= m> wrote:

On T= ue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
<= /div>
The document clearly allows the use of = access token to authenticate non-REGISTER requests when challenged in the c= ontext of the same realm.

Whether that is needed or not i= s a different discussion.
Assuming the UA was able t= o authenticate the user and obtain an access token, then establish an authe= nticated TLS channel with the server, and register the user; is there a nee= d for further challenges from server?

When t= he token expires, you certainly need a new token from the user. With SIP Ou= tbound, we=E2=80=99re more connection oriented than before, so we should pr= opably consider what the
server does with the connection when a t= oken expires (if it=E2=80=99s not already in the draft).
/O

Typically, for SIP, user authentication is not tied to th= e TLS connection. One of the reasons for this is that multiple users can us= e the same TLS connection in federated systems. This is especially true for= Confidential UA, which have trust relationship with a proxy and can mainta= in a secure connection to the registrar/proxy on behalf of multiple clients= .

Once again, it would be much easier to discuss i= f 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 va= gue idea what OAuth with Confidential UA would be.=C2=A0

The example I can think of, would be some sort of hot desk applicati= on, where user allows a=C2=A0Local PBX to register with User Home PBX to ac= cept 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 con= nection for multiple calls or end user devices. Local PBX and User Home PBX= will have a trust relationship, possibly with mutual TLS certificate authe= ntications. A company wide directory server will be used to store actual us= er credentials and will be used to authenticate the user and generate the t= oken.

Best Regards,
_____________
Roman Sh= pount
=C2=A0
_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
= sipcore@ietf.org<= br>https://www.ietf.org/mailman/listinfo/sipcore


--0000000000003b5269058d5b877d-- From nobody Wed Jul 10 16:00:28 2019 Return-Path: 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 A78501200C7 for ; Wed, 10 Jul 2019 16:00:26 -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 iaY-HHunsP1K for ; Wed, 10 Jul 2019 16:00:24 -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 820211200B9 for ; Wed, 10 Jul 2019 16:00:24 -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 x6AN02vA000796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Jul 2019 19:00:03 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> From: Paul Kyzivat Message-ID: <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> Date: Wed, 10 Jul 2019 19:00:02 -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: <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:00:26 -0000 On 7/10/19 11:53 AM, Christer Holmberg wrote: > Hi, > >>> OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using the token in binding refresh REGISTER requests is fine. >>> >>> But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work. >> >> Is the token somehow bound to the "registration service"? (Whatever that is.) >> >> ISTM that the token is bound to the parameters from www-authenticate >> were used in the process of obtaining the token. And so presumably the >> token should be applicable to any other use that provokes a >> www-authenticate with the same values of those parameters. > > Yes. > >> So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get >> challenged the same way I would expect to use the same token for that. >> And I might decide to preemptively use the same token in the SUBSCRIBE >> if it is being sent to the same target. > > Yes. > >> Based on analogies to Digest, I would expect that after receiving a >> Bearer challenge and fetching a matching token I would then add that >> token to a key ring, indexed by some (which?) of the parameters from the >> www-authenticate. And then in the future for new requests I would look >> on the key ring for keys (credentials/tokens) suitable for use on this >> request. (When doing this I might find either Digest or Bearer >> credentials, or maybe both.) >> >> Am I missing something? > > No __ > > In the case you describe, you should be able to use the same token. > > 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. 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. Thanks, Paul From nobody Wed Jul 10 16:04:35 2019 Return-Path: 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 C259D120222 for ; Wed, 10 Jul 2019 16:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, 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 IcS_tGt-1xHS for ; Wed, 10 Jul 2019 16:04:30 -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 4D1251201C9 for ; Wed, 10 Jul 2019 16:04:30 -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 x6AN4RS9001115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 10 Jul 2019 19:04:28 -0400 To: sipcore@ietf.org References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> <5240BC21-613D-4C21-93A9-244C1AA3BAF4@edvina.net> From: Paul Kyzivat Message-ID: Date: Wed, 10 Jul 2019 19:04:27 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:04:34 -0000 On 7/10/19 6:52 PM, Rifaat Shekh-Yusef wrote: > Typically, access token is short lived, and in this case it should be > used only to allow the UA to register the user. > When the time comes to refresh the registration, the UA should use the > refresh token, which is long lived as it stays with the UA, to obtain a > new access token to update the registration. > If you tie it to the registration expiry, then the access token might be > valid for a long time, which degrades the security of the token. This puts a different spin on how a key ring of credentials is managed. Either the key ring always have the refresh token, or else perhaps it should contain both, but they should have different expiry times. This goes well beyond anything described in 3261, so I think an explanation is needed. Thanks, Paul > There are better mechanisms for a proper indication of account > revocation, like the mechanisms defined by the Security Events WG: > https://datatracker.ietf.org/wg/secevent/documents/ > > Regards, >  Rifaat > > > > On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson > wrote: > > > >> On 10 Jul 2019, at 15:08, Olle E. Johansson > > wrote: >> >> >> >>> On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef >>> > wrote: >>> >>> This does not explain the reason for such a requirement. >>> Why do you think we need to couple these together for SIP? >> I don’t want to continue delivering services to clients that are >> deleted or blocked in the customer database. >> With Oauth, the way to block an account is to remove it or change >> authorization in the authentication server (IDP) data base. >> >> The idea with auth tokens and refresh tokens is to be able to >> revocate authorization quickly. >> Delivering a service beyond revocation is not a good thing in my book. >> >> From the definition of Access Token in section 1.4 in RFC 6749: >> >> "Access tokens are credentials used to access protected resources. An >> access token is a string representing an authorization issued to the >> client. The string is usually opaque to the client. Tokens >> represent specific scopes and durations of access, granted by the >> resource owner, and enforced by the resource server and authorization >> server. >> “ >> >> "Duration of access" is in my world coupled to SIP >> registration/subscription expiry. >> > > You have actually implicitly written that expiry time accords to > token expiry : > > "2..3 > . > Subsequent Registrations > > All subsequent REGISTER requests from the UA MUST include a valid > access token. The UA MUST obtain a new access token before the > access token expiry period to continue to get service from the > system. > > “ > > You just need to add that the server MUST not allow an expiry that > is greater than > the access token expiry time. > > /O > > >> Cheers >> /O >> >>> >>> Regards, >>>  Rifaat >>> >>> >>> >>> >>> On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson >> > wrote: >>> >>> >>> >>>> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef >>>> > wrote: >>>> >>>> The UA is expected to obtain a valid access token to get >>>> service, and should be able to use that to refresh its >>>> registration when the registration expires. >>>> Is this coupling of expiry times needed? >>> Absolutely. If we grant a REGISTER expiry time that is much >>> longer than the expiry of the token, we’re in deep waters. >>> >>> Example from RFC 7635 Stun/Oauth - which I think we can >>> borrow a lot from: >>> >>> “ o The lifetime provided by the TURN server in the Allocate and >>> >>> Refresh responses MUST be less than or equal to the lifetime of >>> the token. It is RECOMMENDED that the TURN server calculate the >>> maximum allowed lifetime value using the formula: >>> >>> lifetime + Delta - abs(RDnew - TS) >>> >>> The RECOMMENDED value for the allowed Delta is 5 seconds. >>> >>> “ >>> >>> Note that they have a “MUST” on this. I think we MUST do the >>> same :-) >>> /O >>> >>>> >>>> Regards, >>>>  Rifaat >>>> >>>> >>>> On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson >>>> > wrote: >>>> >>>> >>>> >>>>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef >>>>> > >>>>> wrote: >>>>> >>>>> When the UA authenticates to the AS, it obtains a >>>>> number of tokens: access token and refresh token, and >>>>> depends on the AS, maybe ID token. >>>>> It is the UAs responsibility to use the refresh token >>>>> to obtain a new access token before the expiry of the >>>>> existing access token. >>>> Absolutely - my thought was what the server is supposed >>>> to do. Reading the STUN/Oauth docs, I see a requirement >>>> for expiry >>>> being less than token validity time. In SIP >>>> REGISTER/SUBSCRIBE terms, the expiry time in SIP should >>>> be less >>>> than the time the token is valid. >>>> >>>>  If the token expires, the server needs to reauth or >>>> deny services. It is important that no services are >>>> delivered to an expired authentication. >>>> >>>> /O >>>>> >>>>> Regards, >>>>>  Rifaat >>>>> >>>>> >>>>> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson >>>>> > wrote: >>>>> >>>>> >>>>> >>>>>> On 10 Jul 2019, at 02:53, Roman Shpount >>>>>> > wrote: >>>>>> >>>>>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef >>>>>> >>>>> > 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). >>>>> /O >>>>>> >>>>>> 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 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Jul 10 16:08:02 2019 Return-Path: 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 06B2B120275 for ; Wed, 10 Jul 2019 16:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 SfiM5vWEo1pT for ; Wed, 10 Jul 2019 16:07:59 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 4CC761203ED for ; Wed, 10 Jul 2019 16:07:59 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id o13so1927543pgp.12 for ; Wed, 10 Jul 2019 16:07:59 -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=vZfsirhvCr3jgge1KeHvm23x2/olxP7K1lSy8mlC3Tg=; b=b08A62D7IuAIgDDr0fS83vtD/jPfjFszATXgkYdsEh5/0OqBU+NHA7en1/YeHo0Vzc jcVnxokHBmDijCDfmt9rI2tIfEV+1QHqNlkJtrnbdDMDxnz/6TdRE0/5rRrA7Y6OqvMC Q2mERpKQM94imMOhOcu511z9T0aCFYI2iNdBbEYx4eXn+BqSN/KK3oAqAFfh3XRdAJ6X 6w38wsw/9m6LS/KPZqDC5CTCjIMp9CHk3RR2ZefNNJ+1kTrc8o5ZQdM7eSW9SsIiUJtV 3Oww/Z5cnRo93hT/OAqogkXUGSxBapprPw1xt14E+0vakLTP06PGyp2W/kMxAtDMSaab nr2Q== 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=vZfsirhvCr3jgge1KeHvm23x2/olxP7K1lSy8mlC3Tg=; b=GD+nzKjAoa20gJFyr+yDzYn0/NW1h4HO2noijAlpvR18aCQBJdYfuM+s5iPERH3wn1 zT5e6aJFeVpLjITraWvLARDEf1RfBILgRcbmyQRYNH3dI4bILvx5RpTijMRK4LwW1j+u C6OZJkIqN8T6Q7TKeubEsaA2YBe2IsgTlF3dAmRn8NlrnTYZQuUatj0smxAyBhdKy91a M3oUnRlZ4dqgTqgq3CNrJZXn+WBvNV5X/ADgLqFfX+DivqAc4FBxf6pLwb8vZUv5ij2f 9SbfP/I9FdvkdP5k2IfWqF4ppveEm6pCpSMccL1rbTxr1DRBxoETwfZUiMIZYLMcefqX 8KHA== X-Gm-Message-State: APjAAAWz8187xtu9XfDYhG8fdAyB8X7+sudeCe1I78bNO4al6BZxrvDs 4nt+a2TFHypjlIkxhySlii8tQN1d X-Google-Smtp-Source: APXvYqz08v8bnvu2+XDzihfjleSWCEUEqKWaqPQCKDJJz0P7UglBSMn9FJN40VuNxtTRhZEbQAz22g== X-Received: by 2002:a17:90a:208d:: with SMTP id f13mr963767pjg.68.1562800078496; Wed, 10 Jul 2019 16:07:58 -0700 (PDT) Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com. [209.85.215.180]) by smtp.gmail.com with ESMTPSA id j13sm3171292pfh.13.2019.07.10.16.07.57 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 16:07:57 -0700 (PDT) Received: by mail-pg1-f180.google.com with SMTP id z75so1944593pgz.5 for ; Wed, 10 Jul 2019 16:07:57 -0700 (PDT) X-Received: by 2002:a17:90a:b00b:: with SMTP id x11mr982000pjq.120.1562800076627; Wed, 10 Jul 2019 16:07:56 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <42F6AA81-773C-46DB-8BE7-D76951C24B47@edvina.net> In-Reply-To: <42F6AA81-773C-46DB-8BE7-D76951C24B47@edvina.net> From: Roman Shpount Date: Wed, 10 Jul 2019 19:07:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Cc: Rifaat Shekh-Yusef , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006c2510058d5bbf60" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:08:01 -0000 --0000000000006c2510058d5bbf60 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 10, 2019 at 2:40 AM Olle E. Johansson wrote: > On 10 Jul 2019, at 03:44, Roman Shpount wrote: > > On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef > wrote: > >> For me, the main motivation is SSO. >> The user would use one set of corporate credentials to authenticate, >> login to a deskphone, and get access to SIP and non-SIP services. >> >> I am not sure I am following your use case. >> How would the user authenticate and obtain a an access token in this case? >> >> > The use case is the same SSO in combination with hot desks and multiple > PBXs. User picks a desk at a remote office, goes to a web page to login, > enters his credentials and desk location. Expected result is that the phone > on this temporary desk will ring when user gets a call on user's extension > on the user home PBX. Internally, SSO system produces a token, which is > sent to the PBX in the remote office. PBX in the remote office registers > using this token with use home PBX, and configures that all the calls for > this registration are forwarded to the phone on the user temporary desk. > All the calls placed from that desk are also placed through user home PBX > so that correct line is used and user home caller ID is displayed. > > > That seems very complex. How is the token transferred from the web browser > to the phone? And how does the home PBX validate the token sent on behalf > of the user by the remove office PBX? > > Many chains of trust or many leaps of faith. > > But interesting. > > One way to do it is, that remote PBX sends a registration to the home PBX with the token and adds a forwarding rule to the device on the desk. End device credentials are only used between end device and remote PBX, so nothing on the device changes. Another way to do it, if caller ID does not need to be preserved on user calls, is to run a separate service which performs the third party registration on user home PBX. As a result of user login via a web form, this service initiates the registration to the user home PBX with token authentication. Contact address in this registration is the URL pointed to the remote office PBX, which is pre-configured to ring the phone on user desk. I think I've built a couple of services like this, but needed to store user credentials in DB, which was not secure. Using OAuth would have been much cleaner. Best Regards. _____________ Roman Shpount --0000000000006c2510058d5bbf60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2019 at 2:40 AM O= lle E. Johansson <oej@edvina.net&g= t; wrote:
=
On 10 Jul 2019, at 03:44, Roman Shpount= <roman@telurix.c= om> wrote:

On Tue, Jul 9, 2019 a= t 9:29 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
For me, the main motivation is SSO.
The user would use one set= of corporate credentials to authenticate, login to a deskphone, and get ac= cess to SIP and non-SIP services.

I am not sure I = am following your use case.
How would the user authenticate and o= btain a an access token in this case?


The use case is the same SSO in combination with hot = desks and multiple PBXs. User picks a desk at a remote office, goes to a we= b page to login, enters his credentials and desk location. Expected result = is that the phone on this temporary desk will ring when user gets a call on= user's extension on the user home PBX. Internally, SSO system produces= a token, which is sent to the PBX in the remote office. PBX in the remote = office registers using this token with use home PBX,=C2=A0and configures th= at all the calls for this registration are forwarded to the phone on the us= er temporary desk. All the calls placed from that desk are also placed thro= ugh user home PBX so that correct line is used and user home caller ID is d= isplayed.

That seems ver= y complex. How is the token transferred from the web browser to the phone? = And how does the home PBX validate the token sent on behalf of the user by = the remove office PBX?

Many chains of trust or man= y leaps of faith.

But interesting.

<= /div>
=C2=A0
One way to do it is, that rem= ote PBX sends a registration to the home PBX with the token and adds a forw= arding rule to the device on the desk. End device credentials are only used= between end device and remote PBX, so nothing on the device changes.
=

Another way to do it, if caller ID does not need to be = preserved on user calls, is to run a separate service which performs the th= ird party registration on user home PBX. As a result of user login via a we= b form, this service initiates the registration to the user home PBX with t= oken authentication. Contact address in this registration is the URL pointe= d to the remote office PBX, which is pre-configured to ring the phone on us= er desk. I think I've built a couple of services like this, but needed = to store user credentials in DB, which was not secure. Using OAuth would ha= ve been much cleaner.

Best Regards.
_________= ____
Roman Shpount
=C2= =A0
--0000000000006c2510058d5bbf60-- From nobody Wed Jul 10 16:10:57 2019 Return-Path: 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 1484F1202C5 for ; Wed, 10 Jul 2019 16:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 jY_oLqV1Pyxf for ; Wed, 10 Jul 2019 16:10:55 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 1EC901202AD for ; Wed, 10 Jul 2019 16:10:55 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id s27so1956836pgl.2 for ; Wed, 10 Jul 2019 16:10:55 -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=6jD77bpUl2XxQPaadhyGE2Qh5HtrDOfXp1gJoQlIBMA=; b=aszMfwJc1SFRu8e4BK6JgXqod6sjjEJwvhEI7F/Li9zaqKMXPCq5GMV/wCNuQyCy2K +LDc2XYYGVACvQjB0rmktVAvhwH0m5WZZL0mE+dW4R/c8qjul1b0MJRka43w5YZhbkT9 b8C04ZdDud6DMCrlhYf7ynlgYG6WFdAPCqDb4ieSrNP5Gb3uJP8F+VsA0HHYscYVyrxS YMfKGl81U0cnPnBtF8Ka3juyCU5Dlgv6ayywWu/rx6HjNnNgUzeIqtlFFY12Z7B+f4fs mZrBbVynF6TmHWlJvUU7k8IbZNSgX24grKRL87uud5e2Fjx2JcuaubFCZLr/NfnKk2vf Puvw== 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=6jD77bpUl2XxQPaadhyGE2Qh5HtrDOfXp1gJoQlIBMA=; b=kXXuM46rzTk/ptFypcJARF8aDA06bSPjlnUIZXQZNvrUT0PNcAUSJvZ5/J+NIwkk3R nr5jmIsXXLtNdnEC+mvV5M9PagoxZ/QCXq7TpDS2Ujn6AKiSYIMA/29Asz6UCArWn+S9 8i+uefRT80ErV+psTuK3Z5iWVkZOEesGsHFlWxV/xpHYJKambXMmnB4dlclo7LkvaNqU yaxYRtYzoJnOcrCWAZttHQ25a7XwlIvGE1A8JaUEpG9x30tpyp3+a0oivFsz9F5RI+ak VLH59geQzgB6x4lPsOVkvmyUGYs/RQgNbXz7dZCu9Mr6bblS39Jj47RapNx7fK89i6eb huyA== X-Gm-Message-State: APjAAAWZXdw0Bn7ojhdT3LM8Oxy6CSxoONtKJvxXqjjn1fMKd1dUMhFU r089g5I5SiAwmZ6a+K7RFYoXg5/W X-Google-Smtp-Source: APXvYqxYOR+ljzK90GaRqb0PSMKtaRPn/LgLE/NaSgJvq/WnQGuC8t1lCT5Kl+66UgNJHOcsI8NRSw== X-Received: by 2002:a63:e1e:: with SMTP id d30mr846581pgl.100.1562800254302; Wed, 10 Jul 2019 16:10:54 -0700 (PDT) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com. [209.85.214.171]) by smtp.gmail.com with ESMTPSA id g2sm6141732pfq.88.2019.07.10.16.10.53 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 16:10:53 -0700 (PDT) Received: by mail-pl1-f171.google.com with SMTP id i2so1982919plt.1 for ; Wed, 10 Jul 2019 16:10:53 -0700 (PDT) X-Received: by 2002:a17:902:a40c:: with SMTP id p12mr873574plq.146.1562800252855; Wed, 10 Jul 2019 16:10:52 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> In-Reply-To: <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> From: Roman Shpount Date: Wed, 10 Jul 2019 19:10:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Cc: Rifaat Shekh-Yusef , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ed2f34058d5bc994" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:10:56 -0000 --000000000000ed2f34058d5bc994 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson wrote: > > > On 10 Jul 2019, at 02:53, Roman Shpount wrote: > > On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef > 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=E2=80=99re more connection oriented than before, so= we should > propably consider what the > server does with the connection when a token expires (if it=E2=80=99s 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. Best Regards, _____________ Roman Shpount --000000000000ed2f34058d5bc994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2019 at 2:44 AM O= lle E. Johansson <oej@edvina.net&g= t; wrote:
=

On 10 Jul 2019, at 02:53, Roman= Shpount <roman@t= elurix.com> wrote:

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 t= oken to authenticate non-REGISTER requests when challenged in the context o= f the same realm.

Whether that is needed or not is a diff= erent discussion.
Assuming the UA was able to authen= ticate 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 fu= rther challenges from server?

<= /div>
When the token= expires, you certainly need a new token from the user. With SIP Outbound, = we=E2=80=99re more connection oriented than before, so we should propably c= onsider what the
server does with the connection when a token exp= ires (if it=E2=80=99s not already in the draft).

=

Keep in mind that proxy responsible for SI= P Outbound or Web Sockets edge proxy and registrar can be two different ser= vers. 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 al= ways trivial.

Best Regards,
_____________
= Roman Shpount
=C2=A0
--000000000000ed2f34058d5bc994-- From nobody Wed Jul 10 16:15:18 2019 Return-Path: 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 A668F120222 for ; Wed, 10 Jul 2019 16:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 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, URIBL_BLOCKED=0.001] 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 64V8bYephEOk for ; Wed, 10 Jul 2019 16:15:14 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 D3F5B120019 for ; Wed, 10 Jul 2019 16:15:14 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id c2so1955054plz.13 for ; Wed, 10 Jul 2019 16:15:14 -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=Em17Weswk2DkevW6A793LpQ9scCWcYRChmNehjJXlYE=; b=SUft7pN4J4OuMRJYgoCET154cszYikT8wViYu3pyC+aOglcLvAmE4MCQSmXha69zDm 1T3zz+c9tIjHi4b+vZSLKDuIy8VM3mShGASb8nqLeDs7en2KHdm5eSt32ViGM9yS3niU 7BPBhivFi0FoPujiEWS1obB1JgnWVXiabG2K+vsI4ZpFztp+bl1rjbSX5dK57igkcdrD I0vFXpfA9NFW2iDb+RDWetobbosEsTrkTW05JnARVYBn6RmpTAg+Ed3jsnBJc6qKa5q7 nrAcoXOON4qjBRWGO7Q1mfZi8unjdgMOwUbcilXr89dAUgt4LvrRLr2aCe3c4O80TvSx A6Gg== 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=Em17Weswk2DkevW6A793LpQ9scCWcYRChmNehjJXlYE=; b=VDBom3HRV1Pn2qiwmU5lQaBveI5T522I0873ab96nv6Epxt9bv3SjsetM00NsSL40c 5TyPdBgMWEjcmrZbntRJ4TDSxkbSachAEmuStnRr5R0hHQjQJXJ2OJX4DvRqHY8jW12r K9vSFfkHweyWhw1VvMMU36HbX5gbZ5oEYwxjDLM2D8VGaCLh6a2nu+LOAzwG6p25PheH 2NOcnQDPpgE7gsPlJooplA2ipEtNMwu6kDfRWCFDM8KtHxr7OVVO3GfC2y/CeIbBE2/s x7snbs7FSDAtiO8bdq81XpRDCDwKAYadxTCW/hHv01+F3gedDNx5OZkwC4J16rP4l2cz Hg6Q== X-Gm-Message-State: APjAAAX4opnArs0h6z8IsVrUrsg8z+sqapI9mFVHfGllORtI+a4vNf3a h/gqsGBtDrWOW4o8Su2Rbg+UU4/v X-Google-Smtp-Source: APXvYqwecUPEgHjpa1yIdMVAvKul+cdZWyT81e88ohyrlegLleWFtPp0qX+5sWsHoaNq/rqSTj8irQ== X-Received: by 2002:a17:902:28:: with SMTP id 37mr823297pla.188.1562800514111; Wed, 10 Jul 2019 16:15:14 -0700 (PDT) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com. [209.85.214.174]) by smtp.gmail.com with ESMTPSA id f197sm3091558pfa.161.2019.07.10.16.15.13 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 16:15:13 -0700 (PDT) Received: by mail-pl1-f174.google.com with SMTP id c2so1955014plz.13 for ; Wed, 10 Jul 2019 16:15:13 -0700 (PDT) X-Received: by 2002:a17:902:20c8:: with SMTP id v8mr881482plg.284.1562800512798; Wed, 10 Jul 2019 16:15:12 -0700 (PDT) MIME-Version: 1.0 References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: From: Roman Shpount Date: Wed, 10 Jul 2019 19:15:04 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006b9747058d5bd99e" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:15:17 -0000 --0000000000006b9747058d5bd99e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2019 at 2:54 AM Olle E. Johansson wrote: > Wouldn't you use OAuth to establish the WebSocket connection? >> > > No, WebSocket connection is to a different server and typically does not > require authentication. > > I don=E2=80=99t think that=E2=80=99s correct. See section 7 of RFC 7118 -= SIP over WS. > https://tools.ietf.org/html/rfc7118#section-7 > These options are certainly valid but I some times complicate things. As I have mentioned, if registrar and edge proxy are two different servers, using connection based authentication complicates things. > In this specific case, I was thinking OpenSIPS with SIP-over-WS support. > Implementing OAuth authentication of SIP message would be trivial there, > but OAuth authentication for WebSocket would be much less obvious. > > That=E2=80=99s implementation. I am pretty sure that Kamailio can auth th= e > websocket, either by TLS client cert or HTTP digest auth. Guess I need to > test :-) > As I have said, it is probably doable but much less obvious, especially in the scenario where proxy and registrar are separate. > >What credentials is UA using to place a call (send INVITE to the proxy)? >> >If a call comes in from the proxy to UA, what credentials is UA using t= o >> hang up the call (send BYE message)? >> >> If the registry and the call handling is part of the same service I gues= s >> you could use the same credentials, assuming 3261 generally allows using >> the same credentials for registrations and calls. >> > > Are you saying using OAuth token authentication for calls (INVITE) and in > dialog messages (BYE)? > > Why not? It=E2=80=99s just a different Authorization header value. In my = view > Oauth bearer tokens should be usable in all places where you today have M= D5 > digest auth. > > I was trying to figure out exactly this. I was trying to see why Christer says that OAuth should not cover requests other then registration. That seemed strange to me. _____________ Roman Shpount --0000000000006b9747058d5bd99e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 10, 2019 at 2:54 AM O= lle E. Johansson <oej@edvina.net&g= t; wrote:
=
Wouldn't=C2=A0 y= ou use OAuth to establish the WebSocket connection?
= =C2=A0
No, WebSocket connection is to a different server and typi= cally does not require authentication.
I don=E2=80=99t think that=E2=80=99s correct. See section 7 of RFC 7118 - = SIP over WS.=C2=A0https://tools.ietf.org/html/rfc7118#section-7
<= /div>

=C2=A0These options are certainly val= id but I some times complicate things. As I have mentioned, if registrar an= d edge proxy are two different servers, using connection based authenticati= on complicates things.
In this specific cas= e, I was thinking OpenSIPS with SIP-over-WS support. Implementing OAuth aut= hentication of SIP message would be trivial there, but OAuth authentication= for WebSocket would be much less obvious.
That=E2=80=99s implementation. I am pretty sure that Kamailio can auth = the websocket, either by TLS client cert or HTTP digest auth. Guess I need = to test :-)

As I have said, it = is probably doable but much less obvious, especially in the scenario where = proxy and registrar are separate.
>What credentials is UA using to pla= ce a call (send INVITE to the proxy)?=C2=A0
>If a call comes in from the proxy to UA, what credentials is UA using t= o hang up the call (send BYE message)?

If the registry and the call handling is part of the same service I guess y= ou could use the same credentials, assuming 3261 generally allows using the= same credentials for registrations and calls.

Are you saying using OAuth token authentication for calls (INVITE) = and in dialog messages (BYE)?
Why not? = It=E2=80=99s just a different Authorization header value. In my view Oauth = bearer tokens should be usable in all places where you today have MD5 diges= t auth.

I was trying to figure = out exactly this. I was trying to see why Christer says that OAuth should n= ot cover requests other then registration. That seemed strange to me.
= _____________
Roman Shpount
=C2=A0
--0000000000006b9747058d5bd99e-- From nobody Wed Jul 10 23:24:41 2019 Return-Path: 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 DEB441200EF for ; Wed, 10 Jul 2019 23:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0WVpG2RjlCKB for ; Wed, 10 Jul 2019 23:24:37 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150058.outbound.protection.outlook.com [40.107.15.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC9212008B for ; Wed, 10 Jul 2019 23:24:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q1c0vUB+Sw8YrfZbMZHRoRLsIrhuYSe2C66gETNdVgZQ7bboKjGPJ6rSDeZpv3nr53QXVhzzAmOyeGbluE9hxWhaENgUm6rPLyZg7NFemOa08UXNnFYi0cMDaFpeQ7Dk1Vmdt3LbRgJHF+YNeTAAiO9Kt/paS73a7BwEm534VVt8ifQdcmkPPBN9OXI+K/8velGBK4soQASGL/41deudrHF3OD8PI/WnH0taYTJYGeQcYaphx9L39RWmRWeiWGB/+yqwDlN/8iei27K2/vhGThzpNPHsawBvNHOXuOeQcBaeKjvZcvgF3MMMq52K7Vz3j+3KtVD904KdMjiIdm9l2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XMouh/LH692tme+zFIUViQRxiUA1pCsCKlXj4f0ZPFs=; b=Pn0Qy8pL6O28Xb3c57/OScmDlgHd6Bl7cg0Wl5VBZn+KvuiWO5fA2x2kmtqPyUaSZLB7S+UttIDWv8F4I44HvoCwFIQyI4Fn0Jmdq2GtX5PJxqskqwm0zzTSfA2ljoPGVy8k+VlrROLywocnUpL8e7NiafPaqWF4TcGgz/pmic1zhRPGxXMKEA1suhxMCDe18DHwWKqc3CzXLn/4SvKL1dtt9VK4j+9q464rzzfxQHS4AKFKq7Oj3RgoZX3aatRdT1LkqpkNqvvmW87Ih6MeuQae77vVFR6eBFkDbMTOjMlQ5wxBGZDxp5yLOKFUyNpahNp/Ixlfnmulr15uJQ6ZzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XMouh/LH692tme+zFIUViQRxiUA1pCsCKlXj4f0ZPFs=; b=cNl22ZfS76JO3uAviZIQxg4CMADx5aBZxdGev+KDtP5SyvEwYAkKFRnp8r9bR7DUmyKHGYCkYHD93dMUAXr5dMSM2x8VoavbVs1bv/OEuP/rqhRu8md7vMJ0R3GgrHCdCes86Sgu5nnthZJXHFUg1GSczncxg/JdLo56hYU77bQ= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3209.eurprd07.prod.outlook.com (10.170.246.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 06:24:34 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 06:24:34 +0000 From: Christer Holmberg To: Roman Shpount , "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAADBKCAADc7AIAAhRsAgAESEgCAAKpJgA== Date: Thu, 11 Jul 2019 06:24:34 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ecde6cdc-0c0d-4ff0-3d6b-08d705c8711f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3209; x-ms-traffictypediagnostic: HE1PR07MB3209: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(366004)(376002)(189003)(199004)(36756003)(446003)(316002)(6506007)(4744005)(76176011)(68736007)(6512007)(53936002)(478600001)(14454004)(86362001)(33656002)(2616005)(66946007)(66446008)(64756008)(76116006)(66556008)(66476007)(6246003)(3846002)(6116002)(6436002)(6486002)(476003)(256004)(229853002)(7736002)(8676002)(25786009)(305945005)(110136005)(5660300002)(99286004)(4326008)(71190400001)(71200400001)(81166006)(8936002)(26005)(186003)(44832011)(11346002)(486006)(2906002)(81156014)(58126008)(102836004)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3209; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: o4/hWKp4XQ2lPCp4vpDNbd7dqEpnZa2hXMtz3w9b5neWqHEf0bl3MZFO2G6tRrbc3Q4/vWpyPUg2AnC6/+f4FgT6teaIGF9ZqDCqE9+6Ylde+texFv7FD4Njzj+eBFIq1L45tcwImkAMUOMqsBx9YS534k4jlP8bz2ey4WVN6XtDex5isYG5Z1UTUQ/9uK5Sz8xP092eHnGT3NgYCg8aBBUydEmYJgr59UN9RycUiwNQ/F1FoOaQQbRmCMp+to+T1vHvkUkpXAbvzHvSr0KC2mcf3haYR89pyh2x6rE9CSJx4BfW/y8CM4ecX0vWPVu8Om4FOaHzFg2XdZIhLY4/0tDxj0A6Xa6oM9PVXObeD3Rf3YXzn5KMTJWTxNaOSyjnUb53V6SEVNaU7e7Bjq5FdbVg61DnfJh+NN6E5DzwZDw= Content-Type: text/plain; charset="utf-8" Content-ID: <0BC646C649282B408DF5C0B59E1E2EAB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ecde6cdc-0c0d-4ff0-3d6b-08d705c8711f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 06:24:34.4076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3209 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 06:24:40 -0000 SGksDQoNCi4uLg0KDQo+SSB3YXMgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgZXhhY3RseSB0aGlzLiBJ IHdhcyB0cnlpbmcgdG8gc2VlIHdoeSBDaHJpc3RlciBzYXlzIHRoYXQgT0F1dGggc2hvdWxkIG5v dCBjb3ZlciByZXF1ZXN0cyANCj5vdGhlciB0aGVuIHJlZ2lzdHJhdGlvbi4gVGhhdCBzZWVtZWQg c3RyYW5nZSB0byBtZS4NCg0KSSBhcG9sb2dpemUgZm9yIGJlaW5nIHVuY2xlYXIuIFlvdSBjYW4g Zm9yIHN1cmUgdXNlIGl0IGZvciBub24tcmVnaXN0cmF0aW9uIHJlcXVlc3RzLg0KDQpXaGF0IEkg bWVhbnQgd2FzIHRoYXQgbm9ib2R5IGhhcyBldmVyIGFza2VkIGZvciBpdCwgc28gSSBxdWVzdGlv bmVkIHdoZXRoZXIgaXQgbmVlZHMgdG8gYmUgYWRkZWQgdG8gdGhlIGRyYWZ0IGF0IHRoaXMgcG9p bnQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQogDQrCoA0KDQo= From nobody Wed Jul 10 23:54:12 2019 Return-Path: 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 4057C12015A for ; Wed, 10 Jul 2019 23:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BiECJtfNasU7 for ; Wed, 10 Jul 2019 23:54:09 -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 4755E120045 for ; Wed, 10 Jul 2019 23:54:08 -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 B196DA40; Thu, 11 Jul 2019 08:54:04 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 08:54:04 +0200 Cc: Olle E Johansson , Roman Shpount , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7C47DC5A-6FD4-4BAE-880C-02E21E6F5F52@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 06:54:11 -0000 > On 11 Jul 2019, at 08:24, Christer Holmberg = wrote: >=20 > Hi, >=20 > ... >=20 >> I was trying to figure out exactly this. I was trying to see why = Christer says that OAuth should not cover requests=20 >> other then registration. That seemed strange to me. >=20 > I apologize for being unclear. You can for sure use it for = non-registration requests. >=20 > What I meant was that nobody has ever asked for it, so I questioned = whether it needs to be added to the draft at this point. To break the trend, I ask for it. /O= From nobody Thu Jul 11 00:00:20 2019 Return-Path: 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 16EE6120045 for ; Thu, 11 Jul 2019 00:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 P37vob4HLETs for ; Thu, 11 Jul 2019 00:00:15 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CEA120091 for ; Thu, 11 Jul 2019 00:00:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kYSGy4nsiedRc+cm7q4TiUQJi65a77KA8HB6zeMTzoJCm5f8iI8zPe8rZTlq9xvljXCejQhk5VPxhBfWvb6Sy+AYggujLD/nCSppAjRzJaVEh68IJF83oHNZIdyklD1F1OlHTDV5A3+e8KLPM3Uc/h2XfxcItjzRxAtrjYnxHCjee9r+4asHMHLxAcn00NYMLMLaz6FXfZSkSmdHXhqcuWeXJX2TSsKwQNHqbca0eoxBk4hy3pCR29HrVIqmoH/lWRWWNnUEOAJ714RONjtpHL7RBST3NBPgoLHkDesLczKrNlG3f+jO65eEMdIgfiazf9UBviExH6iVxH/6HG9WoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MKmkVwxrQpA51susDCNYQwjvQmjgdBsdhBknYCTiNHU=; b=bhBNHfhMbxq7zxZKXOLO2+JFxYDMdufs38noSJypqDkRgAXI9vBYKTD8dx1RiyMJULLIIpFakQw26icY0O2T2mLU9lsV7UJIGqpPiNeDroDoC3bjqxxOZL+fhMGLF9JfPNPku0JrJAyk+u6RuykLbYuchy3b7/5oHlLRzdFsFrURaYxpHzKP8hM2nean4ZSj46TpZ5NGjqm/C/YJ22qfuqUMpOHpYmRt2tGeb4f9C8ZL9Xmc1OnKSTEcgll2zSkeKWn9jWYD45HtC4L4ELl4jjLrlHau8FGMuSEUmOn7sm/t+U7aBs2YEEb4NWRaz75MpWEzWRHd3d5Vya3eCkOD2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MKmkVwxrQpA51susDCNYQwjvQmjgdBsdhBknYCTiNHU=; b=Fw/OKrSzZ2d390esgLrdc+Qt9Fd6x4I1ogdpf9XKUCAMyQ/brnTPAS4dUIcZ7ZDLsYmBvb672Vr4rVc03S0LQiYO4zGyEwu5Y6ZQ7aHIAtMGvKOwG0Shot2G4ABTKTBvWmMuG66OTMlsyiEjYjRYUAPkW1sUl33eGZ56RZWqK5M= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3354.eurprd07.prod.outlook.com (10.170.247.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 07:00:12 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 07:00:12 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: Roman Shpount , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAADBKCAADc7AIAAhRsAgAESEgCAAKpJgP//1fUAgAA0AQA= Date: Thu, 11 Jul 2019 07:00:12 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <7C47DC5A-6FD4-4BAE-880C-02E21E6F5F52@edvina.net> In-Reply-To: <7C47DC5A-6FD4-4BAE-880C-02E21E6F5F52@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74be478d-9a29-4696-6198-08d705cd6b8b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3354; x-ms-traffictypediagnostic: HE1PR07MB3354: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(39860400002)(346002)(136003)(376002)(199004)(189003)(52314003)(478600001)(6486002)(8936002)(99286004)(76116006)(6512007)(81166006)(66446008)(64756008)(66946007)(66556008)(36756003)(68736007)(486006)(66476007)(6436002)(71200400001)(86362001)(71190400001)(81156014)(4744005)(8676002)(26005)(6506007)(66066001)(102836004)(25786009)(446003)(229853002)(33656002)(6916009)(2616005)(305945005)(11346002)(476003)(186003)(76176011)(14454004)(4326008)(3846002)(53936002)(6116002)(6246003)(256004)(5660300002)(7736002)(54906003)(58126008)(44832011)(2906002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3354; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1ooxI7VKUwm73EzSaz7C+FO1e3kOBaCfPF246p/pe+PXU4ti4DhNEmYTehyoUFOJH6ejAgGBo8FDBGxv+Gay2+7yhZxCKzgKqPBnkB5iFsdndLLOe2jgRXm8CbaeHs3G3kjeSpDmAwLUtKknEfvvJcH2hYnx/YFSON2O2+hvsBL/2I0V5B5d7BxFFLHVX3GvjSru1AmLoMZNtfz3EeJTKFFCiwHAgsbat9W0jpYXB622i2iCb8vODGmt0Jqr+9zG6lEgol3G0C6KjQ5zwM0RbJd20axoKElIaF8nERdPwGe9FN+AUpNkG6wouHcbvlSNsM1Ok2EdE+k4sF9M9Ldr0fFpFA9S2SZKQdqKA411AgTaKgkRgtw5v18qvsBCgZ+z5/a7pJNCuOo1Rn11JZ8kr2vTb0xtPBsxHB/xpWiFQr8= Content-Type: text/plain; charset="utf-8" Content-ID: <44234F161FAFA6419CF8B3389C627CF5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74be478d-9a29-4696-6198-08d705cd6b8b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 07:00:12.4816 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3354 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:00:18 -0000 SGksDQoNCiA+Pj4gSSB3YXMgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgZXhhY3RseSB0aGlzLiBJIHdh cyB0cnlpbmcgdG8gc2VlIHdoeSBDaHJpc3RlciBzYXlzIHRoYXQgT0F1dGggc2hvdWxkIG5vdCBj b3ZlciByZXF1ZXN0cyANCiA+Pj4gb3RoZXIgdGhlbiByZWdpc3RyYXRpb24uIFRoYXQgc2VlbWVk IHN0cmFuZ2UgdG8gbWUuDQogPj4gDQogPj4gSSBhcG9sb2dpemUgZm9yIGJlaW5nIHVuY2xlYXIu IFlvdSBjYW4gZm9yIHN1cmUgdXNlIGl0IGZvciBub24tcmVnaXN0cmF0aW9uIHJlcXVlc3RzLg0K ID4+IA0KID4+IFdoYXQgSSBtZWFudCB3YXMgdGhhdCBub2JvZHkgaGFzIGV2ZXIgYXNrZWQgZm9y IGl0LCBzbyBJIHF1ZXN0aW9uZWQgd2hldGhlciBpdCBuZWVkcyB0byBiZSBhZGRlZCB0byB0aGUg ZHJhZnQgYXQgdGhpcyBwb2ludC4NCiA+ICAgDQogPiBUbyBicmVhayB0aGUgdHJlbmQsIEkgYXNr IGZvciBpdC4NCg0KSXQgd291bGQgaGF2ZSBiZWVuIG5pY2UgaWYgeW91IGhhZCBhc2tlZCBmb3Ig aXQgeWVhcnMgYWdvIHdoZW4gdGhlIHdvcmsgc3RhcnRlZCwgYnV0IGJldHRlciBsYXRlIHRoYW4g bmV2ZXIgOikNCg0KQW55d2F5LCBJIGRvbid0IHdhbnQgdG8gc3BlbmQgdGltZSBhcmd1aW5nIHdo ZXRoZXIgaXQgc2hvdWxkIGJlIGluY2x1ZGVkOiBpZiBwZW9wbGUgd2FudCBpdCwgbGV0J3MgaW5j bHVkZSBpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg== From nobody Thu Jul 11 00:03:13 2019 Return-Path: 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 A66FA12010E for ; Thu, 11 Jul 2019 00:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JNwi3HIyycAR for ; Thu, 11 Jul 2019 00:03:10 -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 DD0D1120045 for ; Thu, 11 Jul 2019 00:03:09 -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 5E770A40; Thu, 11 Jul 2019 09:03:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 09:03:04 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount Content-Transfer-Encoding: quoted-printable Message-Id: <981789E7-12B2-4E25-B812-2C0C0A07718B@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <7C47DC5A-6FD4-4BAE-880C-02E21E6F5F52@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:03:12 -0000 > On 11 Jul 2019, at 09:00, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>> I was trying to figure out exactly this. I was trying to see why = Christer says that OAuth should not cover requests=20 >>>> other then registration. That seemed strange to me. >>>=20 >>> I apologize for being unclear. You can for sure use it for = non-registration requests. >>>=20 >>> What I meant was that nobody has ever asked for it, so I questioned = whether it needs to be added to the draft at this point. >>=20 >> To break the trend, I ask for it. >=20 > It would have been nice if you had asked for it years ago when the = work started, but better late than never :)n I apologize for not spending time on this earlier. Life got in the way = :-) >=20 > Anyway, I don't want to spend time arguing whether it should be = included: if people want it, let's include it. I don=E2=80=99t see any reason to use one auth scheme for a specific sip = method. What was the thinking behind that? /O >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 11 00:03:22 2019 Return-Path: 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 0F931120045 for ; Thu, 11 Jul 2019 00:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 GgP5MgpqA4lG for ; Thu, 11 Jul 2019 00:03:10 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256EF120091 for ; Thu, 11 Jul 2019 00:03:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/0IMNYPcZJe4Kikou5sAsrEyW+qpDKfRLuCnQNkOtUpM5uhVUGOCwe/rR1rKnaaoXIDVnYvSHao0PVqWCFIATcDDdIYLbkYAWe3qvjCaaHWdvZDF2jbyOFq4ENalo6Y9DBBg1sqlock65sAsf0F3FhH0FjgiDXyQMObPWVHqIgmGIkuoyMRUmR+BUPcKouJV+Jy8Cwb/h4IbGTGwmsuYdcw/vi5qwE6EWFOiNKc+kOm4ejtvlXqcqePi4qkWfRz78NkQ0hU1QZQFQqZ+vXm8LOHr8Hx5WzMbUIs/sATO3RZSgQJCmKaRrii2ZCDs4G0cvATy/Oq4UQI19xFgdMa4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vci0YF5nzZAIEn27Qd4D8kjQ7KJIPhpDt7Rrb6rUr0g=; b=gQa9IfrT7Zad5DA/SbSeLEY5kMwTIGA7pUsZpyUaNk8r2bPJLzYmNOneyAagBV7nw/4DUZH7uCmaVmgR5N/Z+fdPssQ24fLDbhXvHwnA9H7qLNErP5glYfwh0/Scp12h9lu21M1QXZNpGYazhj2WS6X8t12fIb3PTv0sgFLuxVoPjr/CWTmGq7zH6Sl6JvIKGt5kckMBY49IOpAlwPPa0wFF9aLS4axeRETBFbQPK6aoAHAEx99ehcM0Xg79YheSdMcsBfuin+HWMHA1lz90RBB66gsYDXhKtCSeXFfhfUMbTF9LhumDn3wSMVQ/hVxx8ucYPagArHJPSwx6k0LWbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vci0YF5nzZAIEn27Qd4D8kjQ7KJIPhpDt7Rrb6rUr0g=; b=Q4zdXsJcypHbte9+/JMVvgcdFBIjxpxfBVPkALZMQ/1whrZpvLkVN0h8G9YmmGb49YDjuegW7XtCM+YsWfTpF+xzvi52M5wqZzzmCcqjEI2Psr3pTN9GkQKvdyk2z+pzreIpmIq9MhWh8D+8VvoVwJ/pC7fW7m+fZTR/vHOWTC4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3226.eurprd07.prod.outlook.com (10.170.246.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 07:03:07 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 07:03:07 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgA== Date: Thu, 11 Jul 2019 07:03:07 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> In-Reply-To: <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c90c25e6-ea0c-4f79-93a5-08d705cdd391 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3226; x-ms-traffictypediagnostic: HE1PR07MB3226: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(189003)(199004)(66476007)(66946007)(66446008)(64756008)(76116006)(44832011)(14454004)(66556008)(6436002)(6506007)(71190400001)(71200400001)(53936002)(66066001)(2501003)(5660300002)(68736007)(102836004)(25786009)(86362001)(6512007)(478600001)(2906002)(446003)(110136005)(81156014)(11346002)(58126008)(316002)(256004)(6246003)(33656002)(2616005)(36756003)(3846002)(26005)(486006)(186003)(8936002)(229853002)(76176011)(6486002)(6116002)(7736002)(476003)(305945005)(99286004)(2171002)(8676002)(14444005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3226; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: f8LEoRAM9s7D4y0C0tL8Ua18Ah12RXtqWEgBIiP+5qEFrEZopqVTGID46mzBGkDSgGYu6+9fSe0jCj4XoEiQ8MbOAc+3aU3+1uXose2LMSlsTAfIkgJcWcF6is6VQoFdzO7s2HqGb4lkZx5f6e3qPNQHa04GTN87oe7Ll0Oe4DvbZbhLONwM2jTHI5SQukzkNdcMwBWK1GbvV6nMV34DKD45Ym+E3783SuWpNeJaSmL/dPe+q7PvIgzMig9eCIXpNpZncPxc1cUrfpKBF93ssZSf3MfnOxUbHD6oKgLZ9J1Q1TtYTaDIfqQ66y3rhljFzPhDfLl0LhnnuqSu6FxCoMTNJk/QWpUje6Fn1QOWrERb6osiJrcFgmPUBIJYv2vJSrd7ugTjOf+tTji8Z12cH9IBNFWHi0LFfjjgEXwsIVY= Content-Type: text/plain; charset="utf-8" Content-ID: <5F749D14CEC75A4FA0049659DA5782DC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c90c25e6-ea0c-4f79-93a5-08d705cdd391 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 07:03:07.0713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3226 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:03:13 -0000 SGksDQoNCi4uLiANCg0KPj4gQWxsIEkgYW0gc2F5aW5nIGlzIHRoYXQgb25lIHNob3VsZCBub3Qg c2VuZCBhIHRva2VuIHRvIHNvbWVvbmUgdGhhdCBpdCBoYXMgTk9UIGJlZW4gaXNzdWVkIGZvci4N Cj4gICAgDQo+ICAgIFRoZW4geW91IGFyZSBzYXlpbmcgdGhhdCBhIHRva2VuIHNob3VsZCAqbmV2 ZXIqIGJlIGluY2x1ZGVkIGluIGEgcmVxdWVzdCANCj4gICAgdG8gYSB0YXJnZXQgZm9yIHdoaWNo IHlvdSBoYXZlIG5vdCByZWNlaXZlZCBhIGNoYWxsZW5nZSBzb21lIHRpbWUgaW4gdGhlIA0KPiAg ICBwYXN0Lg0KPiAgICANCj4gICAgVGhhdCBpcyBhIGJpdCBleHRyZW1lLCBidXQgSSBndWVzcyB5 b3UgY2FuIHNwZWNpZnkgdGhhdCBpZiB5b3UgdGhpbmsgaXQgDQo+ICAgIGlzIHRoZSByaWdodCB0 aGluZyB0byBkby4NCg0KVGhhdCBpcyBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBnZW5lcmljIE9B dXRoIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiB5b3UgZG9uJ3QgZ2l2ZSBhIHRva2VuIHRvIHNv bWVvbmUgaXQgd2FzIG5vdCBpbnRlbmRlZCBmb3IuDQoNCk9mIGNvdXJzZSwgaWYgeW91IGtub3cg KGJhc2VkIG9uIHdoYXRldmVyIGNvbmZpZ3VyYXRpb24vcG9saWN5KSB0aGF0IGl0J3Mgb2sgdG8g Z2l2ZSB0aGUgdG9rZW4gdG8gdGhlIHRhcmdldCBJIGd1ZXNzIHlvdSBjb3VsZCBkbyBpdC4NCiAg ICANCj4gICAgQnV0IG5vdGUgdGhhdCB0aGlzIGxvZ2ljIHdvbid0IGFsd2F5cyB3b3JrIGZvciBQ cm94eS1BdXRoZW50aWNhdGUuIFlvdSANCj4gICAgKm1pZ2h0KiBrbm93IHRoYXQgYSBwYXJ0aWN1 bGFyIHByb3h5IHdpbGwgYmUgdmlzaXRlZCAoaWYgaXQgaXMgbWVudGlvbmVkIA0KPiAgICBvbiBh IFJvdXRlIGhlYWRlciksIGJ1dCBpdCBpcyBwcmV0dHkgY29tbW9uIGZvciB0aGUgcmVxdWVzdCB0 byB2aXNpdCANCj4gICAgcHJveGllcyB1bmtub3duIChhdCBsZWFzdCBpbiBhZHZhbmNlKSB0byB0 aGUgVUFDLg0KICANCkl0IGlzIGltcG9ydGFudCB0byByZW1lbWJlciB0aGF0LCBzaW5jZSB0aGUg dG9rZW4gbmVlZHMgdG8gYmUgcHJvdGVjdGVkLCBhIHByb3h5IG5lZWRzIHRvIGhhdmUgdGhlIGFz c29jaWF0ZWQgcHJvdGVjdGlvbiBjcmVkZW50aWFscyB0byBiZSBhYmxlIHRvIGFjY2VzcyB0aGUg dG9rZW4uIA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQogICAgDQoNCg== From nobody Thu Jul 11 00:07:25 2019 Return-Path: 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 47489120173 for ; Thu, 11 Jul 2019 00:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DjVzcSyb_IA3 for ; Thu, 11 Jul 2019 00:07:21 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50088.outbound.protection.outlook.com [40.107.5.88]) (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 73B19120045 for ; Thu, 11 Jul 2019 00:07:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bjayUjrXnJgold1T0hoFsF0MtdK60dUYU3e5/eimHfETe/eyW/xXtvv1C5W4dC4DvsWipz32n6qYZzXXkN3wxhvae2nJN4eLraWvjtcu+9SCHs9MeSoouUTf5CZgCBtaBFJ4V8iT6n9IPFquiTVcGtIq0aitRp26k5PGc0xjFYb+MT1JV/1z018QSVxdjVRtd5isAZBNcGSbeQliOBLYYPTAGg+OcTcufKl/07fTnd/HuLDWoo47bBRA7lOj1aRrnfEZCvDNenU48RmObAvAa92vlf2Xf24hWWtb82pq6T7Tmw9XbnnXe+U834Zop0O8z269QdoeLGSnZ6adAknbIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IKA/eS+6ZCOAGcu8NubChIfsUWwOB0F6ZykK4pnBCIw=; b=GczjRaOIH+Xs0/ePWoeoliTDxPMOyi5MW97mAvbkS/NIqNrTt70vEO3YavE8DcDtSz/+wKfm1zHMmVS62x4/bfC4GPeIvAeBKIZKCLLZtbm4yWEhiojK4IJRXTCNfw8OgIuYHQfQCXLU8AtYHm3eQoUBcMT0t8OBGF63WeVka6mOKYOUPCvjyBRhC3MU6dAZ4bMsRQXJLYoDR8g90jA9PofONDkQiMhIAahezw7eSBz/wp1VEGL9uiffAyNoiFOx9jjER2uaMEybBSrmpwXm0x5liMOQ4CArxMUOepejHSRhLy++coTcIQywC6pSGyhxI7OJNBU5V4NrobJ3M1qLTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IKA/eS+6ZCOAGcu8NubChIfsUWwOB0F6ZykK4pnBCIw=; b=IYTUP5gqXVW4beMq1ePJD3mvAQq2pZ02RVNgId/ye/RGqsMNPilHMoSsTkrDuiRShHapdsq95MXXm2uCKzTGWhIlLGNeGxeJtQ5T73kOThAwHlc730Qq9pIXiBq60LyeGz++lUzlloS7G1AUkp3CWc8+Jew6BPZF3XIAUz0YS1g= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3516.eurprd07.prod.outlook.com (10.170.248.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.8; Thu, 11 Jul 2019 07:07:15 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 07:07:15 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" , Roman Shpount Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///8CoCAAAq/0IAABmoAgAADBKCAADc7AIAAhRsAgAESEgCAAKpJgP//1fUAgAA0AQD//86CAAAGbrMA Date: Thu, 11 Jul 2019 07:07:15 +0000 Message-ID: <7FC95F63-BA11-4783-B402-77A0E5D4A3AC@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <7C47DC5A-6FD4-4BAE-880C-02E21E6F5F52@edvina.net> <981789E7-12B2-4E25-B812-2C0C0A07718B@edvina.net> In-Reply-To: <981789E7-12B2-4E25-B812-2C0C0A07718B@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea07abb3-da15-4567-b748-08d705ce6794 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3516; x-ms-traffictypediagnostic: HE1PR07MB3516: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(39860400002)(396003)(346002)(52314003)(199004)(189003)(2906002)(25786009)(102836004)(229853002)(53936002)(26005)(76176011)(6506007)(6486002)(6512007)(5660300002)(478600001)(71200400001)(66556008)(66476007)(76116006)(11346002)(2616005)(66946007)(71190400001)(486006)(64756008)(476003)(66446008)(6246003)(99286004)(6436002)(446003)(86362001)(256004)(44832011)(14454004)(8936002)(68736007)(4326008)(58126008)(186003)(316002)(305945005)(7736002)(54906003)(36756003)(33656002)(8676002)(81166006)(81156014)(6116002)(3846002)(6916009)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3516; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KLDiqKB4hHXRZOYg6FY7ztn7TEyIP7hR7U7GMnnmZQuHGIkC+MEe3zmDqD3/NreHVOnY8yjkHI75gRYhQzq053fnw5YxJGzmbuNrXZSRSd6Nrl3EDXMlfEueCrvjgiFDPrbMPQOF5OKEUhAoEamZlbMMWvFBi2LvUudheQ52KH8LqDAQN5WBbFBMlYjyhfGnzPMexZKtkl7BFoqSPB7n5zDOcA2g0ZS6H7O3QFUu3TyeZrn58fDhLMRwLH+ZB/BapJq+U8P7x8JaG1/7sCPYEJb6q+fbi9Nnv4JsUE/RzRd1YBOiNZTbx3vNhSqakJa3O8kE6dINURtSyUEYalBV1VK3NoAn27bocQYS09IetKjLCTLxPdl7pDFDNVJXnusKVpvPQU/r8qBhOXUzZ7TQI+7EeeUlsYxNKkqYCbGraTw= Content-Type: text/plain; charset="utf-8" Content-ID: <68BE34CC08A4F34A92592F49D2F95733@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea07abb3-da15-4567-b748-08d705ce6794 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 07:07:15.3546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3516 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:07:23 -0000 SGksDQoNCj4+Pj4+IEkgd2FzIHRyeWluZyB0byBmaWd1cmUgb3V0IGV4YWN0bHkgdGhpcy4gSSB3 YXMgdHJ5aW5nIHRvIHNlZSB3aHkgQ2hyaXN0ZXIgc2F5cyB0aGF0IE9BdXRoIHNob3VsZCBub3Qg Y292ZXIgcmVxdWVzdHMgDQo+Pj4+PiBvdGhlciB0aGVuIHJlZ2lzdHJhdGlvbi4gVGhhdCBzZWVt ZWQgc3RyYW5nZSB0byBtZS4NCj4+Pj4gDQo+Pj4+IEkgYXBvbG9naXplIGZvciBiZWluZyB1bmNs ZWFyLiBZb3UgY2FuIGZvciBzdXJlIHVzZSBpdCBmb3Igbm9uLXJlZ2lzdHJhdGlvbiByZXF1ZXN0 cy4NCj4+Pj4gDQo+Pj4+IFdoYXQgSSBtZWFudCB3YXMgdGhhdCBub2JvZHkgaGFzIGV2ZXIgYXNr ZWQgZm9yIGl0LCBzbyBJIHF1ZXN0aW9uZWQgd2hldGhlciBpdCBuZWVkcyB0byBiZSBhZGRlZCB0 byB0aGUgZHJhZnQgYXQgdGhpcyBwb2ludC4NCj4+PiANCj4+PiBUbyBicmVhayB0aGUgdHJlbmQs IEkgYXNrIGZvciBpdC4NCj4+IA0KPj4gSXQgd291bGQgaGF2ZSBiZWVuIG5pY2UgaWYgeW91IGhh ZCBhc2tlZCBmb3IgaXQgeWVhcnMgYWdvIHdoZW4gdGhlIHdvcmsgc3RhcnRlZCwgYnV0IGJldHRl ciBsYXRlIHRoYW4gbmV2ZXIgOiluDQo+SSBhcG9sb2dpemUgZm9yIG5vdCBzcGVuZGluZyB0aW1l IG9uIHRoaXMgZWFybGllci4gTGlmZSBnb3QgaW4gdGhlIHdheSA6LSkNCiAgDQpJIGtub3csIGFu ZCBJIGFwb2xvZ2l6ZSBpZiBJIHNvdW5kZWQgcnVkZS4gSXQncyBqdXN0IHRoaXMgZ2VuZXJpYyBm cnVzdHJhdGlvbiB0aGF0IGl0IHRha2VzIHNvIGxvbmcgdG8gZ2V0IGFueXRoaW5nIGRvbmUgaW4g SUVURiwgYnV0IGl0J3Mgb2YgY291cnNlIG5vdCB5b3VyIGZhdWx0IC0gdGhpcyBoYXMgdGFrZW4g dG9vIGxvbmcgbm8gbWF0dGVyIHdoYXQgOikNCg0KPj4gQW55d2F5LCBJIGRvbid0IHdhbnQgdG8g c3BlbmQgdGltZSBhcmd1aW5nIHdoZXRoZXIgaXQgc2hvdWxkIGJlIGluY2x1ZGVkOiBpZiBwZW9w bGUgd2FudCBpdCwgbGV0J3MgaW5jbHVkZSBpdC4NCj5JIGRvbuKAmXQgc2VlIGFueSByZWFzb24g dG8gdXNlIG9uZSBhdXRoIHNjaGVtZSBmb3IgYSBzcGVjaWZpYyBzaXAgbWV0aG9kLiBXaGF0IHdh cyB0aGUgdGhpbmtpbmcgYmVoaW5kIHRoYXQ/DQoNClBlb3BsZSByZXF1ZXN0ZWQgYSBzb2x1dGlv biBmb3IgZG9pbmcgU0lQIHJlZ2lzdHJhdGlvbiB1c2luZyBPQXV0aCwgc28gd2UgZG9jdW1lbnRl ZCB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3RlciANCg0K From nobody Thu Jul 11 00:30:38 2019 Return-Path: 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 555551201AA for ; Thu, 11 Jul 2019 00:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 e7MlRneXbm9Y for ; Thu, 11 Jul 2019 00:30:35 -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 56D6B120173 for ; Thu, 11 Jul 2019 00:30:35 -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 2B069A40; Thu, 11 Jul 2019 09:30:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 09:30:31 +0200 Cc: "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:30:37 -0000 > On 10 Jul 2019, at 17:26, Paul Kyzivat wrote: >=20 > On 7/9/19 1:45 PM, Christer Holmberg wrote: >=20 >> OAuth allows you to re-use the token as many times as you want (until = it expires) for the same service. So, for SIP, re-using the token in = binding refresh REGISTER requests is fine. >> But, you should not re-use a token you got for one "service" (e.g., = your registration authentication) with another "service" (e.g., = user-to-user authentication for a SIP call). It most likely wouldn't = even work. >=20 > Is the token somehow bound to the "registration service"? (Whatever = that is.) In Oauth2 there are two tokens - access token and refresh token. If you = add OpenID Connect, there=E2=80=99s an Identity token. Can we please be = more specific in our discussions?=20 >=20 > ISTM that the token is bound to the parameters from www-authenticate = were used in the process of obtaining the token. And so presumably the = token should be applicable to any other use that provokes a = www-authenticate with the same values of those parameters. >=20 > So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get = challenged the same way I would expect to use the same token for that. = And I might decide to preemptively use the same token in the SUBSCRIBE = if it is being sent to the same target. >=20 > Based on analogies to Digest, I would expect that after receiving a = Bearer challenge and fetching a matching token I would then add that = token to a key ring, indexed by some (which?) of the parameters from the = www-authenticate. And then in the future for new requests I would look = on the key ring for keys (credentials/tokens) suitable for use on this = request. (When doing this I might find either Digest or Bearer = credentials, or maybe both.) The tokens generally, but if I understand it right not always, are JWT = structures that contain various data. In OpenID connect both the access = and identity token are JWTs. We can either specify specific claims that are standardised for various = SIP functions or let that be open for the SIP implementors to specify or = a combination.=20 I would suggest that a generic specifier meaning =E2=80=9Cthis access = token is valid for SIP services=E2=80=9D would be a good thing.=20 As a service provider I would like to add authorizations like =E2=80=9Cthi= s user is authorized for calls to international destinations=E2=80=9D or = =E2=80=9Cthis user belongs to the support queue=E2=80=9D. /O= From nobody Thu Jul 11 00:40:31 2019 Return-Path: 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 2BAA112025D for ; Thu, 11 Jul 2019 00:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 7rFTO6NpFQaK for ; Thu, 11 Jul 2019 00:40:27 -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 5CBE61201AA for ; Thu, 11 Jul 2019 00:40:27 -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 14716A40; Thu, 11 Jul 2019 09:40:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 09:40:23 +0200 Cc: SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-sip-token-authnz-02 - www and/or proxy auth X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:40:29 -0000 > On 10 Jul 2019, at 17:39, Paul Kyzivat wrote: >=20 > Ollie, >=20 > On 7/10/19 9:21 AM, Olle E. Johansson wrote: >> Why was proxy auth deemed out of scope for this document? >=20 > Are you aware of any deployed uses of Proxy-Authenticate? I have never = heard of any. We do support it in both Asterisk and Kamailio. All my Kamailio = installations during the years use WWW auth for the registrar and proxy auth for calls. I do notice however that realm-based authentication with many challenges = in the same transaction is not widely supported, like your example below. >=20 > IMO Proxy-Authenticate is underspecified, at least for some obscure = cases. Consider: >=20 > - Alice sends a request > - It is challenged (Proxy-Authenticate) by P1 > - Alice resends with credentials for P1 > - P1 accepts credentials and forwards to P2 > - P2 challenges for a different realm > - For request to succeed, Alice will now have to > resend the request with credentials for both P1 & P2 >=20 > What logic should Alice use to decide what credentials to include in = requests to this target, both for the immediate resend, and in future = requests to the same target? Well, in Asterisk chan_sip I added realm-based authentication in order = to select credentials based on the realm. I don=E2=80=99t actually remember if we ever did run tests on this at = SIPit. Early SNOM phones had realm-based auth so you could enter credentials per realm and your example did work with those devices. >=20 > And another one: >=20 > - Alice sends a request > - It is challenged (Proxy-Authenticate) by P1 > - Alice resends with credentials for P1 > - P1 forks to P2A and P2B > - Both P2A and P2B challenge, with different realms >=20 >=20 > Now what happens? Ideally P1 would aggregate the www-authenticate from = both P2A and P2B. And then Alice would gather credentials for both and = include them both in a retry, along with the credentials for P1. None of = this is well defined. I think it=E2=80=99s defined, but not implemented or tested much. >=20 > I had suggested earlier that I wouldn't be too bent out of shape if = this draft left that out of scope. OTOH, I would prefer that this all be = well defined. Or else, if it isn't being used, then maybe = Proxy-Authenticate should be deprecated. That is not really =E2=80=9Cproxy auth=E2=80=9D - you mean = authentication in multiple realms in the same transaction. With Oauth2/OpenID connect that would be a very very complex scenario = with multiple login pages, unless we can come up with some=20 level of chain of trust between the proxys, forwarding the access token = or something else that likely will never be implemented=E2=80=A6 :-) I would suggest forwarding the token - possibly signed by the first = proxy - as a way forward, stating that all proxys in the service must be = in the same authentticaion federation. There is work witht OpenID Connect Federations that I haven=E2=80=99t = started to look at yet. Cheers, /O From nobody Thu Jul 11 00:45:27 2019 Return-Path: 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 ; 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 ; 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 ; 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" 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: Cc: Olle E Johansson , Rifaat Shekh-Yusef , "sipcore@ietf.org" To: Roman Shpount References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:45:26 -0000 --Apple-Mail=_AB1152BB-BA42-478F-A698-C226F67513B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2019, at 01:10, Roman Shpount wrote: >=20 > On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >=20 >=20 >> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>=20 >> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >> The document clearly allows the use of access token to authenticate = non-REGISTER requests when challenged in the context of the same realm. >>=20 >> 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? >>=20 > When the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the > server does with the connection when a token expires (if it=E2=80=99s = not already in the draft). >=20 >=20 > 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 --Apple-Mail=_AB1152BB-BA42-478F-A698-C226F67513B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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> wrote:


On 10 = Jul 2019, at 02:53, Roman Shpount <roman@telurix.com> wrote:

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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does = with the connection when a token expires (if it=E2=80=99s 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

= --Apple-Mail=_AB1152BB-BA42-478F-A698-C226F67513B8-- From nobody Thu Jul 11 00:49:26 2019 Return-Path: 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 4B98712025D for ; Thu, 11 Jul 2019 00:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0xQ6mW7RvJAq for ; Thu, 11 Jul 2019 00:49:22 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00066.outbound.protection.outlook.com [40.107.0.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01391201AA for ; Thu, 11 Jul 2019 00:49:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ef6Al+xN/Wppj0E+vwxPYZjYpP1L3eo2d9kq2rAjrBjDAdiFr3B0JM9l71xy9rWLttS6LtGPYzNyTASR8mT3xGseNi5cmZRkxuXfQbVc79lmcc2RTlPmlDz1BtPiWq/Kz8VKYIwoWlEXxjSLwHdaBEMGlRMg/B8BQ+ALS/7o2bhP4WV6HirvKTZ5RgUEOUzidXBOruGT4f0O6M7cf290DxdZxYQ1MeiBOMHguR3rpiFlbrZcM/vh1DzJJk9afevKEHrbwQg5LPT02vWhSYoCad4qelgxCftIKpz4iGYF90pKSJpvGc/nO+EpVFqChHhz7bVqkkTrqOh1+yWvtLlCWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CyrOlM3zjMjL6PzjaF6hyY93xO5T4qPh3Ehb0ECcc6Q=; b=VZReCigqHyxNbLtTDfz0N74r3pP4NA9TvJPoEvsqSNWc9zsz+wLbbdH1Qly6Cmww1d6tZOUCU89gxCfrTNAA15MoqBBihaj0094VY6rBWOvR3TGpQViQx/DeU/mb7zrMGAf6T+OuHjbg9AzDEmJaDIkMuCPYhXwJtwn+jj4H5Sk+ZcMALJxjNuwV7z/9gMsXef1Q1flbRNpjXHmzOOmUfooK/DIwZ1c3LSYdROmGSaRtRSGL4xILAE0+Mk63BYFQMhxJo9oiXFIM0P9wI3IkgBB277bPDviWBNxM0cREpNBqeVozFH6rEzrXRBtz4c7GIBTkWNDdLIwsSCWHOynHrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CyrOlM3zjMjL6PzjaF6hyY93xO5T4qPh3Ehb0ECcc6Q=; b=LakpO66BgdpZc8FwKNCZ3D6MCQvAx6S5IJDTDm+XG6deFnAWUWgBGUra3V0kdkd+tGYkKF+hj0xCpKXze968w6fJsBoJgoNHuCOMCFrdRnkOl2+n+U1tmywZ2VGIFL1KjM9zVBZ8/S/4mcYeoFneEcbG9PptPcEheIRdyUiReqY= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1SPR01MB01.eurprd07.prod.outlook.com (10.160.67.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.3; Thu, 11 Jul 2019 07:49:18 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 07:49:18 +0000 From: Christer Holmberg To: "Olle E. Johansson" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igA= Date: Thu, 11 Jul 2019 07:49:18 +0000 Message-ID: <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> In-Reply-To: <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e187884-b7fe-4dbb-35c2-08d705d4479f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1SPR01MB01; x-ms-traffictypediagnostic: HE1SPR01MB01: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(189003)(199004)(6486002)(66556008)(66446008)(229853002)(99286004)(476003)(7736002)(64756008)(305945005)(6116002)(44832011)(3846002)(76176011)(8676002)(14454004)(6436002)(446003)(76116006)(33656002)(25786009)(11346002)(5660300002)(66476007)(2616005)(478600001)(66946007)(4326008)(110136005)(71190400001)(71200400001)(86362001)(486006)(8936002)(66066001)(68736007)(36756003)(58126008)(256004)(14444005)(186003)(26005)(316002)(102836004)(53936002)(6512007)(81166006)(81156014)(6506007)(2171002)(6246003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR01MB01; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1AGFy/HbB2CvrXxPAgb3O6arC8nXbbb7KeTUOoKrOOAzDZCeKt/3dGKU2pq6SFl3xLhIDdIY20fXbHuCbvhTV+HDtmaPRsdvkowKZ/6+BEiOrcDpwKNpdwlcdxgPc/nMbYZ1zexOwIzHJPrdVFzF1q+r3JOQrW5iTGXFBfuWrQm5ESIsb6mUGGLPk0fovaCq7Wldd+hpacZfauPmb+cABMkXZMblgyh0++28LkI0U+VAlEm9FgPEJCZmRjChdSsMEsZsY3CzfwSzwThe0mu7cA4Ec7MPl37TyERaGFBwKaj3ixua2AJSnbRGBvIE6sP2rD0yEf9gfyfgO9TbIxyMvf5OLq0dQ/7GrUE+dTlg3uBas6+djU68G3sVIFtYIhlMYjqvjfrzVfsXfwIdnAeQ90K7eqliwKWqiJAo/lhFhSs= Content-Type: text/plain; charset="utf-8" Content-ID: <86C9D24286DE7F498C01C267D469E38C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e187884-b7fe-4dbb-35c2-08d705d4479f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 07:49:18.7687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1SPR01MB01 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:49:24 -0000 DQpIaSwNCiANCj4+PiBPQXV0aCBhbGxvd3MgeW91IHRvIHJlLXVzZSB0aGUgdG9rZW4gYXMgbWFu eSB0aW1lcyBhcyB5b3Ugd2FudCAodW50aWwgaXQgZXhwaXJlcykgZm9yIHRoZSBzYW1lIHNlcnZp Y2UuIFNvLCBmb3IgU0lQLCByZS11c2luZyANCj4+PiB0aGUgdG9rZW4gaW4gYmluZGluZyByZWZy ZXNoIFJFR0lTVEVSIHJlcXVlc3RzIGlzIGZpbmUuDQo+Pj4gQnV0LCB5b3Ugc2hvdWxkIG5vdCBy ZS11c2UgYSB0b2tlbiB5b3UgZ290IGZvciBvbmUgInNlcnZpY2UiIChlLmcuLCB5b3VyIHJlZ2lz dHJhdGlvbiBhdXRoZW50aWNhdGlvbikgd2l0aCBhbm90aGVyIA0KPj4+ICJzZXJ2aWNlIiAoZS5n LiwgdXNlci10by11c2VyIGF1dGhlbnRpY2F0aW9uIGZvciBhIFNJUCBjYWxsKS4gSXQgbW9zdCBs aWtlbHkgd291bGRuJ3QgZXZlbiB3b3JrLg0KPj4gDQo+PiBJcyB0aGUgdG9rZW4gc29tZWhvdyBi b3VuZCB0byB0aGUgInJlZ2lzdHJhdGlvbiBzZXJ2aWNlIj8gKFdoYXRldmVyIHRoYXQgaXMuKQ0K Pg0KPiBJbiBPYXV0aDIgdGhlcmUgYXJlIHR3byB0b2tlbnMgLSBhY2Nlc3MgdG9rZW4gYW5kIHJl ZnJlc2ggdG9rZW4uIElmIHlvdSBhZGQgT3BlbklEIENvbm5lY3QsIHRoZXJl4oCZcyBhbiBJZGVu dGl0eSB0b2tlbi4gQ2FuIHdlIHBsZWFzZSBiZSBtb3JlDQo+IHNwZWNpZmljIGluIG91ciBkaXNj dXNzaW9ucz8gDQoNCkdvb2QgcG9pbnQuIFdoZW4gSSBoYXZlIGJlZW4gdGFsa2luZyBhYm91dCB0 b2tlbnMsIEkgcmVmZXIgdG8gT2F1dGgyIHRva2Vucy4gUGVyaGFwcyB3ZSBzaG91bGQgYWx3YXlz IGluZGljYXRlIHRoYXQgZXhwbGljaXRseS4NCg0KLi4uDQoNCiA+IFRoZSB0b2tlbnMgZ2VuZXJh bGx5LCBidXQgaWYgSSB1bmRlcnN0YW5kIGl0IHJpZ2h0IG5vdCBhbHdheXMsIGFyZSBKV1Qgc3Ry dWN0dXJlcyB0aGF0IGNvbnRhaW4gdmFyaW91cyBkYXRhLiBJbiANCj4gT3BlbklEIGNvbm5lY3Qg Ym90aCB0aGUgYWNjZXNzIGFuZCBpZGVudGl0eSB0b2tlbiBhcmUgSldUcy4NCj4gV2UgY2FuIGVp dGhlciBzcGVjaWZ5IHNwZWNpZmljIGNsYWltcyB0aGF0ICBhcmUgc3RhbmRhcmRpc2VkIGZvciB2 YXJpb3VzIFNJUCBmdW5jdGlvbnMgb3IgbGV0IHRoYXQgYmUgb3BlbiBmb3IgDQo+IHRoZSBTSVAg aW1wbGVtZW50b3JzIHRvIHNwZWNpZnkgb3IgYSBjb21iaW5hdGlvbi4gDQogICANCkZvciBiYWNr d2FyZCBjb21wYXRpYmlsaXR5LCB3ZSBzaG91bGQgYXQgbGVhc3QgbGV0IFNJUCBpbXBsZW1lbnRv cnMgc3BlY2lmeS4NCg0KPiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCBhIGdlbmVyaWMgc3BlY2lmaWVy IG1lYW5pbmcg4oCcdGhpcyBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yIFNJUCBzZXJ2aWNlc+KA nSB3b3VsZCBiZSBhIGdvb2QgdGhpbmcuIA0KPiAgICANCj4gQXMgYSBzZXJ2aWNlIHByb3ZpZGVy IEkgd291bGQgbGlrZSB0byBhZGQgYXV0aG9yaXphdGlvbnMgbGlrZSDigJx0aGlzIHVzZXIgaXMg YXV0aG9yaXplZCBmb3IgY2FsbHMgdG8gaW50ZXJuYXRpb25hbCBkZXN0aW5hdGlvbnPigJ0gDQo+ IG9yIOKAnHRoaXMgdXNlciBiZWxvbmdzIHRvIHRoZSBzdXBwb3J0IHF1ZXVl4oCdLg0KICAgDQpT dWNoIGluZm9ybWF0aW9uIGNvdWxkIGFsc28gYmUgc3RvcmVkIGluIHRoZSB1c2VyIHByb2ZpbGUg aW4gdGhlIHJlZ2lzdHJhci4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KIA0KDQo= From nobody Thu Jul 11 01:12:54 2019 Return-Path: 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 86C95120122 for ; Thu, 11 Jul 2019 01:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QmZ_2V6ae2vn for ; Thu, 11 Jul 2019 01:12:51 -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 B6557120105 for ; Thu, 11 Jul 2019 01:12:50 -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 05EC7A40; Thu, 11 Jul 2019 10:12:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> Date: Thu, 11 Jul 2019 10:12:45 +0200 Cc: Olle E Johansson , Paul Kyzivat , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 08:12:54 -0000 > On 11 Jul 2019, at 09:49, Christer Holmberg = wrote: >=20 >=20 > Hi, >=20 >>>> OAuth allows you to re-use the token as many times as you want = (until it expires) for the same service. So, for SIP, re-using=20 >>>> the token in binding refresh REGISTER requests is fine. >>>> But, you should not re-use a token you got for one "service" (e.g., = your registration authentication) with another=20 >>>> "service" (e.g., user-to-user authentication for a SIP call). It = most likely wouldn't even work. >>>=20 >>> Is the token somehow bound to the "registration service"? (Whatever = that is.) >>=20 >> In Oauth2 there are two tokens - access token and refresh token. If = you add OpenID Connect, there=E2=80=99s an Identity token. Can we please = be more >> specific in our discussions?=20 >=20 > Good point. When I have been talking about tokens, I refer to Oauth2 = tokens. Perhaps we should always indicate that explicitly. Well, the document talks about both, but let=E2=80=99s name the specific = token. >=20 > ... >=20 >> The tokens generally, but if I understand it right not always, are = JWT structures that contain various data. In=20 >> OpenID connect both the access and identity token are JWTs. >> We can either specify specific claims that are standardised for = various SIP functions or let that be open for=20 >> the SIP implementors to specify or a combination.=20 >=20 > For backward compatibility, we should at least let SIP implementors = specify Maybe, but at least we should write something about the usage of claims = and scopes. I think a base level for this draft is specifying a way to say =E2=80=9Cth= is access token is valid for SIP usage=E2=80=9D or =E2=80=9Cthis is also a SIP identity" >=20 >> I would suggest that a generic specifier meaning =E2=80=9Cthis access = token is valid for SIP services=E2=80=9D would be a good thing.=20 >>=20 >> As a service provider I would like to add authorizations like =E2=80=9C= this user is authorized for calls to international destinations=E2=80=9D=20= >> or =E2=80=9Cthis user belongs to the support queue=E2=80=9D. >=20 > Such information could also be stored in the user profile in the = registrar. Absolutely. You either use your IDP only for authentication and handle = authorization elsewhere or trust the IDP for authorizations in SIP. That=E2=80=99s up to the implementor. /O= From nobody Thu Jul 11 02:29:21 2019 Return-Path: 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 3094E12019F for ; Thu, 11 Jul 2019 02:29:20 -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 QjvMGPbCOf09 for ; Thu, 11 Jul 2019 02:29:17 -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 F3CE91200D6 for ; Thu, 11 Jul 2019 02:29:16 -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 643C5A40; Thu, 11 Jul 2019 11:29:13 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D5417CB4-E5DE-43A2-942C-A851B5B8F11F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 11:29:12 +0200 In-Reply-To: <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> Cc: Olle E Johansson , "sipcore@ietf.org" To: Paul Kyzivat References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 09:29:20 -0000 --Apple-Mail=_D5417CB4-E5DE-43A2-942C-A851B5B8F11F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2019, at 09:30, Olle E. Johansson wrote: >=20 >=20 >=20 >> On 10 Jul 2019, at 17:26, Paul Kyzivat wrote: >>=20 >> On 7/9/19 1:45 PM, Christer Holmberg wrote: >>=20 >>> OAuth allows you to re-use the token as many times as you want = (until it expires) for the same service. So, for SIP, re-using the token = in binding refresh REGISTER requests is fine. >>> But, you should not re-use a token you got for one "service" (e.g., = your registration authentication) with another "service" (e.g., = user-to-user authentication for a SIP call). It most likely wouldn't = even work. >>=20 >> Is the token somehow bound to the "registration service"? (Whatever = that is.) > In Oauth2 there are two tokens - access token and refresh token. If = you add OpenID Connect, there=E2=80=99s an Identity token. Can we please = be more > specific in our discussions?=20 >=20 >=20 >>=20 >> ISTM that the token is bound to the parameters from www-authenticate = were used in the process of obtaining the token. And so presumably the = token should be applicable to any other use that provokes a = www-authenticate with the same values of those parameters. >>=20 >> So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get = challenged the same way I would expect to use the same token for that. = And I might decide to preemptively use the same token in the SUBSCRIBE = if it is being sent to the same target. >>=20 >> Based on analogies to Digest, I would expect that after receiving a = Bearer challenge and fetching a matching token I would then add that = token to a key ring, indexed by some (which?) of the parameters from the = www-authenticate. And then in the future for new requests I would look = on the key ring for keys (credentials/tokens) suitable for use on this = request. (When doing this I might find either Digest or Bearer = credentials, or maybe both.) >=20 > The tokens generally, but if I understand it right not always, are JWT = structures that contain various data. Found a draft that specifies an Oauth Access Token JWT profile https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00 = "The original OAuth 2.0 Authorization Framework [RFC6749 = ] specification does not mandate any specific format for access tokens. While that remains perfectly appropriate for many important scenario, in-market use has shown that many commercial OAuth2 implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement. The approach is particularly common in topologies where the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated by some boundary. All of the known commercial implementations known at this time leverage the JSON Web Tokens(JWT) [RFC7519 ] format. =E2=80=9C I think we can safely assume that an Access Token is going to be = parsable. /O > In OpenID connect both the access and identity token are JWTs. > We can either specify specific claims that are standardised for = various SIP functions or let that be open for the SIP implementors to = specify or a combination.=20 >=20 > I would suggest that a generic specifier meaning =E2=80=9Cthis access = token is valid for SIP services=E2=80=9D would be a good thing.=20 >=20 > As a service provider I would like to add authorizations like =E2=80=9Ct= his user is authorized for calls to international destinations=E2=80=9D = or =E2=80=9Cthis user belongs to the support queue=E2=80=9D. >=20 > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_D5417CB4-E5DE-43A2-942C-A851B5B8F11F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Jul 2019, at 09:30, Olle E. Johansson <oej@edvina.net> = wrote:



On 10 Jul 2019, at 17:26, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 7/9/19 1:45 PM, Christer Holmberg wrote:

OAuth allows you to = re-use the token as many times as you want (until it expires) for the = same service. So, for SIP, re-using the token in binding refresh = REGISTER requests is fine.
But, you should not re-use a = token you got for one "service" (e.g., your registration authentication) = with another "service" (e.g., user-to-user authentication for a SIP = call). It most likely wouldn't even work.

Is the token somehow bound to the "registration service"? = (Whatever that is.)
In Oauth2 there are two = tokens - access token and refresh token. If you add OpenID Connect, = there=E2=80=99s an Identity token. Can we please be more
specific in our discussions?



ISTM that = the token is bound to the parameters from www-authenticate were used in = the process of obtaining the token. And so presumably the token should = be applicable to any other use that provokes a www-authenticate with the = same values of those parameters.

So, if I = use a token in REGISTER, and then I do a SUBSCRIBE and get challenged = the same way I would expect to use the same token for that. And I might = decide to preemptively use the same token in the SUBSCRIBE if it is = being sent to the same target.

Based on = analogies to Digest, I would expect that after receiving a Bearer = challenge and fetching a matching token I would then add that token to a = key ring, indexed by some (which?) of the parameters from the = www-authenticate. And then in the future for new requests I would look = on the key ring for keys (credentials/tokens) suitable for use on this = request. (When doing this I might find either Digest or Bearer = credentials, or maybe both.)

The= tokens generally, but if I understand it right not always, are JWT = structures that contain various data.
Found = a draft that specifies an Oauth Access Token JWT profile

"The original OAuth 2.0 Authorization = Framework [RFC6749]
   specification does not =
mandate any specific format for access tokens.
   While that remains perfectly appropriate for many important scenario,
   in-market use has shown that many commercial OAuth2 implementations
   elected to issue access tokens using a format that can be parsed and
   validated by resource servers directly, without further authorization
   server involvement.  The approach is particularly common in
   topologies where the authorization server and resource server are not
   co-located, are not ran by the same entity, or are otherwise
   separated by some boundary.  All of the known commercial
   implementations known at this time leverage the JSON Web Tokens(JWT)
   [RFC7519] format.
=E2=80=9C

I think we can safely assume that an Access Token is going to = be parsable.

/O


In OpenID connect both the access and identity token are = JWTs.
We can either specify specific claims that  are = standardised for various SIP functions or let that be open for the SIP = implementors to specify or a combination.

I = would suggest that a generic specifier meaning =E2=80=9Cthis access = token is valid for SIP services=E2=80=9D would be a good thing.

As a service provider I would like to add = authorizations like =E2=80=9Cthis user is authorized for calls to = international destinations=E2=80=9D or =E2=80=9Cthis user belongs to the = support queue=E2=80=9D.

/O
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_D5417CB4-E5DE-43A2-942C-A851B5B8F11F-- From nobody Thu Jul 11 02:58:45 2019 Return-Path: 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 334F81202D6 for ; Thu, 11 Jul 2019 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 cLXIFozkNSyg for ; Thu, 11 Jul 2019 02:58:41 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30061.outbound.protection.outlook.com [40.107.3.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99191202D1 for ; Thu, 11 Jul 2019 02:58:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DLPdPS+4U6DiT26wgKxxSChGC9ZmP48+KF1UnXtmlhP1NDdNysstH3806w37jWiKr17Opa/wP4ULLs+GElPMX457rP+2BYq8r6yaTH17dtzFoB3BcNu482U8GJ5yKE/YFSBZ1smWQoRp6EwX/D9J5mcpaiZdkVqKzxCRb1I7xZ11ccDyLw5kwNHy8Y0faJKaUKpuq7smVMw5wDyrfjDlW2yovHX/57FyFFXsgq5Vaezwk54gYNQ6N/2kfEebXqKmPTimjmTDnyCOufrQ3CdzgDBM74LAVKmRrMhHuskHVcMqBPClnixZNpP2YWT+hISS/6XqEG17VkgoJhGh9bTBTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ELuhBJNNZnVZ7p/v8JUqkl4Mnp/XYR9+4ipqMh9KQ1I=; b=I5BkAH1e+KW+7Rch/HU7LJe/SEpO3z/D54GUJiWWrKkq5El/vTwZ2HHDu9SAkfQEvbXj5lsf7AElW6SIPfIfAPO8fHaqPzf6D8i2ioDMV3h4Bij2hebmqAXsWWPjNsoJ0jV6G0Tm6zzrkoP6RLfgXFxwTuHVN/DDp4iDWMtUB8tiHkYkj8e06lhLlk0F4AC6vikVFsmodB8tkYacCmlfvWvTQcddYDZLnotBKLEU9L1LxavEfeu+pB8ZidCB/PpmvGkRwqwqg98YdfD92LIXTYW0g5trY9SPpLQyG3kn9fZuUmSM1XomaIr5uaWsc/YSB1EHnJa2foryk8LFf+KxUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ELuhBJNNZnVZ7p/v8JUqkl4Mnp/XYR9+4ipqMh9KQ1I=; b=d5DSUAI0Cxkdp0kP6X7nLdB1Mqae7O8l7IKGKMLxHANtucemXfqVBOmljq+iarsR/Uw7fIOGRXFu1TBl6jZ/Y8PkjzxPJHfMayvKdCX7WQ9svcx876d36l+xh4dlM5TOPSTjoQToan4KSv/dDn/1oU+/viibK1xFmdEKFtWocbE= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3244.eurprd07.prod.outlook.com (10.170.246.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.5; Thu, 11 Jul 2019 09:58:38 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 09:58:38 +0000 From: Christer Holmberg To: "Olle E. Johansson" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAAhKQCAADqCgA== Date: Thu, 11 Jul 2019 09:58:37 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 133b4d97-c9ea-42e7-1f07-08d705e65898 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3244; x-ms-traffictypediagnostic: HE1PR07MB3244: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(189003)(199004)(71200400001)(58126008)(71190400001)(229853002)(110136005)(81166006)(6512007)(81156014)(33656002)(5660300002)(8936002)(8676002)(6486002)(66066001)(86362001)(2906002)(53936002)(256004)(14444005)(4326008)(476003)(2616005)(3846002)(76176011)(6116002)(102836004)(6246003)(2171002)(99286004)(66946007)(6436002)(6506007)(7736002)(68736007)(6306002)(36756003)(66446008)(64756008)(66476007)(66556008)(76116006)(44832011)(26005)(11346002)(446003)(14454004)(478600001)(305945005)(186003)(486006)(25786009)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3244; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VSZAAr91rBMKUJA9KMUx/EWOf+4Zf69ScZBJgw7iSBhUYUhleNLPduz7m2Fir6bJ75u38nMZ3Eu5Mgjv2l/mpHsXyUQTPpKXfu3uyujo3FORlC3HiOsZ/eB02eyrA4wXWQOMWYUMu0RTs1OCPDSrt3MeYApI8s4iSpYJ7MtzBOjsQB2iLhb/055L63XH1H+9Q+DxZSuNPqUKGvHmFEot3TjHqk2swFQxe2i4hOQoQEeBZ43y/Z4oldBgZszEUcE7OPTzAXqUzD4REnugqKdIugeBEsHhPSTkTKGyRxEnZSBSZdIzDzV7KSmIkN+tZ7wUAhPISCuWCi6NIQWYKRtzRDcrMnuyHL+D0MfElENennQ1VZngXV2u2tPtgZ4dbD0Q5IUN21fJPA+6iX6uAlKddii4pPcXVKEojh1X7A6jKlQ= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 133b4d97-c9ea-42e7-1f07-08d705e65898 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 09:58:38.1756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3244 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 09:58:44 -0000 SGksDQoNCj5UaGUgdG9rZW5zIGdlbmVyYWxseSwgYnV0IGlmIEkgdW5kZXJzdGFuZCBpdCByaWdo dCBub3QgYWx3YXlzLCBhcmUgSldUIHN0cnVjdHVyZXMgdGhhdCBjb250YWluIHZhcmlvdXMgZGF0 YS4NCj5Gb3VuZCBhIGRyYWZ0IHRoYXQgc3BlY2lmaWVzIGFuIE9hdXRoIEFjY2VzcyBUb2tlbiBK V1QgcHJvZmlsZQ0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRo LWFjY2Vzcy10b2tlbi1qd3QtMDANCj4NCj4iVGhlIG9yaWdpbmFsIE9BdXRoIDIuMCBBdXRob3Jp emF0aW9uIEZyYW1ld29yayBbaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDldDQo+ ICAgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIGFueSBzcGVjaWZpYyBmb3JtYXQgZm9y IGFjY2VzcyB0b2tlbnMuDQo+ICAgV2hpbGUgdGhhdCByZW1haW5zIHBlcmZlY3RseSBhcHByb3By aWF0ZSBmb3IgbWFueSBpbXBvcnRhbnQgc2NlbmFyaW8sDQo+ICAgaW4tbWFya2V0IHVzZSBoYXMg c2hvd24gdGhhdCBtYW55IGNvbW1lcmNpYWwgT0F1dGgyIGltcGxlbWVudGF0aW9ucw0KPiAgIGVs ZWN0ZWQgdG8gaXNzdWUgYWNjZXNzIHRva2VucyB1c2luZyBhIGZvcm1hdCB0aGF0IGNhbiBiZSBw YXJzZWQgYW5kDQo+ICAgdmFsaWRhdGVkIGJ5IHJlc291cmNlIHNlcnZlcnMgZGlyZWN0bHksIHdp dGhvdXQgZnVydGhlciBhdXRob3JpemF0aW9uDQo+ICAgc2VydmVyIGludm9sdmVtZW50LiAgVGhl IGFwcHJvYWNoIGlzIHBhcnRpY3VsYXJseSBjb21tb24gaW4NCj4gICB0b3BvbG9naWVzIHdoZXJl IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIGFyZSBub3QNCj4g ICBjby1sb2NhdGVkLCBhcmUgbm90IHJhbiBieSB0aGUgc2FtZSBlbnRpdHksIG9yIGFyZSBvdGhl cndpc2UNCj4gICBzZXBhcmF0ZWQgYnkgc29tZSBib3VuZGFyeS4gIEFsbCBvZiB0aGUga25vd24g Y29tbWVyY2lhbA0KPiAgIGltcGxlbWVudGF0aW9ucyBrbm93biBhdCB0aGlzIHRpbWUgbGV2ZXJh Z2UgdGhlIEpTT04gV2ViIFRva2VucyhKV1QpDQo+ICAgW2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3NTE5XSBmb3JtYXQuDQo+4oCcDQo+DQo+IEkgdGhpbmsgd2UgY2FuIHNhZmVseSBh c3N1bWUgdGhhdCBhbiBBY2Nlc3MgVG9rZW4gaXMgZ29pbmcgdG8gYmUgcGFyc2FibGUuDQoNClRo ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdhbnQgdG8gbWFuZGF0ZSBKV1QsIGV2ZW50aG91Z2gg dGhlIHN0YXRlbWVudCBhYm92ZSBwcm9iYWJseSBpcyBjb3JyZWN0Lg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0K From nobody Thu Jul 11 03:22:33 2019 Return-Path: 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 965261202D6 for ; Thu, 11 Jul 2019 03:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lj7LaQEXDiCK for ; Thu, 11 Jul 2019 03:22:30 -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 6AB0B1200D6 for ; Thu, 11 Jul 2019 03:22:30 -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 3BA52A40; Thu, 11 Jul 2019 12:22:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 12:22:25 +0200 Cc: Olle E Johansson , Paul Kyzivat , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 10:22:33 -0000 > On 11 Jul 2019, at 11:58, Christer Holmberg = wrote: >=20 > Hi, >=20 >> The tokens generally, but if I understand it right not always, are = JWT structures that contain various data. >> Found a draft that specifies an Oauth Access Token JWT profile >> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00 >>=20 >> "The original OAuth 2.0 Authorization Framework = [https://tools.ietf.org/html/rfc6749] >> specification does not mandate any specific format for access = tokens. >> While that remains perfectly appropriate for many important = scenario, >> in-market use has shown that many commercial OAuth2 implementations >> elected to issue access tokens using a format that can be parsed and >> validated by resource servers directly, without further = authorization >> server involvement. The approach is particularly common in >> topologies where the authorization server and resource server are = not >> co-located, are not ran by the same entity, or are otherwise >> separated by some boundary. All of the known commercial >> implementations known at this time leverage the JSON Web Tokens(JWT) >> [https://tools.ietf.org/html/rfc7519] format. >> =E2=80=9C >>=20 >> I think we can safely assume that an Access Token is going to be = parsable. >=20 > The question is whether we want to mandate JWT, eventhough the = statement above probably is correct. We may want to consult with the Oauth wg to see where they are heading = with this and if the break to backwards compatibility is considered hurtful. As of now, I don=E2=80=99= t find anything in our solution that requires any claim/scope. Regardless, we can suggest usage of scope and claims in our document. /O= From nobody Thu Jul 11 03:40:48 2019 Return-Path: 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 10CD412011E for ; Thu, 11 Jul 2019 03:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NqUVEWQ7uyc4 for ; Thu, 11 Jul 2019 03:40:43 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10075.outbound.protection.outlook.com [40.107.1.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DF731200E3 for ; Thu, 11 Jul 2019 03:40:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n7VB9W5yeUWtEA/y/OGCRW7A7hnFmvXKcotd22eMsueSigGbcyyAsE/d6ZQvreMzpkZ6cClhKkYscobOnrg2gEK8m1DkPeVkvS4szJH5WOLQgLwEAwJ0sCI10V5FTMMG9nV5eKTYswiAWbtEa0jGC5sa3geVWTgtdPf9cMrwYS4sMTuyDS/5nBfiv/vX98GS4k0Xk494gK9nVpxgwxf8m3tRSavLbxf4LZarOjyY3ZGQd8wnDeoiSXn5+XLR2b1OIMwrI5LdZINN6m3KC9/+P/H8QMgHt98UicCMHGq8T0xWlOjAQ+28/ISEzpFYnj2tamKFK9PtVEsbSn0lujo+Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v7HYHhx33DiEJVuHpUVJkzgwROpn2/BGgHZP9JgjaZ8=; b=E59+Sgo4LjnAddkW0R2CpUm0nylmuvTruTLLHA+3sNHe+JLrbQGohlumKiEwXzN0H76JLzJ+xQvYIAU41QLuAfTY/rV8B+Lu9Wr02nXI20PANN7eqSyXev8mYeZnmrMi2bQKOA2isZ+pGese84FcYKGPfp2J6Ub5tG0vLJfIOkLNhEUagalR+pVguHB/vLlZvM25Ze6kSPxa5zE7XgXbApYv31oHY31yfAQYeeuqbl0gT9ydvrXHZlTvc+e4s51s5TRLig0DUuUuW1bs7WcPyy10qrvi7rzhsRgR3a9YeRiMnsy1e8GxS69DFHmm2RxdzwmLVamIkx/vhI/4AL+XZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v7HYHhx33DiEJVuHpUVJkzgwROpn2/BGgHZP9JgjaZ8=; b=qB3T5aI/12s3GkL7+Y3d/qYxWSt2ttiUTXXbruu73vQ7BQEqlPx5C29H8QeMo7YsXzaiJ06lFARsWgIzCvuHp3HvyWmxVd03sC7nA2jJrO/k1gzLaq3xg5YjLddUEhph3S8TxwWC/Yc+CQVWbFH3vh6HNioNwbbEkkJ3pG7qXb8= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3420.eurprd07.prod.outlook.com (10.170.247.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.8; Thu, 11 Jul 2019 10:40:40 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 10:40:40 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA Date: Thu, 11 Jul 2019 10:40:40 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a577eea6-f209-494e-f6d9-08d705ec37fe x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3420; x-ms-traffictypediagnostic: HE1PR07MB3420: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(376002)(396003)(346002)(189003)(199004)(8936002)(81156014)(8676002)(81166006)(4744005)(66556008)(186003)(5660300002)(86362001)(478600001)(71190400001)(71200400001)(66476007)(33656002)(6436002)(6512007)(66446008)(76116006)(36756003)(54906003)(53936002)(58126008)(6246003)(66946007)(25786009)(64756008)(68736007)(2906002)(66066001)(26005)(99286004)(6916009)(44832011)(3846002)(6116002)(76176011)(6506007)(446003)(14454004)(2616005)(486006)(476003)(102836004)(14444005)(11346002)(305945005)(7736002)(316002)(6486002)(229853002)(256004)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3420; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: d6mobqu8wW/yLv0rEm+JjYQJSz+wJ9iBCUb7wH4RKpdDS/+aL9uZJ4P0roAyglpcsoGg7sCvZuFajwouxuBBvEByVgXvKxf2kRRTvYBhs1mO/a5/SA8PGgwtlngpXdodD8+mBw470VwIL6mRBBxfQcfxOCHi4EI3loeSmEJ90Ks2Fma78RUXMi9WXOtYlee/X+gDgQBKAQJX4gqUN/bT7dbul2vudk9Af5sI93R/ojQgYpRUdK+tanCabi3yQ35bBr++igsewMAhP6+P0b4uTRwLTDcEvHTOEaiLW6W+7gNjI6gbh7QQgaem2vVs4aZRbmobHucinkwbHtEeLdZQX47UbhV1tvoHPsRGR9ny0NnTaxKOFhi+rSRCAXhhPbjpwqFK/Lgzpqp2ZGk+uHiPriuHeq+Mnol+dm2ANT/vq3E= Content-Type: text/plain; charset="utf-8" Content-ID: <07484BEE77FDA04E854BC708F4EC483C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a577eea6-f209-494e-f6d9-08d705ec37fe X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 10:40:40.4032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3420 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 10:40:46 -0000 SGksDQoNCi4uLg0KIA0KICAgID4+PiBUaGUgdG9rZW5zIGdlbmVyYWxseSwgYnV0IGlmIEkgdW5k ZXJzdGFuZCBpdCByaWdodCBub3QgYWx3YXlzLCBhcmUgSldUIHN0cnVjdHVyZXMgdGhhdCBjb250 YWluIHZhcmlvdXMgZGF0YS4gSW4gDQogICAgPj4+IE9wZW5JRCBjb25uZWN0IGJvdGggdGhlIGFj Y2VzcyBhbmQgaWRlbnRpdHkgdG9rZW4gYXJlIEpXVHMuDQogICAgPj4+IFdlIGNhbiBlaXRoZXIg c3BlY2lmeSBzcGVjaWZpYyBjbGFpbXMgdGhhdCAgYXJlIHN0YW5kYXJkaXNlZCBmb3IgdmFyaW91 cyBTSVAgZnVuY3Rpb25zIG9yIGxldCB0aGF0IGJlIG9wZW4gZm9yIA0KICAgID4+PiB0aGUgU0lQ IGltcGxlbWVudG9ycyB0byBzcGVjaWZ5IG9yIGEgY29tYmluYXRpb24uIA0KICAgID4+IA0KICAg ID4+IEZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCB3ZSBzaG91bGQgYXQgbGVhc3QgbGV0IFNJ UCBpbXBsZW1lbnRvcnMgc3BlY2lmeQ0KICAgID4gTWF5YmUsIGJ1dCBhdCBsZWFzdCB3ZSBzaG91 bGQgd3JpdGUgc29tZXRoaW5nIGFib3V0IHRoZSB1c2FnZSBvZiBjbGFpbXMgYW5kIHNjb3Blcy4N CiAgICA+IEkgdGhpbmsgYSBiYXNlIGxldmVsIGZvciB0aGlzIGRyYWZ0IGlzIHNwZWNpZnlpbmcg YSB3YXkgdG8gc2F5IOKAnHRoaXMgYWNjZXNzIHRva2VuIGlzIHZhbGlkIGZvciBTSVAgdXNhZ2Xi gJ0gb3INCiAgICA+4oCcdGhpcyBpcyBhbHNvIGEgU0lQIGlkZW50aXR5Ig0KDQogICAgUGVyaGFw cyB3ZSBjYW4gYWRkIHNvbWUgdGV4dCBhYm91dCBzY29wZSBhbmQgY2xhaW1zLCBidXQgSSBkb24n dCB3YW50IHRvIG1hbmRhdGUgdXNhZ2Ugb2Ygc3BlY2lmaWMgdmFsdWVzLCBiZWNhdXNlIHRoYXQg bWF5IG5vdCBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRp b25zIHVzaW5nIEpXVC4gDQoNCiAgICBSZWdhcmRzLA0KDQogICAgQ2hyaXN0ZXINCg0KDQoNCg== From nobody Thu Jul 11 03:52:35 2019 Return-Path: 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 27213120299 for ; Thu, 11 Jul 2019 03:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2zA7XCP-WXgu for ; Thu, 11 Jul 2019 03:52:30 -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 96FB61202E6 for ; Thu, 11 Jul 2019 03:52:30 -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 E9141A40; Thu, 11 Jul 2019 12:52:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 12:52:25 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 10:52:33 -0000 > On 11 Jul 2019, at 12:40, Christer Holmberg = wrote: >=20 > Hi, >=20 > ... >=20 >>>> The tokens generally, but if I understand it right not always, are = JWT structures that contain various data. In=20 >>>> OpenID connect both the access and identity token are JWTs. >>>> We can either specify specific claims that are standardised for = various SIP functions or let that be open for=20 >>>> the SIP implementors to specify or a combination.=20 >>>=20 >>> For backward compatibility, we should at least let SIP implementors = specify >> Maybe, but at least we should write something about the usage of = claims and scopes. >> I think a base level for this draft is specifying a way to say = =E2=80=9Cthis access token is valid for SIP usage=E2=80=9D or >> =E2=80=9Cthis is also a SIP identity" >=20 > Perhaps we can add some text about scope and claims, but I don't = want to mandate usage of specific values, because that may not be = backward compatible with existing implementations using JWT.=20 We can mandate *if* the access token is a jwt (and there=E2=80=99s an = identity token like OpenID Connect).=20 I see interoperability problems if every implementation is using = different data structures for stuff like SIP AOR, SIP usage claim and = maybe a few more that we will come up with as we continue working. = Standardizing some of these basic data points in tokens will help = interoperability.=20 If the access token is a random blob we don=E2=80=99t require any = change. In addition I think we should change the =E2=80=9Csip.token=E2=80=9D = label to something more specific like =E2=80=9Csip.oauth2=E2=80=9D.=20 /O= From nobody Thu Jul 11 04:25:39 2019 Return-Path: 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 8E02B12011A for ; Thu, 11 Jul 2019 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 YKEp2ltUbOiK for ; Thu, 11 Jul 2019 04:25:35 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140040.outbound.protection.outlook.com [40.107.14.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9818120099 for ; Thu, 11 Jul 2019 04:25:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nDEuwx9TYIJu6Qmozi2UGnz9zXn2H6fhuy0eerzQ8cNvczc8Bw0Z+58WdRoQfeuRQn3vunlX7freGxLLWffQZ/u8+dxl8Oqchxb+q+urBJU2/V//8qfo0l8cvm0ZgDoFbi2ihaqVdcZhRw3DuR8HLg3wNcebgcHcxKAwPQg1PQw/I9a2Yq5iwTDM2vgwcyLu6jIGGAMc/hU8fmYgnqWy4PWRqiTDzWEab5jcXRbWdsP4H5CqU9RLhd+H706vC3RFP6sPPY0NBl3xk1Ju7ZlAIhElTykVozoIHYYFdNyRjfFNrNC4nrplxhVSoPoDDF6nS/5Q4SX5z42rEpqX35ak0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l0N+7g7M4fkqskf/l3joC2pVj/BN+zByF8+XL910HDQ=; b=nq6gEKghRjDqAq0zmmwINqBwYZUEBZ3HRolMDAKy8wxglWai8MmI0geLmqPm3skOzW6HTptkoa11sq0jdatoSYE6TMaJYf87NMJG6zH52jpfxnXXUV4ZwkYxwbei9XukwGnq+hogz98aB1VMS22qP6GK4tN+d9DTZDwWvcKY+Hl10vMM0/qEc6tQgjTUu6Cuesajjfm1SerLaDPfwov9t1S7TdKrG1e83HW68I6ukTuuQ6tYfi/hPYcPHBNyKsc8+pmrHG4eUxwZISYIuao2dVAmrqj7qJylz/Iuw03YMfZZKFAQLW6UCfucnlqO6FiqhzNm/jY+DS4tP3PXxgqYYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l0N+7g7M4fkqskf/l3joC2pVj/BN+zByF8+XL910HDQ=; b=nZiDnq8J7YVBZEfRawWlw1UTpRwKshFXql+a4Pw+cK5rDMgG4h2Ox/ojZIcB1rt1iO8m06wbxZ89LJksZb08Q7u9la/+EtU4MrH6rVgE3DZtnTycHH1bVYZ2hS6XDpP1hBJ0nuGYzPju0UdN27drpUUkUOeF6f4RGVON2MzRaX4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4393.eurprd07.prod.outlook.com (20.176.167.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.8; Thu, 11 Jul 2019 11:25:32 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 11:25:32 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAA== Date: Thu, 11 Jul 2019 11:25:31 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b2ca1d1-395c-4d61-ac18-08d705f27c38 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4393; x-ms-traffictypediagnostic: HE1PR07MB4393: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(199004)(189003)(66066001)(6436002)(102836004)(229853002)(14454004)(8936002)(81166006)(71190400001)(26005)(186003)(6512007)(6506007)(71200400001)(3846002)(6116002)(316002)(58126008)(6486002)(486006)(2616005)(14444005)(478600001)(99286004)(256004)(8676002)(305945005)(33656002)(66476007)(66556008)(64756008)(66446008)(476003)(36756003)(7736002)(76176011)(53936002)(25786009)(86362001)(6916009)(4326008)(68736007)(446003)(2906002)(11346002)(44832011)(5660300002)(6246003)(76116006)(81156014)(66946007)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4393; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gR3+AV+wSiur2ah/Jyk8JAlb30yMRPOfsb3mTD19npVeOrQwyoHx3joQZxGul+V8z9hGj6+zGEaajRO0W+R3gNQmRqk2w+QHNjlhXr5mcFYgyBe2oLLWxkELtHH0elFiUqKwYZhN1CIocU2U2jtElpWuRwgHVKqGpUNSaKQm/hGU9MHQ69NZ0GELVe+7J4RvNUQ30gKRORH5Chf8G4x4BU9dGoF7vCuE89Lf2CVsPxCGNFnSvscAQTeHI9luMVl20ReH5/1M4y50GDtDX0grmYscfxGHp1vAZd+KyykyDy6qXzWmxxH1r/jIGSFCd2ZMIUgOjb8tyq3uIyasUjsfOjtnj9ls0qd2ABY7aoslTQoPMyvnPKuPsqwv/jzueLgawu+xJbGvYTr+3HRzq/WnCP6eIJOUK35BaH61xJEihT0= Content-Type: text/plain; charset="utf-8" Content-ID: <80CF8AFA909A884495FD5EF1C83EE786@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b2ca1d1-395c-4d61-ac18-08d705f27c38 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 11:25:31.8609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4393 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 11:25:38 -0000 SGksDQoNCiAgICA+Pj4+PiBUaGUgdG9rZW5zIGdlbmVyYWxseSwgYnV0IGlmIEkgdW5kZXJzdGFu ZCBpdCByaWdodCBub3QgYWx3YXlzLCBhcmUgSldUIHN0cnVjdHVyZXMgdGhhdCBjb250YWluIHZh cmlvdXMgZGF0YS4gSW4gDQogICAgPj4+Pj4gT3BlbklEIGNvbm5lY3QgYm90aCB0aGUgYWNjZXNz IGFuZCBpZGVudGl0eSB0b2tlbiBhcmUgSldUcy4NCiAgICA+Pj4+PiBXZSBjYW4gZWl0aGVyIHNw ZWNpZnkgc3BlY2lmaWMgY2xhaW1zIHRoYXQgIGFyZSBzdGFuZGFyZGlzZWQgZm9yIHZhcmlvdXMg U0lQIGZ1bmN0aW9ucyBvciBsZXQgdGhhdCBiZSBvcGVuIGZvciANCiAgICA+Pj4+PiB0aGUgU0lQ IGltcGxlbWVudG9ycyB0byBzcGVjaWZ5IG9yIGEgY29tYmluYXRpb24uIA0KICAgID4+Pj4gDQog ICAgPj4+PiBGb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgd2Ugc2hvdWxkIGF0IGxlYXN0IGxl dCBTSVAgaW1wbGVtZW50b3JzIHNwZWNpZnkNCiAgICA+Pj4gTWF5YmUsIGJ1dCBhdCBsZWFzdCB3 ZSBzaG91bGQgd3JpdGUgc29tZXRoaW5nIGFib3V0IHRoZSB1c2FnZSBvZiBjbGFpbXMgYW5kIHNj b3Blcy4NCiAgICA+Pj4gSSB0aGluayBhIGJhc2UgbGV2ZWwgZm9yIHRoaXMgZHJhZnQgaXMgc3Bl Y2lmeWluZyBhIHdheSB0byBzYXkg4oCcdGhpcyBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQgZm9yIFNJ UCB1c2FnZeKAnSBvcg0KICAgID4+PiDigJx0aGlzIGlzIGFsc28gYSBTSVAgaWRlbnRpdHkiDQog ICAgPj4gDQogICAgPj4gICAgUGVyaGFwcyB3ZSBjYW4gYWRkIHNvbWUgdGV4dCBhYm91dCBzY29w ZSBhbmQgY2xhaW1zLCBidXQgSSBkb24ndCB3YW50IHRvIG1hbmRhdGUgdXNhZ2Ugb2Ygc3BlY2lm aWMgdmFsdWVzLCBiZWNhdXNlIHRoYXQgDQogICAgPj4gICAgbWF5IG5vdCBiZSBiYWNrd2FyZCBj b21wYXRpYmxlIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHVzaW5nIEpXVC4gDQogICAg Pg0KICAgID4gV2UgY2FuIG1hbmRhdGUgKmlmKiB0aGUgYWNjZXNzIHRva2VuIGlzIGEgand0IChh bmQgdGhlcmXigJlzIGFuIGlkZW50aXR5IHRva2VuIGxpa2UgT3BlbklEIENvbm5lY3QpLiANCiAg ICANCiAgICBJdCBtYXkgbm90IHdvcmsgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdGhh dCBETyB1c2UgSldUIGFjY2VzcyB0b2tlbnMgKG5vdCBzdXJlIHdoZXRoZXIgdGhleSB1c2UgT3Bl bklEIENvbm5lY3QsIHRob3VnaCkuDQoNCiAgICA+PiBJIHNlZSBpbnRlcm9wZXJhYmlsaXR5IHBy b2JsZW1zIGlmIGV2ZXJ5IGltcGxlbWVudGF0aW9uIGlzIHVzaW5nIGRpZmZlcmVudCBkYXRhIHN0 cnVjdHVyZXMgZm9yIHN0dWZmIGxpa2UgU0lQIEFPUiwgU0lQIHVzYWdlIGNsYWltIA0KICAgID4+ IGFuZCBtYXliZSBhIGZldyBtb3JlIHRoYXQgd2Ugd2lsbCBjb21lIHVwIHdpdGggYXMgd2UgY29u dGludWUgd29ya2luZy4gU3RhbmRhcmRpemluZyBzb21lIG9mIHRoZXNlIGJhc2ljIGRhdGEgcG9p bnRzIGluIHRva2VucyB3aWxsIGhlbHAgaW50ZXJvcGVyYWJpbGl0eS4gDQogICAgPg0KICAgID4g SWYgdGhlIGFjY2VzcyB0b2tlbiBpcyBhIHJhbmRvbSBibG9iIHdlIGRvbuKAmXQgcmVxdWlyZSBh bnkgY2hhbmdlLg0KICAgID4NCiAgICA+IEluIGFkZGl0aW9uIEkgdGhpbmsgd2Ugc2hvdWxkIGNo YW5nZSB0aGUg4oCcc2lwLnRva2Vu4oCdIGxhYmVsIHRvIHNvbWV0aGluZyBtb3JlIHNwZWNpZmlj IGxpa2Ug4oCcc2lwLm9hdXRoMuKAnS4gDQogICAgDQogICAgSSB0aGluayBpdCB3YXMgbWUgd2hv IHN1Z2dlc3RlZCB0byB1c2Ugc2lwLnRva2VuLCBidXQgSSBkb24ndCBoYXZlIGEgc3Ryb25nIG9w aW5pb24gYWJvdXQgaXQuIEl0IHdhcyBhZGRlZCByZWNlbnRseSwgc28gZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zIGN1cnJlbnRseSBkb24ndCB1c2UgaXQgYW55d2F5Lg0KIA0KICAgIFJlZ2FyZHMs DQoNCiAgICBDaHJpc3Rlcg0KDQoNCg0K From nobody Thu Jul 11 04:49:22 2019 Return-Path: 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 3DB4512011A for ; Thu, 11 Jul 2019 04:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fYOqjEbp7ibG for ; Thu, 11 Jul 2019 04:49:18 -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 BD2AF120045 for ; Thu, 11 Jul 2019 04:49:16 -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 B1502A40; Thu, 11 Jul 2019 13:49:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 13:49:12 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 11:49:20 -0000 > On 11 Jul 2019, at 13:25, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>> The tokens generally, but if I understand it right not always, = are JWT structures that contain various data. In=20 >>>>>> OpenID connect both the access and identity token are JWTs. >>>>>> We can either specify specific claims that are standardised for = various SIP functions or let that be open for=20 >>>>>> the SIP implementors to specify or a combination.=20 >>>>>=20 >>>>> For backward compatibility, we should at least let SIP = implementors specify >>>> Maybe, but at least we should write something about the usage of = claims and scopes. >>>> I think a base level for this draft is specifying a way to say = =E2=80=9Cthis access token is valid for SIP usage=E2=80=9D or >>>> =E2=80=9Cthis is also a SIP identity" >>>=20 >>> Perhaps we can add some text about scope and claims, but I don't = want to mandate usage of specific values, because that=20 >>> may not be backward compatible with existing implementations using = JWT.=20 >>=20 >> We can mandate *if* the access token is a jwt (and there=E2=80=99s an = identity token like OpenID Connect).=20 >=20 > It may not work with existing implementations that DO use JWT = access tokens (not sure whether they use OpenID Connect, though). Ok, you are making me interested - what are these implementations? When writing a new standard document, should we really be blocked by = pre-standard implementations? I would assume that we should be inspired by them, learn by their experiences, but not be = hindered by them.=20 >=20 >>> I see interoperability problems if every implementation is using = different data structures for stuff like SIP AOR, SIP usage claim=20 >>> and maybe a few more that we will come up with as we continue = working. Standardizing some of these basic data points in tokens will = help interoperability.=20 >>=20 >> If the access token is a random blob we don=E2=80=99t require any = change. >>=20 >> In addition I think we should change the =E2=80=9Csip.token=E2=80=9D = label to something more specific like =E2=80=9Csip.oauth2=E2=80=9D.=20 >=20 > I think it was me who suggested to use sip.token, but I don't have = a strong opinion about it. It was added recently, so existing = implementations currently don't use it anyway. We have already been confused by discussions about =E2=80=9Cthe token=E2=80= =9D when in fact there are multiple tokens=E2=80=A6 /O= From nobody Thu Jul 11 05:07:27 2019 Return-Path: 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 0BBC3120108 for ; Thu, 11 Jul 2019 05:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zkj_oK5iTAZH for ; Thu, 11 Jul 2019 05:07:22 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00053.outbound.protection.outlook.com [40.107.0.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E161A1200F5 for ; Thu, 11 Jul 2019 05:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vXorJp2jVCTU+hQwYoWFUdyS0uPxPg7yH+TcmFwecCw=; b=biQrn7he9lxEF2GZdur5Wh/SxBIADQ+tD05roJlTabP9Q2GmN9jkrjSxiLyd7gNsVjeArGq7oA/pkIDhtG9nmqviQPiFK5RbMXXf8PyKJDDBuEeYMph4AvKeV9mBcB1gJWci6P1qbguZ7PG1mFn3qeUlbHo9tlyjed0Othwgvuw= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3177.eurprd07.prod.outlook.com (10.170.245.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.12; Thu, 11 Jul 2019 12:07:19 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 12:07:18 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAA3WQA= Date: Thu, 11 Jul 2019 12:07:18 +0000 Message-ID: <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> In-Reply-To: <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ad8390d4-7355-47a7-a4dd-08d705f85276 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3177; x-ms-traffictypediagnostic: HE1PR07MB3177: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(396003)(376002)(346002)(189003)(199004)(6486002)(58126008)(66446008)(53936002)(14444005)(6246003)(66946007)(66556008)(71200400001)(66476007)(6512007)(8936002)(71190400001)(6436002)(316002)(25786009)(256004)(64756008)(81156014)(76116006)(446003)(2616005)(81166006)(11346002)(6916009)(6116002)(26005)(7736002)(3846002)(5660300002)(305945005)(2906002)(86362001)(68736007)(476003)(8676002)(66066001)(102836004)(229853002)(44832011)(4326008)(486006)(76176011)(33656002)(36756003)(6506007)(99286004)(14454004)(478600001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3177; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: NCPkSHGYL5Azj3UlFXb/CPA0xZA0NiI3OSZKe4MnrBdvSMAqpXM4AjzYX0tw+Bcvn9IN3oI9oRugSVY0NDRe5mGGEsE2++ywEZMwG9Bi1TCzx7FkI+Tsf0mIpNrG244ddSWTfPAgLKg5HUAInluCvAXW4LZM7HzPqaKpTrUm7GBSuQ1ISTxC2jCrxpaGAueIG6wl4jvictY6xri0q1Xg6vmkbLJG5vlzT+dtnM1uD1s91qwCE4qwmi5M0hZau51QaSGNDytJuXN43kSgksleOm/K0cxthn5bsO3j2sFn21Dr8Zrq7B8mZ4hLXEyg2JjASc2H8ec9mxFIEZqcazG0vsmiiRrGcQUPLRi8KLv2cu9Ami1V76fPvy69e+WNnL6wtUKe9mgENpoux8Bs47GHdSW0Q6VH7hqMiMQQbdKkyno= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad8390d4-7355-47a7-a4dd-08d705f85276 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 12:07:18.7961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3177 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 12:07:25 -0000 SGksDQoNCiAgICA+Pj4+Pj4+IFRoZSB0b2tlbnMgZ2VuZXJhbGx5LCBidXQgaWYgSSB1bmRlcnN0 YW5kIGl0IHJpZ2h0IG5vdCBhbHdheXMsIGFyZSBKV1Qgc3RydWN0dXJlcyB0aGF0IGNvbnRhaW4g dmFyaW91cyBkYXRhLiBJbiANCiAgICA+Pj4+Pj4+IE9wZW5JRCBjb25uZWN0IGJvdGggdGhlIGFj Y2VzcyBhbmQgaWRlbnRpdHkgdG9rZW4gYXJlIEpXVHMuDQogICAgPj4+Pj4+PiBXZSBjYW4gZWl0 aGVyIHNwZWNpZnkgc3BlY2lmaWMgY2xhaW1zIHRoYXQgIGFyZSBzdGFuZGFyZGlzZWQgZm9yIHZh cmlvdXMgU0lQIGZ1bmN0aW9ucyBvciBsZXQgdGhhdCBiZSBvcGVuIGZvciANCiAgICA+Pj4+Pj4+ IHRoZSBTSVAgaW1wbGVtZW50b3JzIHRvIHNwZWNpZnkgb3IgYSBjb21iaW5hdGlvbi4gDQogICAg Pj4+Pj4+IA0KICAgID4+Pj4+PiBGb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgd2Ugc2hvdWxk IGF0IGxlYXN0IGxldCBTSVAgaW1wbGVtZW50b3JzIHNwZWNpZnkNCiAgICA+Pj4+PiBNYXliZSwg YnV0IGF0IGxlYXN0IHdlIHNob3VsZCB3cml0ZSBzb21ldGhpbmcgYWJvdXQgdGhlIHVzYWdlIG9m IGNsYWltcyBhbmQgc2NvcGVzLg0KICAgID4+Pj4+IEkgdGhpbmsgYSBiYXNlIGxldmVsIGZvciB0 aGlzIGRyYWZ0IGlzIHNwZWNpZnlpbmcgYSB3YXkgdG8gc2F5IOKAnHRoaXMgYWNjZXNzIHRva2Vu IGlzIHZhbGlkIGZvciBTSVAgdXNhZ2XigJ0gb3INCiAgICA+Pj4+PiDigJx0aGlzIGlzIGFsc28g YSBTSVAgaWRlbnRpdHkiDQogICAgPj4+PiANCiAgICA+Pj4+ICAgUGVyaGFwcyB3ZSBjYW4gYWRk IHNvbWUgdGV4dCBhYm91dCBzY29wZSBhbmQgY2xhaW1zLCBidXQgSSBkb24ndCB3YW50IHRvIG1h bmRhdGUgdXNhZ2Ugb2Ygc3BlY2lmaWMgdmFsdWVzLCBiZWNhdXNlIHRoYXQgDQogICAgPj4+PiAg IG1heSBub3QgYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0 aW9ucyB1c2luZyBKV1QuIA0KICAgID4+PiANCiAgICA+Pj4gV2UgY2FuIG1hbmRhdGUgKmlmKiB0 aGUgYWNjZXNzIHRva2VuIGlzIGEgand0IChhbmQgdGhlcmXigJlzIGFuIGlkZW50aXR5IHRva2Vu IGxpa2UgT3BlbklEIENvbm5lY3QpLiANCiAgICA+PiANCiAgICA+PiAgICBJdCBtYXkgbm90IHdv cmsgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBETyB1c2UgSldUIGFjY2VzcyB0 b2tlbnMgKG5vdCBzdXJlIHdoZXRoZXIgdGhleSB1c2UgT3BlbklEIENvbm5lY3QsIHRob3VnaCku DQogICAgPg0KICAgID4gT2ssIHlvdSBhcmUgbWFraW5nIG1lIGludGVyZXN0ZWQgLSB3aGF0IGFy ZSB0aGVzZSBpbXBsZW1lbnRhdGlvbnM/DQogICAgDQogICBVbmZvcnR1bmF0ZWx5IEkgYW0gbm90 IGFibGUgdG8gZ2l2ZSBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhhdC4NCg0KICAgID5XaGVuIHdy aXRpbmcgYSBuZXcgc3RhbmRhcmQgZG9jdW1lbnQsIHNob3VsZCB3ZSByZWFsbHkgYmUgYmxvY2tl ZCBieSBwcmUtc3RhbmRhcmQgaW1wbGVtZW50YXRpb25zPyBJIHdvdWxkIGFzc3VtZSB0aGF0IHdl DQogICAgPnNob3VsZCBiZSBpbnNwaXJlZCBieSB0aGVtLCBsZWFybiBieSB0aGVpciBleHBlcmll bmNlcywgYnV0IG5vdCBiZSBoaW5kZXJlZCBieSB0aGVtLiANCiAgICANCiAgICBUaGUgaW1wbGVt ZW50YXRpb25zIGFyZSBiYXNlZCBvbiBlYXJsaWVyIHZlcnNpb25zIG9mIHRoZSBkcmFmdC4NCg0K ICAgIEFuZCwgeWVzLCB0aGVyZSBpcyB0aGUgb2xkIHNheWluZyB0aGF0IG9uZSBzaG91bGQgbm90 IGRlcGxveSBhIGRyYWZ0IGJlZm9yZSB0aGUgZHJhZnQgYmVjb21lcyBSRkMuIA0KDQogICAgQnV0 LCBpbiB0aGlzIGNhc2UsIHRoZSBmaXJzdCB2ZXJzaW9uIG9mIFJpZmFhdCdzIGluZGl2aWR1YWwg ZHJhZnQgd2FzIHN1Ym1pdHRlZCBpbiAyMDE0LiBUaGVuLCBmb3Igd2hhdGV2ZXIgcmVhc29uLCBp dCB0b29rIDMoISkgeWVhcnMgYmVmb3JlIGl0IGdvdCBhZG9wdGVkLCBhbmQgYWZ0ZXIgdGhhdCB3 ZSBoYXZlIHNvIGZhciB3b3JrZWQgb24gaXQgZm9yIHR3byB5ZWFycy4gSG93IGxvbmcgaXMgb25l IGV4cGVjdGVkIHRvIHdhaXQgZm9yIGFuIFJGQyBiZWZvcmUgZGVwbG95aW5nPz8/DQoNCiAgICAg T2YgY291cnNlLCBpZiBzb21ldGhpbmcgaXMgYnJva2VuIHdlIG5lZWQgdG8gZml4IGl0LiBCdXQs IEkgZG9uJ3QgdGhpbmsgd2hhdCB5b3Ugc3VnZ2VzdCBpcyBmaXhpbmcgc29tZXRoaW5nIHRoYXQg aXMgYnJva2VuLCBpdCBpcyBhZGRpbmcgbmV3IGZ1bmN0aW9uYWxpdHkuIEFuZCwgSSBoYXZlIG5v IHByb2JsZW0gd2l0aCB0aGF0LCBhcyBsb25nIGFzIGl0IGlzIGJhY2t3YXJkIGNvbXBhdGlibGUu DQoNCiAgICBSZWdhcmRzLA0KDQogICAgQ2hyaXN0ZXINCg0KDQoNCg== From nobody Thu Jul 11 05:10:51 2019 Return-Path: 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 4E496120045 for ; Thu, 11 Jul 2019 05:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AHqf8I0LPXdG for ; Thu, 11 Jul 2019 05:10: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 8BEC91200C1 for ; Thu, 11 Jul 2019 05:10:46 -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 CD8CDA40; Thu, 11 Jul 2019 14:10:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> Date: Thu, 11 Jul 2019 14:10:42 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 12:10:50 -0000 > On 11 Jul 2019, at 14:07, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>>> The tokens generally, but if I understand it right not always, = are JWT structures that contain various data. In=20 >>>>>>>> OpenID connect both the access and identity token are JWTs. >>>>>>>> We can either specify specific claims that are standardised = for various SIP functions or let that be open for=20 >>>>>>>> the SIP implementors to specify or a combination.=20 >>>>>>>=20 >>>>>>> For backward compatibility, we should at least let SIP = implementors specify >>>>>> Maybe, but at least we should write something about the usage of = claims and scopes. >>>>>> I think a base level for this draft is specifying a way to say = =E2=80=9Cthis access token is valid for SIP usage=E2=80=9D or >>>>>> =E2=80=9Cthis is also a SIP identity" >>>>>=20 >>>>> Perhaps we can add some text about scope and claims, but I don't = want to mandate usage of specific values, because that=20 >>>>> may not be backward compatible with existing implementations = using JWT.=20 >>>>=20 >>>> We can mandate *if* the access token is a jwt (and there=E2=80=99s = an identity token like OpenID Connect).=20 >>>=20 >>> It may not work with existing implementations that DO use JWT = access tokens (not sure whether they use OpenID Connect, though). >>=20 >> Ok, you are making me interested - what are these implementations? >=20 > Unfortunately I am not able to give information regarding that. >=20 >> When writing a new standard document, should we really be blocked by = pre-standard implementations? I would assume that we >> should be inspired by them, learn by their experiences, but not be = hindered by them.=20 >=20 > The implementations are based on earlier versions of the draft. >=20 > And, yes, there is the old saying that one should not deploy a = draft before the draft becomes RFC.=20 >=20 > But, in this case, the first version of Rifaat's individual draft = was submitted in 2014. Then, for whatever reason, it took 3(!) years = before it got adopted, and after that we have so far worked on it for = two years. How long is one expected to wait for an RFC before = deploying??? >=20 > Of course, if something is broken we need to fix it. But, I don't = think what you suggest is fixing something that is broken, it is adding = new functionality. And, I have no problem with that, as long as it is = backward compatible. I do understand the pain, but I have severe problems of having to adopt = to an unknown implemenetation of an early document that wasn=E2=80=99t = pushed forward. If you had the resources to do development, why didn=E2=80= =99t you spend time pushing the draft forward? 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. = Would it really hurt if a working app was not standard-compliant? /O From nobody Thu Jul 11 05:58:23 2019 Return-Path: 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 124631200E7 for ; Thu, 11 Jul 2019 05:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 i31ot2eyBc_W for ; Thu, 11 Jul 2019 05:58:19 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40051.outbound.protection.outlook.com [40.107.4.51]) (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 7A0A51200A3 for ; Thu, 11 Jul 2019 05:58:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kEAtTziNsLMrpMAk38vO4kuigu8a3aXXIQbsLYYk7DK7igTm5UbQOojEXPyKMIDVaGmi9zDqsDeDvQpGpPHLfBC+fcqedvcN6kfrlM84B2eWzicT6dVec9L1V+rwaXp4ul4EJmB4xFculkSOoMxWAk6sk17CuQS9DLfMrKtUf7JHYNUAJZCq/W5l9pl9xHrIppwCfe0yyNG2ZeS9T7sx+HMfaLVywP18vYPjcOzPrGF36+uscUGNh4EVkjZfnL1U0CmqdQIYaduszwVMPJGqo/t+/s2/Lo/IN/Gxw1HPSDcfKmx2sZ815szi6af7Je8F7BTW2Lr9hmNLTYfICWKv1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f6Gzk30HbAiE7DXN3Um07s3n0cphskXuJxjWoc/ABm4=; b=MXSLXJlbwicCvyNp2KuU3h/csZA9xjNioi1WK6gaWJm8kId6wj488WDpnW7gIHOOSF7D3QRc67pBGpML/fTHxsI1+uuKZF1ZG5X5vY7iq3Z8EbQgz1EsrtSXijtsz6F7SrocWunTCAan11E0f3Vg+VB7R0rVlg5j1My80zHmo4AMdeBrDSKVRvwp4RBdSULppSg3T/ZmJhwk2d/QYQhD7WvNzjl6Whcxwb26mw9nXPYnwSPdaNHxWDdmXEfE56b+gH6s8OGk/rV4zPg4LKSXpFmA8YrPR4Y5mOcCzA1NyR5KFFZrY/8JGnra2eLZo0Wjo/r18gXRR56aYFE1s7x6JQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f6Gzk30HbAiE7DXN3Um07s3n0cphskXuJxjWoc/ABm4=; b=NB0wuv2oCkaBhfEjbP7iBeswlAho2fitpc56dyjsia9vG/65Q/Ucml7X37sH5tjH3YHyR2e6/GuIdd55ajM5NjxPNDKE6bzSqUUyz0JWfYrSXiKUixW4pzuPcc0N2IJykkxk2v1BPvQVLq/W0hmI+uMvUvposZ4431k+xAWRjos= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB1033.eurprd07.prod.outlook.com (10.162.27.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.9; Thu, 11 Jul 2019 12:58:16 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 12:58:16 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAA3WQD//86pAIAAP5UA Date: Thu, 11 Jul 2019 12:58:16 +0000 Message-ID: <45418731-F319-4C03-B543-1398E2EF49E1@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b58f760-1045-463a-25bc-08d705ff7109 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB1033; x-ms-traffictypediagnostic: HE1PR07MB1033: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(366004)(396003)(346002)(136003)(189003)(199004)(305945005)(8676002)(99286004)(76176011)(66556008)(66066001)(76116006)(66446008)(66946007)(58126008)(66476007)(6486002)(64756008)(229853002)(6916009)(53936002)(6246003)(2906002)(8936002)(81166006)(81156014)(44832011)(102836004)(14454004)(476003)(4326008)(71200400001)(256004)(6436002)(316002)(68736007)(6512007)(2616005)(6506007)(25786009)(7736002)(5660300002)(11346002)(486006)(26005)(4744005)(6116002)(33656002)(186003)(86362001)(446003)(478600001)(36756003)(71190400001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1033; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7Lo01qWCkQv0u0G3vO8wcio6AzASIQZjnUzjkDFncaBgFU9dkPiwxEfpaSKOlvc7bvl2DylQPQcbr+/+7DZOZP0+0R0cvtKxTGgO/pKRB5QfiLzW3dBWibbO3PD2UNTzdynM/gydO9tL33iljHmP5a9BVWq4kY8qZT0ByXo2jJNb3tljgdqJXg9A7ANZydDDi1XAlqazZHFWV5kKHPIzurTHaA37h6kdjYDYUA+rdqkHvNgouvc9dCwPd8iFIAnRaX7yAL3jlpib8s5AFVqsvMcHMkKRhfWYnUAez1WEn5FfjraChewVc+u+oiw5/MHsfSbuOXsxWBrV69ZbloA5gKuVYGJxInVVkckXii4cz1tdfOvohqYZManjGo2NpEzpAUTb+YzSACt6rtTfe+Fb3O8FHRNv0VYcIjLLrtKJ7Ok= Content-Type: text/plain; charset="utf-8" Content-ID: <599FD2FD51849A4A98CA2F82EA040FA6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b58f760-1045-463a-25bc-08d705ff7109 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 12:58:16.6449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1033 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 12:58:22 -0000 SGksDQoNCiAgICAuLi4NCg0KICAgID4gUmVnYXJkbGVzcywgaXQgaXMgd2hlcmUgd2UgYXJlIGFu ZCB3ZSBoYXZlIHRvIGZpbmQgc29tZSBzb3J0IG9mIGFncmVlbWVudCBvbiBob3cgdG8gcHJvY2Vl ZC4gSSB3b3VsZCBmZWVsIHNhZCBvZiBoYXZpbmcgDQogICAgPiB0byBzdXBwb3J0IGEgcG9vciBk b2N1bWVudCB3aXRoIHRvbyBtYW55IGNvbXByb21pc2VzIGJlY2F1c2Ugb2YgdGhpcyBpbXBsZW1l bnRhdGlvbi4gDQoNCiAgICBOb3Qgc3VyZSBJIGFncmVlIHdpdGggInRvbyBtYW55IGNvbXByb21p c2VzIi4NCg0KICAgIFdoYXQgd2UgYXJlIGRpc2N1c3NpbmcgaXMgc3RhbmRhcmRpemluZyBzY29w ZSBpbmZvcm1hdGlvbiBpbiB0aGUgZHJhZnQuIElmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlv dSBkb24ndCBuZWVkIHRoYXQgZm9yIHRoZSBiYXNpYyBtZWNoYW5pc20gdG8gd29yayAtIHlvdSBv bmx5IG5lZWQgaXQgaWYgeW91IHdhbnQgdG8gaW5jbHVkZSBhdXRob3JpemF0aW9uIGluZm9ybWF0 aW9uIGluIHRoZSB0b2tlbi4gSW4gY2FzZSBvZiByZWdpc3RyYXRpb24sIGlmIHRoZSBTSVAgc2Vy dmVyIGhhcyB0aGF0IGluZm9ybWF0aW9uLCBpdCBpcyBub3QgbmVlZGVkLg0KDQogICAgQWxzbywg aW4gdGhlIGNhc2Ugb2YgU1NPLCBjb3VsZG4ndCB5b3UgdXNlIHRoZSB0b2tlbiBmb3IgbW9yZSB0 aGluZ3MgdGhhbiBTSVA/IEluIHRoYXQgY2FzZSBJIGFzc3VtZSB5b3UgZG9uJ3Qgd2FudCB0byBz Y29wZSBpdCB0byBTSVAgb25seS4NCiAgICANCiAgICBSZWdhcmRzLA0KDQogICAgQ2hyaXN0ZXIg ICAgDQogICAgDQoNCg== From nobody Thu Jul 11 06:06:51 2019 Return-Path: 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 ; 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 ; 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 ; 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" 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 , "sipcore@ietf.org" To: Christer Holmberg References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <45418731-F319-4C03-B543-1398E2EF49E1@ericsson.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:06:50 -0000 --Apple-Mail=_EE097341-F36F-470F-ABB1-3E1B0F48396C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2019, at 14:58, Christer Holmberg = wrote: >=20 > Hi, >=20 > ... >=20 >> 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=20 >> to support a poor document with too many compromises because of this = implementation.=20 >=20 > Not sure I agree with "too many compromises=E2=80=9D. Not yet, but in a few mail exchanges this topic kept coming up so I = exaggerated a bit. Sorry=E2=80=A6 >=20 > 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. >=20 > 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 = "In particular, access tokens SHOULD be restricted to certain resource = servers, preferably to a single resource server. =E2=80=9C So no, I don=E2=80=99t wan=E2=80=99t 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=E2=80=99s, but the spec keeps saying =E2=80=9CURI=E2=80=9D so I = assume a SIP domain uri or a sip server URI would work too.=20 This is all in theory of course, I don=E2=80=99t 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=E2=80=99s stop using =E2=80=9Cthe token=E2=80=9D = :-) /O= --Apple-Mail=_EE097341-F36F-470F-ABB1-3E1B0F48396C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=9D.
Not yet, but in a few mail exchanges = this topic kept coming up so I exaggerated a bit. Sorry=E2=80=A6


   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=

"In particular, = access tokens SHOULD be restricted to certain resource servers, = preferably to a single resource server. =E2=80=9C

So no, I don=E2=80=99t wan=E2=80=99= 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=E2=80=99s, but the spec keeps saying =E2=80=9CURI=E2=80=9D= so I assume a SIP domain uri or a sip server URI would work = too. 
This = is all in theory of course, I don=E2=80=99t 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=E2=80=99s stop using =E2=80=9Cthe = token=E2=80=9D :-)

/O
= --Apple-Mail=_EE097341-F36F-470F-ABB1-3E1B0F48396C-- From nobody Thu Jul 11 06:24:38 2019 Return-Path: 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 5B904120077 for ; Thu, 11 Jul 2019 06:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 VB7cNiV3AcEu for ; Thu, 11 Jul 2019 06:24:33 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74A81200A3 for ; Thu, 11 Jul 2019 06:24:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dJoRmg1TZQNkQWh061pbNaeLeIUeGe43e4jOROC/hX8yAxGQB/j9+8Iv3SLnQJj7dx2hX8EscJ2RewLzgpmhm7HWBcfCGwwoX6lUnbp9JejMdTBsDRFUZx+xxhCAqSqO3+P8shCPwunK2d4dU5GUhcr654y/4COPd+c2IEa58IG0ThZIoMW1jkh3O4AaNfCpFM1zmH/2GWIWBhB1A/au4OFzxoqabqpYVpZEytzPsw5qkjlikObax5inwT7x3cXW1dkMZ02fYjS/iUc/pylsp3HcEp6mvF8Igwk3rAKYgUsv0u3NEXVStuu8NJungFi5ochmqM91UFduoIPNdF6ZWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FAgRG2cMOaMopNrCjZ8luu33jzn5Y6yedRn/X97qmbY=; b=RjqUh0UD8kQdHMsCY1cXgFBXHTgfrYLeuR9Wn9LGckCnM+jqVbYHoVGxp5y8Cr/hdegHTdmOj7+yGsvc/hajMhEzxGx54UF4XOWzY2/BGFl/FfX8LS+yciYluBBqh0zrx61s+mzmhJVFF1PdMynIW8yhzCpRtL5YMKnx3CsLCNZl4yugN501NjMFM+NIqeG6Sdbr9xzUX/EZhPAOVpql6fVK8Z/E61sIghq8Z/WcpqJ/n72fUP866PoZc6SIYz9Q1Ly/N4C9Qe0BDlSMBbn/etyHLuS/GDUrKOThUyDVdZAMKUj8waSaVoUR09H/9wHCw4TOd8r4V9CtHBAd5ES8vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FAgRG2cMOaMopNrCjZ8luu33jzn5Y6yedRn/X97qmbY=; b=iBpHU6DmSgwTQV/7VQ4m1A/OeD4O286wmkwV0PNQgmTRFCFtTbkETzwmkktXb5temG55wmpg7iYpc8Lmie5Yw/ZCFBKyW3aS/cMc2UfF4jhUozMt9viXOJ4FTbRWdGDwmvdwmP6+h6IP9cbXCX94jZNpB9DPyRxzZ0yZnVqGyN0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3353.eurprd07.prod.outlook.com (10.170.247.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 13:24:30 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 13:24:30 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAA3WQD//86pAIAAP5UA///QEYAABuhJgA== Date: Thu, 11 Jul 2019 13:24:30 +0000 Message-ID: <0E4BF760-5E56-4A0E-A6B4-CE538C739D24@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <45418731-F319-4C03-B543-1398E2EF49E1@ericsson.com> <1521246D-E64A-4CB6-AA48-B90070E45575@edvina.net> In-Reply-To: <1521246D-E64A-4CB6-AA48-B90070E45575@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84b661cf-c711-47d4-b667-08d706031b01 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3353; x-ms-traffictypediagnostic: HE1PR07MB3353: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(199004)(189003)(6486002)(6916009)(3846002)(2616005)(6506007)(81156014)(8676002)(229853002)(6116002)(26005)(64756008)(2906002)(81166006)(66446008)(6246003)(6436002)(102836004)(4326008)(476003)(36756003)(11346002)(44832011)(486006)(99286004)(33656002)(76176011)(66066001)(8936002)(446003)(14454004)(86362001)(71200400001)(66946007)(5660300002)(71190400001)(76116006)(58126008)(478600001)(966005)(53936002)(256004)(6306002)(7736002)(305945005)(186003)(316002)(66556008)(6512007)(66476007)(25786009)(14444005)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3353; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ENeodba8orH74y3vbkASvcJxVCc5GbVDV76IypAwozWvtHxODc6q5VQbFiREELRwzQfXh2Lc+9QMOGXYH6Xo6DvK7paU/ktY5zHiKb4p4fg3069M+FUQpoK/LuBvJETrTPHVmkF97+lXyll3AwYDQVbKNXxt6v40tH0xwiSXAKWkOUmgbzAOCmWQ+EfPbxmgGRKAYfQhtknM5n3eT5OHrvUvPbIYMYIHTYpiIlYUw4VCrwiyOkc9e1Ntr2PCWkBEm4qtmrA1Y4wdMAYJqSX/emghtUn8rM73ptkaFmSc1Wts1q7X/21ocSvr+VL1hgjZQoChorUQdaE/6gqafJLEmUmNa2gw3Gtb5aAdKBtijdT7RWvOwd5rhow8NgNjuyH6qSJ00mUP+Vz2V1Faoja1q22j+ULkZN3cgxQyhW47B8s= Content-Type: text/plain; charset="utf-8" Content-ID: <08C2E33D33F2154EA4BB46D822256AA3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84b661cf-c711-47d4-b667-08d706031b01 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 13:24:30.2361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3353 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:24:37 -0000 SGksDQoNCj4+wqDCoMKgV2hhdCB3ZSBhcmUgZGlzY3Vzc2luZyBpcyBzdGFuZGFyZGl6aW5nIHNj b3BlIGluZm9ybWF0aW9uIGluIHRoZSBkcmFmdC4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwg eW91IGRvbid0IG5lZWQgdGhhdCBmb3IgdGhlIGJhc2ljIG1lY2hhbmlzbSB0byB3b3JrIC0geW91 IG9ubHkgbmVlZCBpdCBpZiB5b3Ugd2FudCB0byBpbmNsdWRlIGF1dGhvcml6YXRpb24gaW5mb3Jt YXRpb24gaW4gdGhlIHRva2VuLiBJbiBjYXNlIG9mIHJlZ2lzdHJhdGlvbiwgaWYgdGhlIFNJUCBz ZXJ2ZXIgaGFzIHRoYXQgaW5mb3JtYXRpb24sIGl0IGlzIG5vdCBuZWVkZWQuDQo+DQo+wqDCoMKg QWxzbywgaW4gdGhlIGNhc2Ugb2YgU1NPLCBjb3VsZG4ndCB5b3UgdXNlIHRoZSB0b2tlbiBmb3Ig bW9yZSB0aGluZ3MgdGhhbiBTSVA/IEluIHRoYXQgY2FzZSBJIGFzc3VtZSB5b3UgZG9uJ3Qgd2Fu dCB0byBzY29wZSBpdCB0byBTSVAgb25seS4NCj4NCj4gUGxlYXNlIHJlYWQgc2VjdGlvbiAzLjMg b2YgdGhlIE9hdXRoIDIuMCBTZWN1cml0eSBCZXN0IEN1cnJlbnQgUHJhY3Rpc2UuDQo+IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNlY3VyaXR5LXRvcGljcy0x Mw0KPg0KPiAiSW4gcGFydGljdWxhciwgYWNjZXNzIHRva2VucyBTSE9VTEQgYmUgcmVzdHJpY3Rl ZCB0byBjZXJ0YWluIHJlc291cmNlwqBzZXJ2ZXJzLCBwcmVmZXJhYmx5IHRvIGEgc2luZ2xlIHJl c291cmNlIHNlcnZlci7CoOKAnA0KDQpGYWlyIGVub3VnaC4gSSdsbCBsZXQgUmlmYWF0IGNvbnRp bnVlIHRoZSBTU08gZGlzY3Vzc2lvbiwgaWYgbmVlZGVkLCBiZWNhdXNlIGhlIGlzIG1vcmUgaW50 ZXJlc3RlZCBpbiB0aGF0Lg0KDQpNeSBtYWluIGludGVyZXN0IGlzIHVzaW5nIE9hdXRoIHRva2Vu cyBmb3IgU0lQIHJlZ2lzdHJhdGlvbnMgb25seSwgc28gdGhhdCBzaG91bGQgYmUgYWxpZ25lZCB3 aXRoIHRoZSBCQ1AgOikNCg0KPiBTbyBubywgSSBkb27igJl0IHdhbuKAmXQgdGhlIGFjY2VzcyB0 b2tlbiB1c2VkIGZvciBTSVAgdXNlZCBmb3IgYW55dGhpbmcgZWxzZS4gV2hlbiB0aGUgY2xpZW50 IHJlcXVlc3RzIGF1dGhvcml6YXRpb24geW91IHByb3BhYmx5IHdhbnQgdG8gcmVxdWVzdCBhIHNw ZWNpZmljIHJlc291cmNlIHNlcnZlciAoU0lQIGRvbWFpbikNCj4gdGhhdCB0aGlzIHRva2VuIGFw cGxpZXMgdG8uIE1vc3QgZXhhbXBsZXMgaW4gdGhlIGRvY3MgcmVmZXIgdG8gSFRUUFMgVVJJ4oCZ cywgYnV0IHRoZSBzcGVjIGtlZXBzIHNheWluZ8Kg4oCcVVJJ4oCdIHNvIEkgYXNzdW1lIGEgU0lQ IGRvbWFpbiB1cmkgb3IgYSBzaXAgc2VydmVyIFVSSSB3b3VsZCB3b3JrIHRvby7CoA0KPiBUaGlz IGlzIGFsbCBpbiB0aGVvcnkgb2YgY291cnNlLCBJIGRvbuKAmXQga25vdyB3aGF0IGtpbmQgb2Yg Y29yZSBkdW1wIG9yIG90aGVyIGhpY2N1cCBhIFNJUCBVUkkgd291bGQgZ2VuZXJhdGUgaW4gY3Vy cmVudCBPQXV0aDIgaW1wbGVtZW50YXRpb25zIDstKQ0KDQpIVFRQIGlzIHJlZmVycmluZyB0byB0 aGUgT0F1dGgyIGludGVyZmFjZXMgZXRjICh3ZSBhcmUgbm90IGRlZmluaW5nIGEgU0lQIE9BdXRo IGludGVyZmFjZSkgV2UgY2FuIGRvdWJsZSBjaGVjayB3aGV0aGVyIGluc3RhbmNlcyBvZiAiVVJJ IiBzaG91bGQgYmUgbW9yZSBzcGVjaWZpYy4NCg0KPiBBbnkgcmVjb21tZW5kYXRpb25zIG9uIE9w ZW4gU291cmNlIE9hdXRoMiBzZXJ2ZXJzIHRvIHBsYXkgYXJvdW5kIHdpdGgsIGJ0dz8NCg0KVW5m b3J0dW5hdGVseSBub3QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQo= From nobody Thu Jul 11 06:46:18 2019 Return-Path: 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 DF44E120224 for ; Thu, 11 Jul 2019 06:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 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, 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 KSdSv6kb-ERb for ; Thu, 11 Jul 2019 06:46:05 -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 0F52B120077 for ; Thu, 11 Jul 2019 06:46:04 -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 x6BDk2lE026384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Jul 2019 09:46:03 -0400 To: sipcore@ietf.org References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> From: Paul Kyzivat Message-ID: <56f4ed60-15b7-5bbe-63a5-10f447ae9094@alum.mit.edu> Date: Thu, 11 Jul 2019 09:46:02 -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: <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:46:13 -0000 This discussion is wandering in many directions. I don't know very much (anything?) about OAuth so it is pretty abstract for me. But what is becoming clear is that the people discussing this have *many* unstated assumptions about how this is to work and how it is to be used. And those don't appear to be well aligned with one another. I've been pushing for more of these assumptions (and implications) to be written down in the document. I still want that. But I'm beginning to think that the issue is bigger than what is likely to fit into this document as it is currently conceived. I think what may be needed is a framework document. (Perhaps "Framework for using OAuth(2?) with SIP", though maybe that isn't quite right. This would discuss why this is important, how it relates to the sip environment, how it fits into a broader authentication environment, etc. Thanks, Paul On 7/11/19 7:49 AM, Olle E. Johansson wrote: > > >> On 11 Jul 2019, at 13:25, Christer Holmberg wrote: >> >> Hi, >> >>>>>>> The tokens generally, but if I understand it right not always, are JWT structures that contain various data. In >>>>>>> OpenID connect both the access and identity token are JWTs. >>>>>>> We can either specify specific claims that are standardised for various SIP functions or let that be open for >>>>>>> the SIP implementors to specify or a combination. >>>>>> >>>>>> For backward compatibility, we should at least let SIP implementors specify >>>>> Maybe, but at least we should write something about the usage of claims and scopes. >>>>> I think a base level for this draft is specifying a way to say “this access token is valid for SIP usage” or >>>>> “this is also a SIP identity" >>>> >>>> Perhaps we can add some text about scope and claims, but I don't want to mandate usage of specific values, because that >>>> may not be backward compatible with existing implementations using JWT. >>> >>> We can mandate *if* the access token is a jwt (and there’s an identity token like OpenID Connect). >> >> It may not work with existing implementations that DO use JWT access tokens (not sure whether they use OpenID Connect, though). > > Ok, you are making me interested - what are these implementations? > When writing a new standard document, should we really be blocked by pre-standard implementations? I would assume that we > should be inspired by them, learn by their experiences, but not be hindered by them. > >> >>>> I see interoperability problems if every implementation is using different data structures for stuff like SIP AOR, SIP usage claim >>>> and maybe a few more that we will come up with as we continue working. Standardizing some of these basic data points in tokens will help interoperability. >>> >>> If the access token is a random blob we don’t require any change. >>> >>> In addition I think we should change the “sip.token” label to something more specific like “sip.oauth2”. >> >> I think it was me who suggested to use sip.token, but I don't have a strong opinion about it. It was added recently, so existing implementations currently don't use it anyway. > > We have already been confused by discussions about “the token” when in fact there are multiple tokens… > > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Jul 11 06:50:15 2019 Return-Path: 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 403461200A3 for ; Thu, 11 Jul 2019 06:50:14 -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 ejekVuvmhKoc for ; Thu, 11 Jul 2019 06:50:11 -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 62A08120077 for ; Thu, 11 Jul 2019 06:50:11 -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 x6BDo6ej026608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jul 2019 09:50:07 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Thu, 11 Jul 2019 09:50:06 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:50:15 -0000 On 7/11/19 3:03 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? If it is protected, then why is there any concern over who it is given to? Thanks, Paul From nobody Thu Jul 11 06:57:06 2019 Return-Path: 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 C67B61200A3 for ; Thu, 11 Jul 2019 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NUnwxramv3Fm for ; Thu, 11 Jul 2019 06:57:00 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130084.outbound.protection.outlook.com [40.107.13.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73B8120077 for ; Thu, 11 Jul 2019 06:56:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AlP0oHRQ+ppu51M7wsSnYBXp0rsB6V35p0T+NYk/vnO+BesspAQRT6dD61wF5/cD6RLIrgd/UeEh/hCOgDRrnVaa5lnjYF7xK2MRcGiBLEeVt5ueX2nzPwumX7nvZI8bCZBFxQmiHTeQV2vpMqIRNtV0FXj0jgWe2CX3KsV3G2mr49oVEOzyuVXsb3yehtdEuA009det7bP9A3ykL3NBF2nzqV0/mowec7fdr0OARPIBIBq+qDXakftR0f+ehBAhxSb6Tiz0/b3kTwP5i6EPR4v9IgrHJB3Ie5v8wQaJ4aMBJdyn/ECKXt4TvoiqzDIatMnLh9Yko/bWG92k4P77Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S6zdO/o9afKaOiMuLeArCVWQ5CBSCnH7oImoK+Cko+o=; b=TMJ3HP9Z2xbMcbgk3/Rwd680o+9MnNQRSrgu6rvx/UUiQhqcBBvAqEqqtgVMOuEi6Ut0PT872L2ggVcMIvdqQ0qrddBOzZ++hm34jkYkAWSMag7K7HH+/ariBRV4KqGnol7ZPgGfWbQxYzjL3hHGjrj3dRGD9n80GWa/U+87EhqBHsulYm7U0E1Ib9OELYueKgJrw9gyxTeNX2CqKN2Yk6hvXXlkdFdhM2wIb3Sj4n05gqZyblNo85JxiIQdzg0LxEXsqSuopcwQsFib64/2Sz58V1n2aJtOKp5JWw9i9L01HbbHRSRZPvL+zsTR2uyq4Z7IZR2tFcerWcKWQwM/dA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S6zdO/o9afKaOiMuLeArCVWQ5CBSCnH7oImoK+Cko+o=; b=OuABkJYDnV7XEIgSblx2n1W8eORBYI39rOR+CzrQyXh23Mb3DiI7PQIAmu4nxk1rRHsX6t1UR37dd4oEyz76SHTX5mip4tpBxMpZY9qF8IdxaydALHEjkjxqH4+rcOChUxofM13OGyletMAWddgCNy4Ngk+BV+a8EBhLN/FbH44= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1SPR01MB01.eurprd07.prod.outlook.com (10.160.67.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.3; Thu, 11 Jul 2019 13:56:56 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 13:56:56 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAAgpQCAADVWAA== Date: Thu, 11 Jul 2019 13:56:56 +0000 Message-ID: <178C3837-A525-4DF9-91D6-9659966D55C5@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <56f4ed60-15b7-5bbe-63a5-10f447ae9094@alum.mit.edu> In-Reply-To: <56f4ed60-15b7-5bbe-63a5-10f447ae9094@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f413e95f-a88a-4735-4861-08d70607a32a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1SPR01MB01; x-ms-traffictypediagnostic: HE1SPR01MB01: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(189003)(199004)(6486002)(66556008)(476003)(99286004)(66446008)(229853002)(6306002)(6116002)(8676002)(3846002)(44832011)(76176011)(14454004)(6436002)(7736002)(64756008)(446003)(305945005)(76116006)(33656002)(25786009)(2501003)(5660300002)(11346002)(66476007)(966005)(2616005)(478600001)(66946007)(110136005)(71200400001)(86362001)(486006)(71190400001)(8936002)(68736007)(36756003)(58126008)(66066001)(256004)(6246003)(14444005)(186003)(26005)(316002)(102836004)(53936002)(6512007)(81166006)(81156014)(2906002)(53546011)(2171002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR01MB01; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yvSDvDY+Bg5YdI9oz6q8USFA+o2xRqYSapmqIF1QEHOrPx4KJ78npl2G3jU2MFIPJO+bhQ9bIccVLYKn2SGEjfagLux3MleK93MzINi6XbKAmi3klvIFzKb7Ll+LwTJ+p776KiGr7hLsa0QAmYE/yMdOYZKtwy2bfSWx4gmDvDFdY95t+oEciVcdXgvN+iSpM97t5hzezNBLbTyPuwZE31kATfZ5K8WSzJmrk5841+jrCZiwC/aiatiAl6Pr3opCJyRy0j2BtAc1HlBGKn1dnnk1hoRmx4LxjpApWelLpa+dD59tdnLeO2yWllLPslYaJpK9EhTfl5br9EFZC7OwajaaFCEoVFNJfhhyhApxo4dOL5ty74q9KwFJf+izdRXXiOy08EnedftoXgxJCjJ3CNmaCz8eGYl3+G0O1gdy5Hg= Content-Type: text/plain; charset="utf-8" Content-ID: <8D4494F0BD57BD428830C71E64073E86@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f413e95f-a88a-4735-4861-08d70607a32a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 13:56:56.6400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1SPR01MB01 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 13:57:04 -0000 SGksDQoNCj4gICAgVGhpcyBkaXNjdXNzaW9uIGlzIHdhbmRlcmluZyBpbiBtYW55IGRpcmVjdGlv bnMuIEkgZG9uJ3Qga25vdyB2ZXJ5IG11Y2ggDQo+ICAgIChhbnl0aGluZz8pIGFib3V0IE9BdXRo IHNvIGl0IGlzIHByZXR0eSBhYnN0cmFjdCBmb3IgbWUuIEJ1dCB3aGF0IGlzIA0KPiAgICBiZWNv bWluZyBjbGVhciBpcyB0aGF0IHRoZSBwZW9wbGUgZGlzY3Vzc2luZyB0aGlzIGhhdmUgKm1hbnkq IHVuc3RhdGVkIA0KPiAgICBhc3N1bXB0aW9ucyBhYm91dCBob3cgdGhpcyBpcyB0byB3b3JrIGFu ZCBob3cgaXQgaXMgdG8gYmUgdXNlZC4gQW5kIA0KPiAgICB0aG9zZSBkb24ndCBhcHBlYXIgdG8g YmUgd2VsbCBhbGlnbmVkIHdpdGggb25lIGFub3RoZXIuDQo+ICAgIA0KPiAgICBJJ3ZlIGJlZW4g cHVzaGluZyBmb3IgbW9yZSBvZiB0aGVzZSBhc3N1bXB0aW9ucyAoYW5kIGltcGxpY2F0aW9ucykg dG8gYmUgDQo+ICAgIHdyaXR0ZW4gZG93biBpbiB0aGUgZG9jdW1lbnQuIEkgc3RpbGwgd2FudCB0 aGF0LiBCdXQgSSdtIGJlZ2lubmluZyB0byANCj4gICAgdGhpbmsgdGhhdCB0aGUgaXNzdWUgaXMg YmlnZ2VyIHRoYW4gd2hhdCBpcyBsaWtlbHkgdG8gZml0IGludG8gdGhpcyANCj4gICAgZG9jdW1l bnQgYXMgaXQgaXMgY3VycmVudGx5IGNvbmNlaXZlZC4NCj4gICAgDQo+ICAgIEkgdGhpbmsgd2hh dCBtYXkgYmUgbmVlZGVkIGlzIGEgZnJhbWV3b3JrIGRvY3VtZW50LiAoUGVyaGFwcyAiRnJhbWV3 b3JrIA0KPiAgICBmb3IgdXNpbmcgT0F1dGgoMj8pIHdpdGggU0lQIiwgdGhvdWdoIG1heWJlIHRo YXQgaXNuJ3QgcXVpdGUgcmlnaHQuIFRoaXMgDQo+ICAgIHdvdWxkIGRpc2N1c3Mgd2h5IHRoaXMg aXMgaW1wb3J0YW50LCBob3cgaXQgcmVsYXRlcyB0byB0aGUgc2lwIA0KPiAgICBlbnZpcm9ubWVu dCwgaG93IGl0IGZpdHMgaW50byBhIGJyb2FkZXIgYXV0aGVudGljYXRpb24gZW52aXJvbm1lbnQs IGV0Yy4NCiAgDQpMZXQncyB0cnkgdG8gZG9jdW1lbnQgYW5kIGNsYXJpZnkgZXZlcnl0aGluZyB3 ZSBuZWVkIGluIHRoaXMgZG9jdW1lbnQuDQoNClRoZSBkcmFmdCB0cmllcyB0byBtYXAgdGhlIE9B dXRoIGFyY2hpdGVjdHVyZSB0byB0aGUgU0lQIGFyY2hpdGVjdHVyZS4gSWYgc29tZXRoaW5nIGlz IHVuY2xlYXIgd2Ugc2hvdWxkIG9mIGNvdXJzZSBjbGFyaWZ5IGl0Lg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KICAgIA0KICAgIE9uIDcvMTEvMTkgNzo0OSBBTSwgT2xsZSBFLiBKb2hh bnNzb24gd3JvdGU6DQogICAgPiANCiAgICA+IA0KICAgID4+IE9uIDExIEp1bCAyMDE5LCBhdCAx MzoyNSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g d3JvdGU6DQogICAgPj4NCiAgICA+PiBIaSwNCiAgICA+Pg0KICAgID4+Pj4+Pj4gVGhlIHRva2Vu cyBnZW5lcmFsbHksIGJ1dCBpZiBJIHVuZGVyc3RhbmQgaXQgcmlnaHQgbm90IGFsd2F5cywgYXJl IEpXVCBzdHJ1Y3R1cmVzIHRoYXQgY29udGFpbiB2YXJpb3VzIGRhdGEuIEluDQogICAgPj4+Pj4+ PiBPcGVuSUQgY29ubmVjdCBib3RoIHRoZSBhY2Nlc3MgYW5kIGlkZW50aXR5IHRva2VuIGFyZSBK V1RzLg0KICAgID4+Pj4+Pj4gV2UgY2FuIGVpdGhlciBzcGVjaWZ5IHNwZWNpZmljIGNsYWltcyB0 aGF0ICBhcmUgc3RhbmRhcmRpc2VkIGZvciB2YXJpb3VzIFNJUCBmdW5jdGlvbnMgb3IgbGV0IHRo YXQgYmUgb3BlbiBmb3INCiAgICA+Pj4+Pj4+IHRoZSBTSVAgaW1wbGVtZW50b3JzIHRvIHNwZWNp Znkgb3IgYSBjb21iaW5hdGlvbi4NCiAgICA+Pj4+Pj4NCiAgICA+Pj4+Pj4gRm9yIGJhY2t3YXJk IGNvbXBhdGliaWxpdHksIHdlIHNob3VsZCBhdCBsZWFzdCBsZXQgU0lQIGltcGxlbWVudG9ycyBz cGVjaWZ5DQogICAgPj4+Pj4gTWF5YmUsIGJ1dCBhdCBsZWFzdCB3ZSBzaG91bGQgd3JpdGUgc29t ZXRoaW5nIGFib3V0IHRoZSB1c2FnZSBvZiBjbGFpbXMgYW5kIHNjb3Blcy4NCiAgICA+Pj4+PiBJ IHRoaW5rIGEgYmFzZSBsZXZlbCBmb3IgdGhpcyBkcmFmdCBpcyBzcGVjaWZ5aW5nIGEgd2F5IHRv IHNheSDigJx0aGlzIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCBmb3IgU0lQIHVzYWdl4oCdIG9yDQog ICAgPj4+Pj4g4oCcdGhpcyBpcyBhbHNvIGEgU0lQIGlkZW50aXR5Ig0KICAgID4+Pj4NCiAgICA+ Pj4+ICAgIFBlcmhhcHMgd2UgY2FuIGFkZCBzb21lIHRleHQgYWJvdXQgc2NvcGUgYW5kIGNsYWlt cywgYnV0IEkgZG9uJ3Qgd2FudCB0byBtYW5kYXRlIHVzYWdlIG9mIHNwZWNpZmljIHZhbHVlcywg YmVjYXVzZSB0aGF0DQogICAgPj4+PiAgICBtYXkgbm90IGJlIGJhY2t3YXJkIGNvbXBhdGlibGUg d2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgSldULg0KICAgID4+Pg0KICAgID4+ PiBXZSBjYW4gbWFuZGF0ZSAqaWYqIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYSBqd3QgKGFuZCB0aGVy ZeKAmXMgYW4gaWRlbnRpdHkgdG9rZW4gbGlrZSBPcGVuSUQgQ29ubmVjdCkuDQogICAgPj4NCiAg ICA+PiAgICAgSXQgbWF5IG5vdCB3b3JrIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHRo YXQgRE8gdXNlIEpXVCBhY2Nlc3MgdG9rZW5zIChub3Qgc3VyZSB3aGV0aGVyIHRoZXkgdXNlIE9w ZW5JRCBDb25uZWN0LCB0aG91Z2gpLg0KICAgID4gDQogICAgPiBPaywgeW91IGFyZSBtYWtpbmcg bWUgaW50ZXJlc3RlZCAtIHdoYXQgYXJlIHRoZXNlIGltcGxlbWVudGF0aW9ucz8NCiAgICA+IFdo ZW4gd3JpdGluZyBhIG5ldyBzdGFuZGFyZCBkb2N1bWVudCwgc2hvdWxkIHdlIHJlYWxseSBiZSBi bG9ja2VkIGJ5IHByZS1zdGFuZGFyZCBpbXBsZW1lbnRhdGlvbnM/IEkgd291bGQgYXNzdW1lIHRo YXQgd2UNCiAgICA+IHNob3VsZCBiZSBpbnNwaXJlZCBieSB0aGVtLCBsZWFybiBieSB0aGVpciBl eHBlcmllbmNlcywgYnV0IG5vdCBiZSBoaW5kZXJlZCBieSB0aGVtLg0KICAgID4gDQogICAgPj4N CiAgICA+Pj4+IEkgc2VlIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgaWYgZXZlcnkgaW1wbGVt ZW50YXRpb24gaXMgdXNpbmcgZGlmZmVyZW50IGRhdGEgc3RydWN0dXJlcyBmb3Igc3R1ZmYgbGlr ZSBTSVAgQU9SLCBTSVAgdXNhZ2UgY2xhaW0NCiAgICA+Pj4+IGFuZCBtYXliZSBhIGZldyBtb3Jl IHRoYXQgd2Ugd2lsbCBjb21lIHVwIHdpdGggYXMgd2UgY29udGludWUgd29ya2luZy4gU3RhbmRh cmRpemluZyBzb21lIG9mIHRoZXNlIGJhc2ljIGRhdGEgcG9pbnRzIGluIHRva2VucyB3aWxsIGhl bHAgaW50ZXJvcGVyYWJpbGl0eS4NCiAgICA+Pj4NCiAgICA+Pj4gSWYgdGhlIGFjY2VzcyB0b2tl biBpcyBhIHJhbmRvbSBibG9iIHdlIGRvbuKAmXQgcmVxdWlyZSBhbnkgY2hhbmdlLg0KICAgID4+ Pg0KICAgID4+PiBJbiBhZGRpdGlvbiBJIHRoaW5rIHdlIHNob3VsZCBjaGFuZ2UgdGhlIOKAnHNp cC50b2tlbuKAnSBsYWJlbCB0byBzb21ldGhpbmcgbW9yZSBzcGVjaWZpYyBsaWtlIOKAnHNpcC5v YXV0aDLigJ0uDQogICAgPj4NCiAgICA+PiAgICAgSSB0aGluayBpdCB3YXMgbWUgd2hvIHN1Z2dl c3RlZCB0byB1c2Ugc2lwLnRva2VuLCBidXQgSSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24g YWJvdXQgaXQuIEl0IHdhcyBhZGRlZCByZWNlbnRseSwgc28gZXhpc3RpbmcgaW1wbGVtZW50YXRp b25zIGN1cnJlbnRseSBkb24ndCB1c2UgaXQgYW55d2F5Lg0KICAgID4gDQogICAgPiBXZSBoYXZl IGFscmVhZHkgYmVlbiBjb25mdXNlZCBieSBkaXNjdXNzaW9ucyBhYm91dCDigJx0aGUgdG9rZW7i gJ0gd2hlbiBpbiBmYWN0IHRoZXJlIGFyZSBtdWx0aXBsZSB0b2tlbnPigKYNCiAgICA+IA0KICAg ID4gL08NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KICAgID4gc2lwY29yZUBpZXRmLm9yZw0K ICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQogICAg PiANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIHNpcGNvcmUgbWFpbGluZyBsaXN0DQogICAgc2lwY29yZUBpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KICAgIA0KDQo= From nobody Thu Jul 11 07:07:55 2019 Return-Path: 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 9A8851200FB for ; Thu, 11 Jul 2019 07:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ntned9uWvLBl for ; Thu, 11 Jul 2019 07:07:50 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140073.outbound.protection.outlook.com [40.107.14.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874EC1200CD for ; Thu, 11 Jul 2019 07:07:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TkRYAzAVz0U+AwTeOiX84GGL6dHHLLz4eTxybiToPpssOalmU5x7c7N2LFHlAOKrfD6WU33ofWzrQOMeWTVU3kdS4aZmgc3LkV9+VxyIATjFSAS99sqGNR4WDrdSlacCMuDADjuFvsmMOzO0SKC9/wt+7mqOYJ1mtjp5JgYQqOXpSApMq/WEY+FDVhKCn75owCl6V3lPHTo7Ze/44M21G0h4eick1iVJ6XHrmzqYdljHWoaU8FCvQG7wfIHKe1HFYB5r+COdx5IeLWyX7BxM5nB60Kd/jnHkndybHwZVBimgnSeVImQ4ZkCcrifSIBq8Nbx4ooqPNDi9cbvMr4U5jQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bT5u3M55yKIYqc4A0x78OvGybH0JP3oI1x4zYApFaB4=; b=hE8JgvHrnHKF5eMG0I7iPGyGkqQusZTXC9nPJMgTqXe+8fGSTL1Ve4KAUSoj3RjIwtQGzVaUOClUjTxFqwarMOsDGVOv1VF+3MXjbAw5tlPYMXB7hGZy3CNr6LE5dVlE0LBzNAls0qLwmmLTkVyvwQpXWn+PLNZIWGvdElcr43q/rHUkYqkIw/Itmpma5QHMBlo0uXEaMI9dpW78C7FW6kfn0lg3C8IwwvmBdMsXvLaWpy88WWFVjDygcWhp9oTZ/KvJPdVoHMbbtYucjpXl/1XCdJjg6YQlTI/ap4UCP/OJdi1yB4iYhG9oceENgkpOAza50P3iDBPagV8gqR1M0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bT5u3M55yKIYqc4A0x78OvGybH0JP3oI1x4zYApFaB4=; b=Ac6fyLd2/cMCMpi5bAbFdlQP3Sk8zBig8m793DqMqYNDTdQJtPu0Y0jIwDL16PnSGktzaI+NzBZfSUntkaONn6Ujz33jzpbNdNMi7mMwWE7kizPSEK84/QQlXwkZdhH2kjHyjDMNPrQenXitZd2gO8dEq1ayxvwef/J4QGx+FWI= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4283.eurprd07.prod.outlook.com (20.176.166.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 14:07:46 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 14:07:46 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgIAAP24AgAA3OYA= Date: Thu, 11 Jul 2019 14:07:46 +0000 Message-ID: <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 395d61eb-4667-4726-664e-08d706092670 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4283; x-ms-traffictypediagnostic: HE1PR07MB4283: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(189003)(199004)(2171002)(3846002)(6116002)(66446008)(71200400001)(446003)(86362001)(11346002)(14454004)(53936002)(81166006)(25786009)(66946007)(36756003)(81156014)(71190400001)(33656002)(486006)(64756008)(68736007)(6246003)(66556008)(8676002)(76116006)(476003)(2616005)(44832011)(66476007)(99286004)(2906002)(58126008)(229853002)(6512007)(5660300002)(7736002)(478600001)(76176011)(6436002)(14444005)(305945005)(6486002)(316002)(102836004)(66066001)(26005)(8936002)(186003)(2501003)(6506007)(256004)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4283; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7Pu9U8RtRvlrLgI3XPJJdq5h/M1zWLsydDum7AZgmdjTl87lDMGiCzeXO8r2ODPWTdvrcjvV5FQZZJukyWz1U/kT2f9oKrhco7LoSMR59V86bXskRRL8fJ/rn3agnuQEGDIglG7rqGHXv6t7VLW4FQIh/giFOPCFUN62Qyh8Jh5MEKC73EW8YiDX8i59f25kJu8g9up9ah6H1hPDjPaycntboS5m2HNOOlv8Rvj5kYCbiNFwmewhRVqxBn8sb0EB2EQW19Y4XQpChYasLaHYRjWlPcn4LbDIXpVJrk3mZ/E8Ui6C7VppSlNdp/PKWPjRl5jcRxz3xB8HXXZBZAfZpmie9qSZasALX3fldXGhamOUF+bwHdjs2LZ0N5ZB1nUyDieCalXkI3UJ4f1g9o/oDmty9MvnoiLLkb0W7hsQB10= Content-Type: text/plain; charset="utf-8" Content-ID: <0E0B2F362E794849B3DA9C515D0EA9FE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 395d61eb-4667-4726-664e-08d706092670 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 14:07:46.4577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4283 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 14:07:53 -0000 SGksDQoNCiAgICA+Pj4+IEFsbCBJIGFtIHNheWluZyBpcyB0aGF0IG9uZSBzaG91bGQgbm90IHNl bmQgYSB0b2tlbiB0byBzb21lb25lIHRoYXQgaXQgaGFzIE5PVCBiZWVuIGlzc3VlZCBmb3IuDQog ICAgPj4+ICAgICANCiAgICA+Pj4gICAgIFRoZW4geW91IGFyZSBzYXlpbmcgdGhhdCBhIHRva2Vu IHNob3VsZCAqbmV2ZXIqIGJlIGluY2x1ZGVkIGluIGEgcmVxdWVzdA0KICAgID4+PiAgICAgdG8g YSB0YXJnZXQgZm9yIHdoaWNoIHlvdSBoYXZlIG5vdCByZWNlaXZlZCBhIGNoYWxsZW5nZSBzb21l IHRpbWUgaW4gdGhlDQogICAgPj4+ICAgICBwYXN0Lg0KICAgID4+PiAgICAgDQogICAgPj4+ICAg ICBUaGF0IGlzIGEgYml0IGV4dHJlbWUsIGJ1dCBJIGd1ZXNzIHlvdSBjYW4gc3BlY2lmeSB0aGF0 IGlmIHlvdSB0aGluayBpdA0KICAgID4+PiAgICAgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLg0K ICAgID4+IA0KICAgID4+IFRoYXQgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZ2VuZXJpYyBP QXV0aCBzZWN1cml0eSBjb25zaWRlcmF0aW9uczogeW91IGRvbid0IGdpdmUgYSB0b2tlbiB0byBz b21lb25lIGl0IHdhcyBub3QgaW50ZW5kZWQgZm9yLg0KICAgID4+IA0KICAgID4+IE9mIGNvdXJz ZSwgaWYgeW91IGtub3cgKGJhc2VkIG9uIHdoYXRldmVyIGNvbmZpZ3VyYXRpb24vcG9saWN5KSB0 aGF0IGl0J3Mgb2sgdG8gZ2l2ZSB0aGUgdG9rZW4gdG8gdGhlIHRhcmdldCBJIGd1ZXNzIHlvdSBj b3VsZCBkbyBpdC4NCiAgICA+PiAgICAgIA0KICAgID4+PiAgICAgQnV0IG5vdGUgdGhhdCB0aGlz IGxvZ2ljIHdvbid0IGFsd2F5cyB3b3JrIGZvciBQcm94eS1BdXRoZW50aWNhdGUuIFlvdQ0KICAg ID4+PiAgICAgKm1pZ2h0KiBrbm93IHRoYXQgYSBwYXJ0aWN1bGFyIHByb3h5IHdpbGwgYmUgdmlz aXRlZCAoaWYgaXQgaXMgbWVudGlvbmVkDQogICAgPj4+ICAgICBvbiBhIFJvdXRlIGhlYWRlciks IGJ1dCBpdCBpcyBwcmV0dHkgY29tbW9uIGZvciB0aGUgcmVxdWVzdCB0byB2aXNpdA0KICAgID4+ PiAgICAgcHJveGllcyB1bmtub3duIChhdCBsZWFzdCBpbiBhZHZhbmNlKSB0byB0aGUgVUFDLg0K ICAgID4+ICAgIA0KICAgID4+IEl0IGlzIGltcG9ydGFudCB0byByZW1lbWJlciB0aGF0LCBzaW5j ZSB0aGUgdG9rZW4gbmVlZHMgdG8gYmUgcHJvdGVjdGVkLCBhIHByb3h5IG5lZWRzIHRvIGhhdmUg dGhlIA0KICAgID4+IGFzc29jaWF0ZWQgcHJvdGVjdGlvbiBjcmVkZW50aWFscyB0byBiZSBhYmxl IHRvIGFjY2VzcyB0aGUgdG9rZW4uDQogICAgPg0KICAgID4gSSdtIGxvc3QgaGVyZS4gSG93IGlz IHRoZSB0b2tlbiBwcm90ZWN0ZWQ/IElzIGl0IGJlY2F1c2UgaXQgaXMgcGFzc2VkIGJ5IA0KICAg ID4gcmVmZXJlbmNlLCBhbmQgb3RoZXIgY3JlZGVudGlhbHMgYXJlIG5lZWRlZCB0byBkZXJlZmVy ZW5jZSBpdD8gT3IgaXMgaXQgDQogICAgPiBwYXNzZWQgYnkgdmFsdWUgYnV0IGVuY3J5cHRlZD8N Cg0KICAgIFRoYXQgZGVwZW5kcyBvbiBob3cgeW91ciBwcm90ZWN0IGl0Lg0KDQogICAgSWYgdGhl IG9hdXRoMiB0b2tlbiBpdHNlbGYgaXMgZW5jcnlwdGVkLCBhbmQgb25seSBhdXRob3JpemVkIGVu dGl0aWVzIGNhbiBkZWNyeXB0IGl0LCB0aGVuIEkgZ3Vlc3MgaXQgZG9lcyBub3QgbWF0dGVyIGlm IGEgbm9uLWF1dGhvcml6ZWQgdXNlciBnZXRzIGl0LCBhcyBpdCB3aWxsIG5vdCBiZSBhYmxlIHRv IHVzZSBpdC4NCg0KICAgIEJ1dCwgaWYgdGhlIG9hdXRoMiB0b2tlbiBpcyBzZW50IGluICJwbGFp biB0ZXh0IiwgdGhlbiB0aGUgU0lQIHNpZ25hbGluZyBuZWVkcyB0byBiZSBwcm90ZWN0ZWQvZW5j cnlwdGVkLiBCdXQsIGluIHRoYXQgY2FzZSwgaWYgSSBtYWtlIGEgcGhvbmUgY2FsbCB0byB5b3Us IGFuZCB0aGUgY2FsbCBpdHNlbGYgaXMgdmFsaWQsIHRoZW4gSSBzaG91bGQgbm90IHNlbmQgeW91 IHRoZSBvYXV0aDIgdG9rZW4gdW5sZXNzIGl0J3MgbWVhbnQgZm9yIHlvdSwgYmVjYXVzZSBvbmNl IHlvdSBkZWNyeXB0IHRoZSBzaWduYWxpbmcgeW91IHdpbGwgaGF2ZSBhY2Nlc3MgdG8gaXQuDQoN CiAgIFdoYXQgaXMgaW1wb3J0YW50IGlzIHRoYXQgYSBub24tYXV0aG9yaXplZCB1c2VyIHNob3Vs ZCBub3QgaGF2ZSBhY2Nlc3MgdG8gYSBub24tcHJvdGVjdGVkIG9hdXRoMiB0b2tlbi4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCiANCg0K From nobody Thu Jul 11 07:09:31 2019 Return-Path: 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 63AEF12010F for ; Thu, 11 Jul 2019 07:09:29 -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 3sbF04FVuHVa for ; Thu, 11 Jul 2019 07:09:27 -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 8B3D91200FB for ; Thu, 11 Jul 2019 07:09:27 -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 x6BE9ERB027931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jul 2019 10:09:14 -0400 To: "Olle E. Johansson" Cc: SIPCORE References: From: Paul Kyzivat Message-ID: Date: Thu, 11 Jul 2019 10:09:14 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-sip-token-authnz-02 - www and/or proxy auth X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 14:09:30 -0000 On 7/11/19 3:40 AM, Olle E. Johansson wrote: > > >> On 10 Jul 2019, at 17:39, Paul Kyzivat wrote: >> >> Ollie, >> >> On 7/10/19 9:21 AM, Olle E. Johansson wrote: >>> Why was proxy auth deemed out of scope for this document? >> >> Are you aware of any deployed uses of Proxy-Authenticate? I have never heard of any. > We do support it in both Asterisk and Kamailio. All my Kamailio installations during the years > use WWW auth for the registrar and proxy auth for calls. > > I do notice however that realm-based authentication with many challenges in the same > transaction is not widely supported, like your example below. I would be shocked if it was well supported given how ill-defined it is. >> IMO Proxy-Authenticate is underspecified, at least for some obscure cases. Consider: >> >> - Alice sends a request >> - It is challenged (Proxy-Authenticate) by P1 >> - Alice resends with credentials for P1 >> - P1 accepts credentials and forwards to P2 >> - P2 challenges for a different realm >> - For request to succeed, Alice will now have to >> resend the request with credentials for both P1 & P2 >> >> What logic should Alice use to decide what credentials to include in requests to this target, both for the immediate resend, and in future requests to the same target? > Well, in Asterisk chan_sip I added realm-based authentication in order to select credentials based on the realm. Can you clarify? Do you mean that after a challenge for a realm you can look up on the key ring for matching credentials for the realm of the challenge? Or do you mean that you can preemptively select credentials by realm to be added to a request before it is challenged based on somehow deriving a realm from properties of the request? > I don’t actually remember if we ever did run tests on this at SIPit. Early SNOM phones had realm-based auth so you could enter > credentials per realm and your example did work with those devices. >> >> And another one: >> >> - Alice sends a request >> - It is challenged (Proxy-Authenticate) by P1 >> - Alice resends with credentials for P1 >> - P1 forks to P2A and P2B >> - Both P2A and P2B challenge, with different realms >> >> >> Now what happens? Ideally P1 would aggregate the www-authenticate from both P2A and P2B. And then Alice would gather credentials for both and include them both in a retry, along with the credentials for P1. None of this is well defined. > I think it’s defined, but not implemented or tested much. Can you point me to where you think it is defined? >> I had suggested earlier that I wouldn't be too bent out of shape if this draft left that out of scope. OTOH, I would prefer that this all be well defined. Or else, if it isn't being used, then maybe Proxy-Authenticate should be deprecated. > That is not really “proxy auth” - you mean authentication in multiple realms in the same transaction. I think the two are closely intertwined. If proxies don't challenge then the only challenge is from the UAS. For a given request a challenge only has one realm. I guess it would be possible for a UAS to put multiple challenges, with different realms, in its response, but I find that unlikely. And if it does, then I *think* the expectation is that the UAC can choose to respond to any *one* of them and that should be sufficient. Proxies provide another source of challenges. Of course any one attempt at the request will only get one challenge. But with Proxy-Authenticate the UAC then knows that it will have to provide a matching credential for it in a subsequent try and then still be prepared for challenges by subsequent proxies and eventually the UAS. Each of these challenges may well be a different realm. > With Oauth2/OpenID connect that would be a very very complex scenario with multiple login pages, unless we can come up with some > level of chain of trust between the proxys, forwarding the access token or something else that likely will never be implemented… :-) I realize it would be complex, and probably contrived. That is why I think the notion of Proxy-Authenticate is half baked. > I would suggest forwarding the token - possibly signed by the first proxy - as a way forward, stating that all proxys in the service must be in the same authentticaion federation. I am not aware of any standards for this. Without those what you are describing is just a proprietary thing. This is further motivation for the sort of framework document I just proposed in another reply. Thanks, Paul > There is work witht OpenID Connect Federations that I haven’t started to look at yet. > > Cheers, > /O > > From nobody Thu Jul 11 07:17:34 2019 Return-Path: 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 9785112016D for ; Thu, 11 Jul 2019 07:17:33 -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 nzEIqY1_Tr4x for ; Thu, 11 Jul 2019 07:17:31 -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 4D47F120162 for ; Thu, 11 Jul 2019 07:16:50 -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 x6BEGjjq028460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Jul 2019 10:16:46 -0400 To: Christer Holmberg , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <56f4ed60-15b7-5bbe-63a5-10f447ae9094@alum.mit.edu> <178C3837-A525-4DF9-91D6-9659966D55C5@ericsson.com> From: Paul Kyzivat Message-ID: Date: Thu, 11 Jul 2019 10:16:45 -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: <178C3837-A525-4DF9-91D6-9659966D55C5@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 14:17:34 -0000 On 7/11/19 9:56 AM, Christer Holmberg wrote: > Hi, > >> This discussion is wandering in many directions. I don't know very much >> (anything?) about OAuth so it is pretty abstract for me. But what is >> becoming clear is that the people discussing this have *many* unstated >> assumptions about how this is to work and how it is to be used. And >> those don't appear to be well aligned with one another. >> >> I've been pushing for more of these assumptions (and implications) to be >> written down in the document. I still want that. But I'm beginning to >> think that the issue is bigger than what is likely to fit into this >> document as it is currently conceived. >> >> I think what may be needed is a framework document. (Perhaps "Framework >> for using OAuth(2?) with SIP", though maybe that isn't quite right. This >> would discuss why this is important, how it relates to the sip >> environment, how it fits into a broader authentication environment, etc. > > Let's try to document and clarify everything we need in this document. > > The draft tries to map the OAuth architecture to the SIP architecture. If something is unclear we should of course clarify it. Sure, go ahead and try. You keep answering my questions as replies to this email thread. But what is needed is for them to be answered in the document. Thanks, Paul From nobody Thu Jul 11 07:24:55 2019 Return-Path: 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 ; 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 ; 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 ; 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 , "sipcore@ietf.org" References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> From: Paul Kyzivat 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Jul 11 07:51:28 2019 Return-Path: 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 B35841200F9 for ; Thu, 11 Jul 2019 07:51: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 ZmfoUZW3_fmG for ; Thu, 11 Jul 2019 07:51:21 -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 EA759120153 for ; Thu, 11 Jul 2019 07:51:19 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 B9FD2A40; Thu, 11 Jul 2019 16:51:15 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_86C709ED-CB40-4265-B264-6073883B0496" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 16:51:15 +0200 In-Reply-To: Cc: SIPCORE To: Paul Kyzivat References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-sip-token-authnz-02 - www and/or proxy auth X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 14:51:26 -0000 --Apple-Mail=_86C709ED-CB40-4265-B264-6073883B0496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2019, at 16:09, Paul Kyzivat wrote: >=20 > On 7/11/19 3:40 AM, Olle E. Johansson wrote: >>> On 10 Jul 2019, at 17:39, Paul Kyzivat = wrote: >>>=20 >>> Ollie, >>>=20 >>> On 7/10/19 9:21 AM, Olle E. Johansson wrote: >>>> Why was proxy auth deemed out of scope for this document? >>>=20 >>> Are you aware of any deployed uses of Proxy-Authenticate? I have = never heard of any. >> We do support it in both Asterisk and Kamailio. All my Kamailio = installations during the years >> use WWW auth for the registrar and proxy auth for calls. >> I do notice however that realm-based authentication with many = challenges in the same >> transaction is not widely supported, like your example below. >=20 > I would be shocked if it was well supported given how ill-defined it = is. :-) I think another reason is that Internet federated SIP did never take = off=E2=80=A6 So you=E2=80=99re locked into one service platform on a = private network. >=20 >>> IMO Proxy-Authenticate is underspecified, at least for some obscure = cases. Consider: >>>=20 >>> - Alice sends a request >>> - It is challenged (Proxy-Authenticate) by P1 >>> - Alice resends with credentials for P1 >>> - P1 accepts credentials and forwards to P2 >>> - P2 challenges for a different realm >>> - For request to succeed, Alice will now have to >>> resend the request with credentials for both P1 & P2 >>>=20 >>> What logic should Alice use to decide what credentials to include in = requests to this target, both for the immediate resend, and in future = requests to the same target? >> Well, in Asterisk chan_sip I added realm-based authentication in = order to select credentials based on the realm. >=20 > Can you clarify? Do you mean that after a challenge for a realm you = can look up on the key ring for matching credentials for the realm of = the challenge? In Asterisk chan_sip you can either define a global list of realms that = we use for lookup or a per-service (=E2=80=9Cpeer=E2=80=9D) list. When = challenged, the code first tries to find the realm in the service definition then looks up the = global list to find a matching set of credentials to use. >=20 > Or do you mean that you can preemptively select credentials by realm = to be added to a request before it is challenged based on somehow = deriving a realm from properties of the request? No, magic doesn=E2=80=99t apply here :-) It=E2=80=99s after we=E2=80=99ve received the auth request. >=20 >> I don=E2=80=99t actually remember if we ever did run tests on this at = SIPit. Early SNOM phones had realm-based auth so you could enter >> credentials per realm and your example did work with those devices. >>>=20 >>> And another one: >>>=20 >>> - Alice sends a request >>> - It is challenged (Proxy-Authenticate) by P1 >>> - Alice resends with credentials for P1 >>> - P1 forks to P2A and P2B >>> - Both P2A and P2B challenge, with different realms >>>=20 >>>=20 >>> Now what happens? Ideally P1 would aggregate the www-authenticate = from both P2A and P2B. And then Alice would gather credentials for both = and include them both in a retry, along with the credentials for P1. = None of this is well defined. >> I think it=E2=80=99s defined, but not implemented or tested much. >=20 > Can you point me to where you think it is defined? Paul - are you asking me to dive into the mountain of SIP documents = again? :-) He he. I was checking this while helping with the updated = digest auth. Let me dig a bit and come back. I know I was thinking about receiving MULTIPLE auth headers with = different checksum algorithms in addition to receiving multiple auth = headers from a forking scenario. The first list is ordered too, so a user agent may end up with a lot of work. Found this in 3261, section 22.3 "If a request is forked (as described in Section 16.7 = ), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant. When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy servers that require authentication, each of which in turn will not forward the request until the originating UAC has authenticated itself in their respective realm. If the UAC does not provide credentials for each challenge, the proxy servers that issued the challenges will not forward requests to the UA where the destination user might be located, and therefore, the virtues of forking are largely lost. =E2=80=9C That section continues wiith additiional comments about forking. Side note: The order will become significant=E2=80=A6 >=20 >>> I had suggested earlier that I wouldn't be too bent out of shape if = this draft left that out of scope. OTOH, I would prefer that this all be = well defined. Or else, if it isn't being used, then maybe = Proxy-Authenticate should be deprecated. >> That is not really =E2=80=9Cproxy auth=E2=80=9D - you mean = authentication in multiple realms in the same transaction. >=20 > I think the two are closely intertwined. If proxies don't challenge = then the only challenge is from the UAS. Right, but there are situations where you get only *ONE* proxy auth = challenge too. > For a given request a challenge only has one realm. No, for a given request each proxy challenge has a unique realm until = the new draft comes into play. > I guess it would be possible for a UAS to put multiple challenges, = with different realms, in its response, but I find that unlikely. You can only have one WWW auth which is what a non-proxying UAS is = supposed to issue. But I guess you can write code that adds a list of proxy-auth and one www auth for different realms.=20 > And if it does, then I *think* the expectation is that the UAC can = choose to respond to any *one* of them and that should be sufficient. I think we=E2=80=99re outside of the RFCs now, discussing implementation = code=E2=80=A6 >=20 > Proxies provide another source of challenges. Of course any one = attempt at the request will only get one challenge. But with = Proxy-Authenticate the UAC then knows that it will have to provide a = matching credential for it in a subsequent try and then still be = prepared for challenges by subsequent proxies and eventually the UAS. = Each of these challenges may well be a different realm. Yep, and that=E2=80=99s covered by RFC 3261. >=20 >> With Oauth2/OpenID connect that would be a very very complex scenario = with multiple login pages, unless we can come up with some >> level of chain of trust between the proxys, forwarding the access = token or something else that likely will never be implemented=E2=80=A6 = :-) >=20 > I realize it would be complex, and probably contrived. That is why I = think the notion of Proxy-Authenticate is half baked. There is actually some work on this in the Oauth working group - trust = between resource servers. I will read up on it unless Rifaat wants to comment. >=20 >> I would suggest forwarding the token - possibly signed by the first = proxy - as a way forward, stating that all proxys in the service must be = in the same authentticaion federation. >=20 > I am not aware of any standards for this. Without those what you are = describing is just a proprietary thing. After reading the security update on Oauth, I realise thatt forwarding = an access token is a big NO NO. If we use the=20 bearer token as outlined in the current draft we must make a MUST not = forward statement on that header. >=20 > This is further motivation for the sort of framework document I just = proposed in another reply. Yes, a problem/requireiment statement would propably be a good thing. I = think there was a discussion on this list and at IETF SIPcore meetings about all this a very long time ago (as = expressed by Christer) which ended up in this draft and the other draft.=20= One group said that we can=E2=80=99t continue updating digest auth, we = need something new. Another group did not object but also wanted a quick way out of MD5, an easy upgrade for existing implementations. /O >=20 > Thanks, > Paul >=20 >> There is work witht OpenID Connect Federations that I haven=E2=80=99t = started to look at yet. >> Cheers, >> /O >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_86C709ED-CB40-4265-B264-6073883B0496 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Jul 2019, at 16:09, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On = 7/11/19 3:40 AM, Olle E. Johansson wrote:
On 10 Jul = 2019, at 17:39, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Ollie,

On 7/10/19 9:21 AM, Olle = E. Johansson wrote:
Why= was proxy auth deemed out of scope for this document?

Are you aware of any deployed = uses of Proxy-Authenticate? I have never heard of any.
We do support it in both Asterisk and Kamailio. = All my Kamailio installations during the years
use WWW = auth for the registrar and proxy auth for calls.
I do = notice however that realm-based authentication with many challenges in = the same
transaction is not widely supported, like your = example below.

I would be = shocked if it was well supported given how ill-defined it is.
:-)
I think another reason = is that Internet federated SIP did never take off=E2=80=A6 So you=E2=80=99= re locked into one service platform on a private network.


IMO Proxy-Authenticate is underspecified, at = least for some obscure cases. Consider:

- = Alice sends a request
- It is challenged = (Proxy-Authenticate) by P1
- Alice resends with = credentials for P1
- P1 accepts credentials and forwards = to P2
- P2 challenges for a different realm
- = For request to succeed, Alice will now have to
=  resend the request with credentials for both P1 & P2

What logic should Alice use to decide what = credentials to include in requests to this target, both for the = immediate resend, and in future requests to the same target?
Well, in Asterisk chan_sip I added realm-based = authentication in order to select credentials based on the realm.

Can you clarify? Do you mean that = after a challenge for a realm you can look up on the key ring for = matching credentials for the realm of the challenge?
In Asterisk chan_sip you can either = define a global list of realms that we use for lookup or a per-service = (=E2=80=9Cpeer=E2=80=9D) list. When challenged, the code = first
tries to find the realm in the service definition then = looks up the global list to find a matching set of credentials to = use.

Or do you mean that you can preemptively = select credentials by realm to be added to a request before it is = challenged based on somehow deriving a realm from properties of the = request?
No, magic doesn=E2=80=99t = apply here :-)
It=E2=80=99s after we=E2=80=99ve received the = auth request.


I don=E2=80=99t actually remember if we ever = did run tests on this at SIPit. Early SNOM phones had realm-based auth = so you could enter
credentials per realm and your example = did work with those devices.

And another one:

- = Alice sends a request
- It is challenged = (Proxy-Authenticate) by P1
- Alice resends with = credentials for P1
- P1 forks to P2A and P2B
-= Both P2A and P2B challenge, with different realms


Now what happens? Ideally P1 would aggregate = the www-authenticate from both P2A and P2B. And then Alice would gather = credentials for both and include them both in a retry, along with the = credentials for P1. None of this is well defined.
I think it=E2=80=99s defined, but not = implemented or tested much.

Can = you point me to where you think it is defined?
Paul - are you asking me to dive = into the mountain of SIP documents again? :-) He he. I was checking this = while helping with the updated digest auth. Let me dig a bit and come = back.
I know I was thinking about receiving MULTIPLE auth = headers with different checksum algorithms in addition to receiving = multiple auth headers from a forking scenario. The first = list
is ordered too, so a user agent may end up with a lot of = work.

Found this in 3261, section = 22.3

"If a request is forked (as described = in Section = 16.7), = various proxy
   servers and/or UAs may wish to challenge the UAC.  In this =
case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.
      When a proxy server issues a challenge in response to a =
request,
      it will not proxy the request until the UAC has retried the
      request with valid credentials.  A forking proxy may forward a
      request simultaneously to multiple proxy servers that require
      authentication, each of which in turn will not forward the request
      until the originating UAC has authenticated itself in their
      respective realm.  If the UAC does not provide credentials =
for
     each challenge, the proxy servers that issued the challenges =
will

      not =
forward requests to the UA where the destination user might be
      located, and therefore, the virtues of forking are largely =
lost.

=E2=80=9C
That section continues wiith = additiional comments about forking.

Side note: The order will become = significant=E2=80=A6



I had suggested earlier that I wouldn't be too = bent out of shape if this draft left that out of scope. OTOH, I would = prefer that this all be well defined. Or else, if it isn't being used, = then maybe Proxy-Authenticate should be deprecated.
That is not really =E2=80=9Cproxy auth=E2=80=9D = - you mean authentication in multiple realms in the same transaction.

I think the two are closely = intertwined. If proxies don't challenge then the only challenge is from = the UAS.
Right, but there are situations where = you get only *ONE* proxy auth challenge too.

For a given request a challenge only has one = realm.
No, for a given request each proxy = challenge has a unique realm until the new draft comes into = play.

I guess it would be possible for a UAS to = put multiple challenges, with different realms, in its response, but I = find that unlikely.
You can only have one WWW = auth which is what a non-proxying UAS is supposed to issue. But I guess = you can write code that adds a list of
proxy-auth and one www = auth for different realms. 

And if it = does, then I *think* the expectation is that the UAC can choose to = respond to any *one* of them and that should be sufficient.
I think we=E2=80=99re outside of the = RFCs now, discussing implementation code=E2=80=A6


Proxies provide another source of challenges. = Of course any one attempt at the request will only get one challenge. = But with Proxy-Authenticate the UAC then knows that it will have to = provide a matching credential for it in a subsequent try and then still = be prepared for challenges by subsequent proxies and eventually the UAS. = Each of these challenges may well be a different realm.
Yep, and that=E2=80=99s covered by = RFC 3261.


With Oauth2/OpenID connect that would be a very = very complex scenario with multiple login pages, unless we can come up = with some
level of chain of trust between the proxys, = forwarding the access token or something else that likely will never be = implemented=E2=80=A6 :-)

I = realize it would be complex, and probably contrived. That is why I think = the notion of Proxy-Authenticate is half baked.
There is actually some work on this = in the Oauth working group - trust between resource servers. I will read = up on it
unless Rifaat wants to comment.

I would = suggest forwarding the token - possibly signed by the first proxy - as a = way forward, stating that all proxys in the service must be in the same = authentticaion federation.

I = am not aware of any standards for this. Without those what you are = describing is just a proprietary thing.
After reading the security update on = Oauth, I realise thatt forwarding an access token is a big NO NO. =  If we use the 
bearer token as outlined in the = current draft we must make a MUST not forward statement on that = header.

This is further motivation for = the sort of framework document I just proposed in another reply.
Yes, a problem/requireiment = statement would propably be a good thing. I think there was a discussion = on this list and
at IETF SIPcore meetings about all this a = very long time ago (as expressed by Christer) which ended up in this = draft and the other draft. 
One group said that we = can=E2=80=99t continue updating digest auth, we need something new. = Another group did not object but also wanted
a quick way out = of MD5, an easy upgrade for existing implementations.

/O

= Thanks,
Paul

There is work witht = OpenID Connect Federations that I haven=E2=80=99t started to look at = yet.
Cheers,
/O
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_86C709ED-CB40-4265-B264-6073883B0496-- From nobody Thu Jul 11 08:00:22 2019 Return-Path: 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 C67F71202AC for ; Thu, 11 Jul 2019 08:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MbuLvohJKT9T for ; Thu, 11 Jul 2019 08:00:17 -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 D9B3112028B for ; Thu, 11 Jul 2019 08:00:11 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 329F5A40; Thu, 11 Jul 2019 17:00:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> Date: Thu, 11 Jul 2019 17:00:05 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:00:20 -0000 > On 11 Jul 2019, at 14:07, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>>> The tokens generally, but if I understand it right not always, = are JWT structures that contain various data. In=20 >>>>>>>> OpenID connect both the access and identity token are JWTs. >>>>>>>> We can either specify specific claims that are standardised = for various SIP functions or let that be open for=20 >>>>>>>> the SIP implementors to specify or a combination.=20 >>>>>>>=20 >>>>>>> For backward compatibility, we should at least let SIP = implementors specify >>>>>> Maybe, but at least we should write something about the usage of = claims and scopes. >>>>>> I think a base level for this draft is specifying a way to say = =E2=80=9Cthis access token is valid for SIP usage=E2=80=9D or >>>>>> =E2=80=9Cthis is also a SIP identity" >>>>>=20 >>>>> Perhaps we can add some text about scope and claims, but I don't = want to mandate usage of specific values, because that=20 >>>>> may not be backward compatible with existing implementations = using JWT.=20 >>>>=20 >>>> We can mandate *if* the access token is a jwt (and there=E2=80=99s = an identity token like OpenID Connect).=20 >>>=20 >>> It may not work with existing implementations that DO use JWT = access tokens (not sure whether they use OpenID Connect, though). >>=20 >> Ok, you are making me interested - what are these implementations? >=20 > Unfortunately I am not able to give information regarding that. >=20 >> When writing a new standard document, should we really be blocked by = pre-standard implementations? I would assume that we >> should be inspired by them, learn by their experiences, but not be = hindered by them.=20 >=20 > The implementations are based on earlier versions of the draft. >=20 > And, yes, there is the old saying that one should not deploy a = draft before the draft becomes RFC.=20 >=20 > But, in this case, the first version of Rifaat's individual draft = was submitted in 2014. Then, for whatever reason, it took 3(!) years = before it got adopted, and after that we have so far worked on it for = two years. How long is one expected to wait for an RFC before = deploying??? >=20 > Of course, if something is broken we need to fix it. But, I don't = think what you suggest is fixing something that is broken, it is adding = new functionality. And, I have no problem with that, as long as it is = backward compatible. >=20 > =20 Christer,=20 I=E2=80=99ve been thinking about this. We are almost in the same = situation as the old discussion about the DIversion: header. While = waiting for another better solution, that=E2=80=99s what all of us implemented. = Then came SIP HIstory and we had no docs to refer to for = interoperability=E2=80=A6 The old draft was later published as an informational RFC. Can we look into the same solution? Publishing the current draft wiith = minor nits as an informational RFC that your implementation is compliant = with and then work on something more up-to-par with current OAuth2/OpenID = connect BCPs and thinking? As an example: When reading the docs I see ways of protecting the access = token so that only a specific service (read SIP domain) may decrypt and use it. That way we don=E2=80=99t need to disallow forwarding of SIP = messages with a bearer token, as the token will be useless beyond that = point. Starting to go down that road, wlil definitely mean that we leave the = implementation you currently have behind. And that is just one issue. The other is having a parsable access token, which I think = would be a requirement to follow the BCP and propably to get through the hole security audit for any standard-track RFC publication. What do you think? Is this a way forward? /O From nobody Thu Jul 11 08:03:20 2019 Return-Path: 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 50FFB1202F3 for ; Thu, 11 Jul 2019 08:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 S0OaT4_quwO9 for ; Thu, 11 Jul 2019 08:03:08 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on060a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::60a]) (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 EF9C3120303 for ; Thu, 11 Jul 2019 08:03:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CFYOBNfOa+QWt/j/GII5f41jZQ2aS6hifs+Opv8VxQf287qn5qUlLA0N3/U2PtgIAVufno1H4YxKXtIxtlz5IrHh5sCLmDA7v/WBLd1nJUA0lV6bUV7yzAXX96j+gjtlZzQkCq+7/LBDx+p9mMhZgZFSFwCPxe0+Dz+/pqMoJmonm4iItkorOf7DflzI6nYyNXkaJVkcdeSSUh9T1Idvk/GV/Av3awEOeEbWOBd5bDI1+6JrkeVG0eXoWR/ykvuQ2DTVv/2JqOnw5EnPa6o60NDqD8WHoP8Ue+GorjhsFw4KHnB5RKkScEEVGPLEoecMORs+2SJcmARuOHbUuaVPdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PKiw2PD+K2nTsyeywMK4sQVUezZt5fX0hYNHsKMyAyo=; b=FkkKNJzFCwGE1tiCW29TYHAmHBy5CPObRGOPkalBEa0Qd4ylKyD7l00KKLGXddDyrPgyRUBjuLDFTLUgNLH9d4IKsx/8KG4tnXvXJ6AdsjhXH7WBH+SIKQGcZOoRKJnwz5cu3eLyWPD49F4Q27bX/q2BIxBC4736vw/x5QE7gQx/pun+OhdKW8saZIsVbG6yoK2AwN8Ne1gQNERaTlp79oZF41cQG+nN2nsIPwQSfadMPTIsgxGU56eX6AvZRcuZ9iCp/05kX0e+9e8DMEDpmxTcAhzEgD1hGCBf8XGN8zoy0h7EibP5PBYFPHFV/AcJjcXLr6tG8xU/D/7WfxvvTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PKiw2PD+K2nTsyeywMK4sQVUezZt5fX0hYNHsKMyAyo=; b=rJhQtfzxsaSIJ71zlYLYsFaL/x8zuAhJaxBKnaqC0AkpyUr3FyAHsld8eLNOYdbLBtmFWgscC0O3hKVnVigaGZfX08qXOv8TAryEkyPqp4cNQW81+EGkp8zojxvsmV5mB3l+qjbNO/G4FrFTERhweQt8tMDOUqDoPmZPVuPC2Os= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4188.eurprd07.prod.outlook.com (20.176.166.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.9; Thu, 11 Jul 2019 15:02:59 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 15:02:59 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgIAAP24AgAA3OYD//9JzgAAHn32A Date: Thu, 11 Jul 2019 15:02:59 +0000 Message-ID: <7AEC21E0-B0A6-4303-B936-F183ED6EC05D@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> <64b7d784-3f34-dd11-d7e2-b22fe621cd70@alum.mit.edu> In-Reply-To: <64b7d784-3f34-dd11-d7e2-b22fe621cd70@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42ab8d2b-e5e2-4838-d7fb-08d70610dd64 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4188; x-ms-traffictypediagnostic: HE1PR07MB4188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(396003)(39860400002)(136003)(199004)(189003)(66946007)(14444005)(256004)(76116006)(186003)(66446008)(64756008)(66556008)(102836004)(14454004)(66476007)(26005)(86362001)(71190400001)(5660300002)(33656002)(2906002)(66066001)(2501003)(6506007)(229853002)(6116002)(3846002)(316002)(81156014)(2616005)(6512007)(2171002)(44832011)(476003)(305945005)(25786009)(8676002)(6486002)(478600001)(110136005)(76176011)(6246003)(71200400001)(446003)(99286004)(36756003)(53936002)(8936002)(81166006)(68736007)(58126008)(6436002)(486006)(11346002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4188; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YXRcpAabLNm49D8FnBhdCqh6fhjSOOeb7J4WvaQTPU+9l0kukE9fXDZPbYfWXC/r569Ta6TX4+bpfgm8t9w0UgKE6l8KMts2BSnfJ6gans12IKYFmzHXItwGykcTCBeqnnS84bvI/Ol3rtHfZ/VI80a1MTcktZFw+CiBCHGW4V5gYA2nQESZvOEVWagqAwpNyt2JRYTWhI51fpNGAETRF0qWs7gfkHrLrHzzjRWOXB0zFmG/JAMEwuDX7zm5xAZJ4633mmeJpBnBvEEhTizMHHfRgWz1wGzy7d5VfiWSrJjtFuitBgx1K+L5Wc9HfwYC1MX0riHiYLbcIP6B7PH4LDjbHsADwrsv40AJnaYkDxGkGpot1d1hwXgDH6vMB1xjI2BoJ9KHAmitfOZ7h2bLcjDHQNVOpxg2zNMsTdDcFrg= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42ab8d2b-e5e2-4838-d7fb-08d70610dd64 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:02:59.7972 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4188 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:03:19 -0000 SGksDQoNCiAgICA+Pj4+Pj4gQWxsIEkgYW0gc2F5aW5nIGlzIHRoYXQgb25lIHNob3VsZCBub3Qg c2VuZCBhIHRva2VuIHRvIHNvbWVvbmUgdGhhdCBpdCBoYXMgTk9UIGJlZW4gaXNzdWVkIGZvci4N CiAgICA+Pj4+Pg0KICAgID4+Pj4+ICAgICBUaGVuIHlvdSBhcmUgc2F5aW5nIHRoYXQgYSB0b2tl biBzaG91bGQgKm5ldmVyKiBiZSBpbmNsdWRlZCBpbiBhIHJlcXVlc3QNCiAgICA+Pj4+PiAgICAg dG8gYSB0YXJnZXQgZm9yIHdoaWNoIHlvdSBoYXZlIG5vdCByZWNlaXZlZCBhIGNoYWxsZW5nZSBz b21lIHRpbWUgaW4gdGhlDQogICAgPj4+Pj4gICAgIHBhc3QuDQogICAgPj4+Pj4NCiAgICA+Pj4+ PiAgICAgVGhhdCBpcyBhIGJpdCBleHRyZW1lLCBidXQgSSBndWVzcyB5b3UgY2FuIHNwZWNpZnkg dGhhdCBpZiB5b3UgdGhpbmsgaXQNCiAgICA+Pj4+PiAgICAgaXMgdGhlIHJpZ2h0IHRoaW5nIHRv IGRvLg0KICAgID4+Pj4NCiAgICA+Pj4+IFRoYXQgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg Z2VuZXJpYyBPQXV0aCBzZWN1cml0eSBjb25zaWRlcmF0aW9uczogeW91IGRvbid0IGdpdmUgYSB0 b2tlbiB0byBzb21lb25lIGl0IHdhcyBub3QgaW50ZW5kZWQgZm9yLg0KICAgID4+Pj4NCiAgICA+ Pj4+IE9mIGNvdXJzZSwgaWYgeW91IGtub3cgKGJhc2VkIG9uIHdoYXRldmVyIGNvbmZpZ3VyYXRp b24vcG9saWN5KSB0aGF0IGl0J3Mgb2sgdG8gZ2l2ZSB0aGUgdG9rZW4gdG8gdGhlIHRhcmdldCBJ IGd1ZXNzIHlvdSBjb3VsZCBkbyBpdC4NCiAgICA+Pj4+DQogICAgPj4+Pj4gICAgIEJ1dCBub3Rl IHRoYXQgdGhpcyBsb2dpYyB3b24ndCBhbHdheXMgd29yayBmb3IgUHJveHktQXV0aGVudGljYXRl LiBZb3UNCiAgICA+Pj4+PiAgICAgKm1pZ2h0KiBrbm93IHRoYXQgYSBwYXJ0aWN1bGFyIHByb3h5 IHdpbGwgYmUgdmlzaXRlZCAoaWYgaXQgaXMgbWVudGlvbmVkDQogICAgPj4+Pj4gICAgIG9uIGEg Um91dGUgaGVhZGVyKSwgYnV0IGl0IGlzIHByZXR0eSBjb21tb24gZm9yIHRoZSByZXF1ZXN0IHRv IHZpc2l0DQogICAgPj4+Pj4gICAgIHByb3hpZXMgdW5rbm93biAoYXQgbGVhc3QgaW4gYWR2YW5j ZSkgdG8gdGhlIFVBQy4NCiAgICA+Pj4+DQogICAgPj4+PiBJdCBpcyBpbXBvcnRhbnQgdG8gcmVt ZW1iZXIgdGhhdCwgc2luY2UgdGhlIHRva2VuIG5lZWRzIHRvIGJlIHByb3RlY3RlZCwgYSBwcm94 eSBuZWVkcyB0byBoYXZlIHRoZQ0KICAgID4+Pj4gYXNzb2NpYXRlZCBwcm90ZWN0aW9uIGNyZWRl bnRpYWxzIHRvIGJlIGFibGUgdG8gYWNjZXNzIHRoZSB0b2tlbi4NCiAgICA+Pj4NCiAgICA+Pj4g SSdtIGxvc3QgaGVyZS4gSG93IGlzIHRoZSB0b2tlbiBwcm90ZWN0ZWQ/IElzIGl0IGJlY2F1c2Ug aXQgaXMgcGFzc2VkIGJ5DQogICAgPj4+IHJlZmVyZW5jZSwgYW5kIG90aGVyIGNyZWRlbnRpYWxz IGFyZSBuZWVkZWQgdG8gZGVyZWZlcmVuY2UgaXQ/IE9yIGlzIGl0DQogICAgPj4+IHBhc3NlZCBi eSB2YWx1ZSBidXQgZW5jcnlwdGVkPw0KICAgID4+IA0KICAgID4+ICAgICAgVGhhdCBkZXBlbmRz IG9uIGhvdyB5b3VyIHByb3RlY3QgaXQuDQogICAgPj4gDQogICAgPj4gICAgICBJZiB0aGUgb2F1 dGgyIHRva2VuIGl0c2VsZiBpcyBlbmNyeXB0ZWQsIGFuZCBvbmx5IGF1dGhvcml6ZWQgZW50aXRp ZXMgY2FuIGRlY3J5cHQgaXQsIHRoZW4gSSBndWVzcyBpdCBkb2VzIA0KICAgID4+ICAgICAgbm90 IG1hdHRlciBpZiBhIG5vbi1hdXRob3JpemVkIHVzZXIgZ2V0cyBpdCwgYXMgaXQgd2lsbCBub3Qg YmUgYWJsZSB0byB1c2UgaXQuDQogICAgPg0KICAgID4gSXMgdGhpcyBnb2luZyB0byBiZSBkZWZp bmVkLCBvciBpcyB0aGUgaW50ZW50IHRvIGxlYXZlIGl0IG9wZW4/DQogICAgPiBJIGRvbid0IHVu ZGVyc3RhbmQgaG93IHRoaW5ncyBjYW4gd29yayBpZiBpdCBpcyBsZWZ0IG9wZW4uDQogICAgDQog ICAgV2Ugbm9ybWFsbHkgZG9uJ3Qgc3BlY2lmeSBIT1cgdG8gcHJvdGVjdCBTSVAgaW5mb3JtYXRp b24sIGJlY2F1c2UgaXQgY2FuIGRvbmUgaW4gIG1hbnkgZGlmZmVyZW50IHdheXMsIHdlIG9ubHkg c2F5IHdoZW4gDQogICAgc29tZSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm90 ZWN0ZWQuDQoNCiAgICBBbHNvLCBpbiB0aGUgY2FzZSBvZiBvYXV0aDIgdG9rZW5zLCBhcyB0aGV5 IGNhbiBiZSBlbmNvZGVkIGluIG1hbnkgZGlmZmVyZW50IHdheXMsIHNvbWUgb2Ygd2hpY2ggaGF2 ZSB0aGVpciBvd24gYnVpbHQtaW4gcHJvdGVjdGlvbnMgKGUuZy4sIEpXVCksIHdlIGNhbid0IHNw ZWNpZnkgYSBzaW5nbGUgc29sdXRpb24gdGhhdCB3b3JrcyBmb3IgYWxsLiBXZSBjYW4gb25seSBz cGVjaWZ5IHdoYXQgc2VjdXJpdHkgY2hhcmFjdGVyaXN0aWNzIG11c3QgYmUgZnVsZmlsbGVkLg0K DQogICAgPj4gIEJ1dCwgaWYgdGhlIG9hdXRoMiB0b2tlbiBpcyBzZW50IGluICJwbGFpbiB0ZXh0 IiwgdGhlbiB0aGUgU0lQIHNpZ25hbGluZyBuZWVkcyB0byBiZSBwcm90ZWN0ZWQvZW5jcnlwdGVk LiANCiAgICA+PiAgQnV0LCBpbiB0aGF0IGNhc2UsIGlmIEkgbWFrZSBhIHBob25lIGNhbGwgdG8g eW91LCBhbmQgdGhlIGNhbGwgaXRzZWxmIGlzIHZhbGlkLCB0aGVuIEkgc2hvdWxkIG5vdCBzZW5k IHlvdSB0aGUgDQogICAgPj4gIG9hdXRoMiB0b2tlbiB1bmxlc3MgaXQncyBtZWFudCBmb3IgeW91 LCBiZWNhdXNlIG9uY2UgeW91IGRlY3J5cHQgdGhlIHNpZ25hbGluZyB5b3Ugd2lsbCBoYXZlIGFj Y2VzcyB0byBpdC4NCiAgICA+PiANCiAgICA+PiAgICAgV2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhh dCBhIG5vbi1hdXRob3JpemVkIHVzZXIgc2hvdWxkIG5vdCBoYXZlIGFjY2VzcyB0byBhIG5vbi1w cm90ZWN0ZWQgb2F1dGgyIHRva2VuLg0KICAgID4NCiAgICA+IEkgZG9uJ3Qgc2VlIGhvdyB0aGlz IGNhbiB3b3JrLiBIb3cgZG9lcyB0aGUgVUFDICprbm93KiBpZiB0aGUgc2VydmVyIGl0IA0KICAg ID4gaXMgc2VuZGluZyBjcmVkZW50aWFscyB0byBpcyBhdXRob3JpemVkIHRvIHJlY2VpdmUgdGhv c2UgY3JlZGVudGlhbHM/DQogICAgPiAgICANCiAgICA+IEluIGdlbmVyYWwgdGhlIFVBQyBkb2Vz bid0IGtub3cgd2hhdCBwcm94aWVzIGFuZCBVQVMgdGhlIHJlcXVlc3Qgd2lsbCANCiAgICA+IHZp c2l0LiBBbGwgaXQga25vd3MgaXMgdGhlIHJlcXVlc3QtVVJJLiBTaW5jZSB0aGVyZSBnZW5lcmFs bHkgaXNuJ3QgYSANCiAgICA+IGRpcmVjdCBjb25uZWN0aW9uIGZyb20gVUFDIHRvIFVBUyBUTFMg YXV0aGVudGljYXRpb24gZG9lc24ndCBoZWxwLg0KIA0KICAgIEluIHRoYXQgY2FzZSB5b3Ugc2hv dWxkIHVzZSBlbmNvZGluZyB3aXRoIGJ1aWx0LWluIHByb3RlY3Rpb24sIHRoYXQgb25seSBhdXRo b3JpemVkIGVudGl0aWVzIGFyZSBhYmxlIHRvIGRlY3J5cHQuIEpXVCBwcm92aWRlcyANCiAgICBz dWNoIHByb3RlY3Rpb24sIHNvIEkgYXNzdW1lIGl0IHdvdWxkbid0IG1hdHRlciBpZiBhIG5vbi1h dXRob3JpemVkIGVudGl0eSByZWNlaXZlcyBpdC4gQW5kLCBhcyBmYXIgYXMgdGhlIE9BdXRoIHRv a2VuIGlzIGNvbmNlcm5lZCwgeW91IGRvbid0IGhhdmUgdG8gcHJvdGVjdCB0aGUgU0lQIHNpZ25h bGluZyB3aGVuIHVzaW5nIEpXVCAodGhlcmUgbWF5IG9mIGNvdXJzZSBiZSBvdGhlciByZWFzb25z IHdoeSB5b3UgbmVlZCB0byBwcm90ZWN0IHRoZSBTSVAgc2lnbmFsaW5nKS4NCg0KICAgUmVnYXJk cywNCg0KICAgQ2hyaXN0ZXINCg0KDQogICAgDQoNCg== From nobody Thu Jul 11 08:13:41 2019 Return-Path: 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 50832120134 for ; Thu, 11 Jul 2019 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 RsEgEkPEuckI for ; Thu, 11 Jul 2019 08:13:37 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89FB12004E for ; Thu, 11 Jul 2019 08:13:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EP8mBhI64/8GbVOajEQbK2zPduLKtx8U4yWsJV6u6uuFl8XB2JsyXyUzrwAt+JS44phsl6E87pCEwtJMGzcuIgPMwkADa2AafdAKB6e2SCFw0FJLg6MpVOrgVZ8ctLAKt4Il1BP0fkX5G/tXX1NTK72ZhAucMLL231C6oELBzooGEOVgEQR5R9aIDHqf6sRMQmoC8iUnuLpjrW9aFgo2gbIu0QDVSH0m2rMuQmJPymwu3ijBKuW0Yl0McOkfOxFvDVlr3Zf2eHaSO3D04a4IkWSpa8tWMHweNd4D+4aBevwc21e/pwW3NH4KOv7gBJhhzbtISsaAJfYrks2T3K1Naw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i6b/CHOwAoMjmQfPGBzDJO5DlAj6c963ABd2QeJmZrs=; b=XWbe6Iuh/i9e5UofX1fA+TDR+2z7O9oEg/B49J/Di4/jKer42gU3lG+ZjbNpSeNG66G6nv4gTdqyNR7akHuBYuMFp7uEm9ZaBGjds34paLaE30Mrb+5AQgmOp5Qpwa3qHxap79ksPAgSuxh6dKCk4MsxgcXt2iLNcT+ucfTqxFFCuZmGvduFilJWpQwX0r+azWrakuVQMgOurnb3CHl/lBv+CFs7ZSxrGdj2FviHTW4RVLq4cROsj6FvynaeVczsaqf+bledqvCf5KCYRvE/fsAt3kUl4k9J8B8Y7pH5OEhVzwdXuDz3dPeoqD2SMDCaEPlMYHgfoEBi1z0HVCrGXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i6b/CHOwAoMjmQfPGBzDJO5DlAj6c963ABd2QeJmZrs=; b=hjtCdj6lQZVX6XmVrrO2BXQMwC58wkpFaMv/h643XMFd/YCWcHQqKDuc8E52OY0RbhOjYphz3wuvIr7WtxikooVtHa26A3914vI9d1TAAuKjaum9Mn+m+uuoPoQHMHR4IzAY/bbSZ8t2iT5KuzCPYrhXHzDGIdwZB8gA1ihTMAo= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3290.eurprd07.prod.outlook.com (10.170.246.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 15:13:33 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 15:13:33 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAA3WQD///38gIAANg6A Date: Thu, 11 Jul 2019 15:13:33 +0000 Message-ID: <8A712633-C587-40B7-9D8A-63AA9B636580@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d72ef25f-6a42-4631-f0ff-08d706125745 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3290; x-ms-traffictypediagnostic: HE1PR07MB3290: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(39860400002)(376002)(136003)(189003)(199004)(478600001)(8676002)(256004)(186003)(14454004)(8936002)(81166006)(81156014)(6436002)(25786009)(6116002)(76176011)(14444005)(3846002)(6506007)(102836004)(26005)(7736002)(305945005)(486006)(86362001)(44832011)(99286004)(446003)(11346002)(229853002)(6916009)(4326008)(2616005)(476003)(6486002)(76116006)(66446008)(66556008)(53936002)(66066001)(36756003)(64756008)(66476007)(71200400001)(6512007)(6246003)(33656002)(5660300002)(316002)(58126008)(71190400001)(68736007)(2906002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3290; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CyEkWotskl8WzlNbtUDB0jf8t2wLlvWbz6GRK4f0j1nzeiT5UveSMhxCXEVzs3ybq7vOmIO+gBbsZIxcgTF3M6mJnuOBeQqZ5zf+TqdJ/rpW8G2Y9c9dMTeXOncYOsfZ7GsPSYXG0LpzHKnKXWMKLzdCaZwl2RbqVfjUYUMwWeBzpY8S/fbWRFxJoP/Oiu2eebKDs2foGaEziA3nHUawb5XwQ3Mxga3M/pgMhHxPzd47vffb8kOlY2e9IVIHtQb4bJVYwDDtPqb7HSwogEOXr+KUGKSVOEF9ociMqCr5BdAKNURLK1jUMCarxBGM2Hj4ZFoUq+UvJjHiuPtiTKvlk4yCVzHPqk0Fncw1yg6zgEfGl0NL9YE60v2DYRbkH9g07F16/j0VUooiuV3O1jCxVpaJ/Yf/caGjJekEM8vUYOM= Content-Type: text/plain; charset="utf-8" Content-ID: <49710FC0358B284C86EBA058429E530B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d72ef25f-6a42-4631-f0ff-08d706125745 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:13:33.8454 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3290 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:13:40 -0000 SGksDQoNCiAgICA+Pj4+Pj4+Pj4gVGhlIHRva2VucyBnZW5lcmFsbHksIGJ1dCBpZiBJIHVuZGVy c3RhbmQgaXQgcmlnaHQgbm90IGFsd2F5cywgYXJlIEpXVCBzdHJ1Y3R1cmVzIHRoYXQgY29udGFp biB2YXJpb3VzIGRhdGEuIEluIA0KICAgID4+Pj4+Pj4+PiBPcGVuSUQgY29ubmVjdCBib3RoIHRo ZSBhY2Nlc3MgYW5kIGlkZW50aXR5IHRva2VuIGFyZSBKV1RzLg0KICAgID4+Pj4+Pj4+PiBXZSBj YW4gZWl0aGVyIHNwZWNpZnkgc3BlY2lmaWMgY2xhaW1zIHRoYXQgIGFyZSBzdGFuZGFyZGlzZWQg Zm9yIHZhcmlvdXMgU0lQIGZ1bmN0aW9ucyBvciBsZXQgdGhhdCBiZSBvcGVuIGZvciANCiAgICA+ Pj4+Pj4+Pj4gdGhlIFNJUCBpbXBsZW1lbnRvcnMgdG8gc3BlY2lmeSBvciBhIGNvbWJpbmF0aW9u LiANCiAgICA+Pj4+Pj4+PiANCiAgICA+Pj4+Pj4+PiBGb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0 eSwgd2Ugc2hvdWxkIGF0IGxlYXN0IGxldCBTSVAgaW1wbGVtZW50b3JzIHNwZWNpZnkNCiAgICA+ Pj4+Pj4+IE1heWJlLCBidXQgYXQgbGVhc3Qgd2Ugc2hvdWxkIHdyaXRlIHNvbWV0aGluZyBhYm91 dCB0aGUgdXNhZ2Ugb2YgY2xhaW1zIGFuZCBzY29wZXMuDQogICAgPj4+Pj4+PiBJIHRoaW5rIGEg YmFzZSBsZXZlbCBmb3IgdGhpcyBkcmFmdCBpcyBzcGVjaWZ5aW5nIGEgd2F5IHRvIHNheSDigJx0 aGlzIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCBmb3IgU0lQIHVzYWdl4oCdIG9yDQogICAgPj4+Pj4+ PiDigJx0aGlzIGlzIGFsc28gYSBTSVAgaWRlbnRpdHkiDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+ PiAgUGVyaGFwcyB3ZSBjYW4gYWRkIHNvbWUgdGV4dCBhYm91dCBzY29wZSBhbmQgY2xhaW1zLCBi dXQgSSBkb24ndCB3YW50IHRvIG1hbmRhdGUgdXNhZ2Ugb2Ygc3BlY2lmaWMgdmFsdWVzLCBiZWNh dXNlIHRoYXQgDQogICAgPj4+Pj4+ICBtYXkgbm90IGJlIGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0 aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgSldULiANCiAgICA+Pj4+PiANCiAgICA+ Pj4+PiBXZSBjYW4gbWFuZGF0ZSAqaWYqIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYSBqd3QgKGFuZCB0 aGVyZeKAmXMgYW4gaWRlbnRpdHkgdG9rZW4gbGlrZSBPcGVuSUQgQ29ubmVjdCkuIA0KICAgID4+ Pj4gDQogICAgPj4+PiAgIEl0IG1heSBub3Qgd29yayB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0 aW9ucyB0aGF0IERPIHVzZSBKV1QgYWNjZXNzIHRva2VucyAobm90IHN1cmUgd2hldGhlciB0aGV5 IHVzZSBPcGVuSUQgQ29ubmVjdCwgdGhvdWdoKS4NCiAgICA+Pj4gDQogICAgPj4+IE9rLCB5b3Ug YXJlIG1ha2luZyBtZSBpbnRlcmVzdGVkIC0gd2hhdCBhcmUgdGhlc2UgaW1wbGVtZW50YXRpb25z Pw0KICAgID4+IA0KICAgID4+ICAgVW5mb3J0dW5hdGVseSBJIGFtIG5vdCBhYmxlIHRvIGdpdmUg aW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoYXQuDQogICAgPj4gDQogICAgPj4+IFdoZW4gd3JpdGlu ZyBhIG5ldyBzdGFuZGFyZCBkb2N1bWVudCwgc2hvdWxkIHdlIHJlYWxseSBiZSBibG9ja2VkIGJ5 IHByZS1zdGFuZGFyZCBpbXBsZW1lbnRhdGlvbnM/IEkgd291bGQgYXNzdW1lIHRoYXQgd2UNCiAg ICA+Pj4gc2hvdWxkIGJlIGluc3BpcmVkIGJ5IHRoZW0sIGxlYXJuIGJ5IHRoZWlyIGV4cGVyaWVu Y2VzLCBidXQgbm90IGJlIGhpbmRlcmVkIGJ5IHRoZW0uIA0KICAgID4+IA0KICAgID4+ICAgIFRo ZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGJhc2VkIG9uIGVhcmxpZXIgdmVyc2lvbnMgb2YgdGhlIGRy YWZ0Lg0KICAgID4+IA0KICAgID4+ICAgIEFuZCwgeWVzLCB0aGVyZSBpcyB0aGUgb2xkIHNheWlu ZyB0aGF0IG9uZSBzaG91bGQgbm90IGRlcGxveSBhIGRyYWZ0IGJlZm9yZSB0aGUgZHJhZnQgYmVj b21lcyBSRkMuIA0KICAgID4+IA0KICAgID4+ICAgIEJ1dCwgaW4gdGhpcyBjYXNlLCB0aGUgZmly c3QgdmVyc2lvbiBvZiBSaWZhYXQncyBpbmRpdmlkdWFsIGRyYWZ0IHdhcyBzdWJtaXR0ZWQgaW4g MjAxNC4gVGhlbiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgaXQgdG9vayAzKCEpIHllYXJzIGJlZm9y ZSBpdCANCiAgICA+PiAgIGdvdCBhZG9wdGVkLCBhbmQgYWZ0ZXIgdGhhdCB3ZSBoYXZlIHNvIGZh ciB3b3JrZWQgb24gaXQgZm9yIHR3byB5ZWFycy4gSG93IGxvbmcgaXMgb25lIGV4cGVjdGVkIHRv IHdhaXQgZm9yIGFuIFJGQyBiZWZvcmUgZGVwbG95aW5nPz8/DQogICAgPj4gDQogICAgPj4gICAg IE9mIGNvdXJzZSwgaWYgc29tZXRoaW5nIGlzIGJyb2tlbiB3ZSBuZWVkIHRvIGZpeCBpdC4gQnV0 LCBJIGRvbid0IHRoaW5rIHdoYXQgeW91IHN1Z2dlc3QgaXMgZml4aW5nIHNvbWV0aGluZyB0aGF0 IGlzIGJyb2tlbiwgaXQgaXMgYWRkaW5nIG5ldyANCiAgICA+PiAgICAgZnVuY3Rpb25hbGl0eS4g QW5kLCBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQsIGFzIGxvbmcgYXMgaXQgaXMgYmFja3dh cmQgY29tcGF0aWJsZS4NCiAgICA+IA0KICAgID4gICANCiAgICA+IENocmlzdGVyLCANCiAgICA+ IEnigJl2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoaXMuIFdlIGFyZSBhbG1vc3QgaW4gdGhlIHNh bWUgc2l0dWF0aW9uIGFzIHRoZSBvbGQgZGlzY3Vzc2lvbiBhYm91dCB0aGUgREl2ZXJzaW9uOiBo ZWFkZXIuIFdoaWxlIHdhaXRpbmcNCiAgICA+IGZvciBhbm90aGVyIGJldHRlciBzb2x1dGlvbiwg dGhhdOKAmXMgd2hhdCBhbGwgb2YgdXMgaW1wbGVtZW50ZWQuIFRoZW4gY2FtZSBTSVAgSElzdG9y eSBhbmQgd2UgaGFkIG5vIGRvY3MgdG8gcmVmZXIgdG8gZm9yIGludGVyb3BlcmFiaWxpdHnigKYN CiAgICA+IFRoZSBvbGQgZHJhZnQgd2FzIGxhdGVyIHB1Ymxpc2hlZCBhcyBhbiBpbmZvcm1hdGlv bmFsIFJGQy4NCiAgICA+DQogICAgPiBDYW4gd2UgbG9vayBpbnRvIHRoZSBzYW1lIHNvbHV0aW9u PyBQdWJsaXNoaW5nIHRoZSBjdXJyZW50IGRyYWZ0IHdpaXRoIG1pbm9yIG5pdHMgYXMgYW4gaW5m b3JtYXRpb25hbCBSRkMgdGhhdCB5b3VyIGltcGxlbWVudGF0aW9uIGlzIGNvbXBsaWFudCB3aXRo DQogICAgPiBhbmQgdGhlbiB3b3JrIG9uIHNvbWV0aGluZyBtb3JlIHVwLXRvLXBhciB3aXRoIGN1 cnJlbnQgT0F1dGgyL09wZW5JRCBjb25uZWN0IEJDUHMgYW5kIHRoaW5raW5nPw0KDQogICAgSSBy ZWFsbHkgdGhpbmsgdGhhdCBpcyBhbiB1bmZhaXIgcmVxdWVzdCwgY29uc2lkZXJpbmcgaG93IG1h bnkgeWVhcnMgc29tZSBvZiB1cyBoYXZlIGJlZW4gd29ya2luZyBvbiB0aGlzLCBlc3BlY2lhbGx5 IHNpbmNlIEkgZG9uJ3QgdGhpbmsgdGhlIGN1cnJlbnQgc29sdXRpb24gaXMgYnJva2VuLg0KDQog ICAgWWVzLCB0aGVyZSBhcmUgbG90cyBvZiB0aGluZ3MgdGhhdCBuZWVkIHRvIGJlIGNsYXJpZmll ZCwgYW5kIHNvbWUgdGhpbmdzIG1heSBiZSBhZGRlZCwgc28gbGV0J3MgZmlyc3QgdHJ5IHRvIGRv IHRoYXQgYW5kIHNlZSB3aGVyZSBpdCB0YWtlcyB1cy4NCg0KICAgID5BcyBhbiBleGFtcGxlOiBX aGVuIHJlYWRpbmcgdGhlIGRvY3MgSSBzZWUgd2F5cyBvZiBwcm90ZWN0aW5nIHRoZSBhY2Nlc3Mg dG9rZW4gc28gdGhhdCBvbmx5IGEgc3BlY2lmaWMgc2VydmljZSAocmVhZCBTSVAgZG9tYWluKSAg bWF5IGRlY3J5cHQgYW5kDQogICAgPnVzZSBpdC4gVGhhdCB3YXkgd2UgZG9u4oCZdCBuZWVkIHRv IGRpc2FsbG93IGZvcndhcmRpbmcgb2YgU0lQIG1lc3NhZ2VzIHdpdGggYSBiZWFyZXIgdG9rZW4s IGFzIHRoZSB0b2tlbiB3aWxsIGJlIHVzZWxlc3MgYmV5b25kIHRoYXQgcG9pbnQuDQoNCiAgICBK V1QgZ2l2ZXMgeW91IHRoYXQgcHJvcGVydHksIGRvZXNuJ3QgaXQ/IFRoZXJlIGlzIG5vdGhpbmcg aW4gdGhlIGN1cnJlbnQgZHJhZnQgdGhhdCBmb3JiaWRzIG9yIHByZXZlbnRzIHlvdSBmcm9tIHVz aW5nIEpXVC4gQXMgd2Ugbm90ZWQgZWFybGllciwgaXQncyBwcm9iYWJseSANCiAgICB3aGF0IG1v c3QgKGFsbD8pIHBlb3BsZSBhcmUgdXNpbmcgYW55d2F5Lg0KDQogICAgPiBTdGFydGluZyB0byBn byBkb3duIHRoYXQgcm9hZCwgd2xpbCBkZWZpbml0ZWx5IG1lYW4gdGhhdCB3ZSBsZWF2ZSB0aGUg aW1wbGVtZW50YXRpb24geW91IGN1cnJlbnRseSBoYXZlIGJlaGluZC4gQW5kIHRoYXQgaXMganVz dA0KICAgID4gb25lIGlzc3VlLiBUaGUgb3RoZXIgaXMgaGF2aW5nIGEgcGFyc2FibGUgYWNjZXNz IHRva2VuLCB3aGljaCBJIHRoaW5rIHdvdWxkIGJlIGEgcmVxdWlyZW1lbnQgdG8gZm9sbG93IHRo ZSBCQ1AgYW5kIHByb3BhYmx5IHRvIGdldCB0aHJvdWdoDQogICAgPiB0aGUgaG9sZSBzZWN1cml0 eSBhdWRpdCBmb3IgYW55IHN0YW5kYXJkLXRyYWNrIFJGQyBwdWJsaWNhdGlvbi4NCiAgICANCiAg ICBKV1QgaXMgcGFyc2FibGUgOikNCg0KICAgIElzIHlvdXIgaXNzdWUgdGhhdCB3ZSBkb24ndCBt YW5kYXRlIEpXVD8gSWYgc28sIHdoeSBkb24ndCB3ZSBsaWFpc2UgKGFzIHlvdSBzdWdnZXN0ZWQg ZWFybGllcikgd2l0aCB0aGUgb2F1dGggd2cgdG8gc2VlIHdoZXRoZXIgaXQgd291bGQgYmUgc2Fm ZSB0byBhc3N1bWUgdGhhdCBldmVyeW9uZSB1c2VzIEpXVC4NCg0KICAgIFJlZ2FyZHMsDQoNCiAg ICBDaHJpc3Rlcg0KDQogDQoNCg== From nobody Thu Jul 11 08:16:55 2019 Return-Path: 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 1A3D912004E for ; Thu, 11 Jul 2019 08:16:54 -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 Fc5U6Y8Hfg0a for ; Thu, 11 Jul 2019 08:16:49 -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 4E484120135 for ; Thu, 11 Jul 2019 08:16:47 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 F2A57A40; Thu, 11 Jul 2019 17:16:42 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <00E2C886-3C25-48AE-B8FE-672D09095666@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9E9DF5A6-A8B0-44F9-8B06-DEB3D71C2344" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 17:16:42 +0200 In-Reply-To: Cc: Olle E Johansson , "sipcore@ietf.org" , Roman Shpount To: Rifaat Shekh-Yusef References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <4a9787e5-b5e2-bc08-0fa0-fae6bd44148d@alum.mit.edu> <527F4C39-F065-4335-A939-6D443F1801E7@ericsson.com> <393C0E68-5D0F-4AB5-B839-424C239E84A9@edvina.net> <161D4FCD-FA4D-4494-AA72-27DF363BEA3B@edvina.net> <5240BC21-613D-4C21-93A9-244C1AA3BAF4@edvina.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:16:55 -0000 --Apple-Mail=_9E9DF5A6-A8B0-44F9-8B06-DEB3D71C2344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jul 2019, at 00:52, Rifaat Shekh-Yusef = wrote: >=20 > Typically, access token is short lived, and in this case it should be = used only to allow the UA to register the user. > When the time comes to refresh the registration, the UA should use the = refresh token, which is long lived as it stays with the UA, to obtain a = new access token to update the registration. > If you tie it to the registration expiry, then the access token might = be valid for a long time, which degrades the security of the token. Or the registration will be valid for a short time=E2=80=A6 I wonder why = the STUN document requires this form of tie-in. I guess we need to ask the authors.=20 I do agree that long-lived access tokens would be a night-mare. I was = thinking along the way that every time you update the access token wth the refresh token, you re-register. And even though you can have a = very long-lived refresh token, we would force the update of the access token for every re-registration. I don=E2=80=99t think = that is a very bad thing.=20 I guess this way of using Oauth for long-lived sessions is a new area = for Oauth. I only found the STUN/TURN example to relate to. /O >=20 > There are better mechanisms for a proper indication of account = revocation, like the mechanisms defined by the Security Events WG: > https://datatracker.ietf.org/wg/secevent/documents/ = =20 >=20 > Regards, > Rifaat >=20 > =20 >=20 > On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson > wrote: >=20 >=20 >> On 10 Jul 2019, at 15:08, Olle E. Johansson > wrote: >>=20 >>=20 >>=20 >>> On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef > wrote: >>>=20 >>> This does not explain the reason for such a requirement. >>> Why do you think we need to couple these together for SIP? >> I don=E2=80=99t want to continue delivering services to clients that = are deleted or blocked in the customer database. >> With Oauth, the way to block an account is to remove it or change = authorization in the authentication server (IDP) data base. >>=20 >> The idea with auth tokens and refresh tokens is to be able to = revocate authorization quickly. >> Delivering a service beyond revocation is not a good thing in my = book. >>=20 >> =46rom the definition of Access Token in section 1.4 in RFC 6749: >>=20 >> "Access tokens are credentials used to access protected resources. An >> access token is a string representing an authorization issued to = the >> client. The string is usually opaque to the client. Tokens >> represent specific scopes and durations of access, granted by the >> resource owner, and enforced by the resource server and = authorization >> server. >> =E2=80=9C >>=20 >> "Duration of access" is in my world coupled to SIP = registration/subscription expiry. >>=20 >=20 > You have actually implicitly written that expiry time accords to token = expiry : >=20 > "2..3 = . Subsequent Registrations > All subsequent REGISTER requests from the UA MUST include a valid > access token. The UA MUST obtain a new access token before the > access token expiry period to continue to get service from the > system.=20 > =E2=80=9C >=20 > You just need to add that the server MUST not allow an expiry that is = greater than > the access token expiry time. >=20 > /O >=20 >=20 >> Cheers >> /O >>=20 >>>=20 >>> Regards, >>> Rifaat >>>=20 >>>=20 >>>=20 >>>=20 >>> On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson > wrote: >>>=20 >>>=20 >>>> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef > wrote: >>>>=20 >>>> The UA is expected to obtain a valid access token to get service, = and should be able to use that to refresh its registration when the = registration expires. >>>> Is this coupling of expiry times needed? >>> Absolutely. If we grant a REGISTER expiry time that is much longer = than the expiry of the token, we=E2=80=99re in deep waters. >>>=20 >>> Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot = from: >>>=20 >>> =E2=80=9C o The lifetime provided by the TURN server in the Allocate = and >>> Refresh responses MUST be less than or equal to the lifetime = of >>> the token. It is RECOMMENDED that the TURN server calculate = the >>> maximum allowed lifetime value using the formula: >>>=20 >>> lifetime + Delta - abs(RDnew - TS) >>>=20 >>> The RECOMMENDED value for the allowed Delta is 5 seconds. >>> =E2=80=9C >>>=20 >>> Note that they have a =E2=80=9CMUST=E2=80=9D on this. I think we = MUST do the same :-) >>> /O >>>=20 >>>>=20 >>>> Regards, >>>> Rifaat >>>>=20 >>>>=20 >>>> On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson > wrote: >>>>=20 >>>>=20 >>>>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef = > wrote: >>>>>=20 >>>>> When the UA authenticates to the AS, it obtains a number of = tokens: access token and refresh token, and depends on the AS, maybe ID = token. >>>>> It is the UAs responsibility to use the refresh token to obtain a = new access token before the expiry of the existing access token. >>>> Absolutely - my thought was what the server is supposed to do. = Reading the STUN/Oauth docs, I see a requirement for expiry >>>> being less than token validity time. In SIP REGISTER/SUBSCRIBE = terms, the expiry time in SIP should be less >>>> than the time the token is valid. >>>>=20 >>>> If the token expires, the server needs to reauth or deny services. = It is important that no services are delivered to an expired = authentication. >>>>=20 >>>> /O >>>>>=20 >>>>> Regards, >>>>> Rifaat >>>>>=20 >>>>>=20 >>>>> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson > wrote: >>>>>=20 >>>>>=20 >>>>>> On 10 Jul 2019, at 02:53, Roman Shpount > wrote: >>>>>>=20 >>>>>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef = > wrote: >>>>>> The document clearly allows the use of access token to = authenticate non-REGISTER requests when challenged in the context of the = same realm. >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>> When the token expires, you certainly need a new token from the = user. With SIP Outbound, we=E2=80=99re more connection oriented than = before, so we should propably consider what the >>>>> server does with the connection when a token expires (if it=E2=80=99= s not already in the draft). >>>>> /O >>>>>>=20 >>>>>> 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.. >>>>>>=20 >>>>>> 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.=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Best Regards, >>>>>> _____________ >>>>>> Roman Shpount >>>>>> =20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore = >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore = >>>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore = >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_9E9DF5A6-A8B0-44F9-8B06-DEB3D71C2344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Jul 2019, at 00:52, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Typically, access token is short lived, and in this case it = should be used only to allow the UA to register the user.
When the time comes to refresh the registration, the UA = should use the refresh token, which is long lived as it stays with the = UA, to obtain a new access token to update the registration.
If you tie it to the registration expiry, = then the access token might be valid for a long time, which degrades the = security of the token.
Or the = registration will be valid for a short time=E2=80=A6 I wonder why the = STUN document requires this form of tie-in. I guess we need to = ask
the authors. 

I = do agree that long-lived access tokens would be a night-mare. I was = thinking along the way that every time you update the access = token
wth the refresh token, you re-register. And even though = you can have a very long-lived refresh token, we would force the = update
of the access token for every re-registration. I = don=E2=80=99t think that is a very bad thing. 

I guess this way of using Oauth for long-lived = sessions is a new area for Oauth. I only found the STUN/TURN example to = relate to.

/O




There are better mechanisms for a = proper indication of account revocation, like the mechanisms defined by = the Security Events WG:
https://datatracker.ietf.org/wg/secevent/documents/ &n= bsp;

Regards,
 Rifaat

 

On Wed, Jul 10, 2019 at 9:17 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 = Jul 2019, at 15:08, Olle E. Johansson <oej@edvina.net> wrote:



On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:

This does not explain the reason = for such a requirement.
Why do you think we need to = couple these together for SIP?
I don=E2=80=99= t want to continue delivering services to clients that are deleted or = blocked in the customer database.
With Oauth, the = way to block an account is to remove it or change authorization in the = authentication server (IDP) data base.

The idea with auth tokens and refresh = tokens is to be able to revocate authorization quickly.
Delivering a service beyond revocation is not a good thing in = my book.

=46rom = the definition of Access Token in section 1.4 in RFC 6749:

"Access tokens are credentials = used to access protected resources. An
   access token is a string representing an authorization issued =
to the
   client.  The string is usually opaque to the client.  Tokens
   represent specific scopes and durations of access, granted by the
   resource owner, and enforced by the resource server and authorization
   server.
=E2=80=9C

"Duration of access" is in my world = coupled to SIP registration/subscription expiry.


You have actually implicitly written = that expiry time accords to token expiry :

"2..3. Subsequent = Registrations
   All subsequent REGISTER requests from the UA MUST include a =
valid
   access token.  The UA MUST obtain a new access token before the
   access token expiry period to continue to get service from the
   system.
=E2=80=9C

You just need to add that the server = MUST not allow an expiry that is greater than
the = access token expiry time.

/O


Cheers
/O


Regards,
 Rifaat




On Wed, Jul = 10, 2019 at 8:25 AM Olle E. Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:

The UA is expected to obtain a valid access token to get = service, and should be able to use that to refresh its registration when = the registration expires.
Is this coupling of = expiry times needed?
Absolutely. If we = grant a REGISTER expiry time that is much longer than the expiry of the = token, we=E2=80=99re in deep waters.

Example from RFC 7635 Stun/Oauth - = which I think we can borrow a lot from:

=E2=80=9C o The lifetime provided by the = TURN server in the Allocate and
      Refresh responses MUST be less than or equal to the =
lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 =
seconds.
=E2=80=9C

Note that they have a =E2=80=9CMUST=E2=80= =9D on this. I think we MUST do the same :-)
/O


Regards,
 Rifaat


On Wed, Jul = 10, 2019 at 7:56 AM Olle E. Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> wrote:

When the UA authenticates to the AS, it obtains a = number of tokens: access token and refresh token, and depends on the AS, = maybe ID token.
It is the UAs responsibility to use the = refresh token to obtain a new access token before the expiry of the = existing access token.
Absolutely - my = thought was what the server is supposed to do. Reading the STUN/Oauth = docs, I see a requirement for expiry
being less = than token validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry = time in SIP should be less
than the time the token = is valid.

 If the token expires, the server needs to reauth or = deny services. It is important that no services are delivered to an = expired authentication.

/O

Regards,
 Rifaat


On Wed, Jul 10, 2019 at 2:44 AM Olle E. = Johansson <oej@edvina.net> wrote:


On 10 Jul 2019, at 02:53, Roman Shpount = <roman@telurix.com> wrote:

<= div class=3D"">
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?

W= hen the token expires, you certainly need a new token from the user. = With SIP Outbound, we=E2=80=99re more connection oriented than before, = so we should propably consider what the
server does = with the connection when a token expires (if it=E2=80=99s not already in = the draft).
/O

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
 
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_9E9DF5A6-A8B0-44F9-8B06-DEB3D71C2344-- From nobody Thu Jul 11 08:26:39 2019 Return-Path: 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 F0752120157 for ; Thu, 11 Jul 2019 08:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kzDpbM5ssIRr for ; Thu, 11 Jul 2019 08:26:35 -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 B398B1200F9 for ; Thu, 11 Jul 2019 08:26:34 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 64A36A40; Thu, 11 Jul 2019 17:26:31 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <8A712633-C587-40B7-9D8A-63AA9B636580@ericsson.com> Date: Thu, 11 Jul 2019 17:26:30 +0200 Cc: "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <8A712633-C587-40B7-9D8A-63AA9B636580@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:26:37 -0000 > On 11 Jul 2019, at 17:13, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>>>>> The tokens generally, but if I understand it right not = always, are JWT structures that contain various data. In=20 >>>>>>>>>> OpenID connect both the access and identity token are JWTs. >>>>>>>>>> We can either specify specific claims that are standardised = for various SIP functions or let that be open for=20 >>>>>>>>>> the SIP implementors to specify or a combination.=20 >>>>>>>>>=20 >>>>>>>>> For backward compatibility, we should at least let SIP = implementors specify >>>>>>>> Maybe, but at least we should write something about the usage = of claims and scopes. >>>>>>>> I think a base level for this draft is specifying a way to say = =E2=80=9Cthis access token is valid for SIP usage=E2=80=9D or >>>>>>>> =E2=80=9Cthis is also a SIP identity" >>>>>>>=20 >>>>>>> Perhaps we can add some text about scope and claims, but I don't = want to mandate usage of specific values, because that=20 >>>>>>> may not be backward compatible with existing implementations = using JWT.=20 >>>>>>=20 >>>>>> We can mandate *if* the access token is a jwt (and there=E2=80=99s = an identity token like OpenID Connect).=20 >>>>>=20 >>>>> It may not work with existing implementations that DO use JWT = access tokens (not sure whether they use OpenID Connect, though). >>>>=20 >>>> Ok, you are making me interested - what are these implementations? >>>=20 >>> Unfortunately I am not able to give information regarding that. >>>=20 >>>> When writing a new standard document, should we really be blocked = by pre-standard implementations? I would assume that we >>>> should be inspired by them, learn by their experiences, but not be = hindered by them.=20 >>>=20 >>> The implementations are based on earlier versions of the draft. >>>=20 >>> And, yes, there is the old saying that one should not deploy a = draft before the draft becomes RFC.=20 >>>=20 >>> But, in this case, the first version of Rifaat's individual draft = was submitted in 2014. Then, for whatever reason, it took 3(!) years = before it=20 >>> got adopted, and after that we have so far worked on it for two = years. How long is one expected to wait for an RFC before deploying??? >>>=20 >>> Of course, if something is broken we need to fix it. But, I don't = think what you suggest is fixing something that is broken, it is adding = new=20 >>> functionality. And, I have no problem with that, as long as it is = backward compatible. >>=20 >>=20 >> Christer,=20 >> I=E2=80=99ve been thinking about this. We are almost in the same = situation as the old discussion about the DIversion: header. While = waiting >> for another better solution, that=E2=80=99s what all of us = implemented. Then came SIP HIstory and we had no docs to refer to for = interoperability=E2=80=A6 >> The old draft was later published as an informational RFC. >>=20 >> Can we look into the same solution? Publishing the current draft = wiith minor nits as an informational RFC that your implementation is = compliant with >> and then work on something more up-to-par with current OAuth2/OpenID = connect BCPs and thinking? >=20 > I really think that is an unfair request, considering how many = years some of us have been working on this, especially since I don't = think the current solution is broken. >=20 > Yes, there are lots of things that need to be clarified, and some = things may be added, so let's first try to do that and see where it = takes us. Let=E2=80=99s do that. My apologies for stepping in late, but I = haven=E2=80=99t felt blocked by an early implementation of a draft = before. I do understand it=E2=80=99s been some time. >=20 >> As an example: When reading the docs I see ways of protecting the = access token so that only a specific service (read SIP domain) may = decrypt and >> use it. That way we don=E2=80=99t need to disallow forwarding of SIP = messages with a bearer token, as the token will be useless beyond that = point. >=20 > JWT gives you that property, doesn't it? There is nothing in the = current draft that forbids or prevents you from using JWT. As we noted = earlier, it's probably=20 > what most (all?) people are using anyway. The implementations I=E2=80=99ve seen is mostly signed JWTs, but you are = right, JWTs can be encrypted. >=20 >> Starting to go down that road, wlil definitely mean that we leave the = implementation you currently have behind. And that is just >> one issue. The other is having a parsable access token, which I think = would be a requirement to follow the BCP and propably to get through >> the hole security audit for any standard-track RFC publication. >=20 > JWT is parsable :) >=20 > Is your issue that we don't mandate JWT? If so, why don't we liaise = (as you suggested earlier) with the oauth wg to see whether it would be = safe to assume that everyone uses JWT. I don=E2=80=99t think we can reach any level of acceptable security in = this without parseable access (and identity) tokens. All new Oauth = documents from the WG seems to=20 assume you can transport metadata from the authorization server to the = resource server in tokens in order to limit access token usage.=20 In addition I think putting the bearer token in a SIP header is = dangerous - it will require a lot for existing non-compliant browsers = not to leak this header out in the wild. Protecting it in a way that only the targeted audience can decode it and = validate it would make the situation better. /O From nobody Thu Jul 11 08:43:52 2019 Return-Path: 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 6B7C51202D9 for ; Thu, 11 Jul 2019 08:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 MAHqMN7d-BHs for ; Thu, 11 Jul 2019 08:43:47 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::614]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892581202E9 for ; Thu, 11 Jul 2019 08:43:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RPD4SbPv5OsTK4TOr18kYkC7tq9S7CoQwTpYc6xHK2B+8PGSSXnZJJBba1uVH7ctwrNMOKdK8bkRcTmUuatlyAg1t0Vwssgh4NY/PKwY/K0kPyhDzkCx0bgWDisoFjn0pY6uEXJ3KWbzrebOfuus+l+hfnDMmAxjEQvp5XlhZwdr7Qrw5xQYXaK2U5xq2LWxzgun3KAud/qtT5bzxOoofgXUC6aAD5sSYUQqAFfA9XjFevmuh0vt9aJ/o5F6GSL+1aFx+EggxkLaWEA8zuD5WODTsV1DnBKI0vtKcqmt5F42DvAaewQ/Wpf5QiaXJu74arG4PsTL58GyIJo8+bz8PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VN3LlKM4k631wE70E8SYNirkLTnmwpK2zu1p92lCTfE=; b=eI1IFiIedo/k6YU/G9oDzoIZLcyCKgOmt5Upucag5wr2UBEEHTLpyGLJfyz7UhiYrQGMgO7VOnekDu8dRQNtUU2WNfTfn4FXIOgoJvTXXJ4hTq9042+Mxe6VxIqdp3W40kAj/GVZ8KSYHgXTTUs+0NdlCuoN4Wf/sMSQ0HLSE3sPALkIYD6m5QRkdjn1RizyH5RtkYhvkStqC5ht8xVJoQGE5z+C0btEB1jkklKEPJR2pk72j/9Pnz9BsIYeE5f11kiHIL55Jp8DjEXNX87kos0XmMFhEw8LKz0jQFNx8CrxhPC8cKcKpHbnPjDKn+7OuOQrh42gTJZgxWA3FrRogA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VN3LlKM4k631wE70E8SYNirkLTnmwpK2zu1p92lCTfE=; b=eTN5zOTc40DGnoeVUtke2sA7AOUl4HzgauylTQQLvkq2i6XAzON8FjTku/1uJH3CWSuQNkMCOViXMAXksrMZfLfTBQvQsf2n+R3iz+WA1/p9w9O92PLB4WSDHV3KnWc+cZpGnyAEYNOzkVxp0A3VMBpe7kHmFWW2eJfZ0Qj8x+4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3212.eurprd07.prod.outlook.com (10.170.246.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 15:43:40 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 15:43:40 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAA3WQD///38gIAANg6A///RVAAABuLOAA== Date: Thu, 11 Jul 2019 15:43:40 +0000 Message-ID: <2929664D-4E91-4D45-8706-4F9D1038F55D@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <8A712633-C587-40B7-9D8A-63AA9B636580@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf9c8192-fc85-40a3-5318-08d706168c14 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3212; x-ms-traffictypediagnostic: HE1PR07MB3212: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(199004)(189003)(81156014)(76176011)(8676002)(81166006)(3846002)(26005)(33656002)(8936002)(4326008)(36756003)(25786009)(6486002)(6916009)(229853002)(316002)(486006)(71200400001)(71190400001)(66946007)(14444005)(256004)(5660300002)(102836004)(478600001)(7736002)(64756008)(66556008)(66446008)(66476007)(305945005)(6116002)(76116006)(6512007)(68736007)(2906002)(186003)(2616005)(14454004)(476003)(11346002)(66066001)(6506007)(44832011)(446003)(6246003)(58126008)(53936002)(86362001)(99286004)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3212; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aXyCfR6frNpBFVh8WnMYtxbOaWGHlUlq26NMdsPL6wbbYSGfh3hUyCmDkd+3PFeQd50PXk51RZrgkj9kqNFQ8/eN9YBnWS85eTxe/oLJoO69Iyp2S310Y+HC3nMPG+/qSmNQ691mVXRKBufvWB59CRkwBR+pMg9aS7rm+5qZCBENGfgJ77eQWAzRj8ZFJ3vu6rnBT73oM+FW+Sc5mq6dvFOkeS1SEmAtHNVi4ECwFpr4LtOxvKZST20CI7qAPC27XW8+CYkfMGD2wFhUokisU0Ti5IqlXyCg44s8Ejc8LcQXVBv+wW3onfd6qzvddYxje7KfWN5vpc5BPrvHLaOcan2m/caMtS6694Q5FXOYGyz0grYUrJtZLobYw7BfFDDZPyaP6DDX4/HyBleAUUxEjfQulyuu53A092QNRN6Ihjw= Content-Type: text/plain; charset="utf-8" Content-ID: <6D98841216F1654F91FA62D03F85E65D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf9c8192-fc85-40a3-5318-08d706168c14 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:43:40.4084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3212 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:43:51 -0000 SGksDQoNCi4uLg0KDQogICAgPj4+IEFzIGFuIGV4YW1wbGU6IFdoZW4gcmVhZGluZyB0aGUgZG9j cyBJIHNlZSB3YXlzIG9mIHByb3RlY3RpbmcgdGhlIGFjY2VzcyB0b2tlbiBzbyB0aGF0IG9ubHkg YSBzcGVjaWZpYyBzZXJ2aWNlIChyZWFkIFNJUCBkb21haW4pICBtYXkgZGVjcnlwdCBhbmQNCiAg ICA+Pj4gdXNlIGl0LiBUaGF0IHdheSB3ZSBkb27igJl0IG5lZWQgdG8gZGlzYWxsb3cgZm9yd2Fy ZGluZyBvZiBTSVAgbWVzc2FnZXMgd2l0aCBhIGJlYXJlciB0b2tlbiwgYXMgdGhlIHRva2VuIHdp bGwgYmUgdXNlbGVzcyBiZXlvbmQgdGhhdCBwb2ludC4NCiAgICA+PiANCiAgICA+PiAgICBKV1Qg Z2l2ZXMgeW91IHRoYXQgcHJvcGVydHksIGRvZXNuJ3QgaXQ/IFRoZXJlIGlzIG5vdGhpbmcgaW4g dGhlIGN1cnJlbnQgZHJhZnQgdGhhdCBmb3JiaWRzIG9yIHByZXZlbnRzIHlvdSBmcm9tIHVzaW5n IEpXVC4gQXMgd2Ugbm90ZWQgZWFybGllciwgaXQncyBwcm9iYWJseSANCiAgICA+PiAgICB3aGF0 IG1vc3QgKGFsbD8pIHBlb3BsZSBhcmUgdXNpbmcgYW55d2F5Lg0KICAgID4NCiAgICA+VGhlIGlt cGxlbWVudGF0aW9ucyBJ4oCZdmUgc2VlbiBpcyBtb3N0bHkgc2lnbmVkIEpXVHMsIGJ1dCB5b3Ug YXJlIHJpZ2h0LCBKV1RzIGNhbiBiZSBlbmNyeXB0ZWQuDQogICAgPiANCiAgICA+Pj4gU3RhcnRp bmcgdG8gZ28gZG93biB0aGF0IHJvYWQsIHdsaWwgZGVmaW5pdGVseSBtZWFuIHRoYXQgd2UgbGVh dmUgdGhlIGltcGxlbWVudGF0aW9uIHlvdSBjdXJyZW50bHkgaGF2ZSBiZWhpbmQuIEFuZCB0aGF0 IGlzIGp1c3QNCiAgICA+Pj4gb25lIGlzc3VlLiBUaGUgb3RoZXIgaXMgaGF2aW5nIGEgcGFyc2Fi bGUgYWNjZXNzIHRva2VuLCB3aGljaCBJIHRoaW5rIHdvdWxkIGJlIGEgcmVxdWlyZW1lbnQgdG8g Zm9sbG93IHRoZSBCQ1AgYW5kIHByb3BhYmx5IHRvIGdldCB0aHJvdWdoDQogICAgPj4+IHRoZSBo b2xlIHNlY3VyaXR5IGF1ZGl0IGZvciBhbnkgc3RhbmRhcmQtdHJhY2sgUkZDIHB1YmxpY2F0aW9u Lg0KICAgID4+IA0KICAgID4+ICAgIEpXVCBpcyBwYXJzYWJsZSA6KQ0KICAgID4+IA0KICAgID4+ ICAgIElzIHlvdXIgaXNzdWUgdGhhdCB3ZSBkb24ndCBtYW5kYXRlIEpXVD8gSWYgc28sIHdoeSBk b24ndCB3ZSBsaWFpc2UgKGFzIHlvdSBzdWdnZXN0ZWQgZWFybGllcikgd2l0aCB0aGUgb2F1dGgg d2cgdG8gc2VlIA0KICAgID4+ICAgIHdoZXRoZXIgaXQgd291bGQgYmUgc2FmZSB0byBhc3N1bWUg dGhhdCBldmVyeW9uZSB1c2VzIEpXVC4NCiAgICA+DQogICAgPiBJIGRvbuKAmXQgdGhpbmsgd2Ug Y2FuIHJlYWNoIGFueSBsZXZlbCBvZiBhY2NlcHRhYmxlIHNlY3VyaXR5IGluIHRoaXMgd2l0aG91 dCBwYXJzZWFibGUgYWNjZXNzIChhbmQgaWRlbnRpdHkpIHRva2Vucy4gQWxsIG5ldyBPYXV0aCAN CiAgICA+IGRvY3VtZW50cyBmcm9tIHRoZSBXRyBzZWVtcyB0byBhc3N1bWUgeW91IGNhbiB0cmFu c3BvcnQgbWV0YWRhdGEgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gdGhlIHJlc291 cmNlIHNlcnZlciBpbiANCiAgICA+IHRva2VucyBpbiBvcmRlciB0byBsaW1pdCBhY2Nlc3MgdG9r ZW4gdXNhZ2UuIA0KICAgIA0KICAgID4gSW4gYWRkaXRpb24gSSB0aGluayBwdXR0aW5nIHRoZSBi ZWFyZXIgdG9rZW4gaW4gYSBTSVAgaGVhZGVyIGlzIGRhbmdlcm91cyAtIGl0IHdpbGwgcmVxdWly ZSBhIGxvdCBmb3IgZXhpc3Rpbmcgbm9uLWNvbXBsaWFudCBicm93c2VycyANCiAgICA+IG5vdCB0 byBsZWFrIHRoaXMgaGVhZGVyIG91dCBpbiB0aGUgd2lsZC4NCg0KICAgIFdoYXQgZG8geW91IG1l YW4gYnkgImV4aXN0aW5nIG5vbi1jb21wbGlhbnQgYnJvd3NlcnMiPw0KDQogICAgPiBQcm90ZWN0 aW5nIGl0IGluIGEgd2F5IHRoYXQgb25seSB0aGUgdGFyZ2V0ZWQgYXVkaWVuY2UgY2FuIGRlY29k ZSBpdCBhbmQgdmFsaWRhdGUgaXQgd291bGQgbWFrZSB0aGUgc2l0dWF0aW9uIGJldHRlci4NCg0K ICAgIEFnYWluLCBKV1QgOikNCg0KICAgIFlvdSBjYW4gaW5jbHVkZSBKV1QgZW5jb2RlZCBpbmZv cm1hdGlvbiBpbiBhIFNJUCBoZWFkZXIuIFdlIGFscmVhZHkgZG8gdGhhdCBlbHNld2hlcmUuICAg IA0KDQogICBSZWdhcmRzLA0KDQogICBDaHJpc3Rlcg0KDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Jul 11 10:10:43 2019 Return-Path: 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 6A2EE120106 for ; Thu, 11 Jul 2019 10:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rR77RntfMbJ5 for ; Thu, 11 Jul 2019 10:10:39 -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 3447912003E for ; Thu, 11 Jul 2019 10:10:38 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 77DD1A40; Thu, 11 Jul 2019 19:10:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 19:10:34 +0200 Cc: Olle E Johansson , Christer Holmberg , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:10:41 -0000 > On 11 Jul 2019, at 15:50, Paul Kyzivat wrote: >=20 > On 7/11/19 3:03 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. >> =20 >>> 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. >=20 > 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? >=20 > If it is protected, then why is there any concern over who it is given = to? Normally most tokens are just digitially signed, but clear text. It can = be encrypted, but then the auth server need to know which key pair to = encrypt it with, which in turn means that the client needs to tell the auth server that which leads to a = requirement to have parseable access tokens. Again, let=E2=80=99s stop talking about =E2=80=9Cthe token=E2=80=9D. = That will confuse ourselves and other readers. Thanks :-) /O= From nobody Thu Jul 11 10:14:46 2019 Return-Path: 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 8B8CF1200D8 for ; Thu, 11 Jul 2019 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E_SNnNQ70U4Q for ; Thu, 11 Jul 2019 10:14:43 -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 99AB0120106 for ; Thu, 11 Jul 2019 10:14:42 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 84B4710F8; Thu, 11 Jul 2019 19:14:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> Date: Thu, 11 Jul 2019 19:14:38 +0200 Cc: Olle E Johansson , Paul Kyzivat , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:14:45 -0000 > On 11 Jul 2019, at 16:07, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>> All I am saying is that one should not send a token to someone = that it has NOT been issued for. >>>>=20 >>>> 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. >>>>=20 >>>> That is a bit extreme, but I guess you can specify that if you = think it >>>> is the right thing to do. >>>=20 >>> That is my understanding of the generic OAuth security = considerations: you don't give a token to someone it was not intended = for. >>>=20 >>> 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. >>>=20 >>>> 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. >>>=20 >>> It is important to remember that, since the token needs to be = protected, a proxy needs to have the=20 >>> associated protection credentials to be able to access the token. >>=20 >> I'm lost here. How is the token protected? Is it because it is passed = by=20 >> reference, and other credentials are needed to dereference it? Or is = it=20 >> passed by value but encrypted? >=20 > That depends on how your protect it. >=20 > 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. >=20 > But, if the oauth2 token is sent in "plain text", then the SIP = signaling needs to be protected/encrypted. Encryption of signalling is not going to protect a token in a SIP header = from reaching to the wrong servers, it is just a first hop encryption. We have far too many SIP RFCs that indicate that = all security problems are solved if we wrap signalling in TLS. > 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. Right. And we have no way in SIP of forbidding any server of forwarding = a specific header. >=20 > What is important is that a non-authorized user should not have = access to a non-protected oauth2 token. Define =E2=80=9Cuser" and =E2=80=9Ctoken=E2=80=9D. A non-encrypted = access token should not be shared with any unauthorized SIP network = element - client or server software. /O >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 11 10:18:51 2019 Return-Path: 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 945A8120198 for ; Thu, 11 Jul 2019 10:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7R1xw_Q7HTGc for ; Thu, 11 Jul 2019 10:18: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 6010E1200D8 for ; Thu, 11 Jul 2019 10:18:47 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 1D4FAA40; Thu, 11 Jul 2019 19:18:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <64b7d784-3f34-dd11-d7e2-b22fe621cd70@alum.mit.edu> Date: Thu, 11 Jul 2019 19:18:44 +0200 Cc: Olle E Johansson , Christer Holmberg , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <58706C19-ECD3-49D6-BD9B-0BC7EBA3F793@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> <64b7d784-3f34-dd11-d7e2-b22fe621cd70@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:18:51 -0000 > On 11 Jul 2019, at 16:24, Paul Kyzivat wrote: >=20 > 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. >=20 > 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. >=20 >> 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. >=20 > 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? >=20 > 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. The UAC will have to know which SIP domain that - in Oauth2 terms - is = the intended audience for authentication and/or authorization. When = requesting authenticiation=20 with the Oauth2 authorization server this needs to be part of the = request. The server may them, provided that it has a trusted certificate = or a key that is shared witih the service, encrypt the requested access token in a way that only the = audience can decrypt. The SIP domain is part of the solution here. That will be stated as a = SIP uri. /O >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 11 10:21:53 2019 Return-Path: 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 1BB38120106 for ; Thu, 11 Jul 2019 10:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Lb8BOa2dGyWo for ; Thu, 11 Jul 2019 10:21:49 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00070.outbound.protection.outlook.com [40.107.0.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93481200D8 for ; Thu, 11 Jul 2019 10:21:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iU60rt5Hs9cdK9TEPxG8h0R+fETgWmjHjEK4hcr/rVmDDzwS18O8sWJ+fN7N5cgU9IC8tinFewDQCTfgnxEfAuaZgFBCtzqQetQNUrBbPZKokfLATp4ZrKxSmNt2yFfVDwSBvhAOXPBq7dJQizLJAtGlYhWuM5Mqffqdmh2/cZaA+mhpVlETxFzsrohw0B7zsdbj8rY5WkSS5S4fuFO4Fu2EAEmM1veqzh1Hf44yC0TmBj8zHdJZTL1s3zNxnwyS8zZRmTIXfbPq0zhoy6m06lCcnoA+3pIIYhoO9Vqx2krFrYMjubfT0fwcTfWXBUjTT/swFqrjb9615m3ZkiCzbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PZbcUGjT0j/Pe9r8AFEwua9eRgrfJS4W/ffFvetgumo=; b=XE6ROE1PEXIf89BlZZNWdFCg1Ev/7etixs3ebwnLIlZ8AQdfhDRB38a0Hqjp6kFlXHIPY7bWP73wVTcF4wIvkN3BqAREmDzVnSYElzZTReoHl7CBzsgQeD7bMDv5LwER/L0sCvnZZk8zKYMGmLTS1ZQ3pfuYOtX/PuceXwAIuW/QUPxEP+vZ/7/JcP0bS91TSc/BdQLKKUk/QHVwGzWpjyyVN86kYEIBottkWAtzVbRIHnRbUZuXO39DlD2nskw6JV/12RF0JXmAH3fvMKNIvxcXZJzvTd10qzY627gL4Dnc+hf3khXt9akrlRUORXIFMRAG1mu47sLCxdkgnu9Cnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PZbcUGjT0j/Pe9r8AFEwua9eRgrfJS4W/ffFvetgumo=; b=rKp1RAUwmnCdCdvA851VcadNtbbmqxBSxVVsq6GaIccs0e+eQ7ANGcChLyuwRYzltsicZ5B1PdbfZfFlymwrBrTj18HmR0Td9G/ZY4+8BFB7g4n7X2vX26bz6JoqMaPWxyTk1eFT2RFZM7xYHaNCngIgMZREsqgX092V4n/iTx0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3483.eurprd07.prod.outlook.com (10.170.247.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 17:21:44 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 17:21:44 +0000 From: Christer Holmberg To: "Olle E. Johansson" , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgIAAP24AgAA4AgCAADVqAA== Date: Thu, 11 Jul 2019 17:21:44 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> In-Reply-To: <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9471282-19aa-4dc1-d6b7-08d706243f55 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3483; x-ms-traffictypediagnostic: HE1PR07MB3483: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(376002)(366004)(136003)(39860400002)(189003)(199004)(305945005)(6506007)(14454004)(66066001)(68736007)(6512007)(26005)(446003)(316002)(186003)(11346002)(102836004)(486006)(71200400001)(44832011)(110136005)(36756003)(71190400001)(476003)(2171002)(53936002)(86362001)(81166006)(7736002)(229853002)(81156014)(6116002)(66946007)(256004)(76116006)(99286004)(4326008)(6246003)(6486002)(64756008)(3846002)(66476007)(33656002)(6436002)(66556008)(14444005)(478600001)(58126008)(2906002)(66446008)(8676002)(25786009)(5660300002)(8936002)(2616005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3483; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MPFTUz0ql/BUhdFBIvUuklGwP793DugCcSnSWEpuUe3aOZ50M3qBEAFXoDh64JdTlBEThcUkhO1Q7ZCfql2E9OAK0jG2uLU6y8VS2xRiWdTMz99pNYdvPBUTZZ1yfVe2j+4qylQuvEErFcthxIFVM7RYwA3ZTBtaT6quHPAB9xJDs/AaYDaDLDXFn8zb+P8rFRUrBA/ELikQXVWHL6OWCwKDoksP2hpORfy2jM0qwgcouUOfHu8l0jaV+NxpR/nzUDrKUAqZB4JdlHVjVcEeChFBrvZIssyx5Cglf0TB95WunqU5Wc6dyMEdg+qLK0HxhBz836MG61iRRfuepFrcc2OPo1nPU1ypyH8SFpQhPee+bDK8FI58lV4UEQDEy9yB0pBmoiXD59VGOVP8iml3rNrP5MZBR4SXDSZfWL2QgX0= Content-Type: text/plain; charset="utf-8" Content-ID: <341F04657715004DB7550F71789A9B83@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9471282-19aa-4dc1-d6b7-08d706243f55 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 17:21:44.6554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3483 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:21:52 -0000 SGksDQoNCiAgICA+Pj4+PiBBbGwgSSBhbSBzYXlpbmcgaXMgdGhhdCBvbmUgc2hvdWxkIG5vdCBz ZW5kIGEgdG9rZW4gdG8gc29tZW9uZSB0aGF0IGl0IGhhcyBOT1QgYmVlbiBpc3N1ZWQgZm9yLg0K ICAgID4+Pj4gICAgICAgIFRoZW4geW91IGFyZSBzYXlpbmcgdGhhdCBhIHRva2VuIHNob3VsZCAq bmV2ZXIqIGJlIGluY2x1ZGVkIGluIGEgcmVxdWVzdA0KICAgID4+Pj4gICAgdG8gYSB0YXJnZXQg Zm9yIHdoaWNoIHlvdSBoYXZlIG5vdCByZWNlaXZlZCBhIGNoYWxsZW5nZSBzb21lIHRpbWUgaW4g dGhlDQogICAgPj4+PiAgICBwYXN0Lg0KICAgID4+Pj4gICAgICAgIFRoYXQgaXMgYSBiaXQgZXh0 cmVtZSwgYnV0IEkgZ3Vlc3MgeW91IGNhbiBzcGVjaWZ5IHRoYXQgaWYgeW91IHRoaW5rIGl0DQog ICAgPj4+PiAgICBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uDQogICAgPj4+IFRoYXQgaXMgbXkg dW5kZXJzdGFuZGluZyBvZiB0aGUgZ2VuZXJpYyBPQXV0aCBzZWN1cml0eSBjb25zaWRlcmF0aW9u czogeW91IGRvbid0IGdpdmUgYSB0b2tlbiB0byBzb21lb25lIGl0IHdhcyBub3QgaW50ZW5kZWQg Zm9yLg0KICAgID4+PiBPZiBjb3Vyc2UsIGlmIHlvdSBrbm93IChiYXNlZCBvbiB3aGF0ZXZlciBj b25maWd1cmF0aW9uL3BvbGljeSkgdGhhdCBpdCdzIG9rIHRvIGdpdmUgdGhlIHRva2VuIHRvIHRo ZSB0YXJnZXQgSSBndWVzcyB5b3UgY291bGQgZG8gaXQuDQogICAgPj4+ICAgICANCiAgICA+Pj4+ ICAgIEJ1dCBub3RlIHRoYXQgdGhpcyBsb2dpYyB3b24ndCBhbHdheXMgd29yayBmb3IgUHJveHkt QXV0aGVudGljYXRlLiBZb3UNCiAgICA+Pj4+ICAgICptaWdodCoga25vdyB0aGF0IGEgcGFydGlj dWxhciBwcm94eSB3aWxsIGJlIHZpc2l0ZWQgKGlmIGl0IGlzIG1lbnRpb25lZA0KICAgID4+Pj4g ICAgb24gYSBSb3V0ZSBoZWFkZXIpLCBidXQgaXQgaXMgcHJldHR5IGNvbW1vbiBmb3IgdGhlIHJl cXVlc3QgdG8gdmlzaXQNCiAgICA+Pj4+ICAgIHByb3hpZXMgdW5rbm93biAoYXQgbGVhc3QgaW4g YWR2YW5jZSkgdG8gdGhlIFVBQy4NCiAgICA+Pj4gICBJdCBpcyBpbXBvcnRhbnQgdG8gcmVtZW1i ZXIgdGhhdCwgc2luY2UgdGhlIHRva2VuIG5lZWRzIHRvIGJlIHByb3RlY3RlZCwgYSBwcm94eSBu ZWVkcyB0byBoYXZlIHRoZSBhc3NvY2lhdGVkIHByb3RlY3Rpb24gY3JlZGVudGlhbHMgdG8gYmUg YWJsZSB0byBhY2Nlc3MgdGhlIHRva2VuLg0KICAgID4+IA0KICAgID4+IEknbSBsb3N0IGhlcmUu IEhvdyBpcyB0aGUgdG9rZW4gcHJvdGVjdGVkPyBJcyBpdCBiZWNhdXNlIGl0IGlzIHBhc3NlZCBi eSByZWZlcmVuY2UsIGFuZCBvdGhlciBjcmVkZW50aWFscyBhcmUgbmVlZGVkIHRvIGRlcmVmZXJl bmNlIGl0PyBPciBpcyBpdCBwYXNzZWQgYnkgdmFsdWUgYnV0IGVuY3J5cHRlZD8NCiAgICA+PiAN CiAgICA+PiBJZiBpdCBpcyBwcm90ZWN0ZWQsIHRoZW4gd2h5IGlzIHRoZXJlIGFueSBjb25jZXJu IG92ZXIgd2hvIGl0IGlzIGdpdmVuIHRvPw0KICAgID4NCiAgICA+Tm9ybWFsbHkgbW9zdCB0b2tl bnMgYXJlIGp1c3QgZGlnaXRpYWxseSBzaWduZWQsIGJ1dCBjbGVhciB0ZXh0LiBJdCBjYW4gYmUg ZW5jcnlwdGVkLCBidXQgdGhlbiB0aGUgYXV0aCBzZXJ2ZXIgbmVlZCB0byBrbm93IHdoaWNoIGtl eSBwYWlyIHRvIGVuY3J5cHQgaXQgd2l0aCwgd2hpY2ggaW4gdHVybiBtZWFucw0KICAgID50aGF0 IHRoZSBjbGllbnQgbmVlZHMgdG8gdGVsbCB0aGUgYXV0aCBzZXJ2ZXIgdGhhdCB3aGljaCBsZWFk cyB0byBhIHJlcXVpcmVtZW50IHRvIGhhdmUgcGFyc2VhYmxlIGFjY2VzcyB0b2tlbnMuDQoNCiAg ICBJIHRoaW5rIHRoZSBvYXV0aDIgdG9rZW4gY2FuIGJlIGRlbGl2ZXJlZCBub24tZW5jcnlwdGVk IHRvIHRoZSBTSVAgVUEgb3ZlciBIVFRQUy4gVGhlIFNJUCBVQSBjYW4gdGhlbiBlbmNyeXB0IHRo ZSBvYXV0aDIgdG9rZW4gYmVmb3JlIHNlbmRpbmcgaXQgb3ZlciBTSVAuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg0K From nobody Thu Jul 11 10:25:08 2019 Return-Path: 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 DD2D0120198 for ; Thu, 11 Jul 2019 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9gH-SjuxAUDb for ; Thu, 11 Jul 2019 10:24:57 -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 EDD9E1200D8 for ; Thu, 11 Jul 2019 10:24:56 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 00261A40; Thu, 11 Jul 2019 19:24:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <7AEC21E0-B0A6-4303-B936-F183ED6EC05D@ericsson.com> Date: Thu, 11 Jul 2019 19:24:52 +0200 Cc: Olle E Johansson , Paul Kyzivat , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0ADB13C4-FDEE-4012-865A-6E0C98D7F0D4@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> <64b7d784-3f34-dd11-d7e2-b22fe621cd70@alum.mit.edu> <7AEC21E0-B0A6-4303-B936-F183ED6EC05D@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:25:03 -0000 > On 11 Jul 2019, at 17:02, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>> All I am saying is that one should not send a token to someone = that it has NOT been issued for. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> That is a bit extreme, but I guess you can specify that if you = think it >>>>>> is the right thing to do. >>>>>=20 >>>>> That is my understanding of the generic OAuth security = considerations: you don't give a token to someone it was not intended = for. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> 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? >>>=20 >>> That depends on how your protect it. >>>=20 >>> If the oauth2 token itself is encrypted, and only authorized = entities can decrypt it, then I guess it does=20 >>> not matter if a non-authorized user gets it, as it will not be = able to use it. >>=20 >> 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. >=20 > We normally don't specify HOW to protect SIP information, because = it can done in many different ways, we only say when=20 > some piece of information needs to be protected. And where have that kind of thinking led us? We need at least one = working interoperable solution for implementers to iimplement as a baseline, while not forbidding others.=20 >=20 > Also, in the case of oauth2 tokens, as they can be encoded in many = different ways, some of which have their own built-in protections (e.g., = JWT), we can't specify a single solution that works for all. We can only = specify what security characteristics must be fulfilled. We can surely specify a working solution that is the base = interoperability level. Otherwise we will just produce a document that goes to the archives and leads to isolated vendor-specific = islands. I don=E2=80=99t like that. I do agree with leaving it open to add other ways of doing things in the = future, but I think we need to deliver a fully specifieid working solution. >=20 >>> But, if the oauth2 token is sent in "plain text", then the SIP = signaling needs to be protected/encrypted.=20 >>> 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=20 >>> oauth2 token unless it's meant for you, because once you decrypt the = signaling you will have access to it. >>>=20 >>> What is important is that a non-authorized user should not have = access to a non-protected oauth2 token. >>=20 >> I don't see how this can work. How does the UAC *know* if the server = it=20 >> is sending credentials to is authorized to receive those credentials? >>=20 >> In general the UAC doesn't know what proxies and UAS the request will=20= >> visit. All it knows is the request-URI. Since there generally isn't a=20= >> direct connection from UAC to UAS TLS authentication doesn't help. >=20 > In that case you should use encoding with built-in protection, that = only authorized entities are able to decrypt. JWT provides=20 > such protection, so I assume it wouldn't matter if a non-authorized = entity receives it. And, as far as the OAuth token is concerned, you = don't have to protect the SIP signaling when using JWT (there may of = course be other reasons why you need to protect the SIP signaling). Most SIP signalling protection - TLS - is hop by hop. We need protection = from the UA to the service domain - possibly across a few intermediate = servers. /O= From nobody Thu Jul 11 10:26:50 2019 Return-Path: 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 C107F120106 for ; Thu, 11 Jul 2019 10:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aZ6wET2GQIgC for ; Thu, 11 Jul 2019 10:26:46 -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 43D311200D8 for ; Thu, 11 Jul 2019 10:26:46 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 7ED5AA40; Thu, 11 Jul 2019 19:26:43 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <2929664D-4E91-4D45-8706-4F9D1038F55D@ericsson.com> Date: Thu, 11 Jul 2019 19:26:43 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <40288F76-525D-43A1-A679-9C5C869121AF@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <8A712633-C587-40B7-9D8A-63AA9B636580@ericsson.com> <2929664D-4E91-4D45-8706-4F9D1038F55D@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:26:49 -0000 > On 11 Jul 2019, at 17:43, Christer Holmberg = wrote: >=20 > Hi, >=20 > ... >=20 >>>> As an example: When reading the docs I see ways of protecting the = access token so that only a specific service (read SIP domain) may = decrypt and >>>> use it. That way we don=E2=80=99t need to disallow forwarding of = SIP messages with a bearer token, as the token will be useless beyond = that point. >>>=20 >>> JWT gives you that property, doesn't it? There is nothing in the = current draft that forbids or prevents you from using JWT. As we noted = earlier, it's probably=20 >>> what most (all?) people are using anyway. >>=20 >> The implementations I=E2=80=99ve seen is mostly signed JWTs, but you = are right, JWTs can be encrypted. >>=20 >>>> Starting to go down that road, wlil definitely mean that we leave = the implementation you currently have behind. And that is just >>>> one issue. The other is having a parsable access token, which I = think would be a requirement to follow the BCP and propably to get = through >>>> the hole security audit for any standard-track RFC publication. >>>=20 >>> JWT is parsable :) >>>=20 >>> Is your issue that we don't mandate JWT? If so, why don't we = liaise (as you suggested earlier) with the oauth wg to see=20 >>> whether it would be safe to assume that everyone uses JWT. >>=20 >> I don=E2=80=99t think we can reach any level of acceptable security = in this without parseable access (and identity) tokens. All new Oauth=20 >> documents from the WG seems to assume you can transport metadata from = the authorization server to the resource server in=20 >> tokens in order to limit access token usage.=20 >=20 >> In addition I think putting the bearer token in a SIP header is = dangerous - it will require a lot for existing non-compliant browsers=20 >> not to leak this header out in the wild. >=20 > What do you mean by "existing non-compliant browsers=E2=80=9D? Haha, yes, that was not parseable. Substitute =E2=80=9Cbrowsers=E2=80=9D = witih =E2=80=9CSIP Proxys=E2=80=9D and it gets better. Sorry. >=20 >> Protecting it in a way that only the targeted audience can decode it = and validate it would make the situation better. >=20 > Again, JWT :) >=20 > You can include JWT encoded information in a SIP header. We already = do that elsewhere. =20 Absolutely. But then we can=E2=80=99t just say =E2=80=9CJWT=E2=80=9D we = have to specify =E2=80=9Cencrypted and signed JWT=E2=80=9D. /O >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jul 11 10:29:11 2019 Return-Path: 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 8CE1A1201DC for ; Thu, 11 Jul 2019 10:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 XaHxontaNQFi for ; Thu, 11 Jul 2019 10:29:06 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30078.outbound.protection.outlook.com [40.107.3.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1839F1200D8 for ; Thu, 11 Jul 2019 10:29:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RC1Q48A399JuPs6770ftylRBCswgvuzX/RUloiDgbEJxTA4bN29YFMO/KVCEiu04spAy/T/GITzQKuvOOOW4IjCV2CXwzPXublnW7yFQIMHmpxJ7pk314hTRNmlEnN321S6HtL3Ytj2dNbuoATz7bcuNS8bTTwsjjFE03piSzhpoitvenGkxv3TvghKR5b84yh75C0PW7/ZZ0rcRohrMEHYWEhvguL0bXQsI5Qiw0u8FCKeJ6xCG9nyukVIHzk+YAzdtc57yw8y7tQYQSDlgYCV3qPEILiH2N12D0QupcXweJSomRWfO4ncVNAqhlhfJ0T3jwmfD9bunJzgcpLcgwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkvX9gWgMXt1TfVjYF7jKMeiQTLRo+mfdJDNhq2l4Tk=; b=FZUoYc4WNO7iY8viG4yPlvs4r6yhN42Cyx48K6Qs8101qvXCLoEcQVB7OaXb05let5H4tEnZJdzGkA/1TDTghQDdI905ayy3B5Xb2KW2QDuAtlv5FH2tODvRbqa+mcd2V1L5O1UbKGTeDh59jGI/O8fZuWN2UgE0h+yEsxxwvGng9VTqESGX793RTckfE1+8MUGBHF8eeak87k+VwKbmBcS1c/7UhkQp3SbZeYDtePDe5hzrvJBQocTqASjI/CK70OMM6bkXRNNjyqlkp91jKnOstYNYzfwaNf2+BKxypjdkviANCvOK/JlJoJPMgseYikh4GHA1XzYk1YAjfZ03Wg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkvX9gWgMXt1TfVjYF7jKMeiQTLRo+mfdJDNhq2l4Tk=; b=bwvSolQqSG1LrnjYVIDaLaGRAPqnj8P80zQYgyhIYH9MPsXQf2Aiy9beXfr50rWZTmBDbzNJrJDYl0Zzy5lXieffxEEsvvEc1zavt2pVuCABQaa/CON8pNOtdGWYCrqETSo1gpf6O787d8ywpXWZ7n2i0UvMPK36WBiDKgU610E= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3483.eurprd07.prod.outlook.com (10.170.247.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 17:29:03 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 17:29:03 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgIAAP24AgAA3OYCAAAHsAIAANlEA Date: Thu, 11 Jul 2019 17:29:02 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <59F235A8-2BD4-49B5-8890-E793E1CF40EC@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 287795e6-d033-4352-c527-08d7062544ac x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3483; x-ms-traffictypediagnostic: HE1PR07MB3483: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(376002)(366004)(136003)(39860400002)(189003)(199004)(305945005)(6506007)(14454004)(6916009)(66066001)(68736007)(6512007)(26005)(446003)(316002)(186003)(11346002)(102836004)(486006)(71200400001)(44832011)(36756003)(71190400001)(476003)(53936002)(86362001)(81166006)(7736002)(229853002)(81156014)(6116002)(66946007)(256004)(76116006)(99286004)(4326008)(54906003)(6246003)(6486002)(64756008)(3846002)(66476007)(33656002)(6436002)(66556008)(14444005)(478600001)(58126008)(2906002)(66446008)(8676002)(25786009)(5660300002)(8936002)(2616005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3483; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aaMXD7g7JrT9PniPtCWy7tWg20Fc7uGKNWdXCUJDO5xEHrIyijp0JQ9DB6/SfnEGZuUKB6y2NulrhBZCPhtqqekqNvKl1QgYEL5bvgvKavMC+B3wpTqWE6Gq4pIPMrK9rY/Jz55We/DxG3qm0bEhh39q1IHRv/yc+edR3TwnNxt98ocdkfrn1eAofc2VxOs+cYNdCUVFJWKS5TJCeaYyJeA1kUkGE529nrJAWoid3nnLFZDco/OukQphLNIifdrZW9a5NOYcDuXqG0oUfocy8ExMDbZW6tt/MJ6dAKwpJXWUN2zlu7pPNAnZ1cPKx4cKOlCZwIV7+5xdjra+BebMigQzcdDZnVzrZ4yg/JQmKWq1mfMCVFysNmeSOnxwsm9Y8VeHvVU13zoC3eK4b84FyjAQJuHNbGKrnShPrirk67c= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 287795e6-d033-4352-c527-08d7062544ac X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 17:29:03.0085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3483 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:29:10 -0000 SGksDQoNCiAgICA+Pj4+Pj4gQWxsIEkgYW0gc2F5aW5nIGlzIHRoYXQgb25lIHNob3VsZCBub3Qg c2VuZCBhIHRva2VuIHRvIHNvbWVvbmUgdGhhdCBpdCBoYXMgTk9UIGJlZW4gaXNzdWVkIGZvci4N CiAgICA+Pj4+PiANCiAgICA+Pj4+PiAgICBUaGVuIHlvdSBhcmUgc2F5aW5nIHRoYXQgYSB0b2tl biBzaG91bGQgKm5ldmVyKiBiZSBpbmNsdWRlZCBpbiBhIHJlcXVlc3QNCiAgICA+Pj4+PiAgICB0 byBhIHRhcmdldCBmb3Igd2hpY2ggeW91IGhhdmUgbm90IHJlY2VpdmVkIGEgY2hhbGxlbmdlIHNv bWUgdGltZSBpbiB0aGUNCiAgICA+Pj4+PiAgICBwYXN0Lg0KICAgID4+Pj4+IA0KICAgID4+Pj4+ ICAgIFRoYXQgaXMgYSBiaXQgZXh0cmVtZSwgYnV0IEkgZ3Vlc3MgeW91IGNhbiBzcGVjaWZ5IHRo YXQgaWYgeW91IHRoaW5rIGl0DQogICAgPj4+Pj4gICAgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRv Lg0KICAgID4+Pj4gDQogICAgPj4+PiBUaGF0IGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGdl bmVyaWMgT0F1dGggc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6IHlvdSBkb24ndCBnaXZlIGEgdG9r ZW4gdG8gc29tZW9uZSBpdCB3YXMgbm90IGludGVuZGVkIGZvci4NCiAgICA+Pj4+IA0KICAgID4+ Pj4gT2YgY291cnNlLCBpZiB5b3Uga25vdyAoYmFzZWQgb24gd2hhdGV2ZXIgY29uZmlndXJhdGlv bi9wb2xpY3kpIHRoYXQgaXQncyBvayB0byBnaXZlIHRoZSB0b2tlbiB0byB0aGUgdGFyZ2V0IEkg Z3Vlc3MgeW91IGNvdWxkIGRvIGl0Lg0KICAgID4+Pj4gDQogICAgPj4+Pj4gICAgQnV0IG5vdGUg dGhhdCB0aGlzIGxvZ2ljIHdvbid0IGFsd2F5cyB3b3JrIGZvciBQcm94eS1BdXRoZW50aWNhdGUu IFlvdQ0KICAgID4+Pj4+ICAgICptaWdodCoga25vdyB0aGF0IGEgcGFydGljdWxhciBwcm94eSB3 aWxsIGJlIHZpc2l0ZWQgKGlmIGl0IGlzIG1lbnRpb25lZA0KICAgID4+Pj4+ICAgIG9uIGEgUm91 dGUgaGVhZGVyKSwgYnV0IGl0IGlzIHByZXR0eSBjb21tb24gZm9yIHRoZSByZXF1ZXN0IHRvIHZp c2l0DQogICAgPj4+Pj4gICAgcHJveGllcyB1bmtub3duIChhdCBsZWFzdCBpbiBhZHZhbmNlKSB0 byB0aGUgVUFDLg0KICAgID4+Pj4gDQogICAgPj4+PiBJdCBpcyBpbXBvcnRhbnQgdG8gcmVtZW1i ZXIgdGhhdCwgc2luY2UgdGhlIHRva2VuIG5lZWRzIHRvIGJlIHByb3RlY3RlZCwgYSBwcm94eSBu ZWVkcyB0byBoYXZlIHRoZSANCiAgICA+Pj4+IGFzc29jaWF0ZWQgcHJvdGVjdGlvbiBjcmVkZW50 aWFscyB0byBiZSBhYmxlIHRvIGFjY2VzcyB0aGUgdG9rZW4uDQogICAgPj4+IA0KICAgID4+PiBJ J20gbG9zdCBoZXJlLiBIb3cgaXMgdGhlIHRva2VuIHByb3RlY3RlZD8gSXMgaXQgYmVjYXVzZSBp dCBpcyBwYXNzZWQgYnkgDQogICAgPj4+IHJlZmVyZW5jZSwgYW5kIG90aGVyIGNyZWRlbnRpYWxz IGFyZSBuZWVkZWQgdG8gZGVyZWZlcmVuY2UgaXQ/IE9yIGlzIGl0IA0KICAgID4+PiBwYXNzZWQg YnkgdmFsdWUgYnV0IGVuY3J5cHRlZD8NCiAgICA+PiANCiAgICA+PiAgICBUaGF0IGRlcGVuZHMg b24gaG93IHlvdXIgcHJvdGVjdCBpdC4NCiAgICA+PiANCiAgICA+PiAgICBJZiB0aGUgb2F1dGgy IHRva2VuIGl0c2VsZiBpcyBlbmNyeXB0ZWQsIGFuZCBvbmx5IGF1dGhvcml6ZWQgZW50aXRpZXMg Y2FuIGRlY3J5cHQgaXQsIHRoZW4gSSBndWVzcyBpdCBkb2VzIG5vdCBtYXR0ZXIgaWYgYSBub24t YXV0aG9yaXplZCB1c2VyIGdldHMgaXQsIGFzIGl0IHdpbGwgbm90IGJlIGFibGUgdG8gdXNlIGl0 Lg0KICAgID4+IA0KICAgID4+ICAgIEJ1dCwgaWYgdGhlIG9hdXRoMiB0b2tlbiBpcyBzZW50IGlu ICJwbGFpbiB0ZXh0IiwgdGhlbiB0aGUgU0lQIHNpZ25hbGluZyBuZWVkcyB0byBiZSBwcm90ZWN0 ZWQvZW5jcnlwdGVkLg0KICAgID4gRW5jcnlwdGlvbiBvZiBzaWduYWxsaW5nIGlzIG5vdCBnb2lu ZyB0byBwcm90ZWN0IGEgdG9rZW4gaW4gYSBTSVAgaGVhZGVyIGZyb20gcmVhY2hpbmcgdG8gdGhl IHdyb25nIHNlcnZlcnMsIGl0IGlzIGp1c3QgYQ0KICAgID4gZmlyc3QgaG9wIGVuY3J5cHRpb24u IFdlIGhhdmUgZmFyIHRvbyBtYW55IFNJUCBSRkNzIHRoYXQgaW5kaWNhdGUgdGhhdCBhbGwgc2Vj dXJpdHkgcHJvYmxlbXMgYXJlIHNvbHZlZCBpZiB3ZSB3cmFwIHNpZ25hbGxpbmcgaW4gVExTLg0K DQogICAgSXQgd291bGQgd29yayBpbiBuZXR3b3JrcyB3aGVyZSB0aGUgaW50ZXJmYWNlIGJldHdl ZW4gdGhlIGNsaWVudCBhbmQgc2VydmVyIGlzIGNvbnNpZGVyZWQgInRydXN0ZWQiLCBidXQgZm9y IHRoZSBnZW5lcmFsIGNhc2UgSSBhZ3JlZS4gDQoNCiAgICA+Pj4gQnV0LCBpbiB0aGF0IGNhc2Us IGlmIEkgbWFrZSBhIHBob25lIGNhbGwgdG8geW91LCBhbmQgdGhlIGNhbGwgaXRzZWxmIGlzIHZh bGlkLCB0aGVuIEkgc2hvdWxkIG5vdCBzZW5kIHlvdSB0aGUgb2F1dGgyIHRva2VuIHVubGVzcyBp dCdzIG1lYW50IA0KICAgID4+PiBmb3IgeW91LCBiZWNhdXNlIG9uY2UgeW91IGRlY3J5cHQgdGhl IHNpZ25hbGluZyB5b3Ugd2lsbCBoYXZlIGFjY2VzcyB0byBpdC4NCiAgICA+Pj4gUmlnaHQuIEFu ZCB3ZSBoYXZlIG5vIHdheSBpbiBTSVAgb2YgZm9yYmlkZGluZyBhbnkgc2VydmVyIG9mIGZvcndh cmRpbmcgYSBzcGVjaWZpYyBoZWFkZXIuDQogICAgPj4gDQogICAgPj4gICBXaGF0IGlzIGltcG9y dGFudCBpcyB0aGF0IGEgbm9uLWF1dGhvcml6ZWQgdXNlciBzaG91bGQgbm90IGhhdmUgYWNjZXNz IHRvIGEgbm9uLXByb3RlY3RlZCBvYXV0aDIgdG9rZW4uDQogICAgPiBEZWZpbmUg4oCcdXNlciIg YW5kIOKAnHRva2Vu4oCdLiAgQSBub24tZW5jcnlwdGVkIGFjY2VzcyB0b2tlbiBzaG91bGQgbm90 IGJlIHNoYXJlZCB3aXRoIGFueSB1bmF1dGhvcml6ZWQgU0lQIG5ldHdvcmsgZWxlbWVudCAtIGNs aWVudCBvciBzZXJ2ZXIgc29mdHdhcmUuDQoNCiAgICBDb3JyZWN0Lg0KDQogICAgKFRoZSByZWFz b24gSSB1c2VkICJ1c2VyIiB3YXMgYmVjYXVzZSB0aGUgdXNlLWNhc2Ugd2FzIGEgY2FsbCBiZXR3 ZWVuIHR3byB1c2VycykNCg0KICAgIFJlZ2FyZHMsDQoNCiAgICBDaHJpc3Rlcg0KDQogDQoNCg== From nobody Thu Jul 11 10:34:07 2019 Return-Path: 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 CDE27120106 for ; Thu, 11 Jul 2019 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 oUOTjH59HQmt for ; Thu, 11 Jul 2019 10:34:03 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20081.outbound.protection.outlook.com [40.107.2.81]) (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 DEBE91200D8 for ; Thu, 11 Jul 2019 10:34:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ajobQz90/qKKe/uYxLeVj6TtF2Qq7enur67UfW2ezQg8Mkg363yvxfdHg3IoOKCdETg3b4uayZ7PkCCIekO76XbY+HwtH19gcnVk37R/A5Gw3Nk/E12upq75eJC7TFL8EfUGzFAIU0D8p04bTxIkZvSfvF3MndY48FrKiwtb5i3ZqjXvl6TAKpqm8q1Jh31TGxggNOE3ce1Lz9m+nAzgZCmmmxcUCNYFWQHQR0aVcjWJIZgQ+BGDegn1NhgmBCIIhoeRrZSN0vJjO2QaNOqWhyUHUTwSIqYxmsGNEznQ6W6Lt1JJCv/jpNHE/vkcmUJzhXSr7dEDtPyL5OkY2km6Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IPJmajYFXY1CfiRe3ZRaguY7Fh8QhLowiF9XerVNTBs=; b=dWIo2a0BERw2WZHEAgNLhlIHuM9zVdEiwRpSHi1bXATxYiP7Vqbz3I3A/olwNf040gWViXPo34QKKeqpTArtvJ1TfBPZt7n6Oy15wzXUPTCM5A7Kdx0XfEYuDiqSpLqPTR/yd9T7nWY+Wnv2l8szp+LYGqQo8mo096wsHKpxqS+oTBWYN7CuYNcyNPhjSeJU3nZ1Y3I7GU82k7sbVa6szRmjijYD+MVWclxBvGyPvPxxC+lftfRkgyyHcfi/+ghwym+n8VrvWQjGLfRXlnKghCgc6Q2kmuxe2iZTTfZL8UaT8ZO7FhW3J4KenJXLOOs8iiC0F2nbM+ZBsJx4vJsZBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IPJmajYFXY1CfiRe3ZRaguY7Fh8QhLowiF9XerVNTBs=; b=UEAAywfx7Efn8PRSLEVe8DuiSTMqV0+z+utltlgrPGtaBcgsgOFM2FSPswrWtArrhr+xUvlAblOHqBjbUQ6DGyDGzi3HkXxDmtKXmvmTHAMjETmKmUn3URnE+W+yXK4HodQgx6AfIDFR+rJR9gf3ZWWFZtAEJvbiiNGF5hVMqdg= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4203.eurprd07.prod.outlook.com (20.176.166.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Thu, 11 Jul 2019 17:33:59 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 17:33:59 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIABDXaAgAA3igD//9RDgAALc6uA///Q/4CAADuIAP//1FUAgAA3WQD///38gIAANg6A///RVAAABuLOAAACr/yAAAEqU4A= Date: Thu, 11 Jul 2019 17:33:59 +0000 Message-ID: <82CEA4CF-7717-427A-B212-46FE09343968@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <5ABB2F7B-8928-4581-8AAD-C8EFDBE95F7E@edvina.net> <99649808-9894-42B4-ADD1-52D0F70A3FB3@ericsson.com> <7CE54346-6558-4605-A5DB-84C539400A19@edvina.net> <1C6CBDE3-EAD4-4470-A528-8EDA7F2487D2@ericsson.com> <8A712633-C587-40B7-9D8A-63AA9B636580@ericsson.com> <2929664D-4E91-4D45-8706-4F9D1038F55D@ericsson.com> <40288F76-525D-43A1-A679-9C5C869121AF@edvina.net> In-Reply-To: <40288F76-525D-43A1-A679-9C5C869121AF@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66edd023-c42f-46a9-5c2c-08d70625f572 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4203; x-ms-traffictypediagnostic: HE1PR07MB4203: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(346002)(396003)(136003)(189003)(199004)(76116006)(6512007)(44832011)(66946007)(66476007)(68736007)(6506007)(66446008)(53936002)(33656002)(6246003)(66556008)(64756008)(476003)(25786009)(446003)(2616005)(486006)(99286004)(11346002)(76176011)(102836004)(8936002)(229853002)(8676002)(81156014)(81166006)(186003)(26005)(6436002)(6486002)(478600001)(6916009)(36756003)(14454004)(305945005)(7736002)(14444005)(256004)(4326008)(58126008)(2906002)(66066001)(3846002)(6116002)(316002)(71190400001)(71200400001)(86362001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4203; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9Ka7xpVxBouJaX+cEAJItn+CtYmgdrH7irT7mTuUBRQkEvyEBm/Hbb1ECkosn8RsiiMnNQLVQOw1CYppfjunvZ7eM5of8Q5HgrgDtTJmZ8D6H3y1z/P1meLiY4UPaQhe+u4bLw14EcKtj16VWgerK8MO3RqCQahJncuR5K54kl1wQNFVDh1U0VkcBKlJsSg2SLIaaxZU2Hk803+cyrBMjWlv1xqN3lsRjM6thJyMo5ztkWr4ER+PiL5aaxgbjxURzsx5auLb94S/1XvFgFe1wkhPzMki9bKCjK1zylRFo8p+16/evCF/lO0D/V4DxdhlOIQ3sivv9F4yMmcnfAoh70VOecQteVljuEm3ajGqkggzeHzcYQeRNNDCrufw6+e710z/lljnbaNsD8FTGzJEl0H7RW+e5esfFVyZiLxppqw= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66edd023-c42f-46a9-5c2c-08d70625f572 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 17:33:59.6744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4203 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:34:06 -0000 SGksDQoNCiAgICA+Pj4+PiBBcyBhbiBleGFtcGxlOiBXaGVuIHJlYWRpbmcgdGhlIGRvY3MgSSBz ZWUgd2F5cyBvZiBwcm90ZWN0aW5nIHRoZSBhY2Nlc3MgdG9rZW4gc28gdGhhdCBvbmx5IGEgc3Bl Y2lmaWMgc2VydmljZSAocmVhZCBTSVAgZG9tYWluKSAgbWF5IGRlY3J5cHQgYW5kDQogICAgPj4+ Pj4gdXNlIGl0LiBUaGF0IHdheSB3ZSBkb27igJl0IG5lZWQgdG8gZGlzYWxsb3cgZm9yd2FyZGlu ZyBvZiBTSVAgbWVzc2FnZXMgd2l0aCBhIGJlYXJlciB0b2tlbiwgYXMgdGhlIHRva2VuIHdpbGwg YmUgdXNlbGVzcyBiZXlvbmQgdGhhdCBwb2ludC4NCiAgICA+Pj4+IA0KICAgID4+Pj4gICBKV1Qg Z2l2ZXMgeW91IHRoYXQgcHJvcGVydHksIGRvZXNuJ3QgaXQ/IFRoZXJlIGlzIG5vdGhpbmcgaW4g dGhlIGN1cnJlbnQgZHJhZnQgdGhhdCBmb3JiaWRzIG9yIHByZXZlbnRzIHlvdSBmcm9tIHVzaW5n IEpXVC4gQXMgd2Ugbm90ZWQgZWFybGllciwgaXQncyBwcm9iYWJseSANCiAgICA+Pj4+ICAgd2hh dCBtb3N0IChhbGw/KSBwZW9wbGUgYXJlIHVzaW5nIGFueXdheS4NCiAgICA+Pj4gDQogICAgPj4+ IFRoZSBpbXBsZW1lbnRhdGlvbnMgSeKAmXZlIHNlZW4gaXMgbW9zdGx5IHNpZ25lZCBKV1RzLCBi dXQgeW91IGFyZSByaWdodCwgSldUcyBjYW4gYmUgZW5jcnlwdGVkLg0KICAgID4+PiANCiAgICA+ Pj4+PiBTdGFydGluZyB0byBnbyBkb3duIHRoYXQgcm9hZCwgd2xpbCBkZWZpbml0ZWx5IG1lYW4g dGhhdCB3ZSBsZWF2ZSB0aGUgaW1wbGVtZW50YXRpb24geW91IGN1cnJlbnRseSBoYXZlIGJlaGlu ZC4gQW5kIHRoYXQgaXMganVzdA0KICAgID4+Pj4+IG9uZSBpc3N1ZS4gVGhlIG90aGVyIGlzIGhh dmluZyBhIHBhcnNhYmxlIGFjY2VzcyB0b2tlbiwgd2hpY2ggSSB0aGluayB3b3VsZCBiZSBhIHJl cXVpcmVtZW50IHRvIGZvbGxvdyB0aGUgQkNQIGFuZCBwcm9wYWJseSB0byBnZXQgdGhyb3VnaA0K ICAgID4+Pj4+IHRoZSBob2xlIHNlY3VyaXR5IGF1ZGl0IGZvciBhbnkgc3RhbmRhcmQtdHJhY2sg UkZDIHB1YmxpY2F0aW9uLg0KICAgID4+Pj4gDQogICAgPj4+PiAgIEpXVCBpcyBwYXJzYWJsZSA6 KQ0KICAgID4+Pj4gDQogICAgPj4+PiAgIElzIHlvdXIgaXNzdWUgdGhhdCB3ZSBkb24ndCBtYW5k YXRlIEpXVD8gSWYgc28sIHdoeSBkb24ndCB3ZSBsaWFpc2UgKGFzIHlvdSBzdWdnZXN0ZWQgZWFy bGllcikgd2l0aCB0aGUgb2F1dGggd2cgdG8gc2VlIA0KICAgID4+Pj4gICB3aGV0aGVyIGl0IHdv dWxkIGJlIHNhZmUgdG8gYXNzdW1lIHRoYXQgZXZlcnlvbmUgdXNlcyBKV1QuDQogICAgPj4+IA0K ICAgID4+PiBJIGRvbuKAmXQgdGhpbmsgd2UgY2FuIHJlYWNoIGFueSBsZXZlbCBvZiBhY2NlcHRh YmxlIHNlY3VyaXR5IGluIHRoaXMgd2l0aG91dCBwYXJzZWFibGUgYWNjZXNzIChhbmQgaWRlbnRp dHkpIHRva2Vucy4gQWxsIG5ldyBPYXV0aCANCiAgICA+Pj4gZG9jdW1lbnRzIGZyb20gdGhlIFdH IHNlZW1zIHRvIGFzc3VtZSB5b3UgY2FuIHRyYW5zcG9ydCBtZXRhZGF0YSBmcm9tIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciB0byB0aGUgcmVzb3VyY2Ugc2VydmVyIGluIA0KICAgID4+PiB0b2tl bnMgaW4gb3JkZXIgdG8gbGltaXQgYWNjZXNzIHRva2VuIHVzYWdlLiANCiAgICA+PiANCiAgICA+ Pj4gSW4gYWRkaXRpb24gSSB0aGluayBwdXR0aW5nIHRoZSBiZWFyZXIgdG9rZW4gaW4gYSBTSVAg aGVhZGVyIGlzIGRhbmdlcm91cyAtIGl0IHdpbGwgcmVxdWlyZSBhIGxvdCBmb3IgZXhpc3Rpbmcg bm9uLWNvbXBsaWFudCBicm93c2VycyANCiAgICA+Pj4gbm90IHRvIGxlYWsgdGhpcyBoZWFkZXIg b3V0IGluIHRoZSB3aWxkLg0KICAgID4+IA0KICAgID4+ICAgIFdoYXQgZG8geW91IG1lYW4gYnkg ImV4aXN0aW5nIG5vbi1jb21wbGlhbnQgYnJvd3NlcnPigJ0/DQogICAgPiBIYWhhLCB5ZXMsIHRo YXQgd2FzIG5vdCBwYXJzZWFibGUuIFN1YnN0aXR1dGUg4oCcYnJvd3NlcnPigJ0gd2l0aWgg4oCc U0lQIFByb3h5c+KAnSBhbmQgaXQgZ2V0cyBiZXR0ZXIuIFNvcnJ5Lg0KDQogICAgSXQncyBvay4g VGhlcmUgaGF2ZSBiZWVuIHNvIG1hbnkgZS1tYWlscyBzbyBJIHdhcyB3b25kZXJpbmcgd2hldGhl ciB0aGVyZSB3YXMgc29tZXRoaW5nIEkndmUgY29tcGxldGVseSBtaXNzZWQgOikNCg0KICAgID4+ PiBQcm90ZWN0aW5nIGl0IGluIGEgd2F5IHRoYXQgb25seSB0aGUgdGFyZ2V0ZWQgYXVkaWVuY2Ug Y2FuIGRlY29kZSBpdCBhbmQgdmFsaWRhdGUgaXQgd291bGQgbWFrZSB0aGUgc2l0dWF0aW9uIGJl dHRlci4NCiAgICA+PiANCiAgICA+PiAgICBBZ2FpbiwgSldUIDopDQogICAgPj4gDQogICAgPj4g ICAgWW91IGNhbiBpbmNsdWRlIEpXVCBlbmNvZGVkIGluZm9ybWF0aW9uIGluIGEgU0lQIGhlYWRl ci4gV2UgYWxyZWFkeSBkbyB0aGF0IGVsc2V3aGVyZS4gICAgDQogICAgPiBBYnNvbHV0ZWx5LiBC dXQgdGhlbiB3ZSBjYW7igJl0IGp1c3Qgc2F5IOKAnEpXVOKAnSB3ZSBoYXZlIHRvIHNwZWNpZnkg IOKAnGVuY3J5cHRlZCBhbmQgc2lnbmVkIEpXVOKAnS4NCiAgICANCiAgICBGYWlyIGVub3VnaC4N Cg0KICAgIFJlZ2FyZHMsDQoNCiAgICBDaHJpc3RlciANCg0K From nobody Thu Jul 11 10:34:20 2019 Return-Path: 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 53BE8120470 for ; Thu, 11 Jul 2019 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Go7j2_rvPMaU for ; Thu, 11 Jul 2019 10:34:14 -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 F099E120465 for ; Thu, 11 Jul 2019 10:34:13 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 C48C5A40; Thu, 11 Jul 2019 19:34:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 11 Jul 2019 19:34:10 +0200 Cc: Olle E Johansson , Paul Kyzivat , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <104E5E9E-8294-4DE0-A2DA-19199C2CD2BE@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:34:18 -0000 > On 11 Jul 2019, at 19:21, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>> 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. >>>>=20 >>>>> 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. >>>=20 >>> 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? >>>=20 >>> If it is protected, then why is there any concern over who it is = given to? >>=20 >> Normally most tokens are just digitially signed, but clear text. It = can be encrypted, but then the auth server need to know which key pair = to encrypt it with, which in turn means >> that the client needs to tell the auth server that which leads to a = requirement to have parseable access tokens. >=20 > I think the oauth2 token can be delivered non-encrypted to the SIIP = UA over HTTPS. The SIP UA can then encrypt the oauth2 token before = sending it over SIP. Now you have to have a shared key pair between every UA and the intended = SIP server. That=E2=80=99s far more complex than having it in the = authorization server. You put a lot of trust in TLS, which is fine. How do you handle = intercepting TLS proxys in the path in this scenario? /O From nobody Thu Jul 11 10:55:28 2019 Return-Path: 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 1603A1200A4 for ; Thu, 11 Jul 2019 10:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 L7XOPgM_GKWC for ; Thu, 11 Jul 2019 10:55:24 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50053.outbound.protection.outlook.com [40.107.5.53]) (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 1D6D512002E for ; Thu, 11 Jul 2019 10:55:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kw2Pg/7jbeUwzGUXMr06PfcrAZcEKtJl4adPdIxNhOMz4ULUIaRySnrCFxEI3MxeJKxV9t2BtzdhVm4YQzs6l0cDSdhrvOmNTp7CF1eGA4m/k3FcEt/Qx2z4sUjK9uoQqODqyAyr74LrnN43BZu1jDZswgt1mleECo170Y4bxrtlK/BcGbNxPUGwt7JPSHNUQXHTG40ENwsq6gD6hcuuilHKZy10VRxAXTcbFwt7Js8nuI/vliyNLipfhGvDMeEdkOuh+GjKvM/QEhzzPC9aeikEqlpsBGD7as59JWTYUDorAlmVzB81d6CSaCiF7cPmd3P0nqhWTVF0aQDS5F7fRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qhkhHNzgbcLhWkz22wuzEyKlIGLRxuAn3HR6BhcgqGQ=; b=Jy0RpU+Ko+yAN84OG9piJ5CSPng1UMEdjFIQvPIoTmBNAH1M6jaVC6+cgIcWSuwFHb0bDPxqceIvOSLYGk5DMbE1qepkgs0lXJyPo0lyQ3bnbeOj6CVncOojhHckS7pR283GdwjupKmvg6EvbN/CogS1DgvJitUXF433lDfutdmVu9HTSMURyXZHulJE612EJSQyx+F39QBttxIlwZpzIRpYByEZNxMJdJkVoGA6E7ML+3UEqkiA/X8s9thkI/ohpjJlev4OdGJ84Ghnki51Dx+lsYvtM0uh3SMJY86jZmJQVRWi4KFel+BY/HLyTaPgcYfsHe3yf0IbyiVZzQsCyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qhkhHNzgbcLhWkz22wuzEyKlIGLRxuAn3HR6BhcgqGQ=; b=YhlydiSY76ZDALThJI91VxJPcoNhv6X8bNfuSY1DosWOjNkyT18s7HCHLWfSUPIYDlszJJv/DNRAsc/bfkGuFO9aKd0fh79+RUfmH4FYsp0zGR0q9UpR/yIScorwC4Xf37fKW2xjxq2sX7KN55JZH2CFk8Sy1fZe4BRBWZ2OZo0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3129.eurprd07.prod.outlook.com (10.170.245.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.7; Thu, 11 Jul 2019 17:55:20 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 17:55:20 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgIAAP24AgAA4AgCAADVqAP//0S4AAAcGhIA= Date: Thu, 11 Jul 2019 17:55:19 +0000 Message-ID: <88220567-FF78-4680-B724-1FB9D72F2FBD@ericsson.com> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> <104E5E9E-8294-4DE0-A2DA-19199C2CD2BE@edvina.net> In-Reply-To: <104E5E9E-8294-4DE0-A2DA-19199C2CD2BE@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: beb503a6-34f8-4ef9-33d4-08d70628f093 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3129; x-ms-traffictypediagnostic: HE1PR07MB3129: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(366004)(39860400002)(376002)(136003)(189003)(199004)(305945005)(81166006)(3846002)(66446008)(71190400001)(99286004)(81156014)(7736002)(71200400001)(76176011)(8676002)(6436002)(6506007)(6486002)(64756008)(66476007)(66556008)(6116002)(229853002)(25786009)(5660300002)(102836004)(2906002)(486006)(66946007)(8936002)(26005)(76116006)(256004)(14444005)(58126008)(36756003)(68736007)(478600001)(316002)(44832011)(6916009)(66066001)(53936002)(14454004)(33656002)(6246003)(476003)(2616005)(4326008)(446003)(11346002)(186003)(86362001)(54906003)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3129; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: golwWG0FeDfMIz0ATFvFauY60NHRiznYKGgwG0vshOSri5VXHJF7H/U9SIYrsziI0kygHbnxSDFkIbmYRj/TLejOcFqBzPmRGsUBF0a+FxXkN46+ys3DOgjz8M4H3DZOI9jlt4RugzJBsCyrKEm428urnhAxOq0Pi0s6TcjsttSnK3b7a8FPDfOZtjURrClhT/c4TTmJN+uBMS95Zn857Dm2GymhssTsSau7KpEdrY7YIgcCrymHl6LH4TSno5v3ak0lExzyCJsbyfhXSi0Ub1vw9lDnlIPPThX5fSqpIJSHdH/jfqSSw37ruGJ3827UiLsvU7kX8y4au/ro3d4E20DTZIrH6huxD9d/z9Qu1/UTjM1mKjyBy1QHahEaoEVfL11e3EQDYq+C5JMJvQVHll0Y+nGJQ8hP5XYWcTsXinU= Content-Type: text/plain; charset="utf-8" Content-ID: <3D0C9517FDB3B943B18FCCF2449B763D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: beb503a6-34f8-4ef9-33d4-08d70628f093 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 17:55:19.9852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3129 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:55:27 -0000 SGksDQoNCiAgICA+Pj4+Pj4+IEFsbCBJIGFtIHNheWluZyBpcyB0aGF0IG9uZSBzaG91bGQgbm90 IHNlbmQgYSB0b2tlbiB0byBzb21lb25lIHRoYXQgaXQgaGFzIE5PVCBiZWVuIGlzc3VlZCBmb3Iu DQogICAgPj4+Pj4+ICAgICAgIFRoZW4geW91IGFyZSBzYXlpbmcgdGhhdCBhIHRva2VuIHNob3Vs ZCAqbmV2ZXIqIGJlIGluY2x1ZGVkIGluIGEgcmVxdWVzdA0KICAgID4+Pj4+PiAgIHRvIGEgdGFy Z2V0IGZvciB3aGljaCB5b3UgaGF2ZSBub3QgcmVjZWl2ZWQgYSBjaGFsbGVuZ2Ugc29tZSB0aW1l IGluIHRoZQ0KICAgID4+Pj4+PiAgIHBhc3QuDQogICAgPj4+Pj4+ICAgICAgIFRoYXQgaXMgYSBi aXQgZXh0cmVtZSwgYnV0IEkgZ3Vlc3MgeW91IGNhbiBzcGVjaWZ5IHRoYXQgaWYgeW91IHRoaW5r IGl0DQogICAgPj4+Pj4+ICAgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLg0KICAgID4+Pj4+IFRo YXQgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgZ2VuZXJpYyBPQXV0aCBzZWN1cml0eSBjb25z aWRlcmF0aW9uczogeW91IGRvbid0IGdpdmUgYSB0b2tlbiB0byBzb21lb25lIGl0IHdhcyBub3Qg aW50ZW5kZWQgZm9yLg0KICAgID4+Pj4+IE9mIGNvdXJzZSwgaWYgeW91IGtub3cgKGJhc2VkIG9u IHdoYXRldmVyIGNvbmZpZ3VyYXRpb24vcG9saWN5KSB0aGF0IGl0J3Mgb2sgdG8gZ2l2ZSB0aGUg dG9rZW4gdG8gdGhlIHRhcmdldCBJIGd1ZXNzIHlvdSBjb3VsZCBkbyBpdC4NCiAgICA+Pj4+PiAN CiAgICA+Pj4+Pj4gICBCdXQgbm90ZSB0aGF0IHRoaXMgbG9naWMgd29uJ3QgYWx3YXlzIHdvcmsg Zm9yIFByb3h5LUF1dGhlbnRpY2F0ZS4gWW91DQogICAgPj4+Pj4+ICAgKm1pZ2h0KiBrbm93IHRo YXQgYSBwYXJ0aWN1bGFyIHByb3h5IHdpbGwgYmUgdmlzaXRlZCAoaWYgaXQgaXMgbWVudGlvbmVk DQogICAgPj4+Pj4+ICAgb24gYSBSb3V0ZSBoZWFkZXIpLCBidXQgaXQgaXMgcHJldHR5IGNvbW1v biBmb3IgdGhlIHJlcXVlc3QgdG8gdmlzaXQNCiAgICA+Pj4+Pj4gICBwcm94aWVzIHVua25vd24g KGF0IGxlYXN0IGluIGFkdmFuY2UpIHRvIHRoZSBVQUMuDQogICAgPj4+Pj4gIEl0IGlzIGltcG9y dGFudCB0byByZW1lbWJlciB0aGF0LCBzaW5jZSB0aGUgdG9rZW4gbmVlZHMgdG8gYmUgcHJvdGVj dGVkLCBhIHByb3h5IG5lZWRzIHRvIGhhdmUgdGhlIGFzc29jaWF0ZWQgcHJvdGVjdGlvbiBjcmVk ZW50aWFscyB0byBiZSBhYmxlIHRvIGFjY2VzcyB0aGUgdG9rZW4uDQogICAgPj4+PiANCiAgICA+ Pj4+IEknbSBsb3N0IGhlcmUuIEhvdyBpcyB0aGUgdG9rZW4gcHJvdGVjdGVkPyBJcyBpdCBiZWNh dXNlIGl0IGlzIHBhc3NlZCBieSByZWZlcmVuY2UsIGFuZCBvdGhlciBjcmVkZW50aWFscyBhcmUg bmVlZGVkIHRvIGRlcmVmZXJlbmNlIGl0PyBPciBpcyBpdCBwYXNzZWQgYnkgdmFsdWUgYnV0IGVu Y3J5cHRlZD8NCiAgICA+Pj4+IA0KICAgID4+Pj4gSWYgaXQgaXMgcHJvdGVjdGVkLCB0aGVuIHdo eSBpcyB0aGVyZSBhbnkgY29uY2VybiBvdmVyIHdobyBpdCBpcyBnaXZlbiB0bz8NCiAgICA+Pj4g DQogICAgPj4+IE5vcm1hbGx5IG1vc3QgdG9rZW5zIGFyZSBqdXN0IGRpZ2l0aWFsbHkgc2lnbmVk LCBidXQgY2xlYXIgdGV4dC4gSXQgY2FuIGJlIGVuY3J5cHRlZCwgYnV0IHRoZW4gdGhlIGF1dGgg c2VydmVyIG5lZWQgdG8ga25vdyB3aGljaCBrZXkgcGFpciB0byBlbmNyeXB0IGl0IHdpdGgsIHdo aWNoIGluIHR1cm4gbWVhbnMNCiAgICA+Pj4gdGhhdCB0aGUgY2xpZW50IG5lZWRzIHRvIHRlbGwg dGhlIGF1dGggc2VydmVyIHRoYXQgd2hpY2ggbGVhZHMgdG8gYSByZXF1aXJlbWVudCB0byBoYXZl IHBhcnNlYWJsZSBhY2Nlc3MgdG9rZW5zLg0KICAgID4+IA0KICAgID4+ICAgIEkgdGhpbmsgdGhl IG9hdXRoMiB0b2tlbiBjYW4gYmUgZGVsaXZlcmVkIG5vbi1lbmNyeXB0ZWQgdG8gdGhlIFNJSVAg VUEgb3ZlciBIVFRQUy4gVGhlIFNJUCBVQSBjYW4gdGhlbiBlbmNyeXB0IHRoZSBvYXV0aDIgdG9r ZW4gYmVmb3JlIHNlbmRpbmcgaXQgb3ZlciBTSVAuDQogICAgPiBOb3cgeW91IGhhdmUgdG8gaGF2 ZSBhIHNoYXJlZCBrZXkgcGFpciBiZXR3ZWVuIGV2ZXJ5IFVBIGFuZCB0aGUgaW50ZW5kZWQgU0lQ IHNlcnZlci4gVGhhdOKAmXMgZmFyIG1vcmUgY29tcGxleCB0aGFuIGhhdmluZyBpdCBpbiB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoNCiAgICBOb3cgd2UgYXJlIGNvbWluZyBiYWNrIHRvIHdo ZXJlIHRoaXMgd291bGQgYWN0dWFsbHkgYmUgdXNlZCA6KQ0KDQogICAgQWdhaW4sIHRoZSBvbmx5 IHVzZS1jYXNlIEkgYW0gYXdhcmUgb2YgaXMgU0lQIHJlZ2lzdHJhdGlvbiwgYW5kIHRoZW4gdGhl IG9ubHkgImludGVuZGVkIFNJUCBzZXJ2ZXIiIGlzIHRoZSByZWdpc3RyYXIuDQoNCiAgICBJbiBh bnkgY2FzZSwgSSB0aGluayB0aGlzIGlzIGEgZGVwbG95bWVudCBxdWVzdGlvbiwgc28gd2UgZG9u J3QgbmVlZCB0byBtYW5kYXRlIG9uZSB3YXkgb3IgYW5vdGhlci4gV2hhdCBtYXR0ZXJzIGlzIHRo YXQgdGhlIEpXVCBpcyBwcm90ZWN0ZWQgb24gdGhlIFNJUCBpbnRlcmZhY2UuDQoNCiAgICA+IFlv dSBwdXQgYSBsb3Qgb2YgdHJ1c3QgaW4gVExTLCB3aGljaCBpcyBmaW5lLiBIb3cgZG8geW91IGhh bmRsZSBpbnRlcmNlcHRpbmcgVExTIHByb3h5cyBpbiB0aGUgcGF0aCBpbiB0aGlzIHNjZW5hcmlv Pw0KDQogICAgSSBndWVzcyB3ZSdkIGhhdmUgdG8gYXNrIHRoZSBPQXV0aCBleHBlcnRzIGFib3V0 IHRoYXQsIGJ1dCBpbiBnZW5lcmFsIEkgdGhpbmsgd2UgY2FuIHB1dCBhcyBtdWNoIHRydXN0IGlu IEhUVFBTIGFzIGFueSBlbHNlIGRvZXMgOikgDQoNCiAgICBBbmQsIGZvciB0aGUgU0lQIHJlZ2lz dHJhdGlvbiBjYXNlLCBJIGRvbid0IHRoaW5rIGl0IGV2ZW4gd291bGQgYmUgYSBwcm9ibGVtIGZv ciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gbWFpbnRhaW4gdGhlIGtleXMgb2YgdGhlIFVB IGFuZCB0aGUgcmVnaXN0cmFyLg0KDQogICAgQXQgdGhlIGVuZCBvZiB0aGUgZGF5LCB5b3UgaGF2 ZSB0byBjaG9vc2UgYSBzb2x1dGlvbiB0aGF0IGZpdHMgeW91ciB1c2UtY2FzZS4gTWF5YmUgdGhp cyBzb2x1dGlvbiBpc24ndCBmZWFzaWJsZSBmb3IgYWxsIHVzZS1jYXNlcywgZXZlbiBpZiBpdCB0 ZWNobmljYWxseSBzdXBwb3J0cyB0aGVtLiBPQXV0aCBtYXkgZml0IGNlcnRhaW4gdXNlLWNhc2Vz IGJldHRlciB0aGFuIG90aGVycywgYW5kIHRoZXJlIGlzIG5vdGhpbmcgd2UgY2FuIGRvIGFib3V0 IHRoYXQuDQogICANCiAgICBSZWdhcmRzLA0KDQogICAgQ2hyaXN0ZXINCg0KICAgIA0KICAgIA0K ICAgIA0KDQo= From nobody Thu Jul 11 12:00:14 2019 Return-Path: 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 E1E9F120495 for ; Thu, 11 Jul 2019 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q2xRhzmGV3Qy for ; Thu, 11 Jul 2019 12:00:04 -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 61858120331 for ; Thu, 11 Jul 2019 12:00:03 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 21578A40; Thu, 11 Jul 2019 21:00:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: <88220567-FF78-4680-B724-1FB9D72F2FBD@ericsson.com> Date: Thu, 11 Jul 2019 20:59:59 +0200 Cc: Olle E Johansson , Paul Kyzivat , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <60E252FC-6B02-4B6C-9034-157909BF72E8@edvina.net> References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> <104E5E9E-8294-4DE0-A2DA-19199C2CD2BE@edvina.net> <88220567-FF78-4680-B724-1FB9D72F2FBD@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 19:00:12 -0000 > On 11 Jul 2019, at 19:55, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>>>>> 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. >>>>>>=20 >>>>>>> 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. >>>>>=20 >>>>> 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? >>>>>=20 >>>>> If it is protected, then why is there any concern over who it is = given to? >>>>=20 >>>> Normally most tokens are just digitially signed, but clear text. It = can be encrypted, but then the auth server need to know which key pair = to encrypt it with, which in turn means >>>> that the client needs to tell the auth server that which leads to a = requirement to have parseable access tokens. >>>=20 >>> I think the oauth2 token can be delivered non-encrypted to the = SIIP UA over HTTPS. The SIP UA can then encrypt the oauth2 token before = sending it over SIP. >> Now you have to have a shared key pair between every UA and the = intended SIP server. That=E2=80=99s far more complex than having it in = the authorization server. >=20 > Now we are coming back to where this would actually be used :) >=20 > Again, the only use-case I am aware of is SIP registration, and = then the only "intended SIP server" is the registrar. And you may pass through a number of SIP proxys on the way. There has been many mails questioning the focus on registration. You = keep coming back to that - what is so different with authentication for a REGISTER than other SIP methods in your view? I=E2=80=99m curious. >=20 > In any case, I think this is a deployment question, so we don't = need to mandate one way or another. What matters is that the JWT is = protected on the SIP interface. I believe others are working on that part - confidentiality between = authorization server and resource server. >=20 >> You put a lot of trust in TLS, which is fine. How do you handle = intercepting TLS proxys in the path in this scenario? >=20 > I guess we'd have to ask the OAuth experts about that, but in = general I think we can put as much trust in HTTPS as any else does :)=20 Which means almost no trust any more... >=20 > And, for the SIP registration case, I don't think it even would be = a problem for the authorization server to maintain the keys of the UA = and the registrar. Agree for many more use cases than just registration :-) >=20 > At the end of the day, you have to choose a solution that fits your = use-case. Maybe this solution isn't feasible for all use-cases, even if = it technically supports them. OAuth may fit certain use-cases better = than others, and there is nothing we can do about that. Depends on the definition of =E2=80=9Cthis solution=E2=80=9D. I do agree = that Oauth2 may not fit all use cases for SIP, but any step away from = the current Digest Auth is a step forward. If you read up on the large amount of drafts and RFCs from the Oauth wg = and OpenID connect you=E2=80=99ll find that they are targeting many = types of situations that=20 would fit not only browser-based SIP ua=E2=80=99s but also SIP desktop = phones and maybe ATA-like boxes. Mutual TLS cert auth hasn=E2=80=99t taken off, which is the only = alternative we currrently have. I do hope we can sort this out and = document a good framework. /O >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 From nobody Thu Jul 11 13:08:06 2019 Return-Path: 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 6BBE4120168 for ; Thu, 11 Jul 2019 13:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 WticcV4fBKrv for ; Thu, 11 Jul 2019 13:08:01 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::60d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1A012022E for ; Thu, 11 Jul 2019 13:08:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VLx3xldNTXAvlH8TYrydDXIU9U83+eqnFx7BIUgyIqbO3/7fIS+pfE74HksdguFZ8gGx9lbhiGue+rRPGaYQ1ZmrQaFOJ6XewmGYtegv1DSxkL+u1iG3w1H8v1hl3FPaOzhpidSMc0nO6Ux6WIop2Y1Fg0iKGrgUwuwZeKqCPBMvGINqUQaljIdsTf5jv8hHpXrx/JYcR2UXiH+zYHjQxz2ChBOjvuO9siwt28FWhu/EFft6MDhTltQCdZTcIc3vFwoSoczEtWrpLWUdBdPoTMRF+CbVv0YO2i87X0SCKY/xIP+OTIN3G1j5/edfuq9D9ht2PSnFnF/zc5whc6kjOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zu4CyH6CQkfakqtEu1NvUmtZZjBeaS9enM679N1sVdY=; b=kIHEBP8u6aBzDXwXCkzhSUslZbmJklXuaMYPBZhUlfC1UiWAjoTUL0jwnl2/Aw7Qdq/soYkFJ1EoyK3rfFbM5pgArlVIAY4Fp/ZJ/t/+/ciVklct97baGZrqGxUHfdhDsdmfSEFD1IfRp9UxLen77D1oIeY/ev5muKtAPTDJtRhw2CM8ffw30rDAsp/0PVGYrIoCa3koF4sovY7JYKuFiDtdBScNvxgWZq4SG9I6G/bJ0F1WLmTdi+W6qXceKelhdLOAOcB/sHU87deqS48Am/+OOv8TaqBdlpwXUQpjoyeJeDHh13CSljD6pohnUNFxNbx6wHUoqF2O0jlNJAZh3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zu4CyH6CQkfakqtEu1NvUmtZZjBeaS9enM679N1sVdY=; b=Fs6DE9mz29Q8RNl+VkAvCmij96dQl5hWujYojVXtkZHAFBC1K3wb/m7A/G6V8XZN+UQwuTPa6CXRPaz166fGtlAEbGdptLIy7AExxdMrHKZc90YuuybGDyF9gC18Bd0clKmz1lQ3RC888mzSNIx19OEAXN6KzNuD4u4YLQrB5vM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4188.eurprd07.prod.outlook.com (20.176.166.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.9; Thu, 11 Jul 2019 20:07:58 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Thu, 11 Jul 2019 20:07:57 +0000 From: Christer Holmberg To: "Olle E. Johansson" CC: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt Thread-Index: AQHVNLWxruT/m/C2REGBvr04oIfCDqa/Al8AgAHwRACAACa0QIAAOvWAgACKbgCAAH00gIAARqSA///Z+ACAADMUgP//1TCAgABAXACAATj+gIAAOeSAgABE8QCAALlBgIAAP24AgAA4AgCAADVqAP//0S4AAAcGhID//9/GgP//9LiA Date: Thu, 11 Jul 2019 20:07:57 +0000 Message-ID: References: <156249821133.14592.1211919336596009446@ietfa.amsl.com> <68ed93ae-57df-6bc7-774b-47959417abda@alum.mit.edu> <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> <89A28FAE-A25A-4AFF-9A94-91E09FDD6C3B@ericsson.com> <2aa8cb91-aac6-b66e-e54a-b9f6c650ce02@alum.mit.edu> <3B02CDE8-77C3-4DD8-940B-8B41993FFD1D@edvina.net> <104E5E9E-8294-4DE0-A2DA-19199C2CD2BE@edvina.net> <88220567-FF78-4680-B724-1FB9D72F2FBD@ericsson.com> <60E252FC-6B02-4B6C-9034-157909BF72E8@edvina.net> In-Reply-To: <60E252FC-6B02-4B6C-9034-157909BF72E8@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [62.113.190.248] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bed07582-e397-4caa-0563-08d7063b77da x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4188; x-ms-traffictypediagnostic: HE1PR07MB4188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(396003)(39860400002)(136003)(199004)(189003)(14444005)(66946007)(256004)(76116006)(186003)(102836004)(66446008)(64756008)(66556008)(66476007)(26005)(14454004)(71190400001)(5660300002)(86362001)(2906002)(74316002)(66066001)(33656002)(6506007)(229853002)(3846002)(6116002)(316002)(81156014)(9686003)(44832011)(476003)(305945005)(8676002)(54906003)(25786009)(66574012)(478600001)(6916009)(4326008)(76176011)(7696005)(55016002)(81166006)(52536014)(71200400001)(446003)(99286004)(53936002)(6246003)(8936002)(68736007)(6436002)(486006)(7736002)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4188; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: R4Oe1yAHyMA+au4C281ob32vyQE7ymZ9nFEafAa76MjBQ9og6x/VbzG0+qtKCJFSU1EutTDdhXEWMUq0VOuFGWRG/YdRfZ8hyu20+GhIVfltNzzrWlRuc2YRNWMErRPiYNi7pnVnBG+0FEcq6t1p0hGIKsBvQHU8S7qz7I8IF5LQ6HqAj9n3OCMv8e8E3Smbs/ftXcl2Ldn9xdwDVk8NeNTIJJsoESYIw8mHddhvq32Q7HVjTdOs7k6wo0zt3bGBiBHdPsJEjENbbduAI8ztGd38DnqzBy9fdNoReNCWl9mJMlPh4hHmJltIy0GCt1jCR4CuHI0zP10eIK+Vk/R2utQPV8wu57DKpamrjxI0cscVd+rYiWz3Emk14N/RxkFZAvRo9SDkRTjC7UfLbLoPTpBGv38EH0WfoiIgYpd8HfE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bed07582-e397-4caa-0563-08d7063b77da X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 20:07:57.8419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4188 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:08:05 -0000 SGksDQoNCj4+Pj4+Pj4+PiBBbGwgSSBhbSBzYXlpbmcgaXMgdGhhdCBvbmUgc2hvdWxkIG5vdCBz ZW5kIGEgdG9rZW4gdG8gc29tZW9uZSB0aGF0IGl0IGhhcyBOT1QgYmVlbiBpc3N1ZWQgZm9yLg0K Pj4+Pj4+Pj4gICAgICBUaGVuIHlvdSBhcmUgc2F5aW5nIHRoYXQgYSB0b2tlbiBzaG91bGQgKm5l dmVyKiBiZSBpbmNsdWRlZCANCj4+Pj4+Pj4+IGluIGEgcmVxdWVzdCAgdG8gYSB0YXJnZXQgZm9y IHdoaWNoIHlvdSBoYXZlIG5vdCByZWNlaXZlZCBhIA0KPj4+Pj4+Pj4gY2hhbGxlbmdlIHNvbWUg dGltZSBpbiB0aGUgIHBhc3QuDQo+Pj4+Pj4+PiAgICAgIFRoYXQgaXMgYSBiaXQgZXh0cmVtZSwg YnV0IEkgZ3Vlc3MgeW91IGNhbiBzcGVjaWZ5IHRoYXQgaWYgDQo+Pj4+Pj4+PiB5b3UgdGhpbmsg aXQgIGlzIHRoZSByaWdodCB0aGluZyB0byBkby4NCj4+Pj4+Pj4gVGhhdCBpcyBteSB1bmRlcnN0 YW5kaW5nIG9mIHRoZSBnZW5lcmljIE9BdXRoIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiB5b3Ug ZG9uJ3QgZ2l2ZSBhIHRva2VuIHRvIHNvbWVvbmUgaXQgd2FzIG5vdCBpbnRlbmRlZCBmb3IuDQo+ Pj4+Pj4+IE9mIGNvdXJzZSwgaWYgeW91IGtub3cgKGJhc2VkIG9uIHdoYXRldmVyIGNvbmZpZ3Vy YXRpb24vcG9saWN5KSB0aGF0IGl0J3Mgb2sgdG8gZ2l2ZSB0aGUgdG9rZW4gdG8gdGhlIHRhcmdl dCBJIGd1ZXNzIHlvdSBjb3VsZCBkbyBpdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgQnV0IG5vdGUg dGhhdCB0aGlzIGxvZ2ljIHdvbid0IGFsd2F5cyB3b3JrIGZvciANCj4+Pj4+Pj4+IFByb3h5LUF1 dGhlbnRpY2F0ZS4gWW91DQo+Pj4+Pj4+PiAgKm1pZ2h0KiBrbm93IHRoYXQgYSBwYXJ0aWN1bGFy IHByb3h5IHdpbGwgYmUgdmlzaXRlZCAoaWYgaXQgaXMgDQo+Pj4+Pj4+PiBtZW50aW9uZWQgIG9u IGEgUm91dGUgaGVhZGVyKSwgYnV0IGl0IGlzIHByZXR0eSBjb21tb24gZm9yIHRoZSANCj4+Pj4+ Pj4+IHJlcXVlc3QgdG8gdmlzaXQgIHByb3hpZXMgdW5rbm93biAoYXQgbGVhc3QgaW4gYWR2YW5j ZSkgdG8gdGhlIFVBQy4NCj4+Pj4+Pj4gSXQgaXMgaW1wb3J0YW50IHRvIHJlbWVtYmVyIHRoYXQs IHNpbmNlIHRoZSB0b2tlbiBuZWVkcyB0byBiZSBwcm90ZWN0ZWQsIGEgcHJveHkgbmVlZHMgdG8g aGF2ZSB0aGUgYXNzb2NpYXRlZCBwcm90ZWN0aW9uIGNyZWRlbnRpYWxzIHRvIGJlIGFibGUgdG8g YWNjZXNzIHRoZSB0b2tlbi4NCj4+Pj4+PiANCj4+Pj4+PiBJJ20gbG9zdCBoZXJlLiBIb3cgaXMg dGhlIHRva2VuIHByb3RlY3RlZD8gSXMgaXQgYmVjYXVzZSBpdCBpcyBwYXNzZWQgYnkgcmVmZXJl bmNlLCBhbmQgb3RoZXIgY3JlZGVudGlhbHMgYXJlIG5lZWRlZCB0byBkZXJlZmVyZW5jZSBpdD8g T3IgaXMgaXQgcGFzc2VkIGJ5IHZhbHVlIGJ1dCBlbmNyeXB0ZWQ/DQo+Pj4+Pj4gDQo+Pj4+Pj4g SWYgaXQgaXMgcHJvdGVjdGVkLCB0aGVuIHdoeSBpcyB0aGVyZSBhbnkgY29uY2VybiBvdmVyIHdo byBpdCBpcyBnaXZlbiB0bz8NCj4+Pj4+IA0KPj4+Pj4gTm9ybWFsbHkgbW9zdCB0b2tlbnMgYXJl IGp1c3QgZGlnaXRpYWxseSBzaWduZWQsIGJ1dCBjbGVhciB0ZXh0LiBJdCANCj4+Pj4+IGNhbiBi ZSBlbmNyeXB0ZWQsIGJ1dCB0aGVuIHRoZSBhdXRoIHNlcnZlciBuZWVkIHRvIGtub3cgd2hpY2gg a2V5IHBhaXIgdG8gZW5jcnlwdCBpdCB3aXRoLCB3aGljaCBpbiB0dXJuIG1lYW5zIHRoYXQgdGhl IGNsaWVudCBuZWVkcyANCj4+Pj4+IHRvIHRlbGwgdGhlIGF1dGggc2VydmVyIHRoYXQgd2hpY2gg bGVhZHMgdG8gYSByZXF1aXJlbWVudCB0byBoYXZlIHBhcnNlYWJsZSBhY2Nlc3MgdG9rZW5zLg0K Pj4+PiANCj4+Pj4gICBJIHRoaW5rIHRoZSBvYXV0aDIgdG9rZW4gY2FuIGJlIGRlbGl2ZXJlZCBu b24tZW5jcnlwdGVkIHRvIHRoZSBTSUlQIFVBIG92ZXIgSFRUUFMuIFRoZSBTSVAgVUEgY2FuIHRo ZW4gZW5jcnlwdCB0aGUgb2F1dGgyIHRva2VuIGJlZm9yZSBzZW5kaW5nIGl0IG92ZXIgU0lQLg0K Pj4+IE5vdyB5b3UgaGF2ZSB0byBoYXZlIGEgc2hhcmVkIGtleSBwYWlyIGJldHdlZW4gZXZlcnkg VUEgYW5kIHRoZSBpbnRlbmRlZCBTSVAgc2VydmVyLiBUaGF04oCZcyBmYXIgbW9yZSBjb21wbGV4 IHRoYW4gaGF2aW5nIGl0IGluIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4NCj4+IA0KPj4gICAg Tm93IHdlIGFyZSBjb21pbmcgYmFjayB0byB3aGVyZSB0aGlzIHdvdWxkIGFjdHVhbGx5IGJlIHVz ZWQgOikNCj4+IA0KPj4gICAgQWdhaW4sIHRoZSBvbmx5IHVzZS1jYXNlIEkgYW0gYXdhcmUgb2Yg aXMgU0lQIHJlZ2lzdHJhdGlvbiwgYW5kIHRoZW4gdGhlIG9ubHkgImludGVuZGVkIFNJUCBzZXJ2 ZXIiIGlzIHRoZSByZWdpc3RyYXIuDQo+IEFuZCB5b3UgbWF5IHBhc3MgdGhyb3VnaCBhIG51bWJl ciBvZiBTSVAgcHJveHlzIG9uIHRoZSB3YXkuDQoNClllcywgYnV0IHRoZXkgd2lsbCBub3QgYmUg ImludGVuZGVkIHNlcnZlciIgKHJlYWQ6IGF1dGhvcml6ZWQgdG8gc2VlIHRoZSBvYXV0aDIgdG9r ZW4pLCBzbyBubyBuZWVkIHRvIHN0b3JlIGFueSBrZXlzIGZvciB0aG9zZSBwcm94aWVzLiBPbmx5 IHRoZSByZWdpc3RyYXIgaXMgdGhlICJpbnRlbmRlZCBzZXJ2ZXIiLg0KDQo+IFRoZXJlIGhhcyBi ZWVuIG1hbnkgbWFpbHMgcXVlc3Rpb25pbmcgdGhlIGZvY3VzIG9uIHJlZ2lzdHJhdGlvbi4gWW91 IGtlZXAgY29taW5nIGJhY2sgdG8gdGhhdCAtIHdoYXQgaXMgc28gZGlmZmVyZW50IHdpdGggYXV0 aGVudGljYXRpb24gDQo+IGZvciBhIFJFR0lTVEVSIHRoYW4gb3RoZXIgU0lQIG1ldGhvZHMgaW4g eW91ciB2aWV3PyBJ4oCZbSBjdXJpb3VzLg0KDQpUaGUgbnVtYmVyIG9yIGVudGl0aWVzIHRoYXQg d2lsbCBhdXRoZW50aWNhdGUgdGhlIFVBLiBZb3Ugd2VyZSB0YWxraW5nIGFib3V0IGhhdmluZyBr ZXlzIGZvciB0aGUgVUEgYW5kIGV2ZXJ5IGludGVuZGVkIHNlcnZlci4gSW4gY2FzZSBvZiByZWdp c3RyYXRpb24sIHRoZSBvbmx5ICJpbnRlbmRlZCBzZXJ2ZXIiIGlzIHRoZSByZWdpc3RyYXIuDQoN Ck9mIGNvdXJzZSwgdGhlcmUgbWF5IGFsc28gYmUgb3RoZXIgdXNlLWNhc2VzIHdoZXJlIHRoZXJl IGlzIG9ubHkgb25lIChvciBhIGZldykgaW50ZW5kZWQgc2VydmVyLCBlLmcsLCBhIFNJUCBzdWJz Y3JpcHRpb24gc2VydmljZS4gSSBhbSBub3Qgc2F5aW5nIHJlZ2lzdHJhdGlvbiBpcyB0aGUgb25s eSBvbmUuIA0KDQo+PiBJbiBhbnkgY2FzZSwgSSB0aGluayB0aGlzIGlzIGEgZGVwbG95bWVudCBx dWVzdGlvbiwgc28gd2UgZG9uJ3QgbmVlZCB0byBtYW5kYXRlIG9uZSB3YXkgb3IgYW5vdGhlci4g V2hhdCBtYXR0ZXJzIGlzIHRoYXQgdGhlIEpXVCBpcyBwcm90ZWN0ZWQgb24gdGhlIFNJUCBpbnRl cmZhY2UuDQo+IEkgYmVsaWV2ZSBvdGhlcnMgYXJlIHdvcmtpbmcgb24gdGhhdCBwYXJ0IC0gY29u ZmlkZW50aWFsaXR5IGJldHdlZW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNl cnZlci4NCg0KWWVzLiANCg0KPj4+IFlvdSBwdXQgYSBsb3Qgb2YgdHJ1c3QgaW4gVExTLCB3aGlj aCBpcyBmaW5lLiBIb3cgZG8geW91IGhhbmRsZSBpbnRlcmNlcHRpbmcgVExTIHByb3h5cyBpbiB0 aGUgcGF0aCBpbiB0aGlzIHNjZW5hcmlvPw0KPj4gDQo+PiAgICBJIGd1ZXNzIHdlJ2QgaGF2ZSB0 byBhc2sgdGhlIE9BdXRoIGV4cGVydHMgYWJvdXQgdGhhdCwgYnV0IGluIA0KPj4gZ2VuZXJhbCBJ IHRoaW5rIHdlIGNhbiBwdXQgYXMgbXVjaCB0cnVzdCBpbiBIVFRQUyBhcyBhbnkgZWxzZSBkb2Vz IDopDQo+IFdoaWNoIG1lYW5zIGFsbW9zdCBubyB0cnVzdCBhbnkgbW9yZS4uLg0KDQpXZWxsLCBp ZiBvbmUgZG9lc24ndCB0cnVzdCBPQXV0aCB0aGVuIGhlL3NoZSBzaG91bGQgb2J2aW91c2x5IG5v dCB1c2UgaXQuIEJ1dCwgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBwbGFjZSB0byBkaXNjdXNz L2ltcHJvdmUgdGhlIGdlbmVyaWMgc2VjdXJpdHkgb2YgT0F1dGguDQoNCj4+IEF0IHRoZSBlbmQg b2YgdGhlIGRheSwgeW91IGhhdmUgdG8gY2hvb3NlIGEgc29sdXRpb24gdGhhdCBmaXRzIHlvdXIg dXNlLWNhc2UuIE1heWJlIHRoaXMgc29sdXRpb24gaXNuJ3QgZmVhc2libGUgZm9yIGFsbCB1c2Ut Y2FzZXMsIGV2ZW4gaWYgaXQgdGVjaG5pY2FsbHkgDQo+PiBzdXBwb3J0cyB0aGVtLiBPQXV0aCBt YXkgZml0IGNlcnRhaW4gdXNlLWNhc2VzIGJldHRlciB0aGFuIG90aGVycywgYW5kIHRoZXJlIGlz IG5vdGhpbmcgd2UgY2FuIGRvIGFib3V0IHRoYXQuDQo+DQo+IERlcGVuZHMgb24gdGhlIGRlZmlu aXRpb24gb2Yg4oCcdGhpcyBzb2x1dGlvbuKAnS4NCg0KT0F1dGggaW4gZ2VuZXJhbCwgYW5kIHRo ZSB1c2FnZSBvZiBPQXV0aCBmb3IgU0lQIGF1dGhlbnRpY2F0aW9uLg0KDQo+IEkgZG8gYWdyZWUg dGhhdCBPYXV0aDIgbWF5IG5vdCBmaXQgYWxsIHVzZSBjYXNlcyBmb3IgU0lQLCBidXQgYW55IHN0 ZXAgYXdheSBmcm9tIHRoZSBjdXJyZW50IERpZ2VzdCBBdXRoIGlzIGEgc3RlcCBmb3J3YXJkLg0K DQpTdXJlLCBidXQgSSBwZXJzb25hbGx5IGRvbuKAmXQgdGhpbmsgT0F1dGggd2lsbCBiZSBmZWFz aWJsZSBmb3IgYWxsIHVzZS1jYXNlcyB3aGVyZSBEaWdlc3QgaXMgY3VycmVudGx5IHVzZWQgLSBl c3BlY2lhbGx5IG5vdCBmb3IgdXNlci10by11c2VyIGF1dGhlbnRpY2F0aW9uLiBJdCdzIG5vdCB3 aGF0IE9BdXRoIHdhcyBkZXNpZ25lZCBmb3IsIEFGQUlLLg0KDQo+IElmIHlvdSByZWFkIHVwIG9u IHRoZSBsYXJnZSBhbW91bnQgb2YgZHJhZnRzIGFuZCBSRkNzIGZyb20gdGhlIE9hdXRoIHdnIGFu ZCBPcGVuSUQgY29ubmVjdCB5b3XigJlsbCBmaW5kIHRoYXQgdGhleSBhcmUgdGFyZ2V0aW5nIG1h bnkgdHlwZXMgb2Ygc2l0dWF0aW9ucyANCj4gdGhhdCB3b3VsZCBmaXQgbm90IG9ubHkgYnJvd3Nl ci1iYXNlZCBTSVAgdWHigJlzIGJ1dCBhbHNvIFNJUCBkZXNrdG9wIHBob25lcyBhbmQgbWF5YmUg QVRBLWxpa2UgYm94ZXMuDQoNCkFic29sdXRlbHkuDQoNCj4gTXV0dWFsIFRMUyBjZXJ0IGF1dGgg aGFzbuKAmXQgdGFrZW4gb2ZmLCB3aGljaCBpcyB0aGUgb25seSBhbHRlcm5hdGl2ZSB3ZSBjdXJy cmVudGx5IGhhdmUuIEkgZG8gaG9wZSB3ZSBjYW4gc29ydCB0aGlzIG91dCBhbmQgZG9jdW1lbnQg YSBnb29kIGZyYW1ld29yay4NCg0KTWUgdG9vIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0K From nobody Fri Jul 12 06:26:30 2019 Return-Path: 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 54731120088 for ; Fri, 12 Jul 2019 06:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 EEwsk0jOC1dx for ; Fri, 12 Jul 2019 06:26:27 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30081.outbound.protection.outlook.com [40.107.3.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1FD12003F for ; Fri, 12 Jul 2019 06:26:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OwLpaQSO0apgnFjddjCcFoFLA6aY7m55ahxZ4IvFW8PbOXgG89oEBMaMv5BuI3XpLp6cVWGubVGfUk15q5+tUoJLn4pPYXkXZC6zVM3UocnxK1NXdDlM5In35bHWSYl5qdFpR0zI/xTKQfojvLxKMlTBQw7/hIhj9ZooheW8tfE8cVyFsjQgXlLmysYT62COOMXy8P+uMn9TtVKW380ST5N8a01zLARUx2H/P1nBkSiN7Ku7fGC2yI8LDn6FPPHY1k2qo23lfbtdoVs2Y57cehN9BZZoIBKv3h5bDhzqICALn5EHIPdMhM/WVVWPmPvLuQ4Zeb7M+aHNTVZkmyk8Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oGLSV95bG/TpUcdgQ10I1NQz358/eKz+n5PvJA0JBc0=; b=CQZQl6hnZgo/9Ww1GOBWbihewDZEZdr/Eq+JE5Gg1duIjoGRCeOUg1QUkDBU8IKGN/IL9QDi4jdH6OOClxfzJcEDGgPJhA8xAFI8J2qJ2Uk/hjhB3dywRDyZGdm2uyYhODuX76ByDT6ny7LqS2kJSx3xcGTfXZx3xL5duJSPveLF4rAcF10ehOQaCT+T4jv0E/ybCz/nJsXZWNZTH5a3PJXX5abv+Vg+2srlG7t0oKVPRveub30Nk8btYN9JUF8yAS4MF1bF9feg8WDrzj3OMSYS74C3WFOyJ8Z0K96BCIeuT9DPGWhc3tZBUWGSpvPjhcg1IMRQko9wa67kcAAHtQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oGLSV95bG/TpUcdgQ10I1NQz358/eKz+n5PvJA0JBc0=; b=FSkUkHHQTPT492EJYFlefanz8BLsGlawQkCYv8Zip1geRheXNFFz+7rSFbXh3Tjx1S8BiV8XXBWRww0rxMKdZzyWw7gBUral/PNSDMDM7oKZIFqfIqFWwwUew4O2lJM+98ZyI49ZcsfCX7H9Ad9CITLbhbwmINCFydzshzM5d1o= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3164.eurprd07.prod.outlook.com (10.170.245.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.7; Fri, 12 Jul 2019 13:26:22 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Fri, 12 Jul 2019 13:26:22 +0000 From: Christer Holmberg To: "Olle E. Johansson" , "sipcore@ietf.org" Thread-Topic: token-authnz: Access Token and Refresh Token Thread-Index: AQHVOLVlDzmIOlCLBUC9tNyFXob2hg== Date: Fri, 12 Jul 2019 13:26:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 993f5217-4b33-414d-3259-08d706cc8813 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3164; x-ms-traffictypediagnostic: HE1PR07MB3164: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 00963989E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(346002)(136003)(376002)(396003)(189003)(199004)(44832011)(26005)(66946007)(2906002)(76116006)(66556008)(64756008)(66476007)(66446008)(8676002)(5660300002)(81166006)(81156014)(6506007)(71200400001)(71190400001)(58126008)(110136005)(4744005)(86362001)(6116002)(3846002)(478600001)(36756003)(102836004)(25786009)(486006)(316002)(186003)(8936002)(14444005)(256004)(305945005)(66066001)(14454004)(6486002)(2501003)(6436002)(53936002)(99286004)(33656002)(68736007)(6512007)(476003)(2616005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3164; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vVIMyv7qgGk3JRR53iLlTf6W1UMdUoqYeU1s+a1YEzhJO76j9fYRjBNvWXD+1esezvCQVDILV3YIPjVfa6mmhVNELg7M+AO9fbuT4gd9xhR/KyOKb8ArdEgaIudKkjH3vGGgOJIcpbL2SDouYVE/CR8htPjp1aE9/jHfI3KhdWl8Bz9itR1p7eaE7+tsU35syHnXnKOAiuXbQcq3WCaaHx8q3jTsg4FjGa52ZKhOhHIdYQGp7DoeioWtici4ZemQTOEbUMqxYksoC0dmV0HdSCETLcOttQfPDaILrIbCFORrAS5SWvDeeSqVr/SO5yyPD58xMth3CF1CBAUQmYoGyoH0NKquzTpBL++IgnzzNj1EpOQaYwAwRkOg6X4U2G7mMlNNnItC15uWq4ZASfmkLiB1dMWO7N3ctrcjAEsnwXk= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 993f5217-4b33-414d-3259-08d706cc8813 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 13:26:22.0929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3164 Archived-At: Subject: [sipcore] token-authnz: Access Token and Refresh Token X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 13:26:29 -0000 SGksDQoNCldoZW4gc2Nhbm5pbmcgdGhyb3VnaCB0aGUgZS1tYWlscywgSSByZWFsaXplZCBvbmUg dGhpbmc6IHdlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0IE9BdXRoIEFjY2VzcyBUb2tlbnMgYW5k IFJlZnJlc2ggVG9rZW5zLiANCg0KSG93ZXZlciwgb25seSBBY2Nlc3MgVG9rZW5zIHdpbGwgYmUg dHJhbnNwb3J0ZWQgaW4gU0lQLiBSZWZyZXNoIFRva2VucyBhcmUgb25seSBiZXR3ZWVuIHRoZSBT SVAgVUEgYW5kIHRoZSBBdXRob3JpemF0aW9uIFNlcnZlciwgYW5kIHRoYXQgaW50ZXJmYWNlIGlz IG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4NCg0KU29ycnkgZm9yIHRoZSBj b25mdXNpb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Fri Jul 12 18:01:16 2019 Return-Path: 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 5407212004F for ; Fri, 12 Jul 2019 18:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 vsQdpRauEv8y for ; Fri, 12 Jul 2019 18:01:11 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 620DB12000E for ; Fri, 12 Jul 2019 18:01:11 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id m6C4hiL9KUhOfm6PVhakra; Sat, 13 Jul 2019 01:01:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1562979669; bh=3FaOlKAn8cagEEZcuVSnDJCk+rrH17vIQeIHYbYU7pY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=T5oKtnqNDAFXlcvE1a36+WDL8v3PHsl8KUf1ohl5hWjMxcIuZe1sVeQxwqOORksFh sbkPRL+n1cvb7ne+G17KzIhHMea3htxaWoWgH1TGJxi08ZR8uZ7KUwRJiLkn5bYcDg VLkigbYiY/sgaQgQpEVGBz7iuo3t7t/7ncIvaTRoRvErWOM3kCsXwaFzGgLsYD7vFg UAB9yKwaotPQ6I/5GFQIAqiqJFvAeA1pxjqctFWbg2pgy3HVZMC3+74/+dUIcZ1STW ABGaIAL8gR0uejaN1fbg/Pion5X5lerJvxq2L1fzQufHZ0e//WdF3t99U7p7SnCTw3 hUYmwJ/6OIl2Q== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-13v.sys.comcast.net with ESMTPA id m6PUhmngMa9P8m6PVhVQB2; Sat, 13 Jul 2019 01:01:09 +0000 X-Xfinity-VMeta: sc=0;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x6D116Ci021278 for ; Fri, 12 Jul 2019 21:01:06 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x6D115J0021275; Fri, 12 Jul 2019 21:01:05 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 12 Jul 2019 21:01:05 -0400 Message-ID: <87zhlipx2m.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Thoughts about 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 01:01:15 -0000 I've finally gotten out from under a bureaucratic problem with my employer and taken a look at sipcore-sip-token-authnz and its e-mail thread. My, my... I haven't read the thread thoroughly, but I've at least skimmed every message up until some time yesterday. But I think I have reasonably well formulated the following observations. 1. I find the new draft considerably easier to understand than the older ones. I'm not sure why; as Christer notes, everything in it is in the older ones. But I suspect that the somewhat narrower scope of the new draft allows me to see the overall concept even when the details aren't particularly clear. So that's a significant advance. I don't see the current version as being near WGLC but rather as a good presentation of the high-level design concept. It's the point where you can start seeing the path to WGLC. 2. One somewhat philosophical point is that the current version presents the work as implementing two (somewhat generic) call flows. But of course, SIP isn't defined in terms of call flows that SIP entities implement by having telepathic knowledge of where they are in particular call flows, but rather in terms of specific internal states of SIP entities which cause them to respond in defined ways to incoming messages. The collective effect of these action specifications makes an unlimited number of useful call flows work. So in this case, we need to dissect each step of these call flows and lay out the specific behaviors that have to be executed by the participating entities. In addition, this is the place to discern which of these behaviors fit into the various existing patterns and structures of SIP. 3. One thing that's clear is that we're really defining a new authentication scheme, named "Bearer", which is used in coordination with an OAuth authorization server. Based on this, it's clear that the scheme can be used in any context any other scheme could be used, as long as the target supports it. This includes for authenticating to a UAS (e.g., a voicemail server) or to a proxy. And we get this functionality "for free"; we don't need to define any more machinery for these uses beyond what is needed to support REGISTER authentication. 4. The question arose on the mailing list whether Proxy-Authenticate is ever used. I know that the sipX family of PBXs uses it. The general pattern is that the proxy demands that the UAC authenticate itself, and then passes authenticated INVITEs to their destination UASs. The destination phones are configured to only accept requests from the IP address of the PBX. This allows a very simple authentication scheme at the UAS to be leveraged into more sophisticated authentication of all incoming requests by a more intelligent proxy. This structure also supports the standard SIP usage where the process of permitting an INVITE to flow *from* a UAC is not coupled to whether or not the UAC is registered. (Of course, a UAS can only *receive* an INVITE to its AOR if it is registered for that AOR.) The draft seems to presume that the ability to send INVITEs is implicitly controlled by whether the UAC has an active registration ... but that is not standard SIP. 5. If I understand it correctly, a SIP request is authenticated by an Authorization header containing the Bearer scheme and a valid access token. As others have noted, any device which can copy the access token can issue any request in the name of the token's user. This situation requires that the SIP messages be fully protected from eavesdropping and that a message containing such an Authorization header must never be handled by an untrusted entity. This is a particularly strict situation. The draft recognizes this and the Security Considerations section says The UAC MUST always make sure that it is communicating with the right registrar/proxy using TLS and proper validation of the server certificate and the identifier in that certificate to protect the access token in transit. However, this restriction is sufficiently different from current practice that it should also be mentioned in the earlier, "operational" sections. This situations sounded familiar to me ... I eventually realized that it is exactly the situation with HTTP Basic authentication. It's also the reason why SIP rejected using Basic authentication. We need a way to use OAuth authentication that has the property of Digest authentication that the values in the Authorization header are bound in some way to the particular request. It seems to me that there are a couple of ways out of this problem. a) Given that OAuth designates the token we are using as "bearer", it's possible that OAuth provides a different mode of operation with the needed properties. b) Use the access_token as essentially the "passwd" value in a clone of the Digest algorithm. This requires that the Authorized header has some other way of indicating to the authenticator what access_token it used. Presumably that information could be bundled into a parameter of the (authenticated user) "uri" parameter of the header. 6. One new UA behavior is where the UAC coordinates the process of the user providing his credentials, forwarding them to the authorization server, and receiving the tokens. I don't see any need to standardize how this is triggered and operates, other than that the contents of the HTTP POST and its response ([01]/[02] or [10]/[11]) need to be properly specified. I assume that these are specified by the OAuth specification, but we need to ensure that our draft clearly specifies whatever parameters are needed by the generic OAuth specification. The reason for being careful with this is that in order to ensure interoperability at the boundary between the UAC and the authorization server, their communication is not truly "out of scope of this specification" but rather "delegated by this specification to the OAuth specification". 7. Similarly for the conversation between the SIP authenticator and the authorization server. 8. Given that Bearer is a new authorization scheme, it doesn't directly demand any new UAC behavior regarding registration. But the REGISTER [12] may introduce a new behavior: Currently, a UAC can only REGISTER for a particular AOR; that AOR appears as the To and From URIs. But in this call flow, it's possible that the UAC does not know which AOR it will eventually attempt to register to, only the SIP domain. So we may need to extend RFC 3261 to provide a "generic" REGISTER form, whose purpose is not to obtain a registration but rather to provoke a 401 response containing the authz_server value that the UAC needs, REGISTER sip:biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 20 To: From: ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Once the user is done with the OAuth handshake, the UAC will know the AOR to register to and can send a normal REGISTER. 9. It seems to me that there should be a stated constraint that the registrar must not issue a registration that is valid for longer than the future validity of the access_token that is used to authenticate the registration request. Presumably this is straightforward to implement in an OAuth context. 10. Both call flows show the UAC obtaining a refresh_token from the authorization server but there is no illustration of the operations that the UAC will do to use the refresh_token to obtain an access_token with longer validity. It is probably worth illustrating this, as it is a different interaction that the authentication server must support. 11. In regard to the sip.token media feature tag, it's not clear that it is particularly useful. Presumably, if the authenticator of a request accepts the Bearer scheme for one of its realms, whenever it gives a 401/407 response, it will always include a WWW-Authenticate/Proxy-Authenticate header for the Bearer scheme and that realm, and that header will include an authz_server parameter. If the UAC does not accept Bearer for a particular realm, it will ignore such a header, so there is little cost of sending it to a UAC that does not support it. Dale From nobody Sat Jul 13 00:25:43 2019 Return-Path: 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 5B531120112 for ; Sat, 13 Jul 2019 00:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DPoj2Lff0jlF for ; Sat, 13 Jul 2019 00:25:37 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60066.outbound.protection.outlook.com [40.107.6.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C2A1200BA for ; Sat, 13 Jul 2019 00:25:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GDUYJUaiVmvBxZ8aTdDVZaq6o77mJNkv0S7kgtoa9rcByHeOroneV5SRXYJ6fd1GhLkpqH1+DlYBWa2ZNBx+q6UJCbbcicxtY0dG+laF+0ArRsufyTgSAXr9uWuhi538BoBzyX9QNPMJtHGLx81oqwgTmPC0EN/v3cj2hqNbTDuiEkmIMTokk5CqlNxNlcqEmS+zMpJylGvRPb+fd9L17yey9rDRmccR+4FVF61ijLar/u9k/j3yPcbZ5gSyvBQYZT4Xk6cmkzjcmPdaRban7MzIEFJJWv0ywsSJpJCebjU1v49zlHAZsq5infFW6QN+c7vW5S6N/RxqfX8outf0TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U/30NjLfIVHuWor7/VsGDJjfg8JmMevfT2oKDOARBd8=; b=BJ3Gb0a1i6OCkEtEIP2mxvCM2MN49cuZIu+MHjiigUtWmHQVoZpS7L5noMNniYe+2oUJG8DX+vM4QWBqhxgdXJ/qrgTTZLc9H8TTbpK5bOHiSMBzIOdrIO79AxdHPmcGxt/prvChgAzY8SsnTHdZTEDhWP+dx0Ak/9xzBzCV732/8BMdWTmXpyO+rUGpPFX/q6jpz3S8APhkmSC4P0FXcRTNlKQKr/6cwZdp2Gijh4QKn/+83ujjJ48ivMiM0cLTxYj8LyHxg1O/SE+hCh5OphbzIeuJ6OX+Aezg2WeZuRCsm+49rK5O7TndYhShU1Qm/GqSX8JeDUhSXRzEkQubYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U/30NjLfIVHuWor7/VsGDJjfg8JmMevfT2oKDOARBd8=; b=GdXqQiu6Xt4doFLqPjwvY0LVB+/BqCpJQgt42yUpPkoog9PoZQazwyAX4T/yVWQT08Dr0zjtJ9h/hmNI69VordCZaBCBxYHV15pqmJUW2cMHccL4/7RISiK281LhoE5Ug3IZPK/zEogHTWekJDGyxgl9a+ApMVjLPCXBXCWzHbc= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3291.eurprd07.prod.outlook.com (10.170.246.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Sat, 13 Jul 2019 07:25:32 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2073.008; Sat, 13 Jul 2019 07:25:32 +0000 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt - Dale's comments Thread-Index: AdU5STutUuxJM/tFSNeInGKMSi7MIA== Date: Sat, 13 Jul 2019 07:25:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.156.56] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c19b0ff8-34db-4c33-32d4-08d707634a1e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3291; x-ms-traffictypediagnostic: HE1PR07MB3291: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(376002)(136003)(396003)(366004)(346002)(39860400002)(189003)(199004)(66066001)(25786009)(53936002)(5660300002)(9686003)(55016002)(71190400001)(7736002)(305945005)(71200400001)(229853002)(66446008)(66476007)(64756008)(66556008)(74316002)(76116006)(66946007)(6116002)(3846002)(81166006)(81156014)(8676002)(7696005)(52536014)(99286004)(86362001)(186003)(26005)(6436002)(6506007)(102836004)(2906002)(44832011)(486006)(8936002)(6246003)(110136005)(2501003)(316002)(33656002)(256004)(14454004)(476003)(14444005)(68736007)(478600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3291; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Q+Tr3A5Ny0bpRhyaSyPPeeGNslgGIH+gPHTwcpv2uUvLrcOWI90hC1Drv0U4azJQUAC7beDDXMjm71nDMs+WcYgUXpDVA8MG0fm9swl+FupNP+qA+xqf63y9j1rktLNSyVMhYO9cni8N9fc7SsQ5BH1lJSA9PHjSNF2HMjM+YLN+AANvCrqGYVRiZkAG991c0mDSBF7g8Acxa3yLhb5OV5M3ltW/rELF6saa2fuqrKWkzoOFKNvVk+Lq0KF4OIIp5L01zRZ3ae6O4rDIsooktp28hbqBxghdQtthqRgWIFe1qU3QSlJGJi1jN7XUgFHELjMLeQGeiRfLEeNDI7I0JZBsd48oMrSYM0JzNzJOrFWy6afXXxXAPRwP6XtNFMKsAQyzjxmWCkGxiHJY1yL8Aa2RD492tvmuPVvypJ89Q6U= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c19b0ff8-34db-4c33-32d4-08d707634a1e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 07:25:32.0355 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3291 Archived-At: Subject: Re: [sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt - Dale's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 07:25:42 -0000 Hi Dale, Please see inline. >2. One somewhat philosophical point is that the current version presents = the work as implementing two (somewhat generic) call flows. >But of course, SIP isn't defined in terms of call flows that SIP entities = implement by having telepathic knowledge of where they are in particular=20 >call flows, but rather in terms of specific internal states of SIP entitie= s which cause them to respond in defined ways to incoming messages. =20 >The collective effect of these action specifications makes an unlimited nu= mber of useful call flows work. > >So in this case, we need to dissect each step of these call flows and lay = out the specific behaviors that have to be executed by the participating en= tities. > >In addition, this is the place to discern which of these behaviors fit int= o the various existing patterns and structures of SIP. I think the draft already does that. What do you think it missing? ---- >4. The question arose on the mailing list whether Proxy-Authenticate is e= ver used. I know that the sipX family of PBXs uses it. The general patter= n is=20 >that the proxy demands that the UAC authenticate itself, and then passes a= uthenticated INVITEs to their destination UASs. The destination phones are= =20 >configured to only accept requests from the IP address of the PBX. This a= llows a very simple authentication scheme at the UAS to be leveraged into m= ore=20 >sophisticated authentication of all incoming requests by a more intelligen= t proxy. > >This structure also supports the standard SIP usage where the process of p= ermitting an INVITE to flow *from* a UAC is not coupled to whether or not=20 >the UAC is registered. (Of course, a UAS can only *receive* an INVITE to = its AOR if it is registered for that AOR.) The draft seems to presume that= the=20 >ability to send INVITEs is implicitly controlled by whether the UAC has an= active registration ... but that is not standard SIP. Agreed. The reason it may look different in the draft is because registration was o= ne of the use-cases we earlier agreed was going to be covered in the draft. --- >5. If I understand it correctly, a SIP request is authenticated by an Aut= horization header containing the Bearer scheme and a valid access token. =20 >As others have noted, any device which can copy the access token can issue= any request in the name of the token's user. This situation requires=20 >that the SIP messages be fully protected from eavesdropping and that a mes= sage containing such an Authorization header must never be handled=20 >by an untrusted entity. > >This is a particularly strict situation. The draft recognizes this and th= e Security Considerations section says > > The UAC MUST always make sure that it is communicating with the right > registrar/proxy using TLS and proper validation of the server > certificate and the identifier in that certificate to protect the > access token in transit. > > However, this restriction is sufficiently different from current practice= that it should also be mentioned in the=20 > earlier, "operational" sections. Feel free to suggest where you want to add text. Related to that, Olle commented that TLS may not be enough, as it is hop-to= -hop when used with SIP. So, we have been discussing encoding the access to= ken using encoded JWTs. >This situations sounded familiar to me ... I eventually realized that it i= s exactly the situation with HTTP Basic authentication. > >It's also the reason why SIP rejected using Basic authentication. > >We need a way to use OAuth authentication that has the property of Digest = authentication that the values in the Authorization=20 >header are bound in some way to the particular request. It seems to me th= at there are a couple of ways out of this problem. > >a) Given that OAuth designates the token we are using as "bearer", it's po= ssible that OAuth provides a different mode of operation with the needed pr= operties. > >b) Use the access_token as essentially the "passwd" value in a clone of th= e Digest algorithm. This requires that the Authorized header has some othe= r way of indicating=20 >to the authenticator what access_token it used. >Presumably that information could be bundled into a parameter of the (auth= enticated user) "uri" parameter of the header. I'd like some more information, and perhaps an example, for this, because I= am not sure I understand. --- >6. One new UA behavior is where the UAC coordinates the process of the us= er providing his credentials, forwarding them to the authorization server,= =20 >and receiving the tokens. I don't see any need to standardize how this is= triggered and operates, other than that the contents of the HTTP POST and= =20 >its response ([01]/[02] or [10]/[11]) need to be properly specified. I as= sume that these are specified by the OAuth specification, but we need to en= sure=20 >that our draft clearly specifies whatever parameters are needed by the gen= eric OAuth specification. > >The reason for being careful with this is that in order to ensure interope= rability at the boundary between the UAC and the authorization server, thei= r=20 >communication is not truly "out of scope of this specification" but rather= "delegated by this specification to the OAuth specification". Where do you think the draft tries to standardize how OAuth operates?=20 --- >7. Similarly for the conversation between the SIP authenticator and the a= uthorization server. See comment 6. --- >8. Given that Bearer is a new authorization scheme, it doesn't directly d= emand any new UAC behavior regarding registration. But the REGISTER [12] m= ay=20 >introduce a new behavior: Currently, a UAC can only REGISTER for a partic= ular AOR; that AOR appears as the To and From URIs. But in this call flow,= it's possible=20 >that the UAC does not know which AOR it will eventually attempt to registe= r to, only the SIP domain. > >So we may need to extend RFC 3261 to provide a "generic" REGISTER form, wh= ose purpose is not to obtain a registration but rather to provoke a >401 response containing the authz_server value that the UAC needs, > > REGISTER sip:biloxi.com SIP/2.0 > Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 > Max-Forwards: 20 > To: > From: ;tag=3D456248 > Call-ID: 843817637684230@998sdasdh09 > CSeq: 1826 REGISTER > Contact: > > Once the user is done with the OAuth handshake, the UAC will know the AOR= to register to and can send a normal REGISTER. I don't think we shall change or extend the basic concept of SIP registrati= ons, where the user is trying to register an AOR. --- >9. It seems to me that there should be a stated constraint that the regis= trar must not issue a registration that is valid for longer than the future= =20 >validity of the access_token that is used to authenticate the registration= request. Presumably this is straightforward to implement in an OAuth cont= ext. There is a discussion about that, somewhere in the list thread. --- >10. Both call flows show the UAC obtaining a refresh_token from the autho= rization server but there is no illustration of the operations that the UAC= =20 >will do to use the refresh_token to obtain an access_token with longer val= idity. It is probably worth illustrating this, as it is a different intera= ction that the authentication server must support. Agree. We can add that. --- >11. In regard to the sip.token media feature tag, it's not clear that it = is particularly useful. Presumably, if the authenticator of a request acce= pts=20 >the Bearer scheme for one of its realms, whenever it gives a 401/407 respo= nse, it will always include a WWW-Authenticate/Proxy-Authenticate=20 >header for the Bearer scheme and that realm, and that header will include = an authz_server parameter. If the UAC does not accept Bearer for a=20 >particular realm, it will ignore such a header, so there is little cost of= sending it to a UAC that does not support it. I'll let Paul comment on this, because I think it raised the need for the i= ndicator. Regards, Christer From nobody Mon Jul 15 00:50:36 2019 Return-Path: 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 5EB87120074 for ; Mon, 15 Jul 2019 00:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 cLHcydNmwLQa for ; Mon, 15 Jul 2019 00:50:32 -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 2A96512001E for ; Mon, 15 Jul 2019 00:50:31 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 8841FA40; Mon, 15 Jul 2019 09:50:27 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 15 Jul 2019 09:50:26 +0200 Cc: Olle E Johansson , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [sipcore] token-authnz: Access Token and Refresh Token X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 07:50:35 -0000 > On 12 Jul 2019, at 15:26, Christer Holmberg = wrote: >=20 > Hi, >=20 > When scanning through the e-mails, I realized one thing: we have been = talking about OAuth Access Tokens and Refresh Tokens.=20 >=20 > However, only Access Tokens will be transported in SIP. Refresh Tokens = are only between the SIP UA and the Authorization Server, and that = interface is outside of the scope of the document. >=20 Correct, we only need access tokens and in the case of OpenID connect = the identity tokens. /O= From nobody Mon Jul 15 01:01:15 2019 Return-Path: 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 644A7120074 for ; Mon, 15 Jul 2019 01:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zdVPFoX-iT7f for ; Mon, 15 Jul 2019 01:01:11 -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 0197C12001E for ; Mon, 15 Jul 2019 01:01:10 -0700 (PDT) Received: from haworthia-20.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (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 ACF10A40; Mon, 15 Jul 2019 10:01:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 15 Jul 2019 10:01:06 +0200 Cc: Olle E Johansson , "Dale R. Worley" , "sipcore@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4514A953-4C1B-4161-9E1B-8D9D33FE453B@edvina.net> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [sipcore] Thoughts about draft-ietf-sipcore-sip-token-authnz-02.txt - Dale's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 08:01:15 -0000 > On 13 Jul 2019, at 09:25, Christer Holmberg = wrote: >=20 > Hi Dale, >=20 > Please see inline. >=20 >> 2. One somewhat philosophical point is that the current version = presents the work as implementing two (somewhat generic) call flows. >> But of course, SIP isn't defined in terms of call flows that SIP = entities implement by having telepathic knowledge of where they are in = particular=20 >> call flows, but rather in terms of specific internal states of SIP = entities which cause them to respond in defined ways to incoming = messages. =20 >> The collective effect of these action specifications makes an = unlimited number of useful call flows work. >>=20 >> So in this case, we need to dissect each step of these call flows and = lay out the specific behaviors that have to be executed by the = participating entities. >>=20 >> In addition, this is the place to discern which of these behaviors = fit into the various existing patterns and structures of SIP. >=20 > I think the draft already does that. What do you think it missing? >=20 > ---- >=20 >> 4. The question arose on the mailing list whether Proxy-Authenticate = is ever used. I know that the sipX family of PBXs uses it. The general = pattern is=20 >> that the proxy demands that the UAC authenticate itself, and then = passes authenticated INVITEs to their destination UASs. The destination = phones are=20 >> configured to only accept requests from the IP address of the PBX. = This allows a very simple authentication scheme at the UAS to be = leveraged into more=20 >> sophisticated authentication of all incoming requests by a more = intelligent proxy. >>=20 >> This structure also supports the standard SIP usage where the process = of permitting an INVITE to flow *from* a UAC is not coupled to whether = or not=20 >> the UAC is registered. (Of course, a UAS can only *receive* an = INVITE to its AOR if it is registered for that AOR.) The draft seems to = presume that the=20 >> ability to send INVITEs is implicitly controlled by whether the UAC = has an active registration ... but that is not standard SIP. >=20 > Agreed. >=20 > The reason it may look different in the draft is because registration = was one of the use-cases we earlier agreed was going to be covered in = the draft. >=20 > --- >=20 >> 5. If I understand it correctly, a SIP request is authenticated by = an Authorization header containing the Bearer scheme and a valid access = token. =20 >> As others have noted, any device which can copy the access token can = issue any request in the name of the token's user. This situation = requires=20 >> that the SIP messages be fully protected from eavesdropping and that = a message containing such an Authorization header must never be handled=20= >> by an untrusted entity. >>=20 >> This is a particularly strict situation. The draft recognizes this = and the Security Considerations section says >>=20 >> The UAC MUST always make sure that it is communicating with the = right >> registrar/proxy using TLS and proper validation of the server >> certificate and the identifier in that certificate to protect the >> access token in transit. >>=20 >> However, this restriction is sufficiently different from current = practice that it should also be mentioned in the=20 >> earlier, "operational" sections. >=20 > Feel free to suggest where you want to add text. >=20 > Related to that, Olle commented that TLS may not be enough, as it is = hop-to-hop when used with SIP. So, we have been discussing encoding the = access token using encoded JWTs. >=20 >> This situations sounded familiar to me ... I eventually realized that = it is exactly the situation with HTTP Basic authentication. >>=20 >> It's also the reason why SIP rejected using Basic authentication. >>=20 >> We need a way to use OAuth authentication that has the property of = Digest authentication that the values in the Authorization=20 >> header are bound in some way to the particular request. It seems to = me that there are a couple of ways out of this problem. >>=20 >> a) Given that OAuth designates the token we are using as "bearer", = it's possible that OAuth provides a different mode of operation with the = needed properties. >>=20 >> b) Use the access_token as essentially the "passwd" value in a clone = of the Digest algorithm. This requires that the Authorized header has = some other way of indicating=20 >> to the authenticator what access_token it used. >> Presumably that information could be bundled into a parameter of the = (authenticated user) "uri" parameter of the header. >=20 > I'd like some more information, and perhaps an example, for this, = because I am not sure I understand. >=20 > --- >=20 >> 6. One new UA behavior is where the UAC coordinates the process of = the user providing his credentials, forwarding them to the authorization = server,=20 >> and receiving the tokens. I don't see any need to standardize how = this is triggered and operates, other than that the contents of the HTTP = POST and=20 >> its response ([01]/[02] or [10]/[11]) need to be properly specified. = I assume that these are specified by the OAuth specification, but we = need to ensure=20 >> that our draft clearly specifies whatever parameters are needed by = the generic OAuth specification. >>=20 >> The reason for being careful with this is that in order to ensure = interoperability at the boundary between the UAC and the authorization = server, their=20 >> communication is not truly "out of scope of this specification" but = rather "delegated by this specification to the OAuth specification". >=20 > Where do you think the draft tries to standardize how OAuth operates?=20= >=20 > --- >=20 >> 7. Similarly for the conversation between the SIP authenticator and = the authorization server. >=20 > See comment 6. >=20 > --- >=20 >> 8. Given that Bearer is a new authorization scheme, it doesn't = directly demand any new UAC behavior regarding registration. But the = REGISTER [12] may=20 >> introduce a new behavior: Currently, a UAC can only REGISTER for a = particular AOR; that AOR appears as the To and =46rom URIs. But in this = call flow, it's possible=20 >> that the UAC does not know which AOR it will eventually attempt to = register to, only the SIP domain. >>=20 >> So we may need to extend RFC 3261 to provide a "generic" REGISTER = form, whose purpose is not to obtain a registration but rather to = provoke a >> 401 response containing the authz_server value that the UAC needs, >>=20 >> REGISTER sip:biloxi.com SIP/2.0 >> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 >> Max-Forwards: 20 >> To: >> From: ;tag=3D456248 >> Call-ID: 843817637684230@998sdasdh09 >> CSeq: 1826 REGISTER >> Contact: >>=20 >> Once the user is done with the OAuth handshake, the UAC will know the = AOR to register to and can send a normal REGISTER. >=20 > I don't think we shall change or extend the basic concept of SIP = registrations, where the user is trying to register an AOR. The UA has to know the AOR when authorizing, to get authorization to use = that AOR. The AOR will in my theory be inicluded in the access or identity token. Specifying a new way to =E2=80=9Cdiscover my AOR=E2=80=9D in SIP is in = my view out of scope for this document. >=20 > --- >=20 >> 9. It seems to me that there should be a stated constraint that the = registrar must not issue a registration that is valid for longer than = the future=20 >> validity of the access_token that is used to authenticate the = registration request. Presumably this is straightforward to implement = in an OAuth context. >=20 > There is a discussion about that, somewhere in the list thread. I think we need to consult with the Oauth group on this. It may be the = case that the long-lived expiry times we in many cases have for = registrations and subscriptions is not considered in the world of Oauth. The example from the STUN/TURN = Oauth docs is the only one I found. >=20 > --- >=20 >> 10. Both call flows show the UAC obtaining a refresh_token from the = authorization server but there is no illustration of the operations that = the UAC=20 >> will do to use the refresh_token to obtain an access_token with = longer validity. It is probably worth illustrating this, as it is a = different interaction that the authentication server must support. >=20 > Agree. We can add that. >=20 > --- >=20 >> 11. In regard to the sip.token media feature tag, it's not clear = that it is particularly useful. Presumably, if the authenticator of a = request accepts=20 >> the Bearer scheme for one of its realms, whenever it gives a 401/407 = response, it will always include a WWW-Authenticate/Proxy-Authenticate=20= >> header for the Bearer scheme and that realm, and that header will = include an authz_server parameter. If the UAC does not accept Bearer = for a=20 >> particular realm, it will ignore such a header, so there is little = cost of sending it to a UAC that does not support it. >=20 > I'll let Paul comment on this, because I think it raised the need for = the indicator. /O= From nobody Tue Jul 16 15:40:45 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE1C12022D; Tue, 16 Jul 2019 15:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.4 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Jean Mahoney , adam@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-rejected@ietf.org, mahoney@nostrum.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156331683380.15219.4576122655631522976.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2019 15:40:33 -0700 Archived-At: Subject: [sipcore] Protocol Action: 'A Session Initiation Protocol (SIP) Response Code for Rejected Calls' to Proposed Standard (draft-ietf-sipcore-rejected-09.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 22:40:35 -0000 The IESG has approved the following document: - 'A Session Initiation Protocol (SIP) Response Code for Rejected Calls' (draft-ietf-sipcore-rejected-09.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ Technical Summary This document defines the 608 (Rejected) SIP response code, which informs a calling party that an intermediary has rejected their call attempt. This document also extends the Call-Info header field so that the caller may contact the blocking party if the rejection was in error. The 608 response code addresses the use case of call rejection by a call analytics engine or other automated process. This contrasts with the 607 (Unwanted) SIP response code, which is sent by a SIP user agent when a human indicates that the call was not wanted [RFC8197]. Working Group Summary The document is of interest to the STIR (Secure Telephone Identity Revisited) WG, but discussions were (mostly) kept to the SIPCORE mailing list since the document covers a SIP extension. Sometimes cross-posting was not successful and some discussions occurred only on the STIR mailing list. All feedback that was discussed on the STIR mailing list was incorporated into the document, however. Document Quality One of the authors (Bhavik Nagda) implemented this solution in Kamailio, which is an open source SIP server. The implementation can be found at https://github.com/nagdab/608_implementation. There are also governmental agencies that are interested in the 608 response code feature. Reviewers and their contributions have been called out in the Acknowledgements section. Tolga Asveren provided substantial feedback on interoperability and security considerations. Personnel Jean Mahoney is the Document Shepherd. Adam Roach is the Responsible Area Director. From nobody Sun Jul 21 04:55:41 2019 Return-Path: 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 AB62412011B for ; Sun, 21 Jul 2019 04:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 69h2n33sl8X2 for ; Sun, 21 Jul 2019 04:55:37 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 7FA3712011E for ; Sun, 21 Jul 2019 04:55:37 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id 34so14269506uar.8 for ; Sun, 21 Jul 2019 04:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aKagafErbnghmNROCRfdfatuJ1PN9zF+LsDjBKTXrJM=; b=IyfNrPrAQKFNmCP2JYVACMqE7/o08xfKEZS2LqjZzv5182O8r0ZLddfp2WwhTaIOUb mlfKefXUYTkiRjRYRo7Ga/r4UELwUkaGiTi1iYNk8SPCt12Ac+SdhehSyKmeBAK7NvbA 8ypkCAq7TbYjE+dtHv/2yn8fEWth4SNgxmdllErXixAZ+jXhO8cEsdhFwd83ZCsixPzA 6bNMnazS+HovSw62V6FrIIJqZykzw9UmRxolw4hXpLm045aq9M7qoBObf0bjhd683oEQ RSjaiyiKkiSiRvsFeJEnU/72ITbfyuV8/2OxR/ovx69GtM9sTiLFtavVMEunZNT7tTSd fVSg== 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; bh=aKagafErbnghmNROCRfdfatuJ1PN9zF+LsDjBKTXrJM=; b=LscHVnqNGnGnTtaeR+o34dIWJ0yKTiqsuwWtODIgPhLICQ+9OKKak/DbZ0dRWhTiKO dTW9lIkHxaadVYEo4TY+3LgYX7qDG/XSEvCPrk2SkUV66XFkQV6yaZJNTnYVYF+KzvnS XAbia6lDxGo7dg3vb+O8KO4I55ZVodlAsX+sPQZb1mc/SRwxw8Vgd0TIwEeL8PBkjn0J 62JPuzqb62lQn1xVlJth3St3BmyPPRCWVCNPj1hRpphd1wySCAvJZwJ2yeOxL4vEuh2L y6GrTNlFuv4BL9nqzeuelrppDVPLflfBqs243PhVaUq05PDcLSQ98XFa4sBQ9yDIzUtm E+uw== X-Gm-Message-State: APjAAAWNHgv0+OOYHfTrsY09TpKVFBt43J60Tdi7lJNgOmUbgUjuGdHq fFA3c9gA8ybbykhmPl/WC4Py6ld+DgIvjC+nhBjA0sfp X-Google-Smtp-Source: APXvYqxCTCRzwx3jcd3klDlUYr5uZkSprVWhSwFMvvaPl6pc8GujBmEtvqzOnSY99EvP28S/2RHbeSlYmM4ymU6xzfw= X-Received: by 2002:ab0:b99:: with SMTP id c25mr39271223uak.53.1563710136458; Sun, 21 Jul 2019 04:55:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yehoshua Gev Date: Sun, 21 Jul 2019 14:55:24 +0300 Message-ID: To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000372258058e2fa3c1" Archived-At: Subject: [sipcore] draft-ietf-sipcore-sip-token-authnz - Security of the token X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 11:55:40 -0000 --000000000000372258058e2fa3c1 Content-Type: text/plain; charset="UTF-8" Hi, Looking at the discussion regarding the way to secure the access token, I think it will be good to summarize the options. OPTION 1 - Bearer authorization (as appears in the draft): Send the token as plain text on the Authorization header. This option is very straight-forward, but lacks the ability of the UAC to verify that the token is not exposed by some intermediary proxy. OPTION 2 - Token encryption (a proposal by Olle Johansson): Encrypt the token using a public key that is provided in a challenge. I believe that a public key of a UA doesn't normally change between challenges, so this method is prone to reply attacks (if the challenge be kept constant). Of course, this method can be extended to include a nonce, but it will make it more complicated. OPTION 3 - Digest scheme (a proposal by Dale Worley): Use a "digest"-like scheme to send a hashed value of the token. I believe this is problematic, as digest can only be used if both parties knows the password (or token) in advance, so it's enough to compare its hash value. In our case, tokens can usually be validated only when their full value is revealed (e.g., validation of JWT token is done without pre-knowledge of the token). OPTION 4 - HTTP Authorization: Assuming that we resort to having only the first hop (the home proxy) perform the authentication, and restricting ourselves to WebRTC clients, the authorization can be done on the HTTP level of WebSocket creation. This option is available to use creating new standards, but apparently it's not enough (or the draft would not have been written). OPTION 5 - New challenge-response mechanism: Probably some combination of options 2 and 3, but having it standardized and performed by 3rd-party OAuth server. Just like RFC 5090 proposed a way for a RADIUS server to perform digest authentication, an extension to OAuth introspection endpoint (RFC 7662), can possibly be made to validate a token using a challenge-response mechanism. With this option, the "security burden" will fall on OAuth servers and not on the SIP UAs. Having laid out the options above (I'm sure there are options I've missed), I think that the scope of the current draft should remain minimal, and OPTION 1 should be used. For example, a common use case is that the home proxy perform the authentication, and remove the Authorization header when forwarding the request. For this use case, it will be nice if option 1 will remain available. Still, even for this scenario, maybe a simple challenge-response mechanism should be required, so the UAC will have a way to know that the home proxy supports this kind of authentication. Without it (if the proxy is not supporting), the UAC might send the token, and the proxy forward it to un-trusted entities. For the long run (on other drafts), the other options should probably be looked into, so the security restriction imposed by option 1 could be relaxed. Regards, Yehoshua --000000000000372258058e2fa3c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Looking at the discussion regarding the way to = secure the access token, I think it will be good to summarize the options.<= br>
OPTION 1 - Bearer authorization (as appears in the draft):
Send t= he token as plain text on the Authorization header.
This option is very = straight-forward, but lacks the ability of the UAC to verify that the token= is not exposed by some intermediary proxy.

OPTION 2 - Token encrypt= ion (a proposal by Olle Johansson):
Encrypt the token using a public key= that is provided in a challenge.
I believe that a public key of a UA do= esn't normally change between challenges, so this method is prone to re= ply attacks (if the challenge be kept constant).
Of course, this method = can be extended to include a nonce, but it will make it more complicated.
OPTION 3 - Digest scheme (a proposal by Dale Worley):
Use a "= digest"-like scheme to send a hashed value of the token.
I believe = this is problematic, as digest can only be used if both parties knows the p= assword (or token) in advance, so it's enough to compare its hash value= .
In our case, tokens can usually be validated only when their full valu= e is revealed (e.g., validation of JWT token is done without pre-knowledge = of the token).

OPTION 4 - HTTP Authorization:
Assuming that we re= sort to having only the first hop (the home proxy) perform the authenticati= on, and restricting ourselves to WebRTC clients, the authorization can be d= one on the HTTP level of WebSocket creation.
This option is available to= use creating new standards, but apparently it's not enough (or the dra= ft would not have been written).

OPTION 5 - New challenge-response m= echanism:
Probably some combination of options 2 and 3, but having it st= andardized and performed by 3rd-party OAuth server.
Just like RFC 5090 p= roposed a way for a RADIUS server to perform digest authentication, an exte= nsion to OAuth introspection endpoint (RFC 7662), can possibly be made to v= alidate a token using a challenge-response mechanism.
With this option, = the "security burden" will fall on OAuth servers and not on the S= IP UAs.


Having laid out the options above (I'm sure there ar= e options I've missed),
I think that the scope of the current draft = should remain minimal, and OPTION 1 should be used.

For example, a c= ommon use case is that the home proxy perform the authentication, and remov= e the Authorization header when forwarding the request. For this use case, = it will be nice if option 1 will remain available.

Still, even for t= his scenario, maybe a simple challenge-response mechanism should be require= d, so the UAC will have a way to know that the home proxy supports
this = kind of authentication. Without it (if the proxy is not supporting), the UA= C might send the token, and the proxy forward it to un-trusted entities.
For the long run (on other drafts), the other options should probably= be looked into, so the security restriction imposed by option 1 could be r= elaxed.


Regards,
Yehoshua
--000000000000372258058e2fa3c1-- From nobody Sun Jul 21 08:44:11 2019 Return-Path: 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 A9520120132 for ; Sun, 21 Jul 2019 08:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 5JqMnZPiP5VL for ; Sun, 21 Jul 2019 08:43:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130077.outbound.protection.outlook.com [40.107.13.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DEC12013A for ; Sun, 21 Jul 2019 08:43:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EVgmQZDwQ98ZLNoNRSjqdapQ1p0xq5dxggqLizm5sspoEXOuVZZPLE3g5UZVtT9fizHf9Wiztf/y0AZUvqtk26rtwYDtjSyHrkf+p0DvwKmY9ZlDoAKyM+FEM5CWuXT4/2sdlziBBR6nYB4wQ4/duLAt2MCN6JqABmpCT5J8UEFp+ghq7S3aXfM4A3vGAb8O3Qk7rbWO/bjHFIdtTguvNTLPJfJuVJMSXlefU53dPBIrB6arbNNeLqSeKMVGQaJCrMgJsgQ53DF5sd1TEybtpwFgZnyhendqmYi3wg8EEzUWbc1KsLAFw/AR7sS0QoDT+owaRijg8oWvFHTx2oa+8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E0tHsc2+my294bsmiei3wn3TeCtU2n31qD1kr6oMUS0=; b=b2jd+HuNMamgQ7l4RM8pUyVAgkR76+YBXpIQTa9k6tfAslf0Lb5gKqZ5D12KVjG9ZxPgi+4DyrXgYK3wKt6Jxt9pwJhBpeezynAwaerWOMIQf7mDtn5jvB81r+1QPu2zPbgUy6+NKIjzAWznq4/VcZwLmSeOk/N6TMRGhC0QvHlTWtQxx4B0KD1TwXIYaxyu8D/KjooeWyQo7d+/AD1JvacmTpbHd/8cr6LhPjUPW0Q9MVr99BrtQcRQTZtjjC+b4MAtckbDf30In/cK7QKE69IjxmQaLIr0Aj/6D9SNorGCJgMLjZau7Zvvd0aF3p7peh4DOaUuSpyyklv+GdTFJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E0tHsc2+my294bsmiei3wn3TeCtU2n31qD1kr6oMUS0=; b=n7tUy10U+ucIvPTfVUbmFhEWhSMAymTIwEKMUHuMn0HYU9KhoqkiR4YgNcjvNWN7I5EKw5QFNUHiZTQs2zptZHjb98ZxJ+QXZjq1nS6ZX21iVemkUid98XevprQa79HOcs5cs0VLAhjUkJ6SljXgNirBCPVuLub/yq32bt9wKCE= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3436.eurprd07.prod.outlook.com (10.170.247.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.9; Sun, 21 Jul 2019 15:43:53 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::5050:a3a9:be80:cf43%5]) with mapi id 15.20.2094.009; Sun, 21 Jul 2019 15:43:53 +0000 From: Christer Holmberg To: Yehoshua Gev , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-sip-token-authnz - Security of the token Thread-Index: AQHVP7tDVzpq44wx5Eqf6X2UASwciqbVNImg Date: Sun, 21 Jul 2019 15:43:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [176.93.45.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 180377fb-5982-4324-6e82-08d70df23bc4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3436; x-ms-traffictypediagnostic: HE1PR07MB3436: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0105DAA385 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(396003)(39860400002)(376002)(189003)(51444003)(199004)(9686003)(54896002)(2420400007)(15650500001)(86362001)(6436002)(2906002)(55016002)(6116002)(790700001)(561944003)(81166006)(33656002)(81156014)(68736007)(8936002)(9326002)(53936002)(6306002)(14454004)(3846002)(66066001)(66574012)(5660300002)(71200400001)(71190400001)(14444005)(110136005)(76176011)(476003)(316002)(11346002)(446003)(66446008)(64756008)(66556008)(66476007)(76116006)(66946007)(478600001)(256004)(25786009)(52536014)(2501003)(8676002)(486006)(6506007)(7736002)(7696005)(186003)(44832011)(102836004)(99286004)(74316002)(7110500001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3436; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: A1E9hmV9HT8S9MIDQ8+WLE0Siu1duNISzM9+49xdwGygjWGPnYNINAZiLTkGDxwq1oHMVf2yunhEo8cmbKv7mMniY8xT1l2pwhVN6qLykfP3LbcA0yyvAejLz7O6Uu0nrEibtlt2F4rq/BPYR6lUgDJjs73e1YyQ/KJvGGIPVsyrvng5228G5myLGZZi/ql8qiaXmfRT11s/VRTclHjB5pzYhDPvO0siXo2stdnYQRpzlYKjFVqSoRuvBCXLU3UviuuVNGnpK/foNMUjQKhp+Tp9Ez8ExFZ+Jja651WabcOT6pa78CVd1V564NbiDKH6e2LRV9XNO8xrKyCq88OE/SFaNTNrAGoEtJehUSp3EfKb7z9cwZ9+DgGIJhdThFcH5xyvwfR1EQWb7UpUGovztdNfkdL9i4jR8/eWpwomcbU= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB31610DB937960AB372A0D61993C50HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 180377fb-5982-4324-6e82-08d70df23bc4 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2019 15:43:53.0831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3436 Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-sip-token-authnz - Security of the token X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 15:44:08 -0000 --_000_HE1PR07MB31610DB937960AB372A0D61993C50HE1PR07MB3161eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWWVob3NodWEsDQoNClRoYW5rcyBmb3IgeW91ciBpbnB1dCENCg0KSSB0aGluayBPUFRJT05T IDMgYW5kIDUgYXJlIG91dHNpZGUgdGhlIHNjb3BlLiBUaGUgbWVjaGFuaXNtIHNoYWxsIHdvcmsg d2l0aCB0aGUgZXhpc3RpbmcgT0F1dGggaW5mcmFzdHJ1Y3R1cmUuIE9QVElPTiA0IGlzIHRvbyBu YXJyb3cg4oCTIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGUgdG9rZW4gaXMgdmVyaWZpZWQgYnkg dGhlIHJlZ2lzdHJhci4NCg0KSG93ZXZlciwgSSBETyBhZ3JlZSB3aXRoIE9sbGUgdGhhdCB0aGUg dG9rZW4gbmVlZHMgdG8gYmUgcHJvdGVjdGVkIHNvIHRoYXQgbm9uLWludGVuZGVkIGVudGl0aWVz IHdpbGwgbm90IGhhdmUgYWNjZXNzIHRvIGl0LiBCdXQsIHRoYXQgZG9lc27igJl0IGFsd2F5cyBt ZWFuIGl0IGhhcyB0byBiZSBlbmNyeXB0ZWQuIEZvciBleGFtcGxlLCBpbiB5b3VyIGhvbWUgZ2F0 ZXdheSBleGFtcGxlIHlvdSBrbm93IHRoYXQgdGhlIGhlYWRlciBmaWVsZCB3aWxsIGJlIHJlbW92 ZWQgYmVmb3JlIHRoZSBTSVAgcmVxdWVzdCBpcyBmb3J3YXJkZWQgdG8gbm9uLWludGVuZGVkIGVu dGl0aWVzLg0KDQpBbHNvLCB3ZSBuZWVkIHRvIGFkZHJlc3MgdGhlIHByb3RlY3Rpb24gb2YgdGhl IHRva2VuLCBvciB0aGUgZHJhZnQgd2lsbCBuZXZlciBwYXNzIElFU0cgcmV2aWV3IPCfmIoNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KTMOkaGV0dMOkasOkOiBzaXBjb3JlIDxzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmc+IFB1b2xlc3RhIFllaG9zaHVhIEdldg0KTMOkaGV0ZXR0eTog c3VubnVudGFpIDIxLiBoZWluw6RrdXV0YSAyMDE5IDE0LjU1DQpWYXN0YWFub3R0YWphOiBzaXBj b3JlQGlldGYub3JnDQpBaWhlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tl bi1hdXRobnogLSBTZWN1cml0eSBvZiB0aGUgdG9rZW4NCg0KSGksDQoNCkxvb2tpbmcgYXQgdGhl IGRpc2N1c3Npb24gcmVnYXJkaW5nIHRoZSB3YXkgdG8gc2VjdXJlIHRoZSBhY2Nlc3MgdG9rZW4s IEkgdGhpbmsgaXQgd2lsbCBiZSBnb29kIHRvIHN1bW1hcml6ZSB0aGUgb3B0aW9ucy4NCg0KT1BU SU9OIDEgLSBCZWFyZXIgYXV0aG9yaXphdGlvbiAoYXMgYXBwZWFycyBpbiB0aGUgZHJhZnQpOg0K U2VuZCB0aGUgdG9rZW4gYXMgcGxhaW4gdGV4dCBvbiB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIu DQpUaGlzIG9wdGlvbiBpcyB2ZXJ5IHN0cmFpZ2h0LWZvcndhcmQsIGJ1dCBsYWNrcyB0aGUgYWJp bGl0eSBvZiB0aGUgVUFDIHRvIHZlcmlmeSB0aGF0IHRoZSB0b2tlbiBpcyBub3QgZXhwb3NlZCBi eSBzb21lIGludGVybWVkaWFyeSBwcm94eS4NCg0KT1BUSU9OIDIgLSBUb2tlbiBlbmNyeXB0aW9u IChhIHByb3Bvc2FsIGJ5IE9sbGUgSm9oYW5zc29uKToNCkVuY3J5cHQgdGhlIHRva2VuIHVzaW5n IGEgcHVibGljIGtleSB0aGF0IGlzIHByb3ZpZGVkIGluIGEgY2hhbGxlbmdlLg0KSSBiZWxpZXZl IHRoYXQgYSBwdWJsaWMga2V5IG9mIGEgVUEgZG9lc24ndCBub3JtYWxseSBjaGFuZ2UgYmV0d2Vl biBjaGFsbGVuZ2VzLCBzbyB0aGlzIG1ldGhvZCBpcyBwcm9uZSB0byByZXBseSBhdHRhY2tzIChp ZiB0aGUgY2hhbGxlbmdlIGJlIGtlcHQgY29uc3RhbnQpLg0KT2YgY291cnNlLCB0aGlzIG1ldGhv ZCBjYW4gYmUgZXh0ZW5kZWQgdG8gaW5jbHVkZSBhIG5vbmNlLCBidXQgaXQgd2lsbCBtYWtlIGl0 IG1vcmUgY29tcGxpY2F0ZWQuDQoNCk9QVElPTiAzIC0gRGlnZXN0IHNjaGVtZSAoYSBwcm9wb3Nh bCBieSBEYWxlIFdvcmxleSk6DQpVc2UgYSAiZGlnZXN0Ii1saWtlIHNjaGVtZSB0byBzZW5kIGEg aGFzaGVkIHZhbHVlIG9mIHRoZSB0b2tlbi4NCkkgYmVsaWV2ZSB0aGlzIGlzIHByb2JsZW1hdGlj LCBhcyBkaWdlc3QgY2FuIG9ubHkgYmUgdXNlZCBpZiBib3RoIHBhcnRpZXMga25vd3MgdGhlIHBh c3N3b3JkIChvciB0b2tlbikgaW4gYWR2YW5jZSwgc28gaXQncyBlbm91Z2ggdG8gY29tcGFyZSBp dHMgaGFzaCB2YWx1ZS4uDQpJbiBvdXIgY2FzZSwgdG9rZW5zIGNhbiB1c3VhbGx5IGJlIHZhbGlk YXRlZCBvbmx5IHdoZW4gdGhlaXIgZnVsbCB2YWx1ZSBpcyByZXZlYWxlZCAoZS5nLiwgdmFsaWRh dGlvbiBvZiBKV1QgdG9rZW4gaXMgZG9uZSB3aXRob3V0IHByZS1rbm93bGVkZ2Ugb2YgdGhlIHRv a2VuKS4NCg0KT1BUSU9OIDQgLSBIVFRQIEF1dGhvcml6YXRpb246DQpBc3N1bWluZyB0aGF0IHdl IHJlc29ydCB0byBoYXZpbmcgb25seSB0aGUgZmlyc3QgaG9wICh0aGUgaG9tZSBwcm94eSkgcGVy Zm9ybSB0aGUgYXV0aGVudGljYXRpb24sIGFuZCByZXN0cmljdGluZyBvdXJzZWx2ZXMgdG8gV2Vi UlRDIGNsaWVudHMsIHRoZSBhdXRob3JpemF0aW9uIGNhbiBiZSBkb25lIG9uIHRoZSBIVFRQIGxl dmVsIG9mIFdlYlNvY2tldCBjcmVhdGlvbi4NClRoaXMgb3B0aW9uIGlzIGF2YWlsYWJsZSB0byB1 c2UgY3JlYXRpbmcgbmV3IHN0YW5kYXJkcywgYnV0IGFwcGFyZW50bHkgaXQncyBub3QgZW5vdWdo IChvciB0aGUgZHJhZnQgd291bGQgbm90IGhhdmUgYmVlbiB3cml0dGVuKS4NCg0KT1BUSU9OIDUg LSBOZXcgY2hhbGxlbmdlLXJlc3BvbnNlIG1lY2hhbmlzbToNClByb2JhYmx5IHNvbWUgY29tYmlu YXRpb24gb2Ygb3B0aW9ucyAyIGFuZCAzLCBidXQgaGF2aW5nIGl0IHN0YW5kYXJkaXplZCBhbmQg cGVyZm9ybWVkIGJ5IDNyZC1wYXJ0eSBPQXV0aCBzZXJ2ZXIuDQpKdXN0IGxpa2UgUkZDIDUwOTAg cHJvcG9zZWQgYSB3YXkgZm9yIGEgUkFESVVTIHNlcnZlciB0byBwZXJmb3JtIGRpZ2VzdCBhdXRo ZW50aWNhdGlvbiwgYW4gZXh0ZW5zaW9uIHRvIE9BdXRoIGludHJvc3BlY3Rpb24gZW5kcG9pbnQg KFJGQyA3NjYyKSwgY2FuIHBvc3NpYmx5IGJlIG1hZGUgdG8gdmFsaWRhdGUgYSB0b2tlbiB1c2lu ZyBhIGNoYWxsZW5nZS1yZXNwb25zZSBtZWNoYW5pc20uDQpXaXRoIHRoaXMgb3B0aW9uLCB0aGUg InNlY3VyaXR5IGJ1cmRlbiIgd2lsbCBmYWxsIG9uIE9BdXRoIHNlcnZlcnMgYW5kIG5vdCBvbiB0 aGUgU0lQIFVBcy4NCg0KDQpIYXZpbmcgbGFpZCBvdXQgdGhlIG9wdGlvbnMgYWJvdmUgKEknbSBz dXJlIHRoZXJlIGFyZSBvcHRpb25zIEkndmUgbWlzc2VkKSwNCkkgdGhpbmsgdGhhdCB0aGUgc2Nv cGUgb2YgdGhlIGN1cnJlbnQgZHJhZnQgc2hvdWxkIHJlbWFpbiBtaW5pbWFsLCBhbmQgT1BUSU9O IDEgc2hvdWxkIGJlIHVzZWQuDQoNCkZvciBleGFtcGxlLCBhIGNvbW1vbiB1c2UgY2FzZSBpcyB0 aGF0IHRoZSBob21lIHByb3h5IHBlcmZvcm0gdGhlIGF1dGhlbnRpY2F0aW9uLCBhbmQgcmVtb3Zl IHRoZSBBdXRob3JpemF0aW9uIGhlYWRlciB3aGVuIGZvcndhcmRpbmcgdGhlIHJlcXVlc3QuIEZv ciB0aGlzIHVzZSBjYXNlLCBpdCB3aWxsIGJlIG5pY2UgaWYgb3B0aW9uIDEgd2lsbCByZW1haW4g YXZhaWxhYmxlLg0KDQpTdGlsbCwgZXZlbiBmb3IgdGhpcyBzY2VuYXJpbywgbWF5YmUgYSBzaW1w bGUgY2hhbGxlbmdlLXJlc3BvbnNlIG1lY2hhbmlzbSBzaG91bGQgYmUgcmVxdWlyZWQsIHNvIHRo ZSBVQUMgd2lsbCBoYXZlIGEgd2F5IHRvIGtub3cgdGhhdCB0aGUgaG9tZSBwcm94eSBzdXBwb3J0 cw0KdGhpcyBraW5kIG9mIGF1dGhlbnRpY2F0aW9uLiBXaXRob3V0IGl0IChpZiB0aGUgcHJveHkg aXMgbm90IHN1cHBvcnRpbmcpLCB0aGUgVUFDIG1pZ2h0IHNlbmQgdGhlIHRva2VuLCBhbmQgdGhl IHByb3h5IGZvcndhcmQgaXQgdG8gdW4tdHJ1c3RlZCBlbnRpdGllcy4NCg0KRm9yIHRoZSBsb25n IHJ1biAob24gb3RoZXIgZHJhZnRzKSwgdGhlIG90aGVyIG9wdGlvbnMgc2hvdWxkIHByb2JhYmx5 IGJlIGxvb2tlZCBpbnRvLCBzbyB0aGUgc2VjdXJpdHkgcmVzdHJpY3Rpb24gaW1wb3NlZCBieSBv cHRpb24gMSBjb3VsZCBiZSByZWxheGVkLg0KDQoNClJlZ2FyZHMsDQpZZWhvc2h1YQ0K --_000_HE1PR07MB31610DB937960AB372A0D61993C50HE1PR07MB3161eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlNoa3Bvc3RpdHl5bGkx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFllaG9zaHVhLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3Mg Zm9yIHlvdXIgaW5wdXQhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgT1BUSU9OUyAzIGFuZCA1IGFyZSBvdXRzaWRl IHRoZSBzY29wZS4gVGhlIG1lY2hhbmlzbSBzaGFsbCB3b3JrIHdpdGggdGhlIGV4aXN0aW5nIE9B dXRoIGluZnJhc3RydWN0dXJlLiBPUFRJT04gNCBpcyB0b28gbmFycm93IOKAkyB0aGVyZSBhcmUg Y2FzZXMgd2hlcmUgdGhlIHRva2VuIGlzIHZlcmlmaWVkIGJ5IHRoZSByZWdpc3RyYXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkhvd2V2ZXIsIEkgRE8gYWdyZWUgd2l0aCBPbGxlIHRoYXQgdGhlIHRva2VuIG5lZWRzIHRvIGJl IHByb3RlY3RlZCBzbyB0aGF0IG5vbi1pbnRlbmRlZCBlbnRpdGllcyB3aWxsIG5vdCBoYXZlIGFj Y2VzcyB0byBpdC4gQnV0LCB0aGF0IGRvZXNu4oCZdCBhbHdheXMgbWVhbiBpdCBoYXMgdG8gYmUg ZW5jcnlwdGVkLiBGb3IgZXhhbXBsZSwgaW4NCiB5b3VyIGhvbWUgZ2F0ZXdheSBleGFtcGxlIHlv dSBrbm93IHRoYXQgdGhlIGhlYWRlciBmaWVsZCB3aWxsIGJlIHJlbW92ZWQgYmVmb3JlIHRoZSBT SVAgcmVxdWVzdCBpcyBmb3J3YXJkZWQgdG8gbm9uLWludGVuZGVkIGVudGl0aWVzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkFsc28sIHdlIG5lZWQgdG8gYWRkcmVzcyB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgdG9rZW4sIG9y IHRoZSBkcmFmdCB3aWxsIG5ldmVyIHBhc3MgSUVTRyByZXZpZXcNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZjttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+JiMxMjg1MjI7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGSSI+TMOkaGV0dMOkasOkOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRkkiPiBzaXBjb3JlICZsdDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8 Yj5QdW9sZXN0YSA8L2I+WWVob3NodWEgR2V2PGJyPg0KPGI+TMOkaGV0ZXR0eTo8L2I+IHN1bm51 bnRhaSAyMS4gaGVpbsOka3V1dGEgMjAxOSAxNC41NTxicj4NCjxiPlZhc3RhYW5vdHRhamE6PC9i PiBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+QWloZTo8L2I+IFtzaXBjb3JlXSBkcmFmdC1pZXRm LXNpcGNvcmUtc2lwLXRva2VuLWF1dGhueiAtIFNlY3VyaXR5IG9mIHRoZSB0b2tlbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks PGJyPg0KPGJyPg0KTG9va2luZyBhdCB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgdGhlIHdheSB0 byBzZWN1cmUgdGhlIGFjY2VzcyB0b2tlbiwgSSB0aGluayBpdCB3aWxsIGJlIGdvb2QgdG8gc3Vt bWFyaXplIHRoZSBvcHRpb25zLjxicj4NCjxicj4NCk9QVElPTiAxIC0gQmVhcmVyIGF1dGhvcml6 YXRpb24gKGFzIGFwcGVhcnMgaW4gdGhlIGRyYWZ0KTo8YnI+DQpTZW5kIHRoZSB0b2tlbiBhcyBw bGFpbiB0ZXh0IG9uIHRoZSBBdXRob3JpemF0aW9uIGhlYWRlci48YnI+DQpUaGlzIG9wdGlvbiBp cyB2ZXJ5IHN0cmFpZ2h0LWZvcndhcmQsIGJ1dCBsYWNrcyB0aGUgYWJpbGl0eSBvZiB0aGUgVUFD IHRvIHZlcmlmeSB0aGF0IHRoZSB0b2tlbiBpcyBub3QgZXhwb3NlZCBieSBzb21lIGludGVybWVk aWFyeSBwcm94eS48YnI+DQo8YnI+DQpPUFRJT04gMiAtIFRva2VuIGVuY3J5cHRpb24gKGEgcHJv cG9zYWwgYnkgT2xsZSBKb2hhbnNzb24pOjxicj4NCkVuY3J5cHQgdGhlIHRva2VuIHVzaW5nIGEg cHVibGljIGtleSB0aGF0IGlzIHByb3ZpZGVkIGluIGEgY2hhbGxlbmdlLjxicj4NCkkgYmVsaWV2 ZSB0aGF0IGEgcHVibGljIGtleSBvZiBhIFVBIGRvZXNuJ3Qgbm9ybWFsbHkgY2hhbmdlIGJldHdl ZW4gY2hhbGxlbmdlcywgc28gdGhpcyBtZXRob2QgaXMgcHJvbmUgdG8gcmVwbHkgYXR0YWNrcyAo aWYgdGhlIGNoYWxsZW5nZSBiZSBrZXB0IGNvbnN0YW50KS48YnI+DQpPZiBjb3Vyc2UsIHRoaXMg bWV0aG9kIGNhbiBiZSBleHRlbmRlZCB0byBpbmNsdWRlIGEgbm9uY2UsIGJ1dCBpdCB3aWxsIG1h a2UgaXQgbW9yZSBjb21wbGljYXRlZC48YnI+DQo8YnI+DQpPUFRJT04gMyAtIERpZ2VzdCBzY2hl bWUgKGEgcHJvcG9zYWwgYnkgRGFsZSBXb3JsZXkpOjxicj4NClVzZSBhICZxdW90O2RpZ2VzdCZx dW90Oy1saWtlIHNjaGVtZSB0byBzZW5kIGEgaGFzaGVkIHZhbHVlIG9mIHRoZSB0b2tlbi48YnI+ DQpJIGJlbGlldmUgdGhpcyBpcyBwcm9ibGVtYXRpYywgYXMgZGlnZXN0IGNhbiBvbmx5IGJlIHVz ZWQgaWYgYm90aCBwYXJ0aWVzIGtub3dzIHRoZSBwYXNzd29yZCAob3IgdG9rZW4pIGluIGFkdmFu Y2UsIHNvIGl0J3MgZW5vdWdoIHRvIGNvbXBhcmUgaXRzIGhhc2ggdmFsdWUuLjxicj4NCkluIG91 ciBjYXNlLCB0b2tlbnMgY2FuIHVzdWFsbHkgYmUgdmFsaWRhdGVkIG9ubHkgd2hlbiB0aGVpciBm dWxsIHZhbHVlIGlzIHJldmVhbGVkIChlLmcuLCB2YWxpZGF0aW9uIG9mIEpXVCB0b2tlbiBpcyBk b25lIHdpdGhvdXQgcHJlLWtub3dsZWRnZSBvZiB0aGUgdG9rZW4pLjxicj4NCjxicj4NCk9QVElP TiA0IC0gSFRUUCBBdXRob3JpemF0aW9uOjxicj4NCkFzc3VtaW5nIHRoYXQgd2UgcmVzb3J0IHRv IGhhdmluZyBvbmx5IHRoZSBmaXJzdCBob3AgKHRoZSBob21lIHByb3h5KSBwZXJmb3JtIHRoZSBh dXRoZW50aWNhdGlvbiwgYW5kIHJlc3RyaWN0aW5nIG91cnNlbHZlcyB0byBXZWJSVEMgY2xpZW50 cywgdGhlIGF1dGhvcml6YXRpb24gY2FuIGJlIGRvbmUgb24gdGhlIEhUVFAgbGV2ZWwgb2YgV2Vi U29ja2V0IGNyZWF0aW9uLjxicj4NClRoaXMgb3B0aW9uIGlzIGF2YWlsYWJsZSB0byB1c2UgY3Jl YXRpbmcgbmV3IHN0YW5kYXJkcywgYnV0IGFwcGFyZW50bHkgaXQncyBub3QgZW5vdWdoIChvciB0 aGUgZHJhZnQgd291bGQgbm90IGhhdmUgYmVlbiB3cml0dGVuKS48YnI+DQo8YnI+DQpPUFRJT04g NSAtIE5ldyBjaGFsbGVuZ2UtcmVzcG9uc2UgbWVjaGFuaXNtOjxicj4NClByb2JhYmx5IHNvbWUg Y29tYmluYXRpb24gb2Ygb3B0aW9ucyAyIGFuZCAzLCBidXQgaGF2aW5nIGl0IHN0YW5kYXJkaXpl ZCBhbmQgcGVyZm9ybWVkIGJ5IDNyZC1wYXJ0eSBPQXV0aCBzZXJ2ZXIuPGJyPg0KSnVzdCBsaWtl IFJGQyA1MDkwIHByb3Bvc2VkIGEgd2F5IGZvciBhIFJBRElVUyBzZXJ2ZXIgdG8gcGVyZm9ybSBk aWdlc3QgYXV0aGVudGljYXRpb24sIGFuIGV4dGVuc2lvbiB0byBPQXV0aCBpbnRyb3NwZWN0aW9u IGVuZHBvaW50IChSRkMgNzY2MiksIGNhbiBwb3NzaWJseSBiZSBtYWRlIHRvIHZhbGlkYXRlIGEg dG9rZW4gdXNpbmcgYSBjaGFsbGVuZ2UtcmVzcG9uc2UgbWVjaGFuaXNtLjxicj4NCldpdGggdGhp cyBvcHRpb24sIHRoZSAmcXVvdDtzZWN1cml0eSBidXJkZW4mcXVvdDsgd2lsbCBmYWxsIG9uIE9B dXRoIHNlcnZlcnMgYW5kIG5vdCBvbiB0aGUgU0lQIFVBcy48YnI+DQo8YnI+DQo8YnI+DQpIYXZp bmcgbGFpZCBvdXQgdGhlIG9wdGlvbnMgYWJvdmUgKEknbSBzdXJlIHRoZXJlIGFyZSBvcHRpb25z IEkndmUgbWlzc2VkKSw8YnI+DQpJIHRoaW5rIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBjdXJyZW50 IGRyYWZ0IHNob3VsZCByZW1haW4gbWluaW1hbCwgYW5kIE9QVElPTiAxIHNob3VsZCBiZSB1c2Vk Ljxicj4NCjxicj4NCkZvciBleGFtcGxlLCBhIGNvbW1vbiB1c2UgY2FzZSBpcyB0aGF0IHRoZSBo b21lIHByb3h5IHBlcmZvcm0gdGhlIGF1dGhlbnRpY2F0aW9uLCBhbmQgcmVtb3ZlIHRoZSBBdXRo b3JpemF0aW9uIGhlYWRlciB3aGVuIGZvcndhcmRpbmcgdGhlIHJlcXVlc3QuIEZvciB0aGlzIHVz ZSBjYXNlLCBpdCB3aWxsIGJlIG5pY2UgaWYgb3B0aW9uIDEgd2lsbCByZW1haW4gYXZhaWxhYmxl Ljxicj4NCjxicj4NClN0aWxsLCBldmVuIGZvciB0aGlzIHNjZW5hcmlvLCBtYXliZSBhIHNpbXBs ZSBjaGFsbGVuZ2UtcmVzcG9uc2UgbWVjaGFuaXNtIHNob3VsZCBiZSByZXF1aXJlZCwgc28gdGhl IFVBQyB3aWxsIGhhdmUgYSB3YXkgdG8ga25vdyB0aGF0IHRoZSBob21lIHByb3h5IHN1cHBvcnRz PGJyPg0KdGhpcyBraW5kIG9mIGF1dGhlbnRpY2F0aW9uLiBXaXRob3V0IGl0IChpZiB0aGUgcHJv eHkgaXMgbm90IHN1cHBvcnRpbmcpLCB0aGUgVUFDIG1pZ2h0IHNlbmQgdGhlIHRva2VuLCBhbmQg dGhlIHByb3h5IGZvcndhcmQgaXQgdG8gdW4tdHJ1c3RlZCBlbnRpdGllcy48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpGb3IgdGhlIGxvbmcgcnVuIChv biBvdGhlciBkcmFmdHMpLCB0aGUgb3RoZXIgb3B0aW9ucyBzaG91bGQgcHJvYmFibHkgYmUgbG9v a2VkIGludG8sIHNvIHRoZSBzZWN1cml0eSByZXN0cmljdGlvbiBpbXBvc2VkIGJ5IG9wdGlvbiAx IGNvdWxkIGJlIHJlbGF4ZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ZZWhvc2h1YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR07MB31610DB937960AB372A0D61993C50HE1PR07MB3161eurp_-- From nobody Mon Jul 22 14:39:09 2019 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA7812001B; Mon, 22 Jul 2019 14:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <156383153972.22694.11101638464705866045@ietfa.amsl.com> Date: Mon, 22 Jul 2019 14:38:59 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-locparam-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:39:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core WG of the IETF. Title : Location Source Parameter for the SIP Geolocation Header Field Authors : James Winterbottom Roland Jesske Bruno Chatras Andrew Hutton Filename : draft-ietf-sipcore-locparam-02.txt Pages : 8 Date : 2019-07-22 Abstract: There are some circumstances where a geolocation header field may contain more than one location value. Knowing the identity of the node adding the location value allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the location values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-locparam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-locparam-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-locparam-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-locparam-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/