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

"Peterson, Jon" <> Thu, 15 September 2016 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E81C812B107 for <>; Thu, 15 Sep 2016 13:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.7
X-Spam-Status: No, score=-102.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 hzZnllG360vV for <>; Thu, 15 Sep 2016 13:51:52 -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 3D59812B02C for <>; Thu, 15 Sep 2016 13:51:52 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u8FKh9XG021356; Thu, 15 Sep 2016 16:51:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version;; bh=QXAiYO3GS6ZMUmBef3zLIhB7gWyXmuFgba8uWo9Usn0=; b=mmrN44ONRWuxlT/s/akBN8IJi/8ciCcRowuioMl9ue2nUiojMyOI6K/T59yFgsrq+ylt iCsl8Zzo5f1qn9SiLzmxxkOV3riQtGfmwahUmaQO2DzigIqPuoWjtNBiVcJJNnEn7S5Q bQQqUICRjzIPeiM4oVajJwrCs83A/x2HAUVRBbnfZyMeZRwAIQXxALVtDcOkcsI3c+XD 1xFUo+so7kgK8dw5lEKkADuFavX48QNhYtXCgYSlhqpAAx5PX+zIIAibUEMcXs2bDfGy 8zhtj5ur44ezFcARKTfScstqTGEPeMwPvbHKGRAtl+0Y365pnaozmUzZt0ptsUj930Bv jg==
Received: from ([]) by with ESMTP id 25ce9qkjgb-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Sep 2016 16:51:45 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Thu, 15 Sep 2016 16:51:43 -0400
From: "Peterson, Jon" <>
To: Alan Ford <>, Brian Rosen <>
Thread-Topic: [stir] 4474bis: Why only RECOMMEND when multiple identities?
Thread-Index: AQHSCr0aO2cgMkmCPEuSpwV160N6wqB2ILfggAG0jACAA1l8gIAABekAgAABcQD//6g2gA==
Date: Thu, 15 Sep 2016 20:51:42 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D4004AA81B3224jonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-15_10:, , 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 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609150275
Archived-At: <>
Cc: "" <>, Christer Holmberg <>
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: Thu, 15 Sep 2016 20:51:56 -0000

I don't think I agree with either the framing of the problem or the proposed solution here (for the first problem in Alan's mail); but to dig in to this, we need to go back to the first principles of canonicalizing phone numbers.

A From identity (or a PAI identity) is expected to contain an address-of-record of the originator of the request. If some really unhelpful URI that is only resolvable locally is used as the From, then we should expect there to be problems in ordinary SIP operations if the request escapes that local environment. The whole point of including an AoR as your public identity is that someone who sees it can dereference it, and through standard routing procedures (in baseline SIP we mean RFC3263) you'll end up reaching the right user agents(). If you aren't operating within those constraints, I don't think that's really something that RFC4474bis can fix.

A To identity expresses the AoR you are trying to reach. We already have a split in baseline SIP between the To and the Request-URI, because SIP recognizes that the target of a request is likely to be dynamic: in baseline SIP, the To is supposed to be immutable, and the Request-URI is supposed to support hard changes.

When it comes to rfc4474bis, the idea of having both sides run their own independent canonicalization of the telephone number arose because deployment experience suggests that intermediaries in fact modify telephone numbers in transit in various ways, be they found in the To and From header field values or wherever else. This meddling includes thing like removing visual separators, but also includes adding and subtracting suffixes and prefixes as necessary to render the telephone number or URI there globally reachable and meaningful. Or in some cases, it includes nulling them out entirely because some other header (like PAI) is doing their job in a way that the intermediary likes better. Nothing that we do on the originating side will prevent intermediaries that want to alter these numbers form doing so -- including sticking them in a PASSporT object we tunnel in the SIP request. All that would do is encourage those intermediaries to change the numbers in the PASSporT object too. Like, years ago, we entertained just having a new SIP header field that would contain the canonical number as the authentication service saw it - but merely adding another field cannot get around the intermediaries: they will know it's there and they will do what they want to it. "canon" has no magic powers that would save it from the same fate.

At the end of the day, if you are on the receiving side, you are left to inspect whatever is left after intermediaries get through with the message. This remains one of the most important reasons that "canon" (which now means carrying the header and payload PASSporT objects) is optional: the philosophy behind canonicalization is that what matters isn't some value that the authentication service mandates, but instead how the two sides understand the numbers as they receive them. The originating side may initially direct the request to some local seven digital telephone number: but by the time that gets to the terminating side, a country code and area code might be added to it. They both "mean" the same number, and the authentication service that signs the request exercises the canonicalization process in order to capture what it thinks the originator "meant" for the global environment.

