Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Nov 2019 07:09:04 +0000

Hi,

>I do not have a strong opinion here.
>
>Anybody has an opinion or thoughts about adding such a text?

In addition we’d obviously also change the ABNF back, to allow empty values.

Regards,

Christer

On Thu, Oct 31, 2019 at 1:50 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Something like this:

“In some cases a UAC needs to include an Authorization header field in a request before it has received a challenge, in order to provide user information (using the ‘userinfo’ header field parameter) that is needed in order to create the challenge. An example of such case is when the HTTP Digest Authentication Using AKA mechanism (RFC3310) (RFC4169) is used. In such case the Authorization header field would typically not contain a ‘response’ header field parameter before a challenge response is provided. However, for the IP Multimedia Subsystem (IMS) it has been specified that the Authorization header field in such case does contain a  ‘response’ header field parameter, with an empty value (empty string). For that reason the modified request-digest ABNF allows such empty values.”

Regards,

Christer

From: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 31 October 2019 at 19.22
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Alexey Melnikov <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

Can you propose some text?

Thanks,
 Rifaat

On Thu, Oct 31, 2019 at 11:44 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Perhaps we could add some text about the IMS use-case, in order to explain the empty value?

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>>
Date: Thursday, 31 October 2019 at 15.52
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Alexey Melnikov <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

Hi,

>This IMS behavior would have been in violation of RFC3261 which specified exactly 32 Hex characters.
>So, this change should not make much of a difference in this case.

In reality it probably doesn’t make a difference, but it would make the IMS procedures “aligned” with the IETF spec.

Regards,

Christer

On Thu, Oct 31, 2019 at 9:37 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

The reason for the empty value comes from IMS and AKA, where you need to include the user id already in the initial REGISTER request (this seems to be missing from RFC 3310, but that’s a separate topic) in order for the server to create the challenge,  meaning that in the initial REGISTER request you include an Authorization header field with the username parameter carrying the IMS private user identity, the realm parameter and the uri parameter. At this point you obviously don’t yet have the response, so in IMS it is specified that the response parameter is inserted with an empty value.

WHY it was specified that way (instead of simply not including the response parameter) I don’t know, but I do know that it has been implemented and deployed that way for many years.

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 31 October 2019 at 15.20
To: Alexey Melnikov <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

Done.

On Thu, Oct 31, 2019 at 9:13 AM Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Oct 31, 2019, at 1:11 PM, Rifaat Shekh-Yusef wrote:
Hi Alexey,

I am fine with Paul's suggestion.
Are you ok with "32*LHEX"?
Yes!

Thank you,
Alexey

Regards,
 Rfaat

On Thu, Oct 31, 2019 at 7:22 AM Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rifaat,

On Wed, Oct 30, 2019, at 9:50 PM, Rifaat Shekh-Yusef wrote:
Thanks Alexey!

I am fine with the first two comments, and will fix these in the coming version of the document.

I am not sure I follow the 3rd one. Why do you see the need for a minimum number of hex digits?
You do say that the number of hex digits match the hash lenght, so it is probably Ok. However empty value is never valid (and I am worried it might hit some boundary condition bug in implementations), so prohibiting it in ABNF would be the best.

Best Regards,
Alexey

Regards,
 Rifaat

On Wed, Oct 30, 2019 at 1:16 PM Alexey Melnikov via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Alexey Melnikov has entered the following ballot position for
draft-ietf-sipcore-digest-scheme-12: No Objection

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-digest-scheme/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am agreeing with Alissa's DISCUSS.

Also, I have a few comments of my own:

1) Last para of Section 2.1:

2.1.  Hash Algorithms

   A UAS prioritizes which algorithm to use based on the ordering of the
   challenge header fields in the response it is preparing.

This looks either wrong or confusing to me. I think you are just saying here
that the order is decided by the server at this point.

   That
   process is specified in section 2.3 and parallels the process used in
   HTTP specified by [RFC7616].

So based on the above, my suggested replacement for both sentences:

   A UAS prioritizes which algorithm to use based on its policy,
   which is specified in section 2.3 and parallels the process used in
   HTTP specified by [RFC7616].

