Re: [sipcore] SIP Digest - Open Issue

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

On Thu, Mar 9, 2017 at 2:42 PM, Asveren, Tolga <[e-mail]>
wrote:

> i- I think it needs to be handled. It may have a cohort of anti-fans but
> forking is part of RFC3261 and should be covered for any scenario/new
> mechanism.
>
>
Ok.



>
>
> ii- I am not sure whether “UAC responds with the ones it supports” is the
> right approach. New/updated implementations may follow that advice but what
> about existing UACs?
>

Existing UAC will use MD5 if present in the challenge. If MD5 is not
present, it means that the server decided not to support MD5 and requires
new clients that support SHA2.



> I think there may be a need to define a new option-tag indicating support
> for SHA*. If that is not present, only MD5 should be used. And actually
> this comment is applicable for any scenario, not just for forking. For
> forking, aggregation should consider the option-tag.
>
>
>

I am not clear on why an option-tag is needed; can you please elaborate?



> iii- UAC supporting SHA* and receiving challenges for both MD5/SHA* should
> reply for both of them.
>

It depends, if the challenge is coming from one server that supports both,
then the UAC should prefer SHA2; otherwise, you are right, the UAC will
have to provide both.



> Authorization headers should be ordered based on the order of received
> WWW/Proxy-Authenticate header if challenges for both MD5/SHA* are received
> for the same realm. This would be needed if forking happens and one of the
> forked challengers support only MD5. Forking proxy should send only MD5
> Authorization header to such an entity.
>

This is already covered by the existing text.



> iv- In general, I don’t think there is a need to repeat “Updates to HTTP”
> etc…, which are already present in RFC3261.
>
>
>

There are few differences between what is in RFC3261 and what is in the
draft. Also, this is provided for completeness to cover the Digest
mechanism in one document.

Regards,
 Rifaat




> Thanks,
>
> Tolga
>
>
>
> *From:* sipcore [mailto:[e-mail]] *On Behalf Of *Rifaat
> Shekh-Yusef
> *Sent:* Thursday, March 9, 2017 9:04 AM
> *To:* [e-mail]
> *Subject:* [sipcore] SIP Digest - Open Issue
>
>
>
> Hi,
>
>
>
> There is an open issue around the Digest draft and I would like to get
> some thoughts from the WG about it:
>
> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/
>
>
>
> The issue is related to section 2.5 Forking:
>
> Is this a real use case? if so, the current text calls for the proxy to
> aggregate the responses and for the UAC to respond to the the ones it
> support; is this a reasonable approach?
>
>
>
> Appreciate any thoughts about this.
>
>
>
> Regards,
>
>  Rifaat
>
>
>