Subject: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 10 Jan 2014 19:48:09 -0500

Hi,

This draft,
https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/,
updates the Digest Authentication Scheme used by SIP based on the ongoing
update to the HTTP Digest Authentication Scheme described here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/.

The document has one open issue related to the backward compatibility with
RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP
document is still under discussion.

I would appreciate any feedback on this initial version of this document.

Regards,

 Rifaat

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Jan 10, 2014 at 7:45 PM
Subject: New Version Notification for
draft-yusef-sipcore-digest-scheme-00.txt
To: Rifaat Shekh-Yusef <[email-masked]>

A new version of I-D, draft-yusef-sipcore-digest-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:           draft-yusef-sipcore-digest-scheme
Revision:       00
Title:          The Session Initiation Protocol (SIP) Digest Authentication
Scheme
Document date:  2014-01-10
Group:          Individual Submission
Pages:          7
URL:
http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt
Status:
https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/
Htmlized:
http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00

Abstract:
   This document updates the Digest Access Authentication scheme used by
   the Session Initiation Protocol (SIP) to add support for SHA2 digest
   algorithms to replace the MD5 algorithm.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 11 Jan 2014 11:51:10 +0100

On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef <[email-masked]> wrote:

> Hi,
>  
> This draft, https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/, updates the Digest Authentication Scheme used by SIP based on the ongoing update to the HTTP Digest Authentication Scheme described here: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/.
>  
> The document has one open issue related to the backward compatibility with RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP document is still under discussion.
Great to see this finally happen!

A few questions:

1. If you modify the BNF and other things - doesn't this update RFC 3261?
2. You state as an open issue whether we need to keep backwards compatibility
   with 2543/2069. What do you think, what would be the effect if we don't?
3. I would like to see a section that more clearly defines the changes compared
    with 3261/2543 to make it easier for developers to understand what they
    need to change and what they can keep.

Cheers,
/O

> Subject: New Version Notification for draft-yusef-sipcore-digest-scheme-00.txt
> Title:          The Session Initiation Protocol (SIP) Digest Authentication Scheme
> URL:            http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/
> Htmlized:       http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00
> 
> 
> Abstract:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 11 Jan 2014 21:27:45 -0500

Thanks Olle,

See my replies inline...

Regards,
 Rifaat

> 1. If you modify the BNF and other things - doesn't this update RFC 3261?

Yes, I will add that to the next version of the draft.

>    with 2543/2069. What do you think, what would be the effect if we don't?

That depends on what we have out there.
Are there are many deployed systems that comply to RFC2543 but not RFC3261?
Do most proxies add the "qop" parameter today?

>     need to change and what they can keep.
Ok.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 12 Jan 2014 10:36:20 +0100

> Yes, I will add that to the next version of the draft.
Before Cullen says it:

Do we have to update RFC3261 meaning that everyone is forced to update to stay 
compliant with SIP? Or can we do this as an optional addon?

Moving forward and leaving MD5 behind is desirable, but maybe not declaring devices
incompatible with SIP. What is the opinion of the SIPcore group?

> Do most proxies add the "qop" parameter today?
Good question. Are proxys really allowed to mess with the authentication headers?

If we make this an optional specification, possibly with a supported header, like

Supported: strongauth

then we can get rid of the old stuff. And maybe such a header would help migration.
The server in that case doesn't have to downgrade to md5 and can make a decision
on whether it requires this to proceed.

Opinions?

/O

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 12 Jan 2014 08:11:22 -0500

Maybe I was not clear enough.
The draft is *not *deprecating MD5, but leaves it there for backward
compatibility. This is explained in the HTTP draft.

The question is around the use of "qop" today which is optional in RFC2617
and still under discussion in the HTTP draft to understand the impact there.

Regards,
 Rifaat

On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson <[email-masked]> wrote:

>> The document has one open issue related to the backward compatibility
>> with RFC2543/RFC2069. The backward compatibility with RFC2069 in the HTTP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jan 2014 12:51:49 -0500

