From nobody Fri Jun 1 14:33:21 2018 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 6BBEA12DA1C; Fri, 1 Jun 2018 14:33:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, sipcore@ietf.org, mahoney@nostrum.com, sipcore-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152788879836.15386.5435926722156120818.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 14:33:18 -0700 Archived-At: Subject: [sipcore] sipcore - New Meeting Session Request for IETF 102 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:33:19 -0000 A new meeting session request has just been submitted by Jean Mahoney, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Jean Mahoney Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: avtcore dispatch ice modern stir Second Priority: mmusic rtcweb sipbrandy People who must be present: Ben Campbell Brian Rosen Jean Mahoney Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 1 15:56:35 2018 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 60E1512E037; Fri, 1 Jun 2018 15:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 LaKVB0oUvw-W; Fri, 1 Jun 2018 15:56:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109E912E035; Fri, 1 Jun 2018 15:56:32 -0700 (PDT) Received: from mutabilis-2.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w51MuVpc065043 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Jun 2018 17:56:31 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be mutabilis-2.local To: sipcore@ietf.org Cc: sipcore-chairs@ietf.org References: <152788879836.15386.5435926722156120818.idtracker@ietfa.amsl.com> From: "A. Jean Mahoney" Message-ID: <0ac2b2d9-750a-81f2-6021-d5680308922a@nostrum.com> Date: Fri, 1 Jun 2018 17:56:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152788879836.15386.5435926722156120818.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] sipcore - New Meeting Session Request for IETF 102 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:56:34 -0000 This meeting is tentatively scheduled to give us a little more time to determine if there are any topics that would benefit from face-to-face time in Montreal. Let the chairs know, thanks! On 6/1/18 4:33 PM, IETF Meeting Session Request Tool wrote: > > > A new meeting session request has just been submitted by Jean Mahoney, a Chair of the sipcore working group. > > > --------------------------------------------------------- > Working Group Name: Session Initiation Protocol Core > Area Name: Applications and Real-Time Area > Session Requester: Jean Mahoney > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 40 > Conflicts to Avoid: > First Priority: avtcore dispatch ice modern stir > Second Priority: mmusic rtcweb sipbrandy > > > > People who must be present: > Ben Campbell > Brian Rosen > Jean Mahoney > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > From nobody Mon Jun 4 01:21:57 2018 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 386D91243FE for ; Mon, 4 Jun 2018 01:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 aJA8QsAmKigS for ; Mon, 4 Jun 2018 01:21:52 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 5DE071242F5 for ; Mon, 4 Jun 2018 01:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528100509; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ev5F1YjN92be5iUUfxYgZE+SsCg6EiAt0mys0UczBfA=; b=bp/33T+8wZyiHs28KUcHCnT7JUCoXohq5rz49jUN1k1Cf/sC7NCratxxVG64mNtk C/koUsXcD1EoxF2SX4uijXG7xGqAj+dH5ZdHsibSZF1QiiaxTq5VoInIaO+JfJ5a EdubsleT5fIdOzsTT8Gl3C9bJkb1xljKKcPdACuDcRs=; X-AuditID: c1b4fb3a-f5fff70000005fee-56-5b14f69df0a1 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 77.7D.24558.D96F41B5; Mon, 4 Jun 2018 10:21:49 +0200 (CEST) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSHC009.ericsson.se (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 4 Jun 2018 10:21:49 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 4 Jun 2018 10:21:49 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Mon, 4 Jun 2018 10:21:49 +0200 From: Christer Holmberg To: Christer Holmberg , Martin Thomson CC: SIPCORE , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Draft new version: sip-push-13 Thread-Index: AQHT0ZUebqw9NffvP0uySpMUTA5bkqQxp7yAgACSbQCAAMtWAIADyx3ggAKbzICAAJGJ0IAWKwUA Date: Mon, 4 Jun 2018 08:21:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B72EF43F6@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72EF7FA7@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EF7FA7@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUyM2K7ru7cbyLRBnOvWltcO/OP0aL380Jm i68/NrE5MHvsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBndm+azFGwSrtix+S17A+Nl/i5G Tg4JAROJ5vtNLF2MXBxCAkcYJV6duMwM4WxmlJg0ewaU85VR4t76LlYIZylQ2a5NTF2MHBxs AhYS3f+0QUaJCCRLnHmxkBnEZhYIlXi8/gozSImwgKnEh9VQJWYSJz89YYOwoyS+rJgHVs4i oCLRO/U8O4jNK2AtMf/lXyaIVaeYJa4d28oEkuAU8JOY+fAZK4jNKCAm8f3UGiaIXeISt57M Z4J4R0BiyZ7zzBC2qMTLx//A6kUF9CQ2nLjNDhFXktjSuwWqV0/ixtQpbBC2tcT0vY9ZIGxt iWULXzNDHCQocXLmE7C4EFC8ZfEE9gmMUrOQrJ6FZNQsJKNmIRk1C8moBYysqxhFi1OLi3PT jYz0Uosyk4uL8/P08lJLNjECo/jglt9WOxgPPnc8xCjAwajEw7v3hUi0EGtiWXFl7iFGCQ5m JRFe9pNAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxOaRZRQgLpiSWp2ampBalFMFkmDk6pBsYQ W63fnV9ca3U2S7UttO6esPbq+osv7Kaftn2tW7bnoPO+GX+VhIufly62NDjffMvq4O1ptmsS 12ydHvzB6fTpg9FBdY6/c6Nt4y/VVgoWBxht6Wh7Xui37vZjFwf5K9nXt+9tP3H6K6/a5HvH BKdsuXT5+MTZDxt8DF5m8X4rsZCc4Hv3lLKJEktxRqKhFnNRcSIARcgcKN4CAAA= Archived-At: Subject: Re: [sipcore] Draft new version: sip-push-13 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 08:21:55 -0000 Hi, It is now 2 weeks since I sent my reply. I=B9d really like to move the document forward. Regards, Christer On 21/05/18 10:01, "sipcore on behalf of Christer Holmberg" wrote: >Hi, > >>> I suggest to remove the second paragraph, talking about maintaining >>> connections with keep-alives. Will that make things more clear? >> >> Maybe I should state this differently. You have an ample problem >>statement, but what you don't >> have is a *solution* statement. That is, an explanation of the model >>you are using to address that problem. > >Doesn't the 4th paragraph of the Introduction address that? > >>>>> The primary mechanism in this document is an augmentation of UA >>>>> contact details. If you think of it that way, the lack of >>>>>reachability is the >>>>> exceptional condition. >>>> The primary mechanism is to wake up suspended UAs, in order to >>>> maintain registrations and provide reachability. That was the >>>>original use-case that >>>> triggered the whole document. >>> >>> The possibility to indicate that a UA is able to maintain >>>registrations, >>> but still want to receive push notifications for incoming calls, was >>>added later. >> >> How the document got to where it is doesn't matter so much as where it >>is now. > >In my opinion it is still the main use-case, and I think we shall keep it >that way: the default is that the UA can not awake , and any exception >can then be explicitly signalled. > >>> The purpose is that, if the UA has indicated that it is able to >>>maintain the registration, but for whatever reason >>> does not send a re-registration, the proxy can still trigger a push >>>notification prior to registration expiration. >> >> Yes, that is clear. >> >>> Do you want to remove that feature, and assume that UAs that have >>>indicated that they are able to maintain the >>> registration will actually do it (and, if they don't, the registration >>>will expire)? >> >> I'm suggesting that - when framed as a mechanism to ensure continuous >>reachability, it is better to make the >> time relative to the time of registration rather than relative to the >>end of registration. > >So, what do you suggest? > >Regards, > >Christer > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jun 5 13:47:26 2018 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 81C54131176 for ; Tue, 5 Jun 2018 13:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_3V_DRuKwaW for ; Tue, 5 Jun 2018 13:47:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08393130DDD for ; Tue, 5 Jun 2018 13:47:22 -0700 (PDT) Received: from mutabilis-2.local ([47.186.17.148]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w55KlLCe091891 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 5 Jun 2018 15:47:21 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.17.148] claimed to be mutabilis-2.local To: SIPCORE From: "A. Jean Mahoney" Message-ID: Date: Tue, 5 Jun 2018 15:47:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 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-authn X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 20:47:24 -0000 Hi all, Today starts the WGLC for draft-ietf-sipcore-sip-authn. https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-authn/ Please provide feedback by Wednesday, June 20. Note: Since this draft became a WG document, it has received little feedback on list. The chairs would like to see some feedback and discussion during WGLC so that we can gauge WG consensus. Thanks! Jean From nobody Thu Jun 7 00:54:47 2018 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 748F4130E9D for ; Thu, 7 Jun 2018 00:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2ffCSlci02b for ; Thu, 7 Jun 2018 00:54:39 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 9CA26130E9C for ; Thu, 7 Jun 2018 00:54:39 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id j12-v6so5727444qkk.4 for ; Thu, 07 Jun 2018 00:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=p3cIaFZ1B67D7pcR4wC8c+yWmdAVXrKMIfapsYId+ig=; b=PAY9w3zwbFLLbiLlQkqmgqYKtQ5Z+p1Ltb4UuO65o/15uC+Ey7mEf5jWbztg31BiD4 TpG88pHGTW4wViI7cQW5IoL1LeVw40uaTyT/BxVYdEmkm95nkBGXRt3QIP7zzxm9wMa6 k1fFp4oEMuYXJWJAl08Q0tQl9PrcvYXgTm0BPY80qZ/FScTZVgjT/jdKjpX5aiIvmpmq uoMGc80k0FQ7t1E2SSapncM0bElu+ZghUopNfNgJhJQTzvR/VXuHEt3XsOgZ4DxkaeUV kBHYKqbBfUeBRLQ6DQfVxRdmtGcUQrKW7SeEfpRfnOfYg7jN5ScW7Fj0A6RaCEj1afS4 c5vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p3cIaFZ1B67D7pcR4wC8c+yWmdAVXrKMIfapsYId+ig=; b=O8ShI2QYEM3OogF64bfKQWn+VOTnIDF+JOdXNmxSAWq0b67Ir8X1XG7O4ytkztYnFw 5E4cL/mvEiPm46Lx6Wi7M9K696VfJIP97JjGGtN/z5eaQ6/C+XwQyyTNUNokotiux/TN 5ZIT7QhjKs8xgcDwX3y+r0RUSpfCn9B9jBXHS0I1Nb7c4mimCxyDCwVs4QnIUw/2mgFW DcDNQwtV7izPIr1xwYa8qxlwKy6cC+rO6b5xkDkvKnyE0L1JINaep+jhcP5xCJq6SkKp 6gtd5jdaMvveL2xdJHChGwT/dyKiwuOpC9XtnmnKYvD2HIjXFWzpVuFdeHo32HY4fLI+ 8xuA== X-Gm-Message-State: APt69E08xPOA8RI7dgz4Cfas9k2+sy2GlW8XZqHh5FtSMn4cRwszXDn7 GRhDU6JGcA7OPUYGZlwyshrOIOe8Mv8Z2WT/lEmpN3TY X-Google-Smtp-Source: ADUXVKKCZAlk9bGNQnT3pB+Jh4Vtadw1xUkDZTitL8KFcmMy/0AnCIE8UPXoD9PV3TT9zYN+JXYnAmJ3/uA1J0yYrVk= X-Received: by 2002:a37:7346:: with SMTP id o67-v6mr564448qkc.137.1528358078517; Thu, 07 Jun 2018 00:54:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:8624:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 00:54:37 -0700 (PDT) From: Yehoshua Gev Date: Thu, 7 Jun 2018 10:54:37 +0300 Message-ID: To: SIPCORE Content-Type: multipart/alternative; boundary="0000000000005c187e056e089874" Archived-At: Subject: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 07:54:44 -0000 --0000000000005c187e056e089874 Content-Type: text/plain; charset="UTF-8" Hi, Several comments: Section 2.2.4: There is a reference to RFC 4474 for the list of SIP headers to be included in digest-string. I think it would be good to specifically indicate that the digest-string equals to signed-identity-digest of RFC 4474, but without the enclosing quotes. Section 3.2: The last paragraph does not indicate what should be done in case of authentication failure (due to missing authentication token in the request or usage of invalid token). RFC 6750 section 3 requires the use of 401 with WWW-Authenticate header, and details the syntax of that header. I believe that the draft can add a reference to that section, saying that the same syntax should be used in SIP. Section 4: a. I think that a note should be added that the syntax of the Bearer scheme defined here for SIP deviates from the syntax defined by RFC 6750 (in that that the token is given in a name=value format). I believe this is done to conform to the current SIP ABNF - maybe this should be written as a reasoning for the deviation. b. Given the proposed syntax, I don't see a reason to forbid extensions. Maybe the syntax could be written like: credentials /= ("Bearer" LWS bearer-response) bearer-response = "access_token" EQUAL access_token *(COMMA auth-param) General: The draft describes how registrations are authenticated. There are scenarios for which there is no registration done (like click-to-call, where only outbound calls are done). Maybe the draft should be expanded to include any SIP request. This might even be a security issue: In regular SIP Digest authentication, the Authorization header is included in all requests even after successful registration, probably as SIP doesn't require that subsequent requests are sent over the same [authenticated/ secured] transport-layer connection. Section 2 of the draft roughly corresponds to the methods described in section 4 (Obtaining Authorization) of RFC 6749. But, in RFC 6749 these methods are only used to obtain an access token to be used on subsequent requests, whilst in the draft they are used for achieving access. I'm not an expert on OAuth, but I believe the only methods to achieve access are defined in section 7 (Accessing Protected Resources) of RFC 6749, which require the usage of an access token with Authorization header (similar to section 3 of the draft). Thanks, Yehoshua Gev --0000000000005c187e056e089874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Several comments:

Section 2.2.4: There is a reference to RFC 4474 for the list of SIP= headers to be included in digest-string.
I think it would be goo= d to specifically indicate that the digest-string equals to signed-identity= -digest of RFC 4474, but without the enclosing quotes.

=
Section 3.2: The last paragraph does not indicate what should be done = in case of authentication failure (due to missing authentication token in t= he request or usage of invalid token).
RFC 6750 section 3 require= s the use of 401 with WWW-Authenticate header, and details the syntax of th= at header.
I believe that the draft can add a reference to that s= ection, saying that the same syntax should be used in SIP.

Se= ction 4:
a. I think that a note should be added that the syntax o= f the Bearer scheme defined here for SIP deviates from the syntax defined b= y RFC=C2=A06750 (in that that the token is given in a name=3Dvalue format).= I believe this is done to conform to the current SIP ABNF - maybe this sho= uld be written as a reasoning for the deviation.

b= . Given the proposed syntax, I don't see a reason to forbid extensions.= Maybe the syntax could be written like:
=C2=A0 credentials = /=3D ("Bearer" LWS bearer-response)
=C2=A0 bearer-respo= nse =3D "access_token" EQUAL access_token *(COMMA auth-param)

General:
The draft describes how regi= strations are authenticated.
There are scenarios for which there = is no registration done (like click-to-call, where only outbound calls are = done).
Maybe the draft should be expanded to include any SIP requ= est.

This might even be a security issue:
In regular SIP Digest authentication, the Authorization header is include= d in all requests even after successful registration, probably as SIP doesn= 't require that subsequent requests are sent over the same [authenticat= ed/secured]=C2=A0transport-layer connection.
Section 2 o= f the draft roughly corresponds to the methods described in section 4 (Obta= ining Authorization) of RFC 6749.
But, in RFC 6749 these methods = are only used to obtain an access token to be used on subsequent requests, = whilst in the draft they are used for=20 Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000f52b76056e14b241" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.14 Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-spam X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 22:21:15 -0000 --000000000000f52b76056e14b241 Content-Type: text/plain; charset="UTF-8" Thanks. Will appear in -04 shortly. (Updating the draft, finally, so this is just for the record.) On Fri, Feb 16, 2018 at 7:20 AM, Dale R. Worley wrote: > I forgot to check this nit last night: > > ... it MUST use an empty data URL [RFC2397] as a placeholder, as in > "data:". > > The placeholder URL MUST be "data:," (with a final comma). See RFC 2397 > section 3. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000f52b76056e14b241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. Will appear in -04 shortly.

(Up= dating the draft, finally, so this is just for the record.)

On Fri, Feb 16, 2018 = at 7:20 AM, Dale R. Worley <worley@ariadne.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">I forgot to check this nit last night:

=C2=A0 =C2=A0... it MUST use an empty data URL [RFC2397] as a placeholder, = as in
=C2=A0 =C2=A0"data:".

The placeholder URL MUST be "data:," (with a final comma).=C2=A0 = See RFC 2397
section 3.

Dale

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

--000000000000f52b76056e14b241-- From nobody Thu Jun 7 15:43:05 2018 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 92F41130DDD for ; Thu, 7 Jun 2018 15:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeB8gNszicRy for ; Thu, 7 Jun 2018 15:42:59 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 8E9B8130DD3 for ; Thu, 7 Jun 2018 15:42:59 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w57MecrT031209 for ; Thu, 7 Jun 2018 18:42:58 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 5E99288 for ; Thu, 7 Jun 2018 18:42:58 -0400 (EDT) Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id 9A12C8E for ; Thu, 7 Jun 2018 18:42:56 -0400 (EDT) Received: from mail-ot0-f198.google.com (mail-ot0-f198.google.com [74.125.82.198]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w57MguGP054450 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 7 Jun 2018 18:42:56 -0400 Received: by mail-ot0-f198.google.com with SMTP id w25-v6so7176696otj.18 for ; Thu, 07 Jun 2018 15:42:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X1QrtslI0HuCzmxSrhKw8yCuhNvwZ+V6U5zhTbguQiU=; b=EnxvWTQixj204NN57nvLCq9vuQt4FbF4wxpYT/RNjvvAAkKhzPOgDG8BtQ6UImYm3d SqBltvLDwr9Zngp9fAVZbuSiyV8mixh9WKFbltsjpU8oYi4RheUhrIqInJaalQMTpHQP TozvnQ3V/FDx/CFYSakiNnHb8PuwtVPGDf+wnI7p6Lo2+hl3VG5+lKa0OqjiK60T/NJ/ kf/QiIiNDteEzHRkKMNingU663wjfXr2+yDx2wZI4epRxh5W5H01/veBuRLKpE3OmRW2 HsZvKMtYKzQZpkbDHB/GEhay89tvuD3yTeVC/6I8LhFdJqRzsO1THc3QmuX8rPTUu1j1 n/4g== X-Gm-Message-State: APt69E1fBqQK2TCRu/Guu84d8+O5Pv1eZALiwnA74VFSW8Rw5PYMGZwt 8CLwr+ZKas8+6OoJkFE13dspOjSHp5/N5tl0hrCCpOPaizX8cbN89xsO970hFPTK+oS270o+rfC VHhvKJjQeZpGFsNXjVRR21UBn9vZndSi2 X-Received: by 2002:aca:eb44:: with SMTP id j65-v6mr1801217oih.307.1528411375486; Thu, 07 Jun 2018 15:42:55 -0700 (PDT) X-Google-Smtp-Source: ADUXVKImr03nTsdLYSyX6H9YrVMva5JfgFSGaCO7L2pFS/VOV6r9qCxRG6SK9FaZI0GHKCJowqK7CB1xv9dQRQBkcqY= X-Received: by 2002:aca:eb44:: with SMTP id j65-v6mr1801210oih.307.1528411375054; Thu, 07 Jun 2018 15:42:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:25aa:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 15:42:34 -0700 (PDT) In-Reply-To: <87inaxfynn.fsf@hobgoblin.ariadne.com> References: <87inaxfynn.fsf@hobgoblin.ariadne.com> From: Henning Schulzrinne Date: Thu, 7 Jun 2018 18:42:34 -0400 Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000014ed79056e150103" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.14 Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-spam X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 22:43:03 -0000 --00000000000014ed79056e150103 Content-Type: text/plain; charset="UTF-8" Not great, but here's my new wording: SIP proxies or B2BUAs MUST add a new Call-Info "info" header field instance, rather than add parameters to an existing one. Thus, there MAY be several Call-Info header instances of purpose "info" in one request, either as a single header with a comma-separated list or separate headers, or some combination. Let me know if that's sufficiently clear. Henning On Thu, Feb 15, 2018 at 9:37 PM, Dale R. Worley wrote: > "A. Jean Mahoney" writes: > > Working Group Last Call starts today for draft-ietf-sipcore-callinfo- > spam. > > 3. Overview of Operation > > SIP proxies or B2BUAs MUST add a new Call-Info "info" header field > instance, rather than add parameters to an existing one. Thus, there > MAY be several Call-Info header fields of purpose "info" in one > request. > > This is correct, but I misread it the first time. The grammar of > Call-Info is: > > Call-Info = "Call-Info" HCOLON info *(COMMA info) > info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) > info-param = ( "purpose" EQUAL ( "icon" / "info" > / "card" / token ) ) / generic-param > > and the above text means that a device may not add further info-param's > to an existing info. But it may add additional info's to an existing > Call-Info, rather than using separate header fields. > > However, it's easy to misread as meaning that the following is not > allowed: > > Call-Info: 5974c8d942f120351143> ;source=carrier.example.com > ;purpose=info ;confidence=85 ;type=fraud ;reason="FTC list", > ;source=other.example.com > ;purpose=info ;confidence=20 ;type=prison > > Is there a way to phrase this that is less easy to misread? > --00000000000014ed79056e150103 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not great, but here's my new wording:
<= br>

SIP proxies or B2BUAs MUST add a new Call-In= fo "info" header field instance, rather than add parameters to an= existing one. Thus, there MAY be several Call-Info header instances of pur= pose "info" in one request, either as a single header with a comm= a-separated list or separate headers, or some combination.


Let me know if that's sufficiently clear.

Henning

On Thu, Feb 15, 2018 at 9:37 PM, Dale R. Worley &l= t;worley@ariadne.co= m> wrote:
"A. Jean Mah= oney" <mahoney@nostrum.com> writes:
> Working Group Last Call starts today for draft-ietf-sipcore-callinfo-<= wbr>spam.

=C2=A0 =C2=A03.=C2=A0 Overview of Operation

=C2=A0 =C2=A0SIP proxies or B2BUAs MUST add a new Call-Info "info"= ; header field
=C2=A0 =C2=A0instance, rather than add parameters to an existing one.=C2=A0= Thus, there
=C2=A0 =C2=A0MAY be several Call-Info header fields of purpose "info&q= uot; in one
=C2=A0 =C2=A0request.

This is correct, but I misread it the first time.=C2=A0 The grammar of
Call-Info is:

=C2=A0 =C2=A0 Call-Info=C2=A0 =C2=A0=3D=C2=A0 "Call-Info" HCOLON = info *(COMMA info)
=C2=A0 =C2=A0 info=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=C2=A0 LAQUOT absoluteURI = RAQUOT *( SEMI info-param)
=C2=A0 =C2=A0 info-param=C2=A0 =3D=C2=A0 ( "purpose" EQUAL ( &quo= t;icon" / "info"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ &quo= t;card" / token ) ) / generic-param

and the above text means that a device may not add further info-param's=
to an existing info.=C2=A0 But it may add additional info's to an exist= ing
Call-Info, rather than using separate header fields.

However, it's easy to misread as meaning that the following is not
allowed:

=C2=A0 =C2=A0Call-Info: <http://wwww.example.com/
=C2=A0 =C2=A0 =C2=A0 =C2=A05974c8d942f120351143> ;source=3Dcarrier.exam= ple.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0;purpose=3Dinfo ;confidence=3D85 ;type=3Dfraud ;= reason=3D"FTC list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0<data:> ;source=3Dother.example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0;purpose=3Dinfo ;confidence=3D20 ;type=3Dprison<= br>
Is there a way to phrase this that is less easy to misread?
--00000000000014ed79056e150103-- From nobody Thu Jun 7 17:39:28 2018 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 0772A130FFC for ; Thu, 7 Jun 2018 17:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 AA_zp7PpaUEY for ; Thu, 7 Jun 2018 17:39:21 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 10A85130FE5 for ; Thu, 7 Jun 2018 17:39:20 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w580aEsx055850 for ; Thu, 7 Jun 2018 20:39:19 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id BA1156D for ; Thu, 7 Jun 2018 20:39:19 -0400 (EDT) Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 9A8BB6D for ; Thu, 7 Jun 2018 20:39:19 -0400 (EDT) Received: from mail-ot0-f199.google.com (mail-ot0-f199.google.com [74.125.82.199]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w580dJoD055950 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 7 Jun 2018 20:39:19 -0400 Received: by mail-ot0-f199.google.com with SMTP id h3-v6so7531988otj.15 for ; Thu, 07 Jun 2018 17:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g3Uf07nOxmIg5uTcxFj+M1nY3DfbKb9HK/DmEeRnL9g=; b=A1MzdBWtTnv1VshQMTc3oZ2Gp4zP4LuzYgA6oYKw/p1l7Sa36q6K9Vfs99m3QOnDNh yjSuXU785Z8Mg97+pRRDz7JapWDVr4LSdGLCXEriyIB3CWfO2LCP70LU/JadbVifRsZE sXLqJ5ik3gPpPDKM/PQee/+Dy7NdQ+kGshwADbkd3OmoDgSuEb5WzPeJC8L9PxtJzKKa 1pVNJP6PmdN9nDALkweruDaiI6ThDDTXHb61apUPFjk4QCxMzC1F/cZDIVxXRNo3yVnn 4k+3A490Y2X7iZy+RakQQ4aY18E444wJiWbcfGAxgi606xrDsgH944eKJoyMAGasZRIV GGuA== X-Gm-Message-State: APt69E3yeV4ym2lxj+ZZHZ3ypddASRCXiDKsGOLovPVbK0UhAVCFHP4j hgJJ8uPNxjZMKuZUcx/207YkT3VbA4VObhoT0lTf3U0M/tGeL2NRv92rf4soOIDttXHC6AH2zPN 2yFVbQ2tnttV2WCLaj0jLUjqBXVuCWgfI X-Received: by 2002:aca:4ed6:: with SMTP id c205-v6mr1986986oib.254.1528418358811; Thu, 07 Jun 2018 17:39:18 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIdaGsAOcbCZkwmqTgnFkQ0Tv//N3fmMFj3fHj1Rjc9gjHOab3IIIhEj+FYQJd4KgFOAbSHwDYKKpz743swOec= X-Received: by 2002:aca:4ed6:: with SMTP id c205-v6mr1986972oib.254.1528418358359; Thu, 07 Jun 2018 17:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:25aa:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 17:38:57 -0700 (PDT) In-Reply-To: <87inaxfynn.fsf@hobgoblin.ariadne.com> References: <87inaxfynn.fsf@hobgoblin.ariadne.com> From: Henning Schulzrinne Date: Thu, 7 Jun 2018 20:38:57 -0400 Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000051893b056e16a102" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.15 Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-spam X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 00:39:24 -0000 --00000000000051893b056e16a102 Content-Type: text/plain; charset="UTF-8" Example fixed. Glad you caught this. > 6.1. REGISTER Response > ... > SIP/2.0 200 OK > ... > From: Bob ;tag=a73kszlfl > To: Bob ;tag=34095828jh > ... > Feature-Caps: *sip.call-info.spam > > Having recently made the same mistake, I notice that the Feature-Caps > header should be: > > Feature-Caps: * ;sip.call-info.spam > > See the BNF in RFC 6809 section 6.2.1. > --00000000000051893b056e16a102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Example fixed. Glad you caught this.
=C2=A0
=C2=A0 =C2=A06.1.=C2=A0 REGISTER Response
=C2=A0 =C2=A0...
=C2=A0 =C2=A0SIP/2.0 200 OK
=C2=A0 =C2=A0...
=C2=A0 =C2=A0From: Bob <sips:bob@biloxi.example.com>;tag=3Da73kszlfl
=C2=A0 =C2=A0To: Bob <s= ips:bob@biloxi.example.com>;tag=3D34095828jh
=C2=A0 =C2=A0...
=C2=A0 =C2=A0Feature-Caps: *sip.call-info.spam

Having recently made the same mistake, I notice that the Feature-Caps
header should be:

=C2=A0 =C2=A0Feature-Caps: * ;sip.call-info.spam

See the BNF in RFC 6809 section 6.2.1.
--00000000000051893b056e16a102-- From nobody Thu Jun 7 17:46:52 2018 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 5A086131004 for ; Thu, 7 Jun 2018 17:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 rDaDKaOrGZJd for ; Thu, 7 Jun 2018 17:46:42 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 B9BA5130FE5 for ; Thu, 7 Jun 2018 17:46:42 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w580kIjU057441 for ; Thu, 7 Jun 2018 20:46:41 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 89DA06D for ; Thu, 7 Jun 2018 20:46:41 -0400 (EDT) Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id 5E8066D for ; Thu, 7 Jun 2018 20:46:41 -0400 (EDT) Received: from mail-ot0-f198.google.com (mail-ot0-f198.google.com [74.125.82.198]) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id w580keKT031846 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 7 Jun 2018 20:46:41 -0400 Received: by mail-ot0-f198.google.com with SMTP id h38-v6so7553070otb.4 for ; Thu, 07 Jun 2018 17:46:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uXn5EabwLgHIUrjZf5xFFGKUsSlqcdLveOrh7Z9Yufs=; b=DLvp7PPGuCwnbH/ByRiOSr28/vX2rMS1ggwO/AIxaRdisRsh1/eNjRd9XWa42i7n7S Y3w53uBOu5zNjX3FGl75Z8sVin42NHrDXn1P6f4oZCKAe8pGYL9QW1yAqagTu6a9ITBU H0CmaAh5qa7wrnrd+KqkKZoqzQUHqtVoqT5zplFpgmopn3qVJLVnkvQsjwA2Ck4r3+vc SS5FyegQSVURLTGvWY3g/onQwh4CU/mUkDsEwMrOiDwHWGzgfJ04axBmoyVy+vbH1I7r /IllJ9yYRLpSl0nsmczbffdCs1Wd/fxnX7DOcgFRbjM3tIL8pPpNhkUbMj0iU9ZUhjkA eMlw== X-Gm-Message-State: APt69E1ZqWBGHumJFyCkdf3/lWylfxDGzE9L0sG2T0FNiq5eHKfnN6EC abELTpUqHg1ZNwGx11Z4ISobku3c28faOrZK6u0vsO6Yp9yJHUgT/jjCAbl76u+7Q9rUC531abc L0PirfFvnc1uJYMqyT3GaNSCYQvA0TXBh X-Received: by 2002:a9d:6283:: with SMTP id x3-v6mr2262989otk.111.1528418799324; Thu, 07 Jun 2018 17:46:39 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ4NeB13NJeuKFlGAVeethGzk6LwPVwgMero+GQwOw4Igqmwl8HeUwphYAKJcvyhYnUjYrswHSf7ivScPz/xj8= X-Received: by 2002:a9d:6283:: with SMTP id x3-v6mr2262957otk.111.1528418797714; Thu, 07 Jun 2018 17:46:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:25aa:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 17:46:17 -0700 (PDT) In-Reply-To: <600669c7-4203-d71c-c59f-3a64eb120e78@alum.mit.edu> References: <600669c7-4203-d71c-c59f-3a64eb120e78@alum.mit.edu> From: Henning Schulzrinne Date: Thu, 7 Jun 2018 20:46:17 -0400 Message-ID: To: Paul Kyzivat Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000008189f1056e16bbcc" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.16 Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-spam X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 00:46:50 -0000 --0000000000008189f1056e16bbcc Content-Type: text/plain; charset="UTF-8" Thanks; fixed. On Mon, Feb 12, 2018 at 10:23 AM, Paul Kyzivat wrote: > On 2/12/18 6:42 AM, A. Jean Mahoney wrote: > >> Hi all, >> >> Working Group Last Call starts today for draft-ietf-sipcore-callinfo-sp >> am. >> >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ >> >> Please provide any feedback to the sipcore mailing list by Monday, >> February 26th. >> > > I have some issues with the example in 6.1. It has: > > Feature-Caps: *sip.call-info.spam > > AFAIK it should be: > > Feature-Caps: *;+sip.call-info.spam > > Otherwise I think this is in good shape. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000008189f1056e16bbcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks; fixed.

On Mon, Feb 12, 2018 at 10:23 AM, Paul Kyzivat <pk= yzivat@alum.mit.edu> wrote:
On 2/12/18 6:42 AM, A. Jean Mahoney wrote:
Hi all,

Working Group Last Call starts today for draft-ietf-sipcore-callinfo-spam.

https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/

Please provide any feedback to the sipcore mailing list by Monday, February= 26th.

I have some issues with the example in 6.1. It has:

=C2=A0 =C2=A0Feature-Caps: *sip.call-info.spam

AFAIK it should be:

=C2=A0 =C2=A0Feature-Caps: *;+sip.call-info.spam

Otherwise I think this is in good shape.

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

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

--0000000000008189f1056e16bbcc-- From nobody Thu Jun 7 17:50:46 2018 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 EA92D130FE5; Thu, 7 Jun 2018 17:50:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152841904291.30813.18210648433139978385@ietfa.amsl.com> Date: Thu, 07 Jun 2018 17:50:42 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-callinfo-spam-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 00:50:43 -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 : SIP Call-Info Parameters for Labeling Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-callinfo-spam-03.txt Pages : 9 Date : 2018-06-07 Abstract: Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, confidence and references to additional information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-callinfo-spam-03 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-callinfo-spam-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-callinfo-spam-03 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 Jun 8 12:16:29 2018 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 CFCD2130F75 for ; Fri, 8 Jun 2018 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4HFQIK4lnYA for ; Fri, 8 Jun 2018 12:16:24 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 7896D130F06 for ; Fri, 8 Jun 2018 12:16:24 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id x18-v6so9601663uaj.9 for ; Fri, 08 Jun 2018 12:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YLnBRszKCRcaPwyUd6xv/z1sinOuJa4lEgGJARgbyb8=; b=TwXqouFTs0gGxvFjUpodUt88m0P2TmteOKgilu98p0RS9+R9FJb4nMZKmT+fTBbKiB Wv3nIFs8OXB5xLMuZxlWgUNWfid2mrq5YJFaI3eVkiclrbo5Ipbn84O9yl715ZGK2KeZ vXaEThngIQRDZNiNojKEq6RWEZzuNGtm7tBAseH/AvYOqKeTyJKsKVlvEKTWJ6dGYFTw tPTSH+sBpRwNueX308RZZMy9iIYMpJDtwvtgxOVToAFsRDRsDn8rqalSMAKjJI4myeMk 5Yu1pbLEqoXJnH3RiTi3/qzvavgl1OZsqzPP414pL6YgGJ/tBdJlqosOIMwThyErCN1u AyVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YLnBRszKCRcaPwyUd6xv/z1sinOuJa4lEgGJARgbyb8=; b=J6APpnI6TNG90bJKYLez3jpbKz4OaE+M7y+il7391XEs0oFmr0DyKiPg1pk912uGGq KoLMCuT3J9uJNUZwjWgB6ozqIFId/kCxUQMrwyoYuLmPxu9k/0GMTuFr9WIIG6dMT7Ea kuldhpILIIL9U+pXGGlX6ZogCUGTOzYgnXSABslnjBx7D6hVOT0gNZZEzb3z0HqACDpJ lhA3I6LQj2im9Ixa4zfHI1ZOFev4feG9vvbxgaY9ubTxiHHl2d000lO15wfyxFCq+j3m X8+k2R9nA2TjC3gCzqKYssAdeYJPF7V3z+WIS89F3/Ka4TWu/7tRavyBaAvXxARc34N+ 4V3w== X-Gm-Message-State: APt69E3uRGsvgI08GSdaAI8EcjmxnIZdTJq3UmwEMNsf8X6HFT6liAsh r80h1crEhxssRppJy6TpH6Qj2FnWR7nNBoz4CMoy0g== X-Google-Smtp-Source: ADUXVKJh3xja5sR4OJVyv4F5toFjJD486S+4icOK+i0FjLMqU/ga7Kp8gdEKPIVOl7O7aQctYBZaNty7kZcr09q1HkE= X-Received: by 2002:ab0:1523:: with SMTP id o32-v6mr4967233uae.194.1528485383092; Fri, 08 Jun 2018 12:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:458c:0:0:0:0:0 with HTTP; Fri, 8 Jun 2018 12:16:22 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Fri, 8 Jun 2018 15:16:22 -0400 Message-ID: To: Yehoshua Gev Cc: SIPCORE Content-Type: multipart/alternative; boundary="0000000000004dbf3d056e263c7b" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 19:16:27 -0000 --0000000000004dbf3d056e263c7b Content-Type: text/plain; charset="UTF-8" Hi Yehoshua, Thanks for your review and comments. See my replies inline. Regards, Rifaat On Thu, Jun 7, 2018 at 3:54 AM, Yehoshua Gev wrote: > Hi, > > Several comments: > > Section 2.2.4: There is a reference to RFC 4474 for the list of SIP > headers to be included in digest-string. > I think it would be good to specifically indicate that the digest-string > equals to signed-identity-digest of RFC 4474, but without the enclosing > quotes. > I am not clear on what you mean by "digest-string equals to signed-identity-digest " The goal is to use the shared-key to provide a hash of digest-string as proof that the client has access to the shared-key. > > Section 3.2: The last paragraph does not indicate what should be done in > case of authentication failure (due to missing authentication token in the > request or usage of invalid token). > RFC 6750 section 3 requires the use of 401 with WWW-Authenticate header, > and details the syntax of that header. > I believe that the draft can add a reference to that section, saying that > the same syntax should be used in SIP. > Yeah, I agree that the document should explicitly cover the failure use case. I will address that in the next version of the document. > Section 4: > a. I think that a note should be added that the syntax of the Bearer > scheme defined here for SIP deviates from the syntax defined by RFC 6750 > (in that that the token is given in a name=value format). I believe this is > done to conform to the current SIP ABNF - maybe this should be written as a > reasoning for the deviation. > That is correct. I will add a note. > > b.. Given the proposed syntax, I don't see a reason to forbid extensions. > Maybe the syntax could be written like: > credentials /= ("Bearer" LWS bearer-response) > bearer-response = "access_token" EQUAL access_token *(COMMA auth-param) > > We could do that. Do you have a specific parameter in mind? I will look into the proper syntax for this. > General: > The draft describes how registrations are authenticated. > There are scenarios for which there is no registration done (like > click-to-call, where only outbound calls are done). > Maybe the draft should be expanded to include any SIP request. > > Good point. I will add some text around that. > This might even be a security issue: > In regular SIP Digest authentication, the Authorization header is included > in all requests even after successful registration, probably as SIP doesn't > require that subsequent requests are sent over the same [authenticated/ > secured] transport-layer connection. > Section 2 of the draft roughly corresponds to the methods described in > section 4 (Obtaining Authorization) of RFC 6749. > But, in RFC 6749 these methods are only used to obtain an access token to > be used on subsequent requests, whilst in the draft they are used for > achieving access. > I'm not an expert on OAuth, but I believe the only methods to achieve > access are defined in section 7 (Accessing Protected Resources) of RFC > 6749, which require the usage of an access token with Authorization header > (similar to section 3 of the draft). > > Section 2.1.2 defines the idea of a shared-key to be used to establish new connection and re-register to the proxy after a connection is lost, without the need for a new code. This same mechanism could be used with all subsequent requests, not only registration. I will add some text to explicitly state that. Regards, Rifaat > Thanks, > Yehoshua Gev > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --0000000000004dbf3d056e263c7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yehoshua,

Thanks for your review and= comments.
See my replies inline.

Regard= s,
=C2=A0Rifaat

On Thu, Jun 7, 2018 at 3:54 AM, Yehoshua Gev <= span dir=3D"ltr"><yoshigev@gmail.com> wrote:
Hi,

Several comments:

<= /div>
Section 2.2.4: There is a reference to RFC 4474 for the list of S= IP headers to be included in digest-string.
I think it would be g= ood to specifically indicate that the digest-string equals to signed-identi= ty-digest of RFC 4474, but without the enclosing quotes.

I am not clear on what you mean by "digest= -string equals to signed-identity-digest "
The goal is to use the shared-key to provide a hash of dig= est-string as proof that the client has access to the shared-key.
=C2=A0

<= /div>
Section 3.2: The last paragraph does not indicate what should be = done in case of authentication failure (due to missing authentication token= in the request or usage of invalid token).
RFC 6750 section 3 re= quires the use of 401 with WWW-Authenticate header, and details the syntax = of that header.
I believe that the draft can add a reference to t= hat section, saying that the same syntax should be used in SIP.
=

Yeah, I agree that the document should exp= licitly cover the failure use case.
I will address that in the ne= xt version of the document.


Section 4:
a. I think that a note s= hould be added that the syntax of the Bearer scheme defined here for SIP de= viates from the syntax defined by RFC=C2=A06750 (in that that the token is = given in a name=3Dvalue format). I believe this is done to conform to the c= urrent SIP ABNF - maybe this should be written as a reasoning for the devia= tion.

That is correct. I will a= dd a note.
=C2=A0

b.. Given the proposed syntax, I don't se= e a reason to forbid extensions. Maybe the syntax could be written like:
=C2=A0 credentials /=3D ("Bearer" LWS bearer-respons= e)
=C2=A0 bearer-response =3D "access_token" EQUAL acce= ss_token *(COMMA auth-param)

<= div>
We could do that. Do you have a specific parameter in mi= nd?
I will look into the proper syntax for this.

=C2=A0
<= /div>
General:
The draft describes how registrations are auth= enticated.
There are scenarios for which there is no registration= done (like click-to-call, where only outbound calls are done).
M= aybe the draft should be expanded to include any SIP request.

Good point. I will add some t= ext around that.

=C2=A0
This might even be a security is= sue:
In regular SIP Digest authentication, the Authorization head= er is included in all requests even after successful registration, probably= as SIP doesn't require that subsequent requests are sent over the same= [authenticated/secured]=C2=A0transport-layer connection.
Section 2 of the draft roughly corresponds to the methods described = in section 4 (Obtaining Authorization) of RFC 6749.
But, in RFC 6= 749 these methods are only used to obtain an access token to be used on sub= sequent requests, whilst in the draft they are used for=20
Thanks,
Yehoshua Gev

=

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

--0000000000004dbf3d056e263c7b-- From nobody Sun Jun 10 04:48:49 2018 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 8AF51130E3C for ; Sun, 10 Jun 2018 04:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nj1XQ1mSzPzB for ; Sun, 10 Jun 2018 04:48:44 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 59EC5130E35 for ; Sun, 10 Jun 2018 04:48:44 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id z16-v6so11738966uaz.10 for ; Sun, 10 Jun 2018 04:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BVlsuNaAvAuIR5kfuFZMDONNkMd6KMVeEKvhdell3aI=; b=KQ+VLD8VL2Swcsx/ALmPc0L8AakeQaENVLQUFrNf+Hrt+pUtdU8YzrkS/Ry3Z+kAzC eHNwFDjbGKQZFVqlC4YI5a4Oy/+ErQ6M3IqvzpQGJl9NOqCu6u1Lca9N3sOqWadLvtDI XkWCx9WtJbgZE9mYDycrT2PfgW5NMCNIxWihi0fEqzksZRxWLQRmO+Dtpf/ulA2/LZkG BUuZjU3m5ol7Ufi2yB78XBw85SJlmOnKzhR8+3c9wI/FIz9AkYdkhvRz8tmJpQjAfSiq zdFPsV3N/XZjnXxPdOl6MFOyiM1BAVcTmclHRXsoSmGMVGTDrvHV1Kt4r+dvdDOPdWPV TlUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BVlsuNaAvAuIR5kfuFZMDONNkMd6KMVeEKvhdell3aI=; b=JawhJYVWPuAsR+BI3YT9cGCTND11YReZSaQU8L1ajTd4YTmBneS/jYT4l2r8QeMVfw bCj9KTghMaPj5BgLmRu6jVEtNduqbJCs3h8Qav1fkOng9MzJ/kRMFpZtaHW/V9W4ofgX Kb6CpPoAaQ3BGsD1apUxQBWE+y5rOaFyjjF4pVrtgndki71S43zsTiwcItCZ8tygHCxX 1mp/waiHcrsMd07Hi5OPxWPp4uKcZkCKmQC8Ze8UOIVqwzwrAlneDn99pDuinJeocT4a sCIhKM6AU43iY3hGz3QX28Sk7O4O/51NbudZAeRsQMh7Z2OZlgL85cLziMdoEOHKr8er vsWA== X-Gm-Message-State: APt69E0/ipKZfC7f0DHwaLVAMqFp+A8ZAwdD1KYCKzijaS66S1TyAoHl ItnaEYVhtLs0/N3g4JXKcO4pGwwAUWd7+QNdkag= X-Google-Smtp-Source: ADUXVKJrumlR3hGc/9ssEzFqPRUKchrXTaokSeIvwLEkdEKSi2pYL9SQpfxlvp5HRctt3HE6W5zlg0IWbZcZy2ioEtc= X-Received: by 2002:ab0:30f6:: with SMTP id d22-v6mr9244121uam.58.1528631323306; Sun, 10 Jun 2018 04:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:48e7:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 04:48:42 -0700 (PDT) In-Reply-To: References: From: Yehoshua Gev Date: Sun, 10 Jun 2018 14:48:42 +0300 Message-ID: To: Rifaat Shekh-Yusef Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000004b13e056e483781" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 11:48:48 -0000 --00000000000004b13e056e483781 Content-Type: text/plain; charset="UTF-8" Thanks Rifaat. See inline. On Fri, Jun 8, 2018 at 10:16 PM, Rifaat Shekh-Yusef wrote: > Hi Yehoshua, > > Thanks for your review and comments. > See my replies inline. > > Regards, > Rifaat > > > On Thu, Jun 7, 2018 at 3:54 AM, Yehoshua Gev wrote: > >> Hi, >> >> Several comments: >> >> Section 2.2.4: There is a reference to RFC 4474 for the list of SIP >> headers to be included in digest-string. >> I think it would be good to specifically indicate that the digest-string >> equals to signed-identity-digest of RFC 4474, but without the enclosing >> quotes. >> > > I am not clear on what you mean by "digest-string equals to > signed-identity-digest " > The goal is to use the shared-key to provide a hash of digest-string as > proof that the client has access to the shared-key. > I meant that the current text doesn't include the specific syntax of digest-string, it just references RFC 4474, which doesn't mention digest-string. RFC 4474 mention another element (signed-identity-digest) which seems very similar to digest-string. The only difference I see between them, is that signed-identity-digest is enclosed by quoted, while digest-string doesn't. > > >> >> Section 3.2: The last paragraph does not indicate what should be done in >> case of authentication failure (due to missing authentication token in the >> request or usage of invalid token). >> RFC 6750 section 3 requires the use of 401 with WWW-Authenticate header, >> and details the syntax of that header. >> I believe that the draft can add a reference to that section, saying that >> the same syntax should be used in SIP. >> > > Yeah, I agree that the document should explicitly cover the failure use > case. > I will address that in the next version of the document. > > >> Section 4: >> a. I think that a note should be added that the syntax of the Bearer >> scheme defined here for SIP deviates from the syntax defined by RFC 6750 >> (in that that the token is given in a name=value format). I believe this is >> done to conform to the current SIP ABNF - maybe this should be written as a >> reasoning for the deviation. >> > > That is correct. I will add a note. > > >> >> b.. Given the proposed syntax, I don't see a reason to forbid extensions. >> Maybe the syntax could be written like: >> credentials /= ("Bearer" LWS bearer-response) >> bearer-response = "access_token" EQUAL access_token *(COMMA auth-param) >> >> > We could do that. Do you have a specific parameter in mind? > I don't have anything in mind. I will look into the proper syntax for this. > > > >> General: >> The draft describes how registrations are authenticated. >> There are scenarios for which there is no registration done (like >> click-to-call, where only outbound calls are done). >> Maybe the draft should be expanded to include any SIP request. >> >> > Good point. I will add some text around that. > > > >> This might even be a security issue: >> In regular SIP Digest authentication, the Authorization header is >> included in all requests even after successful registration, probably as >> SIP doesn't require that subsequent requests are sent over the same >> [authenticated/secured] transport-layer connection. >> Section 2 of the draft roughly corresponds to the methods described in >> section 4 (Obtaining Authorization) of RFC 6749. >> But, in RFC 6749 these methods are only used to obtain an access token to >> be used on subsequent requests, whilst in the draft they are used for >> achieving access. >> I'm not an expert on OAuth, but I believe the only methods to achieve >> access are defined in section 7 (Accessing Protected Resources) of RFC >> 6749, which require the usage of an access token with Authorization header >> (similar to section 3 of the draft). >> >> > Section 2.1.2 defines the idea of a shared-key to be used to establish new > connection and re-register to the proxy after a connection is lost, without > the need for a new code. > This same mechanism could be used with all subsequent requests, not only > registration. I will add some text to explicitly state that. > > After re-reading section 2, I think I can better explain my concern. The section defines a way for the SIP proxy to maintain the authenticity of the UA without challenging all the requests of the UA. Probably it takes the assumption that all (and only) the UA traffic will be sent over the same secured transport-layer connection. If this is the assumption (which I don't really like), I think that this should be defined as a MUST for the proxy to reject requests received on other connections. Also, if the UA "is incapable of maintainings (typo) the confidentiality of the user credentials and any obtained tokens." (section 1.4), how would it store the shared-key of section 2.1.2? And how come OAuth, as used for HTTP, doesn't rely on proxies, but relies on the clients storing a token? Are SIP UAs more insecure than web browsers? I suggest that the mechanisms of section 2 will only be used by the UA to acquire a token, which will later be used according to the mechanism of section 3. This way the behavior of SIP UA will be much similar to the behavior of HTTP client. > Regards, > Rifaat > > > > >> Thanks, >> Yehoshua Gev >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > --00000000000004b13e056e483781 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rifaat.
See inline.
=C2=A0
=

On Fri,= Jun 8, 2018 at 10:16 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Hi = Yehoshua,

Thanks for your review and comments.
See my replies inline.

Regards,
=C2=A0R= ifaat


On Thu, Jun 7, 2018 at 3:54 AM, Yehoshua Gev <y= oshigev@gmail.com> wrote:
<= div dir=3D"ltr">Hi,

Several comments:

Section 2.2.4: There is a reference to RFC 4474 for the list of SIP = headers to be included in digest-string.
I think it would be good= to specifically indicate that the digest-string equals to signed-identity-= digest of RFC 4474, but without the enclosing quotes.

I am not clear on what you mean by "di= gest-string equals to signed-identity-digest "
The goal is to use the shared-key to provide a hash of dig= est-string as proof that the client has access to the shared-key.

I meant that the current tex= t doesn't include the specific syntax of=C2=A0digest-string, it just = references=C2=A0RFC 4474, which doesn't mention=20 4474 mention another element (= signed-identity-digest) which seems very similar= to=C2=A0digest-string.
The only difference I see between them, is that=C2=A0signed-identity-digest is enclosed by quoted, while=C2=A0=
=C2=A0

Section 3.2: The last p= aragraph does not indicate what should be done in case of authentication fa= ilure (due to missing authentication token in the request or usage of inval= id token).
RFC 6750 section 3 requires the use of 401 with WWW-Au= thenticate header, and details the syntax of that header.
I belie= ve that the draft can add a reference to that section, saying that the same= syntax should be used in SIP.

Yeah, I agree that the document should explicitly cover the failure = use case.
I will address that in the next version of the document= .


Section 4:
a. I think that a note should be = added that the syntax of the Bearer scheme defined here for SIP deviates fr= om the syntax defined by RFC=C2=A06750 (in that that the token is given in = a name=3Dvalue format). I believe this is done to conform to the current SI= P ABNF - maybe this should be written as a reasoning for the deviation.

That is correct. I will add= a note.
=C2=A0

b.. Given the proposed syntax, I don't see= a reason to forbid extensions. Maybe the syntax could be written like:
=C2=A0 credentials /=3D ("Bearer" LW= S bearer-response)
=C2=A0 bearer-response =3D "access_token&= quot; EQUAL access_token *(COMMA auth-param)


We could do that. Do you have a s= pecific parameter in mind?
I don&#= 39;t have anything in mind.

=
I will look into the proper syntax for this.

=C2=A0
General:
The draft describes how registrations = are authenticated.
There are scenarios for which there is no regi= stration done (like click-to-call, where only outbound calls are done).
Maybe the draft should be expanded to include any SIP request.
=


Good point. I = will add some text around that.

= =C2=A0
This might even be a security issue:
In regular SIP Digest authe= ntication, the Authorization header is included in all requests even after = successful registration, probably as SIP doesn't require that subsequen= t requests are sent over the same [authenticated/secured]=C2=A0tra= nsport-layer connection.
Section 2 of the draft roughly corr= esponds to the methods described in section 4 (Obtaining Authorization) of = RFC 6749.
But, in RFC 6749 these methods are only used to obtain = an access token to be used on subsequent requests, whilst in the draft they= are used for=20 assumption=C2=A0(which I don't really like), I think that this= should be defined as a MUST for the proxy to reject requests received on o= ther connections.

Also, if the UA "is incapable of maintainings (ty= po)=C2=A0the co= nfidentiality of the user credentials and any obtained=C2=A0tokens." (section 1.4), h= ow would it store the shared-key of section 2.1.2?
And how come OAuth, as used f= or HTTP, doesn't rely on proxies, but relies on the clients storing a t= oken? Are SIP UAs more insecure than web browsers?

I suggest that the mec= hanisms of section 2 will only be used by the UA to acquire=C2=A0a token, w= hich will later be used according to the mechanism of section 3.
This way= the behavior of SIP UA will be much similar to the behavior of HTTP client= .
=C2=A0
R= egards,
=C2=A0Rifaat


=C2= =A0
Th= anks,
Yehoshua Gev


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


--00000000000004b13e056e483781-- From nobody Sun Jun 10 14:18:09 2018 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 4216C130EDC for ; Sun, 10 Jun 2018 14:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 Sr-AnmvcLNcn for ; Sun, 10 Jun 2018 14:18:06 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2380B130E60 for ; Sun, 10 Jun 2018 14:18:06 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id S7AVfA8Zfg5tQS7ivfbG1w; Sun, 10 Jun 2018 21:18:05 +0000 Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-06v.sys.comcast.net with ESMTPA id S7itfeeFMpMbFS7iufC6qi; Sun, 10 Jun 2018 21:18:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w5ALI30g013824 for ; Sun, 10 Jun 2018 17:18:03 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w5ALI3C3013819; Sun, 10 Jun 2018 17:18:03 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 10 Jun 2018 17:18:03 -0400 Message-ID: <87h8magx2s.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfIIH0sGyT/VwpOAoNA0eGUnSdB00XDCtQiF3Gs7YRBLPEaF0HFw3bULq6ISiNZnscte4r/xWtETe9I2O2VJbGPpSolhRtxi1bCcz/YrJAL0c1r8glXj9 m6Du6aQLUSrguF+BTZOcDEAH6pNzOmMRjKLKFwJrRU4UXKIVYjndXOGH Archived-At: Subject: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 21:18:07 -0000 This is an interesting and important piece of work. I've attempted to read earlier versions once or twice and never successfully understood it. This version of the draft is more comprehensible than previous versions and seems to be on the right track, but there are a number of important issues that need to be addressed. Trying to list them in order of importance: - All of the interactions with the "authorization server" are described as out of scope. This is rather a problem, since all of the call flows that the document describes require the authorization server as an integral part of the flow. If interacting with the authorization server is not standardized, then no interoperability has been defined in practice -- both the UA and the proxy must have special knowledge of the authorization server. In practice, that means that all components of the system will have to be purchased from one vendor. (As a consequence, the meaning of the Location header in the 401 response (section 2.1.1) is not fixed -- the UA is expected to do something with the value of the header, but there is no specification of what that is.) - The Security Considerations section does not describe whether and how the messages in the call flows need to be protected from eavesdropping. - The document doesn't give a clear statement of which requests are authenticated, what guarantees the authentication provides, or how the call flows might be used in authorizing requests. The only use of the authentication/authorization information specified in the document is SIP registration, but I suspect the intention is that SIP requests carrying authentication/authorization can be forwarded to other server entities, which can validate the AA information to determine whether to service the request. - The terminology is not consistent throughout the document. It's really important to use only one phrase to name each thing in a system, and to put the definition in the glossary. E.g., "Authorization Server" and "AuthZ" server are used interchangeably, and I suspect that "the server" and "IdP entity" also mean the same thing. Of course, SIP and OAuth may use different terms for the same entity, which makes things harder, but the glossary can show the correspondence between the two sets of terms. - The meaning, use, and format of the various data items is not clear. E.g., what is the format and significance of an "authorization code"? In particular, HMAC is used without specifying how its output (which is a sequence of binary octets) is encoded when it is included in SIP messages. - The example call flow diagrams do not include enough detail, which means I can't study them to get into my memory a good idea of what the flow diagram illustrates. Also, though the description gives an overview, but there's considerable information about the dataflow of authorization values that is under-described. E.g., at the end of the section 2.1 flow, it *seems* that the proxy will retain "tokens" associated with the registration, but that's not stated, nor is it stated how the tokens might be used. Is the proxy expected to attach them to later requests by the UA so that other servers can determine that the request is authorized? - Various nits, including: The document uses RFC 2119 rather than RFC 8174, which updates 2119. There is a reference to "RFC474bis" which should be "RFC4474bis". Dale From nobody Mon Jun 11 13:01:40 2018 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 BB9CF130ECB for ; Mon, 11 Jun 2018 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWk-0cBU0dLc for ; Mon, 11 Jun 2018 13:01:36 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 BCCD3130EC9 for ; Mon, 11 Jun 2018 13:01:35 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id d74-v6so12747786vke.10 for ; Mon, 11 Jun 2018 13:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SrtZzw+CYSW8jlXhBechMXNxx3R7bx366J8KwIcOMKE=; b=hjmRzSBTVfYeGuo24Hen4jOuzgYq597WbMB+9D5bVG1ydD9SQh9Olo1ml/UkX6VS27 mCOhpDoJ+yiV3fG6hoCSxss8XjR5UydouuYPrjS2lFsOeRYu5zc2IcBgPfqsRBsQ1sBj ffbl3doJqxzqudteu8fIhIKqn4qtPLzlIrNuMdEbySxc/jmeW+1cFtJ/G2YRVRWziQwG i/KbEdfcL6S2eOjpMTgwj3pqCU0hjgxnf+dLehYMVqwvc43UDvgbJp9oUdNoLir7g+64 v2CIPEnq20ca0I7+S966U4xRPEJDSu1auXyn0HgES6jax0DWHn6SoeKIQJZk/7Mh10cG rUlA== 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=SrtZzw+CYSW8jlXhBechMXNxx3R7bx366J8KwIcOMKE=; b=GYO6HM0BEGEhWtl9nbfo0rlz7DKQ/2hWadFDWcAc97NYZbyllBaulTyzP27cPu4NWr bdGT+nXjaYF4LLKmtbSvNyfvoiunZ6SevnhP8rJSyVXQAD0HeMV//3vpjThARstmkUHi eRVcMa8Nlnb6XYIh9v0P1vCDkD7FN9uSqLHFeJcvvzoaYheiccjxKGkoNGpV1sHZtkqs B2yPEZOk+g56gMJF71Dj+1NMCb8b23ttY/tCpBZTm5sOjKnUyh2kYMtnUjIQ5W/n2pwG mnkGrpOi6tHy1KQbku8bRjJbBgGJh54pVSTtvvn2a2rWnA5LSCBwpBsqu+rsQj1GTmCn JSug== X-Gm-Message-State: APt69E1+5VxqPc5kWf7TPC9iIYr4RN07k5JtuasODrzwS/WfqZ8HYhVy JO0t6zhW403oDxiMJ8juaywQWYnTMYMOuK5b7qs= X-Google-Smtp-Source: ADUXVKI4J33cEeCiIsKgZzJ/O4EpyxrTxuoOLR9uyJnpqN/sgdHzXe4ScxvmzgiSsFyLlUzgVWqnYkgmtPSHkXvJ848= X-Received: by 2002:a1f:8bc6:: with SMTP id n189-v6mr377319vkd.104.1528747294677; Mon, 11 Jun 2018 13:01:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 11 Jun 2018 16:01:53 -0400 Message-ID: To: Yehoshua Gev Cc: SIPCORE Content-Type: multipart/alternative; boundary="000000000000736023056e6337b5" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 20:01:39 -0000 --000000000000736023056e6337b5 Content-Type: text/plain; charset="UTF-8" Inline... On Sun, Jun 10, 2018 at 7:48 AM Yehoshua Gev wrote: > Thanks Rifaat. > See inline. > > > > On Fri, Jun 8, 2018 at 10:16 PM, Rifaat Shekh-Yusef > wrote: > >> Hi Yehoshua, >> >> Thanks for your review and comments. >> See my replies inline. >> >> Regards, >> Rifaat >> >> >> On Thu, Jun 7, 2018 at 3:54 AM, Yehoshua Gev wrote: >> >>> Hi, >>> >>> Several comments: >>> >>> Section 2.2.4: There is a reference to RFC 4474 for the list of SIP >>> headers to be included in digest-string. >>> I think it would be good to specifically indicate that the digest-string >>> equals to signed-identity-digest of RFC 4474, but without the enclosing >>> quotes. >>> >> >> I am not clear on what you mean by "digest-string equals to >> signed-identity-digest " >> The goal is to use the shared-key to provide a hash of digest-string as >> proof that the client has access to the shared-key. >> > > I meant that the current text doesn't include the specific syntax of digest-string, > it just references RFC 4474, which doesn't mention digest-string. > RFC 4474 mention another element (signed-identity-digest) which seems > very similar to digest-string. > The only difference I see between them, is that signed-identity-digest is > enclosed by quoted, while digest-string doesn't. > digest-string is defined in section 9 https://tools.ietf.org/html/rfc4474#section-9 >> >>> >>> Section 3.2: The last paragraph does not indicate what should be done in >>> case of authentication failure (due to missing authentication token in the >>> request or usage of invalid token). >>> RFC 6750 section 3 requires the use of 401 with WWW-Authenticate header, >>> and details the syntax of that header. >>> I believe that the draft can add a reference to that section, saying >>> that the same syntax should be used in SIP. >>> >> >> Yeah, I agree that the document should explicitly cover the failure use >> case. >> I will address that in the next version of the document. >> >> >>> Section 4: >>> a. I think that a note should be added that the syntax of the Bearer >>> scheme defined here for SIP deviates from the syntax defined by RFC 6750 >>> (in that that the token is given in a name=value format). I believe this is >>> done to conform to the current SIP ABNF - maybe this should be written as a >>> reasoning for the deviation. >>> >> >> That is correct. I will add a note. >> >> >>> >>> b.. Given the proposed syntax, I don't see a reason to forbid >>> extensions. Maybe the syntax could be written like: >>> credentials /= ("Bearer" LWS bearer-response) >>> bearer-response = "access_token" EQUAL access_token *(COMMA auth-param) >>> >>> >> We could do that. Do you have a specific parameter in mind? >> > I don't have anything in mind. > > I will look into the proper syntax for this. >> >> >> >>> General: >>> The draft describes how registrations are authenticated. >>> There are scenarios for which there is no registration done (like >>> click-to-call, where only outbound calls are done). >>> Maybe the draft should be expanded to include any SIP request. >>> >>> >> Good point. I will add some text around that. >> >> >> >>> This might even be a security issue: >>> In regular SIP Digest authentication, the Authorization header is >>> included in all requests even after successful registration, probably as >>> SIP doesn't require that subsequent requests are sent over the same >>> [authenticated/secured] transport-layer connection. >>> Section 2 of the draft roughly corresponds to the methods described in >>> section 4 (Obtaining Authorization) of RFC 6749. >>> But, in RFC 6749 these methods are only used to obtain an access token >>> to be used on subsequent requests, whilst in the draft they are used for >>> achieving access. >>> I'm not an expert on OAuth, but I believe the only methods to achieve >>> access are defined in section 7 (Accessing Protected Resources) of RFC >>> 6749, which require the usage of an access token with Authorization header >>> (similar to section 3 of the draft). >>> >>> >> Section 2.1.2 defines the idea of a shared-key to be used to establish >> new connection and re-register to the proxy after a connection is lost, >> without the need for a new code. >> This same mechanism could be used with all subsequent requests, not only >> registration. I will add some text to explicitly state that. >> >> After re-reading section 2, I think I can better explain my concern. > The section defines a way for the SIP proxy to maintain the authenticity > of the UA without challenging all the requests of the UA. > Probably it takes the assumption that all (and only) the UA traffic will > be sent over the same secured transport-layer connection. > If this is the assumption (which I don't really like), I think that this > should be defined as a MUST for the proxy to reject requests received on > other connections. > > No, the point of the shared-key idea is to allow the phone to establish new connections, when needed, to send new requests. > Also, if the UA "is incapable of maintainings (typo) the confidentiality > of the user credentials and any obtained tokens." (section 1.4), how > would it store the shared-key of section 2.1.2? > The shared-key is created and maintained in memory, while the other credentials are usually stored locally for example in flash. Also, the document provides a way to enable or disable this functionality, based on the security policy on the server. > And how come OAuth, as used for HTTP, doesn't rely on proxies, but relies > on the clients storing a token? Are SIP UAs more insecure than web browsers? > > > I suggest that the mechanisms of section 2 will only be used by the UA to > acquire a token, which will later be used according to the mechanism of > section 3. > This way the behavior of SIP UA will be much similar to the behavior of > HTTP client. > The browser does not store any tokens when the *code flow* is used, and that is what this flow is trying to do here. Section 3 defines that mechanism that you are suggesting here. Regards, Rifaat > >> Regards, >> Rifaat >> >> >> >> >>> Thanks, >>> Yehoshua Gev >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> > --000000000000736023056e6337b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline...

On Sun, Jun 10, 2018 at 7:48 AM Yehoshua Gev <yoshigev@gmail.com> wrote:
Thanks Rifaat.
See in= line.
=C2=A0


<= div class=3D"gmail_quote">On Fri, Jun 8, 2018 at 10:16 PM, Rifaat Shekh-Yus= ef <rifaat.ietf@gmail.com> wrote:
Hi Yehoshua,

Thanks for your review and comments.
See my replies inline= .

Regards,
=C2=A0Rifaat


On Thu,= Jun 7, 2018 at 3:54 AM, Yehoshua Gev <yoshigev@gmail.com> = wrote:
Hi,

Several comments:

Section= 2.2.4: There is a reference to RFC 4474 for the list of SIP headers to be = included in digest-string.
I think it would be good to specifical= ly indicate that the digest-string equals to signed-identity-digest of RFC = 4474, but without the enclosing quotes.

I am not clear on what you mean by "digest-string eq= uals to signed-identity-digest "
The goal is to use the shared-key to provide a hash of dig= est-string as proof that the client has access to the shared-key.

I meant that the current tex= t doesn't include the specific syntax of=C2=A0digest-string, it just = references=C2=A0RFC 4474, which doesn't mention=20 4474 mention another element (= signed-identity-digest) which seems very similar= to=C2=A0digest-string.
The only difference I see between them, is that=C2=A0signed-identity-digest is enclosed by quoted, while=C2=A0= https://tools.ietf.org/html/rfc4474#section-9

=
=C2=A0

Section 3.2: The la= st paragraph does not indicate what should be done in case of authenticatio= n failure (due to missing authentication token in the request or usage of i= nvalid token).
RFC 6750 section 3 requires the use of 401 with WW= W-Authenticate header, and details the syntax of that header.
I b= elieve that the draft can add a reference to that section, saying that the = same syntax should be used in SIP.

<= /span>
Yeah, I agree that the document should explicitly cover the fail= ure use case.
I will address that in the next version of the docu= ment.


Section 4:
a. I think that a not= e should be added that the syntax of the Bearer scheme defined here for SIP= deviates from the syntax defined by RFC=C2=A06750 (in that that the token = is given in a name=3Dvalue format). I believe this is done to conform to th= e current SIP ABNF - maybe this should be written as a reasoning for the de= viation.

That is correct= . I will add a note.
=C2=A0

b.. Given the pr= oposed syntax, I don't see a reason to forbid extensions. Maybe the syn= tax could be written like:
=C2=A0 credentials /=3D (&q= uot;Bearer" LWS bearer-response)
=C2=A0 bearer-response =3D = "access_token" EQUAL access_token *(COMMA auth-param)
=


We could do th= at. Do you have a specific parameter in mind?
I don't have anything in mind.

I will look into the proper synt= ax for this.

=C2=A0
General:<= /div>
The draft describes how registrations are authenticated.
There are scenarios for which there is no registration done (like click-t= o-call, where only outbound calls are done).
Maybe the draft shou= ld be expanded to include any SIP request.


Good point. I will add some text around t= hat.

=C2=A0
This might even be = a security issue:
In regular SIP Digest authentication, the Autho= rization header is included in all requests even after successful registrat= ion, probably as SIP doesn't require that subsequent requests are sent = over the same [authenticated/secured]=C2=A0transport-layer connect= ion.
Section 2 of the draft roughly corresponds to the methods de= scribed in section 4 (Obtaining Authorization) of RFC 6749.
But, = in RFC 6749 these methods are only used to obtain an access token to be use= d on subsequent requests, whilst in the draft they are used for=20 assumption=C2=A0(which I don't really like), I think that this= should be defined as a MUST for the proxy to reject requests received on o= ther connections.

N= o, the point of the shared-key idea is to allow the phone to establish new = connections, when needed, to send new requests.
=C2=A0
Also, if the UA &q= uot;is incapable of ma= intainings (typo)=C2=A0the confidentiality of the user credentials and any obtained=C2=A0<= /span>tokens." (s= ection 1.4), how would it store the shared-key of section 2.1.2?

The shared-key is crea= ted and maintained in memory, while the other credentials are usually store= d locally for example in flash.
Also, the document provides a way= to enable or disable this functionality, based on the security policy on t= he server.
=C2=A0
And how come = OAuth, as used for HTTP, doesn't rely on proxies, but relies on the cli= ents storing a token? Are SIP UAs more insecure than web browsers?= =C2=A0
I suggest that the mechanisms of section 2 will only be used by the UA = to acquire=C2=A0a token, which will later be used according to the mechanis= m of section 3.
This way the behavior of SIP UA will be much similar to t= he behavior of HTTP client.

code flow=C2=A0is used, and that is what = this flow is trying to do here.
Sec= tion 3 defines that mechanism that you are suggesting here.

<= /div>
Rega= rds,
=C2=A0Rifaat

=C2=A0
=
Regards,
=C2=A0Rifaat

=C2=A0
=
Thanks,
Yehoshua Gev
<= br>

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



--000000000000736023056e6337b5-- From nobody Mon Jun 11 13:41:08 2018 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 94F09130ED0 for ; Mon, 11 Jun 2018 13:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-_KB9fLOfq5 for ; Mon, 11 Jun 2018 13:41:04 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 014A9130EC4 for ; Mon, 11 Jun 2018 13:41:04 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k14-v6so14432935uao.12 for ; Mon, 11 Jun 2018 13:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LVsKt0S6V1+LGugpr662+Yu2t6t6ZJ232g+U8tTWiqM=; b=UoYXxX6W+Pw2jbAxVqm6xOYtCEnTETkWBOzDZZISrIbvHArvZcO2baWBNtE0VQs79i I0qXeoM9GOblhQ3b2yf7BTMd06nQUubrER1WLzRppfHvWj1ccrB0671x6FD/7hzZ2xsZ rSPAnQgSMUpgaiq4hshsWyPyeoV97N/Wbvg2IIxgrwn+z4ENk6y/EUzjwh/Nx9HtqTUh MogJfkpe+/9nHu7MVRo6BbQZuYoitD+kN4n276SXSnrPZQ3e8ZQXJaX6v2ZHnR9bztqJ No9Ax1OvJHxrrfPBTfV199mwMlW0UCX3ew7MlnpSNFWfbXKtMY1RV0gSeQtP/X0aYlAD TFFQ== 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=LVsKt0S6V1+LGugpr662+Yu2t6t6ZJ232g+U8tTWiqM=; b=oKps4VZ3jUBzWqvQVvrG0a19jqUcZVf+hJ2UW8Slm/X2oSs59a3J2iBPHrCVw43ZPS esdkCbVQ1XDlcpgmjfKHp7NIDYFvFztdXPTmElTUJJcCywClnSN3/r+kiHjJkCHRa2+u K3uVnf7p2TzyneUWEWgnUimu8Fgq8eUIb2pZdyI4VYTuMe7GHSHUXWctNhc8BtFed9sW Ql9mas9aGEYQmYR21CIp0ivtLCnt3GUN2cwyKO5AGPfp9rTR6oJIm1YkVj82kyKqZAU/ dwh6cWhBFx+VwzaYXZkFB+PKS46GznbW1TIltSwEC/09B8KBgE7it1unFK940zuI98k2 s6Qg== X-Gm-Message-State: APt69E2H/aHq1rghR/klcjozFc95eFbaChlfiSa66BelasIl4Yu/MJDW mowdSIf0lqP/QNu2iCuN1cTb/eKwMnAyw8iC3VLxng== X-Google-Smtp-Source: ADUXVKIDhfs6W5a1MfbSQnFnpO5nzYyNGTKWuNKp00BIjfGkyvB/VHoLzJAEyn5zrwvfkJyXsLlEnK0fKHaA+sDmDUs= X-Received: by 2002:a9f:3c13:: with SMTP id u19-v6mr511856uah.70.1528749662518; Mon, 11 Jun 2018 13:41:02 -0700 (PDT) MIME-Version: 1.0 References: <87h8magx2s.fsf@hobgoblin.ariadne.com> In-Reply-To: <87h8magx2s.fsf@hobgoblin.ariadne.com> From: Rifaat Shekh-Yusef Date: Mon, 11 Jun 2018 16:41:21 -0400 Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000095c222056e63c483" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 20:41:07 -0000 --00000000000095c222056e63c483 Content-Type: text/plain; charset="UTF-8" Hi Dale, Thanks for your review and comments. Please, see my replies inline. Regards, Rifaat On Sun, Jun 10, 2018 at 5:18 PM Dale R. Worley wrote: > This is an interesting and important piece of work. I've attempted to > read earlier versions once or twice and never successfully understood > it. This version of the draft is more comprehensible than previous > versions and seems to be on the right track, but there are a number of > important issues that need to be addressed. Trying to list them in > order of importance: > > - All of the interactions with the "authorization server" are > described as out of scope. This is rather a problem, since all of the > call flows that the document describes require the authorization > server as an integral part of the flow. If interacting with the > authorization server is not standardized, then no interoperability has > been defined in practice -- both the UA and the proxy must have > special knowledge of the authorization server. In practice, that > means that all components of the system will have to be purchased from > one vendor. > (As a consequence, the meaning of the Location header in the 401 > response (section 2.1.1) is not fixed -- the UA is expected to do > something with the value of the header, but there is no specification > of what that is.) > > The missing parts are the ones that use the existing OAuth 2.0 mechanism defined in RFC6749. I will try to add more details to make it clearer. - The Security Considerations section does not describe whether and > how the messages in the call flows need to be protected from > eavesdropping. > > Yeah, I will add these details. > - The document doesn't give a clear statement of which requests are > authenticated, what guarantees the authentication provides, or how the > call flows might be used in authorizing requests. The only use of the > authentication/authorization information specified in the document is > SIP registration, but I suspect the intention is that SIP requests > carrying authentication/authorization can be forwarded to other server > entities, which can validate the AA information to determine whether > to service the request. > > This part is out of scope for this document. We had a long debate on the mailing list about this, so we left it for future documents. > - The terminology is not consistent throughout the document. It's > really important to use only one phrase to name each thing in a > system, and to put the definition in the glossary. E.g., > "Authorization Server" and "AuthZ" server are used interchangeably, > and I suspect that "the server" and "IdP entity" also mean the same > thing. Of course, SIP and OAuth may use different terms for the same > entity, which makes things harder, but the glossary can show the > correspondence between the two sets of terms. > > I will fix that. > - The meaning, use, and format of the various data items is not clear. > E.g., what is the format and significance of an "authorization code"? > In particular, HMAC is used without specifying how its output (which > is a sequence of binary octets) is encoded when it is included in SIP > messages. > > I will fix that. > - The example call flow diagrams do not include enough detail, which > means I can't study them to get into my memory a good idea of what the > flow diagram illustrates. Also, though the description gives an > overview, but there's considerable information about the dataflow of > authorization values that is under-described. E.g., at the end of the > section 2.1 flow, it *seems* that the proxy will retain "tokens" > associated with the registration, but that's not stated, nor is it > stated how the tokens might be used. Is the proxy expected to attach > them to later requests by the UA so that other servers can determine > that the request is authorized? > > I will clarify that > - Various nits, including: > > The document uses RFC 2119 rather than RFC 8174, which updates 2119. > > There is a reference to "RFC474bis" which should be "RFC4474bis". > > Thanks, Rifaat > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00000000000095c222056e63c483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dale,

Thanks for your review and com= ments.
Please, see my replies inline.

Re= gards,
=C2=A0Rifaat



<= /div>
On Sun, Jun 10, 2018 a= t 5:18 PM Dale R. Worley <worley@ariadne.com> wrote:
This is an interesting and important piece of work.=C2=A0 I'= ve attempted to
read earlier versions once or twice and never successfully understood
it.=C2=A0 This version of the draft is more comprehensible than previous versions and seems to be on the right track, but there are a number of
important issues that need to be addressed.=C2=A0 Trying to list them in order of importance:

- All of the interactions with the "authorization server" are
described as out of scope.=C2=A0 This is rather a problem, since all of the=
call flows that the document describes require the authorization
server as an integral part of the flow.=C2=A0 If interacting with the
authorization server is not standardized, then no interoperability has
been defined in practice -- both the UA and the proxy must have
special knowledge of the authorization server.=C2=A0 In practice, that
means that all components of the system will have to be purchased from
one vendor.
(As a consequence, the meaning of the Location header in the 401
response (section 2.1.1) is not fixed -- the UA is expected to do
something with the value of the header, but there is no specification
of what that is.)

The missing parts are the ones that use the existing = OAuth 2.0 mechanism defined in RFC6749.
I will try to add more de= tails to make it clearer.
=C2=A0

- The Security Considerations section does not describe whether and
how the messages in the call flows need to be protected from
eavesdropping.

Yeah, I will add these details.

<= div>=C2=A0
- The document doesn't give a clear statement of which requests are
authenticated, what guarantees the authentication provides, or how the
call flows might be used in authorizing requests.=C2=A0 The only use of the=
authentication/authorization information specified in the document is
SIP registration, but I suspect the intention is that SIP requests
carrying authentication/authorization can be forwarded to other server
entities, which can validate the AA information to determine whether
to service the request.

This part is out of scope for this document.
We had a long debate on the mailing list about this, so we left it for fu= ture documents.

=C2=A0
- The terminology is not consistent throughout the document.=C2=A0 It's=
really important to use only one phrase to name each thing in a
system, and to put the definition in the glossary.=C2=A0 E.g.,
"Authorization Server" and "AuthZ" server are used inte= rchangeably,
and I suspect that "the server" and "IdP entity" also m= ean the same
thing.=C2=A0 Of course, SIP and OAuth may use different terms for the same<= br> entity, which makes things harder, but the glossary can show the
correspondence between the two sets of terms.

I will fix that.

=C2=A0
- The meaning, use, and format of the various data items is not clear.
E.g., what is the format and significance of an "authorization code&qu= ot;?
In particular, HMAC is used without specifying how its output (which
is a sequence of binary octets) is encoded when it is included in SIP
messages.

I will fix that.

=C2=A0
- The example call flow diagrams do not include enough detail, which
means I can't study them to get into my memory a good idea of what the<= br> flow diagram illustrates.=C2=A0 Also, though the description gives an
overview, but there's considerable information about the dataflow of authorization values that is under-described.=C2=A0 E.g., at the end of the=
section 2.1 flow, it *seems* that the proxy will retain "tokens"<= br> associated with the registration, but that's not stated, nor is it
stated how the tokens might be used.=C2=A0 Is the proxy expected to attach<= br> them to later requests by the UA so that other servers can determine
that the request is authorized?

I will clarify that

=C2=A0
- Various nits, including:

The document uses RFC 2119 rather than RFC 8174, which updates 2119.

There is a reference to "RFC474bis" which should be "RFC4474= bis".


Thanks,
=C2=A0Rifaat
=C2=A0
Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000095c222056e63c483-- From nobody Tue Jun 12 19:21:49 2018 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 E6DCB130DC2 for ; Tue, 12 Jun 2018 19:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 yR4zELycWxJm for ; Tue, 12 Jun 2018 19:21:45 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 D6F8D127332 for ; Tue, 12 Jun 2018 19:21:44 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id Su3qfygSDN6xcSvPsfdn0u; Wed, 13 Jun 2018 02:21:44 +0000 Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-03v.sys.comcast.net with ESMTPA id SvPqfojMziX04SvPrfYLWH; Wed, 13 Jun 2018 02:21:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w5D2LgD2004625; Tue, 12 Jun 2018 22:21:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w5D2LfOg004622; Tue, 12 Jun 2018 22:21:41 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef Cc: sipcore@ietf.org In-Reply-To: (rifaat.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 12 Jun 2018 22:21:41 -0400 Message-ID: <87lgbjfmtm.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfPBu4QQVCAN7cxNRRCVfWv6zGNexv72hljo91fYX9LIy5Gw0E9IvUK5Y5pMQNepcOkxoO6O5kXST7GvxZc0dhFLhmjozgKkLMsJDtWNfwhLuSrdVGg4o ExJW3Ii+HB7Kx5r18AVWo2sH0rXcY4b1EKsJoY00XRCiwxkdSi2iSqU162JTjupgdL/fib4nIi2/1WuQHXPLxAFTteOAVkIJZo0= Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 02:21:46 -0000 Rifaat Shekh-Yusef writes: > (As a consequence, the meaning of the Location header in the 401 >> response (section 2.1.1) is not fixed -- the UA is expected to do >> something with the value of the header, but there is no specification >> of what that is.) >> >> The missing parts are the ones that use the existing OAuth 2.0 mechanism > defined in RFC6749. > I will try to add more details to make it clearer. One suggestion is that the Location header in the F2 401 response should have a field parameter to indicate to the Agent the intended meaning of the Location URI, i.e., its the URL of an OAuth Authorization Server and should be accessed per the protocols in this document. More importantly, a quick look suggests that where section 2.1 shows this | F2 401 Unauthorized | | | Location: AuthZ Server | |<------------------------------| | | | | | | | > The UA prompts the user to provide his/her credentials. | > The UA then, as per OAuth 2.0 protocol, authenticates the user to | > the AuthZ server, and obtains an authorization code, which the UA | > will later hand to the Proxy. | |<------------------------------------------------------------->| | | | | | | | F3 REGISTER [authz code] | | |------------------------------>| | there is intended to be a reference to 4.1.1 and 4.1.2 of RFC 6749. 4.1.1 tells how the Agent is to construct an HTTP GET request, which starts the interaction between the user and the Authorization Server. Eventually, per 4.1.2, the Authorization Server sends the web client a redirection to a URL based on the redirect_uri parameter in the initial GET request. The Agent recognizes that URL and extracts from it the authorization code, which it includes in the body of the F3 REGISTER per 2.1.1 in this draft. Generally speaking, I estimate that nobody reading this document will have prior knowledge of OAuth, so it would help greatly if you could provide the cross-references between the parts of the protocol described here with the sections of RFC 6749 that are incorporated into it. Currently, the document only says "The method used by the UA to obtain the code is out of scope for this document." which is generally used to mean "that part is not defined", not "that part is specified in RFC XXXX, so we won't repeat it here"! >> - The document doesn't give a clear statement of which requests are >> authenticated, what guarantees the authentication provides, or how the >> call flows might be used in authorizing requests. The only use of the >> authentication/authorization information specified in the document is >> SIP registration, but I suspect the intention is that SIP requests >> carrying authentication/authorization can be forwarded to other server >> entities, which can validate the AA information to determine whether >> to service the request. >> >> This part is out of scope for this document. > We had a long debate on the mailing list about this, so we left it for > future documents. The problem is that if there's no specification of how this would be used to actually do something, you haven't answered the question "Why bother?". If I guess correctly, once the registration is set up (F3 in 2.1), then the proxy is expected to apply the "tokens" to any request that the Agent sends to it, before the proxy forwards the request to its destination. If you would specify how that is done, I would see how this could be used in a practical system. Dale From nobody Wed Jun 13 06:30:23 2018 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 8BE65130EA1 for ; Wed, 13 Jun 2018 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu0ORHhVAS09 for ; Wed, 13 Jun 2018 06:30:16 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 762EF130E37 for ; Wed, 13 Jun 2018 06:30:15 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id o138-v6so1508747vkd.3 for ; Wed, 13 Jun 2018 06:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cZB7eg9/0jX4Q4OEOLkwKGypMsoglb0W2DRMpb5sgRY=; b=WERboS1/r6WGF56rvE+uBmgbtDirgB+ClPZnr6MTaVc//qrqSWPzUMqSN08iNcGACY CLSIVpF/66qDtczcpvqFIKv5b5Z/xfefJ3vaXHLkD/EI9JaKOEj2mZKpmVgLelXiBjIs m6ELx5faD1iyaj0ihT5ZwmXP+KEpxmCJ3b4wW3+YXRfDrTzIZavQ40vE9+OfJX7vQ4uR n7mvLJDpW2kHvn/uA0nkWc54aSNtLbz4yYGhmAhmGxwEO13zxeoGRU344ULEKy5UGfjU L02uE+hbPdafRFnHifxt+9N8rAW7zvV2gyV14KlXve/lNn0gn40RTgc35iqZbQy/oPzF 8zdw== 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=cZB7eg9/0jX4Q4OEOLkwKGypMsoglb0W2DRMpb5sgRY=; b=NWQjJtNHeUt5Qw3+KAIcg1IQ+jbD6YDaLmydSsuqtVT99YdfEQ+UIC7s3OykPeyKwv xZlbHTNtnAInRA4NRANHdvF1NCcYUhV4/wyyCZenQTuO4YUBfCmT2397B5Pbs8EGw1ux p5I27k1cyBHD232XLFAJMC8A9PAkgQVbIr/FZjsYfqKl0+VAKjWCweSfrTLH9jN2+SY5 059ws7ZR5e0Q32I4XQxGde6JiOGV3cSjPq0RTroSwn3qtvMM/1Yj5VM3wGmOhgxhwwIK iwCU07PGJXXP1T33Y5Wkkiz1d8SyZh2Vlqr6wrf0d4buas9db7V7SSLWGM9F5BtPBu2F vIfA== X-Gm-Message-State: APt69E0eBCeCXCXs052Iq9IUQjGLdxGjlNsr8O4xNY/4jeDph4A3QTv5 GG4e86WAz9tUHsD2vkPVxfdca2YI1CttM/2q2ldvi5PH X-Google-Smtp-Source: ADUXVKL5cygFyTjBq+FYGZdXx5KRRLtEcAY2XNKWSVwKHoc+stpa3gMbWGo43m1Dh+DqExPh4MKPoVKxv2EKK0Tcmbs= X-Received: by 2002:a1f:de82:: with SMTP id v124-v6mr3021299vkg.92.1528896614081; Wed, 13 Jun 2018 06:30:14 -0700 (PDT) MIME-Version: 1.0 References: <87lgbjfmtm.fsf@hobgoblin.ariadne.com> In-Reply-To: <87lgbjfmtm.fsf@hobgoblin.ariadne.com> From: Rifaat Shekh-Yusef Date: Wed, 13 Jun 2018 09:30:33 -0400 Message-ID: To: "Dale R. Worley" Cc: SIPCORE Content-Type: multipart/alternative; boundary="00000000000094ac35056e85fbb7" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-authn-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 13:30:21 -0000 --00000000000094ac35056e85fbb7 Content-Type: text/plain; charset="UTF-8" Inline... On Tue, Jun 12, 2018 at 10:21 PM Dale R. Worley wrote: > Rifaat Shekh-Yusef writes: > > (As a consequence, the meaning of the Location header in the 401 > >> response (section 2.1.1) is not fixed -- the UA is expected to do > >> something with the value of the header, but there is no specification > >> of what that is.) > >> > >> The missing parts are the ones that use the existing OAuth 2.0 mechanism > > defined in RFC6749. > > I will try to add more details to make it clearer. > > One suggestion is that the Location header in the F2 401 response should > have a field parameter to indicate to the Agent the intended > meaning of the Location URI, i.e., its the URL of an OAuth Authorization > Server and should be accessed per the protocols in this document. > Will do. > > More importantly, a quick look suggests that where section 2.1 shows > this > > | F2 401 Unauthorized | | > | Location: AuthZ Server | > |<------------------------------| | > | | | > | | | > > The UA prompts the user to provide his/her credentials. | > > The UA then, as per OAuth 2.0 protocol, authenticates the user to | > > the AuthZ server, and obtains an authorization code, which the UA | > > will later hand to the Proxy. | > |<------------------------------------------------------------->| > | | | > | | | > | F3 REGISTER [authz code] | | > |------------------------------>| | > > there is intended to be a reference to 4.1.1 and 4.1.2 of RFC 6749. > 4.1.1 tells how the Agent is to construct an HTTP GET request, which > starts the interaction between the user and the Authorization Server. > Eventually, per 4.1.2, the Authorization Server sends the web client a > redirection to a URL based on the redirect_uri parameter in the initial > GET request. The Agent recognizes that URL and extracts from it the > authorization code, which it includes in the body of the F3 REGISTER per > 2.1.1 in this draft. > > Generally speaking, I estimate that nobody reading this document will > have prior knowledge of OAuth, so it would help greatly if you could > provide the cross-references between the parts of the protocol described > here with the sections of RFC 6749 that are incorporated into it. > Currently, the document only says "The method used by the UA to obtain > the code is out of scope for this document." which is generally used to > mean "that part is not defined", not "that part is specified in RFC > XXXX, so we won't repeat it here"! > > Sure. I did assume that people are familiar with OAuth, which in hindsight it is clear that was a mistake. >> - The document doesn't give a clear statement of which requests are > >> authenticated, what guarantees the authentication provides, or how the > >> call flows might be used in authorizing requests. The only use of the > >> authentication/authorization information specified in the document is > >> SIP registration, but I suspect the intention is that SIP requests > >> carrying authentication/authorization can be forwarded to other server > >> entities, which can validate the AA information to determine whether > >> to service the request. > >> > >> This part is out of scope for this document. > > We had a long debate on the mailing list about this, so we left it for > > future documents. > > The problem is that if there's no specification of how this would be > used to actually do something, you haven't answered the question "Why > bother?". > If I guess correctly, once the registration is set up (F3 in 2.1), then > the proxy is expected to apply the "tokens" to any request that the > Agent sends to it, before the proxy forwards the request to its > destination. If you would specify how that is done, I would see how > this could be used in a practical system. > > The main problem that this document is trying to address is the *Single-Sign On*. We would like to allow the SIP UA to use one set of credentials to authenticate and get access to SIP and non-SIP services. With regards to the authorization part, take a look at the following thread: https://www.ietf.org/mail-archive/web/sipcore/current/msg07223.html Because we could not get to an agreement at that time, we decided to work on the parts that there is agreement on, and that is the reason for this document and its limited scope. Regards, Rifaat > Dale > --00000000000094ac35056e85fbb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline...


On Tue, Jun 12, 2018 at 10:21 PM Dale R. Worley <worley@ariadne.com> wrote:
Rifaat Shekh-Yusef <= rifaat.ietf@gmai= l.com> writes:
> (As a consequence, the meaning of the Location header in the 401
>> response (section 2.1.1) is not fixed -- the UA is expected to do<= br> >> something with the value of the header, but there is no specificat= ion
>> of what that is.)
>>
>> The missing parts are the ones that use the existing OAuth 2.0 mec= hanism
> defined in RFC6749.
> I will try to add more details to make it clearer.

One suggestion is that the Location header in the F2 401 response should have a field parameter to indicate to the Agent the intended
meaning of the Location URI, i.e., its the URL of an OAuth Authorization Server and should be accessed per the protocols in this document.

Will do.

=C2=A0

More importantly, a quick look suggests that where section 2.1 shows
this

=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0F2 401 Unauth= orized |=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=A0|
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Locat= ion: AuthZ Server=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=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=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=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=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=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=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 The UA prompts the user to provide his/her credentials.=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 The UA then, as per OAuth 2.0 protocol, authenticates the user t= o |
>=C2=A0 the AuthZ server, and obtains an authorization code, which the U= A |
>=C2=A0 will later hand to the Proxy.=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= =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=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=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=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=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=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0| F3 REGISTER [authz code]=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=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

there is intended to be a reference to 4.1.1 and 4.1.2 of RFC 6749.
4.1.1 tells how the Agent is to construct an HTTP GET request, which
starts the interaction between the user and the Authorization Server.
Eventually, per 4.1.2, the Authorization Server sends the web client a
redirection to a URL based on the redirect_uri parameter in the initial
GET request.=C2=A0 The Agent recognizes that URL and extracts from it the authorization code, which it includes in the body of the F3 REGISTER per 2.1.1 in this draft.

Generally speaking, I estimate that nobody reading this document will
have prior knowledge of OAuth, so it would help greatly if you could
provide the cross-references between the parts of the protocol described here with the sections of RFC 6749 that are incorporated into it.
Currently, the document only says "The method used by the UA to obtain=
the code is out of scope for this document." which is generally used t= o
mean "that part is not defined", not "that part is specified= in RFC
XXXX, so we won't repeat it here"!

Sure.
I did assume that people are familiar= with OAuth, which in hindsight it is clear that was a mistake.
= =C2=A0

>> - The document doesn't give a clear statement of which request= s are
>> authenticated, what guarantees the authentication provides, or how= the
>> call flows might be used in authorizing requests.=C2=A0 The only u= se of the
>> authentication/authorization information specified in the document= is
>> SIP registration, but I suspect the intention is that SIP requests=
>> carrying authentication/authorization can be forwarded to other se= rver
>> entities, which can validate the AA information to determine wheth= er
>> to service the request.
>>
>> This part is out of scope for this document.
> We had a long debate on the mailing list about this, so we left it for=
> future documents.

The problem is that if there's no specification of how this would be used to actually do something, you haven't answered the question "= Why
bother?".
The main problem that this document is tr= ying to address is the Single-Sign On.
We would like to allow the SIP UA to use one set of credentials t= o authenticate=C2=A0
and get access = to SIP and non-SIP services.

With regards to the authorization part= , take a look at the following thread:

Because we could not get to an agreement at that time, we = decided to work=C2=A0
on the parts t= hat there is agreement on, and that is the reason for this=C2=A0
document and its limited scope.

Regards,
=C2=A0Rifaat

=C2=A0
Dale
--00000000000094ac35056e85fbb7-- From nobody Mon Jun 18 00:51:47 2018 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 C97D4130E61 for ; Mon, 18 Jun 2018 00:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 UVSLjJ3661pY for ; Mon, 18 Jun 2018 00:51:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6AD130E85 for ; Mon, 18 Jun 2018 00:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529308300; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Os2fgpNQ5jfIetqeeGVqs6+FZ/EGNGJLsDnW6HcrzTc=; b=CxRtzLTmJXydeCYqZy7qfJ8GjvYI4P2+z67Zi4YRqzMl3+/sc6bSW6riSJKDSGd4 EyGd/ldRFPSI87Z7Pe94a2SLZeeh/mi0anF//GsTPLU9hPhr+NiVW/Tv7HaG+RW9 SNy56eSm77BUnQC7mz0GLFjpUxsLl82B1H5n8GwnOuA=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-69-5b27648c2874 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.E3.22015.C84672B5; Mon, 18 Jun 2018 09:51:40 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 18 Jun 2018 09:51:39 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Mon, 18 Jun 2018 09:51:39 +0200 From: Christer Holmberg To: Christer Holmberg , Martin Thomson CC: SIPCORE , "sipcore-chairs@ietf.org" Thread-Topic: [sipcore] Draft new version: sip-push-13 Thread-Index: AQHT0ZUebqw9NffvP0uySpMUTA5bkqQxp7yAgACSbQCAAMtWAIADyx3ggAKbzICAAJGJ0IAWKwUAgBX4UYA= Date: Mon, 18 Jun 2018 07:51:39 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B72EF43F6@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72EF7FA7@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="euc-kr" Content-ID: <4AE6232BD4A7FF49B5018DFB5964625F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2J7uW5Pinq0wf/fShbXzvxjtOj9vJDZ 4uuPTWwOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8bvs59YChpkK/5smcjSwLhApouR k0NCwERi18pupi5GLg4hgaOMErtPnYdyvjFKtCxaAOUsY5SY9foIYxcjBwebgIVE9z9tkG4R gWSJMy8WMoPYzAKhEo/XX2EGKREWMJX4sBqqxEzi5KcnbBB2ksTpjg9MIDaLgKrEyxlfGUFs XgFriTmXZ7JCrPrDLLFi538WkASngI3EgWXvwYoYBcQkvp9awwSxS1zi1pP5TBAfCEgs2XOe GcIWlXj5+B8riC0qoCex4cRtdoi4ksSW3i1QvVoSX37sY4OwrSX2LNzLDmErSkzpfsgOcZCg xMmZT1gmAH2NZN0sJO2zkLTPQtI+C0n7AkbWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB MXlwy2/dHYyrXzseYhTgYFTi4WX0V48WYk0sK67MPcQowcGsJMKrLgMU4k1JrKxKLcqPLyrN SS0+xCjNwaIkzqu3ak+UkEB6YklqdmpqQWoRTJaJg1OqgTFFbYVCv9Obmd+VhEJ+Nh9tn/Hs 61Np/8A3MSuuTmx5bexUdP+/X71UT5znDzWVKenTJutZMvvy5fX66XmmqYtesprt19Xmdlbl tYxpqX+P5Drtxr5cU5MbltkX4rXKd1zdtEPV83yg0wP/3fZbJXV2LZ26nDXGTLFW5dSpuPPq 9RnJz/W/KbEUZyQaajEXFScCAOMBRc3FAgAA Archived-At: Subject: Re: [sipcore] Draft new version: sip-push-13 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 07:51:45 -0000 Q2FuIHdlIHBsZWFzZSBtb3ZlIHRoZSBkcmFmdCBmb3J3YXJkIG5vdz8NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KT24gMDQvMDYvMTggMTE6MjEsICJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+SGksDQo+DQo+SXQgaXMgbm93 IDIgd2Vla3Mgc2luY2UgSSBzZW50IG15IHJlcGx5Lg0KPg0KPkmp9mQgcmVhbGx5IGxpa2UgdG8g bW92ZSB0aGUgZG9jdW1lbnQgZm9yd2FyZC4NCj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+ DQo+DQo+DQo+T24gMjEvMDUvMTggMTA6MDEsICJzaXBjb3JlIG9uIGJlaGFsZiBvZiBDaHJpc3Rl ciBIb2xtYmVyZyINCj48c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+d3JvdGU6DQo+DQo+PkhpLA0KPj4NCj4+Pj4g SSBzdWdnZXN0IHRvIHJlbW92ZSB0aGUgc2Vjb25kIHBhcmFncmFwaCwgdGFsa2luZyBhYm91dCBt YWludGFpbmluZw0KPj4+PiBjb25uZWN0aW9ucyB3aXRoIGtlZXAtYWxpdmVzLiBXaWxsIHRoYXQg bWFrZSB0aGluZ3MgbW9yZSBjbGVhcj8NCj4+Pg0KPj4+IE1heWJlIEkgc2hvdWxkIHN0YXRlIHRo aXMgZGlmZmVyZW50bHkuICBZb3UgaGF2ZSBhbiBhbXBsZSBwcm9ibGVtDQo+Pj5zdGF0ZW1lbnQs IGJ1dCB3aGF0IHlvdSBkb24ndA0KPj4+IGhhdmUgaXMgYSAqc29sdXRpb24qIHN0YXRlbWVudC4g IFRoYXQgaXMsIGFuIGV4cGxhbmF0aW9uIG9mIHRoZSBtb2RlbA0KPj4+eW91IGFyZSB1c2luZyB0 byBhZGRyZXNzIHRoYXQgcHJvYmxlbS4NCj4+DQo+PkRvZXNuJ3QgdGhlIDR0aCBwYXJhZ3JhcGgg b2YgdGhlIEludHJvZHVjdGlvbiBhZGRyZXNzIHRoYXQ/DQo+Pg0KPj4+Pj4+IFRoZSBwcmltYXJ5 IG1lY2hhbmlzbSBpbiB0aGlzIGRvY3VtZW50IGlzIGFuIGF1Z21lbnRhdGlvbiBvZiBVQQ0KPj4+ Pj4+IGNvbnRhY3QgZGV0YWlscy4gSWYgeW91IHRoaW5rIG9mIGl0IHRoYXQgd2F5LCB0aGUgbGFj ayBvZg0KPj4+Pj4+cmVhY2hhYmlsaXR5IGlzIHRoZQ0KPj4+Pj4+IGV4Y2VwdGlvbmFsIGNvbmRp dGlvbi4NCj4+Pj4+IFRoZSBwcmltYXJ5IG1lY2hhbmlzbSBpcyB0byB3YWtlIHVwIHN1c3BlbmRl ZCBVQXMsIGluIG9yZGVyIHRvDQo+Pj4+PiBtYWludGFpbiByZWdpc3RyYXRpb25zIGFuZCBwcm92 aWRlIHJlYWNoYWJpbGl0eS4gVGhhdCB3YXMgdGhlDQo+Pj4+Pm9yaWdpbmFsIHVzZS1jYXNlIHRo YXQNCj4+Pj4+IHRyaWdnZXJlZCB0aGUgd2hvbGUgZG9jdW1lbnQuDQo+Pj4+DQo+Pj4+IFRoZSBw b3NzaWJpbGl0eSB0byBpbmRpY2F0ZSB0aGF0IGEgVUEgaXMgYWJsZSB0byBtYWludGFpbg0KPj4+ PnJlZ2lzdHJhdGlvbnMsDQo+Pj4+IGJ1dCBzdGlsbCB3YW50IHRvIHJlY2VpdmUgcHVzaCBub3Rp ZmljYXRpb25zIGZvciBpbmNvbWluZyBjYWxscywgd2FzDQo+Pj4+YWRkZWQgbGF0ZXIuDQo+Pj4N Cj4+PiBIb3cgdGhlIGRvY3VtZW50IGdvdCB0byB3aGVyZSBpdCBpcyBkb2Vzbid0IG1hdHRlciBz byBtdWNoIGFzIHdoZXJlIGl0DQo+Pj5pcyBub3cuDQo+Pg0KPj5JbiBteSBvcGluaW9uIGl0IGlz IHN0aWxsIHRoZSBtYWluIHVzZS1jYXNlLCBhbmQgSSB0aGluayB3ZSBzaGFsbCBrZWVwIGl0DQo+ PnRoYXQgd2F5OiB0aGUgZGVmYXVsdCBpcyB0aGF0IHRoZSBVQSBjYW4gbm90IGF3YWtlICwgYW5k IGFueSBleGNlcHRpb24NCj4+Y2FuIHRoZW4gYmUgZXhwbGljaXRseSBzaWduYWxsZWQuDQo+Pg0K Pj4+PiBUaGUgcHVycG9zZSBpcyB0aGF0LCBpZiB0aGUgVUEgaGFzIGluZGljYXRlZCB0aGF0IGl0 IGlzIGFibGUgdG8NCj4+Pj5tYWludGFpbiB0aGUgcmVnaXN0cmF0aW9uLCBidXQgZm9yIHdoYXRl dmVyIHJlYXNvbg0KPj4+PiBkb2VzIG5vdCBzZW5kIGEgcmUtcmVnaXN0cmF0aW9uLCB0aGUgcHJv eHkgY2FuIHN0aWxsIHRyaWdnZXIgYSBwdXNoDQo+Pj4+bm90aWZpY2F0aW9uIHByaW9yIHRvIHJl Z2lzdHJhdGlvbiBleHBpcmF0aW9uLg0KPj4+DQo+Pj4gWWVzLCB0aGF0IGlzIGNsZWFyLg0KPj4+ DQo+Pj4+IERvIHlvdSB3YW50IHRvIHJlbW92ZSB0aGF0IGZlYXR1cmUsIGFuZCBhc3N1bWUgdGhh dCBVQXMgdGhhdCBoYXZlDQo+Pj4+aW5kaWNhdGVkIHRoYXQgdGhleSBhcmUgYWJsZSB0byBtYWlu dGFpbiB0aGUNCj4+Pj4gcmVnaXN0cmF0aW9uIHdpbGwgYWN0dWFsbHkgZG8gaXQgKGFuZCwgaWYg dGhleSBkb24ndCwgdGhlIHJlZ2lzdHJhdGlvbg0KPj4+PndpbGwgZXhwaXJlKT8NCj4+Pg0KPj4+ IEknbSBzdWdnZXN0aW5nIHRoYXQgLSB3aGVuIGZyYW1lZCBhcyBhIG1lY2hhbmlzbSB0byBlbnN1 cmUgY29udGludW91cw0KPj4+cmVhY2hhYmlsaXR5LCBpdCBpcyBiZXR0ZXIgdG8gbWFrZSB0aGUN Cj4+PiB0aW1lIHJlbGF0aXZlIHRvIHRoZSB0aW1lIG9mIHJlZ2lzdHJhdGlvbiByYXRoZXIgdGhh biByZWxhdGl2ZSB0byB0aGUNCj4+PmVuZCBvZiByZWdpc3RyYXRpb24uDQo+Pg0KPj5Tbywgd2hh dCBkbyB5b3Ugc3VnZ2VzdD8NCj4+DQo+PlJlZ2FyZHMsDQo+Pg0KPj5DaHJpc3Rlcg0KPj4NCj4+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+c2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4+c2lwY29yZUBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4NCg0K From nobody Tue Jun 19 02:52:31 2018 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 672E71310DB; Tue, 19 Jun 2018 02:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 (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 JDAI7RtqdAzE; Tue, 19 Jun 2018 02:52:27 -0700 (PDT) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 D4C0B131156; Tue, 19 Jun 2018 02:52:20 -0700 (PDT) Received: by mail-ot0-x242.google.com with SMTP id p95-v6so21862122ota.5; Tue, 19 Jun 2018 02:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PiPi3xe/QPt8jbBbPy5KzAYp/Z1wBZBDKtkmwMiJo+E=; b=KRnrN2ddPgVbYulaAOvSspsRMw7iTNI+jkDJjfw9DhharnMlnQ6NuSaBk+o0hl/B7T aGr7sNOWz9iO1AB3n+sRw0Cip+DTa/ZDaFUhXoeNMr9JRvBs2deQe3tkYRDEYALJ2KIn PYusZeR/Sh43tSDrI6ezwFsKvw6Em+0JcSxYOSf7PyckfZlzY6eXL+wBplveT1ohk4CD R4IpYtN1rRW0LfGejCtqlhgaeX4L7jdshvHI0hJ0d4x+qaiE05kaqgKEKKs5jDNLRosB VhD5xO44zIHG8GuaEg8ndTvFszbXbVTlDj7r25vNTFPSCdGJqroZ3FIil56uK+0mEeCP 8MLA== 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=PiPi3xe/QPt8jbBbPy5KzAYp/Z1wBZBDKtkmwMiJo+E=; b=un3PPeoJcr0ENLJGGYTa6YI/dOD4QpShfvrBVx9w5kE8hTTLaz/I99XFjlIs6rAxEk zor6ZH+8OuGeMqs8lu+gxl8D4MAsS73dY+WGSHJyNEoK71V17vL15Xw8s44AnuTW3dM0 TWT3d9f7smH/M53wpWyS5TBe0yIyBPbEZ27uknji+pzvY40T0cpUlhC9kQM/haCJb7rA ywsdrFiyYC81r6/exHmpZdOEO7B3CZHcD1MMwrD+fWyx6U8RGE/vqI01vHNIiAZBWH6e vpI6ZowewMsen8Qo1WblNPRF3EKjprR18LLXuYbrqYL0ZgXYFOX7xHgj9HzBG3UDX+mD xGmQ== X-Gm-Message-State: APt69E1NDRBQC07ZRLqL8W03fxUCOzHsWFv/OIr8k/6l7WQXZciXt/nL TqqZExAqwiFDuzrH4U5nS6o7FD7YB7wU4SCtZog= X-Google-Smtp-Source: ADUXVKKFHT6tbPhot8zZVGcTeLWvMaEugJr4m90HghM9if6RBLi/wM/+UGinVRy4U/K/5PzQIcavUfdDKR6WhIVRhFE= X-Received: by 2002:a9d:e2a:: with SMTP id c39-v6mr10395597otc.241.1529401940119; Tue, 19 Jun 2018 02:52:20 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B72EF43F6@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72EF7FA7@ESESSMB109.ericsson.se> In-Reply-To: From: Martin Thomson Date: Tue, 19 Jun 2018 19:52:08 +1000 Message-ID: To: Christer Holmberg Cc: SIPCORE , sipcore-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Draft new version: sip-push-13 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 09:52:31 -0000 Do as you will. I apologize for not responding, it's clear that we're not speaking the same language, but it's not that important. On Mon, Jun 18, 2018 at 5:51 PM Christer Holmberg wrote: > > Can we please move the draft forward now? > > Regards, > > Christer > > On 04/06/18 11:21, "Christer Holmberg" > wrote: > > >Hi, > > > >It is now 2 weeks since I sent my reply. > > > >I=C2=B9d really like to move the document forward. > > > >Regards, > > > >Christer > > > > > > > >On 21/05/18 10:01, "sipcore on behalf of Christer Holmberg" > > > >wrote: > > > >>Hi, > >> > >>>> I suggest to remove the second paragraph, talking about maintaining > >>>> connections with keep-alives. Will that make things more clear? > >>> > >>> Maybe I should state this differently. You have an ample problem > >>>statement, but what you don't > >>> have is a *solution* statement. That is, an explanation of the model > >>>you are using to address that problem. > >> > >>Doesn't the 4th paragraph of the Introduction address that? > >> > >>>>>> The primary mechanism in this document is an augmentation of UA > >>>>>> contact details. If you think of it that way, the lack of > >>>>>>reachability is the > >>>>>> exceptional condition. > >>>>> The primary mechanism is to wake up suspended UAs, in order to > >>>>> maintain registrations and provide reachability. That was the > >>>>>original use-case that > >>>>> triggered the whole document. > >>>> > >>>> The possibility to indicate that a UA is able to maintain > >>>>registrations, > >>>> but still want to receive push notifications for incoming calls, was > >>>>added later. > >>> > >>> How the document got to where it is doesn't matter so much as where i= t > >>>is now. > >> > >>In my opinion it is still the main use-case, and I think we shall keep = it > >>that way: the default is that the UA can not awake , and any exception > >>can then be explicitly signalled. > >> > >>>> The purpose is that, if the UA has indicated that it is able to > >>>>maintain the registration, but for whatever reason > >>>> does not send a re-registration, the proxy can still trigger a push > >>>>notification prior to registration expiration. > >>> > >>> Yes, that is clear. > >>> > >>>> Do you want to remove that feature, and assume that UAs that have > >>>>indicated that they are able to maintain the > >>>> registration will actually do it (and, if they don't, the registrati= on > >>>>will expire)? > >>> > >>> I'm suggesting that - when framed as a mechanism to ensure continuous > >>>reachability, it is better to make the > >>> time relative to the time of registration rather than relative to the > >>>end of registration. > >> > >>So, what do you suggest? > >> > >>Regards, > >> > >>Christer > >> > >>_______________________________________________ > >>sipcore mailing list > >>sipcore@ietf.org > >>https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Wed Jun 27 14:14:55 2018 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 1CAB6130E34; Wed, 27 Jun 2018 14:14:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Rosen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Cc: br@brianrosen.net, Brian Rosen , sipcore@ietf.org, iesg-secretary@ietf.org, sipcore-chairs@ietf.org Message-ID: <153013409211.15378.1115327153051342096.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2018 14:14:52 -0700 Archived-At: Subject: [sipcore] Publication has been requested for draft-ietf-sipcore-sip-push-11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.26 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:14:53 -0000 Brian Rosen has requested publication of draft-ietf-sipcore-sip-push-11 as Proposed Standard on behalf of the SIPCORE working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/