Subject: [sipcore] SIP OAuth - v01

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 8 Jul 2014 08:21:42 -0400

Hi,

Sorry, I could not get the draft ready before the submission cut-off time,
so I am attaching version 01 to this email.
With this version I believe that I have addressed *most* of the comments
received so far.
I would appreciate it if you can review and comment on this version.

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Jul 2014 17:36:42 -0400

Rifaat,

Here are an assortment of comments. Some are about specific sections, 
but many are not.

It appears that a fairly detailed understanding of RFC6749 is required 
to understand this draft. I don't have that. It would be good if you 
could provide at least a few basics in this draft, and clearly identify 
the mappings between the pieces you are talking about and those in 6749. 
Based on about 5 minutes browsing 6749 I *think* that the mappings are:
- User Agent = Client
- Proxy = Resource Server
- Authorization Server = Authorization Server (!)
- Resource Owner = ???

And, what is the Resource?

Can you please include a *brief* tutorial as part of your session in 
Toronto?

Also, I see many uses of "token". But 6749 makes a major distinction 
between a "refresh token" and an "access token". I can't tell which is 
meant where. That needs to be clear. I get the impression that 6749 
expects the client to give the resource server an access token, not a 
refresh token. I have the feeling what you are proposing does. But I'm 
not at all sure I understand that right.

I think this needs a more complete positioning relative to existing 
mechanisms. I interpret this to be an alternative to 
draft-yusef-sipcore-digest-scheme. Presumably the encryption used 
throughout this one at least has the potential to be more robust than 
the existing digest authentication. I would expect to see that mentioned 
as a benefit.

When I see OAuth used on the web (at least I think that is what it is), 
I am usually offered multiple authenticators to choose from. E.g., 
Google, Facebook, Disqus, ...

I would think the same would be true here: that the 401 would provide 
these alternatives.

It took me quite awhile before I realized that sections 3, 4 & 5 were 
*alternate* ways of using OAuth. Is it your intent that we would choose 
one? Or do you think we could define them all and implementations would 
choose which to use. Wouldn't that cause interop problems? Also, ISTM 
that the benefits differ for these three alternatives, and so should be 
described separately for each.

Section 3.2:

F6 is an HTTP 302. Why? And where would it send us? I gather you are 
just ignoring it.

(When OAuth is used with with web servers, a web server takes the place 
of the proxy, and I infer from your -00 version that it would return a 
302 to the auth server. And then the auth server eventually returns a 
302 to get back to the original web server. But how does the auth server 
know to do that, and what URL to put in the 302?  ISTM it must be told, 
either by an interaction between the web server and the auth server, or 
by embedding a URL for the web server into the url of the auth server. 
Whatever this mechanism is, perhaps it needs to be reconsidered, 
repurposed for sip.)

Section 3.6 (Token Refresh):

How often must the token be refreshed? Does it have an expiration time?
Suppose the token expires before the registration binding expires? I 
guess it would make sense for the registrar to refresh before that 
happens. If it can't refresh, and the token expires, what should the 
registrar do with the binding?

Perhaps the registrar should take the expiration time of the token into 
account when deciding on the expiration time of the binding - ensuring 
that the binding expires first. Then the registrar will never need to 
refresh the token - the user agent will do so before refreshing the 
registration.

Section 4.3:

Hmm - this of course doesn't serve as a fix for the weakness of the 
encryption with digest.

How is this advantageous compared to simply using digest?

Section 5.2:

How would the UA know to get a token before attempting to register? The 
need for a token depends on the registrar wanting one. I would expect 
that this need would be indicated by a 401 response to REGISTER.

Here again I am confused by the mapping from the shown components to the 
OAuth components.

Bottom line:

I think there is a lot of promise here. But it is still very confusing 
(to me). You need to iterate and refine until you get a number of people 
who understand the proposal.

I look forward to having a lively discussion in Toronto. Please make a 
presentation that will will facilitate such a discussion. I am happy to 
review slides in advance of the meeting.

	Thanks,
	Paul

On 7/8/14 8:21 AM, Rifaat Shekh-Yusef wrote:
> Hi,
>
> Sorry, I could not get the draft ready before the submission cut-off
> time, so I am attaching version 01 to this email.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 9 Jul 2014 08:38:42 -0400

Thanks Paul!

Please, see my reply inline...

Regards,
 Rifaat

On Tue, Jul 8, 2014 at 5:36 PM, Paul Kyzivat <[email-masked]> wrote:

> Rifaat,
>
> Here are an assortment of comments. Some are about specific sections, but
> many are not.
>
> It appears that a fairly detailed understanding of RFC6749 is required to
> understand this draft.

It would definitely help :)

> I don't have that. It would be good if you could provide at least a few
> basics in this draft, and clearly identify the mappings between the pieces
> you are talking about and those in 6749. Based on about 5 minutes browsing
> 6749 I *think* that the mappings are:
> - User Agent = Client
In the first version of the draft I did include a section that tried to map
OAuth roles to SIP, but it seems that it confused people, so I removed it
from this version.
The goal of this draft is not to shoehorn SIP into the model defined in
RFC6749, but to build a framework based on the ideas specified in RFC6749.
For that reason I think that we should not try to map SIP roles into the
OAuth roles.

> And, what is the Resource?
In the context of RFC6749, this would be something that the user owns, like
a photo on some Website.

> Can you please include a *brief* tutorial as part of your session in
Sure. I could talk about one grant type.

