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

[Rifaat Shekh-Yusef <[e-mail]>]

I do not have a strong opinion here.

Anybody has an opinion or thoughts about adding such a text?

Regards,
 Rifaat


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".
>
>
>
>
>
>
>
>
>
>