Subject: [stir] RFC8224 / Use of a=fingerprint

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 22 Mar 2018 12:14:31 +0000

A few doubts regarding use of a=fingerprint for RFC8224:

4.1.  PASSporT Construction
...

   o  Fourth, if the request contains a Session Description Protocol
      (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 [RFC8225],
      Section 5.2.2.

12.1.  Protected Request Fields
...
  When signing a request that contains a fingerprint of keying material
   in SDP for DTLS-SRTP [RFC5763], this mechanism always provides a
   signature over that fingerprint.  This signature prevents certain
   classes of impersonation attacks in which an attacker forwards or
   cut-and-pastes a legitimate request.  Although the target of the
   attack may accept the request, the attacker will be unable to
   exchange media with the target, as they will not possess a key
   corresponding to the fingerprint.  For example, there are some
   baiting attacks, launched with the REFER method or through social
   engineering, where the attacker receives a request from the target
   and reoriginates it to a third party.  These might not be prevented
   by only a signature over the From, To, and Date, but they could be
   prevented by securing a fingerprint for DTLS-SRTP.  While this is a
   different form of impersonation than is commonly used for
   robocalling, ultimately there is little purpose in establishing the
   identity of the user that originated a SIP request if this assurance
   is not coupled with a comparable assurance over the contents of the
   subsequent media communication.  This signature also reduces the
   potential for active eavesdropping attacks against the SIP media.  In
   environments where DTLS-SRTP is unsupported, however, no field is
   signed and no protections are provided.

i- (with lawyer hat on)
Which one of these statements prevails? I assume it is the former as it is using normative language as "MUST" therefore "a=fingerprint" must be used when it is present.

ii- (with technical hat on)
Wouldn't the attack vector mentioned in 12.1 be applicable for connection oriented media, e.g. a=fingerprint in SDP is used while establishing a MSRP session (and possibly for other cases) as well?

Thanks,
Tolga

---

From: Chris Wendt <[email-masked]>
Date: Sun, 25 Mar 2018 22:26:10 -0400

MSRP is tcp/tls so doesn’t apply to intended the use of a=fingerprint/mky

> On Mar 22, 2018, at 8:14 AM, Asveren, Tolga <[email-masked]> wrote:
> 
> ....
> ....
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 26 Mar 2018 03:52:50 +0000

Could you elaborate more why it is not applicable? Use of a=fingerprint for MSRP is possible per RFCRFC4975:

14.4.  Using TLS in Peer-to-Peer Mode

   TLS can be used with a self-signed certificate as long as there is a
   mechanism for both sides to ascertain that the other side used the
   correct certificate.  When used with SDP and SIP, the correct
   certificate can be verified by passing a fingerprint of the
   certificate in the SDP and ensuring that the SDP has suitable
   integrity protection.  When SIP is used to transport the SDP, the
   integrity can be provided by the SIP Identity mechanism [17].  The
   rest of this section describes the details of this approach.

Thanks,
Tolga

From: Chris Wendt <[email-masked]>
Sent: Sunday, March 25, 2018 10:26 PM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [stir] RFC8224 / Use of a=fingerprint

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

> On Mar 22, 2018, at 8:14 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 26 Mar 2018 19:59:54 -0400

I stand corrected.

Thanks for pointing that out.  It references RFC4474 in that section which RFC8224 replaces, but seems to be to be fairly compatible with the intent of support of fingerprint in RFC8224/8225, although procedures are different of course.

> On Mar 25, 2018, at 11:52 PM, Asveren, Tolga <[email-masked]> wrote:
> 
> From: Chris Wendt <[email-masked] <mailto:[email-masked]>> 
> To: Asveren, Tolga <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > On Mar 22, 2018, at 8:14 AM, Asveren, Tolga <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>