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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 9 Jun 2016 13:59:15 -0400

Hi Jon,

Sorry for the delayed reply.

Let's take the video conference example, and discuss the possible ways for the
conference server to provide service.

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

Possible solutions:

1. Conference Server acts as an AuthN and AuthZ server. Requests to
the server must provide an identity and credentials, and services will
be provided based on locally stored information associated with
the identity provided in the request.

2. Conference Server acts as an AuthZ server, but delegates the AuthN
part. Requests to the server must provide an identity token, and services
will be provided based on locally stored information associated with
the identity provided in the token.

3. Conference Server delegates both AuthN and AuthZ parts. Requests to
the server must provide an access token, which might or might not
include information about the user requesting the service, and services
will be provided based on information provided in the access token or as
a result of an introspection step using the access token.

Now, let's look at the 3rd option a bit more, and assume that the
server provides the following types of conference services:
1. audio conference
2. audio/video conference
3. web conference

or some combination of the above.

Let's also assume that the server allows control over the number
of participants allowed in each one of these conference types or
combinations.

Here is one way that I envisioned we could use to address this use case:

When an enterprise user in the 1st trust domain wants to register with
the SIP Proxy, it will have to authenticate to the IdP and as a result
either the UA or the Proxy (depends on the UA's capabilities) will be
provided with an AuthN and AuthZ tokens. This process could involve an
interim step to allow only the proxy to get access to the tokens, or the
tokens could be sent to the UA which will then use them to communicate with
the proxy.

The AuthN token is the identity of the user, and the AuthZ token has
all the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the
UA will send an INVITE to the Proxy, and will include the AuthZ token if it
is in possession of the tokens; otherwise, the proxy will add the
appropriate token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to
multiple services; to avoid sending that AuthZ token to all servers
providing services granted to the user, the proxy could obtain a different
token with limited scope that is specific to the service being provided
(conference services in this case); there is a standard Token Exchange
mechanism for that.

The AuthZ token will include information about the type of service
allowed (audio, audio/video, etc), and the limit on the number of
participants. The AuthZ token might or might not have any information about
the user requesting the service, which depends on the level of privacy
needed.

When the conference server receives this token in the SIP INVITE, all
it has to do is validate that the token was signed by an IdP that it has
a trust relationship with, and provide the service requested by the
AuthZ token. The conference server does not need the AuthN token to be able
to provide a service.

Regards,
 Rifaat

On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <[email-masked]>
wrote:

>
> 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: "Peterson, Jon" <[email-masked]>
Date: Mon, 13 Jun 2016 19:36:08 +0000

Just to play back the general problem statement, I think we'd agree that of your three numbered possible solutions, #1 is more or less the assumed baseline SIP behavior - cases where, for example, the server would send a Digest challenge in the backwards direction to authenticate the user agent and then make any authorization decision based on its own ACLs or what have you. Your solutions #2 and #3 cover the two cases I think are interesting: SSO-like ones where relying parties trust an identity assertion provided by an IdP of some sort (#2) and cases where the identity information is not included at all (or is at least optional) and instead the relying party trusts traits or attributes or what have you provided by the IdP. I've argued that SIP has always been able to do #1, that we at least already have some ways to do #2, and that we've already done requirements for #3 (RFC4484) but to date have gone no farther, and that it would be new work if we were to specify protocol for #3.

So yes, the third option is where we need to focus. But the point of my last mail was to say that what we need to narrow our discussion down to what the attributes are that we imagine applications in these use cases will require to process SIP requests, primarily SIP INVITE requests. You say some high-level things below like that your third-option token "might grant the user access to multiple services" on the conference service which is your relying party. In terms of concrete authorization traits for this use case, towards the very end you suggest attributes of a conference like the number of participants or the media types permitted in the conference.

Radhika sent a helpful summary of conference control protocols to the list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which actually let you manage attributes of a conference like the number of participants and media types allowed. The interesting thing about protocols like CCMP is that they are not, you know, actually transported by SIP. CCMP is transported by HTTP. Why? Because the semantics of conference control doesn't actually map onto SIP INVITE transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OAuth if you like. You even will find some text about Role-Based Access Control in the XCON (RFC6503) security consideration. Although you can use SIP and SDP to set up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS between its own endpoints. It is unclear to me what carrying attribute information around in a SIP INVITE would accomplish with regards to authorizing CCMP or BFCP transactions.

So again, the point of my last mail was that the problem of authorizing SIP INVITEs is actually different from the problem of authorizing generic application transactions. SIP INVITEs still have more or less the semantics of a call setup message: they are requesting that a session be initiated. Conference control is not managed with SIP transactions, and the security of conference control protocols does not devolve to authorizing SIP transactions. I suspect we'll find that most of the other security attributes that "applications" need to do their jobs similarly don't map onto the semantics of a SIP INVITE - but, I'm still open to entertaining examples that might cast doubt on that suspicion.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 9, 2016 at 10:59 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3

Hi Jon,

Let's take the video conference example, and discuss the possible ways for the conference server to provide service.

Possible solutions:

1. Conference Server acts as an AuthN and AuthZ server. Requests to the server must provide an identity and credentials, and services will be provided based on locally stored information associated with the identity provided in the request.

2. Conference Server acts as an AuthZ server, but delegates the AuthN part. Requests to the server must provide an identity token, and services will be provided based on locally stored information associated with the identity provided in the token.

3. Conference Server delegates both AuthN and AuthZ parts. Requests to the server must provide an access token, which might or might not include information about the user requesting the service, and services will be provided based on information provided in the access token or as a result of an introspection step using the access token.

Now, let's look at the 3rd option a bit more, and assume that the server provides the following types of conference services:
1. audio conference
2. audio/video conference
3. web conference

Let's also assume that the server allows control over the number of participants allowed in each one of these conference types or combinations.

When an enterprise user in the 1st trust domain wants to register with the SIP Proxy, it will have to authenticate to the IdP and as a result either the UA or the Proxy (depends on the UA's capabilities) will be provided with an AuthN and AuthZ tokens. This process could involve an interim step to allow only the proxy to get access to the tokens, or the tokens could be sent to the UA which will then use them to communicate with the proxy.

The AuthN token is the identity of the user, and the AuthZ token has all the services granted to the user by the IdP/AuthZ Service.

When the enterprise user needs access to the conference service, the UA will send an INVITE to the Proxy, and will include the AuthZ token if it is in possession of the tokens; otherwise, the proxy will add the appropriate token to the outgoing INVITE sent to the conference server.

The scope of the AuthZ token might grant the user access to multiple services; to avoid sending that AuthZ token to all servers providing services granted to the user, the proxy could obtain a different token with limited scope that is specific to the service being provided (conference services in this case); there is a standard Token Exchange mechanism for that.

The AuthZ token will include information about the type of service allowed (audio, audio/video, etc), and the limit on the number of participants. The AuthZ token might or might not have any information about the user requesting the service, which depends on the level of privacy needed.

When the conference server receives this token in the SIP INVITE, all it has to do is validate that the token was signed by an IdP that it has a trust relationship with, and provide the service requested by the AuthZ token. The conference server does not need the AuthN token to be able to provide a service.

Regards,
 Rifaat

On Wed, May 25, 2016 at 3:06 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

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: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 14 Jun 2016 09:33:19 -0400

On Mon, Jun 13, 2016 at 3:36 PM, Peterson, Jon <[email-masked]>
wrote:

>
> Just to play back the general problem statement, I think we'd agree that
> of your three numbered possible solutions, #1 is more or less the assumed
> baseline SIP behavior - cases where, for example, the server would send a
> Digest challenge in the backwards direction to authenticate the user agent
> and then make any authorization decision based on its own ACLs or what have
> you. Your solutions #2 and #3 cover the two cases I think are interesting:
> SSO-like ones where relying parties trust an identity assertion provided by
> an IdP of some sort (#2) and cases where the identity information is not
> included at all (or is at least optional) and instead the relying party
> trusts traits or attributes or what have you provided by the IdP. I've
> argued that SIP has always been able to do #1, that we at least already
> have some ways to do #2, and that we've already done requirements for #3
> (RFC4484) but to date have gone no farther, and that it would be new work
> if we were to specify protocol for #3.
>
> So yes, the third option is where we need to focus. But the point of my
> last mail was to say that what we need to narrow our discussion down to
> what the attributes are that we imagine applications in these use cases
> will require to process SIP requests, primarily SIP INVITE requests. You
> say some high-level things below like that your third-option token "might
> grant the user access to multiple services" on the conference service which
> is your relying party. In terms of concrete authorization traits for this
> use case, towards the very end you suggest attributes of a conference like
> the number of participants or the media types permitted in the conference.
>
> Radhika sent a helpful summary of conference control protocols to the list
> which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which
> actually let you manage attributes of a conference like the number of
> participants and media types allowed.
>

This conference use case was an example for a SIP-based conference server
(RFC4579), just to describe the idea around the delegation of AuthNZ.

If the server is a CCMP-based conference, then you would obviously use that
to control and manage the conference server.

> The interesting thing about protocols like CCMP is that they are not, you
> know, actually transported by SIP. CCMP is transported by HTTP. Why?
> Because the semantics of conference control doesn't actually map onto SIP
> INVITE transactions very well. They map quite aptly to HTTP, and in the
> HTTP context, you can certainly use OAuth if you like.
>

Help me understand this part.

Why can an HTTP request transport a token to a resource server to be able
to access a specific resource, while SIP request cannot transport a similar
token to a SIP server to access a service?

> You even will find some text about Role-Based Access Control in the XCON
> (RFC6503) security consideration. Although you can use SIP and SDP to set
> up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS
> between its own endpoints. It is unclear to me what carrying attribute
> information around in a SIP INVITE would accomplish with regards to
> authorizing CCMP or BFCP transactions.
>

SIP INVITE will carry attributes to authorize that specific SIP request;
there is nothing in proposal #3 that suggest that SIP will carry
authorization for CCMP or any other protocol.

>
> So again, the point of my last mail was that the problem of authorizing
> SIP INVITEs is actually different from the problem of authorizing generic
> application transactions. SIP INVITEs still have more or less the semantics
> of a call setup message: they are requesting that a session be initiated.
> Conference control is not managed with SIP transactions, and the security
> of conference control protocols does not devolve to authorizing SIP
> transactions.
>

Well, RFC4579 defines a SIP Conference Control mechanism that allows you to
initiate and control a conference server using only SIP requests; so I am
not sure I understand this statement, unless we have different definitions
for the term “conference control”.

In any case, my point was not to discuss conference servers specifically,
but to discuss the general idea of delegating both AuthN and AuthZ in a SIP
network.

Regards,

 Rifaat

> I suspect we'll find that most of the other security attributes that
> "applications" need to do their jobs similarly don't map onto the semantics
> of a SIP INVITE - but, I'm still open to entertaining examples that might
> cast doubt on that suspicion.
>
> Jon Peterson
> Neustar, Inc.
>
> From: Rifaat Shekh-Yusef <[email-masked]>
> To: Jon Peterson <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, "[email-masked]"
> <[email-masked]>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 14 Jun 2016 16:52:46 +0000

Radhika sent a helpful summary of conference control protocols to the list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which actually let you manage attributes of a conference like the number of participants and media types allowed.

This conference use case was an example for a SIP-based conference server (RFC4579), just to describe the idea around the delegation of AuthNZ.
If the server is a CCMP-based conference, then you would obviously use that to control and manage the conference server.

While RFC4579 (an implementation of the RFC4353 framework) provides means to do conference control from within SIP, the kinds of control primitives it specifies are totally decoupled from the sorts of policies that the attributes you proposed would constrain. Those policies fall under what RFC4353 calls "conference policy." Neither RFC4579 nor its requirements (RFC4245) really say anything about how conference policy is set or distributed.

Authorizing SIP requests is misaligned with setting conference policy, especially in consideration of the sorts of attributes you seem to have in mind - even when we're considering controlling conferences compliant with the RFC4353 framework.

That's because the conference in RFC4579 isn't "created" when a user agent sends an INVITE request to the conference bridge - it is created when the conference URI is created, which is necessarily beforehand. Conferences in the RF4353 framework are associated with conference policies,

The example of CCMP shows that you can do conference control with OAuth over in the HTTP realm without needing to add anything whatsoever to SIP.

The interesting thing about protocols like CCMP is that they are not, you know, actually transported by SIP. CCMP is transported by HTTP. Why? Because the semantics of conference control doesn't actually map onto SIP INVITE transactions very well. They map quite aptly to HTTP, and in the HTTP context, you can certainly use OAuth if you like.

Help me understand this part.
Why can an HTTP request transport a token to a resource server to be able to access a specific resource, while SIP request cannot transport a similar token to a SIP server to access a service?

Of course both SIP and HTTP can carry arbitrary chunks of data, including any sort of token we can imagine. My point is that the semantics of an INVITE are really different from the semantics of a POST - and that is why, ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.  INVITEs are sent by a user agent when it is trying to set up a media session between itself and some remote resource on the Internet. While RFC4579 has a way to set up a conference as a side effect of sending an INVITE to connect to the conference, must of the subsequent control work happens totally outside the context of that dialog, and the authorization of those operations is completely disconnected from the authorization of the conference-opening INVITE.

And of course, SIP can support faux-HTTP semantics with mechanisms like PUBLISH and NOTIFY. But I think the interesting question about standardizing an approach to authorization of SIP requests is about INVITE.

You even will find some text about Role-Based Access Control in the XCON (RFC6503) security consideration. Although you can use SIP and SDP to set up a BFCP connection (RFC4583), the security of BFCP relies on mutual TLS between its own endpoints. It is unclear to me what carrying attribute information around in a SIP INVITE would accomplish with regards to authorizing CCMP or BFCP transactions.

SIP INVITE will carry attributes to authorize that specific SIP request; there is nothing in proposal #3 that suggest that SIP will carry authorization for CCMP or any other protocol.

That is where I think you and I have a disconnect. The SIP INVITE in the conference control (RFC4579) case would not carry attributes like the ones you've identified in order to authorize that specific SIP request. The attributes that you identified, the media types the conference allows and the number of participants permitted simultaneously in a conference, have nothing to do with the SIP INVITE that opens the conference bridge. Those attributes apply to authorization decisions regarding later participants that will be added to the conference.

We can imagine that the

So again, the point of my last mail was that the problem of authorizing SIP INVITEs is actually different from the problem of authorizing generic application transactions. SIP INVITEs still have more or less the semantics of a call setup message: they are requesting that a session be initiated. Conference control is not managed with SIP transactions, and the security of conference control protocols does not devolve to authorizing SIP transactions.

Well, RFC4579 defines a SIP Conference Control mechanism that allows you to initiate and control a conference server using only SIP requests; so I am not sure I understand this statement, unless we have different definitions for the term “conference control”.

In any case, my point was not to discuss conference servers specifically, but to discuss the general idea of delegating both AuthN and AuthZ in a SIP network.

If you could furnish an example of attributes that would be carried in a SIP iNVITE that are actually salient to the authorization of that particular SIP request, we'd be getting a lot closer to common ground.

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

I suspect we'll find that most of the other security attributes that "applications" need to do their jobs similarly don't map onto the semantics of a SIP INVITE - but, I'm still open to entertaining examples that might cast doubt on that suspicion.

Jon Peterson
Neustar, Inc.

Hi Jon,

Possible solutions:

Regards,
 Rifaat

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 14 Jun 2016 16:56:59 +0000

Um, sorry, this mail got sent accidentally well before it was completed. Let me try to repair it and resend.

Jon Peterson
Neustar, Inc.

From: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 14, 2016 at 9:52 AM
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3

We can imagine that the

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

Jon Peterson
Neustar, Inc.

Hi Jon,

Possible solutions:

Regards,
 Rifaat

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 14 Jun 2016 17:27:30 +0000

This time my response should be more complete. Sorry about that!

While RFC4579 (an implementation of the RFC4353 framework) provides a means to do conference control from within SIP, the kinds of control primitives it specifies are totally decoupled from the sorts of policies that the attributes you proposed would constrain. Those policies fall under what RFC4353 calls "conference policy." Neither RFC4579 nor its requirements (RFC4245) really say anything about how conference policy is set or distributed. RFC4353 does, though, and what it says is (in 4.6) is "the conference policy can be manipulated using web applications or voice applications [i.e. IVRs - JFP]. It can also be manipulated with non-SIP-specific standard or proprietary protocols."

Authorizing SIP requests is misaligned with setting conference policy, especially in consideration of the sorts of attributes you seem to have in mind - even when we're considering controlling conferences compliant with the RFC4353 framework.  That's because the conference in RFC4579 isn't "created" when a user agent sends an INVITE request to the conference bridge - it is created when the conference URI is created, which is necessarily beforehand (or at best, ad hoc through the conference factory). Conference policy is set and disseminated in that context, not in the context of the SIP transaction that happens to open the bridge.

Moreover, my point was that the example of CCMP shows that you can do conference control with OAuth over in the HTTP realm without needing to add anything whatsoever to SIP.  If you need OAuth-style controls for conferencing, that would seem to be a quicker path to implementation.

Of course both SIP and HTTP can carry arbitrary chunks of data, including any sort of token we can imagine. My point is that the semantics of an INVITE are really different from the semantics of a POST - and that is why, ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.  INVITEs are sent by a user agent when it is trying to set up a media session between itself and some remote resource on the Internet. While RFC4579 has a way to open a conference as a side effect of sending an INVITE to connect to the conference, the policies associated with the sorts of attributes you specified are set totally outside the context of that dialog, and the execution of those policies is completely disconnected from the authorization of the conference-opening INVITE. More on this below.

 I think the interesting question about standardizing an approach to authorization of SIP requests is about INVITE. Of course, SIP supports faux-HTTP semantics with mechanisms like PUBLISH and NOTIFY, and we could talk about authorizing a number of other non-dialog-forming methods as well, but if we're going to kick off an effort to specify authorization policy for SIP, the primary thing we need to worry about is INVITE.

That is where I think you and I have a disconnect. The SIP INVITE in the conference control (RFC4579) case would not carry attributes like the ones you've identified in order to authorize that specific SIP request. The attributes that you identified - the media types the conference allows and the number of participants permitted simultaneously in a conference - have nothing to do with the SIP INVITE that opens the conference bridge. Instead, they are components of conference policy. Those policies apply to authorization decisions regarding later participants that will be added to the conference, and thus to the authorization of later SIP transactions and dialogs, such as when a new participant sends an INVITE to the conference bridge after having been sent a REFER by the conference controller, say, and the focus decides to reject that INVITE because the maximum number of participants has been exceeded.

We can imagine a way to publish such a conference policy to the conference bridge with SIP, of course, but the question is, in what sense are those policies actually aligned with the question of whether or not we should authorize the SIP request that carries them? If they are not, then we aren't really talking about authorizing SIP requests, we're talking uploading long-term application policies over SIP with faux-HTTP semantics, which is pretty far from where we started and where I think we need to go.

Yeah, I was using the term loosely - once we bring RFC4579 into the mix, we need to distinguish "conference control" from "conference policy," and then say that RFC4579 and the entire RFC4353 framework is about control, not about managing conference policy over SIP. The two attributes you propose belong to that conference policy realm rather than conference control, strictly speaking.
In any case, my point was not to discuss conference servers specifically, but to discuss the general idea of delegating both AuthN and AuthZ in a SIP network.

In that case, if you could furnish a use case with attributes that would be carried in a SIP iNVITE that are actually salient to the authorization of that particular SIP request, we'd be getting a lot closer to common ground.

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

Jon Peterson
Neustar, Inc.

Hi Jon,

Possible solutions:

Regards,
 Rifaat

Jon Peterson
Neustar, Inc.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2016 17:42:03 +0000

Hi,

.

> Of course both SIP and HTTP can carry arbitrary chunks of data, including any sort of token we can imagine. My point is that the semantics of an INVITE are really different from the semantics of a POST - > and that is why, ultimately, protocols like CCMP don't use SIP as a transport but instead use HTTP.  INVITEs are sent by a user agent when it is trying to set up a media session between itself and some 
> remote resource on the Internet. While RFC4579 has a way to set up a conference as a side effect of sending an INVITE to connect to the conference, must of the subsequent control work happens 
> totally outside the context of that dialog, and the authorization of those operations is completely disconnected from the authorization of the conference-opening INVITE.
>

Just to point out that in the IMS use-case the token needs to be carried in the REGISTER request, and it has nothing to do with a conference server.

Regards,

Christer

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 14 Jun 2016 18:10:35 +0000

But to the point - in that (very very different) use case, the REGISTER
request is accepted or rejected based on the contents of the token it
carries, right?

Jon Peterson
Neustar, Inc.

On 6/14/16, 10:42 AM, "Christer Holmberg" <[email-masked]>
wrote:

>Hi,
>
>.
>
>>> Why can an HTTP request transport a token to a resource server to be
>>>able to access a specific resource, while SIP request cannot transport
>>>a similar token to a SIP server to access a service?
>>
>> Of course both SIP and HTTP can carry arbitrary chunks of data,
>>including any sort of token we can imagine. My point is that the
>>semantics of an INVITE are really different from the semantics of a POST
>>- > and that is why, ultimately, protocols like CCMP don't use SIP as a
>>transport but instead use HTTP.  INVITEs are sent by a user agent when
>>it is trying to set up a media session between itself and some
>> remote resource on the Internet. While RFC4579 has a way to set up a
>>conference as a side effect of sending an INVITE to connect to the
>>conference, must of the subsequent control work happens
>> totally outside the context of that dialog, and the authorization of
>>those operations is completely disconnected from the authorization of
>>the conference-opening INVITE.
>>
>> And of course, SIP can support faux-HTTP semantics with mechanisms like
>>PUBLISH and NOTIFY. But I think the interesting question about
>>standardizing an approach to authorization of SIP requests is
>> about INVITE.
>
>Just to point out that in the IMS use-case the token needs to be carried
>in the REGISTER request, and it has nothing to do with a conference
>server.
>
>Regards,
>
>Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2016 18:31:01 +0000

Hi,

>But to the point - in that (very very different) use case, the REGISTER request is accepted or rejected >based on the contents of the token it carries, right?

Yes.

Regards,

Christer

On 6/14/16, 10:42 AM, "Christer Holmberg" <[email-masked]>
wrote:

>>>able to access a specific resource, while SIP request cannot 
>>>transport a similar token to a SIP server to access a service?
>>
>>- > and that is why, ultimately, protocols like CCMP don't use SIP as 
>>a transport but instead use HTTP.  INVITEs are sent by a user agent 
>>when it is trying to set up a media session between itself and some  
>>conference, must of the subsequent control work happens  totally 
>>outside the context of that dialog, and the authorization of those 
>>operations is completely disconnected from the authorization of the 
>>conference-opening INVITE.
>>
>> And of course, SIP can support faux-HTTP semantics with mechanisms 
>>like PUBLISH and NOTIFY. But I think the interesting question about 
>>standardizing an approach to authorization of SIP requests is  about 
>>INVITE.
>
>Just to point out that in the IMS use-case the token needs to be 
>carried in the REGISTER request, and it has nothing to do with a 
>conference server.
>
>Regards,
>
>Christer
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 15 Jun 2016 10:51:34 -0400

On Tue, Jun 14, 2016 at 1:27 PM, Peterson, Jon <[email-masked]>
wrote:

>> Radhika sent a helpful summary of conference control protocols to the
>> list which surveyed mechanisms like CCMP, BFCP, and MRB, protocols which
> If the server is a CCMP-based conference, then you would obviously use
> that to control and manage the conference server.
>
>
> While RFC4579 (an implementation of the RFC4353 framework) provides a
> means to do conference control from within SIP, the kinds of control
> primitives it specifies are totally decoupled from the sorts of policies
> that the attributes you proposed would constrain. Those policies fall under
> what RFC4353 calls "conference policy."
>

I agree. This is an important distinction and clarification.

> Neither RFC4579 nor its requirements (RFC4245) really say anything about
> how conference policy is set or distributed. RFC4353 does, though, and what
> it says is (in 4.6) is "the conference policy can be manipulated using web
> applications or voice applications [i.e. IVRs - JFP]. It can also be
> manipulated with non-SIP-specific standard or proprietary protocols."
>
>
Proposal #3 delegates this function from the conference server to the
authorization server. The conference server becomes a consumer and enforcer
of a policy.

> Authorizing SIP requests is misaligned with setting conference policy,
> especially in consideration of the sorts of attributes you seem to have in
> mind - even when we're considering controlling conferences compliant with
> the RFC4353 framework.  That's because the conference in RFC4579 isn't
> "created" when a user agent sends an INVITE request to the conference
> bridge - it is created when the conference URI is created, which is
> necessarily beforehand (or at best, ad hoc through the conference factory).
> Conference policy is set and disseminated in that context, not in the
> context of the SIP transaction that happens to open the bridge.
>

In the diagram I provided, I did not separate the Conference Factory from
the Focus, maybe I should have.
The INVITE with the token will be sent to the factory, which will create
the focus and set the proper limitation on the focus based on the
authorization provided in the token.
How is this misaligned with settings a conference policy?

>
> Moreover, my point was that the example of CCMP shows that you can do
> conference control with OAuth over in the HTTP realm without needing to add
> anything whatsoever to SIP.  If you need OAuth-style controls for
> conferencing, that would seem to be a quicker path to implementation.
>

If your conference server supports CCMP, then yes, that would be the right
answer. What if your server does not support CCMP?
But, again, the conference use case is an example only to drive the point,
not to discuss the best way to implement conference server.

> Of course both SIP and HTTP can carry arbitrary chunks of data, including
> any sort of token we can imagine. My point is that the semantics of an
> INVITE are really different from the semantics of a POST - and that is why,
> ultimately, protocols like CCMP don't use SIP as a transport but instead
> use HTTP.  INVITEs are sent by a user agent when it is trying to set up a
> media session between itself and some remote resource on the Internet.
>

Not necessarily; an INVITE is used to create a conference focus, for
example.
And, as Christer mentioned, the use of token is not limited to INVITEs. It
will be used with a REGISTER request to allow a UA to register with the
registrar, and maybe other SIP methods.

> While RFC4579 has a way to open a conference as a side effect of sending
> an INVITE to connect to the conference, the policies associated with the
> sorts of attributes you specified are set totally outside the context of
> that dialog, and the execution of those policies is completely disconnected
> from the authorization of the conference-opening INVITE. More on this below.
>
>  I think the interesting question about standardizing an approach to
> authorization of SIP requests is about INVITE. Of course, SIP supports
> faux-HTTP semantics with mechanisms like PUBLISH and NOTIFY, and we could
> talk about authorizing a number of other non-dialog-forming methods as
> well, but if we're going to kick off an effort to specify authorization
> policy for SIP, the primary thing we need to worry about is INVITE.
>
>
> That is where I think you and I have a disconnect. The SIP INVITE in the
> conference control (RFC4579) case would not carry attributes like the ones
> you've identified in order to authorize that specific SIP request. The
> attributes that you identified - the media types the conference allows and
> the number of participants permitted simultaneously in a conference - have
> nothing to do with the SIP INVITE that opens the conference bridge.
>

Well, not exactly.
The first INVITE that is sent to the conference factory is exactly that.

> Instead, they are components of conference policy. Those policies apply to
> authorization decisions regarding later participants that will be added to
> the conference, and thus to the authorization of later SIP transactions and
> dialogs, such as when a new participant sends an INVITE to the conference
> bridge after having been sent a REFER by the conference controller, say,
> and the focus decides to reject that INVITE because the maximum number of
> participants has been exceeded.
>

Sure, the INVITE that is sent to the focus would fall under this
description. Why is that a bad thing?

> We can imagine a way to publish such a conference policy to the conference
> bridge with SIP, of course, but the question is, in what sense are those
> policies actually aligned with the question of whether or not we should
> authorize the SIP request that carries them? If they are not, then we
> aren't really talking about authorizing SIP requests, we're talking
> uploading long-term application policies over SIP with faux-HTTP semantics,
> which is pretty far from where we started and where I think we need to go.
>

There is no "uploading long-term application policies"; the long term
policies are set on the authorization server.
The INVITE will carry the authorization for a specific focus targeted by
the this request.

> Well, RFC4579 defines a SIP Conference Control mechanism that allows you
> to initiate and control a conference server using only SIP requests; so I
> am not sure I understand this statement, unless we have different
> definitions for the term “conference control”.
>
>
> Yeah, I was using the term loosely - once we bring RFC4579 into the mix,
> we need to distinguish "conference control" from "conference policy," and
> then say that RFC4579 and the entire RFC4353 framework is about control,
> not about managing conference policy over SIP. The two attributes you
> propose belong to that conference policy realm rather than conference
> control, strictly speaking.
>
> In that case, if you could furnish a use case with attributes that would
> be carried in a SIP iNVITE that are actually salient to the authorization
> of that particular SIP request, we'd be getting a lot closer to common
> ground.
>
>
An obvious example would be an INVITE with a token sent to a conference
factory to authorize the creation of a focus.

Regards,
 Rifaat

>> Let's take the video conference example, and discuss the possible ways
>> for the conference server to provide service.
>>
>>
>>> 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).
>>>
>>> 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.
>>>

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 15 Jun 2016 21:06:26 +0000

An obvious example would be an INVITE with a token sent to a conference factory to authorize the creation of a focus.

We're still talking past each other. My point above was that the two attributes you specified - constraints on conference size and media types - have nothing to do with the authorization of the INVITE carrying those attributes. Like, unless the conference size permitted is 0, then the INVITE that creates an ad hoc conference and connects you to its bridge is not going to be rejected by the focus on the basis of that conference size attribute. If the maximum conference size were 0, the AuthZ service just wouldn't attach a token to an INVITE as it would never be allowed to start a conference. Same goes for media types.

Instead, what your two attributes constrain is what happens after the conference is created: when ten users try to dial in to a conference with a permitted size of nine, say. That tenth INVITE would get rejected - not the conference-forming INVITE that you propose would carry the token. That's why what you're proposing is overloading the INVITE to tunnel conference policy constraints to the focus. I mean, maybe that's a problem space worth investigating, though I suspect there are good reasons why RFC4353 specified that conference policy is not manipulated with SIP - mostly because the semantics of manipulating conference policy probably don't map well onto dialog-forming SIP requests. But I think that conference policy provisioning problem space would be pretty far from where we started in this discussion.

Let me reiterate what I wrote in my previous mail, which I quote here at the top: "furnish a use case with attributes that would be carried in a SIP iNVITE that are actually salient to the authorization of that particular SIP request." Again: "that particular SIP request." Not later transactions in some broader context in which the original user agent probably isn't even an endpoint.

The Authorization header in SIP, for example, is actually used by the UAS to make a decision about whether or not to authorize the request in which the header appears.  The token that you propose a SIP INVITE would carry in this case is not used by the relying party to make a decision about whether or not that INVITE is authorized. That's why I believe this conference policy issue is a different problem space entirely from figuring out how to implement attribute-based authorization for SIP requests.

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 16 Jun 2016 09:19:16 -0400

The attributes I provided are examples of attributes that might be provided
in an access token; it was not meant to include all the attributes for this
use case, because my intention was not to focus on conference server, but
to discuss the idea in general.

The following could be used with the conference factory to request a
conference focus:
The INVITE sent to the conference factory could include a token that has a
*conference-type* attribute which could take one of the following
values: *audio,
video, webconference, audio-webconference, or video-webconference*.
The conference factory will then issue a *conference uri* for the requested
conference type, assuming the token is valid. If the *conference-type*
attribute is missing, then the request would be rejected.

Is that what you are looking for?

Regards,
 Rifaat

On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <[email-masked]>
wrote:

> We're still talking past each other. My point above was that the two
> attributes you specified - constraints on conference size and media types -
> have nothing to do with the authorization of the INVITE carrying those
> attributes. Like, unless the conference size permitted is 0, then the
> INVITE that creates an ad hoc conference and connects you to its bridge is
> not going to be rejected by the focus on the basis of that conference size
> attribute. If the maximum conference size were 0, the AuthZ service just
> wouldn't attach a token to an INVITE as it would never be allowed to start
> a conference. Same goes for media types.
>
> Instead, what your two attributes constrain is what happens after the
> conference is created: when ten users try to dial in to a conference with a
> permitted size of nine, say. That tenth INVITE would get rejected - not the
> conference-forming INVITE that you propose would carry the token. That's
> why what you're proposing is overloading the INVITE to tunnel conference
> policy constraints to the focus. I mean, maybe that's a problem space worth
> investigating, though I suspect there are good reasons why RFC4353
> specified that conference policy is not manipulated with SIP - mostly
> because the semantics of manipulating conference policy probably don't map
> well onto dialog-forming SIP requests. But I think that conference policy
> provisioning problem space would be pretty far from where we started in
> this discussion.
>
> Let me reiterate what I wrote in my previous mail, which I quote here at
> the top: "furnish a use case with attributes that would be carried in a SIP
> iNVITE that are actually salient to the authorization of that particular
> SIP request." Again: "that particular SIP request." Not later transactions
> in some broader context in which the original user agent probably isn't
> even an endpoint.
>
> The Authorization header in SIP, for example, is actually used by the UAS
> to make a decision about whether or not to authorize the request in which
> the header appears.  The token that you propose a SIP INVITE would carry in
> this case is not used by the relying party to make a decision about whether
> or not that INVITE is authorized. That's why I believe this conference
> policy issue is a different problem space entirely from figuring out how to
> implement attribute-based authorization for SIP requests.
>
> Jon Peterson
> Neustar, Inc.
>
>
> Regards,
>  Rifaat
>
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 21 Jun 2016 23:46:10 +0000

It's not really what I'm looking for, no, and after mulling this over a bit, I fear going farther along this path would only drill down into levels of complexity that will likely make this harder to understand rather than easier.

I do acknowledge that you describe the INVITE as being rejected if it doesn't contain a token - but that's not the same thing as saying the INVITE will be rejected because the relying party makes an authorization decision based on the attributes in the token. It's more like an INVITE being rejected because a user agent can't supply an Authorization header. I will reiterate that I don't think the kinds of attributes you are proposing should be in the scope of an effort that will try to address a framework for authorizing SIP requests. I don't think the values of the attributes (as opposed to the mere presence of some attributes) have anything to do with authorizing the SIP request that you propose would carry the attributes.

With regards to this whole conferencing example, it does seem a bit contrived to me, like you're sketching a SIP-based way of setting conference policy on the fly that happens to require the kind of attributes you want, and then saying that demonstrates the need for the attributes. The fact that all of the ways to do conference policy we can point to in fact do it via the web makes it hard for me to understand why we should create a SIP-based way of doing this. To me, it looks like you're opening a problem space that has much more to do with reshaping the way that SIP does conferences (and again, as Radhika's mail pointing out, there's been a lot of thinking about this since the days of RFC4579) than it does with defining a framework for authorizing SIP requests.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 16, 2016 at 6:19 AM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP AuthNZ Problem Statement - v3

The attributes I provided are examples of attributes that might be provided in an access token; it was not meant to include all the attributes for this use case, because my intention was not to focus on conference server, but to discuss the idea in general.

The following could be used with the conference factory to request a conference focus:
The INVITE sent to the conference factory could include a token that has a conference-type attribute which could take one of the following values: audio, video, webconference, audio-webconference, or video-webconference.
The conference factory will then issue a conference uri for the requested conference type, assuming the token is valid. If the conference-type attribute is missing, then the request would be rejected.

Regards,
 Rifaat

On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 Jun 2016 19:50:13 -0400

Furthermore, reading all of this, I cannot understand why Authorization
token cannot be a part of SIP URL, either as user part or URL parameter.
This does not need to be anything more then service specific URL and does
not require a new SIP header or authentication mechanism.

_____________
Roman Shpount

On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon <[email-masked]>
wrote:

>
> It's not really what I'm looking for, no, and after mulling this over a
> bit, I fear going farther along this path would only drill down into levels
> of complexity that will likely make this harder to understand rather than
> easier.
>
> I do acknowledge that you describe the INVITE as being rejected if it
> doesn't contain a token - but that's not the same thing as saying the
> INVITE will be rejected because the relying party makes an authorization
> decision based on the attributes in the token. It's more like an INVITE
> being rejected because a user agent can't supply an Authorization header. I
> will reiterate that I don't think the kinds of attributes you are proposing
> should be in the scope of an effort that will try to address a framework
> for authorizing SIP requests. I don't think the values of the attributes
> (as opposed to the mere presence of some attributes) have anything to do
> with authorizing the SIP request that you propose would carry the
> attributes.
>
> With regards to this whole conferencing example, it does seem a bit
> contrived to me, like you're sketching a SIP-based way of setting
> conference policy on the fly that happens to require the kind of attributes
> you want, and then saying that demonstrates the need for the attributes.
> The fact that all of the ways to do conference policy we can point to in
> fact do it via the web makes it hard for me to understand why we should
> create a SIP-based way of doing this. To me, it looks like you're opening a
> problem space that has much more to do with reshaping the way that SIP does
> conferences (and again, as Radhika's mail pointing out, there's been a lot
> of thinking about this since the days of RFC4579) than it does with
> defining a framework for authorizing SIP requests.
>
> Jon Peterson
> Neustar, Inc.
>
> Cc: "[email-masked]" <[email-masked]>
> The attributes I provided are examples of attributes that might be
> provided in an access token; it was not meant to include all the attributes
> for this use case, because my intention was not to focus on conference
> server, but to discuss the idea in general.
>
> The INVITE sent to the conference factory could include a token that has a *
> conference-type* attribute which could take one of the following values: *audio,
> The conference factory will then issue a *conference uri* for the
> requested conference type, assuming the token is valid. If the
> *conference-type* attribute is missing, then the request would be
> rejected.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 22 Jun 2016 08:41:19 -0400

Jon,

I think we are still talking past each other.

The token added to the INVITE is *not a policy*; it is an authorization by
the AuthZ Server to allow this request to create a conference focus.

The policy is created and managed in the AuthZ Server; remember that the
idea is to delegate the AuthZ to a separate entity other than the server
providing the service.

Let’s continue with the conference use case:

                                 :                 :

                  +--------+     :                 :

                  | IdP    |     :                 :

    |             |        |     :                 :

    |             +--------+     :                 :

    |                 |          :                 :

    |                 |          :                 :

|        |        |        |     :                 :     | Conference

                                 :                 :

Let’s assume that the domain in Trust Domain 1 is example.com, and Alice
needs an account with this domain and needs access to the conference server.

The administrator of the example.com domain creates an account for Alice (
[email-masked]) and sets her *conference policy* to “*conference-type **=
audio | audio-webconference”* to allow her to create either an audio
conference or an audio-webconference.

Now, Alice decides to start an audio conference; to do that, the phone
obtains an access token from the AuthNZ server that allows Alice to start a
conference of the type “*audio”*.

When Alice sends the INVITE to the conference server, the phone will
include that specific access token, which will be used by the conference
factory to authorize the request to create a conference focus.

So, the conference server has no idea what the policy is; all it knows is
that it received a request with a token created by a specific AuthNZ
server. If the conference server trusts the AuthNZ server and the token is
valid, it authorizes the request and creates the requested conference
focus; otherwise, the request is rejected.

Hopefully this is clearer.

Regards,

 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 22 Jun 2016 08:48:29 -0400

Roman,

I think that the question of how to exactly carry the token in SIP request
is a minor issue *at this stage*.
We are discussing the idea and concept of delegating both the AuthN and
AuthZ to separate server(s) and how to achieve that.

Regards,
 Rifaat

On Tue, Jun 21, 2016 at 7:50 PM, Roman Shpount <[email-masked]> wrote:

>> The INVITE sent to the conference factory could include a token that has
>> a * conference-type* attribute which could take one of the following
>> values: *audio, video, webconference, audio-webconference, or
>> video-webconference*.
>>>> In that case, if you could furnish a use case with attributes that
>>>> would be carried in a SIP iNVITE that are actually salient to the
>>>> authorization of that particular SIP request, we'd be getting a lot closer
>>>> to common ground.
>>>>
>>>>
>>> The Authorization header in SIP, for example, is actually used by the
>>> UAS to make a decision about whether or not to authorize the request in
>>> which the header appears.  The token that you propose a SIP INVITE would
>>> carry in this case is not used by the relying party to make a decision
>>> about whether or not that INVITE is authorized. That's why I believe this
>>> conference policy issue is a different problem space entirely from figuring
>>> out how to implement attribute-based authorization for SIP requests.
>>>
>>> Jon Peterson
>>> Neustar, Inc.
>>>
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 22 Jun 2016 17:02:41 -0400

Rifaat,

In your example, I would expect to issue an HTTP request to create the
conference, get the SIP URI back (with authentication token embedded in the
URI) and place the SIP call to this URI. I do not see a reason why
any standardization effort is required to implement this.

Regards,

_____________
Roman Shpount

On Wed, Jun 22, 2016 at 8:48 AM, Rifaat Shekh-Yusef <[email-masked]>
wrote:

>>> On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <[email-masked]
>>> > wrote:
>>>
>>>>
>>>>>
>>>> Let me reiterate what I wrote in my previous mail, which I quote here
>>>> at the top: "furnish a use case with attributes that would be carried in a
>>>> SIP iNVITE that are actually salient to the authorization of that
>>>> particular SIP request." Again: "that particular SIP request." Not later
>>>> transactions in some broader context in which the original user agent
>>>> probably isn't even an endpoint.
>>>>

---

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

The token added to the INVITE is not a policy; it is an authorization by the AuthZ Server to allow this request to create a conference focus.

Well, this is the complexity level I was trying to avoid, but, I do agree that what your proposed token carries isn't strictly a conference policy - it is instead a policy that constrains conference policies that users are allowed to set.

The thing that RFC4353 calls "conference policy" is essentially a policy for a particular instance of a conference. The two attributes you initially proposed actually constrain conference policies rather than conferences - that is, they apply to all conferences that I might try to set policy for, rather than any given conference instance. When I set up a particular conference, for example, I might want it to be voice only, and to have four seats. That's the policy I want for that conference. I gather the attributes you proposed are the constraints that my local administrative domain imposes on conferences I create, so the conference policy I set for any given policy needs to be a subset of those constraints. If my administrative domain limits me to only three-seat conferences, then when I try to set a conference policy for four seats, that manipulation of conference policy would presumably be rejected when it is compared to my administrative domain's constraints.

But of course, in the ad hoc corner case you are considering, the conference bridge has no way of anticipating how many users Alice will try to add to the conference - so, her initial INVITE containing the parameter would never be rejected for violating the constraint on conference size, only later INVITEs would be. That attribute has nothing to do with authorizing the INVITE carrying the token.

Moreover, how does one actually manipulate my conference policy? According to RFC4353, it isn't with SIP. Probably with the web, with an HTTP request. RFC4579 et al do not provide provisions for setting conference policy. Adding the attributes you proposed to SIP isn't really about setting conference policy, it's about alerting the conference service to the constraints on conference policy that are imposed by my administrative domain. This is an important distinction, because it shows how far removed that SIP transaction actually is from the way conference policy is set. Why would I send a SIP request with the constraints on conference policy if I'm only going to have to use HTTP to actually set conference policy later? Why wouldn't my administrative domain have me attach its imposed constraints on conference policy to the actual HTTP message that is manipulating conference policy?

<snip>

Now, Alice decides to start an audio conference; to do that, the phone obtains an access token from the AuthNZ server that allows Alice to start a conference of the type “audio”.

I did figure you had something like this is mind - perhaps that Alice would send her INVITE to the IdP first, and that the IdP would then  inspect and authorize a conference policy that Alice somehow conveyed via the INVITE. Through what field or parameter do you suppose to INVITE will convey that Alice intends for the conference to be restricted to audio media? Or do you perhaps mean that Alice would use HTTP to inform her IdP of the media choices for the conference - in the which case policy for the conference starts in the HTTP realm, and should certainly stay there.

I imagine that in the corner case of an ad hoc conference, the INVITE that Alice is sending would contain some session negotiation parameters that could be taken to imply what sorts of media types Alice wants to allow or forbid in the conference. But I will reiterate that RFC4579 and the related specifications I can think of off the top of my head do not contain a provision for the INVITE to communicate session policy information - and I don't think it is safe to infer from the SDP in an INVITE that Alice intends to limit the conference to the media type(s) it offers.

Moreover, in the ad hoc conference corner case, I see no plausible justification for why the conference bridge would ever reject Alice's initial INVITE based on the media type it contains. If she's sending her INVITE through the IdP via SIP, it would never even forward the request, let alone issue a token for it, if it didn't like the media type that Alice was proposing - if Alice proposes "video", and the IdP only allows "audio", when the IdP receives Alice's INVITE containing "video" it would do the rejecting itself (in SIP or HTTP). So once again, I don't see how this token would ever lead to the actual INVITE that carried the token ever being rejected by the conference bridge based on the media types authorized by the token.

Jon Peterson
Neustar, Inc.

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Thu, 23 Jun 2016 11:55:36 +0000

Hi, Jon:

"So once again, I don't see how this token would ever lead to the actual INVITE that carried the token ever being rejected by the conference bridge based on the media types authorized by the token."

Based on your above conclusion, it appears that there is something missing the way the SIP conferencing is set up. My guess is that both the conference initiator (who sent the original INVITE) and conference "focus" should be autonomous in accepting or rejecting the call if the conferencing parameters are not within the expectation of their respective domains.

I would be glad to know what are the criteria that the SIP-based conferencing based on focus standardized so far for accepting or rejecting the call if it is not token or it is other parameter including SDP.

Your analysis will really be helpful to us.

BR/Radhika

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

<snip>

	Now, Alice decides to start an audio conference; to do that, the phone obtains an access token from the AuthNZ server that allows Alice to start a conference of the type "audio".

Jon Peterson
Neustar, Inc.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 23 Jun 2016 10:21:04 -0400

On Wed, Jun 22, 2016 at 6:29 PM, Peterson, Jon <[email-masked]>
wrote:

>
> The token added to the INVITE is *not a policy*; it is an authorization
> by the AuthZ Server to allow this request to create a conference focus.
>
>
> Well, this is the complexity level I was trying to avoid, but, I do agree
> that what your proposed token carries isn't strictly a conference policy -
> it is instead a policy that constrains conference policies that users are
> allowed to set.
>
> The thing that RFC4353 calls "conference policy" is essentially a policy
> for a particular instance of a conference. The two attributes you initially
> proposed actually constrain conference policies rather than conferences -
> that is, they apply to all conferences that I might try to set policy for,
> rather than any given conference instance. When I set up a particular
> conference, for example, I might want it to be voice only, and to have four
> seats. That's the policy I want for that conference. I gather the
> attributes you proposed are the constraints that my local administrative
> domain imposes on conferences I create, so the conference policy I set for
> any given policy needs to be a subset of those constraints. If my
> administrative domain limits me to only three-seat conferences, then when I
> try to set a conference policy for four seats, that manipulation of
> conference policy would presumably be rejected when it is compared to my
> administrative domain's constraints.
>
> But of course, in the ad hoc corner case you are considering, the
> conference bridge has no way of anticipating how many users Alice will try
> to add to the conference - so, her initial INVITE containing the parameter
> would never be rejected for violating the constraint on conference size,
> only later INVITEs would be. That attribute has nothing to do with
> authorizing the INVITE carrying the token.
>

Let me give you an example from the Web that I use all the time.
I use Google Drive to share files with others; to do that I go to specific
file/directory that I would like to share and add the email of the person
that I would like to share the file with, and get a link to that
file/directory.
I send that link to the person that owns the email address, which will be
able to use his email address and his credentials to get access to the
file/directory; the system will prevent anybody else from accessing that
file.

So, Google Drive has no way of knowing that someone else other than the one
that I authorized would try to access the file, but it has a clear
understanding of the authorization around this specific file/directory that
it enforces for any access attempts that comes after I set the
authorization.

In that sense, it is similar to this conference use case.

Why is this a problem? what is it about the conference server enforcing a
specific authorization on later requests that is problematic?

>
> Moreover, how does one actually manipulate my conference policy? According
> to RFC4353, it isn't with SIP. Probably with the web, with an HTTP request.
> RFC4579 et al do not provide provisions for setting conference policy.
> Adding the attributes you proposed to SIP isn't really about setting
> conference policy, it's about alerting the conference service to the
> constraints on conference policy that are imposed by my administrative
> domain. This is an important distinction, because it shows how far removed
> that SIP transaction actually is from the way conference policy is set. Why
> would I send a SIP request with the constraints on conference policy if I'm
> only going to have to use HTTP to actually set conference policy later?
>

Sorry, but this last sentence is not clear to me. What do you mean by "f
I'm only going to have to use HTTP to actually set conference policy later?"
Remember that the conference policy is now managed on the AuthNZ server,
not the conference server.

> Why wouldn't my administrative domain have me attach its imposed
> constraints on conference policy to the actual HTTP message that is
> manipulating conference policy?
>
> <snip>
>
>
> I did figure you had something like this is mind - perhaps that Alice
> would send her INVITE to the IdP first, and that the IdP would then
>  inspect and authorize a conference policy that Alice somehow conveyed via
> the INVITE. Through what field or parameter do you suppose to INVITE will
> convey that Alice intends for the conference to be restricted to audio
> media? Or do you perhaps mean that Alice would use HTTP to inform her IdP
> of the media choices for the conference - in the which case policy for the
> conference starts in the HTTP realm, and should certainly stay there.
>

No, I am not suggesting to use SIP to communicate with the IdP at all. The
idea is to utilize existing mechanisms that know how to do that already.
In our OAuth draft, we proposed to use HTTP to communicate with the IdP and
SIP to carry the token(s) or code.
https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-oauth/

>
> I imagine that in the corner case of an ad hoc conference, the INVITE that
> Alice is sending would contain some session negotiation parameters that
> could be taken to imply what sorts of media types Alice wants to allow or
> forbid in the conference. But I will reiterate that RFC4579 and the related
> specifications I can think of off the top of my head do not contain a
> provision for the INVITE to communicate session policy information - and I
> don't think it is safe to infer from the SDP in an INVITE that Alice
> intends to limit the conference to the media type(s) it offers.
>
> Moreover, in the ad hoc conference corner case, I see no plausible
> justification for why the conference bridge would ever reject Alice's
> initial INVITE based on the media type it contains. If she's sending her
> INVITE through the IdP via SIP, it would never even forward the request,
> let alone issue a token for it, if it didn't like the media type that Alice
> was proposing - if Alice proposes "video", and the IdP only allows "audio",
> when the IdP receives Alice's INVITE containing "video" it would do the
> rejecting itself (in SIP or HTTP).
>

Yes, that is the whole idea; to delegate the authorization part from the
conference server; the only thing that the conference will be doing now is
enforcing the authorization provided in the token, assuming the token is
valid and provided by a trusted entity.

> So once again, I don't see how this token would ever lead to the actual
> INVITE that carried the token ever being rejected by the conference bridge
> based on the media types authorized by the token.
>

So what? why is this a problem?

Regards,
 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 23 Jun 2016 10:32:25 -0400

Roman,

We are specifically talking about an RFC4579 based conference use case,
just to drive the point and discuss the concept and idea of delegating
AuthNZ to other entities.

Regards,
 Rifaat

On Wed, Jun 22, 2016 at 5:02 PM, Roman Shpount <[email-masked]> wrote:

> On Wed, Jun 22, 2016 at 8:48 AM, Rifaat Shekh-Yusef <[email-masked]
> > wrote:
>
>> Roman,
>>
>> I think that the question of how to exactly carry the token in SIP
>> request is a minor issue *at this stage*.
>>> On Tue, Jun 21, 2016 at 7:46 PM, Peterson, Jon <[email-masked]
>>> > wrote:
>>>
>>>>
>>>> The INVITE sent to the conference factory could include a token that
>>>> has a * conference-type* attribute which could take one of the
>>>> following values: *audio, video, webconference, audio-webconference,
>>>> or video-webconference*.
>>>> On Wed, Jun 15, 2016 at 5:06 PM, Peterson, Jon <
>>>> [email-masked]> wrote:
>>>>
>>>>>
>>>>>>
>>>>> An obvious example would be an INVITE with a token sent to a
>>>>> conference factory to authorize the creation of a focus.
>>>>>
>>>>>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 23 Jun 2016 10:40:28 -0400

> AuthNZ to other entities.
I think it is more like we are discussing spherical elephants in vacuum. I
am not aware of anybody using  RFC4579 based conference in such a manner or
ever needing to so.

Is there a practical application for this framework?
_____________
Roman Shpount

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Thu, 23 Jun 2016 17:35:41 +0000

Inline [RRR]

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Thursday, June 23, 2016 10:40 AM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [sipcore] 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. 

________________________________

On Thu, Jun 23, 2016 at 10:32 AM, Rifaat Shekh-Yusef <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	Roman,

	We are specifically talking about an RFC4579 based conference use case, just to drive the point and discuss the concept and idea of delegating AuthNZ to other entities.

I think it is more like we are discussing spherical elephants in vacuum. I am not aware of anybody using  RFC4579 based conference in such a manner or ever needing to so.

[RRR] SIP-based centralized conferencing is being used in proprietary ways following these kinds of framework (RFC4579 )and 3rd party call control RFCs filling many black holes that these RFCs do not answer including security.

[RRR] Industry did not get enough guidance from IETF RFCs for multiparty multimedia conferencing.

[RRR] This security discussion is one of the mini-vivid examples. 
_____________
Roman Shpount

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 24 Jun 2016 18:27:09 +0000

Moreover, in the ad hoc conference corner case, I see no plausible justification for why the conference bridge would ever reject Alice's initial INVITE based on the media type it contains. If she's sending her INVITE through the IdP via SIP, it would never even forward the request, let alone issue a token for it, if it didn't like the media type that Alice was proposing - if Alice proposes "video", and the IdP only allows "audio", when the IdP receives Alice's INVITE containing "video" it would do the rejecting itself (in SIP or HTTP).

Yes, that is the whole idea; to delegate the authorization part from the conference server; the only thing that the conference will be doing now is enforcing the authorization provided in the token, assuming the token is valid and provided by a trusted entity.

... um, I would have thought this totally undermined your argument. If the IdP simply prevents the INVITE from ever being sent to the conference bridge when the proposed media type is unacceptable to the IdP, then there's no need to carry attribute to the conference bridge at all. If the IdP doesn't like the media type, the conference bridge will never see the INVITE; and if the conference bridge sees the INVITE, then the IdP must have liked the media type. Attribute adds nothing.

This is a consequence of architecting an administrative domain in a draconian way that lets intermediaries prevent user agents from sending SIP messages where they like, of course. 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.

So once again, I don't see how this token would ever lead to the actual INVITE that carried the token ever being rejected by the conference bridge based on the media types authorized by the token.

It's a problem because you're proposing to take a feature (OAuth) that exists in HTTP and to add it to SIP.  To make an argument for that, you at least must establish that SIP needs this feature - and preferably you need to establish that making this protocol change and performing these operations in SIP is less work (in the grand scheme of implementation and deployment overall) than saying that if you want to perform operations like this you should instead just use HTTP. (Which you can, and for these conference cases, you surely should.)

What I postulated way back at the beginning of this thread is that the kind of applications that benefit from attribute-based authorization tend to be controlled by the web rather than by SIP, and that this is why, although we've been studying this problem space for more than a decade, we never standardized an attribute-based authorization protocol for SIP. This entire conferencing example has been about manipulating conference policy and managing constraints on conference policy, which may be a problem space with unsolved issues (honestly, I'm not much of an expert on the current thinking about conferencing) but I don't think it's the SIP authorization problem space.

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, is mainly about figuring out why you would say yes or no to that question. What you are proposing here is a conference policy constraint token that lets the IdP piggyback information on the INVITE to be sent to the conference bring. We've struggled here to even identify how that information would alter to the decision about whether or not to accept the INVITE. If we need to standardize a protocol mechanism for that function, I have a hard time seeing why SIP would be our first choice, and then why an INVITE setting up a session would be the right choice, versus just doing this with a protocol interaction that has a semantics other than "I'd like to set up a session with you."

I'd note that your Google drive example is also a pretty poor fit for these semantics. But these are the primary semantics of SIP. If the thing you want to do has different semantics, there's probably a way to do with a different protocol. Albeit, that doesn't mean there isn't an authorization problem for SIP worth identifying and considering.

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Fri, 24 Jun 2016 19:13:01 +0000

Hi, Rifaat:

If we look into SIP XCON RFCs for centralized conferencing in SIP (and even in 3pcc),  the fundamental assumption is this: All conferencing services to all users are centrally controlled by the "focus." It has been done for a very solid technical reason: Distributed real-time conferencing services with multimedia for multiparty are very difficult to deal with, not only in SIP but in all other call control protocols, and security feature is only one them.

If the above criterion is not met and AuthNZ is put outside the control of the focus for real-time multimedia multipoint call, Jon has shown diligently where it leads to us.

So, I suggest let us analyze all RFCs related of XCON WG and suggest what we can do best here under the umbrella of focus.

BR/Radhika 

PS: Jon - I got the answer of my earlier email sent to you why focus will not be able to either accept or reject the call.

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Friday, June 24, 2016 2:27 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.

	Regards,
	 Rifaat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 28 Jun 2016 05:32:21 -0400

On Fri, Jun 24, 2016 at 2:27 PM, Peterson, Jon <[email-masked]>
wrote:

> ... um, I would have thought this totally undermined your argument. If the
> IdP simply prevents the INVITE from ever being sent to the conference
> bridge when the proposed media type is unacceptable to the IdP, then
> there's no need to carry attribute to the conference bridge at all. If the
> IdP doesn't like the media type, the conference bridge will never see the
> INVITE; and if the conference bridge sees the INVITE, then the IdP must
> have liked the media type. Attribute adds nothing.
>
> This is a consequence of architecting an administrative domain in a
> draconian way that lets intermediaries prevent user agents from sending SIP
> messages where they like, of course.
>

I am not sure what you mean by this. The IdP cannot prevent anybody from
sending any request to any server.

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

> It's a problem because you're proposing to take a feature (OAuth) that
> exists in HTTP and to add it to SIP.
>

I would not call OAuth a "feature". It is an authorization framework.

> To make an argument for that, you at least must establish that SIP needs
> this feature - and preferably you need to establish that making this
> protocol change and performing these operations in SIP is less work (in the
> grand scheme of implementation and deployment overall) than saying that if
> you want to perform operations like this you should instead just use HTTP.
> (Which you can, and for these conference cases, you surely should.)
>
> What I postulated way back at the beginning of this thread is that the
> kind of applications that benefit from attribute-based authorization tend
> to be controlled by the web rather than by SIP, and that this is why,
> although we've been studying this problem space for more than a decade, we
> never standardized an attribute-based authorization protocol for SIP. This
> entire conferencing example has been about manipulating conference policy
> and managing constraints on conference policy, which may be a problem space
> with unsolved issues (honestly, I'm not much of an expert on the current
> thinking about conferencing) but I don't think it's the SIP authorization
> problem space.
>
> 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.
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.

Regards,
 Rifaat

> is mainly about figuring out why you would say yes or no to that question.
> What you are proposing here is a conference policy constraint token that
> lets the IdP piggyback information on the INVITE to be sent to the
> conference bring. We've struggled here to even identify how that
> information would alter to the decision about whether or not to accept the
> INVITE. If we need to standardize a protocol mechanism for that function, I
> have a hard time seeing why SIP would be our first choice, and then why an
> INVITE setting up a session would be the right choice, versus just doing
> this with a protocol interaction that has a semantics other than "I'd like
> to set up a session with you."
>
> I'd note that your Google drive example is also a pretty poor fit for
> these semantics. But these are the primary semantics of SIP. If the thing
> you want to do has different semantics, there's probably a way to do with a
> different protocol. Albeit, that doesn't mean there isn't an authorization
> problem for SIP worth identifying and considering.
>
> Jon Peterson
> Neustar, Inc.
>
>
> Regards,
>  Rifaat
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jun 2016 16:55:07 -0400

On 6/28/16 5:32 AM, Rifaat Shekh-Yusef wrote:

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

If you want to tell a server something about what you want it to do, you 
can use caller preferences. At least then you are being explicit about it.

That seems more straightforward than embedding similar information into 
an authorization token.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 30 Jun 2016 10:29:13 -0400

An access token is explicit too; it carries authorization to access some
resource/service.

I am not sure what you have in mind.
Are you suggesting that after the UA/Proxy gets the token from the IdP,
that the UA/Proxy would then transform the authorizations given in the
token to a SIP caller preference format?

Regards,
 Rifaat

On Tue, Jun 28, 2016 at 4:55 PM, Paul Kyzivat <[email-masked]> wrote:

> That seems more straightforward than embedding similar information into an
> authorization token.
>
>         Thanks,
>         Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jun 2016 10:43:20 -0400

> token to a SIP caller preference format?

It sounds like you are imagining a situation where the user gets a token 
that authorizes some specific service(s) without the user knowing what 
services those are. And then the user makes a request with the token and 
expects the server to figure out what services to supply.

That seems backwards to me. I would expect that the user would figure 
out what services he wants, then get some credentials that are 
sufficient to authorize the service, and then request the service and 
supply the credentials to cover it.

It may be that the credentials he has are broad enough to cover lots of 
services. He doesn't want them all, he wants what he wants at the time 
of invocation.

So callerprefs provides a mechanism to express what features you want 
from a callee. To that you then need to supply credentials, in this case 
in the form of an authorization token.

	Thanks,
	Paul

> Regards,
>  Rifaat
>
>
>
>
> On Tue, Jun 28, 2016 at 4:55 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     If you want to tell a server something about what you want it to do,
>     you can use caller preferences. At least then you are being explicit
>     about it.
>
>     That seems more straightforward than embedding similar information
>     into an authorization token.
>
>             Thanks,
>             Paul
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 30 Jun 2016 13:02:29 -0400

On Thu, Jun 30, 2016 at 10:43 AM, Paul Kyzivat <[email-masked]>
wrote:

> services those are.

No, that is not what I am proposing.
The user in the conference example will have to explicitly ask for a
specific conference type, e.g. video conference.
There are different ways of obtaining a token with the right authorization
needed for a specific service.

> And then the user makes a request with the token and expects the server to
> figure out what services to supply.
>

Yes, the server providing the service will be able to validate the token,
which explicitly states requested service (e.g. video conference with a
maximum of 5 participants) , and then provide the service accordingly.

>
> That seems backwards to me. I would expect that the user would figure out
> what services he wants, then get some credentials that are sufficient to
> authorize the service, and then request the service and supply the
> credentials to cover it.
>
> services. He doesn't want them all, he wants what he wants at the time of
> invocation.
>
> So callerprefs provides a mechanism to express what features you want from
> a callee. To that you then need to supply credentials, in this case in the
> form of an authorization token.
>

Well, if we are sending an authorization token anyway, why would we
separate the token from the authorizations?

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Jun 2016 13:24:17 -0400

Comment at end

On 6/30/16 1:02 PM, Rifaat Shekh-Yusef wrote:
>
> On Thu, Jun 30, 2016 at 10:43 AM, Paul Kyzivat <[email-masked]
>     It sounds like you are imagining a situation where the user gets a
>     token that authorizes some specific service(s) without the user
>     knowing what services those are.
>
> There are different ways of obtaining a token with the right
> authorization needed for a specific service.
>
>     And then the user makes a request with the token and expects the
>     server to figure out what services to supply.
>
> Yes, the server providing the service will be able to validate the
> token, which explicitly states requested service (e.g. video conference
> with a maximum of 5 participants) , and then provide the service
> accordingly.
>
>     That seems backwards to me. I would expect that the user would
>     figure out what services he wants, then get some credentials that
>     are sufficient to authorize the service, and then request the
>     service and supply the credentials to cover it.
>
>     It may be that the credentials he has are broad enough to cover lots
>     of services. He doesn't want them all, he wants what he wants at the
>     time of invocation.
>
>     So callerprefs provides a mechanism to express what features you
>     want from a callee. To that you then need to supply credentials, in
>     this case in the form of an authorization token.
>

1) Separation of responsibility.

2) What you are suggesting would require authorization servers to have 
the means to dice up authorizations into whatever granularity a user 
wants to request services.

Suppose some systems don't do that. They simply grant you access to a 
conference server that can do all sorts of conferences. But you still 
want to decide whether to have an audio-only conference or an 
audio/video conference. Now you need a different way to request that.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 Jun 2016 20:03:09 +0000

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