Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 4 Jul 2016 09:54:20 -0400

On Thu, Jun 30, 2016 at 4:03 PM, Peterson, Jon <[email-masked]>
wrote:

>
>
>
>
>> But even if we assume a more open environment where the user agent can
>> send INVITEs directly to the conference bridge, all the conference bridge
>> needs is a signature or similar token that indicates the IdP's approval,
>> -not- any specific attribute.
>>
>
> Of course attributes are needed.
> How would otherwise the conference server know which type of conference to
> start (audio, video, etc)? what is the limitation on the number of
> participant? etc...
>
>
> This is exactly what my "deeper level of complexity" in a previous mail
> pulled apart. You need to differentiate a) what kind of conference the user
> wants from b) what kind of conference the IdP is willing to authorize.
> Your token is just an indication of what the IdP is willing to authorize,
> and if that is a superset of what the user wants, then the IdP will issue a
> token. If it is a subset, then it won't.
>
> So how does the conference server know which type of conference to start?
> Well, again, you've focused this discussion on the corner case of an ad hoc
> RFC4579 conference,
>

I disagree that this is a corner case; you could replace that conference
server with any other SIP service and the same mechanism would apply.

> in the ad hoc case the conference bridge has to infer that from the type
> of session that the user agent creates with the conference bridge with its
> initial INVITE.
>

Not sure why you are saying "the conference bridge has to *infer* that";
the information would be explicitly provided in the token.

> It's not really a very good assumption, though, which is why we quickly
> run into trouble when we start trying to understand this corner case.
> However, I think it would be safe to say that for this ad hoc case, if the
> IdP was willing to issue an authorization token, then it authorizes the
> media type(s) that the user specified in their INVITE -  and thus that
> attributes in the token to express what media types the IdP allowed would
> be at best redundant.
>
> But to be clear, a token that conveys what the IdP is willing to authorize
> does not serve the same purpose as a SIP means for a user agent to convey
> to a conference bridge what kind of conference it would like to have - nor
> as a means for a user agent to communicate to an IdP what kind of
> conference it intends to propose. Paul is mentioning mechanisms like caller
> prefs here because it would be new work, through some SIP mechanism along
> those lines, to convey that information with SIP.
>
> Outside of this corner case, though, the conference URI is acquired in an
> out-of-band fashion at the same time as conference policy is set - surely
> through HTTP, surely through a web interface, and that's where all the
> OAuth goodness can (and should) play into conference policy management.
> Trying to inflate this one ad hoc corner case into a murky argument that
> SIP needs OAuth is and has this whole time been a stretch. RFC4353 already
> says conference policy management is not a SIP function. I'm not
> particularly interested in working on overriding that, since it Is
> obviously solved by just using HTTP, without any new work on our part.
>
>
>> The semantics of the INVITE method are "hey, remote resource, I'd like to
>> set up a session with you involving the following media types." The
>> question of whether or not you accept INVITEs, which is to my mind the SIP
>> authorization problem,
>>
>
> This is the main difference between how you and I see this.
> I think that the authorization problem is much bigger than just
> authorizing a specific SIP method. The authorization should be dealing with *access
> to services* provided by SIP servers regardless of the SIP method being
> used.
>
>
> Our real disconnect I think is the degree to which you think SIP offers
> "services" or that application control is inside the scope of SIP. It's not.
>

Here are few RFCs that do just that; define services and control them:
https://tools.ietf.org/html/rfc5359
https://tools.ietf.org/html/rfc3087
https://datatracker.ietf.org/doc/rfc7463/

> SIP is a protocol that allows Internet endpoints to discover one another
> and to agree on the character of a session they'd like to share, according
> to RFC3261. If I may quote from Section 2  of that document "SIP does not
> offer conference control services" and indeed "SIP does not provide
> services."
>

Here is the full quote:

  "SIP does not provide services.  Rather, *SIP provides primitives that*
*   can be used to implement different services*.  For example, *SIP can*
*   locate a user and deliver an opaque object to his current location*.
   If this primitive is used to deliver a session description written in
   SDP, for instance, the endpoints can agree on the parameters of a
   session.  *If the same primitive is used to deliver a photo of the*
*   caller as well as the session description, a "caller ID" service can*
*   be easily implemented*.  As this example shows, *a single primitive is*
*   typically used to provide several different services*."

This means that SIP is not limited to negotiating session characteristics;
it is much more than that and could be used to provide services.

The last sentence in the above quote is really important. An INVITE could
be used to start a conference, access a voice mail, put a call on hold,
etc; these services require different authorizations.

Regards,
 Rifaat

