Re: [stir] RFC 8224

Marc Petit-Huguenin <marc@petit-huguenin.org> Wed, 07 April 2021 16:51 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 6E5DB3A20D4 for <stir@ietfa.amsl.com>; Wed, 7 Apr 2021 09:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 hQ7cWmttDRCa for <stir@ietfa.amsl.com>; Wed, 7 Apr 2021 09:51:15 -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 3402A3A20D3 for <stir@ietf.org>; Wed, 7 Apr 2021 09:51:14 -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) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4183FAE255; Wed, 7 Apr 2021 18:51:10 +0200 (CEST)
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
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>
Message-ID: <e91411bb-e524-8532-8df5-8658ba552a68@petit-huguenin.org>
Date: Wed, 07 Apr 2021 09:51:08 -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: <AM0PR07MB38609494607756BB997F14D293759@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/6tDkVgxkAXXYIqhezICKP-kEIPQ>
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 16:51:21 -0000

On 4/7/21 9:41 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.

> 
> 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