Subject: [sipcore] SIP Authentication/Authorization Problem Statement

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 20 Apr 2016 13:40:55 -0400

All,

A group of us decided to take a step back from discussing the SIP OAuth
document, and instead decided to discuss the SIP
Authentication/Authorization problem to allow the different parties to
articulate where they are coming from and what problem they are trying to
solve.

I started this discussion with the following text as a starting point:

The following is a simplified classic SIP deployment model:

+--------+                      +--------+                      +--------+

|        |                      | SIP    |                      | SIP App|

|   UA   |----------------------| Proxy  |----------------------| Server |

|        |                      |        |                      |        |

+--------+                      +--------+                      +--------+

With this model, the endpoint is assigned an outbound SIP proxy and all SIP
communications must go through that SIP proxy.

The SIP Proxy 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):

The first goal is to “outsource” the user authentication part to a
separate IdP entity, to allow the SIP user to use his credentials with the
IdP to register with the SIP Proxy and get basic SIP services, and to get
access to the advanced services provided by the SIP Application Servers.

The second goal is to “outsource” 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.

I also explained that my motivation for this work is to address few
*Enterprise* use cases, which mainly include the Single-Sign On use case
where the user is authenticated once and as a result the user gets access
to a variety of SIP and non-SIP services, and a centralized authorization
use case where the administrator is able to authorize access to these
services from one network element.

Jon suggested that there are several use cases that we should be looking
at, and he articulated these use cases as follows:

But more to my point (and I suspect Adam's) there are several distinct use
cases for SIP that involve adding a secure attestation about the user to
SIP requests that will be consumed and trusted by some entity downstream.
This problem is probably generic to whether the meat of that assertion is
fetched from a network service or generated locally at a SIP entity - for
SIP Identity-like architectures, one might say the IdP-ish component of the
architecture (the "authentication service") is typically colocated with a
proxy server, for example. In some cases, the relying parties downstream
are in the same trust domain as the attester/user, and in some cases they
could be in a different trust domain. It may vary in the confidentiality of
the assertion, or indeed in the confidentiality of the user's identity.
This encompasses interworking with external protocols like Jingle and
WebRTC, this encompasses preventing impersonation, this potentially
involves enterprise use cases like Cullen was talking about.

Adam elaborated on Jon’s statement that talks about “different trust
domains” as follows:

I believe he's referring to the kind of use cases addressed by RFC 4474 and
by the work currently going on in STIR -- ones in which some entity asserts
the identity of a party in the call for use by an entity in a completely
unrelated trust domain.

There's also the matter of interdomain trait-based authorization
(independent of identity). The introduction section of RFC 4484 is a really
good place to start if you're not familiar with the concept.

At this point Adam, as SIPCORE chair, suggested that we continue this
discussion on the SIPCORE mailing list. So here we are…

Regards,

 Rifaat

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Wed, 20 Apr 2016 18:17:49 +0000

Hi, Rifaat and all:

In addition, you can also look into SIP-related authentication/Authorization in DIAMETER/RADIUS RFCs - how they use AAA protocol to address the similar problem.

BR/Radhika 

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 20, 2016 1:41 PM
To: [email-masked]
Subject: [Non-DoD Source] [sipcore] SIP Authentication/Authorization Problem Statement

All,

A group of us decided to take a step back from discussing the SIP OAuth document, and instead decided to discuss the SIP Authentication/Authorization problem to allow the different parties to articulate where they are coming from and what problem they are trying to solve.

|        |                      | SIP    |                      | SIP App|

|        |                      |        |                      |        |

With this model, the endpoint is assigned an outbound SIP proxy and all SIP communications must go through that SIP proxy.

2. Authorization Server

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):

The first goal is to “outsource” the user authentication part to a separate IdP entity, to allow the SIP user to use his credentials with the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP Application Servers.

The second goal is to “outsource” 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.

I also explained that my motivation for this work is to address few *Enterprise* use cases, which mainly include the Single-Sign On use case where the user is authenticated once and as a result the user gets access to a variety of SIP and non-SIP services, and a centralized authorization use case where the administrator is able to authorize access to these services from one network element.

Jon suggested that there are several use cases that we should be looking at, and he articulated these use cases as follows:

