Last Call Review of draft-ietf-stir-rfc4474bis-14
review-ietf-stir-rfc4474bis-14-genart-lc-gurbani-2016-11-01-00

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

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Summary:

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.

Major:

- 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.

Minor:

- 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



Nits:

- 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/

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg at bell-labs.com / vijay.gurbani at nokia-bell-labs.com
Web: 

http://ect.bell-labs.com/who/vkg/

  | Calendar: 

http://goo.gl/x3Ogq