[Gen-art] COMPLETE Gen-ART review of draft-ietf-stir-rfc4474bis-14

"Vijay K.Gurbani" <vijay.gurbani@nokia-bell-labs.com> Thu, 03 November 2016 18:38 UTC

Return-Path: <vijay.gurbani@nokia-bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 26A4C1296A6; Thu, 3 Nov 2016 11:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Y9ryslm4j2YE; Thu, 3 Nov 2016 11:38:51 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6B7129AC6; Thu, 3 Nov 2016 11:38:51 -0700 (PDT)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown []) by Websense Email Security Gateway with ESMTPS id 59AFBB8F767DC; Thu, 3 Nov 2016 18:38:47 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com []) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id uA3IcnL7000596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 18:38:49 GMT
Received: from umail.lucent.com (umail.ndc.lucent.com []) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id uA3IcmMm014432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2016 18:38:49 GMT
Received: from [] (shoonya.ih.lucent.com []) by umail.lucent.com (8.13.8/TPES) with ESMTP id uA3IcmSx023746; Thu, 3 Nov 2016 13:38:48 -0500 (CDT)
From: "Vijay K.Gurbani" <vijay.gurbani@nokia-bell-labs.com>
To: draft-ietf-stir-passport.all@ietf.org
Message-ID: <4a800ae0-b09f-675d-c287-81689b271f4d@nokia-bell-labs.com>
Date: Thu, 03 Nov 2016 13:38:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/6uFqmtbiciUwF66vNcJn0huFNJc>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] COMPLETE Gen-ART review of draft-ietf-stir-rfc4474bis-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 18:38:56 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-stir-rfc4474bis-14
Reviewer: Vijay K. Gurbani
Review Date: Nov-03-2016
IETF LC End Date: Unknown
IESG Telechat date: Nov-03-2016


This document is ready to be published as a Proposed Standard once the
nits/comments below have been addressed.

Major issues: 1

Minor issues: 3

Nits/editorial comments: Various.


- S7.4 contains requirements for a credential system, and the draft
  assumes that any credential system that works with the draft will
  adhere to the five expectations outlined in the section.

  My question is how do we ensure that these expectations are met?
  Through IANA?  (But there is no subsection in the IANA registry
  section corresponding to this.)  Through some form of domain expert
  required to review a specification outlining the five expectations?
  It seems to me that since the credential service is an integral part
  of the system, some manner of review by the appropriate working group
  (or a designated expert) should take place.


- S3: "baseline SIP" ==> What do you mean by this?  (I know what you
  mean, of course, but others reading the document may not.)  Perhaps
  the following substitution is better?

  s/purposes of baseline SIP,/use of SIP as defined in [RFC 3261],/

- S6.2.2, the 436 response case.  I am a big believer of protocols
  imparting as much error information as they can, especially if the
  protocol is as expressive as SIP.  Since this error code is repairable,
  why not provide information to the repairer on exactly which Identity
  header was 'bad'.  Something like:

  436 Bad Identity Info
  Warning: 399 https://biloxi.example.org/biloxi.cert is not accessible

  Or message/sipfrag could be used as well.

  We do not have to make such debugging/error information propagation
  mandatory (MUST), but we should at least alert the implementers to
  it existence (SHOULD).

- S6.2.2, the 437 response case.  Same reasoning as above.  Example:

  437 Unsupported credential
  Warning: 399 https://biloxi.example.org/biloxi.cert


- S1: "However, the recipient of a SIP request has no way to verify
  that the From header field has been populated appropriately, in the
  absence of some sort of cryptographic authentication mechanism."
  Changing the order of the dependent clauses may lead to better
  readability.  That is,
  "However, in the absence of some sort of cryptographic authentication
  mechanism, the recipient of a SIP request has no way to verify that
  the From header field has been populated appropriately."

- S1: You may want to define what "swatting" is for those not well-
  versed in ART terminology.

- S1: "less spoofable" ... Merriam-Webster does not define "spoofable"
  as a word (online version).  Perhaps better to say "less amenable to
  spoofing" instead.  Something as the following suggested text:
  "Ideally, a cryptographic approach to identity can provide a much
  stronger assurance of identity than the Caller ID service used
  by the public-switched telephone network today.  Such an approach
  would also be less amenable to identity spoofing."

- S3: s/through means entirely up to the authentication service,/through
   per-arranged means with the authentication service,/

- S3: s/credentials that will be trusted by relying parties to sign for
  telephone numbers are a key component of the architecture./credentials
  that will be trusted by relying parties to be authoritative for
  telephone numbers become a key component of the architecture./

- S3: s/not so easy to/not as easy to/

- S3: s/ but this document does not mandate or specify a credential
  system.  [I-D.ietf-stir-certificates] describes a credential system
  compatible with this architecture./ but this document does not mandate
  or specify a particular credential system;
  [I-D.ietf-stir-certificates] describes one credential system compatible
  with this architecture."

- S3 s/This is typically easier to deal with, as these identities are
  issued to users by authorities over Internet domains./This is
  typically easier to deal with as these identities are issued by
  organizations that have authority over Internet domains./

- S3: s/can issue them an identity/issues an identity/

- S3: s/prove in some fashion/proves/

- S6.2, Step 3: "The verifier must ensure that it possesses the proper
  keying material to validate the signature...".  Here, I believe
  that the verifier must ensure that it *has access to* to the proper
  keying material, more than the fact that it "possesses" it.  Namely,
  the verifier needs to have access to the URI in the "info" parameter.
  Whether or not it caches the certificate (thus making it "possess" it),
  is up to the policies of the verifier.

  Summary: s/possesses/has access to/

- S7.1, first paragraph, first sentence.  With respect to my above
  comment, s/have access to/possess/

  The Authentication Service must not only have access to, but must
  possess the private keying material.  Possession implies access, but
  access may not imply possession.

- S7.1, second paragaph: s/For non-telephone number user parts/For
  non-telephone number URIs/

- S8, s/vet the identity/confirm the identity/


- vijay
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq