[sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 05 May 2020 18:46 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9773A0C37; Tue, 5 May 2020 11:46:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney <mahoney@nostrum.com>, mahoney@nostrum.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.129.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158870439650.25526.11019219125541236895@ietfa.amsl.com>
Date: Tue, 05 May 2020 11:46:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/Rt8IGHO0OAGVGR7j_myzsqmpUbA>
Subject: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 18:46:37 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-15: 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 the updates in the -14 (and -15); they cover most of my points. Unfortunately, the new security considerations text seems to introduce a problematic recommendation: 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]. Looking at RFC 8252 (Section 8.12), it seems to be rather strongly recommending to *not* use an embedded browser, which is the opposite of the apparent recommendation here. Are we missing a word "avoiding" or similar? Also, I am not 100% sure my note about refresh tokens was fully addressed; in Section 2.1.1 we see: The refresh token is only used between the UAC and the AS. If the AS provides a refresh token to the UAC, the UAC uses it to request a new access token and refresh token from the AS before the currently used access token expires ([RFC6749], Section 1.5). If the AS does not Is it accurate to say that the refresh token is used "to request a new access token and refresh token" (specifically the "and refresh token" part)? I know that it is not always returned, but am less sure about whether the semantics always include an (implicit) request for a new one. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some other comments on the new text that do not rise to Discuss-level. Thanks for adding the mention of a whitelist of trusted ASes; I would consider also mentioning it in Section 4 for the authz_server parameter, and/or in the security considerations. I also would have liked to see some guidance about when one should/shouldn't include the realm parameter in a challenge. Section 2.1.1 UAC contacts the AS in order to obtain tokens, and includes the requested scopes, based on a local configuration (Figure 1). The UAC MUST check the AS URL received in the 401/407 response against a list of trusted ASs configured on the UAC, in order to prevent several classes of possible vulnerabilities when a client blindly attempt to use any provided authorization. nits: "attempts", and maybe "any provided authorization server". Section 3 nit: s/claimes/claims/ Section 5 When a registrar chooses to challenge a REGISTER request, if the registrar can provide access to different levels of services, it is RECOMMENDED that the registrar includes a scope in the response in order to indicate the minimum scope needed to register and access basic services. The access token might include an extended scope that gives the user access to more advanced features beyond basic services. Is there anything to say about how the broader scope value might be learned?
- [sipcore] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk via Datatracker
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Rifaat Shekh-Yusef
- Re: [sipcore] Benjamin Kaduk's Discuss on draft-i… Christer Holmberg