Connected Identity for STIR
draft-ietf-stir-rfc4916-update-07

[Ballot comment]
Hi Jon and Chris,

Thanks for the follow-up and clarification.

I understand better how you are approaching these. I'm clearing my DISCUSS ballot, but I'm leaving most of content, for record.

================Initial Ballot=================
# Update or not update RFC4916?

We say that the mechanism in 4916 is complex. We also recommend against it in general, except some “corner cases”.

Also, I understand that we don’t specify a new "from-change" behavior, but still the discussion in Section 10 is sufficient in its own to weight the reco in 4916 with at least the complexity statement in this document.

BTW, can we have some brief description of these corner cases?

# Security, Trust, & Privacy

There are several statements that I think need some better scoping/caution as they may be misleading about provided security protection:

(1)

CURRENT:
  Some sort of directory service might exist advertising support for
  connected identity which institutions could use to inform potential
  callers that, if connected identity is supported when reaching them
  with SIP, there is a potential security problem. 

How to trust that? How this is maintained/populated? What about stale information?

(2)

CURRENT:
  previously supported connected identity, so that if support is
  unavailable later, calling users could be alerted to a potential
  security problem.

This is challenging with number portability and may lead to “false positives”.

(3)

CURRENT:
  Similarly, when clicking on a telephone
  number viewed on a web page, or similar service, smartphones often
  prompt users approve the access to the outbound dialer. 

There is no guarantee that the displayed number corresponds to the actual request-uri of a session that will be issued. May be add a caution about risk with such uses.

(4)

CURRENT:
  probe
  what identity would be reached as a destination, and potentially even
  to exchange STIR PASSporTs in order to validate whether or not the
  expected destination can be reached securely. 

There is no correlation between the probed identities and the session that will be placed. Did I missed something? If not, adding some warning would be needed here.

(5) I wonder whether the probing mentioned early in the document can also be used to help attacker adjust their strategies. If so, can we add a note about this?

For example, the following can be used to detect when redirection/session transfer is in place and infer users activity (transfer of a fixed number for a long period can be a hint that users are abroad, for example)?

CURRENT:
  Note that sending "div" PASSporTs in the backwards direction will
  potentially reveal service logic to the called party.  As presumably
  this service logic is enacted on behalf of the called party, the
  called party can make a policy determination about reflecting those
  "div" PASSporTs back to the caller: connected identity may not be
  compatible with some operator policies.

(6) There are other statements that are presented as providing better security while I think this is more about a "feeling of better secure". For example,

CURRENT:

  Connected identity is very valuable for these use cases because
  it gives a strong assurance to the calling party that they have in
  fact reached the user for the called telephone number.

Assuming the “trusted” device is not also hijacked!

I would avoid claiming this is secure in an absolute manner.

# Group all Operational/Deployment considerations in a dedicated section

There are several ops considerations that are spread in many parts of the document. For the convenience of those who will deploy, it would be better to group these considerations in one section. For example,

CURRENT:
"div" is not universally supported, so calls MAY
  be retargeted without generating a "div" PASSporT, in which case the
  use of "rsp" PASSporTs will not be possible.  Note that the decision
  to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter
  of local policy of the relying parties: some stricter systems may not
  want to trust any "rsp" that differs from the "dest" in the PASSporT
  of the original request.

  Note that sending "div" PASSporTs in the backwards direction will
  potentially reveal service logic to the called party.  As presumably
  this service logic is enacted on behalf of the called party, the
  called party can make a policy determination about reflecting those
  "div" PASSporTs back to the caller: connected identity may not be
  compatible with some operator policies.

and

CURRENT:
  This
  specification thus does not recommend PASSporTs for any requests sent
  in a dialog other than INVITE, UPDATE, and BYE.

# STIR deployment assumptions

Maybe that’s obvious for the authors/WG, but should we say early that the STIR benefits will be observed if all involved session parties are STIR-capable?

# Logging

CURRENT:
  While this specification does not prescribe any user experience
  associated with placing a call, it assumes that callers might have
  some way to a set an authorization posture that will result in the
  right thing happening when the connected identity is not expected.

Can we have some reco for UAC to logs such events? In some contexts, this can be used for troubleshooting.

# Back with a reference

(1)

CURRENT:
  SIP Identity header and the revised problem space of STIR. 

Please cite a reference for the revied pb space.

(2)

CURRENT:
  For example,
  there is a class of mobile fraud attacks ("call stretching") 

Do we have any ref about “call stretching” attack we can cite here?

(3)

CURRENT:
  and PRACK, and provisional responses

Cite RFC3262?

(4)

CURRENT:
  Mid-dialog requests also require special handling in diversion cases.
  Relying parties who intended to trust an "rsp" PASSporT MUST validate
  any "div" chain back to the "rsp" PASSporT on any Identity header

Can we have a pointer about how the chain validation is done?

# On terminology

The document makes use of STIR/SIP terms that need to be digested. Please add a note to Section 2 where readers can find those (“retargeting”, “SIP service”, etc.).

Also, terms such as PAID are used without being introduced. Consider: s/the P-Asserted-Identity header/the P-Asserted-Identity (PAID) header

# I don’t parse the following as RFC8862 is about best practices. Please elaborate.

CURRENT:
  This document also addresses concerns
  about applying [RFC4916] connected identity to STIR discussed in the
  SIPBRANDY framework [RFC8862].

# Side note

CURRENT:
  Moreover, on the
  Internet, the lack of any centralized or even federated routing
  system for telephone numbers has resulted in deployments where the

(no change is needed) This reminds me TRIP (RFC3219) and its inherent support of policies; but the market decided otherwise.

# Redundant behavior

(1) Section 4

CURRENT:
  (although "div" MAY additionally appear in responses, per
  Section 5).

