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

[Alexey Melnikov <[e-mail]>]

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