Re: [stir] Question from the IETF 101 note taker

"Peterson, Jon" <> Wed, 28 March 2018 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92E7B126D05 for <>; Wed, 28 Mar 2018 12:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zcTG3sLP2uCB for <>; Wed, 28 Mar 2018 12:48:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DBC71250B8 for <>; Wed, 28 Mar 2018 12:48:29 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w2SJiBxI001497; Wed, 28 Mar 2018 15:48:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : content-type : mime-version; s=selector1; bh=QtLx+D1vybTgCsUs+e0J2Onjd4QG2E53Ce80s6DymS4=; b=P6bsaLgRGVKkLGBEfxbcs462OEkKCA0Mk2msW8lMAMNjkifX3+KI3HkSWljc5zz/w4sw dWMlF9Dlu2ydGtAmajgU9h0DY6Pht3VzfJG7nP7/L5a1SrK9fWzmxbWpUeGDUHyYAKcx dhEc2hIrgYpNtVpFc8rmK6p51Kbnkjl4yOJyKvmjHOkU3yJLDqBkVAnYTkZL8lH6WYdm oGbC9+RpgTxNZxBkuoRxr34g8s+nrXidA81BVaX2i3JfE1OKGFCL4YC75PhhpM46ioKp l5WSP19tytaURAV0729JKTBcrU8yFW0BkKErjN6RiDloXgjrpU26VSDebbT8eyDS17ij UQ==
Received: from ([]) by with ESMTP id 2gwkpkfues-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Mar 2018 15:48:27 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Wed, 28 Mar 2018 15:48:26 -0400
From: "Peterson, Jon" <>
To: Russ Housley <>, IETF STIR Mail List <>
Thread-Topic: [stir] Question from the IETF 101 note taker
Thread-Index: AQHTxs28s4EuGl8e/0+2RaujrSdkeg==
Date: Wed, 28 Mar 2018 19:48:26 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9D06C2A9EC934713B28FA309FF8834AAteamneustar_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-28_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803280202
Archived-At: <>
Subject: Re: [stir] Question from the IETF 101 note taker
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Mar 2018 19:48:33 -0000

I don’t think the idea of having Identity headers in a 3XX, which the original UAC could optionally use in subsequent requests, was controversial with anyone. I just kind of asked if anyone objected, but people seemed to get the rationale and were cool with it. So I thought the take away was that we’re keeping it. It does have some potentially complex interactions with nesting and multiple Identity headers, but that’s up to us to document adequately.

Jon Peterson
Neustar, Inc.

From: stir <>; on behalf of Russ Housley <>;
Date: Wednesday, March 28, 2018 at 11:51 AM
To: IETF STIR Mail List <>;
Subject: [stir] Question from the IETF 101 note taker

Can anyone answer this question?  If not, we will need to review the audio.


On Mar 26, 2018, at 6:40 AM, Christer Holmberg <<>> wrote:


Below are my minutes from the IETF#101 STIR session.

Note that there is one OUTCOME with “????”, regarding whether we should allow Identity in 3xx responses, because I missed what was decided. Please fill in :)




Topic: PASSporT Extension for Resource-Priority Authorization
Presenter: Martin Dolly
Draft: draft-ietf-stir-rph-03

Status update.

An issue whether ppt values should be quoted or not. Both ways are used, and we should agree on a common way. See 'PASSporT Extension for Divert' minutes.

NEXT STEP: Submit new version of draft.


Topic: PASSporT Extension for SHAKEN
Presenter: Chris Wendt
Draft: draft-ietf-stir-passport-shaken-01

Status update.

Indicated that some minor changes are still to be done, but otherwise the draft is ready to be moved forwarded. Nobody objected to moving the draft forward.

NEXT STEP: Submit new version of draft.


Topic: PASSporT Extension for Divert
Presenter: Jon Peterson
Draft: draft-ietf-stir-passport-divert-02

ISSUE: It was suggested to allow Identity in 3xx responses.

ISSUE: It was discussed on whether we should deprecate the usage of nested claims for the in-band solution.
It was indicated that the total size of an INVITE request is not a problem (the size will be large even without Identity header fields), but a large size of a single header field can cause problems.
It was indicated that we should use the same mechanism for in-band and out-of-band (nesting is needed for out-of-band).
It was indicated that, if nesting is used, it needs to be clarified how nesting is done when there are multiple incoming Identity header fields, if e.g., all of them are to be nested.
OUTCOME: Nesting will stay.

ISSUE: It was discussed whether we should define the order of Identity header fields in a SIP message, when multiple header fields are included.
OUTCOME: No need to define order of Identity header fields.

ISSUE: It was discussed whether we should define the order of claims within a PASSporT, as required by RFC 8225.
OUTCOME: No need to define anything additional, as RFC 8225 already defines how to order the claims as part of the serialisation.

ISSUE: Should we make 'opt' independent of 'div', so nesting can be used with other PASSporT extensions?
OUTCOME: Will allow 'opt' with other extensions, if needed in future.

ISSUE: Should ppt= values be quoted or not?
OUTCOME: Keep quoting mandatory.

It was indicated that more reviewers of the draft are needed.

NEXT STEP: Submit new version of the draft. WGLC once the next version of the draft has been submitted.


Topic: Out-Of-Band (OOB)
Presenter: Jon P
Draft: draft-ietf-stir-oob-02

Presentation of changes:

- More generic guidance for validating PASSportTS against calls without SIP.

- Mocked up a REST interface for a CPS. Initial work, more work is needed.

It was indicated that there a need to specify at least one CPS discovery mechanism (while realising that service discovery in general is a complex and much-studied topic).

NEXT STEP: Work will continue.


Topic: Registry for Country-Specific STIR Root Certificates
Presenter: Eric B (remote)
Draft: draft-burger-stir-iana-cert-00

There was much concern about the suggestion. It would come with a big liability and huge responsibility on IANA. It was also unclear what the Expert Reviewer is expected to do.

It was indicated that, if such registry is to be created, it should be done e.g., by ITU-T. While to problem might be clear, it is not the within the expertise of IETF or IANA.

It was indicated that, even if a registry exist, people will not rely on the information and will anyway do vetting.

NEXT STEP: No decision.


Topic: Connected Identity for STIR
Presenter: Jon P
Draft: draft-peterson-stir-rfc4916-update-00

"STIR backwards". Send an UPDATE request in the backwards direction while the call is being established.

NEXT STEP: No decision (discussions will continue).


Topic: Callback
Presenter: Jonathan R
Draft: draft-rosenberg-stir-callback-00

It was indicated that the mechanism should be seen as a complement to RFC 8226.

It was indicated that the callback INVITE will often reach a PSTN gateway that do not support the Require header field value, which would trigger a call establishment in the PSTN network.

It was indicated that perhaps OOB could be used for this.

NEXT STEP: No decision.


Topic: SIPcoin
Presenter: Jonathan R
Draft: draft-rosenberg-stir-sipcoin-00

Short presentation of the mechanism.

It was clarified the a blockchain is not needed: an entity will only do work before the call, and then show proof of the work when establishing a call.

Interested parties were invited to a lunch meeting, where further discussions could take place.

NEXT STEP: No decision.

stir mailing list<><>