Skip to main content

Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR)
draft-ietf-stir-identity-header-errors-handling-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, ben@nostrum.com, draft-ietf-stir-identity-header-errors-handling@ietf.org, rfc-editor@rfc-editor.org, stir-chairs@ietf.org, stir@ietf.org, superuser@gmail.com
Subject: Protocol Action: 'Identity Header Errors Handling for STIR' to Proposed Standard (draft-ietf-stir-identity-header-errors-handling-08.txt)

The IESG has approved the following document:
- 'Identity Header Errors Handling for STIR'
  (draft-ietf-stir-identity-header-errors-handling-08.txt) as Proposed
  Standard

This document is the product of the Secure Telephone Identity Revisited
Working Group.

The IESG contact persons are Murray Kucherawy and Francesca Palombini.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/


Ballot Text

Technical Summary

   This document extends STIR and the Authenticated Identity Management
   in the Session Initiation Protocol (SIP) error handling procedures to
   include the mapping of verification failure reasons to STIR defined
   4xx codes so the failure reason of an Identity header field can be
   conveyed to the upstream authentication service when local policy
   dictates that the call should continue in the presence of a
   verification failure.  This document also defines procedures that
   enable a failure reason to be mapped to a specific Identity header
   field for scenarios that use multiple Identity header fields where
   some may have errors and others may not and the handling of those
   situations is defined.

Working Group Summary

   There was general agreement among a fairly small group of STIR participants.
   This group included people with SIP and STIR implementation experience.

   There was no significant controversy. There were some architectural questions
   and some questions about potential privacy leaks that that were worked
   through to consensus. One participant questioned whether the mechanism
   could be deployed in practice, but most active participants did not see a 
   problem.

   No one has threatened an appeal or expressed extreme discontent.

Document Quality

   The shepherd is not aware of existing implementations. However, this work is
   likely to be adopted by the ATIS/SIP Forum IP-NNI task force, which will
   likely result in wide-spread implementation in the voice service provider
   community.

Personnel

   Ben Campbell is the document shepherd.
   Murray Kucherawy is the responsible Area Director.

RFC Editor Note