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

From: [email-masked]
Date: Sun, 07 Jul 2019 04:16:51 -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-02.txt
	Pages           : 12
	Date            : 2019-07-07

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

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

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: Sun, 7 Jul 2019 07:19:52 -0400

All,

We have submitted a new version of the document based on the feedback
provided so far.
Please, take a look at let us know what you think.

Regards,
 Rifaat

On Sun, Jul 7, 2019 at 7:18 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: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Jul 2019 12:56:04 -0400

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

This is better. I still have a few thoughts:

* Regarding WWW-Authenticate:

I believe it will how be possible for a server to support both Digest 
and Bearer. I think this means that the client can use either depending 
on what sort of credentials it or its user happen to know.

I think it would be good to mention this. I guess in principle the 
client could return credentials for both. In that case, I don't know 
whether both must be valid or if it is sufficient for one to be valid. 
Perhaps we need to discuss that. (Presumably only credentials for a/the 
realm that the server supports are to be considered, with those for 
other realms being ignored.)

* Regarding non-registration requests (and maybe registration requests too):

    The UA MUST NOT insert a token in a non-REGISTER request, unless the
    non-REGISTER request has been challenged, or the peer is considered a
    trusted entity.

What is a trusted entity? In any case I think this is too strong. Once a 
request has been challenged the client knows this target wants the 
credentials. We certainly don't want to force every subsequent request 
to the same target to take two round trips, one without credentials and 
then one with. So the client needs to associate these credentials with 
this target, for awhile. But that begs the question of how long to 
retain this association. In the case of Digest, a nonce eventually 
expires and the old credentials fail and get forgotten and replaced by 
new ones. I guess the life cycle will be somewhat different for Bearer. 
This needs some thought and discussion.

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> 
> On Sun, Jul 7, 2019 at 7:18 AM <[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-02
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-02>
> 
>     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: Mon, 8 Jul 2019 19:30:16 +0000

Hi,

>I believe it will how be possible for a server to support both Digest and Bearer. I think this means that the client 
>can use either depending on what sort of credentials it or its user happen to know.
>
>I think it would be good to mention this. I guess in principle the client could return credentials for both. In that case, I don't 
>know whether both must be valid or if it is sufficient for one to be valid. 
>Perhaps we need to discuss that. (Presumably only credentials for a/the realm that the server supports are to 
>be considered, with those for other realms being ignored.)

I think that is outside the scope of the draft. There could be multiple variants of multiple challenges.

And, RFC 3261 already talks generally about multiple challenges. I do think some of the 3261 text could be improved and clarified, but that should be done as a separate task.

> What is a trusted entity?

I asked that to be added, but it can be removed.

> In any case I think this is too strong. Once a request has been challenged the client knows this target wants the credentials. 
> We certainly don't want to force every subsequent request to the same target to take two round trips, one without credentials 
> and then one with. So the client needs to associate these credentials with this target, for awhile. But that begs the question of 
> how long to retain this association. In the case of Digest, a nonce eventually expires and the old credentials fail and get forgotten 
> and replaced by new ones. I guess the life cycle will be somewhat different for Bearer. 

From a generic perspective I think 3261 should describe how credentials are provided in subsequent requests.

As far as tokens are concerned, I am not sure it's within the scope of this draft to define the lifetime of token credentials, as they are not SIP specific.

Having said that, I DO agree with you that the current came out too strong - and wrong: my intention was to say that credentials from a REGISTER request are not placed in a non-REGISTER request.

BUT, if a non-REGISTER requests gets challenged, we should allow the client to include the credentials in subsequent non-REGISTER requests - at least within the same session (in case of session related requests).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 8 Jul 2019 18:45:37 -0400

> And, RFC 3261 already talks generally about multiple challenges. I do think some of the 3261 text could be improved and clarified, but that should be done as a separate task.

While I agree in principle that this is in some sense independent of the 
individual schemes, Bearer is what pushes this from one to two, which is 
when the issue appears. So IMO it makes sense to say something about it 
here. Saying that it *ought* to be in 3261 is fine, but in practice that 
is simply saying that it isn't going to be considered at all.

>  From a generic perspective I think 3261 should describe how credentials are provided in subsequent requests.

See my comment above on what ought to go in 3261.

> As far as tokens are concerned, I am not sure it's within the scope of this draft to define the lifetime of token credentials, as they are not SIP specific.

I'm not too much concerned with the *lifetime* of the token, since that 
will pretty much take care of itself. (When it exceeds its lifetime it 
will stop working.)

But I suspect there might be security concerns here, and that they may 
be different from those that apply to Digest.

It *may* be that it would be fine to include the token in every request, 
regardless of target - that doing so won't cause any security concerns. 
Conversely, that might not be so.

IIUC, similar tokens are used for single-signon, so perhaps there are 
guidelines that can be repurposed for use here. But I think *something* 
needs to be said or else implementors won't know what to do and the 
result will be interop problems.

> BUT, if a non-REGISTER requests gets challenged, we should allow the client to include the credentials in subsequent non-REGISTER requests - at least within the same session (in case of session rel…

ISTM that is also too strong. If I used a token for REGISTER, and then I 
do something else (e.g., SUBSCRIBE) with the same server, then it should 
be fine to use it in other requests directed to the same server. And 
possibly to other servers as well. You seem to be assuming that 
credentials for registration are somehow different from credentials for 
other things. It is up to the servers in question to decide that, not 
this protocol document.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 07:18:18 +0000

Hi,

>>> and Bearer. I think this means that the client can use either depending on what sort of credentials it or its user happen to know.
>>>
>>> client could return credentials for both. In that case, I don't know whether both must be valid or if it is sufficient for one to be valid.
>>> Perhaps we need to discuss that. (Presumably only credentials for 
>>> a/the realm that the server supports are to be considered, with those 
>>> for other realms being ignored.)
>> 
> While I agree in principle that this is in some sense independent of the individual schemes, Bearer is what pushes this from one to two, which 
> is when the issue appears. So IMO it makes sense to say something about it here. Saying that it *ought* to be in 3261 is fine, but in practice that is 
> simply saying that it isn't going to be considered at all.

I am saying that the procedures should be in one place, and that's RFC 3261. 

And, as 3261 already talks about multiple challenges/credentials, I don't think Bearer is pushing this.

Having said that, we can for sure reference the 3261 procedures in the draft, but I don't think the draft is the place where to describe SIP usage of multiple challenges/credentials.

>>> We certainly don't want to force every subsequent request to the same 
>>> target to take two round trips, one without credentials and then one 
>>> with. So the client needs to associate these credentials with this 
>>> target, for awhile. But that begs the question of how long to retain this association. In the case of Digest, a nonce eventually 
>>> expires and the old credentials fail and get forgotten and replaced by new ones. I guess the life cycle will be somewhat different for Bearer.
> I'm not too much concerned with the *lifetime* of the token, since that will pretty much take care of itself. (When it exceeds its lifetime it will stop working.)
>
> But I suspect there might be security concerns here, and that they may be different from those that apply to Digest.
>
> It *may* be that it would be fine to include the token in every request, regardless of target - that doing so won't cause any security concerns. 
> IIUC, similar tokens are used for single-signon, so perhaps there are guidelines that can be repurposed for use here. But I think *something* 
> needs to be said or else implementors won't know what to do and the result will be interop problems.
>
>> Having said that, I DO agree with you that the current came out too strong - and wrong: my intention was to say that credentials 
>> from a REGISTER request are not placed in a non-REGISTER request.
>> 
>> BUT, if a non-REGISTER requests gets challenged, we should allow the client to include the credentials in subsequent non-REGISTER 
>> requests - at least within the same session (in case of session related requests).
>
> ISTM that is also too strong. If I used a token for REGISTER, and then I do something else (e.g., SUBSCRIBE) with the same server, 
> then it should be fine to use it in other requests directed to the same server. 

Fair enough, if you know the server is the same.

> And possibly to other servers as well. You seem to be assuming that credentials for registration are somehow different from credentials 
> for other things. It is up to the servers in question to decide that, not this protocol document.

As I said in another reply, if you by default place a REGISTER token in a non-REGISTER request the token may reach the remote peer, which could be a security concern. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Jul 2019 10:29:11 -0400

> As I said in another reply, if you by default place a REGISTER token in a non-REGISTER request the token may reach the remote peer, which could be a security concern.

I would like to hear more about this. Is there something about the token 
that reveals stuff that might not be suitable to expose to everyone? I 
personally don't know. This seems like something that ought to be 
discussed in security considerations.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 15:42:02 +0000

Hi,
    
>    discussed in security considerations.
  
The token itself does not reveal anything, but in OAuth the token is used to access the requested resource, so it is considered sensitive information.

As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. I have never heard about anyone using it for non-REGISTER authentication, and I wonder whether we even need to cover it in the draft. We could limit the scope the REGISTER requests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separate draft can be written.

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 9 Jul 2019 12:24:23 -0400

On Tue, Jul 9, 2019 at 11:43 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >> As I said in another reply, if you by default place a REGISTER token in
> a non-REGISTER request the token may reach the remote peer, which could be
> a security concern.
> >
> The token itself does not reveal anything,

That depends on the type of token.
A JWT might contain data that must be protected for privacy reasons.

but in OAuth the token is used to access the requested resource, so it is
> considered sensitive information.
>
>
Yeah, because these are *bearer *tokens it means that they are not bind to
a specific UA.
There are ways to bind a token to a specific UA (see RFC7800), but this is
out of scope for this document

Regards,
 Rifaat

> As far as I know, OAuth for SIP has only been used for REGISTER requests,
> between the UA and the registrar. I have never heard about anyone using it
> for non-REGISTER authentication, and I wonder whether we even need to cover
> it in the draft. We could limit the scope the REGISTER requests. Then, if
> anyone ever needs OAuth for non-REGISTER requests, a separate draft can be
> written.
>
> Regards,
>
> Christer
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Jul 2019 12:25:54 -0400

> As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. I have never heard about anyone using it for non-REGISTER authentication, and I wonder wh…

Yes, you can do that if you wish. But ISTM that the issues are largely 
the same so I don't know why you would do that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 16:28:43 +0000

Hi,

>> As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. I have never heard about anyone using
>> it for non-REGISTER authentication, and I wonder whether we even need to cover it in the draft. We could limit the scope the REGISTER requests. 
>> Then, if anyone ever needs OAuth for non-REGISTER requests, a separate draft can be written.
>    

The REGISTER request, and the token, will only reach the registrar.

Regards,

Christer

    	Thanks,
    	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 16:35:43 +0000

Hi,

> A JWT might contain data that must be protected for privacy reasons.
 
Correct. My mistake.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 9 Jul 2019 12:55:29 -0400

> The REGISTER request, and the token, will only reach the registrar.

And any proxies on the path to the registrar.

But if I send an INVITE, am challenged by the target of the INVITE, and 
then send the token in a retry of the INVITE then it only goes there, 
where it is supposed to go. How is that any different from the registrar 
case? Is it because I somehow trust the registrar more that I trust who 
I am calling?

ISTM that what is more important is the relationship between the domain 
of the UAS I'm trying to contact and the realm of the challenge. (Do I 
think this server has any business claiming to be authenticate for this 
realm?)

The other tricky part is deciding whether to send the cached credentials 
(token) in a new request that hasn't just immediately challenged. But 
note that the request "in response" to a challenge is indistinguishable 
from a request sent to the same target later other than by time delay. 
The security concerns should be the same. Sending the token to some 
other target before being challenged by that target is a different leap 
of faith, so has different concerns.

My main point here is not to get you to explain it to me in this email 
thread. What I want is to see this discussed adequately in the security 
considerations of the document. If it isn't "safe" to send the token to 
everybody, then how do I decide who I can safely send it to?

One partial answer might be: if a challenge results in asking the user 
to authenticate for the realm, then the user gets to decide if he wants 
to, and if so then the resulting token should be sent to the same target 
just then. But this doesn't address when the same token can be used 
preemptively later. That still needs discussion.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 17:45:50 +0000

Hi,

>    And any proxies on the path to the registrar.
  
Sure, and that we do need to cover: the token needs to be protected.
  
>    case? Is it because I somehow trust the registrar more that I trust who 
  
I assume most people trust their registrar. If you don't, you obviously can't use the mechanism. We can for sure add text to clarify that, if needed.

And, you can for sure decide to trust the one you are calling. But, again, I still think we could leave user-to-user authentication out of scope of the draft. The scope has been using OAuth for registrations from day one, and that is what people have been asking for. 

Also, after people had raised issues with the previous draft, we agreed to only move the current parts into the new draft.

>    preemptively later. That still needs discussion.
  
OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using the token in binding refresh REGISTER requests is fine.

But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 14:27:51 -0400

> anyone ever needs OAuth for non-REGISTER requests, a separate draft can be
Really? Normally, for a secure solution, every SIP request, including
requests sent by UA in dialog established from the server to the registered
end point must be authenticated. OAuth for REGISTRER requests only is kind
of useless since it does not allow UA to send any messages to the server
without some additional authentication mechanism.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 19:11:19 +0000

Hi,

>> As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. 
>> I have never heard about anyone using it for non-REGISTER authentication, and I wonder whether we even need 
>> to cover it in the draft. We could limit the scope the REGISTER requests. Then, if anyone ever needs OAuth for non-REGISTER requests, a separate draft can be written.
> 
> Really? Normally, for a secure solution, every SIP request, including requests sent by UA in dialog established from the 
> server to the registered end point must be authenticated. OAuth for REGISTRER requests only is kind of useless since it 
> does not allow UA to send any messages to the server without some additional authentication mechanism.

Not sure what you mean by "secure solution", but UAs can still use SIP Digest authentication.

What I am saying is that only use-case for SIP OAuth I am aware of is for REGISTER.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 15:29:16 -0400

On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg <
[email-masked]> wrote:

> >> As far as I know, OAuth for SIP has only been used for REGISTER
> requests, between the UA and the registrar.
> >> I have never heard about anyone using it for non-REGISTER
> authentication, and I wonder whether we even need
> >> to cover it in the draft. We could limit the scope the REGISTER
> requests. Then, if anyone ever needs OAuth for non-REGISTER requests, a
> separate draft can be written.
> >
> requests sent by UA in dialog established from the
> > server to the registered end point must be authenticated. OAuth for
> REGISTRER requests only is kind of useless since it
> How do they get these SIP Digest credentials?

I am looking at a very simple SIP-Over-Websockets client scenario:

User logs into the web site which uses OAuth. UA, running in the browser
gets a token which is used to Register UA with a SIP proxy.

What credentials is UA using to place a call (send INVITE to the proxy)?
If a call comes in from the proxy to UA, what credentials is UA using to
hang up the call (send BYE message)?

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 9 Jul 2019 20:00:23 +0000

Hi,

> User logs into the web site which uses OAuth. UA, running in the browser gets a token which is used to Register UA with a SIP proxy.

Wouldn't  you use OAuth to establish the WebSocket connection?

>If a call comes in from the proxy to UA, what credentials is UA using to hang up the call (send BYE message)?

If the registry and the call handling is part of the same service I guess you could use the same credentials, assuming 3261 generally allows using the same credentials for registrations and calls.

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 9 Jul 2019 17:16:39 -0400

This document is specifically focused on *confidential *UAs.
UAs running in the browser, public UAs, will be addressed in a separate
document.

Regards,
 Rifaat

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 18:57:44 -0400

> Wouldn't  you use OAuth to establish the WebSocket connection?

No, WebSocket connection is to a different server and typically does not
require authentication. In this specific case, I was thinking OpenSIPS with
SIP-over-WS support. Implementing OAuth authentication of SIP message would
be trivial there, but OAuth authentication for WebSocket would be much less
obvious.

> If the registry and the call handling is part of the same service I guess
> you could use the same credentials, assuming 3261 generally allows using
> the same credentials for registrations and calls.
>

Are you saying using OAuth token authentication for calls (INVITE) and in
dialog messages (BYE)?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 18:59:50 -0400

Hi Riffat,

> UAs running in the browser, public UAs, will be addressed in a separate

Can you provide a real life example of confidential UA using OAuth for
registration only and not generating calls or sending any messages in
dialog (or using different authentication method for these actions)?

I cannot quite figure out what this is.

Thank You,
_____________
Roman Shpount

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 9 Jul 2019 19:17:45 -0400

> dialog (or using different authentication method for these actions)?

What? why do you think that is the case?
How did you get to the conclusion that the UA will not be able to make a
call?

Regards,
 Rifaat

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 19:27:24 -0400

> How did you get to the conclusion that the UA will not be able to make a
Quoting Christer:

it in the draft.

So, I am trying to understand the use case where:

1. UA is confidential
2. OAuth is used for registration only
3. Other messages are not sent or different authentication method is used
for them, i.e. calls and in dialog messages are not initiated or initiated
using a different authentication method.

So far, I cannot figure out what this is.

Best Regards,
_____________
Roman Shpount

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 9 Jul 2019 20:30:26 -0400

The document clearly allows the use of access token to authenticate
non-REGISTER requests when challenged in the context of the same realm.

Whether that is needed or not is a different discussion.
Assuming the UA was able to authenticate the user and obtain an access
token, then establish an authenticated TLS channel with the server, and
register the user; is there a need for further challenges from server?

Regards,
 Rifaat

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 20:53:40 -0400

> register the user; is there a need for further challenges from server?
Typically, for SIP, user authentication is not tied to the TLS connection.
One of the reasons for this is that multiple users can use the same TLS
connection in federated systems. This is especially true for Confidential
UA, which have trust relationship with a proxy and can maintain a secure
connection to the registrar/proxy on behalf of multiple clients.

Once again, it would be much easier to discuss if you can provide a use
specific case for OAuth with confidential UA. I can easily think of a OAuth
use case for Public User Agent, but only have a vague idea what OAuth with
Confidential UA would be.

The example I can think of, would be some sort of hot desk application,
where user allows a Local PBX to register with User Home PBX to accept
calls on behalf of user in a remote location. In this case, Local PBX and
User Home PBX will be federated systems which will use a single TLS
connection for multiple calls or end user devices. Local PBX and User Home
PBX will have a trust relationship, possibly with mutual TLS certificate
authentications. A company wide directory server will be used to store
actual user credentials and will be used to authenticate the user and
generate the token.

Best Regards,
_____________
Roman Shpount

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 9 Jul 2019 21:28:58 -0400

For me, the main motivation is SSO.
The user would use one set of corporate credentials to authenticate, login
to a deskphone, and get access to SIP and non-SIP services.

I am not sure I am following your use case.
How would the user authenticate and obtain a an access token in this case?

Regards,
 Rifaat

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 21:44:37 -0400

> How would the user authenticate and obtain a an access token in this case?
The use case is the same SSO in combination with hot desks and multiple
PBXs. User picks a desk at a remote office, goes to a web page to login,
enters his credentials and desk location. Expected result is that the phone
on this temporary desk will ring when user gets a call on user's extension
on the user home PBX. Internally, SSO system produces a token, which is
sent to the PBX in the remote office. PBX in the remote office registers
using this token with use home PBX, and configures that all the calls for
this registration are forwarded to the phone on the user temporary desk.
All the calls placed from that desk are also placed through user home PBX
so that correct line is used and user home caller ID is displayed.

Best Regards,
_____________
Roman Shpount

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 9 Jul 2019 21:58:54 -0400

Such a use case is not covered by this document, and is out of scope.

Regards,
 Rifaat

On Tue, Jul 9, 2019 at 9:44 PM Roman Shpount <[email-masked]> wrote:

>> The user would use one set of corporate credentials to authenticate,
>> login to a deskphone, and get access to SIP and non-SIP services.
>>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Jul 2019 23:28:49 -0400

Can you then explain, what is covered, ideally providing a real world use
case?

Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 08:36:28 +0200

Here’s one example:

Many web apps and mobile apps already use OpenID connect for single sign on. The  tokens may now include a scope for the SIP platform,
which means that the app can open SIP over WebSockets and authenticate with the same set of tokens as for other backend services to the
SIP service.

The SIP service must now validate the tokens with the IDP. 

/O

> On 10 Jul 2019, at 05:28, Roman Shpount <[email-masked]> wrote:
> 
> Can you then explain, what is covered, ideally providing a real world use case?
> 
> Roman Shpount
> 
> On Tue, Jul 9, 2019, 21:59 Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Jul 9, 2019 at 9:44 PM Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Jul 9, 2019 at 9:29 PM Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
> The user would use one set of corporate credentials to authenticate, login to a deskphone, and get access to SIP and non-SIP services.
> 
> The use case is the same SSO in combination with hot desks and multiple PBXs. User picks a desk at a remote office, goes to a web page to login, enters his credentials and desk location. Expected result is that the phone on this temporary desk will ring when user gets a call on user's extension on the user home PBX. Internally, SSO system produces a token, which is sent to the PBX in the remote office. PBX in the remote office registers using this token with use home PBX, and configures that all the calls for this registration are forwarded to the phone on the user temporary desk. All the calls placed from that desk are also placed through user home PBX so that correct line is used and user home caller ID is displayed.
> 
> Best Regards,
> _____________
> Roman Shpount
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 08:40:23 +0200

> On 10 Jul 2019, at 03:44, Roman Shpount <[email-masked]> wrote:
> 

That seems very complex. How is the token transferred from the web browser to the phone? And how does the home PBX validate the token sent on behalf of the user by the remove office PBX?

Many chains of trust or many leaps of faith.

But interesting.

/O :-)

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 08:44:03 +0200

