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

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 <tasveren@rbbn.com> wrote:
> 
> 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 <chris-ietf@chriswendt.net <mailto:chris-ietf@chriswendt.net>> 
> Sent: Sunday, March 25, 2018 10:26 PM
> To: Asveren, Tolga <tasveren@rbbn.com <mailto:tasveren@rbbn.com>>
> Cc: stir@ietf.org <mailto:stir@ietf.org>; jon.peterson@neustar.biz <mailto:jon.peterson@neustar.biz>
> Subject: Re: [stir] RFC8224 / Use of a=fingerprint
>  
> NOTICE: This email was received from an EXTERNAL sender
> 
> 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 <tasveren@rbbn.com <mailto:tasveren@rbbn.com>> wrote:
> > 
> > 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
> > 
> > _______________________________________________
> > stir mailing list
> > stir@ietf.org <mailto:stir@ietf.org>
> > https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>