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

From: [email-masked]
Date: Mon, 24 Jun 2019 09:54:34 -0700

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-01.txt
	Pages           : 11
	Date            : 2019-06-24

Abstract:
   This document defines a mechanism for SIP, that is based on the OAuth
   2.0 and OpenID Connect Core 1.0 specifications, to enable the
   delegation of the user authentication and SIP registration
   authorization to a dedicated third-party entity that is separate from
   the SIP network elements that provide the SIP service.

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-01
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-01

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

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: Mon, 24 Jun 2019 12:58:08 -0400

All,

We have submitted a new version of the draft that adds more details and we
believe address the comments provided so far.
Please, take a look and let us know what you think.

Regards,
 Rifaat

On Mon, Jun 24, 2019 at 12:55 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: Mon, 24 Jun 2019 16:37:27 -0400

On 6/24/19 12:58 PM, Rifaat Shekh-Yusef wrote:
> All,
> 
> We have submitted a new version of the draft that adds more details and 
> we believe address the comments provided so far.

I think this still has things a bit backwards. Step [07] in 2.1.2 seems 
out of place. Why would the UA know to prompt the user at this point, 
and if it did, how would the user know *which* credentials to provide.

With Digest, you would never prompt for credentials until you have 
received a 401 with WWW-Authenticate. The Realm in that is then 
displayed to the user as indication of which credentials he should supply.

I would expect something similar with Bearer. Presumably this will tell 
me "Google", or "Facebook", or whatever. In your case these may be 
alternatives that the user can choose among. So I think you need more 
explanation about how the alternatives are presented. Don't just pass 
the buck to 3261 on the WWW-Authenticate parameters. You have ones that 
aren't mentioned there, and the usage is probably somewhat different.

After this has been done once, the UA can then cache the credentials for 
while and preemptively supply them in future registration requests. With 
Digest there are some guidelines on when to preemptively try them and 
when not. I would expect something similar for Bearer. There are 
probably some security reasons not to preemptively send the credentials 
to every server the UA attempts to connect to. As long as credentials 
are only being used for REGISTER this probably isn't a problem. But it 
certainly is possible for server to request credentials for requests 
other than REGISTER. I'd like to see a discussion of that too.

	Thanks,
	Paul

> Regards,
>   Rifaat
> 
> 
> On Mon, Jun 24, 2019 at 12:55 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-01
>     <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-01>
> 
>     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: Tue, 25 Jun 2019 09:05:46 -0400

Thanks Paul!

Please, see my replies inline.

Regards,
 Rifaat

On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat <[email-masked]> wrote:

> Yeah, this was a copy and paste from the previous flow.
I agree that the prompt should happen after the 401 response. I will fix
that.

> aren't mentioned there, and the usage is probably somewhat different.
The UA gets redirected to an *Authorization Server (AS)*, which could in
theory redirect the UA to an *IdP *server to authenticate the user.
But, this is completely out of scope for this document, as this follows a
well-defined HTTP-based OAuth mechanism.

> other than REGISTER. I'd like to see a discussion of that too.
The UA never sends any credentials to the registrar, only to the AS/IdP.
The UA will only send the *Access Token *to the registrar which will be
able to validate that the token was issued by a trusted AS.

Regards,
 Rifaat

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2019 10:47:36 -0400

On 6/25/19 9:05 AM, Rifaat Shekh-Yusef wrote:
> On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Thx

> But, this is completely out of scope for this document, as this follows 
> a well-defined HTTP-based OAuth mechanism.

OK, as long as it somehow takes account of the server that requires 
authentication and the type(s) of authentication it is willing to 
accept. You can't rely on the UAC being psychic about what credentials 
are required.

> able to validate that the token was issued by a trusted AS.

That is details. What the UA provides to the registrar are credentials 
in a functional sense, even if they are passed in an indirect way. It 
still requires a security analysis, though the conclusions might be 
somewhat different. I *guess* that it is still a bad idea to hand out 
the access token indiscriminately to everyone you connect to.

	Thanks,
	Paul

>     <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-01.txt
>      >              Pages           : 11
>      >              Date            : 2019-06-24
>      >
>      >     Abstract:
>      >         This document defines a mechanism for SIP, that is based
>     on the
>      >     OAuth
>      >         authorization to a dedicated third-party entity that is
>     separate
>      >     from
>      >     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: Tue, 25 Jun 2019 13:32:04 -0400

> accept. You can't rely on the UAC being psychic about what credentials
Notice that the challenge provided in the WWW-Authenticate response,
defined in section 3, includes many details that could be used by the UAC
to prompt the user for the right credentials.
Is there anything missing that should be added to help the UAC?

