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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 22 Apr 2020 08:01:42 -0700

Roman Danyliw 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:
----------------------------------------------------------------------

The use of the OpenID ID token appears to be underspecified.  Section 1.3 notes
the possibility of using it as one of the three possible tokens.  However, the
SIP procedures in Section 2 makes no note of it, only covering the use of the
“access token” and the “refresh token”.

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

Thanks for the update based on the SECDIR review (and thanks to Derrell Piper
for providing it).

** Section 1.3.  Per “Access Tokens could be represented in one of the above
two formats.”, if not one of these two formats, then which other ones?

** Section 2.1.1.  Per “An OpenID Connect server …”, based on the flows
depicted in Figure 1 and 2, how the OpenID Connect server fits isn’t clear.

** Section 2.1.2.  Per “Endpoints that support this specification MUST support
encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and protecting access
tokens when they are included in SIP requests, unless some other mechanism is
used to guarantee that only authorized SIP endpoints have access to the access
token.” -- is it the “use of” or “support for” JWT that is required if there
isn’t an alternative?  Section 5 uses similar language.

** Section 2.1.3.  Per “Note that, if there were multiple challenges with
different schemes, then the UAC may be able to successfully retry the request
using non-Bearer credentials.”, would that decision be made based on local
policy?

** Section 5.  Should the use of the scope parameter be noted (or RECOMMENDED)
to narrow the utility of the token?

** Editorial Nits:
Section 1.3.  Typo. s/usualy/usually/

Section 7.  Typo.  s/coversion/conversion/