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

From: [email-masked] (Dale R. Worley)
Date: Wed, 25 Jun 2014 16:07:43 -0400

Here are some thoughts on draft-yusef-sipcore-sip-oauth-00, mostly on
section 3.  I don't want to sound too critical here, but there are a
bunch of details that could be cleared up in the -01.

The subject is a bit slippery because it isn't really "OAuth used to
authenticate SIP", but an OAuth-like protocol used to authenticate
SIP.  (I got wrong-footed before I realized that.)  So the draft needs
to spell out all the details of the operations, because you can't
reliably interpolate what parts of OAuth are to be copied into the
protocol.

Similarly, the list of OAuth roles isn't particularly informative,
because the roles in SIP have somewhat different functions and
different names.  (That wrong-footed me before I realized the OAuth
roles weren't a guide to how the protocol worked.)

It seems like we do not *need* to use 3xx responses to the first
REGISTER request and the final GET request.  (Though they might prove
to be convenient for various reasons.)  In OAuth, these are needed
because the sequencing of these requests must be done by the browser,
which is assumed to not understand the OAuth protocol flow; the 3xx
responses direct it to perform the correct sequence.  In the SIP case,
we assume that the UA knows the OAuth sequence.  So we could have the
response to the first REGISTER be a 4xx response, and the response to
the final GET be a 200 response, and the UA would still know what to
do.

It would be good to know how the first REGISTER response interoperates
when there are other authentication mechanisms present.  I'd expect a
407 response with suitable Proxy-Authenticate headers; the grammar
allows a wide variety of authentication challenges, and the
authorization server URL could be returned in one of them, while
challenges for different auth. methods could be in others.

It appears that the message flow requires the process to start with a
REGISTER method, because the proxy needs to return the "token".  Is
this true?  It would be better if the process could start with any
request, because the UA might discover at any moment that it has stale
authentication values.  If there is a dependency of authentication on
registration, this should be spelled out explicitly as a design
feature/constraint.

A design feature of OAuth is that the authorization server redirects
the user's browser back to the location of the initial HTTP request
after the user authenticates himself.  This is accomplished by the
server of the initial request providing a redirection to the
authentication server that includes the original URL as a parameter.
The details of this are fixed in the OAuth specification.  Since we
assume the UA knows the OAuth-SIP message sequence, we can have the UA
remember the destination of the original request.  On the other hand,
if we want the authorization server to have control, that part of the
message sequence needs to be specified (which isn't now).

The correspondence of phrases like "the initial request" with the
messages in the flow diagram is not very clear.  E.g., in section 3.3,
"the initial request" is the first GET, which is the 3rd message in
the diagram, and the 2nd "request" in the diagram.  It would help to
name the messages (the convention seems to be F1, F2, etc.) and refer
to the messages by name in the text.

It would help if the semantics of some of the data items was
explained.  For instance, the response to the second GET includes a
"code", but there is no description of what its semantics are -- is it
secret?  does it contain information about the requester's identity?
is it signed by the auth. server?  Similarly for "master-key" and
"token".

It's not clear to me why the 1st GET request needs a client-side nonce
("state").  The text says that it's to prevent replay attacks, but the
transaction with the auth. server seems to be idempotent.  Or is it
assumed that the auth. server stores exactly one master-key for each
user identity?  (Perhaps this is knowledge that I would have if I
understood OAuth.)  In any case, how the auth. server checks for
replays needs to be detailed.

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

In section 3.6, it seems that "some-request-headers" is intended to be
the same as "digest-string" in section 9 of RFC 4474.  If so, it would
make things clearer to call it "digest-string".

It would help if the authentication processes that are carried out
were specified explicitly.  For instance, when the proxy receives an
authenticated request, all the proxy has to go on is the "pop" value
in the Authorization header, and since it's a hash, it doesn't
explicitly contain the user's identity.  Presumably the Proxy is
supposed to obtain the identity from some other element in the
request, use that identity to look up the recorded master-key, use
that to compute what the "pop" should be, and verify that is correct.

This implies that there is only one or a small number of master-keys
that are valid for any particular user at one time, and that the proxy
has a list of them.

Indeed, as a design question, what information is the proxy required
to know?  In Basic and Digest authentication, it must know all the
user names and passwords.  But it's conceivable that this scheme
delegates all user-level information to the auth. server, and all the
proxy needs to know is how to verify that a token was issued by the
auth. server.  Since this is a major architectural feature, it would
help if this was stated explicitly.

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?

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 28 Jun 2014 06:26:43 -0400

Hi Dale,

Thanks for the detailed review.
Please, see my reply inline...

Regards,
 Rifaat

> bunch of details that could be cleared up in the -01.
I want you be be critical :), because I want to improve this document.
I did mention in my email to the mailing list that the draft is still
missing many details, I just wanted to get the discussion started.

> reliably interpolate what parts of OAuth are to be copied into the
I think the document clearly states that it is trying to define a framework
that is *based* on OAuth 2.0 framework.

> roles weren't a guide to how the protocol worked.)
I am planning on adding more details to this section.

> the final GET be a 200 response, and the UA would still know what to
Paul has already raised this issue on the mailing list, and I agree that
401 would be a valid approach too.

> challenges for different auth. methods could be in others.
The challenge-response mechanism is well-defined and allows different
schemes to be used.
The current proposal uses the Digest scheme, but others could be used.

But for the first REGISTER in the flow in section 3, the 401 should not
include an authenticate header as the proxy is not challenging the request,
only a way to redirect the UA to the authorization server.

> registration, this should be spelled out explicitly as a design
No, the REGISTER request could include a token (See section 5). I will make
sure to clarify this in section 3.

> message sequence needs to be specified (which isn't now).
I do not think that the authorization server should have the control here.
It should be the responsibility of the UA to use the correct outbound proxy.

> to the messages by name in the text.
Ok

> is it signed by the auth. server?  Similarly for "master-key" and
Ok

> replays needs to be detailed.
Good point. The 1st GET does not need to include that; only the 2nd GET.

> authorization for a request.)
This is explained in RFC6749, section 1.3.1.

> make things clearer to call it "digest-string".
Ok.

> that to compute what the "pop" should be, and verify that is correct.
OK

> help if this was stated explicitly.
Ok

> on the "token" value.  What is the token used for?  Or is there a
The token is used to control the various services and the level of service
allowed for the user in possession of the token.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 12:27:19 -0400

On 6/28/14 6:26 AM, Rifaat Shekh-Yusef wrote:

> include an authenticate header as the proxy is not challenging the
> request, only a way to redirect the UA to the authorization server.

Isn't the proxy saying: I refuse your request because I require a 
correct "code"? That seems like a challenge to me.

It just happens to also include hints on where to go to get a code.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 30 Jun 2014 12:59:42 -0400

May be it is my wording that is a bit confusing here.

The server includes the Authenticate header in the challenge to indicate to
the client which scheme it must use to provide user's credentials in the
response.
In this case the server is not expecting the client to provide it with the
user's credentials; instead it is expecting the client to provide the
user's credentials to the authorization server.

So, yes, in this case the proxy is challenging the client, but I do not see
the need to include the Authenticate header in the challenge.

Regards,
 Rifaat

On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat <[email-masked]>
wrote:

> Isn't the proxy saying: I refuse your request because I require a correct
> "code"? That seems like a challenge to me.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 13:12:26 -0400

On 6/30/14 12:59 PM, Rifaat Shekh-Yusef wrote:
> The server includes the Authenticate header in the challenge to indicate
> to the client which scheme it must use to provide user's credentials in
> the response.
> In this case the server is not expecting the client to provide it with
> the user's credentials; instead it is expecting the client to provide
> the user's credentials to the authorization server.

ISTM there are two different credentials:

- an auth code presented by the client to the proxy
- credentials presented to the auth server in order to get an auth code

> So, yes, in this case the proxy is challenging the client, but I do not
> see the need to include the Authenticate header in the challenge.

There needs to be some way for the client to deliver the code to the 
server. The Authorization header, with a new scheme, would be a 
plausible way to do that. The challenge then says that credentials (the 
token) using the new scheme are required.

	Thanks,
	Paul

> Regards,
>   Rifaat
>
>
>
> On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     _________________________________________________
>     sipcore mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 30 Jun 2014 13:39:34 -0400

On Mon, Jun 30, 2014 at 1:12 PM, Paul Kyzivat <[email-masked]> wrote:

> server. The Authorization header, with a new scheme, would be a plausible
> way to do that.

Yes, and that is already described in the draft.

The challenge then says that credentials (the token) using the new scheme
> are required.
>
> What is the benefit of the proxy explicitly stating that in the challenge?

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jun 2014 14:25:53 -0400

I think we are now suffering from not understanding one another, because 
we are too far into hypothetical space.

Could you spin another version that uses sip 401/407? Then we can more 
easily discuss issues of how that works.

	Thanks,
	Paul

On 6/30/14 1:39 PM, Rifaat Shekh-Yusef wrote:
>
>
>
> On Mon, Jun 30, 2014 at 1:12 PM, Paul Kyzivat <[email-masked]
>     plausible way to do that.
>
>
>     The challenge then says that credentials (the token) using the new
>     scheme are required.
>
>         On Mon, Jun 30, 2014 at 12:27 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         wrote:
>
>                       It would be good to know how the first REGISTER
>         response
>                  interoperates
>                       when there are other authentication mechanisms
>         present.
>                    I'd expect a
>                       407 response with suitable Proxy-Authenticate
>         headers; the
>                  grammar
>                       authorization server URL could be returned in one
>         of them,
>                  while
>                  The current proposal uses the Digest scheme, but others
>         could be
>                  used.
>
>                  But for the first REGISTER in the flow in section 3,
>         the 401
>                  should not
>              ___________________________________________________
>              sipcore mailing list
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/____listinfo/sipcore
>         <https://www.ietf.org/mailman/__listinfo/sipcore>
>              <https://www.ietf.org/mailman/__listinfo/sipcore
>         <https://www.ietf.org/mailman/listinfo/sipcore>>
>
>
>
>