Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-10.txt

From: [email-masked]
Date: Sat, 07 Mar 2020 13:37:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)
        Authors         : Rifaat Shekh-Yusef
                          Christer Holmberg
                          Victor Pascual
	Filename        : draft-ietf-sipcore-sip-token-authnz-10.txt
	Pages           : 14
	Date            : 2020-03-07

Abstract:
   This document defines the "Bearer" authentication scheme for the
   Session Initiation Protocol (SIP), and a mechanism by which user
   authentication and SIP registration authorization is delegated to a
   third party, using the OAuth 2.0 framework and OpenID Connect Core
   1.0.  This document updates RFC 3261 to provide guidance on how a SIP
   User Agent Client (UAC) responds to a SIP 401/407 response that
   contains multiple WWW-Authenticate/Proxy-Authenticate header fields.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-10
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 7 Mar 2020 16:40:43 -0500

All,

This new version addresses the latest comment from Paul regarding the token
representations.
Please, take a look and let us know if you have any further comments.

Regards,
 Rifaat

On Sat, Mar 7, 2020 at 4:37 PM <[email-masked]> wrote:

>         Title           : Third-Party Token-based Authentication and
> Authorization for Session Initiation Protocol (SIP)
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 7 Mar 2020 21:48:07 -0500

Rifaat,

On 3/7/20 4:40 PM, Rifaat Shekh-Yusef wrote:
> All,
> 
> This new version addresses the latest comment from Paul regarding the 
> token representations.

This helps. I still find the various uses of "token" confusing in a way 
I suspect is unnecessary. Part of this may be a matter of OAUTH having 
much more machinery that we ought to need to understand for this draft. 
It would be nice if this draft were understandable without knowing about 
  irrelevant parts of OAUTH.

I think I now understand that for the most part this document is only 
concerned with access tokens, and that it generally doesn't matter 
whether they are structured or reference. There seem to be some limited 
sections where you need to talk about refresh tokens as being needed to 
refresh a stale access token. And similarly there is a limited need to 
distinguish between structured and reference tokens when discussing 
security considerations. (In this last update you also added a reference 
to ID tokens. IIUC we shouldn't need to know about them at all.)

I appreciate that you are deeply familiar with the details of OAUTH to 
the extent that you can't appreciate how confusing this can be to those 
of us who aren't. hence this becomes frustrating for both of us.

I think it would be good to hear what others have to say before deciding 
what (if any) other changes should be made.

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> On Sat, Mar 7, 2020 at 4:37 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>              Title           : Third-Party Token-based Authentication
>     and Authorization for Session Initiation Protocol (SIP)
>     https://datatracker.ietf..org/doc/html/draft-ietf-sipcore-sip-token-authnz-10
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-10>
> 
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 8 Mar 2020 07:51:11 -0400

Hi Paul,

I completely understand, and I would happy to try to make it clearer.
I believe your reviews and question made this document a much better
document than it was initially, and I would be happy to continue to do that
if needed.
The goal is to publish a document that would be useful to the wider
community as much as possible.

I will try to go over the document again, and see if I can make it clearer.

I agree that it would be great if we can get more people to review the
document and provide feedback.

Regards,
 Rifaat

On Sat, Mar 7, 2020 at 9:48 PM Paul Kyzivat <[email-masked]> wrote:

> >     https://datatracker.ietf.
> .org/doc/html/draft-ietf-sipcore-sip-token-authnz-10
> >     <

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 13 Mar 2020 12:07:55 -0400

Paul,

I went through the document again, and to me it seems clear what we meant
we mention a token, but I probably am way too close to see the issues that
you might be seeing.
Do you have some specific issue that you think we could try to clarify?

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Mar 2020 19:28:28 +0000

Paul, could you please provide the input that is requested, so that we can try to move the draft forward.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Friday, 13 March 2020 at 18.08
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-10.txt

Paul,

I went through the document again, and to me it seems clear what we meant we mention a token, but I probably am way too close to see the issues that you might be seeing.
Do you have some specific issue that you think we could try to clarify?

Regards,
 Rifaat

On Sat, Mar 7, 2020 at 9:48 PM Paul Kyzivat <[email-masked]<mailto:pkyzivat@alum..mit.edu>> wrote:
Rifaat,

        Thanks,
        Paul

> Regards,
>   Rifaat
>
>
> On Sat, Mar 7, 2020 at 4:37 PM <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>
>     until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>
>     <http://tools.ietf.org>.
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

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

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Sun, 22 Mar 2020 12:49:22 -0500

Hi all,

Would the following text help?

Current:

1.3.  Token Formats

    Tokens can be represented in two different formats:

    *  Structured Token: a token that consists of a structured object
       that contains the claims associated with the token, e.g.  JWT as
       defined in [RFC7519].

    *  Reference Token: a token that consists of a random string that is
       used to obtain the details of the token and its associated claims,
       as defined in [RFC6749].

    Access Tokens could be represnetd in one of the above two formats.
    Refresh Tokens usualy are represented in a reference format, as this
    token is consumed only the AS that issued the token.  ID Token is
    defined as a structured token in the form of a JWT.

Proposed:

1.3 Token Types and Formats

    The tokens used in third-party authorization depend on the type of
    authorization server (AS).

    An OAuth authorization server provides the following tokens to
    a successfully authorized UAC:

    *  Access token: the UAC will use this token to gain access
       to services by providing the token to a SIP server.

    *  Refresh token: the UAC will present this token to the AS
       to refresh a stale access token.

    An OpenID Connect server returns an additional token:

    *  ID Token: this token contains the SIP URI and other
       user-specific details that will be consumed by the UAC.

    Tokens can be represented in two different formats:

    *  Structured token: a token that consists of a structured object
       that contains the claims associated with the token, e.g.,
       JSON Web Token (JWT) defined in [RFC7519].

    *  Reference token: a token that consists of a random string that is
       used to obtain the details of the token and its associated claims,
       as defined in [RFC6749].

    Access tokens can be represented in one of the above two formats.
    Refresh tokens usually are represented in a reference format, as this
    token is consumed only the AS that issued the token.  The ID Token is
    defined as a structured token in the form of a JWT.

Thanks,

Jean

On 3/13/20 11:07 AM, Rifaat Shekh-Yusef wrote:
> Paul,
> 
> I went through the document again, and to me it seems clear what we 
> meant we mention a token, but I probably am way too close to see the 
> issues that you might be seeing.
>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >     A New Internet-Draft is available from the on-line
>     Internet-Drafts
>      >     directories.
>      >     This draft is a work item of the Session Initiation Protocol
>     Core WG
>      >     of the IETF.
>      >
>      >              Filename        :
>     draft-ietf-sipcore-sip-token-authnz-10.txt
>      >              Pages           : 14
>      >              Date            : 2020-03-07
>      >
>      >     Abstract:
>      >         1.0.  This document updates RFC 3261 to provide guidance
>     on how
>      >     a SIP
>      >     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>
>      >     <http://tools.ietf.org>.
>      >
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 22 Mar 2020 15:58:01 -0400

Thanks Jean!

This looks good to me.

*Paul,*

Does this help address your issue with the current text in the document?

Regards,
 Rifaat

On Sun, Mar 22, 2020 at 1:49 PM A. Jean Mahoney <[email-masked]> wrote:

> >      >     Please note that it may take a couple of minutes from the
> time of
> >      >     submission

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Mar 2020 15:58:15 -0400

Jean,

Comments inline.

>     defined as a structured token in the form of a JWT.

This is getting much better.

I think a lot of the problem is that OAuth has been sloppy in choosing 
their terminology.

IIUC there are many varieties of token, varying in at least two dimensions:

- Purpose: Access, Refresh, ID

- Format: Structured, Reference

But it seems that the nomenclature is using "(prefix) Token" to describe 
both. So when referring to "Access Token" it is unspecified whether it 
is Structured or Reference, and when referring to "Reference Token" it 
is unspecified whether it is Access, Refresh, or ID.

In many cases this may be clear from context once all this is clear to 
the reader. But maybe there is room to be more explicit, such as: 
Structured Access Token, or even (Structured or Reference) Access Token.

I've been staring at, and commenting on, this for so long that I no 
longer think I can objectively see what is necessary to make the text clear.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Mar 2020 20:55:36 +0000

Hi,

I am fine with Jean’s suggestion too.

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Sunday, 22 March 2020 at 21.58
To: "A. Mahoney" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-10.txt

Thanks Jean!

This looks good to me..

Paul,

Regards,
 Rifaat

On Sun, Mar 22, 2020 at 1:49 PM A. Jean Mahoney <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Current:

1.3.  Token Formats

Proposed:

Thanks,

Jean

On 3/13/20 11:07 AM, Rifaat Shekh-Yusef wrote:
> On Sat, Mar 7, 2020 at 9:48 PM Paul Kyzivat <[email-masked]<mailto:[email-masked]>
> <mailto:pkyzivat@alum.<mailto:pkyzivat@alum.>.mit.edu<http://mit.edu>>> wrote:
>
>     Rifaat,
>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      > <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >
>      >
>     tools.ietf.org<http://tools.ietf.org> <http://tools.ietf.org>
>      >     <http://tools.ietf.org>.
>      >
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Mar 2020 21:33:17 +0000

Hi,

...

    > Structured Access Token, or even (Structured or Reference) Access Token

If it, for what we are describing, does not matter whether an access token is Structured or Reference, there is no need to be explicit.

For example, when we talk about sending SIP requests, we don't explicitly say whether they are sent over UDP or TCP - unless what we are describing is specific to UDP or TCP transport.

Regards,

Christer