Subject: Re: [sipcore] Fwd: New Version Notification for draft-yusef-sipcore-sip-oauth-00.txt

From: Michael Procter <[email-masked]>
Date: Thu, 5 Jun 2014 20:17:56 +0100

On 29 May 2014 18:45, Rifaat Shekh-Yusef <[email-masked]> wrote:
> Hi Michael,
>
> Thanks for the review and feedback.
>
> Sure, I will add a section to talk about uses cases.
> Would you be able to share your use cases to see if we can cover them in
> this document?

The main use-case that sprang to mind was if someone wanted to use an
"Auto-Attendant-as-a-Service" app with their existing SIP trunking
provider.  In this scenario I imagined visiting AAaaS.example.com, and
doing the normal HTTP-based OAUTH cycle with an account on
itsp.example.net, so that itsp.example.net gives a suitable access
token to AAaaS.example.com.  Then, AAaaS.example.com could use the
token in some way to perform the necessary SIP activity at the ITSP.
With that in mind, I can see that I could use the flow in section 5,
or something quite like it.  Single purpose SIP credentials would also
work, of course.

The flow in section 4 involves passing my username/password for
itsp.example.net to AAaaS.example.com, which I probably don't feel
comfortable doing.  Maybe this flow would make more sense from a trust
perspective with something like a real phone rather than a webapp.  A
use-case would probably help me understand when this flow could be
used.

I don't know when I'd use the flow in section 3.  If the client has an
adequate UI, I don't see why this is better than using OAUTH over HTTP
to start with.  If it doesn't have an adequate UI, then this feels
more like an automatic provisioning approach.  This flow seems to move
all the OAUTH machinery into SIP, but I don't know enough about the
properties of OAUTH to say whether this is a good or bad idea yet!
Again, a use-case would definitely help me understand what you want to
achieve with this flow.

Regards,

Michael

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 7 Jun 2014 16:47:59 -0400

On Thu, Jun 5, 2014 at 3:17 PM, Michael Procter <[email-masked]> wrote:

> or something quite like it.

Yes, the flow in section 5 would definitely address such a use case.

> Single purpose SIP credentials would also
> work, of course.
>
>
True, but with the token-based solution the token could be used to get
access to other services, and to control the level of service provided by
an application.

> use-case would probably help me understand when this flow could be
Yes, real phones is what I had in mind for this one.
This flow would allow the system to utilize the existing authentication
mechanism (Digest), and still be able to enjoy the benefits of a
token-based authorization.

> Again, a use-case would definitely help me understand what you want to
What I had in mind with this one is a 3rd party authorization server that
could provide authorization for SIP and non-SIP clients for various
services.
With the Authorization Code Grant as defined in RFC6749, the authentication
is not defined and typically done in the context of the code downloaded to
the browser.
The idea here is to introduce a new interface that would allow the client
to directly authenticate with the authorization server to allow the SIP
phones to utilize that existing authorization server.

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 07 Jun 2014 19:34:59 -0400

Rifaat,

Thanks for taking a crack at this. I realize it is a rough first cut.

Take these comments with a grain of salt - I may well just not 
understand what you intend.

IIUC, the general intended flow is:
- UA sends register, gets 302 with https URI
- UA understands that to mean that it should use that URI
   to request authorization, to be later used to retry
   the register.

I find a leap of faith there. This is very different semantics from 
normal handling of 3xx. 3xx responses *may* contain arbitrary URIs, 
including https URIs. But what exactly to do in such a case is not 
specified. It seems unreasonable to assume that it always means what 
this draft has assumed.

Then there is a further leap of faith that after using the returned 
https uri one should then use the results of that to retry the original 
register request with the original sip URI, together with the new 
credentials.

I'm sure we can find a way to signal that this is the intended behavior, 
but I suspect that a 3xx response is not the answer. I'm inclined to 
think that a 401, together with some new content in the response, would 
be a better way.

Then, I guess all of that is preparatory to getting a token to be used 
to cause subsequent requests to be authenticated. What assumptions are 
you making here?

Is it necessary to provide credentials to authenticate all requests? Or 
can this be avoided if you use a secure transport for the register and 
the subsequent requests?

How does this relate to sip outbound? Can responses to outbound requests 
to the UA be authenticated? Is there a reason they don't need to be?

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 8 Jun 2014 17:16:49 -0400

Hi Paul,

Thanks for your review and comments.
Please, see my reply inline...

Regards,
 Rifaat

On Sat, Jun 7, 2014 at 7:34 PM, Paul Kyzivat <[email-masked]> wrote:

> Take these comments with a grain of salt - I may well just not understand
> what you intend.
>
Correct.

I find a leap of faith there. This is very different semantics from normal
> handling of 3xx. 3xx responses *may* contain arbitrary URIs, including
> https URIs. But what exactly to do in such a case is not specified. It
> seems unreasonable to assume that it always means what this draft has
> assumed.
>
> Then there is a further leap of faith that after using the returned https
> uri one should then use the results of that to retry the original register
> request with the original sip URI, together with the new credentials.
>
> but I suspect that a 3xx response is not the answer. I'm inclined to think
> that a 401, together with some new content in the response, would be a
> better way.
>
>
I was trying to capture the idea; the exact details of which code to use
and what details to include in the body is obviously still open for
discussion.
401 would be a reasonable approach too.

> Then, I guess all of that is preparatory to getting a token to be used to
> cause subsequent requests to be authenticated. What assumptions are you
> making here?
>
>
1. Client Type: confidential
2. The mechanism must work over secure and non-secure transports.

> can this be avoided if you use a secure transport for the register and the
> subsequent requests?
>
>
If the client and server are able to establish a mutually authenticated
secure channel, then there is no need to authenticate every subsequent
request; otherwise, I think it is needed.

> How does this relate to sip outbound?

Good question; I did not think about it before you mentioned it.
Assuming all outbound proxies use the same authorization server, then I
think that it would be possible to use the token the client receives from
the first registrations to register with the other proxies.

Can responses to outbound requests to the UA be authenticated?

It is possible because both sides have a shared master-key that could be
used by both sides to compute a proof-of-possession.

Is there a reason they don't need to be?
The only reason I can think of is performance impact on the server.

I need to spend more time thinking about the implications of outbound on
this.

Regards,
 Rifaat

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