Re: [sipcore] draft-ietf-sipcore-digest-scheme comments

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

On Sat, May 25, 2019 at 3:36 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> ...
>
> >>>>>>>> Section 2.4:
> >>>>>>>>
> >>>>>>>> "When the UAC receives a response with multiple header fields
> with the
> >>>>>>>>   same realm it SHOULD use the topmost header field that it
> supports,
> >>>>>>>>   unless a local policy dictates otherwise.”
> >>>>>>>>
> >>>>>>>> Why a SHOULD? I would prefer a MUST.
> >>>>>>>
> >>>>>>> I can do that, but the last part of this paragraph states that
> local policy can override this recommendations anyway.
> >>>>>>> So, does it make any difference?
> >>>>>>> Should we allow that? Why would local policy enforce a downgrade?
> >>>>>>>
> >>>>>>>> “When the UAC receives a 401 response with multiple
> WWW-Authenticate
> >>>>>>>>   header fields with different realms it SHOULD retry and include
> an
> >>>>>>>>   Authorization header field containing credentials that match the
> >>>>>>>>   topmost header field of any one of the realms.”
> >>>>>>>>
> >>>>>>>> If you are disallowing multiple Authorization headers for the
> same realm,
> >>>>>>>> but with different algorithms I think this should be clearly
> written. In my
> >>>>>>>> view, that would be a good thing.
> >>>>>>>
> >>>>>>> This is allowed.
> >>>>>>
> >>>>>> RFC 3261 does not say anything about using the topmost header, does
> it?
> >>>>>>
> >>>>>> I was referring to this document.
> >>>>>
> >>>>> So, the should-use-topmost is something new, defined in this
> document?
> >>>>
> >>>> Yes, as per RFC7616.
> >>>
> >>> Perhaps then say "As defined in RFC7617,...."
> >>>
> >>> And, perhaps mention it in section 2, where the changes are listed.
> >>>
> >>> The normative text for SIP is specified in this document, so I do not
> see the need to add such a sentence.
> >>
> >> When we update an RFC, it is good to have an overview about what the
> updates are, so that people don't have to start reading 3261, 7617
> >> and try to figure out themselves. They will obviously have to read the
> RFCs to figure out the details, but it helps if they know what the updates
> >> are about.
> >
> > Section 2 is all about the changes introduced to the Digest mechanism.
>
> Yes, but that doesn't really say anything about what exactly is updated.
>
> > If that is not sufficient, can you propose some text?
>
> Something like this:
>
> "2.  Updates RFC 3261
>

I do not see the need for this change. The first page has "Update: 3261"
and the first sentence in section 2 explicitly states that again.


> This section replaces the reference to RFC2617 with a reference to RFC7617
> in RFC3261, and
> describes the modifications to the usage of the Digest mechanism in
> RFC3261 resulting from
> that reference update. It adds support for the SHA-256 and SHA-512/256
> algorithms. It adds
> required support for the "qop" option. It provides additional UAC and UAS
> procedures regarding usage of
> multiple SIP Authorization, WWW-Authenticate and Proxy-Authenticate header
> fields, including
> in which order to insert and process them. It provides guidance regarding
> forking. Finally, it
> updates the SIP protocol BNF as required by the updates."
>
> Feel free to modify, remove - or add if I have forgot something.
>
> All of this is specified later in section 2, but if this helps someone, I
do not mind adding this to section 2.


>
> In addition, I suggest to change the names of subsections 2.3 and 2.4.
>
> The current name of subsection 2.3 is "The Authenticate Response Header
> Field". But, there is no such header field described. The section talks
> about other header fields (with similar names). Could we simply call it
> "UAS behavior"?
>
> The current name of subsection 2.4 is "The Authorization Request Header
> Field". But, the section also talks about the WWW-Authenticate header
> field. Could we simply call it "UAC behavior"?
>
>
Sure. I can make these changes.

Regards,
 Rifaat




> Regards,
>
> Christer
>
>
>