2) Last para of Section 2.4:

   If the UAC cannot respond to any of the challenges in the response,
   then it SHOULD abandon attempts to send the request unless a local
   policy dictates otherwise.

Is trying other non Digest algorithms covered by "SHOULD abandon"?
If yes, maybe you should make this clearer.

   For example, if the UAC does not have
   credentials or has stale credentials for any of the realms, the UAC
   will abandon the request.

3) In Section 2.7:

      request-digest = LDQUOT *LHEX RDQUOT

This now allows empty value. I suggest you specify a minimum number of hex
digits allowed in the ABNF. Or at least change "*LHEX" to "2*LHEX".

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 1 Nov 2019 10:10:01 +0000

> On 1 Nov 2019, at 07:09, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>  

If the ABNF is changed back for this, I think some extra text would be useful.
>  
> Regards,
>  
> Christer
>  
>  
>  
>  
> On Thu, Oct 31, 2019 at 1:50 PM Christer Holmberg <[email-masked]> wrote:
> Something like this:
>  
> From: Rifaat Shekh-Yusef <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: Christer Holmberg <christer.holmberg=[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Alexey Melnikov <[email-masked]>
> On Thu, Oct 31, 2019 at 11:44 AM Christer Holmberg <[email-masked]> wrote:
> Hi,
>  
> From: sipcore <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
> To: Rifaat Shekh-Yusef <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Alexey Melnikov <[email-masked]>
> On Thu, Oct 31, 2019 at 9:37 AM Christer Holmberg <[email-masked]> wrote:
>  
> Hi,
>  
> From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
> To: Alexey Melnikov <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> On Thu, Oct 31, 2019 at 9:13 AM Alexey Melnikov <[email-masked]> wrote:
> On Thu, Oct 31, 2019 at 7:22 AM Alexey Melnikov <[email-masked]> wrote:
>  
> Hi Rifaat,
>  
> On Wed, Oct 30, 2019 at 1:16 PM Alexey Melnikov via Datatracker <[email-masked]> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Nov 2019 11:50:39 +0000

Hi,

>If the ABNF is changed back for this, I think some extra text would be useful.

Did you see my suggested text below? Or, do you think that more is needed?  

Regards,
 
Christer

 
On Thu, Oct 31, 2019 at 1:50 PM Christer Holmberg <mailto:[email-masked]> wrote:
Something like this:

Regards,
 
Christer

From: Rifaat Shekh-Yusef <mailto:[email-masked]>
Date: Thursday, 31 October 2019 at 19.22
To: Christer Holmberg <mailto:[email-masked]>
Cc: Christer Holmberg <christer.holmberg=mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, Alexey Melnikov <mailto:[email-masked]>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

Thanks,
 Rifaat

On Thu, Oct 31, 2019 at 11:44 AM Christer Holmberg <mailto:[email-masked]> wrote:
Hi,

Regards,
 
Christer
 
From: sipcore <mailto:[email-masked]> on behalf of Christer Holmberg <christer.holmberg=mailto:[email-masked]>
Date: Thursday, 31 October 2019 at 15.52
To: Rifaat Shekh-Yusef <mailto:[email-masked]>
Cc: "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, Alexey Melnikov <mailto:[email-masked]>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
 
Hi,

 
Regards,
 
Christer

 
On Thu, Oct 31, 2019 at 9:37 AM Christer Holmberg <mailto:[email-masked]> wrote:
 
Hi,

 
Regards,
 
Christer

From: sipcore <mailto:[email-masked]> on behalf of Rifaat Shekh-Yusef <mailto:[email-masked]>
Date: Thursday, 31 October 2019 at 15.20
To: Alexey Melnikov <mailto:[email-masked]>
Cc: "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>, "mailto:[email-masked]" <mailto:[email-masked]>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
 
Done.
 
On Thu, Oct 31, 2019 at 9:13 AM Alexey Melnikov <mailto:[email-masked]> wrote:
On Thu, Oct 31, 2019, at 1:11 PM, Rifaat Shekh-Yusef wrote:
Hi Alexey,

Thank you,
Alexey
 
Regards,
 Rfaat

On Thu, Oct 31, 2019 at 7:22 AM Alexey Melnikov <mailto:[email-masked]> wrote:
 
Hi Rifaat,

 
 
Best Regards,
Alexey
 
Regards,
 Rifaat

On Wed, Oct 30, 2019 at 1:16 PM Alexey Melnikov via Datatracker <mailto:[email-masked]> wrote:
Alexey Melnikov has entered the following ballot position for
draft-ietf-sipcore-digest-scheme-12: No Objection

 

 
 
2.1.  Hash Algorithms

 
   That

 

 
 
3) In Section 2.7:

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 3 Nov 2019 05:01:09 -0500