No need to be redundant with Section 5. Keep the normative language in one place. Thanks.

(2) Section 6

CURRENT:
  originating and terminating side, as well as any BYE requests, SHOULD
  contain Identity headers with valid PASSporTs.  If only the
  terminating side supports connected identity, obviously the
  originator cannot be expected to know that it needs to send PASSporTs
  for subsequent requests like BYE.  Doing so prevents third-parties
  from spoofing any mid-dialog requests in order to redirect media or
  similarly interfere with communications, as well as preventing denial
  of service teardowns by attackers, so it has clear benefits and is
  thus RECOMMENDED.

There is a subtlety here but these SHOULD/RECOMMENDED are redundant IMO. Keep one.

# NITS

## Please use “session” instead of “call” as the mechanism applied to any media session. Also consider using “terminating”/”initiating” parties rather that “called/calling”, etc.

## Expand STIR in the abstract

## SIP does not initiates sessions

OLD: The Session Initiation Protocol (SIP) [RFC3261] initiates
NEW: The Session Initiation Protocol (SIP) [RFC3261] is used to initiate

## Better Scope

OLD:
  One area of connected identity that is not explored in this document
  is the implications for conferencing, especially meshed conferencing
  systems.  This scope of this mechanism is solely two-party
  communications; multiparty sharing of connected identity is left for
  future work.

NEW
  This document focuses solely two-party
  communications; multiparty sharing of connected identity is left for
  future work. Specifically, it is out of scope to explore the implications
  for conferencing, especially meshed conferencing systems. 

## Past constructs

Even if this was published in the past, many statements related to 4916 can still be used in present. Please update these statement to use present. For example,

OLD: [RFC4916] allowed
NEW: [RFC4916] allows

Or

OLD: [RFC4916] rightly observed
NEW: [RFC4916] rightly observes 

Etc.

## Simplify

OLD:
  It also
  explores some new features that would be enabled by connected
  identity for STIR, including the use of connected identity to prevent
  route hijacking and to notify callers when an expected called party
  has successfully been reached. 

NEW:
  It also
  explores some new features that would be enabled by connected
  identity for STIR, including to prevent
  route hijacking and to notify initiating parties when an expected terminating party
  has successfully been reached. 

## Modern?!

(1)

CURRENT:
  The STIR problem statement [RFC7340] enumerates robocalling,
  voicemail hacking, vishing, and swatting as problems with the modern
  telephone network

I would s/modern/IP-based

(2)

CURRENT:
  The user interface of modern smartphones support an address book from

There was such address book even in old fixed phones ;-) I would delete “modern” mention.

## Generalize

OLD:
  Finally, telephone numbers are widely used today for two-factor
  authentication (TFA) prior to accessing web resources,

NEW:
  Finally, telephone numbers are widely used today for two-factor
  authentication (TFA) prior to accessing resources on the Internet,

## Straightforward

CURRENT:
  In straightforward call setup, the address-of-record

That is?

Please consider s/ address-of-record/address-of-record (AoR). Then, use AoR in the remaining part of the text.

## Move upper as this convention is already used before this note.

CURRENT:
  PASSporTs of the "rsp" type will be
  referred to throughout this specification as "rsp" PASSporTs.

## Be consistent with 3261 use + nit fix

OLD:
  While it might seem attractive to provide identity for failure
  response codes (4XX, 5XX, 6XX), those explicitly do not form
  dialogs
  or connections, and are thus outside the scope of this specification.
  The same applies to redirect (3XX) response codes, though see
  [RFC8946] section 7 for guidance on authentication redirection.

NEW:
  While it might seem attractive to provide identity for failure
  response codes (4xx, 5xx, 6xx), those explicitly do not form
  dialogs
  or connections, and are thus outside the scope of this specification.
  The same applies to redirect (3xx) response codes, though see
  Section 7 of [RFC8946] for guidance on authentication redirection.

There are other similar occurrences in the document that need to be fixed.

Cheers,
Med

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards track RFC is requested.  Yes, this appears on the
  title page of the Internet-Draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The SIP Identity header conveys cryptographic identity information
  about the originators of SIP requests.  However, the Secure Telephone
  Identity Revisited (STIR) framework provides no means for determining
  the identity of the called party in a traditional telephone calling
  scenario.  This document updates prior guidance to reflect changes to
  SIP Identity that accompanied STIR, and offers a way to tell the
  originator the "connected identity".  Tha is, the telephone number of
  the party that answered the call, even if the call was retargeted to
  party trying to impersonate the intended destination.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document as a standards-track RFC.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Murray Kucherawy is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd did a complete review of -04 during WG Last
  Call.  Then, the ball got dropped, and the shepherd writeup was
  delayed.  The ball has been found, revision -05 was posted to
  resolve the problems that were discovered, and we are (finally)
  moving the document forward.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns at all.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No additional review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns at all.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Both authors have confirmed that they are unaware of any IPR
  disclosures that need to be submitted.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been submitted against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The STIR WG reached consensus, and there is support for
  publication of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened to appeal or expressed discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits raises a warnings:

  -- Obsolete informational reference (is this intentional?): RFC 4474
    (Obsoleted by RFC 8224)

  This reference to RFC 4474 is needed.  It is providing historical
  context.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No additional formal review is needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, informative and normative references appear is separate
  sections in the document.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No, publication of this document will not change the status of
  any other documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This specification defines a new PASSporT type for the PASSport
  Extensions Registry:
 
    https://www.iana.org/assignments/passport/passport.xhtml#passport-extensions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None is needed for this document.

[Ballot comment]
I support Mohamed Boucadair's DISCUSS regarding updating RFC4916.

