Re: [stir] RFC 8224

[Marc Petit-Huguenin <[e-mail]>]

On 4/7/21 1:43 PM, Marc Petit-Huguenin wrote:
> On 4/7/21 1:06 PM, Christer Holmberg wrote:
>> 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=p65539t161720
>>>>> 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]
>>>>> 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.

In fact after reading again the ABNF in RFC 3966, the first bullet point process in 8.3 would not get rid of the digits after ";phone-context=", as in the example in section 6 of RFC 3966, so that would not work in that case.  But that works in the example below because the context does not contain a number.

So there is something missing.

> 
>>
>> 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.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=p65539t16172
>>>>> 0
>>>>> 6731m169121c110882s1_1220390100-1617434405
>>>>> Call-ID: p65539t1617206731m169121c110882s2
>>>>> CSeq: 1 INVITE
>>>>> Max-Forwards: 66
>>>>> Content-Length: 896
>>>>> Via: SIP/2.0/TCP
>>>>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk55555
>>>>> 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]
>>>>> x
>>>>> xx.mccxxx.3gppnetwork.org;user=phone,response="",nonce="",realm="",u
>>>>> s
>>>>> ername=[e-mail]<mailto:xxxx
>>>>> 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;ici
>>>>> 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;regst
>>>>> 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:[e-mail]
>>>>> 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.mcc
>>>>> 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:[e-mail]
>>>>> 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.mcc
>>>>> 3 [e-mail];user=phone>
>>>>>
>>>>> From: Christer Holmberg
>>>>> <[e-mail]<mailto:[e-mail]
>>>>> 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]42
>>>>>> 0
>>>>>> .mcc312.3gppnetwork.org;user=phone
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> -- 
> 
> 
> 
> 


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