Subject: [sipcore] Fwd: SIP Authorization Framework Use Cases

From: Matt Ryan <[email-masked]>
Date: Mon, 25 Aug 2014 14:02:26 -0600

Some comments to Rifaat's response.  Sorry for the bad formatting (GMail is
being a challenge).

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.

[MR] - Sorry, I misread.

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

> 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.

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.

[MR]  It sounds like you are stating that an example of OAuth is to use
your Facebook login to access resources on different websites, instead of
having to create an account on each site.
Sorry, no.  This is not what OAuth does.  You must have an existing
relationship with all the sites in order for OAuth to work.  OAuth is about
you, the user, allowing one web service to have *restricted* access
(time-based, number or type of resources, etc.) to your resources under
control by another web service.  OAuth allows you to do grant the first web
service this ability without requiring you to provide to the first service
your login credentials to the second service.  OAuth does not facilitate
you sharing credentials between both services.  There are other
technologies that do this but OAuth is not one.
If you still disagree I recommend re-reading the RFC.  I will too - perhaps
I have misread it.  But allowing me to avoid "creating different accounts
for each site" is an authentication issue, which is not what OAuth is about
IIUC.

(snip)

>
>
> 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.

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

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.

[MR]  Using another set of credentials = authentication problem, not
authorization, therefore not OAuth.

With the SIP OAuth proposal, the user is expected to authenticate to the
Authorization Server,

[MR]  You are mixing terms here.  Are we talking about authentication or
authorization?

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.

[MR]  In OAuth, the user does not request or obtain access tokens - ever.
 The client service requests the access tokens.  It does this based on
having some predefined API key, not shared credentials.

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.

[MR]  Fine - but if both services are in the same enterprise why is OAuth
required?  That's just extra work for no benefit.  OAuth is about enabling
restricted access to shared resources between two parties.  This makes the
assumption that the relationship the user has with each party is not
necessarily the same.  If the relationship *is* the same (it is the same
business entity), what is the value?

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.

[MR]  I disagree that an authorization framework is needed.  All that is
needed here is to share credentials.  Both services are controlled by the
same business entity.

(snip)

>
> 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.

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.

[MR]  The enterprise can *easily* do all of these things without OAuth -
probably easier, in fact, without OAuth than to do it with OAuth.  The
enterprise can easily do this because it controls all of the services.
 Once the user has logged in, the enterprise can determine from the user's
credential which of all these services they can access.  OAuth is just a
harder way to solve this problem.
OAuth becomes interesting when the services are NOT all controlled by the
same enterprise.

--
Matt Ryan

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 26 Aug 2014 13:44:59 -0400

Inline...

On Mon, Aug 25, 2014 at 4:02 PM, Matt Ryan <[email-masked]> wrote:

> Some comments to Rifaat's response.  Sorry for the bad formatting (GMail
> is being a challenge).
>
>
>
> >   2. Advanced SIP Services: services provided by SIP application
> 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.
>
> If you still disagree I recommend re-reading the RFC.  I will too -
> perhaps I have misread it.  But allowing me to avoid "creating different
> accounts for each site" is an authentication issue, which is not what OAuth
> is about IIUC.
>
>
Try to login/sign-in with each of the following links and you will see that
you will be provided with an option to use your facebook account:
https://www.flickr.com/
https://vimeo.com/
http://hockey.fantasysports.yahoo.com/
http://www.forbes.com/
http://oscar.go.com/

> (snip)
>
>
> >
> >
> > Enterprise Use Cases
> > --------------------
>
> >
> > 1. Corporate-wide SSO
> >
> > An enterprise is interested in providing its users with an SSO
> capability to
As I mentioned before, I was not trying to shoe horn the SIP OAuth proposal
to OAuth 2.0 model; all I was trying to do is use the general idea to
define a model for SIP.
Take a look at the following two examples that define OAuth models for user
authentication and authorization:
http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-01
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10#appendix-A.2

> 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
> 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.
I am talking about large enterprises with thousands of users, with various
systems that are not integrated that most of the time are managed by
different IT teams.
Tightly integrating these systems together is not an easy task, and might
not be desirable.
With an OAuth-type of a solution you could loosely tie these together and
allow reuse of existing authentication and authorization systems.

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