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

From: RFC Errata System <[email-masked]>
Date: Sat, 27 Mar 2021 13:48:39 -0700 (PDT)

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 <[email-masked]>

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

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Mar 2021 12:48:23 -0400

I think this errata should be approved.

Russ

> On Mar 27, 2021, at 4:48 PM, RFC Errata System <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 28 Mar 2021 15:56:05 -0600

@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 <[email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 28 Mar 2021 15:42:35 -0700

See the examples in section 4.1.1 of RFC 8224.

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

---

From: Chris Wendt <[email-masked]>
Date: Sun, 28 Mar 2021 20:45:31 -0400

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 <[email-masked]> wrote:
> 
> Email: [email-masked] <mailto:[email-masked]>
> Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.org/>
> Profile: https://www.linkedin.com/in/petithug <https://www.linkedin.com/in/petithug>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 31 Mar 2021 12:15:51 -0700

The errata may be incomplete.  Section 4 says:

"The signed-identity-digest contains a base64 encoding of a PASSporT [RFC8225]."

I understand that as similar to what Cullen said, i.e. `base64(base64Url(header).base64url(payload).base64url(sig))`.

I think the errata should change that to:

"The signed-identity-digest contains a PASSporT which is encoded as specified in [RFC8225]."