The terminology section needs to be updated; while it contains the RFC2919 boilerplate, it doesn't list a lot of the specialized terminology used in this document. Consider adding a list of terms used in this document, potentially with references to other RFCs or relevant documents as needed.

[Ballot comment]
"Copyright Notice", paragraph 0
>    Copyright (c) 2024 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.

The Copyright statement needs to be updated. Normally, this would have happened automatically if the draft had been published anytime this year. However, the document has actually expired. It expired on April 24, but probably because it was already in the IESG queue, it is still marked Active. No explicit action is required other than to publish a new version of the document.

Section 1, paragraph 0
> 1.  Introduction

As Med has already pointed out, the Shepherd's write-up uses an old template. The writeup indicates that there was a gap between -04 and -05 versions of the document, and that might explain why the writeup identifies Murray as the Responsible AD, when in fact it is Orie. The write-up needs to be updated to reflect the change.

No reference entries found for these items, which were mentioned in the text. While somewhat obvious, a note to the RFC Editor would make it clear.

[RFCThis].

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "her"; alternatives might be "they", "them", "their"
* Term "traditional"; alternatives might be "classic", "classical", "common",
  "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Will note that the Shepherd's write-up already refects this nit.
Reference [RFC4474] to RFC4474, which was obsoleted by RFC8224 (this may be on
purpose).

Section 4, paragraph 1
> es, per Section 5). At a high level, an "rsp" PASSporT is signed similarly to
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 4, paragraph 3
> SIPBRANDY [RFC8862]. The handling of an "rsp" PASSporT differs from the handl
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 5, paragraph 1
> ackwards direction is the only current defined way for secure indications of
>                                ^^^^^^^^^^^^^^^
Make sure that the adjective "current" is correct. Possibly, it should be an
adverb (typically ~ly) that modifies "defined". Possibly, it should be the
first word in a compound adjective (hyphenated adjective). Possibly, it is
correct.

Section 5, paragraph 2
> ved in the dialog-initiating INVITE. An "rsp" PASSporT that signs a different
>                                      ^^
Use "A" instead of "An" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 5, paragraph 3
> R, a matter of local policy of the relying parties: some stricter systems may
>                                    ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 6, paragraph 2
>  cases where it would be useful to relying parties, but recipients of a CANCE
>                                    ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 6, paragraph 2
> elying parties who intended to trust an "rsp" PASSporT MUST validate any "div
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 7, paragraph 1
> ble, media should not be exchanged. Thus we assume that users have a way in t
>                                    ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 8, paragraph 2
> ample.com/cert.cer" } The payload of an "rsp" PASSporT looks entirely like a
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 8, paragraph 3
>  elements appearing in the payload of an "rsp" type PASSporT. 10. UPDATE Pro
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 11, paragraph 1
> as with "div," the "dest" element of an "rsp" PASSporT is signed, rather tha
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 13, paragraph 1
>  The value of a "rsp" PASSporT to relying parties, as with all PASSporTs, de
>                                  ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 13, paragraph 1
> with all PASSporTs, depends on the relying party trusting the certificate tha
>                                    ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

Section 13, paragraph 1
> ider Codes (SPCs), effectively the relying party knows the network operator w
>                                    ^^^^^^^
The verb "rely" requires the preposition "on" (or "upon").

[Ballot comment]
I support Med's discuss on clarification of relationship with RFC4916. I don't have the technical expertise in this area to evaluate or recommend how that can be done.

[Ballot comment]
Thank you to Elwyn B. Davies for the GENART review.  Please consider the proposed editorial changes.

I support Mohamed Boucadair DISCUSS position and the feedback of the GENART reviewer on providing additional clarity in Section 10 on the relationship between this specification and RFC496.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-stir-rfc4916-update-06

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-stir-rfc4916-update-06.txt


# General Review
# ==============

## the document reads well and is nicely written. It handles technology i am not so familiar with and hence my review is from generalist perspective.

## Shepherd writeup seems based upon a year old prior draft (it references the prior responsible STIR WG AD and I missed finding the downref )

## I suspect it was me being a RTG focused that terminology as swatting and vishing were things i have to do a short internet lookup. I guess in the field of this text, everybody is very well aware of this terminology

## The term "ppt" is used for the first time on line 231. I have not the faintest idea what is a ppt. Is this specified in an RFC? (i may have missed finding the reference). Maybe this is very well known terminology in this domain and my observation makes so sense as result.

## first use of 'div' on line 232 does not expand into RFC8946. however it does expand on line 234. Typically the first usage has the reference document associated. (minor idnit as both instances are so close to each other, only 2 lines difference). Another term was "orig" that i was not familiar with and failed to find a reference at first usage.

# Detailed Review
# ===============

The abstract reads:

11 Abstract
12
13   The SIP Identity header conveys cryptographic identity information
14   about the originators of SIP requests.  The Secure Telephone Identity
15   Revisited (STIR) framework however provides no means for determining
16   the identity of the called party in a traditional telephone calling
17   scenario.  This document updates prior guidance on the "connected
18   identity" problem to reflect the changes to SIP Identity that
19   accompanied STIR, and considers a revised problem space for connected
20   identity as a means of detecting calls that have been retargeted to a
21   party impersonating the intended destination, as well as the spoofing
22   of mid-dialog or dialog-terminating events by intermediaries or third
23   parties.

