Re: [sipcore] SIP Digest - Open Issue

["Asveren, Tolga" <[e-mail]>]

It seems an option-tag wouldn’t be needed if existing UACs follow relevant specifications to the letter:
- RFC2617 (I refer to this one rather than RFC7616 as the latter one is “too new” for most existing implementations) tells that a challenge with an unknown algorithm should be ignored.
  algorithm
     A string indicating a pair of algorithms used to produce the digest
     and a checksum. If this is not present it is assumed to be "MD5".
     If the algorithm is not understood, the challenge should be ignored
     (and a different one used, if there is more than one).
No RFC2119 keywords here but still I would take it as a mandate. OTOH, I wouldn’t be surprised, if there are quite some implementations out there, which would have issues in practice:

-          UAC ignoring all challenges if one of them -especially the topmost one- has an unknown algorithm

-          UAC assuming MD5 without checking algorithm field and replying for all challenges as such

An option tag may benefit also new UACs which are replying to high volume of challenges, e.g. a core network element rather than a UE. If they are able to indicate support for SHA*, a new challenger would ask only for it. Otherwise UAC would be challenged with both MD5/SHA* and needs to reply for both.  Can’t we allow UAC to reply only with SHA*? I wouldn’t think so, as there may be forking and one of the forked challengers may be using only MD5.

Overall, an option-tag is not a semantical MUST but would add real value in practice AFAICT.

On another note, I think ordering of Authentication header should not matter as “alg” has to be included if it is not MD5 (again per above quoted text). OTOH, I think it could be good to mandate/mention this explicitly in the draft.
And RFC3261 has the following:

   When resubmitting its request in response to a 401 (Unauthorized) or
   407 (Proxy Authentication Required) that contains multiple
   challenges, a UAC MAY include an Authorization value for each WWW-
   Authenticate value and a Proxy-Authorization value for each Proxy-
   Authenticate value for which the UAC wishes to supply a credential.
   As noted above, multiple credentials in a request SHOULD be
   differentiated by the "realm" parameter.

Which probably need to be updated to say “request SHOULD be differentiated by the “realm”/”alg” parameter combination.

Thanks,
Tolga

From: Rifaat Shekh-Yusef [mailto:[e-mail]]
Sent: Friday, March 10, 2017 9:01 AM
To: Asveren, Tolga <[e-mail]>
Cc: [e-mail]
Subject: Re: [sipcore] SIP Digest - Open Issue



On Thu, Mar 9, 2017 at 2:42 PM, Asveren, Tolga <[e-mail]<mailto:[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]<mailto:[e-mail]>] On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, March 9, 2017 9:04 AM
To: [e-mail]<mailto:[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