[sipcore] Resend: WGLC: draft-ietf-sipcore-digest-scheme

worley@ariadne.com (Dale R. Worley) Fri, 17 May 2019 12:20 UTC

Return-Path: <worley@alum.mit.edu>
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 3A27A120359 for <sipcore@ietfa.amsl.com>; Fri, 17 May 2019 05:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjJ1ez5j3zh4 for <sipcore@ietfa.amsl.com>; Fri, 17 May 2019 05:20:10 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 BA1ED120357 for <sipcore@ietf.org>; Fri, 17 May 2019 05:20:10 -0700 (PDT)
Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id RbjYhIIt3KkkfRbqLhecX6; Fri, 17 May 2019 12:20:09 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1558095609; bh=sLnJlBWJ19O2nEpMbEgLVTnJvAEZ6u2YZz52sS/BKzs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=A4RDI0F7bky5qip82WxfyRntZcHkUBwqSG8UspICQwdNRHnA/R7fMGSjtPyO3Iip9 UUfj3S3QxBLUNmFOWA8ApQ6OMTA29ZrJeHIWqu9QFaDkFzfVPdoTwFauq5vfETGA2d zNrtxM48tdFM5GfnI79pjHZgBtX+6wqSl2g5IQ19Vl38wRkpXdNF7iw+UgU3L2UuKU XauZyogUQPLVwNkQMsRSWR7HXFaQcbYDxumhf27aMnED689HubxwNS7BPWB1IaYZam XuJZxtt2l62F21fsm1X7jfq0LVx/CdY4LoPLiCGRYS+vD0GOiMnChpMRWgcuc0OffH U9Wurj+oTAQxQ==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-20v.sys.comcast.net with ESMTPA id RbqKhlDv45DQoRbqLhpmgf; Fri, 17 May 2019 12:20:09 +0000
X-Xfinity-VMeta: sc=0;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x4HCK79Y018210 for <sipcore@ietf.org>; Fri, 17 May 2019 08:20:07 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x4HCK6r3018203; Fri, 17 May 2019 08:20:06 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: sipcore@ietf.org
Sender: worley@ariadne.com
Date: Fri, 17 May 2019 08:20:06 -0400
Message-ID: <87bm01mfwp.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/A3ITIUqn3jwO1tPQSXnBkmCH9xA>
Subject: [sipcore] Resend: WGLC: draft-ietf-sipcore-digest-scheme
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 17 May 2019 12:20:12 -0000

[resend -- for some reason, this didn't get through to the mailing list]

Sorry for being late with this.  Below are my detailed comments, but
generally the significant ones fall into two groups:

1) When is the binding time of "the contents of the Hash Algorithms for
HTTP Digest Authentication registry"?  That is, if a new algorithm is
added to the registry, does it automatically become authorized for use
in SIP?

My impression is that the answer is Yes.  But if so, the wording should
be updated in several places, because it seems to me that the current
wording tends to imply that this document copies the list of algorithms
from the registry at this time and authorizes those algorithms.

2) There is discussion "The IANA registry ... specifies the algorithms
... and specifies a priority for each algorithm."  But I cannot find the word
priority in the registry, nor in the sole reference in the registry, RFC
7616.  Can you update this to point to whatever defines the priority?

Dale

----------

   Abstract

   This document updates the Digest Access Authentication scheme used by
   the Session Initiation Protocol (SIP) to add support for secure
   digest algorithms to replace the broken MD5 algorithm.

Might be worth specifying what the "secure digest algorithms" are.

   1.  Introduction

   [...] which by default uses MD5 as
   the default algorithm.

Do you want "default" twice in this phrase?

   This document updates the Digest Access Authentication scheme used by
   SIP to support the list of digest algorithms defined in the "Hash
   Algorithms for HTTP Digest Authentication" registry defined by
   [RFC7616].

This should be phrased "to support the algorithms defined in the "Hash
Algorithms for HTTP Digest Authentication" registry".  This phrasing
gives a late-binding interpretation, that is, if an algorithm is added
to the registry, ipso facto it becomes authorized for use in SIP.

   2.  The SIP Digest Authentication Scheme

   This section describes the modifications to the operation of the
   Digest mechanism as specified in [RFC3261] in order to support the
   SHA- 256 and SHA-512/256 algorithms as described in [RFC7616], and
   also to require support for the "qop" option."

Similarly, you want this to be late-binding:

   This section describes the modifications to the operation of the
   Digest mechanism as specified in [RFC3261] in order to support the
   algorithms defined in the "Hash Algorithms for HTTP Digest
   Authentication" registry defined by [RFC7616].
	      
--

   2.1.  Hash Algorithms

   The Digest scheme has an 'algorithm' parameter that specifies the
   algorithm to be used to compute the digest of the response.  The IANA
   registry named "HTTP Digest Hash Algorithms" specifies the algorithms
   that correspond to 'algorithm' values, and specifies a priority for
   each algorithm.

I don't see a priority specified in the registry.

   3.  Augmented BNF for the SIP Protocol

   The number of hex digits must be specified by the specification of
   the algorithm used.

It might be better to say that the number of hex digits is implied by
the length of the value of the algorithm used, since the specification
of an algorithm might explicitly define its output as a sequence of
hex digits.

   It extends the algorithm parameter as follows to allow for SHA2
   algorithms to be used:

Or indeed, any algorithm in the registry.

   5.  IANA Considerations

   This document will use the algorithms defined in that
   registry.

Again is the question of binding time:

   This document specifies that algorithms defined in that registry
   may be used in SIP digest authentication.

[END]