GV> Potentially alternative abstract textblob that could be mingled with the original.( i'll leave that to the authors to decide what they prefer):

"
The Identity header field defined for the Session Initiation Protocol (SIP)
in RFC 4474 conveys cryptographic assurance of the identity of the originator
of a SIP request. RFC 4916 extends this mechanism to support authenticated
identity for the caller's asserted identity in certain contexts, particularly
where privacy considerations or intermediaries modify the From header field.
However, the authentication practices outlined in RFC 4916 do not align with
the STIR (Secure Telephone Identity Revisited) architecture defined in RFC 8224.
This document updates RFC 4916 to incorporate the PASSporT (Personal Assertion
Token) format for conveying asserted identities, thereby enhancing security and
interoperability within the STIR framework. This update ensures compatibility
with modern SIP identity practices and strengthens the overall identity
assurance in SIP networks.
"

105   The property of providing identity of the called party to the calling
106   party is called "connected identity."  Previous work on connected
107   identity focused on fixing the core semantics of SIP.  [RFC4916]
108   allowed a mid-dialog request, such as an UPDATE [RFC3311], to convey
109   identity in either direction within the context of an existing
110   INVITE-initiated dialog.  In an update to the original [RFC3261]
111   behavior, [RFC4916] allowed that UPDATE to alter the From header
112   field value for requests in the backwards direction: previously
113   [RFC3261] required that the From header field values sent in requests
114   in the backwards direction reflect the To header field value of the
115   dialog-forming request.  Under the original [RFC3261] rules, if Alice
116   sent a dialog-forming request to Bob, then even if Bob's SIP service
117   forwarded that dialog-forming request to Carol, Carol would still be
118   required to put Bob's identity in the From header field value in any
119   mid-dialog requests in the backwards direction.

GV> What about following blob:

"
The provision of identity information for the called party to the calling
party is referred to as "connected identity." Prior work on connected
identity focused on addressing shortcomings in the core semantics of SIP.
[RFC4916] introduced mechanisms allowing a mid-dialog request, such as
an UPDATE [RFC3311], to convey identity information in either direction
within the context of an established INVITE-initiated dialog.
Specifically, [RFC4916] updated the behavior originally defined in
[RFC3261] by permitting an UPDATE to modify the From header field value
for requests sent in the backwards (callee-to-caller) direction.
Under the original RFC 3261 rules, requests in the backwards direction
were required to use a From header field value reflecting the To header
field value of the dialog-forming request. Consequently, under [RFC3261],
if Alice initiated a dialog-forming request to Bob, and Bob’s SIP service
subsequently forwarded the request to Carol, Carol would still be required
to use Bob’s identity in the From header field of any mid-dialog requests
sent in the backwards direction.
"

143   One area of connected identity that is not explored in this document
144   is the implications for conferencing, especially meshed conferencing
145   systems.  This scope of this mechanism is solely two-party
146   communications; multiparty sharing of connected identity is left for
147   future work.

GV> What about the following textblob:

"
This document does not address the implications of connected identity in
conferencing scenarios, particularly in meshed conferencing systems. The
scope of the mechanism described herein is limited to two-party
communications. The extension of connected identity mechanisms to multiparty
communications is left for future work.
"

228   This specification therefore adds provisional and final responses,
229   including the 100, 180, 183, and 200 responses, to the set of
230   messages that can contain an Identity header.  PASSporTs that appear

GV> What are 100, 180, 183 and 200 responses?

242   While it might seem attractive to provide identity for failure
243   response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs
244   or connections, and are thus outside the scope of this specification.
245   The same applies to redirect (3XX) response codes, though see
246   [RFC8946] Section 7 for guidance on authentication redirection.

GV> Do the 4XX, 5XX etc codes mean something in STIR technology domain? I am
not sure what this refers towards or what the intent of this phrase is from
a routing generalist perspective

[Ballot discuss]
Hi Jon and Chris,

Thanks for the effort put into this document.

Also, thanks to Ron Bonica for the OPSDIR review.

# Shepherd Write-up

## The write-up does not follow the latest version [1].

## The write-up includes:

“The author has confirmed that he is unaware of any IPR disclosures that need to be submitted.”

Is this only one specific author? If both authors have replied, maybe worth reflecting this in the write-up. Thanks.

## Downref

The write-up indicates that there is no downref but the document cites RFC 3375 as normative. That downref is called in the IETF LC.

That's said, that RFC should not be cited as normative at the first place. IMO, it should be cited as informative given that the only citation is:

CURRENT:
  The establishment of media-less dialogs has long been specified as a
  component of third-party call control in SIP [RFC3375], in which an
  INVITE is sent with no SDP

# DISCUSS

## Update or not update RFC4916?

We say that the mechanism in 4916 is complex. We also recommend against it in general, except some “corner cases”.

Also, I understand that we don’t specify a new "from-change" behavior, but still the discussion in Section 10 is sufficient in its own to weight the reco in 4916 with at least the complexity statement in this document.

BTW, can we have some brief description of these corner cases?

## Security, Trust, & Privacy

There are several statements that I think need some better scoping/caution as they may be misleading about provided security protection:

(1)

CURRENT:
  Some sort of directory service might exist advertising support for
  connected identity which institutions could use to inform potential
  callers that, if connected identity is supported when reaching them
  with SIP, there is a potential security problem. 

How to trust that? How this is maintained/populated? What about stale information?

(2)

CURRENT:
  previously supported connected identity, so that if support is
  unavailable later, calling users could be alerted to a potential
  security problem.

This is challenging with number portability and may lead to “false positives”.

(3)

CURRENT:
  Similarly, when clicking on a telephone
  number viewed on a web page, or similar service, smartphones often
  prompt users approve the access to the outbound dialer. 

There is no guarantee that the displayed number corresponds to the actual request-uri of a session that will be issued. May be add a caution about risk with such uses.

(4)

CURRENT:
  probe
  what identity would be reached as a destination, and potentially even
  to exchange STIR PASSporTs in order to validate whether or not the
  expected destination can be reached securely. 

There is no correlation between the probed identities and the session that will be placed. Did I missed something? If not, adding some warning would be needed here.

(5) I wonder whether the probing mentioned early in the document can also be used to help attacker adjust their strategies. If so, can we add a note about this?

For example, the following can be used to detect when redirection/session transfer is in place and infer users activity (transfer of a fixed number for a long period can be a hint that users are abroad, for example)?

CURRENT:
  Note that sending "div" PASSporTs in the backwards direction will
  potentially reveal service logic to the called party.  As presumably
  this service logic is enacted on behalf of the called party, the
  called party can make a policy determination about reflecting those
  "div" PASSporTs back to the caller: connected identity may not be
  compatible with some operator policies.

(6) There are other statements that are presented as providing better security while I think this is more about a "feeling of better secure". For example,

CURRENT:

  Connected identity is very valuable for these use cases because
  it gives a strong assurance to the calling party that they have in
  fact reached the user for the called telephone number.

Assuming the “trusted” device is not also hijacked!

I would avoid claiming this is secure in an absolute manner.

[Ballot comment]
# Group all Operational/Deployment considerations in a dedicated section

There are several ops considerations that are spread in many parts of the document. For the convenience of those who will deploy, it would be better to group these considerations in one section. For example,

CURRENT:
"div" is not universally supported, so calls MAY
  be retargeted without generating a "div" PASSporT, in which case the
  use of "rsp" PASSporTs will not be possible.  Note that the decision
  to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter
  of local policy of the relying parties: some stricter systems may not
  want to trust any "rsp" that differs from the "dest" in the PASSporT
  of the original request.

  Note that sending "div" PASSporTs in the backwards direction will
  potentially reveal service logic to the called party.  As presumably
  this service logic is enacted on behalf of the called party, the
  called party can make a policy determination about reflecting those
  "div" PASSporTs back to the caller: connected identity may not be
  compatible with some operator policies.

and

CURRENT:
  This
  specification thus does not recommend PASSporTs for any requests sent
  in a dialog other than INVITE, UPDATE, and BYE.

# STIR deployment assumptions

Maybe that’s obvious for the authors/WG, but should we say early that the STIR benefits will be observed if all involved session parties are STIR-capable?

# Logging

CURRENT:
  While this specification does not prescribe any user experience
  associated with placing a call, it assumes that callers might have
  some way to a set an authorization posture that will result in the
  right thing happening when the connected identity is not expected.

Can we have some reco for UAC to logs such events? In some contexts, this can be used for troubleshooting.

# Back with a reference

(1)

CURRENT:
  SIP Identity header and the revised problem space of STIR. 

Please cite a reference for the revied pb space.

(2)

CURRENT:
  For example,
  there is a class of mobile fraud attacks ("call stretching") 

Do we have any ref about “call stretching” attack we can cite here?

(3)

CURRENT:
  and PRACK, and provisional responses

Cite RFC3262?

(4)

CURRENT:
  Mid-dialog requests also require special handling in diversion cases.
  Relying parties who intended to trust an "rsp" PASSporT MUST validate
  any "div" chain back to the "rsp" PASSporT on any Identity header

Can we have a pointer about how the chain validation is done?

# On terminology

The document makes use of STIR/SIP terms that need to be digested. Please add a note to Section 2 where readers can find those (“retargeting”, “SIP service”, etc.).

Also, terms such as PAID are used without being introduced. Consider: s/the P-Asserted-Identity header/the P-Asserted-Identity (PAID) header

# I don’t parse the following as RFC8862 is about best practices. Please elaborate.

CURRENT:
  This document also addresses concerns
  about applying [RFC4916] connected identity to STIR discussed in the
  SIPBRANDY framework [RFC8862].

# Side note

CURRENT:
  Moreover, on the
  Internet, the lack of any centralized or even federated routing
  system for telephone numbers has resulted in deployments where the

(no change is needed) This reminds me TRIP (RFC3219) and its inherent support of policies; but the market decided otherwise.

# Redundant behavior

(1) Section 4

CURRENT:
  (although "div" MAY additionally appear in responses, per
  Section 5).

No need to be redundant with Section 5. Keep the normative language in one place. Thanks.

(2) Section 6

CURRENT:
  originating and terminating side, as well as any BYE requests, SHOULD
  contain Identity headers with valid PASSporTs.  If only the
  terminating side supports connected identity, obviously the
  originator cannot be expected to know that it needs to send PASSporTs
  for subsequent requests like BYE.  Doing so prevents third-parties
  from spoofing any mid-dialog requests in order to redirect media or
  similarly interfere with communications, as well as preventing denial
  of service teardowns by attackers, so it has clear benefits and is
  thus RECOMMENDED.

There is a subtlety here but these SHOULD/RECOMMENDED are redundant IMO. Keep one.

# NITS

## Please use “session” instead of “call” as the mechanism applied to any media session. Also consider using “terminating”/”initiating” parties rather that “called/calling”, etc.

## Expand STIR in the abstract

## SIP does not initiates sessions

OLD: The Session Initiation Protocol (SIP) [RFC3261] initiates
NEW: The Session Initiation Protocol (SIP) [RFC3261] is used to initiate

## Better Scope

OLD:
  One area of connected identity that is not explored in this document
  is the implications for conferencing, especially meshed conferencing
  systems.  This scope of this mechanism is solely two-party
  communications; multiparty sharing of connected identity is left for
  future work.

NEW
  This document focuses solely two-party
  communications; multiparty sharing of connected identity is left for
  future work. Specifically, it is out of scope to explore the implications
  for conferencing, especially meshed conferencing systems. 

## Past constructs

Even if this was published in the past, many statements related to 4916 can still be used in present. Please update these statement to use present. For example,

OLD: [RFC4916] allowed
NEW: [RFC4916] allows

Or

OLD: [RFC4916] rightly observed
NEW: [RFC4916] rightly observes 

Etc.

## Simplify

OLD:
  It also
  explores some new features that would be enabled by connected
  identity for STIR, including the use of connected identity to prevent
  route hijacking and to notify callers when an expected called party
  has successfully been reached. 

NEW:
  It also
  explores some new features that would be enabled by connected
  identity for STIR, including to prevent
  route hijacking and to notify initiating parties when an expected terminating party
  has successfully been reached. 

## Modern?!

(1)

CURRENT:
  The STIR problem statement [RFC7340] enumerates robocalling,
  voicemail hacking, vishing, and swatting as problems with the modern
  telephone network

I would s/modern/IP-based

(2)

CURRENT:
  The user interface of modern smartphones support an address book from

There was such address book even in old fixed phones ;-) I would delete “modern” mention.

