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

# 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

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.

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

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.

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

I agree with Med that "This document updates prior guidance" seems to imply it Updates: a previous document.

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.