> The only thing SIP has to do with conference services is that "SIP can be
> used to initiate a session that uses some other conference control
> protocol", look ahead to BFCP, and of course that SIP user agents can
> initiate sessions with conference bridges.
>
> Much the same way that HTTP authorizes *access to resources*, regardless
> of the HTTP method being used. You do not need a specific token for HTTP
> GET vs HTTP POST, because the method does not matter; what matters is the
> resource that the method is trying to access.
>
>
> Accessing and changing resources on the Internet is in the scope of HTTP,
> which is why HTTP should be used for the purposes you have in mind here.
> Yes, in addition to initiating sessions, SIP has a number of methods that
> let it convey data, such as INFO, MESSAGE, NOTIFY and so on, and in some
> use cases, they can similarly provide access to resources. Maybe there's a
> SIP authorization problem for those methods that we could find. But for the
> most part, the SIP authorization problem should be aligned with the purpose
> of SIP - it should be about deciding whether or not to accept session
> initiation attempts. That's a problem I'd be willing to work on.
>
> Jon Peterson
> Neustar, Inc.
>
>
> Regards,
>  Rifaat
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 7 Jul 2016 01:10:35 +0000

So how does the conference server know which type of conference to start? Well, again, you've focused this discussion on the corner case of an ad hoc RFC4579 conference,

I disagree that this is a corner case; you could replace that conference server with any other SIP service and the same mechanism would apply.

We've probably delved excessively into this one use case - it perhaps would have been more helpful to see examples of the attributes you propose for others services.

It is a "corner case" in so far as most of RFC4579 focuses on the "sunny day" case where there is a pre-existing conference URI (probably gotten via means like an "IVR, web page") that you just dial into or add people to. Only Section 5.4 deals with this "ad hoc" case. And of course RFC4579 is just one way of managing conferences in a landscape full of methods that use protocols other than SIP, albeit SIP will be used to actually initiate sessions to the conference.

in the ad hoc case the conference bridge has to infer that from the type of session that the user agent creates with the conference bridge with its initial INVITE.

Not sure why you are saying "the conference bridge has to infer that"; the information would be explicitly provided in the token.

The main point of my last message was to try to tease apart a) what kind of conference the user wants from b) what kind of conference the IdP is willing to authorize.  The fact that you're still just conflating them here suggests we're making little progress in even communicating, let along persuading each other.

Upleveling, if you think a token, rather than the SDP in the SIP INVITE, tells the conference bridge what kind of media the user agent is proposing for its session, then the scope of the problem you're considering is even more unwieldy than I thought. The potential difference between a) the media types the user (as a matter of personal conference policy) would allow any participants to use in the conference vs. c) which media the user is proposing in the SDP of the INVITE for its own connection to the conference bridge, is the further wrinkle I was attempting to untangle in the line you quote above - many elements need to be teased apart to understand the ad hoc case.

Our real disconnect I think is the degree to which you think SIP offers "services" or that application control is inside the scope of SIP. It's not.

These are pretty much landline replacement "services" for CLASS features and similar functions, so I'll talk more about them in a minute. But I'd be real interested to hear what kinds of OAuth-style attributes need to be carried in tokens in order to authorize those sorts of functions, and how the post-1970s PSTN managed to live without them for decades.

SIP is a protocol that allows Internet endpoints to discover one another and to agree on the character of a session they'd like to share, according to RFC3261. If I may quote from Section 2  of that document "SIP does not offer conference control services" and indeed "SIP does not provide services."

Here is the full quote:

  "SIP does not provide services.  Rather, SIP provides primitives that
   can be used to implement different services.  For example, SIP can
   locate a user and deliver an opaque object to his current location.
   If this primitive is used to deliver a session description written in
   SDP, for instance, the endpoints can agree on the parameters of a
   session.  If the same primitive is used to deliver a photo of the
   caller as well as the session description, a "caller ID" service can
   be easily implemented.  As this example shows, a single primitive is
   typically used to provide several different services."

This means that SIP is not limited to negotiating session characteristics; it is much more than that and could be used to provide services.

You passed over my RFC3261 quote that "SIP does not offer conference control services" in silence while bolding lots of other 14 point text there.

To talk about the paragraph you quote we need to open the more philosophical question of "what do we consider a service?" Clearly, if caller-ID is a service, or call waiting, or similar CLASS features, then in that sense of course SIP provides "services" via its primitives, and I've worked on defining a few myself. But CLASS features as "services" are not of remotely the same category as OAuth third-party services that consume tokens from IDPs - you don't need any sort of third-party authorization attribute or token in an INVITE to put someone on hold to take another call, say, or to send an image between endpoints. Back in the days of IN, these kinds of features had to be performed by "the network," and it was kind of a big deal that instead in SIP you just implemented them in primitives under the control of user agents, hence this text. But I think you are more concerned with controlling third party applications than with features like call waiting, and conflating those two categories under the umbrella of "services" to make it sound like SIP encompasses and legitimizes what you want to do is not going to persuade me, in any event.

SIP does provide the primitives necessary to implement CLASS features, and a number of RFCs today describe how to implement those features with SIP primitives. And when you initiate a session with a voicemail bridge, say, we could authorize your access to voicemail boxes in a number of different ways. But if you wanted to implement a trait-based authorization system for authorizing access to voicemails held on a third-party server, realistically, would (or should) you do it with SIP? Because there are a lot of HTTP and IMAP based visual voicemail services out there that support advanced features like speech-to-text transcription and so on where OAuth-like primitives make a lot of sense. Just because you can call a voicemail service with a SIP INVITE, that doesn't means that a SIP INVITE is the right place to stage an OAuth "service" like that, nor its security. I feel exactly the same way about conference policy.

The last sentence in the above quote is really important. An INVITE could be used to start a conference, access a voice mail, put a call on hold, etc; these services require different authorizations.

An INVITE can be used to initiate a session with a conference bridge, because semantics of an INVITE are "hey, I would like to initiate a session with you with the following media parameters." Setting conference policy requires a different semantics than that, and as I've repeatedly said in this thread (and as far as I can tell, you have not contradicted), the relevant RFCs recommend that you don't set conference policy with SIP. I'm really don't understand why that does not deter you.

I think at this point, if you want to propose your way of setting conference policy with SIP as a problem space, feel free - I don't happen to think there's much of a gap there, given the existence of means other than RFC4579 ad hoc INVITEs to set up conferences when you have more complicated security needs than an ad hoc conference ordinarily would. If the group agrees that there is 1) a need to convey conference policy in SIP, and 2) a need for attribute-based authorization tokens issued by IdPs to support that conference policy, that could be scoped as its own problem space and put forward for dispatch. But I don't think this is a general authorization problem for SIP.

Jon Peterson
Neustar, Inc.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 8 Jul 2016 12:29:40 -0400

On Wed, Jul 6, 2016 at 9:10 PM, Peterson, Jon <[email-masked]>
wrote:

> We've probably delved excessively into this one use case - it perhaps
> would have been more helpful to see examples of the attributes you propose
> for others services.
>

Sure. I could do that.

>
> It is a "corner case" in so far as most of RFC4579 focuses on the "sunny
> day" case where there is a pre-existing conference URI (probably gotten via
> means like an "IVR, web page") that you just dial into or add people to.
> Only Section 5.4 deals with this "ad hoc" case. And of course RFC4579 is
> just one way of managing conferences in a landscape full of methods that
> use protocols other than SIP, albeit SIP will be used to actually initiate
> sessions to the conference.
>
> As I mentioned multiple times already, my intention is *not* to
specifically discuss the conference use case, but discuss the idea of
delegating AuthNZ to a separate party other than the server providing the
service.

> The main point of my last message was to try to tease apart a) what kind
> of conference the user wants from b) what kind of conference the IdP is
> willing to authorize.  The fact that you're still just conflating them here
> suggests we're making little progress in even communicating, let along
> persuading each other.
>
> Upleveling, if you think a token, rather than the SDP in the SIP INVITE,
> tells the conference bridge what kind of media the user agent is proposing
> for its session,
>

No, that is *not* what I am suggesting at all.

> then the scope of the problem you're considering is even more unwieldy
> than I thought. The potential difference between a) the media types the
> user (as a matter of personal conference policy) would allow any
> participants to use in the conference vs. c) which media the user is
> proposing in the SDP of the INVITE for its own connection to the conference
> bridge, is the further wrinkle I was attempting to untangle in the line you
> quote above - many elements need to be teased apart to understand the ad
> hoc case.
>
>
> These are pretty much landline replacement "services" for CLASS features
> and similar functions,
>

I have no idea what you mean by "CLASS feature"; can you please elaborate?

> so I'll talk more about them in a minute. But I'd be real interested to
> hear what kinds of OAuth-style attributes need to be carried in tokens in
> order to authorize those sorts of functions, and how the post-1970s PSTN
> managed to live without them for decades.
>
>
>   "SIP does not provide services.  Rather, * SIP provides primitives that*
> You passed over my RFC3261 quote that "SIP does not offer conference
> control services" in silence while
>

 As I mentioned above, my goal is not to specifically discuss conference
control services.

> bolding lots of other 14 point text there.
>

Sorry about that. I use Gmail which does not provide much control over the
size of the font, I selected the one above Normal, which happened to be
Large 😀.

> To talk about the paragraph you quote we need to open the more
> philosophical question of "what do we consider a service?" Clearly, if
> caller-ID is a service, or call waiting, or similar CLASS features, then in
> that sense of course SIP provides "services" via its primitives, and I've
> worked on defining a few myself. But CLASS features as "services" are not
> of remotely the same category as OAuth third-party services that consume
> tokens from IDPs - you don't need any sort of third-party authorization
> attribute or token in an INVITE to put someone on hold to take another
> call, say, or to send an image between endpoints.
>

While I agree that some of these are basic features that would probably be
provided by default, I do not think that our goal here is to tell the
service provided what and what not to authorize.
The goal should be to define a *framework *that would allow them to choose
what they want to authorize.

> Back in the days of IN, these kinds of features had to be performed by
> "the network," and it was kind of a big deal that instead in SIP you just
> implemented them in primitives under the control of user agents, hence this
> text. But I think you are more concerned with controlling third party
> applications than with features like call waiting, and conflating those two
> categories under the umbrella of "services" to make it sound like SIP
> encompasses and legitimizes what you want to do is not going to persuade
> me, in any event.
>

Let me make sure I understand what you are saying here,
Are you saying that just because the SIP application is provided by a third
party server you would not consider that to be a SIP service?

>
> SIP does provide the primitives necessary to implement CLASS features, and
> a number of RFCs today describe how to implement those features with SIP
> primitives. And when you initiate a session with a voicemail bridge, say,
> we could authorize your access to voicemail boxes in a number of different
> ways. But if you wanted to implement a trait-based authorization system for
> authorizing access to voicemails held on a third-party server,
> realistically, would (or should) you do it with SIP?
>

Why not?
There are existing SIP application servers that do that already.

> Because there are a lot of HTTP and IMAP based visual voicemail services
> out there that support advanced features like speech-to-text transcription
> and so on where OAuth-like primitives make a lot of sense. Just because you
> can call a voicemail service with a SIP INVITE, that doesn't means that a
> SIP INVITE is the right place to stage an OAuth "service" like that, nor
> its security. I feel exactly the same way about conference policy.
>

We are obviously in disagreement here, but I am not sure I understand the "nor
its security" comment; can you elaborate?

> An INVITE can be used to initiate a session with a conference bridge,
> because semantics of an INVITE are "hey, I would like to initiate a session
> with you with the following media parameters." Setting conference policy
> requires a different semantics than that, and as I've repeatedly said in
> this thread (and as far as I can tell, you have not contradicted), the
> relevant RFCs recommend that you don't set conference policy with SIP. I'm
> really don't understand why that does not deter you.
>

> I think at this point, if you want to propose your way of setting
> conference policy with SIP as a problem space, feel free - I don't happen
> to think there's much of a gap there, given the existence of means other
> than RFC4579 ad hoc INVITEs to set up conferences when you have more
> complicated security needs than an ad hoc conference ordinarily would. If
> the group agrees that there is 1) a need to convey conference policy in
> SIP, and 2) a need for attribute-based authorization tokens issued by IdPs
> to support that conference policy,
>

Again, I am *not* suggesting to use SIP to set the policy (1); SIP will
only be used to carry the authorization (2).

Regards,
 Rifaat

> that could be scoped as its own problem space and put forward for
> dispatch. But I don't think this is a general authorization problem for SIP.
>
> Jon Peterson
> Neustar, Inc.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 14 Jul 2016 21:35:17 +0000

I think at this point, if you want to propose your way of setting conference policy with SIP as a problem space, feel free - I don't happen to think there's much of a gap there, given the existence of means other than RFC4579 ad hoc INVITEs to set up conferences when you have more complicated security needs than an ad hoc conference ordinarily would. If the group agrees that there is 1) a need to convey conference policy in SIP, and 2) a need for attribute-based authorization tokens issued by IdPs to support that conference policy,

Again, I am not suggesting to use SIP to set the policy (1); SIP will only be used to carry the authorization (2).

At its core, this is our disagreement in a nutshell. If SIP is not the protocol that is setting the conference policy, then it makes no sense to me that SIP should convey the authorization for conference policy. Setting conference policy is a task that is much more aligned with the semantics and features available in HTTP, and that's why HTTP is what the conferencing framework recommends for this. Surely the protocol that needs to carry the authorization for the conference policy is the protocol that carries the conference policy. Conveniently, HTTP already supports OAuth.

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat