[sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)
Magnus Westerlund via Datatracker <noreply@ietf.org> Thu, 23 April 2020 13:46 UTC
Return-Path: <noreply@ietf.org>
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 1824D3A07A2; Thu, 23 Apr 2020 06:46:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Magnus Westerlund via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney <mahoney@nostrum.com>, mahoney@nostrum.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <158764958890.26081.9155918989165894263@ietfa.amsl.com>
Date: Thu, 23 Apr 2020 06:46:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/jf41XquMUqMjSSh2vnf8YpnkuDs>
Subject: [sipcore] Magnus Westerlund's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 13:46:30 -0000
Magnus Westerlund has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think these resolution for this is rather straight forward, however the implications of one is going to break deployed implementations. 1. Section 4: This is rather straight forward to resolve but you do have a SIP syntax violation in these rules. challenge =/ ("Bearer" LWS bearer-cln *(COMMA bearer-cln)) bearer-cln = realm / scope / authz-server / error / auth-param authz-server = "authz_server" EQUAL authz-server-value authz-server-value = https-URI realm = <defined in RFC3261> auth-param = <defined in RFC3261> scope = <defined in RFC6749> error = <defined in RFC6749> https-URI = <defined in RFC7230> So RFC 3261 defines the Challenge construct as: challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge Where this extension needs to match the syntax of the other-challenge: other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) Where we need to look at: auth-param = auth-param-name EQUAL ( token / quoted-string ) Please note what is included in the "token" rule. token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) the allowed syntax for https-URI in RFC 7230 is: https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Which include both "/", "?" and "#" that are not allowed in token. Thus, the URI included in the authz-server-value MUST be converted into a quoted-string matching syntax rule. 2. In addition should not the "authz_server" be registered in the https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12 registry? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- An additional thing. Is SIP directly using the HTTP Authentication Schemes IANA registry (https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#authschemes) or does it have its own tucked away somewhere? And if it is the former, should its references for the "bearer" add this RFC as a reference?
- [sipcore] Magnus Westerlund's Discuss on draft-ie… Magnus Westerlund via Datatracker
- Re: [sipcore] Magnus Westerlund's Discuss on draf… Christer Holmberg