Subject: [sipcore] SIP OAuth: Information element to carry token

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Jun 2014 16:33:30 +0000

Hi,

I was taking a look at draft-yusef-sipcore-sip-oauth-00.

In section 4, I see that the OAuth token is carried in a message body. Is there a reason why one could not use  the SIP Authorization header field?

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 12 Jun 2014 12:57:51 -0400

Hi Christer,

I tried to keep this proposal aligned with approach taken by RFC6749, but I
think that using Authorization header would be a valid option too.
Is there any reason that you prefer it to be carried in the Authorization
header instead of the message body?

Regards,
 Rifaat

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg <
[email-masked]> wrote:

> In section 4, I see that the OAuth token is carried in a message body. Is
> there a reason why one could not use  the SIP Authorization header field?
>
> Regards,
>
> Christer
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Jun 2014 18:03:34 +0000

Hi,

>I tried to keep this proposal aligned with approach taken by RFC6749, but I think that using >Authorization header would be a valid option too.
>Is there any reason that you prefer it to be carried in the Authorization header instead of the message >body?

I was just thinking it would be more alligned with other mechanisms used in SIP.

Also, using a message body for this purpose seems a little "overkill" in my opinion.

Regards,

Christer

On Thu, Jun 12, 2014 at 12:33 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 13 Jun 2014 06:23:34 +0000

Hello,

I share the same view as Christer.

New authentication schemes should preferably extend / re-use the headers defined for authentication (i.e. WWW-Authenticate, Authorization, Authentication-Info, Proxy-Authenticate, Proxy-Authorization).

This would enable usage of the OAuth method in any protocol which uses those headers.

This would enable usage of the OAuth method in (a) authentication with proxy and (b) authentication with server.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: sipcore [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: 12. června 2014 18:58
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] SIP OAuth: Information element to carry token

Hi Christer,

I tried to keep this proposal aligned with approach taken by RFC6749, but I think that using Authorization header would be a valid option too.
Is there any reason that you prefer it to be carried in the Authorization header instead of the message body?

Regards,
 Rifaat

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 13 Jun 2014 08:18:06 -0400

I am fine with this; I will make the change in the next version of the
draft.

Regards,
 Rifaat

On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <[email-masked]>
wrote:

> New authentication schemes should preferably extend / re-use the headers
> defined for authentication (i.e. WWW-Authenticate, Authorization,
> Authentication-Info, Proxy-Authenticate, Proxy-Authorization).
>
>
>
> This would enable usage of the OAuth method in (a) authentication with
> proxy and (b) authentication with server.
>
>
>
> Kind regards
>
>
>
> Ivo Sedlacek
>
>
>
> This Communication is Confidential. We only send and receive email on the
> basis of the terms set out at www.ericsson.com/email_disclaimer
>
> *From:* sipcore [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* 12. června 2014 18:58
> *To:* Christer Holmberg
> *Cc:* [email-masked]
> *Subject:* Re: [sipcore] SIP OAuth: Information element to carry token
>
>
>
> Hi Christer,
>
>
>
> I tried to keep this proposal aligned with approach taken by RFC6749, but
> I think that using Authorization header would be a valid option too.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 13 Jun 2014 16:48:14 +0000

Well, the Authorization header field is defined in RFC2617, and the base SIP specification instructs implementers to use its syntax. In other words, these headers don't belong to us. The syntax and semantics of OAuth is nothing like them. I don't think it's reasonable for us to just overload the syntax and semantics of the HTTP authentication system in this way for SIP.  Nor is it that case that by doing so in SIP, we will allow "any protocol that uses these headers" to use OAuth - that's exactly backwards. What we'd be doing is creating fragmentation and confusion.

Our OAuth usage should be aligned with HTTP's usage, that is, with RFC6749. If we want something different, I think we need to talk to them about it.

Jon Peterson
Neustar, Inc.

From: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 13, 2014 at 5:18 AM
To: Ivo Sedlacek <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP OAuth: Information element to carry token

I am fine with this; I will make the change in the next version of the draft.

Regards,
 Rifaat

On Fri, Jun 13, 2014 at 2:23 AM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<https://urldefense.proofpoint.com/v1/url?u=http://www.ericsson.com/email_disclaimer&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B31F1WQyjSQmLQXwHuHE%3D%0A&m=tSZkokp7MD%2Bv2nBl0fcdUmQy3ahvGiSxOhZdyfyIedM%3D%0A&s=e5ef8d03eab1d1868332e155a7a578a2a94bb90a292d983b2476f1519a535bb7>

Hi Christer,

Regards,
 Rifaat

Regards,

Christer

_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore<https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/sipcore&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B31F1WQyjSQmLQXwHuHE%3D%0A&m=tSZkokp7MD%2Bv2nBl0fcdUmQy3ahvGiSxOhZdyfyIedM%3D%0A&s=5618516c526050b7677bc2750637f8d88fdbd1f0b69c2d73e7cbe65a485b2227>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 13 Jun 2014 13:44:54 -0400

Hi Jon,

Yeah, that was my initial reaction to this request, as my intention was to
keep this document aligned with RFC6749.
Personally, I prefer to keep it aligned with RFC6749, but I can kind of see
the argument of using an existing mechanism to keep it aligned with SIP in
this specific case.

The challenge-response mechanism defined in RFC2617 is now obsolete; it is
now defined in RFC7235.
The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the
process of doing the same for the Digest Scheme.

The flow in section 4 carries the token in the 200 OK; one possible way to
carry that in SIP is to use the Authentication-Info, which is *not* part of
the challenge-response framework defined in RFC7235.
The Authentication-Info is defined in the above Digest draft, which we
could make sure that it is extendible (I just noticed that it is not extendible
in the current version but I can fix that in the next version of the Digest
draft).
That would allow us to extend it for SIP, if that is what we want to do.

I do not have strong opinion on this one; I can go either way.

Regards,
 Rifaat

On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon <[email-masked]>
wrote:

>
>  Well, the Authorization header field is defined in RFC2617, and the base
> SIP specification instructs implementers to use its syntax. In other words,
> these headers don't belong to us. The syntax and semantics of OAuth is
> nothing like them. I don't think it's reasonable for us to just overload
> the syntax and semantics of the HTTP authentication system in this way for
> SIP.  Nor is it that case that by doing so in SIP, we will allow "any
> protocol that uses these headers" to use OAuth - that's exactly backwards.
> What we'd be doing is creating fragmentation and confusion.
>
>  Our OAuth usage should be aligned with HTTP's usage, that is, with
> RFC6749. If we want something different, I think we need to talk to them
> about it.
>
>  Jon Peterson
> Neustar, Inc.
>
>   From: Rifaat Shekh-Yusef <[email-masked]>
> To: Ivo Sedlacek <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
>> <https://urldefense.proofpoint.com/v1/url?u=http://www.ericsson.com/email_disclaimer&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B31F1WQyjSQmLQXwHuHE%3D%0A&m=tSZkokp7MD%2Bv2nBl0fcdUmQy3ahvGiSxOhZdyfyIedM%3D%0A&s=e5ef8d03eab1d1868332e155a7a578a2a94bb90a292d983b2476f1519a535bb7>
>>
>> <https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/sipcore&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B31F1WQyjSQmLQXwHuHE%3D%0A&m=tSZkokp7MD%2Bv2nBl0fcdUmQy3ahvGiSxOhZdyfyIedM%3D%0A&s=5618516c526050b7677bc2750637f8d88fdbd1f0b69c2d73e7cbe65a485b2227>
>>
>>
>>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Jun 2014 08:32:18 +0000

Hi,

My initial question was why existing SIP header fields weren't used. IF there are good reasons (e.g. based on Jon's input) I think it would be useful to document those in the draft.

Regards,

Christer

________________________________
From: sipcore [[email-masked]] on behalf of Rifaat Shekh-Yusef [[email-masked]]
Sent: Friday, 13 June 2014 8:44 PM
To: Peterson, Jon
Cc: [email-masked]; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token

Hi Jon,

Yeah, that was my initial reaction to this request, as my intention was to keep this document aligned with RFC6749.
Personally, I prefer to keep it aligned with RFC6749, but I can kind of see the argument of using an existing mechanism to keep it aligned with SIP in this specific case.

The challenge-response mechanism defined in RFC2617 is now obsolete; it is now defined in RFC7235.
The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in the process of doing the same for the Digest Scheme.

The flow in section 4 carries the token in the 200 OK; one possible way to carry that in SIP is to use the Authentication-Info, which is not part of the challenge-response framework defined in RFC7235.
The Authentication-Info is defined in the above Digest draft, which we could make sure that it is extendible (I just noticed that it is not extendible in the current version but I can fix that in the next version of the Digest draft).
That would allow us to extend it for SIP, if that is what we want to do.

Regards,
 Rifaat

On Fri, Jun 13, 2014 at 12:48 PM, Peterson, Jon <[email-masked]<mailto:[email-masked]>> wrote:

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

Kind regards

Ivo Sedlacek

Hi Christer,

Regards,
 Rifaat

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 15 Jun 2014 20:02:34 +0000

I suspect there are two steps to this question.

1)    Given that there are some differences between HTTP and SIP, would it be more appropriate to use a header field rather than a message body?

2)    If a header field is used, should it be an extension of an existing header field or a new one?

regards

Keith