> On 10 Jul 2019, at 02:53, Roman Shpount <[email-masked]> wrote:
> 
> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
> The document clearly allows the use of access token to authenticate non-REGISTER requests when challenged in the context of the same realm.
> 
> Assuming the UA was able to authenticate the user and obtain an access token, then establish an authenticated TLS channel with the server, and register the user; is there a need for further challenges from server?
> 
When the token expires, you certainly need a new token from the user. With SIP Outbound, we’re more connection oriented than before, so we should propably consider what the
server does with the connection when a token expires (if it’s not already in the draft).
/O
> 
> Typically, for SIP, user authentication is not tied to the TLS connection. One of the reasons for this is that multiple users can use the same TLS connection in federated systems. This is especially true for Confidential UA, which have trust relationship with a proxy and can maintain a secure connection to the registrar/proxy on behalf of multiple clients.
> 
> Once again, it would be much easier to discuss if you can provide a use specific case for OAuth with confidential UA. I can easily think of a OAuth use case for Public User Agent, but only have a vague idea what OAuth with Confidential UA would be. 
> 
> The example I can think of, would be some sort of hot desk application, where user allows a Local PBX to register with User Home PBX to accept calls on behalf of user in a remote location. In this case, Local PBX and User Home PBX will be federated systems which will use a single TLS connection for multiple calls or end user devices. Local PBX and User Home PBX will have a trust relationship, possibly with mutual TLS certificate authentications. A company wide directory server will be used to store actual user credentials and will be used to authenticate the user and generate the token.
> 
> Best Regards,
> _____________
> Roman Shpount
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 08:54:08 +0200

> On 10 Jul 2019, at 00:57, Roman Shpount <[email-masked]> wrote:
> 
> On Tue, Jul 9, 2019 at 4:00 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> No, WebSocket connection is to a different server and typically does not require authentication.
I don’t think that’s correct. See section 7 of RFC 7118 - SIP over WS. https://tools.ietf.org/html/rfc7118#section-7 <https://tools.ietf.org/html/rfc7118#section-7>

> In this specific case, I was thinking OpenSIPS with SIP-over-WS support. Implementing OAuth authentication of SIP message would be trivial there, but OAuth authentication for WebSocket would be much less obvious.
That’s implementation. I am pretty sure that Kamailio can auth the websocket, either by TLS client cert or HTTP digest auth. Guess I need to test :-)

> Are you saying using OAuth token authentication for calls (INVITE) and in dialog messages (BYE)?
Why not? It’s just a different Authorization header value. In my view Oauth bearer tokens should be usable in all places where you today have MD5 digest auth.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 09:08:06 +0200

> On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> This document is specifically focused on confidential UAs.
> UAs running in the browser, public UAs, will be addressed in a separate document.
Maybe you should make that more clear, as it is very confusing terminology… I see that section 1.2 in your draft defines theses
types, based on RFC 6749. You apply it to the term “UA” which I think confuses things. A “public UA” may have support
for confidentiality, but not from an Oauth point of view. I think we should look for other terms for this.

In addition, I don’t find any text in your draft indicating that “Public UAs” is out of scope.

/O
> 
> Regards,
>  Rifaat
> 
> 
> On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, Jul 9, 2019 at 3:11 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 07:17:47 +0000

Hi,

To clarify my comment, as Rifaat said, the document does allow usage of access token to authenticate non-REGISTER requests.

I questioned whether the draft needs to cover such use-cases.

Regards,

Christer

From: Rifaat Shekh-Yusef <[email-masked]>
Sent: 10 July 2019 03:30
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt

Regards,
 Rifaat

On Tue, Jul 9, 2019 at 7:27 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Jul 9, 2019 at 7:17 PM Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
Can you provide a real life example of confidential UA using OAuth for registration only and not generating calls or sending any messages in dialog (or using different authentication method for these actions)?

What? why do you think that is the case?
How did you get to the conclusion that the UA will not be able to make a call?

Quoting Christer:

As far as I know, OAuth for SIP has only been used for REGISTER requests, between the UA and the registrar. I have never heard about anyone using it for non-REGISTER authentication, and I wonder whether we even need to cover it in the draft.

1. UA is confidential
2. OAuth is used for registration only
3. Other messages are not sent or different authentication method is used for them, i.e. calls and in dialog messages are not initiated or initiated using a different authentication method.

Best Regards,
_____________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 09:23:41 +0200

> On 9 Jul 2019, at 18:55, Paul Kyzivat <[email-masked]> wrote:
> 
>>>>>          I would like to hear more about this. Is there something uppoabout the token
> But if I send an INVITE, am challenged by the target of the INVITE, and then send the token in a retry of the INVITE then it only goes there, where it is supposed to go. How is that any different from the registrar case? Is it because I somehow trust the registrar more that I trust who I am calling?
> 
> ISTM that what is more important is the relationship between the domain of the UAS I'm trying to contact and the realm of the challenge. (Do I think this server has any business claiming to be authenticate for this realm?)
> 
> The other tricky part is deciding whether to send the cached credentials (token) in a new request that hasn't just immediately challenged. But note that the request "in response" to a challenge is indistinguishable from a request sent to the same target later other than by time delay. The security concerns should be the same. Sending the token to some other target before being challenged by that target is a different leap of faith, so has different concerns.
> 
> My main point here is not to get you to explain it to me in this email thread. What I want is to see this discussed adequately in the security considerations of the document. If it isn't "safe" to send the token to everybody, then how do I decide who I can safely send it to?
> 
> One partial answer might be: if a challenge results in asking the user to authenticate for the realm, then the user gets to decide if he wants to, and if so then the resulting token should be sent to the same target just then. But this doesn't address when the same token can be used preemptively later. That still needs discussion.

This is an interesting topic that we really need to look into seriously. Consider an access token that has a validity of one hour. That token can be copied by any proxys or network elements on the path and be re-used by others within the validity period to get access.

RFC 6749 Section 10.3 clearly states the need for confidentiality of the access token:

"Access token credentials (as well as any confidential access token
   attributes) MUST be kept confidential in transit and storage, and
   only shared among the authorization server, the resource servers the
   access token is valid for, and the client to whom the access token is
   issued.
"

One solution would be that the challenge indicates a pointer to a valid cert with a public key to use for encryption of the tokens. We have the identity-info header in RFC 4474 as an example of pointing to a cert. The implementation supporting this draft already supports https…

/O

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 09:28:22 +0000

Hi,

...

>   issued."
> One solution would be that the challenge indicates a pointer to a valid cert with a public key to use for encryption of the tokens. We have the identity-info header in RFC 4474 
> as an example of pointing to a cert. The implementation supporting this draft already supports https…

As I indicated in another e-mail, the token needs to be protected, so that proxies between the UA and registrar (in the case of REGISTER) can't use it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 09:34:59 +0000

Hi,

> When the token expires, you certainly need a new token from the user. With SIP Outbound, we’re more 
> connection oriented than before, so we should propably consider what the

We can add some words about that.

Do you think there is something OAuth specific? Credentials can expire when you use other types of authentication too. Does 3261 and/or Outbound say anything about that?

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 10 Jul 2019 07:50:35 -0400

When the UA authenticates to the AS, it obtains a number of tokens: access
token and refresh token, and depends on the AS, maybe ID token.
It is the UAs responsibility to use the refresh token to obtain a new
access token before the expiry of the existing access token.

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <[email-masked]> wrote:

>> When the token expires, you certainly need a new token from the user.
> With SIP Outbound, we’re more connection oriented than before, so we should
> propably consider what the

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 10 Jul 2019 07:51:46 -0400

On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson <[email-masked]> wrote:

> Maybe you should make that more clear, as it is very confusing
> terminology… I see that section 1.2 in your draft defines theses
> types, based on RFC 6749. You apply it to the term “UA” which I think
> confuses things. A “public UA” may have support
Any suggested text?

> In addition, I don’t find any text in your draft indicating that “Public
I will fix that.

Thanks,
 Rifaat

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 13:56:04 +0200

> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> When the UA authenticates to the AS, it obtains a number of tokens: access token and refresh token, and depends on the AS, maybe ID token.
> It is the UAs responsibility to use the refresh token to obtain a new access token before the expiry of the existing access token.
Absolutely - my thought was what the server is supposed to do. Reading the STUN/Oauth docs, I see a requirement for expiry
being less than token validity time. In SIP REGISTER/SUBSCRIBE terms, the expiry time in SIP should be less
than the time the token is valid.

 If the token expires, the server needs to reauth or deny services. It is important that no services are delivered to an expired authentication.

/O
> 
> Regards,
>  Rifaat
> 
> 
> On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 10 Jul 2019, at 02:53, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 14:02:22 +0200

