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

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 Jan 2014 17:48:19 -0500 (EST)

Here are some comments on draft-yusef-sipcore-digest-scheme-03:

Section 2 says, "This section describes the modifications to the
operation of the Digest mechanism as specified in RFC3261."

I think it would be helpful here to also point to HTTP-DIGEST by
adding "... in order to support the SHA2-256 and SHA2-512/256
algorithms as described in [HTTP-DIGEST], and also to require support
for the "qop" option."

The text is a bit hazy about the distinction between the *name* of the
algorithm and the "algorithm" value that is used to specify the
algorithm.  In particular, one algorithm is *called* "SHA2-512/256",
but its corresponding *value* is "SHA2-512-256".  This is easy enough
to understand, but it may be inviting trouble.  It appears that the
underlying problem is that "/" is not a token character, and that RFC
3261 restricts algorithm values to being tokens.

Two algorithms are called "SHA2-256" and "SHA2-512/256".  But the
standard names for these two algorithms seem to be  "SHA-256" and
"SHA-512/256", looking at the Wikipedia page "SHA-2" and mentions of
these algorithms in the titles of various RFCs.

The use of "-sess" seems to be poorly specified.  Much of the text
treats algorithm values ending in "-sess" opaquely, in that certain
enumerated algorithm values that happen to end in "-sess" cause the A1
processing to be modified.  But the intention seems to be that "-sess"
is a *modifier* of an algorithm that is otherwise defined.  It seems
like there should be a specification of the meaning of "-sess" that is
orthogonal to the algorithm name proper.

Section 2.3 says, "If the UAS challenges with multiple
WWW-Authenticate/Proxy- Authenticate headers, then each one of these
headers MUST use a different digest algorithm."

We don't want this restriction because it would forbid the UAS to
provide multiple challenges with different realms but the same
algorithm.  In addition, this restriction provides no benefit to UACs,
because when a proxy aggregates challenges, even if the UASs are
following this rule, the aggregated challenge may not follow this
rule.

Section 2.3 says, "The UAS MUST add these headers to the response in
order of strength of the algorithm, starting with the strongest
algorithm, followed by the less strong algorithms."

I think the rule you want is that the challenges should be listed in
the order that the UAS would prefer to see them used.  In general,
this SHOULD be in order of cryptographic strength, but there could be
other considerations, and it's possible that the consensus of
cryptographic strength could change over time, leaving an
implementation out-of-compliance.

Section 2.4 says, "If the UAC does not support any of the algorithms
in the response, then it should abandon attempts to send the request."

I think this can be generalized to "If the UAC cannot respond to any
of the challenges in the response ..."; e.g., if the UAC does not have
credentials for any of the realms.

Section 2.5 says, "When the forking proxy places multiple
WWW-Authenticate and Proxy-Authenticate header fields from one proxy
into the single response it MUST maintain the order of these header
fields. The ordering of the header field values from the various
proxies is not significant."

I think "one proxy" should be "one received response".

In theory, it may not be possible for the proxy to both remove all
duplicates from the list and also maintain the order from each
received response (since two duplicated headers might appear in
opposite orders in two responses).  But I think that is impossible
unless two received responses can have headers with the same nonce
value.

Section 2.6 says, "The SIP scheme usage is almost completely identical
to that for HTTP."

I'd prefer "... is similar to that for HTTP." given that the
differences are quite significant (especially in that the request URI
is not protected).

Section 2.6 says, "This section does NOT maintain backward
compatibility with RFC 2543."

This statement needs to be fleshed out.  In one sense, it is not
backward compatible with *RFC 3261*, because it requires UAs to fully
support "qop" -- UAs that are compliant with RFC 3261 but don't
support "qop" are not compliant with the modified RFC 3261.

On the other hand, as long as UAs can deal with their other-ends not
supporting "qop" (which I expect to be the universal implementation
practice), then they are *compatible* with such UAs.

There is also the problem that "compatibility with RFC 2543" is used
to mean "compatibility with RFC 2069 (which was referenced in early
drafts of RFC 2543)".  I'm not sure if that's technically incorrect,
but it would probably be clearer to state "RFC 2069" directly.

Section 2.6 says, "4. The text in RFC 2617 [17] regarding cache
operation does not apply to SIP."

There are some tricky issues surrounding the binding-time of the
reference "[17]".  For clarity, this probably needs to be turned into
a reference that is resolved within this document.

