Subject: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 20 Apr 2020 22:49:50 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-sipcore-sip-token-authnz-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document.  Enabling Open-ID and OAUTH with SIP is quite useful.

This document specifically calls out single sign-on as a reason to use this
mechanism, and SSO has a host of serious security and privacy issues.  As those
issues are not discussed in the referenced documents, I think they need to be
raised here.  Recommended usage/configuration to avoid or mitigate the issues
would be ideal, but at the very least I think they need to be documented, as
it’s clear that implementors are not aware of them or don’t think they’re
important enough to worry about.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

— Section 1.1 —
Please copy the BCP 14 boilerplate exactly from RFC 8174.

— Section 1.3 —

   Refresh Tokens usualy are represented in a reference format

Typo: “usually”.

— Section 3 —

   The methods used and the access
   provided by the token is based on local policy

“are based”, to match the plural subject.

   Examples of such other
   mechanisms are introspection [RFC7662], user profile lookups, etc.

“Examples” and “etc.” are mutually redundant.  I would remive the latter and
replace the comma before “user profile lookups” with “and”.

— Section 6 —
This can’t be empty.  It should say that there are no IANA actions needed for
this document.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 21 Apr 2020 06:54:22 -0400

Hi Barry,

Thanks for your the review.
Regarding the DISCUSS, how about adding the following text to the security
considerations section:

Single Sing-On enables the user to use one set of credentials to
authenticate
once and gain access to multiple SIP and non-SIP services using access
token(s).
Because of that, it is critical to make sure that extra security measures be
taken to guards these credentials.

Examples of such measures include long passphrase instead of a password,
enabling
multi-factor factor authentication, and the use of embedded browser when
possible,
as defined in RFC8252.

Although this is out of scope for this document, it is important to
carefully
consider the claims provided in the tokens used to access these services to
make
sure of the privacy of the user accessing these services. As mentioned
above,
this document calls for encrypting JWT representing the access token.

Regards,
 Rifaat

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Apr 2020 11:36:42 +0000

The pull request: https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7

Regards,

Christer

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tuesday, 21 April 2020 at 13.54
To: Barry Leiba <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "A. Mahoney" <[email-masked]>
Subject: Re: Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)
Resent from: <[email-masked]>
Resent to: Rifaat Shekh-Yusef <[email-masked]>, Christer Holmberg <[email-masked]>, Victor Pascual <[email-masked]>
Resent date: Tuesday, 21 April 2020 at 13.54

Hi Barry,

Thanks for your the review.
Regarding the DISCUSS, how about adding the following text to the security considerations section:

Single Sing-On enables the user to use one set of credentials to authenticate
once and gain access to multiple SIP and non-SIP services using access token(s).
Because of that, it is critical to make sure that extra security measures be
taken to guards these credentials.

Examples of such measures include long passphrase instead of a password, enabling
multi-factor factor authentication, and the use of embedded browser when possible,
as defined in RFC8252.

Although this is out of scope for this document, it is important to carefully
consider the claims provided in the tokens used to access these services to make
sure of the privacy of the user accessing these services. As mentioned above,
this document calls for encrypting JWT representing the access token.

Regards,
 Rifaat

On Tue, Apr 21, 2020 at 1:49 AM Barry Leiba via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Barry Leiba has entered the following ballot position for
draft-ietf-sipcore-sip-token-authnz-13: Discuss

— Section 1.1 —

— Section 1.3 —

Typo: “usually”.

— Section 3 —

   Examples of such other

— Section 6 —

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2020 14:17:52 -0400

Thanks for the reply, Rifaat.  We're on the right track, though
there's more involved.  We just have to figure out the best way to
handle it, because this document doesn't have the full responsibility
to lay out best practices for SSO.  So let's see if we can come up
with a reasonable compromise.

Let me start by laying out, quickly, some of the issues with SSO:

The biggest problems include:
- privacy exposures: if I "login with Facebook" everywhere, Facebook
gets a lot of information about what I do and where I log in, and
users are generally not aware of that
- exposure on many services if my SSO (Facebook or whatever) login is
compromised: now that the SSO login is used in other places, that
single point of compromise has a far broader effect -- you get to that
in your first suggested paragraph
- if my SSO login is compromised, an attacker can use it to create new
SSOs on sites that I haven't even used, and sometimes they can switch
my existing separate accounts to SSO, adding compromises that I didn't
sign up for
- inability to extricate myself from the situation: most sites don't
make it easy to undo SSO once I've enabled it, and many don't allow it
at all

It's clearly well beyond the scope of this document to cover all that
in any detail, but it might be worth a brief overview of the problems.
Let me see if I can add a paragraph or two to what you've already
suggested, to cover the other three issues.

<<
Single Sign-On (SSO) enables the user to use one set of credentials to
authenticate once and gain access to multiple SIP and non-SIP services
using access token(s). If the SSO login is compromised, that single
point of compromise has a much broader effect than is the case without
SSO.  Further, an attacker can often use a compromised account to set
up Single Sign-On for other services that the victim has not
established an account with, and sometimes can even switch a dedicated
account into Single-Sign-On mode, creating a still broader attack.

Because of that, it is critical to make sure that extra security
measures be taken to safeguard credentials used for Single Sign-On.
Examples of such measures include long passphrase instead of a
password, enabling multi-factor factor authentication, and the use of
embedded browser when possible, as defined in RFC8252.

Although this is out of scope for this document, it is important to
carefully consider the claims provided in the tokens used to access
these services to make sure of the privacy of the user accessing these
services. As mentioned above, this document calls for encrypting JWT
representing the access token.

It is important that both parties participating in SSO provide
mechanisms for users to sever the SSO relationship, so that it is
possible without undue difficulty to mitigate a compromise that has
already happened.

The operator of a Single-Sign-On authentication system has access to
private information about sites and services that their users log
into, and even, to some extent, about their usage patterns.  It's
important to call these out in privacy disclosures and policies, and
to make sure that users can be aware of the tradeoffs between
convenience and privacy when they choose to use SSO.

Does that work?

And then it would be good for us (the IETF community as a whole, not
ICE) to figure out whether to write a BCP related to SSO
security/privacy issues.

Barry

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 21 Apr 2020 15:25:30 -0400

Thanks Barry!

As you pointed out, this is way beyond the scope of this document and the
SIPCore WG (not ICE), as I was trying to focus on things that this document
controls.
Having said that, I am fine with adding the updated text to the security
consideration section if that addresses your concerns and clears the
DISCUSS.

I will add your proposed text to the next version of the draft.
Regards,
 Rifaat

On Tue, Apr 21, 2020 at 2:18 PM Barry Leiba <[email-masked]> wrote:

> measures be

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2020 15:53:42 -0400

> As you pointed out, this is way beyond the scope of this document and the SIPCore WG (not ICE),

Urk... I had also just reviewed an ICE document.  This is all so confusing!  :-)

> Having said that, I am fine with adding the updated text to the security consideration section
> if that addresses your concerns and clears the DISCUSS.

To be clear: we've had the discussion, so the DISCUSS will be cleared
in any case.  I do think it's important for this document to put a
stake in the ground with respect to SSO issues, so I'd like to see the
suggested text in the document, and I appreciate your willingness to
put it in.  Thanks!  At the same time, I do not want to do it over the
objections of the working group, if that should be the case -- this
isn't just a "make the AD happy" thing.

Thanks for discussing this with me, and I will go clear my DISCUSS now.

Barry

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 21 Apr 2020 16:03:26 -0400

Hi Barry,

Sorry if I came across as just trying to clear the DISCUSS.
I think the suggested text is useful as a general advise and reminder, but
as you know this is not something that this document controls.

In any case, I am happy to add it to the security consideration section and
hope that this will remind people to think and consider these issues.

Regards,
 Rifaat

On Tue, Apr 21, 2020 at 3:53 PM Barry Leiba <[email-masked]> wrote:

> consideration section

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Apr 2020 21:39:29 +0000

Hi,

Below is a link to a pull request with the SSO text for the Security Considerations.

https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Rifaat Shekh-Yusef <[email-masked]>
Date: Tuesday, 21 April 2020 at 22.26
To: Barry Leiba <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] Barry Leiba's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT)

Thanks Barry!

As you pointed out, this is way beyond the scope of this document and the SIPCore WG (not ICE), as I was trying to focus on things that this document controls..
Having said that, I am fine with adding the updated text to the security consideration section if that addresses your concerns and clears the DISCUSS.

On Tue, Apr 21, 2020 at 2:18 PM Barry Leiba <[email-masked]<mailto:[email-masked]>> wrote:

<<

Does that work?

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2020 17:51:38 -0400

> https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/7

Parfait; merci beaucoups!

Barry