Re: [rtcweb] BUNDLE: Attempting to resolve security consideration

Thanks,

I have updated the text, new text at the bottom after replies.


Den 2017-03-04 kl. 21:28, skrev Eric Rescorla:
> I certainly think we have to remove the 14.1 reference. Other comments
> below.
> With these comments, I would find this text acceptable.
>
> 16.  Security Considerations
>
>    The security considerations defined in [RFC3264] and [RFC5888] apply
>    to the BUNDLE extension.  Bundle does not change which information
>    flows over the network but only changes which addresses and ports
>    that information is flowing on and thus has very little impact on the
>    security of the RTP sessions.
>
>    When the BUNDLE extension is used, a single set of security
>    credentials might be used for all media streams specified by a BUNDLE
>    group.
>
> Isn't this actually required? Both a=fingerprint and a=crypto are
> of type TRANSPORT.

I think you are correct assuming that one is using SRTP. All the IETF 
key-management scheme follows this, although a=mikey is IDENTICAL. If 
one uses other security mechanisms, then this is still relevant to capture.

>
>
>    When the BUNDLE extension is used, the number of SSRC values within a
>    single RTP session increases, which increases the risk of SSRC
>    collision.  [RFC4568] describes how SSRC collision may weaken SRTP
>    and SRTCP encryption in certain situations.
>
> This seems like it's only true in a very limited sense of situations.
> In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision
> would require that one direction generate colliding SSRCs. That's
> certainly possible, but should be straightforward to avoid in most
> architectures. In any case, the base rate SSRC collision is far to
> high to rely on statistics to prevent it.

I don't think this paragraph is that relevant. I would lean towards 
removing it. With DTLS-SRTP that per direction specific transport keys 
even an SSRC collision is not an issue, assuming that crypto end-point 
is not actually trying to forward two different RTP streams using the 
same SSRC, which would be so broken also on RTP level, in addition to 
revealing the plaintext for some ciphers.

We actually don't have a mechanism that always work for preventing SSRC 
collisions by ensuring agreement of SSRC usage.

>
>
>    The identfication-tag, when included in the RTP MID SDES item,
>
> This is at typo.
>
>    independent of transport, RTCP SDES packet or RTP header extension,
>    can expose the value to parties beyond the signaling chain.
>    Therefore, the identification-tag MUST NOT contain any user related
>    information.
>
> You should just use the JSEP language here.
>
>    o  An "a=mid" line, as specified in [RFC5888], Section 4.  All MID
>       values MUST be generated in a fashion that does not leak user
>       information, e.g., randomly or using a per-PeerConnection counter,
>       and SHOULD be 3 bytes or less, to allow them to efficiently fit
>       into the RTP header extension defined in
>
>    However, the implementation's method for generating
>    identfication-tags could enable fingerprinting of the implementation
>
> typo in "identification"
>

Fixed

>
>    making it vulnerable to targeted attacks.  The identication-tag is
>    exposed on the RTP stream level when included in the RTP header
>    extensions, however what it reveals of the RTP media stream structure
>    of the endpoint and application was already possible to deduct from
>
> I assume you mean "deduce"

Yes.

>
>    the RTP streams without the MID SDES header extensions.  As the
>    identification-tag is also used to route the media stream to the
>    right application functionality it is also important that the value
>    received is the one intended by the sender, thus integrity and the
>    authenticity of the source are important to prevent denial of service
>    on the application.
>
> Is there any condition when you are using SRTP that these values are
> not integrity protected? If not, what is the issue here?
>

Applies to other security mechanisms than SRTP.

>
>    At least to prevent third parties from modifying
>    the identification-tag value.
>
> This is not a sentence.

I will repeat it, the requirement is clear from previous sentence.

>
>    To avoid the security risks associated with tracking of
>    implementations, there is RECOMMENDED algorithm for generating
>    identification-tags in Section 14.1.
>
> See above.
>

16.  Security Considerations

    The security considerations defined in [RFC3264] and [RFC5888] apply
    to the BUNDLE extension.  Bundle does not change which information
    flows over the network but only changes which addresses and ports
    that information is flowing on and thus has very little impact on the
    security of the RTP sessions.

    When the BUNDLE extension is used, a single set of security
    credentials might be used for all media streams specified by a BUNDLE
    group.  When using SRTP this is further required at least for the
    IETF defined key-management solutions due to their SDP attributes
    (a=crypto, a=fingerprint, a=mikey) classification in
    [I-D.ietf-mmusic-sdp-mux-attributes].  But for other security
    solutions, this may require further consideration.

    The identfication-tag, independent of transport, RTCP SDES packet or
    RTP header extension, can expose the value to parties beyond the
    signaling chain.  Therefore, the identification-tag values MUST be
    generated in a fashion that does not leak user information, e.g.,
    randomly or using a per-bundle group counter, and SHOULD be 3 bytes
    or less, to allow them to efficiently fit into the MID RTP header
    extension.  However, the implementation's method for generating
    identification-tags could enable fingerprinting of the implementation
    making it vulnerable to targeted attacks.  The identication-tag is
    exposed on the RTP stream level when included in the RTP header
    extensions, however what it reveals of the RTP media stream structure
    of the endpoint and application was already possible to deduce from
    the RTP streams without the MID SDES header extensions.  As the
    identification-tag is also used to route the media stream to the
    right application functionality it is also important that the value
    received is the one intended by the sender, thus integrity and the
    authenticity of the source are important to prevent denial of service
    on the application.  Existing SRTP configurations requires integrity
    protection of both RTCP and RTP header extensions.

    "RTP Header Extension for the RTP Control Protocol (RTCP) Source
    Description Items" [RFC7941] security consideration requires that
    when RTCP is confidentiality protected that any SDES RTP header
    extension carrying an SDES item, like the MID RTP header extension,
    is also protected using commensurate strength algorithms.  However,
    assuming the above requirements and recommendations are followed
    there are no known significant security risks with leaving the MID
    RTP header extension without confidentiality protection.  Thus, the
    requirements in RFC 7941 MAY be ignored for the MID RTP header
    extension.  Security mechanisms for RTP/RTCP are discussed in Options
    for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
    provide the necessary security functions of ensuring the integrity
    and source authenticity.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic