Subject: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-03.txt

From: [email-masked]
Date: Sun, 26 May 2019 04:35:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : The Session Initiation Protocol (SIP) Digest Authentication Scheme
        Author          : Rifaat Shekh-Yusef
	Filename        : draft-ietf-sipcore-digest-scheme-03.txt
	Pages           : 8
	Date            : 2019-05-26

Abstract:
   This document updates the Digest Access Authentication scheme used by
   the Session Initiation Protocol (SIP) to add support for more secure
   digest algorithms, e.g.  SHA-256 and SHA-512-256, to replace the
   broken MD5 algorithm.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-digest-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-digest-scheme-03
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-digest-scheme-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-digest-scheme-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 May 2019 07:41:46 -0400

Hi,

I appreciate all the feedback and comments.

I believe that with this version of the document I have addressed all the
comments provided so far.
Please, take a look and let me know if I missed anything or if you have any
further comments.

Regards,
 Rifaat

On Sun, May 26, 2019 at 7:36 AM <[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 May 2019 16:49:28 +0000

Hi,

Technically it looks good, but I still have some comments (mostly editorial).

Q1:

Section 2.3 says:

“When a UAS receives a request from a UAC, and an acceptable Authorization header field is not sent,…”

s/sent/received

Q2:

In section 2.3, the text says both “add header fields” and “include header fields”. Please use consistent terminology.

(This comment may apply to other sections too, so please double check).

Q3:

Section 2.4 says:

“When the UAC receives a response with multiple header fields…”

Please add the name of the header fields you are referring to.

Q4:

Section 2.4 says:

“If the UAC cannot respond to any of the challenges in the response,
then it should abandon attempts to send the request; e.g., if the UAC
does not have credentials for any of the realms.”

What if it is a mid-dialog request, e.g., a BYE? If the actions taken by the UAC are based on local policy, it would be good to say so.

Why “should” with small letters?

Q5:

I suggest a “2.X Reference Update” section, that explicitly says that the reference to RFC2617 is replaced to a a reference to RFC7617.

I know it is mentioned in Section 2, but the subsections define the actual updates.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Sunday, 26 May 2019 at 14.42
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-03.txt

Hi,

I believe that with this version of the document I have addressed all the comments provided so far.
Please, take a look and let me know if I missed anything or if you have any further comments.

Regards,
 Rifaat

On Sun, May 26, 2019 at 7:36 AM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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<http://tools.ietf.org>.

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 May 2019 14:51:13 -0400

> header field is not sent,…”
Ok

>
>
> Q2:
>
>
>
> In section 2.3, the text says both “add header fields” and “include header
> fields”. Please use consistent terminology.
>
>
>
> Ok

> Ok

> What if it is a mid-dialog request, e.g., a BYE? If the actions taken by
> the UAC are based on local policy, it would be good to say so.
>
>
Is this a real use case?
If the UAC was able to establish a call then it must already have the
needed credentials and should be able to terminate the call.

> Why “should” with small letters?
I will change to SHOULD.

>
>
> Q5:
>
>
>
> I suggest a “2.X Reference Update” section, that explicitly says that the
> reference to RFC2617 is replaced to a a reference to RFC7617.
>
>
>

Is this really necessary?

Regards,
 Rifaat

>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Rifaat
> Shekh-Yusef <[email-masked]>
> *Date: *Sunday, 26 May 2019 at 14.42
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] I-D Action:
> draft-ietf-sipcore-digest-scheme-03.txt
>
>
>
> Hi,
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 May 2019 19:08:18 +0000

Hi,

... 
 
Q4:
 
> If the UAC was able to establish a call then it must already have the needed credentials and should be able to terminate the call.

It is allowed to challenge a mid-dialog request. Whether it's allowed to require new credentials mid-dialog I don't know. Does 3261 define any restrictions?

If the spec allows things to take place people may define test cases for it, and then there needs to be SOME guidance on what to do.
 
>Why “should” with small letters?

Which would mean that it is allowed to send the request in certain situations.

---

> Is this really necessary?

I was thinking quite a bit about it. I think it needs to be clear - but I guess there can be different opinions on how to make it clear enough.

Regards,

Christer

 
 
From: sipcore <mailto:[email-masked]> on behalf of Rifaat Shekh-Yusef <mailto:[email-masked]>
Date: Sunday, 26 May 2019 at 14.42
To: "mailto:[email-masked]" <mailto:[email-masked]>
Cc: "mailto:[email-masked]" <mailto:[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-digest-scheme-03.txt
 
Hi, 

 
Regards,
 Rifaat

On Sun, May 26, 2019 at 7:36 AM <mailto:[email-masked]> wrote:

Abstract:

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

mailto:[email-masked]

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 May 2019 16:08:30 -0400

On Sun, May 26, 2019 at 3:08 PM Christer Holmberg <
[email-masked]> wrote:

> >> What if it is a mid-dialog request, e.g., a BYE? If the actions taken
> by the UAC are based on local policy, it would be good to say so.
> >
> > Is this a real use case?
> It is allowed to challenge a mid-dialog request. Whether it's allowed to
> require new credentials mid-dialog I don't know. Does 3261 define any
> restrictions?
>
> If the spec allows things to take place people may define test cases for
> it, and then there needs to be SOME guidance on what to do.
>

I do not see the use case, but I will add the following at the end of the
above sentence: "unless a local policy dictates otherwise".

> >> I suggest a “2.X Reference Update” section, that explicitly says that
> the reference to RFC2617 is replaced to a a reference to RFC7617.
> >>
> I was thinking quite a bit about it. I think it needs to be clear - but I
> guess there can be different opinions on how to make it clear enough.
>
>
I do not think that a sub-section is needed in this case.
But I do not have a strong opinion and can go either way.
Do others have an opinion on this?

Regards,
 Rifaat

> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
> From: sipcore <mailto:[email-masked]> on behalf of Rifaat
> Shekh-Yusef <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 May 2019 18:16:35 -0400

On 5/26/19 3:08 PM, Christer Holmberg wrote:
> It is allowed to challenge a mid-dialog request. Whether it's allowed to require new credentials mid-dialog I don't know.

Certainly credentials can expire mid-dialog. I see no reason why they 
can't also change mid-dialog, resulting in failure of the cached 
credentials and a new challenge.

> Does 3261 define any restrictions?

I don't believe so.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 May 2019 19:33:28 -0400

On Sun, May 26, 2019 at 6:16 PM Paul Kyzivat <[email-masked]> wrote:

> require new credentials mid-dialog I don't know.
>
> Certainly credentials can expire mid-dialog.

Why would a proxy challenge a mid-dialog request when the proxy knows that
the UAC's credentials has expired?

I see no reason why they
> This could happen today with the existing digest mechanism. Is there an
existing recommendations for how to deal with such a use case?
I guess one way to deal with this is for the proxy to accept the old
credentials for mid-dialog requests, but require the new credentials for
any new dialog initiating requests.

Regards,
 Rifaat

> > I was thinking quite a bit about it. I think it needs to be clear - but
> I guess there can be different opinions on how to make it clear enough.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 May 2019 21:57:25 -0400

On 5/26/19 7:33 PM, Rifaat Shekh-Yusef wrote:
> 
> 
> On Sun, May 26, 2019 at 6:16 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >>> What if it is a mid-dialog request, e.g., a BYE? If the actions
>     taken by the UAC are based on local policy, it would be good to say so.
>      >>
>      >> Is this a real use case?
>      >> If the UAC was able to establish a call then it must already
>     have the needed credentials and should be able to terminate the call.
>      >
>      > It is allowed to challenge a mid-dialog request. Whether it's
>     allowed to require new credentials mid-dialog I don't know.
> 
> Why would a proxy challenge a mid-dialog request when the proxy knows 
> that the UAC's credentials has expired?

I was thinking of the credentials at the UAS expiring. But I suppose it 
could happen for Proxy-Authenticate as well.

It *is* unusual for a non-registrar UAS requiring credentials, but it is 
possible.

> any new dialog initiating requests.

I'm not aware of any recommendations in this regard. I think it falls 
into the realm of policy.

Again, I don't know why you are bringing up proxies.

But these are all somewhat obscure cases based on current practice.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 May 2019 22:11:02 -0400

When I said "proxy" I was thinking of both registrar and proxy.
But I agree with you that these are obscure use cases that better left for
a local policy to deal with.

Regards,
 Rifaat