> On 10 Jul 2019, at 13:51, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> 
> 
> On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Maybe you should make that more clear, as it is very confusing terminology… I see that section 1..2 in your draft defines theses
I carefully avoided any suggestions… Was hoping someone on the mailling list would step forward with
some brilliant new terminology. :-)

Maybe just reverting to OAuth terminology with “public clients and confidential clients” to avoid setting our own terms
and directly refer terminology to Oauth specs. I still don’t like “confidential client” when they really mean “something
that at least doesn’t show what they do in source code but may still be totally insecure”...

Yeah, I know that’s a boring suggestion.

/O :-)

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 10 Jul 2019 08:18:33 -0400

The UA is expected to obtain a valid access token to get service, and
should be able to use that to refresh its registration when the
registration expires.
Is this coupling of expiry times needed?

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson <[email-masked]> wrote:

> Absolutely - my thought was what the server is supposed to do. Reading the
> STUN/Oauth docs, I see a requirement for expiry
>  If the token expires, the server needs to reauth or deny services. It is
> important that no services are delivered to an expired authentication.
>
> /O
>
>
> Regards,
>  Rifaat
>
>
>> Typically, for SIP, user authentication is not tied to the TLS
>> connection. One of the reasons for this is that multiple users can use the
>> same TLS connection in federated systems. This is especially true for
>> Confidential UA, which have trust relationship with a proxy and can
>> maintain a secure connection to the registrar/proxy on behalf of multiple
>> clients.
>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 10 Jul 2019 08:20:33 -0400

I am fine with referring to the OAuth definition.
Anybody has an issue with this?

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 8:02 AM Olle E. Johansson <[email-masked]> wrote:

>> terminology… I see that section 1..2 in your draft defines theses
> Maybe just reverting to OAuth terminology with “public clients and
> confidential clients” to avoid setting our own terms
> and directly refer terminology to Oauth specs. I still don’t like
> “confidential client” when they really mean “something

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 12:22:49 +0000

Hi,

Maybe we want to point out that token expiration and registration expiration are two separate things, but I don’t think they should be coupled.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Wednesday, 10 July 2019 at 15.19
To: Olle Johansson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Roman Shpount <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-02.txt

The UA is expected to obtain a valid access token to get service, and should be able to use that to refresh its registration when the registration expires.
Is this coupling of expiry times needed?

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:

/O

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

On 10 Jul 2019, at 02:53, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
The document clearly allows the use of access token to authenticate non-REGISTER requests when challenged in the context of the same realm.

Typically, for SIP, user authentication is not tied to the TLS connection. One of the reasons for this is that multiple users can use the same TLS connection in federated systems.. This is especially true for Confidential UA, which have trust relationship with a proxy and can maintain a secure connection to the registrar/proxy on behalf of multiple clients.

The example I can think of, would be some sort of hot desk application, where user allows a Local PBX to register with User Home PBX to accept calls on behalf of user in a remote location. In this case, Local PBX and User Home PBX will be federated systems which will use a single TLS connection for multiple calls or end user devices.. Local PBX and User Home PBX will have a trust relationship, possibly with mutual TLS certificate authentications. A company wide directory server will be used to store actual user credentials and will be used to authenticate the user and generate the token.

Best Regards,
_____________
Roman Shpount

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 12:24:55 +0000

Hi,

>Anybody has an issue with this?

I support your suggestion.

Regards,

Christer

On Wed, Jul 10, 2019 at 8:02 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

On 10 Jul 2019, at 13:51, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jul 10, 2019 at 3:08 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

On 9 Jul 2019, at 23:16, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:

Any suggested text?

/O :-)

I will fix that..

Thanks,
 Rifaat

/O

Regards,
 Rifaat

On Tue, Jul 9, 2019 at 3:29 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Best Regards,
_____________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 14:25:21 +0200

> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
Absolutely. If we grant a REGISTER expiry time that is much longer than the expiry of the token, we’re in deep waters.

Example from RFC 7635 Stun/Oauth - which I think we can borrow a lot from:

“ o The lifetime provided by the TURN server in the Allocate and
      Refresh responses MUST be less than or equal to the lifetime of
      the token.  It is RECOMMENDED that the TURN server calculate the
      maximum allowed lifetime value using the formula:

        lifetime + Delta - abs(RDnew - TS)

      The RECOMMENDED value for the allowed Delta is 5 seconds.
“

Note that they have a “MUST” on this. I think we MUST do the same :-)
/O

> 
> Regards,
>  Rifaat
> 
> 
> On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 14:26:36 +0200

> On 10 Jul 2019, at 14:22, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>  
See separate response. I think the need to be coupled. 

/O
>  
> Regards,
>  
> Christer
>  
> From: sipcore <[email-masked] <mailto:[email-masked]>> on behalf of Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>>
> To: Olle Johansson <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Roman Shpount <[email-masked] <mailto:[email-masked]>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 10 Jul 2019 08:30:05 -0400

This does not explain the reason for such a requirement.
Why do you think we need to couple these together for SIP?

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson <[email-masked]> wrote:

> Absolutely. If we grant a REGISTER expiry time that is much longer than
> the expiry of the token, we’re in deep waters.
>
>> When the UA authenticates to the AS, it obtains a number of tokens:
>> access token and refresh token, and depends on the AS, maybe ID token.
>> Absolutely - my thought was what the server is supposed to do. Reading
>> the STUN/Oauth docs, I see a requirement for expiry

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 12:35:18 +0000

Hi,

>Why do you think we need to couple these together for SIP?

I don't think we should mandate them to be coupled.

If the token expires before the registration, an UA can still send a REGISTER with the new token - even if the registration is not about to expire.

Regards,

Christer

On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson <mailto:[email-masked]> wrote:

On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef <mailto:[email-masked]> wrote:

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson <mailto:[email-masked]> wrote:

On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef <mailto:[email-masked]> wrote:

/O

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson <mailto:[email-masked]> wrote:

On 10 Jul 2019, at 02:53, Roman Shpount <mailto:[email-masked]> wrote:

On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <mailto:[email-masked]> wrote:
The document clearly allows the use of access token to authenticate non-REGISTER requests when challenged in the context of the same realm. 

Best Regards,
_____________
Roman Shpount
 
mailto:[email-masked]

mailto:[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 15:08:26 +0200

> On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
I don’t want to continue delivering services to clients that are deleted or blocked in the customer database.
With Oauth, the way to block an account is to remove it or change authorization in the authentication server (IDP) data base.

The idea with auth tokens and refresh tokens is to be able to revocate authorization quickly.
Delivering a service beyond revocation is not a good thing in my book.

From the definition of Access Token in section 1.4 in RFC 6749:

"Access tokens are credentials used to access protected resources. An
   access token is a string representing an authorization issued to the
   client.  The string is usually opaque to the client.  Tokens
   represent specific scopes and durations of access, granted by the
   resource owner, and enforced by the resource server and authorization
   server.
“

"Duration of access" is in my world coupled to SIP registration/subscription expiry.

Cheers
/O

> 
> Regards,
>  Rifaat
> 
> 
> 
> 
> On Wed, Jul 10, 2019 at 8:25 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 15:17:09 +0200

> On 10 Jul 2019, at 15:08, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
>> On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>> wrote:
>> 

You have actually implicitly written that expiry time accords to token expiry :

"2.3 <https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02#section-2.3>. Subsequent Registrations

   All subsequent REGISTER requests from the UA MUST include a valid
   access token.  The UA MUST obtain a new access token before the
   access token expiry period to continue to get service from the
   system. 
“

You just need to add that the server MUST not allow an expiry that is greater than
the access token expiry time.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jul 2019 11:26:05 -0400

> But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another "service" (e.g., user-to-user authentication for a SIP call). It most likely would…

Is the token somehow bound to the "registration service"? (Whatever that 
is.)

ISTM that the token is bound to the parameters from www-authenticate 
were used in the process of obtaining the token. And so presumably the 
token should be applicable to any other use that provokes a 
www-authenticate with the same values of those parameters.

So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get 
challenged the same way I would expect to use the same token for that. 
And I might decide to preemptively use the same token in the SUBSCRIBE 
if it is being sent to the same target.

Based on analogies to Digest, I would expect that after receiving a 
Bearer challenge and fetching a matching token I would then add that 
token to a key ring, indexed by some (which?) of the parameters from the 
www-authenticate. And then in the future for new requests I would look 
on the key ring for keys (credentials/tokens) suitable for use on this 
request. (When doing this I might find either Digest or Bearer 
credentials, or maybe both.)

Am I missing something?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jul 2019 15:53:17 +0000

Hi,

>    Is the token somehow bound to the "registration service"? (Whatever that is.)
>  

Yes.

>    if it is being sent to the same target.

Yes.

>    credentials, or maybe both.)
  
No __

In the case you describe, you should be able to use the same token.

All I am saying is that one should not send a token to someone that it has NOT been issued for.

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 10 Jul 2019 18:52:02 -0400

Typically, access token is short lived, and in this case it should be used
only to allow the UA to register the user.
When the time comes to refresh the registration, the UA should use the
refresh token, which is long lived as it stays with the UA, to obtain a new
access token to update the registration.
If you tie it to the registration expiry, then the access token might be
valid for a long time, which degrades the security of the token.

There are better mechanisms for a proper indication of account revocation,
like the mechanisms defined by the Security Events WG:
https://datatracker.ietf.org/wg/secevent/documents/

Regards,
 Rifaat

On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson <[email-masked]> wrote:

> With Oauth, the way to block an account is to remove it or change
> authorization in the authentication server (IDP) data base.
>
> "2.3
> <https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02#section-2.3>.
> Subsequent Registrations
>
>>>  If the token expires, the server needs to reauth or deny services. It
>>> is important that no services are delivered to an expired authentication.
>>>
>>> /O
>>>
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>>> On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef <
>>>> [email-masked]> wrote:
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jul 2019 19:00:02 -0400

> All I am saying is that one should not send a token to someone that it has NOT been issued for.

Then you are saying that a token should *never* be included in a request 
to a target for which you have not received a challenge some time in the 
past.

That is a bit extreme, but I guess you can specify that if you think it 
is the right thing to do.

