Subject: [sipcore] Question on drafft-yusef-sipcore-sip-oauth-01

From: Adam Lewis <[email-masked]>
Date: Wed, 14 Jan 2015 22:08:15 +0000

Hi,

I am confused by the way that OAuth is currently proposed to be used with SIP in this draft.  Looking at the flow of messages in section 3.2, it shows at F3  that the SIP UA (after receiving the 401 in F2) triggers an authorization request to the authorization endpoint of the authorization server, at which point the UA utilizes the master-key to authenticate to the authorization server at F5.  Finally the UA gets the authorization code at F6.  All good so far.

My confusion starts at F7 where the UA sends the code to the Proxy, and where the proxy exchanges the code for the actual token (F8/F9).  This is a bit of an unconventional flow, as normally the client that obtains the authorization code is the same client that exchanges it for the token.  Why in this flow is the UA obtaining the code, only to send it to the proxy to obtain the token?

I would have thought that the UA would use the code to obtain the token, and embed the token in its request to the proxy, to authenticate the user.  Then the proxy could do a p-asserted-id or something similar when routing SIP messages onward ...

tx!
adam

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 16 Jan 2015 10:33:53 -0500

Hi Adam,

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

Regards,
 Rifaat

On Wed, Jan 14, 2015 at 5:08 PM, Adam Lewis <
[email-masked]> wrote:

>  Hi,
>
>
>
> I am confused by the way that OAuth is currently proposed to be used with
> SIP in this draft.  Looking at the flow of messages in section 3.2, it
> shows at F3  that the SIP UA (after receiving the 401 in F2) triggers an
> authorization request to the authorization endpoint of the authorization
> server, at which point the UA utilizes the master-key to authenticate to
> the authorization server at F5.  Finally the UA gets the authorization code
> at F6.  All good so far.
>
>
>
> My confusion starts at F7 where the UA sends the code to the Proxy, and
> where the proxy exchanges the code for the actual token (F8/F9).  This is a
> bit of an unconventional flow, as normally the client that obtains the
> authorization code is the same client that exchanges it for the token.  Why
> in this flow is the UA obtaining the code, only to send it to the proxy to
> obtain the token?
>

Notice that in F9 the authorization server returns the ID Token and the
master-key to the proxy. The master-key is needed to allow us to use the
proof-of-possession mechanism for any subsequent messages as described at
the top of page 8 (F11/F12).

>
> I would have thought that the UA would use the code to obtain the token,
> and embed the token in its request to the proxy, to authenticate the user.
> Then the proxy could do a p-asserted-id or something similar when routing
> SIP messages onward ...
>

With the current document the ID Token is not sent to the UA; we have an
open issue around that, and I think it probably makes more sense to send it
back to the UA to allow the UA to use the ID Token with its communication
with SIP and non-SIP network elements.

Regards,
 Rifaat

>
>
>
> tx!
>
> adam
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>