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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, November 3, 2019 12:01 PM
To: Alexey Melnikov <[e-mail]<mailto:[e-mail]>>
Cc: Christer Holmberg <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; SIPCORE <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:

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

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.

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 31 October 2019 at 19.22
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Cc: Christer Holmberg <christer.holmberg=[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Alexey Melnikov <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:

Hi,



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



Regards,



Christer



From: sipcore <[e-mail]<mailto:[e-mail]>> on behalf of Christer Holmberg <christer.holmberg=[e-mail]<mailto:[e-mail]>>
Date: Thursday, 31 October 2019 at 15.52
To: Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Alexey Melnikov <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 31 October 2019 at 15.20
To: Alexey Melnikov <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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".