But note that this logic won't always work for Proxy-Authenticate. You 
*might* know that a particular proxy will be visited (if it is mentioned 
on a Route header), but it is pretty common for the request to visit 
proxies unknown (at least in advance) to the UAC.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jul 2019 19:04:27 -0400

On 7/10/19 6:52 PM, Rifaat Shekh-Yusef wrote:
> Typically, access token is short lived, and in this case it should be 
> used only to allow the UA to register the user.
> refresh token, which is long lived as it stays with the UA, to obtain a 
> new access token to update the registration.

This puts a different spin on how a key ring of credentials is managed. 
Either the key ring always have the refresh token, or else perhaps it 
should contain both, but they should have different expiry times.

This goes well beyond anything described in 3261, so I think an 
explanation is needed.

	Thanks,
	Paul

> There are better mechanisms for a proper indication of account 
> revocation, like the mechanisms defined by the Security Events WG:
> On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>>     On 10 Jul 2019, at 15:08, Olle E. Johansson <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>     On 10 Jul 2019, at 14:30, Rifaat Shekh-Yusef
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>     I don’t want to continue delivering services to clients that are
>>     deleted or blocked in the customer database.
>     "2..3
>>>>         On 10 Jul 2019, at 14:18, Rifaat Shekh-Yusef
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         The UA is expected to obtain a valid access token to get
>>>>         service, and should be able to use that to refresh its
>>>>         registration when the registration expires.
>>>         Absolutely. If we grant a REGISTER expiry time that is much
>>>         longer than the expiry of the token, we’re in deep waters.
>>>
>>>>         On Wed, Jul 10, 2019 at 7:56 AM Olle E. Johansson
>>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>
>>>>>             On 10 Jul 2019, at 13:50, Rifaat Shekh-Yusef
>>>>>             <[email-masked] <mailto:[email-masked]>>
>>>>>             wrote:
>>>>>
>>>>>             When the UA authenticates to the AS, it obtains a
>>>>>             number of tokens: access token and refresh token, and
>>>>>             depends on the AS, maybe ID token.
>>>>>             It is the UAs responsibility to use the refresh token
>>>>>             to obtain a new access token before the expiry of the
>>>>>             existing access token.
>>>>             Absolutely - my thought was what the server is supposed
>>>>             to do. Reading the STUN/Oauth docs, I see a requirement
>>>>             for expiry
>>>>             being less than token validity time. In SIP
>>>>             REGISTER/SUBSCRIBE terms, the expiry time in SIP should
>>>>             be less
>>>>              If the token expires, the server needs to reauth or
>>>>             deny services. It is important that no services are
>>>>             delivered to an expired authentication.
>>>>
>>>>             /O
>>>>>
>>>>>             Regards,
>>>>>              Rifaat
>>>>>
>>>>>
>>>>>             On Wed, Jul 10, 2019 at 2:44 AM Olle E. Johansson
>>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>                 On 10 Jul 2019, at 02:53, Roman Shpount
>>>>>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>                 On Tue, Jul 9, 2019 at 8:30 PM Rifaat Shekh-Yusef
>>>>>>                 <[email-masked]
>>>>>>                 <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>                     The document clearly allows the use of access
>>>>>>                     token to authenticate non-REGISTER requests
>>>>>>                     when challenged in the context of the same realm.
>>>>>>
>>>>>>                     Assuming the UA was able to authenticate the
>>>>>>                     user and obtain an access token, then
>>>>>>                     establish an authenticated TLS channel with
>>>>>>                     the server, and register the user; is there a
>>>>>>                     need for further challenges from server?
>>>>>>
>>>>>                 When the token expires, you certainly need a new
>>>>>                 token from the user. With SIP Outbound, we’re more
>>>>>                 server does with the connection when a token
>>>>>                 expires (if it’s not already in the draft).
>>>>>                 /O
>>>>>>
>>>>>>                 Typically, for SIP, user authentication is not
>>>>>>                 tied to the TLS connection. One of the reasons for
>>>>>>                 this is that multiple users can use the same TLS
>>>>>>                 connection in federated systems. This is
>>>>>>                 especially true for Confidential UA, which have
>>>>>>                 trust relationship with a proxy and can maintain a
>>>>>>                 secure connection to the registrar/proxy on behalf
>>>>>>                 of multiple clients..
>>>>>>
>>>>>>                 Once again, it would be much easier to discuss if
>>>>>>                 you can provide a use specific case for OAuth with
>>>>>>                 confidential UA. I can easily think of a OAuth use
>>>>>>                 case for Public User Agent, but only have a vague
>>>>>>                 idea what OAuth with Confidential UA would be.
>>>>>>
>>>>>>                 The example I can think of, would be some sort of
>>>>>>                 hot desk application, where user allows a Local
>>>>>>                 PBX to register with User Home PBX to accept calls
>>>>>>                 on behalf of user in a remote location. In this
>>>>>>                 case, Local PBX and User Home PBX will be
>>>>>>                 federated systems which will use a single TLS
>>>>>>                 connection for multiple calls or end user devices.
>>>>>>                 Local PBX and User Home PBX will have a trust
>>>>>>                 relationship, possibly with mutual TLS certificate
>>>>>>                 authentications. A company wide directory server
>>>>>>                 will be used to store actual user credentials and
>>>>>>                 will be used to authenticate the user and generate
>>>>>>                 the token.
>>>>>>
>>>>>>                 Best Regards,
>>>>>>                 _____________
>>>>>>                 Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Jul 2019 19:07:48 -0400

On Wed, Jul 10, 2019 at 2:40 AM Olle E. Johansson <[email-masked]> wrote:

> That seems very complex. How is the token transferred from the web browser
> to the phone? And how does the home PBX validate the token sent on behalf
> of the user by the remove office PBX?
>
One way to do it is, that remote PBX sends a registration to the home PBX
with the token and adds a forwarding rule to the device on the desk. End
device credentials are only used between end device and remote PBX, so
nothing on the device changes.

Another way to do it, if caller ID does not need to be preserved on user
calls, is to run a separate service which performs the third party
registration on user home PBX. As a result of user login via a web form,
this service initiates the registration to the user home PBX with token
authentication. Contact address in this registration is the URL pointed to
the remote office PBX, which is pre-configured to ring the phone on user
desk. I think I've built a couple of services like this, but needed to
store user credentials in DB, which was not secure. Using OAuth would have
been much cleaner.

Best Regards.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Jul 2019 19:10:44 -0400

> server does with the connection when a token expires (if it’s not already
Keep in mind that proxy responsible for SIP Outbound or Web Sockets edge
proxy and registrar can be two different servers. Connection from end user
device to SIP Outbound Proxy can be unique, but connection from edge proxy
to the registrar can be reused for multiple clients. I am sure this can be
un-bundled and made to work but it is not always trivial.

Best Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Jul 2019 19:15:04 -0400

On Wed, Jul 10, 2019 at 2:54 AM Olle E. Johansson <[email-masked]> wrote:

> require authentication.
> I don’t think that’s correct. See section 7 of RFC 7118 - SIP over WS.
> https://tools.ietf.org/html/rfc7118#section-7
>

 These options are certainly valid but I some times complicate things. As I
have mentioned, if registrar and edge proxy are two different servers,
using connection based authentication complicates things.

> In this specific case, I was thinking OpenSIPS with SIP-over-WS support.
> Implementing OAuth authentication of SIP message would be trivial there,
> but OAuth authentication for WebSocket would be much less obvious.
>
> That’s implementation. I am pretty sure that Kamailio can auth the
> websocket, either by TLS client cert or HTTP digest auth. Guess I need to
> test :-)
>

As I have said, it is probably doable but much less obvious, especially in
the scenario where proxy and registrar are separate.

> Why not? It’s just a different Authorization header value. In my view
> Oauth bearer tokens should be usable in all places where you today have MD5
> digest auth.
>
> I was trying to figure out exactly this. I was trying to see why Christer
says that OAuth should not cover requests other then registration. That
seemed strange to me.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 06:24:34 +0000

Hi,

...

>I was trying to figure out exactly this. I was trying to see why Christer says that OAuth should not cover requests 
>other then registration. That seemed strange to me.

I apologize for being unclear. You can for sure use it for non-registration requests.

What I meant was that nobody has ever asked for it, so I questioned whether it needs to be added to the draft at this point.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 08:54:04 +0200

> On 11 Jul 2019, at 08:24, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 

To break the trend, I ask for it.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 07:00:12 +0000

Hi,

 > To break the trend, I ask for it.

It would have been nice if you had asked for it years ago when the work started, but better late than never :)

Anyway, I don't want to spend time arguing whether it should be included: if people want it, let's include it.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 09:03:04 +0200

> On 11 Jul 2019, at 09:00, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> It would have been nice if you had asked for it years ago when the work started, but better late than never :)n
I apologize for not spending time on this earlier. Life got in the way :-)

> Anyway, I don't want to spend time arguing whether it should be included: if people want it, let's include it.
I don’t see any reason to use one auth scheme for a specific sip method. What was the thinking behind that?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 07:03:07 +0000

Hi,

... 

>    is the right thing to do.

That is my understanding of the generic OAuth security considerations: you don't give a token to someone it was not intended for.

Of course, if you know (based on whatever configuration/policy) that it's ok to give the token to the target I guess you could do it.
    
>    proxies unknown (at least in advance) to the UAC.
  
It is important to remember that, since the token needs to be protected, a proxy needs to have the associated protection credentials to be able to access the token. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 07:07:15 +0000

Hi,

>I apologize for not spending time on this earlier. Life got in the way :-)
  
I know, and I apologize if I sounded rude. It's just this generic frustration that it takes so long to get anything done in IETF, but it's of course not your fault - this has taken too long no matter what :)

>I don’t see any reason to use one auth scheme for a specific sip method. What was the thinking behind that?

People requested a solution for doing SIP registration using OAuth, so we documented that.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 09:30:31 +0200

> On 10 Jul 2019, at 17:26, Paul Kyzivat <[email-masked]> wrote:
> 
In Oauth2 there are two tokens - access token and refresh token. If you add OpenID Connect, there’s an Identity token. Can we please be more
specific in our discussions? 

> 
> ISTM that the token is bound to the parameters from www-authenticate were used in the process of obtaining the token. And so presumably the token should be applicable to any other use that provokes a www-authenticate with the same values of those parameters.
> 
> So, if I use a token in REGISTER, and then I do a SUBSCRIBE and get challenged the same way I would expect to use the same token for that. And I might decide to preemptively use the same token in the SUBSCRIBE if it is being sent to the same target.
> 
> Based on analogies to Digest, I would expect that after receiving a Bearer challenge and fetching a matching token I would then add that token to a key ring, indexed by some (which?) of the parameters from the www-authenticate. And then in the future for new requests I would look on the key ring for keys (credentials/tokens) suitable for use on this request. (When doing this I might find either Digest or Bearer credentials, or maybe both.)

The tokens generally, but if I understand it right not always, are JWT structures that contain various data. In OpenID connect both the access and identity token are JWTs.
We can either specify specific claims that  are standardised for various SIP functions or let that be open for the SIP implementors to specify or a combination. 

I would suggest that a generic specifier meaning “this access token is valid for SIP services” would be a good thing. 

As a service provider I would like to add authorizations like “this user is authorized for calls to international destinations” or “this user belongs to the support queue”.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 09:45:17 +0200

> On 11 Jul 2019, at 01:10, Roman Shpount <[email-masked]> wrote:
> 
> Keep in mind that proxy responsible for SIP Outbound or Web Sockets edge proxy and registrar can be two different servers. Connection from end user device to SIP Outbound Proxy can be unique, but connection from edge proxy to the registrar can be reused for multiple clients. I am sure this can be un-bundled and made to work but it is not always trivial.

Right, but the specific contacts with separate reg-id*s could be disabled in the registrar.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 07:49:18 +0000

Hi,
 
>>> OAuth allows you to re-use the token as many times as you want (until it expires) for the same service. So, for SIP, re-using 
>>> the token in binding refresh REGISTER requests is fine.
>>> But, you should not re-use a token you got for one "service" (e.g., your registration authentication) with another 
>>> "service" (e.g., user-to-user authentication for a SIP call). It most likely wouldn't even work.
>> 

Good point. When I have been talking about tokens, I refer to Oauth2 tokens. Perhaps we should always indicate that explicitly.

...

 > The tokens generally, but if I understand it right not always, are JWT structures that contain various data. In 
> OpenID connect both the access and identity token are JWTs.
> We can either specify specific claims that  are standardised for various SIP functions or let that be open for 
> the SIP implementors to specify or a combination. 
   
For backward compatibility, we should at least let SIP implementors specify.

> As a service provider I would like to add authorizations like “this user is authorized for calls to international destinations” 
> or “this user belongs to the support queue”.
   
Such information could also be stored in the user profile in the registrar.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 10:12:45 +0200

> On 11 Jul 2019, at 09:49, Christer Holmberg <[email-masked]> wrote:
> 
> 
> Hi,
> 
Well, the document talks about both, but let’s name the specific token.
> For backward compatibility, we should at least let SIP implementors specify
Maybe, but at least we should write something about the usage of claims and scopes.
I think a base level for this draft is specifying a way to say “this access token is valid for SIP usage” or
“this is also a SIP identity"
> Such information could also be stored in the user profile in the registrar.
Absolutely. You either use your IDP only for authentication and handle authorization elsewhere or trust the IDP
for authorizations in SIP. That’s up to the implementor.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 11:29:12 +0200

> On 11 Jul 2019, at 09:30, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
> The tokens generally, but if I understand it right not always, are JWT structures that contain various data.
Found a draft that specifies an Oauth Access Token JWT profile
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00 <https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00>

"The original OAuth 2.0 Authorization Framework [RFC6749 <https://tools.ietf.org/html/rfc6749>]
   specification does not mandate any specific format for access tokens.
   While that remains perfectly appropriate for many important scenario,
   in-market use has shown that many commercial OAuth2 implementations
   elected to issue access tokens using a format that can be parsed and
   validated by resource servers directly, without further authorization
   server involvement.  The approach is particularly common in
   topologies where the authorization server and resource server are not
   co-located, are not ran by the same entity, or are otherwise
   separated by some boundary.  All of the known commercial
   implementations known at this time leverage the JSON Web Tokens(JWT)
   [RFC7519 <https://tools.ietf.org/html/rfc7519>] format.
“

I think we can safely assume that an Access Token is going to be parsable.

/O

> In OpenID connect both the access and identity token are JWTs.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 09:58:37 +0000

Hi,

>https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00
>
>"The original OAuth 2.0 Authorization Framework [https://tools.ietf.org/html/rfc6749]
>   [https://tools.ietf.org/html/rfc7519] format.
>“
>

The question is whether we want to mandate JWT, eventhough the statement above probably is correct.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 12:22:25 +0200

> On 11 Jul 2019, at 11:58, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

We may want to consult with the Oauth wg to see where they are heading with this and if the break
to backwards compatibility is considered hurtful. As of now, I don’t find anything in our solution
that requires any claim/scope.

Regardless, we can suggest usage of scope and claims in our document.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 10:40:40 +0000

Hi,

...
 
    >“this is also a SIP identity"

    Perhaps we can add some text about scope and claims, but I don't want to mandate usage of specific values, because that may not be backward compatible with existing implementations using JWT. 

    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 12:52:25 +0200

> On 11 Jul 2019, at 12:40, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 

We can mandate *if* the access token is a jwt (and there’s an identity token like OpenID Connect). 

I see interoperability problems if every implementation is using different data structures for stuff like SIP AOR, SIP usage claim and maybe a few more that we will come up with as we continue working. Standardizing some of these basic data points in tokens will help interoperability. 

If the access token is a random blob we don’t require any change.

In addition I think we should change the “sip.token” label to something more specific like “sip.oauth2”. 

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 11:25:31 +0000

Hi,

    >>    Perhaps we can add some text about scope and claims, but I don't want to mandate usage of specific values, because that 
    >>    may not be backward compatible with existing implementations using JWT. 
    >
    
    It may not work with existing implementations that DO use JWT access tokens (not sure whether they use OpenID Connect, though).

    >> I see interoperability problems if every implementation is using different data structures for stuff like SIP AOR, SIP usage claim 
    >> and maybe a few more that we will come up with as we continue working. Standardizing some of these basic data points in tokens will help interoperability. 
    >
    
    I think it was me who suggested to use sip.token, but I don't have a strong opinion about it. It was added recently, so existing implementations currently don't use it anyway.
 
    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 13:49:12 +0200

> On 11 Jul 2019, at 13:25, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Ok, you are making me interested - what are these implementations?
When writing a new standard document, should we really be blocked by pre-standard implementations? I would assume that we
should be inspired by them, learn by their experiences, but not be hindered by them. 

>    I think it was me who suggested to use sip.token, but I don't have a strong opinion about it. It was added recently, so existing implementations currently don't use it anyway.

We have already been confused by discussions about “the token” when in fact there are multiple tokens…

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 12:07:18 +0000

Hi,

    > Ok, you are making me interested - what are these implementations?
    
   Unfortunately I am not able to give information regarding that.

    >should be inspired by them, learn by their experiences, but not be hindered by them. 
    
    The implementations are based on earlier versions of the draft.

    And, yes, there is the old saying that one should not deploy a draft before the draft becomes RFC. 

    But, in this case, the first version of Rifaat's individual draft was submitted in 2014. Then, for whatever reason, it took 3(!) years before it got adopted, and after that we have so far worked on it for two years. How long is one expected to wait for an RFC before deploying???

     Of course, if something is broken we need to fix it. But, I don't think what you suggest is fixing something that is broken, it is adding new functionality. And, I have no problem with that, as long as it is backward compatible.

    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 14:10:42 +0200

> On 11 Jul 2019, at 14:07, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

I do understand the pain, but I have severe problems of having to adopt to an unknown implemenetation of an early document that wasn’t pushed forward. If you had the resources to do development, why didn’t you spend time pushing the draft forward?

Regardless, it is where we are and we have to find some sort of agreement on how to proceed. I would feel sad of having to support a poor document with too many compromises because of this implementation. Would it really hurt if a working app was not standard-compliant?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 12:58:16 +0000

Hi,

    ...

    > Regardless, it is where we are and we have to find some sort of agreement on how to proceed. I would feel sad of having 
    > to support a poor document with too many compromises because of this implementation. 

    Not sure I agree with "too many compromises".

    What we are discussing is standardizing scope information in the draft. If I understand correctly, you don't need that for the basic mechanism to work - you only need it if you want to include authorization information in the token. In case of registration, if the SIP server has that information, it is not needed.

    Also, in the case of SSO, couldn't you use the token for more things than SIP? In that case I assume you don't want to scope it to SIP only.
    
    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 15:06:43 +0200

> On 11 Jul 2019, at 14:58, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>    ...
> 
>    Not sure I agree with "too many compromises”.
Not yet, but in a few mail exchanges this topic kept coming up so I exaggerated a bit. Sorry…

>    Also, in the case of SSO, couldn't you use the token for more things than SIP? In that case I assume you don't want to scope it to SIP only.

Please read section 3.3 of the Oauth 2.0 Security Best Current Practise.
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13>

"In particular, access tokens SHOULD be restricted to certain resource servers, preferably to a single resource server. “

So no, I don’t wan’t the access token used for SIP used for anything else. When the client requests authorization you propably want to request a specific resource server (SIP domain)
that this token applies to. Most examples in the docs refer to HTTPS URI’s, but the spec keeps saying “URI” so I assume a SIP domain uri or a sip server URI would work too. 
This is all in theory of course, I don’t know what kind of core dump or other hiccup a SIP URI would generate in current OAuth2 implementations ;-)

Any recommendations on Open Source Oauth2 servers to play around with, btw?

Gentle reminder: Let’s stop using “the token” :-)

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 13:24:30 +0000

Hi,

> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
>

Fair enough. I'll let Rifaat continue the SSO discussion, if needed, because he is more interested in that.

My main interest is using Oauth tokens for SIP registrations only, so that should be aligned with the BCP :)

> This is all in theory of course, I don’t know what kind of core dump or other hiccup a SIP URI would generate in current OAuth2 implementations ;-)

HTTP is referring to the OAuth2 interfaces etc (we are not defining a SIP OAuth interface) We can double check whether instances of "URI" should be more specific.

> Any recommendations on Open Source Oauth2 servers to play around with, btw?

Unfortunately not.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jul 2019 09:46:02 -0400

This discussion is wandering in many directions. I don't know very much 
(anything?) about OAuth so it is pretty abstract for me. But what is 
becoming clear is that the people discussing this have *many* unstated 
assumptions about how this is to work and how it is to be used. And 
those don't appear to be well aligned with one another.

I've been pushing for more of these assumptions (and implications) to be 
written down in the document. I still want that. But I'm beginning to 
think that the issue is bigger than what is likely to fit into this 
document as it is currently conceived.

I think what may be needed is a framework document. (Perhaps "Framework 
for using OAuth(2?) with SIP", though maybe that isn't quite right. This 
would discuss why this is important, how it relates to the sip 
environment, how it fits into a broader authentication environment, etc.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jul 2019 09:50:06 -0400

> It is important to remember that, since the token needs to be protected, a proxy needs to have the associated protection credentials to be able to access the token.

I'm lost here. How is the token protected? Is it because it is passed by 
reference, and other credentials are needed to dereference it? Or is it 
passed by value but encrypted?

If it is protected, then why is there any concern over who it is given to?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 13:56:56 +0000

Hi,

>    environment, how it fits into a broader authentication environment, etc.
  
Let's try to document and clarify everything we need in this document.

The draft tries to map the OAuth architecture to the SIP architecture. If something is unclear we should of course clarify it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 14:07:46 +0000

Hi,

    >> It is important to remember that, since the token needs to be protected, a proxy needs to have the 
    >> associated protection credentials to be able to access the token.
    >

    That depends on how your protect it.

    If the oauth2 token itself is encrypted, and only authorized entities can decrypt it, then I guess it does not matter if a non-authorized user gets it, as it will not be able to use it.

    But, if the oauth2 token is sent in "plain text", then the SIP signaling needs to be protected/encrypted. But, in that case, if I make a phone call to you, and the call itself is valid, then I should not send you the oauth2 token unless it's meant for you, because once you decrypt the signaling you will have access to it.

   What is important is that a non-authorized user should not have access to a non-protected oauth2 token.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jul 2019 10:16:45 -0400

> The draft tries to map the OAuth architecture to the SIP architecture. If something is unclear we should of course clarify it.

Sure, go ahead and try.

You keep answering my questions as replies to this email thread. But 
what is needed is for them to be answered in the document.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Jul 2019 10:24:43 -0400

>      If the oauth2 token itself is encrypted, and only authorized entities can decrypt it, then I guess it does not matter if a non-authorized user gets it, as it will not be able to use it.

Is this going to be defined, or is the intent to leave it open?
I don't understand how things can work if it is left open.

>     What is important is that a non-authorized user should not have access to a non-protected oauth2 token.

I don't see how this can work. How does the UAC *know* if the server it 
is sending credentials to is authorized to receive those credentials?

In general the UAC doesn't know what proxies and UAS the request will 
visit. All it knows is the request-URI. Since there generally isn't a 
direct connection from UAC to UAS TLS authentication doesn't help.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 17:00:05 +0200

>     Of course, if something is broken we need to fix it. But, I don't think what you suggest is fixing something that is broken, it is adding new functionality. And, I have no problem with that, as…
Christer, 
I’ve been thinking about this. We are almost in the same situation as the old discussion about the DIversion: header. While waiting
for another better solution, that’s what all of us implemented. Then came SIP HIstory and we had no docs to refer to for interoperability…
The old draft was later published as an informational RFC.

Can we look into the same solution? Publishing the current draft wiith minor nits as an informational RFC that your implementation is compliant with
and then work on something more up-to-par with current OAuth2/OpenID connect BCPs and thinking?

As an example: When reading the docs I see ways of protecting the access token so that only a specific service (read SIP domain)  may decrypt and
use it. That way we don’t need to disallow forwarding of SIP messages with a bearer token, as the token will be useless beyond that point.
Starting to go down that road, wlil definitely mean that we leave the implementation you currently have behind. And that is just
one issue. The other is having a parsable access token, which I think would be a requirement to follow the BCP and propably to get through
the hole security audit for any standard-track RFC publication.

What do you think? Is this a way forward?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 15:02:59 +0000

Hi,

    >>      If the oauth2 token itself is encrypted, and only authorized entities can decrypt it, then I guess it does 
    >>      not matter if a non-authorized user gets it, as it will not be able to use it.
    >
    
    We normally don't specify HOW to protect SIP information, because it can done in  many different ways, we only say when 
    some piece of information needs to be protected.

    Also, in the case of oauth2 tokens, as they can be encoded in many different ways, some of which have their own built-in protections (e.g., JWT), we can't specify a single solution that works for all. We can only specify what security characteristics must be fulfilled.

    >>  But, if the oauth2 token is sent in "plain text", then the SIP signaling needs to be protected/encrypted. 
    >>  But, in that case, if I make a phone call to you, and the call itself is valid, then I should not send you the 
    >>  oauth2 token unless it's meant for you, because once you decrypt the signaling you will have access to it.
    >> 
 
    In that case you should use encoding with built-in protection, that only authorized entities are able to decrypt. JWT provides 
    such protection, so I assume it wouldn't matter if a non-authorized entity receives it. And, as far as the OAuth token is concerned, you don't have to protect the SIP signaling when using JWT (there may of course be other reasons why you need to protect the SIP signaling).

   Regards,

   Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 15:13:33 +0000

Hi,

    >>    But, in this case, the first version of Rifaat's individual draft was submitted in 2014. Then, for whatever reason, it took 3(!) years before it 
    >>   got adopted, and after that we have so far worked on it for two years. How long is one expected to wait for an RFC before deploying???
    >> 
    >>     Of course, if something is broken we need to fix it. But, I don't think what you suggest is fixing something that is broken, it is adding new 
    >>     functionality. And, I have no problem with that, as long as it is backward compatible.
    > 
    >   
    > Christer, 

    I really think that is an unfair request, considering how many years some of us have been working on this, especially since I don't think the current solution is broken.

    Yes, there are lots of things that need to be clarified, and some things may be added, so let's first try to do that and see where it takes us.

    >use it. That way we don’t need to disallow forwarding of SIP messages with a bearer token, as the token will be useless beyond that point.

    JWT gives you that property, doesn't it? There is nothing in the current draft that forbids or prevents you from using JWT. As we noted earlier, it's probably 
    what most (all?) people are using anyway.

    > the hole security audit for any standard-track RFC publication.
    
    JWT is parsable :)

    Is your issue that we don't mandate JWT? If so, why don't we liaise (as you suggested earlier) with the oauth wg to see whether it would be safe to assume that everyone uses JWT.

    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 17:16:42 +0200

> On 11 Jul 2019, at 00:52, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> Typically, access token is short lived, and in this case it should be used only to allow the UA to register the user.
> When the time comes to refresh the registration, the UA should use the refresh token, which is long lived as it stays with the UA, to obtain a new access token to update the registration.
> If you tie it to the registration expiry, then the access token might be valid for a long time, which degrades the security of the token.
Or the registration will be valid for a short time… I wonder why the STUN document requires this form of tie-in. I guess we need to ask
the authors. 

I do agree that long-lived access tokens would be a night-mare. I was thinking along the way that every time you update the access token
wth the refresh token, you re-register. And even though you can have a very long-lived refresh token, we would force the update
of the access token for every re-registration. I don’t think that is a very bad thing. 

I guess this way of using Oauth for long-lived sessions is a new area for Oauth. I only found the STUN/TURN example to relate to.

/O

> 
> There are better mechanisms for a proper indication of account revocation, like the mechanisms defined by the Security Events WG:
> https://datatracker.ietf.org/wg/secevent/documents/ <https://datatracker.ietf.org/wg/secevent/documents/>  
> 
> Regards,
>  Rifaat
> 
>  
> 
> On Wed, Jul 10, 2019 at 9:17 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 10 Jul 2019, at 15:08, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> "2..3 <https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-02#section-2.3>. Subsequent Registrations
>>>>>> Typically, for SIP, user authentication is not tied to the TLS connection. One of the reasons for this is that multiple users can use the same TLS connection in federated systems. This is especially true for Confidential UA, which have trust relationship with a proxy and can maintain a secure connection to the registrar/proxy on behalf of multiple clients..
>>>>>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 17:26:30 +0200

> On 11 Jul 2019, at 17:13, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
Let’s do that. My apologies for stepping in late, but I haven’t felt blocked by an early implementation of a draft before. I do understand it’s been
some time.
>    what most (all?) people are using anyway.
The implementations I’ve seen is mostly signed JWTs, but you are right, JWTs can be encrypted.
>    Is your issue that we don't mandate JWT? If so, why don't we liaise (as you suggested earlier) with the oauth wg to see whether it would be safe to assume that everyone uses JWT.
I don’t think we can reach any level of acceptable security in this without parseable access (and identity) tokens. All new Oauth documents from the WG seems to 
assume you can transport metadata from the authorization server to the resource server in tokens in order to limit access token usage. 

In addition I think putting the bearer token in a SIP header is dangerous - it will require a lot for existing non-compliant browsers not to leak this header out in the wild.
Protecting it in a way that only the targeted audience can decode it and validate it would make the situation better.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 15:43:40 +0000

Hi,

...

    >>    Is your issue that we don't mandate JWT? If so, why don't we liaise (as you suggested earlier) with the oauth wg to see 
    >>    whether it would be safe to assume that everyone uses JWT.
    >
    > I don’t think we can reach any level of acceptable security in this without parseable access (and identity) tokens. All new Oauth 
    > documents from the WG seems to assume you can transport metadata from the authorization server to the resource server in 
    > tokens in order to limit access token usage. 
    
    > not to leak this header out in the wild.

    What do you mean by "existing non-compliant browsers"?

    > Protecting it in a way that only the targeted audience can decode it and validate it would make the situation better.

    Again, JWT :)

    You can include JWT encoded information in a SIP header. We already do that elsewhere.    

   Regards,

   Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 19:10:34 +0200

> On 11 Jul 2019, at 15:50, Paul Kyzivat <[email-masked]> wrote:
> 
> I'm lost here. How is the token protected? Is it because it is passed by reference, and other credentials are needed to dereference it? Or is it passed by value but encrypted?
> 

Normally most tokens are just digitially signed, but clear text. It can be encrypted, but then the auth server need to know which key pair to encrypt it with, which in turn means
that the client needs to tell the auth server that which leads to a requirement to have parseable access tokens.

Again, let’s stop talking about “the token”. That will confuse ourselves and other readers. Thanks :-)

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 19:14:38 +0200

> On 11 Jul 2019, at 16:07, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
Encryption of signalling is not going to protect a token in a SIP header from reaching to the wrong servers, it is just a
first hop encryption. We have far too many SIP RFCs that indicate that all security problems are solved if we wrap signalling in TLS.

> But, in that case, if I make a phone call to you, and the call itself is valid, then I should not send you the oauth2 token unless it's meant for you, because once you decrypt the signaling you will have access to it.
Right. And we have no way in SIP of forbidding any server of forwarding a specific header.
>   What is important is that a non-authorized user should not have access to a non-protected oauth2 token.
Define “user" and “token”.  A non-encrypted access token should not be shared with any unauthorized SIP network element - client or server software.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 19:18:44 +0200

> On 11 Jul 2019, at 16:24, Paul Kyzivat <[email-masked]> wrote:
> 
> I don't see how this can work. How does the UAC *know* if the server it is sending credentials to is authorized to receive those credentials?
> 
> In general the UAC doesn't know what proxies and UAS the request will visit. All it knows is the request-URI. Since there generally isn't a direct connection from UAC to UAS TLS authentication doesn't help.
The UAC will have to know which SIP domain that - in Oauth2 terms - is the intended audience for authentication and/or authorization. When requesting authenticiation 
with the Oauth2 authorization server this needs to be part of the request. The server may them, provided that it has a trusted certificate or a key that is shared witih the
service, encrypt the requested access token in a way that only the audience can decrypt.

The SIP domain is part of the solution here. That will be stated as a SIP uri.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 17:21:44 +0000

Hi,

    >that the client needs to tell the auth server that which leads to a requirement to have parseable access tokens.

    I think the oauth2 token can be delivered non-encrypted to the SIP UA over HTTPS. The SIP UA can then encrypt the oauth2 token before sending it over SIP.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 19:24:52 +0200

> On 11 Jul 2019, at 17:02, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
And where have that kind of thinking led us? We need at least one working interoperable solution for implementers to iimplement
as a baseline, while not forbidding others. 
>    Also, in the case of oauth2 tokens, as they can be encoded in many different ways, some of which have their own built-in protections (e.g., JWT), we can't specify a single solution that works fo…
We can surely specify a working solution that is the base interoperability level. Otherwise we will just produce a
document that goes to the archives and leads to isolated vendor-specific islands. I don’t like that.
I do agree with leaving it open to add other ways of doing things in the future, but  I think we need to deliver
a fully specifieid working solution.

>    such protection, so I assume it wouldn't matter if a non-authorized entity receives it. And, as far as the OAuth token is concerned, you don't have to protect the SIP signaling when using JWT (t…

Most SIP signalling protection - TLS - is hop by hop. We need protection from the UA to the service domain - possibly across a few intermediate servers.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 19:26:43 +0200

> On 11 Jul 2019, at 17:43, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 
>    What do you mean by "existing non-compliant browsers”?
Haha, yes, that was not parseable. Substitute “browsers” witih “SIP Proxys” and it gets better. Sorry.

>    You can include JWT encoded information in a SIP header. We already do that elsewhere.    
Absolutely. But then we can’t just say “JWT” we have to specify  “encrypted and signed JWT”.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 17:29:02 +0000

Hi,

    > first hop encryption. We have far too many SIP RFCs that indicate that all security problems are solved if we wrap signalling in TLS.

    It would work in networks where the interface between the client and server is considered "trusted", but for the general case I agree. 

    >>> But, in that case, if I make a phone call to you, and the call itself is valid, then I should not send you the oauth2 token unless it's meant 
    >>> for you, because once you decrypt the signaling you will have access to it.

    Correct.

    (The reason I used "user" was because the use-case was a call between two users)

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 17:33:59 +0000

Hi,

    > Haha, yes, that was not parseable. Substitute “browsers” witih “SIP Proxys” and it gets better. Sorry.

    It's ok. There have been so many e-mails so I was wondering whether there was something I've completely missed :)

    > Absolutely. But then we can’t just say “JWT” we have to specify  “encrypted and signed JWT”.
    
    Fair enough.

    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 19:34:10 +0200

> On 11 Jul 2019, at 19:21, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>    I think the oauth2 token can be delivered non-encrypted to the SIIP UA over HTTPS. The SIP UA can then encrypt the oauth2 token before sending it over SIP.
Now you have to have a shared key pair between every UA and the intended SIP server. That’s far more complex than having it in the authorization server.

You put a lot of trust in TLS, which is fine. How do you handle intercepting TLS proxys in the path in this scenario?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 17:55:19 +0000

Hi,

    > Now you have to have a shared key pair between every UA and the intended SIP server. That’s far more complex than having it in the authorization server.

    Now we are coming back to where this would actually be used :)

    Again, the only use-case I am aware of is SIP registration, and then the only "intended SIP server" is the registrar.

    In any case, I think this is a deployment question, so we don't need to mandate one way or another. What matters is that the JWT is protected on the SIP interface.

    > You put a lot of trust in TLS, which is fine. How do you handle intercepting TLS proxys in the path in this scenario?

    I guess we'd have to ask the OAuth experts about that, but in general I think we can put as much trust in HTTPS as any else does :) 

    And, for the SIP registration case, I don't think it even would be a problem for the authorization server to maintain the keys of the UA and the registrar.

    At the end of the day, you have to choose a solution that fits your use-case. Maybe this solution isn't feasible for all use-cases, even if it technically supports them. OAuth may fit certain use-cases better than others, and there is nothing we can do about that.
   
    Regards,

    Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 11 Jul 2019 20:59:59 +0200

> On 11 Jul 2019, at 19:55, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
And you may pass through a number of SIP proxys on the way.

There has been many mails questioning the focus on registration. You keep coming back to that - what is so different with authentication
for a REGISTER than other SIP methods in your view? I’m curious.

>    In any case, I think this is a deployment question, so we don't need to mandate one way or another. What matters is that the JWT is protected on the SIP interface.
I believe others are working on that part - confidentiality between authorization server and resource server.

>    I guess we'd have to ask the OAuth experts about that, but in general I think we can put as much trust in HTTPS as any else does :) 
Which means almost no trust any more...
>    And, for the SIP registration case, I don't think it even would be a problem for the authorization server to maintain the keys of the UA and the registrar.
Agree for many more use cases than just registration :-)
>    At the end of the day, you have to choose a solution that fits your use-case. Maybe this solution isn't feasible for all use-cases, even if it technically supports them. OAuth may fit certain us…
Depends on the definition of “this solution”. I do agree that Oauth2 may not fit all use cases for SIP, but any step away from the current Digest Auth is a step forward.
If you read up on the large amount of drafts and RFCs from the Oauth wg and OpenID connect you’ll find that they are targeting many types of situations that 
would fit not only browser-based SIP ua’s but also SIP desktop phones and maybe ATA-like boxes.

Mutual TLS cert auth hasn’t taken off, which is the only alternative we currrently have. I do hope we can sort this out and document a good framework.

/O

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2019 20:07:57 +0000

Hi,

>>>>>>>>      Then you are saying that a token should *never* be included 
>>>>>>>> in a request  to a target for which you have not received a 
>>>>>>>> challenge some time in the  past.
>>>>>>>>      That is a bit extreme, but I guess you can specify that if 
>>>>>>>> you think it  is the right thing to do.
>>>>>>>>  *might* know that a particular proxy will be visited (if it is 
>>>>>>>> mentioned  on a Route header), but it is pretty common for the 
>>>>>>>> request to visit  proxies unknown (at least in advance) to the UAC.
>>>>> Normally most tokens are just digitially signed, but clear text. It 
>>>>> can be encrypted, but then the auth server need to know which key pair to encrypt it with, which in turn means that the client needs 
>>>>> to tell the auth server that which leads to a requirement to have parseable access tokens.
>>>> 

Yes, but they will not be "intended server" (read: authorized to see the oauth2 token), so no need to store any keys for those proxies. Only the registrar is the "intended server".

> for a REGISTER than other SIP methods in your view? I’m curious.

The number or entities that will authenticate the UA. You were talking about having keys for the UA and every intended server. In case of registration, the only "intended server" is the registrar.

Of course, there may also be other use-cases where there is only one (or a few) intended server, e.g,, a SIP subscription service. I am not saying registration is the only one. 

Yes. 

>>    I guess we'd have to ask the OAuth experts about that, but in 
>> general I think we can put as much trust in HTTPS as any else does :)

Well, if one doesn't trust OAuth then he/she should obviously not use it. But, I don't think this is the place to discuss/improve the generic security of OAuth.

>> At the end of the day, you have to choose a solution that fits your use-case. Maybe this solution isn't feasible for all use-cases, even if it technically 
>> supports them. OAuth may fit certain use-cases better than others, and there is nothing we can do about that.
>
> Depends on the definition of “this solution”.

OAuth in general, and the usage of OAuth for SIP authentication.

> I do agree that Oauth2 may not fit all use cases for SIP, but any step away from the current Digest Auth is a step forward.

Sure, but I personally don’t think OAuth will be feasible for all use-cases where Digest is currently used - especially not for user-to-user authentication. It's not what OAuth was designed for, AFAIK.

> If you read up on the large amount of drafts and RFCs from the Oauth wg and OpenID connect you’ll find that they are targeting many types of situations 
> that would fit not only browser-based SIP ua’s but also SIP desktop phones and maybe ATA-like boxes.

Absolutely.

> Mutual TLS cert auth hasn’t taken off, which is the only alternative we currrently have. I do hope we can sort this out and document a good framework.

Me too :)

Regards,

Christer