Subject: [stir] RFC 4474bis Last Call - Fingerprint

From: "David Frankel" <[email-masked]>
Date: Fri, 2 Sep 2016 11:03:43 -0700

Greetings.

I find myself worried about the following text in the 4474bis draft at 4.1:

"Fourth, if the request contains an SDP message body, and if that SDP
contains one or more "a=fingerprint" attributes, then the JSON key "mky"
MUST appear with the algorithm(s) and value(s) of the fingerprint attributes
(if they differ), following the format given in [I-D.ietf-stir-passport]
Section 3.2.2.2."

As I understand it, this is done to ensure that the fingerprint has not been
altered (perhaps by a "man in the middle") and give confidence that the
media is encrypted end-to-end.

However, I fear that this may break STIR in some not-entirely-uncommon
situations. Public network SIP calls are routinely re-originated (as we've
discussed). Sometimes the RTP will still go end-to-end unaltered, but in
other cases it may be necessary to terminate and re-originate the stream as
well as the SIP messaging. For example, a transit operator might need to
transcode the audio if the operators on either side don't have matching
codecs. For example, a transit operator might transcode wideband audio
between G.722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly
between G.711 a-law and mu-law. (The reality may be that anybody that can
handle a-law can handle mu-law, so transcoding should "never" be required
for G.711.) There could be other examples. I guess for lawful intercept
(CALEA) the interceptor would still be able to LISTEN without altering the
fingerprint, so perhaps that wouldn't break the STIR signature.

I raise the point for discussion. (The details here are a bit outside my
expertise, and I probably missed some earlier discussion.) One possible
suggestion is to change "MUST" to "MAY" in the text I quoted above. This
gives the originator of the call the opportunity to decide whether they want
downstream operators to have the flexibility to alter the fingerprint but
still maintain the end-to-end identity assurance offered with STIR. An
originator may be mostly concerned with protecting their media on the first
hop; this would let them do that (I think).

While protecting the fingerprint is a nice-to-have, I didn't recall it in
the STIR charter or problem statement.

David

David Frankel

ZipDXR LLC

Monte Sereno, CA USA

Tel: 1-800-FRANKEL (1-800-372-6535)

 <http://www.zipdx.info/features/> Watch Our Video!

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Sep 2016 19:02:04 +0000

Hi,

In addition to the cases David presented, there can also be an intermediary disables media by setting the m= line port value to zero. In such cases the intermediary may also remove all fingerprint attributes associated with the m= line.

And, even if all fingerprints sent by the signer reach the verifier, there is no guarantee they will be in the same matter. Not sure whether it matters as far as calculating the signature is concerned, but just to keep in mind...

In general, assuming we are going to use (or at least allow) Appendix F, we cannot change any "MUST" to "MAY", because we need to specify exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: [email-masked]
Subject: [stir] RFC 4474bis Last Call - Fingerprint

Greetings.

"Fourth, if the request contains an SDP message body, and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] Section 3.2.2.2."

As I understand it, this is done to ensure that the fingerprint has not been altered (perhaps by a "man in the middle") and give confidence that the media is encrypted end-to-end.

However, I fear that this may break STIR in some not-entirely-uncommon situations. Public network SIP calls are routinely re-originated (as we've discussed). Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream as well as the SIP messaging. For example, a transit operator might need to transcode the audio if the operators on either side don't have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reality may be that anybody that can handle a-law can handle mu-law, so transcoding should "never" be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA) the interceptor would still be able to LISTEN without altering the fingerprint, so perhaps that wouldn't break the STIR signature.

I raise the point for discussion. (The details here are a bit outside my expertise, and I probably missed some earlier discussion.) One possible suggestion is to change "MUST" to "MAY" in the text I quoted above. This gives the originator of the call the opportunity to decide whether they want downstream operators to have the flexibility to alter the fingerprint but still maintain the end-to-end identity assurance offered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this would let them do that (I think).

While protecting the fingerprint is a nice-to-have, I didn't recall it in the STIR charter or problem statement.

David

