Subject: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Jan 2018 15:23:35 +0000

Hi,

Related to my issue below, I think it would be good to show a complete example with two Identity header fields in section 4.1 of draft-ietf-stir-passport-divert-01.

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday 4 January 2018 at 12:10
To: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-rfc4474bis-16: Syntax question

Is it still possible to fix this in the document, or do we file an errata once the RFC has been published?

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 3 January 2018 at 20:57
To: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: [stir] draft-ietf-stir-rfc4474bis-16: Syntax question

Hi,

Section 4 says:

   “Note that unlike the prior specification
   in RFC4474, the Identity header field is now allowed to appear more
   than one time in a SIP request.  The revised grammar for the Identity
   header field builds on the ABNF [RFC5234] in RFC 3261 [RFC3261]
   Section 25.  It is as follows:

      Identity = "Identity" HCOLON signed-identity-digest SEMI
      ident-info *( SEMI ident-info-params )
      …”

However, that syntax does NOT allow multiple Identity header fields, according to the rules in RFC 3261:

   “Multiple header field rows with the same field-name MAY be present in
   a message if and only if the entire field-value for that header field
   is defined as a comma-separated list”

It should be something like:

     Identity = "Identity" HCOLON signed-identity * (COMMA signed-identity)
     signed-identity = signed-identity-digest SEMI identi-info * (SEMI ident-info-params)
     …”

Or, misunderstood I have?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 8 Jan 2018 16:05:27 -0600

[as responsible AD]

Christer --

Thanks for looking closely at 4474bis and offering up your comments. 
Based on the current state of things, I don't think changes are 
warranted at this time.

This document is in AUTH48 with sign-offs from all but one author. While 
discovery of a catastrophic error would be enough to warrant additional 
working-group crafting on the document, I don't see anything here that 
is catastrophic. The multiple-header issue you describe is a bit 
confusing, but that appears to be a flaw in RFC3261 more than this 
document. Importantly, the section of 3261 you cite is followed by:

>     The exceptions
>     to this rule are the WWW-Authenticate, Authorization, Proxy-
>     Authenticate, and Proxy-Authorization header fields.  Multiple header
>     field rows with these names MAY be present in a message, but since
>     their grammar does not follow the general form listed inSection 7.3 <https://tools.ietf.org/html/rfc3261#section-7.3>,
>     they MUST NOT be combined into a single header field row.

This, combined with the fact that the syntax of "Identity" *also* 
doesn't follow the general form listed in RFC 3261 section 7.3, means 
that the "...MAY... if and only if..." construct you cite also doesn't 
apply to it. It might have been cleaner to indicate that "Identity" is 
added to the list of exceptions in section 7.3.1 of RFC 3261, but this 
seems to be a lack of tidiness rather than a critical flaw in the document.

I will note that the decision not to allow comma separation appears to 
have been intentional [1], and was mentioned as recently as last June on 
the mailing list [2]. In that light, I believe that your request would 
functionally be asking to reverse prior working group consensus rather 
than fixing an error. We are well past the point of revisiting past 
working group decisions on this document.

/a

____
[1] Although I can't find the corresponding minutes or email, I have a 
vague recollection of discussions about which syntax would be more 
likely to be compatible with exiting RFC4474 implementations, with the 
current syntax reflecting the outcome of those discussions.

[2] https://mailarchive.ietf.org/arch/msg/stir/tAhE7jD6OWTlGHO-MLQavpODm1s

On 1/8/18 09:23, Christer Holmberg wrote:
> Hi,
>
> Related to my issue below, I think it would be good to show a complete 
> example with two Identity header fields in section 4.1 
> of draft-ietf-stir-passport-divert-01.
>
> Regards,
>
> Christer
>
> From: stir <[email-masked] <mailto:[email-masked]>> on 
> behalf of Christer Holmberg <[email-masked] 
> <mailto:[email-masked]>>
> To: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> From: stir <[email-masked] <mailto:[email-masked]>> on 
> behalf of Christer Holmberg <[email-masked] 
> <mailto:[email-masked]>>
> To: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Jan 2018 22:25:25 +0000

