Subject: [sipcore] SIP AuthNZ Problem Statement - v3

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 3 May 2016 08:16:04 -0400

All,

The following is v3 of the problem statement based on the feedback provided.

Thoughts?

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.

IdP Definition:

    "IdP (Identity Provider), is a system that creates, maintains, and
    manages identity information for principals (users, services, or
    systems) and provides principal authentication to other service
    providers (applications) within a federation or distributed network.
    It is a trusted third party that can be relied upon by users and
    servers when users and servers are establishing a dialog that must be
    authenticated. The IdP sends an attribute assertion containing trusted
    information about the user to the SP".

The above IdP definition is borrowed from the following MIT Knowledge Base
site:
http://kb.mit.edu/confluence/display/glossary/IdP+(Identity+Provider)

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.

The following is one possible Enterprise deployment model. With this model,
a trust relationship must be established between the SIP Proxy, the SIP
Application servers, and the IdP.

                   .......................................................
                   :                                                     :
                   :       +--------+           Trust Domain             :
                   :       | IdP    |                                    :
    +--------------:-------| AuthZ  |---------------------------+        :
    |              :       |        |                           |        :
    |              :       +--------+                           |        :
    |              :           |                                |        :
    |              :           |                                |        :
+--------+         :       +--------+                      +--------+_   :
|        |         :       | SIP    |                      | SIP App| |  :
|   UA   |---------:-------| Proxy  |----------------------| Server | |  :
|        |         :       |        |                      |        | |  :
+--------+         :       +--------+                      +--------+ |  :
                   :                                         ---------+  :
                   :                                                     :
                   .......................................................

The following is one possible Internet deployment model where the SIP App
is deployed in the cloud, and the local users get access to the cloud
service based on local authNZ.

With this model, a trust relationship must be established between the cloud
service provider and the customer.

     Trust Domain 1              :    Internet     :  Trust Domain 2
                                 :                 :
                  +--------+     :                 :
                  | IdP    |     :                 :
    +-------------| AuthZ  |     :                 :
    |             |        |     :                 :
    |             +--------+     :                 :
    |                 |          :                 :
    |                 |          :                 :
+--------+        +--------+     :                 :     +--------+
|        |        | SIP    |     :                 :     | SIP App|
|   UA   |--------| Proxy  |-----:-----------------:-----| Video  |
|        |        |        |     :                 :     | Conference
+--------+        +--------+     :                 :     +--------+
                                 :                 :

The following is one possible Internet deployment model where one SIP App
is deployed in the cloud and is used to provide some service which
requires access to some resources in a local SIP App.

With this model, a trust relationship must be established between the cloud
service provider and the customer.

     Trust Domain 1                  :    Internet     :  Trust Domain 2
                                     :                 :
            +--------+   +--------+  :                 :
            | IdP    |   | SIP App|  :                 :
    +-------| AuthZ  |---| VM     |  :                 :
    |       |        |   | Server |  :                 :
    |       +--------+   +--------+  :                 :
    |               |     |          :                 :
    |               |     |          :                 :
+--------+        +--------+         :                 :     +--------+
|        |        | SIP    |         :                 :     | SIP App|
|   UA   |--------| Proxy  |---------:-----------------:-----| Text   |
|        |        |        |         :                 :     | Transcribe
+--------+        +--------+         :                 :     +--------+
                                     :                 :

The following is one possible Internet deployment model with two separate
trust domains where a user from one trust domain is calling another user in
the other trust domain.

With this model, no initial trust relationship between the trust domains is
needed to allow the call to be established.

     Trust Domain 1         :    Internet     :          Trust Domain 2
                            :                 :
                +--------+  :                 :  +--------+
                | IdP    |  :                 :  | IdP    |
    +-----------| AuthZ  |  :                 :  | AuthZ  |-----------+
    |           |        |  :                 :  |        |           |
    |           +--------+  :                 :  +--------+           |
    |                       :                 :                       |
    |                       :                 :                       |
