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

From: [email-masked]
Date: Thu, 24 Oct 2019 17:51:17 -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-05.txt
	Pages           : 14
	Date            : 2019-10-24

Abstract:
   This document updates RFC 3261 and 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-05
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-05

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

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: Thu, 24 Oct 2019 20:54:16 -0400

All,

We believe that with this version we have addressed the latest comments
received on the previous version.
Please, take a look and let us know what you think.

Regards,
 Rifaat

On Thu, Oct 24, 2019 at 8:52 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, 30 Oct 2019 12:47:09 -0400

Hi Rifaat,

> Please, take a look and let us know what you think.

I'm still struggling to understand what the expectations are of the UA 
in this process.

IIUC, when the registrar/server/proxy generates a "Bearer" challenge 
specifying a particular AS, that implies that it has knowledge of that 
AS and how to deal with it. And it may well have relationships with 
multiple ASs, and challenge using them all. And there is an assumption 
that either UA or the *user* of the UA must have a relationship with at 
least on of the ASs to use for authentication.

My thought is that commonly the UA itself *won't* have a relationship 
with the AS. Rather it will expect the user to be the one to have that. 
In this case, can the UA have generic code that deals with any possible AS?

With web authentication I commonly experience an authentication popup 
that offers alternatives. (E.g., facebook or google or private local 
id/pw authentication.) The user then gets to pick one, and then 
authenticate with a corresponding AS. I am thinking the SIP process 
could be the same. The alternatives offered to the user would correspond 
to all the challenges (both Bearer and digest) for a single realm.

Is this a use case you have in mind as being covered?

(Of course, it may be that a UA is build to not depend on the user for 
authentication. In that case it must be preconfigured with credentials. 
But that isn't really no different from preloading the credential cache. 
And I guess it might be configured to only work with a single AS.)

Based on your updates, I think I get it that the result from the AS to 
the UA access, refresh and possible id tokens, that only the access 
token is destined to be included in bearer credentials. The UA must know 
to use the refresh token to refresh its access token. And the UA may 
know to use the ID token for something (what?).  Is any of this 
knowledge AS-specific, or is it all generic?

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> On Thu, Oct 24, 2019 at 8:52 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-05
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-05>
> 
>     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: Wed, 30 Oct 2019 19:13:32 +0000

Hi,

>least on of the ASs to use for authentication.

Correct.

>In this case, can the UA have generic code that deals with any possible AS?

Yes. The interface between the UA and the AS is standardized.

>Is this a use case you have in mind as being covered?

I assume that the registrar could offer multiple AS(s), and then the user chooses one that it has a relationship with. Especially if the operator is using 3rd party AS(s), like Facebook, Google etc.

However, the operator might also use its own AS (or have a relationship with a specific 3rd party AS), where the user relationship with the AS is part of the user subscription, and in that case the registrar most likely will only return that AS (because it knows the user has a relationship with it).

>knowledge AS-specific, or is it all generic?

It is part of the standardized OAuth procedures.

Regards,

Christer