And a comment about draft-ietf-httpauth-digest-04:

This draft creates a registry named "HTTP Digest Hash Algorithms".
There is already a registry named "HTTP Digest Algorithm Values"
(http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml).
That latter registry has a different purpose, similar algorithm names,
and specifies that the algorithm outputs are to be presented in
base64.  I think there is a significant danger of confusion, but it
would also be difficult to combine them.

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 23 Jan 2014 20:27:02 -0500

Hi Dale,

Thanks a lot for these great comments.
See my reply inline...

Regards,
 Rifaat

> algorithms as described in [HTTP-DIGEST], and also to require support
Ok

> 3261 restricts algorithm values to being tokens.
How do you suggest I fix that?

> these algorithms in the titles of various RFCs.
Ok, I will change the name to align with the standard name.

> orthogonal to the algorithm name proper.

I need to think about this one.

> following this rule, the aggregated challenge may not follow this
I will clarify it to make it clear that this limitation is for multiple
headers with the same realm.

> implementation out-of-compliance.
Good point. I will fix it.

> credentials for any of the realms.
Ok

> I think "one proxy" should be "one received response".
Ok.

> differences are quite significant (especially in that the request URI
Ok.

> but it would probably be clearer to state "RFC 2069" directly.
How about replacing the MUST with SHOULD in section 2.6, bullet 7, as
follows:

   Servers SHOULD be able to properly handle "qop" parameter received
   in an authorization header field, and clients SHOULD 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.

> a reference that is resolved within this document.
Yes.

> would also be difficult to combine them.
Yeah, it might confuse people. Do you have a better name for this registry?

Regards,
 Rifaat

Dale
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jan 2014 22:24:30 -0500

I have added a few comments inline.

	Thanks,
	Paul

On 1/23/14 8:27 PM, Rifaat Shekh-Yusef wrote:
> On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley <[email-masked]
> <mailto:[email-masked]>> wrote:
>

I've been trying to get at this too. It is really a defect in the 
original definition of digest, but it is how hard to get out of.

Till now my suggestion has been that it is just up to each new algorithm 
to specify a -sess variant if appropriate, and to define it.

If it will always be the case that every new algorithm should have a 
-sess variant and a non-sess variant, and that the difference between 
them can be defined once, then it would be better to do that, and change 
the syntax to just in clude a [ "-sess" ] and a common definition of 
what that means.

>     credentials for any of the realms.

I think that is too strong. Suppose the request has been forked, with 
separate challenges from each fork, and the proxy has merged them. If 
the UAC can only respond to one of the challenges, that should be ok. 
Then one fork will work and the other will not.

>     [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 24 Jan 2014 08:38:39 -0500

Inline...

On Thu, Jan 23, 2014 at 10:24 PM, Paul Kyzivat <[email-masked]>wrote:

> I've been trying to get at this too. It is really a defect in the original
> definition of digest, but it is how hard to get out of.
>
> If it will always be the case that every new algorithm should have a -sess
> variant and a non-sess variant, and that the difference between them can be
> defined once, then it would be better to do that, and change the syntax to
> just in clude a [ "-sess" ] and a common definition of what that means.
>
>
>
Ok. I will add the details of the meaning of the -sess variant to the
document.

> separate challenges from each fork, and the proxy has merged them. If the
> UAC can only respond to one of the challenges, that should be ok. Then one
> fork will work and the other will not.
>
>
Hmmm. How is that different from Dale's proposal.
If I paraphrase what Dale is saying, I understand it to say: "if the UAC is
not able to respond to at least one challenge..."

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2014 11:36:05 -0500

On 1/24/14 8:38 AM, Rifaat Shekh-Yusef wrote:
> Inline...
>
>
> On Thu, Jan 23, 2014 at 10:24 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         On Thu, Jan 23, 2014 at 5:48 PM, Dale R. Worley
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Here are some comments on
>         draft-yusef-sipcore-digest-__scheme-03:
>
>     Till now my suggestion has been that it is just up to each new
>     algorithm to specify a -sess variant if appropriate, and to define it.
>
>     -sess variant and a non-sess variant, and that the difference
>     between them can be defined once, then it would be better to do
>     that, and change the syntax to just in clude a [ "-sess" ] and a
>     common definition of what that means.
>
>
>

IIUC, this needs to be in [HTTP-DIGEST], not *this* document. Right?

>     I think that is too strong. Suppose the request has been forked,
>     with separate challenges from each fork, and the proxy has merged
>     them. If the UAC can only respond to one of the challenges, that
>     should be ok. Then one fork will work and the other will not.
>
> If I paraphrase what Dale is saying, I understand it to say: "if the UAC
> is not able to respond to at least one challenge..."

Maybe I read it wrong and we are all saying the same thing.

But it is tricky. If there are multiple challenges on a single fork, 
then those all need to be answered to be successful, but if they are on 
different forks then maybe not. So how do you decide when to give up, to 
avoid retrying forever?

	Thanks,
	Paul

>         (http://www.iana.org/__assignments/http-dig-alg/http-__dig-alg.xhtml
>         <http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml>).
>              _________________________________________________
>              sipcore mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/sipcore
>         <https://www.ietf.org/mailman/listinfo/sipcore>
>
>
>
>
>
>         _________________________________________________
>         sipcore mailing list
>         https://www.ietf.org/mailman/__listinfo/sipcore
>         <https://www.ietf.org/mailman/listinfo/sipcore>
>
>
>     _________________________________________________
>     sipcore mailing list
>     https://www.ietf.org/mailman/__listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 24 Jan 2014 17:14:57 -0500 (EST)

> >              Section 2.4 says, "If the UAC does not support any of
> >              the algorithms in the response, then it should
> >              abandon attempts to send the request."
> >
> >              I think this can be generalized to "If the UAC cannot
> >              respond to any of the challenges in the response
> >              ..."; e.g., if the UAC does not have credentials for
> >              any of the realms.
> >

Maybe there is a deeper question.

I have been *assuming* that if a UAS puts multiple challenges in its
response, then the UAC can successfully resend the request (to that
UAS) if it provides (valid) credentials for *any one* challenge.

With this assumption, the natural course of action for a UAC, when
challenged, is to resend the request with all credentials that it
possesses that match any one of the challenges.  And if it possesses
no such credential to give up.

And the UAC has to behave that way anyway, because it does not know
which challenges came from the same UAS and which came from different
UASs.

What if a UAS requires more than one credential? ... That works as
well, because the UAC will provide multiple credentials, and if the
UAC happens to provide a sufficient set to convince the UAS, the UAS
will accept the request.

It seems that in any of these cases, the UAC should provide
credentials for every challenge for which it has matching credentials.
Only if the UAC has no credentials for any of the challenges does the
UAC know for certain that the resend will fail.

> From: Paul Kyzivat <[email-masked]>

> IIUC, this needs to be in [HTTP-DIGEST], not *this* document. Right?

Hmmm, yes, I overlooked that -sess isn't used with SIP.  Perhaps
draft-yusef-sipcore-digest-scheme should state that the -sess variants
aren't used with SIP?

> From: Rifaat Shekh-Yusef <[email-masked]>

> How do you suggest I fix that?

I'm not sure that there is a good fix.  Thinking about it again,
perhaps what is bothering me is that draft-yusef-sipcore-digest-scheme
does not state the values of "algorithm" that are valid for SIP, it
only gives the algorithm names.  OTOH, the algorithm names are
translated into values by the registry table.  OTOOH, that fact
doesn't seem to be mentioned in the draft.  Perhaps add a sentence to
the beginning of 2.1:

   The Digest scheme has an 'algorithm' parameter that specifies the
   algorithm to be used to compute the digest of the response.  The
   IANA registry named "..." specifies the algorithms that correspond
   to 'algorithm' values.

And revise the IANA Considerations to mention that.  (This should be
parallel to text in HTTP-DIGEST.)

>    send the "qop" parameter in any resulting authorization header

Assuming that your intention is (1) for a UA to be conformant to this
spec, it must generate qop when possible and respond to qop when qop
is present in the challenge, and (2) to interoperate with UAs that do
not support qop (those implemented to RFC 2069 and called "RFC 2543"),
ISTM that your normative text is correct.

All I want is more detailed explanation where the compatilities and
incompatibilities lie.  Perhaps:

    This document requires UAs to provide "qop" in challenges and to
    provide "qop" in responses to challenges that provide "qop".  Thus
    UAs that are compliant to RFC 3261 or RFC 2543 (which are based on
    RFC 2617) are not compliant to this document unless they implement
    "qop".

    UAs that are compliant with this document will interoperate with
    UAs that do not implement "qop" (as described in RFC 2617).

That's not exactly how I want to say it, but I think it gives the
idea.

> Yeah, it might confuse people. Do you have a better name for this registry?

The ideal thing would be to combine the two registries.  You could
almost do that, except that the existing registry is for use with RFC
3230 (the HTTP "Digest" header), and specifies the encoding to be used
on the hash output.  And for the algorithms we are talking about, that
encoding is specified as base64, not hex.

I suppose "HTTP Digest Authentication Algorithm Values" would be
correct, although the potential for confusion is high.

Unfortunately it is probably not worth the effort to define a unified
registry and update all the relevant documents to deal with the
(somewhat different) unified registry.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2014 18:05:22 -0500

> UAC happens to provide a sufficient set to convince the UAS, the UAS

On any one path you should have at most one UAS challenging, but may 
have several proxies. So you would need to provide credentials for each 
of those.

When forking, those could be merged from multiple paths. The UAC, for a 
successful retry, will at least need to successfully respond to all the 
challenges from one of the paths.

> UAC know for certain that the resend will fail.

Certainly it should respond to everything it can.
But how does it know when to give up?

I guess this really depends on circumstances. If it is prompting a user 
for passwords, then it can just keep trying. But if it is working only 
with stored credentials, then I guess it must keep track of which ones 
it has already supplied. If all the ones it can supply have already been 
tried then it needs to give up.

But, contrary to my original suggestion, I guess we shouldn't be trying 
to give guidance here. (It is too implementation dependent.)

	Thanks,
	Paul

---

From: Michael Procter <[email-masked]>
Date: Sat, 25 Jan 2014 20:04:00 +0000

> Certainly it should respond to everything it can.

That seems to disagree with draft-ietf-httpauth-digest section 5.5 which begins:

   An HTTP/1.1 server may return multiple challenges with a 401
   (Authenticate) response, and each challenge may use a different auth-
   scheme. A user agent MUST choose to use the strongest auth- scheme it
   understands and request credentials from the user based upon that
   challenge.

If a UAS issues two challenges for the same realm but different
auth-schemes, then it seems reasonable to only respond with the
strongest supported auth-scheme.  To respond with both a stronger and
weaker algorithm seems unwise.

But if a proxy aggregates two challenges for the same realm but with
different auth-schemes, then as you both suggest, answering both
challenges is most likely to succeed.  RFC 3261 Section 22.3 last para
addresses this scenario.

Without being able to tell these two cases apart, I'm not sure a UAC
is able to maximise the chances of a request succeeding at the same
time as minimising the risk of using weaker auth-schemes when stronger
ones may be supported.

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Jan 2014 15:52:21 -0500

> time as minimising the risk of using weaker auth-schemes when stronger

Perhaps the UAC should choose the strongest auth-scheme for each realm, 
and respond to all of those.

That might fail on some fork if two alternate servers support different 
auth-schemes for the same realm. But that seems like a very badly 
configured realm, so maybe we don't care.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Jan 2014 06:28:02 -0500

Here is the current text from draft-yusef-sipcore-digest-scheme-04, section
2.4:

   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.

Which leaves it to the UAC's implementation to decide on what to do in
different use cases.
Is that good enough? should we change the SHOULD to MUST?

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Jan 2014 14:15:05 -0500

On 1/26/14 6:28 AM, Rifaat Shekh-Yusef wrote:
> Here is the current text from draft-yusef-sipcore-digest-scheme-04,
> section 2.4:
>

If we are agreeing that the there should only be one response per realm, 
then the question is which one.

The above says it SHOULD be the first one. In simple cases that is the 
one most preferred by the UAS. And if the UAS orders them strongest 
first, then it is equivalent to the UAC choosing the strongest.

But it gets more complex with proxies and forking. Of note, how does a 
forking proxy merge these from different forks. Unless it determines the 
order of the merge based on strength, the first one may not be the 
strongest.

ISTM that is is having too many cooks working on the soup. It seems 
clearer to just have the UAC choose the strongest it supports for each 
realm.

	Thanks,
	Paul

> Regards,
>   Rifaat
>
>
>
>
>
>
>
>
> On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat <[email-masked]
>         On 24 January 2014 23:05, Paul Kyzivat <[email-masked]
>     Perhaps the UAC should choose the strongest auth-scheme for each
>     realm, and respond to all of those.
>
>     That might fail on some fork if two alternate servers support
>     different auth-schemes for the same realm. But that seems like a
>     very badly configured realm, so maybe we don't care.
>
>              Thanks,
>              Paul
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Jan 2014 14:45:06 -0500

On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat <[email-masked]> wrote:

> The above says it SHOULD be the first one. In simple cases that is the one
> most preferred by the UAS. And if the UAS orders them strongest first, then
> it is equivalent to the UAC choosing the strongest.
>
>
The reason for doing that in the HTTP draft was to minimize the impact on
the browsers, as the existing behavior of the browsers is to prefer the
topmost header.

> order of the merge based on strength, the first one may not be the
Do you see a problem with requiring proxies to order them based on strength?

> clearer to just have the UAC choose the strongest it supports for each
The question is: how will existing UACs behave when they receive multiple
headers?
Will they choke?
Will they prefer the first? the last?

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Jan 2014 15:40:03 -0500

On 1/26/14 2:45 PM, Rifaat Shekh-Yusef wrote:
>
>
>
> On Sun, Jan 26, 2014 at 2:15 PM, Paul Kyzivat <[email-masked]
>         Here is the current text from
>         draft-yusef-sipcore-digest-__scheme-04,
>         section 2.4:
>
>     If we are agreeing that the there should only be one response per
>     realm, then the question is which one.
>
>     The above says it SHOULD be the first one. In simple cases that is
>     the one most preferred by the UAS. And if the UAS orders them
>     strongest first, then it is equivalent to the UAC choosing the
>     strongest.
>
>
> The reason for doing that in the HTTP draft was to minimize the impact
> on the browsers, as the existing behavior of the browsers is to prefer
> the topmost header.

Well, that is fine for browsers. What is existing behavior for sip UACs?
Maybe we can't depend on common language for this.

>     But it gets more complex with proxies and forking. Of note, how does
>     a forking proxy merge these from different forks. Unless it
>     determines the order of the merge based on strength, the first one
>     may not be the strongest.
>
>

Note that afaik this is only a sip problem. I don't think there are 
forking proxies for http.

In principle it could be done in proxies. But do you want to depend on 
all affected proxies implementing this? The UAC and UAS *need* to 
implement this before they can use new algorithms. Once they do, most 
things may work with existing proxies if you don't put such a 
requirement on them.

>     clearer to just have the UAC choose the strongest it supports for
>     each realm.
>
>
> The question is: how will existing UACs behave when they receive
> multiple headers?
> Will they choke?

Yes, that is an important question. They *shouldn't* choke, because they 
can already get this. Are they going to choke when they see a new 
algorithm mentioned?

I can imagine that testing may show that you can get backward compatible 
behavior best when the UAS puts the md5 algorithm first. Then 
implementations compatible with your draft, that support other 
algorithms, can pick out the strongest that they support.

But this is something we might want data on before making a decision.

	Thanks,
	Paul

> Regards,
>   Rifaat
>
>
>
>              Thanks,
>              Paul
>
>         Regards,
>            Rifaat
>
>
>
>
>
>
>
>
>         On Sat, Jan 25, 2014 at 3:52 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         wrote:
>
>                  On 24 January 2014 23:05, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>__> wrote:
>
>                  That seems to disagree with draft-ietf-httpauth-digest
>         section
>                  5.5 which begins:
>
>                       scheme. A user agent MUST choose to use the
>         strongest auth-
>                  scheme it
>                       understands and request credentials from the user
>         based
>                  upon that
>                       challenge.
>
>                  challenges is most likely to succeed.  RFC 3261 Section
>         22.3
>                  last para
>                  addresses this scenario.
>
>                  time as minimising the risk of using weaker
>         auth-schemes when
>                  stronger
>                  ones may be supported.
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Jan 2014 17:41:09 -0500

> Maybe we can't depend on common language for this.
Yes, I agree; the recommendation for SIP will most likely be different than
the  recommendations for HTTP.

> In principle it could be done in proxies. But do you want to depend on all
> affected proxies implementing this? The UAC and UAS *need* to implement
> this before they can use new algorithms. Once they do, most things may work
> with existing proxies if you don't put such a requirement on them.
>
>
Yeah, that will complicate things.

> can already get this. Are they going to choke when they see a new algorithm
> mentioned?
>
> implementations compatible with your draft, that support other algorithms,
> can pick out the strongest that they support.
>
Agree,

Regards.
 Rifaat

>>                       (Authenticate) response, and each challenge may use
>> a
>>                  different auth-