+--------+      +--------+  :                 :  +--------+      +--------+
|        |      | SIP    |  :                 :  | SIP    |      |        |
|   UA   |------| Proxy  |--:-----------------:--| Proxy  |------|   UA   |
|        |      |        |  :                 :  |        |      |        |
+--------+      +--------+  :                 :  +--------+      +--------+
                            :                 :

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: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 8 May 2016 09:25:10 -0400

All,

I did not receive any comment about this version of the text; does this
mean that people are happy with the current text?

Also, I have a question that I would like to get people's thoughts about it:
The current text assumes that the AuthN and the AuthZ functions co-reside
in one network element; should we consider the case that these functions
reside in separate network elements?

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 8 May 2016 15:27:01 +0000

Hi,

>From my experience, it's always better to define FUNCTIONS and the relationship requirements (trust etc) between them. It is then an implementation issue whether they are located in the physical node.

Of course, IF there is a reason why two functions must be located in the physical node we should say so, but typically that's not the case.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Rifaat Shekh-Yusef<mailto:[email-masked]>
Sent: ‎08/‎05/‎2016 16:25
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3

All,

I did not receive any comment about this version of the text; does this mean that people are happy with the current text?

Also, I have a question that I would like to get people's thoughts about it:
The current text assumes that the AuthN and the AuthZ functions co-reside in one network element; should we consider the case that these functions reside in separate network elements?

Regards,
 Rifaat

On Tue, May 3, 2016 at 8:16 AM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
All,

Thoughts?

Regards,
 Rifaat

---

Overview
--------

                                +--------+
                                | SIP    |

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

IdP Definition:

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

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

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 9 May 2016 19:40:29 +0000

I do think this is getting sharper - the use cases in the Trust Relationships section make a lot of this more clear. Please do number those examples so we can refer to them in discussion.

On authentication, I'm not sure it is so easy or helpful to break it down into user-to-user versus user-to-server authN. A number of ways that we could add identity information to SIP might be totally agnostic to whether a user or server ends up being the relying party, and I don't think we want to cordon these options off from one another. At the end of the day, in cases where identity information is going to be consumed by the recipient of a SIP request, I'd be happier talking about the SIP roles and functions; i.e. text that says something like "authentication information carried in SIP may be consumed by intermediaries such as proxy servers or endpoints such as user agents." How that identity gets rendered to a user or a service is a separate question.

Also, one smaller point on the authentication text: is it that you want "the SIP user to use his non-SIP credentials... to register with the SIP registrar", or, is it that you want the SIP user to be able to use a token generated by the IdP to authenticate to a SIP registrar? Perhaps a question about how we are defining credentials. The latter sounds more like SSO, where the user first logs in to the IdP; the former sounds like the registrar proxies the user's shared secret to the IdP in order to log the user in. Maybe either flow is possible.

It is nice to have a definition of IdP on hand, though there are a couple features of this definition I'd point out. It contains some terms like "principal authentication" which seems to carry a connotation beyond baseline authentication where I'm not entirely sure what is implied.  I'd also single out text that seems very narrow, like, "The IdP sends an attribute assertion containing trusted information about the user to the SP." The term "attribute assertion" there implies much of the classic SAML-like model where the IdP is a broker for accessing a set of fields associated with a user. Is that what we're solving for?

Along those lines, I still do have some confusion about exactly what information we expect the IdP will supply to services for authorization. I guess I imagine the primary decision decision here for carrying authorization information in SIP, as it relates to authentication, is not between a self-contained or opaque token, but is more like these two high level choices:

A) SIP carries the identity of the user as assured by the IdP. Each relying party uses that identity to make an authorization decision about access to its services (like a classic ACL).

B) SIP carries (either by value or by reference) a set of attributes about the user as assured by the IdP. Each relying party uses or more of those attributes to make an authorization decision about access to its services.

