Re: [stir] [Technical Errata Reported] RFC8224 (6499)

[Chris Wendt <[e-mail]>]

Yes, so just to explain, we inherited base64url from RFC7519 JWT, so i think the errata is correct, but I believe no-one, i’m aware of at least, actually followed base64 vs base64url for implementing 8224 simply because JWT implementation and interop is so widely accepted at this point (although i didn’t do the homework to see what the potential breakage would be).  To be clear this is only for the PASSporT/JWT value in the identity header not any of the parameters that come afterword.

To Cullen’s point, i think because from 4474 to 8224 the switch as i recall was just a signature to a JWT/PASSporT, this probably is different enough that any implementation of 4474 identity would not be compatible to begin with, if the SBC would even touch the contents of the header values. But again, we have a lot of 8224 identity headers passing in SP networks and i have not heard of any interop issues, from everything i’ve heard most networks have been turning on identity headers passing through SBCs for the first time.  And i believe most SBCs do not evaluate the identity header, only until you get to the point where the verification service is the value parsed, as far as i’m aware.

-Chris

> On Mar 28, 2021, at 6:42 PM, Marc Petit-Huguenin <[e-mail]> wrote:
> 
> See the examples in section 4.1.1 of RFC 8224.
> 
> On 3/28/21 2:56 PM, Cullen Jennings wrote:
>> @Chris ….
>> Uh, I’m not sure. I’m not up to speed on this enough and certainly defer to the people that know more than me.
>> I agree the passport is bas64url encoded, but are the strings we are talking about here done the same way? It looks like 4474 has them as base64 encoded.
>> My read was the passport string was base64url encoded, then that string was used with combined and encdoed a second time with base64 encode to go in the identity header.
>> Anyways, I have no idea what should happen here but the more I looked at it, the less obvious it was to me.
>>  I’d love to hear from Chris ?
>> Anyways … as a practical point, If you move the Identity header from using base64 in 4474, to base64url in 8224, it seems likely that lots of SBC will reject them. That will be particularly frustrating to debug given it will not reject all of them where the different characters in the alphabet don’t occur.
>>> On Mar 28, 2021, at 10:48 AM, Russ Housley <[e-mail]> wrote:
>>> 
>>> I think this errata should be approved.
>>> 
>>> Russ
>>> 
>>>> On Mar 27, 2021, at 4:48 PM, RFC Errata System <[e-mail]> wrote:
>>>> 
>>>> The following errata report has been submitted for RFC8224,
>>>> "Authenticated Identity Management in the Session Initiation Protocol (SIP)".
>>>> 
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> https://www.rfc-editor.org/errata/eid6499
>>>> 
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Marc Petit-Huguenin <[e-mail]>
>>>> 
>>>> Section: 4
>>>> 
>>>> Original Text
>>>> -------------
>>>> Identity = "Identity" HCOLON signed-identity-digest SEMI
>>>>         ident-info *( SEMI ident-info-params )
>>>> signed-identity-digest = 1*(base64-char / ".")
>>>> ident-info = "info" EQUAL ident-info-uri
>>>> ident-info-uri = LAQUOT absoluteURI RAQUOT
>>>> ident-info-params = ident-info-alg / ident-type /
>>>>   ident-info-extension
>>>> ident-info-alg = "alg" EQUAL token
>>>> ident-type = "ppt" EQUAL token
>>>> ident-info-extension = generic-param
>>>> 
>>>> base64-char = ALPHA / DIGIT / "/" / "+"
>>>> 
>>>> 
>>>> Corrected Text
>>>> --------------
>>>> Identity = "Identity" HCOLON signed-identity-digest SEMI
>>>>         ident-info *( SEMI ident-info-params )
>>>> signed-identity-digest = 1*(base64url-char / ".")
>>>> ident-info = "info" EQUAL ident-info-uri
>>>> ident-info-uri = LAQUOT absoluteURI RAQUOT
>>>> ident-info-params = ident-info-alg / ident-type /
>>>>   ident-info-extension
>>>> ident-info-alg = "alg" EQUAL token
>>>> ident-type = "ppt" EQUAL token
>>>> ident-info-extension = generic-param
>>>> 
>>>> base64url-char = ALPHA / DIGIT / "-" / "_"
>>>> 
>>>> 
>>>> Notes
>>>> -----
>>>> RFC 8225 makes it clear that the encoding is BASE4URL, not the standard BASE64 encoding.
>>>> 
>>>> Instructions:
>>>> -------------
>>>> This erratum is currently posted as "Reported". If necessary, please
>>>> use "Reply All" to discuss whether it should be verified or
>>>> rejected. When a decision is reached, the verifying party
>>>> can log in to change the status and edit the report, if necessary.
>>>> 
>>>> --------------------------------------
>>>> RFC8224 (draft-ietf-stir-rfc4474bis-16)
>>>> --------------------------------------
>>>> Title               : Authenticated Identity Management in the Session Initiation Protocol (SIP)
>>>> Publication Date    : February 2018
>>>> Author(s)           : J. Peterson, C. Jennings, E. Rescorla, C. Wendt
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Secure Telephone Identity Revisited
>>>> Area                : Applications and Real-Time
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>> 
> 
> 
> -- 
> Marc Petit-Huguenin
> Email: [e-mail] <mailto:[e-mail]>
> Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.org/>
> Profile: https://www.linkedin.com/in/petithug <https://www.linkedin.com/in/petithug>