## Generalize

OLD:
  Finally, telephone numbers are widely used today for two-factor
  authentication (TFA) prior to accessing web resources,

NEW:
  Finally, telephone numbers are widely used today for two-factor
  authentication (TFA) prior to accessing resources on the Internet,

## Straightforward

CURRENT:
  In straightforward call setup, the address-of-record

That is?

Please consider s/ address-of-record/address-of-record (AoR). Then, use AoR in the remaining part of the text.

## Move upper as this convention is already used before this note.

CURRENT:
  PASSporTs of the "rsp" type will be
  referred to throughout this specification as "rsp" PASSporTs.

## Be consistent with 3261 use + nit fix

OLD:
  While it might seem attractive to provide identity for failure
  response codes (4XX, 5XX, 6XX), those explicitly do not form
  dialogs
  or connections, and are thus outside the scope of this specification.
  The same applies to redirect (3XX) response codes, though see
  [RFC8946] section 7 for guidance on authentication redirection.

NEW:
  While it might seem attractive to provide identity for failure
  response codes (4xx, 5xx, 6xx), those explicitly do not form
  dialogs
  or connections, and are thus outside the scope of this specification.
  The same applies to redirect (3xx) response codes, though see
  Section 7 of [RFC8946] for guidance on authentication redirection.

