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

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

Inline...

On Tue, May 21, 2019 at 4:57 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> ...
>
> >> Section 2.1:
> >>
> >> "Note that [RFC7616] defines a -sess variant for each algorithm; the
> >>   -sess variants are not used with SIP.”
> >>
> >> Is this already forbidden in 3261 or is this new proposed language? If
> so, “are not” should propably
> >> be something like “MUST not”
> >
> > I do not think that 3261 forbids the -sess variant, and I do not see the
> need to forbid it here either
> > So then I suggest we remove the statement that the -sess variants are
> not used with SIP.
>
> If -sess variant was defined in RFC 7616, it was obviously not mentioned
> in RFC 3261 __
>
> What is the difference between the session variant and the non-session
> variant? What is meant by "session"? RFC 7616 doesn't give any explanation,
> and I couldn't find anything by googling either.
>
>
See RFC 7616, section 3.4.2 for more details.



> I do think we need to say *something*.
>

Any suggestion?



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



>
> >> "8.  Servers MUST be able to properly handle "qop" parameter received
> >>   in an authorization header field, and clients MUST be able to
> >>   properly handle "qop" parameter received in WWW-Authenticate and
> >>   Proxy-Authenticate header fields.  Servers MUST always send a "qop"
> >>   parameter in WWW-Authenticate and Proxy-Authenticate header field
> >>   values, and clients MUST send the "qop" parameter in any resulting
> >>   authorization header field.”
> >>
> >> This is not clear. If the servers MUST always send “qop” then we
> >> add that to SIP 2.0 with no backwards options or compatibility.
> >> Since you write “clients MUST be able to”… it seems like you
> >> assume that clients have a choise of whether they use it. I think
> >> one has to be a bit more clear so developers understands how
> >> to modify their implementations.
> >> In addition:
> >> Are we ready to require that all SIP 2.0 compliant software support QOP?
> >>
> >> Here is a quote form RFC3261:
> >> "Use of the "qop" parameter is optional in RFC 2617 for the purposes
> >> of backwards compatibility with RFC 2069; since RFC 2543 was
> >> based on RFC 2069, the "qop" parameter must unfortunately
> >> remain optional for clients and servers to receive."
> >>
> >> That is no longer the case with RFC7616.
> >> Since this is a change from RFC 3261 we propably want clarify that for
> developers.
> >> I think that if we want to modify RFC7616 for SIP, we can. The question
> still
> >> stands - are we ready to change the way current auth works today in
> SIP/2.0. There’s
> >> a lot of implementations out there that will suddenly not be
> standard-following.
> >>
> >> I’m not saying it’s a bad thing, just that we have to understand the
> implication.
>
> The typical way to solve this is to say that endpoints compliant with this
> specification must do this and that, but for backward compatibility also
> needs to be able to not do it.
>
> Regards,
>
> Christer
>
>
>