Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-07.txt

From: [email-masked]
Date: Wed, 15 Jan 2020 09:40:09 -0800

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           : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)
        Authors         : Rifaat Shekh-Yusef
                          Christer Holmberg
                          Victor Pascual
	Filename        : draft-ietf-sipcore-sip-token-authnz-07.txt
	Pages           : 14
	Date            : 2020-01-15

Abstract:
   This document defines a SIP mechanism that relies on the OAuth 2.0
   and OpenID Connect Core 1.0 to enable delegation of the user
   authentication and SIP registration authorization to a third-party.
   The document updates RFC 3261.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-07
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-07

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: Wed, 15 Jan 2020 12:42:27 -0500

All,

We have just submitted a new version of the document that hopefully
addresses all the comments received so far.
Please, take a look and let us know what you think.

Regards,
 Rifaat

On Wed, Jan 15, 2020 at 12:40 PM <[email-masked]> wrote:

>         Title           : Third-Party Token-based Authentication and
> Authorization for Session Initiation Protocol (SIP)
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jan 2020 15:12:47 -0500

While reviewing this new version I began to wonder if the general 
procedures for authentication in sip are sufficiently clear and 
unambiguous. This isn't strictly an issue for this draft, but because 
this draft introduces a new authentication scheme along side digest it 
has the potential to aggravate thee issues. ISTM that without answers to 
these issues it will be difficult to deploy this new token authnz draft. 
But that draft may not be the appropriate place to answer them. I'd like 
to hear what others here think is the proper way to deal with this.

My general issue is what to do when, while trying to send a request, a 
UAC receives authorization challenges for multiple schemes and/or 
multiple realms. This can potentially occur in a single 401 response, a 
single 407 response, or some combination of 407 and 401 responses.

Note that a forking proxy may aggregate 401 and 407 responses from 
multiple forks and pass the multiple WWW-Authenticate and 
Proxy-Authenticate responses back to the UAC. How the UAC deals with 
this is also at issue.

Also, if there are multiple authenticating proxies on an unforked path 
from UAC to UAS, then the UAC will receive the challenges one at a time. 
The request will only reach a subsequent proxy after the request is sent 
with adequate credentials for every early proxy in the change. Note that 
this means that the UAC must remember to include the credentials from 
earlier challenges when retrying after a subsequent challenge because 
that subsequent challenge won't include the earlier challenges.

(1) is it valid for a single UAS or proxy to issue concurrent challenges 
specifying differing schemes? I believe it is or should be.

(2) is it valid for a single UAS or proxy to issue concurrent challenges 
on its own behalf specifying differing realms? I'm not sure if this 
makes sense or not. (This is distinct from a forking proxy aggregating 
downstream challenges.)

(3) If a UAS or proxy does issue concurrent challenges specifying 
differing schemes, how is the UAC expected to successfully respond? Is 
the UAC expected to respond with credentials for *each* scheme, or is it 
sufficient to respond to one of them? I am inclined to think that the 
different schemes should be considered alternatives, so that it is 
sufficient to respond to one of them. At least in the case where they 
are for the same realm. It may be more confusing if they are for 
differing realms.

(4) If multiple UASs and/or proxies claim the same realm then are they 
expected to accept the same credentials? I think this must be so, else 
the user and UAC won't be able to sort out what credential to use for a 
given challenge.

Generally, ISTM that the UAC should group challenges by realm, 
attempting to obtain a single set of credentials for each realm. If 
there is more than one realm mentioned in the response, then it should 
obtain a set of credentials for each. And then, if there 407 responses 
to prior attempts to send this same request then the credentials chosen 
for them should also be included in this retry.

What do others think about this? Do you think this is sufficiently 
specified in existing RFCs? If so, can you explain this?

	Thanks,
	Paul

On 1/15/20 12:42 PM, Rifaat Shekh-Yusef wrote:
> On Wed, Jan 15, 2020 at 12:40 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>              Title           : Third-Party Token-based Authentication
>     and Authorization for Session Initiation Protocol (SIP)
>     https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-07
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-07>
> 
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Jan 2020 10:34:26 +0000

Hi Paul,

Regarding (1), you commented on that earlier, and we included the following text (updates 3261):

   "If the UAC receives a 401/407 response with multiple WWW-
   Authenticate/Proxy-Authenticate header fields, providing challenges
   using different authentication schemes for the same realm, the UAC
   provides credentials for one or more of the schemes that it supports,
   based on local policy."

Regarding (2), (3) and (4), I am not sure whether the protocol needs to explicitly forbid those scenarios. A network designer can always mess up things - without breaking the protocol. Perhaps it would be useful to put together a BCP regarding SIP authentication, but it is outside the scope of THIS draft.

So, can we now move the draft forward?

Regards,

Christer

On 15/01/2020, 22.13, "sipcore on behalf of Paul Kyzivat" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    	Thanks,
    	Paul