Subject: [stir] I-D Action: draft-peterson-stir-messaging-01.txt

From: [email-masked]
Date: Mon, 22 Feb 2021 15:36:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.

        Title           : Messaging Use Cases and Extensions for STIR
        Authors         : Jon Peterson
                          Chris Wendt
	Filename        : draft-peterson-stir-messaging-01.txt
	Pages           : 10
	Date            : 2021-02-22

Abstract:
   Secure Telephone Identity Revisited (STIR) provides a means of
   attesting the identity of a telephone caller via a signed token in
   order to prevent impersonation of a calling party number, which is a
   key enabler for illegal robocalling.  Similar impersonation is
   sometimes leveraged by bad actors in the text messaging space.  This
   document considers the applicability of STIR's Persona Assertion
   Token (PASSporT) and certificate issuance framework to instant text
   and multimedia messaging use cases, both for messages carried or
   negotiated by SIP, and for non-SIP messaging.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-peterson-stir-messaging/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-peterson-stir-messaging-01
https://datatracker.ietf.org/doc/html/draft-peterson-stir-messaging-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-peterson-stir-messaging-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Feb 2021 20:25:37 +0000

Hi,

Regarding the "msgi" claim, isn't signing the message content (media) outside the scope of STIR? It has nothing do to with user identity (yes, perhaps we could say that about some of the other PASSPort extension claims too, but at least they are related to signaling information).

Also, if we would want to create a claim for the message body content, why not define a generic mechanism that can be used for different MIME types?

Regards,

Christer

-----Original Message-----
From: stir <[email-masked]> On Behalf Of [email-masked]
Sent: tiistai 23. helmikuuta 2021 1.36
To: [email-masked]
Cc: [email-masked]
Subject: [stir] I-D Action: draft-peterson-stir-messaging-01.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 24 Feb 2021 22:42:14 +0000

Hi Christer,

There is probably a line somewhere that we shouldn't cross for what the integrity protection of STIR is supposed to cover, but I'm not sure it's very crisply drawn at this point - I think it's broadly anything we think is an attack vector in the threat model for impersonation. If we fear that a bank could send a signed message, and someone who captured it could do a cut-and-paste replay with a different message, I think we're in the neighborhood of impersonation.

The thinking in stir-messaging is very similar to how RCD (and "rcdi") have been designed - in some respects, it's difficult to distinguish RCD from an instant messaging service. And if we could leverage "mkey" to secure the (likely self-signed) keys used for MSRPoTLS, say, that too is tying the security of the content back to STIR, just as RFC8862 does. 

Staging the message integrity protection at the MIME layer would be fine provided that the things we want to protect are all basically carried as MIME. We could as you suggest define different approaches for different MIME types.

Jon Peterson
Neustar, Inc.

On 2/23/21, 12:25 PM, "stir on behalf of Christer Holmberg" <[email-masked] on behalf of christer.holmberg=[email-masked]> wrote:

    Hi,

    
    Regards,
    
    Christer

---

From: Brian Rosen <[email-masked]>
Date: Thu, 25 Feb 2021 08:46:46 -0500

Just a reminder that location in emergency calls can be carried in a MIME body, as well as what we call “additional data” and protecting that against meddling and spoofing is very important.  There are people looking at this specific issue, but a more generic way to protect a MIME body would be helpful I think.  From my point of view, we don’t need different mechanisms for different MIME types, but we might need different attestation and attestation sources for different MIME types.

Brian

> On Feb 24, 2021, at 5:42 PM, Peterson, Jon <jon.peterson=[email-masked]> wrote:
> 
> 
> Hi Christer,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2021 14:02:46 +0000

Hi,

>Just a reminder that location in emergency calls can be carried in a MIME body, as well as what we call “additional data” and protecting that against meddling and
>spoofing is very important.  There are people looking at this specific issue, but a more generic way to protect a MIME body would be helpful I think. 

Well, you can send location information etc also in RTP, and you don't want a middleman to intercept your RTP stream :)

My point is that I think we need to discuss whether media protection is part of STIR.

> From my point of view, we don’t need different mechanisms for different MIME types, but we might need different attestation and attestation sources for different MIME types.

I think Jon misunderstood. My question/suggestion was actually whether there the *SAME* mechanism could be used for different MIME types.

Regards,

Christer

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Feb 2021 18:53:32 +0000

The scope question of where we draw the line for STIR is the interesting one. Again, I don't see this as fundamentally different than "mkey", and indeed for some cases in messaging, "mkey" may in fact be sufficient by itself.  But the point is, we built STIR intentionally with the hook of "mkey" to support full-suite security, where media security is bound to the signature over a PASSporT (e.g. RFC8862). I don't think it is a significant scope shift for STIR to provide the same feature for messaging. The only place I get a little nervous about that is contemplating the potential use of non-TN identifiers for the message sender and receiver... but even that, I think, is in the scope that RFC8224 intended - just not the scope that RFC8226 intended. For now, I'm happy to look at messaging for STIR solely through the lens of how RFC8226 credentials can help.

Doing some MIME-level protection is fine by me, again, provided that everything we're trying to protect is MIME.

Jon Peterson
Neustar, Inc.

On 2/25/21, 6:02 AM, "Christer Holmberg" <[email-masked]> wrote:

    Hi,

    

    
    Regards,
    
    Christer

    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!pCpd2B-OydVNJvLi54pxu1uCGHBGslL2OVVM2aIcbifLugUvQSIh-UUh_uxZVODMG0UJuA$

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Feb 2021 20:16:23 +0000

Hi,

Perhaps we should have a generic discussion about what is within the scope of STIR as we are moving forward.

Because, to me it seems like we can now use a PASSPort to sign more or less anything.

Regards,

Christer

Get Outlook for iOS

From: Peterson, Jon <[email-masked]>
Sent: Thursday, February 25, 2021 8:53 PM
To: Christer Holmberg; Brian Rosen
Cc: [email-masked]
Subject: Re: [stir] I-D Action: draft-peterson-stir-messaging-01.txt

Jon Peterson

Neustar, Inc.

Hi,

Regards,

Christer

> https://protect2.fireeye.com/v1/url?k=d0b44318-8f2f7a5b-d0b40383-861fcb972bfc-7080816a16bd64d7&q=1&e=23e9c6d3-384f-46cf-b3f5-41aa50059ebb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir__%3B%21%21N14HnBHF%21pCpd2B-OydVNJvLi54pxu1uCGHBGslL2OVVM2aIcbifLugUvQSIh-UUh_uxZVODMG0UJuA%24

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Feb 2021 22:36:18 +0000

Happy to have that discussion – maybe we can use some of stir-messaging’s agenda time for it.

I think a good start to the discussion would be determining whether we think there’s a scope difference between “mkey” to secure DTLS/SRTP and “mkey” to secure MSRPoTLS.

Jon Peterson
Neustar, Inc.

From: Christer Holmberg <[email-masked]>
Date: Thursday, February 25, 2021 at 12:16 PM
To: "Peterson, Jon" <[email-masked]>, Brian Rosen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [stir] I-D Action: draft-peterson-stir-messaging-01.txt

Hi,

Regards,

Christer

Get Outlook for iOS<https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!N14HnBHF!vsUS4L675IQPmklLkJowCpx-D29UXuCMK2JagyAH3al3vMlXB4Sup7_ScOI$ >

________________________________

Jon Peterson
Neustar, Inc.

    Hi,

    Regards,

    Christer

    > https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=d0b44318-8f2f7a5b-d0b40383-861fcb972bfc-7080816a16bd64d7&q=1&e=23e9c6d3-384f-46cf-b3f5-41aa50059ebb&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fstir__*3B*21*21N14HnBHF*21pCpd2B-OydVNJvLi54pxu1uCGHBGslL2OVVM2aIcbifLugUvQSIh-UUh_uxZVODMG0UJuA*24__;JSUlJSUlJSUlJSUlJSUlJQ!!N14HnBHF!vsUS4L675IQPmklLkJowCpx-D29UXuCMK2JagyAH3al3vMlXB4Su9r6EYX8$

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Feb 2021 22:56:11 +0000

Hi,

>I think a good start to the discussion would be determining whether we think there’s a scope difference between “mkey” to secure DTLS/SRTP and “mkey” to secure MSRPoTLS.

I assume you mean “mky”?

I guess the difference is that “mky” does not directly protect the media – it protects signalling information that protects the media :)

But, I hear what you are saying, and one could claim that we allowed usage of PASSport for media protection already from day one when we did RFC 8225.

Regards,

Christer

From: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 25, 2021 at 12:16 PM
To: "Peterson, Jon" <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] I-D Action: draft-peterson-stir-messaging-01.txt

Hi,

Regards,

Christer

Get Outlook for iOS<https://protect2.fireeye.com/v1/url?k=745f3a64-2bc40361-745f7aff-86d2114eab2f-0a41dd8003a9012b&q=1&e=76500b94-3a72-4539-a761-e323c9da5da5&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2Fo0ukef__%3B%21%21N14HnBHF%21u1UKqywy1layQHXqXO6SA7Ie65ocyPMjFboLy0UUQDBq-B-FUHn6RUPTHa7t7dDxgKzjv9c%24>

________________________________
From: Peterson, Jon <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 25, 2021 8:53 PM
To: Christer Holmberg; Brian Rosen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] I-D Action: draft-peterson-stir-messaging-01.txt

Jon Peterson
Neustar, Inc.

On 2/25/21, 6:02 AM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    Regards,

    Christer

    > On Feb 24, 2021, at 5:42 PM, Peterson, Jon <jon.peterson=[email-masked]<mailto:jon.peterson=[email-masked]>> wrote:
    >
    >
    > Hi Christer,
    >
    > On 2/23/21, 12:25 PM, "stir on behalf of Christer Holmberg" <[email-masked] on behalf of christer.holmberg=[email-masked]<mailto:[email-masked]%20on%20behalf%20of%20christer.holmberg=[email-masked]>> wrote:
    >
    >    Hi,
    >
    > [email-masked]<mailto:[email-masked]>
    > https://protect2.fireeye.com/v1/url?k=d0b44318-8f2f7a5b-d0b40383-861fcb972bfc-7080816a16bd64d7&q=1&e=23e9c6d3-384f-46cf-b3f5-41aa50059ebb&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir__%3B%21%21N14HnBHF%21pCpd2B-OydVNJvLi54pxu1uCGHBGslL2OVVM2aIcbifLugUvQSIh-UUh_uxZVODMG0UJuA%24<https://protect2.fireeye.com/v1/url?k=7c8fde65-2314e760-7c8f9efe-86d2114eab2f-c1f126aa49c79985&q=1&e=76500b94-3a72-4539-a761-e323c9da5da5&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dd0b44318-8f2f7a5b-d0b40383-861fcb972bfc-7080816a16bd64d7%26q%3D1%26e%3D23e9c6d3-384f-46cf-b3f5-41aa50059ebb%26u%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2F%2A2Fwww.ietf.org%2A2Fmailman%2A2Flistinfo%2A2Fstir__%2A3B%2A21%2A21N14HnBHF%2A21pCpd2B-OydVNJvLi54pxu1uCGHBGslL2OVVM2aIcbifLugUvQSIh-UUh_uxZVODMG0UJuA%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21N14HnBHF%21u1UKqywy1layQHXqXO6SA7Ie65ocyPMjFboLy0UUQDBq-B-FUHn6RUPTHa7t7dDx_cqVrOc%24>