Rifaat,

Thanks for looking into this. I think it is a good thing to do.
I have a few comments:

Is it your intent to change the *default* algorithm? Or simply to add 
new algorithms? You can't really change the default and remain backward 
compatible.

If the intent is simply to add new algorithms, then ISTM that this can 
just be an extension to 3261.

The IANA Considerations says:

    The [HTTP-DIGEST] defines an IANA registry named "HTTP Digest Hash
    Algorithms" to simplify the introduction of new algorithms in the
    future. This document will use the algorithms defined in that
    registry.

The references don't define [HTTP-DIGEST].  The registry I was able to 
find is: 
https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml, and I 
found one draft that adds values to it: RFC 5843. But that rfc says:

    Note: This is unrelated to HTTP Digest Authentication.  Instance
    Digests in HTTP provide a digest, also known as a checksum or hash,
    of an entire representation of the current state of a resource.

I find that RFC 2617 is the replacement for 2069, but it doesn't add 
algorithms or introduce a registry.

Also, while you mention the registry in iana considerations, I don't see 
anything that discusses *use* of a registry.

I also don't see anything that describes the use of the "-sess" suffix 
on the algorithm. (It is described in 3261, but solely for MD5-sess.)

I think we could do the draft in such a way that it does utilize a 
registry for algorithms, either the one mentioned above or a new one.

	Thanks,
	Paul

