[secdir] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12

Derrell Piper via Datatracker <noreply@ietf.org> Tue, 14 April 2020 21:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFF3A0FD9; Tue, 14 Apr 2020 14:07:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Derrell Piper via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-sipcore-sip-token-authnz.all@ietf.org, last-call@ietf.org, sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158689842488.27716.15541584374764439587@ietfa.amsl.com>
Reply-To: Derrell Piper <ddp@electric-loft.org>
Date: Tue, 14 Apr 2020 14:07:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4SDbZ04i_gog4Hm8FNui8NY2yBE>
Subject: [secdir] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 21:07:05 -0000

Reviewer: Derrell Piper
Review result: Has Nits

Reviewer: Derrell Piper
Review result: Ready With Nits

I reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents entering the IESG.  These comments
are directed at the security area director(s).  Document editors and WG
chairs should treat these comments like any other last call comments.

This document defines a third-party token authentication scheme for
authentication to SIP services using "bearer" tokens from the OAuth 2.0
framework and the OpenID Connect Core 1.0 to support native application
assisted (or proxy-based) token-based authentication and authorization.

pp. 3, 1., nit

"...enables the single-sign-on features, which allows the user to..."

"...enables single sign-on, which allows the user to..."

pp. 5, last sentence

"previously" means "from the out-of-scope mechanism", just say that.

pp. 7, 2.1.1

"(or with invalid credentials)"

Why continue when a UAC presents invalid credentials?  [See below.]

pp. 8, 2.1.3

2.1.1 says if you get invalid credentials to go REGISTER, and here in
REGISTER, it says if you get invalid credentials, go to 2.1.1.  This
seems recursive though I'm assuming this ultimately terminates when all
the schemes are exhausted without success.

Derrell