Re: [stir] Definition of STIR

Richard Shockey <richard@shockey.us> Thu, 12 May 2022 20:29 UTC

Return-Path: <richard@shockey.us>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67678C15952A for <stir@ietfa.amsl.com>; Thu, 12 May 2022 13:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l3Q02KJ_XaJ for <stir@ietfa.amsl.com>; Thu, 12 May 2022 13:29:02 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ABEC14F735 for <stir@ietf.org>; Thu, 12 May 2022 13:29:01 -0700 (PDT)
Received: from cmgw11.mail.unifiedlayer.com (unknown [10.0.90.126]) by progateway6.mail.pro1.eigbox.com (Postfix) with ESMTP id 89BA510047A47 for <stir@ietf.org>; Thu, 12 May 2022 20:29:01 +0000 (UTC)
Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with ESMTP id pFQindxE3wm8ipFQjnclXt; Thu, 12 May 2022 20:29:01 +0000
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.4 cv=DpSTREz+ c=1 sm=1 tr=0 ts=627d6e0d a=KXpOjjFwo8kCkgxs2x2AJQ==:117 a=KXpOjjFwo8kCkgxs2x2AJQ==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=MKtGQD3n3ToA:10:nop_fastflux_from_domain_1 a=1oJP67jkp3AA:10:nop_fastflux_mid_domain_1 a=oZkIemNP1mAA:10:nop_rcvd_month_year a=qMgonR0qfJAA:10:endurance_base64_authed_username_1 a=jqBRFv0mrdUA:10:from_fastflux_domain1 a=PeFO9FbFhS32YxYntvkA:9 a=uw9Sko2_AAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=YRLU8ZVIAAAA:8 a=0FD05c-RAAAA:8 a=Z80JlwQ0AAAA:8 a=48vgC7mUAAAA:8 a=9bOKTyGbAAAA:8 a=dbcnAWtwAAAA:8 a=m2kBL9iQk5NzCm-B96sA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=ivbTfD_dPm4A:10:phone_number_3 a=uBj0Gdr_CfwA:10:demote_hacked_domain_2 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=2JLUh5-gAAAA:8 a=UqCG9HQmAAAA:8 a=3sUvqiie7aflK2L9kR4A:9 a=LOyD9kmEjAtAXagB:21 a=gKO2Hq4RSVkA:10:nop_mshtml a=UiCQ7L4-1S4A:10:nop_mshtml_css_classes a=hTZeC7Yk6K0A:10:nop_msword_html a=frz4AuCg-hUA:10:nop_css_in_html a=dB0NWylLPTSImCDXM2VX:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=G0fnPMQLLrhXuW0VSdpZ:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=Zz-tw7mMPhxMdvFcggwQ:22 a=w1C3t2QeGrPiZgrLijVG:22 a=2MnCfuFsdWRFdRCRZFaS:22 a=hnrGVjIjb-X0WoHtSFqa:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZPK6L+aceINlPTxHohqRU2ZP5tPQnBIl1wMWqHlUeuA=; b=oJ9oJ3YWXyA7K/XLz5CSPxfNEo hHoK1wYgo4TmXTemcNh8aQhmN8QNFcjqypSd7Lw+TaOiO7rjb12ougvjl3Tb5aoJZmMPlz4U/kEJ1 tyaEUgm0xqYovOXybWMT9FaDJ;
Received: from pool-108-56-134-98.washdc.fios.verizon.net ([108.56.134.98]:54872 helo=[192.168.1.214]) by box5527.bluehost.com with esmtpa (Exim 4.94.2) (envelope-from <richard@shockey.us>) id 1npFQi-000jcR-EQ; Thu, 12 May 2022 14:29:00 -0600
User-Agent: Microsoft-MacOutlook/16.61.22050700
Date: Thu, 12 May 2022 16:28:59 -0400
From: Richard Shockey <richard@shockey.us>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Robert Sparks <rjsparks@nostrum.com>, "stir@ietf.org" <stir@ietf.org>
Message-ID: <60FA6B6B-0714-45CE-86E0-E760C2F674D9@shockey.us>
Thread-Topic: [stir] Definition of STIR
References: <700E1CC1-37ED-4A26-9822-35874C925646@shockey.us> <HE1PR07MB4441A7BCA89EB795CFBA537993C89@HE1PR07MB4441.eurprd07.prod.outlook.com> <BYAPR02MB41685704706EFA588BAD1647D2C89@BYAPR02MB4168.namprd02.prod.outlook.com> <HE1PR07MB4441BB167B0AD82243F005B493C89@HE1PR07MB4441.eurprd07.prod.outlook.com> <0acb9af0-15f2-35bd-a5ed-30a00c1afdba@nostrum.com> <AA02ED4B-E584-4763-8D4D-C6F7808B0A7F@shockey.us> <HE1PR07MB4441F7174FD412BBAAF55BD293CB9@HE1PR07MB4441.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB4441F7174FD412BBAAF55BD293CB9@HE1PR07MB4441.eurprd07.prod.outlook.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3735217740_1461994135"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box5527.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-BWhitelist: no
X-Source-IP: 108.56.134.98
X-Source-L: No
X-Exim-ID: 1npFQi-000jcR-EQ
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-108-56-134-98.washdc.fios.verizon.net ([192.168.1.214]) [108.56.134.98]:54872
X-Source-Auth: richard+shockey.us
X-Email-Count: 7
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20=
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/FvpV9tCw12gNluORP6a4fTNbQdk>
Subject: Re: [stir] Definition of STIR
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 May 2022 20:29:06 -0000

 

Oh and one more thing…. 

 

This stuff gets complicated …politically

 

 

https://www.neca.org/docs/default-source/wwpdf/public/42822robo.pdf

 

 

Nice bed time reading only 230 pages.

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

www.sipnoc.org  (2022)

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday, May 12, 2022 at 3:35 PM
To: Richard Shockey <richard@shockey.us>, Robert Sparks <rjsparks@nostrum.com>, "stir@ietf.org" <stir@ietf.org>
Subject: RE: [stir] Definition of STIR

 

Hi,

 

At least in my experience, ”RTCWEB” is normally not used outside of the circles that worked on it. People normally talk about “WebRTC”. Also, as far as I remember, there are no RFCs with “RTCWEB” in the title (they all talk about defining this and that for “WebRTC”), or RFCs using “RTCWEB” to refer to some specific mechanism.

 

Also, I don’t think it is problem when “STIR/SHAKEN” etc is used as an abstract “marketing term”, referring to the work that IETF and ATIS have done.

 

The problem comes when we start using it in technical terms, talking about “STIR mechanism”, “extending STIR”, etc. Then it becomes much more abstract. 

 

I think the sentences suggested by Robert ("The set of mechanisms beginning with RFC8224 and its extensions" or "The set of mechanism defined by the STIR working group.") would clarify a lot, eventhough it may seem obvious to those involved in the IETF/ATIS work.

 

Regards,

 

Christer

 

 

 

 

 

From: stir <stir-bounces@ietf.org> On Behalf Of Richard Shockey
Sent: torstai 12. toukokuuta 2022 3.29
To: Robert Sparks <rjsparks@nostrum.com>; stir@ietf.org
Subject: Re: [stir] Definition of STIR

 

 

Robert did you really have to bring up RTCWEB?  LOL 

 

+1 plus the implementation of the STIR/SHAKEN framework is a national regulatory specific issue.   US CA now.  France is coming.  UK wants to do it but has very specific problems that take precedence.

 

I’m on the FCC NANC Federal Advisory Committee and we just completed a report on the current state of affairs not only in the US but other countries. Lots of folks on this list participated in this effort.

 

https://access.atis.org/apps/org/workgroup/catawg2/document.php?document_id=65705

 

 

 

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

www.sipnoc.org  (2022)

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: stir <stir-bounces@ietf.org> on behalf of Robert Sparks <rjsparks@nostrum.com>
Date: Wednesday, May 11, 2022 at 7:06 PM
To: <stir@ietf.org>
Subject: Re: [stir] Definition of STIR

 

Hi Christer -

While I sort of see your concern, I think you may be overthinking the need to have a single document that says what "STIR" is?