Alexey, Christer,

How about the following:
1. Change the ABNF to "request-digest = LDQUOT *LHEX RDQUOT"
2. Change the text below it to say "The number of hex digits is implied by
the length of the value of the algorithm used, with the minimum size of 32.
A parameter with an empty value (empty string) is allowed when the
algorithm is not specified.""

Regards,
 Rifaat

On Fri, Nov 1, 2019 at 6:10 AM Alexey Melnikov <[email-masked]>
wrote:

> “In some cases a UAC needs to include an Authorization header field in a
> request before it has received a challenge, in order to provide user
> information (using the ‘userinfo’ header field parameter) that is needed in
> order to create the challenge. An example of such case is when the HTTP
> Digest Authentication Using AKA mechanism (RFC3310) (RFC4169) is used. In
> such case the Authorization header field would typically not contain a
> ‘response’ header field parameter before a challenge response is provided.
> However, for the IP Multimedia Subsystem (IMS) it has been specified that
> the Authorization header field in such case does contain a  ‘response’
> header field parameter, with an empty value (empty string). For that reason
> the modified request-digest ABNF allows such empty values.”
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From: *Rifaat Shekh-Yusef <[email-masked]>
> *Date: *Thursday, 31 October 2019 at 19.22
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Christer Holmberg <christer.holmberg=[email-masked]>,
> "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, Alexey Melnikov <
> [email-masked]>
> *Subject: *Re: [sipcore] Alexey Melnikov's No Objection on
> draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Christer Holmberg
> <christer.holmberg=[email-masked]>
> *Date: *Thursday, 31 October 2019 at 15.52
> *To: *Rifaat Shekh-Yusef <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, Alexey Melnikov <
> [email-masked]>
> *Subject: *Re: [sipcore] Alexey Melnikov's No Objection on
> draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
>
>
>
> Hi,
>
>
>
> In reality it probably doesn’t make a difference, but it would make the
> IMS procedures “aligned” with the IETF spec.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
> The reason for the empty value comes from IMS and AKA, where you need to
> include the user id already in the initial REGISTER request (this seems to
> be missing from RFC 3310, but that’s a separate topic) in order for the
> server to create the challenge,  meaning that in the initial REGISTER
> request you include an Authorization header field with the username
> parameter carrying the IMS private user identity, the realm parameter and
> the uri parameter. At this point you obviously don’t yet have the response,
> so in IMS it is specified that the response parameter is inserted with an
> empty value.
>
>
>
> WHY it was specified that way (instead of simply not including the
> response parameter) I don’t know, but I do know that it has been
> implemented and deployed that way for many years.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Rifaat
> Shekh-Yusef <[email-masked]>
> *Date: *Thursday, 31 October 2019 at 15.20
> *To: *Alexey Melnikov <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] Alexey Melnikov's No Objection on
> draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
>
>
>
> Done.
>
>
>
> You do say that the number of hex digits match the hash lenght, so it is
> probably Ok. However empty value is never valid (and I am worried it might
> hit some boundary condition bug in implementations), so prohibiting it in
> ABNF would be the best.
>
>
>
> Best Regards,
>
> Alexey
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 3 Nov 2019 18:53:52 +0000

Hi,

I am fine with the suggestion, but instead of talking about an algorithm not being provided I would like to talk about a *challenge response* not being provided.

Regards,

Christer

________________________________
From: Rifaat Shekh-Yusef <[email-masked]>
Sent: Sunday, November 3, 2019 12:01 PM
To: Alexey Melnikov <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; The IESG <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Alexey Melnikov's No Objection on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)

Alexey, Christer,

How about the following:
1. Change the ABNF to "request-digest = LDQUOT *LHEX RDQUOT"
2. Change the text below it to say "The number of hex digits is implied by the length of the value of the algorithm used, with the minimum size of 32. A parameter with an empty value (empty string) is allowed when the algorithm is not specified.""

Regards,
 Rifaat

On Fri, Nov 1, 2019 at 6:10 AM Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

On 1 Nov 2019, at 07:09, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

Something like this:

Regards,

Christer

Thanks,

 Rifaat

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Done.

Hi Alexey,

Yes!

Thank you,

Alexey

Regards,

 Rfaat

Hi Rifaat,

Thanks Alexey!

Best Regards,

Alexey

Regards,

 Rifaat

COMMENT:

2.1.  Hash Algorithms

   That

3) In Section 2.7:

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 3 Nov 2019 15:28:37 -0500

I am not sure I am following, What do you mean by "challenge response not
being provided"?

Regards,
 Rifaat

On Sun, Nov 3, 2019 at 1:53 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I am fine with the suggestion, but instead of talking about an algorithm
> not being provided I would like to talk about a *challenge response* not
> being provided.
>
> Regards,
>
> Christer
>
>
> ------------------------------
> *From:* Rifaat Shekh-Yusef <[email-masked]>
> *Sent:* Sunday, November 3, 2019 12:01 PM
> *To:* Alexey Melnikov <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>;
> [email-masked] <[email-masked]>;
> [email-masked] <
> [email-masked]>; The IESG <[email-masked]>;
> SIPCORE <[email-masked]>
> *Subject:* Re: [sipcore] Alexey Melnikov's No Objection on

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Nov 2019 07:57:56 +0000

Hi,

>I am not sure I am following, What do you mean by "challenge response not being provided"?

The response to the challenge provided by the server.

If you think it is unclear, maybe something like:

“A parameter with an empty value (empty string) is allowed when the UAC has not yet received a challenge."

Regards,

Christer

On Sun, Nov 3, 2019 at 1:53 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; SIPCORE <[email-masked]<mailto:[email-masked]>>

Alexey, Christer,

How about the following:

Regards,
 Rifaat

Hi,

Regards,

Christer

Something like this:

Regards,

Christer

Thanks,

 Rifaat

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Done.

Hi Alexey,

Yes!

Thank you,

Alexey

Regards,

 Rfaat

Hi Rifaat,

Thanks Alexey!

Best Regards,

Alexey

Regards,

 Rifaat

COMMENT:

2.1.  Hash Algorithms

   That

3) In Section 2.7:

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 4 Nov 2019 07:53:54 -0500

I see. I am fine with this.

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 4 Nov 2019 09:29:09 -0500

> has not yet received a challenge."

I'm confused. When is this behavior appropriate and what does it mean?

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> On Sun, Nov 3, 2019 at 1:53 PM Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi,
> 
>     I am fine with the suggestion, but instead of talking about an
>     algorithm not being provided I would like to talk about a *challenge
>     response* not being provided.
> 
>     Regards,
> 
>     Christer
> 
>     ------------------------------------------------------------------------
> 
>     *From:*Rifaat Shekh-Yusef <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Alexey Melnikov <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>;
>     [email-masked]
>     <mailto:[email-masked]>
>     <[email-masked]
>     <mailto:[email-masked]>>; The IESG
>     <[email-masked] <mailto:[email-masked]>>; SIPCORE <[email-masked]
>     <mailto:[email-masked]>>
>     2. Change the text below it to say "The number of hex digits is
>     implied by the length of the value of the algorithm used, with the
>     minimum size of 32. A parameter with an empty value (empty string)
>     is allowed when the algorithm is not specified.""
> 
>     Regards,
> 
>       Rifaat
> 
>     On Fri, Nov 1, 2019 at 6:10 AM Alexey Melnikov
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         On 1 Nov 2019, at 07:09, Christer Holmberg
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Hi,
> 
>             On Thu, Oct 31, 2019 at 1:50 PM Christer Holmberg
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>                 Something like this:
> 
>                 “In some cases a UAC needs to include an Authorization
>                 header field in a request before it has received a
>                 challenge, in order to provide user information (using
>                 the ‘userinfo’ header field parameter) that is needed in
>                 order to create the challenge. An example of such case
>                 is when the HTTP Digest Authentication Using AKA
>                 mechanism (RFC3310) (RFC4169) is used. In such case the
>                 Authorization header field would typically not contain a
>                 ‘response’ header field parameter before a challenge
>                 response is provided. However, for the IP Multimedia
>                 Subsystem (IMS) it has been specified that the
>                 Authorization header field in such case does contain a
>                   ‘response’ header field parameter, with an empty value
>                 (empty string). For that reason the modified
>                 request-digest ABNF allows such empty values.”
> 
>                 Regards,
> 
>                 Christer
> 
>                 *From: *Rifaat Shekh-Yusef <[email-masked]
>                 <mailto:[email-masked]>>
>                 *To: *Christer Holmberg <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc: *Christer Holmberg
>                 <christer.holmberg=[email-masked]
>                 <mailto:[email-masked]>>,
>                 "[email-masked]
>                 <mailto:[email-masked]>"
>                 <[email-masked]
>                 <mailto:[email-masked]>>,
>                 "[email-masked]
>                 <mailto:[email-masked]>"
>                 <[email-masked]
>                 <mailto:[email-masked]>>,
>                 "[email-masked] <mailto:[email-masked]>" <[email-masked]
>                 <mailto:[email-masked]>>, "[email-masked]
>                 <mailto:[email-masked]>" <[email-masked]
>                 <mailto:[email-masked]>>, Alexey Melnikov
>                 <[email-masked] <mailto:[email-masked]>>
>                 *Subject: *Re: [sipcore] Alexey Melnikov's No Objection
>                 on draft-ietf-sipcore-digest-scheme-12: (with COMMENT)
> 
>                 On Thu, Oct 31, 2019 at 11:44 AM Christer Holmberg
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
> 
>                     Hi,
> 
>                     Perhaps we could add some text about the IMS
>                     use-case, in order to explain the empty value?
> 
>                     Regards,
> 
>                     Christer
> 
>                     *From: *sipcore <[email-masked]
>                     <mailto:[email-masked]>> on behalf of
>                     Christer Holmberg
>                     <christer.holmberg=[email-masked]
>                     <mailto:[email-masked]>>
>                     *To: *Rifaat Shekh-Yusef <[email-masked]
>                     <mailto:[email-masked]>>
>                     *Cc: *"[email-masked]
>                     <mailto:[email-masked]>"
>                     <[email-masked]
>                     <mailto:[email-masked]>>,
>                     "[email-masked]
>                     <mailto:[email-masked]>"
>                     <[email-masked]
>                     <mailto:[email-masked]>>,
>                     "[email-masked] <mailto:[email-masked]>"
>                     <[email-masked] <mailto:[email-masked]>>,
>                     "[email-masked] <mailto:[email-masked]>"
>                     <[email-masked] <mailto:[email-masked]>>, Alexey
>                     Melnikov <[email-masked]
>                     <mailto:[email-masked]>>
>                     *Subject: *Re: [sipcore] Alexey Melnikov's No
>                     Objection on draft-ietf-sipcore-digest-scheme-12:
>                     (with COMMENT)
> 
>                     Hi,
> 
>                     In reality it probably doesn’t make a difference,
>                     but it would make the IMS procedures “aligned” with
>                     the IETF spec.
> 
>                     Regards,
> 
>                     Christer
> 
>                     On Thu, Oct 31, 2019 at 9:37 AM Christer Holmberg
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
> 
>                         Hi,
> 
>                         The reason for the empty value comes from IMS
>                         and AKA, where you need to include the user id
>                         already in the initial REGISTER request (this
>                         seems to be missing from RFC 3310, but that’s a
>                         separate topic) in order for the server to
>                         create the challenge,  meaning that in the
>                         initial REGISTER request you include an
>                         Authorization header field with the username
>                         parameter carrying the IMS private user
>                         identity, the realm parameter and the uri
>                         parameter. At this point you obviously don’t yet
>                         have the response, so in IMS it is specified
>                         that the response parameter is inserted with an
>                         empty value.
> 
>                         WHY it was specified that way (instead of simply
>                         not including the response parameter) I don’t
>                         know, but I do know that it has been implemented
>                         and deployed that way for many years.
> 
>                         Regards,
> 
>                         Christer
> 
>                         *From: *sipcore <[email-masked]
>                         <mailto:[email-masked]>> on behalf of
>                         Rifaat Shekh-Yusef <[email-masked]
>                         <mailto:[email-masked]>>
>                         *To: *Alexey Melnikov <[email-masked]
>                         <mailto:[email-masked]>>
>                         *Cc: *"[email-masked]
>                         <mailto:[email-masked]>"
>                         <[email-masked]
>                         <mailto:[email-masked]>>,
>                         "[email-masked]
>                         <mailto:[email-masked]>"
>                         <[email-masked]
>                         <mailto:[email-masked]>>,
>                         "[email-masked] <mailto:[email-masked]>"
>                         <[email-masked] <mailto:[email-masked]>>,
>                         "[email-masked] <mailto:[email-masked]>"
>                         <[email-masked] <mailto:[email-masked]>>
>                         On Thu, Oct 31, 2019 at 9:13 AM Alexey Melnikov
>                         <[email-masked]
>                         <mailto:[email-masked]>> wrote:
> 
>                                 On Thu, Oct 31, 2019 at 7:22 AM Alexey
>                                 Melnikov <[email-masked]
>                                 <mailto:[email-masked]>> wrote:
> 
>                                     Hi Rifaat,
> 
>                                         I am fine with the first two
>                                         comments, and will fix these in
>                                         the coming version of the document.
> 
>                                         I am not sure I follow the 3rd
>                                         one. Why do you see the need for
>                                         a minimum number of hex digits?
> 
>                                     You do say that the number of hex
>                                     digits match the hash lenght, so it
>                                     is probably Ok. However empty value
>                                     is never valid (and I am worried it
>                                     might hit some boundary condition
>                                     bug in implementations), so
>                                     prohibiting it in ABNF would be the
>                                     best.
> 
>                                     Best Regards,
> 
>                                     Alexey
> 
>                                         Regards,
> 
>                                           Rifaat
> 
>                                         On Wed, Oct 30, 2019 at 1:16 PM
>                                         Alexey Melnikov via Datatracker
>                                         <[email-masked]
>                                         <mailto:[email-masked]>> wrote:
> 
>                                             Alexey Melnikov has entered
>                                             the following ballot
>                                             position for
> 
>                                             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:
> 
>                                                 A UAS prioritizes which
>                                             algorithm to use based on
>                                             the ordering of the
> 
>                                                 challenge header fields
>                                             This looks either wrong or
>                                             confusing to me. I think you
>                                             are just saying here
> 
>                                                 process is specified in
>                                             section 2.3 and parallels
>                                             the process used in
> 
>                                             So based on the above, my
>                                             suggested replacement for
>                                             both sentences:
> 
>                                                 A UAS prioritizes which
>                                             algorithm to use based on
>                                             its policy,
> 
>                                                 which is specified in
>                                             section 2.3 and parallels
>                                             the process used in
> 
>                                                 If the UAC cannot
>                                             respond to any of the
>                                             challenges in the response,
> 
>                                                 then it SHOULD abandon
>                                             attempts to send the request
>                                             unless a local
> 
>                                             Is trying other non Digest
>                                             algorithms covered by
>                                             "SHOULD abandon"?
> 
>                                             If yes, maybe you should
>                                             make this clearer.
> 
>                                                 For example, if the UAC
>                                             does not have
> 
>                                                 credentials or has stale
>                                             credentials for any of the
>                                             realms, the UAC
> 
>                                             This now allows empty value.
>                                             I suggest you specify a
>                                             minimum number of hex
> 
>                                             digits allowed in the ABNF.
>                                             Or at least change "*LHEX"
>                                             to "2*LHEX".
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Nov 2019 14:43:36 +0000

Hi,

    > I'm confused. When is this behavior appropriate and what does it mean?

As I explained earlier, there are cases (IMS AKA) where the Authorization header field is sent before a challenge has been received, and 3GPP specified that an empty response parameter is included in such cases.

Regards,

Christer

    >                         Objection on