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

[Christer Holmberg <[e-mail]>]

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