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

From: [email-masked] (Dale R. Worley)
Date: Fri, 17 May 2019 08:20:06 -0400

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 May 2019 13:42:41 -0400

Thanks Dale!

See my replies below.

Regards,
 Rifaat

> from the registry at this time and authorizes those algorithms.
Yes, that is correct.
I will try to make it clearer; feel free to suggest a text, if you want.

> .... and specifies a priority for each algorithm."  But I cannot find the
> word
It is specified in section 3.7:
https://tools.ietf.org/html/rfc7616#section-3.7

But I think the wording in the draft is confusing; I will try to clarify
that.

> Dale

Ok

> No I do not :)
I will fix that.

> to the registry, ipso facto it becomes authorized for use in SIP.

Ok

> Similarly, you want this to be late-binding:

Ok.

>    Authentication" registry defined by [RFC7616].

I will clarify it.

> Ok

> Ok

>    may be used in SIP digest authentication.

Ok

>
> [END]
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 18 May 2019 17:50:45 +0000

Hi,

Regarding “authorized to use”, aren’t SIP clients allowed to use algorithms that aren’t in the registry?

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Saturday, 18 May 2019 at 18.43
To: Dale Worley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Resend: WGLC: draft-ietf-sipcore-digest-scheme

Thanks Dale!

See my replies below.

Regards,
 Rifaat

On Fri, May 17, 2019 at 8:20 AM Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
[resend -- for some reason, this didn't get through to the mailing list]

Yes, that is correct.

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?

But I think the wording in the draft is confusing; I will try to clarify that.

Dale

----------

   Abstract

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

Ok

   1.  Introduction

Ok

Ok.

--

   2.1.  Hash Algorithms

I will clarify it.

   5.  IANA Considerations

[END]

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 19 May 2019 21:15:54 -0400

> But I think the wording in the draft is confusing; I will try to clarify

Looking at section 2.1 of draft-ietf-sipcore-digest-scheme-02, it reads

   2.1.  Hash Algorithms

   [RFC3261] specifies only one algorithm, MD5, which is used by
   default.  This document extends [RFC3261] to allow use of any
   registered algorithm.

   The priority of the algorithm defines its usage preference.  UAs
   SHOULD prefer algorithms with higher priorities.

   Note that [RFC7616] defines a -sess variant for each algorithm; the
   -sess variants are not used with SIP.

A nit is that the registry is named "Hash Algorithms for HTTP Digest
Authentication".

RFC 7616 is not referenced here as establishing the priorities, but
rather the IANA registry is referenced.  The critical text is from RFC
7616, which establishes the preference ordering of algorithms not
globally, but based on the authentication challenge in a particular
challenge/response transaction:

   The server MUST
   add these challenges to the response in order of preference, starting
   with the most preferred algorithm, followed by the less preferred
   algorithm.
   [...]
   When the client receives the first challenge, it SHOULD use the first
   challenge it supports, unless a local policy dictates otherwise.

This suggests the wording could be improved along thse lines (changes
marked with "|"):

   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 "Hash Algorithms for HTTP Digest Authentication"
 | specifies the algorithms
 | that correspond to 'algorithm' values.

   [RFC3261] specifies only one algorithm, MD5, which is used by
   default.  This document extends [RFC3261] to allow use of any
   registered algorithm.

 | [RFC7616] specifies the usage preference when a response
 | contains multiple challenges specifying different algorithms.  That
 | specification is not changed by this document.

   Note that [RFC7616] defines a -sess variant for each algorithm; the
   -sess variants are not used with SIP.

And there is this issue:

> My impression is that the answer is Yes.

Perhaps I am being too fussy about this issue.  But I would like to
ensure that nobody mistakes the intention of this document.  I think
the following two wording changes would be more than enough to avoid
any problems:

   1.  Introduction

   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]) as it is updated from time to time.

   2.1.  Hash Algorithms

   [RFC3261] specifies only one algorithm, MD5, which is used by
   default.  This document extends [RFC3261] to allow use of any
 | algorithm that is registered at the time of use.

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 19 May 2019 22:48:52 -0400

Thanks Dale!

I liked your proposed changes; I will incorporate them into the next
version of the document.

Regards,
 Rifaat

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 20 May 2019 22:17:14 -0400

> I liked your proposed changes; I will incorporate them into the next

Though I did make a mistake -- RFC 7616 only applies to HTTP, so the
statement in draft-ietf-sipcore-digest-scheme-02 section 2.3 para 2 is
not redundant, even though it appears to be repeating RFC 7616.  Therefore...

>>  | specification is not changed by this document.

The above sentence is incorrect.  I intended it to replace the current
para 3 of the section, and it would be good to replace para 3 with
something correct that clarifies the same question.  Perhaps something
like

   A UAS prioritizes which algorithm to use based on the ordering of the
   challenge headers in the response it is processing.  That process is
   specified in section 2.3 and parallels the process used in HTTP
   specified by [RFC7616].

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 25 May 2019 06:35:51 -0400

Thanks Dale,

I will replace the 3 paragraph of section 2.1 with your proposed text.

Regards,
 Rifaat