Authenticated Identity Management in the Session Initiation Protocol (SIP)
draft-ietf-stir-rfc4474bis-16

[Ballot comment]
Thanks for a well written document.  Just one comment, I would have liked to have seen section 10 much sooner in the document, maybe in the introduction as changes are usually up front.

[Ballot discuss]

This should be an easy one to fix (or else I'm missing stuff,
which is quite possible) but if a fix is needed then it'd impact
on interop...

In 8.3, I think the ABNF conflicts with the E164Number definition
in the certs draft which disallows "#" and "*" (if I understand
the "FROM" clause in the ASN.1 module correctly).

[Ballot comment]
Thanks for this work. I'm balloting  yes, but have a few minor comments and questions:

Substantive:

- 6.2, step 4:  This says that if the full form of passport is included, and the Date header and iat do not match, use iat if it is fresh. I'm curious why not just use iat in the first place? What should one do if Date is fresh, but iat is not?

-6.2.2: This section recommends specific result code reason phrases for a couple of circumstances. I assume the idea is that one should use a "helpful" reason phrase, and these are examples of phrases helpful for the circumstances. But it reads as if you mean to standardize those specific reason phrases.  If the intent is really to offer examples, please clarify. I'd hate to see us back in the days of commonly seeing SIP code break due to unexpected reason phrases.

- 7.2: The first sentence says verifiers must have a way to acquire and _retain_ certificates. Why must they have a way to retain them? The last paragraph in the section says they might wish to have a way to retain certs, but doesn't seem to require it.

-- Is there any concern that the requirement to be able to dereference effectively arbitrary URLs in "info" parameters could become a DOS attack vector? E.g. info parameters that point to HTTP URIs that never respond, respond very slowly, or return huge and/or corrupt certs?

-13.1 and 13.2: Is there a reason not to retarget the references in the IANA entries for the Identity header field and for the error codes from 4474 to [RFCThis]?

Editorial:

- 4.1.1, example: I assume the backslashes indicate line folding for documentation purposes only. It might be worth mentioning that.

- 6.1, step 4, last paragraph: Is the reference to section 9 mean that section of _this_ document, or that section of stir-passport?

- 7.1, 2nd paragraph: It seems odd to use 2119 MUSTs in examples of policies that authenticator services might have.

-8.1, third paragraph: s/exampple/example

[Ballot comment]
This is a well written document (despite giving too many deployment choices in some areas). I have a short list of small issues/nits:

In Section 4: ABNF for the signed-identity-digest allows empty string? Is this intentional? If not, maybe use "1*" in front?

In Section 5.1: are you missing an empty line between the header and the SDP payload?

In Section 6.2.2: is it customary in SIP to use the human readable portion of error responses?

In Section 7.4: HTTP URIs need a reference.

In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case as well?

[Ballot comment]
One minor comment:
Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for?

(Added later)

Now I have read draft-ietf-stir-passport. So it clear why this method is used. Didn't realize that the following sentence means 'please check PASSporT for further questions...': "this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT." Maybe just give a more specific reference including the section refernce.

[Ballot comment]
One minor comment:
Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-stir-rfc4474bis-14.txt. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, we understand that there are four registry actions to complete.

First, in the Header Fields subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

the entry for Identity-Info is to be marked "deprecated" and the reference is to be changed to [ RFC-to-be ].

Second, in the Response Codes subregistry also in the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

the Reason phrase for the 436 response default reason phrase will be changed from "Bad Identity-Info" to "Bad Identity Info" and [ RFC-to-be ] will be added to the references for the reason.

In the same registry, the 437 "Unsupported Certificate" default reason phrase will be changed to "Unsupported Credential" and [ RFC-to-be ] will be added to the references for the reason.

Third, the Identity-Info Parameters subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

will have its name changed to "Identity Parameters" and a reference of [ RFC-to-be ] will be added to the references.

In that same subregistry, the "alg" parameter entry in the registry will be updated to reference [ RFC-to-be ] as its specification.

In that same subregistry a new parameter name will be registered as follows:

Parameter Name: info
Reference: [ RFC-to-be ]

Fourth, in Section 13.4 of the current draft, the author request that the Identity-Info Algorithm Parameter Values subregistry of the Session Initiation Protocol (SIP) Parameters registry located at:

https://www.iana.org/assignments/sip-parameters/

be deleted.

Question --> Would it be acceptable to simply close the existing registry?

An example of this is the AFSDB RR Subtype registry at:

http://www.iana.org/assignments/dns-parameters/

We would change the registration procedure to "registry closed per [this document]" and list this document as the defining RFC. We would also be willing to modify any entries in the registry per your instructions.

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-stir-rfc4474bis@ietf.org, alissa@cooperw.in, stir@ietf.org, "Robert Sparks" , stir-chairs@ietf.org, rjsparks@nostrum.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Authenticated Identity Management in the Session Initiation Protocol (SIP)) to Proposed Standard


The IESG has received a request from the Secure Telephone Identity
Revisited WG (stir) to consider the following document:
- 'Authenticated Identity Management in the Session Initiation Protocol
  (SIP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The baseline security mechanisms in the Session Initiation Protocol
  (SIP) are inadequate for cryptographically assuring the identity of
  the end users that originate SIP requests, especially in an
  interdomain context.  This document defines a mechanism for securely
  identifying originators of SIP requests.  It does so by defining a
  SIP header field for conveying a signature used for validating the
  identity, and for conveying a reference to the credentials of the
  signer.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2562/

1. Summary

draft-ietf-stir-rfc4474bis defines protocol and is intended for publication as
Proposed Standard. It obsoletes RFC4474. From the abstract:

  The baseline security mechanisms in the Session Initiation Protocol
  (SIP) are inadequate for cryptographically assuring the identity of
  the end users that originate SIP requests, especially in an
  interdomain context.  This document defines a mechanism for securely
  identifying originators of SIP requests.  It does so by defining a
  SIP header field for conveying a signature used for validating the
  identity, and for conveying a reference to the credentials of the
  signer.

This document is a component of a toolset for combating robocalling. In the
US, the FCC is applying significant pressure to the industry to deter
robocalling (with deadlines in the last part of 2016). An industry-led strike
force is moving towards deployment of a solution that uses that toolset. The
ATIS/SIP Forum IPNNI Task Force's SHAKEN solution relies on the toolset defined
by STIR and profiles it for deployment in the North American market.

The changes from RFC4474 are significant, and detailed in the document. The
syntax defined in this document is not backwards compatible with RFC4474 (and
this is discussed explicitly in the document). There are no known deployed
implementations of RFC4474.

2. Review and Consensus

This document has undergone heavy review. The syntax and expressivity of the
protocol changed significantly during its development, particularly when
reconciling early tension with the SHAKEN effort. The feedback from that effort
led to the use of the passport concepts defined in draft-ietf-stir-passport.

Recent versions of this document were implemented and tested at the SIP Forum
SIPit test event in September. Feedback from that event informed improvements
to both the protocol and the prose in the document. Those implementations are
tracking the changes made in the latest versions.

The document suite has been through three working group last calls, the third
of which was abbreviated to one week. The first last call stimulated
significant discussion, some of which was heated. Dave Crocker, in particular,
provided a large amount of feedback during the first last call, indicating
disagreement with the overall approach the working group has taken. Working
through the comments led to improvements in the documents.

This document required no formal directorate reviews.

3. Intellectual Property

The authors have each confirmed that any IPR they are aware of has been
disclosed. There is currently one disclosure registered for this document. The
disclosure was sent to the working group list on 24 Mar 2015. There was no
subsequent list discussion.

4. Other Points

IDnits reports no significant issues with the document. In particular, there
are no normative downreferences from this document.

The document uses ABNF to define grammar. The ABNF was reviewed by the
implementers at SIPit. Robert Sparks also verified the ABNF was well formed
using BAP.

The document requires several actions from IANA. They are concretely described
in the document text.

A two week WG Last Call for rfc4474bis started on 13 July 2016, and it will end on 27 July 2016.  Ideally major concerns will be raised quickly so that they can be tackled during IETF 96.