Subject: [sipcore] SIP AuthNZ Problem Statement v2

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 27 Apr 2016 08:11:37 -0400

All,

The following is a new problem statement text that I think captures all the
comments received so far.
Please, take a look and let me know if you have any further comments.

Regards,
 Rifaat

---

Overview
--------

The following is a simplified classic SIP deployment model:

                                +--------+
                                | SIP    |
    ,---------------------------| Registrar
    |                           |        |
+--------+                      +--------+                      +--------+
|        |                      | SIP    |                      | SIP App|
|   UA   |----------------------| Proxy  |----------------------| Server |
|        |                      |        |                      |        |
+--------+                      +--------+                      +--------+

With this model, the endpoint is assigned a dedicated SIP proxy/registrar
and all SIP communications must go through that SIP proxy.

The SIP Proxy/Registrar plays 3 different roles:
1. Authentication Server (SIP Registrar)
2. Authorization Server
3. Service provider, e.g. basic calls, call forwarding, call transfer, etc.

SIP Application Servers provide advanced SIP services, e.g. conference,
presence, etc. Application Servers usually have their own authentication
and authorization mechanism that is separate from the one provided by the
SIP proxy.

We would like to discuss the idea of "outsourcing" the user authentication
and services authorization to separate network element(s):

Authentication (AuthN)
----------------------

There are two types of authentications in a SIP network: user-to-server
authentication and user-to-user authentication. These authentications could
be in the context of one trust domain, or it could cross boundaries between
different trust domains.

We would like to explore the idea of "outsourcing" the user authentication
part to a separate IdP entity, to allow the SIP user to use his non-SIP
credentials, e.g. corporate credentials, with the IdP to register with the
SIP registrar, get basic services from the SIP Proxy, and get access to the
advanced services provided by the SIP Application Servers.

We would also like to explore the idea of using the same "outsourcing"
mechanism to address the user authentication when it crosses trust domain
boundaries.

Authorization (AuthZ)
---------------------

We would like to explore the idea of "outsourcing" the authorization part
to a separate network element to allow the administrator to grant access to
the basic services provided by the SIP Proxy, and the various advanced
services provided by the SIP Application Servers.

In general, there are two authorization mechanisms that could be used in
this case:

1. Self-contained token, which includes all the authorizations needed for
   the server providing the service to be able to make a decision to grant
   or deny the service request, and might include control over the level of
   service provided to the user.

2. Opaque token, which requires an introspection step, where the server
   providing the service would reach to the authorization server to get the
   details of the authorizations provided for that specific token.

There are pros and cons to each approach that we need to discuss and make a
decision on supporting one of these, or maybe both.

Trust Relationships
-------------------

An important aspect of this exercise is to properly define the trust
relationship between the various network elements that would enable the new
desired functionalities.

Types of Clients
----------------

The solution must take into consideration the various types of SIP clients
that might be involved and active in the system, e.g. softclient,
hardphones, etc.

The solution must also take into consideration the limitation on some of
these clients that might impact the way assertions are obtained and
handled. For example, the following client limitation would require an
interim step to obtain an assertion:

1. UI Limitation: a hardphone with limited UI capability that only allows
   the user to interact with the phone through the phone's keypad.

2. Security Limitation: a client that is incapable of maintaining the
   security of the user's credentials or the assertion.

In these use cases, we would need a way to get the assertion to the servers
that will provide the service without requiring the client to get access to
the assertion.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Apr 2016 10:24:34 -0400

Rifaat,

This is starting to make more sense to me. But IMO it needs more work.

The figure seems inadequate to describe the problem space. One can infer 
that the intent is to add another box to the picture, for the IdP. Also, 
should I assume there may be several IdPs and several SIP App Servers?

Then there remains a question of what the relationship is of those boxes 
to the others. Presumably an App Server will need a trust relationship 
with at least one IdP. How will the user know which IdP to use to obtain 
authorization for a particular app server?

And how will this work when multiple users are involved, and a call 
between them might involve app servers for each?

	Thanks,
	Paul

On 4/27/16 8:11 AM, Rifaat Shekh-Yusef wrote:
> All,
>
> The following is a new problem statement text that I think captures all
> the comments received so far.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 27 Apr 2016 14:35:26 +0000

Honestly I would rather take the term IdP out of this problem statement entirely, unless it is defined in some very neutral way - the issue is that we all project our understandings of this term from various industry identity architectures onto this problem. We should instead show a box for it, and show what data we imagine goes in and out of it in the use cases that we care about.

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Apr 27, 2016, at 10:24 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Rifaat,
> 
> The figure seems inadequate to describe the problem space. One can infer that the intent is to add another box to the picture, for the IdP. Also, should I assume there may be several IdPs and several SIP App Servers?
> 
> Then there remains a question of what the relationship is of those boxes to the others. Presumably an App Server will need a trust relationship with at least one IdP. How will the user know which IdP to use to obtain authorization for a particular app server?
> 
> And how will this work when multiple users are involved, and a call between them might involve app servers for each?
> 
>    Thanks,
>    Paul
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 27 Apr 2016 19:28:03 -0400

