Re: [stir] RFC 8224

Marc Petit-Huguenin <marc@petit-huguenin.org> Wed, 07 April 2021 17:25 UTC

Return-Path: <marc@petit-huguenin.org>
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 600A83A22CC for <stir@ietfa.amsl.com>; Wed, 7 Apr 2021 10:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUB-2f-HiaJ8 for <stir@ietfa.amsl.com>; Wed, 7 Apr 2021 10:25:24 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CA63A229E for <stir@ietf.org>; Wed, 7 Apr 2021 10:25:17 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:d250:99ff:fedf:93cd] (unknown [IPv6:2601:648:8400:8e7d:d250:99ff:fedf:93cd]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 71977AE255; Wed, 7 Apr 2021 19:25:11 +0200 (CEST)
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Zerr, Brad" <BZerr@tnsi.com>, Chris Wendt <chris-ietf@chriswendt.net>
Cc: Cullen Jennings <fluffy@iii.ca>, IETF STIR Mail List <stir@ietf.org>, Eric Rescorla <ekr@rtfm.com>, Jon Peterson <jon.peterson@neustar.biz>, "Toy, Arthur" <atoy@tnsi.com>
References: <DM6PR15MB4108EDAC1D320CA0132CFFE3C8779@DM6PR15MB4108.namprd15.prod.outlook.com> <85B1C6DA-6128-4D4D-A0A4-499C03CA390D@iii.ca> <AM0PR07MB3860550B5D4DB10FAA5EF0D293769@AM0PR07MB3860.eurprd07.prod.outlook.com> <ca269d6c-5b64-1c2d-3c30-06ecbe1945ee@petit-huguenin.org> <AM0PR07MB3860D8B8F633F8AD911CA47893759@AM0PR07MB3860.eurprd07.prod.outlook.com> <DM6PR15MB4108A6CF60DB1FB40C427C7FC8759@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38609183F83C41834AC0BDB493759@AM0PR07MB3860.eurprd07.prod.outlook.com> <5BE0F62B-2DE2-4073-BB7D-47DA2E1584B4@chriswendt.net> <DM6PR15MB41081CB035395CBE61904150C8759@DM6PR15MB4108.namprd15.prod.outlook.com> <AM0PR07MB38609494607756BB997F14D293759@AM0PR07MB3860.eurprd07.prod.outlook.com> <e91411bb-e524-8532-8df5-8658ba552a68@petit-huguenin.org> <AM0PR07MB3860CAF8EA7ACA8B65B0729D93759@AM0PR07MB3860.eurprd07.prod.outlook.com>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
Message-ID: <e5abeb7e-c192-11ad-b534-13e614547327@petit-huguenin.org>
Date: Wed, 07 Apr 2021 10:25:10 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <AM0PR07MB3860CAF8EA7ACA8B65B0729D93759@AM0PR07MB3860.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/wZzPmxo8dEje943DK3ILfEdRHWI>
Subject: Re: [stir] RFC 8224
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 07 Apr 2021 17:25:34 -0000

1. Section 8.1:

The origin is either in the From header or in the P-Asserted-Identity header, in the example below we have both, but which one to use is a matter of local policy, so we are going to process all 3 (one in the From, two in the PAI):

orig1: sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org;tag=p65539t1617206731m169121c110882s1_1220390100-1617434405
orig2: sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
orig3: tel:xxxxxxxxx

The destination is always in the To header:

dest: sip:*99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org@ims.mncxxx.mccxxx.3gppnetwork.org;user=phone

2. Section 8.1

Per this section, SIP URIs containing a user=phone parameter or tel URI contain a phone numbers.  Everything else does not contain a phone number.

Here only orig3 and dest contains a phone number, and need to be canonicalized using section 8.3.  The part subject to canonicalization is the user part of the URI:

orig3: xxxxxxxxx
dest: *99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org

orig1 and orig2 are canonicalized using section 8.5.  The input is the whole URI:

orig1: sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org
orig2: ip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org

3. Section 8.3

Both orig3 and dest are canonicalized by removing everything but digits, '*' and '#':

orig3: xxxxxxxxx (I suppose)
dest: *99

We check that both are globally routable.  It is not possible to say for orig3, but dest is definitively not globally routable (does not start with a leading country code).  That means that we cannot use that for the destination.  The next bullet point could be used to make that string routable, but that's probably something that should have been done before hitting the authentication service.

4. Section 8.4

Both orig1 and orig2 are canonicalized:

orig1: sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org
orig2: sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org

Now local policy chooses between orig1, orig2 and orig3:

"orig":{"uri":"sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org}

"orig":{"uri":"sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org"}

"orig":{"tn":"xxxxxxxxx"}

"dest" cannot be populated.



On 4/7/21 9:54 AM, Christer Holmberg wrote:
> Hi,
> 
>>> Maybe the problem with the To header is the phone-context parameter. The RFC 8224 procedures do not cover the presence of the parameter: the parameter
>>> is not removed, nor is it added to the tn. And, the generic SIP canonicalization procedures does not remove the parameter either.
>>
>> That is not my understanding of RFC 8224 section 8.1 and 8.3.
> 
> What is your understanding?
> 
> Regards,
> 
> Christer
> 
> 
> 
>> From: Zerr, Brad <BZerr@tnsi.com>
>> Sent: keskiviikko 7. huhtikuuta 2021 18.26
>> To: Chris Wendt <chris-ietf@chriswendt.net>; Christer Holmberg <christer.holmberg@ericsson.com>
>> Cc: Marc Petit-Huguenin <marc@petit-huguenin.org>; Cullen Jennings <fluffy@iii.ca>; IETF STIR Mail List <stir@ietf.org>; Eric Rescorla <ekr@rtfm.com>; Jon Peterson <jon.peterson@neustar.biz>; Toy, Arthur <atoy@tnsi.com>
>> Subject: RE: [stir] RFC 8224
>>
>> Hi Chris,
>>
>> Here is a little background that got this conversation going.
>>
>> One of our customers sent us a SIP INVITE so we could perform the Stir-Shaken Signing for them.  The customer performed the translations on their MMTEL TAS to translate *55 to a 10 digit number.  When we receive the SIP INVITE for signing, it had the REQ-URI with the 10 digit number and the TO header with *55, see below.  Our applications rejected this because of the TO header (whether it is right or wrong is to be determined).  So we start questioning how * and # short codes should be handled.
>>
>> FYI, I “x” out information to keep anonymous
>>
>> INVITE sip:+xxxxxxxxxx;phone-context=imsmncXXXmccXXXXgppnetworkorg@ims.mncxxx.mcc3xxx.3gppnetwork.org;user=phone SIP/2.0
>> To: sip:*99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org@ims.mncxxx.mccxxx.3gppnetwork.org;user=phone
>> From: sip:+1xxxxxxxxxx@ims.mncxxxx.mccxxx.3gppnetwork.org;tag=p65539t1617206731m169121c110882s1_1220390100-1617434405
>> Call-ID: p65539t1617206731m169121c110882s2
>> CSeq: 1 INVITE
>> Max-Forwards: 66
>> Content-Length: 896
>> Via: SIP/2.0/TCP xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk555555yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
>> Via: SIP/2.0/TCP xxxxxxx:5082;branch=z9hG4bK1220390081-337970536
>> Route: sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr
>> Route: sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%2Bxxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%40ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
>> Record-Route: sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.org@scscf2.ims.mncxxxx.mccxxxx.3gppnetwork.org:5060;maddr=xxxxxxxxx;lr
>> Contact: sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype="cellular";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel<sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel>"
>> Content-Type: application/sdp
>> Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
>> Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
>> Supported: timer, 100rel, path, precondition, replaces
>> P-Asserted-Identity: sip:xxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org
>> P-Asserted-Identity: tel:xxxxxxxxx
>> Proxy-Authorization: Digest uri=sip:*99;phone-context=ims.mnc4xxx.mccxxx.3gppnetwork.org@ims.mncxxx.mccxxx.3gppnetwork.org;user=phone,response="",nonce="",realm="",username=xxxxxxxxxxxxxx@ims.mncxxx.mcc3xxx.3gppnetwork.org<mailto:xxxxxxxxxxxxxx@ims.mncxxx.mcc3xxx.3gppnetwork.org>
>> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org
>> P-Access-Network-Info: 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-cell-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
>> Min-SE: 900
>> Session-Expires: 1800
>> P-Charging-Vector: icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;icid-generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org;orig-ioi=ims.mncxxx.mccxxxx.3gppnetwork.org
>> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
>> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
>> P-Served-User: sip:xxxxxxxxxxx@ims.mnc420.mcc312.3gppnetwork.org;sescase=orig;regstate=reg
>> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
>> P-Early-Media: supported
>> Session-ID: 7c386176b888d13d404845e189d6885b
>>
>> From: Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
>> Sent: Wednesday, April 7, 2021 10:10 AM
>> To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
>> Cc: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; Marc Petit-Huguenin <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>; Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy, Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>> Subject: Re: [stir] RFC 8224
>>
>> This is a legit question for RFC8224 and agree with the answers, but just in case it’s relevant you would not send these types of SIP URIs as dest in context of STIR/SHAKEN (over NNI/peering relationship) which only supports tel URIs currently.  That may not be your use-case but just wanted to clarify in case it was relevant.  I would be curious to know the context if you are willing to share though, i am guessing intra network use case between device and app server?  Definitely interested in those cases, for me in context of delegate certs.
>>
>> -Chris
>>
>>
>>
>> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
>>
>> Hi,
>>
>> ´*´ can be used as such in a SIP-URI, but ‘#’ would have to be escaped.
>>
>> So:
>>
>> To: sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone
>>
>> …is ok, but;
>>
>> To: sip:#55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone>
>>
>> …is NOT ok. Instead:
>>
>> To: sip:%2355;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone
>>
>> …will have to be used.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> From: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>
>> Sent: keskiviikko 7. huhtikuuta 2021 14.27
>> To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; Marc Petit-Huguenin <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>; Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy, Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>> Subject: RE: [stir] RFC 8224
>>
>> Good Morning.
>>
>> Would you mind providing an example of what the TO header should look like for both a * and # dial to help clear up?  Assume they are leading characters in the TO header.
>>
>> Example of what is being sent today:
>>
>> To: sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone
>>
>> To: sip:#55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone>
>>
>> From: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
>> Sent: Wednesday, April 7, 2021 3:14 AM
>> To: Marc Petit-Huguenin <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>; Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>>; Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>; Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy, Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>> Subject: RE: [stir] RFC 8224
>>
>> Hi,
>>
>>> I think the question was about the format to use before canonicalization.
>>>
>>> My understanding of RFC 3986 is that `#` should be escaped because it is the delimiter for an URI fragment. Fragments are not defined in SIP URIs, but a generic URI parser may still remove everything after and including '#'.
>>
>> "#" will have to be escaped in a SIP-URI, e.g., in a To header field.
>>
>> But, Section 8.3 of RFC 8224 has nothing to do with a SIP-URI or the To header field.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>> OTOH there is no need to escape '*' as it is part of the `sub-delims` rule.
>>
>> so
>>
>> ....
>> To: sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone
>> ....
>>
>> is fine, but dialing directly an extension would be:
>>
>> ....
>> To: sip:+14085550460%2377@example.org;user=phone
>> ....
>>
>> On 4/6/21 5:43 AM, Christer Holmberg wrote:
>>> Hi,
>>>
>>> %2A is not the ASCII format of *, it is the escaped (see RFC 3261).
>>>
>>> And, the syntax allows both * and #, so no need to escape (in fact, it is not even possible to escape in this case):
>>>
>>> tn-spec = 1*tn-char
>>> tn-char = "#" / "*" / DIGIT
>>>
>>> Also, note that RFC 8224 does not define the syntax of the To header field - that is done in RFC 3261. The telephone number described in Section 8.3 of RFC 8224 will be included in the PASSPort (RFC 8225).
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> On Behalf Of Cullen Jennings
>>> Sent: tiistai 6. huhtikuuta 2021 15.30
>>> To: Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com>>; IETF STIR Mail List <stir@ietf.org<mailto:stir@ietf.org>>
>>> Cc: chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>; Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>; Jon Peterson <jon.peterson@neustar.biz<mailto:jon.peterson@neustar.biz>>; Toy, Arthur <atoy@tnsi.com<mailto:atoy@tnsi.com>>
>>> Subject: Re: [stir] RFC 8224
>>>
>>>
>>> Adding to STIR mailing list …
>>>
>>>
>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <BZerr@tnsi.com<mailto:BZerr@tnsi.com<mailto:BZerr@tnsi.com%3cmailto:BZerr@tnsi.com>>> wrote:
>>>
>>> Good Morning.
>>>
>>> This may not be the correct process, so let me know if I should ask this in a different forum.
>>>
>>> I had a question regarding section 8.3 when it comes to * and # handling. Is this stating that when a * or # proceeds a digit string (i.e. *55), it should be in ASCI Format for the * (i.e. %2A)
>>>
>>> <image001.png>
>>>
>>> So Instead of this:
>>>
>>> To: sip:*55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone
>>>
>>> It should be this
>>>
>>> To: sip:%2A55;phone-context=ims.mnc420.mcc312.3gppnetwork.org@ims.mnc420.mcc312.3gppnetwork.org;user=phone
>>>
>>>
>>>
>>
>>
> 


-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug