Subject: Re: [sipcore] draft-yusef-sipcore-sip-oauth-00

From: [email-masked] (Dale R. Worley)
Date: Thu, 3 Jul 2014 15:44:01 -0400

> From: Rifaat Shekh-Yusef <[email-masked]>

> > It's not clear to me why the UA is required to use the code to obtain
> > a token.  Isn't the possession of the code sufficient proof of
> > identity of the requester?  (This is also seen in OAuth, but I didn't
> > spot the explanation of the need for the two-step process to obtain
> > authorization for a request.)
>
> This is explained in RFC6749, section 1.3.1.

I assume you mean:

   1.3.1.  Authorization Code

   [...]

   The authorization code provides a few important security benefits,
   such as the ability to authenticate the client, as well as the
   transmission of the access token directly to the client without
   passing it through the resource owner's user-agent and potentially
   exposing it to others, including the resource owner.

> > And I notice that the "authenticated request" process does not depend
> > on the "token" value.  What is the token used for?  Or is there a
> > mistake here?
> >
> The token is used to control the various services and the level of service
> allowed for the user in possession of the token.

Comparing the description in RFC 6749, section 1.3.1, para. 3 with the
figure in section 3.1 of draft-yusef-sipcore-sip-oauth-00:

   User                            Proxy                   Authorization
   Agent                                                          Server
   ---------------------------------------------------------------------
     |                               |                               |
     | REGISTER [email-masked]  |                               |
     |------------------------------>|                               |
     |                           302 |                               |
     |<------------------------------|                               |
     |                               |                               |
     | GET /authorize?response_type=code&...                         |
     |-------------------------------------------------------------->|
     |                               |                           401 |
     |<--------------------------------------------------------------|
     |                               |                               |
     |                               |                               |
   o master-key = HMAC-SHA256(HA1, realm + nonce)                    |
     |                               |                               |
     | GET /authorize?response_type=code&... with credentials        |
     |-------------------------------------------------------------->|
     |                               |                               |
     |                               |                               |
     |                      o master-key=HMAC-SHA256(HA1, realm + nonce)
     |                               |                               |
     |                               |                    302 [code] |
     |<--------------------------------------------------------------|
     |                               |                               |
     |                               |                               |
     | REGISTER [email-masked] & code                           |
     |------------------------------>|                               |
     |                               | POST /token [code]            |
     |                               |------------------------------>|
     |                               |    200 OK [ token,            |
     |                               |             refresh token,    |
     |                               |             master-key]       |
     |                               |<------------------------------|
     |                        200 OK |                               |
     |<------------------------------|                               |
     |                               |                               |
     |                               |                               |

and the corresponding flow for OAuth in the top image in
http://docs.oracle.com/cd/E39820_01/doc.11121/gateway_docs/content/oauth_flows.html
("UAuth for Dummies, i.e., Me") ...

It appears that you want the SIP proxy (as OAuth Client) to send the
authorization code to the Authorization Server to obtain a token.  In
the OAuth case, the token is sent by the Client to the Resource Server
to get the Resource Server to do something that it wants.

But looking at the figure in the draft, there is no Resource Server.
All that I see is that the SIP user agent can get the proxy to accept
its call.

I suspect that there is an un-shown leg of this call, where the proxy
then sends the call, with the token attached somehow, to a further
UAS.  This UAS takes the Resource Server role, and uses the token to
authorize the request.

To make this work, section 2 has to be changed to say "The Proxy will
play [the Client] role with SIP, rather than the current Resource
Server role.

The protocol description would also have to show how the token was
attached to the forwarded SIP request.

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 4 Jul 2014 09:44:57 -0400

>    exposing it to others, including the resource owner.
Yes.

> figure in section 3.1 of draft-yusef-sipcore-sip-oauth-00:

It depends on the requested service by the UA.
If the user is initiating a call, then the proxy is the Resource Server in
this case, and no need to forward the token to another server.
If the user, for example, is trying to access his Voice Mail on some Voice
Mail Server, then the proxy will forward the INVITE to the Voice Mail
Server and include the token associated with that user.
The standard way to carry the token is by using the Bearer scheme as
follows:

   Authorization: Bearer token=<some-token>

I will expand on this in the next version of the draft.

Regards,
 Rifaat

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 4 Jul 2014 10:36:16 -0400

> this case, and no need to forward the token to another server.

I assume you mean "if the resource being requested is to get the proxy
to forward the call".  In that case, the proxy is *both* the Client
(in that it passes the access code to the Authorization Server to get
the token) and the Resource Server (in that it uses the token to
authorize the forwarding).

But in that case, is there any functional need for the token?  Or it
used in this case to make the process uniform with what is done in the
case below?

> I will expand on this in the next version of the draft.

Please do -- since this isn't actually "OAuth inserted into SIP", you
have to specify that, it isn't implicit.

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 4 Jul 2014 13:25:34 -0400

> authorize the forwarding).
Correct.

> used in this case to make the process uniform with what is done in the
The purpose of the token in this case is to make sure that the user is
allowed get basic services as long as the token is valid.
If the proxy is unable to refresh the token before it expires, then the
proxy must challenge the UA, and the UA will then have to go to the
Authorization Server to get a new code.

> have to specify that, it isn't implicit.
I did use the Bearer scheme in other parts of the document, but I agree
with you that I need to explicitly specify it here.

Regards,
 Rifaat