Subject: [sipcore] SIP Authorization Framework Use Cases

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 18 Aug 2014 14:19:22 -0400

Hi,

During the discussion of the SIP OAuth proposal in Toronto, it was decided
that we need a list of use cases to make it clear what we are trying to
solve.
The following is some definitions and the use cases that I had in mind when
I started working on the SIP OAuth proposal.

I know that others had different use cases in mind that they want the new
authorization framework to address.

Regards,
 Rifaat

Definitions
-----------

o Types of SIP services:
  1. Basic SIP Services: make/receive call, transfer, call forward, ...
  2. Advanced SIP Services: services provided by SIP application
servers, e.g. Voice Mail, Conference Services, Video Services,
Presence, IM, ...

o Single Sign-On (SSO): SSO is a property that allows the user to be
authenticated once and as a result have access to multiple services in
the system.

o Authentication: the process of verifying the identity of a user
trying to get access to some network services.

o Authorization: the process of controlling a user access to network
services and the level of service provided to the user.

Enterprise Use Cases
--------------------

1. Corporate-wide SSO

An enterprise is interested in providing its users with an SSO capability to
the corporate various services.
The enterprise has an authorization server for controlling the user access
to their network and would like to extend that existing authorization
server to control the user access to the various services provided by
their SIP network.

The user is expected to provide his corporate credentials to login to the
corporate network and get different types of services, regardless of
the protocol used to provide the service, and without the need to
create different accounts for these different types of services.

2. SIP SSO

An enterprise is interested in providing its users with an SSO capability to
the corporate various SIP services.

The enterprise wants to control the services provided to their SIP users and
the level of service provided to the user by their SIP application servers
without the need to create different accounts for these services.

The enterprise wants to utilize an existing authentication mechanism
provided by SIP, but would like to be able to control who gets access to
what service and when.

The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the
services provided by the various SIP application servers without being
challenged to provide credentials for each type of service.

3. Edge Authorization

An enterprise is interested in authenticating and authorizing a remote user
trying to get access to services provided by the corporate SIP network.

The enterprise would like to authenticate and authorize the remote
user at the edge
of the network using a SIP network element that does not have direct access to
the SIP user account, e.g. SBC. The enterprise is also interested in providing
the user with an SSO capability to the corporate various SIP services.

The user is expected to use his SIP credentials to login to the SIP
network and get access to the basic services, and to get access to the
services provided by the various SIP application servers without being
challenged to provide credentials for each type of service.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Aug 2014 18:40:43 +0000

Hi Rifaat,

3GPP defines the usage of OAuth2 for WebRTC based access to IMS.

On a high-level, it is similar to section 5 in the draft, i.e. the UA retrieves the token using a non-SIP mechanism (HTTP), and then includes it in the SIP REGISTER request.

3GPP maps OAuth roles into IMS roles using the table below:

IMS role                                 OAuth role

IMS subscriber                        Resource Owner
WWSF                                    Client
WAF                                       Authorization Server
IMS network                           Resource Server

WWSF (WebRTC Web Server Function)

-          Acts as web server, from where the user downloads the IMS access application.
WAF (WebRTC Authorisation Function)

-          Acts as the authorization server (the "facebook"), and issues the authorization tokens.

(The WWSF and WAF can, but does not have to, be located in the same domain as the IMS provider.)

I guess the important thing to note here is that the IMS core network (including the registrar/S-CSCF and HSS) does not act as Authorization Server, but rather as the Resource Server.

In fact, the IMS core network itself does not even need to support OAuth2.0. Instead the WAF performs mapping and verification between "legacy IMS credentials" and "web credentials" (e.g. OAuth2.0). The detailed procedures for that mapping/verification is not specified in the current 3GPP release.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: 18 August 2014 21:19
To: [email-masked]
Subject: [sipcore] SIP Authorization Framework Use Cases

Hi,

During the discussion of the SIP OAuth proposal in Toronto, it was decided that we need a list of use cases to make it clear what we are trying to solve.
The following is some definitions and the use cases that I had in mind when I started working on the SIP OAuth proposal.

I know that others had different use cases in mind that they want the new authorization framework to address.

Regards,
 Rifaat

Definitions

-----------

o Types of SIP services:

  2. Advanced SIP Services: services provided by SIP application servers, e.g. Voice Mail, Conference Services, Video Services, Presence, IM, ...

o Single Sign-On (SSO): SSO is a property that allows the user to be authenticated once and as a result have access to multiple services in the system.

o Authentication: the process of verifying the identity of a user trying to get access to some network services.

o Authorization: the process of controlling a user access to network services and the level of service provided to the user.

Enterprise Use Cases

--------------------

1. Corporate-wide SSO

their SIP network.

2. SIP SSO

what service and when.

3. Edge Authorization

The enterprise would like to authenticate and authorize the remote user at the edge

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Aug 2014 11:05:04 -0400

Rifaat,

[as chair] Thanks for starting this!

[as individual] comments inline

On 8/18/14 2:19 PM, Rifaat Shekh-Yusef wrote:
> Hi,
>
> During the discussion of the SIP OAuth proposal in Toronto, it was
> decided that we need a list of use cases to make it clear what we are
> trying to solve.
> The following is some definitions and the use cases that I had in mind
> when I started working on the SIP OAuth proposal.
>
>    2. Advanced SIP Services: services provided by SIP application servers, e.g.
> Voice Mail,

What is the service that is being authorized?
Presumably it is not the capturing of messages, because the entity with 
the credentials isn't involved in that.
Is it the retrieval of messages?

> Conference Services,

Again, what is the service being authorized?
Is it the creation of a scheduled conference?
Is it proof of identity as one of the participants the creator of the 
conference wants to allow?

> Video Services,

What are video services that are different from conference services or 
"voice"mail?

> Presence,

What is being authorized?
Is it publication of presence state?
Subscription to presence state?
(This is actually one of the clearer ones.)

> IM,

Again, what is the service?
Do I need special permissions to set up an MSRP stream,
or send a MESSAGE? (That seems odd. Do I need special permission to set 
up an RTP stream?)
Is it access to a store/forward server for IMs?

These questions may seem nit-picky, but for me they are needed to 
understand what sort of credentials are needed, by whom, and to 
determine if the entity that needs to provide something knows when and 
what they need to provide.

> ...

This one seems relatively clear and reasonable to me.

> challenged to provide credentials for each type of service.

IIUC, the intent here is that a user/device provides credentials to 
register, and then is not further involved. Various "services" are 
provisioned to be available to subsets of the enterprise users.

An important consideration here is how those subsets are defined.

> challenged to provide credentials for each type of service.

How is this different from (2)?

To these I would like to add another:

Internet-Wide SSO:

A user wants to subscribe to sip services the same way he subscribes to 
web services - using his identity from one of the popular internet-wide 
authentication services. (E.g., Google+, Facebook, Disqus.)

After that, all that is needed to gain access to those services is to 
log his device in to the chosen authentication service.

	Thanks,
	Paul

---

From: Matt Ryan <[email-masked]>
Date: Tue, 19 Aug 2014 10:04:51 -0600

Hi,

I have included some comments inline below.

> I know that others had different use cases in mind that they want the new authorization framework to address.

I was one who volunteered to offer a use case or two.  I have been working on this (amidst summer holidays) and hope to have something to provide within the next day or so.

> Definitions

As I’ve been considering example cases, I came up with five different tests that I think must apply before any use case can be a valid SIP OAuth use case.

1.  The scenario must be about authorization, not authentication.  Authorization is about determining whether a specific user-agent may access a resource or perform a function.  Authentication is about determining whether the user of a user-agent is really who the user claims to be.  Authentication is about credentials and identity.  Authorization is about permission and rights.  OAuth is for authorization, not authentication.  It is about controlling access to resources, not about minimizing the number of credentials a user has to manage (that is e.g. OpenID).
2.  There needs to be a protected resource that the end-user owns and manages, but the client does not normally have access to, and there must be a real value to the end-user to be able to manage the relationships separately.  "The relationships" here mean the relationship between the end-user and the client, and the end-user and the server.  There needs to be a reason why there is value to the end-user that these each be managed separately instead of together.
3.  The scenario must be about an end-user granting a client *restricted* access to the protected resource.  If the access to the protected resource is unlimited, there is no point to OAuth - the end-user may as well simply provide to the client the end-user's credentials to access the protected resource.
4.  At the time the end-user approves the request the client has made, or will make, of the server to access the protected resource, the end-user must be able to be presented with a verifiable conversation with the server wherein the approval is given.  So there are two parts to this test.  The first is that the conversation has to be able to take place where the server asks the end-user if it is okay that the client obtain the authorization being requested.  The second part is that the end-user needs to be able to trust that the conversation is between the end-user and the server, not with the client or a man-in-the-middle or whatever.
5.  Finally, there needs to be a justifiable reason why the client wishes to communicate with the server via SIP rather than HTTP.  Performing the OAuth negotiation is a solved problem in HTTP, so if that is a reasonable option the application developer will choose HTTP.  The scenario needs to demonstrate a reason why using SIP is required, or at least preferred.

The first four tests are basic OAuth tests - they must all be relevant to the use case for OAuth to be justified.  The fifth use case is relevant to SIP OAuth, which is what this draft is about.

SSO is just a variant of Authentication.  It has to do with allowing a single credential to authenticate a user to a multitude of services without requiring the user to remember multiple credentials or reenter the same credentials all the time.  There are a number of SSO solutions available today, but as I understand it OAuth is not one of them.

> Enterprise Use Cases

This is an authentication / SSO use case.  Can you explain why OAuth is a solution to this problem?
 
> challenged to provide credentials for each type of service.

Same question - this is an authentication / SSO use case.  Can you explain why OAuth is a solution to this problem?

> challenged to provide credentials for each type of service.

This sounds like an authentication issue again, not an authorization issue.  The use case is centered around using a single set of credentials to obtain access to each service.

Additionally, in these use cases all of the resources are controlled by the same enterprise.  The value of OAuth is that it allows a resource owner to authorize restricted access by a client to a resource managed by a distinct resource server.  This is presumably because the resource owner has a different level of trust with each entity - otherwise, the resource owner could grant unrestricted access to the resource.  If both the client and the resource are controlled by the same enterprise, the resource owner already has a trust relationship with the enterprise, so implementing OAuth seems unnecessary to me.

Can you help me understand why using OAuth is necessary here?  Why would the enterprise not just offer unrestricted access between all of the services, once the user has authenticated?

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

Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  801.762.6281 |  mryan at getjive dot com

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 19 Aug 2014 16:05:31 -0400

> From: Rifaat Shekh-Yusef <[email-masked]>

> create different accounts for these different types of services.

In most of your cases, you speak of "services" or "types of services".
But I think that a central element of your envisioned use-case is that
each *service* is provided by a specific *application server*, that
is, a separate processing device.

And that many of the issues of authentication have to do with the fact
that the application server is not integrated with the rest of the
SIP system.  E.g.,

- We don't want to require the application server to have a complete
  database of all SIP users that are allowed to use the server (with
  their credentials).

- We don't want to require the UA to present its credentials
  individually to both the SIP system and to every application server
  involved in a particular call.

Otherwise, if a "service" is just some feature of the PBX, there is no
interesting authentication problem -- the UA authenticates itself to
the PBX, and the PBX knows what services the UA is allowed to use.

I think it would help if this assumption was made more explicit.

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 22 Aug 2014 08:59:49 -0400

Paul,

Thanks for your comments.
Please, see my reply inline...

Regards,
 Rifaat

On Tue, Aug 19, 2014 at 11:05 AM, Paul Kyzivat <[email-masked]>
wrote:

>> servers, e.g.
Correct.

> conference wants to allow?
I was thinking of the creation of a conference.
But authenticating the identity of the participant is an interesting one; I
need to think about that.

> Yeah, this is related to conference service.

> (This is actually one of the clearer ones.)
I was thinking mainly about the subscription to presence state of the
contacts.

> or send a MESSAGE? (That seems odd. Do I need special permission to set up
> an RTP stream?)
The level of control can vary, as this is typically not specified in a
standard, but left as an implementation detail.
The protocol should only provide the framework to enable that control.

> understand what sort of credentials are needed, by whom, and to determine
> if the entity that needs to provide something knows when and what they need
> to provide.
>
>
>  ...
>>
>> authenticated once and as a result have access to multiple services in the
>> system.
>>
> register, and then is not further involved.

I was thinking of a user providing credentials, not device. Do you see a
use case where you need a device to provide credentials?

> Various "services" are provisioned to be available to subsets of the
> enterprise users.
>
>
Yes, the user authenticates once, and gets an access token that is specific
for him.
The access token has a scope associated with it that controls the services
and the level of service provided to that user.

> An important consideration here is how those subsets are defined.
These are typically not specified in the framework, but left to the
implementation to decided on the level of control the system needs.

> How is this different from (2)?
In (2) the endpoint authenticates directly to the authorization service
that has access to the user's credentials.
With this use case, the edge device does not have that access, and needs to
communicate with the authorization server to authenticate the user.

> After that, all that is needed to gain access to those services is to log
> his device in to the chosen authentication service.
>
>         Thanks,
>         Paul
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 22 Aug 2014 09:18:53 -0400

Hi Matt,

Notice that this thread is not trying to discuss the solution, but to
collect use cases. I did not mention SIP OAuth in the definition or the use
cases description.

But let me try to address some of your comments below. See my reply
inline...

Regards,
 Rifaat

On Tue, Aug 19, 2014 at 12:04 PM, Matt Ryan <[email-masked]> wrote:

> I was one who volunteered to offer a use case or two.  I have been working
> on this (amidst summer holidays) and hope to have something to provide
> within the next day or so.
>
>
> > Regards,
> >  Rifaat
> >
> >
> > Definitions
> > -----------
> >
> > o Types of SIP services:
> servers, e.g. Voice Mail, Conference Services, Video Services, Presence,
> IM, ...
> >
> As I've been considering example cases, I came up with five different
> tests that I think must apply before any use case can be a valid SIP OAuth
> use case.
>
> 1.  The scenario must be about authorization, not authentication.
> Authorization is about determining whether a specific user-agent may access
> a resource or perform a function.  Authentication is about determining
> whether the user of a user-agent is really who the user claims to be.
> Authentication is about credentials and identity.  Authorization is about
> permission and rights.  OAuth is for authorization, not authentication.  It
> is about controlling access to resources, not about minimizing the number
> of credentials a user has to manage (that is e.g. OpenID).
>

Well, I think it is about both: controlling access to resources, and using
a single credentials to grant access to different resources.
With OAuth 2.0 you could use, for example, your Facebook account to grant
access to your resources on different sites, instead of creating different
account for each site that provides you with some service.

> 2.  There needs to be a protected resource that the end-user owns and
> manages, but the client does not normally have access to, and there must be
> a real value to the end-user to be able to manage the relationships
> separately.  "The relationships" here mean the relationship between the
> end-user and the client, and the end-user and the server.  There needs to
> be a reason why there is value to the end-user that these each be managed
> separately instead of together.
> 3.  The scenario must be about an end-user granting a client *restricted*
> access to the protected resource.  If the access to the protected resource
> is unlimited, there is no point to OAuth - the end-user may as well simply
> provide to the client the end-user's credentials to access the protected
> resource.
> 4.  At the time the end-user approves the request the client has made, or
> will make, of the server to access the protected resource, the end-user
> must be able to be presented with a verifiable conversation with the server
> wherein the approval is given.  So there are two parts to this test.  The
> first is that the conversation has to be able to take place where the
> server asks the end-user if it is okay that the client obtain the
> authorization being requested.  The second part is that the end-user needs
> to be able to trust that the conversation is between the end-user and the
> server, not with the client or a man-in-the-middle or whatever.
> 5.  Finally, there needs to be a justifiable reason why the client wishes
> to communicate with the server via SIP rather than HTTP.  Performing the
> OAuth negotiation is a solved problem in HTTP, so if that is a reasonable
> option the application developer will choose HTTP.  The scenario needs to
> demonstrate a reason why using SIP is required, or at least preferred.
>
>
First, the proposal does *not *call for using SIP to authenticate to the
Authorization Server, unless it is authenticating to the SIP Registrar.
Second, when using Code Grant type, the authentication in OAuth 2.0 is a
solved problem for the browser, not for a SIP UA.

> The first four tests are basic OAuth tests - they must all be relevant to
> the use case for OAuth to be justified.  The fifth use case is relevant to
> SIP OAuth, which is what this draft is about.
>
>
> SSO is just a variant of Authentication.  It has to do with allowing a
> single credential to authenticate a user to a multitude of services without
> requiring the user to remember multiple credentials or reenter the same
> credentials all the time.  There are a number of SSO solutions available
> today, but as I understand it OAuth is not one of them.
>
>
> >
> >
> > Enterprise Use Cases
> > --------------------
> >
> > 1. Corporate-wide SSO
> >
Let's take this use case as an example.
The user is provided with corporate credentials to allow him to login to
the corporate network and get access to services.
The user cannot use the corporate credentials to get access to SIP
services, and he is required to use yet another credentials that are
specific to the SIP network.

With the SIP OAuth proposal, the user is expected to authenticate to the
Authorization Server, and as a result will be provided with an access token
that controls the user's access to all corporate service, including the SIP
services.
The access token could also control the level of service provided to the
user by a specific application server; for example, a conference server
might want to control who could get access to video conference service vs
audio service only.

To achieve that you need more than just an authentication; there is a need
for an authorization framework, which is what OAuth is all about.

> This sounds like an authentication issue again, not an authorization
> issue.  The use case is centered around using a single set of credentials
> to obtain access to each service.
>
> Additionally, in these use cases all of the resources are controlled by
> the same enterprise.  The value of OAuth is that it allows a resource owner
> to authorize restricted access by a client to a resource managed by a
> distinct resource server.  This is presumably because the resource owner
> has a different level of trust with each entity - otherwise, the resource
> owner could grant unrestricted access to the resource.  If both the client
> and the resource are controlled by the same enterprise, the resource owner
> already has a trust relationship with the enterprise, so implementing OAuth
> seems unnecessary to me.
>
> Can you help me understand why using OAuth is necessary here?  Why would
> the enterprise not just offer unrestricted access between all of the
> services, once the user has authenticated?
>

Why would the enterprise do such a thing?
The enterprise might give some users access to video services, but not to
others.
The enterprise might also want to control when a user can get access to the
video service, or even the quality of video provided to the user.
Just because a user authenticated to the system, does not mean that the
user should get unlimited access to all services provided by the enterprise.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 22 Aug 2014 09:24:35 -0400

Hi Dale,

Yes, you are correct.
Thanks for clearly articulating that in your text.

Regards,
 Rifaat