Moreover, to your specific argument, here's the rub: because this is a security function, carrying the canonical value in "canon" cannot really help unless the verification service already knows how to turn the value already in the From (or PAI or whatever) into the canonical value anyway. Why not? Because if I get a From with "" and the PASSporT object in canon says the orig is a tn value "12012142102", how is the verification service supposed to know whether or not this is a cut-and-paste attack? If the verification service just blindly trusted that the contents of the PASSporT object's orig were equivalent to the URI in the From, it would never be able to tell whether or not the PASSporT object actually belonged with this call. The value of "canon" is only there for debugging and optimization purposes, we say this many times in the spec. It is NOT there to tunnel some "secret" value for the telephone number between the authentication service and verification service, as that would be a huge security hole. And it wouldn't work anyway because as I said above intermediaries could just change it. The neat thing about not including "canon" is that intermediaries can't change something that isn't in the message. This was effectively the argument Hadriel and others made back in the day.

You can argue that the verification service will sometimes not have sufficient information to arrive at the same canonicalization as the authentication service, and I agree. In some cases it won't: like when calls escape from really opaque private branches, or in if one end is in some weird variable-length dialing plan, or if a nationally-specific service number is used, or whatever. I just think that in order for those calls to realistically get routed and expect identity to work, they need to express identifiers in a way that is actually useful to the rest of the world. We formerly had some text in rfc4474bis that recommended (against the normative guidance of RFC3261, incidentally) that authentication services alter the To and From header fields to conform with the canonicalizations that they performed if those changes warranted notice. Ultimately, though, I took that out because the potential intermediary interference after the fact makes it moot. The question is not whether the verification service trusts the bits the authentication service claims it saw, the question is whether or not the verification service can derive an identity equal to that from the values it sees in the SIP request.

Ultimately, implementations need to use numbers in a sane way in order to have any expectation that SIP will work. In those cases where the use of numbers is sane enough that SIP will work, then I think Identity will probably work too.

Jon Peterson
Neustar, Inc.

From: Alan Ford <<>>
Date: Thursday, September 15, 2016 at 12:06 PM
To: Brian Rosen <<>>
Cc: Jon Peterson <<>>, "<>" <<>>, Christer Holmberg <<>>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

Hi Brian,

The problem is on the receiving end. I see a number as the source or destination, and decide it’s a tn: so try to construct a passport object with a tn: and validate it as such, but this fails. This is because the sender sent it as a sip: URI instead. But because there’s no canon, I don’t know how to reconstruct the passport so can’t validate.


On 15 Sep 2016, at 20:01, Brian Rosen <<>> wrote:

Okay, got it.  Pity the poor blokes who have to DTMF these extensions, but I get it.

So, what really is correct behavior here?  The call is sent with an internal extension as a SIP URI, the mechanism tries to set an Identity header, and what?

If it does not have a credential for that TN, it shouldn’t be trying to sign using a TN credential.

If it has a credential for the SIP ID, then the scope of that credential wouldn’t be a telephone number, it would be a domain, and the recipient should be able to figure out what is happening.

Where is the problem?


On Sep 15, 2016, at 2:40 PM, Alan Ford <<>> wrote:

Hi all,

I’m involved in the interop testing of early STIR implementations at Sipit, and we have quickly run into issues around understanding how the sender has encoded the source/destination. One person’s tn: is another person’s sip: URI; the rules from the draft simply assume that any purely-numeric user part is a telephone number, which is not always the case in the real world. Without any context, when you call a numeric alias in another domain, you have no idea whether this maps to a telephone number or a SIP URI. If the receiver thinks it’s a tn:, but the sender thinks it’s a SIP URI, then the Identity will not validate.

In short, I agree with Christer that the canon is far more important than the draft suggests, and is needed whenever there could be any ambiguity about how a sender has encoded (or a receiver would encode) some of the data (which, frankly, is most B2B scenarios).

Indeed, I would go probably further and suggest the canon SHOULD always be included, - i.e. MUST, unless it is known to be operating within a controlled environment where all entities that may be validating the Identity header have a common understanding on its construction.