Part of my disconnect here is that I think most traditional SSO-style use cases don't require B, they just require A. This makes me think there must be something interesting about the attributes that will be shared here such that an approach more like B is needed. Anonymization is an example of a requirement that gets us closer to B. If we assume the existence of a "self-contained token" that would tell the service everything it needs to know about whether it should authorize a request - what do we imagine that it might contain?

The Trust Relationship use cases shed the most light because they let us know whether the services have a relationship with the user. In an SSO-like case for the "cloud" video conferencing service, if the service has a trust relationship with the customer, rather than with the IdP, that would seem to argue for an A-like authorization method. It is in B-like architectures that the services trust attributes provided by the IdP instead of the identity of the customer. Though again, rather than seeing concepts of "service" and "customer" I'd rather see this be clear about the SIP entities in the architecture that are involved.

Jon Peterson
Neustar, Inc.

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 8, 2016 at 8:27 AM
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3

Hi,

Regards,

Christer

Sent: ?08/?05/?2016 16:25

All,

Regards,
 Rifaat

Thoughts?

Regards,
 Rifaat

---

Overview
--------

                                +--------+
                                | SIP    |

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

IdP Definition:

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

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

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 11 May 2016 12:30:49 -0400

On Mon, May 9, 2016 at 3:40 PM, Peterson, Jon <[email-masked]>
wrote:

>
> I do think this is getting sharper - the use cases in the Trust
> Relationships section make a lot of this more clear. Please do number those
> examples so we can refer to them in discussion.
>
>
Sure.

> On authentication, I'm not sure it is so easy or helpful to break it down
> into user-to-user versus user-to-server authN. A number of ways that we
> could add identity information to SIP might be totally agnostic to whether
> a user or server ends up being the relying party, and I don't think we want
> to cordon these options off from one another. At the end of the day, in
> cases where identity information is going to be consumed by the recipient
> of a SIP request, I'd be happier talking about the SIP roles and functions;
> i.e. text that says something like "authentication information carried in
> SIP may be consumed by intermediaries such as proxy servers or endpoints
> such as user agents." How that identity gets rendered to a user or a
> service is a separate question.
>
>
I guess that depends on how you envision the solution to the various use
cases would work. Let's take the conference server use case as an example:
In this case the user would authenticate to the IdP locally, but that
authenticated user identity does not have to travel all the way to the
conference server; all the conference server should care about is that it
received a token from a trusted entity for a specific domain to authorize
access to its service; the identity of the user is not important to the
server providing the service.

This obviously is not the case with the user-to-user authentication use
case, where the identity of the caller is the main issue at hand.

Also, one smaller point on the authentication text: is it that you want
> "the SIP user to use his non-SIP credentials... to register with the SIP
> registrar", or, is it that you want the SIP user to be able to use a token
> generated by the IdP to authenticate to a SIP registrar? Perhaps a question
> about how we are defining credentials. The latter sounds more like SSO,
> where the user first logs in to the IdP; the former sounds like the
> registrar proxies the user's shared secret to the IdP in order to log the
> user in. Maybe either flow is possible.
>
>
I think that the registrar should *not *be part of the authentication
process at all, and it should never get access to the shared secret. The
whole idea is to delegate the authentication process to the IdP.
The user should authenticate to the IdP, get a token(s) (or a code) and use
that to register with the registrar.

> It is nice to have a definition of IdP on hand, though there are a couple
> features of this definition I'd point out. It contains some terms like
> "principal authentication" which seems to carry a connotation beyond
> baseline authentication where I'm not entirely sure what is implied.  I'd
> also single out text that seems very narrow, like, "The IdP sends an
> attribute assertion containing trusted information about the user to the
> SP." The term "attribute assertion" there implies much of the classic
> SAML-like model where the IdP is a broker for accessing a set of fields
> associated with a user. Is that what we're solving for?
>
> Along those lines, I still do have some confusion about exactly what
> information we expect the IdP will supply to services for authorization. I
> guess I imagine the primary decision decision here for carrying
> authorization information in SIP, as it relates to authentication, is not
> between a self-contained or opaque token, but is more like these two high
> level choices:
>
> A) SIP carries the identity of the user as assured by the IdP. Each
> relying party uses that identity to make an authorization decision about
> access to its services (like a classic ACL).
>
> B) SIP carries (either by value or by reference) a set of attributes about
> the user as assured by the IdP. Each relying party uses or more of those
> attributes to make an authorization decision about access to its services.
>
> Part of my disconnect here is that I think most traditional SSO-style use
> cases don't require B, they just require A. This makes me think there must
> be something interesting about the attributes that will be shared here such
> that an approach more like B is needed. Anonymization is an example of a
> requirement that gets us closer to B. If we assume the existence of a
> "self-contained token" that would tell the service everything it needs to
> know about whether it should authorize a request - what do we imagine that
> it might contain?
>
>
I think that we need two types of tokens; let's, for now, call them *AuthN
Token* and *AuthZ Token*. (we need more that two, but this is good enough
for now).
AuthN Token represents the user identity, while the AuthZ Token represents
the services the user is authorized to access.

The AuthN Token could be used inside the trusted domain but is not required
to leave that trust domain in the user-to-server use cases.
The AuthZ Token is the token that will be allowed to leave the trust domain
and be consumed by the server providing the service.

This would allow us to achieve the SSO inside the trust domain, and control
the access to services inside and outside the trust domain.

> The Trust Relationship use cases shed the most light because they let us
> know whether the services have a relationship with the user. In an SSO-like
> case for the "cloud" video conferencing service, if the service has a trust
> relationship with the customer, rather than with the IdP, that would seem
> to argue for an A-like authorization method. It is in B-like architectures
> that the services trust attributes provided by the IdP instead of the
> identity of the customer. Though again, rather than seeing concepts of
> "service" and "customer" I'd rather see this be clear about the SIP
> entities in the architecture that are involved.
>
>
Ok.

Regards,
 Rifaat

> Jon Peterson
> Neustar, Inc.
>
> From: sipcore <[email-masked]> on behalf of Christer Holmberg <
> [email-masked]>
> To: Rifaat Shekh-Yusef <[email-masked]>, "[email-masked]" <
> [email-masked]>
> >From my experience, it's always better to define FUNCTIONS and the
> relationship requirements (trust etc) between them. It is then an
> implementation issue whether they are located in the physical node.
>
> Of course, IF there is a reason why two functions must be located in the
> physical node we should say so, but typically that's not the case.
>
> Regards,
>
> Christer
>
> ------------------------------
> From: Rifaat Shekh-Yusef <[email-masked]>
> To: [email-masked]
>> |        |      |        |  :                 :  |        |      |
>>  |

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 13 May 2016 17:25:49 +0000

I guess that depends on how you envision the solution to the various use cases would work. Let's take the conference server use case as an example:
In this case the user would authenticate to the IdP locally, but that authenticated user identity does not have to travel all the way to the conference server; all the conference server should care about is that it received a token from a trusted entity for a specific domain to authorize access to its service; the identity of the user is not important to the server providing the service.

I think we need to distinguish cases where the conference server doesn't care about the user identity from cases where, for various reason, the identity of the user must be withheld from the conference server. Ultimately, if relying parties are going to receive this token, whatever it is, and then query an authorization server for more specific instructions, then it matters whether the user identity can serve as a key for that query, or whether it must not serve as a key for that query to achieve some security or policy aim. This is the distinction I was trying to inject into this discussion.

I think that the registrar should not be part of the authentication process at all, and it should never get access to the shared secret. The whole idea is to delegate the authentication process to the IdP.
The user should authenticate to the IdP, get a token(s) (or a code) and use that to register with the registrar.

That is what I assumed you meant; I just wanted to make sure that the description of "credential" here was crisp enough for us to use.