Paul,

The provided figure was meant to capture the current state as a background
information.
But I agree that a figure that captures the new elements would be useful; I
will add a new figure with the new network elements.

Regarding the relationship between the network elements, I provided some
text that states that we need to define that relationship.
It seems to me that defining the relationships at this stage is a bit
premature. Should not this be done when we start working on defining
solutions to these problems?

Regards,
 Rifaat

On Wed, Apr 27, 2016 at 10:24 AM, Paul Kyzivat <[email-masked]>
wrote:

> to the others. Presumably an App Server will need a trust relationship with
> at least one IdP. How will the user know which IdP to use to obtain

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 27 Apr 2016 19:29:44 -0400

Jon,

Do you have a "very neutral" definition to the term IdP?

Regards,
 Rifaat

On Wed, Apr 27, 2016 at 10:35 AM, Peterson, Jon <[email-masked]>
wrote:

>
> Honestly I would rather take the term IdP out of this problem statement
> entirely, unless it is defined in some very neutral way - the issue is that
> we all project our understandings of this term from various industry
> identity architectures onto this problem. We should instead show a box for
> it, and show what data we imagine goes in and out of it in the use cases
> that we care about.
>
> Jon Peterson
> Neustar, Inc.
>
> Sent from my iPad
>
> >> |        |                      | SIP    |                      | SIP
> App|
> >> |        |                      |        |                      |
>   |

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 27 Apr 2016 20:52:27 -0400

Jon,

How about the following definition?

http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider)

Regards,
 Rifaat

On Wed, Apr 27, 2016 at 7:29 PM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

>> > The figure seems inadequate to describe the problem space. One can
>> infer that the intent is to add another box to the picture, for the IdP.
>> Also, should I assume there may be several IdPs and several SIP App Servers?
>> >
>> > Then there remains a question of what the relationship is of those
>> boxes to the others. Presumably an App Server will need a trust
>> relationship with at least one IdP. How will the user know which IdP to use
>> to obtain authorization for a particular app server?
>> >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Apr 2016 10:45:26 +0000

Hi,

>authorization for a particular app server?

With web apps, you are redirected to the correct IdP (e.g. Facebook). So,
unless the UA knows which IdP to use, I guess the SIP App Server could
inform it.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Apr 2016 10:17:28 -0400

On 4/27/16 7:28 PM, Rifaat Shekh-Yusef wrote:
> Paul,
>
> The provided figure was meant to capture the current state as a
> background information.
> But I agree that a figure that captures the new elements would be
> useful; I will add a new figure with the new network elements.
>

Yes, some of this probably falls into the solution domain rather than 
the problem domain. But I think some of it may fall into the problem 
domain. I have the sense that there is an assumption that there is a 
single IdP and that any/all clients and app servers trust it. This 
*might* be appropriate is some enterprise deployments, but it doesn't 
scale well beyond that.

	Thanks,
	Paul

> Regards,
>  Rifaat
>
>
>
>
> On Wed, Apr 27, 2016 at 10:24 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Rifaat,
>
>     infer that the intent is to add another box to the picture, for the
>     IdP. Also, should I assume there may be several IdPs and several SIP
>     App Servers?
>
>     relationship with at least one IdP. How will the user know which IdP
>     to use to obtain authorization for a particular app server?
>
>         |        |                      | SIP    |
>         | SIP App|
>         |        |                      |        |
>         |        |
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Apr 2016 10:21:23 -0400

> unless the UA knows which IdP to use, I guess the SIP App Server could

In the web apps I encounter you are usually given a choice of IdPs that 
the app server can deal with, and you can choose one that you have a 
relationship with. That same model could work here if the user is 
interfacing through an app that has a web interface as well as sip. But 
it may present a problem in other cases, such as phones with limited UIs.

That is why I think it needs to be explored.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Apr 2016 15:41:11 +0000

Hi,

Also with SIP you can have a choice of IdPs, as long as the app server has a relationship with them(in order to verify access tokens etc.).

The app doesn't necessarily need to have a web interface. The user can e.g. be requested to select IdP and/or provide credentials using the dial pad. This is one of the use-cases in the draft.

(In case of WebRTC, though, the app and the web interface are typically the same thing, if it's an HTML5/JS app.)

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎28/‎04/‎2016 17:21
To: Christer Holmberg<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] SIP AuthNZ Problem Statement v2

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Apr 2016 11:48:03 -0400

On 4/28/16 11:41 AM, Christer Holmberg wrote:
> Hi,
>
> Also with SIP you can have a choice of IdPs, as long as the app server
> has a relationship with them(in order to verify access tokens etc.).
>
> The app doesn't necessarily need to have a web interface. The user can
> e.g. be requested to select IdP and/or provide credentials using the
> dial pad. This is one of the use-cases in the draft.
>
> (In case of WebRTC, though, the app and the web interface are typically
> the same thing, if it's an HTML5/JS app.)

I'm not saying there aren't solutions - only that it is something that 
needs to be carefully considered. So it needs to be in the scope of the 
work.

	Thanks,
	Paul

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: Christer Holmberg <mailto:[email-masked]>;