The second reason I think that future implementers would thank you for guidance like this is to enable extensibility. Say we wanted to add protection of Display Name - and in the SIP world this is very important since endpoints will typically display only display name if it is present, so provides a trivial way of bypassing human visual validation. Today, that would be achieved by defining a new ppt that added this field. Which is all well and good, but both the sender and the receiver would need to support this new ppt, and this is by no means guaranteed. So for maximum compatibility what would a sender do? Should a sender include multiple Identity headers of multiple ppts, hoping one is supported by the far end? The overhead there would be huge. If canon was always included, then (and I’m not saying this should necessarily be baseline spec, since it’s too big a change at this stage) a receiver could validate the signature of the canon, rather than reconstructing it, and then validate field-by-field for the fields it cares/knows about.


On 13 Sep 2016, at 23:30, Peterson, Jon <<>> wrote:

The more values there are in a SIP request that are candidates for the identity of the caller, the more likely we are going to entertain corner cases like this. There is no guarantee that the canonicalized identity in the From header field will be identical to one in PAI - why carry PAI if it would be? - and similarly if there are multiple PAIs there's no guarantee that they will all canonicalize to the same form. Somehow, though, in those RFC3324 trust environments, you are supposed to be able to know which PAI contains the identity that you care about for this purpose, the identity of the originator of the call. STIR can't tell you how to find that, only local trust domain policy can. I don't think the burden is on STIR to make this unambiguous when apparently the trust domains already can and do.

But, of course, when carrying the "canon" parameter, it will have one value for the originating telephone number, say, and that will match the canonicalized form of one of those identities and not the others. If your trust domain introduces this ambiguity into every call, then your trust domain should probably set a local policy of sending "canon" with every call. I'm not sure there's much more to say about it than that in the core specs, though.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <<>>
Date: Monday, September 12, 2016 at 10:31 AM
To: Jon Peterson <<>>, "<>" <<>>
Subject: RE: [stir] 4474bis: Why only RECOMMEND when multiple identities?


Ok, maybe “multiple identities” was the wrong wording.

My point was that, even if you know you should derive the identity from PAI instead of From, you can have two P-Asserted-Identity header fields, and as far as I understand there is no guarantee that the canonicalized form of those match.



From: Peterson, Jon []
Sent: 09 September 2016 20:11
To: Christer Holmberg <<>>;<>
Subject: Re: [stir] 4474bis: Why only RECOMMEND when multiple identities?

The only normative RECOMMEND in Section 8 is for cases "where local policy canonicalizes the identity into a form different form how it appears in the From header field." That doesn't have anything to do with multiple identities. The text in the previous sentence notes that it is talking about a case where "the canonical identity derives from the P-Asserted-Identity field rather than the From header field," not a case where identities based on both appear in different Identity headers.

If P-Asserted-Identity is present, surely that's where you should be looking for identity information. As I've argued several times in the past, this is no more or less ambiguous than the practical use of P-Asserted-Identity in the field today: nothing about the request tells you "use PAI instead of From" other than the presence of PAI. Because of all the RFC3324 trust domain stuff that Mark Watson talked us into back in the day, it's hard to say anything more than that it's a matter of local policy, as nothing about the protocol tells you whether or not you are in an RFC3324 trust domain. Thus far, I gather this hasn't impeded the adoption of PAI. I did ask the WG in Berlin if we should include some more explicit indicator that would tell you that an Identity header came from PAI rather than From, and the consensus was not to.

We are largely punting on why you might have multiple Identity headers present in the same request: this is included for forward compatibility. The most likely use cases are ones where extensions will differentiate the Identity headers. The recommendation to include "canon" here just enables some potential implementation optimizations (e.g. Verifier canonicalizes the identity in PAI, then compares to value in "canon" to save cycles before computing the identity string and checking for breakage).

Jon Peterson
Neustar, Inc.

From: stir <<>> on behalf of Christer Holmberg <<>>
Date: Friday, September 9, 2016 at 4:32 AM
To: "<>" <<>>
Subject: [stir] 4474bis: Why only RECOMMEND when multiple identities?


Section 8 of draft-4474bis says (or, that’s at least my reading) that, if the SIP request contains multiple identities (e.g. if the request in addition to the From header field contains one or more P-Asserted-Identity header fields), it is RECOMMENDED to include “canon”, so that the verifier knows which identity to verify.

Why is this only RECOMMENDED? If there are more than one identity, shouldn’t it be a MUST? I don’t think we want the verifier to try all identities, and see which one (if any) works, do we?

Now, the text DOES talk about “local policy” when it comes to choosing between From and PAI for deriving the identity, so perhaps we could say “MUST, unless local policy defines from where the identity is retrieved”, or something like that…


stir mailing list<>

stir mailing list<>