Re: [stir] RFC 8224

[Christer Holmberg <[e-mail]>]

Hi,

>>>>> 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:[e-mail];tag=p65539t1617
>>>>> 20
>>>>> 6731m169121c110882s1_1220390100-1617434405
>>>>> orig2: sip:[e-mail]
>>>>> orig3: tel:xxxxxxxxx
>>>>>
>>>>> The destination is always in the To header:
>>>>>
>>>>> dest:
>>>>> sip:*99;phone-context=[e-mail].
>>>>> mc
>>>>> cxxx.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:[e-mail]
>>>>> orig2: ip:[e-mail]
>>>>
>>>> Where in Section 8 is it defined that phone-context is removed?
>>>
>>> It is removed by not being part of the username (or user part) portion of a SIP URI:
>> 
>> It is part of the user part.
>> 
>> When user=phone is present, the user part is encoded as a telephone-subscriber (RFC 2806), which may contain a phone-context.
>
> Right, I was thinking of user=phone.
>
> phone-context and the other parameters are removed when applying the first bullet point in 8.3.

well, the bullet only talks about specific characters, which means numeric characters of the phone-context would remain...

I think there should be explicit text about tel-URL parameters (in addition to phone-context there are also others).

Regards,

Christer



> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 8.1:
> 
> "First, implementations will ascertain if the user portion of the URI
>    constitutes a telephone number.  Telephone numbers most commonly
>    appear in SIP header field values in the username portion of a SIP
>    URI"
> 
> 8.3:
> 
> "Once an implementation has identified a telephone number, it must
>    construct a number string."
> 
> "o  Implementations MUST drop any "+"s, internal dashes, parentheses,
>       or other non-numeric characters, except for the "#" or "*" keys
>       used in some special service numbers"
> 
>    
>>
>>
>>
>> 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 <[e-mail]>
>>>> Sent: keskiviikko 7. huhtikuuta 2021 18.26
>>>> To: Chris Wendt <[e-mail]>; Christer Holmberg 
>>>> <[e-mail]>
>>>> Cc: Marc Petit-Huguenin <[e-mail]>; Cullen Jennings 
>>>> <[e-mail]>; IETF STIR Mail List <[e-mail]>; Eric Rescorla 
>>>> <[e-mail]>; Jon Peterson <[e-mail]>; Toy, 
>>>> Arthur <[e-mail]>
>>>> 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=[e-mail]
>>>> x x x.mcc3xxx.3gppnetwork.org;user=phone SIP/2.0
>>>> To:
>>>> sip:*99;phone-context=[e-mail].
>>>> m
>>>> c
>>>> cxxx.3gppnetwork.org;user=phone
>>>> From:
>>>> sip:[e-mail];tag=p65539t1617
>>>> 2
>>>> 0
>>>> 6731m169121c110882s1_1220390100-1617434405
>>>> Call-ID: p65539t1617206731m169121c110882s2
>>>> CSeq: 1 INVITE
>>>> Max-Forwards: 66
>>>> Content-Length: 896
>>>> Via: SIP/2.0/TCP
>>>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk5555
>>>> 5
>>>> 5 yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
>>>> 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%
>>>> 2
>>>> B
>>>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%
>>>> 4
>>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
>>>> Record-Route:
>>>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.
>>>> m
>>>> [e-mail].3gppnetwork.
>>>> o
>>>> rg: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:[e-mail]
>>>> P-Asserted-Identity: tel:xxxxxxxxx
>>>> Proxy-Authorization: Digest
>>>> uri=sip:*99;phone-context=[e-mail]
>>>> c
>>>> x
>>>> xx.mccxxx.3gppnetwork.org;user=phone,response="",nonce="",realm="",
>>>> u
>>>> s
>>>> ername=[e-mail]<mailto:xxx
>>>> x x [e-mail]>
>>>> 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-
>>>> c
>>>> e
>>>> ll-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
>>>> Min-SE: 900
>>>> Session-Expires: 1800
>>>> P-Charging-Vector:
>>>> icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;ic
>>>> i
>>>> d
>>>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org;orig-ioi=ims.
>>>> m
>>>> ncxxx.mccxxxx.3gppnetwork.org
>>>> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
>>>> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
>>>> P-Served-User:
>>>> sip:[e-mail];sescase=orig;regs
>>>> t
>>>> a
>>>> te=reg
>>>> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
>>>> P-Early-Media: supported
>>>> Session-ID: 7c386176b888d13d404845e189d6885b
>>>>
>>>> From: Chris Wendt
>>>> <[e-mail]<mailto:[e-mail]>>
>>>> Sent: Wednesday, April 7, 2021 10:10 AM
>>>> To: Christer Holmberg
>>>> <[e-mail]<mailto:christer.holmberg@ericsson.c
>>>> o
>>>> m
>>>>>>
>>>> Cc: Zerr, Brad <[e-mail]<mailto:[e-mail]>>; Marc 
>>>> Petit-Huguenin 
>>>> <[e-mail]<mailto:[e-mail]>>; Cullen 
>>>> Jennings <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List 
>>>> <[e-mail]<mailto:[e-mail]>>; Eric Rescorla 
>>>> <[e-mail]<mailto:[e-mail]>>; Jon Peterson 
>>>> <[e-mail]<mailto:[e-mail]>>; Toy, 
>>>> Arthur <[e-mail]<mailto:[e-mail]>>
>>>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> ´*´ can be used as such in a SIP-URI, but ‘#’ would have to be escaped.
>>>>
>>>> So:
>>>>
>>>> To:
>>>> sip:*55;phone-context=[e-mail]420.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org;user=phone
>>>>
>>>> …is ok, but;
>>>>
>>>> To:
>>>> sip:#55;phone-context=[e-mail]420.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mc
>>>> c
>>>> 3 [e-mail];user=phone>
>>>>
>>>> …is NOT ok. Instead:
>>>>
>>>> To:
>>>> sip:%2355;phone-context=[e-mail]420.
>>>> mcc312.3gppnetwork.org;user=phone
>>>>
>>>> …will have to be used.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> From: Zerr, Brad <[e-mail]<mailto:[e-mail]>>
>>>> Sent: keskiviikko 7. huhtikuuta 2021 14.27
>>>> To: Christer Holmberg
>>>> <[e-mail]<mailto:christer.holmberg@ericsson.c
>>>> o
>>>> m
>>>>>> ; Marc Petit-Huguenin
>>>> <[e-mail]<mailto:[e-mail]>>; Cullen 
>>>> Jennings <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List 
>>>> <[e-mail]<mailto:[e-mail]>>
>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>> Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Jon Peterson 
>>>> <[e-mail]<mailto:[e-mail]>>; Toy, 
>>>> Arthur <[e-mail]<mailto:[e-mail]>>
>>>> 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=[e-mail]420.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org;user=phone
>>>>
>>>> To:
>>>> sip:#55;phone-context=[e-mail]420.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org;user=phone<sip:*55;phone-context=ims.mnc420.mc
>>>> c
>>>> 3 [e-mail];user=phone>
>>>>
>>>> From: Christer Holmberg
>>>> <[e-mail]<mailto:christer.holmberg@ericsson.c
>>>> o
>>>> m
>>>>>>
>>>> Sent: Wednesday, April 7, 2021 3:14 AM
>>>> To: Marc Petit-Huguenin
>>>> <[e-mail]<mailto:[e-mail]>>; Cullen 
>>>> Jennings <[e-mail]<mailto:[e-mail]>>; Zerr, Brad 
>>>> <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List 
>>>> <[e-mail]<mailto:[e-mail]>>
>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>> Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Jon Peterson 
>>>> <[e-mail]<mailto:[e-mail]>>; Toy, 
>>>> Arthur <[e-mail]<mailto:[e-mail]>>
>>>> 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=[e-mail]420.
>>>> m
>>>> c
>>>> c312.3gppnetwork.org;user=phone
>>>> ....
>>>>
>>>> is fine, but dialing directly an extension would be:
>>>>
>>>> ....
>>>> To: sip:[e-mail];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 <[e-mail]<mailto:[e-mail]>> 
>>>>> On Behalf Of Cullen Jennings
>>>>> Sent: tiistai 6. huhtikuuta 2021 15.30
>>>>> To: Zerr, Brad <[e-mail]<mailto:[e-mail]>>; IETF STIR 
>>>>> Mail List <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>>> Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Jon Peterson 
>>>>> <[e-mail]<mailto:[e-mail]>>; Toy, 
>>>>> Arthur <[e-mail]<mailto:[e-mail]>>
>>>>> Subject: Re: [stir] RFC 8224
>>>>>
>>>>>
>>>>> Adding to STIR mailing list …
>>>>>
>>>>>
>>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>> 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=[e-mail]420.
>>>>> m
>>>>> cc312.3gppnetwork.org;user=phone
>>>>>
>>>>> It should be this
>>>>>
>>>>> To:
>>>>> sip:%2A55;phone-context=[e-mail]4
>>>>> 2
>>>>> 0
>>>>> .mcc312.3gppnetwork.org;user=phone
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --




--
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://protect2.fireeye.com/v1/url?k=28d0d527-774bedc5-28d095bc-86073b36ea28-f2c358423b8421cd&q=1&e=78d08abe-b951-45e0-a93d-4a2bc670a4be&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
Profile: https://www.linkedin.com/in/petithug