David Frankel
ZipDX(r) LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)
Watch Our Video!<http://www.zipdx.info/features/>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Sep 2016 19:04:40 +0000

Correction: "there is no guarantee they will be in the same ORDER".

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 02 September 2016 22:02
To: David Frankel <[email-masked]>; [email-masked]
Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint

Hi,

Regards,

Christer

From: stir [mailto:[email-masked]] On Behalf Of David Frankel
Sent: 02 September 2016 21:04
To: [email-masked]<mailto:[email-masked]>
Subject: [stir] RFC 4474bis Last Call - Fingerprint

Greetings.

David

David Frankel
ZipDX(r) LLC
Monte Sereno, CA USA

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 2 Sep 2016 18:45:51 +0000

However, I fear that this may break STIR in some not-entirely-uncommon situations.

Using "mkey" at all is, I'd say, an extremely uncommon situation today. That could change over time, though.

Public network SIP calls are routinely re-originated (as we’ve discussed). Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream as well as the SIP messaging. For example, a transit operator might need to transcode the audio if the operators on either side don’t have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reality may be that anybody that can handle a-law can handle mu-law, so transcoding should “never” be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA) the interceptor would still be able to LISTEN without altering the fingerprint, so perhaps that wouldn’t break the STIR signature.

We take the presence of "mkey" here as an indication that the user demands confidentiality and wants the call to fail if confidentiality is not available. This is, as I said, not the common situation. But where that is the user's explicit intention, a transcoder can and should be seen as a man-in-the-middle intercepting media and making end-to-end confidentiality impossible.

If intermediaries outright remove some media streams because they don't like the codecs, and with them the resulting keys, but leave other streams and keys intact, we do want that to be a recoverable error - and "canon" as usually can come to the rescue here. This was actually a motivation for the current "mkey" syntax in PASSporT.

Elsewhere (in SIPBRANDY) we recently began exploring the distinction between opportunistically offering crypto parameters in SIP and demanding them. We aspire to basically create profiles in SIPBRANDY that build on rfc4474bis to allow both those options. The strict SIPBRANDY profile will also require things like implementing the authentication and verification service functions in the UA rather than in an intermediary. I am trying to make sure that as rfc4474bis ships we aren't closing any doors that SIPBRANDY will need open. We've already added some support text for it, and I will ponder if there's anything more we could do here that will help enable a more opportunistic use - where the originator is willing to grant some "flexibility" as you say to entities downstream.

 I raise the point for discussion. (The details here are a bit outside my expertise, and I probably missed some earlier discussion.) One possible suggestion is to change “MUST” to “MAY” in the text I quoted above. This gives the originator of the call the opportunity to decide whether they want downstream operators to have the flexibility to alter the fingerprint but still maintain the end-to-end identity assurance offered with STIR. An originator may be mostly concerned with protecting their media on the first hop; this would let them do that (I think).

While protecting the fingerprint is a nice-to-have, I didn’t recall it in the STIR charter or problem statement.

In terms of earlier discussion you might have missed, the PERPASS BCP that rfc4474bis cites motivated this text, which was the then subject of a consensus call taken by the chairs, which the working group affirmed. I rather think the absence of this text would be an impediment to the advancement of the document through the standardization process due to the very strong community support for PERPASS.

Jon Peterson
Neustar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 2 Sep 2016 19:17:00 +0000

PASSporT is designed to allow media streams to be reordered (again, this is one of the cases Jonathan Lennox raised that got us to change the original "mkey" syntax). Setting an "m=" line to zero and removing the associated fingerprint will also be captured by "canon" and should be recoverable - provided of course that the intermediaries are willing to let "canon" through.

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 2, 2016 at 12:02 PM
To: David Frankel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] RFC 4474bis Last Call - Fingerprint

Hi,

And, even if all fingerprints sent by the signer reach the verifier, there is no guarantee they will be in the same matter. Not sure whether it matters as far as calculating the signature is concerned, but just to keep in mind…

In general, assuming we are going to use (or at least allow) Appendix F, we cannot change any “MUST” to “MAY”, because we need to specify exactly what content is used to calculate the signature, as that information will not be carried in the SIP message.

Regards,

Christer

Greetings.

“Fourth, if the request contains an SDP message body, and if that SDP contains one or more "a=fingerprint" attributes, then the JSON key "mky" MUST appear with the algorithm(s) and value(s) of the fingerprint attributes (if they differ), following the format given in [I-D.ietf-stir-passport] Section 3.2.2.2.”

As I understand it, this is done to ensure that the fingerprint has not been altered (perhaps by a “man in the middle”) and give confidence that the media is encrypted end-to-end.

However, I fear that this may break STIR in some not-entirely-uncommon situations. Public network SIP calls are routinely re-originated (as we’ve discussed). Sometimes the RTP will still go end-to-end unaltered, but in other cases it may be necessary to terminate and re-originate the stream as well as the SIP messaging. For example, a transit operator might need to transcode the audio if the operators on either side don’t have matching codecs. For example, a transit operator might transcode wideband audio between G.722.2 (AMR-WB) and G.722. Or between G.729 and G.711. Or possibly between G.711 a-law and mu-law. (The reality may be that anybody that can handle a-law can handle mu-law, so transcoding should “never” be required for G.711.) There could be other examples. I guess for lawful intercept (CALEA) the interceptor would still be able to LISTEN without altering the fingerprint, so perhaps that wouldn’t break the STIR signature.

David

David Frankel
ZipDX® LLC
Monte Sereno, CA USA

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Sep 2016 20:01:05 +0000

Hi,

>PASSporT is designed to allow media streams to be reordered (again, this is one of the >cases Jonathan Lennox raised that got us to change the original "mkey" syntax). Setting an >"m=" line to zero and removing the associated fingerprint will also be captured by "canon" >and should be recoverable - provided of course that the intermediaries are willing to let >"canon" through.

Doesn't that require "canon", and the claims, to be present in the request? In the latest version of 4474bis they are still optional...

Regards,

Christer

Hi,

Regards,

Christer

Greetings.

David

David Frankel
ZipDX(r) LLC
Monte Sereno, CA USA

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 2 Sep 2016 20:12:53 +0000

To recover these if they were removed requires the presence of "canon." That does not mean that "canon" is or should be required.

Again, the decision to make "canon" optional depends on how common we anticipate these removal cases will be, and how heavily we would weigh the cost of increasing the message size every time we use Identity. We've had this discussion a number of times now, including a consensus call at the last meeting, and consistently the conclusion has been to keep "canon" optional. This "mkey" one especially I do not anticipate will result in a common failure condition.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 2, 2016 at 1:01 PM
To: Jon Peterson <[email-masked]<mailto:[email-masked]>>, David Frankel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [stir] RFC 4474bis Last Call - Fingerprint

Hi,

>PASSporT is designed to allow media streams to be reordered (again, this is one of the >cases Jonathan Lennox raised that got us to change the original "mkey" syntax). Setting an >"m=" line to zero…

Doesn’t that require “canon”, and the claims, to be present in the request? In the latest version of 4474bis they are still optional…

Regards,

Christer

Hi,

Regards,

Christer

Greetings.

David

David Frankel
ZipDX® LLC
Monte Sereno, CA USA

---

From: Chris Wendt <[email-masked]>
Date: Tue, 6 Sep 2016 22:33:37 -0400

I did get this comment from other folks as well and for mky, I will be updating in the next release of passport incorporating a MUST for ordering fingerprint values in lexicographic order to guarantee it validating in the case where fingerprint order is changed.

Hopefully this should solve your concerns.

Thanks.

> On Sep 2, 2016, at 4:12 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> From: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> To: Jon Peterson <[email-masked] <mailto:[email-masked]>>, David Frankel <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>> To: David Frankel <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>> From: stir [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of David Frankel
>>> To: [email-masked] <mailto:[email-masked]>
>>> Watch Our Video! <http://www.zipdx.info/features/>
>>>  
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir