From nobody Mon Dec 2 05:44: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 048081207FB; Mon, 2 Dec 2019 05:44:38 -0800 (PST) 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 mkiYlN-sskV6; Mon, 2 Dec 2019 05:44:36 -0800 (PST) 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 61327120274; Mon, 2 Dec 2019 05:44:36 -0800 (PST) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xB2DiX07085325 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 Dec 2019 07:44:34 -0600 (CST) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1575294274; bh=ZtOVvY/x9EgwsGa0Y/mUTqv9X4gUqE+D3UO5boN6Jm4=; h=To:From:Subject:Date; b=i88Y6GsBbQE3WfE+gAl5Ro3iiXhLTmSVra6WjE0ltGIDy4qiR5/1LVjdqFvYI6fUw fD+OAi/WWAyxNORZzwwwyDUce2dKoWehypCq8epDOoE2dskrv6vnCTixm0jQXtsTe3 kJT/3XTeM2os2q/Z41YFqo6DW6d3/VCmz2LlGYAY= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local To: SIPCORE , draft-ietf-sipcore-sip-token-authnz@ietf.org From: "A. Jean Mahoney" Message-ID: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> Date: Mon, 2 Dec 2019 07:44:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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] WGLC draft-ietf-sipcore-sip-token-authnz 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, 02 Dec 2019 13:44:38 -0000 Hi all, Today starts the Working Group Last Call of draft-ietf-sipcore-sip-token-authnz-06. https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ The document has changed quite a bit since its predecessor went through WGLC. Please review. If you submitted feedback on a previous version, make sure that it was addressed and your questions answered. Also appreciated would be any information on implementation plans. WGLC ends Monday, Dec 16. Thanks! Jean From nobody Tue Dec 3 10:18: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 60C7D120099 for ; Tue, 3 Dec 2019 10:18:34 -0800 (PST) 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, 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=alum.mit.edu 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 V0yuaStWKJ59 for ; Tue, 3 Dec 2019 10:18:31 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760048.outbound.protection.outlook.com [40.107.76.48]) (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 5DFB112007A for ; Tue, 3 Dec 2019 10:18:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d6U4xGL9QUfgH3ITDBCxRsDD61ZpeIJyDkZczjumqoIb14wH4xjZKvQzQVtH/thBy90FFoX4jEPqTgzEpbzgPIKpLWPdjGV0E00hwn+i9fJcaYTNqXl65XtBmSH++Rw+uFEbJMf3Q16hhukvFTv8kWxlBlKq4WUP6xfM9QksOx62izq8gQpFfHuFucYhkJfzjMjbICzVNWQSaH4sJ/3nf1PA1NdMTPWcoY1SqiXqxg+ruj0r+88yQepJ+78qyvWTgQ/oH+rIQqhuq9MPfwqFzI19oZqAibqgjSlx4QnNMPKkFhOriBek5oaiaZzO+8QG7Kesdcn6UXIA3hoH88MUHw== 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=GhTJlX/EiPUztNRFWHTdT5a5C1s5cFSjI3WARYMx1SI=; b=JVimiZe7aZozBTF7ucTQg8W3aghCwnKKG9i9gBGBjZDZOjSQyD7nKPQyMajfOe2/jITLedy0LZdHYm1qYHIg6cVtgjYGtxARftraQ4Ax90+D/f+JpQS+aEXbsGq6mzzteTT7GJmaXnuTF7nuWXnTrMeOP3+V/OwCssjw8OUyZAT4TFA5HzRryiU+QH3pgfPCrEpzoESaNB2VxKXeBUCLLR7McHyZKk95FN3Tbq0rGkGxgJ2FezYMd4M6r0bcE5a9L4PadDYcG+cKGMw1iove837CW2gkH7WQIt0BVDZBFs//PuNw6asNhWdkDnOs5RMQalWBX8iFrILe4TmCRvMXWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GhTJlX/EiPUztNRFWHTdT5a5C1s5cFSjI3WARYMx1SI=; b=MOeXmi/i0BRB8uOL86hRDL7ctuUmLY58FiBs6tMC8EgNhagR9OzfsUyGy0FXshfWh14rQHWoofDT6FgdJOeTpszNIf1k/WguSDgnF1QYtlE0RUByCc/jpMkOqii+HluEbIG6BpEN7V0efrbH+oJTc3ed7IGBZGB8SyzIHNTKKAM= Received: from MWHPR12CA0056.namprd12.prod.outlook.com (2603:10b6:300:103::18) by BY5PR12MB4097.namprd12.prod.outlook.com (2603:10b6:a03:213::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.17; Tue, 3 Dec 2019 18:18:29 +0000 Received: from SN1NAM02FT047.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::204) by MWHPR12CA0056.outlook.office365.com (2603:10b6:300:103::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12 via Frontend Transport; Tue, 3 Dec 2019 18:18:29 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT047.mail.protection.outlook.com (10.152.72.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17 via Frontend Transport; Tue, 3 Dec 2019 18:18:29 +0000 Received: from Kokiri.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 xB3IIRvT019198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 3 Dec 2019 13:18:28 -0500 To: sipcore@ietf.org References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> From: Paul Kyzivat Message-ID: Date: Tue, 3 Dec 2019 13:18:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(199004)(189003)(53754006)(356004)(7596002)(75432002)(2351001)(305945005)(2361001)(76130400001)(31686004)(6916009)(186003)(66574012)(58126008)(6246003)(70206006)(5660300002)(36906005)(106002)(229853002)(70586007)(6306002)(446003)(11346002)(2906002)(2616005)(956004)(53546011)(2870700001)(88552002)(65956001)(31696002)(336012)(14444005)(26005)(498600001)(2486003)(26826003)(50466002)(86362001)(8936002)(76176011)(966005)(246002)(8676002)(23676004); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR12MB4097; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 56d9bc3c-c242-48ab-b5ef-08d7781d3271 X-MS-TrafficTypeDiagnostic: BY5PR12MB4097: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-Forefront-PRVS: 02408926C4 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IpQBXxR2/jZagseoQeEaNl8JfxxLyzsy1AFo28OLWSGspAK2TBTfW7gexl+IULCz+Bz8C3aTFM3ZQi7VSe7GoBh/HnC84G5QwjwvezYFAoweYkox4mzZzbiNkS4dR+ECfOBaoH7d76AfYZimlnyJ+KqXAeh4eK4HsPBq6tAmMQxPkWNhn7xR7y2iihbZR1iYzXggSgTEQl688sSOaUK2NIuBBiGLN5JamGW/+/hg0SMw8TrUjWIuIgHQUrI07Jltn/zJQ6oFSrfCzAP8yz1Bkof3G20iEPdXdi+LYG2or+gy7sZNSyFUlFoIpAhdzEFvbfrSskML2ZEA0ghDT8gAV5hhbaF0gL+oMbrCOMJlv9cYWS3Rjw1zHAcMTz3GWN1hd2Ry813EPPfso3T5I4xEaKoJdzboTvy0yS18QE2U4K22bsT4Elfighv5pWVYMQcb33lX0RCgatcaNMun170Cg4PjdPTQ7GSxl5uOG95fv+w= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2019 18:18:29.0481 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 56d9bc3c-c242-48ab-b5ef-08d7781d3271 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4097 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 03 Dec 2019 18:18:34 -0000 I've just reviewed the document again, in full. There are still a number of areas that need work: * Section 2.1.1 says: The method used to authenticate the user and obtain these tokens is out of scope for this document, with one potential method is the Native App mechanism defined in [RFC8252]. The advantages of using the mechanism defined in [RFC8252] is that the user will be directed to use a browser to interact with the authorization server. This allows the authorization server to prompt the user for multi-factor authentication, redirect the user to third-party identity providers, and the use of single-sign-on sessions. My problem with this is: the challenge gives the UAC an HTTPS URL of an AS. It does not normatively state how the UAC is to use this, or what usage(s) the AS MUST support. Hence there is no assurance that the UAC will be able to successfully access the AS. This could be resolved by requiring that the UAC and AS MUST support RFC8252. Or perhaps there is some more expansive RFC that can be referenced. In the end there needs to be something MTI. * Section 2.1.2: You talk about local policy here, but which server's local policy are you talking about? I'm guessing that the AS provides a token containing whatever methods have been granted for the user, and the registrar can then use policy to decide what method(s) it wants to require for registration. Am I correct in assuming that the UAC doesn't play any role in this other than to relay the token from the AS to the registrar? And in this case why is this point being made in the section about *UAC* behavior? Can you please clarify the text here? * Section 2.1.4: This section says that the UAC MUST include an Authorization header field with the Bearer scheme. This is overly strong. This should be an explanation that *if* it has received a challenge containing the Bearer scheme then to resolve that particular challenge it needs to send a request with an Authorization header field containing the response to that challenge, including the Bearer scheme. (But note that if there were multiple challenges with different schemes then it maybe able to successfully retry the request using non-Bearer credentials.) I don't understand what distinction you are trying to draw by distinguishing the behavior for creating a binding from that for refreshing a binding. AFAIK there should be no difference. And in fact the UAC in general cannot know whether the request being send will establish or refresh a binding. * Section 2.1.5: This section has similar issues to section 2.1.4: The MUST is too strong, and the reason for distinguishing between in-dialog requests from others is unclear. * Section 2.2: Again is overly strong in its use of MUST. I think it is evident that the point being made is that a challenge containing Bearer scheme is the way to indicate that is with a challenge with Bearer scheme, but the text is at least awkward. How about: When a UAS or Registrar receives a request that fails to contain authorization credentials acceptable to it, it SHOULD challenge the request by sending a 401 (Unauthorized) response. To indicate that it is willing to accept an OAuth2 token as a credential the UAS/Registrar MUST include a Proxy-Authentication header field in the response, indicate "Bearer" scheme and include an address of an Authorization Server from which the originator can obtain an access token. In the second paragraph, please provide a reference: ... using the procedures from [RFC???] associated with the type of access token used. * Section 2.3: Similar comment to section 2.2. How about the following for the first paragraph: When a proxy receives a request that fails to contain authorization credentials acceptable to it, it SHOULD challenge the request by sending a 407 (Proxy Authentication Required) response. To indicate that it is willing to accept an OAuth2 token as a credential the proxy MUST include a Proxy-Authentication header field in the response, indicating "Bearer" scheme and including an address to an Authorization Server from which the originator can obtain an access token. I don't think the second paragraph should condition any behavior on whether it has previously challenged. That requires that the proxy be stateful, and it isn't a necessary condition. Instead, how about: When a proxy wishes to authenticate a received request, it MUST search the request for Proxy-Authorization header fields with 'realm' parameters that match its realm. It then MUST successfully validate the credentials from at least one Proxy-Authorization header field for its realm. When the scheme is Bearer the proxy MUST validate the access token, using the procedures from [RFC???] associated with the type of access token used. * Section 3: The following: The realm and auth-param parameters are defined in [RFC3261]. is incomplete, because it is missing 'challenge', 'realm', and 'https-URI. (Where is https-URI defined?) Another way to do this is by adding the following to the syntax: challenge = realm = auth-param = scope = error = https-URI = (This helps those who might try to formally validate the syntax because it removes undefined parameters.) Also, 'scope' and 'error' are very generic rule names being used in a very restricted context. While these are not defined in RFC3261, there is the potential conflict with other extensions. I'd recommend using more specific terms. E.g., challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) bearer-cln = realm / bearer-scope / authz-server / bearer-error / auth-param authz-server = "authz_server" EQUAL authz-server-value authz-server-value = https-URI challenge = realm = auth-param = bearer-scope = bearer-error = https-URI = Regarding the scope parameter: This parameter is conveyed from the registrar to the UAC. But what is the UAC to do with it? How does it have any control over the scope of the token it gets from the AS? Is the UAC supposed to convey this to the AS? If so, how? Regarding the error parameter: Is this just intended to be of help in debugging the UAC? Or is it expected that the UAC might take some sort of pre-programmed action in response? If the latter, how might that work? Is this information suitable for presentation to the user? * Section 4: I agree with Dale - I don't see any value in this tag. I tried to search for all discussion on the point. The discussion attributes me with requesting it, but I don't think I did. * Missing: I find no syntax extensions for Authorization and Proxy-Authorization. These need to be added. Thanks, Paul On 12/2/19 8:44 AM, A. Jean Mahoney wrote: > Hi all, > > Today starts the Working Group Last Call of > draft-ietf-sipcore-sip-token-authnz-06. > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > The document has changed quite a bit since its predecessor went through > WGLC. > > Please review.  If you submitted feedback on a previous version, make > sure that it was addressed and your questions answered. > > Also appreciated would be any information on implementation plans. > > WGLC ends Monday, Dec 16. From nobody Wed Dec 4 00:00: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 757DA120106 for ; Wed, 4 Dec 2019 00:00:16 -0800 (PST) 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 swzCmXKooQNd for ; Wed, 4 Dec 2019 00:00:14 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150081.outbound.protection.outlook.com [40.107.15.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 2C32D120100 for ; Wed, 4 Dec 2019 00:00:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E/4bqmDdy364EuPofB/TU0CZ5vDdPOvvkC+iiqYsd6yB2XxZ2ujjmsbdxTFBltaYCvg67r+4JwsQ/pRPlhpatXq5+B15oFeuEzf+CZ2M4lU4WinU3BGThDUjYns2aIKtEpRkAl0yVR+rPfqLwOLiKLOH4L1PwiJjQgqLrjaNQMkEXOFDe4LSwU3XZaS+3d0F38Jdc0xCNCNvBhn5byvOnY+YhAudK9u5/fpZXtj7MEgFZrFnTOsQLvcJm6wqoFrOhTZx5CN5D+Pornk38Xm6CnER/j3+lAKQM9YHjKvllXJSfpV4eQe0XTRBpYZwEFfut4VfDT+u7qwZMuWYtO9Ewg== 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=hXF7mHw+4wyLpQ8t+ptSiNLEQiMhUZtsj1T9NTQL0x4=; b=N9rIk9xOp/us2pNf9JYr0y4XQ9ejxQvgJKCpNXthT0+8TPuoexKRTxr8JUxKA5WiJb4A+XJGyQNydUNrOpmGDWCZKTP/dY15AJZPVu13BTXtifmRGal0EGhN+RgehHbeYlNrbC8UVZo7k5rzhKRsbGcAH/l81Atev8y612EnuzUbCtGXlExnA/49e+CkZ69ZEpn89bPR7ZVITCvCFFlnme4XeaifCrdX8DuFX8Piq9L7iDEplImSA8JHqQ4PzS14hySTDzIwfZu0P+kSSEO/iRj4pILj3T6aO01VHJCkuP/ueb8yBXCBB8/x/tDhMZ1xrG7tnV8xtSMJxjM2tGNkKA== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hXF7mHw+4wyLpQ8t+ptSiNLEQiMhUZtsj1T9NTQL0x4=; b=U0ybi5P26AU8IOoFl38yacKTYhx2xwjiB8mHUeRNb1Rfi2dewILkoSM5ouzzucsnO2Gqs8Ei4odEdfMfYxYYocu/BZQ7okgUBVG3JTxKq951l+gUYCoKiBRou4U/c0ZGZrVbFJvMlzzgLnbBtyQ37dQexSanvg1RFCFjzzLRsNE= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3308.eurprd07.prod.outlook.com (10.170.246.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.6; Wed, 4 Dec 2019 08:00:09 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2516.003; Wed, 4 Dec 2019 08:00:09 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Thread-Index: AQHVqRaq+n57bvgHbkmAxusa4398hqeoufCAgAEHG4A= Date: Wed, 4 Dec 2019 08:00:09 +0000 Message-ID: <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 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: 1eaadd6b-9757-4cb6-367f-08d7788ffbe7 x-ms-traffictypediagnostic: HE1PR07MB3308: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(189003)(199004)(2501003)(5660300002)(33656002)(6486002)(478600001)(66946007)(66476007)(66556008)(58126008)(76116006)(64756008)(66446008)(7736002)(99286004)(316002)(91956017)(6116002)(110136005)(3846002)(2616005)(36756003)(446003)(11346002)(26005)(256004)(71200400001)(305945005)(81156014)(2171002)(81166006)(44832011)(6246003)(102836004)(14444005)(2906002)(8676002)(86362001)(71190400001)(6512007)(229853002)(8936002)(25786009)(76176011)(186003)(6506007)(14454004)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3308; 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: BCL:0; x-microsoft-antispam-message-info: v4TgdtXSTLvTrEFZt3ucJvqRmNHnHkHmyJ/iBhjrbEJcoQIHW3nzXrme7adLH5Q91uusgyEKnjF49TnTN5h4Bf7Y+yOINx9FF2qO1vedKho5vDUgZls75L/KlTwoEhKEN0/AujtAx6z/HUwcRB1IEem87NXpb5hI4eXoLSbLTU00zfpIovkHTJHIA+q9OFimKqx2+JnIOTTwMEDWajWNKoc0e+JudtwCzyFgDYEBZoznG0wU7xXxhLDEbqo49SPLf1ZgORCB4IMljPC38uVaxDtvpZ0NvvfD3WrHrQcOAKcWuizyQjVi+WbNMbfALBVEVc2GKtQCP37W6mlaz1E1oO7bpBc6LY9CkKtBL9UtHbLAIr3NJBlwjakmWdYrhbzNQ8BJZFhA0cIVhdxtcOp4w8js7yCZvxatHn8QAx3Uov6yEa5fKI/2/qHkNSiwShyy x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <614D0491D5C47A4FBE59D64C7D45B59B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1eaadd6b-9757-4cb6-367f-08d7788ffbe7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 08:00:09.6955 (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: luoUO17DamDDbhTJiEZ5JPi6zeGuVlscQlc0p6HvypqjjXMnX66DnM8UdOUfAwKY99H1gDeBkrFqJeBRaBZ6e46063eQlhgG5gmQ2yg8L4E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3308 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 04 Dec 2019 08:00:16 -0000 SGkgUGF1bCwNCg0KTXkgY29tbWVudHMgb24gc29tZSBvZiB5b3VyIFNJUC1yZWxhdGVkIGlzc3Vl cyAoSSBhbSBub3QgYWRkcmVzc2luZyB5b3VyIGlzc3VlcyBvbiBTZWN0aW9ucyAyLjEuMSBhbmQg Mi4xLjIgaW4gdGhpcyByZXBseSkuIA0KDQo+ICAgICogU2VjdGlvbiAyLjEuNDoNCj4gICAgDQo+ ICAgIFRoaXMgc2VjdGlvbiBzYXlzIHRoYXQgdGhlIFVBQyBNVVNUIGluY2x1ZGUgYW4gQXV0aG9y aXphdGlvbiBoZWFkZXIgDQo+ICAgIGZpZWxkIHdpdGggdGhlIEJlYXJlciBzY2hlbWUuIFRoaXMg aXMgb3Zlcmx5IHN0cm9uZy4NCj4gICAgDQo+ICAgIFRoaXMgc2hvdWxkIGJlIGFuIGV4cGxhbmF0 aW9uIHRoYXQgKmlmKiBpdCBoYXMgcmVjZWl2ZWQgYSBjaGFsbGVuZ2UgDQo+ICAgIGNvbnRhaW5p bmcgdGhlIEJlYXJlciBzY2hlbWUgdGhlbiB0byByZXNvbHZlIHRoYXQgcGFydGljdWxhciBjaGFs bGVuZ2UgDQo+ICAgIGl0IG5lZWRzIHRvIHNlbmQgYSByZXF1ZXN0IHdpdGggYW4gQXV0aG9yaXph dGlvbiBoZWFkZXIgZmllbGQgY29udGFpbmluZyANCj4gICAgdGhlIHJlc3BvbnNlIHRvIHRoYXQg Y2hhbGxlbmdlLCBpbmNsdWRpbmcgdGhlIEJlYXJlciBzY2hlbWUuDQogIA0KSSBzdWdnZXN0IHRo YXQgd2UgZXhwYW5kIHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gdGhlIHNlY3Rpb24uIFNvbWV0aGlu ZyBsaWtlOg0KDQoiVGhlIHByb2NlZHVyZXMgaW4gdGhpcyBzZWN0aW9uIGFwcGx5IHdoZW4gdGhl IFVBQyBoYXMgcmVjZWl2ZWQgYSBjaGFsbGVuZ2UgdGhhdCBjb250YWlucyBhIEJlYXJlciBzY2hl bWUsIA0KYW5kIHRoZSBVQUMgaGFzIG9idGFpbmVkIGEgdG9rZW4gYXMgc3BlY2lmaWVkIGluIHNl Y3Rpb24gU2VjdGlvbiAyLjEuMS4iDQogIA0KPiAgICAoQnV0IG5vdGUgdGhhdCBpZiB0aGVyZSB3 ZXJlIG11bHRpcGxlIGNoYWxsZW5nZXMgd2l0aCBkaWZmZXJlbnQgc2NoZW1lcyANCj4gICAgdGhl biBpdCBtYXliZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSByZXRyeSB0aGUgcmVxdWVzdCB1c2luZyBu b24tQmVhcmVyIA0KPiAgICBjcmVkZW50aWFscy4pDQo+ICAgIA0KPiAgICBJIGRvbid0IHVuZGVy c3RhbmQgd2hhdCBkaXN0aW5jdGlvbiB5b3UgYXJlIHRyeWluZyB0byBkcmF3IGJ5IA0KPiAgICBk aXN0aW5ndWlzaGluZyB0aGUgYmVoYXZpb3IgZm9yIGNyZWF0aW5nIGEgYmluZGluZyBmcm9tIHRo YXQgZm9yIA0KPiAgICByZWZyZXNoaW5nIGEgYmluZGluZy4gQUZBSUsgdGhlcmUgc2hvdWxkIGJl IG5vIGRpZmZlcmVuY2UuIEFuZCBpbiBmYWN0IA0KPiAgICB0aGUgVUFDIGluIGdlbmVyYWwgY2Fu bm90IGtub3cgd2hldGhlciB0aGUgcmVxdWVzdCBiZWluZyBzZW5kIHdpbGwgDQo+ICAgIGVzdGFi bGlzaCBvciByZWZyZXNoIGEgYmluZGluZy4NCiAgDQpJdCBpcyBpbXBvcnRhbnQgdG8gcG9pbnQg b3V0IHRoYXQgdGhlIHNhbWUgYWNjZXNzIHRva2VuIG1pZ2h0IG5vdCBuZWNlc3NhcmlseSBiZSB1 c2VkIHRocm91Z2hvdXQgdGhlIGxpZmV0aW1lIG9mIHRoZSByZWdpc3RyYXRpb24sIGlmIHRoZSBw cmV2aW91c2x5IGluY2x1ZGVkIGFjY2VzcyB0b2tlbiBoYXMgZXhwaXJlZC4NCg0KLS0tDQogDQo+ ICAgICogU2VjdGlvbiAyLjEuNToNCj4gICAgDQo+ICAgIFRoaXMgc2VjdGlvbiBoYXMgc2ltaWxh ciBpc3N1ZXMgdG8gc2VjdGlvbiAyLjEuNDogVGhlIE1VU1QgaXMgdG9vIA0KPiAgICBzdHJvbmcs IGFuZCB0aGUgcmVhc29uIGZvciBkaXN0aW5ndWlzaGluZyBiZXR3ZWVuIGluLWRpYWxvZyByZXF1 ZXN0cyANCj4gICAgZnJvbSBvdGhlcnMgaXMgdW5jbGVhci4NCiAgDQpTZWUgbXkgY29tbWVudHMg Zm9yIDIuMS40Lg0KDQotLS0NCg0KPiAgICAqIFNlY3Rpb24gMi4yOg0KPiAgICANCj4gICAgQWdh aW4gaXMgb3Zlcmx5IHN0cm9uZyBpbiBpdHMgdXNlIG9mIE1VU1QuIEkgdGhpbmsgaXQgaXMgZXZp ZGVudCB0aGF0IA0KPiAgICB0aGUgcG9pbnQgYmVpbmcgbWFkZSBpcyB0aGF0IGEgY2hhbGxlbmdl IGNvbnRhaW5pbmcgQmVhcmVyIHNjaGVtZSBpcyB0aGUgDQo+ICAgIHdheSB0byBpbmRpY2F0ZSB0 aGF0IGlzIHdpdGggYSBjaGFsbGVuZ2Ugd2l0aCBCZWFyZXIgc2NoZW1lLCBidXQgdGhlIA0KPiAg ICB0ZXh0IGlzIGF0IGxlYXN0IGF3a3dhcmQuDQo+ICAgIA0KPiAgICBIb3cgYWJvdXQ6DQo+ICAg IA0KPiAgICAgICAgV2hlbiBhIFVBUyBvciBSZWdpc3RyYXIgcmVjZWl2ZXMgYSByZXF1ZXN0IHRo YXQgZmFpbHMgdG8gY29udGFpbg0KPiAgICAgICAgYXV0aG9yaXphdGlvbiBjcmVkZW50aWFscyBh Y2NlcHRhYmxlIHRvIGl0LCBpdCBTSE9VTEQgY2hhbGxlbmdlIHRoZQ0KPiAgICAgICAgcmVxdWVz dCBieSBzZW5kaW5nIGEgNDAxIChVbmF1dGhvcml6ZWQpIHJlc3BvbnNlLiBUbyBpbmRpY2F0ZSB0 aGF0DQo+ICAgICAgICBpdCBpcyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBPQXV0aDIgdG9rZW4gYXMg YSBjcmVkZW50aWFsIHRoZQ0KPiAgICAgICAgVUFTL1JlZ2lzdHJhciBNVVNUIGluY2x1ZGUgYSBQ cm94eS1BdXRoZW50aWNhdGlvbiBoZWFkZXIgZmllbGQgaW4gdGhlDQo+ICAgICAgICByZXNwb25z ZSwgaW5kaWNhdGUgIkJlYXJlciIgc2NoZW1lIGFuZCBpbmNsdWRlIGFuIGFkZHJlc3Mgb2YgYW4N Cj4gICAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIGZyb20gd2hpY2ggdGhlIG9yaWdpbmF0b3Ig Y2FuIG9idGFpbiBhbiBhY2Nlc3MNCj4gICAgICAgIHRva2VuLg0KICANCldGTS4NCiAgDQo+ICAg IEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoLCBwbGVhc2UgcHJvdmlkZSBhIHJlZmVyZW5jZToNCj4g ICAgDQo+ICAgICAgICAuLi4gdXNpbmcgdGhlIHByb2NlZHVyZXMgZnJvbSBbUkZDPz8/XSBhc3Nv Y2lhdGVkIHdpdGggdGhlIHR5cGUgb2YNCj4gICAgICAgIGFjY2VzcyB0b2tlbiB1c2VkLg0KICAN Ck9rLg0KDQotLS0NCiAgDQo+ICAgICogU2VjdGlvbiAyLjM6DQo+ICAgIA0KPiAgICBTaW1pbGFy IGNvbW1lbnQgdG8gc2VjdGlvbiAyLjIuIEhvdyBhYm91dCB0aGUgZm9sbG93aW5nIGZvciB0aGUg Zmlyc3QgDQo+ICAgIHBhcmFncmFwaDoNCj4gICAgDQo+ICAgICAgICBXaGVuIGEgcHJveHkgcmVj ZWl2ZXMgYSByZXF1ZXN0IHRoYXQgZmFpbHMgdG8gY29udGFpbg0KPiAgICAgICAgYXV0aG9yaXph dGlvbiBjcmVkZW50aWFscyBhY2NlcHRhYmxlIHRvIGl0LCBpdCBTSE9VTEQgY2hhbGxlbmdlIHRo ZQ0KPiAgICAgICAgcmVxdWVzdCBieSBzZW5kaW5nIGEgNDA3IChQcm94eSBBdXRoZW50aWNhdGlv biBSZXF1aXJlZCkgcmVzcG9uc2UuDQo+ICAgICAgICBUbyBpbmRpY2F0ZSB0aGF0IGl0IGlzIHdp bGxpbmcgdG8gYWNjZXB0IGFuIE9BdXRoMiB0b2tlbiBhcyBhDQo+ICAgICAgICBjcmVkZW50aWFs IHRoZSBwcm94eSBNVVNUIGluY2x1ZGUgYSBQcm94eS1BdXRoZW50aWNhdGlvbg0KPiAgICAgICAg aGVhZGVyIGZpZWxkIGluIHRoZSByZXNwb25zZSwgaW5kaWNhdGluZyAiQmVhcmVyIiBzY2hlbWUg YW5kDQo+ICAgICAgICBpbmNsdWRpbmcgYW4gYWRkcmVzcyB0byBhbiBBdXRob3JpemF0aW9uIFNl cnZlciBmcm9tIHdoaWNoIHRoZQ0KPiAgICAgICAgb3JpZ2luYXRvciBjYW4gb2J0YWluIGFuIGFj Y2VzcyB0b2tlbi4NCiAgDQpXRk0uDQoNCj4gICAgSSBkb24ndCB0aGluayB0aGUgc2Vjb25kIHBh cmFncmFwaCBzaG91bGQgY29uZGl0aW9uIGFueSBiZWhhdmlvciBvbiANCj4gICAgd2hldGhlciBp dCBoYXMgcHJldmlvdXNseSBjaGFsbGVuZ2VkLiBUaGF0IHJlcXVpcmVzIHRoYXQgdGhlIHByb3h5 IGJlIA0KPiAgICBzdGF0ZWZ1bCwgYW5kIGl0IGlzbid0IGEgbmVjZXNzYXJ5IGNvbmRpdGlvbi4g SW5zdGVhZCwgaG93IGFib3V0Og0KPiAgICANCj4gICAgICAgIFdoZW4gYSBwcm94eSB3aXNoZXMg dG8gYXV0aGVudGljYXRlIGEgcmVjZWl2ZWQgcmVxdWVzdCwgaXQgTVVTVA0KPiAgICAgICAgc2Vh cmNoIHRoZSByZXF1ZXN0IGZvciBQcm94eS1BdXRob3JpemF0aW9uIGhlYWRlciBmaWVsZHMgd2l0 aCAncmVhbG0nDQo+ICAgICAgICBwYXJhbWV0ZXJzIHRoYXQgbWF0Y2ggaXRzIHJlYWxtLiBJdCB0 aGVuIE1VU1Qgc3VjY2Vzc2Z1bGx5IHZhbGlkYXRlDQo+ICAgICAgICB0aGUgY3JlZGVudGlhbHMg ZnJvbSBhdCBsZWFzdCBvbmUgUHJveHktQXV0aG9yaXphdGlvbiBoZWFkZXIgZmllbGQNCj4gICAg ICAgIGZvciBpdHMgcmVhbG0uIFdoZW4gdGhlIHNjaGVtZSBpcyBCZWFyZXIgdGhlIHByb3h5IE1V U1QgdmFsaWRhdGUgdGhlDQo+ICAgICAgICBhY2Nlc3MgdG9rZW4sIHVzaW5nIHRoZSBwcm9jZWR1 cmVzIGZyb20gW1JGQz8/P10gYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiAgICAgICAgdHlwZSBvZiBh Y2Nlc3MgdG9rZW4gdXNlZC4NCiAgDQpXRk0uDQoNCi0tLQ0KDQo+ICAgICogU2VjdGlvbiAzOg0K PiAgICANCj4gICAgVGhlIGZvbGxvd2luZzoNCj4gICAgDQo+ICAgICAgICBUaGUgcmVhbG0gYW5k IGF1dGgtcGFyYW0gcGFyYW1ldGVycyBhcmUgZGVmaW5lZCBpbiBbUkZDMzI2MV0uDQo+ICAgIA0K PiAgICBpcyBpbmNvbXBsZXRlLCBiZWNhdXNlIGl0IGlzIG1pc3NpbmcgJ2NoYWxsZW5nZScsICdy ZWFsbScsIGFuZCANCj4gICAgJ2h0dHBzLVVSSS4gKFdoZXJlIGlzIGh0dHBzLVVSSSBkZWZpbmVk PykgDQo+DQo+IEFub3RoZXIgd2F5IHRvIGRvIHRoaXMgaXMgYnkgIGFkZGluZyB0aGUgZm9sbG93 aW5nIHRvIHRoZSBzeW50YXg6DQo+ICAgIA0KPiAgICAgICAgICAgIGNoYWxsZW5nZSA9IDxkZWZp bmVkIGluIFJGQzMyNjE+DQo+ICAgICAgICAgICAgcmVhbG0gPSA8ZGVmaW5lZCBpbiBSRkMzMjYx Pg0KPiAgICAgICAgICAgIGF1dGgtcGFyYW0gPSA8ZGVmaW5lZCBpbiBSRkMzMjYxPg0KPiAgICAg ICAgICAgIHNjb3BlID0gPGRlZmluZWQgaW4gUkZDNjc0OT4NCj4gICAgICAgICAgICBlcnJvciA9 IDxkZWZpbmVkIGluIFJGQzY3NDk+DQo+ICAgICAgICAgICAgaHR0cHMtVVJJID0gPHdoZXJlPz8/ Pg0KPiAgICANCj4gICAgKFRoaXMgaGVscHMgdGhvc2Ugd2hvIG1pZ2h0IHRyeSB0byBmb3JtYWxs eSB2YWxpZGF0ZSB0aGUgc3ludGF4IGJlY2F1c2UgDQo+ICAgIGl0IHJlbW92ZXMgdW5kZWZpbmVk IHBhcmFtZXRlcnMuKQ0KDQpUaGUgc2VjdGlvbiBkb2VzIGVuaGFuY2UgJ2NoYWxsZW5nZScsIHNv IEkgZ3Vlc3Mgd2UgY2FuIGFkZCB0ZXh0IHNheWluZyB0aGF0ICdjaGFsbGVuZ2UnIGlzIGRlZmlu ZWQgaW4gUkZDIDMyNjEuDQoNClJlZ2FyZGluZyB0aGUgb3RoZXIgcGFyYW1ldGVycywgdGhlIHRl eHQgYWxyZWFkeSBzYXlzIHdoZXJlIHRoZXkgYXJlIGRlZmluZWQuDQoNCk9yLCBhcmUgeW91IHNh eWluZyB0aGF0IHlvdSB3YW50IHRoZSByZWZlcmVuY2VzIGluIHRoZSBzeW50YXgsIHJhdGhlciB0 aGFuIGluIHRoZSBub3JtYXRpdmUgdGV4dD8NCg0KPiAgICBBbHNvLCAnc2NvcGUnIGFuZCAnZXJy b3InIGFyZSB2ZXJ5IGdlbmVyaWMgcnVsZSBuYW1lcyBiZWluZyB1c2VkIGluIGEgDQo+ICAgIHZl cnkgcmVzdHJpY3RlZCBjb250ZXh0LiBXaGlsZSB0aGVzZSBhcmUgbm90IGRlZmluZWQgaW4gUkZD MzI2MSwgdGhlcmUgDQo+ICAgIGlzIHRoZSBwb3RlbnRpYWwgY29uZmxpY3Qgd2l0aCBvdGhlciBl eHRlbnNpb25zLiBJJ2QgcmVjb21tZW5kIHVzaW5nIA0KPiAgICBtb3JlIHNwZWNpZmljIHRlcm1z LiBFLmcuLA0KPiAgICANCj4gICAgICAgICAgICBjaGFsbGVuZ2UgID0vICAoIkJlYXJlciIgTFdT IGJlYXJlci1jbG4gKihDT01NQSBiZWFyZXItY2xuKSkNCj4gICAgICAgICAgICBiZWFyZXItY2xu ID0gcmVhbG0gLyBiZWFyZXItc2NvcGUgLyBhdXRoei1zZXJ2ZXIgLyBiZWFyZXItZXJyb3IgLw0K PiAgICAgICAgICAgICAgICAgICAgICAgICBhdXRoLXBhcmFtDQo+ICAgICAgICAgICAgYXV0aHot c2VydmVyID0gImF1dGh6X3NlcnZlciIgRVFVQUwgYXV0aHotc2VydmVyLXZhbHVlDQo+ICAgICAg ICAgICAgYXV0aHotc2VydmVyLXZhbHVlID0gaHR0cHMtVVJJDQo+DQo+ICAgICAgICAgICAgY2hh bGxlbmdlID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCj4gICAgICAgICAgICByZWFsbSA9IDxkZWZp bmVkIGluIFJGQzMyNjE+DQo+ICAgICAgICAgICAgYXV0aC1wYXJhbSA9IDxkZWZpbmVkIGluIFJG QzMyNjE+DQo+ICAgICAgICAgICAgYmVhcmVyLXNjb3BlID0gPGRlZmluZWQgYXMgc2NvcGUgaW4g UkZDNjc0OT4NCj4gICAgICAgICAgICBiZWFyZXItZXJyb3IgPSA8ZGVmaW5lZCBhcyBlcnJvciBp biBSRkM2NzQ5Pg0KPiAgICAgICAgICAgIGh0dHBzLVVSSSA9IDx3aGVyZT8/Pz4NCg0KVGhlIEhU VFAgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgZmllbGQgdXNlcyAnZXJyb3InIGFuZCAnc2NvcGUn LCBhbmQgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGJlIGFsaWduZWQuDQogIA0KPiAgICBS ZWdhcmRpbmcgdGhlIHNjb3BlIHBhcmFtZXRlcjoNCj4gICAgDQo+ICAgIFRoaXMgcGFyYW1ldGVy IGlzIGNvbnZleWVkIGZyb20gdGhlIHJlZ2lzdHJhciB0byB0aGUgVUFDLiBCdXQgd2hhdCBpcyAN Cj4gICAgdGhlIFVBQyB0byBkbyB3aXRoIGl0PyBIb3cgZG9lcyBpdCBoYXZlIGFueSBjb250cm9s IG92ZXIgdGhlIHNjb3BlIG9mIA0KPiAgICB0aGUgdG9rZW4gaXQgZ2V0cyBmcm9tIHRoZSBBUz8g SXMgdGhlIFVBQyBzdXBwb3NlZCB0byBjb252ZXkgdGhpcyB0byB0aGUgDQo+ICAgIEFTPyBJZiBz bywgaG93Pw0KICANClRoZSBVQUMgd2lsbCBnZXQgdGhlIHNjb3BlIGZyb20gdGhlIEFTLCBhbmQg d2lsbCBmb3J3YXJkIGl0IHRvd2FyZHMgdGhlIFVBUy9yZWdpc3RyYXIuDQogIA0KPiAgICBSZWdh cmRpbmcgdGhlIGVycm9yIHBhcmFtZXRlcjoNCj4gICAgDQo+ICAgIElzIHRoaXMganVzdCBpbnRl bmRlZCB0byBiZSBvZiBoZWxwIGluIGRlYnVnZ2luZyB0aGUgVUFDPyBPciBpcyBpdCANCj4gICAg ZXhwZWN0ZWQgdGhhdCB0aGUgVUFDIG1pZ2h0IHRha2Ugc29tZSBzb3J0IG9mIHByZS1wcm9ncmFt bWVkIGFjdGlvbiBpbiANCj4gICAgcmVzcG9uc2U/IElmIHRoZSBsYXR0ZXIsIGhvdyBtaWdodCB0 aGF0IHdvcms/IElzIHRoaXMgaW5mb3JtYXRpb24gDQo+ICAgIHN1aXRhYmxlIGZvciBwcmVzZW50 YXRpb24gdG8gdGhlIHVzZXI/DQogIA0KSSBzZWUgbm8gcmVhc29uIHdoeSBpdCBjYW4ndCBiZSBw cmVzZW50ZWQgdG8gdGhlIHVzZXIsIGFuZCBJIGd1ZXNzIHRoZSBVQUMgYWN0aW9ucyBkZXBlbmQg b24gd2hhdCB0aGUgZXJyb3IgY29kZSBpcy4NCg0KSG93ZXZlciwgYXMgdGhlIHBhcmFtZXRlciBp cyBkZXNjcmliZWQgaW4gUkZDIDY3NDksIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byByZXBlYXQg dGhhdCBpbiB0aGlzIGRyYWZ0Lg0KDQotLS0NCiAgDQo+ICAgICogU2VjdGlvbiA0Og0KPiAgICAN Cj4gICAgSSBhZ3JlZSB3aXRoIERhbGUgLSBJIGRvbid0IHNlZSBhbnkgdmFsdWUgaW4gdGhpcyB0 YWcuIEkgdHJpZWQgdG8gc2VhcmNoIA0KPiAgICBmb3IgYWxsIGRpc2N1c3Npb24gb24gdGhlIHBv aW50LiBUaGUgZGlzY3Vzc2lvbiBhdHRyaWJ1dGVzIG1lIHdpdGggDQo+ICAgIHJlcXVlc3Rpbmcg aXQsIGJ1dCBJIGRvbid0IHRoaW5rIEkgZGlkLg0KICANCkl0IHdhcyBPbGxlIHdobyByZXF1ZXN0 ZWQgaXQuDQoNCkhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIGFueSBoYXJtIGluIGhhdmluZyBpdC4gSXQg YWxsb3dzIHRoZSBVQUMgdG8gaW5mb3JtIHByb3hpZXMvVUFTL1JlZ2lzdHJhciB3aGV0aGVyIGl0 IHN1cHBvcnRzIHRoZSBiZWFyZXIgc2NoZW1lLg0KDQotLS0NCg0KPiAgICAqIE1pc3Npbmc6DQo+ ICAgIA0KPiAgICBJIGZpbmQgbm8gc3ludGF4IGV4dGVuc2lvbnMgZm9yIEF1dGhvcml6YXRpb24g YW5kIFByb3h5LUF1dGhvcml6YXRpb24uIA0KPiAgICBUaGVzZSBuZWVkIHRvIGJlIGFkZGVkLg0K ICANCk9rLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQogDQoNCg== From nobody Wed Dec 4 05:53: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 CF86512012E; Wed, 4 Dec 2019 05:53:39 -0800 (PST) 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 vXsbNdd1jY8J; Wed, 4 Dec 2019 05:53:37 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130078.outbound.protection.outlook.com [40.107.13.78]) (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 0EF561200FE; Wed, 4 Dec 2019 05:53:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HyWtJwn0UqElDzqWPgkos2NijY8N7jihyKRezy9rsLCF+W1eXs78fe15VveVxwlwSSLM9HhJTyCNA09lvRRdDAzmwQAeGaFbQ14g4+BGnHuiyiyBIMd6jEsxSnOMrtLXFHQrV4pLvJxFM2dyDvpyGvR8zrhgnclvjwMHxU2h/vw3UyUmMVMXW6jZswaCWdcjv2+V6Ffmc2jwkw+DXDRHePw3i9/64JNFfbOlyPNNa+oZgdNbYVFdM1qYMb/xzEIEz5xuIk5HlqqG5EiprJ4EJvFMl6V7d2wMsoWasQdY0DcOauaZv1VZXnE+pJ4roikPtgM166sulFninFDm30LUIw== 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=b6CA/rLm5pMxz79P0sVtgKGUJ+Crqtc2HWprxxuY6+M=; b=ED1ageqADfV61kOafAm1S7Wfh2HafZwTVSkyB8HFmXmoB+X5Zh45zF8OgsFkjhB62aXgQ6oZHINLvzGp0ahcbeC0GqYtYnT1pCNqjn2URIHEd8JTXe8k+/tmzGuiSzUHskkqGAgIo07uxrpTnq7eiKOWOWBXhDE3bPMhJWIWawR4/9P5LcG8Y2FfjcS8PZl8EKVrpLbf6mxZ1HGskmqwb5z/XZDvih8j2psYyJeX2Y9UxdJebMMDmghLYNwU6Z7weqp8FH1p4OfhfzwSODEEbmgMPXa1jCH3RCFq0TNvj0A/HmsXzdTpep+kU9uVZYOZjH+vusXu4ruSqv23nM9g1g== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b6CA/rLm5pMxz79P0sVtgKGUJ+Crqtc2HWprxxuY6+M=; b=aToStxDr+pVPN7dlwPtzSY6e8R+goy0vW4X3t5Bv2PSyRVIFE2QWynmXZaadwz8WS+r+F+1zTvF0fALEQqMzLWdX40yu51IKFpDVK6rhdmO6cg+PWKDniP3+FMNfh6Yb6D3Id1UM8+dD+XkpBSD0MV8dJBTCUmViorRsraPZhlw= Received: from HE1PR0701MB2220.eurprd07.prod.outlook.com (10.168.29.21) by HE1PR0701MB2763.eurprd07.prod.outlook.com (10.168.183.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.4; Wed, 4 Dec 2019 13:53:32 +0000 Received: from HE1PR0701MB2220.eurprd07.prod.outlook.com ([fe80::85d5:508d:307a:9b52]) by HE1PR0701MB2220.eurprd07.prod.outlook.com ([fe80::85d5:508d:307a:9b52%10]) with mapi id 15.20.2516.003; Wed, 4 Dec 2019 13:53:32 +0000 From: =?iso-8859-1?Q?J=F6rgen_Axell?= To: "A. Jean Mahoney" , SIPCORE , "draft-ietf-sipcore-sip-token-authnz@ietf.org" Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Thread-Index: AQHVqRaqTae6oxQspkiKpJW4SbhNwqep+n8w Date: Wed, 4 Dec 2019 13:53:32 +0000 Message-ID: References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> In-Reply-To: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorgen.axell@ericsson.com; x-originating-ip: [81.229.17.163] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22703688-5f7a-4ab6-9a62-08d778c159cc x-ms-traffictypediagnostic: HE1PR0701MB2763: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(39860400002)(346002)(396003)(13464003)(199004)(189003)(53754006)(99286004)(74316002)(7736002)(305945005)(5660300002)(2906002)(7696005)(8676002)(76176011)(66446008)(64756008)(66556008)(81166006)(66946007)(81156014)(3846002)(6116002)(66476007)(52536014)(76116006)(8936002)(9686003)(71190400001)(71200400001)(966005)(55016002)(14454004)(6506007)(53546011)(6436002)(102836004)(2501003)(478600001)(6246003)(86362001)(25786009)(11346002)(316002)(110136005)(229853002)(26005)(33656002)(186003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2763; H:HE1PR0701MB2220.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: BCL:0; x-microsoft-antispam-message-info: aZbS5AjJX3H7BUZ6DeO4+UbVGs4QO7ghenYlscuKQiwkx9clZwBi2zj9JDmD7bArGNxhJM5RowthyJYD7GQr+EOF9C8EFihGDr7FQvXxYOWctBiHnsTr33NCyNw+M7Tep9Wg0Q+k2RMS8YBA8Kt4ZIBMVxXp59ALC1UTioxbLQfjhAOdm1QiOg3fItli2gRj4RAVuGaVBCiwPwcBFgel+KETLTX3pX8hk8RkxkzhTn4zhYLE/QcxkP3XVx61nsOALaQtRx9BmhTHkZx9Z6+IwVXXcVjDYVjOgFDwOOEQ3xW7atNAoKyS+QGgmjdmrQ1+FgYz0yfrSKMbpFhaX590M8TbfYFI13G8F89B126xUsQwHgxMhQLZ50F6ttzQfAK3NIjL6NFKWCJDJI20A+5UZL+n4s6oSh1z1FIVZKHEbTi8NGx06nQJguQFpGoqwDba2tIkS0YhOcQ/Uy+13zKXW4V58DlsyWvfkpF32gbT18XAB92vtUW86iDGvnXBVrqed34dY2llfwCXZ4gNyjMNsPJT8f86/UuGLl4kWiGGsI9tmnp0A+xnVl7XUoh+RvK5 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22703688-5f7a-4ab6-9a62-08d778c159cc X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2019 13:53:32.4607 (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: tcnp4jHmt5sB8EmTRhNblUbjjLluD4xabbo/S1W2d/zpFzCMLuGJcemPIYYHQQLOahw+33lZPd6RkT8BaJm1+ybYdWDBfsJrMMykGO5MacU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2763 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 04 Dec 2019 13:53:40 -0000 A few nits: 1.2: Second bullet: maintainings-->maintaining 2.1.1: shouldn't "out of scope for" be "out of scope of"? 2.1.3: this specifications--> this specification 2.1.4: Authorization headerf-->Authorization header 2.2: end of first para, from there-->from where 2.3: same as 2.2 3: In BNF we have authz-server parameters. Shouldn't this be authz-server-v= alue? 5.1: The figure belows show--> The figure below shows below the figure: autentication-->authentication 5.2: The figure belows as above. Regards, J=F6rgen -----Original Message----- From: sipcore On Behalf Of A. Jean Mahoney Sent: den 2 december 2019 14:45 To: SIPCORE ; draft-ietf-sipcore-sip-token-authnz@ietf.or= g Subject: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Hi all, Today starts the Working Group Last Call of draft-ietf-sipcore-sip-token-au= thnz-06. https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ The document has changed quite a bit since its predecessor went through WGL= C. Please review. If you submitted feedback on a previous version, make sure = that it was addressed and your questions answered. Also appreciated would be any information on implementation plans. WGLC ends Monday, Dec 16. Thanks! Jean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 4 21:24: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 73074120947; Wed, 4 Dec 2019 21:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ToEqjqXmXq6r; Wed, 4 Dec 2019 21:24:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E5E1200BA; Wed, 4 Dec 2019 21:24:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 83D8CF40724; Wed, 4 Dec 2019 21:24:31 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sipcore@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20191205052431.83D8CF40724@rfc-editor.org> Date: Wed, 4 Dec 2019 21:24:31 -0800 (PST) Archived-At: Subject: [sipcore] =?utf-8?q?RFC_8688_on_A_Session_Initiation_Protocol_?= =?utf-8?q?=28SIP=29_Response_Code_for_Rejected_Calls?= 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, 05 Dec 2019 05:24:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8688 Title: A Session Initiation Protocol (SIP) Response Code for Rejected Calls Author: E.W. Burger, B. Nagda Status: Standards Track Stream: IETF Date: December 2019 Mailbox: eburger@standardstrack.com, nagdab@gmail.com Pages: 22 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-rejected-09.txt URL: https://www.rfc-editor.org/info/rfc8688 DOI: 10.17487/RFC8688 This document defines the 608 (Rejected) Session Initiation Protocol (SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Dec 7 02:37: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 52276120178; Sat, 7 Dec 2019 02:37:52 -0800 (PST) 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 C_D7UbTicXZA; Sat, 7 Dec 2019 02:37:50 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10061.outbound.protection.outlook.com [40.107.1.61]) (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 91B59120142; Sat, 7 Dec 2019 02:37:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JfvetYqYThcru256jEm+q8vC0L4tADKE1TkNhA0BLqiLNuO3NILYwZ6gDHE28JSigdc+qLR3iSsiOk3REwh2gXHKe21Q1uywMjl6Hq8XY/8Q54ihTpIyb2vPfz/aoCJb0YvMWOAVAnLgZD/YkA4eFW6cn1iecbXrCmcGjqaVTb8JoeqVWL47NKLCt4Nx18xgfkMYrRtU7OFmarJNA/DKhE/WWjEUEe/i0v0OoTeZWWmMkQvZ3X5cQCS7JPEja/m+NIepbvHM4wzdQFO1kFMzgQZnHtzHn+xUHQgsNeJ59VOAVEhXx/Lwymm8ZElJd+c+sxaXVIklnxjQ1/DkjZi3Mg== 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=y3I60bgmtpimyT1fnFLwlLab8H9ASJEqZfvucexegtg=; b=XWtbEo2OFvgEWZMlZVKdO5eXQbKp8Bl2M2fM8+dxQBVZAqrbyTZT+zBG5SGjeIj/FVW9lwVffn2HONnBzgz5qZFKc1KMQEK8jc7n9xzNe9WsyqkMD8heH6VDKNSDKOShj9CHFsH98txgZv8W5Nhcgw2gRMwZZBeJhWItVLjuJHPo5r7J9EdK3w4zGISuGKYP8R2MLhH3rhBA4WE3B2x1h+zFpndEu8wpZihcHw8bvrEnEJuFeRf/2zzKtK00r1lw2VSG86n3l/mF61ZJQkqwRgBTP682EHVkw4ZeYjiglbXr+XeN022RTG7topEq/w76j4zMavUetRKJZ/Ac7MLVJA== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y3I60bgmtpimyT1fnFLwlLab8H9ASJEqZfvucexegtg=; b=J51rdYr1+9+plbo+G1ccNLn6Ka2dO5fNFIWZhNWbE0/zornVzpB2g6wVFFbeXRGU365tkgMTRZDHvttc3QRVo+Ow9ZjKJeei2sZ5e5ooQBd6D4fqar7HMtkx5onmuVJU7mLyjEH0nksvsUuBIo7+3zQqa7GdWyU5AA+yO7X9Zj0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3227.eurprd07.prod.outlook.com (10.170.247.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.9; Sat, 7 Dec 2019 10:37:47 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::2ca9:414:cc01:9706%4]) with mapi id 15.20.2516.003; Sat, 7 Dec 2019 10:37:47 +0000 From: Christer Holmberg To: =?iso-8859-1?Q?J=F6rgen_Axell?= , "A. Jean Mahoney" , SIPCORE , "draft-ietf-sipcore-sip-token-authnz@ietf.org" Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Thread-Index: AQHVqRaq+n57bvgHbkmAxusa4398hqeqAkAAgASAJHo= Date: Sat, 7 Dec 2019 10:37:46 +0000 Message-ID: References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.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: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0bb28253-cbd1-4def-3bff-08d77b018015 x-ms-traffictypediagnostic: HE1PR07MB3227: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0244637DEA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(189003)(199004)(53754006)(13464003)(8676002)(8936002)(81166006)(81156014)(86362001)(76116006)(102836004)(966005)(478600001)(33656002)(186003)(19627405001)(76176011)(53546011)(26005)(5660300002)(74316002)(44832011)(229853002)(55016002)(52536014)(54896002)(66946007)(6506007)(9686003)(66556008)(64756008)(7696005)(66446008)(66476007)(99286004)(2906002)(110136005)(71190400001)(316002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3227; 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: BCL:0; x-microsoft-antispam-message-info: SUomY+FxjAeFp7KlI0DwcWKfc2d58R1LVXb28E7HCy6n6lSQjtGQjktR9XwduEsZBq6xcaApAtkojIqb/6PG2tIIv6oilwUTfqyzNpLL/CKwzB0mM/IKFEPwVC9WyGJHcvN0bu2dUeIpSU1wAvVvQctzNQ1oSQCuBxiHG+y9HlV0IZi54h9ZKlPr/6/q30pNbqaCO2zPY086WdOkQTNtRK+zwWtcS2bp77hB+aqqiMgOeJ4oA7sVsoYBfin9ZCY7S4CICu6ZwATU4yG33P0ZsbQYGopbpQEnZuC99w4GCoJKbJeTR0zrkV9gp1GuoutTwwn1G6T9Oo9c5gVdFPVv8rK4iTaLVdkhGnwgsgjY99kkex7R6C+SNWGKOeMWsmSMZGoX3kolMJcxZ6h2QKEe3+wJtM2IosiWYeC+QPiwQszoY6pwjcXdXkUiYFiSWsrhTMSC5nwIcHjrgK2/8F9nV/QEr3/CtATqW5FeoN2w2jic4sc+LsJDQBdZqPDUfnIo/ARzPGKbFdxIaXG8SvukzOvB0OI6bJda8zErYcVMDjQ6qfYerc4Sbn83HFEZUni7 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161FFC1ABF4F2757C85CDB5935E0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0bb28253-cbd1-4def-3bff-08d77b018015 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2019 10:37:46.8944 (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: vXhKt0WExsHsEqK/dvS5lePj9hT3Z94AzCvivwJMhTY3lQM8QRVqBupAfCWSXv2ZxGOAO5xNWEmhzvRIesuV/uYScE7j58yA4ES4VeT5/P4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3227 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 07 Dec 2019 10:37:52 -0000 --_000_HE1PR07MB3161FFC1ABF4F2757C85CDB5935E0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi J=F6rgen, Thanks for your feedback! We will do the fixes as suggested. Regards, Christer ________________________________ From: sipcore on behalf of J=F6rgen Axell Sent: Wednesday, December 4, 2019 3:53 PM To: A. Jean Mahoney ; SIPCORE ; draf= t-ietf-sipcore-sip-token-authnz@ietf.org Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz A few nits: 1.2: Second bullet: maintainings-->maintaining 2.1.1: shouldn't "out of scope for" be "out of scope of"? 2.1.3: this specifications--> this specification 2.1.4: Authorization headerf-->Authorization header 2.2: end of first para, from there-->from where 2.3: same as 2.2 3: In BNF we have authz-server parameters. Shouldn't this be authz-server-v= alue? 5.1: The figure belows show--> The figure below shows below the figure: autentication-->authentication 5.2: The figure belows as above. Regards, J=F6rgen -----Original Message----- From: sipcore On Behalf Of A. Jean Mahoney Sent: den 2 december 2019 14:45 To: SIPCORE ; draft-ietf-sipcore-sip-token-authnz@ietf.or= g Subject: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Hi all, Today starts the Working Group Last Call of draft-ietf-sipcore-sip-token-au= thnz-06. https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ The document has changed quite a bit since its predecessor went through WGL= C. Please review. If you submitted feedback on a previous version, make sure = that it was addressed and your questions answered. Also appreciated would be any information on implementation plans. WGLC ends Monday, Dec 16. Thanks! Jean _______________________________________________ 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 --_000_HE1PR07MB3161FFC1ABF4F2757C85CDB5935E0HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi J=F6rgen,

Thanks for your feedback! We will do the fixes as suggested.

Regards,

Christer


From: sipcore <sipcore-b= ounces@ietf.org> on behalf of J=F6rgen Axell <jorgen.axell=3D40ericss= on.com@dmarc.ietf.org>
Sent: Wednesday, December 4, 2019 3:53 PM
To: A. Jean Mahoney <mahoney@nostrum.com>; SIPCORE <sipcore= @ietf.org>; draft-ietf-sipcore-sip-token-authnz@ietf.org <draft-ietf-= sipcore-sip-token-authnz@ietf.org>
Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz
 
A few nits:
1.2: Second bullet: maintainings-->maintaining
2.1.1: shouldn't "out of scope for" be "out of scope of"= ;?
2.1.3: this specifications--> this specification
2.1.4: Authorization headerf-->Authorization header
2.2: end of first para, from there-->from where
2.3: same as 2.2
3: In BNF we have authz-server parameters. Shouldn't this be authz-server-v= alue?
5.1: The figure belows show--> The figure below shows
below the figure: autentication-->authentication
5.2: The figure belows as above.

Regards,
J=F6rgen
-----Original Message-----
From: sipcore <sipcore-bounces@ietf.org> On Behalf Of A. Jean Mahoney=
Sent: den 2 december 2019 14:45
To: SIPCORE <sipcore@ietf.org>; draft-ietf-sipcore-sip-token-authnz@i= etf.org
Subject: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz

Hi all,

Today starts the Working Group Last Call of draft-ietf-sipcore-sip-token-au= thnz-06.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz= /

The document has changed quite a bit since its predecessor went through WGL= C.

Please review.  If you submitted feedback on a previous version, make = sure that it was addressed and your questions answered.

Also appreciated would be any information on implementation plans.

WGLC ends Monday, Dec 16.

Thanks!

Jean

_______________________________________________
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
--_000_HE1PR07MB3161FFC1ABF4F2757C85CDB5935E0HE1PR07MB3161eurp_-- From nobody Sun Dec 8 04:29: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 A595412007A for ; Sun, 8 Dec 2019 04:29:44 -0800 (PST) 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 HJilzO-wRx9Y for ; Sun, 8 Dec 2019 04:29:42 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 3EA7912000F for ; Sun, 8 Dec 2019 04:29:42 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id g12so10300595ild.2 for ; Sun, 08 Dec 2019 04:29:42 -0800 (PST) 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=c44UkKNHKSum9dQabA87pc8yZAKR++9BNDxoHbCr8k8=; b=Cuqh/2pni48F49cju+L7AdNWo9C/jvjtNWz/S0UhEpgCvNZ7/xC+7II/5/tV9sLGiq f8HNxdFVP6io7jC4WYGfsLD8taVEDTySsTtA7IqWovr8y5qS26t9l0Hlr1DmFRqO+79i bYzPzMbUODjUz8Mm9+R1VneWt5eE+8DmGLd3qUdqieWJFb6qYGC6G/Do9rS9KATF4FDF 2a+AiuJt6MP/CjLkC0jDjfkVZXBgL9Fk2i42RfsGrnhwFqagpHU/0zUXQpMa7VfJxwzO OjbM1hamNr5yQb1a5tQNYsAwl9fEadbWbwfPIr2NQpnaKeXq1M2t54KHvDfvyP5dPZ1d ri3A== 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=c44UkKNHKSum9dQabA87pc8yZAKR++9BNDxoHbCr8k8=; b=O2SNgThZetVXZDqBdDn3d72rpUgBLf3qjO0d1cSqQSSCAYXqfh2N3WJEtRM5xf8GM8 Fi+QLZbNjCZa2OYkj/7dhDJu+0k9z9fIJ85J/tcpXR29UXSlOsDAREFdQAujDx6WtBv+ RIdwFUsd3KNvjSWhn9jj6VdkqyGNp16q+dHyZWABshxo5f0xPXA1oDfgaOJy9wRzmlF8 p6m9ZCY4dtCor5dZlIjKYP4JY0kzpA1rIKRSKO4xS13+Bbr5fQO4o/+N6G3asWCAxCtg Jn03IpyDnHP4SZQCbvvY39OcLMAdLQ5bV2Wr1IeqH2lNNiPEou/yX0qHaZBwY5rw+f54 OGtQ== X-Gm-Message-State: APjAAAWVjGFYBHirbbiHCJanqG64HGPwd5te5E+Mij1g45hoKtre48QS vIbmCZGmQe799rqgAehk0rp9A3kgaNOGbJ0m7DrIVM+a X-Google-Smtp-Source: APXvYqwazqIM2l5Et3wpYj/MBrmZbZVKiNDitp6qS8uJ9uCVhTKNEahG0s5K5j4IJYKGC2Z1k1E2RTVIcRaFTZ0u8ps= X-Received: by 2002:a92:3984:: with SMTP id h4mr22340254ilf.36.1575808181536; Sun, 08 Dec 2019 04:29:41 -0800 (PST) MIME-Version: 1.0 References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> In-Reply-To: <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> From: Rifaat Shekh-Yusef Date: Sun, 8 Dec 2019 07:29:30 -0500 Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e50eb40599306ef2" Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 08 Dec 2019 12:29:44 -0000 --000000000000e50eb40599306ef2 Content-Type: text/plain; charset="UTF-8" Hi Paul, Thanks for the detailed review. Regarding the My problem with this is: the challenge gives the UAC an HTTPS URL of an AS. It does not normatively state how the UAC is to use this, or what usage(s) the AS MUST support. Hence there is no assurance that the UAC will be able to successfully access the AS. This could be resolved by requiring that the UAC and AS MUST support RFC8252. Or perhaps there is some more expansive RFC that can be referenced. In the end there needs to be something MTI. I think that MUST is too strong in this case. I would be fine with a SHOULD, as there are different ways to achieve this based on the type of UAC, e.g. a browser-based UAC application. Thoughts? Regarding your comment about section 2.1.2, I agree with you; I will move it to its own section. Regards, Rifaat On Wed, Dec 4, 2019 at 3:00 AM Christer Holmberg wrote: > Hi Paul, > > My comments on some of your SIP-related issues (I am not addressing your > issues on Sections 2.1.1 and 2.1.2 in this reply). > > > * Section 2.1.4: > > > > This section says that the UAC MUST include an Authorization header > > field with the Bearer scheme. This is overly strong. > > > > This should be an explanation that *if* it has received a challenge > > containing the Bearer scheme then to resolve that particular > challenge > > it needs to send a request with an Authorization header field > containing > > the response to that challenge, including the Bearer scheme. > > I suggest that we expand the first paragraph in the section. Something > like: > > "The procedures in this section apply when the UAC has received a > challenge that contains a Bearer scheme, > and the UAC has obtained a token as specified in section Section 2.1.1." > > > (But note that if there were multiple challenges with different > schemes > > then it maybe able to successfully retry the request using non-Bearer > > credentials.) > > > > I don't understand what distinction you are trying to draw by > > distinguishing the behavior for creating a binding from that for > > refreshing a binding. AFAIK there should be no difference. And in > fact > > the UAC in general cannot know whether the request being send will > > establish or refresh a binding. > > It is important to point out that the same access token might not > necessarily be used throughout the lifetime of the registration, if the > previously included access token has expired. > > --- > > > * Section 2.1.5: > > > > This section has similar issues to section 2.1.4: The MUST is too > > strong, and the reason for distinguishing between in-dialog requests > > from others is unclear. > > See my comments for 2.1.4. > > --- > > > * Section 2.2: > > > > Again is overly strong in its use of MUST. I think it is evident that > > the point being made is that a challenge containing Bearer scheme is > the > > way to indicate that is with a challenge with Bearer scheme, but the > > text is at least awkward. > > > > How about: > > > > When a UAS or Registrar receives a request that fails to contain > > authorization credentials acceptable to it, it SHOULD challenge > the > > request by sending a 401 (Unauthorized) response. To indicate that > > it is willing to accept an OAuth2 token as a credential the > > UAS/Registrar MUST include a Proxy-Authentication header field in > the > > response, indicate "Bearer" scheme and include an address of an > > Authorization Server from which the originator can obtain an > access > > token. > > WFM. > > > In the second paragraph, please provide a reference: > > > > ... using the procedures from [RFC???] associated with the type of > > access token used. > > Ok. > > --- > > > * Section 2.3: > > > > Similar comment to section 2.2. How about the following for the first > > paragraph: > > > > When a proxy receives a request that fails to contain > > authorization credentials acceptable to it, it SHOULD challenge > the > > request by sending a 407 (Proxy Authentication Required) response. > > To indicate that it is willing to accept an OAuth2 token as a > > credential the proxy MUST include a Proxy-Authentication > > header field in the response, indicating "Bearer" scheme and > > including an address to an Authorization Server from which the > > originator can obtain an access token. > > WFM. > > > I don't think the second paragraph should condition any behavior on > > whether it has previously challenged. That requires that the proxy be > > stateful, and it isn't a necessary condition. Instead, how about: > > > > When a proxy wishes to authenticate a received request, it MUST > > search the request for Proxy-Authorization header fields with > 'realm' > > parameters that match its realm. It then MUST successfully > validate > > the credentials from at least one Proxy-Authorization header field > > for its realm. When the scheme is Bearer the proxy MUST validate > the > > access token, using the procedures from [RFC???] associated with > the > > type of access token used. > > WFM. > > --- > > > * Section 3: > > > > The following: > > > > The realm and auth-param parameters are defined in [RFC3261]. > > > > is incomplete, because it is missing 'challenge', 'realm', and > > 'https-URI. (Where is https-URI defined?) > > > > Another way to do this is by adding the following to the syntax: > > > > challenge = > > realm = > > auth-param = > > scope = > > error = > > https-URI = > > > > (This helps those who might try to formally validate the syntax > because > > it removes undefined parameters.) > > The section does enhance 'challenge', so I guess we can add text saying > that 'challenge' is defined in RFC 3261. > > Regarding the other parameters, the text already says where they are > defined. > > Or, are you saying that you want the references in the syntax, rather than > in the normative text? > > > Also, 'scope' and 'error' are very generic rule names being used in a > > very restricted context. While these are not defined in RFC3261, > there > > is the potential conflict with other extensions. I'd recommend using > > more specific terms. E.g., > > > > challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) > > bearer-cln = realm / bearer-scope / authz-server / > bearer-error / > > auth-param > > authz-server = "authz_server" EQUAL authz-server-value > > authz-server-value = https-URI > > > > challenge = > > realm = > > auth-param = > > bearer-scope = > > bearer-error = > > https-URI = > > The HTTP WWW-Authenticate header field uses 'error' and 'scope', and I > think it would be good to be aligned. > > > Regarding the scope parameter: > > > > This parameter is conveyed from the registrar to the UAC. But what is > > the UAC to do with it? How does it have any control over the scope of > > the token it gets from the AS? Is the UAC supposed to convey this to > the > > AS? If so, how? > > The UAC will get the scope from the AS, and will forward it towards the > UAS/registrar. > > > Regarding the error parameter: > > > > Is this just intended to be of help in debugging the UAC? Or is it > > expected that the UAC might take some sort of pre-programmed action > in > > response? If the latter, how might that work? Is this information > > suitable for presentation to the user? > > I see no reason why it can't be presented to the user, and I guess the UAC > actions depend on what the error code is. > > However, as the parameter is described in RFC 6749, I don't think we need > to repeat that in this draft. > > --- > > > * Section 4: > > > > I agree with Dale - I don't see any value in this tag. I tried to > search > > for all discussion on the point. The discussion attributes me with > > requesting it, but I don't think I did. > > It was Olle who requested it. > > However, I don't see any harm in having it. It allows the UAC to inform > proxies/UAS/Registrar whether it supports the bearer scheme. > > --- > > > * Missing: > > > > I find no syntax extensions for Authorization and > Proxy-Authorization. > > These need to be added. > > Ok. > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000e50eb40599306ef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for th= e detailed=C2=A0review.

Regarding the
My problem with this is: the challenge gives the UAC an HTTPS = URL of an
AS. It does not normatively state how the UA= C is to use this, or what
usage(s) the AS MUST support= . Hence there is no assurance that the UAC
will be abl= e to successfully access the AS.

=
This could be resolved by requiring that the UAC and AS MUST support
RFC8252. Or perhaps there is some more expansive RFC th= at can be
referenced. In the end there needs to be som= ething MTI.=C2=A0=C2=A0

<= /div>
I think that MUST is too strong in this case. I would be fine wit= h a SHOULD, as there are different ways to achieve this based on the type o= f UAC, e.g. a browser-based UAC application.
Thoughts?
=

Regarding your comment about section 2.1.2, I= agree with you; I will move it to its own section.

Regards,
=C2=A0Rifaat


=
On Wed= , Dec 4, 2019 at 3:00 AM Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org= > wrote:
Hi P= aul,

My comments on some of your SIP-related issues (I am not addressing your is= sues on Sections 2.1.1 and 2.1.2 in this reply).

>=C2=A0 =C2=A0 * Section 2.1.4:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 This section says that the UAC MUST include an Authorizat= ion header
>=C2=A0 =C2=A0 field with the Bearer scheme. This is overly strong.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 This should be an explanation that *if* it has received a= challenge
>=C2=A0 =C2=A0 containing the Bearer scheme then to resolve that particu= lar challenge
>=C2=A0 =C2=A0 it needs to send a request with an Authorization header f= ield containing
>=C2=A0 =C2=A0 the response to that challenge, including the Bearer sche= me.

I suggest that we expand the first paragraph in the section. Something like= :

"The procedures in this section apply when the UAC has received a chal= lenge that contains a Bearer scheme,
and the UAC has obtained a token as specified in section Section 2.1.1.&quo= t;

>=C2=A0 =C2=A0 (But note that if there were multiple challenges with dif= ferent schemes
>=C2=A0 =C2=A0 then it maybe able to successfully retry the request usin= g non-Bearer
>=C2=A0 =C2=A0 credentials.)
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I don't understand what distinction you are trying to= draw by
>=C2=A0 =C2=A0 distinguishing the behavior for creating a binding from t= hat for
>=C2=A0 =C2=A0 refreshing a binding. AFAIK there should be no difference= . And in fact
>=C2=A0 =C2=A0 the UAC in general cannot know whether the request being = send will
>=C2=A0 =C2=A0 establish or refresh a binding.

It is important to point out that the same access token might not necessari= ly be used throughout the lifetime of the registration, if the previously i= ncluded access token has expired.

---

>=C2=A0 =C2=A0 * Section 2.1.5:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 This section has similar issues to section 2.1.4: The MUS= T is too
>=C2=A0 =C2=A0 strong, and the reason for distinguishing between in-dial= og requests
>=C2=A0 =C2=A0 from others is unclear.

See my comments for 2.1.4.

---

>=C2=A0 =C2=A0 * Section 2.2:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Again is overly strong in its use of MUST. I think it is = evident that
>=C2=A0 =C2=A0 the point being made is that a challenge containing Beare= r scheme is the
>=C2=A0 =C2=A0 way to indicate that is with a challenge with Bearer sche= me, but the
>=C2=A0 =C2=A0 text is at least awkward.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 How about:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a UAS or Registrar receives a request = that fails to contain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization credentials acceptable to it,= it SHOULD challenge the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 request by sending a 401 (Unauthorized) res= ponse. To indicate that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 it is willing to accept an OAuth2 token as = a credential the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 UAS/Registrar MUST include a Proxy-Authenti= cation header field in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 response, indicate "Bearer" schem= e and include an address of an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authorization Server from which the origina= tor can obtain an access
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 token.

WFM.

>=C2=A0 =C2=A0 In the second paragraph, please provide a reference:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... using the procedures from [RFC???] asso= ciated with the type of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 access token used.

Ok.

---

>=C2=A0 =C2=A0 * Section 2.3:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Similar comment to section 2.2. How about the following f= or the first
>=C2=A0 =C2=A0 paragraph:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a proxy receives a request that fails = to contain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization credentials acceptable to it,= it SHOULD challenge the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 request by sending a 407 (Proxy Authenticat= ion Required) response.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 To indicate that it is willing to accept an= OAuth2 token as a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 credential the proxy MUST include a Proxy-A= uthentication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 header field in the response, indicating &q= uot;Bearer" scheme and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 including an address to an Authorization Se= rver from which the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 originator can obtain an access token.

WFM.

>=C2=A0 =C2=A0 I don't think the second paragraph should condition a= ny behavior on
>=C2=A0 =C2=A0 whether it has previously challenged. That requires that = the proxy be
>=C2=A0 =C2=A0 stateful, and it isn't a necessary condition. Instead= , how about:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a proxy wishes to authenticate a recei= ved request, it MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 search the request for Proxy-Authorization = header fields with 'realm'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters that match its realm. It then MU= ST successfully validate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the credentials from at least one Proxy-Aut= horization header field
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for its realm. When the scheme is Bearer th= e proxy MUST validate the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 access token, using the procedures from [RF= C???] associated with the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type of access token used.

WFM.

---

>=C2=A0 =C2=A0 * Section 3:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 The following:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The realm and auth-param parameters are def= ined in [RFC3261].
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 is incomplete, because it is missing 'challenge',= 'realm', and
>=C2=A0 =C2=A0 'https-URI. (Where is https-URI defined?)
>
> Another way to do this is by=C2=A0 adding the following to the syntax:=
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 challenge =3D <defined in = RFC3261>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 realm =3D <defined in RFC3= 261>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth-param =3D <defined in= RFC3261>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scope =3D <defined in RFC6= 749>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error =3D <defined in RFC6= 749>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https-URI =3D <where???>= ;
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 (This helps those who might try to formally validate the = syntax because
>=C2=A0 =C2=A0 it removes undefined parameters.)

The section does enhance 'challenge', so I guess we can add text sa= ying that 'challenge' is defined in RFC 3261.

Regarding the other parameters, the text already says where they are define= d.

Or, are you saying that you want the references in the syntax, rather than = in the normative text?

>=C2=A0 =C2=A0 Also, 'scope' and 'error' are very generi= c rule names being used in a
>=C2=A0 =C2=A0 very restricted context. While these are not defined in R= FC3261, there
>=C2=A0 =C2=A0 is the potential conflict with other extensions. I'd = recommend using
>=C2=A0 =C2=A0 more specific terms. E.g.,
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 challenge=C2=A0 =3D/=C2=A0 (&= quot;Bearer" LWS bearer-cln *(COMMA bearer-cln))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bearer-cln =3D realm / bearer= -scope / authz-server / bearer-error /
>=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=A0auth-param
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authz-server =3D "authz_= server" EQUAL authz-server-value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 authz-server-value =3D https-= URI
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 challenge =3D <defined in = RFC3261>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 realm =3D <defined in RFC3= 261>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth-param =3D <defined in= RFC3261>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bearer-scope =3D <defined = as scope in RFC6749>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bearer-error =3D <defined = as error in RFC6749>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https-URI =3D <where???>= ;

The HTTP WWW-Authenticate header field uses 'error' and 'scope&= #39;, and I think it would be good to be aligned.

>=C2=A0 =C2=A0 Regarding the scope parameter:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 This parameter is conveyed from the registrar to the UAC.= But what is
>=C2=A0 =C2=A0 the UAC to do with it? How does it have any control over = the scope of
>=C2=A0 =C2=A0 the token it gets from the AS? Is the UAC supposed to con= vey this to the
>=C2=A0 =C2=A0 AS? If so, how?

The UAC will get the scope from the AS, and will forward it towards the UAS= /registrar.

>=C2=A0 =C2=A0 Regarding the error parameter:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 Is this just intended to be of help in debugging the UAC?= Or is it
>=C2=A0 =C2=A0 expected that the UAC might take some sort of pre-program= med action in
>=C2=A0 =C2=A0 response? If the latter, how might that work? Is this inf= ormation
>=C2=A0 =C2=A0 suitable for presentation to the user?

I see no reason why it can't be presented to the user, and I guess the = UAC actions depend on what the error code is.

However, as the parameter is described in RFC 6749, I don't think we ne= ed to repeat that in this draft.

---

>=C2=A0 =C2=A0 * Section 4:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I agree with Dale - I don't see any value in this tag= . I tried to search
>=C2=A0 =C2=A0 for all discussion on the point. The discussion attribute= s me with
>=C2=A0 =C2=A0 requesting it, but I don't think I did.

It was Olle who requested it.

However, I don't see any harm in having it. It allows the UAC to inform= proxies/UAS/Registrar whether it supports the bearer scheme.

---

>=C2=A0 =C2=A0 * Missing:
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 I find no syntax extensions for Authorization and Proxy-A= uthorization.
>=C2=A0 =C2=A0 These need to be added.

Ok.

Regards,

Christer



_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000e50eb40599306ef2-- From nobody Sun Dec 8 14:18:04 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 E67451200F8 for ; Sun, 8 Dec 2019 14:18:02 -0800 (PST) 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, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 Xx0qiX0uRE_4 for ; Sun, 8 Dec 2019 14:17:59 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2059.outbound.protection.outlook.com [40.107.237.59]) (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 E79971200E9 for ; Sun, 8 Dec 2019 14:17:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RqtToU+wU36J9iw/9dr8dSFNjCjUxIVF9tQg/dD0Hne5zdMsM7rrjPgmp6YnSO9SyMWghhAqufiag+ZVXj2j07dEzK+ApqL+aGdBDdKl/FctvfMShaJJxxJDKALwJgN1VFrzxPnx8f6TIgecRcXSqKDg0gR+kYGhDep3jSO/qknnO2qMn9LfLZZenfqvHwuzK9ANdwWax4gawHlv8NgbGpGYbu9S5WC35QRKi2kI5c7qC230hpxbMiuQJocgkU1H6LC6hI+M8wfi6Q9zJHQnDBG5q6OTVl1uSvVTYZukDmk4Nc9ek51Po2osKatdHKmakn9Wuo7bp4j1kZEXpqBGrA== 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=1WJmUbgx5gGKdteCW/5m9yfqKLnUYDfYB0VZ43Iu22k=; b=AzRfgqFHp7d/RIudlSQFiqXXOnzbjynYvIGciy1z29nw3WGIc/KizzIWk1yv/yg72n/JWHjq2hxu0t+gXeQSc/YR9+5B2+znYvuTAd/reIRUL9Wc7H4uBQ6iDy/nF5w0AJcdLrJZNJ5niMs9KsNRVo8JCMvc0UKZvdSfVyefpIyYJ2LPq0uGZz/xME4uraFxGnIoIsWcGCfVCTHkfPdGYGpP4piryddcEKWW40WAQX31FdTYHjtn8NGHH4JbroFHUEc1MT8/KBn5X7+ywuGClOZxkrDsryO3shV2AmmNBn8O2CzuwmUuudTjXDsEGDd1+C1M1i7pQ60uUaY/H/W+5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1WJmUbgx5gGKdteCW/5m9yfqKLnUYDfYB0VZ43Iu22k=; b=Xm7DwBX1Ok/sWwAh30rq3xCqQSW/XpHgu3YSXWfC4VudZlc5oaSbHaulMTN7UE12EPDKrcoKPRgSfkY7Ph6dx+419kBi13hGJPOpJktC888hKya6HSvr4ii9YcImQ6usKxQHrAdEcyecfW6TAC66SP4vgB7IftfPppfAOyN9NJw= Received: from DM3PR12CA0138.namprd12.prod.outlook.com (2603:10b6:0:51::34) by BN6PR12MB1940.namprd12.prod.outlook.com (2603:10b6:404:fd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Sun, 8 Dec 2019 22:17:54 +0000 Received: from CY1NAM02FT038.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::200) by DM3PR12CA0138.outlook.office365.com (2603:10b6:0:51::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12 via Frontend Transport; Sun, 8 Dec 2019 22:17:54 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT038.mail.protection.outlook.com (10.152.74.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.26 via Frontend Transport; Sun, 8 Dec 2019 22:17:53 +0000 Received: from Kokiri.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 xB8MHp9C007544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2019 17:17:52 -0500 To: Rifaat Shekh-Yusef , Christer Holmberg Cc: "sipcore@ietf.org" References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> From: Paul Kyzivat Message-ID: <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> Date: Sun, 8 Dec 2019 17:17:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(346002)(396003)(51914003)(51444003)(189003)(199004)(65956001)(316002)(31696002)(2870700001)(58126008)(786003)(75432002)(88552002)(50466002)(8676002)(2906002)(110136005)(86362001)(70206006)(246002)(356004)(30864003)(5660300002)(229853002)(66574012)(956004)(26005)(478600001)(31686004)(966005)(2616005)(4326008)(7596002)(336012)(186003)(305945005)(26826003)(8936002)(36906005)(76130400001)(70586007)(76176011)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR12MB1940; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 382607e2-bfde-4b0a-118c-08d77c2c7896 X-MS-TrafficTypeDiagnostic: BN6PR12MB1940: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0245702D7B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5xQDr+MUOPmTlOzMcS1LkRynyFNWO/KkTmIiQMH9AFF0ZhRtzeJ7Kz5YZvTmv40Mon9HIyFscEAAKKd5Xpz2BVO2WBDmj+bvhr8YpwW8LC7m9DFooIw4slbv4QOiW1Gfq0X3mVilNhmxZE5oXtSO1affw19uIp3RqiCCe7roX5naCowtto5TMfOVmCgK+wett2Xg6VSD/4XIzGKrSLSfjShbj7LwAVIFPd96C6NUeVMA7gAuSV9t7CJdhiu9mHvKtuEC+qDfWxF0Cw9i61g3vTbj7WgPtSk8i6Q6JMc16p0NE+/+zVGChdicuye/Vp/JXL/q8UqzWiAp2B0Ogx3jbZ1kDtIOZiP5t2n0O6mqsyit5P9UltSydf+EdpSjaIrLan/I8S/GMfYjd/IIuus2l6vJIkX2SnxNQJy86/XliWtg+WOHXscPsox76TSX5+g8RS6INiYDO5ig/4M8Rj3h+RBysfbzixLX3SE7cJOLIRsRybhSugIZWQ45VpiNTrFWTsFaPBGcTzqY5uQZ9ue/IAKmG74FA645sp+8WaQzI13t46LT3IC3eH2HpshcL7Mx X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2019 22:17:53.7829 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 382607e2-bfde-4b0a-118c-08d77c2c7896 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1940 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 08 Dec 2019 22:18:03 -0000 Hi Rifaat, On 12/8/19 7:29 AM, Rifaat Shekh-Yusef wrote: > Hi Paul, > > Thanks for the detailed review. > > Regarding the > > My problem with this is: the challenge gives the UAC an HTTPS URL of an > AS. It does not normatively state how the UAC is to use this, or what > usage(s) the AS MUST support. Hence there is no assurance that the UAC > will be able to successfully access the AS. > > This could be resolved by requiring that the UAC and AS MUST support > RFC8252. Or perhaps there is some more expansive RFC that can be > referenced. In the end there needs to be something MTI. > > > I think that MUST is too strong in this case. I would be fine with a > SHOULD, as there are different ways to achieve this based on the type of > UAC, e.g. a browser-based UAC application. > Thoughts? I agree there can be variation based on type of UAC. E.g., actually using a browser and having the end user interact with it, vs. a UAC that is an automaton and doesn't have a user. But in the end whatever it is must use the URI as the starting point for the interaction. With a browser interface presumably the URI is used to fetch a page that is presented to the user. And the user then can determine in a human intuitive way how to interact with that page to complete the authentication. If it is an automaton then that won't work. It must have *some* way of determining how to interact with the web server and present what facts it has (e.g. user id and pw) to that server in order to complete authentication. And in either case, there must be a well defined way of learning if it succeeded and conveying the resulting token back to the sip server. RFC8252 seems to try to specify this at least in some cases, though it is still fuzzy to me. This should be deterministic - it shouldn't be neccessary for an automaton to be specially programmed for how to interact with the particular AS and how to convey the result back to the sip server. > Regarding your comment about section 2.1.2, I agree with you; I will > move it to its own section. Moving it to a separate section isn't necessary or sufficient. It needs to be clarified. I'm assuming responses to my other points will be coming later. Thanks, Paul > Regards, >  Rifaat > > > > On Wed, Dec 4, 2019 at 3:00 AM Christer Holmberg > > wrote: > > Hi Paul, > > My comments on some of your SIP-related issues (I am not addressing > your issues on Sections 2.1.1 and 2.1.2 in this reply). > > >    * Section 2.1.4: > > > >    This section says that the UAC MUST include an Authorization > header > >    field with the Bearer scheme. This is overly strong. > > > >    This should be an explanation that *if* it has received a > challenge > >    containing the Bearer scheme then to resolve that particular > challenge > >    it needs to send a request with an Authorization header field > containing > >    the response to that challenge, including the Bearer scheme. > > I suggest that we expand the first paragraph in the section. > Something like: > > "The procedures in this section apply when the UAC has received a > challenge that contains a Bearer scheme, > and the UAC has obtained a token as specified in section Section 2.1.1." > > >    (But note that if there were multiple challenges with > different schemes > >    then it maybe able to successfully retry the request using > non-Bearer > >    credentials.) > > > >    I don't understand what distinction you are trying to draw by > >    distinguishing the behavior for creating a binding from that for > >    refreshing a binding. AFAIK there should be no difference. And > in fact > >    the UAC in general cannot know whether the request being send > will > >    establish or refresh a binding. > > It is important to point out that the same access token might not > necessarily be used throughout the lifetime of the registration, if > the previously included access token has expired. > > --- > > >    * Section 2.1.5: > > > >    This section has similar issues to section 2.1.4: The MUST is too > >    strong, and the reason for distinguishing between in-dialog > requests > >    from others is unclear. > > See my comments for 2.1.4. > > --- > > >    * Section 2.2: > > > >    Again is overly strong in its use of MUST. I think it is > evident that > >    the point being made is that a challenge containing Bearer > scheme is the > >    way to indicate that is with a challenge with Bearer scheme, > but the > >    text is at least awkward. > > > >    How about: > > > >        When a UAS or Registrar receives a request that fails to > contain > >        authorization credentials acceptable to it, it SHOULD > challenge the > >        request by sending a 401 (Unauthorized) response. To > indicate that > >        it is willing to accept an OAuth2 token as a credential the > >        UAS/Registrar MUST include a Proxy-Authentication header > field in the > >        response, indicate "Bearer" scheme and include an address > of an > >        Authorization Server from which the originator can obtain > an access > >        token. > > WFM. > > >    In the second paragraph, please provide a reference: > > > >        ... using the procedures from [RFC???] associated with the > type of > >        access token used. > > Ok. > > --- > > >    * Section 2.3: > > > >    Similar comment to section 2.2. How about the following for > the first > >    paragraph: > > > >        When a proxy receives a request that fails to contain > >        authorization credentials acceptable to it, it SHOULD > challenge the > >        request by sending a 407 (Proxy Authentication Required) > response. > >        To indicate that it is willing to accept an OAuth2 token as a > >        credential the proxy MUST include a Proxy-Authentication > >        header field in the response, indicating "Bearer" scheme and > >        including an address to an Authorization Server from which the > >        originator can obtain an access token. > > WFM. > > >    I don't think the second paragraph should condition any > behavior on > >    whether it has previously challenged. That requires that the > proxy be > >    stateful, and it isn't a necessary condition. Instead, how about: > > > >        When a proxy wishes to authenticate a received request, it > MUST > >        search the request for Proxy-Authorization header fields > with 'realm' > >        parameters that match its realm. It then MUST successfully > validate > >        the credentials from at least one Proxy-Authorization > header field > >        for its realm. When the scheme is Bearer the proxy MUST > validate the > >        access token, using the procedures from [RFC???] > associated with the > >        type of access token used. > > WFM. > > --- > > >    * Section 3: > > > >    The following: > > > >        The realm and auth-param parameters are defined in [RFC3261]. > > > >    is incomplete, because it is missing 'challenge', 'realm', and > >    'https-URI. (Where is https-URI defined?) > > > > Another way to do this is by  adding the following to the syntax: > > > >            challenge = > >            realm = > >            auth-param = > >            scope = > >            error = > >            https-URI = > > > >    (This helps those who might try to formally validate the > syntax because > >    it removes undefined parameters.) > > The section does enhance 'challenge', so I guess we can add text > saying that 'challenge' is defined in RFC 3261. > > Regarding the other parameters, the text already says where they are > defined. > > Or, are you saying that you want the references in the syntax, > rather than in the normative text? > > >    Also, 'scope' and 'error' are very generic rule names being > used in a > >    very restricted context. While these are not defined in > RFC3261, there > >    is the potential conflict with other extensions. I'd recommend > using > >    more specific terms. E.g., > > > >            challenge  =/  ("Bearer" LWS bearer-cln *(COMMA > bearer-cln)) > >            bearer-cln = realm / bearer-scope / authz-server / > bearer-error / > >                         auth-param > >            authz-server = "authz_server" EQUAL authz-server-value > >            authz-server-value = https-URI > > > >            challenge = > >            realm = > >            auth-param = > >            bearer-scope = > >            bearer-error = > >            https-URI = > > The HTTP WWW-Authenticate header field uses 'error' and 'scope', and > I think it would be good to be aligned. > > >    Regarding the scope parameter: > > > >    This parameter is conveyed from the registrar to the UAC. But > what is > >    the UAC to do with it? How does it have any control over the > scope of > >    the token it gets from the AS? Is the UAC supposed to convey > this to the > >    AS? If so, how? > > The UAC will get the scope from the AS, and will forward it towards > the UAS/registrar. > > >    Regarding the error parameter: > > > >    Is this just intended to be of help in debugging the UAC? Or > is it > >    expected that the UAC might take some sort of pre-programmed > action in > >    response? If the latter, how might that work? Is this information > >    suitable for presentation to the user? > > I see no reason why it can't be presented to the user, and I guess > the UAC actions depend on what the error code is. > > However, as the parameter is described in RFC 6749, I don't think we > need to repeat that in this draft. > > --- > > >    * Section 4: > > > >    I agree with Dale - I don't see any value in this tag. I tried > to search > >    for all discussion on the point. The discussion attributes me > with > >    requesting it, but I don't think I did. > > It was Olle who requested it. > > However, I don't see any harm in having it. It allows the UAC to > inform proxies/UAS/Registrar whether it supports the bearer scheme. > > --- > > >    * Missing: > > > >    I find no syntax extensions for Authorization and > Proxy-Authorization. > >    These need to be added. > > Ok. > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Dec 9 00:37: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 71D53120048 for ; Mon, 9 Dec 2019 00:37:49 -0800 (PST) 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 V-Ix1qHPvnsb for ; Mon, 9 Dec 2019 00:37:46 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::616]) (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 BD25212001A for ; Mon, 9 Dec 2019 00:37:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YXeZ6kmSFPMHGJ/7OxUz24sHDbZkoPDQTn8zYktaJNZvKb+exDh37ClLmuHlKhCD7r9vHXMqfU6OkCHGAyU8s/BDpw5kn9pRxTy8FeBpnZesSZuhB6t7A2S15gq4p6DvvY1zaWv6Gfs8iUOv9RMC+NFxdmtyObPryKK+LQAFJ8y7iaa1djmrJQK6eL7eZUJbZJpKGEgf+9FMGThvqg3K/x4Gor+odS2XM3/LbIpb1WReDFZqdcO3sw0Q79gIc9Zbkmkom2RpAoDKyh5p80tUfxjdFcO6kTL7kcOJIaRmjr3DvKF67S55v4J7YKeFsz801RcS3r7uz7Yi24Mri6ckjw== 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=ZK1TMTy7NRUGdXrHGPFrTg3S8itEh4fr5CystUDd49A=; b=kcGZ260gqMlqieMEXZWqc/64Y/PYV/LnoHAKI9vt+DSDZeDXaFGkLpGLRLwxY+sspAvd3IZL0ACAwbSt4WS1xC7cIshE50N4wI50LSBs159ZfLstHeB1ChUie20KB1OziOMAO6NdQ1DI3a+xWv941FzpMFofXtPs5ekVRvtGRBmqW/TKPEZHPyJSp+qSgsKBAwxMMUEgsFfr/VRUziy38OjKW/9S530ymbH5YCb4ltWsMRdzDcTGzqT+cSPLPMMCxBth5GFPK/P1G1AkL+9xDCubALV+cA9Onjj2CEpRaLuiRwpDvZWt0ZmxKvYvFbYIbhIPKWnjwO+vaISJ88C6+Q== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZK1TMTy7NRUGdXrHGPFrTg3S8itEh4fr5CystUDd49A=; b=r3C9vp3kLqxHO1u0H3ibXEBg4iPaGREs6W9W1IsDgsZPELPfLq35mzCQkM0ndE0SqjHPrfkqRIS5rqqIDVeVuooZc75q0Tb3wg2v4pdsmIAeGNeUbXCv2AuxFxJ5HWVcR0iw0Qqd9wtKQ4nfkOkGnqlG4fS2fOhxG3kAU7johh4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4170.eurprd07.prod.outlook.com (20.176.164.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.7; Mon, 9 Dec 2019 08:37:43 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::4dd7:adc9:881e:69c7]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::4dd7:adc9:881e:69c7%7]) with mapi id 15.20.2538.012; Mon, 9 Dec 2019 08:37:43 +0000 From: Christer Holmberg To: Paul Kyzivat , Rifaat Shekh-Yusef CC: "sipcore@ietf.org" Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Thread-Index: AQHVqRaq+n57bvgHbkmAxusa4398hqeoufCAgAEHG4CABnMOAIAApGKAgADOtgA= Date: Mon, 9 Dec 2019 08:37:43 +0000 Message-ID: <9B7C541D-0359-4DB1-9E1C-0015BEDD1B37@ericsson.com> References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> In-Reply-To: <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 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: 66cc8fb5-12e0-49e5-8ad7-08d77c830f15 x-ms-traffictypediagnostic: HE1PR07MB4170: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(39860400002)(396003)(346002)(51444003)(189003)(199004)(51914003)(91956017)(64756008)(81156014)(66446008)(76116006)(66476007)(66556008)(66946007)(81166006)(71190400001)(71200400001)(86362001)(8676002)(2906002)(229853002)(58126008)(305945005)(36756003)(99286004)(110136005)(8936002)(6486002)(316002)(966005)(478600001)(76176011)(4326008)(186003)(6512007)(102836004)(53546011)(26005)(6506007)(66574012)(2616005)(33656002)(44832011)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4170; 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: BCL:0; x-microsoft-antispam-message-info: 67bcMnS3IzXqeVTrV2bUsUpsTSDNV/I5kl/Hey+m3X+P0olTkp4F3tDPiYKHs/66jBlb0tWlZr5obz2LrfXKhJlC5y7OiFM1TYiK84/pZvc8dPtdcUzNoup/iB43Cr+/Dp23MiMI5mYEtcY4tMX7I5/k2y9xpxl/ciPuX47Anqpn0AU+Yw2MedEvDGfGKFf28pjsRnJ5aNHRlKDaTq07VtNWjkKO6ZMnOfgKZ6FKnMlbD14LkvCOE7vn1XNZpZtetme3rKMl5KsmhRLigsJZ0NNea19NULVoQfdOYBEue+w72LHK48yshN6QqfBrRxbZltzZllyMga8SJ60u6Cbtny4JsRX/fwxM6e6VQ4arRXmrKBLKMeaj7dNBri7Ej0JjTJp9kP1k57gLoUei4iJ1uYbF+2QftECvufs6OmDfQN2VBpnBnQoVeJxzKwSjRYYqsGNe0StzOrbh7WV1hpZw/w0a2kgeGQqf1XDkS2jigeo2WeTjGLa57mKprqAKx1kTl2ce1HZ+FbsZ80LFfJApDWwFpg+/w67yBN8OtDLWDAEIV2/PhXzpfw5JrxjgJFsT x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <69A320E0A0EC464AA8346FD6613C9ADA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66cc8fb5-12e0-49e5-8ad7-08d77c830f15 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 08:37:43.0295 (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: 9rliDpSFewS/UO90EMib2PM+S1UMwk5RP0UivTo6BRZpe2llBU8gbr2iz19Oxfc0+zw7FEb4L1TvELLPHuxABzff5KnPTMto0X82dAs9c0I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4170 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 09 Dec 2019 08:37:49 -0000 SGkgUGF1bCwNCg0KSSByZXBsaWVkIHRvIHlvdXIgb3RoZXIgcG9pbnRzIGxhc3Qgd2Vlay4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K77u/T24gMDkvMTIvMjAxOSwgMC4xOCwgIlBhdWwgS3l6 aXZhdCIgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQoNCiAgICBIaSBSaWZhYXQsDQog ICAgDQogICAgT24gMTIvOC8xOSA3OjI5IEFNLCBSaWZhYXQgU2hla2gtWXVzZWYgd3JvdGU6DQog ICAgPiBIaSBQYXVsLA0KICAgID4gDQogICAgPiBUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZXZp ZXcuDQogICAgPiANCiAgICA+IFJlZ2FyZGluZyB0aGUNCiAgICA+IA0KICAgID4gICAgIE15IHBy b2JsZW0gd2l0aCB0aGlzIGlzOiB0aGUgY2hhbGxlbmdlIGdpdmVzIHRoZSBVQUMgYW4gSFRUUFMg VVJMIG9mIGFuDQogICAgPiAgICAgQVMuIEl0IGRvZXMgbm90IG5vcm1hdGl2ZWx5IHN0YXRlIGhv dyB0aGUgVUFDIGlzIHRvIHVzZSB0aGlzLCBvciB3aGF0DQogICAgPiAgICAgdXNhZ2UocykgdGhl IEFTIE1VU1Qgc3VwcG9ydC4gSGVuY2UgdGhlcmUgaXMgbm8gYXNzdXJhbmNlIHRoYXQgdGhlIFVB Qw0KICAgID4gICAgIHdpbGwgYmUgYWJsZSB0byBzdWNjZXNzZnVsbHkgYWNjZXNzIHRoZSBBUy4N CiAgICA+IA0KICAgID4gICAgIFRoaXMgY291bGQgYmUgcmVzb2x2ZWQgYnkgcmVxdWlyaW5nIHRo YXQgdGhlIFVBQyBhbmQgQVMgTVVTVCBzdXBwb3J0DQogICAgPiAgICAgUkZDODI1Mi4gT3IgcGVy aGFwcyB0aGVyZSBpcyBzb21lIG1vcmUgZXhwYW5zaXZlIFJGQyB0aGF0IGNhbiBiZQ0KICAgID4g ICAgIHJlZmVyZW5jZWQuIEluIHRoZSBlbmQgdGhlcmUgbmVlZHMgdG8gYmUgc29tZXRoaW5nIE1U SS4gDQogICAgPiANCiAgICA+IA0KICAgID4gSSB0aGluayB0aGF0IE1VU1QgaXMgdG9vIHN0cm9u ZyBpbiB0aGlzIGNhc2UuIEkgd291bGQgYmUgZmluZSB3aXRoIGEgDQogICAgPiBTSE9VTEQsIGFz IHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyB0byBhY2hpZXZlIHRoaXMgYmFzZWQgb24gdGhlIHR5 cGUgb2YgDQogICAgPiBVQUMsIGUuZy4gYSBicm93c2VyLWJhc2VkIFVBQyBhcHBsaWNhdGlvbi4N CiAgICA+IFRob3VnaHRzPw0KICAgIA0KICAgIEkgYWdyZWUgdGhlcmUgY2FuIGJlIHZhcmlhdGlv biBiYXNlZCBvbiB0eXBlIG9mIFVBQy4gRS5nLiwgYWN0dWFsbHkgDQogICAgdXNpbmcgYSBicm93 c2VyIGFuZCBoYXZpbmcgdGhlIGVuZCB1c2VyIGludGVyYWN0IHdpdGggaXQsIHZzLiBhIFVBQyB0 aGF0IA0KICAgIGlzIGFuIGF1dG9tYXRvbiBhbmQgZG9lc24ndCBoYXZlIGEgdXNlci4NCiAgICAN CiAgICBCdXQgaW4gdGhlIGVuZCB3aGF0ZXZlciBpdCBpcyBtdXN0IHVzZSB0aGUgVVJJIGFzIHRo ZSBzdGFydGluZyBwb2ludCBmb3IgDQogICAgdGhlIGludGVyYWN0aW9uLiBXaXRoIGEgYnJvd3Nl ciBpbnRlcmZhY2UgcHJlc3VtYWJseSB0aGUgVVJJIGlzIHVzZWQgdG8gDQogICAgZmV0Y2ggYSBw YWdlIHRoYXQgaXMgcHJlc2VudGVkIHRvIHRoZSB1c2VyLiBBbmQgdGhlIHVzZXIgdGhlbiBjYW4g DQogICAgZGV0ZXJtaW5lIGluIGEgaHVtYW4gaW50dWl0aXZlIHdheSBob3cgdG8gaW50ZXJhY3Qg d2l0aCB0aGF0IHBhZ2UgdG8gDQogICAgY29tcGxldGUgdGhlIGF1dGhlbnRpY2F0aW9uLiBJZiBp dCBpcyBhbiBhdXRvbWF0b24gdGhlbiB0aGF0IHdvbid0IHdvcmsuIA0KICAgIEl0IG11c3QgaGF2 ZSAqc29tZSogd2F5IG9mIGRldGVybWluaW5nIGhvdyB0byBpbnRlcmFjdCB3aXRoIHRoZSB3ZWIg DQogICAgc2VydmVyIGFuZCBwcmVzZW50IHdoYXQgZmFjdHMgaXQgaGFzIChlLmcuIHVzZXIgaWQg YW5kIHB3KSB0byB0aGF0IA0KICAgIHNlcnZlciBpbiBvcmRlciB0byBjb21wbGV0ZSBhdXRoZW50 aWNhdGlvbi4gQW5kIGluIGVpdGhlciBjYXNlLCB0aGVyZSANCiAgICBtdXN0IGJlIGEgd2VsbCBk ZWZpbmVkIHdheSBvZiBsZWFybmluZyBpZiBpdCBzdWNjZWVkZWQgYW5kIGNvbnZleWluZyB0aGUg DQogICAgcmVzdWx0aW5nIHRva2VuIGJhY2sgdG8gdGhlIHNpcCBzZXJ2ZXIuDQogICAgDQogICAg UkZDODI1MiBzZWVtcyB0byB0cnkgdG8gc3BlY2lmeSB0aGlzIGF0IGxlYXN0IGluIHNvbWUgY2Fz ZXMsIHRob3VnaCBpdCANCiAgICBpcyBzdGlsbCBmdXp6eSB0byBtZS4gVGhpcyBzaG91bGQgYmUg ZGV0ZXJtaW5pc3RpYyAtIGl0IHNob3VsZG4ndCBiZSANCiAgICBuZWNjZXNzYXJ5IGZvciBhbiBh dXRvbWF0b24gdG8gYmUgc3BlY2lhbGx5IHByb2dyYW1tZWQgZm9yIGhvdyB0byANCiAgICBpbnRl cmFjdCB3aXRoIHRoZSBwYXJ0aWN1bGFyIEFTIGFuZCBob3cgdG8gY29udmV5IHRoZSByZXN1bHQg YmFjayB0byB0aGUgDQogICAgc2lwIHNlcnZlci4NCiAgICANCiAgICA+IFJlZ2FyZGluZyB5b3Vy IGNvbW1lbnQgYWJvdXQgc2VjdGlvbiAyLjEuMiwgSSBhZ3JlZSB3aXRoIHlvdTsgSSB3aWxsIA0K ICAgID4gbW92ZSBpdCB0byBpdHMgb3duIHNlY3Rpb24uDQogICAgDQogICAgTW92aW5nIGl0IHRv IGEgc2VwYXJhdGUgc2VjdGlvbiBpc24ndCBuZWNlc3Nhcnkgb3Igc3VmZmljaWVudC4gSXQgbmVl ZHMgDQogICAgdG8gYmUgY2xhcmlmaWVkLg0KICAgIA0KICAgIEknbSBhc3N1bWluZyByZXNwb25z ZXMgdG8gbXkgb3RoZXIgcG9pbnRzIHdpbGwgYmUgY29taW5nIGxhdGVyLg0KICAgIA0KICAgIAlU aGFua3MsDQogICAgCVBhdWwNCiAgICANCiAgICA+IFJlZ2FyZHMsDQogICAgPiAgIFJpZmFhdA0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gT24gV2VkLCBEZWMgNCwgMjAxOSBhdCAzOjAw IEFNIENocmlzdGVyIEhvbG1iZXJnIA0KICAgID4gPGNocmlzdGVyLmhvbG1iZXJnPTQwZXJpY3Nz b24uY29tQGRtYXJjLmlldGYub3JnIA0KICAgID4gPG1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFy Yy5pZXRmLm9yZz4+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAgSGkgUGF1bCwNCiAgICA+IA0K ICAgID4gICAgIE15IGNvbW1lbnRzIG9uIHNvbWUgb2YgeW91ciBTSVAtcmVsYXRlZCBpc3N1ZXMg KEkgYW0gbm90IGFkZHJlc3NpbmcNCiAgICA+ICAgICB5b3VyIGlzc3VlcyBvbiBTZWN0aW9ucyAy LjEuMSBhbmQgMi4xLjIgaW4gdGhpcyByZXBseSkuDQogICAgPiANCiAgICA+ICAgICAgPiAgICAq IFNlY3Rpb24gMi4xLjQ6DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAgICBUaGlzIHNlY3Rp b24gc2F5cyB0aGF0IHRoZSBVQUMgTVVTVCBpbmNsdWRlIGFuIEF1dGhvcml6YXRpb24NCiAgICA+ ICAgICBoZWFkZXINCiAgICA+ICAgICAgPiAgICBmaWVsZCB3aXRoIHRoZSBCZWFyZXIgc2NoZW1l LiBUaGlzIGlzIG92ZXJseSBzdHJvbmcuDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAgICBU aGlzIHNob3VsZCBiZSBhbiBleHBsYW5hdGlvbiB0aGF0ICppZiogaXQgaGFzIHJlY2VpdmVkIGEN CiAgICA+ICAgICBjaGFsbGVuZ2UNCiAgICA+ICAgICAgPiAgICBjb250YWluaW5nIHRoZSBCZWFy ZXIgc2NoZW1lIHRoZW4gdG8gcmVzb2x2ZSB0aGF0IHBhcnRpY3VsYXINCiAgICA+ICAgICBjaGFs bGVuZ2UNCiAgICA+ICAgICAgPiAgICBpdCBuZWVkcyB0byBzZW5kIGEgcmVxdWVzdCB3aXRoIGFu IEF1dGhvcml6YXRpb24gaGVhZGVyIGZpZWxkDQogICAgPiAgICAgY29udGFpbmluZw0KICAgID4g ICAgICA+ICAgIHRoZSByZXNwb25zZSB0byB0aGF0IGNoYWxsZW5nZSwgaW5jbHVkaW5nIHRoZSBC ZWFyZXIgc2NoZW1lLg0KICAgID4gDQogICAgPiAgICAgSSBzdWdnZXN0IHRoYXQgd2UgZXhwYW5k IHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gdGhlIHNlY3Rpb24uDQogICAgPiAgICAgU29tZXRoaW5n IGxpa2U6DQogICAgPiANCiAgICA+ICAgICAiVGhlIHByb2NlZHVyZXMgaW4gdGhpcyBzZWN0aW9u IGFwcGx5IHdoZW4gdGhlIFVBQyBoYXMgcmVjZWl2ZWQgYQ0KICAgID4gICAgIGNoYWxsZW5nZSB0 aGF0IGNvbnRhaW5zIGEgQmVhcmVyIHNjaGVtZSwNCiAgICA+ICAgICBhbmQgdGhlIFVBQyBoYXMg b2J0YWluZWQgYSB0b2tlbiBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiBTZWN0aW9uIDIuMS4xLiIN CiAgICA+IA0KICAgID4gICAgICA+ICAgIChCdXQgbm90ZSB0aGF0IGlmIHRoZXJlIHdlcmUgbXVs dGlwbGUgY2hhbGxlbmdlcyB3aXRoDQogICAgPiAgICAgZGlmZmVyZW50IHNjaGVtZXMNCiAgICA+ ICAgICAgPiAgICB0aGVuIGl0IG1heWJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHJldHJ5IHRoZSBy ZXF1ZXN0IHVzaW5nDQogICAgPiAgICAgbm9uLUJlYXJlcg0KICAgID4gICAgICA+ICAgIGNyZWRl bnRpYWxzLikNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgIEkgZG9uJ3QgdW5kZXJzdGFu ZCB3aGF0IGRpc3RpbmN0aW9uIHlvdSBhcmUgdHJ5aW5nIHRvIGRyYXcgYnkNCiAgICA+ICAgICAg PiAgICBkaXN0aW5ndWlzaGluZyB0aGUgYmVoYXZpb3IgZm9yIGNyZWF0aW5nIGEgYmluZGluZyBm cm9tIHRoYXQgZm9yDQogICAgPiAgICAgID4gICAgcmVmcmVzaGluZyBhIGJpbmRpbmcuIEFGQUlL IHRoZXJlIHNob3VsZCBiZSBubyBkaWZmZXJlbmNlLiBBbmQNCiAgICA+ICAgICBpbiBmYWN0DQog ICAgPiAgICAgID4gICAgdGhlIFVBQyBpbiBnZW5lcmFsIGNhbm5vdCBrbm93IHdoZXRoZXIgdGhl IHJlcXVlc3QgYmVpbmcgc2VuZA0KICAgID4gICAgIHdpbGwNCiAgICA+ICAgICAgPiAgICBlc3Rh Ymxpc2ggb3IgcmVmcmVzaCBhIGJpbmRpbmcuDQogICAgPiANCiAgICA+ICAgICBJdCBpcyBpbXBv cnRhbnQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIHNhbWUgYWNjZXNzIHRva2VuIG1pZ2h0IG5vdA0K ICAgID4gICAgIG5lY2Vzc2FyaWx5IGJlIHVzZWQgdGhyb3VnaG91dCB0aGUgbGlmZXRpbWUgb2Yg dGhlIHJlZ2lzdHJhdGlvbiwgaWYNCiAgICA+ICAgICB0aGUgcHJldmlvdXNseSBpbmNsdWRlZCBh Y2Nlc3MgdG9rZW4gaGFzIGV4cGlyZWQuDQogICAgPiANCiAgICA+ICAgICAtLS0NCiAgICA+IA0K ICAgID4gICAgICA+ICAgICogU2VjdGlvbiAyLjEuNToNCiAgICA+ICAgICAgPg0KICAgID4gICAg ICA+ICAgIFRoaXMgc2VjdGlvbiBoYXMgc2ltaWxhciBpc3N1ZXMgdG8gc2VjdGlvbiAyLjEuNDog VGhlIE1VU1QgaXMgdG9vDQogICAgPiAgICAgID4gICAgc3Ryb25nLCBhbmQgdGhlIHJlYXNvbiBm b3IgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBpbi1kaWFsb2cNCiAgICA+ICAgICByZXF1ZXN0cw0K ICAgID4gICAgICA+ICAgIGZyb20gb3RoZXJzIGlzIHVuY2xlYXIuDQogICAgPiANCiAgICA+ICAg ICBTZWUgbXkgY29tbWVudHMgZm9yIDIuMS40Lg0KICAgID4gDQogICAgPiAgICAgLS0tDQogICAg PiANCiAgICA+ICAgICAgPiAgICAqIFNlY3Rpb24gMi4yOg0KICAgID4gICAgICA+DQogICAgPiAg ICAgID4gICAgQWdhaW4gaXMgb3Zlcmx5IHN0cm9uZyBpbiBpdHMgdXNlIG9mIE1VU1QuIEkgdGhp bmsgaXQgaXMNCiAgICA+ICAgICBldmlkZW50IHRoYXQNCiAgICA+ICAgICAgPiAgICB0aGUgcG9p bnQgYmVpbmcgbWFkZSBpcyB0aGF0IGEgY2hhbGxlbmdlIGNvbnRhaW5pbmcgQmVhcmVyDQogICAg PiAgICAgc2NoZW1lIGlzIHRoZQ0KICAgID4gICAgICA+ICAgIHdheSB0byBpbmRpY2F0ZSB0aGF0 IGlzIHdpdGggYSBjaGFsbGVuZ2Ugd2l0aCBCZWFyZXIgc2NoZW1lLA0KICAgID4gICAgIGJ1dCB0 aGUNCiAgICA+ICAgICAgPiAgICB0ZXh0IGlzIGF0IGxlYXN0IGF3a3dhcmQuDQogICAgPiAgICAg ID4NCiAgICA+ICAgICAgPiAgICBIb3cgYWJvdXQ6DQogICAgPiAgICAgID4NCiAgICA+ICAgICAg PiAgICAgICAgV2hlbiBhIFVBUyBvciBSZWdpc3RyYXIgcmVjZWl2ZXMgYSByZXF1ZXN0IHRoYXQg ZmFpbHMgdG8NCiAgICA+ICAgICBjb250YWluDQogICAgPiAgICAgID4gICAgICAgIGF1dGhvcml6 YXRpb24gY3JlZGVudGlhbHMgYWNjZXB0YWJsZSB0byBpdCwgaXQgU0hPVUxEDQogICAgPiAgICAg Y2hhbGxlbmdlIHRoZQ0KICAgID4gICAgICA+ICAgICAgICByZXF1ZXN0IGJ5IHNlbmRpbmcgYSA0 MDEgKFVuYXV0aG9yaXplZCkgcmVzcG9uc2UuIFRvDQogICAgPiAgICAgaW5kaWNhdGUgdGhhdA0K ICAgID4gICAgICA+ICAgICAgICBpdCBpcyB3aWxsaW5nIHRvIGFjY2VwdCBhbiBPQXV0aDIgdG9r ZW4gYXMgYSBjcmVkZW50aWFsIHRoZQ0KICAgID4gICAgICA+ICAgICAgICBVQVMvUmVnaXN0cmFy IE1VU1QgaW5jbHVkZSBhIFByb3h5LUF1dGhlbnRpY2F0aW9uIGhlYWRlcg0KICAgID4gICAgIGZp ZWxkIGluIHRoZQ0KICAgID4gICAgICA+ICAgICAgICByZXNwb25zZSwgaW5kaWNhdGUgIkJlYXJl ciIgc2NoZW1lIGFuZCBpbmNsdWRlIGFuIGFkZHJlc3MNCiAgICA+ICAgICBvZiBhbg0KICAgID4g ICAgICA+ICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciBmcm9tIHdoaWNoIHRoZSBvcmlnaW5h dG9yIGNhbiBvYnRhaW4NCiAgICA+ICAgICBhbiBhY2Nlc3MNCiAgICA+ICAgICAgPiAgICAgICAg dG9rZW4uDQogICAgPiANCiAgICA+ICAgICBXRk0uDQogICAgPiANCiAgICA+ICAgICAgPiAgICBJ biB0aGUgc2Vjb25kIHBhcmFncmFwaCwgcGxlYXNlIHByb3ZpZGUgYSByZWZlcmVuY2U6DQogICAg PiAgICAgID4NCiAgICA+ICAgICAgPiAgICAgICAgLi4uIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGZy b20gW1JGQz8/P10gYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgID4gICAgIHR5cGUgb2YNCiAgICA+ ICAgICAgPiAgICAgICAgYWNjZXNzIHRva2VuIHVzZWQuDQogICAgPiANCiAgICA+ICAgICBPay4N CiAgICA+IA0KICAgID4gICAgIC0tLQ0KICAgID4gDQogICAgPiAgICAgID4gICAgKiBTZWN0aW9u IDIuMzoNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgIFNpbWlsYXIgY29tbWVudCB0byBz ZWN0aW9uIDIuMi4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgZm9yDQogICAgPiAgICAgdGhlIGZp cnN0DQogICAgPiAgICAgID4gICAgcGFyYWdyYXBoOg0KICAgID4gICAgICA+DQogICAgPiAgICAg ID4gICAgICAgIFdoZW4gYSBwcm94eSByZWNlaXZlcyBhIHJlcXVlc3QgdGhhdCBmYWlscyB0byBj b250YWluDQogICAgPiAgICAgID4gICAgICAgIGF1dGhvcml6YXRpb24gY3JlZGVudGlhbHMgYWNj ZXB0YWJsZSB0byBpdCwgaXQgU0hPVUxEDQogICAgPiAgICAgY2hhbGxlbmdlIHRoZQ0KICAgID4g ICAgICA+ICAgICAgICByZXF1ZXN0IGJ5IHNlbmRpbmcgYSA0MDcgKFByb3h5IEF1dGhlbnRpY2F0 aW9uIFJlcXVpcmVkKQ0KICAgID4gICAgIHJlc3BvbnNlLg0KICAgID4gICAgICA+ICAgICAgICBU byBpbmRpY2F0ZSB0aGF0IGl0IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIE9BdXRoMiB0b2tlbiBh cyBhDQogICAgPiAgICAgID4gICAgICAgIGNyZWRlbnRpYWwgdGhlIHByb3h5IE1VU1QgaW5jbHVk ZSBhIFByb3h5LUF1dGhlbnRpY2F0aW9uDQogICAgPiAgICAgID4gICAgICAgIGhlYWRlciBmaWVs ZCBpbiB0aGUgcmVzcG9uc2UsIGluZGljYXRpbmcgIkJlYXJlciIgc2NoZW1lIGFuZA0KICAgID4g ICAgICA+ICAgICAgICBpbmNsdWRpbmcgYW4gYWRkcmVzcyB0byBhbiBBdXRob3JpemF0aW9uIFNl cnZlciBmcm9tIHdoaWNoIHRoZQ0KICAgID4gICAgICA+ICAgICAgICBvcmlnaW5hdG9yIGNhbiBv YnRhaW4gYW4gYWNjZXNzIHRva2VuLg0KICAgID4gDQogICAgPiAgICAgV0ZNLg0KICAgID4gDQog ICAgPiAgICAgID4gICAgSSBkb24ndCB0aGluayB0aGUgc2Vjb25kIHBhcmFncmFwaCBzaG91bGQg Y29uZGl0aW9uIGFueQ0KICAgID4gICAgIGJlaGF2aW9yIG9uDQogICAgPiAgICAgID4gICAgd2hl dGhlciBpdCBoYXMgcHJldmlvdXNseSBjaGFsbGVuZ2VkLiBUaGF0IHJlcXVpcmVzIHRoYXQgdGhl DQogICAgPiAgICAgcHJveHkgYmUNCiAgICA+ICAgICAgPiAgICBzdGF0ZWZ1bCwgYW5kIGl0IGlz bid0IGEgbmVjZXNzYXJ5IGNvbmRpdGlvbi4gSW5zdGVhZCwgaG93IGFib3V0Og0KICAgID4gICAg ICA+DQogICAgPiAgICAgID4gICAgICAgIFdoZW4gYSBwcm94eSB3aXNoZXMgdG8gYXV0aGVudGlj YXRlIGEgcmVjZWl2ZWQgcmVxdWVzdCwgaXQNCiAgICA+ICAgICBNVVNUDQogICAgPiAgICAgID4g ICAgICAgIHNlYXJjaCB0aGUgcmVxdWVzdCBmb3IgUHJveHktQXV0aG9yaXphdGlvbiBoZWFkZXIg ZmllbGRzDQogICAgPiAgICAgd2l0aCAncmVhbG0nDQogICAgPiAgICAgID4gICAgICAgIHBhcmFt ZXRlcnMgdGhhdCBtYXRjaCBpdHMgcmVhbG0uIEl0IHRoZW4gTVVTVCBzdWNjZXNzZnVsbHkNCiAg ICA+ICAgICB2YWxpZGF0ZQ0KICAgID4gICAgICA+ICAgICAgICB0aGUgY3JlZGVudGlhbHMgZnJv bSBhdCBsZWFzdCBvbmUgUHJveHktQXV0aG9yaXphdGlvbg0KICAgID4gICAgIGhlYWRlciBmaWVs ZA0KICAgID4gICAgICA+ICAgICAgICBmb3IgaXRzIHJlYWxtLiBXaGVuIHRoZSBzY2hlbWUgaXMg QmVhcmVyIHRoZSBwcm94eSBNVVNUDQogICAgPiAgICAgdmFsaWRhdGUgdGhlDQogICAgPiAgICAg ID4gICAgICAgIGFjY2VzcyB0b2tlbiwgdXNpbmcgdGhlIHByb2NlZHVyZXMgZnJvbSBbUkZDPz8/ XQ0KICAgID4gICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgICA+ICAgICAgPiAgICAgICAgdHlw ZSBvZiBhY2Nlc3MgdG9rZW4gdXNlZC4NCiAgICA+IA0KICAgID4gICAgIFdGTS4NCiAgICA+IA0K ICAgID4gICAgIC0tLQ0KICAgID4gDQogICAgPiAgICAgID4gICAgKiBTZWN0aW9uIDM6DQogICAg PiAgICAgID4NCiAgICA+ICAgICAgPiAgICBUaGUgZm9sbG93aW5nOg0KICAgID4gICAgICA+DQog ICAgPiAgICAgID4gICAgICAgIFRoZSByZWFsbSBhbmQgYXV0aC1wYXJhbSBwYXJhbWV0ZXJzIGFy ZSBkZWZpbmVkIGluIFtSRkMzMjYxXS4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgIGlz IGluY29tcGxldGUsIGJlY2F1c2UgaXQgaXMgbWlzc2luZyAnY2hhbGxlbmdlJywgJ3JlYWxtJywg YW5kDQogICAgPiAgICAgID4gICAgJ2h0dHBzLVVSSS4gKFdoZXJlIGlzIGh0dHBzLVVSSSBkZWZp bmVkPykNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IEFub3RoZXIgd2F5IHRvIGRvIHRoaXMg aXMgYnkgIGFkZGluZyB0aGUgZm9sbG93aW5nIHRvIHRoZSBzeW50YXg6DQogICAgPiAgICAgID4N CiAgICA+ICAgICAgPiAgICAgICAgICAgIGNoYWxsZW5nZSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+ DQogICAgPiAgICAgID4gICAgICAgICAgICByZWFsbSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQog ICAgPiAgICAgID4gICAgICAgICAgICBhdXRoLXBhcmFtID0gPGRlZmluZWQgaW4gUkZDMzI2MT4N CiAgICA+ICAgICAgPiAgICAgICAgICAgIHNjb3BlID0gPGRlZmluZWQgaW4gUkZDNjc0OT4NCiAg ICA+ICAgICAgPiAgICAgICAgICAgIGVycm9yID0gPGRlZmluZWQgaW4gUkZDNjc0OT4NCiAgICA+ ICAgICAgPiAgICAgICAgICAgIGh0dHBzLVVSSSA9IDx3aGVyZT8/Pz4NCiAgICA+ICAgICAgPg0K ICAgID4gICAgICA+ICAgIChUaGlzIGhlbHBzIHRob3NlIHdobyBtaWdodCB0cnkgdG8gZm9ybWFs bHkgdmFsaWRhdGUgdGhlDQogICAgPiAgICAgc3ludGF4IGJlY2F1c2UNCiAgICA+ICAgICAgPiAg ICBpdCByZW1vdmVzIHVuZGVmaW5lZCBwYXJhbWV0ZXJzLikNCiAgICA+IA0KICAgID4gICAgIFRo ZSBzZWN0aW9uIGRvZXMgZW5oYW5jZSAnY2hhbGxlbmdlJywgc28gSSBndWVzcyB3ZSBjYW4gYWRk IHRleHQNCiAgICA+ICAgICBzYXlpbmcgdGhhdCAnY2hhbGxlbmdlJyBpcyBkZWZpbmVkIGluIFJG QyAzMjYxLg0KICAgID4gDQogICAgPiAgICAgUmVnYXJkaW5nIHRoZSBvdGhlciBwYXJhbWV0ZXJz LCB0aGUgdGV4dCBhbHJlYWR5IHNheXMgd2hlcmUgdGhleSBhcmUNCiAgICA+ICAgICBkZWZpbmVk Lg0KICAgID4gDQogICAgPiAgICAgT3IsIGFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IHdhbnQgdGhl IHJlZmVyZW5jZXMgaW4gdGhlIHN5bnRheCwNCiAgICA+ICAgICByYXRoZXIgdGhhbiBpbiB0aGUg bm9ybWF0aXZlIHRleHQ/DQogICAgPiANCiAgICA+ICAgICAgPiAgICBBbHNvLCAnc2NvcGUnIGFu ZCAnZXJyb3InIGFyZSB2ZXJ5IGdlbmVyaWMgcnVsZSBuYW1lcyBiZWluZw0KICAgID4gICAgIHVz ZWQgaW4gYQ0KICAgID4gICAgICA+ICAgIHZlcnkgcmVzdHJpY3RlZCBjb250ZXh0LiBXaGlsZSB0 aGVzZSBhcmUgbm90IGRlZmluZWQgaW4NCiAgICA+ICAgICBSRkMzMjYxLCB0aGVyZQ0KICAgID4g ICAgICA+ICAgIGlzIHRoZSBwb3RlbnRpYWwgY29uZmxpY3Qgd2l0aCBvdGhlciBleHRlbnNpb25z LiBJJ2QgcmVjb21tZW5kDQogICAgPiAgICAgdXNpbmcNCiAgICA+ICAgICAgPiAgICBtb3JlIHNw ZWNpZmljIHRlcm1zLiBFLmcuLA0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gICAgICAgICAg ICBjaGFsbGVuZ2UgID0vICAoIkJlYXJlciIgTFdTIGJlYXJlci1jbG4gKihDT01NQQ0KICAgID4g ICAgIGJlYXJlci1jbG4pKQ0KICAgID4gICAgICA+ICAgICAgICAgICAgYmVhcmVyLWNsbiA9IHJl YWxtIC8gYmVhcmVyLXNjb3BlIC8gYXV0aHotc2VydmVyIC8NCiAgICA+ICAgICBiZWFyZXItZXJy b3IgLw0KICAgID4gICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgIGF1dGgtcGFyYW0NCiAg ICA+ICAgICAgPiAgICAgICAgICAgIGF1dGh6LXNlcnZlciA9ICJhdXRoel9zZXJ2ZXIiIEVRVUFM IGF1dGh6LXNlcnZlci12YWx1ZQ0KICAgID4gICAgICA+ICAgICAgICAgICAgYXV0aHotc2VydmVy LXZhbHVlID0gaHR0cHMtVVJJDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiAgICAgICAgICAg IGNoYWxsZW5nZSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQogICAgPiAgICAgID4gICAgICAgICAg ICByZWFsbSA9IDxkZWZpbmVkIGluIFJGQzMyNjE+DQogICAgPiAgICAgID4gICAgICAgICAgICBh dXRoLXBhcmFtID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCiAgICA+ICAgICAgPiAgICAgICAgICAg IGJlYXJlci1zY29wZSA9IDxkZWZpbmVkIGFzIHNjb3BlIGluIFJGQzY3NDk+DQogICAgPiAgICAg ID4gICAgICAgICAgICBiZWFyZXItZXJyb3IgPSA8ZGVmaW5lZCBhcyBlcnJvciBpbiBSRkM2NzQ5 Pg0KICAgID4gICAgICA+ICAgICAgICAgICAgaHR0cHMtVVJJID0gPHdoZXJlPz8/Pg0KICAgID4g DQogICAgPiAgICAgVGhlIEhUVFAgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgZmllbGQgdXNlcyAn ZXJyb3InIGFuZCAnc2NvcGUnLCBhbmQNCiAgICA+ICAgICBJIHRoaW5rIGl0IHdvdWxkIGJlIGdv b2QgdG8gYmUgYWxpZ25lZC4NCiAgICA+IA0KICAgID4gICAgICA+ICAgIFJlZ2FyZGluZyB0aGUg c2NvcGUgcGFyYW1ldGVyOg0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gICAgVGhpcyBwYXJh bWV0ZXIgaXMgY29udmV5ZWQgZnJvbSB0aGUgcmVnaXN0cmFyIHRvIHRoZSBVQUMuIEJ1dA0KICAg ID4gICAgIHdoYXQgaXMNCiAgICA+ICAgICAgPiAgICB0aGUgVUFDIHRvIGRvIHdpdGggaXQ/IEhv dyBkb2VzIGl0IGhhdmUgYW55IGNvbnRyb2wgb3ZlciB0aGUNCiAgICA+ICAgICBzY29wZSBvZg0K ICAgID4gICAgICA+ICAgIHRoZSB0b2tlbiBpdCBnZXRzIGZyb20gdGhlIEFTPyBJcyB0aGUgVUFD IHN1cHBvc2VkIHRvIGNvbnZleQ0KICAgID4gICAgIHRoaXMgdG8gdGhlDQogICAgPiAgICAgID4g ICAgQVM/IElmIHNvLCBob3c/DQogICAgPiANCiAgICA+ICAgICBUaGUgVUFDIHdpbGwgZ2V0IHRo ZSBzY29wZSBmcm9tIHRoZSBBUywgYW5kIHdpbGwgZm9yd2FyZCBpdCB0b3dhcmRzDQogICAgPiAg ICAgdGhlIFVBUy9yZWdpc3RyYXIuDQogICAgPiANCiAgICA+ICAgICAgPiAgICBSZWdhcmRpbmcg dGhlIGVycm9yIHBhcmFtZXRlcjoNCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+ICAgIElzIHRo aXMganVzdCBpbnRlbmRlZCB0byBiZSBvZiBoZWxwIGluIGRlYnVnZ2luZyB0aGUgVUFDPyBPcg0K ICAgID4gICAgIGlzIGl0DQogICAgPiAgICAgID4gICAgZXhwZWN0ZWQgdGhhdCB0aGUgVUFDIG1p Z2h0IHRha2Ugc29tZSBzb3J0IG9mIHByZS1wcm9ncmFtbWVkDQogICAgPiAgICAgYWN0aW9uIGlu DQogICAgPiAgICAgID4gICAgcmVzcG9uc2U/IElmIHRoZSBsYXR0ZXIsIGhvdyBtaWdodCB0aGF0 IHdvcms/IElzIHRoaXMgaW5mb3JtYXRpb24NCiAgICA+ICAgICAgPiAgICBzdWl0YWJsZSBmb3Ig cHJlc2VudGF0aW9uIHRvIHRoZSB1c2VyPw0KICAgID4gDQogICAgPiAgICAgSSBzZWUgbm8gcmVh c29uIHdoeSBpdCBjYW4ndCBiZSBwcmVzZW50ZWQgdG8gdGhlIHVzZXIsIGFuZCBJIGd1ZXNzDQog ICAgPiAgICAgdGhlIFVBQyBhY3Rpb25zIGRlcGVuZCBvbiB3aGF0IHRoZSBlcnJvciBjb2RlIGlz Lg0KICAgID4gDQogICAgPiAgICAgSG93ZXZlciwgYXMgdGhlIHBhcmFtZXRlciBpcyBkZXNjcmli ZWQgaW4gUkZDIDY3NDksIEkgZG9uJ3QgdGhpbmsgd2UNCiAgICA+ICAgICBuZWVkIHRvIHJlcGVh dCB0aGF0IGluIHRoaXMgZHJhZnQuDQogICAgPiANCiAgICA+ICAgICAtLS0NCiAgICA+IA0KICAg ID4gICAgICA+ICAgICogU2VjdGlvbiA0Og0KICAgID4gICAgICA+DQogICAgPiAgICAgID4gICAg SSBhZ3JlZSB3aXRoIERhbGUgLSBJIGRvbid0IHNlZSBhbnkgdmFsdWUgaW4gdGhpcyB0YWcuIEkg dHJpZWQNCiAgICA+ICAgICB0byBzZWFyY2gNCiAgICA+ICAgICAgPiAgICBmb3IgYWxsIGRpc2N1 c3Npb24gb24gdGhlIHBvaW50LiBUaGUgZGlzY3Vzc2lvbiBhdHRyaWJ1dGVzIG1lDQogICAgPiAg ICAgd2l0aA0KICAgID4gICAgICA+ICAgIHJlcXVlc3RpbmcgaXQsIGJ1dCBJIGRvbid0IHRoaW5r IEkgZGlkLg0KICAgID4gDQogICAgPiAgICAgSXQgd2FzIE9sbGUgd2hvIHJlcXVlc3RlZCBpdC4N CiAgICA+IA0KICAgID4gICAgIEhvd2V2ZXIsIEkgZG9uJ3Qgc2VlIGFueSBoYXJtIGluIGhhdmlu ZyBpdC4gSXQgYWxsb3dzIHRoZSBVQUMgdG8NCiAgICA+ICAgICBpbmZvcm0gcHJveGllcy9VQVMv UmVnaXN0cmFyIHdoZXRoZXIgaXQgc3VwcG9ydHMgdGhlIGJlYXJlciBzY2hlbWUuDQogICAgPiAN CiAgICA+ICAgICAtLS0NCiAgICA+IA0KICAgID4gICAgICA+ICAgICogTWlzc2luZzoNCiAgICA+ ICAgICAgPg0KICAgID4gICAgICA+ICAgIEkgZmluZCBubyBzeW50YXggZXh0ZW5zaW9ucyBmb3Ig QXV0aG9yaXphdGlvbiBhbmQNCiAgICA+ICAgICBQcm94eS1BdXRob3JpemF0aW9uLg0KICAgID4g ICAgICA+ICAgIFRoZXNlIG5lZWQgdG8gYmUgYWRkZWQuDQogICAgPiANCiAgICA+ICAgICBPay4N CiAgICA+IA0KICAgID4gICAgIFJlZ2FyZHMsDQogICAgPiANCiAgICA+ICAgICBDaHJpc3Rlcg0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgc2lwY29yZSBtYWlsaW5nIGxpc3QN CiAgICA+ICAgICBzaXBjb3JlQGlldGYub3JnIDxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCiAg ICA+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCiAg ICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Fri Dec 13 06:02: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 55012120855 for ; Fri, 13 Dec 2019 06:02:37 -0800 (PST) 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 wuWSZfPl87kH for ; Fri, 13 Dec 2019 06:02:34 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 03954120058 for ; Fri, 13 Dec 2019 06:02:33 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id f5so2145717ilq.5 for ; Fri, 13 Dec 2019 06:02:33 -0800 (PST) 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=/CJPViCPPURYUd+O3bKEicn4FOxX4UbMj1vxhW5DxzU=; b=Gz4pxq7I1mjAc5sWoA6qLU2B/5CP6jF9qF4B7fH8PWwKh+hFMP0jlZ/4iXohWYTLbs Q5bBgpjTnSvzho/inBplNdBmiQMXdFCwghXnATO8ZSG1299jnu8EzhRsnTI6cNIAM8Lf iTp2Sx1T2KeEEQ9DT6Z0sX8NDF4NrhxK5nsHa+YmdcQTA5ipU/DYEL5wi5ci/V/csSIV xojyPtiL1Fq0ZM510issQAEWUqGQGHT6DwhgcB7Z5rgp0sUEDrYhXFa+ybIaDtI0Qs64 sFQAJiIip2nyx415BvkqIvpEwlYkq9gCRk1fYHAEt6r5OYS8Ni69KGOsY9lTAXE4WoEU Z2lw== 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=/CJPViCPPURYUd+O3bKEicn4FOxX4UbMj1vxhW5DxzU=; b=jrWOtigxgdTOFxpX5C9VyscLOTD0SRpc6+SuzsbHVQ2Lj0myeX345y2s29/U8zh9pV g+sCPjaB+aXc5Wojx6UwPFLLuYqRVsWlBLPhf+UwqQFkHpuYFW3y/riM/6OuFosh+PjS FZqY4DD+9L2JEt7bwMe8TG1Ud2VHjwvyN4bVOEpZY4Qa4aM+zpJ4d0xXhwaPkUVtHc1y xL8wYm79S+7nTfgz03/neI6UEJNsOy/q7p1eTPhC8yOMCPrWTqp+jADf4L72NQk86FGz ZzfhXleW2vQX8KrkDF33IBscjdlcVZQFxQ3zMuu+9CHBDzn1gOv6N5JjSxFdRBQYlVcO nLSw== X-Gm-Message-State: APjAAAUHSxuUMM5SDolZlSzkZzvhzGutYL0qIdDAuNcmYb6THOZkusgv VG7QEhoN5FZHYZELUwIjkHsD1x/wo+9SQ4DTd4o9kM6Lvws= X-Google-Smtp-Source: APXvYqxUTrIB2bD028J/SNuk87lij4BvBEtCXxrOh+zhNMz3VIIvs+IV+J57uuU/PV/B42fp6ZLkvyPsnSgQo5WZE4k= X-Received: by 2002:a92:3a8e:: with SMTP id i14mr14040202ilf.255.1576245751302; Fri, 13 Dec 2019 06:02:31 -0800 (PST) MIME-Version: 1.0 References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> In-Reply-To: <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> From: Rifaat Shekh-Yusef Date: Fri, 13 Dec 2019 09:02:20 -0500 Message-ID: To: Paul Kyzivat Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="00000000000015e4be059996507b" Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 13 Dec 2019 14:02:37 -0000 --00000000000015e4be059996507b Content-Type: text/plain; charset="UTF-8" On Sun, Dec 8, 2019 at 5:17 PM Paul Kyzivat wrote: > Hi Rifaat, > > On 12/8/19 7:29 AM, Rifaat Shekh-Yusef wrote: > > Hi Paul, > > > > Thanks for the detailed review. > > > > Regarding the > > > > My problem with this is: the challenge gives the UAC an HTTPS URL of > an > > AS. It does not normatively state how the UAC is to use this, or what > > usage(s) the AS MUST support. Hence there is no assurance that the > UAC > > will be able to successfully access the AS. > > > > This could be resolved by requiring that the UAC and AS MUST support > > RFC8252. Or perhaps there is some more expansive RFC that can be > > referenced. In the end there needs to be something MTI. > > > > > > I think that MUST is too strong in this case. I would be fine with a > > SHOULD, as there are different ways to achieve this based on the type of > > UAC, e.g. a browser-based UAC application. > > Thoughts? > > I agree there can be variation based on type of UAC. E.g., actually > using a browser and having the end user interact with it, vs. a UAC that > is an automaton and doesn't have a user. > > But in the end whatever it is must use the URI as the starting point for > the interaction. With a browser interface presumably the URI is used to > fetch a page that is presented to the user. And the user then can > determine in a human intuitive way how to interact with that page to > complete the authentication. If it is an automaton then that won't work. > It must have *some* way of determining how to interact with the web > server and present what facts it has (e.g. user id and pw) to that > server in order to complete authentication. And in either case, there > must be a well defined way of learning if it succeeded and conveying the > resulting token back to the sip server. > > RFC8252 seems to try to specify this at least in some cases, though it > is still fuzzy to me. This should be deterministic - it shouldn't be > neccessary for an automaton to be specially programmed for how to > interact with the particular AS and how to convey the result back to the > sip server. > > There are different ways that a UAC can act on the HTTPS URI, depending on the type of UAC. Here are few examples: 1. RFC8252 for Native Apps 2. RFC8628 for browser-less devices 3. https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ for browser-based apps New mechanisms could be defined and added to address other use case not covered by existing mechanisms. This is the reason I am really hesitant to add any normative text and require any specific mechanism. I still think this is out of scope for this document, and any text should be informative only. > > Regarding your comment about section 2.1.2, I agree with you; I will > > move it to its own section. > > Moving it to a separate section isn't necessary or sufficient. It needs > to be clarified. > > Ok. I will clarify it. > I'm assuming responses to my other points will be coming later. > > Christer provided feedback on the rest of you comments. Do you have any further comment on Christer's responses? Regards, Rifaat > Thanks, > Paul > > > Regards, > > Rifaat > > > > > > > > On Wed, Dec 4, 2019 at 3:00 AM Christer Holmberg > > > > wrote: > > > > Hi Paul, > > > > My comments on some of your SIP-related issues (I am not addressing > > your issues on Sections 2.1.1 and 2.1.2 in this reply). > > > > > * Section 2.1.4: > > > > > > This section says that the UAC MUST include an Authorization > > header > > > field with the Bearer scheme. This is overly strong. > > > > > > This should be an explanation that *if* it has received a > > challenge > > > containing the Bearer scheme then to resolve that particular > > challenge > > > it needs to send a request with an Authorization header field > > containing > > > the response to that challenge, including the Bearer scheme. > > > > I suggest that we expand the first paragraph in the section. > > Something like: > > > > "The procedures in this section apply when the UAC has received a > > challenge that contains a Bearer scheme, > > and the UAC has obtained a token as specified in section Section > 2.1.1." > > > > > (But note that if there were multiple challenges with > > different schemes > > > then it maybe able to successfully retry the request using > > non-Bearer > > > credentials.) > > > > > > I don't understand what distinction you are trying to draw by > > > distinguishing the behavior for creating a binding from that > for > > > refreshing a binding. AFAIK there should be no difference. And > > in fact > > > the UAC in general cannot know whether the request being send > > will > > > establish or refresh a binding. > > > > It is important to point out that the same access token might not > > necessarily be used throughout the lifetime of the registration, if > > the previously included access token has expired. > > > > --- > > > > > * Section 2.1.5: > > > > > > This section has similar issues to section 2.1.4: The MUST is > too > > > strong, and the reason for distinguishing between in-dialog > > requests > > > from others is unclear. > > > > See my comments for 2.1.4. > > > > --- > > > > > * Section 2.2: > > > > > > Again is overly strong in its use of MUST. I think it is > > evident that > > > the point being made is that a challenge containing Bearer > > scheme is the > > > way to indicate that is with a challenge with Bearer scheme, > > but the > > > text is at least awkward. > > > > > > How about: > > > > > > When a UAS or Registrar receives a request that fails to > > contain > > > authorization credentials acceptable to it, it SHOULD > > challenge the > > > request by sending a 401 (Unauthorized) response. To > > indicate that > > > it is willing to accept an OAuth2 token as a credential the > > > UAS/Registrar MUST include a Proxy-Authentication header > > field in the > > > response, indicate "Bearer" scheme and include an address > > of an > > > Authorization Server from which the originator can obtain > > an access > > > token. > > > > WFM. > > > > > In the second paragraph, please provide a reference: > > > > > > ... using the procedures from [RFC???] associated with the > > type of > > > access token used. > > > > Ok. > > > > --- > > > > > * Section 2.3: > > > > > > Similar comment to section 2.2. How about the following for > > the first > > > paragraph: > > > > > > When a proxy receives a request that fails to contain > > > authorization credentials acceptable to it, it SHOULD > > challenge the > > > request by sending a 407 (Proxy Authentication Required) > > response. > > > To indicate that it is willing to accept an OAuth2 token > as a > > > credential the proxy MUST include a Proxy-Authentication > > > header field in the response, indicating "Bearer" scheme > and > > > including an address to an Authorization Server from which > the > > > originator can obtain an access token. > > > > WFM. > > > > > I don't think the second paragraph should condition any > > behavior on > > > whether it has previously challenged. That requires that the > > proxy be > > > stateful, and it isn't a necessary condition. Instead, how > about: > > > > > > When a proxy wishes to authenticate a received request, it > > MUST > > > search the request for Proxy-Authorization header fields > > with 'realm' > > > parameters that match its realm. It then MUST successfully > > validate > > > the credentials from at least one Proxy-Authorization > > header field > > > for its realm. When the scheme is Bearer the proxy MUST > > validate the > > > access token, using the procedures from [RFC???] > > associated with the > > > type of access token used. > > > > WFM. > > > > --- > > > > > * Section 3: > > > > > > The following: > > > > > > The realm and auth-param parameters are defined in > [RFC3261]. > > > > > > is incomplete, because it is missing 'challenge', 'realm', and > > > 'https-URI. (Where is https-URI defined?) > > > > > > Another way to do this is by adding the following to the syntax: > > > > > > challenge = > > > realm = > > > auth-param = > > > scope = > > > error = > > > https-URI = > > > > > > (This helps those who might try to formally validate the > > syntax because > > > it removes undefined parameters.) > > > > The section does enhance 'challenge', so I guess we can add text > > saying that 'challenge' is defined in RFC 3261. > > > > Regarding the other parameters, the text already says where they are > > defined. > > > > Or, are you saying that you want the references in the syntax, > > rather than in the normative text? > > > > > Also, 'scope' and 'error' are very generic rule names being > > used in a > > > very restricted context. While these are not defined in > > RFC3261, there > > > is the potential conflict with other extensions. I'd recommend > > using > > > more specific terms. E.g., > > > > > > challenge =/ ("Bearer" LWS bearer-cln *(COMMA > > bearer-cln)) > > > bearer-cln = realm / bearer-scope / authz-server / > > bearer-error / > > > auth-param > > > authz-server = "authz_server" EQUAL authz-server-value > > > authz-server-value = https-URI > > > > > > challenge = > > > realm = > > > auth-param = > > > bearer-scope = > > > bearer-error = > > > https-URI = > > > > The HTTP WWW-Authenticate header field uses 'error' and 'scope', and > > I think it would be good to be aligned. > > > > > Regarding the scope parameter: > > > > > > This parameter is conveyed from the registrar to the UAC. But > > what is > > > the UAC to do with it? How does it have any control over the > > scope of > > > the token it gets from the AS? Is the UAC supposed to convey > > this to the > > > AS? If so, how? > > > > The UAC will get the scope from the AS, and will forward it towards > > the UAS/registrar. > > > > > Regarding the error parameter: > > > > > > Is this just intended to be of help in debugging the UAC? Or > > is it > > > expected that the UAC might take some sort of pre-programmed > > action in > > > response? If the latter, how might that work? Is this > information > > > suitable for presentation to the user? > > > > I see no reason why it can't be presented to the user, and I guess > > the UAC actions depend on what the error code is. > > > > However, as the parameter is described in RFC 6749, I don't think we > > need to repeat that in this draft. > > > > --- > > > > > * Section 4: > > > > > > I agree with Dale - I don't see any value in this tag. I tried > > to search > > > for all discussion on the point. The discussion attributes me > > with > > > requesting it, but I don't think I did. > > > > It was Olle who requested it. > > > > However, I don't see any harm in having it. It allows the UAC to > > inform proxies/UAS/Registrar whether it supports the bearer scheme. > > > > --- > > > > > * Missing: > > > > > > I find no syntax extensions for Authorization and > > Proxy-Authorization. > > > These need to be added. > > > > Ok. > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > --00000000000015e4be059996507b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=C2=A0

On Sun, Dec 8, 2019 = at 5:17 PM Paul Kyzivat <pkyziv= at@alum.mit.edu> wrote:
Hi Rifaat,

On 12/8/19 7:29 AM, Rifaat Shekh-Yusef wrote:
> Hi Paul,
>
> Thanks for the detailed=C2=A0review.
>
> Regarding the
>
>=C2=A0 =C2=A0 =C2=A0My problem with this is: the challenge gives the UA= C an HTTPS URL of an
>=C2=A0 =C2=A0 =C2=A0AS. It does not normatively state how the UAC is to= use this, or what
>=C2=A0 =C2=A0 =C2=A0usage(s) the AS MUST support. Hence there is no ass= urance that the UAC
>=C2=A0 =C2=A0 =C2=A0will be able to successfully access the AS.
>
>=C2=A0 =C2=A0 =C2=A0This could be resolved by requiring that the UAC an= d AS MUST support
>=C2=A0 =C2=A0 =C2=A0RFC8252. Or perhaps there is some more expansive RF= C that can be
>=C2=A0 =C2=A0 =C2=A0referenced. In the end there needs to be something = MTI.
>
>
> I think that MUST is too strong in this case. I would be fine with a <= br> > SHOULD, as there are different ways to achieve this based on the type = of
> UAC, e.g. a browser-based UAC application.
> Thoughts?

I agree there can be variation based on type of UAC. E.g., actually
using a browser and having the end user interact with it, vs. a UAC that is an automaton and doesn't have a user.

But in the end whatever it is must use the URI as the starting point for the interaction. With a browser interface presumably the URI is used to fetch a page that is presented to the user. And the user then can
determine in a human intuitive way how to interact with that page to
complete the authentication. If it is an automaton then that won't work= .
It must have *some* way of determining how to interact with the web
server and present what facts it has (e.g. user id and pw) to that
server in order to complete authentication. And in either case, there
must be a well defined way of learning if it succeeded and conveying the resulting token back to the sip server.

RFC8252 seems to try to specify this at least in some cases, though it
is still fuzzy to me. This should be deterministic - it shouldn't be neccessary for an automaton to be specially programmed for how to
interact with the particular AS and how to convey the result back to the sip server.


There are different ways that a UAC ca= n act on the HTTPS URI, depending on the type of UAC.=C2=A0
Here = are few examples:
1. RFC8252 for Native Apps
2. RFC8628= for browser-less devices

New mechanisms could be defined and added to ad= dress other use case not covered by existing mechanisms.

This is the reason I am really hesitant to add any normative text an= d require any specific mechanism.=C2=A0
I still think this is out= of scope for this document, and any text should be informative only.
=

=C2=A0
> Regarding your comment about section 2.1.2, I agree with you; I will <= br> > move it to its own section.

Moving it to a separate section isn't necessary or sufficient. It needs=
to be clarified.

Ok. I will clarify it.

=C2= =A0
I'm assuming responses to my other points will be coming later.


Christer provided feedback on the rest= of you comments. Do you have any further comment on Christer's respons= es?

Regards,
=C2=A0Rifaat

=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> Regards,
>=C2=A0 =C2=A0Rifaat
>
>
>
> On Wed, Dec 4, 2019 at 3:00 AM Christer Holmberg
> <christer.holmberg=3D40ericsson.com@dmarc.ietf.org
> <mailto:40ericsson.com@dmarc.ietf.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Paul,
>
>=C2=A0 =C2=A0 =C2=A0My comments on some of your SIP-related issues (I a= m not addressing
>=C2=A0 =C2=A0 =C2=A0your issues on Sections 2.1.1 and 2.1.2 in this rep= ly).
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Section 2.1.4:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 This section says that the UAC M= UST include an Authorization
>=C2=A0 =C2=A0 =C2=A0header
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 field with the Bearer scheme. Th= is is overly strong.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 This should be an explanation th= at *if* it has received a
>=C2=A0 =C2=A0 =C2=A0challenge
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 containing the Bearer scheme the= n to resolve that particular
>=C2=A0 =C2=A0 =C2=A0challenge
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 it needs to send a request with = an Authorization header field
>=C2=A0 =C2=A0 =C2=A0containing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the response to that challenge, = including the Bearer scheme.
>
>=C2=A0 =C2=A0 =C2=A0I suggest that we expand the first paragraph in the= section.
>=C2=A0 =C2=A0 =C2=A0Something like:
>
>=C2=A0 =C2=A0 =C2=A0"The procedures in this section apply when the= UAC has received a
>=C2=A0 =C2=A0 =C2=A0challenge that contains a Bearer scheme,
>=C2=A0 =C2=A0 =C2=A0and the UAC has obtained a token as specified in se= ction Section 2.1.1."
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 (But note that if there were mul= tiple challenges with
>=C2=A0 =C2=A0 =C2=A0different schemes
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 then it maybe able to successful= ly retry the request using
>=C2=A0 =C2=A0 =C2=A0non-Bearer
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 credentials.)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I don't understand what dist= inction you are trying to draw by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 distinguishing the behavior for = creating a binding from that for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 refreshing a binding. AFAIK ther= e should be no difference. And
>=C2=A0 =C2=A0 =C2=A0in fact
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the UAC in general cannot know w= hether the request being send
>=C2=A0 =C2=A0 =C2=A0will
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 establish or refresh a binding.<= br> >
>=C2=A0 =C2=A0 =C2=A0It is important to point out that the same access t= oken might not
>=C2=A0 =C2=A0 =C2=A0necessarily be used throughout the lifetime of the = registration, if
>=C2=A0 =C2=A0 =C2=A0the previously included access token has expired. >
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Section 2.1.5:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 This section has similar issues = to section 2.1.4: The MUST is too
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 strong, and the reason for disti= nguishing between in-dialog
>=C2=A0 =C2=A0 =C2=A0requests
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 from others is unclear.
>
>=C2=A0 =C2=A0 =C2=A0See my comments for 2.1.4.
>
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Section 2.2:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Again is overly strong in its us= e of MUST. I think it is
>=C2=A0 =C2=A0 =C2=A0evident that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the point being made is that a c= hallenge containing Bearer
>=C2=A0 =C2=A0 =C2=A0scheme is the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 way to indicate that is with a c= hallenge with Bearer scheme,
>=C2=A0 =C2=A0 =C2=A0but the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 text is at least awkward.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 How about:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a UAS or Regi= strar receives a request that fails to
>=C2=A0 =C2=A0 =C2=A0contain
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization cred= entials acceptable to it, it SHOULD
>=C2=A0 =C2=A0 =C2=A0challenge the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 request by sending= a 401 (Unauthorized) response. To
>=C2=A0 =C2=A0 =C2=A0indicate that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 it is willing to a= ccept an OAuth2 token as a credential the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 UAS/Registrar MUST= include a Proxy-Authentication header
>=C2=A0 =C2=A0 =C2=A0field in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 response, indicate= "Bearer" scheme and include an address
>=C2=A0 =C2=A0 =C2=A0of an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authorization Serv= er from which the originator can obtain
>=C2=A0 =C2=A0 =C2=A0an access
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 token.
>
>=C2=A0 =C2=A0 =C2=A0WFM.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 In the second paragraph, please = provide a reference:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... using the proc= edures from [RFC???] associated with the
>=C2=A0 =C2=A0 =C2=A0type of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 access token used.=
>
>=C2=A0 =C2=A0 =C2=A0Ok.
>
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Section 2.3:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Similar comment to section 2.2. = How about the following for
>=C2=A0 =C2=A0 =C2=A0the first
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 paragraph:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a proxy recei= ves a request that fails to contain
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 authorization cred= entials acceptable to it, it SHOULD
>=C2=A0 =C2=A0 =C2=A0challenge the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 request by sending= a 407 (Proxy Authentication Required)
>=C2=A0 =C2=A0 =C2=A0response.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 To indicate that i= t is willing to accept an OAuth2 token as a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 credential the pro= xy MUST include a Proxy-Authentication
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 header field in th= e response, indicating "Bearer" scheme and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 including an addre= ss to an Authorization Server from which the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 originator can obt= ain an access token.
>
>=C2=A0 =C2=A0 =C2=A0WFM.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I don't think the second par= agraph should condition any
>=C2=A0 =C2=A0 =C2=A0behavior on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 whether it has previously challe= nged. That requires that the
>=C2=A0 =C2=A0 =C2=A0proxy be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 stateful, and it isn't a nec= essary condition. Instead, how about:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 When a proxy wishe= s to authenticate a received request, it
>=C2=A0 =C2=A0 =C2=A0MUST
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 search the request= for Proxy-Authorization header fields
>=C2=A0 =C2=A0 =C2=A0with 'realm'
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 parameters that ma= tch its realm. It then MUST successfully
>=C2=A0 =C2=A0 =C2=A0validate
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the credentials fr= om at least one Proxy-Authorization
>=C2=A0 =C2=A0 =C2=A0header field
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 for its realm. Whe= n the scheme is Bearer the proxy MUST
>=C2=A0 =C2=A0 =C2=A0validate the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 access token, usin= g the procedures from [RFC???]
>=C2=A0 =C2=A0 =C2=A0associated with the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 type of access tok= en used.
>
>=C2=A0 =C2=A0 =C2=A0WFM.
>
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Section 3:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 The following:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 The realm and auth= -param parameters are defined in [RFC3261].
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 is incomplete, because it is mis= sing 'challenge', 'realm', and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 'https-URI. (Where is https-= URI defined?)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Another way to do this is by=C2=A0 adding the= following to the syntax:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chal= lenge =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 real= m =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth= -param =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scop= e =3D <defined in RFC6749>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 erro= r =3D <defined in RFC6749>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http= s-URI =3D <where???>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 (This helps those who might try = to formally validate the
>=C2=A0 =C2=A0 =C2=A0syntax because
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 it removes undefined parameters.= )
>
>=C2=A0 =C2=A0 =C2=A0The section does enhance 'challenge', so I = guess we can add text
>=C2=A0 =C2=A0 =C2=A0saying that 'challenge' is defined in RFC 3= 261.
>
>=C2=A0 =C2=A0 =C2=A0Regarding the other parameters, the text already sa= ys where they are
>=C2=A0 =C2=A0 =C2=A0defined.
>
>=C2=A0 =C2=A0 =C2=A0Or, are you saying that you want the references in = the syntax,
>=C2=A0 =C2=A0 =C2=A0rather than in the normative text?
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Also, 'scope' and 'e= rror' are very generic rule names being
>=C2=A0 =C2=A0 =C2=A0used in a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 very restricted context. While t= hese are not defined in
>=C2=A0 =C2=A0 =C2=A0RFC3261, there
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 is the potential conflict with o= ther extensions. I'd recommend
>=C2=A0 =C2=A0 =C2=A0using
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 more specific terms. E.g.,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chal= lenge=C2=A0 =3D/=C2=A0 ("Bearer" LWS bearer-cln *(COMMA
>=C2=A0 =C2=A0 =C2=A0bearer-cln))
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bear= er-cln =3D realm / bearer-scope / authz-server /
>=C2=A0 =C2=A0 =C2=A0bearer-error /
>=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 =C2=A0 =C2=A0 =C2=A0auth-param
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth= z-server =3D "authz_server" EQUAL authz-server-value
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth= z-server-value =3D https-URI
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chal= lenge =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 real= m =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auth= -param =3D <defined in RFC3261>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bear= er-scope =3D <defined as scope in RFC6749>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bear= er-error =3D <defined as error in RFC6749>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http= s-URI =3D <where???>
>
>=C2=A0 =C2=A0 =C2=A0The HTTP WWW-Authenticate header field uses 'er= ror' and 'scope', and
>=C2=A0 =C2=A0 =C2=A0I think it would be good to be aligned.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Regarding the scope parameter: >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 This parameter is conveyed from = the registrar to the UAC. But
>=C2=A0 =C2=A0 =C2=A0what is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the UAC to do with it? How does = it have any control over the
>=C2=A0 =C2=A0 =C2=A0scope of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 the token it gets from the AS? I= s the UAC supposed to convey
>=C2=A0 =C2=A0 =C2=A0this to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 AS? If so, how?
>
>=C2=A0 =C2=A0 =C2=A0The UAC will get the scope from the AS, and will fo= rward it towards
>=C2=A0 =C2=A0 =C2=A0the UAS/registrar.
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Regarding the error parameter: >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 Is this just intended to be of h= elp in debugging the UAC? Or
>=C2=A0 =C2=A0 =C2=A0is it
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 expected that the UAC might take= some sort of pre-programmed
>=C2=A0 =C2=A0 =C2=A0action in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 response? If the latter, how mig= ht that work? Is this information
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 suitable for presentation to the= user?
>
>=C2=A0 =C2=A0 =C2=A0I see no reason why it can't be presented to th= e user, and I guess
>=C2=A0 =C2=A0 =C2=A0the UAC actions depend on what the error code is. >
>=C2=A0 =C2=A0 =C2=A0However, as the parameter is described in RFC 6749,= I don't think we
>=C2=A0 =C2=A0 =C2=A0need to repeat that in this draft.
>
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Section 4:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I agree with Dale - I don't = see any value in this tag. I tried
>=C2=A0 =C2=A0 =C2=A0to search
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 for all discussion on the point.= The discussion attributes me
>=C2=A0 =C2=A0 =C2=A0with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 requesting it, but I don't t= hink I did.
>
>=C2=A0 =C2=A0 =C2=A0It was Olle who requested it.
>
>=C2=A0 =C2=A0 =C2=A0However, I don't see any harm in having it. It = allows the UAC to
>=C2=A0 =C2=A0 =C2=A0inform proxies/UAS/Registrar whether it supports th= e bearer scheme.
>
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 * Missing:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 I find no syntax extensions for = Authorization and
>=C2=A0 =C2=A0 =C2=A0Proxy-Authorization.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 These need to be added.
>
>=C2=A0 =C2=A0 =C2=A0Ok.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>
>=C2=A0 =C2=A0 =C2=A0Christer
>
>
>
>=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
>

--00000000000015e4be059996507b-- From nobody Fri Dec 13 06:57:44 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 B618C120219 for ; Fri, 13 Dec 2019 06:57:42 -0800 (PST) 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=unavailable 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 MtZM5Mb9mS9I for ; Fri, 13 Dec 2019 06:57:39 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10072.outbound.protection.outlook.com [40.107.1.72]) (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 9FD2C12011D for ; Fri, 13 Dec 2019 06:57:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WAcK2Ec6NEWyJmkUhmYBiZ5RyT0xGr8ftQm8rn9qh90fyiTP+Jk5B6coHopR34BYGgZRMaTIiNGJNJCxdljGgJTYd6NlM7R/pcXow2HfHX/cz54CIwelycBvGAP8ONPur5aRCrgfNpKLsFnqwBnuIbfIOJdNz2I66Wd1PID/C7VOwu/Hm2QaHJmL0mq/u6Z/UX4L9gn/do++RzKubVGrteCZsMMkDGQNExFicwLqd/1g1xVUVIb5O7SDbN0VTHKHWL+Xii6eEAvMDLKIcTmb1IHSWGOZdcGkB9e9Z6WihVj4t6CB+k49VO0j58ceoqgecdZvbCFZPFZXOuGhSAGO+g== 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=OwZNAey7xrVERX7pa+aHiDGOnR4/qeSNr1J5hXjkEWQ=; b=PRvz4SGIm+ZWYyZITTmNxogR4ByuzSK3a5RTbtSy9Z6W01ChtUoudeYFlfCjg6QbqH71xFFe6AdOFnYqRKIKwUXBpjn8gvBsTE/0d3rcNYqa2refqR1DZH3jJW2M6OBNaoAkO5qB0SUtCnoogi35wj0uZQLZXF0vsWFDHGXnP6kzUc5qNNS1sWXi0CshDwtg/BU2I74Syx7mmVxl9EWcHxxnf8EY3AIPkzjD7LZi4xyjDb3nlrJFkUBjFe/YUEulmPPmjBodHh823zzfNV/NltRMbEOmhNN0bTH+OSgbOFYfKQIY50GfeqGbDS9kLqXvnErvHIga1O+HKxxnQvBUFg== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OwZNAey7xrVERX7pa+aHiDGOnR4/qeSNr1J5hXjkEWQ=; b=EsDcV1J5/g1Ci9zCOv/TtfO1ijHwZO1wbyPJL/UYNUYykvr3mhGtuPy7AsVRzjeuehVqvf75BRRr6zogyd21kf279GHCXq1eItScry2JjzJRvRyllT9Bot4N4kscE+xaU15loaww+7+/DE7SAwbUYMILiDCK06W6DszlmS7A3Ko= Received: from DB6PR0701MB2421.eurprd07.prod.outlook.com (10.168.73.16) by DB6PR0701MB2470.eurprd07.prod.outlook.com (10.168.75.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.8; Fri, 13 Dec 2019 14:57:35 +0000 Received: from DB6PR0701MB2421.eurprd07.prod.outlook.com ([fe80::39bd:a590:dcd9:201e]) by DB6PR0701MB2421.eurprd07.prod.outlook.com ([fe80::39bd:a590:dcd9:201e%10]) with mapi id 15.20.2538.017; Fri, 13 Dec 2019 14:57:35 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Paul Kyzivat CC: "sipcore@ietf.org" , Christer Holmberg Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Thread-Index: AQHVqRaq+n57bvgHbkmAxusa4398hqeoufCAgAEHG4CABnMOAIAApGKAgAdRNgCAADD0gA== Date: Fri, 13 Dec 2019 14:57:35 +0000 Message-ID: <336998CA-02F4-49AE-B080-CE0C54BBA249@ericsson.com> References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14b8:1829:11:ac6f:23b1:739f:922] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba7bea72-5311-45c6-98a7-08d77fdcca3c x-ms-traffictypediagnostic: DB6PR0701MB2470: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(346002)(376002)(366004)(51914003)(51444003)(199004)(189003)(44832011)(6506007)(2616005)(8676002)(316002)(4326008)(86362001)(186003)(71200400001)(478600001)(110136005)(54906003)(6512007)(966005)(66574012)(33656002)(8936002)(81166006)(2906002)(66556008)(91956017)(76116006)(66946007)(6486002)(66446008)(64756008)(81156014)(66476007)(36756003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2470; H:DB6PR0701MB2421.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: BCL:0; x-microsoft-antispam-message-info: XYORy+As3zI3JUj3+8LuGsP+Cyoq/luDf/HClb5cFS+WAQrICu4cSXmH9DhCtUPqcN0Vv40gByvWPrKdgJ6n5/R+6PyzRNlqCJu6ARqKTXQyWTaDdAm0yrsoszKCKMwDx8eiN81RAwNUuB4lcWZCzbE1+qMe51jjDdWih4+nVoqufHui61mai6RefAR8znfujel55KUzxXhKfvyWiTilG62mSC8p+D7mpIeD/qgGJj8nicT6mxDgnWT9rAX2wvQ3r5mnWP2RAdKerEZjqE3naSlf/daoR7EdpyOnFmw3tjiEF0EkZgbpZS4QozAQjanlU4xGsCxmIpJc7JwnCEWSNfl6oaMeox/b/ja0B36WZI0HPQneliPYBTxDNgEzBjnNKqWICBZAqpVlmpkFvNJuBgJ+e/W08A7ej8r8ZPezutUZWjEfeeHc0IWDAvJ9/qmbmB7VdoF+5j9exHRfxuHC8ErR4yoU3pNsHWL6A5k3cAsSGr0haBms7DTC2oACR7iddkxazG/+ABIhVyK/8mUa3WvWIx4HVairl8v/blfmQahEFt+9+rrKJwVstTQlhVHn x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0E86B048B60BEB4BB424FC75BF1690AF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba7bea72-5311-45c6-98a7-08d77fdcca3c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 14:57:35.7406 (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: ZjAG0foea29YSH2S4Or6fMlxuNo71JOj+J0T2RHKEdP80q1ke6RMOJEfLS+X2S1m4Ul865IHVBtq307FC1yMU08KO7MbOcGFgr6J4vjLVik= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2470 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 13 Dec 2019 14:57:43 -0000 SGksDQoNCj4+PiBUaGFua3MgZm9yIHRoZSBkZXRhaWxlZMKgcmV2aWV3Lg0KPj4+IA0KPj4+IFJl Z2FyZGluZyB0aGUNCj4+PiANCj4+PsKgIMKgIMKgTXkgcHJvYmxlbSB3aXRoIHRoaXMgaXM6IHRo ZSBjaGFsbGVuZ2UgZ2l2ZXMgdGhlIFVBQyBhbiBIVFRQUyBVUkwgb2YgYW4NCj4+PsKgIMKgIMKg QVMuIEl0IGRvZXMgbm90IG5vcm1hdGl2ZWx5IHN0YXRlIGhvdyB0aGUgVUFDIGlzIHRvIHVzZSB0 aGlzLCBvciB3aGF0DQo+Pj7CoCDCoCDCoHVzYWdlKHMpIHRoZSBBUyBNVVNUIHN1cHBvcnQuIEhl bmNlIHRoZXJlIGlzIG5vIGFzc3VyYW5jZSB0aGF0IHRoZSBVQUMNCj4+PsKgIMKgIMKgd2lsbCBi ZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSBhY2Nlc3MgdGhlIEFTLg0KPj4+IA0KPj4+wqAgwqAgwqBU aGlzIGNvdWxkIGJlIHJlc29sdmVkIGJ5IHJlcXVpcmluZyB0aGF0IHRoZSBVQUMgYW5kIEFTIE1V U1Qgc3VwcG9ydA0KPj4+wqAgwqAgwqBSRkM4MjUyLiBPciBwZXJoYXBzIHRoZXJlIGlzIHNvbWUg bW9yZSBleHBhbnNpdmUgUkZDIHRoYXQgY2FuIGJlDQo+Pj7CoCDCoCDCoHJlZmVyZW5jZWQuIElu IHRoZSBlbmQgdGhlcmUgbmVlZHMgdG8gYmUgc29tZXRoaW5nIE1USS4gDQo+Pj4gDQo+Pj4gDQo+ Pj4gSSB0aGluayB0aGF0IE1VU1QgaXMgdG9vIHN0cm9uZyBpbiB0aGlzIGNhc2UuIEkgd291bGQg YmUgZmluZSB3aXRoIGEgDQo+Pj4gU0hPVUxELCBhcyB0aGVyZSBhcmUgZGlmZmVyZW50IHdheXMg dG8gYWNoaWV2ZSB0aGlzIGJhc2VkIG9uIHRoZSB0eXBlIG9mIA0KPj4+IFVBQywgZS5nLiBhIGJy b3dzZXItYmFzZWQgVUFDIGFwcGxpY2F0aW9uLg0KPj4+IFRob3VnaHRzPw0KPj4NCj4+IEkgYWdy ZWUgdGhlcmUgY2FuIGJlIHZhcmlhdGlvbiBiYXNlZCBvbiB0eXBlIG9mIFVBQy4gRS5nLiwgYWN0 dWFsbHkgDQo+PiB1c2luZyBhIGJyb3dzZXIgYW5kIGhhdmluZyB0aGUgZW5kIHVzZXIgaW50ZXJh Y3Qgd2l0aCBpdCwgdnMuIGEgVUFDIHRoYXQgDQo+PiBpcyBhbiBhdXRvbWF0b24gYW5kIGRvZXNu J3QgaGF2ZSBhIHVzZXIuDQo+Pg0KPj4gQnV0IGluIHRoZSBlbmQgd2hhdGV2ZXIgaXQgaXMgbXVz dCB1c2UgdGhlIFVSSSBhcyB0aGUgc3RhcnRpbmcgcG9pbnQgZm9yIA0KPj4gdGhlIGludGVyYWN0 aW9uLiBXaXRoIGEgYnJvd3NlciBpbnRlcmZhY2UgcHJlc3VtYWJseSB0aGUgVVJJIGlzIHVzZWQg dG8gDQo+PiBmZXRjaCBhIHBhZ2UgdGhhdCBpcyBwcmVzZW50ZWQgdG8gdGhlIHVzZXIuIEFuZCB0 aGUgdXNlciB0aGVuIGNhbiANCj4+IGRldGVybWluZSBpbiBhIGh1bWFuIGludHVpdGl2ZSB3YXkg aG93IHRvIGludGVyYWN0IHdpdGggdGhhdCBwYWdlIHRvIA0KPj4gY29tcGxldGUgdGhlIGF1dGhl bnRpY2F0aW9uLiBJZiBpdCBpcyBhbiBhdXRvbWF0b24gdGhlbiB0aGF0IHdvbid0IHdvcmsuLiAN Cj4+IEl0IG11c3QgaGF2ZSAqc29tZSogd2F5IG9mIGRldGVybWluaW5nIGhvdyB0byBpbnRlcmFj dCB3aXRoIHRoZSB3ZWIgDQo+PiBzZXJ2ZXIgYW5kIHByZXNlbnQgd2hhdCBmYWN0cyBpdCBoYXMg KGUuZy4gdXNlciBpZCBhbmQgcHcpIHRvIHRoYXQgDQo+PiBzZXJ2ZXIgaW4gb3JkZXIgdG8gY29t cGxldGUgYXV0aGVudGljYXRpb24uIEFuZCBpbiBlaXRoZXIgY2FzZSwgdGhlcmUgDQo+PiBtdXN0 IGJlIGEgd2VsbCBkZWZpbmVkIHdheSBvZiBsZWFybmluZyBpZiBpdCBzdWNjZWVkZWQgYW5kIGNv bnZleWluZyB0aGUgDQo+PiByZXN1bHRpbmcgdG9rZW4gYmFjayB0byB0aGUgc2lwIHNlcnZlci4N Cj4+DQo+PiBSRkM4MjUyIHNlZW1zIHRvIHRyeSB0byBzcGVjaWZ5IHRoaXMgYXQgbGVhc3QgaW4g c29tZSBjYXNlcywgdGhvdWdoIGl0IA0KPj4gaXMgc3RpbGwgZnV6enkgdG8gbWUuIFRoaXMgc2hv dWxkIGJlIGRldGVybWluaXN0aWMgLSBpdCBzaG91bGRuJ3QgYmUgDQo+PiBuZWNjZXNzYXJ5IGZv ciBhbiBhdXRvbWF0b24gdG8gYmUgc3BlY2lhbGx5IHByb2dyYW1tZWQgZm9yIGhvdyB0byANCj4+ IGludGVyYWN0IHdpdGggdGhlIHBhcnRpY3VsYXIgQVMgYW5kIGhvdyB0byBjb252ZXkgdGhlIHJl c3VsdCBiYWNrIHRvIHRoZSANCj4+IHNpcCBzZXJ2ZXIuDQo+DQo+IFRoZXJlIGFyZSBkaWZmZXJl bnQgd2F5cyB0aGF0IGEgVUFDIGNhbiBhY3Qgb24gdGhlIEhUVFBTIFVSSSwgZGVwZW5kaW5nIG9u IHRoZSB0eXBlIG9mIFVBQy7CoA0KPiBIZXJlIGFyZSBmZXcgZXhhbXBsZXM6DQo+IDEuIFJGQzgy NTIgZm9yIE5hdGl2ZSBBcHBzDQo+IDIuIFJGQzg2MjggZm9yIGJyb3dzZXItbGVzcyBkZXZpY2Vz DQo+IDMuwqBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRo LWJyb3dzZXItYmFzZWQtYXBwcy/CoGZvciBicm93c2VyLWJhc2VkIGFwcHMNCj4NCj4gTmV3IG1l Y2hhbmlzbXMgY291bGQgYmUgZGVmaW5lZCBhbmQgYWRkZWQgdG8gYWRkcmVzcyBvdGhlciB1c2Ug Y2FzZSBub3QgY292ZXJlZCBieSBleGlzdGluZyBtZWNoYW5pc21zLg0KPg0KPiBUaGlzIGlzIHRo ZSByZWFzb24gSSBhbSByZWFsbHkgaGVzaXRhbnQgdG8gYWRkIGFueSBub3JtYXRpdmUgdGV4dCBh bmQgcmVxdWlyZSBhbnkgc3BlY2lmaWMgbWVjaGFuaXNtLsKgDQo+IEkgc3RpbGwgdGhpbmsgdGhp cyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQsIGFuZCBhbnkgdGV4dCBzaG91bGQg YmUgaW5mb3JtYXRpdmUgb25seS4NCg0KSSBhZ3JlZS4gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KDQoNCg0KDQoNCj4gPG1haWx0bzptYWlsdG86NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0 Zi5vcmc+PiB3cm90ZToNCj4gDQo+wqAgwqAgwqBIaSBQYXVsLA0KPiANCj7CoCDCoCDCoE15IGNv bW1lbnRzIG9uIHNvbWUgb2YgeW91ciBTSVAtcmVsYXRlZCBpc3N1ZXMgKEkgYW0gbm90IGFkZHJl c3NpbmcNCj7CoCDCoCDCoHlvdXIgaXNzdWVzIG9uIFNlY3Rpb25zIDIuMS4xIGFuZCAyLjEuMiBp biB0aGlzIHJlcGx5KS4NCj4gDQo+wqAgwqAgwqAgPsKgIMKgICogU2VjdGlvbiAyLjEuNDoNCj7C oCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKgIFRoaXMgc2VjdGlvbiBzYXlzIHRoYXQgdGhlIFVB QyBNVVNUIGluY2x1ZGUgYW4gQXV0aG9yaXphdGlvbg0KPsKgIMKgIMKgaGVhZGVyDQo+wqAgwqAg wqAgPsKgIMKgIGZpZWxkIHdpdGggdGhlIEJlYXJlciBzY2hlbWUuIFRoaXMgaXMgb3Zlcmx5IHN0 cm9uZy4NCj7CoCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKgIFRoaXMgc2hvdWxkIGJlIGFuIGV4 cGxhbmF0aW9uIHRoYXQgKmlmKiBpdCBoYXMgcmVjZWl2ZWQgYQ0KPsKgIMKgIMKgY2hhbGxlbmdl DQo+wqAgwqAgwqAgPsKgIMKgIGNvbnRhaW5pbmcgdGhlIEJlYXJlciBzY2hlbWUgdGhlbiB0byBy ZXNvbHZlIHRoYXQgcGFydGljdWxhcg0KPsKgIMKgIMKgY2hhbGxlbmdlDQo+wqAgwqAgwqAgPsKg IMKgIGl0IG5lZWRzIHRvIHNlbmQgYSByZXF1ZXN0IHdpdGggYW4gQXV0aG9yaXphdGlvbiBoZWFk ZXIgZmllbGQNCj7CoCDCoCDCoGNvbnRhaW5pbmcNCj7CoCDCoCDCoCA+wqAgwqAgdGhlIHJlc3Bv bnNlIHRvIHRoYXQgY2hhbGxlbmdlLCBpbmNsdWRpbmcgdGhlIEJlYXJlciBzY2hlbWUuDQo+IA0K PsKgIMKgIMKgSSBzdWdnZXN0IHRoYXQgd2UgZXhwYW5kIHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4g dGhlIHNlY3Rpb24uDQo+wqAgwqAgwqBTb21ldGhpbmcgbGlrZToNCj4gDQo+wqAgwqAgwqAiVGhl IHByb2NlZHVyZXMgaW4gdGhpcyBzZWN0aW9uIGFwcGx5IHdoZW4gdGhlIFVBQyBoYXMgcmVjZWl2 ZWQgYQ0KPsKgIMKgIMKgY2hhbGxlbmdlIHRoYXQgY29udGFpbnMgYSBCZWFyZXIgc2NoZW1lLA0K PsKgIMKgIMKgYW5kIHRoZSBVQUMgaGFzIG9idGFpbmVkIGEgdG9rZW4gYXMgc3BlY2lmaWVkIGlu IHNlY3Rpb24gU2VjdGlvbiAyLjEuMS4iDQo+IA0KPsKgIMKgIMKgID7CoCDCoCAoQnV0IG5vdGUg dGhhdCBpZiB0aGVyZSB3ZXJlIG11bHRpcGxlIGNoYWxsZW5nZXMgd2l0aA0KPsKgIMKgIMKgZGlm ZmVyZW50IHNjaGVtZXMNCj7CoCDCoCDCoCA+wqAgwqAgdGhlbiBpdCBtYXliZSBhYmxlIHRvIHN1 Y2Nlc3NmdWxseSByZXRyeSB0aGUgcmVxdWVzdCB1c2luZw0KPsKgIMKgIMKgbm9uLUJlYXJlcg0K PsKgIMKgIMKgID7CoCDCoCBjcmVkZW50aWFscy4pDQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKgID7C oCDCoCBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCBkaXN0aW5jdGlvbiB5b3UgYXJlIHRyeWluZyB0 byBkcmF3IGJ5DQo+wqAgwqAgwqAgPsKgIMKgIGRpc3Rpbmd1aXNoaW5nIHRoZSBiZWhhdmlvciBm b3IgY3JlYXRpbmcgYSBiaW5kaW5nIGZyb20gdGhhdCBmb3INCj7CoCDCoCDCoCA+wqAgwqAgcmVm cmVzaGluZyBhIGJpbmRpbmcuIEFGQUlLIHRoZXJlIHNob3VsZCBiZSBubyBkaWZmZXJlbmNlLiBB bmQNCj7CoCDCoCDCoGluIGZhY3QNCj7CoCDCoCDCoCA+wqAgwqAgdGhlIFVBQyBpbiBnZW5lcmFs IGNhbm5vdCBrbm93IHdoZXRoZXIgdGhlIHJlcXVlc3QgYmVpbmcgc2VuZA0KPsKgIMKgIMKgd2ls bA0KPsKgIMKgIMKgID7CoCDCoCBlc3RhYmxpc2ggb3IgcmVmcmVzaCBhIGJpbmRpbmcuDQo+IA0K PsKgIMKgIMKgSXQgaXMgaW1wb3J0YW50IHRvIHBvaW50IG91dCB0aGF0IHRoZSBzYW1lIGFjY2Vz cyB0b2tlbiBtaWdodCBub3QNCj7CoCDCoCDCoG5lY2Vzc2FyaWx5IGJlIHVzZWQgdGhyb3VnaG91 dCB0aGUgbGlmZXRpbWUgb2YgdGhlIHJlZ2lzdHJhdGlvbiwgaWYNCj7CoCDCoCDCoHRoZSBwcmV2 aW91c2x5IGluY2x1ZGVkIGFjY2VzcyB0b2tlbiBoYXMgZXhwaXJlZC4NCj4gDQo+wqAgwqAgwqAt LS0NCj4gDQo+wqAgwqAgwqAgPsKgIMKgICogU2VjdGlvbiAyLjEuNToNCj7CoCDCoCDCoCA+DQo+ wqAgwqAgwqAgPsKgIMKgIFRoaXMgc2VjdGlvbiBoYXMgc2ltaWxhciBpc3N1ZXMgdG8gc2VjdGlv biAyLjEuNDogVGhlIE1VU1QgaXMgdG9vDQo+wqAgwqAgwqAgPsKgIMKgIHN0cm9uZywgYW5kIHRo ZSByZWFzb24gZm9yIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gaW4tZGlhbG9nDQo+wqAgwqAgwqBy ZXF1ZXN0cw0KPsKgIMKgIMKgID7CoCDCoCBmcm9tIG90aGVycyBpcyB1bmNsZWFyLg0KPiANCj7C oCDCoCDCoFNlZSBteSBjb21tZW50cyBmb3IgMi4xLjQuDQo+IA0KPsKgIMKgIMKgLS0tDQo+IA0K PsKgIMKgIMKgID7CoCDCoCAqIFNlY3Rpb24gMi4yOg0KPsKgIMKgIMKgID4NCj7CoCDCoCDCoCA+ wqAgwqAgQWdhaW4gaXMgb3Zlcmx5IHN0cm9uZyBpbiBpdHMgdXNlIG9mIE1VU1QuIEkgdGhpbmsg aXQgaXMNCj7CoCDCoCDCoGV2aWRlbnQgdGhhdA0KPsKgIMKgIMKgID7CoCDCoCB0aGUgcG9pbnQg YmVpbmcgbWFkZSBpcyB0aGF0IGEgY2hhbGxlbmdlIGNvbnRhaW5pbmcgQmVhcmVyDQo+wqAgwqAg wqBzY2hlbWUgaXMgdGhlDQo+wqAgwqAgwqAgPsKgIMKgIHdheSB0byBpbmRpY2F0ZSB0aGF0IGlz IHdpdGggYSBjaGFsbGVuZ2Ugd2l0aCBCZWFyZXIgc2NoZW1lLA0KPsKgIMKgIMKgYnV0IHRoZQ0K PsKgIMKgIMKgID7CoCDCoCB0ZXh0IGlzIGF0IGxlYXN0IGF3a3dhcmQuDQo+wqAgwqAgwqAgPg0K PsKgIMKgIMKgID7CoCDCoCBIb3cgYWJvdXQ6DQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKgID7CoCDC oCDCoCDCoCBXaGVuIGEgVUFTIG9yIFJlZ2lzdHJhciByZWNlaXZlcyBhIHJlcXVlc3QgdGhhdCBm YWlscyB0bw0KPsKgIMKgIMKgY29udGFpbg0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCBhdXRob3Jp emF0aW9uIGNyZWRlbnRpYWxzIGFjY2VwdGFibGUgdG8gaXQsIGl0IFNIT1VMRA0KPsKgIMKgIMKg Y2hhbGxlbmdlIHRoZQ0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCByZXF1ZXN0IGJ5IHNlbmRpbmcg YSA0MDEgKFVuYXV0aG9yaXplZCkgcmVzcG9uc2UuIFRvDQo+wqAgwqAgwqBpbmRpY2F0ZSB0aGF0 DQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIGl0IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIE9BdXRo MiB0b2tlbiBhcyBhIGNyZWRlbnRpYWwgdGhlDQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIFVBUy9S ZWdpc3RyYXIgTVVTVCBpbmNsdWRlIGEgUHJveHktQXV0aGVudGljYXRpb24gaGVhZGVyDQo+wqAg wqAgwqBmaWVsZCBpbiB0aGUNCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgcmVzcG9uc2UsIGluZGlj YXRlICJCZWFyZXIiIHNjaGVtZSBhbmQgaW5jbHVkZSBhbiBhZGRyZXNzDQo+wqAgwqAgwqBvZiBh bg0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCBBdXRob3JpemF0aW9uIFNlcnZlciBmcm9tIHdoaWNo IHRoZSBvcmlnaW5hdG9yIGNhbiBvYnRhaW4NCj7CoCDCoCDCoGFuIGFjY2Vzcw0KPsKgIMKgIMKg ID7CoCDCoCDCoCDCoCB0b2tlbi4NCj4gDQo+wqAgwqAgwqBXRk0uDQo+IA0KPsKgIMKgIMKgID7C oCDCoCBJbiB0aGUgc2Vjb25kIHBhcmFncmFwaCwgcGxlYXNlIHByb3ZpZGUgYSByZWZlcmVuY2U6 DQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCAuLi4gdXNpbmcgdGhlIHByb2Nl ZHVyZXMgZnJvbSBbUkZDPz8/XSBhc3NvY2lhdGVkIHdpdGggdGhlDQo+wqAgwqAgwqB0eXBlIG9m DQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIGFjY2VzcyB0b2tlbiB1c2VkLg0KPiANCj7CoCDCoCDC oE9rLg0KPiANCj7CoCDCoCDCoC0tLQ0KPiANCj7CoCDCoCDCoCA+wqAgwqAgKiBTZWN0aW9uIDIu MzoNCj7CoCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKgIFNpbWlsYXIgY29tbWVudCB0byBzZWN0 aW9uIDIuMi4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgZm9yDQo+wqAgwqAgwqB0aGUgZmlyc3QN Cj7CoCDCoCDCoCA+wqAgwqAgcGFyYWdyYXBoOg0KPsKgIMKgIMKgID4NCj7CoCDCoCDCoCA+wqAg wqAgwqAgwqAgV2hlbiBhIHByb3h5IHJlY2VpdmVzIGEgcmVxdWVzdCB0aGF0IGZhaWxzIHRvIGNv bnRhaW4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgYXV0aG9yaXphdGlvbiBjcmVkZW50aWFscyBh Y2NlcHRhYmxlIHRvIGl0LCBpdCBTSE9VTEQNCj7CoCDCoCDCoGNoYWxsZW5nZSB0aGUNCj7CoCDC oCDCoCA+wqAgwqAgwqAgwqAgcmVxdWVzdCBieSBzZW5kaW5nIGEgNDA3IChQcm94eSBBdXRoZW50 aWNhdGlvbiBSZXF1aXJlZCkNCj7CoCDCoCDCoHJlc3BvbnNlLg0KPsKgIMKgIMKgID7CoCDCoCDC oCDCoCBUbyBpbmRpY2F0ZSB0aGF0IGl0IGlzIHdpbGxpbmcgdG8gYWNjZXB0IGFuIE9BdXRoMiB0 b2tlbiBhcyBhDQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIGNyZWRlbnRpYWwgdGhlIHByb3h5IE1V U1QgaW5jbHVkZSBhIFByb3h5LUF1dGhlbnRpY2F0aW9uDQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKg IGhlYWRlciBmaWVsZCBpbiB0aGUgcmVzcG9uc2UsIGluZGljYXRpbmcgIkJlYXJlciIgc2NoZW1l IGFuZA0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCBpbmNsdWRpbmcgYW4gYWRkcmVzcyB0byBhbiBB dXRob3JpemF0aW9uIFNlcnZlciBmcm9tIHdoaWNoIHRoZQ0KPsKgIMKgIMKgID7CoCDCoCDCoCDC oCBvcmlnaW5hdG9yIGNhbiBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLg0KPiANCj7CoCDCoCDCoFdG TS4NCj4gDQo+wqAgwqAgwqAgPsKgIMKgIEkgZG9uJ3QgdGhpbmsgdGhlIHNlY29uZCBwYXJhZ3Jh cGggc2hvdWxkIGNvbmRpdGlvbiBhbnkNCj7CoCDCoCDCoGJlaGF2aW9yIG9uDQo+wqAgwqAgwqAg PsKgIMKgIHdoZXRoZXIgaXQgaGFzIHByZXZpb3VzbHkgY2hhbGxlbmdlZC4gVGhhdCByZXF1aXJl cyB0aGF0IHRoZQ0KPsKgIMKgIMKgcHJveHkgYmUNCj7CoCDCoCDCoCA+wqAgwqAgc3RhdGVmdWws IGFuZCBpdCBpc24ndCBhIG5lY2Vzc2FyeSBjb25kaXRpb24uIEluc3RlYWQsIGhvdyBhYm91dDoN Cj7CoCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIFdoZW4gYSBwcm94eSB3aXNoZXMg dG8gYXV0aGVudGljYXRlIGEgcmVjZWl2ZWQgcmVxdWVzdCwgaXQNCj7CoCDCoCDCoE1VU1QNCj7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgc2VhcmNoIHRoZSByZXF1ZXN0IGZvciBQcm94eS1BdXRob3Jp emF0aW9uIGhlYWRlciBmaWVsZHMNCj7CoCDCoCDCoHdpdGggJ3JlYWxtJw0KPsKgIMKgIMKgID7C oCDCoCDCoCDCoCBwYXJhbWV0ZXJzIHRoYXQgbWF0Y2ggaXRzIHJlYWxtLiBJdCB0aGVuIE1VU1Qg c3VjY2Vzc2Z1bGx5DQo+wqAgwqAgwqB2YWxpZGF0ZQ0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCB0 aGUgY3JlZGVudGlhbHMgZnJvbSBhdCBsZWFzdCBvbmUgUHJveHktQXV0aG9yaXphdGlvbg0KPsKg IMKgIMKgaGVhZGVyIGZpZWxkDQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIGZvciBpdHMgcmVhbG0u IFdoZW4gdGhlIHNjaGVtZSBpcyBCZWFyZXIgdGhlIHByb3h5IE1VU1QNCj7CoCDCoCDCoHZhbGlk YXRlIHRoZQ0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCBhY2Nlc3MgdG9rZW4sIHVzaW5nIHRoZSBw cm9jZWR1cmVzIGZyb20gW1JGQz8/P10NCj7CoCDCoCDCoGFzc29jaWF0ZWQgd2l0aCB0aGUNCj7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgdHlwZSBvZiBhY2Nlc3MgdG9rZW4gdXNlZC4NCj4gDQo+wqAg wqAgwqBXRk0uDQo+IA0KPsKgIMKgIMKgLS0tDQo+IA0KPsKgIMKgIMKgID7CoCDCoCAqIFNlY3Rp b24gMzoNCj7CoCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKgIFRoZSBmb2xsb3dpbmc6DQo+wqAg wqAgwqAgPg0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCBUaGUgcmVhbG0gYW5kIGF1dGgtcGFyYW0g cGFyYW1ldGVycyBhcmUgZGVmaW5lZCBpbiBbUkZDMzI2MV0uDQo+wqAgwqAgwqAgPg0KPsKgIMKg IMKgID7CoCDCoCBpcyBpbmNvbXBsZXRlLCBiZWNhdXNlIGl0IGlzIG1pc3NpbmcgJ2NoYWxsZW5n ZScsICdyZWFsbScsIGFuZA0KPsKgIMKgIMKgID7CoCDCoCAnaHR0cHMtVVJJLiAoV2hlcmUgaXMg aHR0cHMtVVJJIGRlZmluZWQ/KQ0KPsKgIMKgIMKgID4NCj7CoCDCoCDCoCA+IEFub3RoZXIgd2F5 IHRvIGRvIHRoaXMgaXMgYnnCoCBhZGRpbmcgdGhlIGZvbGxvd2luZyB0byB0aGUgc3ludGF4Og0K PsKgIMKgIMKgID4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgY2hhbGxlbmdlID0gPGRl ZmluZWQgaW4gUkZDMzI2MT4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgcmVhbG0gPSA8 ZGVmaW5lZCBpbiBSRkMzMjYxPg0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDCoCBhdXRoLXBh cmFtID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAg c2NvcGUgPSA8ZGVmaW5lZCBpbiBSRkM2NzQ5Pg0KPsKgIMKgIMKgID7CoCDCoCDCoCDCoCDCoCDC oCBlcnJvciA9IDxkZWZpbmVkIGluIFJGQzY3NDk+DQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKg IMKgIGh0dHBzLVVSSSA9IDx3aGVyZT8/Pz4NCj7CoCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKg IChUaGlzIGhlbHBzIHRob3NlIHdobyBtaWdodCB0cnkgdG8gZm9ybWFsbHkgdmFsaWRhdGUgdGhl DQo+wqAgwqAgwqBzeW50YXggYmVjYXVzZQ0KPsKgIMKgIMKgID7CoCDCoCBpdCByZW1vdmVzIHVu ZGVmaW5lZCBwYXJhbWV0ZXJzLikNCj4gDQo+wqAgwqAgwqBUaGUgc2VjdGlvbiBkb2VzIGVuaGFu Y2UgJ2NoYWxsZW5nZScsIHNvIEkgZ3Vlc3Mgd2UgY2FuIGFkZCB0ZXh0DQo+wqAgwqAgwqBzYXlp bmcgdGhhdCAnY2hhbGxlbmdlJyBpcyBkZWZpbmVkIGluIFJGQyAzMjYxLg0KPiANCj7CoCDCoCDC oFJlZ2FyZGluZyB0aGUgb3RoZXIgcGFyYW1ldGVycywgdGhlIHRleHQgYWxyZWFkeSBzYXlzIHdo ZXJlIHRoZXkgYXJlDQo+wqAgwqAgwqBkZWZpbmVkLg0KPiANCj7CoCDCoCDCoE9yLCBhcmUgeW91 IHNheWluZyB0aGF0IHlvdSB3YW50IHRoZSByZWZlcmVuY2VzIGluIHRoZSBzeW50YXgsDQo+wqAg wqAgwqByYXRoZXIgdGhhbiBpbiB0aGUgbm9ybWF0aXZlIHRleHQ/DQo+IA0KPsKgIMKgIMKgID7C oCDCoCBBbHNvLCAnc2NvcGUnIGFuZCAnZXJyb3InIGFyZSB2ZXJ5IGdlbmVyaWMgcnVsZSBuYW1l cyBiZWluZw0KPsKgIMKgIMKgdXNlZCBpbiBhDQo+wqAgwqAgwqAgPsKgIMKgIHZlcnkgcmVzdHJp Y3RlZCBjb250ZXh0LiBXaGlsZSB0aGVzZSBhcmUgbm90IGRlZmluZWQgaW4NCj7CoCDCoCDCoFJG QzMyNjEsIHRoZXJlDQo+wqAgwqAgwqAgPsKgIMKgIGlzIHRoZSBwb3RlbnRpYWwgY29uZmxpY3Qg d2l0aCBvdGhlciBleHRlbnNpb25zLiBJJ2QgcmVjb21tZW5kDQo+wqAgwqAgwqB1c2luZw0KPsKg IMKgIMKgID7CoCDCoCBtb3JlIHNwZWNpZmljIHRlcm1zLiBFLmcuLA0KPsKgIMKgIMKgID4NCj7C oCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgY2hhbGxlbmdlwqAgPS/CoCAoIkJlYXJlciIgTFdT IGJlYXJlci1jbG4gKihDT01NQQ0KPsKgIMKgIMKgYmVhcmVyLWNsbikpDQo+wqAgwqAgwqAgPsKg IMKgIMKgIMKgIMKgIMKgIGJlYXJlci1jbG4gPSByZWFsbSAvIGJlYXJlci1zY29wZSAvIGF1dGh6 LXNlcnZlciAvDQo+wqAgwqAgwqBiZWFyZXItZXJyb3IgLw0KPsKgIMKgIMKgID7CoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGF1dGgtcGFyYW0NCj7CoCDCoCDCoCA+wqAgwqAg wqAgwqAgwqAgwqAgYXV0aHotc2VydmVyID0gImF1dGh6X3NlcnZlciIgRVFVQUwgYXV0aHotc2Vy dmVyLXZhbHVlDQo+wqAgwqAgwqAgPsKgIMKgIMKgIMKgIMKgIMKgIGF1dGh6LXNlcnZlci12YWx1 ZSA9IGh0dHBzLVVSSQ0KPsKgIMKgIMKgID4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAg Y2hhbGxlbmdlID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAg wqAgwqAgcmVhbG0gPSA8ZGVmaW5lZCBpbiBSRkMzMjYxPg0KPsKgIMKgIMKgID7CoCDCoCDCoCDC oCDCoCDCoCBhdXRoLXBhcmFtID0gPGRlZmluZWQgaW4gUkZDMzI2MT4NCj7CoCDCoCDCoCA+wqAg wqAgwqAgwqAgwqAgwqAgYmVhcmVyLXNjb3BlID0gPGRlZmluZWQgYXMgc2NvcGUgaW4gUkZDNjc0 OT4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgYmVhcmVyLWVycm9yID0gPGRlZmluZWQg YXMgZXJyb3IgaW4gUkZDNjc0OT4NCj7CoCDCoCDCoCA+wqAgwqAgwqAgwqAgwqAgwqAgaHR0cHMt VVJJID0gPHdoZXJlPz8/Pg0KPiANCj7CoCDCoCDCoFRoZSBIVFRQIFdXVy1BdXRoZW50aWNhdGUg aGVhZGVyIGZpZWxkIHVzZXMgJ2Vycm9yJyBhbmQgJ3Njb3BlJywgYW5kDQo+wqAgwqAgwqBJIHRo aW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gYmUgYWxpZ25lZC4NCj4gDQo+wqAgwqAgwqAgPsKgIMKg IFJlZ2FyZGluZyB0aGUgc2NvcGUgcGFyYW1ldGVyOg0KPsKgIMKgIMKgID4NCj7CoCDCoCDCoCA+ wqAgwqAgVGhpcyBwYXJhbWV0ZXIgaXMgY29udmV5ZWQgZnJvbSB0aGUgcmVnaXN0cmFyIHRvIHRo ZSBVQUMuIEJ1dA0KPsKgIMKgIMKgd2hhdCBpcw0KPsKgIMKgIMKgID7CoCDCoCB0aGUgVUFDIHRv IGRvIHdpdGggaXQ/IEhvdyBkb2VzIGl0IGhhdmUgYW55IGNvbnRyb2wgb3ZlciB0aGUNCj7CoCDC oCDCoHNjb3BlIG9mDQo+wqAgwqAgwqAgPsKgIMKgIHRoZSB0b2tlbiBpdCBnZXRzIGZyb20gdGhl IEFTPyBJcyB0aGUgVUFDIHN1cHBvc2VkIHRvIGNvbnZleQ0KPsKgIMKgIMKgdGhpcyB0byB0aGUN Cj7CoCDCoCDCoCA+wqAgwqAgQVM/IElmIHNvLCBob3c/DQo+IA0KPsKgIMKgIMKgVGhlIFVBQyB3 aWxsIGdldCB0aGUgc2NvcGUgZnJvbSB0aGUgQVMsIGFuZCB3aWxsIGZvcndhcmQgaXQgdG93YXJk cw0KPsKgIMKgIMKgdGhlIFVBUy9yZWdpc3RyYXIuDQo+IA0KPsKgIMKgIMKgID7CoCDCoCBSZWdh cmRpbmcgdGhlIGVycm9yIHBhcmFtZXRlcjoNCj7CoCDCoCDCoCA+DQo+wqAgwqAgwqAgPsKgIMKg IElzIHRoaXMganVzdCBpbnRlbmRlZCB0byBiZSBvZiBoZWxwIGluIGRlYnVnZ2luZyB0aGUgVUFD PyBPcg0KPsKgIMKgIMKgaXMgaXQNCj7CoCDCoCDCoCA+wqAgwqAgZXhwZWN0ZWQgdGhhdCB0aGUg VUFDIG1pZ2h0IHRha2Ugc29tZSBzb3J0IG9mIHByZS1wcm9ncmFtbWVkDQo+wqAgwqAgwqBhY3Rp b24gaW4NCj7CoCDCoCDCoCA+wqAgwqAgcmVzcG9uc2U/IElmIHRoZSBsYXR0ZXIsIGhvdyBtaWdo dCB0aGF0IHdvcms/IElzIHRoaXMgaW5mb3JtYXRpb24NCj7CoCDCoCDCoCA+wqAgwqAgc3VpdGFi bGUgZm9yIHByZXNlbnRhdGlvbiB0byB0aGUgdXNlcj8NCj4gDQo+wqAgwqAgwqBJIHNlZSBubyBy ZWFzb24gd2h5IGl0IGNhbid0IGJlIHByZXNlbnRlZCB0byB0aGUgdXNlciwgYW5kIEkgZ3Vlc3MN Cj7CoCDCoCDCoHRoZSBVQUMgYWN0aW9ucyBkZXBlbmQgb24gd2hhdCB0aGUgZXJyb3IgY29kZSBp cy4NCj4gDQo+wqAgwqAgwqBIb3dldmVyLCBhcyB0aGUgcGFyYW1ldGVyIGlzIGRlc2NyaWJlZCBp biBSRkMgNjc0OSwgSSBkb24ndCB0aGluayB3ZQ0KPsKgIMKgIMKgbmVlZCB0byByZXBlYXQgdGhh dCBpbiB0aGlzIGRyYWZ0Lg0KPiANCj7CoCDCoCDCoC0tLQ0KPiANCj7CoCDCoCDCoCA+wqAgwqAg KiBTZWN0aW9uIDQ6DQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKgID7CoCDCoCBJIGFncmVlIHdpdGgg RGFsZSAtIEkgZG9uJ3Qgc2VlIGFueSB2YWx1ZSBpbiB0aGlzIHRhZy4gSSB0cmllZA0KPsKgIMKg IMKgdG8gc2VhcmNoDQo+wqAgwqAgwqAgPsKgIMKgIGZvciBhbGwgZGlzY3Vzc2lvbiBvbiB0aGUg cG9pbnQuIFRoZSBkaXNjdXNzaW9uIGF0dHJpYnV0ZXMgbWUNCj7CoCDCoCDCoHdpdGgNCj7CoCDC oCDCoCA+wqAgwqAgcmVxdWVzdGluZyBpdCwgYnV0IEkgZG9uJ3QgdGhpbmsgSSBkaWQuDQo+IA0K PsKgIMKgIMKgSXQgd2FzIE9sbGUgd2hvIHJlcXVlc3RlZCBpdC4NCj4gDQo+wqAgwqAgwqBIb3dl dmVyLCBJIGRvbid0IHNlZSBhbnkgaGFybSBpbiBoYXZpbmcgaXQuIEl0IGFsbG93cyB0aGUgVUFD IHRvDQo+wqAgwqAgwqBpbmZvcm0gcHJveGllcy9VQVMvUmVnaXN0cmFyIHdoZXRoZXIgaXQgc3Vw cG9ydHMgdGhlIGJlYXJlciBzY2hlbWUuDQo+IA0KPsKgIMKgIMKgLS0tDQo+IA0KPsKgIMKgIMKg ID7CoCDCoCAqIE1pc3Npbmc6DQo+wqAgwqAgwqAgPg0KPsKgIMKgIMKgID7CoCDCoCBJIGZpbmQg bm8gc3ludGF4IGV4dGVuc2lvbnMgZm9yIEF1dGhvcml6YXRpb24gYW5kDQo+wqAgwqAgwqBQcm94 eS1BdXRob3JpemF0aW9uLg0KPsKgIMKgIMKgID7CoCDCoCBUaGVzZSBuZWVkIHRvIGJlIGFkZGVk Lg0KPiANCj7CoCDCoCDCoE9rLg0KPiANCj7CoCDCoCDCoFJlZ2FyZHMsDQo+IA0KPsKgIMKgIMKg Q2hyaXN0ZXINCj4gDQo+IA0KPiANCj7CoCDCoCDCoF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+wqAgwqAgwqBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPsKg IMKgIMKgbWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmcgPG1haWx0bzptYWlsdG86c2lwY29yZUBpZXRm Lm9yZz4NCj7CoCDCoCDCoGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw Y29yZQ0KPiANCg0K From nobody Fri Dec 13 08:14:32 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 E1EDF12010C for ; Fri, 13 Dec 2019 08:14:29 -0800 (PST) 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, 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=alum.mit.edu 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 Nqj87BTGpxFy for ; Fri, 13 Dec 2019 08:14:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750054.outbound.protection.outlook.com [40.107.75.54]) (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 914B112009E for ; Fri, 13 Dec 2019 08:14:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FTDQnzabB2A0BlxLOOAPXeejL7G0BMqFMAvo1A6PvF0L7I5w1iWcLe2Wvv1i404VsQXBgRWdYJ2lA7Ta5LhDrPk/Q7MPt8tmLqjDZPl0wCc79lWkenGrGj/TXBbEP5XVtX7kPtoTBIOiX3jlxDSsyxogtpHzEE8wQNYfvdZAYmdOA+dQLytN9f8hLar/e32IbvNA15K1Knc8zvRZuOyXYLy1JVdLMaLNuCJXPru0hme2Q005BecLDPvgj5a8ji/G/MB1nEtBis5jgSg0UsG1R0maGk1vI9YBvmsp2illmEUDivYjdoXiF8G/Jb7xVJg7GtqiZGwajsKCT0HE05E3TA== 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=Ab/YN/lL5fQuPpk2W/NDIyXYSrv+3wFRIwVb5h4fJwk=; b=JXZ0HnQwzPRocAbsrXnCaPhOGHqATxumJ4v9nZq9V4ZadY5dV80Ka0KNlvWD8EhsMK01+F5q/708RcXEkKuYbIHMcOmOf0F/WJOqoV7trCFtt8+KeMXPldp51wIlXjCsd7pAzcDoVlXZbKuBInSXsvMRVKpkybMkcsrIVRvxxUF404NeN7QHuEP9/xp/uKSyvq9LYyZ86O7wqH6ZZRyTPhQl7SlxfMY3qRpRMIQ7FIJs7WtEFc/sAgWT4gBYdM//KWlxfXfnHL3J9NKMRYs5qpAI1c3MMsJEZCWcUWj1qkkgHdptzE4pQfrAP3vwvHK7M1Hs+jODQEJ2/krZUk5jAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ab/YN/lL5fQuPpk2W/NDIyXYSrv+3wFRIwVb5h4fJwk=; b=M1XaD70dOg0pF34liOYvvq4xRaua5gpmCeZbjQJ7OkKsmKung9U9JiumoGT5aSyOVxBDZVTUbA08ikjxpJkBGedtjbbTCOwC0OkPq+GAmPVY14O5QhCNVxx6PrRv9HZFnDECb8UmHNf+f6MzCCbhA9CDwmSOhL8Fj3glsBWGWus= Received: from SN1PR12CA0056.namprd12.prod.outlook.com (2603:10b6:802:20::27) by DM5PR12MB1723.namprd12.prod.outlook.com (2603:10b6:3:111::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Fri, 13 Dec 2019 16:14:25 +0000 Received: from BL2NAM02FT020.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e46::203) by SN1PR12CA0056.outlook.office365.com (2603:10b6:802:20::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18 via Frontend Transport; Fri, 13 Dec 2019 16:14:25 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT020.mail.protection.outlook.com (10.152.77.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14 via Frontend Transport; Fri, 13 Dec 2019 16:14:24 +0000 Received: from Kokiri.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 xBDGEMOq011517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2019 11:14:23 -0500 To: Rifaat Shekh-Yusef Cc: Christer Holmberg , "sipcore@ietf.org" References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> From: Paul Kyzivat Message-ID: <797824da-fbd0-666b-67b1-51b510af19ac@alum.mit.edu> Date: Fri, 13 Dec 2019 11:14:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(199004)(189003)(54906003)(4326008)(2906002)(75432002)(53546011)(956004)(66574012)(26826003)(336012)(498600001)(6916009)(7596002)(2616005)(966005)(5660300002)(8936002)(70586007)(8676002)(76130400001)(356004)(186003)(70206006)(26005)(36906005)(246002)(31686004)(31696002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1723; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: daef7d16-60cc-4e36-37f8-08d77fe78548 X-MS-TrafficTypeDiagnostic: DM5PR12MB1723: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0250B840C1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +2/uHVYvoJOHf/tUzzq+kMK0QIUNMyS4WG2vaEbDnjeZq9isHWPgYm75dslGjIqxefAoatnwutj1nA16Th3zmhjIIFF3OMPAW7Bw5srlh9OaJDUWJzOgpFZhI8f4UPP5Lm6I+moeZ29zxKpUyTIklIt6IUTyNOe+j4Bk9HZ9LXmfdnJ1A0IhzxCO8LbNGjFDNhSvfAmVKS3XRDAFlyDqUEZpuW7feoJs0n8IIqGycWsaiKs5IDxuGPKQID5prrEpXdjG6DNHnGoRBNqgJ+5+9WaRnD0eUgw60Ww+IqzFzdjh6rAcbSwJf0GcWAOrIQcfZ2Q4BYQ1HSt1vKFGWF8l75nSX0tYzjAXo71gXJXwzCKO7qPNN7lz75HC8gu2uHaxI3zccrXSjIVEHy+QE2ldsIO/GsWBu+YfFud/ZOQziw3rsnp7iuHKfuuHpODZVagblzO03KNGRA6UTLBRNpAVlJ1mcjpZYZSK/HpoEB3a/sg= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2019 16:14:24.5639 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: daef7d16-60cc-4e36-37f8-08d77fe78548 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1723 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 13 Dec 2019 16:14:30 -0000 Rifaat, On 12/13/19 9:02 AM, Rifaat Shekh-Yusef wrote: > But in the end whatever it is must use the URI as the starting point > for > the interaction. With a browser interface presumably the URI is used to > fetch a page that is presented to the user. And the user then can > determine in a human intuitive way how to interact with that page to > complete the authentication. If it is an automaton then that won't > work. > It must have *some* way of determining how to interact with the web > server and present what facts it has (e.g. user id and pw) to that > server in order to complete authentication. And in either case, there > must be a well defined way of learning if it succeeded and conveying > the > resulting token back to the sip server. > > RFC8252 seems to try to specify this at least in some cases, though it > is still fuzzy to me. This should be deterministic - it shouldn't be > neccessary for an automaton to be specially programmed for how to > interact with the particular AS and how to convey the result back to > the > sip server. > > There are different ways that a UAC can act on the HTTPS URI, depending > on the type of UAC. > Here are few examples: > 1. RFC8252 for Native Apps > 2. RFC8628 for browser-less devices > 3. > https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ for browser-based > apps > > New mechanisms could be defined and added to address other use case not > covered by existing mechanisms. > > This is the reason I am really hesitant to add any normative text and > require any specific mechanism. > I still think this is out of scope for this document, and any text > should be informative only. I know very little about web development, and so I found draft-ietf-oauth-browser-based-apps very difficult to understand. But based on that I think I realize a bit of where it is coming from: With a browser based web app, the code running in the browser may be provided by the web app it is talking to. In that case they can have customized implicit knowledge of the inner workings of each other and the mechanics of the interaction between the two need not be standardized. The question is, what does that have to do with sip? Are you imagining a case where there is a browser based sip client that has been served to the browser by a web server that has implicit knowledge of the workings of the sip registrar? My concern is driven by an expectation that sip client MAY be an independent entity has no knowledge of the workings of the sip server. In that case the *only* knowledge it has in support of authentication is what comes in the authorization challenge. That MUST be sufficient information, together with information it can get by asking the end user in realtime, to complete the authentication and successfully retry the request with proper credentials. IIUC the current spec doesn't accomplish that. I get the impression (though I am far from sure) that you are trying to cover cases where the sip server assumes that the client has been custom implemented to work with that server. If so, I don't think that is an appropriate stance for a sip standard. > > Regarding your comment about section 2.1.2, I agree with you; I will > > move it to its own section. > > Moving it to a separate section isn't necessary or sufficient. It needs > to be clarified. > > Ok. I will clarify it. > > I'm assuming responses to my other points will be coming later. > > > Christer provided feedback on the rest of you comments. Do you have any > further comment on Christer's responses? I don't recall. I'll have to check back. Thanks, Paul From nobody Fri Dec 13 09:37: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 54CC0120855 for ; Fri, 13 Dec 2019 09:37:52 -0800 (PST) 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, 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=alum.mit.edu 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 9PwEkScBO1xW for ; Fri, 13 Dec 2019 09:37:49 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2089.outbound.protection.outlook.com [40.107.220.89]) (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 0EBA3120041 for ; Fri, 13 Dec 2019 09:37:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IZsvbAPUuKm6apEPkStktrymi69ymcsM91M6y6DwF+7VYQYbkiUMw4KLICaIhiw0J3fMQENk+g4w599PSV4kCe5bcHJTNFjCT3fiu/IlTAZn8TO2GV8Wm4ZvS4UWSiHGBiAXF2n2g+AnVyLbpAUoMKJxY4nsZwInb7YVf8JzwUELkOB6xYC84Pmue60BePHprGU4mWUNZoSlyNRlR3C7aMkJR/JZiY1B7zx+TejWfl+61cn08k3+nYJVSOgGfXv4cfktY/eFz6chLN8hRY3JOkfqTHI97Z32Vnm9Y3MJHZ0R0kNZj5UZ9nMtA4OhGn51bvWvgzKH/WYa1lAg2cdBxA== 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=OkRKFHAxQo5eaEqRV4f+uLguFPJgFGA4LyOUlU1SpBQ=; b=Qz5xbkeVEK4aWt3+vqouWJ3nvKpokRdTPvriBT+d6hn4pWtnyZZ6J3Tqh8HfmPlk2oeZy9L5jPizlwn+lTW4/pUXZiW4HLc32AJLtRC7l6jjOqozi5LVxbFV9IK0OlmcY5nRK6wSbbc1Rd9B8Sl/lLcQcKiv9USwWZHd1iMCoR/UAaoZ0tkh5uh9UBiq1QLGAVGEIoP3wzwPiqeWsvItx6ztkMJPDN7nF5rXpFKwQJnJsAS1+eCW5X3Br6lJvGCW1eRSMXUdGcY8g/y8546xGWq0O0755kIbvPLkR6hoSCqBmxq+0FF3EZCwdMmw33H9R2KaUpVbkvIuLjNXV4/S2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OkRKFHAxQo5eaEqRV4f+uLguFPJgFGA4LyOUlU1SpBQ=; b=S4PXph3umnKaWn8aF8PcJ8+okRpY93yQQ6bV352MyjyLfxgYoAzrVmoPb837HWqW15YztV2LJedIjjYnp6DB+Wd7l/WlD5n0xbw6KnkgVCo3ztVNx+2Pqvj/jnAvi2Yn6P+SDpme2PM7Li1EcCJqzOW9vQwKooW7Swq+J6kRVPU= Received: from BN6PR1201CA0014.namprd12.prod.outlook.com (2603:10b6:405:4c::24) by MN2PR12MB3936.namprd12.prod.outlook.com (2603:10b6:208:16a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Fri, 13 Dec 2019 17:37:47 +0000 Received: from SN1NAM02FT031.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::208) by BN6PR1201CA0014.outlook.office365.com (2603:10b6:405:4c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.15 via Frontend Transport; Fri, 13 Dec 2019 17:37:46 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT031.mail.protection.outlook.com (10.152.72.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.14 via Frontend Transport; Fri, 13 Dec 2019 17:37:46 +0000 Received: from Kokiri.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 xBDHbhAQ016758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Dec 2019 12:37:44 -0500 To: Rifaat Shekh-Yusef Cc: Christer Holmberg , SIPCORE References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> From: Paul Kyzivat Message-ID: <9fc74274-2fd8-00e2-74ce-56ce771bba85@alum.mit.edu> Date: Fri, 13 Dec 2019 12:37:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(189003)(199004)(26005)(7596002)(246002)(8936002)(8676002)(70586007)(54906003)(70206006)(36906005)(31696002)(6916009)(86362001)(336012)(76130400001)(53546011)(186003)(2906002)(498600001)(75432002)(26826003)(356004)(2616005)(956004)(4326008)(5660300002)(31686004)(30864003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR12MB3936; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d4676310-e15d-42e7-23bc-08d77ff32a97 X-MS-TrafficTypeDiagnostic: MN2PR12MB3936: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0250B840C1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1jo7kdkMq4pk3kFPAQaJhLdo8J6bHKvfqeMtlxj29ENRW/AcPQJ5fqBhJ4etyKoHca7OYY1tFyVaJ0eLWGmlsDGJobeO3i7v+C4m5+d+PJEzP4WhAh8PtQGs5TUYVDaUEtwvosZxdZobiiDkXZqFsk8PU/ec35gg8lRZ2jdNAJvXE9aC23xdvh92swgJB1gvmeI2GOa96EacV+35tD57qaeRcrmx/1CnSawRwWsL1kxaCskyU5zxshFZCdD89VnXUclzdHqxKxzCpydWu9OkmQ5Zg4K5p33uyIINW07wIpHKLyHaE4VyQJg0cw4nGbD6a4MzHzJcKdOqsFYGx4+gh6ReZ36J999TqrGSMRB3wddsKDR8FB0q3dt4SCD/wUu2yzmN27TQER+7jYZ4QID6JjE3OYjcg7jwjueo8A/u+NtsmpQJo01lin9ZROhozrJD X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2019 17:37:46.1690 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d4676310-e15d-42e7-23bc-08d77ff32a97 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3936 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 13 Dec 2019 17:37:52 -0000 On 12/13/19 9:02 AM, Rifaat Shekh-Yusef wrote: > > > On Sun, Dec 8, 2019 at 5:17 PM Paul Kyzivat > wrote: > I'm assuming responses to my other points will be coming later. > > Christer provided feedback on the rest of you comments. Do you have any > further comment on Christer's responses? Hmm. I can find no evidence that I received Christer's reply. But I have now found it in the archives. I will reply based on the text from the archive. I'm sorry that this isn't properly threaded into the replies. On 12/13/19 9:02 AM, Christer Holmberg wrote: > Hi Paul, > > My comments on some of your SIP-related issues (I am not addressing your issues on Sections 2.1.1 and 2.1.2 in this reply). > >> * Section 2.1.4: >> >> This section says that the UAC MUST include an Authorization header >> field with the Bearer scheme. This is overly strong. >> >> This should be an explanation that *if* it has received a challenge >> containing the Bearer scheme then to resolve that particular challenge >> it needs to send a request with an Authorization header field containing >> the response to that challenge, including the Bearer scheme. > > I suggest that we expand the first paragraph in the section. Something like: > > "The procedures in this section apply when the UAC has received a challenge that contains a Bearer scheme, > and the UAC has obtained a token as specified in section Section 2.1.1." OK >> (But note that if there were multiple challenges with different schemes >> then it maybe able to successfully retry the request using non-Bearer >> credentials.) >> >> I don't understand what distinction you are trying to draw by >> distinguishing the behavior for creating a binding from that for >> refreshing a binding. AFAIK there should be no difference. And in fact >> the UAC in general cannot know whether the request being send will >> establish or refresh a binding. > > It is important to point out that the same access token might not necessarily be used throughout the lifetime of the registration, if the previously included access token has expired. Fine. It is good to cover that. But it shouldn't be conflated with creating vs. refreshing a binding. For instance, the UAC may have knowingly allowed a registration to expire and yet still cached the credentials (tokens). Then later it might want to reestablish a registration using cached credentials. At that time it can decide if its access token is still good, and if not use its refresh token to get a fresh one, and then either way use that preemptively in its register request. > --- > >> * Section 2.1.5: >> >> This section has similar issues to section 2.1.4: The MUST is too >> strong, and the reason for distinguishing between in-dialog requests >> from others is unclear. > > See my comments for 2.1.4. > > --- > >> * Section 2.2: >> >> Again is overly strong in its use of MUST. I think it is evident that >> the point being made is that a challenge containing Bearer scheme is the >> way to indicate that is with a challenge with Bearer scheme, but the >> text is at least awkward. >> >> How about: >> >> When a UAS or Registrar receives a request that fails to contain >> authorization credentials acceptable to it, it SHOULD challenge the >> request by sending a 401 (Unauthorized) response. To indicate that >> it is willing to accept an OAuth2 token as a credential the >> UAS/Registrar MUST include a Proxy-Authentication header field in the >> response, indicate "Bearer" scheme and include an address of an >> Authorization Server from which the originator can obtain an access >> token. > > WFM. > >> In the second paragraph, please provide a reference: >> >> ... using the procedures from [RFC???] associated with the type of >> access token used. > > Ok. > > --- > >> * Section 2.3: >> >> Similar comment to section 2.2. How about the following for the first >> paragraph: >> >> When a proxy receives a request that fails to contain >> authorization credentials acceptable to it, it SHOULD challenge the >> request by sending a 407 (Proxy Authentication Required) response. >> To indicate that it is willing to accept an OAuth2 token as a >> credential the proxy MUST include a Proxy-Authentication >> header field in the response, indicating "Bearer" scheme and >> including an address to an Authorization Server from which the >> originator can obtain an access token. > > WFM. > >> I don't think the second paragraph should condition any behavior on >> whether it has previously challenged. That requires that the proxy be >> stateful, and it isn't a necessary condition. Instead, how about: >> >> When a proxy wishes to authenticate a received request, it MUST >> search the request for Proxy-Authorization header fields with 'realm' >> parameters that match its realm. It then MUST successfully validate >> the credentials from at least one Proxy-Authorization header field >> for its realm. When the scheme is Bearer the proxy MUST validate the >> access token, using the procedures from [RFC???] associated with the >> type of access token used. > > WFM. > > --- > >> * Section 3: >> >> The following: >> >> The realm and auth-param parameters are defined in [RFC3261]. >> >> is incomplete, because it is missing 'challenge', 'realm', and >> 'https-URI. (Where is https-URI defined?) >> >> Another way to do this is by adding the following to the syntax: >> >> challenge = >> realm = >> auth-param = >> scope = >> error = >> https-URI = >> >> (This helps those who might try to formally validate the syntax because >> it removes undefined parameters.) > > The section does enhance 'challenge', so I guess we can add text saying that 'challenge' is defined in RFC 3261. > > Regarding the other parameters, the text already says where they are defined. > > Or, are you saying that you want the references in the syntax, rather than in the normative text? I'm just *suggesting* that doing so in ABNF will make life easier for anybody who wants to process the abnf using tools. >> Also, 'scope' and 'error' are very generic rule names being used in a >> very restricted context. While these are not defined in RFC3261, there >> is the potential conflict with other extensions. I'd recommend using >> more specific terms. E.g., >> >> challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) >> bearer-cln = realm / bearer-scope / authz-server / bearer-error / >> auth-param >> authz-server = "authz_server" EQUAL authz-server-value >> authz-server-value = https-URI >> >> challenge = >> realm = >> auth-param = >> bearer-scope = >> bearer-error = >> https-URI = > > The HTTP WWW-Authenticate header field uses 'error' and 'scope', and I think it would be good to be aligned. The context in which abnf from HTTP is processed is distinct from that in which SIP abnf is processed. Consider somebody who is trying to pull together complete abnf for sip and all the sip extensions that they implement. All the rule names newly defined in one sip extension need to be distinct from those defined in other sip extensions. (Except in cases of extensions to extensions.) If the new rule names are sufficiently unique to effectively eliminate conflicts then all should be good. If common words are used as rule names, then multiple extensions may inadvertently conflict. We have no mechanisms for easily detecting such conflicts. I'm just trying to suggest practices that help with this. I don't think that what I suggest above will confuse anyone that is familiar with the HTTP abnf. >> Regarding the scope parameter: >> >> This parameter is conveyed from the registrar to the UAC. But what is >> the UAC to do with it? How does it have any control over the scope of >> the token it gets from the AS? Is the UAC supposed to convey this to the >> AS? If so, how? > > The UAC will get the scope from the AS, and will forward it towards the UAS/registrar. I'm confused. According to RFC6749 the client and user agent are passing the scope *to* the AS. Then (I think) that influences whether a token is returned and if so which one. In our context here, I gather that the registrar is conveying the scope for credentials it will accept. Then I guess the UAC is expected to pass this on to the AS. I think the processing of scope needs more explanation. >> Regarding the error parameter: >> >> Is this just intended to be of help in debugging the UAC? Or is it >> expected that the UAC might take some sort of pre-programmed action in >> response? If the latter, how might that work? Is this information >> suitable for presentation to the user? > > I see no reason why it can't be presented to the user, and I guess the UAC actions depend on what the error code is. > > However, as the parameter is described in RFC 6749, I don't think we need to repeat that in this draft. I'm not sure I understand it there, but it appears to me that the error parameter is returned by the AS to the client in response to a request for a token. In that case I don't see why it will be present in a WWW-Authenticate header field. Can you explain the flow that results in this being in WWW-Authenticate? > --- > >> * Section 4: >> >> I agree with Dale - I don't see any value in this tag. I tried to search >> for all discussion on the point. The discussion attributes me with >> requesting it, but I don't think I did. > > It was Olle who requested it. > > However, I don't see any harm in having it. It allows the UAC to inform proxies/UAS/Registrar whether it supports the bearer scheme. There is no particular harm other than added complexity and the likelihood that others will in the future ask about it. > --- > >> * Missing: >> >> I find no syntax extensions for Authorization and Proxy-Authorization. >> These need to be added. > > Ok. Thanks, Paul From nobody Fri Dec 13 10:49: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 A5CB21200A1 for ; Fri, 13 Dec 2019 10:49:35 -0800 (PST) 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 rjNAYR4XLHV0 for ; Fri, 13 Dec 2019 10:49:33 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40050.outbound.protection.outlook.com [40.107.4.50]) (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 7A7C2120013 for ; Fri, 13 Dec 2019 10:49:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gWuGhBmgd4VId0fd+6vH/Lnw+ICYXuxdrGRreGCCxSTR4ofsalNgMD8zJDSW4fRzqufNa9u6phgJpzF2zXLf+YcNalUdtGibNHKfTJZc4iY5Id/5oi44XSIi+C5gy8Iug3dJCZ7xOvcm7nRLDgBsnS0X66AlDffzcm6qe/C5L16YVCTfVYlAylOis8qxNURCZp+ymkOKniT6YDz89IsIK8Uu43tSkLdRMnjIziPinR1LofAzhT4F+kH2DOfuWMBna2Gqfn2TJqx2mLMZz5eyJk8n+My+YkNAGz/EC4aWa5vmoME2LT0yFg/Sag5ViMdwGu9++6/DXjHqh7P9h9I1yw== 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=K78bwjidMaJQmA9pfeNqRTti4lWK41yPOe3aD3X8dKI=; b=fh8rUgf46pfcQy+T+AkGoRGkSu5W9nHw/TKJlkw51p4VlPHrMXcJOPeV3UQZMWnM2M+6JZpaxPLIlrR9bix0RN1MY+23DM+UllMWCv1zscmDW3YPGmpVZtTGfdJi394AF+rUqH2XxYc+8SqF/BWTm4cE9Dn8TrPREGTKLfzcHsv/0RVgEWKOoC4187BY4NKRrsahdHd3vUnYSmyPWU4OfqOFRlvS4xonC9ADrtP1RKq1XWMOM9OIKco97bFvVD5UNF1TVkhG53rI8e0XoyQkon+xBJQWRy1BThmffdXZZwr4WjRgv/mlza0kWo52aQY4SNJ49827nMqcCI+OAb5NOw== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K78bwjidMaJQmA9pfeNqRTti4lWK41yPOe3aD3X8dKI=; b=aDv2ndiCbZbf1AM0ok0MEvtbaD88dwl9Kstz2z/5ExqHNXDMQJMq5oielljdfL5D+8GUv6CMe1raFAaa0lJj56zUJVGH5QLzfGCaft0G6BVcR0222e3JzIrMIiBBzCg6uBiuhPyRYjXBd6BGeSz2yXxsetXuKbR7Mi0VgLuqkjQ= Received: from DB6PR0701MB2421.eurprd07.prod.outlook.com (10.168.73.16) by DB6PR0701MB2422.eurprd07.prod.outlook.com (10.168.75.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.10; Fri, 13 Dec 2019 18:49:31 +0000 Received: from DB6PR0701MB2421.eurprd07.prod.outlook.com ([fe80::39bd:a590:dcd9:201e]) by DB6PR0701MB2421.eurprd07.prod.outlook.com ([fe80::39bd:a590:dcd9:201e%10]) with mapi id 15.20.2538.017; Fri, 13 Dec 2019 18:49:31 +0000 From: Christer Holmberg To: Paul Kyzivat , Rifaat Shekh-Yusef CC: "sipcore@ietf.org" , Christer Holmberg Thread-Topic: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz Thread-Index: AQHVqRaq+n57bvgHbkmAxusa4398hqeoufCAgAEHG4CABnMOAIAApGKAgAdRNgCAACTkAIAATN6A Date: Fri, 13 Dec 2019 18:49:31 +0000 Message-ID: <2A861C17-7D03-49FF-A0AA-D9BD31D3E2A4@ericsson.com> References: <9b7ddc2f-d54a-bbaa-8e56-276c8bed725f@nostrum.com> <76BD0473-8921-4931-9AEE-1880C3AA6A57@ericsson.com> <8bc9d0f1-2b13-6ee0-73a5-8056c186b029@alum.mit.edu> <797824da-fbd0-666b-67b1-51b510af19ac@alum.mit.edu> In-Reply-To: <797824da-fbd0-666b-67b1-51b510af19ac@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [129.192.75.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07aa2cbc-8917-4c29-c43e-08d77ffd306c x-ms-traffictypediagnostic: DB6PR0701MB2422: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0250B840C1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(199004)(189003)(478600001)(66556008)(54906003)(66476007)(26005)(81166006)(81156014)(186003)(8676002)(2616005)(316002)(76116006)(91956017)(4326008)(71200400001)(110136005)(66574012)(2906002)(33656002)(36756003)(86362001)(6486002)(66946007)(6506007)(44832011)(5660300002)(8936002)(6512007)(64756008)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2422; H:DB6PR0701MB2421.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: BCL:0; x-microsoft-antispam-message-info: 0G/TFeQ7VEWzKGZqLAMN468O+TWCqRiqz1y/+M5YMtO1CAq1tHAELrTEEuqfrf9V06cU0VGexqU7nyOb7okZSk6Gm6QRvjiX4uhsb+GuTJsi/Zr6PuRNhSDN04o5+rky+IN8YvbFhra04FDxvPye2TKFXxDDVilaTLOR7rHAzV89iXZEfsL+Bh/7kSUIDCFZg7sisP2ShKx0spbaXw5n0vP0S9teX2+7NE+IUKcXSut2EqKAUP8zYDb7ANUszW7o0JVovmbOTcMjQ/WlDtF9J0o6/JJi9u9o4iYmCR8l6V6Mk+FhO/kdNq0U8jd7nedtnh0buLHvSzJsODjEMglR8AU7Bwhtm3OFsn2TjaK3fzxapHtmVL7dzI0qxSRtEiUv8/K8ntAZNIWzDmlL7UuddOzminZJ63VUn3fOu+RFNt0SP7inY9+QSjNn962Hbp8y x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <77A4A9F2D080EC499834BD5226EA0AB9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07aa2cbc-8917-4c29-c43e-08d77ffd306c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 18:49:31.0603 (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: Fec/YY4NhWD7rJJILaTK5Xes9GkCWN5etoIOnEJdpOc46g1ZJNy1P1e9FLyXlER/9Wj/Dw5rbjBTmrN6vaMowA/azzNyJfupVn0VDqy4l+w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2422 Archived-At: Subject: Re: [sipcore] WGLC draft-ietf-sipcore-sip-token-authnz 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, 13 Dec 2019 18:49:35 -0000 SGkgUGF1bCwNCg0KLi4uDQoNCj4gICAgSSBrbm93IHZlcnkgbGl0dGxlIGFib3V0IHdlYiBkZXZl bG9wbWVudCwgYW5kIHNvIEkgZm91bmQgDQo+ICAgIGRyYWZ0LWlldGYtb2F1dGgtYnJvd3Nlci1i YXNlZC1hcHBzIHZlcnkgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQuIEJ1dCANCj4gICAgYmFzZWQg b24gdGhhdCBJIHRoaW5rIEkgcmVhbGl6ZSBhIGJpdCBvZiB3aGVyZSBpdCBpcyBjb21pbmcgZnJv bToNCj4gICAgDQo+ICAgIFdpdGggYSBicm93c2VyIGJhc2VkIHdlYiBhcHAsIHRoZSBjb2RlIHJ1 bm5pbmcgaW4gdGhlIGJyb3dzZXIgbWF5IGJlIA0KPiAgICBwcm92aWRlZCBieSB0aGUgd2ViIGFw cCBpdCBpcyB0YWxraW5nIHRvLiBJbiB0aGF0IGNhc2UgdGhleSBjYW4gaGF2ZSANCj4gICAgY3Vz dG9taXplZCBpbXBsaWNpdCBrbm93bGVkZ2Ugb2YgdGhlIGlubmVyIHdvcmtpbmdzIG9mIGVhY2gg b3RoZXIgYW5kIA0KPiAgICB0aGUgbWVjaGFuaWNzIG9mIHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVu IHRoZSB0d28gbmVlZCBub3QgYmUgc3RhbmRhcmRpemVkLg0KPiAgICANCj4gICAgVGhlIHF1ZXN0 aW9uIGlzLCB3aGF0IGRvZXMgdGhhdCBoYXZlIHRvIGRvIHdpdGggc2lwPyBBcmUgeW91IGltYWdp bmluZyBhIA0KPiAgICBjYXNlIHdoZXJlIHRoZXJlIGlzIGEgYnJvd3NlciBiYXNlZCBzaXAgY2xp ZW50IHRoYXQgaGFzIGJlZW4gc2VydmVkIHRvIA0KPiAgICB0aGUgYnJvd3NlciBieSBhIHdlYiBz ZXJ2ZXIgdGhhdCBoYXMgaW1wbGljaXQga25vd2xlZGdlIG9mIHRoZSB3b3JraW5ncyANCj4gICAg b2YgdGhlIHNpcCByZWdpc3RyYXI/DQoNCkkgYW0gbm90IHN1cmUgd2hhdCAid29ya2luZ3Mgb2Yg dGhlIHNpcCByZWdpc3RyYXIiIHlvdSBhcmUgcmVmZXJyaW5nIHRvLg0KDQpUaGUgdXNlci9hcHBs aWNhdGlvbiBvYnZpb3VzbHkgbmVlZCB0byBzdXBwb3J0IGF0IGxlYXN0IG9uZSBvZiB0aGUgT0F1 dGggYXBwbGljYXRpb24gc2VydmVyIHByb3ZpZGVycyB1c2VkIGJ5IHRoZSByZWdpc3RyYXIuIElm IGl0IGRvZXNuJ3QsIGF1dGhlbnRpY2F0aW9uIHdpbGwgZmFpbC4gVGhhdCBpcyBub3JtYWwgYmVo YXZpb3IgZm9yIHdlYiBhcHBsaWNhdGlvbnMuIEhvd2V2ZXIsIHdoZW4gYSB1c2VyIG1ha2VzIGEg Y29udHJhY3Qgd2l0aCB0aGUgcmVnaXN0cmFyIG9wZXJhdG9yLCB0aGUgdXNlciB3aWxsIG5vcm1h bGx5IGJlIHRvbGQgd2hpY2ggYXBwbGljYXRpb24gc2VydmVyIHByb3ZpZGVycyBhcmUgc3VwcG9y dGVkIGJ5IHRoZSBvcGVyYXRvci4NCg0KPiAgICBNeSBjb25jZXJuIGlzIGRyaXZlbiBieSBhbiBl eHBlY3RhdGlvbiB0aGF0IHNpcCBjbGllbnQgTUFZIGJlIGFuIA0KPiAgICBpbmRlcGVuZGVudCBl bnRpdHkgaGFzIG5vIGtub3dsZWRnZSBvZiB0aGUgd29ya2luZ3Mgb2YgdGhlIHNpcCBzZXJ2ZXIu IA0KPg0KPiAgICBJbiB0aGF0IGNhc2UgdGhlICpvbmx5KiBrbm93bGVkZ2UgaXQgaGFzIGluIHN1 cHBvcnQgb2YgYXV0aGVudGljYXRpb24gaXMgDQo+ICAgIHdoYXQgY29tZXMgaW4gdGhlIGF1dGhv cml6YXRpb24gY2hhbGxlbmdlLiANCg0KSXQgZG9lc24ndCBuZWVkIHRvIGtub3cgbW9yZS4NCg0K PiBUaGF0IE1VU1QgYmUgc3VmZmljaWVudCAgaW5mb3JtYXRpb24sIHRvZ2V0aGVyIHdpdGggaW5m b3JtYXRpb24gaXQgY2FuIGdldCBieSBhc2tpbmcgdGhlIGVuZCB1c2VyIA0KPiBpbiByZWFsdGlt ZSwgdG8gY29tcGxldGUgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZCBzdWNjZXNzZnVsbHkgcmV0cnkg dGhlIHJlcXVlc3Qgd2l0aCBwcm9wZXIgY3JlZGVudGlhbHMuIA0KPiBBcyBmYXIgYXMgU0RQIGlz IGNvbmNlcm5lZCwgdGhlIG9ubHkgZm9ybWF0IGlzICd3ZWJydGMtZGF0YWNoYW5uZWwnLg0KDQpJ dCBnZXRzIHRoYXQgaW5mb3JtYXRpb24gaW4gdGhlIDQwMS80MDcgcmVzcG9uc2UuIFRoZSBIVFRQ UyBVUkkgaW5kaWNhdGVzIHdoaWNoIGFwcGxpY2F0aW9uIHNlcnZlciBwcm92aWRlciBpcyB1c2Vk LCBzbyB0aGUgYXBwbGljYXRpb24gY2FuIHF1ZXJ5IHRoZSBjcmVkZW50aWFscyBhc3NvY2lhdGVk IHdpdGggdGhhdCBhcHBsaWNhdGlvbiBzZXJ2ZXIgYW5kIHBlcmZvcm0gdGhlIE9BdXRoIHByb2Nl ZHVyZXMgd2l0aCB0aGUgYXBwbGljYXRpb24gc2VydmVyLg0KDQo+ICAgIEkgZ2V0IHRoZSBpbXBy ZXNzaW9uICh0aG91Z2ggSSBhbSBmYXIgZnJvbSBzdXJlKSB0aGF0IHlvdSBhcmUgdHJ5aW5nIHRv IA0KPiAgICBjb3ZlciBjYXNlcyB3aGVyZSB0aGUgc2lwIHNlcnZlciBhc3N1bWVzIHRoYXQgdGhl IGNsaWVudCBoYXMgYmVlbiBjdXN0b20gDQo+ICAgIGltcGxlbWVudGVkIHRvIHdvcmsgd2l0aCB0 aGF0IHNlcnZlci4gSWYgc28sIEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBhbiANCj4gICAgYXBwcm9w cmlhdGUgc3RhbmNlIGZvciBhIHNpcCBzdGFuZGFyZC4NCiAgDQpUaGUgc2VydmVyIG9ubHkgYXNz dW1lcyB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMgT0F1dGggLSB3aGljaCB0aGUgY2xpZW50IGNh biBpbmRpY2F0ZSB1c2luZyB0aGUgbWVkaWEgZmVhdHVyZSB0YWcuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQogDQoNCg== From nobody Sat Dec 14 12:42: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 B8FDD12002E for ; Sat, 14 Dec 2019 12:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 76tu6RujmsE8 for ; Sat, 14 Dec 2019 12:42:43 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 9C60012000F for ; Sat, 14 Dec 2019 12:42:43 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id x3so3632256oto.11 for ; Sat, 14 Dec 2019 12:42:43 -0800 (PST) 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=vSmxXpQ2ArRwFx8O2WSFsk4QYbJD/YWbBjiZ705Cztc=; b=BAmuGhqQn2Alb6DuEBuPUHZBJHLiVsuc83dR0u5+usj4yB4Fmikisvl0lU0QdeSd3t pNok7UZUgJS0Pm3UZ7C1EuZWp69ldwmCrlk6rQlYI3MdDKIC4aMkicdJVEJpQhLJ70+X 0xzf7pG5zntunh53R4Q415B5J0bxbk8Aadmt41fsC4e17T0rJ7yTQTMrwl7FYDpv6b6K JfG9nPCanuTamDJ6w4sKN0IfwixYY5jIdbp+Kkrfl0LZiBkx2ZVorkQBKzbl4A5fPMm6 +x/BZ9Y56n2HWDV3TL90atvQ/4tBgKxNZE1/CFjt772m3e7LChbUev/PumexDgysDptW hGvA== 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=vSmxXpQ2ArRwFx8O2WSFsk4QYbJD/YWbBjiZ705Cztc=; b=V6lXhNIHmv8lShIaFPoZY+ofkqzUJRPqacTApvUzqk6vixpAF1lCT4Wup8r1lsaY9f oBqkxr2g0lVaAEvK451qTOVBCMxjLW/FH3WSdD6HIfnNXv4tdPfvdr8eMt0i3A/4QRFY /bDdq1ZEigW4+8M3OJzfLN9Eih5DKZrush1va/Mv9gpHHOqvRYGb5j083MQBq6EbbjJa wEDq330mWEpok8KEk4rttU+vFlstSHzNYzJ2ZULZgnrbj4r+FLiEp7gpFn0RYtO/a9iA OV28YWomvzsUNDcowcZLEBPCaj4jYZ7MUGFE6+KclLB8nge1eiVuncFEcpD4o+RUU1Ps ES4A== X-Gm-Message-State: APjAAAWZreEl9H9tBh8JLr5ZAEfKdCTvoqSI8LcwWEGRDI5CBvI6b1X1 l+Cr9aC4Bvy2FMN7+8RIJYqM8bT5P1o= X-Google-Smtp-Source: APXvYqzd08Mgp6S2MD74WiQo6wisdrYmwaFA2RbumTUc8k9u3G11x+n1jFN2w91bz7ongGxYiH5yDQ== X-Received: by 2002:a9d:684e:: with SMTP id c14mr22706817oto.340.1576356162302; Sat, 14 Dec 2019 12:42:42 -0800 (PST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com. [209.85.167.175]) by smtp.gmail.com with ESMTPSA id r17sm4872881otq.70.2019.12.14.12.42.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Dec 2019 12:42:41 -0800 (PST) Received: by mail-oi1-f175.google.com with SMTP id x195so2573842oix.4 for ; Sat, 14 Dec 2019 12:42:40 -0800 (PST) X-Received: by 2002:aca:fc17:: with SMTP id a23mr8952794oii.63.1576356160362; Sat, 14 Dec 2019 12:42:40 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: From: Roman Shpount Date: Sat, 14 Dec 2019 15:42:33 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RFC Errata System , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , Ben Campbell , Alexey Melnikov , Adam Roach - SIPCORE Chair , Brian Rosen , "A. Jean Mahoney" , SIPCORE Content-Type: multipart/alternative; boundary="000000000000fa63490599b00486" Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 14 Dec 2019 20:42:47 -0000 --000000000000fa63490599b00486 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It looks like RFC 5630 allows this and there is a description of such flow in https://tools.ietf.org/html/rfc5630#section-6.4. Please disregard this errata. _____________ Roman Shpount On Sat, Dec 14, 2019 at 3:18 PM Roman Shpount wrote: > If you look at this message: > > INVITE sip:bob@example.com SIP/2.0 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > Max-Forwards: 70 > Supported: path, outbound, gruu > Route: > Contact: > Content-Type: application/sdp > > Then WS, not WSS should be used to send it. In order for WSS to be used, > Route header should be "Route: nsport=3Dws;lr>" . > > There is currently no standard compliant way to send a SIP message over > WSS (or any other secure protocol) and then have it forwarded over an > insecure protocol (UDP). Current example implies this is possible. > _____________ > Roman Shpount > > > On Sat, Dec 14, 2019 at 3:08 PM I=C3=B1aki Baz Castillo w= rote: > >> As replied in JsSIP mailing list, this is not a bug in 7118 but a genera= l >> design issue in RFC 3261. >> >> El s=C3=A1b., 14 dic. 2019 21:06, RFC Errata System >> escribi=C3=B3: >> >>> The following errata report has been submitted for RFC7118, >>> "The WebSocket Protocol as a Transport for the Session Initiation >>> Protocol (SIP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid5937 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Roman Shpount >>> >>> Section: 8.2 >>> >>> Original Text >>> ------------- >>> INVITE sip:bob@example.com SIP/2.0 >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Max-Forwards: 70 >>> Supported: path, outbound, gruu >>> Route: >>> Contact: >>> Content-Type: application/sdp >>> >>> >>> F2 100 Trying proxy.example.com -> Alice (transport WSS) >>> >>> SIP/2.0 100 Trying >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> >>> >>> F3 INVITE proxy.example.com -> Bob (transport UDP) >>> >>> INVITE sip:bob@203.0.113.22:5060 SIP/2.0 >>> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> Record-Route: , >>> >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Max-Forwards: 69 >>> Supported: path, outbound, gruu >>> Contact: >>> Content-Type: application/sdp >>> >>> F4 200 OK Bob -> proxy.example.com (transport UDP) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>> ;received=3D192.0.2.10 >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> Record-Route: , >>> >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Contact: >>> Content-Type: application/sdp >>> >>> >>> F5 200 OK proxy.example.com -> Alice (transport WSS) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> Record-Route: , >>> >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Contact: >>> Content-Type: application/sdp >>> >>> >>> F6 ACK Alice -> proxy.example.com (transport WSS) >>> >>> ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>> Route: , >>> , >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 ACK >>> Max-Forwards: 70 >>> >>> F7 ACK proxy.example.com -> Bob (transport UDP) >>> >>> ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 >>> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 ACK >>> Max-Forwards: 69 >>> >>> >>> F8 BYE Bob -> proxy.example.com (transport UDP) >>> >>> BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> Route: , >>> >>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>> To: sip:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> Max-Forwards: 70 >>> >>> >>> F9 BYE proxy.example.com -> Alice (transport WSS) >>> >>> BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>> To: sip:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> Max-Forwards: 69 >>> >>> >>> F10 200 OK Alice -> proxy.example.com (transport WSS) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>> To: sip:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> >>> >>> F11 200 OK proxy.example.com -> Bob (transport UDP) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>> To: sip:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> >>> Corrected Text >>> -------------- >>> F1 INVITE Alice -> proxy.example.com (transport WSS) >>> >>> INVITE sips:bob@example.com SIP/2.0 >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> From: sips:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Max-Forwards: 70 >>> Supported: path, outbound, gruu >>> Route: >>> Contact: >>> Content-Type: application/sdp >>> >>> >>> F2 100 Trying proxy.example.com -> Alice (transport WSS) >>> >>> SIP/2.0 100 Trying >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> From: sips:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> >>> >>> F3 INVITE proxy.example.com -> Bob (transport TLS) >>> >>> INVITE sips:bob@203.0.113.22 SIP/2.0 >>> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> Record-Route: , >>> >>> From: sip:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Max-Forwards: 69 >>> Supported: path, outbound, gruu >>> Contact: >> ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob> >>> Content-Type: application/sdp >>> >>> F4 200 OK Bob -> proxy.example.com (transport TLS) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>> ;received=3D192.0.2.10 >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> Record-Route: , >>> >>> From: sips:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Contact: >>> Content-Type: application/sdp >>> >>> >>> F5 200 OK proxy.example.com -> Alice (transport WSS) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>> Record-Route: , >>> >>> From: sips:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 INVITE >>> Contact: >>> Content-Type: application/sdp >>> >>> >>> F6 ACK Alice -> proxy.example.com (transport WSS) >>> >>> ACK sips:bob@203.0.113.22 SIP/2.0 >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>> Route: , >>> , >>> From: sips:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 ACK >>> Max-Forwards: 70 >>> >>> F7 ACK proxy.example.com -> Bob (transport TLS) >>> >>> ACK sips:bob@203.0.113.22 SIP/2.0 >>> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx >>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>> From: sips:alice@example.com;tag=3Dasdyka899 >>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>> Call-ID: asidkj3ss >>> CSeq: 1 ACK >>> Max-Forwards: 69 >>> >>> >>> F8 BYE Bob -> proxy.example.com (transport TLS) >>> >>> BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> Route: , >>> >>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>> To: sips:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> Max-Forwards: 70 >>> >>> >>> F9 BYE proxy.example.com -> Alice (transport WSS) >>> >>> BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>> To: sips:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> Max-Forwards: 69 >>> >>> >>> F10 200 OK Alice -> proxy.example.com (transport WSS) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>> To: sips:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> >>> >>> F11 200 OK proxy.example.com -> Bob (transport TLS) >>> >>> SIP/2.0 200 OK >>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>> To: sips:alice@example.com;tag=3Dasdyka899 >>> Call-ID: asidkj3ss >>> CSeq: 1201 BYE >>> >>> Notes >>> ----- >>> This example states that WSS protocol is used, but Route header >>> specifies SIP URI with transport=3Dws. which would mean WS (insecure We= b >>> Socket). Furthermore, if SIPS URI is used in Route header, then all oth= er >>> URI must be SIPS as well and message cannot be forwarded over UDP, SIPS >>> over TLS must be used instead. I have modified the entire example to us= e >>> SIPS and TLS, instead of SIP and UDP. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC7118 (draft-ietf-sipcore-sip-websocket-10) >>> -------------------------------------- >>> Title : The WebSocket Protocol as a Transport for the >>> Session Initiation Protocol (SIP) >>> Publication Date : January 2014 >>> Author(s) : I. Baz Castillo, J. Millan Villegas, V. Pascual >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol Core RAI >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> >> --000000000000fa63490599b00486 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It looks like RFC 5630 allows this and there is a descript= ion of such flow in=C2=A0 https://tools.i= etf.org/html/rfc5630#section-6.4.

Please disregard t= his errata.=C2=A0
_____________
Roman Shpount


On Sat, Dec 14, 2019 at 3:18 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">
If you lo= ok at this message:

INVITE=C2= =A0sip:bo= b@example.com=C2=A0SIP/2.0
Via: SIP/2.0/WSS= df7jal23ls0d.invalid;branch=3Dz9hG= 4bK56sdasks
From:=C2=A0sip:alice@example.com;tag= =3Dasdyka899
To:=C2=A0sip:bob@example.com
Call-ID: asidkj= 3ss
C= Seq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:4= 43;transport=3Dws;lr>
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-= 14a06cf1;ob>
Content-Type: application/sdp=C2=A0

<= div>Then WS, not WSS should be used to send it. In order for WSS to be used= , Route header should be "Route: <= sips:proxy.example.com:443;transport=3Dws;lr>" .
=
There is currently no standard compliant way to send a SIP m= essage over WSS (or any other secure protocol) and then have it forwarded o= ver an insecure protocol (UDP). Current example implies this is possible.
_____________
Roman Shpount
<= /div>

On Sat, Dec 14, 2019 at 3:08 PM I=C3=B1aki Baz Castill= o <ibc@aliax.net&= gt; wrote:
As replied in JsSIP mailing list, this is not a bug in 7118 bu= t a general design issue in RFC 3261.

<= div dir=3D"ltr" class=3D"gmail_attr">El s=C3=A1b., 14 dic. 2019 21:06, RFC = Errata System <rfc-editor@rfc-editor.org> escribi=C3=B3:
The following errata report has been= submitted for RFC7118,
"The WebSocket Protocol as a Transport for the Session Initiation Prot= ocol (SIP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5937
--------------------------------------
Type: Technical
Reported by: Roman Shpount <roman@telurix.com>

Section: 8.2

Original Text
-------------
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:443;transport=3Dws;lr>
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1= ;ob>
Content-Type: application/sdp


F2 100 Trying=C2=A0 proxy.example.com -> Alice (transport = WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE=C2=A0 proxy.example.com -> Bob (transport UDP)
INVITE sip:bob@203.0.113.22:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dwss;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1= ;ob>
Content-Type: application/sdp

F4 200 OK=C2=A0 Bob -> proxy.example.com (transport UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> =C2=A0;received=3D192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=3Dudp>
Content-Type: application/sdp


F5 200 OK=C2=A0 proxy.example.com -> Alice (transport WSS)=

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=3Dudp>
Content-Type: application/sdp


F6 ACK=C2=A0 Alice -> proxy.example.com (transport WSS)
ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>,
=C2=A0<sip:proxy.example.com;transport=3Dudp;lr>,
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK=C2=A0 proxy.example.com -> Bob (transport UDP)

ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx=
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE=C2=A0 Bob -> proxy.example.com (transport UDP)

BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2= .0
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
Route: <sip:proxy.example.com;transport=3Dudp;lr>,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE=C2=A0 proxy.example.com -> Alice (transport WSS)
BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2= .0
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK=C2=A0 Alice -> proxy.example.com (transport WSS= )

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK=C2=A0 proxy.example.com -> Bob (transport UDP)<= br>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Corrected Text
--------------
F1 INVITE=C2=A0 Alice -> proxy.example.com (transport WSS)=

INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sips:proxy.example.com:443;transport=3Dwss;lr>
Contact: <sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06c= f1;ob>
Content-Type: application/sdp


F2 100 Trying=C2=A0 proxy.example.com -> Alice (transport = WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE=C2=A0 proxy.example.com -> Bob (transport TLS)
INVITE sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sips:alice@example.com
=C2=A0;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp

F4 200 OK=C2=A0 Bob -> proxy.example.com (transport TLS)
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> =C2=A0;received=3D192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F5 200 OK=C2=A0 proxy.example.com -> Alice (transport WSS)=

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F6 ACK=C2=A0 Alice -> proxy.example.com (transport WSS)
ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
Route: <sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>,
=C2=A0<sips:proxy.example.com;lr>,
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK=C2=A0 proxy.example.com -> Bob (transport TLS)

ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx=
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE=C2=A0 Bob -> proxy.example.com (transport TLS)

BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob S= IP/2.0
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE=C2=A0 proxy.example.com -> Alice (transport WSS)
BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob S= IP/2.0
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK=C2=A0 Alice -> proxy.example.com (transport WSS= )

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK=C2=A0 proxy.example.com -> Bob (transport TLS)<= br>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Notes
-----
This example states that WSS protocol is used, but Route header specifies S= IP URI with transport=3Dws. which would mean WS (insecure Web Socket). Furt= hermore, if SIPS URI is used in Route header, then all other URI must be SI= PS as well and message cannot be forwarded over UDP, SIPS over TLS must be = used instead. I have modified the entire example to use SIPS and TLS, inste= ad of SIP and UDP.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7118 (draft-ietf-sipcore-sip-websocket-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The WebSocket= Protocol as a Transport for the Session Initiation Protocol (SIP)
Publication Date=C2=A0 =C2=A0 : January 2014
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: I. Baz Castillo, J. Mil= lan Villegas, V. Pascual
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Session Initiation= Protocol Core RAI
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Real-time App= lications and Infrastructure
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--000000000000fa63490599b00486-- From nobody Sat Dec 14 20:00: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 5D199120026 for ; Sat, 14 Dec 2019 12:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Xe28khISF5b7 for ; Sat, 14 Dec 2019 12:06:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE1912000F for ; Sat, 14 Dec 2019 12:06:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 98A51F406CB; Sat, 14 Dec 2019 12:06:23 -0800 (PST) To: ibc@aliax.net, jmillan@aliax.net, victor.pascual@quobis.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, br@brianrosen.net, mahoney@nostrum.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: roman@telurix.com, sipcore@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191214200623.98A51F406CB@rfc-editor.org> Date: Sat, 14 Dec 2019 12:06:23 -0800 (PST) Archived-At: X-Mailman-Approved-At: Sat, 14 Dec 2019 20:00:54 -0800 Subject: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 14 Dec 2019 20:06:40 -0000 The following errata report has been submitted for RFC7118, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5937 -------------------------------------- Type: Technical Reported by: Roman Shpount Section: 8.2 Original Text ------------- INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Route: Contact: Content-Type: application/sdp F2 100 Trying proxy.example.com -> Alice (transport WSS) SIP/2.0 100 Trying Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE F3 INVITE proxy.example.com -> Bob (transport UDP) INVITE sip:bob@203.0.113.22:5060 SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Supported: path, outbound, gruu Contact: Content-Type: application/sdp F4 200 OK Bob -> proxy.example.com (transport UDP) SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c ;received=192.0.2.10 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact: Content-Type: application/sdp F5 200 OK proxy.example.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact: Content-Type: application/sdp F6 ACK Alice -> proxy.example.com (transport WSS) ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Route: , , From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 70 F7 ACK proxy.example.com -> Bob (transport UDP) ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 From: sip:alice@example.com;tag=asdyka899 To: sip:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 69 F8 BYE Bob -> proxy.example.com (transport UDP) BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Route: , From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 70 F9 BYE proxy.example.com -> Alice (transport WSS) BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 69 F10 200 OK Alice -> proxy.example.com (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE F11 200 OK proxy.example.com -> Bob (transport UDP) SIP/2.0 200 OK Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Corrected Text -------------- F1 INVITE Alice -> proxy.example.com (transport WSS) INVITE sips:bob@example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sips:alice@example.com;tag=asdyka899 To: sips:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Route: Contact: Content-Type: application/sdp F2 100 Trying proxy.example.com -> Alice (transport WSS) SIP/2.0 100 Trying Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sips:alice@example.com;tag=asdyka899 To: sips:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE F3 INVITE proxy.example.com -> Bob (transport TLS) INVITE sips:bob@203.0.113.22 SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sip:alice@example.com;tag=asdyka899 To: sips:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Supported: path, outbound, gruu Contact: Content-Type: application/sdp F4 200 OK Bob -> proxy.example.com (transport TLS) SIP/2.0 200 OK Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhjhjqw32c ;received=192.0.2.10 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sips:alice@example.com;tag=asdyka899 To: sips:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact: Content-Type: application/sdp F5 200 OK proxy.example.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sips:alice@example.com;tag=asdyka899 To: sips:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Contact: Content-Type: application/sdp F6 ACK Alice -> proxy.example.com (transport WSS) ACK sips:bob@203.0.113.22 SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Route: , , From: sips:alice@example.com;tag=asdyka899 To: sips:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 70 F7 ACK proxy.example.com -> Bob (transport TLS) ACK sips:bob@203.0.113.22 SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bKhwpoc80zzx Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 From: sips:alice@example.com;tag=asdyka899 To: sips:bob@example.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 69 F8 BYE Bob -> proxy.example.com (transport TLS) BYE sips:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 Route: , From: sips:bob@example.com;tag=bmqkjhsd To: sips:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 70 F9 BYE proxy.example.com -> Alice (transport WSS) BYE sips:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sips:bob@example.com;tag=bmqkjhsd To: sips:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 69 F10 200 OK Alice -> proxy.example.com (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sips:bob@example.com;tag=bmqkjhsd To: sips:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE F11 200 OK proxy.example.com -> Bob (transport TLS) SIP/2.0 200 OK Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sips:bob@example.com;tag=bmqkjhsd To: sips:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Notes ----- This example states that WSS protocol is used, but Route header specifies SIP URI with transport=ws. which would mean WS (insecure Web Socket). Furthermore, if SIPS URI is used in Route header, then all other URI must be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS must be used instead. I have modified the entire example to use SIPS and TLS, instead of SIP and UDP. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7118 (draft-ietf-sipcore-sip-websocket-10) -------------------------------------- Title : The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) Publication Date : January 2014 Author(s) : I. Baz Castillo, J. Millan Villegas, V. Pascual Category : PROPOSED STANDARD Source : Session Initiation Protocol Core RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Sat Dec 14 20:01: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 A59E512000F for ; Sat, 14 Dec 2019 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 rsmwQC03VSU4 for ; Sat, 14 Dec 2019 12:08:06 -0800 (PST) Received: from mail-vs1-xe41.google.com (mail-vs1-xe41.google.com [IPv6:2607:f8b0:4864:20::e41]) (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 A4F5F120026 for ; Sat, 14 Dec 2019 12:08:05 -0800 (PST) Received: by mail-vs1-xe41.google.com with SMTP id f8so1743689vsq.8 for ; Sat, 14 Dec 2019 12:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0quLy7MubL3vhcx1CrDN94m+vkd5kPwv04UElhAP9QY=; b=HDnc+QAGXYZRGxcnpRv+6jjblqHGyyIbAcCEg5bZEGnUdFy8nb7JaO89dO9iHNKigb ml706GsqjkT4AN+Osy6eHTgwcPDOZLEiCDVeydJk+j/cOv7ThQrSo+o8JU3RfLq2TYx6 54bG82ohXB6Bho6tDa/10UBdMy4T+XeQQnnfJrSFIysDSPXQ52o2aMoXZvGVvS9oKfTs mdf3GjPO4OEW4FdRK4rREeSP6TJcQV0GahJLa9cPGM5Tlh5tWZ+oo0+aXmecvm961h9a ykWgOA5evxNN0kbNnhisVLaCsFBTTlwEcxtV93yERze1/1m+Bqrf5zZ9NlTV1LmInKjb BOuA== 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=0quLy7MubL3vhcx1CrDN94m+vkd5kPwv04UElhAP9QY=; b=LuYAUqjUGd+ziei5PZ9BMTop3crgZTHSECIxXIXnHMGUphiky8UjoWZZlD0V1CBhly DaNX/HIQ6jSXdw32vxbrnujq9fbRld+faZXe/EnqGmN9UkYclszav3ycdI5dBPUXvhGm GctdanVp9lG6hLaRgNTbh0SuvIssC1uYyYjx4udlgyAWkmZb8+4Ncpuz6sEoIJzjExCT GknW3iDmkZt0lfl76Gp7F8vCowmVTvnxNOoXneRXTH17S+w0z2NgahhkOICXVCWZKuSX xPHy+nSvvuObSEQvdptkH+7Kkwf8FnUN7dWgw0AypZNJ9l5D1U9cmP6CfxneGOUjlPuq f9hg== X-Gm-Message-State: APjAAAVsbAFVTBgOYnqZw7C2Jagr6AJTOp8GSx/UUgYK00YHgISj1duD /bJwp0rZ0qIE5n6yx4VeljsOifrb7duDB55pvdX21w== X-Google-Smtp-Source: APXvYqyCWNkChDpx6Uhc7ZuMskZUTRLsfB2nKVIjabRzcLVXlYAboISpt0R8xbhO+gDouzMmlSMrtlmT8XO8m9fL/Ws= X-Received: by 2002:a67:b309:: with SMTP id a9mr14781609vsm.97.1576354084471; Sat, 14 Dec 2019 12:08:04 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: <20191214200623.98A51F406CB@rfc-editor.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 14 Dec 2019 21:07:52 +0100 Message-ID: To: RFC Errata System Cc: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , victor.pascual@quobis.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, br@brianrosen.net, mahoney@nostrum.com, roman@telurix.com, sipcore@ietf.org Content-Type: multipart/alternative; boundary="0000000000003ede4a0599af893a" Archived-At: X-Mailman-Approved-At: Sat, 14 Dec 2019 20:00:54 -0800 Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 14 Dec 2019 20:08:10 -0000 --0000000000003ede4a0599af893a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As replied in JsSIP mailing list, this is not a bug in 7118 but a general design issue in RFC 3261. El s=C3=A1b., 14 dic. 2019 21:06, RFC Errata System escribi=C3=B3: > The following errata report has been submitted for RFC7118, > "The WebSocket Protocol as a Transport for the Session Initiation Protoco= l > (SIP)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5937 > > -------------------------------------- > Type: Technical > Reported by: Roman Shpount > > Section: 8.2 > > Original Text > ------------- > INVITE sip:bob@example.com SIP/2.0 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > Max-Forwards: 70 > Supported: path, outbound, gruu > Route: > Contact: > Content-Type: application/sdp > > > F2 100 Trying proxy.example.com -> Alice (transport WSS) > > SIP/2.0 100 Trying > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > > > F3 INVITE proxy.example.com -> Bob (transport UDP) > > INVITE sip:bob@203.0.113.22:5060 SIP/2.0 > Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > Record-Route: , > > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > Max-Forwards: 69 > Supported: path, outbound, gruu > Contact: > Content-Type: application/sdp > > F4 200 OK Bob -> proxy.example.com (transport UDP) > > SIP/2.0 200 OK > Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c > ;received=3D192.0.2.10 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > Record-Route: , > > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 INVITE > Contact: > Content-Type: application/sdp > > > F5 200 OK proxy.example.com -> Alice (transport WSS) > > SIP/2.0 200 OK > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > Record-Route: , > > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 INVITE > Contact: > Content-Type: application/sdp > > > F6 ACK Alice -> proxy.example.com (transport WSS) > > ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 > Route: , > , > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 ACK > Max-Forwards: 70 > > F7 ACK proxy.example.com -> Bob (transport UDP) > > ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 > Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 > From: sip:alice@example.com;tag=3Dasdyka899 > To: sip:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 ACK > Max-Forwards: 69 > > > F8 BYE Bob -> proxy.example.com (transport UDP) > > BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 > Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > Route: , > > From: sip:bob@example.com;tag=3Dbmqkjhsd > To: sip:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > Max-Forwards: 70 > > > F9 BYE proxy.example.com -> Alice (transport WSS) > > BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 > Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 > Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > From: sip:bob@example.com;tag=3Dbmqkjhsd > To: sip:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > Max-Forwards: 69 > > > F10 200 OK Alice -> proxy.example.com (transport WSS) > > SIP/2.0 200 OK > Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 > Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > From: sip:bob@example.com;tag=3Dbmqkjhsd > To: sip:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > > > F11 200 OK proxy.example.com -> Bob (transport UDP) > > SIP/2.0 200 OK > Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > From: sip:bob@example.com;tag=3Dbmqkjhsd > To: sip:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > > Corrected Text > -------------- > F1 INVITE Alice -> proxy.example.com (transport WSS) > > INVITE sips:bob@example.com SIP/2.0 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > From: sips:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > Max-Forwards: 70 > Supported: path, outbound, gruu > Route: > Contact: > Content-Type: application/sdp > > > F2 100 Trying proxy.example.com -> Alice (transport WSS) > > SIP/2.0 100 Trying > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > From: sips:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > > > F3 INVITE proxy.example.com -> Bob (transport TLS) > > INVITE sips:bob@203.0.113.22 SIP/2.0 > Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > Record-Route: , > > From: sip:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com > Call-ID: asidkj3ss > CSeq: 1 INVITE > Max-Forwards: 69 > Supported: path, outbound, gruu > Contact: ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob> > Content-Type: application/sdp > > F4 200 OK Bob -> proxy.example.com (transport TLS) > > SIP/2.0 200 OK > Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c > ;received=3D192.0.2.10 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > Record-Route: , > > From: sips:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 INVITE > Contact: > Content-Type: application/sdp > > > F5 200 OK proxy.example.com -> Alice (transport WSS) > > SIP/2.0 200 OK > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > Record-Route: , > > From: sips:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 INVITE > Contact: > Content-Type: application/sdp > > > F6 ACK Alice -> proxy.example.com (transport WSS) > > ACK sips:bob@203.0.113.22 SIP/2.0 > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 > Route: , > , > From: sips:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 ACK > Max-Forwards: 70 > > F7 ACK proxy.example.com -> Bob (transport TLS) > > ACK sips:bob@203.0.113.22 SIP/2.0 > Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 > From: sips:alice@example.com;tag=3Dasdyka899 > To: sips:bob@example.com;tag=3Dbmqkjhsd > Call-ID: asidkj3ss > CSeq: 1 ACK > Max-Forwards: 69 > > > F8 BYE Bob -> proxy.example.com (transport TLS) > > BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 > Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > Route: , > > From: sips:bob@example.com;tag=3Dbmqkjhsd > To: sips:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > Max-Forwards: 70 > > > F9 BYE proxy.example.com -> Alice (transport WSS) > > BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 > Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 > Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > From: sips:bob@example.com;tag=3Dbmqkjhsd > To: sips:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > Max-Forwards: 69 > > > F10 200 OK Alice -> proxy.example.com (transport WSS) > > SIP/2.0 200 OK > Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 > Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > From: sips:bob@example.com;tag=3Dbmqkjhsd > To: sips:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > > > F11 200 OK proxy.example.com -> Bob (transport TLS) > > SIP/2.0 200 OK > Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 > From: sips:bob@example.com;tag=3Dbmqkjhsd > To: sips:alice@example.com;tag=3Dasdyka899 > Call-ID: asidkj3ss > CSeq: 1201 BYE > > Notes > ----- > This example states that WSS protocol is used, but Route header specifies > SIP URI with transport=3Dws. which would mean WS (insecure Web Socket). > Furthermore, if SIPS URI is used in Route header, then all other URI must > be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS > must be used instead. I have modified the entire example to use SIPS and > TLS, instead of SIP and UDP. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7118 (draft-ietf-sipcore-sip-websocket-10) > -------------------------------------- > Title : The WebSocket Protocol as a Transport for the > Session Initiation Protocol (SIP) > Publication Date : January 2014 > Author(s) : I. Baz Castillo, J. Millan Villegas, V. Pascual > Category : PROPOSED STANDARD > Source : Session Initiation Protocol Core RAI > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > --0000000000003ede4a0599af893a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As replied in JsSIP mailing list, this is not a bug in 71= 18 but a general design issue in RFC 3261.

El s=C3=A1b., 14 dic. 2019 21:06,= RFC Errata System <rfc-edi= tor@rfc-editor.org> escribi=C3=B3:
The following errata report has been submitted for RFC7118,
"The WebSocket Protocol as a Transport for the Session Initiation Prot= ocol (SIP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5937
--------------------------------------
Type: Technical
Reported by: Roman Shpount <roman@telurix.com>

Section: 8.2

Original Text
-------------
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:443;transport=3Dws;lr>
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1= ;ob>
Content-Type: application/sdp


F2 100 Trying=C2=A0 proxy.example.com -> Alice (transport = WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE=C2=A0 proxy.example.com -> Bob (transport UDP)
INVITE sip:bob@203.0.113.22:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dwss;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1= ;ob>
Content-Type: application/sdp

F4 200 OK=C2=A0 Bob -> proxy.example.com (transport UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> =C2=A0;received=3D192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=3Dudp>
Content-Type: application/sdp


F5 200 OK=C2=A0 proxy.example.com -> Alice (transport WSS)=

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=3Dudp>
Content-Type: application/sdp


F6 ACK=C2=A0 Alice -> proxy.example.com (transport WSS)
ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>,
=C2=A0<sip:proxy.example.com;transport=3Dudp;lr>,
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK=C2=A0 proxy.example.com -> Bob (transport UDP)

ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx=
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE=C2=A0 Bob -> proxy.example.com (transport UDP)

BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2= .0
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
Route: <sip:proxy.example.com;transport=3Dudp;lr>,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE=C2=A0 proxy.example.com -> Alice (transport WSS)
BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2= .0
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK=C2=A0 Alice -> proxy.example.com (transport WSS= )

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK=C2=A0 proxy.example.com -> Bob (transport UDP)<= br>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Corrected Text
--------------
F1 INVITE=C2=A0 Alice -> proxy.example.com (transport WSS)=

INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sips:proxy.example.com:443;transport=3Dwss;lr>
Contact: <sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06c= f1;ob>
Content-Type: application/sdp


F2 100 Trying=C2=A0 proxy.example.com -> Alice (transport = WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE=C2=A0 proxy.example.com -> Bob (transport TLS)
INVITE sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sips:alice@example.com
=C2=A0;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp

F4 200 OK=C2=A0 Bob -> proxy.example.com (transport TLS)
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> =C2=A0;received=3D192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F5 200 OK=C2=A0 proxy.example.com -> Alice (transport WSS)=

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F6 ACK=C2=A0 Alice -> proxy.example.com (transport WSS)
ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
Route: <sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>,
=C2=A0<sips:proxy.example.com;lr>,
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK=C2=A0 proxy.example.com -> Bob (transport TLS)

ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx=
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE=C2=A0 Bob -> proxy.example.com (transport TLS)

BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP= /2.0
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE=C2=A0 proxy.example.com -> Alice (transport WSS)
BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP= /2.0
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK=C2=A0 Alice -> proxy.example.com (transport WSS= )

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK=C2=A0 proxy.example.com -> Bob (transport TLS)<= br>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Notes
-----
This example states that WSS protocol is used, but Route header specifies S= IP URI with transport=3Dws. which would mean WS (insecure Web Socket). Furt= hermore, if SIPS URI is used in Route header, then all other URI must be SI= PS as well and message cannot be forwarded over UDP, SIPS over TLS must be = used instead. I have modified the entire example to use SIPS and TLS, inste= ad of SIP and UDP.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7118 (draft-ietf-sipcore-sip-websocket-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The WebSocket= Protocol as a Transport for the Session Initiation Protocol (SIP)
Publication Date=C2=A0 =C2=A0 : January 2014
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: I. Baz Castillo, J. Mil= lan Villegas, V. Pascual
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Session Initiation= Protocol Core RAI
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Real-time App= lications and Infrastructure
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000003ede4a0599af893a-- From nobody Sat Dec 14 20:01: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 E4528120026 for ; Sat, 14 Dec 2019 12:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 I6yB1qxs7iKg for ; Sat, 14 Dec 2019 12:18:42 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 D461D12000F for ; Sat, 14 Dec 2019 12:18:41 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id o9so3661773ote.2 for ; Sat, 14 Dec 2019 12:18:41 -0800 (PST) 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=WJpYts2DzdiK0CdBCmCihoqSq79MvybcK09B3c+RJVk=; b=gYxT1YK50BtaqCozVi/8lqWlQstzoGTc1oDl8G9MM6btkd9anbogKGwZjHls1JNNYL Ec2gEcTRD6xob2NjaLiIAjKsOIkNz9t3SvKGE2vBXI20GfBTYJ+tHvFI1qrSzS40Xv3z 2FsRp7BPUMa2H+/1JB5+LGzspMKFPdzPrpa1+wxkRYqe6siIorcpgpsChDK9Zf7W1G4s VZ6xtOrFj67w+2MJck6zg28wjmBf4xw6fr3YSVn82mWk8Qi1HAoQzrkidUBfyMLxw7lh wDWlnvy4dkJt6RXuKdr9aYx+sCS7t3UM/5EaRkUgq+NnecJu/w6T2w5Qk76Df/Sz+mDR St9Q== 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=WJpYts2DzdiK0CdBCmCihoqSq79MvybcK09B3c+RJVk=; b=TgotGNhuIrODte+/LKsTRCwT4wuEx9kamRKWBYjt+bWOg4sdsjYumJwLgP4XuKvnn6 gykx0B79O13GkZD8LEUXHe9JrNDfvyVpzOG0HFnrfMdPYJaMOSN6wwbpBJrkl+CpjjFm l5h/p8EY92zNcXA3/2Ohv5aPguRx65QL4lhCkXIqw4vsqboTBGx/xiBGZxmlNr1GvDhp +WZPBAkf1WDVh1PV/gK5k7cDP/QZ+J9XT5uEbj0EBioRUVqfeI52IqT0Gth9zhnSkqPX 6mO87M+35yWYn7W30NkTQyzC+v1WBesXTrD8FFAvMXHEh6Z6p2hvOwGVnA7GeHLUtdBK GHDg== X-Gm-Message-State: APjAAAXJXT9kEjEKAAmfcOeQb3FrJCgR2noHpEMyDddiQC8mRM/cteot vL+AAd2Z1rXm8fcBySGrzbZqoi4Fo2E= X-Google-Smtp-Source: APXvYqxaa0repptTx75odvF1nZLXDM0LvbvzTrRS8RmGs7cecC43aIiH8a4zqIiI8IcRjmCebmlbbQ== X-Received: by 2002:a05:6830:2087:: with SMTP id y7mr21108407otq.96.1576354720561; Sat, 14 Dec 2019 12:18:40 -0800 (PST) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com. [209.85.167.174]) by smtp.gmail.com with ESMTPSA id k6sm4808492otb.65.2019.12.14.12.18.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Dec 2019 12:18:39 -0800 (PST) Received: by mail-oi1-f174.google.com with SMTP id v140so2578412oie.0 for ; Sat, 14 Dec 2019 12:18:39 -0800 (PST) X-Received: by 2002:a05:6808:8d5:: with SMTP id k21mr8796714oij.121.1576354718595; Sat, 14 Dec 2019 12:18:38 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: From: Roman Shpount Date: Sat, 14 Dec 2019 15:18:31 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RFC Errata System , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , victor.pascual@quobis.com, Ben Campbell , Alexey Melnikov , Adam Roach - SIPCORE Chair , Brian Rosen , "A. Jean Mahoney" , SIPCORE Content-Type: multipart/alternative; boundary="0000000000000ae5340599afaf22" Archived-At: X-Mailman-Approved-At: Sat, 14 Dec 2019 20:00:54 -0800 Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 14 Dec 2019 20:18:45 -0000 --0000000000000ae5340599afaf22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you look at this message: INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks From: sip:alice@example.com;tag=3Dasdyka899 To: sip:bob@example.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Route: Contact: Content-Type: application/sdp Then WS, not WSS should be used to send it. In order for WSS to be used, Route header should be "Route: " . There is currently no standard compliant way to send a SIP message over WSS (or any other secure protocol) and then have it forwarded over an insecure protocol (UDP). Current example implies this is possible. _____________ Roman Shpount On Sat, Dec 14, 2019 at 3:08 PM I=C3=B1aki Baz Castillo wro= te: > As replied in JsSIP mailing list, this is not a bug in 7118 but a general > design issue in RFC 3261. > > El s=C3=A1b., 14 dic. 2019 21:06, RFC Errata System > escribi=C3=B3: > >> The following errata report has been submitted for RFC7118, >> "The WebSocket Protocol as a Transport for the Session Initiation >> Protocol (SIP)". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5937 >> >> -------------------------------------- >> Type: Technical >> Reported by: Roman Shpount >> >> Section: 8.2 >> >> Original Text >> ------------- >> INVITE sip:bob@example.com SIP/2.0 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Max-Forwards: 70 >> Supported: path, outbound, gruu >> Route: >> Contact: >> Content-Type: application/sdp >> >> >> F2 100 Trying proxy.example.com -> Alice (transport WSS) >> >> SIP/2.0 100 Trying >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> >> >> F3 INVITE proxy.example.com -> Bob (transport UDP) >> >> INVITE sip:bob@203.0.113.22:5060 SIP/2.0 >> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> Record-Route: , >> >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Max-Forwards: 69 >> Supported: path, outbound, gruu >> Contact: >> Content-Type: application/sdp >> >> F4 200 OK Bob -> proxy.example.com (transport UDP) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >> ;received=3D192.0.2.10 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> Record-Route: , >> >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Contact: >> Content-Type: application/sdp >> >> >> F5 200 OK proxy.example.com -> Alice (transport WSS) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> Record-Route: , >> >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Contact: >> Content-Type: application/sdp >> >> >> F6 ACK Alice -> proxy.example.com (transport WSS) >> >> ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >> Route: , >> , >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 ACK >> Max-Forwards: 70 >> >> F7 ACK proxy.example.com -> Bob (transport UDP) >> >> ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 >> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 ACK >> Max-Forwards: 69 >> >> >> F8 BYE Bob -> proxy.example.com (transport UDP) >> >> BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> Route: , >> >> From: sip:bob@example.com;tag=3Dbmqkjhsd >> To: sip:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> Max-Forwards: 70 >> >> >> F9 BYE proxy.example.com -> Alice (transport WSS) >> >> BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> From: sip:bob@example.com;tag=3Dbmqkjhsd >> To: sip:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> Max-Forwards: 69 >> >> >> F10 200 OK Alice -> proxy.example.com (transport WSS) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> From: sip:bob@example.com;tag=3Dbmqkjhsd >> To: sip:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> >> >> F11 200 OK proxy.example.com -> Bob (transport UDP) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> From: sip:bob@example.com;tag=3Dbmqkjhsd >> To: sip:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> >> Corrected Text >> -------------- >> F1 INVITE Alice -> proxy.example.com (transport WSS) >> >> INVITE sips:bob@example.com SIP/2.0 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> From: sips:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Max-Forwards: 70 >> Supported: path, outbound, gruu >> Route: >> Contact: >> Content-Type: application/sdp >> >> >> F2 100 Trying proxy.example.com -> Alice (transport WSS) >> >> SIP/2.0 100 Trying >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> From: sips:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> >> >> F3 INVITE proxy.example.com -> Bob (transport TLS) >> >> INVITE sips:bob@203.0.113.22 SIP/2.0 >> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> Record-Route: , >> >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Max-Forwards: 69 >> Supported: path, outbound, gruu >> Contact: > ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob> >> Content-Type: application/sdp >> >> F4 200 OK Bob -> proxy.example.com (transport TLS) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >> ;received=3D192.0.2.10 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> Record-Route: , >> >> From: sips:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Contact: >> Content-Type: application/sdp >> >> >> F5 200 OK proxy.example.com -> Alice (transport WSS) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> Record-Route: , >> >> From: sips:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Contact: >> Content-Type: application/sdp >> >> >> F6 ACK Alice -> proxy.example.com (transport WSS) >> >> ACK sips:bob@203.0.113.22 SIP/2.0 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >> Route: , >> , >> From: sips:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 ACK >> Max-Forwards: 70 >> >> F7 ACK proxy.example.com -> Bob (transport TLS) >> >> ACK sips:bob@203.0.113.22 SIP/2.0 >> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >> From: sips:alice@example.com;tag=3Dasdyka899 >> To: sips:bob@example.com;tag=3Dbmqkjhsd >> Call-ID: asidkj3ss >> CSeq: 1 ACK >> Max-Forwards: 69 >> >> >> F8 BYE Bob -> proxy.example.com (transport TLS) >> >> BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> Route: , >> >> From: sips:bob@example.com;tag=3Dbmqkjhsd >> To: sips:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> Max-Forwards: 70 >> >> >> F9 BYE proxy.example.com -> Alice (transport WSS) >> >> BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> From: sips:bob@example.com;tag=3Dbmqkjhsd >> To: sips:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> Max-Forwards: 69 >> >> >> F10 200 OK Alice -> proxy.example.com (transport WSS) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> From: sips:bob@example.com;tag=3Dbmqkjhsd >> To: sips:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> >> >> F11 200 OK proxy.example.com -> Bob (transport TLS) >> >> SIP/2.0 200 OK >> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >> From: sips:bob@example.com;tag=3Dbmqkjhsd >> To: sips:alice@example.com;tag=3Dasdyka899 >> Call-ID: asidkj3ss >> CSeq: 1201 BYE >> >> Notes >> ----- >> This example states that WSS protocol is used, but Route header specifie= s >> SIP URI with transport=3Dws. which would mean WS (insecure Web Socket). >> Furthermore, if SIPS URI is used in Route header, then all other URI mus= t >> be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS >> must be used instead. I have modified the entire example to use SIPS and >> TLS, instead of SIP and UDP. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7118 (draft-ietf-sipcore-sip-websocket-10) >> -------------------------------------- >> Title : The WebSocket Protocol as a Transport for the >> Session Initiation Protocol (SIP) >> Publication Date : January 2014 >> Author(s) : I. Baz Castillo, J. Millan Villegas, V. Pascual >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol Core RAI >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> > --0000000000000ae5340599afaf22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you look at this message:

INVITE=C2=A0sip:bob@example.com=C2=A0SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
= From:=C2=A0sip:alice@example.com;tag=3Dasdyka= 899
T= o:=C2=A0s= ip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, g= ruu
R= oute: <sip:proxy.example.com:443;tra= nsport=3Dws;lr>
Contact: <sip:alice@example.com= ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp= =C2=A0

Then WS, not WSS should be used to send it.= In order for WSS to be used, Route header should be "Route: <sips:proxy.example.com:443;transport=3Dws;lr&g= t;" .

There is currently no standard c= ompliant way to send a SIP message over WSS (or any other secure protocol) = and then have it forwarded over an insecure protocol (UDP). Current example= implies this is possible.
_____________
Roman = Shpount


On Sat, Dec 14, 2019 at 3:08 PM I=C3=B1a= ki Baz Castillo <ibc@aliax.net> = wrote:
As replied in JsSIP mailing list, this is not a bug in 7118 but a= general design issue in RFC 3261.

El s=C3=A1b., 14 dic. 2019 21:06, RFC Err= ata System <rfc-editor@rfc-editor.org> escribi=C3=B3:
The following errata report has been su= bmitted for RFC7118,
"The WebSocket Protocol as a Transport for the Session Initiation Prot= ocol (SIP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5937
--------------------------------------
Type: Technical
Reported by: Roman Shpount <roman@telurix.com>

Section: 8.2

Original Text
-------------
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:443;transport=3Dws;lr>
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1= ;ob>
Content-Type: application/sdp


F2 100 Trying=C2=A0 proxy.example.com -> Alice (transport = WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE=C2=A0 proxy.example.com -> Bob (transport UDP)
INVITE sip:bob@203.0.113.22:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dwss;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1= ;ob>
Content-Type: application/sdp

F4 200 OK=C2=A0 Bob -> proxy.example.com (transport UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> =C2=A0;received=3D192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=3Dudp>
Content-Type: application/sdp


F5 200 OK=C2=A0 proxy.example.com -> Alice (transport WSS)=

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=3Dudp;lr>= ;,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=3Dudp>
Content-Type: application/sdp


F6 ACK=C2=A0 Alice -> proxy.example.com (transport WSS)
ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>,
=C2=A0<sip:proxy.example.com;transport=3Dudp;lr>,
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK=C2=A0 proxy.example.com -> Bob (transport UDP)

ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx=
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
From: sip:alice@example.com;tag=3Dasdyka899
To: sip:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE=C2=A0 Bob -> proxy.example.com (transport UDP)

BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2= .0
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
Route: <sip:proxy.example.com;transport=3Dudp;lr>,
=C2=A0<sip:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE=C2=A0 proxy.example.com -> Alice (transport WSS)
BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2= .0
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK=C2=A0 Alice -> proxy.example.com (transport WSS= )

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK=C2=A0 proxy.example.com -> Bob (transport UDP)<= br>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sip:bob@example.com;tag=3Dbmqkjhsd
To: sip:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Corrected Text
--------------
F1 INVITE=C2=A0 Alice -> proxy.example.com (transport WSS)=

INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sips:proxy.example.com:443;transport=3Dwss;lr>
Contact: <sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06c= f1;ob>
Content-Type: application/sdp


F2 100 Trying=C2=A0 proxy.example.com -> Alice (transport = WSS)

SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE=C2=A0 proxy.example.com -> Bob (transport TLS)
INVITE sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sip:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sips:alice@example.com
=C2=A0;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp

F4 200 OK=C2=A0 Bob -> proxy.example.com (transport TLS)
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c<= br> =C2=A0;received=3D192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F5 200 OK=C2=A0 proxy.example.com -> Alice (transport WSS)=

SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
Record-Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sips:bob@203.0.113.22>
Content-Type: application/sdp


F6 ACK=C2=A0 Alice -> proxy.example.com (transport WSS)
ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
Route: <sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>,
=C2=A0<sips:proxy.example.com;lr>,
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK=C2=A0 proxy.example.com -> Bob (transport TLS)

ACK sips:bob@203.0.113.22 SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx=
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
From: sips:alice@example.com;tag=3Dasdyka899
To: sips:bob@example.com;tag=3Dbmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE=C2=A0 Bob -> proxy.example.com (transport TLS)

BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob S= IP/2.0
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
Route: <sips:proxy.example.com;lr>,
=C2=A0<sips:h7kjh12s@proxy.example.com:443;transport=3Dws;lr>
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE=C2=A0 proxy.example.com -> Alice (transport WSS)
BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob S= IP/2.0
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69


F10 200 OK=C2=A0 Alice -> proxy.example.com (transport WSS= )

SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE


F11 200 OK=C2=A0 proxy.example.com -> Bob (transport TLS)<= br>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
From: sips:bob@example.com;tag=3Dbmqkjhsd
To: sips:alice@example.com;tag=3Dasdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

Notes
-----
This example states that WSS protocol is used, but Route header specifies S= IP URI with transport=3Dws. which would mean WS (insecure Web Socket). Furt= hermore, if SIPS URI is used in Route header, then all other URI must be SI= PS as well and message cannot be forwarded over UDP, SIPS over TLS must be = used instead. I have modified the entire example to use SIPS and TLS, inste= ad of SIP and UDP.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7118 (draft-ietf-sipcore-sip-websocket-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The WebSocket= Protocol as a Transport for the Session Initiation Protocol (SIP)
Publication Date=C2=A0 =C2=A0 : January 2014
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: I. Baz Castillo, J. Mil= lan Villegas, V. Pascual
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Session Initiation= Protocol Core RAI
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Real-time App= lications and Infrastructure
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000000ae5340599afaf22-- From nobody Sun Dec 15 14:55: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 B269D120128 for ; Sun, 15 Dec 2019 14:54:54 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.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 SV2__ytUHejY for ; Sun, 15 Dec 2019 14:54:51 -0800 (PST) Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (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 80B58120119 for ; Sun, 15 Dec 2019 14:54:51 -0800 (PST) Received: by mail-ua1-x942.google.com with SMTP id f7so1433007uaa.8 for ; Sun, 15 Dec 2019 14:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=StJGulM4deQ0SyI1rJqFTY23lAf8vy7RD+7pMd0/cQc=; b=n48lo0SjNMtnATspnUUSV+2rx/JBXfi7ZYn28HyBkYoSt57ZcP+yKHcyM3WiWci+PB +z0L5uMP/LnvC9dEghdSdunfPYWA/vhVvKgcXM+XYoPRAj2tUh1sodB/ge8G3Rr4hL3O 9eS/gJ9mLl2nh1gnvdqVLJTsMs4xsUfoMvhaQBNjTKQtcgbdUYDs+8gzrjNRjG1Yd5M/ bf9OY1hLIwSqpMyEnWDtMfZD3FntcmMB/zAzdpO/kUmHXLxLkDYgDX87qnay3ebMxqRV UX+WbcxzdNVXdN6begOTSMAsbsTIV1AqCBJGFlreX8opms7hUU41BmHa/pAelMQKrap2 S+kg== 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:content-transfer-encoding; bh=StJGulM4deQ0SyI1rJqFTY23lAf8vy7RD+7pMd0/cQc=; b=luG9/Zty6JCbWR+VxPk43sC19cUGq7oAJNkQGhRSOPkQoH7f59d6GhChZVPdYB0aJu 8vv/UfhrqWMvr5LlhL0/yVNxYRUx1cmvYFjqwhaMA+F5x/rarfpGa0BsWKqQDTFtanaZ uDGqYhwWCE+CiqClXwNiVPBpwRMnA+GneBAAR7IxujyjJM9woh/iSOzB0jrmkbVyaE1T 8+WeMmq6fPZ25qxCOg1XOsd8sPvMHJjgRwtLvue2KXfH2ww1hjX7jzl2PZgmpyMEPRIq HV0APEIW0JbH+Xe0uWnN84jLTrMTr1QtDFiwTFvEi1RrWzQnyZNe+sX8GmBS12qu1r5m 1x5w== X-Gm-Message-State: APjAAAVxHlGrn0YbpnUy3eIfsfcTq+Oang5pSlXWnBVIA3ek0WvgRzPP 7vKP5iD74s/9VsMXz/+wRewt5V+GQ1rZUZmUYDeAaw== X-Google-Smtp-Source: APXvYqwJsra9dmM9sxVJHcuC6P639noaRUsoaechgQ0WNAFsVweLSLAgldTaiAMl/bwVUt+K+4IGk0clLNisZxJJJ1Q= X-Received: by 2002:ab0:24cd:: with SMTP id k13mr22092066uan.66.1576450490293; Sun, 15 Dec 2019 14:54:50 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 15 Dec 2019 23:54:39 +0100 Message-ID: To: Roman Shpount Cc: RFC Errata System , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , Ben Campbell , Alexey Melnikov , Adam Roach - SIPCORE Chair , Brian Rosen , "A. Jean Mahoney" , SIPCORE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 15 Dec 2019 22:54:58 -0000 Yeah, that's exactly the section I meant :) On Sat, 14 Dec 2019 at 21:42, Roman Shpount wrote: > > It looks like RFC 5630 allows this and there is a description of such flo= w in https://tools.ietf.org/html/rfc5630#section-6.4. > > Please disregard this errata. > _____________ > Roman Shpount > > > On Sat, Dec 14, 2019 at 3:18 PM Roman Shpount wrote: >> >> If you look at this message: >> >> INVITE sip:bob@example.com SIP/2.0 >> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >> From: sip:alice@example.com;tag=3Dasdyka899 >> To: sip:bob@example.com >> Call-ID: asidkj3ss >> CSeq: 1 INVITE >> Max-Forwards: 70 >> Supported: path, outbound, gruu >> Route: >> Contact: >> Content-Type: application/sdp >> >> Then WS, not WSS should be used to send it. In order for WSS to be used,= Route header should be "Route: " . >> >> There is currently no standard compliant way to send a SIP message over = WSS (or any other secure protocol) and then have it forwarded over an insec= ure protocol (UDP). Current example implies this is possible. >> _____________ >> Roman Shpount >> >> >> On Sat, Dec 14, 2019 at 3:08 PM I=C3=B1aki Baz Castillo = wrote: >>> >>> As replied in JsSIP mailing list, this is not a bug in 7118 but a gener= al design issue in RFC 3261. >>> >>> El s=C3=A1b., 14 dic. 2019 21:06, RFC Errata System escribi=C3=B3: >>>> >>>> The following errata report has been submitted for RFC7118, >>>> "The WebSocket Protocol as a Transport for the Session Initiation Prot= ocol (SIP)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://www.rfc-editor.org/errata/eid5937 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Roman Shpount >>>> >>>> Section: 8.2 >>>> >>>> Original Text >>>> ------------- >>>> INVITE sip:bob@example.com SIP/2.0 >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Max-Forwards: 70 >>>> Supported: path, outbound, gruu >>>> Route: >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> >>>> F2 100 Trying proxy.example.com -> Alice (transport WSS) >>>> >>>> SIP/2.0 100 Trying >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> >>>> >>>> F3 INVITE proxy.example.com -> Bob (transport UDP) >>>> >>>> INVITE sip:bob@203.0.113.22:5060 SIP/2.0 >>>> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> Record-Route: , >>>> >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Max-Forwards: 69 >>>> Supported: path, outbound, gruu >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> F4 200 OK Bob -> proxy.example.com (transport UDP) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>>> ;received=3D192.0.2.10 >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> Record-Route: , >>>> >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> >>>> F5 200 OK proxy.example.com -> Alice (transport WSS) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> Record-Route: , >>>> >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> >>>> F6 ACK Alice -> proxy.example.com (transport WSS) >>>> >>>> ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>>> Route: , >>>> , >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 ACK >>>> Max-Forwards: 70 >>>> >>>> F7 ACK proxy.example.com -> Bob (transport UDP) >>>> >>>> ACK sip:bob@203.0.113.22:5060;transport=3Dudp SIP/2.0 >>>> Via: SIP/2.0/UDP proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sip:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 ACK >>>> Max-Forwards: 69 >>>> >>>> >>>> F8 BYE Bob -> proxy.example.com (transport UDP) >>>> >>>> BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> Route: , >>>> >>>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>>> To: sip:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> Max-Forwards: 70 >>>> >>>> >>>> F9 BYE proxy.example.com -> Alice (transport WSS) >>>> >>>> BYE sip:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>>> To: sip:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> Max-Forwards: 69 >>>> >>>> >>>> F10 200 OK Alice -> proxy.example.com (transport WSS) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>>> To: sip:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> >>>> >>>> F11 200 OK proxy.example.com -> Bob (transport UDP) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/UDP 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> From: sip:bob@example.com;tag=3Dbmqkjhsd >>>> To: sip:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> >>>> Corrected Text >>>> -------------- >>>> F1 INVITE Alice -> proxy.example.com (transport WSS) >>>> >>>> INVITE sips:bob@example.com SIP/2.0 >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> From: sips:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Max-Forwards: 70 >>>> Supported: path, outbound, gruu >>>> Route: >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> >>>> F2 100 Trying proxy.example.com -> Alice (transport WSS) >>>> >>>> SIP/2.0 100 Trying >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> From: sips:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> >>>> >>>> F3 INVITE proxy.example.com -> Bob (transport TLS) >>>> >>>> INVITE sips:bob@203.0.113.22 SIP/2.0 >>>> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> Record-Route: , >>>> >>>> From: sip:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Max-Forwards: 69 >>>> Supported: path, outbound, gruu >>>> Contact: >>> ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob> >>>> Content-Type: application/sdp >>>> >>>> F4 200 OK Bob -> proxy.example.com (transport TLS) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhjhjqw32c >>>> ;received=3D192.0.2.10 >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> Record-Route: , >>>> >>>> From: sips:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> >>>> F5 200 OK proxy.example.com -> Alice (transport WSS) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks >>>> Record-Route: , >>>> >>>> From: sips:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 INVITE >>>> Contact: >>>> Content-Type: application/sdp >>>> >>>> >>>> F6 ACK Alice -> proxy.example.com (transport WSS) >>>> >>>> ACK sips:bob@203.0.113.22 SIP/2.0 >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>>> Route: , >>>> , >>>> From: sips:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 ACK >>>> Max-Forwards: 70 >>>> >>>> F7 ACK proxy.example.com -> Bob (transport TLS) >>>> >>>> ACK sips:bob@203.0.113.22 SIP/2.0 >>>> Via: SIP/2.0/TLS proxy.example.com;branch=3Dz9hG4bKhwpoc80zzx >>>> Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090 >>>> From: sips:alice@example.com;tag=3Dasdyka899 >>>> To: sips:bob@example.com;tag=3Dbmqkjhsd >>>> Call-ID: asidkj3ss >>>> CSeq: 1 ACK >>>> Max-Forwards: 69 >>>> >>>> >>>> F8 BYE Bob -> proxy.example.com (transport TLS) >>>> >>>> BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> Route: , >>>> >>>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>>> To: sips:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> Max-Forwards: 70 >>>> >>>> >>>> F9 BYE proxy.example.com -> Alice (transport WSS) >>>> >>>> BYE sips:alice@example.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 >>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>>> To: sips:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> Max-Forwards: 69 >>>> >>>> >>>> F10 200 OK Alice -> proxy.example.com (transport WSS) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/WSS proxy.example.com:443;branch=3Dz9hG4bKmma01m3r5 >>>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>>> To: sips:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> >>>> >>>> F11 200 OK proxy.example.com -> Bob (transport TLS) >>>> >>>> SIP/2.0 200 OK >>>> Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001 >>>> From: sips:bob@example.com;tag=3Dbmqkjhsd >>>> To: sips:alice@example.com;tag=3Dasdyka899 >>>> Call-ID: asidkj3ss >>>> CSeq: 1201 BYE >>>> >>>> Notes >>>> ----- >>>> This example states that WSS protocol is used, but Route header specif= ies SIP URI with transport=3Dws. which would mean WS (insecure Web Socket).= Furthermore, if SIPS URI is used in Route header, then all other URI must = be SIPS as well and message cannot be forwarded over UDP, SIPS over TLS mus= t be used instead. I have modified the entire example to use SIPS and TLS, = instead of SIP and UDP. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC7118 (draft-ietf-sipcore-sip-websocket-10) >>>> -------------------------------------- >>>> Title : The WebSocket Protocol as a Transport for the Se= ssion Initiation Protocol (SIP) >>>> Publication Date : January 2014 >>>> Author(s) : I. Baz Castillo, J. Millan Villegas, V. Pascual >>>> Category : PROPOSED STANDARD >>>> Source : Session Initiation Protocol Core RAI >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG --=20 I=C3=B1aki Baz Castillo From nobody Thu Dec 19 07:06: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 9D91412007C for ; Thu, 19 Dec 2019 07:06:27 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 b74KDEjeWu2N for ; Thu, 19 Dec 2019 07:06:26 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 13A5E120059 for ; Thu, 19 Dec 2019 07:06:26 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id v10so2903686oiv.12 for ; Thu, 19 Dec 2019 07:06:26 -0800 (PST) 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=yK+nPNO3apT1nknb2KiStKo0cGLRf4FxF4il3DKm5TY=; b=iAyUWUbhrBlECoR302tjTSUaOyIQcMyjKlkYpnKmE6dy85QL2weY/wbE6JKbhIscUi zC5hmZrLziiEtw5Y7NgcWGQD1pjWlbTguRMJNbZ7juCoP4aqrNS4p+g+dTJS7jEE5rLE ioQ6EUi4wk3hOU78B2lCPSBbnB5CoL8W9ggOp+AEEFliygFwms71o3DHwGB22Xi2GmSF lBIrBBE1Aa1dRYzzh+1MILpf0qPAk+wyqig14QRCADIbHJbaWzzDenCzPtY1yrQGm4qE bQ8RBV1qtwPn8onQUNW1XQn5qGX1Pynziwe2lfzY0l5tUDpeSc6oCxBU0D6+6RlH6h59 N2mg== 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=yK+nPNO3apT1nknb2KiStKo0cGLRf4FxF4il3DKm5TY=; b=AXppx5x5Iv2XpaYPqCbnjicPrfvegnp3l3QhX8Nv0xas5Xvd4gmT47j4wgsR8H1zi5 tsIaoR5jlusPk4ZmS5y44xMrYRmtkq9zo8qkgD2dg+MnwB48khjNibSg6ADdRP5HYE55 9BAxKUCsE5303rIDGgDTtYFn3bytnX5ykY5/NoXCI76iLE4WzrU3glY02X+UaIq8ao0C QK9QP/NW9R5eWdWAOE9UpA6gdLmF8ocJy48O53HLb0RJAjFm15t5KiJ+8H6JqbpSBUzH D6neGiPaRZ/YulAYVkzphtAwFM/VI6SN3Qnbhr3hXLWJ9lTdPRRudlfK2iXZ41L69Tzc mo3A== X-Gm-Message-State: APjAAAXJPh6g76uLKCqW7/ENQIdGL86NPZEC6pk0VDXv0oDyoXXSifQT +VcCDEA86AQuiCFBOp5P+ujaSvf8S/w= X-Google-Smtp-Source: APXvYqyZdsPgXWszdjXj3Oi1jUCkc0GGXLbQ0JWyXIHQ7cCuynD/BHaRHlQNE+Oh2suG1/Co7Cfu7g== X-Received: by 2002:a05:6808:103:: with SMTP id b3mr2202528oie.89.1576767984547; Thu, 19 Dec 2019 07:06:24 -0800 (PST) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com. [209.85.167.182]) by smtp.gmail.com with ESMTPSA id 9sm2239980otk.78.2019.12.19.07.06.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Dec 2019 07:06:23 -0800 (PST) Received: by mail-oi1-f182.google.com with SMTP id l136so2940343oig.1 for ; Thu, 19 Dec 2019 07:06:23 -0800 (PST) X-Received: by 2002:aca:180a:: with SMTP id h10mr2471067oih.99.1576767982831; Thu, 19 Dec 2019 07:06:22 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: From: Roman Shpount Date: Thu, 19 Dec 2019 10:06:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RFC Errata System , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , Ben Campbell , Alexey Melnikov , Adam Roach - SIPCORE Chair , Brian Rosen , "A. Jean Mahoney" , SIPCORE Content-Type: multipart/alternative; boundary="0000000000008290de059a0fe7f6" Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 19 Dec 2019 15:06:28 -0000 --0000000000008290de059a0fe7f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 15, 2019 at 5:54 PM I=C3=B1aki Baz Castillo wro= te: > Yeah, that's exactly the section I meant :) > > On Sat, 14 Dec 2019 at 21:42, Roman Shpount wrote: > > > > It looks like RFC 5630 allows this and there is a description of such > flow in https://tools.ietf.org/html/rfc5630#section-6.4. > > One small nit that in the RFC7118 example, according to https://tools.ietf.org/html/rfc5630#section-6.4, there should not be "transport=3Dws" or any other transport in the URI in the Route header. Sin= ce this Route URI is simply there for the proxy to identify that the message was correctly routed and remove, this is just a nit. Best Regards, _____________ Roman Shpount --0000000000008290de059a0fe7f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 15, 2019 at 5:54 PM I=C3=B1ak= i Baz Castillo <ibc@aliax.net> w= rote:
Yeah, that's exactly the section I meant :)

On Sat, 14 Dec 2019 at 21:42, Roman Shpount <roman@telurix.com> wrote:
>
> It looks like RFC 5630 allows this and there is a description of such = flow in=C2=A0 https://tools.ietf.org/html/rfc5630#sec= tion-6.4.



--0000000000008290de059a0fe7f6-- From nobody Thu Dec 19 08:26: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 BE6781200A4 for ; Thu, 19 Dec 2019 08:26:21 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=aliax-net.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 Bur53d-hiEsz for ; Thu, 19 Dec 2019 08:26:19 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 B173112022C for ; Thu, 19 Dec 2019 08:26:19 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id d17so1789831vke.5 for ; Thu, 19 Dec 2019 08:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=P6SPprVzfKLjebC2NadeOcur0xhgVu4CA0HzcijZQms=; b=gbmCS+wjnOaY+W5tkFcJWL/9YQU2HhFSgt8McrCuaqUeJi1ZelB0XDdUT4IxImfGBp cXamiM2g9YSO3yCXasqj7yoW7X/Bu3DfjpM6o2HsPYKcsnXvTsTVJMfPVruVPvPcPjQX y7vj2QhVgTAdCLDJybiZC24Y8+b+LWUoL+Wi9Tg8Xnh+Dvv71X6cPFbd/q/L8AOgQEpe /2+bp61BHJZqfxDHiI6tIbrttSAMACPO1VfnncZBReyMcyazahjMAGedjVR1IQEZ2byc 74QVFDpLL6TWlPMILvZSdCkMyNkOZQghe61WO7hb8oHhmRqU+Kh68xAm51n6b0U27nzx RCiQ== 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:content-transfer-encoding; bh=P6SPprVzfKLjebC2NadeOcur0xhgVu4CA0HzcijZQms=; b=chRpBrpJxEOAPC23/N5tLbFB1ldrE14ZvEnXHl0o5yVMyLR7x5F5udw5XJJutKPDi3 LKDwoYdrE+ZKymVEAM+mq4mSteooioLFKnH8QJ+MTDdYMjV/F19TgF4xFBmpzwu9KYxU YszPxGXIdOUGDFafVWV7rRGiaR/F2ttm7W8CrvW7gIGjpZBFYfX/Zuji/G6WC8sevLyv XUx30Xg1Oc+wCh9y7ZtpTl/gqJRT3BnmPQQNLavSGZMqoiKcRszMcYDFG9OIv0StQRaQ Hzbp1FcteFTgdCM6kzQHlzkgzLfZI9i/GEQXQ5lXK55EpYYns7g5MAcgjKNr6i2gmr/l x3tQ== X-Gm-Message-State: APjAAAX3XNMOs22ERBZw9+9AXCUPC58PvF8czFIyS9FmmPdbaQk43QsF F0sYZUAHgdJIe8uEMUeKjEd3nnqwdsEITTsXU/Vsag== X-Google-Smtp-Source: APXvYqzBg0nRW6PMA+ANNYcjnWhSb0qm9Oxx/CHtUXZtl7o/5l0yol7zVUDseqZjoXNxBl5E1n69w+2tRneewa/Qnkk= X-Received: by 2002:ac5:cc7a:: with SMTP id w26mr6345202vkm.64.1576772778480; Thu, 19 Dec 2019 08:26:18 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 19 Dec 2019 17:26:07 +0100 Message-ID: To: Roman Shpount Cc: RFC Errata System , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , Ben Campbell , Alexey Melnikov , Adam Roach - SIPCORE Chair , Brian Rosen , "A. Jean Mahoney" , SIPCORE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 19 Dec 2019 16:26:22 -0000 On Thu, 19 Dec 2019 at 16:06, Roman Shpount wrote: > > On Sun, Dec 15, 2019 at 5:54 PM I=C3=B1aki Baz Castillo w= rote: >> >> Yeah, that's exactly the section I meant :) >> >> On Sat, 14 Dec 2019 at 21:42, Roman Shpount wrote: >> > >> > It looks like RFC 5630 allows this and there is a description of such = flow in https://tools.ietf.org/html/rfc5630#section-6.4. >> > > One small nit that in the RFC7118 example, according to https://tools.iet= f.org/html/rfc5630#section-6.4, there should not be "transport=3Dws" or any= other transport in the URI in the Route header. Since this Route URI is si= mply there for the proxy to identify that the message was correctly routed = and remove, this is just a nit. I don't think there is a MUST NOT for that, nor that such a transport=3Dws is really invalid, is it? From nobody Thu Dec 19 12:27: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 94A1F120B6A for ; Thu, 19 Dec 2019 12:27:28 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 NAmakDJAl6Od for ; Thu, 19 Dec 2019 12:27:27 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 DBACD120A96 for ; Thu, 19 Dec 2019 12:27:26 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id w1so8732340otg.3 for ; Thu, 19 Dec 2019 12:27:26 -0800 (PST) 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=pChR1kQGol8jobQF3YpBKUjQ8WOaTlAWgGU0u+Wej7Q=; b=mEmn1M8vJ4g8I6L55OLhA/k8NONqjr5xfaIQ8kpW+0sBluW7oKea35za1RWuLFSLMK 3qZMAFi3EXAcUMQNxz590TW9JwbJoloBzFDnQEmCQQWoR3ciFszedmi0cO4KLxyozFG1 RczUtyh/BRobfyEyx8hL/O8KsWnulGIkPFVwDekG6rKmBhlGEppF8onuyaDQUibFKyl1 RVznrwzEmwMeTv6AAvN4M8uRfHxD4hsqeXYhoWcpF5+qosBiGB/aO6wYrTk+YnEBTMDS vOFP0knJVEpsO91fUlmRQ4bloLw1RbafvLS38i6N8ktbNrPNblxCtjAAuOtKlVf8gAXq +Org== 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=pChR1kQGol8jobQF3YpBKUjQ8WOaTlAWgGU0u+Wej7Q=; b=eg3UxgpaJGkXQkM+fzrpI0IfKhBIiouSH0lVOHZJ1WQkZ/DrsnpIauudpAn7oVYG+k Og+aHFlpNcrRMLz3sup/CD+9NXN40aQJViKEfDPR8DWEVu/tEqpKlgeJHqaTb4c8ZhvZ TVK+ilgM2KIpQMA4wlDK3ngQtcQpSg3T2D+dZLEAEHYtXgtJaDVZodvuBRz0Ck0zbv6E qR+/IRNp2PVeZpdNlYcgGESNnBryYjIGy5Jt/f7FUPSVYPyem8gTzvqXa7DG9dCr7C7y zFlR4b0c1QoBXmqzVUnIt/7fKcXAgdTMA8i7GBgT8D0hiq+JxohW5SZl3NNjEfAPY6x6 LVfw== X-Gm-Message-State: APjAAAVRpjQWYTi84u5XG5q74PR4pfwkzUeifCNFHutI/4W0yEIocVyi 3jiE5bwYeuAObm/FoFXSt3cGuspuLlw= X-Google-Smtp-Source: APXvYqz/2miLZB4RjNvTQSePANnuWuDNdaBQuKNR/1BMnuxHGDPVSAuA1eS8MZ4SuXew5iZFKTgE6Q== X-Received: by 2002:a9d:748d:: with SMTP id t13mr10395666otk.181.1576787245587; Thu, 19 Dec 2019 12:27:25 -0800 (PST) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com. [209.85.167.177]) by smtp.gmail.com with ESMTPSA id q1sm2595211otr.40.2019.12.19.12.27.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Dec 2019 12:27:24 -0800 (PST) Received: by mail-oi1-f177.google.com with SMTP id i1so3647539oie.8 for ; Thu, 19 Dec 2019 12:27:24 -0800 (PST) X-Received: by 2002:aca:c5ca:: with SMTP id v193mr3171291oif.77.1576787244024; Thu, 19 Dec 2019 12:27:24 -0800 (PST) MIME-Version: 1.0 References: <20191214200623.98A51F406CB@rfc-editor.org> In-Reply-To: From: Roman Shpount Date: Thu, 19 Dec 2019 15:27:14 -0500 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: RFC Errata System , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= , Ben Campbell , Alexey Melnikov , Adam Roach - SIPCORE Chair , Brian Rosen , "A. Jean Mahoney" , SIPCORE Content-Type: multipart/alternative; boundary="000000000000910bd1059a14634e" Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC7118 (5937) 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, 19 Dec 2019 20:27:28 -0000 --000000000000910bd1059a14634e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 19, 2019 at 11:26 AM I=C3=B1aki Baz Castillo wr= ote: > On Thu, 19 Dec 2019 at 16:06, Roman Shpount wrote: > > > > On Sun, Dec 15, 2019 at 5:54 PM I=C3=B1aki Baz Castillo > wrote: > >> > >> Yeah, that's exactly the section I meant :) > >> > >> On Sat, 14 Dec 2019 at 21:42, Roman Shpount wrote: > >> > > >> > It looks like RFC 5630 allows this and there is a description of suc= h > flow in https://tools.ietf.org/html/rfc5630#section-6.4. > >> > > > > One small nit that in the RFC7118 example, according to > https://tools.ietf.org/html/rfc5630#section-6.4, there should not be > "transport=3Dws" or any other transport in the URI in the Route header. S= ince > this Route URI is simply there for the proxy to identify that the message > was correctly routed and remove, this is just a nit. > > I don't think there is a MUST NOT for that, nor that such a > transport=3Dws is really invalid, is it? > It is not invalid, it just adds to overall confusion. This transport parameter (and likely the whole route header) is irrelevant. This is why it is a nit. _____________ Roman Shpount --000000000000910bd1059a14634e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 19 Dec 2019 at 16:06, Roman Shpount <roman@telurix.com> w= rote:
>
> On Sun, Dec 15, 2019 at 5:54 PM I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>>
>> Yeah, that's exactly the section I meant :)
>>
>> On Sat, 14 Dec 2019 at 21:42, Roman Shpount <roman@telurix.com> wrote:
>> >
>> > It looks like RFC 5630 allows this and there is a description= of such flow in=C2=A0 https://tools.ietf.org/html/rf= c5630#section-6.4.
>>
>
> One small nit that in the RFC7118 example, according to https://tools.ietf.org/html/rfc5630#section-6.4, there should n= ot be "transport=3Dws" or any other transport in the URI in the R= oute header. Since this Route URI is simply there for the proxy to identify= that the message was correctly routed and remove, this is just a nit.

I don't think there is a MUST NOT for that, nor that such a
transport=3Dws is really invalid, is it?

It is not invalid, it just adds to overall confusion. This transport para= meter (and likely the whole route header) is irrelevant. This is why it is = a nit.
_____________
Roman Shpount=C2=A0
--000000000000910bd1059a14634e-- From nobody Fri Dec 27 00:54:46 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 6CD641200F6; Fri, 27 Dec 2019 00:54:41 -0800 (PST) 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.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <157743688134.30049.15747013420001740313@ietfa.amsl.com> Date: Fri, 27 Dec 2019 00:54:41 -0800 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4028bis-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: Fri, 27 Dec 2019 08:54:41 -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 : Session Timers in the Session Initiation Protocol (SIP) Authors : Christer Holmberg Steve Donovan Jonathan Rosenberg Filename : draft-ietf-sipcore-rfc4028bis-02.txt Pages : 26 Date : 2019-12-27 Abstract: This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session- Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4028bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-rfc4028bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rfc4028bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4028bis-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 Fri Dec 27 00:56:09 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 371FA1200F9 for ; Fri, 27 Dec 2019 00:56:07 -0800 (PST) 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 3FibBdbKFMgr for ; Fri, 27 Dec 2019 00:56:05 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70083.outbound.protection.outlook.com [40.107.7.83]) (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 2FD9D1200F6 for ; Fri, 27 Dec 2019 00:56:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gi/vVAGMe7DUXufkr1X9Mfjidxeu1QqAycdt9nlIBm3xqWOU5Bp/MwYqEkN/UsZbMMgZGy93BvS21ucWo9+q3LRucJfo4TtZt3OM3jdxCePnBIgBBQdC+9pvoM00YB573jsUUZ9Bu1+RHyq0oZ7T2DWJBDy08JNf3tcL/cXFdMmomg0ht91ALf/dZ9/ZXpfTZv59leCJ9qPQiMZEnWoMtU1qq3/XvPVkdBC4voWyObRyXc7Ut6SsC0FKvfVH0FqzB1wKaTUzXUNv3OXd//gHPErs93IamSMl5FhXT3mhA7frdzADEOBfkLwF1sWwC00itWRJR43gMG/KmWWDKEPU1Q== 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=1a2i9z2fDkTSDGWer5XixkpfkG9RAgOa76tbOpDRsOg=; b=c01Tn2yPlBfA7R1L/3T6VCOnuHXvKQnE0WbnBr5cJJaM7cDlAQ+PUMEGZ9XOkDHT9kXO/4bZ5ss4THtMVyh9J1JlyHdy2sxjiX9jpgeS/DKSs6bN9zpsLWulWU8r2lwiAGuSmeidEbLtRRoCk9OA8HftndyX3IzrZ9+kqwySQFrmx93Hd9HwvOg0LsJdLuLz/k5U2ZZNA8vNTYIoYwqWMNUIUP1/rF7b56wUPFgfW8VgD7OGIUoWRJO81TGRQ73gmmQlQmmtX/kVRpNtGrsZzFiKafbvUA0EKscqnzff/e2U3ufym9dNnNhwSBkwPJc2pMcXm4ZbJTLS+LzsjTFvWQ== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1a2i9z2fDkTSDGWer5XixkpfkG9RAgOa76tbOpDRsOg=; b=jtnZAEcgmuIW4uA7j8bh3e6uXkXpTJu0ExQjcmlYTXFO2RvvlxmsrVWASCPZoqBK1G/o4FLTbo4EnHzCm0awwbLzZNCF0shS0p+6RtI+sdjIT3Sjqt31TuqwqJBMNryw0D3agP70smEbl8bQZb0olUDZ3scb2ejtWOUdaiyhQJE= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB5475.eurprd07.prod.outlook.com (20.178.22.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.7; Fri, 27 Dec 2019 08:56:00 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::28e8:93ab:34a6:c38d]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::28e8:93ab:34a6:c38d%3]) with mapi id 15.20.2602.006; Fri, 27 Dec 2019 08:56:00 +0000 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Draft new version: draft-ietf-sipcore-rfc4028bis-02 Thread-Index: AQHVvJN2WdyTJLi5tUi2jS7hTxh80Q== Date: Fri, 27 Dec 2019 08:56:00 +0000 Message-ID: <6DE3977B-3111-43A6-82B0-DD52011B35E3@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 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: 203183cc-efd4-4522-40ce-08d78aaa98b5 x-ms-traffictypediagnostic: AM0PR07MB5475: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(199004)(189003)(186003)(8936002)(33656002)(6512007)(26005)(6506007)(6486002)(44832011)(8676002)(81156014)(81166006)(2906002)(66446008)(66556008)(66476007)(64756008)(86362001)(76116006)(71200400001)(6916009)(558084003)(66946007)(316002)(36756003)(5660300002)(478600001)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5475; H:AM0PR07MB3987.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: BCL:0; x-microsoft-antispam-message-info: TO47wNbgH6/36G5dcR4r/pNBHC77wvutiIe61+A1OZqF3daoySOvdljIytDRiBOZ7Qcqc3ZzEYCDI1oC2LCsqD5QtJxcRXGGPcvrtpu7Y4hQ8Po7sml5gWvTaBiR3uSdhp8qXph6mlRcKrSUXM+LaLLCCfTiN1rS8UDvoGcnTjtrMsOok8EtI/LKZMOVps2r8ja7jPF4bSiflnwnQGQCjo5fYplcvGQIsODg1R92k13133wweJ9CEniaME+vdk11F8vkKCRKxiZ+q64/uVz0K4ISjjHSPCGX51mk+A4iQF2D+FP8oWbbM2ZBmKIZn7cd/Sdgm9SmIn1cru5rYH2UCddSrWFhMTi53FO3tt644zP5MvXJncvTYtfzvaoXvxwlm99JEKfhizsubvSfnKa05mR5gPBR3IKw3u9QvjQrIAqY+yxTlc0UPzcOQvuj0Ljc x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6DE3977B311143A682B0DD52011B35E3ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 203183cc-efd4-4522-40ce-08d78aaa98b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 08:56:00.5944 (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: ++FqfT8xNERK5hISDg6zKdlWRtGIH4Rax9BsmdCYqDxftRRLyOojqb/92q0U1TPwF3b+Yh+gm1q8cnU/JFzNA477MQNYmgkvSuUKdNAu1X4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5475 Archived-At: Subject: [sipcore] Draft new version: draft-ietf-sipcore-rfc4028bis-02 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, 27 Dec 2019 08:56:07 -0000 --_000_6DE3977B311143A682B0DD52011B35E3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTAyKSBvZiA0MDI4YmlzLg0K DQpUaGUgbmV3IHZlcnNpb24gd2FzIHN1Ym1pdHRlZCBiZWNhdXNlIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGV4cGlyZWQuIFRoZXJlIGFyZSBubyBjaGFuZ2VzIGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91 cyB2ZXJzaW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K --_000_6DE3977B311143A682B0DD52011B35E3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5B9C170D1940EE4E84264B4FF680A5DD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uICgtMDIp IG9mIDQwMjhiaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBuZXcgdmVyc2lvbiB3YXMgc3VibWl0dGVkIGJl Y2F1c2UgdGhlIHByZXZpb3VzIHZlcnNpb24gZXhwaXJlZC4gVGhlcmUgYXJlIG5vIGNoYW5nZXMg Y29tcGFyZWQgdG8gdGhlIHByZXZpb3VzIHZlcnNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_6DE3977B311143A682B0DD52011B35E3ericssoncom_-- From nobody Fri Dec 27 08:39: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 5AF11120098 for ; Fri, 27 Dec 2019 08:39:07 -0800 (PST) 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, 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=alum.mit.edu 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 5MbfszPEIevn for ; Fri, 27 Dec 2019 08:39:05 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760080.outbound.protection.outlook.com [40.107.76.80]) (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 00F0B120019 for ; Fri, 27 Dec 2019 08:39:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=karHz3fIgpzaNsi/Vzq/6DOSGJfdxYWSy+2RB7re/7f6HurT4qKbn3IyZw1z2AHcWDBb51ukjBYYmb4fkArA3gXLgZYz1QJXmb6L0ZN1QC5mnG9AFmDi4NR3XwC8UZl/EbrVLSumeIj65Jpta6DB5cu17WKYMEK+apyDQtIfoH+M/nC5thcCoW70pVRFQ9tmp8Abif1ghITFEluK070gmBFzUoEfEF7/Wdnr6K9lFIHmgdCC695t5g87q5ni5KEch5aogsUR+bw3A16AEPn+dwi5ThP18T7qy19fS80crU78APAqEi5TpYgBoDhA++zPKfAfVVz8OJZ+OVmyE+30lQ== 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=k2WIEgN1dsow+bU+EIVPBCZnKxs9HjjOcHD/wcIOiM8=; b=O7cVh+IXPTuWMUq8YtaksLu8kte6Fy1Jug8PTk52o6ImfYIhe0cwfDZCCr36sP8mpRArW0v8DvaZKboGMsOM4GN43QMfVKAGDu2MS3JQsgTCwVzd4mTWW/h3yDI1qGKdFFRgKkket4xxt/7SUSZa9z2XWo/9mPQO1GReWuXWv/oDFrznQDXrpEWbuEbl5baOL9ZMoUGZjXY8PvZmedXklnZuNeG2WwQ6pd7+3MRMPn3Y4FpLRlpKwOiroUEYD9/TwRpIpZYUYHUagyEWWLFuPvNKJIxu+bJhiwvRxQBPq+rq7Wk6bvuznwUvDLTNeqxX7W4aDPP/NEF+loZwPD4+tA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k2WIEgN1dsow+bU+EIVPBCZnKxs9HjjOcHD/wcIOiM8=; b=VLufFClZQZ+XnyekBWTkbqCKp1rxl/1eYuidN6tfR8wn5lpDd1m9rtOnhzPxqsGbJwT5GpE3K+GxNLAvxYa/O7+5i3K828ncSGEmckaX7xZq0sCPFImByPMKN811LBugr1O/aazD7jU2xozSyTcPz7gZJk9y6z1KDkvSqq2dnVM= Received: from MWHPR12CA0025.namprd12.prod.outlook.com (2603:10b6:301:2::11) by MN2PR12MB3614.namprd12.prod.outlook.com (2603:10b6:208:c6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Fri, 27 Dec 2019 16:39:02 +0000 Received: from SN1NAM02FT050.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e44::200) by MWHPR12CA0025.outlook.office365.com (2603:10b6:301:2::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11 via Frontend Transport; Fri, 27 Dec 2019 16:39:02 +0000 Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT050.mail.protection.outlook.com (10.152.72.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.14 via Frontend Transport; Fri, 27 Dec 2019 16:39:01 +0000 Received: from Kokiri.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 xBRGcxvH001731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 27 Dec 2019 11:39:00 -0500 To: sipcore@ietf.org References: <6DE3977B-3111-43A6-82B0-DD52011B35E3@ericsson.com> From: Paul Kyzivat Message-ID: Date: Fri, 27 Dec 2019 11:38:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6DE3977B-3111-43A6-82B0-DD52011B35E3@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(396003)(189003)(199004)(26005)(76130400001)(316002)(786003)(36906005)(70206006)(70586007)(336012)(186003)(956004)(4744005)(5660300002)(356004)(2616005)(6916009)(31686004)(75432002)(26826003)(478600001)(53546011)(2906002)(8676002)(246002)(8936002)(7596002)(86362001)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR12MB3614; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d0aedf4f-654f-40a1-f538-08d78aeb4775 X-MS-TrafficTypeDiagnostic: MN2PR12MB3614: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4714; X-Forefront-PRVS: 0264FEA5C3 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f87J0JDWyl++aX9dOTAXmC36CN9qY6hvQeqaXSk5nIErkVapaGFXvGEm+z2PypxkwzjkO9SQ6bDg/lH6TxeADyCoKkdWtf6hnJJ86VuYs72jU38p2SU1y13Y6CCRTDuGbBare4sDMeI1lFQNT8PdLDtS1af4v+B4rh/N2Iw8MEBhhsf7VkWuQFSbsK0r+MkcbNLX9ZX/ROEzpqKFd5NLXnOTYEO70Y2Dr3t5h+Igu/zH2mcVTQiy/InZsg7plfNIBJ7I4utiBUqRufZdQnUUTjncG64TWqyqluQa9+6sEcnG8dxmU+eiUmxCXOREf1VX/TEpgjdzWe+X62BaB0l5SM4zVx/GdU+kDXNdJN/WrFgA70oPrS4mmmfmJNJBG4tAFo3oCrUthB2pJnzBWM+x0neuNEDoqWZxnZYV3RpDAk9HPrtIq3g+TvjUKJ2PPhdf X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Dec 2019 16:39:01.5643 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d0aedf4f-654f-40a1-f538-08d78aeb4775 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3614 Archived-At: Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-rfc4028bis-02 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, 27 Dec 2019 16:39:07 -0000 Christer, On 12/27/19 3:56 AM, Christer Holmberg wrote: > Hi, > > I have submitted a new version (-02) of 4028bis. > > The new version was submitted because the previous version expired. > There are no changes compared to the previous version. IIUC there are also no substantive changes from RFC4028. Right? (Just changes in xml2rfc formatting, addition of you as author, etc.) Is this establishing a baseline for the session timer fix discussed back in 2017? Merry Christmas, Paul From nobody Fri Dec 27 09:12: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 EBA58120089 for ; Fri, 27 Dec 2019 09:12:37 -0800 (PST) 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 MZXpDFVaFhNd for ; Fri, 27 Dec 2019 09:12:36 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70052.outbound.protection.outlook.com [40.107.7.52]) (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 BFEB712012D for ; Fri, 27 Dec 2019 09:12:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cRgxVDGaK+tXRgXvqVy2jhPN4zow5L9ksxrxyAG55KC8N42N/ZMXcen60Fhmnyaex/47IIbX3sKTeVjh7+XlbB/+4mvT/VAhmhLk5HmAjWVtLyJYoRFFndya8R+EHM0fGVoXG0xPfI69GpLl6nNZUEjM5jxFQqTg0QSnW9auITWNSScyE8qFUVisqDNffQ5nyjwBw7fbHQKgp2sbVbIeB1oH2ocDcmfanCb5k6YKHNjprAFHNGMLCcd53gq9DHJGAEj9GBA76vgUqSSGVBUofmlQwuEee4+jY8a20gkhFo05ZE8WwCiP5gIvoe0H1+7uP5+KKssZsaCUvmhx7slhUQ== 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=0NRSC09H/C21ysQ787NUsTt3ILFkGg5GhH4aIY3usSI=; b=WtmnphwtQMndXuLLtVxBTuhedCnpkmm3NHP5yINcoyZnIQbnqx8ZAbbXb1sGWTkvvBYYy4m8fb6htHwMo70dHpryUp/BfAo7p7aFZAsGr3gOK0deA28UizsmAjjfejF43DU/P6xPnfHwQEgM0R4mbHLLNlUfTJcg0Sd4ZxIb/GjFFquQrglzkdFlCdsVlvdM4pTHDGGVmU1nC4jl00SbQqF71uUu8x+GtCH35ttE4WJr1ZLl3GudDZYukxJyOt6OL9ZYSdzvIKomIq8JOLr7AUZXs5gv9K/TTE/SkeAGU6kk/4tw7jGzUKJPgeCmF56NyJoYuSTiK/iIy9YTqJklrg== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0NRSC09H/C21ysQ787NUsTt3ILFkGg5GhH4aIY3usSI=; b=uHXFrMqPIBzan2ZuSYoLLhd7vDm+afsuEppIbOiQ1oin1ku+xzASZdorjmW1tmtexwxHRUlUJgQp6jsSQPeE5uHxAIgb9EroKvxF4XUYL57YoS94iRDWkWUKngB2AGh3rBy+LSTExuotWz0KOSdqYcaTEHsvGCYG+8necJtCGbs= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB5635.eurprd07.prod.outlook.com (20.178.82.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.8; Fri, 27 Dec 2019 17:12:30 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::28e8:93ab:34a6:c38d]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::28e8:93ab:34a6:c38d%3]) with mapi id 15.20.2602.006; Fri, 27 Dec 2019 17:12:30 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-rfc4028bis-02 Thread-Index: AQHVvJN2WdyTJLi5tUi2jS7hTxh80afOLx+AgAAq5IA= Date: Fri, 27 Dec 2019 17:12:29 +0000 Message-ID: References: <6DE3977B-3111-43A6-82B0-DD52011B35E3@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 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: 19268351-d663-4828-f021-08d78aeff487 x-ms-traffictypediagnostic: AM0PR07MB5635: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(199004)(189003)(2906002)(36756003)(6512007)(478600001)(33656002)(5660300002)(110136005)(4744005)(26005)(6486002)(316002)(2616005)(71200400001)(44832011)(186003)(8936002)(81166006)(8676002)(81156014)(66556008)(6506007)(76116006)(66946007)(64756008)(66476007)(66446008)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5635; H:AM0PR07MB3987.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: BCL:0; x-microsoft-antispam-message-info: 6JKedbSdmf4yUbcG0+1LA4DRdL4kBlO631Bs86sarAQOXA5wyP/zmvWQUlLVPPs0XB2JuPZZ4frs57C4wQpJTM5pGxTgWw9kKOEq8TBSCeV1EVUgrBE56EUASrnPPFmfwmvDVfMgqO5ebBIkFO5H/9mtWNfsLiBQultyNpFdZTU8w3Cj+gptLdWLKXhRnFLOzC5aJ0KdPwKCXJtq0PILre3p0FF02e17UkXCyPX+PnQVnHmmW4PeaznS1i9WRgZYR3zbhjw4i5p5Eepim04UFp2QqYGR0QeXBKzt01XscYHKj766KTYXA7IvTdwGu01VguhMXscd4x2VVeGtEFDC4dg40uGOMlEGLTckMlG3zyYULufj+0RhkKAiq1uZPzaCMTRPV4IWdBlUq63VFUaQV1ThpPeYLzmh5LJSa/MNHZnMvGxZ4xHbKUyOMy5ReEoS x-ms-exchange-transport-forked: True 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: 19268351-d663-4828-f021-08d78aeff487 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2019 17:12:29.9081 (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: XcWqkLMgjFDNMcsatVb0cZV6t9CX54ZHtkIoicbOu8s/EOP8PC4cN0JAnY8Xx3WdDJDoFopcUID6W80Jd5+DMnhuLNg/DWtBhtD9QZDCoiU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5635 Archived-At: Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-rfc4028bis-02 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, 27 Dec 2019 17:12:38 -0000 SGksDQoNCj4+IEkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTAyKSBvZiA0MDI4Ymlz Lg0KPj4gDQo+PiBUaGUgbmV3IHZlcnNpb24gd2FzIHN1Ym1pdHRlZCBiZWNhdXNlIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGV4cGlyZWQuIA0KPj4gVGhlcmUgYXJlIG5vIGNoYW5nZXMgY29tcGFyZWQg dG8gdGhlIHByZXZpb3VzIHZlcnNpb24uDQo+ICAgIA0KPiAgICBJSVVDIHRoZXJlIGFyZSBhbHNv IG5vIHN1YnN0YW50aXZlIGNoYW5nZXMgZnJvbSBSRkM0MDI4LiBSaWdodD8gKEp1c3QgDQo+ICAg IGNoYW5nZXMgaW4geG1sMnJmYyBmb3JtYXR0aW5nLCBhZGRpdGlvbiBvZiB5b3UgYXMgYXV0aG9y LCBldGMuKQ0KICANCkNvcnJlY3QuIEkgaG9wZSB0byBnZXQgdGhlIG90aGVyIGRyYWZ0cyBkb25l LCBzbyBJIGNhbiBzdGFydCBzdWdnZXN0aW5nIGFjdHVhbCBjaGFuZ2VzLg0KDQo+IElzIHRoaXMg ZXN0YWJsaXNoaW5nIGEgYmFzZWxpbmUgZm9yIHRoZSBzZXNzaW9uIHRpbWVyIGZpeCBkaXNjdXNz ZWQgYmFjayAgaW4gMjAxNz8NCg0KVmVyc2lvbiAtMDAgYWxyZWFkeSBkaWQgdGhhdC4gQnV0LCBh Z2Fpbiwgbm8gY2hhbmdlcyB0byB0aGUgY29udGVudCBoYXZlIHlldCBiZWVuIGRvbmUuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KIA0KDQo=