Hi,

I don’t want to change any prior decisions at this point, so I am fine with not allowing comma separation. I just hope implementers will realize they have to use the 3261 “exception rules”.

I guess we could clarify it in draft-ietf-stir-passport-divert, though, which defines usage of two header fields.

Regards,

Christer

From: Adam Roach [mailto:[email-masked]]
Sent: 09 January 2018 00:05
To: Christer Holmberg <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

[as responsible AD]

Christer --

Thanks for looking closely at 4474bis and offering up your comments. Based on the current state of things, I don't think changes are warranted at this time.

This document is in AUTH48 with sign-offs from all but one author. While discovery of a catastrophic error would be enough to warrant additional working-group crafting on the document, I don't see anything here that is catastrophic. The multiple-header issue you describe is a bit confusing, but that appears to be a flaw in RFC3261 more than this document. Importantly, the section of 3261 you cite is followed by:

   The exceptions

   their grammar does not follow the general form listed in Section 7.3<https://tools.ietf.org/html/rfc3261#section-7.3>,

This, combined with the fact that the syntax of "Identity" *also* doesn't follow the general form listed in RFC 3261 section 7.3, means that the "...MAY... if and only if..." construct you cite also doesn't apply to it. It might have been cleaner to indicate that "Identity" is added to the list of exceptions in section 7.3.1 of RFC 3261, but this seems to be a lack of tidiness rather than a critical flaw in the document.

I will note that the decision not to allow comma separation appears to have been intentional [1], and was mentioned as recently as last June on the mailing list [2]. In that light, I believe that your request would functionally be asking to reverse prior working group consensus rather than fixing an error. We are well past the point of revisiting past working group decisions on this document.

/a

____
[1] Although I can't find the corresponding minutes or email, I have a vague recollection of discussions about which syntax would be more likely to be compatible with exiting RFC4474 implementations, with the current syntax reflecting the outcome of those discussions.

Regards,

Christer

Regards,

Christer

Hi,

Section 4 says:

Regards,

Christer

stir mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 11 Jan 2018 16:35:08 +0000

The discussion at the STIR meeting in Singapore actually decided on using nesting for divert rather multiple separate PASSporTs (and hence separate Identity headers) - largely motivated by the needs of out-of-band, but following that, as I recall, it was also decided we should have one way to do it between in-band and out-of-band. So my marching orders coming out of that were to providing nesting-only for the next revision of divert, so it would no longer say anything about multiple Identity headers.

Broadly, I'd prefer to keep the multiple Identity header language in 4474bis for forward-compatibility reasons anyway.

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 8, 2018 at 2:25 PM
To: Adam Roach <[email-masked]<mailto:[email-masked]>>, IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

Hi,

Regards,

Christer

From: Adam Roach [mailto:[email-masked]]
Sent: 09 January 2018 00:05
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

[as responsible AD]

Christer --

   The exceptions

   their grammar does not follow the general form listed in Section 7.3<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3261-23section-2D7.3&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=0tfOd9VwMoAvl0JKO2y6wP_mUQxKNpMG7nzhdSG5zik&s=amr22ItfUix8IB4Bw5vlEc22vUYEyij0OTyIiTmZW4o&e=>,

/a

____

[2] https://mailarchive.ietf.org/arch/msg/stir/tAhE7jD6OWTlGHO-MLQavpODm1s<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_stir_tAhE7jD6OWTlGHO-2DMLQavpODm1s&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=0tfOd9VwMoAvl0JKO2y6wP_mUQxKNpMG7nzhdSG5zik&s=vBmyKD1D8ZvSrGhPungiuGhQuBvV-kvtev4wekjtZHk&e=>

Regards,

Christer

Regards,

Christer

Hi,

Section 4 says:

Regards,

Christer

stir mailing list

