[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?