I think that we need two types of tokens; let's, for now, call them AuthN Token and AuthZ Token. (we need more that two, but this is good enough for now).

Statements of that form make me very wary. I can imagine that there would be two ways to do this, one where we have the identity of the user serve as a key and one where we don't. When you suggest we need a plurality of tokens, you're setting us up for a world of complexity and non-interoperability.

AuthN Token represents the user identity, while the AuthZ Token represents the services the user is authorized to access.

The AuthN Token could be used inside the trusted domain but is not required to leave that trust domain in the user-to-server use cases.
The AuthZ Token is the token that will be allowed to leave the trust domain and be consumed by the server providing the service.

As a scope decision, that seems pretty arbitrary. Again, as I said previously, I have a hard time imagining why we would want to specify an AuthN mechanism that works inside the trusted domain but will require something else if it leaves the trust domain. If a UA implementation can't anticipate whether or not a SIP request is going to terminate in the local trust domain (and ordinarily, how could it?), then it would always have to add both. In addition of course to the From header. And don't forge the PAI. And however many other things 3GPP has us stuff into these messages that carry the "real" identity of the user.

Our job is to arrive at architectural commonality, and to reduce the needless proliferation of identifiers in SIP requests.

This would allow us to achieve the SSO inside the trust domain, and control the access to services inside and outside the trust domain.

I think achieving SSO inside a trust domain can be achieved with virtually no new protocol work on our part. It is understanding the need for anonymity here, and the precise requirement for access control for SIP services, and how those are entangled with the aforementioned SSO identifiers, that seems potentially worth a dispatch.

Jon Peterson
Neustar, Inc.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 15 May 2016 09:28:33 -0400

On Fri, May 13, 2016 at 1:25 PM, Peterson, Jon <[email-masked]>
wrote:

> I think we need to distinguish cases where the conference server doesn't
> care about the user identity from cases where, for various reason, the
> identity of the user must be withheld from the conference server.
>

Can you please elaborate on this?
Can you provide an example?

> Ultimately, if relying parties are going to receive this token, whatever
> it is, and then query an authorization server for more specific
> instructions, then it matters whether the user identity can serve as a key
> for that query, or whether it must not serve as a key for that query to
> achieve some security or policy aim. This is the distinction I was trying
> to inject into this discussion.
>
> That is what I assumed you meant; I just wanted to make sure that the
> description of "credential" here was crisp enough for us to use.
>
>
Ok. I will clarify the text.

> Statements of that form make me very wary. I can imagine that there would
> be two ways to do this, one where we have the identity of the user serve as
> a key and one where we don't. When you suggest we need a plurality of
> tokens, you're setting us up for a world of complexity and
> non-interoperability.
>
>
There are few advantages to the idea of creating separate tokens for AuthN
and AuthZ:
1. Allows separate independent entities to provide these functionalities,
with some established trust between them.
2. Allows staged adoption of the new recommendation; you could start with
delegation of authentication, and at a later stage delegate the
authorization.

> The AuthN Token could be used inside the trusted domain but is not
> required to leave that trust domain in the user-to-server use cases.
> The AuthZ Token is the token that will be allowed to leave the trust
> domain and be consumed by the server providing the service.
>
>
> As a scope decision, that seems pretty arbitrary. Again, as I said
> previously, I have a hard time imagining why we would want to specify an
> AuthN mechanism that works inside the trusted domain but will require
> something else if it leaves the trust domain. If a UA implementation can't
> anticipate whether or not a SIP request is going to terminate in the local
> trust domain (and ordinarily, how could it?), then it would always have to
> add both. In addition of course to the From header. And don't forge the
> PAI. And however many other things 3GPP has us stuff into these messages
> that carry the "real" identity of the user.
>
>
It is not the UA's role to decide where a token would travel or not. In
fact in some use cases the UA would never get access to any token at all.

> Our job is to arrive at architectural commonality, and to reduce the
> needless proliferation of identifiers in SIP requests.
>
>
I am all for that; the question is how to achieve that.

> This would allow us to achieve the SSO inside the trust domain, and
> control the access to services inside and outside the trust domain.
>
>
> I think achieving SSO inside a trust domain can be achieved with virtually
> no new protocol work on our part.
>

Can you please elaborate on this?
Keep in mind the use cases and the different types of endpoints and their
limitations.

Regards,
 Rifaat

> It is understanding the need for anonymity here, and the precise
> requirement for access control for SIP services, and how those are
> entangled with the aforementioned SSO identifiers, that seems potentially
> worth a dispatch.
>
> Jon Peterson
> Neustar, Inc.
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 18 May 2016 17:29:21 +0000

I think we need to distinguish cases where the conference server doesn't care about the user identity from cases where, for various reason, the identity of the user must be withheld from the conference server.

Some identity federation architectures require that you conceal the user's identity from a relying party while still sharing attributes about that user. For example, in a single sign-on system that allows users to access a streaming video game service, the IdP might want to share with the service an attribute attesting that the user is over 18 (and can thus play "M" rated games) but not share the user's name or other personally identifying information.

In any attribute-sharing scheme, you're going to be sharing some token that lets relying parties access attributes associated with the individual. In cases where you can share the user's identity, often the identity is the best token. In cases where you can't, you need something else, something more opaque. I think this is a fundamental distinction in the architecture and pretty much the only reason not to use one of our existing ways of sharing identity as the token issued by an IdP.

Well, actually, you said you wanted more than two ways to do this, so I didn't get the sense from your prior statement that commonality was your priority. It is mine.

I think achieving SSO inside a trust domain can be achieved with virtually no new protocol work on our part.

Can you please elaborate on this?
Keep in mind the use cases and the different types of endpoints and their limitations.

We already have ways to carry around an identity in SIP. Within one trust domain, you don't have the kinds of confidentiality requirements that I articulate above, so surely one of our existing ways of sharing identity would suffice. It is only when the identity crosses administrative boundaries, in situations closer to a federated identity architecture, that you start seeing requirements to share only selected information. So I should be careful when we talk about "trust domains," as these federated cases amount only to partial trust, but that was what I meant.

Jon Peterson
Neustar, Inc.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 23 May 2016 08:03:55 -0400

On Wed, May 18, 2016 at 1:29 PM, Peterson, Jon <[email-masked]>
wrote:

> Some identity federation architectures require that you conceal the user's
> identity from a relying party while still sharing attributes about that
> user. For example, in a single sign-on system that allows users to access a
> streaming video game service, the IdP might want to share with the service
> an attribute attesting that the user is over 18 (and can thus play "M"
> rated games) but not share the user's name or other personally identifying
> information.
>
> In any attribute-sharing scheme, you're going to be sharing some token
> that lets relying parties access attributes associated with the individual.
> In cases where you can share the user's identity, often the identity is the
> best token. In cases where you can't, you need something else, something
> more opaque. I think this is a fundamental distinction in the architecture
> and pretty much the only reason not to use one of our existing ways of
> sharing identity as the token issued by an IdP.
>
>
Yet another reason to separate AuthN and AuthZ tokens.

> Well, actually, you said you wanted more than two ways to do this, so I
> didn't get the sense from your prior statement that commonality was your
> priority. It is mine.
>
>
Sure :)

I did not mean to imply that it is a *priority *for me.
But I am definitely willing and interested in discussing the idea to see if
we can come up with a way to do that, hence this whole exercise; but I am
not seeing it yet, and I was hoping that you could help me see it, assuming
that there is indeed a way to do that.

