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

From: [email-masked]
Date: Sat, 12 Oct 2019 14:12:23 -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           : 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-03.txt
	Pages           : 14
	Date            : 2019-10-12

Abstract:
   This document defines a mechanism for SIP, that is based on the OAuth
   2.0 and OpenID Connect Core 1.0 specifications, to enable the
   delegation of the user authentication and SIP registration
   authorization to a dedicated third-party entity that is separate from
   the SIP network elements that provide the SIP service.

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-03
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-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: Sat, 12 Oct 2019 17:17:28 -0400

Hi,

We have submitted a new version of the draft that hopefully addresses the
comments we received on the previous version.
Please, take a look and let us know what you think.

Regards,
 Rifaat

On Sat, Oct 12, 2019 at 5:13 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: Sun, 13 Oct 2019 18:15:14 -0400

This version is better. But I still have some concerns:

1) the syntax says that the value of the 'authz_server' parameter of a 
bearer challenge is a quoted-string. The diagram in section 5.1 shows an 
HTTP POST request being sent to the Authorization Server. I find no text 
saying the authz_server value should be an HTTP URL. If this is the 
expectation then make it clear in the syntax. OTOH, if the expectation 
is that the value can be something else, then you need some explanation 
of what it can be and how the UA knows how to use it.

2) section 2.1.1 says:

    The tokens returned to the UA depend on the
    type of server: with an OAuth AS, the tokens provided are the access
    token and refresh token.  With an OpenID Connect server, an
    additional ID-Token is returned, which contains the SIP URI and other
    user specific details.  The method used to authenticate the user and
    obtain these tokens is out of scope for this document, with one
    potential method is the Native App mechanism defined in [RFC8252].

How is it that the UA, using only information from the challenge (namely 
the realm, scope, and authz-server params) works out how to do this?

Is the distinction between OpenID and OAuth AS needed in advance, or can 
the UAC simply open a browser to the AS URL and the end user will be 
able to figure it out. And when the result is returned, are the 
different kinds of results self identifying or not? Please add some text 
to clarify this.

3) RFC3261 indicates (not clearly) the need to handle multiple 
challenges in a response and consequent need to include multiple 
credentials in subsequent requests. With only digest as an 
authentication scheme it is presumably the case that multiple challenges 
will contain *different* realms.

With the addition of bearer as another authentication scheme, there is 
also the possibility of multiple challenges for the *same* realm, one 
for digest and another for bearer. (A given server might support both.) 
In this case presumably the UAC should choose to provide credentials for 
one or the other. (It might defer the choice of which to use to the end 
user through the GUI.)

Because RFC3261 neglected to discuss this possibility I think this draft 
needs to take that on. It could be specified in some way unique to 
bearer, or (better) as a revision to 3261 covering all cases where there 
are multiple challenges for the same realm.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Oct 2019 16:24:02 +0000

Hi Paul, 

Please see inline.
    
>    of what it can be and how the UA knows how to use it.
  
OAuth uses HTTPS, so we can indicate that.

---
  
 >   different kinds of results self identifying or not? Please add some text 
   
Rifaat?

---

>    are multiple challenges for the same realm.
  
Section 22.3 of 3261 says:

      "When a proxy server issues a challenge in response to a request,
      it will not proxy the request until the UAC has retried the
      request with valid credentials.  A forking proxy may forward a
      request simultaneously to multiple proxy servers that require
      authentication, each of which in turn will not forward the request
      until the originating UAC has authenticated itself in their
      respective realm.  If the UAC does not provide credentials for
      each challenge, the proxy servers that issued the challenges will
      not forward requests to the UA where the destination user might be
      located, and therefore, the virtues of forking are largely lost."

So, I am not sure what else we can say regarding multiple challenges from different realms.

If we want to say something about receiving multiple challenges from the *same* realm, we could say something like:

"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, it is RECOMMENDED that the UAC provides 
credentials for each challenge scheme that it supports."

Regards,

Christer