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

From: Derrell Piper via Datatracker <[email-masked]>
Date: Tue, 14 Apr 2020 14:07:04 -0700

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Apr 2020 07:58:01 +0000

Hi Derrell,

Thank You for the review! Please see inline.
    
>    "...enables single sign-on, which allows the user to..."
  
We can fix as suggested.

---
  
>    "previously" means "from the out-of-scope mechanism", just say that.
  
I think that sounds a little "clumsy" to repeat it. Would it work if we said "obtained in the step above", or something like that?

---
  
>    the schemes are exhausted without success.
  
Section 2.1.1 defines generic procedures, while section 2.1.3 defines the procedures specific for the REGISTER request.

Regards,

Christer

---

From: Derrell Piper <[email-masked]>
Date: Wed, 15 Apr 2020 11:21:34 -0700

> On Apr 15, 2020, at 12:58 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Derrell,
> 

“the step above” works too.

> Section 2.1.1 defines generic procedures, while section 2.1.3 defines the procedures specific for the REGISTER request.

Okay.

Derrell