>> I think achieving SSO inside a trust domain can be achieved with
>> virtually no new protocol work on our part.
>>
>
> We already have ways to carry around an identity in SIP. Within one trust
> domain, you don't have the kinds of confidentiality requirements that I
> articulate above, so surely one of our existing ways of sharing identity
> would suffice. It is only when the identity crosses administrative
> boundaries, in situations closer to a federated identity architecture, that
> you start seeing requirements to share only selected information. So I
> should be careful when we talk about "trust domains," as these federated
> cases amount only to partial trust, but that was what I meant.
>
>
I guess it depends on your definition of *identity*; if it is the name and
the AOR of the user, then you are correct that we have ways to carry this
information in SIP today.
But *identity* could include many other attributes like: address, age,
contact info, etc; in this case SIP does not have away to carry all that
info which could be included in a token.

Also, if we decided to separate the AuthN and AuthZ, then we might need to
carry more than one token.
Another issues in the need, in some cases, to avoid sending the token to
the UA; in this case there is a need for an interim step to get the
token(s) to the SIP proxy.

I do not know how you could achieve all of that " with virtually no new
protocol work on our part".

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 May 2016 11:47:56 -0400

On 5/23/16 8:03 AM, Rifaat Shekh-Yusef wrote:

>     We already have ways to carry around an identity in SIP. Within one
>     trust domain, you don't have the kinds of confidentiality
>     requirements that I articulate above, so surely one of our existing
>     ways of sharing identity would suffice. It is only when the identity
>     crosses administrative boundaries, in situations closer to a
>     federated identity architecture, that you start seeing requirements
>     to share only selected information. So I should be careful when we
>     talk about "trust domains," as these federated cases amount only to
>     partial trust, but that was what I meant.
>
> I guess it depends on your definition of *identity*; if it is the name
> and the AOR of the user, then you are correct that we have ways to carry
> this information in SIP today.

That mixes up *identity* from properties/attributes of the identified 
entity. Even the name (display name) is a property. It typically isn't 
an identity because it isn't unique.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 23 May 2016 12:12:12 -0400

On Mon, May 23, 2016 at 11:47 AM, Paul Kyzivat <[email-masked]>
wrote:

> entity. Even the name (display name) is a property. It typically isn't an
> identity because it isn't unique.
>
>
Yeah, you are right.
I will try to to make sure that this is clear in the next version of the
text.

Regards,
 Rifaat

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 May 2016 19:06:59 +0000

Also, if we decided to separate the AuthN and AuthZ, then we might need to carry more than one token.

I could see an argument that there is a need to carry the identity of the user in one header, and a reference to a place where you can get attributes about the originating user in another header, say. That's more or less what we envisioned the last time we went down this path, which led to the RFC4484 requirements, largely informed by SAML (which I seem to recall 3GPP was interested in at the time).

But it's no accident that the work on RFC4484 never went beyond requirements. Today, I think that much of the useful work that could be done on the authorization question is in identifying which SIP authorization policies are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conceive of applications adjunct to communications that would require attributes, the challenge has been justifying why you would invoke those applications with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close to those of placing a telephone call.  The authorization policies of a telephone call are really different than that of a web service, say, both in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain interaction can occur. With appropriate caveats for other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy requirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, and their interaction with identity information. But just saying that there might be a video conference service in the cloud, say, doesn't shed a lot of light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who opens the conference bridge needs to be charged, that's identity information - which in its usual form will convey the individual user and their domain, like user@domain. If you need more complex semantics than that, it's probably because you're doing something more complicated than just calling in to the conference. But it's less clear to me why you'd use SIP for such cases. Drilling down deeper into these use cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which largely involve billing (including when dealing with various protocol gateways) and resource management (both preemption and priority), ultimately didn't seem sufficient to motivate protocol work.

Another issues in the need, in some cases, to avoid sending the token to the UA; in this case there is a need for an interim step to get the token(s) to the SIP proxy.

If this information is carried in headers, then presumably it could be added, consumed, subtracted, or whatever by any relevant intermediaries.

Jon Peterson
Neustar, Inc.

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Thu, 26 May 2016 17:27:56 +0000

Hi, Jon:

You have done an excellent analysis of the SIP call scenario described below: User and Conferencing server.

Recently, media resource broker (MRB) RFC 6917 has been standardized. If the conferencing server interacts with MRB for setting up the media, the SIP call scenario also need to include MRB.

I like to see your analysis whether the existing security parameters of SIP are sufficient for AuthN and AuthZ.

In another note, we have not addressed the application sharing using SIP call (similar along the line of MRB). It may be another item we may look in the future, if there is a need. Right now, application sharing happens independent of the SIP call.

BR/Radhika 

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, May 25, 2016 3:07 PM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3

Jon Peterson
Neustar, Inc.

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Fri, 27 May 2016 20:56:53 +0000

Hi, Jon:

I forgot to add a couple of other RFCs related to the security issue: SIP-based centralized conferencing control manipulation protocol (CCMP) - RFC 4582 and Binary Floor Control Protocol (BFCP) - RFC 4582.

So, we have three RFCs with different protocols (RFC 4582 - CCMP, RFC 4582 - BFCP, and RFC 6917 - MRB) that are needed in the context SIP-based conferencing call at least for now (although other applications may appear in the future when multimedia conferencing becomes a usual feature over the public Internet like multimedia streaming).

The key is that all of them need SIP Conferencing UAs (XCON) AuthN and AuthZ. 

Now, we get a more complex scenario of SIP-based conferencing that is directly related to media (MRB) for its media part, BFCP may be thought a kind of application sharing, and CCMP manipulated the overall conference that is being "originally" initiated by SIP Conferencing UAs (XCON).

It appears that there is a dependency between SIP, CCMP, MRB, and BFCP. 

It makes the security scenario more interesting because there are four  different protocols (SIP, CCMP, MRB, and BFCP) although all of those protocols must coordinate internally among themselves making conferencing successful, and security function is one of them.

Again, I like to see your analysis whether the existing security parameters of SIP are sufficient for AuthN and AuthZ.

BR/Radhika 

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Roy, Radhika R CIV USARMY RDECOM CERDEC (US)
Sent: Thursday, May 26, 2016 1:28 PM
To: Peterson, Jon <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] [Non-DoD Source] Re: SIP AuthNZ Problem Statement - v3

All active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.  

----

Hi, Jon:

BR/Radhika 

-----Original Message-----
From: sipcore [Caution-mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Wednesday, May 25, 2016 3:07 PM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [sipcore] SIP AuthNZ Problem Statement - v3

But it's no accident that the work on RFC4484 never went beyond requirements. Today, I think that much of the useful work that could be done on the authorization question is in identifying which SIP authorization policies are likely to depend on attributes as opposed to just the identity of the end user. While we can readily conceive of applications adjunct to communications that would require attributes, the challenge has been justifying why you would invoke those applications with SIP rather than, say, HTTP.  The fundamental semantics of a SIP INVITE have remained pretty close to those of placing a telephone call.  The authorization policies of a telephone call are really different than that of a web service, say, both in terms of how and why they are invoked, what kinds of parties are involved, what forms redirection or cross-domain interaction can occur. With appropriate caveats for other methods (notably MESSAGE, SUBSCRIBE/NOTIFY. INFO), SIP requests have authorization policy re
 quirements that look a lot like call treatment policies.

That much said, I am kind of interested in call treatment policies, and their interaction with identity information. But just saying that there might be a video conference service in the cloud, say, doesn't shed a lot of light for me. If there's a video conference, I'd ordinarily think you just call into it. If the user who opens the conference bridge needs to be charged, that's identity information - which in its usual form will convey the individual user and their domain, like user@domain. If you need more complex semantics than that, it's probably because you're doing something more complicated than just calling in to the conference. But it's less clear to me why you'd use SIP for such cases. Drilling down deeper into these use cases would help me understand where we're going, anyway - the use cases in RFC4484 Section 4, which largely involve billing (including when dealing with various protocol gateways) and resource management (both preemption and priority), ultimately didn't se
 em sufficient to motivate protocol work.

Jon Peterson
Neustar, Inc.

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