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



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