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

From: [email-masked]
Date: Sat, 19 Oct 2019 13:20:11 -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-04.txt
	Pages           : 14
	Date            : 2019-10-19

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

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

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, 19 Oct 2019 16:23:00 -0400

All,

We update the draft based on the latest comments, mainly from Paul.
Please, take a look and let us know what you think.

Regards,
 Rifaat

On Sat, Oct 19, 2019 at 4:21 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: Christer Holmberg <[email-masked]>
Date: Sat, 19 Oct 2019 22:03:54 +0000

Hi,

We also added text about using token claims for granting access, as requested by Olle.

Regards,

Christer

Lähettäjä: sipcore <[email-masked]> Puolesta Rifaat Shekh-Yusef
Lähetetty: lauantai 19. lokakuuta 2019 23.23
Vastaanottaja: SIPCORE <[email-masked]>
Aihe: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-04.txt

All,

Regards,
 Rifaat

On Sat, Oct 19, 2019 at 4:21 PM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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

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: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Oct 2019 11:40:23 -0400

Rifaat,

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

Thanks. This is better. I have some followup questions to broaden my 
understanding. (Once I understand better, I may have some suggestions on 
how to make the document clearer in this regard.)

IIUC, upon getting a challenge for which there is no cached response, 
the typical expected behavior for a UA is to launch a browser using the 
URL from the authz-server-value in the challenge. Is that right?

I'm not clear on the sequence of events following that. IOW, I'm looking 
for more detail on step [3] in the figure in section 5.1. I would expect 
that this first action of the browser will result in the AS returning a 
form to the browser that will be displayed to the user. Then the user 
will presumably need to fill in that form and send it to the AS. And 
this may involve a dialog of multiple exchanges. This will presumably 
eventually end with a response from the AS containing a token. How does 
the UA recognize this as the completion of the dialog?

In particular, does the UA need to know anything about the AS or the 
authentication environment in which it is operating? Or is this 
consistent across all types of AS?

Also, I gather there can be different kinds of token in the response. Is 
this of concern to the UA? Or does the UA blindly pass the resulting 
token on to the registrar, so that the registrar can decide what to do 
with it?

Another point I want to follow up on is: you have now clarified that the 
authz-server-value contains a URL referencing the AS. Why not tighten 
the syntax to specify the allowed value types? I presume you intend this 
to be something that a browser can use to query the AS. The obvious type 
for this is an HTTPS URL. I am guessing that you are leaving this vague 
to allow other types that might be supported by browsers and ASs. But 
presumably there is something you can say about the properties expected 
of this URL. I guess it ought to be something that is generally 
supported by browsers, and that can be used to reference forms. (E.g., a 
SIP URL wouldn't be appropriate here.)

	Thanks,
	Paul

> 
> Regards,
>   Rifaat
> 
> 
> On Sat, Oct 19, 2019 at 4:21 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-04
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-04>
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 22 Oct 2019 20:45:32 -0400

> the UA recognize this as the completion of the dialog?

In this specific case, take a look at the following flow in the RFC that
defines this mechanism:
https://tools.ietf.org/html/rfc8252#section-4.1

> The UA needs to know if it is an OAuth AS or and OpenID Connect server to
know to request access and refresh tokens only or in addition to ask for an
id token.

> The UA will only pass the Access Token to the registrar.
The refresh token is used by the UA to obtain new access token from the AS
and will never be passed to any other entity.
The id token is consumed by the UA only to get more information about the
user, e.g. SIP AOR.

> the syntax to specify the allowed value types?

Can you elaborate on what you mean "value types"?

Regards,
 Rifaat

> I presume you intend this
> >     https://datatracker.ietf.
> .org/doc/html/draft-ietf-sipcore-sip-token-authnz-04
> >     <

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Oct 2019 11:37:47 -0400

On 10/22/19 8:45 PM, Rifaat Shekh-Yusef wrote:
> 
> 
> On Mon, Oct 21, 2019 at 11:40 AM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Rifaat,
> 

I don't find that at all useful because it abstracts away all the useful 
bits. This implies an interface between the client app and the browser. 
What is that interface? Where is it defined? This is needed to implement 
a client app. Specifically:

- what information is passed in (1)? (Just the URL?) And how?

- what information does the client app expect back in (4)? How is it 
encoded?

- the figure shows just one round trip (2) and (3) between the broswer 
and the AS. Is that always the case? Doesn't this potentially require 
multiple round trips? How does the browser know it is time to return to 
the client app?

- is the SIP UAS that is requesting authorization (e.g. registrar) the 
token endpoint in figure 4.1?

> The UA needs to know if it is an OAuth AS or and OpenID Connect server 
> to know to request access and refresh tokens only or in addition to ask 
> for an id token.

How does it know that? Isn't that a function of what the SIP UAS 
requesting authorization wants?

> The refresh token is used by the UA to obtain new access token from the 
> AS and will never be passed to any other entity.
> The id token is consumed by the UA only to get more information about 
> the user, e.g. SIP AOR.

None of this is clear from your draft.

Perhaps you could start by reproducing Figure 1 from 
https://tools.ietf.org/html/rfc8252#section-4.1 but changing the labels 
of the components to map them on to the elements in your draft.

> Can you elaborate on what you mean "value types"?

Instead of defining the syntax as a quoted string, you could use ABNF 
for an HTTP/HTTPS URL. Or if you want it more general than that you 
could give generic URL syntax and use text to describe which kinds of 
URL are (and are not) suitable. (E.g. I imagine that SIP: and FILE: URLs 
are probably not suitable. I don't know what would be beyond HTTP and 
HTTPS.)

	Thanks,
	Paul

>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >     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.
>      >
>      >              Filename        :
>     draft-ietf-sipcore-sip-token-authnz-04.txt
>      >              Pages           : 14
>      >              Date            : 2019-10-19
>      >
>      >     Abstract:
>      >         This document defines a mechanism for SIP, that is based
>     on the
>      >     OAuth
>      >         authorization to a dedicated third-party entity that is
>     separate
>      >     from
>      >     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>
>      >     <http://tools.ietf.org>.
>      >
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 23 Oct 2019 17:48:43 -0400

On Wed, Oct 23, 2019 at 11:37 AM Paul Kyzivat <[email-masked]> wrote:

> RFC8252 describes how the mechanism works in details, but all of this is
really out of scope for this document.

> Configuration. I will add some text to cover that.

> Fair enough. I will add these details to the draft.

> for an HTTP/HTTPS URL.

I will do that.

Thanks,
 Rifaat

> Or if you want it more general than that you
> >      >     Please note that it may take a couple of minutes from the
> time of
> >      >     submission