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

From: [email-masked]
Date: Tue, 28 May 2019 08:31: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-00.txt
	Pages           : 8
	Date            : 2019-05-28

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

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: Tue, 28 May 2019 13:03:50 -0400

All,

We have just submitted this draft as one of the drafts that will replace
the draft-ietf-sipcore-sip-authn draft.
This is based on the discussion of separating the existing draft into two
new drafts that address the different use cases in the original draft.

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

Regards,
 Rifaat

On Tue, May 28, 2019 at 11:31 AM <[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: Tue, 28 May 2019 17:26:26 +0000

Hi,

As far as I know, there should not be anything technically new in this draft: it contains the stuff we agreed to move from draft-ietf-sipcore-sip-authn into a separate draft.

So, my suggestion would be to give interested people a couple of weeks to refresh their minds what it’s all about, and if nothing major comes up then go for WGLC.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Tuesday, 28 May 2019 at 20.04
To: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-00.txt

All,

We have just submitted this draft as one of the drafts that will replace the draft-ietf-sipcore-sip-authn draft.
This is based on the discussion of separating the existing draft into two new drafts that address the different use cases in the original draft.

Regards,
 Rifaat

On Tue, May 28, 2019 at 11:31 AM <[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-00
https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-00<https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-00>

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: Tue, 28 May 2019 13:39:04 -0400

There is some technical addition related to the type of token being issued
(JWT).
Also, the security section is still empty.
I would like to first hear from the WG about their view of the details of
the draft.

So, I do not think the draft is ready to go WGLC at this point.

Regards,
 Rifaat

On Tue, May 28, 2019 at 1:26 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> As far as I know, there should not be anything technically new in this
> draft: it contains the stuff we agreed to move from draft-ietf-sipcore-sip-authn
> into a separate draft.
>
>
>
> So, my suggestion would be to give interested people a couple of weeks to
> refresh their minds what it’s all about, and if nothing major comes up then
> go for WGLC.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *sipcore <[email-masked]> on behalf of Rifaat
> Shekh-Yusef <[email-masked]>
> *Date: *Tuesday, 28 May 2019 at 20.04
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sipcore] I-D Action:
> draft-ietf-sipcore-sip-token-authnz-00.txt
>
>
>
> All,
>
>
>
> https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-00
> <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-00>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 May 2019 18:42:25 +0000

Fair enough – I forgot about the security section.

But, having said that, I still want to point out that this is not new stuff.

Regards,

Christer

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tuesday, 28 May 2019 at 20.39
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-00.txt

There is some technical addition related to the type of token being issued (JWT).
Also, the security section is still empty.
I would like to first hear from the WG about their view of the details of the draft.

Regards,
 Rifaat

On Tue, May 28, 2019 at 1:26 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 28 May 2019 at 20.04
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-00.txt

All,

Regards,
 Rifaat

Abstract:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2019 10:49:45 -0400

What is the intent of this draft? Given the number of TODOs I gather it 
is sort of an indication of intent. It needs a lot more meat.

The overview assumes that the UA knows in advance, without being 
challenged, that the registrar uses this sort of authentication and that 
credentials should be obtained and presented in the first registration 
attempt.

That isn't the way authentication normally works in SIP. Rather, the UA 
would typically attempt to register first, be challenged (with 
WwW-Authenticate), then obtain needed credentials, and finally retry the 
registration with the credentials. It might be that the challenge would 
include *both* a Digest challenge and a Bearer challenge, allowing the 
UA and the user to choose.

So I would expect that to be the case here. It would change the call 
flow in the example, and would use a challenge carrying the new scheme.

The Syntax (section 3) shows a new definition of the Authorization 
header field with the proposed new scheme *instead* of the existing 
Digest scheme. Instead, I would expect to see you defining new values 
for 'auth-scheme' and 'auth-param'. (The mechanism for doing this needs 
discussion. I think it probably calls for a registry of schemes rather 
than changing the syntax.)

Section 4 says it describes syntax of a body, but it only gives an example.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 May 2019 18:58:21 +0000

Hi Paul,

First, to give some background: As I mentioned earlier, note that is not something new. The solution was already documented in draft-ietf-sipcore-sip-authn, that has been around for years. That draft also contained some other stuff, that people had issues with, so we decided to move non-issue parts into a separate draft. Section 4 is new stuff, though.

> What is the intent of this draft? Given the number of TODOs I gather it is sort of an indication of intent. It needs a lot more meat.
>
> The overview assumes that the UA knows in advance, without being challenged, that the registrar uses this sort of authentication 
> and that credentials should be obtained and presented in the first registration attempt.
>
>That isn't the way authentication normally works in SIP. Rather, the UA would typically attempt to register first, be challenged (with WwW->Authenticate), then obtain needed credentials, and finally retry the registration with the credentials. It might be that the challenge would include >*both* a Digest challenge and a Bearer challenge, allowing the UA and the user to choose.
>
>So I would expect that to be the case here. It would change the call flow in the example, and would use a challenge carrying the new scheme.

In some cases the UA WILL know (e.g., by means of configuration or specification) that the registrar supports it.

But, I agree that we can add some more text about the case when the UA does not know.

>The Syntax (section 3) shows a new definition of the Authorization header field with the proposed new scheme *instead* of the existing Digest scheme. >Instead, I would expect to see you defining new values for 'auth-scheme' and 'auth-param'. (The mechanism for doing this needs discussion. I think it >probably calls for a registry of schemes rather than changing the syntax.)

The new scheme was used in draft-ietf-sipcore-sip-authn, and there are deployments based on that, so I would not like to change it at this point.

>Section 4 says it describes syntax of a body, but it only gives an example.

I agree. It also needs to specific (or at least reference) the MIME type.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2019 16:42:56 -0400

On 5/30/19 2:58 PM, Christer Holmberg wrote:
> Hi Paul,
> 
> First, to give some background: As I mentioned earlier, note that is not something new. The solution was already documented in draft-ietf-sipcore-sip-authn, that has been around for years.

Yes, I remember.

> That draft also contained some other stuff, that people had issues with, so we decided to move non-issue parts into a separate draft. Section 4 is new stuff, though.
> 

Yes, but that is a degenerate form of the general case. Its true in 
Digest as well, but only for cached credentials, since with Digest you 
need the challenge to generate credentials. For this new form I guess 
that isn't true, but you *will* need to know whether the registrar uses 
the new form.

Also note that the draft currently doesn't define a way for a 
*challenge* to specify "Bearer". That is needed.

> The new scheme was used in draft-ietf-sipcore-sip-authn, and there are deployments based on that, so I would not like to change it at this point.

What is shown has ABNF of:

        Authorization = "Authorization" HCOLON "Bearer" LWS
                        "access_token" EQUAL access_token COMMA
                        "token_type" EQUAL token_type *(COMMA auth-param)

Note: "=", not "=/", so it can't be directly merged into the SDP ABNF. 
Minimum fix is to change to "=/". But since the existing SDP syntax has 
an extension point defined it is better to hook into that than to go 
around it. There is a need to ensure that the new syntax is backward 
compatible, so it must also match the existing extension syntax. I think 
the above does that, but still it is better to hook into what is there.

This won't change what usages match the syntax so there should be no 
compatibility issue.

Also note that the draft currentl

> I agree. It also needs to specific (or at least reference) the MIME type.

Good.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 May 2019 07:13:29 +0000

Hi,

...
    
>>>> That isn't the way authentication normally works in SIP. Rather, the UA would typically attempt to register first, be challenged (with WwW->Authenticate), 
>>>> then obtain needed credentials, and finally retry the registration with the credentials. It might be that the challenge would include >*both* a Digest challenge 
>>>> and a Bearer challenge, allowing the UA and the user to choose.
>>>

I missed a part of this. There will not be a SIP challenge associated with the scheme. Any challenge will be between the UA and the Authorization Server, and that interface will typically be HTTPS.

Once the UA gets the token from the Authorization Sever , it will include it in the SIP REGISTER request, and the "proxy" will check it with the Authorization Server. But, the "proxy" will not challenge the UA.

Of course, it should still be possible to reject a REGISTER request that does not carry a token to begin with - or a token that cannot be verified by the "proxy" - but I assume there are generic SIP procedures for that.

>    that isn't true, but you *will* need to know whether the registrar uses 
  
Sure. But, even if the UA does not know, it can still try. It may be the only authentication mechanism the UA supports (in case of "web clients" etc).

>    *challenge* to specify "Bearer". That is needed.

See my comment earlier.

>>> The Syntax (section 3) shows a new definition of the Authorization header field with the proposed new scheme *instead* of the existing Digest scheme. 
>>> Instead, I would expect to see you defining new values for 'auth-scheme' and 'auth-param'. (The mechanism for doing this needs discussion. I think it 
>>> probably calls for a registry of schemes rather than changing the syntax.)
>> 

I assume you mean SIP, not SDP?

The syntax of the extension hook ("other-response") is:

Authorization            =  "Authorization" HCOLON credentials
credentials                 =  ("Digest" LWS digest-response) / other-response

other-response         =  auth-scheme LWS auth-param *(COMMA auth-param)
auth-param               =  auth-param-name EQUAL ( token / quoted-string )
auth-param-name   =  token

...so, the "Bearer" syntax fits into that.
   
> Also note that the draft currentl

I assume something got lost here? __

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 May 2019 11:22:26 -0400

> I missed a part of this. There will not be a SIP challenge associated with the scheme. Any challenge will be between the UA and the Authorization Server, and that interface will typically be HTTPS.

I don't understand. If the registrar needs Bearer credentials, and a 
REGISTER is received that doesn't contain one, then surely it must 
challenge, indicating that what it wants are Bearer credentials.

Also, I would expect that there would be more to the challenge - that it 
would indicate what authority/authorities it will accept credentials 
from. E.g., Facebook, Google, ...

Following this, if the challenge indicated "Bearer", I would expect the 
UA to then ask its user to go though the handshake with the 
authentication server to get the credentials. Or, for Digest, to request 
a userid/password from the user.

(On the web, many places that require authentication present the user 
with both alternatives. I would expect the same here.)

> Once the UA gets the token from the Authorization Sever , it will include it in the SIP REGISTER request, and the "proxy" will check it with the Authorization Server. But, the "proxy" will not chal…

What if the credentials are invalid.

(I would not talk about the "proxy" here, as this gets entangled with 
Proxy-Authenticate. I would talk about the *registrar* challenging.)

> Of course, it should still be possible to reject a REGISTER request that does not carry a token to begin with - or a token that cannot be verified by the "proxy" - but I assume there are generic SI…

Yes there are - the registrar can challenge again 401. That is *the* way.

> Sure. But, even if the UA does not know, it can still try. It may be the only authentication mechanism the UA supports (in case of "web clients" etc).

Yes. If the UA has previously obtained credentials, perhaps for access 
to another target, it can preemptively try those for new targets. There 
is little to lose in doing so, as long as the server will challenge if 
they are wrong.

But if the UA doesn't have any credentials, then getting them will 
generally require a user interaction. So the UA isn't likely to want go 
through the process of getting a credential without knowing that doing 
so will be useful. And that it is getting them from the proper server.

>>     *challenge* to specify "Bearer". That is needed.

And mine.

> I assume you mean SIP, not SDP?

Yea, sorry. (I've been discussing SDP a lot recently.)

> ...so, the "Bearer" syntax fits into that.

Yes. But the "=" is still totally wrong. And even with this changed to 
"=/" consider what it will look like when merged into the SIP syntax:

        Authorization =/ "Authorization" HCOLON "Bearer" LWS
                         "access_token" EQUAL access_token COMMA
                         "token_type" EQUAL token_type
                         *(COMMA auth-param)
        access_token = quoted-string
        token_type = quoted-string

Would you write it that way? There is a lot of duplication of common 
syntax, which is confusing.

Instead, I would be write (for the addition):

        credentials  =/ ("Bearer" LWS bearer-response)
        bearer-response = bearer-token COMMA bearer-token-type
        bearer-token = "access_token" EQUAL quoted-string
        bearer-token-type = "token_type" = quoted-string

(I've changed rule names to be less generic, more specific to this case. 
I also would prefer to change "access_token" and "token_type" to 
eliminate use of underscore and make them more specific to this case. 
Perhaps to the same names as I have used for the rules.)

In addition, there is need to extend 'challenge':

        challenge =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))
        bearer-cln = realm

Here I am speculating a bit. At least you need the challenge to specify 
"Bearer". And then, as I noted above, I think you need to indicate which 
Authorization Server(s) are supported. I don't know how those should be 
identified. Here I'm just guessing by reusing "realm". It might instead 
be "domain", or something else.

>> Also note that the draft currentl

I forget. Ignore it.

	Thanks,
	Paul