> meant where. That needs to be clear. I get the impression that 6749 expects
> the client to give the resource server an access token, not a refresh
> token. I have the feeling what you are proposing does. But I'm not at all
> sure I understand that right.
>
>
Ok. When I used token by itself, I meant access token. I will make it
explicit.

> throughout this one at least has the potential to be more robust than the
> existing digest authentication. I would expect to see that mentioned as a
> benefit.
>
>
Not exactly. The draft is still using Digest to authenticate the user to
the Authorization Server.
The difference is that in this case the Digest is used only to get the
code/token, and not with every request sent to the server.

I have been discussing other possible solutions to replace Digest on the
Crypto Forum Research Group (CFRG) mailing list and I have a short
presentation about that during the Toronto meeting.
Will see how that goes, and then come up with a proposal for SIP based on
that discussion.

> When I see OAuth used on the web (at least I think that is what it is), I
> am usually offered multiple authenticators to choose from. E.g., Google,
> Facebook, Disqus, ...
>
That depends on the proxy and the established trust with the various
Authorization Servers.

> one?

No.

> Or do you think we could define them all and implementations would choose
> which to use.

We need to define them all, because they address different use cases. I
tried to capture the potential use of each one in the Usage sections.

> Wouldn't that cause interop problems?

> Also, ISTM that the benefits differ for these three alternatives, and so
> should be described separately for each.
>
>
Ok.

> Section 3.2:
>
> F6 is an HTTP 302. Why? And where would it send us? I gather you are just
> ignoring it.
>
>
The initial proposal was to use redirection to get to the Authorization
Server and then back to the Proxy.
Since we changed F2 from 302 to 401, we need to change this one too; it
should be just 200 OK. The UA knows its outbound proxies and does not need
the help of the Authorization Server.

(When OAuth is used with with web servers, a web server takes the place of
> the proxy, and I infer from your -00 version that it would return a 302 to
> the auth server. And then the auth server eventually returns a 302 to get
> back to the original web server. But how does the auth server know to do
> that, and what URL to put in the 302?  ISTM it must be told, either by an
> interaction between the web server and the auth server, or by embedding a
> URL for the web server into the url of the auth server. Whatever this
> mechanism is, perhaps it needs to be reconsidered, repurposed for sip.)
>
>

> How often must the token be refreshed? Does it have an expiration time?

Yes, tokens have expiration time.

> Suppose the token expires before the registration binding expires? I guess
> it would make sense for the registrar to refresh before that happens. If it
> can't refresh, and the token expires, what should the registrar do with the
> binding?
>
>
Good question.

> account when deciding on the expiration time of the binding - ensuring that
> the binding expires first. Then the registrar will never need to refresh
> the token - the user agent will do so before refreshing the registration.
>
>
I need to think about that.

> How is this advantageous compared to simply using digest?
The advantage is that the 4 messages of the challenge-response will be used
once during registration, but all subsequent requests will not be
challenged as long as the UA is in possession of a valid token.
Another advantage is that an access token would allow you access to
different services based on the scope of the token.

> need for a token depends on the registrar wanting one. I would expect that
> this need would be indicated by a 401 response to REGISTER.
>
>
This section is still under construction and has some initial thoughts that
need to be developed further.
The use case I am trying to address here is where a UA is able to obtain a
token using some out-of-band interface before attempting to connect to the
SIP proxy.
I need more time to develop and expand this section to make it clear.

> I think there is a lot of promise here. But it is still very confusing (to
> me). You need to iterate and refine until you get a number of people who
> understand the proposal.
>
>
Agree.

> review slides in advance of the meeting.
Sure.

Regards,
 Rifaat

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 9 Jul 2014 10:47:06 -0400

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

> For that reason I think that we should not try to map SIP roles into the

IMO, it is very important to make this sort of conceptual relationship
clear to the reader, because (in most cases) the reader absorbs a
conceptual framework very quickly, and interprets all of the details
within the framework.  So it's important to state up front something

> RFC6749, but to build a framework based on the ideas specified in RFC6749.

Given that warning, you could then list the analogy (and differences)
between the roles of the SIP entities and the OAuth entities.  (Though
if you do list the OAuth role names, warn the user if/where they are
not comparable to ordinary usage.)

But of course, once you've stated that this isn't (strictly speaking)
"applying OAuth to SIP", you have to lay out all of the details very
explicitly, because the reader can't interpolate anything that is
unsaid "because that's the way OAuth does it".

> In the context of RFC6749, this would be something that the user owns, like

But of course, this isn't the context of RFC 6749.  As far as I can
tell, the Resource is something that the user (that is, the caller)
wants to *access* using SIP.

Which leads me to a matter that I found confusing in the OAuth
description:  There are two *users*, the one that *owns* the resource
(has administrative control over who may access it) and the one that
wants to *access* the resource.  If I remember correctly (and I may
not), OAuth uses the term Resource Owner for the *latter* role and has
no explicit name for the former role.  If I'm correct, this is likely
to be a major point of confusion in your system, and you need to take
pains to make the use of the terminology explicit, lest people like me
get confused.

> Ok. When I used token by itself, I meant access token. I will make it

One thing to avoid if possible is using more than one word or phrase
to describe one single type of thing.  The reader often wonders
whether he has correctly interpreted a phrase.  One way to reduce this
problem is to have a Lexicon section and to add an entry for every
special-purpose word or phrase that you introduce.  Then, in the text,
verify that every special-purpose word or phrase you use is in the
lexicon in exactly the same form.  Then the readers can be sure they
read the text correctly.

Beware that you understand the subject well and we don't understand it
at all...

Dale