There are other similar occurrences in the document that need to be fixed.

Cheers,
Med

[1] https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup

[Ballot discuss]
Hi Jon and Chris,

Thanks for the effort put into this document.

Also, thanks to Ron Bonica for the OPSDIR review.

# Shepherd Write-up

## The write-up does not follow the latest version [1].

## The write-up includes:

“The author has confirmed that he is unaware of any IPR disclosures that need to be submitted.”

Is this only one specific author? If both authors have replied, maybe worth reflecting this in the write-up. Thanks.

## Downref

The write-up indicates that there is no downref but the document cites RFC 3375 as normative. That downref is call in the IETF LC.

That's said, that RFC should not be cited as normative at the first place. It should be cited as informative given that the only citation is:

CURRENT:
  The establishment of media-less dialogs has long been specified as a
  component of third-party call control in SIP [RFC3375], in which an
  INVITE is sent with no SDP

# DISCUSS

## Update or not update RFC4916?

We say that the mechanism in 4916 is complex. We also recommend against it in general, except some “corner cases”.

Also, I understand that that we don’t specify a new "from-change" behavior but still the discussion in Section 10 is sufficient in its own to warrant to weight the reco in 4916 with at least the complexity statement in this document.

BTW, can we have some brief description of these corner cases?

## Security, Trust, & Privacy

There are several statements that I think need some better scoping/caution as they may be misleading about provided security protection:

(1)

CURRENT:
  Some sort of directory service might exist advertising support for
  connected identity which institutions could use to inform potential
  callers that, if connected identity is supported when reaching them
  with SIP, there is a potential security problem. 

How to trust that? How this is maintained/populated? What about stale information?

(2)

CURRENT:
  previously supported connected identity, so that if support is
  unavailable later, calling users could be alerted to a potential
  security problem.

This is challenging with number portability and may lead to “false positives”.

(3)

CURRENT:
  Similarly, when clicking on a telephone
  number viewed on a web page, or similar service, smartphones often
  prompt users approve the access to the outbound dialer. 

There is no guarantee that the displayed number corresponds to the actual request-uri of a session that will be issued. May be add a caution about risk with such uses.

(4)

CURRENT:
  probe
  what identity would be reached as a destination, and potentially even
  to exchange STIR PASSporTs in order to validate whether or not the
  expected destination can be reached securely. 

There is no correlation between the probed identities and the session that will be placed. Did I missed something? If not, adding some warning would be needed here.

(5) I wonder whether the probing mentioned early in the document can also be used to help attacker adjust their strategies. If so, can we add a note about this to the document?

For example, the following can  can be used to detect when redirection is in place and infer users activity (redirection of a fixed number for a long period can be a hint that users are abroad, for example)?

CURRENT:
  Note that sending "div" PASSporTs in the backwards direction will
  potentially reveal service logic to the called party.  As presumably
  this service logic is enacted on behalf of the called party, the
  called party can make a policy determination about reflecting those
  "div" PASSporTs back to the caller: connected identity may not be
  compatible with some operator policies.

(6) There are other statement that are presented as providing better security while I think this is more about a "feeling of better secure". For example,

CURRENT:

  Connected identity is very valuable for these use cases because
  it gives a strong assurance to the calling party that they have in
  fact reached the user for the called telephone number.

Assuming the “trusted” device is not also hijacked!

I would avoid claiming this is secure in an absolute manner.

[Ballot comment]
# Group all Operational/Deployment considerations in a dedicated section

There are several ops considerations that are spread in many parts of the document. For the convenience of those who will deploy, it would be better to group these considerations in one section. For example,

CURRENT:
"div" is not universally supported, so calls MAY
  be retargeted without generating a "div" PASSporT, in which case the
  use of "rsp" PASSporTs will not be possible.  Note that the decision
  to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter
  of local policy of the relying parties: some stricter systems may not
  want to trust any "rsp" that differs from the "dest" in the PASSporT
  of the original request.

  Note that sending "div" PASSporTs in the backwards direction will
  potentially reveal service logic to the called party.  As presumably
  this service logic is enacted on behalf of the called party, the
  called party can make a policy determination about reflecting those
  "div" PASSporTs back to the caller: connected identity may not be
  compatible with some operator policies.

and

CURRENT:
  This
  specification thus does not recommend PASSporTs for any requests sent
  in a dialog other than INVITE, UPDATE, and BYE.

# STIR deployment assumptions

Maybe that’s obvious for the authors/WG, but should we say early that these STIR benefits will be observed if involved session parties are STIR-capable?

# Logging

CURRENT:
  While this specification does not prescribe any user experience
  associated with placing a call, it assumes that callers might have
  some way to a set an authorization posture that will result in the
  right thing happening when the connected identity is not expected.

Can we have some reco for UAC to logs such events? In some contexts, this can be used for troubleshooting.

# Back with a reference

(1)

CURRENT:
  SIP Identity header and the revised problem space of STIR. 

Please cite a reference for the revied pb space.

(2)

CURRENT:
  For example,
  there is a class of mobile fraud attacks ("call stretching") 

Do we have any ref about “call stretching” attack we can cite here?

(3)

CURRENT:
  and PRACK, and provisional responses

Cite RFC3262?

(4)

CURRENT:
  Mid-dialog requests also require special handling in diversion cases.
  Relying parties who intended to trust an "rsp" PASSporT MUST validate
  any "div" chain back to the "rsp" PASSporT on any Identity header

Can we have a pointer about how the chain validation is done?

# On terminology

The document makes use of STIR/SIP terms that need to be digested. Please add a note to Section 2 where readers can find those (“retargeting”, “SIP service”, etc.).

Also, terms such as PAID are used without being introduced. Consider: s/the P-Asserted-Identity header/the P-Asserted-Identity (PAID) header

# I don’t parse the following as RFC8862 is about best practices. Please elaborate.

CURRENT:
  This document also addresses concerns
  about applying [RFC4916] connected identity to STIR discussed in the
  SIPBRANDY framework [RFC8862].

# Side note

CURRENT:
  Moreover, on the
  Internet, the lack of any centralized or even federated routing
  system for telephone numbers has resulted in deployments where the

(no change is needed) This reminds me TRIP (RFC3219) and its inherent support of policies; but the market decided otherwise.

# Redundant behavior

(1) Section 4

CURRENT:
  (although "div" MAY additionally appear in responses, per
  Section 5).

No need to be redundant with Section 5. Keep the normative language in one place. Thanks.

(2) Section 6

CURRENT:
  originating and terminating side, as well as any BYE requests, SHOULD
  contain Identity headers with valid PASSporTs.  If only the
  terminating side supports connected identity, obviously the
  originator cannot be expected to know that it needs to send PASSporTs
  for subsequent requests like BYE.  Doing so prevents third-parties
  from spoofing any mid-dialog requests in order to redirect media or
  similarly interfere with communications, as well as preventing denial
  of service teardowns by attackers, so it has clear benefits and is
  thus RECOMMENDED.

There is a subtlety here but these SHOULD/RECOMMENDED are redundant IMO. Keep one.

# NITS

## Please use “session” instead of “call” as the mechanism applied to any media session. Also consider using “terminating”/”initiating” parties rather that “called/calling”, etc.

## Expand STIR in the abstract

## SIP does not initiates sessions

OLD: The Session Initiation Protocol (SIP) [RFC3261] initiates
NEW: The Session Initiation Protocol (SIP) [RFC3261] is used to initiate

## Better Scope

OLD:
  One area of connected identity that is not explored in this document
  is the implications for conferencing, especially meshed conferencing
  systems.  This scope of this mechanism is solely two-party
  communications; multiparty sharing of connected identity is left for
  future work.

NEW
  This document focuses solely two-party
  communications; multiparty sharing of connected identity is left for
  future work. Specifically, it is out of scope to explore the implications
  for conferencing, especially meshed conferencing systems. 

## Past constructs

Even if this was published in the past, many statements related to 4916 can still be used in present. Please update these statement to use present. For example,

OLD: [RFC4916] allowed
NEW: [RFC4916] allows

Or

OLD: [RFC4916] rightly observed
NEW: [RFC4916] rightly observes 

Etc.

## Simplify

OLD:
  It also
  explores some new features that would be enabled by connected
  identity for STIR, including the use of connected identity to prevent
  route hijacking and to notify callers when an expected called party
  has successfully been reached. 

NEW:
  It also
  explores some new features that would be enabled by connected
  identity for STIR, including to prevent
  route hijacking and to notify initiating parties when an expected terminating party
  has successfully been reached. 

## Modern?!

(1)

CURRENT:
  The STIR problem statement [RFC7340] enumerates robocalling,
  voicemail hacking, vishing, and swatting as problems with the modern
  telephone network

I would s/modern/IP-based

(2)

CURRENT:
  The user interface of modern smartphones support an address book from

There was such address book even in old fixed phones ;-) I would delete “modern” mention.

## Generalize

OLD:
  Finally, telephone numbers are widely used today for two-factor
  authentication (TFA) prior to accessing web resources,

NEW:
  Finally, telephone numbers are widely used today for two-factor
  authentication (TFA) prior to accessing resources on the Internet,

## Straightforward

CURRENT:
  In straightforward call setup, the address-of-record

That is?

Please consider s/ address-of-record// address-of-record (AoR). Then, use AoR in the remaining part of the text.

## Move upper as this convention is already used before this note.

CURRENT:
  PASSporTs of the "rsp" type will be
  referred to throughout this specification as "rsp" PASSporTs.

## Be consistent with 3261 use + nit fix

OLD:
  While it might seem attractive to provide identity for failure
  response codes (4XX, 5XX, 6XX), those explicitly do not form
  dialogs
  or connections, and are thus outside the scope of this specification.
  The same applies to redirect (3XX) response codes, though see
  [RFC8946] section 7 for guidance on authentication redirection.

NEW:
  While it might seem attractive to provide identity for failure
  response codes (4xx, 5xx, 6xx), those explicitly do not form
  dialogs
  or connections, and are thus outside the scope of this specification.
  The same applies to redirect (3xx) response codes, though see
  Section 7 of [RFC8946] for guidance on authentication redirection.

There are other similar occurrences in the document that need to be fixed.

Cheers,
Med

[1] https://datatracker.ietf.org/doc/shepherdwriteup-template/workinggroup

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-stir-rfc4916-update-06. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Personal Assertion Token (PASSporT) Extensions registry in the Personal Assertion Token (PASSporT) registry group located at:

https://www.iana.org/assignments/passport/

A single new extension will be registered as follows:

ppt value: rsp
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

We understand that this is the only action required to be completed upon approval of this document.

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

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-11-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-stir-rfc4916-update@ietf.org, housley@vigilsec.com, orie@transmute.industries, stir-chairs@ietf.org, stir@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Connected Identity for STIR) to Proposed Standard


The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document: - 'Connected Identity for STIR'
  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
last-call@ietf.org mailing lists by 2024-11-19. 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 SIP Identity header conveys cryptographic identity information
  about the originators of SIP requests.  The Secure Telephone Identity
  Revisited (STIR) framework however provides no means for determining
  the identity of the called party in a traditional telephone calling
  scenario.  This document updates prior guidance on the "connected
  identity" problem to reflect the changes to SIP Identity that
  accompanied STIR, and considers a revised problem space for connected
  identity as a means of detecting calls that have been retargeted to a
  party impersonating the intended destination, as well as the spoofing
  of mid-dialog or dialog-terminating events by intermediaries or third
  parties.




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



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3375: Generic Registry-Registrar Protocol Requirements (Informational - Internet Engineering Task Force (IETF) stream)

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards track RFC is requested.  Yes, this appears on the
  title page of the Internet-Draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The SIP Identity header conveys cryptographic identity information
  about the originators of SIP requests.  However, the Secure Telephone
  Identity Revisited (STIR) framework provides no means for determining
  the identity of the called party in a traditional telephone calling
  scenario.  This document updates prior guidance to reflect changes to
  SIP Identity that accompanied STIR, and offers a way to tell the
  originator the "connected identity".  Tha is, the telephone number of
  the party that answered the call, even if the call was retargeted to
  party trying to impersonate the intended destination.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document as a standards-track RFC.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Murray Kucherawy is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd did a complete review of -04 during WG Last
  Call.  Then, the ball got dropped, and the shepherd writeup was
  delayed.  The ball has been found, revision -05 was posted to
  resolve the problems that were discovered, and we are (finally)
  moving the document forward.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns at all.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No additional review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns at all.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  The author has confirmed that he is unaware of any IPR
  disclosures that need to be submitted.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been submitted against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The STIR WG reached consensus, and there is support for
  publication of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened to appeal or expressed discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits raises a warnings:

  -- Obsolete informational reference (is this intentional?): RFC 4474
    (Obsoleted by RFC 8224)

  This reference to RFC 4474 is needed.  It is providing historical
  context.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No additional formal review is needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, informative and normative references appear is separate
  sections in the document.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No, publication of this document will not change the status of
  any other documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This specification defines a new PASSporT type for the PASSport
  Extensions Registry:
 
    https://www.iana.org/assignments/passport/passport.xhtml#passport-extensions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None is needed for this document.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards track RFC is requested.  Yes, this appears on the
  title page of the Internet-Draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The SIP Identity header conveys cryptographic identity information
  about the originators of SIP requests.  However, the Secure Telephone
  Identity Revisited (STIR) framework provides no means for determining
  the identity of the called party in a traditional telephone calling
  scenario.  This document updates prior guidance to reflect changes to
  SIP Identity that accompanied STIR, and offers a way to tell the
  originator the "connected identity".  Tha is, the telephone number of
  the party that answered the call, even if the call was retargeted to
  party trying to impersonate the intended destination.

Working Group Summary

  The STIR WG reached consensus, and there is support for
  publication of this document as a standards-track RFC.

Document Quality

  Several people have expressed interest in implementing this
  specification.

Personnel

  Russ Housley is the Document Shepherd.
  Murray Kucherawy is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd did a complete review of -04 during WG Last
  Call.  Then, the ball got dropped, and the shepherd writeup was
  delayed.  The ball has been found, revision -05 was posted to
  resolve the problems that were discovered, and we are (finally)
  moving the document forward.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns at all.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No additional review is needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns at all.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  The author has confirmed that he is unaware of any IPR
  disclosures that need to be submitted.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been submitted against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The STIR WG reached consensus, and there is support for
  publication of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened to appeal or expressed discontent.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  IDnits raises a warnings:

  -- Obsolete informational reference (is this intentional?): RFC 4474
    (Obsoleted by RFC 8224)

  This reference to RFC 4474 is needed.  It is providing historical
  context.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No additional formal review is needed for this document.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, informative and normative references appear is separate
  sections in the document.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  None.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No, publication of this document will not change the status of
  any other documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This specification defines a new PASSporT type for the PASSport
  Extensions Registry:
 
    https://www.iana.org/assignments/passport/passport.xhtml#passport-extensions

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None is needed for this document.