But more to my point (and I suspect Adam's) there are several distinct use cases for SIP that involve adding a secure attestation about the user to SIP requests that will be consumed and trusted by some entity downstream. This problem is probably generic to whether the meat of that assertion is fetched from a network service or generated locally at a SIP entity - for SIP Identity-like architectures, one might say the IdP-ish component of the architecture (the "authentication service") is typically colocated with a proxy server, for example. In some cases, the relying parties downstream are in the same trust domain as the attester/user, and in some cases they could be in a different trust domain. It may vary in the confidentiality of the assertion, or indeed in the confidentiality of the user's identity. This encompasses interworking with external protocols like Jingle and WebRTC, this encompasses preventing impersonation, this potentially involves enterprise use cases like Cullen was talking about. 

Adam elaborated on Jon’s statement that talks about “different trust domains” as follows:

I believe he's referring to the kind of use cases addressed by RFC 4474 and by the work currently going on in STIR -- ones in which some entity asserts the identity of a party in the call for use by an entity in a completely unrelated trust domain.

There's also the matter of interdomain trait-based authorization (independent of identity). The introduction section of RFC 4484 is a really good place to start if you're not familiar with the concept.

At this point Adam, as SIPCORE chair, suggested that we continue this discussion on the SIPCORE mailing list. So here we are…

Regards,

 Rifaat

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 20 Apr 2016 18:59:12 +0000

I am definitely supportive of trying to find a common problem statement here to reconcile the numerous ways that we seem to be specifying identity assertions in SIP (and in related real-time communication protocols). Authorization, because of its implications for policy and trust models, has been a thornier topic for us to cover, though I'm open to developing a problem statement for it as well (RFC4484 notably never got any farther than requirements).

I think to get this into the shape we'd need a problem statement to be, we need to be more specific about what we mean by "IdP" and "Authorization Server" in the starting point discussion below. If an IdP is just an entity that provides some kind of token that can be added to SIP messages asserting the identity of the originator, for example, then we have a number of overlapping mechanisms that do that. Getting a single sign-on experience, such that a SIP entities is authenticated by a service that creates an assertion added to SIP requests that can be validated and trusted by entities receiving the request is probably achievable without any new protocol work. But If we mean something more specific by "IdP," we need to narrow in on what that is.

For an "Authorization Server," well, I think the function of that entity is somewhat unclear in the statement below. I agree that today, authorization decisions are made by the entities that receive SIP requests based on some sort of local policy predicated on trust relationships dictated by the controller of the device. The distinction between the owner or controller of the device and the "administrator" of this authorization architecture isn't clear to me from reading this, nor is it clear what information the "advanced" services residing in app servers might need to make an authorization decision. The nature of that information will dictate much of the requirements here: to whom can it be revealed, and to whom must it be confidential; how is it structured; etc.

My point about "trust domains" below is tied up in questions about the scope of the identity and authorization mechanism. Can or should the assertion be trusted by relying parties who have no previous association with the issuer of the token, for example? For the "Authorization Server" function, since it assumes an "administrator" who can authorize access to a set of resources under its control, I'd imagine that the only relying parties that would accept the token have a very clear prior association with the "administrator" (though we'd need to say more about what we imagine it would be). In federated identity models that come up fairly often, you sometimes do have trust across domain boundaries that is significantly looser. If that's in scope, that's important to understand.

Jon Peterson
Neustar, Inc.

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 20, 2016 at 10:40 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sipcore] SIP Authentication/Authorization Problem Statement

All,

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Apr 2016 20:21:51 +0000

Hi Jon,

Thanks for your input! A comment below.

...

>I think to get this into the shape we'd need a problem statement to be, we need to be more specific about what we mean by "IdP" and "Authorization Server" in the starting point discussion below. If an IdP is just an >entity that provides some kind of token that can be added to SIP messages asserting the identity of the originator, for example, then we have a number of overlapping mechanisms that do that. Getting a single sign->on experience, such that a SIP entities is authenticated by a service that creates an assertion added to SIP requests that can be validated and trusted by entities receiving the request is probably achievable without any >new protocol work. But If we mean something more specific by "IdP," we need to narrow in on what that is.

We will probably need different definitions of "IdP", depending on the use-case. For example, in the 3GPP use-case the IdP is just an entity that provides some kind of token.

However, even in that case, carrying that token in SIP does require some protocol work.

Regards,

Christer

All,

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

The first goal is to "outsource" the user authentication part to a separate IdP entity, to allow the SIP user to use his credentials with the IdP to register with the SIP Proxy and get basic SIP services, and to get access to the advanced services provided by the SIP Application Servers.

The second goal is to "outsource" 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.

Adam elaborated on Jon's statement that talks about "different trust domains" as follows:

At this point Adam, as SIPCORE chair, suggested that we continue this discussion on the SIPCORE mailing list. So here we are...

Regards,
 Rifaat

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 20 Apr 2016 22:07:49 -0400

> The first goal is to "outsource" the user authentication part to a
> The second goal is to "outsource" the authorization part to a separate

I have a hard time thinking about this without knowing what the dataflow
is.  I don't know if this limitation is intrinsic to the subject or just
how I think.

For example, in the sipX system, calls are only allowed to exit the
IP->PSTN gateway if they arrive at the gateway directly from the proxy,
and the proxy verifies that the SIP caller is allowed to make a PSTN
call to the specific destination.  So in that example, the UA contains
the user's credentials, which it attaches to the request and sends to
the proxy.  (Let's neglect how the UA gets a valid nonce.)  The proxy
authenticates the user and then authorizes the user to make a PSTN call
to the particular E.164 number.  It then attaches an authorization token
to the request (i.e., the IP source address) to the request and sends it
to the application server (gateway).

It seems like permission to use the app server requires two steps: (1)
authentication of the source, and then (2) authorization of the source
to use the service.  These can be done together in one place (as in the
above example) or they can be done in two places.  In principle, either
step can be done in either the proxy or the app server, or even the UA.
The entity that performs a step can outsource it to another server.  If
either step is done by the proxy, it needs to attach to the request some
sort of token indicating that the step has been completed before sending
the request to the app server.

It seems like there are a dozen or more dataflow patterns that could be
used to "outsource" one or both of these steps.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Apr 2016 12:46:43 +0000

Hi,

A few comments on the text:

First, I don’t think we should say “outbound SIP proxy”. That may confuse people with RFC 5256, and I assume that is not what you are talking about. Why not simply call it “SIP registrar”?

Second, when we talk about credentials, we must be clear on what kind of credentials we talk about.

Third, it is good trying to come up with a set of goals, but it needs to be clear that for some use-cases only some goals may apply.

Thanks!

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: 20 April 2016 20:41
To: [email-masked]
Subject: [sipcore] SIP Authentication/Authorization Problem Statement

All,

Regards,
 Rifaat

---

From: Robert Sparks <[email-masked]>
Date: Thu, 21 Apr 2016 09:30:44 -0500

On 4/21/16 7:46 AM, Christer Holmberg wrote:
> First, I don’t think we should say “outbound SIP proxy”. That may 
> confuse people with RFC 5256, and I assume that is not what you are 
> talking about. Why not simply call it “SIP registrar”?
>
Because it's not acting only as a registrar, at least in that example. 
Routes (loaded with Service-Route I assume?) are forcing traffic through 
it. If it has a role to play in this auth/auth story when messages go 
through it in this role, it needs to have a named player, and registrar 
would be even more confusing. (Does it have such a role?)

It might be even more useful to show any proxies put on the path by 
Route establishing mechanisms (preloaded or provided by Service-Route) 
as separate from the registrar, even if the roles are combined in one 
box a given deployment.
> Third, it is good trying to come up with a set of goals, but it needs 
> to be clear that for some use-cases only some goals may apply.
>
> Thanks!
>
> Regards,
>
> Christer
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Rifaat 
> Shekh-Yusef
> *Sent:* 20 April 2016 20:41
> *To:* [email-masked]
> *Subject:* [sipcore] SIP Authentication/Authorization Problem Statement
>
> All,
>
> A group of us decided to take a step back from discussing the SIP 
> OAuth document, and instead decided to discuss the SIP 
> articulate where they are coming from and what problem they are trying 
> to solve.
>
> With this model, the endpoint is assigned an outbound SIP proxy and 
> all SIP communications must go through that SIP proxy.
>
> 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):
>
> separate IdP entity, to allow the SIP user to use his credentials with 
> the IdP to register with the SIP Proxy and get basic SIP services, and 
> to get access to the advanced services provided by the SIP Application 
> Servers.
>
> 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.
>
> *Enterprise* use cases, which mainly include the Single-Sign On use 
> case where the user is authenticated once and as a result the user 
> gets access to a variety of SIP and non-SIP services, and a 
> centralized authorization use case where the administrator is able to 
> authorize access to these services from one network element.
>
> Jon suggested that there are several use cases that we should be 
> looking at, and he articulated these use cases as follows:
>
> But more to my point (and I suspect Adam's) there are several distinct 
> use cases for SIP that involve adding a secure attestation about the 
> user to SIP requests that will be consumed and trusted by some entity 
> downstream. This problem is probably generic to whether the meat of 
> that assertion is fetched from a network service or generated locally 
> at a SIP entity - for SIP Identity-like architectures, one might say 
> the IdP-ish component of the architecture (the "authentication 
> service") is typically colocated with a proxy server, for example. In 
> some cases, the relying parties downstream are in the same trust 
> domain as the attester/user, and in some cases they could be in a 
> different trust domain. It may vary in the confidentiality of the 
> assertion, or indeed in the confidentiality of the user's identity. 
> I believe he's referring to the kind of use cases addressed by RFC 
> 4474 and by the work currently going on in STIR -- ones in which some 
> entity asserts the identity of a party in the call for use by an 
> entity in a completely unrelated trust domain.
>
> (independent of identity). The introduction section of RFC 4484 is a 
> really good place to start if you're not familiar with the concept.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 23 Apr 2016 07:30:50 -0400

Thanks Jon!

Please, see my reply inline...

Regards,
 Rifaat

On Wed, Apr 20, 2016 at 2:59 PM, Peterson, Jon <[email-masked]>
wrote:

>
> I am definitely supportive of trying to find a common problem statement
> here to reconcile the numerous ways that we seem to be specifying identity
> assertions in SIP (and in related real-time communication protocols).
> Authorization, because of its implications for policy and trust models, has
> been a thornier topic for us to cover, though I'm open to developing a
> problem statement for it as well (RFC4484 notably never got any farther
> than requirements).
>
> I think to get this into the shape we'd need a problem statement to be, we
> need to be more specific about what we mean by "IdP" and "Authorization
> Server" in the starting point discussion below. If an IdP is just an entity
> that provides some kind of token that can be added to SIP messages
> asserting the identity of the originator, for example, then we have a
> number of overlapping mechanisms that do that.
>

Yes, I agree with that.
This is one of the challenges that we need to discuss and address. Should
we support multiple mechanisms? should we select one to rule them all?
other options?

> Getting a single sign-on experience, such that a SIP entities is
> authenticated by a service that creates an assertion added to SIP requests
> that can be validated and trusted by entities receiving the request is
> probably achievable without any new protocol work.
>

That depends on how you get that assertion. Do you get it directly or
indirectly through some interim step?
This is dictated by the type of client you are using; the following client
limitation would require an interim step:
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 away to get the assertion to the servers
that will provide the service without requiring the client to get access to
the assertion.

Another part that we need to think about is how to carry the assertion in a
SIP message.

> But If we mean something more specific by "IdP," we need to narrow in on
> what that is.
>
> For an "Authorization Server," well, I think the function of that entity
> is somewhat unclear in the statement below. I agree that today,
> authorization decisions are made by the entities that receive SIP requests
> based on some sort of local policy predicated on trust relationships
> dictated by the controller of the device. The distinction between the owner
> or controller of the device and the "administrator" of this authorization
> architecture isn't clear to me from reading this, nor is it clear what
> information the "advanced" services residing in app servers might need to
> make an authorization decision. The nature of that information will dictate
> much of the requirements here: to whom can it be revealed, and to whom must
> it be confidential; how is it structured; etc.
>
>
Ok. I will add more details to clarify these aspects.
In general, I can think of two possible ways to provide authorization:
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.
Do you see other options here?

My point about "trust domains" below is tied up in questions about the
> scope of the identity and authorization mechanism. Can or should the
> assertion be trusted by relying parties who have no previous association
> with the issuer of the token, for example?
>

As I mentioned before, my motivation for this work was to address few
*Enterprise
*use cases, so this use case was out of scope for what I was trying to
accomplish.

> For the "Authorization Server" function, since it assumes an
> "administrator" who can authorize access to a set of resources under its
> control, I'd imagine that the only relying parties that would accept the
> token have a very clear prior association with the "administrator" (though
> we'd need to say more about what we imagine it would be).
>

Yes. Sure, I will add more details to cover this.

> In federated identity models that come up fairly often, you sometimes do
> have trust across domain boundaries that is significantly looser. If that's
> in scope, that's important to understand.
>
>
I am definitely open to discussing this and see if we can find a common
solution that would apply to this use case too.

Regards,
 Rifaat

> Jon Peterson
> Neustar, Inc.
>
> From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> With this model, the endpoint is assigned an outbound SIP proxy and all
> SIP communications must go through that SIP proxy.
>
>
>
> I believe he's referring to the kind of use cases addressed by RFC 4474
> and by the work currently going on in STIR -- ones in which some entity
> asserts the identity of a party in the call for use by an entity in a
> completely unrelated trust domain.
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 23 Apr 2016 07:39:41 -0400

Thanks Radhika,

I need to educate myself about Diameter/Radius and the SIP-related RFCs.
Meanwhile, please feel free to chime in with any thoughts about this
discussion based on your experience with Diameter/Radius.

Regards,
 Rifaat

On Wed, Apr 20, 2016 at 2:17 PM, Roy, Radhika R CIV USARMY RDECOM CERDEC
(US) <[email-masked]> wrote:

> Hi, Rifaat and all:
>
> In addition, you can also look into SIP-related
> authentication/Authorization in DIAMETER/RADIUS RFCs - how they use AAA
> protocol to address the similar problem.
>
> BR/Radhika
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 23 Apr 2016 07:55:47 -0400

Thanks Dale!

Yes, you are absolutely right.

Two steps are needed: authentication of the user and authorization to
access services.
These could be done by one new network element, or could be done by two
separate network elements.

We need to discuss these options and pros and cons of each.

Regards,
 Rifaat

On Wed, Apr 20, 2016 at 10:07 PM, Dale R. Worley <[email-masked]> wrote:

> > |        |                      | SIP    |                      | SIP
> App|
> > |        |                      |        |                      |
> |
> the

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 23 Apr 2016 08:07:26 -0400

Christer,

I agree with your second and third points below.

Regarding the first point, I agree with Robert, that calling it SIP
Registrar might be even more confusing.

Robert,

Yes, the proxy would have an important role to play in the authNZ
(authentication/authorization) story.
I like you suggestion of explicitly separating the registrar function from
the proxy function. I will do that in the next version of the text.

Regards,
 Rifaat

On Thu, Apr 21, 2016 at 10:30 AM, Robert Sparks <[email-masked]>
wrote:

> First, I don’t think we should say “outbound SIP proxy”. That may confuse
> people with RFC 5256, and I assume that is not what you are talking about.
> Why not simply call it “SIP registrar”?
>
> It might be even more useful to show any proxies put on the path by Route
> establishing mechanisms (preloaded or provided by Service-Route) as
> separate from the registrar, even if the roles are combined in one box a
> given deployment.
>
>
>
> Third, it is good trying to come up with a set of goals, but it needs to
> be clear that for some use-cases only some goals may apply.
>
>
>
> Thanks!
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* sipcore [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Rifaat Shekh-Yusef
> sipcore mailing [email-masked]://www.ietf.org/mailman/listinfo/sipcore
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 24 Apr 2016 13:09:48 +0000

Hi,

We can call it something else, but I don't think we should call it "outbound proxy".

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Rifaat Shekh-Yusef<mailto:[email-masked]>
Sent: ‎23/‎04/‎2016 15:07
To: Robert Sparks<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] SIP Authentication/Authorization Problem Statement

Christer,

Regarding the first point, I agree with Robert, that calling it SIP Registrar might be even more confusing.

Robert,

Yes, the proxy would have an important role to play in the authNZ (authentication/authorization) story.
I like you suggestion of explicitly separating the registrar function from the proxy function. I will do that in the next version of the text.

Regards,
 Rifaat

On Thu, Apr 21, 2016 at 10:30 AM, Robert Sparks <[email-masked]<mailto:[email-masked]>> wrote:

First, I don’t think we should say “outbound SIP proxy”. That may confuse people with RFC 5256, and I assume that is not what you are talking about. Why not simply call it “SIP registrar”?
Because it's not acting only as a registrar, at least in that example. Routes (loaded with Service-Route I assume?) are forcing traffic through it. If it has a role to play in this auth/auth story when messages go through it in this role, it needs to have a named player, and registrar would be even more confusing. (Does it have such a role?)

It might be even more useful to show any proxies put on the path by Route establishing mechanisms (preloaded or provided by Service-Route) as separate from the registrar, even if the roles are combined in one box a given deployment.

Thanks!

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: 20 April 2016 20:41
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] SIP Authentication/Authorization Problem Statement

All,

Regards,
 Rifaat

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

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