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

[Paul Kyzivat <[e-mail]>]

On 11/4/19 2:57 AM, Christer Holmberg wrote:
> 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."

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 
> <[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".
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>