Subject: [sipcore] ABNF: request-digest: 32 characters, only 32 characters and nothing but 32 characters?

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Feb 2018 10:58:07 +0000

Hi,

In RFC 3261, the ABNF for the Authorization header field is:

Authorization     =  "Authorization" HCOLON credentials
credentials       =  ("Digest" LWS digest-response)
                     / other-response
digest-response   =  dig-resp *(COMMA dig-resp)
dig-resp          =  username / realm / nonce / digest-uri
                      / dresponse / algorithm / cnonce
                      / opaque / message-qop
                      / nonce-count / auth-paramŠ
dresponse         =  "response" EQUAL request-digest
request-digest    =  LDQUOT 32LHEX RDQUOT

Šsimilarly, the ABNF for the Proxy-Authori<ation header field is:

Proxy-Authorization  =  "Proxy-Authorization" HCOLON credentials

When looking at the examples with response parameters, only the example in
Section 22.22 contains 32 LHEX characters:

	response=³7587245234b3434cc3412213e5f113a5432² (Section 20.7)
	response=³245f23415f11432b3434341c022² (Section 20.28)
	response=³6629fae49393a05397450978507c4ef1² (Section 22.22)

This has caused confusion on whether one is required to use 32 characters,
or whether one could e.g., use more or less - or even an empty value (no
characters).

There *IS* an errata about this, which fixes the example in section 20.7:
https://www.rfc-editor.org/errata_search.php?rfc=3261&rec_status=15&present
ation=table

We would need one also for section 20.28.

Also, the status of the errata is 'Held for Document Update¹. I think we
should verify it (and possibly others in HfDU state too), because I assume
we are not going to update 3261 anytime soon.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 13 Feb 2018 23:07:01 -0500

> In RFC 3261, the ABNF for the Authorization header field is:

I suspect this has been implicitly updated by the later versions of HTTP
Digest.  It looks like RFC 7616 is the central piece of that, but I
can't find the reference to the revised BNF.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Feb 2018 08:37:06 +0000

Hi,

>can't find the reference to the revised BNF.

I can¹t find the revised BNF either, but I find the following text in 7616:

        "If the MD5 algorithm is used to calculate the digest, then the
MD5 digest
         will be represented as 32 hexadecimal characters, while SHA-256
and 
         SHA-512/256 are represented as 64 hexadecimal characters."

So, to me it seems like we need to update the ABNF in 3261.

OLD:

NEW:

    request-digest    =  LDQUOT 32*LHEX RDQUOT

Šor something like that.

I don¹t think we need to update section 26.4.1 (HTTP Digest).

There are a number of reference to RFC 2617, but I haven¹t checked whether
the referenced parts have changed in RFC 7616.

So, if we only want to update the ABNF, I guess that can be done with an
errata. If we want to make a wider 2617-to-7616 update, I guess we¹d need
a draft for that.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 14 Feb 2018 21:42:25 -0500

Christer Holmberg <[email-masked]> writes:
> I can't find the revised BNF either, but I find the following text in 7616:
> [...]
>

First off, can Rifaat point us to the BNF?

In regard to updating 3261, why don't we have it properly point to 7616
and its successors, so we don't have to have to keep revising 3261 to
track 7616?

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2018 06:41:49 +0000

Hi,

>and its successors, so we don't have to have to keep revising 3261 to

Well, assuming that is possible to begin with, it would also require an
update to 3261, wouldn¹t it? :)

But, regarding the syntax, I don¹t understand why we have to limit the
number of characters (32, 64, or whatever). Just allow an unlimited number
of characters, and it will be future proof.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Feb 2018 11:33:37 +0000

Hi,

I realised that Rifaat’s draft actually updates the ABNF (by removing the
32 characters restriction), so we wouldn’t need anything in addition to
that.

I know the draft has been discussed in the past. I don’t remember what the
outcome has been, but my suggestion would be to actually adopt the draft.

Regards,

Christer

On 15/02/18 08:41, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 15 Feb 2018 11:01:49 -0500

Dale,

The HTTP Authorization header is defined in RFC7235:
https://tools.ietf.org/html/rfc7235

As Christer mentioned, the SIP Digest draft has updated the SIP ABNF in
section 3:
https://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-06#section-3

Regards,
 Rifaat

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 15 Feb 2018 21:07:13 -0500

Christer Holmberg <[email-masked]> writes:
> I realised that Rifaat's draft actually updates the ABNF (by removing the
> 32 characters restriction), so we wouldn't need anything in addition to
> that.

I was going to say, What is the name of the draft?, but it's
draft-yusef-sipcore-digest-scheme, which is dated last September, which
is probably why I remember it.

It not only updates the ABNF in RFC 3261, it also connects it with RFC
7611.

---> So, I call for adoption of draft-yusef-sipcore-digest-scheme as a
WG draft.

Dale