https://www.ietf.org/mailman/listinfo/stir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=0tfOd9VwMoAvl0JKO2y6wP_mUQxKNpMG7nzhdSG5zik&s=DH7yKHJoDgmb0aq6gqAjFhE7Y_vdix3Pg944il-tNPI&e=>

---

From: Julio Martinez-Minguito <[email-masked]>
Date: Fri, 12 Jan 2018 10:26:01 +0000

Hi,

About the slides from the STIR Singapore meeting:
https://datatracker.ietf.org/meeting/100/materials/slides-100-stir-passport-divert/

If we have user A served by Operator A (originating party), user B served by Operator B (original destination/diverting party) and user C served by Operator C (final destination/diverted party)
It's not good that B's operator signs A's identity. B's operator is not authoritative for A. In a diversion case, I'd rather keep different Identities to enable accountability and separate responsibilities. The Identity added by Operator A includes the signature from A so even Operator C can validate that the original call comes from Operator A. Removing the Identity added by A by the diverting party B removes useful information. It makes that A authority is somewhat delegated to B.

Note also that by removing the original Identity header from Operator A, If the PASSporT is a SHAKEN object with, eventual SHAKEN attest and orig in the PASSporT from the original party will be lost towards the new target C.

/Julio

From: Peterson, Jon [mailto:[email-masked]]
Sent: den 11 januari 2018 17:35
To: Christer Holmberg <[email-masked]>; Adam Roach <[email-masked]>; IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

Jon Peterson
Neustar, Inc.

Hi,

I don't want to change any prior decisions at this point, so I am fine with not allowing comma separation. I just hope implementers will realize they have to use the 3261 "exception rules".

Regards,

Christer

[as responsible AD]

Christer --

   The exceptions

/a

____

Regards,

Christer

Regards,

Christer

Hi,

Section 4 says:

   "Note that unlike the prior specification

      ..."

   "Multiple header field rows with the same field-name MAY be present in
   a message if and only if the entire field-value for that header field
   is defined as a comma-separated list"

     ..."

Regards,

Christer

stir mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Jan 2018 09:30:19 +0000

Hi,

One more comment on this.

No matter if one uses comma separation within a single Identity header field, or multiple Identity header fields, the spec doesn’t say anything about the semantics of the order of the header fields.

For example, in SIP the order of Record-Route, Route, Via etc matters, because it impacts how a SIP message is routed.

My first thought was that it doesn’t really matter in which order Identity header fields are listed in a SIP message, so we don’t need to say anything (in addition to the fact that multiple header fields are allowed).

But, when I read the divert extension slides from Singapore, it says the following:

     “An Identity header with “div” always points to some prior Identity header”

The word *prior* seem to indicate that the order of header fields DOES matter (as the Identity header field does not contain any “sequence number,” or similar mechanism for ordering them).

So, even if divert would use a single Identity header field, shouldn’t 4474bis specify how Identity headers are added to a SIP message?

Otherwise we could end up with a situation with vendor A sending:

Identity: A
Identity: B

…and vendor B sending:

Identity: B
Identity: A

In some case the order may not matter, in some cases it may.

Or?

Regards,

Christer

[as responsible AD]

Christer --

   The exceptions

/a

____

Regards,

Christer

Regards,

Christer

Hi,

Section 4 says:

Regards,

Christer

stir mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jan 2018 08:14:56 +0000

Hi,

Any comment on this?

RFC 3261 does say:

"The relative order of header field rows with the same field name is important."

However, I can’t find any generic rule how  header field rows with the same name are added to a SIP message. Record-Route, Route etc all have header field specific rules (which often are the identical).

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Saturday 13 January 2018 at 11:30
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] draft-ietf-stir-passport-divert: two Identity header fields [was: draft-ietf-stir-rfc4474bis-16: Syntax question]

Hi,

Identity: A
Identity: B

…and vendor B sending:

Identity: B
Identity: A

Or?

Regards,

Christer

[as responsible AD]

Christer --

   The exceptions

/a

____

Regards,

Christer

Regards,

Christer

Hi,

Section 4 says:

Regards,

Christer

stir mailing list