Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Alan Ford <> Sat, 17 September 2016 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F118212B0A8 for <>; Fri, 16 Sep 2016 18:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6-olqXs0DDMQ for <>; Fri, 16 Sep 2016 18:22:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63E9812B067 for <>; Fri, 16 Sep 2016 18:22:42 -0700 (PDT)
Received: by with SMTP id 38so50835065qte.1 for <>; Fri, 16 Sep 2016 18:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LLRCcuFiqiGQIUcbOUPZ/e+QIqNDsKFhqVnWm/9iRm8=; b=Lyzlb7KmTyhzHXlVqYxC35QgyEW4YeQ/fwjsmN6WSEdY+oxykfk7DSQIbFv+klPq7b TEC26z0x8MUAcZwKHDf0WoC9hDa6YjxtyKKoX/TolEmpBlG32wNaKSjUe+mEhBuUGmkt WTiAu2lp9cg4xtg2BwZEY6wcowV57cVuZX9fDOREa4nPAqP2zJjNie74gmbOFGzpYsB2 fRRM51F0udG9JBL45aWo5RSbtQl6j1Y5BU1GWaFDe2kWeSJb4rXs8Dx/Yy4oIpsIY8xT ez7I6xlE1NcnxsmiZkEFrDX7OCCQMun5R8Zle4nlRd7OvVrj6mFQwxm2viq9ohgfH3l+ EW5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LLRCcuFiqiGQIUcbOUPZ/e+QIqNDsKFhqVnWm/9iRm8=; b=ZhFvnlN0Lac+5x+5d+Wg8O7hwLqwu1x7VK6tdCFUt8hkR/ulVYJA6pob0p+IRYYaHr sS4OTDYdlVwbeWJ5iO67R/QoxKVKUMiniZfl8s2vRgTKbL5+/9g/0KhdkKy9+etM+8VT OgayqF0DogXYgNi33EAaRwv9YH0BNNl8NmVpbdfhwnLtP3Phc2KMkyVqDeExhObnXVcF DsRckI+csJawGNYgC44+EOnGJurgcynuJ2uiws5i6S4fUbV+QDpsRpMCr2IFr3QZlxD4 YFY1lojvqDKiD+pBsLx663w3Bvi9ztLvfHOoHuAm6G6lI0Cypo0+jT38XlhNPlSBbPcP kJig==
X-Gm-Message-State: AE9vXwNHNwaMbpVI21eCANFD6Ds1sBBmBW024DzwTDI1mse/GVDpHcSofmgUEOrCcyb3Xw==
X-Received: by with SMTP id k25mr18677599qta.75.1474075361466; Fri, 16 Sep 2016 18:22:41 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id i5sm6251766qti.30.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 18:22:40 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A1255B4-E9D2-4947-AB6E-A84819F338CE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Sat, 17 Sep 2016 02:19:59 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Peterson, Jon" <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>, Christer Holmberg <>, Brian Rosen <>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Sep 2016 01:22:45 -0000

Hi Jon,

I feel we’re getting distracted by the PAI discussion here, and this was not the initial driver behind my comments. I felt it was an additional valid issue, stemming from the same problems of lack of clear canonicalisation, and so latched on to the ongoing discussions here, but let’s leave this out for the moment.

My primary concern was the SIP/TN distinction. Here is an example, real-world which we ran into in SIPit:

- Sender’s PASSporT:

{ “orig” : { “uri” : “” }, “dest” : { “uri” : [ “” ] } }

The sender sends like this since it is in a SIP environment, e.g. a large enterprise, with no distinction of internal and external calling.

- Receiver’s PASSporT:

{ “orig” : { “uri” : “” }, “dest” : { “tn” : “87654321" } }

These are two different PASSporTs, which will not validate, because both ends canonicalised a call in a different way. The receiver considers the number a TN, but the sender did not.

This is why I am proposing mandating canon in any circumstances where you cannot guarantee the behaviour of the receiver.

A few more replies inline; avoiding anything PAI-related...

> On 16 Sep 2016, at 19:00, Peterson, Jon <> wrote:
>> Indeed not. But, it tells the receiver which fields to look in, and what form of canonicalisation to undertake. This is A Good Thing from an implementation and interoperability point of view.
> Only if you think that the way that the state in which the authentication service saw these fields should determine for the verifier what the "real" identity of the originator is. That is not an assumption we make, or should make. 
> Since we're still talking about this, maybe we should also bring this back to the gatewaying and mixed-SIP cases that informed this decision. I hesitate to move indications into PASSporT that say things like "I got this identity from a PAI" because PASSporT shouldn't have those sorts of dependencies on a using protocol. I similarly can imagine a case where a VoIP call starts in, say, Jingle, and lands eventually on a SIP endpoint, with some gateway in the middle. The original Jingle authentication service didn't derive its TN from any SIP header at all. Cases like that should be in our scope of consideration here.
> I would ultimately prefer not to festoon PASSporT with SIP-specific indicators.

That’s perfectly understandable, and a new PASSporT could be defined to provide this function if desired.

However, to achieve deployability with STIR as defined today requires people to canonicalise in the same way. To make this happen, we need to share information.

>>> The presence of canon cannot influence the verification service decision: we want security to fail (which, I feel obliged to say, doesn't necessarily mean rejecting the request) if the verification service canonicalization does not resolve to the same value that the auth service used. That is what this mechanism is designed to do.
>> But this is the problem! When a sender does not know its target would canonicalise the destination address as a TN, and thus encodes it as a SIP URI in the PASSporT object, verification would fail. But with canon, the verification service could be more intelligent, as it may be able to pass all other verification logic if it knew how the field had been canonicalised.
> I am indeed saying that is a security bug, not a feature. Though surely an attacker would like to make the verification service "more intelligent" by telling it "try to see things my way.” 

Then I fear there is misunderstanding here. A verification service has a set of possible canonicalisations (e.g. to TN or not to TN). It could, as Paul said in another mail, try all combinations, but that would be computationally expensive. By providing the canon we are providing information as to which of these possible canonicalisations to choose. This is not adding any additional security risk - all canonicalisations are those which the verification service would support anyway.

> We both agree that "canon" should at least be allowed, and when it is present, I think it is meaningful for the verification service to compare the canonicalized value(s) it found in the message with the orig value of the PASSporT object as a step in the verification process. That doesn't raise any alarm bells for me. As soon as this becomes instead about how the verification service should decide based on the information in "canon" how its canonicalization process should work., that trips the alarm loud and clear.

Again, this is not saying “what is in the canon is truth”, it is saying “this is what I encoded, if you think this canonicalisation is accurate then let’s validate”.

>>> ... the PASSport object is not a security hole in the sense that it lacks integrity protection. The security hole appears only if we stipulate that the verification service trusts that the orig tn value in the PASSporT object is a canonicalization of whatever identity the SIP request carries.
>> I don’t think anyone is suggesting that should be the logic. I certainly am not.
> I cannot distinguish what you are recommending from this.

I hope my example at the start of this mail clarifies this.