On 1/12/14 8:11 AM, Rifaat Shekh-Yusef wrote:
> The question is around the use of "qop" today which is optional in
> RFC2617 and still under discussion in the HTTP draft to understand the
> impact there.
>
> Regards,
>   Rifaat
>
>
> On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     Thanks Olle,
>>
>>     See my replies inline...
>>
>>     Regards,
>>      Rifaat
>>
>>
>>
>>     On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>
>>         On 11 Jan 2014, at 01:48, Rifaat Shekh-Yusef
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         Hi,
>>>
>>>
>>>         This draft,
>>>         updates the Digest Authentication Scheme used by SIP based on
>>>         the ongoing update to the HTTP Digest Authentication Scheme
>>>         described here:
>>>         The document has one open issue related to the backward
>>>         compatibility with RFC2543/RFC2069. The backward
>>>         compatibility with RFC2069 in the HTTP document is still
>>>         under discussion.
>>>
>>>         From: ** <[email-masked]
>>>         <mailto:[email-masked]>>
>>>         To: Rifaat Shekh-Yusef <[email-masked]
>>>         <mailto:[email-masked]>>
>>>
>>>
>>>
>>>         until the htmlized version and diff are available at
>>>         tools.ietf.org <http://tools.ietf.org/>.
>>>
>>>         The IETF Secretariat
>>>
>>>
>>>         [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 14 Jan 2014 13:49:55 -0500

Hi Paul,

Thanks for reviewing the document and for your comments.
Please, see my reply inline...

Regards,
 Rifaat

On Tue, Jan 14, 2014 at 12:51 PM, Paul Kyzivat <[email-masked]>wrote:

> Is it your intent to change the *default* algorithm? Or simply to add new
> algorithms? You can't really change the default and remain backward
> compatible.
>

Yes, the idea is to make SHA2-256 as the default algorithm.
The server is allowed to send multiple WWW-Authenticate headers with Digest
schemes, but with different algorithms, as described in the HTTP Draft
I have struggled with how much information I need to put in this draft.
The current draft is minimalistic and relies on the HTTP draft to describe
the mechanism in details. Is that ok? should I instead add more details to
this draft that cover the operation of the new mechanism?

> Sorry, I forgot to add the reference; this points to the following HTTP
draft which is expected to obsolete RFC2617:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

The registry was added to the latest version of the draft and there was no
final decision on how to proceed with this, as there were some ideas of
pointing to other similar registries that might have some of these
algorithms.

The references don't define [HTTP-DIGEST].  The registry I was able to find
> is: https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml, and
> I found one draft that adds values to it: RFC 5843. But that rfc says:
>
> I also don't see anything that describes the use of the "-sess" suffix on
> the algorithm. (It is described in 3261, but solely for MD5-sess.)
>
> I do not think that the new algorithms will impact that aspect of the
protocol. Do you?

I think we could do the draft in such a way that it does utilize a registry
> for algorithms, either the one mentioned above or a new one.
>
>         Thanks,
>         Paul
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 15 Jan 2014 00:04:14 +0100

> I have struggled with how much information I need to put in this draft.

Hi, let me understand: Do you mean that if a SIP UA receives a 401
response with multiple WWW-Authenticate headers (having all of them
the same realm,) the UA should be able to select one of them (i.e. the
one with an algorithm that the UA supports)?

Is it that documented by RFC 2617 or 3261?

Another question (assuming "yes" is the response to the above
questions): Are today's SIP UAs really ready to receive multiple
WWW-Authenticate headers (same realm) and select the "best" one?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 14 Jan 2014 18:55:32 -0500

Hi Iñaki,

Regards,
 Rifaat

On Tue, Jan 14, 2014 at 6:04 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> Yes.

>
> Yes. The following is a quote from RFC2617:

   Note: User agents will need to take special care in parsing the WWW-
   Authenticate or Proxy-Authenticate header field value if it contains
   more than one challenge, or if more than one WWW-Authenticate header
   field is provided, since the contents of a challenge may itself
   contain a comma-separated list of authentication parameters.

The new HTTP draft makes this more explicit.

> WWW-Authenticate headers (same realm) and select the "best" one?
They should, according to the above quote from RFC2617.
We had the same question with regards to the browsers and it turned out
that the browsers were able to handle it properly; browsers give preference
to the header that appears first.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Jan 2014 18:57:40 -0500

Inline...

On 1/14/14 1:49 PM, Rifaat Shekh-Yusef wrote:
> On Tue, Jan 14, 2014 at 12:51 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Rifaat,
>
>     Is it your intent to change the *default* algorithm? Or simply to
>     add new algorithms? You can't really change the default and remain
>     backward compatible.
>
>

IIUC, previously (according to 2543 and 3261) MD5 is used if no 
algorithm is specified. And you would propose to change the default in 
that case.

How can that possibly work in a backward compatible way???

I think you can *deprecate* MD5, but not change the default. That means 
that anything conforming to this extension/revision MUST specify an 
algorithm, and not MD5. But it still isn't a default.

> The server is allowed to send multiple WWW-Authenticate headers with
> Digest schemes, but with different algorithms, as described in the HTTP
> Draft
> The current draft is minimalistic and relies on the HTTP draft to
> describe the mechanism in details. Is that ok? should I instead add more
> details to this draft that cover the operation of the new mechanism?

I think it is too minimal. I haven't yet read [HTTP-DIGEST], but I doubt 
it will be sufficient.

>     If the intent is simply to add new algorithms, then ISTM that this
>     can just be an extension to 3261.
>

OK. I'll have to check that out.

> The registry was added to the latest version of the draft and there was
> no final decision on how to proceed with this, as there were some ideas
> of pointing to other similar registries that might have some of these
> algorithms.

I guess you propose to use the same registry for SIP?

>     The references don't define [HTTP-DIGEST].  The registry I was able
>     to find is:
>     https://www.iana.org/__assignments/http-dig-alg/http-__dig-alg.xhtml
>     <https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml>,
>     and I found one draft that adds values to it: RFC 5843. But that rfc
>     says:
>
>     Also, while you mention the registry in iana considerations, I don't
>     see anything that discusses *use* of a registry.
>
>     I also don't see anything that describes the use of the "-sess"
>     suffix on the algorithm. (It is described in 3261, but solely for
>     MD5-sess.)
>

I just took a peek at [HTTP-DIGEST], and see that it defines the "-sess" 
variations.

It appears to me that every algorithm is likely to have a "-sess" 
variant, and the relationship between the two is likely to be the same. 
Do you really want every new algorithm that is registered to be required 
to redefine a "-sess" variant? Or could a generic way be defined for 
deriving a "-sess" variant from an arbitrary algorithm.

>         On Sun, Jan 12, 2014 at 4:36 AM, Olle E. Johansson
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>              On 12 Jan 2014, at 03:27, Rifaat Shekh-Yusef
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>__> wrote:
>
>                  Thanks Olle,
>
>                  See my replies inline...
>
>                  Regards,
>                   Rifaat
>
>
>
>                  On Sat, Jan 11, 2014 at 5:51 AM, Olle E. Johansson
>             <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>                      <[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>__> wrote:
>
>                          Hi,
>
>
>                          This draft,
>                 https://datatracker.ietf.org/__doc/draft-yusef-sipcore-__digest-scheme/
>                 <https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/>,
>                 https://datatracker.ietf.org/__doc/draft-ietf-httpauth-__digest/
>                 <https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/>.
>
>
>                          I would appreciate any feedback on this initial
>                 version of
>                          this document.
>
>
>                      1. If you modify the BNF and other things - doesn't
>             this
>                      update RFC 3261?
>
>
>              Moving forward and leaving MD5 behind is desirable, but
>         maybe not
>              declaring devices
>                         with 2543/2069. What do you think, what would be
>             the effect
>                      if we don't?
>
>
>                  Are there are many deployed systems that comply to
>             RFC2543 but not
>                  RFC3261?
>              If we make this an optional specification, possibly with a
>         supported
>              header, like
>
>              Supported: strongauth
>
>              then we can get rid of the old stuff. And maybe such a
>         header would
>              help migration.
>              The server in that case doesn't have to downgrade to md5
>         and can
>              make a decision
>                      3. I would like to see a section that more clearly
>             defines the
>                      changes compared
>                 <mailto:[email-masked]>
>                          <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                          draft-yusef-sipcore-digest-__scheme-00.txt
>                 <mailto:[email-masked]>
>                          <mailto:[email-masked]
>                 <mailto:[email-masked]>>__>
>
>
>
>                          A new version of I-D,
>                 draft-yusef-sipcore-digest-__scheme-00.txt
>                          has been successfully submitted by Rifaat
>                 Shekh-Yusef and
>                          posted to the
>                          IETF repository.
>
>                          Name:           draft-yusef-sipcore-digest-__scheme
>                          Revision:       00
>                          Title:          The Session Initiation Protocol
>                 (SIP) Digest
>                          Authentication Scheme
>                 http://www.ietf.org/internet-__drafts/draft-yusef-sipcore-__digest-scheme-00.txt
>                 <http://www.ietf.org/internet-drafts/draft-yusef-sipcore-digest-scheme-00.txt>
>                          Status:
>                 https://datatracker.ietf.org/__doc/draft-yusef-sipcore-__digest-scheme/
>                 <https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/>
>                          Htmlized:
>                 http://tools.ietf.org/html/__draft-yusef-sipcore-digest-__scheme-00
>                 <http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-00>
>
>
>                          Abstract:
>                             This document updates the Digest Access
>                 Authentication
>                          scheme used by
>                             the Session Initiation Protocol (SIP) to add
>                 support for
>                          SHA2 digest
>                          Please note that it may take a couple of
>                 minutes from the
>                          time of submission
>                 tools.ietf.org <http://tools.ietf.org>
>                 <http://tools.ietf.org/>.
>
>
>                          The IETF Secretariat
>
>
>                          _________________________________________________
>                          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
>             <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: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 14 Jan 2014 19:37:46 -0500

Inline...

On Tue, Jan 14, 2014 at 6:57 PM, Paul Kyzivat <[email-masked]> wrote:

> IIUC, previously (according to 2543 and 3261) MD5 is used if no algorithm
> is specified. And you would propose to change the default in that case.
>
I see what you saying. I need to think about how to change the text to not
state that we are changing the default, but still prefer SHA2-256.

> I guess you propose to use the same registry for SIP?
Yes

> It appears to me that every algorithm is likely to have a "-sess" variant,
> and the relationship between the two is likely to be the same. Do you
> really want every new algorithm that is registered to be required to
> redefine a "-sess" variant? Or could a generic way be defined for deriving
> a "-sess" variant from an arbitrary algorithm.
>
>
Good point. I will change it in the next version of the draft.

Thanks,
 Rifaat

>>              Do we have to update RFC3261 meaning that everyone is forced
>> to
>>              update to stay
>>                          with 3261/2543 to make it easier for developers
>> to
>>                      understand what they
>>                 http://www.ietf.org/internet-_
>> _drafts/draft-yusef-sipcore-__digest-scheme-00.txt

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 15 Jan 2014 14:51:37 -0500 (EST)

It's great that you are writing this!

The draft as it is now written references "[HTTP-DIGEST]" in many
places, but does not specify what that *is*.  In a sense, this is
unavoidable, since the new HTTP-digest RFC isn't out yet.  But if one
is trying to read *this* draft and figure out its significance, one is
blocked by the fact that this draft is written from the point of view
of being the glue that connects an unspecified document to SIP.  One
solution would be to insert a note that tells the reader the current
draft name for HTTP-DIGEST, a note that would be removed in the formal
publication.

   Since RFC 2543 is based on HTTP Digest as defined in RFC 2069, SIP
   servers supporting [HTTP-DIGEST] MUST ensure they are backwards
   compatible with RFC 2069.  Procedures for this backwards
   compatibility are specified in [HTTP-DIGEST].  Note, however, that
   SIP servers MUST NOT accept or request Basic authentication.

It's not clear to me what "are backwards compatible with RFC 2069"
means, because RFC 2069 deals exclusively with HTTP.  And similarly, a
SIP server doesn't support [HTTP-DIGEST] per se either.  I think you
mean to say, "SIP servers conformant to this specification must be
backwards compatible with SIP digest authentication as specified in
RFC 3261 section 22.4 (which is based on RFC 2069).  The procedures
for backward compatibility in SIP are the same as those specified for
HTTP in [HTTP-DIGEST]."

My larger point is that neither RFC 2069 or [HTTP-DIGEST] applies to
SIP directly; only the modifications of those made by RFC 2543, RFC
3261, and this draft apply to SIP.

          Therefore, any
          algorithms that have a dependency on the cnonce (including
          "MD5-sess", "SHA2-256-sess", and "SHA2-512-256-sess") require 
          that the qop directive be sent.  Use of the "qop" parameter 

I think it would read better as "Therefore, any algorithms that
require that cnonce be sent (including ...".

   RFC 2543 did not allow usage of the Authentication-Info header field
   (it effectively used RFC 2069). However, we now allow usage of this
   header field, since it provides integrity checks over the bodies and
   provides mutual authentication.  ...

There are now three specifications regarding authentication, RFC 2543,
RFC 3261, and "RFC 3261 with the extensions in this document", and you
should make clear which spec enables Authentication-Info.  The text
above seems to say that it is the new draft that enables
Authentication-Info, but looking at RFC 3261 clearly shows a
specification for its use.

   ... [HTTP-DIGEST] defines mechanisms for
   backwards compatibility using the qop attribute in the request. These
   mechanisms MUST be used by a server to determine if the client
   supports the new mechanisms in [HTTP-DIGEST] that were not specified
   in RFC 2069.

The connection of remainder of this paragraph to the previous part is
unclear to me.  It is also unclear what particular "backwards
compatibility" is supported "using the qop attribute", as there are
now at least two extensions and now two levels of backward
compatibility.

And given that this seems to be a very general statement about how
backwards compatibility (vs. digest auth in 3261) is achieved, it
probably should be a separate paragraph.

Perhaps this would be clearer to me if I knew off the top of my head
the details of the security mechanisms defined in these various
documents, and then I would know which document is implied in each
reference.  But it would be a better exposition if one did not have to
be on top of all the details to be able to grasp the overall
structure.

Also, is "qop" a "directive", a "parameter", or an "attribute"?

      request-digest    =  LDQUOT digest-size LHEX RDQUOT
      digest-size       = "32" / "64" 

This doesn't achieve what you want, since it results in
    "32a"
    "62f"
being valid request-digest values.  The problem is that that in the
BNF form "<n>element", "n" must be a literal decimal number.  What you
intend is
      request-digest    =  LDQUOT 32LHEX RDQUOT
                        /  LDQUOT 64LHEX RDQUOT
But I see in RFC 3261 that response-digest (in Authentication-Info) is
syntactically allowed to be variable length:
    Authentication-Info  =  "Authentication-Info" HCOLON ainfo
			    *(COMMA ainfo)
    ainfo                =  nextnonce / message-qop
			     / response-auth / cnonce
			     / nonce-count
    nextnonce            =  "nextnonce" EQUAL nonce-value
    response-auth        =  "rspauth" EQUAL response-digest
    response-digest      =  LDQUOT *LHEX RDQUOT
Why not allow request-digest to be variable length?
      request-digest    =  LDQUOT *LHEX RDQUOT
That prevents the need for further revisions if a larger digest is
ever defined.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2014 15:24:27 -0500

Regarding the hex stuff:

If it is variable length, then it is necessary to specify how it is to 
be padded. If the algorithm forces it to 32 or 64 bits, does it add pad 
on the front or the back?

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 16 Jan 2014 09:31:05 -0500

Hi Dale,

Thanks for your thorough review.

I tried to make the draft short and simple and rely on the HTTP draft for
more details, but that did not seem to work.

I have just submitted a new version of the draft:
http://www.ietf.org/id/draft-yusef-sipcore-digest-scheme-01.txt

With this version I added more details and described the changes compared
to RFC3261, instead of pointing to the HTTP draft.
I hope this is a bit more clear than the -00 version.

Regards,
 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 16 Jan 2014 09:38:05 -0500

Paul,

The digest size depends on the algorithm used; MD5 has an output of 32
hexadecimal characters, and SHA2-256 & SHA2-512/256 have an output of 64
hexadecimal characters.
Take a look at section 2.2 for more details:
http://tools.ietf.org/html/draft-yusef-sipcore-digest-scheme-01#section-2.2

Regards,
 Rifaat

On Wed, Jan 15, 2014 at 3:24 PM, Paul Kyzivat <[email-masked]> wrote:

> Regarding the hex stuff:
>
> If it is variable length, then it is necessary to specify how it is to be
> padded. If the algorithm forces it to 32 or 64 bits, does it add pad on the
> front or the back?
>
>         Thanks,
>         Paul
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 Jan 2014 15:15:50 -0500 (EST)

> From: Paul Kyzivat <[email-masked]>
> 
> Regarding the hex stuff:
> 
> If it is variable length, then it is necessary to specify how it is
> to be padded. If the algorithm forces it to 32 or 64 [hex digits],
> does it add pad on the front or the back?

I wouldn't expect it to be padded at all:  The hash outputs a certain
number of hex digits, and the request-digest has to match, including
the length, or auth fails.

Of course, that the length must match isn't stated anywhere.

But we run into that problem even if the syntax only allows the choice
between 32 or 64 hex digits.

I think we're already running into that problem with
Authentication-Info...

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jan 2014 18:00:44 -0500

Rifaat,

The new version is a definite improvement. Now I have more to comment 
on. :-)

Section 2.1 defines a preference list. How would this be affected by the 
registration of additional algorithms in the future? ISTM that if there 
is reason to have a "standard" preference list, then it ought to be part 
of the registry. (Or perhaps this document should simply state that the 
the challenger should list the algorithms it supports in order of 
strength of the algorithm.

Similarly, section 2.2 specifies the size of the digest per algorithm, 
for the currently defined algorithms. Again, shouldn't this be part of 
the registry, or perhaps there should just be a statement that the 
registry references a document that describes the algorithm, and the 
size of the digest must be specified as part of the algorithm description.

In section 2.4, it might be helpful to state that if the UAC doesn't 
support any of the algorithms in the response that it should abandon 
attempts to send this request.

In section 2.5:

You give a separate definition of H(entity-body) for SHA2-256 and 
SHA2-512-256. But what if some other algorithm from the registry is 
used? ISTM that what is needed is a general mechanism, parameterized by 
the selected algorithm.

Also, I think specifying this as informal deltas to 3261 is going to 
cause a great deal of trouble. I think it would be better to restate 
most or all of section 22.4 with the needed changes applied.

In section 3:

If there is to be a registry, then I think enumerating the values from 
the registry in the ABNF is counter-productive. It will simply lead to 
confusion about what needs to be done to add another algorithm. I 
suggest something along the lines of:

       algorithm =  "algorithm" EQUAL (
                    <digest-alg-name-from-IANA-registry>
                    / token )

(And I'm debating whether 'token' ought to be there. I think not.)

There is then a requirement that new values added to the registry must 
be compatible with the syntax of 'token'. That will need to go into 
[HTTP-DIGEST] that specifies the registry and requirements for adding to 
it.

	Thanks,
	Paul

> I tried to make the draft short and simple and rely on the HTTP draft
> for more details, but that did not seem to work.
>
> With this version I added more details and described the changes
> compared to RFC3261, instead of pointing to the HTTP draft.
> On Wed, Jan 15, 2014 at 2:51 PM, Dale R. Worley <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 19 Jan 2014 11:50:11 +0100

15 jan 2014 kl. 00:55 skrev Rifaat Shekh-Yusef <[email-masked]>:

> We had the same question with regards to the browsers and it turned out that the browsers were able to handle it properly; browsers give preference to the header that appears first.

"They should" is not the same as "they do". We have seen issues with SIP UA's not handling authentication in multiple realms in the same request, like one proxy and one www-auth.
I know that Asterisk doesn't handle that properly.

I think we really need good implementation guidelines followed by online SIPit tests in order to make this happen.

/O

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 19 Jan 2014 06:15:12 -0500

I agree, but just to make it clear, this is also an RFC3261 requirement,
not only an HTTP requirement.
Take a look at the following quote from RFC3261, Section 22.3:

   If a request is forked (as described in Section 16.7), various proxy
   servers and/or UAs may wish to challenge the UAC.  In this case, the
   forking proxy server is responsible for aggregating these challenges
   into a single response.  Each WWW-Authenticate and Proxy-Authenticate
   value received in responses to the forked request MUST be placed into
   the single response that is sent by the forking proxy to the UA; the
   ordering of these header field values is not significant.

Regards,

 Rifaat

On Sun, Jan 19, 2014 at 5:50 AM, Olle E. Johansson <[email-masked]> wrote:

> "They should" is not the same as "they do". We have seen issues with SIP
> UA's not handling authentication in multiple realms in the same request,
> like one proxy and one www-auth.
> I think we really need good implementation guidelines followed by online
> SIPit tests in order to make this happen.
>
> /O
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 19 Jan 2014 15:03:21 +0100

19 jan 2014 kl. 12:15 skrev Rifaat Shekh-Yusef <[email-masked]>:

> I agree, but just to make it clear, this is also an RFC3261 requirement, not only an HTTP requirement.
I agree fully. We have set up tests for this at SIPit, but haven't forced the issue as very few UAs
support it. We do need to fix that.

/O
> I think we really need good implementation guidelines followed by online SIPit tests in order to make this happen.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 19 Jan 2014 15:08:02 +0100

> be on top of all the details to be able to grasp the overall

Ir Dale doesn't understand this off the top of his head, we clearly need very clear
implementor guidelines - maybe in an appendix.

/O