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

[Christer Holmberg <[e-mail]>]

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.

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

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

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