> in a functional sense, even if they are passed in an indirect way.

Fair enough

> It still requires a security analysis, though the conclusions might be
> Yeah, this will be covered by the security consideration section.
In general, the UAC must always make sure that it is communicating with the
right registrar using TLS and proper validation of the server certificate
and the identity in that certificate.

Regards,
 Rifaat

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jun 2019 19:04:33 +0000

Hi,

...

> In general, the UAC must always make sure that it is communicating with the right registrar using TLS and proper validation of the server certificate and the identity in that certificate.

Correct.

And,  when it comes to the SIP signaling, I think this is similar to other cases where you send sensitive information: if you communicate with untrusted entities you need to make sure that the information is protected (encrypted).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2019 17:01:32 -0400

Inline...

On 6/25/19 1:32 PM, Rifaat Shekh-Yusef wrote:
> 
> 
> On Tue, Jun 25, 2019 at 10:47 AM Paul Kyzivat <[email-masked] 
>      > On Mon, Jun 24, 2019 at 4:37 PM Paul Kyzivat
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >      > All,
>      >      >
>      >      > We have submitted a new version of the draft that adds more
>      >     details and
>      >      > we believe address the comments provided so far.
>      >      > Please, take a look and let us know what you think.
>      >
>      >     displayed to the user as indication of which credentials he
>     should
>      >     supply.
>      >
> defined in section 3, includes many details that could be used by the 
> UAC to prompt the user for the right credentials.

Yes, there is quite a bit, and scant information about what the 
significance is of each bit of it. IMO some explanation is needed of 
these items and how they are expected to be used. And a more fleshed out 
example that shows who puts up the UI to gather the needed info, what is 
included in the prompt, what comes back, and what is done with it then. 
Enough to relate it to real world experience.

(AFAIK most real world experience is with web interfaces. For instance 
when hitting restricted web sites that require a login from Google, 
Facebook, Discus, etc. IIUC this could be much like that, including the 
choice of which of those to use. So a use case like that would be great.

>      >     After this has been done once, the UA can then cache the
>     credentials
>      >     for
>      >     while and preemptively supply them in future registration
>     requests.
>      >     With
> In general, the UAC must always make sure that it is communicating with 
> the right registrar using TLS and proper validation of the server 
> certificate and the identity in that certificate.

Again, while it is probably true that SIP authentication is mostly used 
with registrars, it is also possible for other servers to require 
authentication, for SUBSCRIBE, NOTIFY, or even INVITE. Any server can 
send a challenge. So the UA needs to be prepared for this and do the 
right thing.

Doing that right includes caching credentials and providing them 
appropriately to avoid unnecessarily prompting the user too often. And 
then preemptively sending credentials becomes an optimization to avoid 
extra round trips. This of course is very important for REGISTER since 
it at times is used very frequently as a keep-alive. But at the same 
time one needs to have some security guidance on when it is appropriate 
to send preemptively and when not.

One answer might be that you should only preemptively send this stuff 
when you have previously (and recently?) been challenged by the "same" 
server, and then send only the credentials that resulted from that 
challenge. But even then there is a question of what "same" means. So 
this needs some explanatory text. The writeup for Digest give some of 
this, though it could probably stand to be improved.

This gets more complex if you consider use with Proxy-Authenticate. This 
mostly gets into the theoretical since I have never heard of it being 
used in practice. It makes things complicated since in theory there 
could be multiple proxies on the path, and they of necessity challenge 
one at a time. To complete the request you then must supply a suitable 
credential for each of the proxies on the path. AFAIK that has never 
been satisfactorily explained. So I guess I would give you a pass if you 
put in a disclaimer that using this for Proxy-Authenticate is outside 
the scope of this document.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 26 Jun 2019 15:26:13 -0400

On Tue, Jun 25, 2019 at 5:01 PM Paul Kyzivat <[email-masked]> wrote:

> these items and how they are expected to be used.

Sure

> And a more fleshed out
I think UI related issues and authentication using 3rd party IdPs are
really out of scope of this document.

> to send preemptively and when not.
I will add text around this to indicate that non-REGISTER requests should
always include the Access Token in the request.

> the scope of this document.

Ok.

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Jun 2019 13:47:33 +0000

Hi,
 
...

> I think UI related issues and authentication using 3rd party IdPs are really out of scope of this document.

I agree.

...

> I will add text around this to indicate that non-REGISTER requests should always include the Access Token in the request.

I don't think we shall do that.

I think the token shall only be included in non-REGISTER requests only if such requests are being challenged (or, perhaps also based on local configuration), because otherwise the token may be sent to a non-trusted remote peer.

Regards,

Christer