I question one thing in this document:
Section 4 allows identity headers in a variety of response types,
including 100. I am dubious about allowing this in 100. It is a special
case, because it is sent hop-by-hop instead of being forwarded end to
end. To properly populate the identity, an intermediary would need the
identity from further downstream. But the 100 is sent before the the
downstream target has been reached.
I didn't note any other issues during a casual read-through.
Thanks,
Paul
On 11/5/24 7:15 AM, The IESG wrote:
The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document: - 'Connected Identity for STIR'
<draft-ietf-stir-rfc4916-update-06.txt> 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@xxxxxxxx mailing lists by 2024-11-19. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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)
_______________________________________________
IETF-Announce mailing list -- ietf-announce@xxxxxxxx
To unsubscribe send an email to ietf-announce-leave@xxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
