Subject: [sipcore] Comments on draft-yusef-sipcore-digest-scheme-04

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Feb 2014 15:39:55 -0500

(Catching up on my reading)
(Speaking as an individual)

This version is much improved over the last one I reviewed.
I do have futher comments:

Section 2.1 says:

    RFC3261 specifies only one algorithm, MD5, which is used by default.
    This document adds two new algorithms, to align with the [HTTP-
    DIGEST], that SHOULD be used instead of MD5: SHA-256 & SHA-512/256.

That is true today. But it is also true that [HTTP-DIGEST] defines a 
registry of algorithms, and is written so that it is applicable to any 
algorithm that might be added to that registry in the future. Presumably 
that is the intent here too - not just to support the two new 
algorithms. So I suggest something like:

    RFC3261 specifies only one algorithm, MD5, which is used by default.
    This document extends RFC3261 to allow use of any registered
    algorithm.

Sections 2.4 & 2.5:

    When the UAC receives a response with multiple headers with the same
    realm it SHOULD use the topmost header that it supports, unless a
    local policy dictates otherwise. The client should ignore any
    challenge it does not understand.

    When the UAC receives a response with multiple headers with different
    realms it SHOULD provide all credentials that it possesses that match
    any one of the challenges.

What does the 2nd paragraph mean? It sounds like it contradicts the 
first paragraph. I *think* you mean, at least in part:

    When the UAC receives a 401 response with multiple WWW-Authenticate
    headers with different realms it SHOULD retry and include an
    Authorization header containing credentials that match the topmost
    header of any one of the realms.

AFAIK the only way that you would get WWW-Authenticate challenges from 
multiple realms is with forking, where some of the forks are in 
different realms. The above means that in the retry the forks from other 
realms will fail again, and challenge again. This is not ideal.

And that doesn't cover proxies. If multiple proxies are challenging, 
from different realms, then the request won't succeed unless it contains 
credentials for each of those realms. If there is no forking, then the 
challenges are going to occur one at a time, and the request will only 
succeed if the UAC maintains authentication sessions for each, 
preemptively includes credentials for them in the retries, and the 
nonces for the earlier ones remain valid until the request succeeds.

If there is forking, and proxies on different forks are in distinct 
realms, then things get more complicated.

ISTM that the best answer is for the UAC to provide *one* set of 
credentials for *each* distinct realm challenged via WWW-Authenticate, 
and for each distinct realm challenged via Proxy-Authenticate. In each 
case, using the first (or highest priority) algorithm it supports.

This still has a potential problem - different servers in a realm may 
vary in what algorithms they support. If so, the above may not always 
provide a good result. But I don't think we can fix that.

It would also be helpful to include some explanatory text, and maybe 
examples, of how all this works when there there are multiple proxies 
challenging, and when there is forking to multiple destinations in the 
same and different realms.

Section 2.6 says:

    1. The URI included in the challenge has the following BNF:

       URI  =  SIP-URI / SIPS-URI

Note that this assumes the R-URI of a sip request can only be SIP or 
SIPS. But we to allow other values, e.g., TEL and IM. The sip ABNF is:

Request-URI    =  SIP-URI / SIPS-URI / absoluteURI

So why not just say:

       URI  =  Request-URI

Later in bullet 6 is:

        H(entity-body) = chosen-algorithm("")

        For example, when the chosen algorithm is SHA-256, then:

(That was my suggestion.) But for consistency with the latest 
[HTTP-DIGEST], this would probably better be:

        H(entity-body) = <algorithm>("")

        For example, when the <algorithm> is SHA-256, then:

That's all for now.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 25 Feb 2014 18:58:24 -0500

Thanks Paul,

Please, see my reply inline...

Regards,
 Rifaat

On Sun, Feb 23, 2014 at 3:39 PM, Paul Kyzivat <[email-masked]> wrote:

> that is the intent here too - not just to support the two new algorithms.
> So I suggest something like:
>
Ok

> What does the 2nd paragraph mean? It sounds like it contradicts the first
> paragraph. I *think* you mean, at least in part:
>
> Yes, I like your text better.

> multiple realms is with forking, where some of the forks are in different
> realms. The above means that in the retry the forks from other realms will
> fail again, and challenge again. This is not ideal.
>

Not necessarily. The client can include authorization for more than one
challenge. Take a look at the following quote from RFC3261, section 22.3:

   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.

And that doesn't cover proxies. If multiple proxies are challenging, from
> different realms, then the request won't succeed unless it contains
> succeed if the UAC maintains authentication sessions for each, preemptively
> includes credentials for them in the retries, and the nonces for the
> earlier ones remain valid until the request succeeds.
>
> credentials for *each* distinct realm challenged via WWW-Authenticate, and
> for each distinct realm challenged via Proxy-Authenticate. In each case,
> using the first (or highest priority) algorithm it supports.
>
> This still has a potential problem - different servers in a realm may vary
> in what algorithms they support. If so, the above may not always provide a
> good result. But I don't think we can fix that.
>

I agree with that, as that was the intention of the text provided in
section 2.4. Maybe it was not clear enough.

The question is how to do that while maintaining backward compatibility?
Do we require the proxies to maintain order of challenges and assume that
existing endpoints will select the top challenge? or
Do we allow proxies to provide challenges in no particular order and expect
the client to select the most preferred, which might not work with existing
clients?

> challenging, and when there is forking to multiple destinations in the same
> and different realms.
>
> Ok, I will add more details.

> Note that this assumes the R-URI of a sip request can only be SIP or SIPS.
> But we to allow other values, e.g., TEL and IM. The sip ABNF is:
>
OK

>        For example, when the <algorithm> is SHA-256, then:
Ok

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Feb 2014 10:42:12 -0500

On 2/25/14 6:58 PM, Rifaat Shekh-Yusef wrote:
> On Sun, Feb 23, 2014 at 3:39 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     registry of algorithms, and is written so that it is applicable to
>     any algorithm that might be added to that registry in the future.
>     Presumably that is the intent here too - not just to support the two
>     new algorithms. So I suggest something like:
>

But that at least implies *choosing* *one* realm to respond to.
I explicitly narrowed the above to 401 responses, where that *might* 
make sense. But not necessarily, when there is forking.

>     AFAIK the only way that you would get WWW-Authenticate challenges
>     from multiple realms is with forking, where some of the forks are in
>     different realms. The above means that in the retry the forks from
>     other realms will fail again, and challenge again. This is not ideal.
>
>

Then my suggested text is wrong. Perhaps the goal should be:

- supply credentials for *each* realm that has challenged
   (but omit for those where no credentials are available)

- for each realm, use (only) the first (highest priority)
   algorithm supported

- if the same realm is challenged with both WWW-Authenticate and
   Proxy-Authenticate, then I *think* one must not allow
   Proxy-Authenticate to bid down to a lower priority algorithm.
   (That could be an attack.) But this needs more discussion.

- I think the logic for preemptively including credentials needs
   further explanation, so that it works in the presence of
   proxies that authenticate on different forks.

>     from different realms, then the request won't succeed unless it
>     contains credentials for each of those realms. If there is no
>     forking, then the challenges are going to occur one at a time, and
>     the request will only succeed if the UAC maintains authentication
>     sessions for each, preemptively includes credentials for them in the
>     retries, and the nonces for the earlier ones remain valid until the
>     request succeeds.
>
>     credentials for *each* distinct realm challenged via
>     WWW-Authenticate, and for each distinct realm challenged via
>     Proxy-Authenticate. In each case, using the first (or highest
>     priority) algorithm it supports.
>
>     This still has a potential problem - different servers in a realm
>     may vary in what algorithms they support. If so, the above may not
>     always provide a good result. But I don't think we can fix that.
>
>
> Do we require the proxies to maintain order of challenges and assume
> that existing endpoints will select the top challenge? or
> Do we allow proxies to provide challenges in no particular order and
> expect the client to select the most preferred, which might not work
> with existing clients?

This is hard. I haven't thought it through in detail.

>     examples, of how all this works when there there are multiple
>     proxies challenging, and when there is forking to multiple
>     destinations in the same and different realms.
>

Getting a good set of use cases would make it easier to explore the issues.

	Thanks,
	Paul