The language that you pointed to when you started this thread could be restated as "The set of mechanisms beginning with RFC8224 and its extensions" or "The set of mechanism defined by the STIR working group.", or for _that particular sentence_ we can just point at a particular RFC.

But really, for readability even into the future, STIR is a well enough known acronym now that the sentence will not confuse or mislead, and readers will be able to follow it to the necessary documents (via the Normative References) to understand what the document is saying.

Charters do "last forever" fwiw. And replay your question using "RTCWEB" :)

RjS

 

On 5/11/22 3:20 PM, Christer Holmberg wrote:

Hi,

 

>Does it need to be in an RFC?  Maybe update the WG charter instead?

 

I don’t think we normally define terminology in the charter. Also, as the WG/charter may not “last forever”, I don’t know if we can reference it.

 

>I’m not against it being in an RFC, but don’t know if there is a need.

 

The word “STIR” is used in many RFCs, but there is no (AFAIK) definition or reference anywhere.

 

draft-ietf-stir-identity-header-errors-handling references RFC 8224 for the new “STIR” Reason header protocol value.

 

Regards,

 

Christer

 

 

 

From: Christer Holmberg <christer.holmberg@ericsson.com> 
Sent: Wednesday, May 11, 2022 2:23 PM
To: Richard Shockey <richard@shockey.us>; Gorman, Pierce <Pierce.Gorman@t-mobile.com>; stir@ietf.org
Subject: RE: [stir] Definition of STIR

 

Hi,

 

>Pierce that about covers it…

 

But that is not documented in any RFC, is it?

 

Regards,

 

Christer

 

 

 

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

www.sipnoc.org  (2022)

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

 

 

From: stir <stir-bounces@ietf.org> on behalf of "Gorman, Pierce" <Pierce.Gorman@t-mobile.com>
Date: Wednesday, May 11, 2022 at 2:04 PM
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>, "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] Definition of STIR

 

I suppose you or others could volunteer attempts at a definition.  Once satisfactorily achieved, what would you do with it?  Not trying to be a smart alec.  I’m seriously curious.

 

I will volunteer that I think of “STIR” as being the collection of work in the IETF that is referenced in “SHAKEN” call authentication specifications in use in the US and Canada (so far).

 

“STIR” is the collection of work that tells you how to create a SIP Identity header of whatever type you need for a particular call type, and how to create an X.509 security certificate (chain) with extensions and constraints needed to verify the contents of a SIP Identity header.

 

“SHAKEN” (a body of work in the ATIS/SIP Forum Joint Task Force on IP-NNI) tells you how to create and use various SIP Identity types defined in “STIR” and about the governance, policy, and certificate authorization framework used to acquire SHAKEN-specific X.509 end-entity certificates.

 

Beyond this, the call authentication governance authorities in the US and Canada have created requirements and selected entities to be Policy Administrators (PAs) and also created Certificate Policies which outline the requirements to be an authorized (within their respective jurisdictions) Certification Authority (CA), thus creating the SHAKEN GA/PA/CA Secure Telephone Identity (STI) Public Key Infrastructures (PKIs).

 

I expect others can volunteer alternative, and potentially better, definitions.

 

Best regards,

 

 

Pierce Gorman

From: stir <stir-bounces@ietf.org> On Behalf Of Christer Holmberg
Sent: Wednesday, May 11, 2022 11:52 AM
To: stir@ietf.org
Subject: [stir] Definition of STIR

 

[External]

 

Hi,

 

What exactly is ”STIR”, other than the name of an IETF WG?

 

Sometimes “STIR” used in document titles, sometimes there is text saying “STIR”/“the STIR mechanism” does this and that, provides this and that etc. draft-ietf-stir-identity-header-errors-handling talks about “extending STIR”.

 

RFC 7340 is supposed to describe the STIR problem, but 7340 does not even say what STIR stands for (Secure Telephone Identity Revisited), and there is no RFC named “STIR”.

 

The question came up while I was reviewing the messaging draft, which says:

 

“Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller…”

 

Regards,

 

Christer

 

_______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir 

 
_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir
_______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir