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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 21 Apr 2020 12:59:29 -0700

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

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/

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

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.

Rifaat and I have discussed the above comment and have come up with some text
for the Security Considerations that calls out some of the issues, briefly. 
Something with more scope than that -- perhaps a BCP about security/privacy
concerns with respect to SSO -- is in order, but, clearly, that's way out of
scope for this document.

Other, editorial points.

— 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 remove 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.