________________________________
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 14 June 2014 09:32
To: Rifaat Shekh-Yusef; Peterson, Jon
Cc: [email-masked]; Ivo Sedlacek
Subject: Re: [sipcore] SIP OAuth: Information element to carry token

Hi,

Regards,

Christer

Hi Jon,

Regards,
 Rifaat

Jon Peterson
Neustar, Inc.

Regards,
 Rifaat

Kind regards

Ivo Sedlacek

Hi Christer,

Regards,
 Rifaat

Regards,

Christer

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 16 Jun 2014 08:39:05 -0400

Thanks Keith,

Where do you stand on these two questions?

Regards,
 Rifaat

On Sun, Jun 15, 2014 at 4:02 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> 1)    Given that there are some differences between HTTP and SIP, would it
> be more appropriate to use a header field rather than a message body?
>
>  ------------------------------
> *From:* sipcore [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 14 June 2014 09:32
> *To:* Rifaat Shekh-Yusef; Peterson, Jon
>
> *Cc:* [email-masked]; Ivo Sedlacek
> My initial question was why existing SIP header fields weren't used.
> IF there are good reasons (e.g. based on Jon's input) I think it would be
> useful to document those in the draft.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>  ------------------------------
> *From:* sipcore [[email-masked]] on behalf of Rifaat
> Shekh-Yusef [[email-masked]]
> *Sent:* Friday, 13 June 2014 8:44 PM
> *To:* Peterson, Jon
> *Cc:* [email-masked]; Ivo Sedlacek
>  Yeah, that was my initial reaction to this request, as my intention was
> to keep this document aligned with RFC6749.
> Personally, I prefer to keep it aligned with RFC6749, but I can kind of
> see the argument of using an existing mechanism to keep it aligned with SIP
> in this specific case.
>
> The https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ is in
> the process of doing the same for the Digest Scheme.
>
>  The flow in section 4 carries the token in the 200 OK; one possible way
> to carry that in SIP is to use the Authentication-Info, which is *not*
> part of the challenge-response framework defined in RFC7235.
>>  Well, the Authorization header field is defined in RFC2617, and the
>> base SIP specification instructs implementers to use its syntax. In other
>> words, these headers don't belong to us. The syntax and semantics of OAuth
>> is nothing like them. I don't think it's reasonable for us to just overload
>>> This Communication is Confidential. We only send and receive email on
>>> the basis of the terms set out at www.ericsson.com/email_disclaimer
>>> I tried to keep this proposal aligned with approach taken by RFC6749,
>>> but I think that using Authorization header would be a valid option too.
>>>
>>> Is there any reason that you prefer it to be carried in the
>>> Authorization header instead of the message body?
>>>
>>>
>>>
>>> Regards,
>>>
>>>  Rifaat
>>>
>>>
>>>
>>>
>>>
>>> In section 4, I see that the OAuth token is carried in a message body.
>>> Is there a reason why one could not use  the SIP Authorization header field?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 20 Jun 2014 18:12:16 -0400

Perhaps it's because I've not read the draft closely enough, but it
seems like there isn't a statement of:

- What precisely is the mechanism intended to achieve?  

- How does it relate to OAuth itself?

As far as I can tell from the OAuth documents, OAuth is to permit a
"client" (a third-party application) to access a protected resource on
a "resource server" without requiring the ultimate "user" (on whose
behalf the client is operating) to give the client a copy of the
user's credentials.

But while the SIP proxy is designated as having the "resource server"
role, it's not clear to me who the OAuth "client" is.  Is it the same
as the SIP client?  (If so, then why bother with the OAuth overhead,
as the "client" then *always* knows the user's credentials?)

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 21 Jun 2014 07:33:12 -0400

Hi Dale,

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

Regards,
 Rifaat

> - What precisely is the mechanism intended to achieve?
I touched on this in the introduction section:

   This document defines a new authorization mechanism for SIP that is
   based on the OAuth 2.0 protocol. The new mechanism allows the proxy
   to avoid challenging every request from the client. The use of tokens
   is a Single Sing-On enabler, which allows for the definition of fine
   grained scopes that could be used by proxies and application servers
   to authorize clients to perform certain actions of behalf of the user
   but not others.

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

> as the "client" then *always* knows the user's credentials?)
The Resource Server could be an outbound proxy or an application server
that provides some service.
The Client could be the SIP UA or the outbound proxy trying to get access
to some application server.

While in the case when the UA is the Client, the UA will have access to the
credentials, the new mechanism has the following benefits:
1. The proxy does not have to challenge every request from the UA
2. The token could be used by the system to control access to other
services, and to control the level of service provided by an application.

I will try to spin a new draft and include more details about the use cases
and the benefits of this mechanism.

Regards,
 Rifaat