Subject: [MMUSIC] BUNDLE: Attempting to resolve security consideration

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Mar 2017 14:24:17 +0100

Hi,

Last IETF meeting we had discussions regarding the security 
considerations for the MID RTP header extensions regarding the need for 
encrypting the RTP header. On Christer's request I have attempted to 
capture what I believed was the outcome of this discussion into a text 
proposal.

So the intention of the text is to capture the security considerations, 
i.e. known risks and what we believe is necessary to mitigate these 
risks. The conclusion of the discussion was that encrypting the MID in 
RTP header extensions is not necessary, and thus we have a conflict with 
the requirements in RFC 7941. I have attempted to motivate and on that 
basis wavier this requirement for this particular RTP SDES header 
extension. This is captured in last paragraph of section 16.

The risk of implementation tracking lead us into a discussion around a 
algorithm for generating MID Values. I have drafted a proposal for such 
an algorithm in a new Section 14.1 inserted prior to the existing one.

I note that in RTCWeb WG we did discuss that the encryption wavier would 
be done in the security architecture. However, I believe in retrospect 
that not covering this in BUNDLE in a common fashion would be confusing 
and likely cause questions in regards to the requirements of RFC 7941 
when BUNDLE is used in other context than WebRTC.

So please review and provide feedback. I know Christer wants to close 
this issue.

14.1.  Generating Identification-tags

    The identification-tag is exposed on the network layer due to the
    SDES item and RTP header extension defined below.  As this exposes
    the identification-tag beyond contexts where it is normally exposed,
    i.e.  signalling layer additional potential for implementation
    identification exists.  To avoid such risks a RECOMMENDED to be used
    algorithm for how the identification-tag value is generated is
    specified below.  Using this one will ensure that one can't identify
    which of the implementations using this algorithm it is.  The
    algorithm is also designed to keep down the length of the MID SDES
    item to preserve the MTU in RTP packets.

    The value of the identification-tag for a particular media
    description is generated by first determining the unsigned integer
    index of the corresponding m= line in the SDP.  The first m= line in
    the SDP gets index 0, then each subsequent m= line present in the SDP
    gets an index value one value higher the previous line.  The index
    value is then encoded to create the identification-tag value.  The
    encoding is done in following the algorithm.  The integer reminder of
    a division by 64 of the index, i.e. MOD 64, is determined.  The
    reminder is encoded into an UTF-8 (ASCII) character by looking up the
    character from the reminder using Table 1 in [RFC4648].  This
    character is added to the front of the output string.  After that the
    index is updated to the result of the index divided by 64.  If the
    index becomes 0, then conclude the encoding.  If not, then go back
    and the step calculating the reminder.  This algorithm is below
    described using pseudo code.

    # Initialization
    work-index = index
    # index is the index value to encode as unsigned integer
    output = "" # Output string

    # The below must be performed once to encode index=0
    do {
       reminder = work-index MOD 64
       next-char = TableLookup(reminder)
       output = concat(next-char,output)
       work-index = work-index / 64
    } while (work-index >0)

    Examples of input and output:

    Input     Output
    0         A
    1         B
    42        q
    56        4
    63        /
    64        BA
    65        BB
    256       EA
    4095      //

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 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.

    The identfication-tag, when included in the RTP MID SDES item,
    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.  However, the implementation's method for generating
    identfication-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 deduct 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.  At least to prevent third parties from modifying
    the identification-tag value.

    To avoid the security risks associated with tracking of
    implementations, there is RECOMMENDED algorithm for generating
    identification-tags in Section 14.1.  "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.

-- 

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-masked]
----------------------------------------------------------------------

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Mar 2017 08:49:53 -0500

On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund <
[email-masked]> wrote:

> Hi,
>
> Last IETF meeting we had discussions regarding the security considerations
> for the MID RTP header extensions regarding the need for encrypting the RTP
> header. On Christer's request I have attempted to capture what I believed
> was the outcome of this discussion into a text proposal.
>
> i.e. known risks and what we believe is necessary to mitigate these risks.
> The conclusion of the discussion was that encrypting the MID in RTP header
> extensions is not necessary, and thus we have a conflict with the
> requirements in RFC 7941. I have attempted to motivate and on that basis
> wavier this requirement for this particular RTP SDES header extension. This
> is captured in last paragraph of section 16.
>
> algorithm for generating MID Values. I have drafted a proposal for such an
> algorithm in a new Section 14.1 inserted prior to the existing one.
>
> be done in the security architecture. However, I believe in retrospect that
> not covering this in BUNDLE in a common fashion would be confusing and
> likely cause questions in regards to the requirements of RFC 7941 when
> BUNDLE is used in other context than WebRTC.
>
> So please review and provide feedback. I know Christer wants to close this
> issue.
>
>
>    which of the implementations using this algorithm it is.

If you mean which stack, I do not believe that this is actually that useful
a design
consideration. There are going to be a very large number of ways to
fingerprint
stacks. As the rest of the text seems predicated on that design objective,
I do
not think we should make this change.

-Ekr

The
>    Examples of input and output:

This seems way over-prescriptive.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Mar 2017 16:06:21 +0100

Den 2017-03-03 kl. 14:49, skrev Eric Rescorla:
>
>
> On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     considerations for the MID RTP header extensions regarding the need
>     for encrypting the RTP header. On Christer's request I have
>     attempted to capture what I believed was the outcome of this
>     discussion into a text proposal.
>
>     So the intention of the text is to capture the security
>     considerations, i.e. known risks and what we believe is necessary to
>     mitigate these risks. The conclusion of the discussion was that
>     encrypting the MID in RTP header extensions is not necessary, and
>     thus we have a conflict with the requirements in RFC 7941. I have
>     attempted to motivate and on that basis wavier this requirement for
>     this particular RTP SDES header extension. This is captured in last
>     paragraph of section 16.
>
>     The risk of implementation tracking lead us into a discussion around
>     a algorithm for generating MID Values. I have drafted a proposal for
>     such an algorithm in a new Section 14.1 inserted prior to the
>     existing one.
>
>     I note that in RTCWeb WG we did discuss that the encryption wavier
>     would be done in the security architecture. However, I believe in
>     retrospect that not covering this in BUNDLE in a common fashion
>     would be confusing and likely cause questions in regards to the
>     requirements of RFC 7941 when BUNDLE is used in other context than
>     WebRTC.
>
>     So please review and provide feedback. I know Christer wants to
>     close this issue.
>
>
> If you mean which stack, I do not believe that this is actually that
> useful a design
> stacks. As the rest of the text seems predicated on that design
> objective, I do

Okay, what is your view on Section 16, if we remove the first sentence 
of the last paragraph that references 14.1?

We need to get the security considerations in BUNDLE into reasonable 
shape so that we actually can get BUNDLE published.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 4 Mar 2017 12:28:45 -0800

I certainly think we have to remove the 14.1 reference. Other comments
below.
With these comments, I would find this text acceptable.

Isn't this actually required? Both a=fingerprint and a=crypto are
of type TRANSPORT.

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.

This is at typo.

   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"

I assume you mean "deduce"

   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?

   At least to prevent third parties from modifying
   the identification-tag value.

This is not a 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.

   "RTP Header Extension for the

On Fri, Mar 3, 2017 at 7:06 AM, Magnus Westerlund <
[email-masked]> wrote:

> Okay, what is your view on Section 16, if we remove the first sentence of
> the last paragraph that references 14.1?
>
> We need to get the security considerations in BUNDLE into reasonable shape
> so that we actually can get BUNDLE published.
>
> Cheers
>
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 Mar 2017 14:07:07 +0100

Thanks,

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

> Isn't this actually required? Both a=fingerprint and a=crypto are

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.

> 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.

>    identfication-tags could enable fingerprinting of the implementation

Fixed

> I assume you mean "deduce"

Yes.

> not integrity protected? If not, what is the issue here?

Applies to other security mechanisms than SRTP.

>    the identification-tag value.

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

    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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 6 Mar 2017 14:35:41 +0100

2017-03-03 14:24 GMT+01:00 Magnus Westerlund <[email-masked]>:
> When the BUNDLE extension is used, the number of SSRC values within a single RTP session increases, which increases the risk of SSRC collision

This is relevant when there are ~100000000 streams within a single RTP
session. If there are 10 streams, the exact risk is 10 / 2^32 =
2.32e-09.

I think we can live without having to mention this "issue" in every
RTP related specification.

To be clear: stating that "BUNDLE increases the risk of SSRC
collision" is a no sense IMHO.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Mar 2017 05:36:14 -0800

On Mon, Mar 6, 2017 at 5:07 AM, Magnus Westerlund <
[email-masked]> wrote:

> key-management scheme follows this, although a=mikey is IDENTICAL. If one
> uses other security mechanisms, then this is still relevant to capture.

Which security mechanisms are you thinking of here?

> 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.
>

I am fine to remove this paragraph.

> Applies to other security mechanisms than SRTP.

What such mechanisms are there? The only ones I know of that people have
proposed
just encapsulate the entire packet.

>    security of the RTP sessions.

Is this precisely true? Do you ever use the MID extension w/o BUNDLE?
It certainly changes which ICE checks you do.

>    making it vulnerable to targeted attacks.

I would say "Note that if implementations use different methods for
generating
... this could..."

>   The identication-tag is

Still misspelled.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Mar 2017 05:49:09 -0800

On Mon, Mar 6, 2017 at 5:35 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> single RTP session increases, which increases the risk of SSRC collision
>

This actually isn't quite correct (this is just the usual birthday paradox
math)
Assuming I haven't made a mistake, the correct formula is:

1 - (\prod_{i=0}^{9} 2^{32} - i)

> RTP related specification.

I agree with you that this is a relatively small number, but that doesn't
mean we don't
need to consider it. For instance, if SRTP did not use directional keys and
we allowed
each side to choose SSRCs w/o any attempts to suppress collisions, there
would
be a small but non-zero number of calls which used a two-time pad on a
daily basis.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 6 Mar 2017 16:23:15 +0100

> 1 - (\prod_{i=0}^{9} 2^{32} - i)

Right :)

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 7 Mar 2017 10:45:52 +0100

Hi,

Please see inline.

Den 2017-03-06 kl. 14:36, skrev Eric Rescorla:
>
>     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.
>
>

I didn't have any specific security mechanism in mind. I simply want to 
make clear the requirements that arises due to the new mechanisms that 
BUNDLE creates. As you commented I can only think of mechanism that 
protects the whole packet.

> It certainly changes which ICE checks you do.

So lets start with the question of MID without using BUNDLE. As MID is 
used in grouping of media lines use cases, i.e. RFC 5888 there are 
certainly uses. However, there exist no need to signal MIDs on RTP 
session level in those cases as there already exist a one to one mapping 
between the MID and the transport addresses used for that RTP session. 
Only with BUNDLE do the RTP streams from the different m= lines start 
sharing transport context.

So strictly the above is incorrect. What was multiple security context 
due to different RTP sessions, or other sessions are now moved into a 
single context. I think we could reformulate this to say:

    The security considerations defined in [RFC3264] and [RFC5888] apply
    to the BUNDLE extension.  Bundle does not change which information,
    e.g.  RTP streams, that flows over the network.  Primarily it changes
    which addresses and ports, and thus in which (RTP) sessions that the
    information is flowing in.  This affects the security contexts being
    used and can cause previously separated information flows to share
    security context.  This has very little impact on the performance of
    the security mechanism of the RTP sessions, however which actors that
    are present in a particular security context may require additional
    thoughts when applying Bundle.

Is this better?

> I would say "Note that if implementations use different methods for

Yes, I will use this.

> Still misspelled.

Yes, there was actually two misspelled instances left, and I had 
corrected one.

Full section text after corrections:

    The security considerations defined in [RFC3264] and [RFC5888] apply
    to the BUNDLE extension.  Bundle does not change which information,
    e.g.  RTP streams, that flows over the network.  Primarily it changes
    which addresses and ports, and thus in which (RTP) sessions that the
    information is flowing in.  This affects the security contexts being
    used and can cause previously separated information flows to share
    security context.  This has very little impact on the performance of
    the security mechanism of the RTP sessions, however which actors that
    are present in a particular security context may require additional
    thoughts when applying Bundle.

    The identification-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.  Note that if implementations use different methods for
    generating identification-tags this could enable fingerprinting of
    the implementation making it vulnerable to targeted attacks.  The
    identification-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.

-- 

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Mar 2017 09:47:07 -0800

> protects the whole packet.

Yeah, this seems more confusing than illuminating. There are lots of
theoretical
risks that might happen if we had some new security mechanism with unknown
properties.

> certainly uses. However, there exist no need to signal MIDs on RTP session
> level in those cases as there already exist a one to one mapping between
> the MID and the transport addresses used for that RTP session. Only with
> BUNDLE do the RTP streams from the different m= lines start sharing
> transport context.
>

That's what I meant by "MID extension". Sorry for the confusion.

So strictly the above is incorrect. What was multiple security context due
> to different RTP sessions, or other sessions are now moved into a single
> context. I think we could reformulate this to say:
>

But it still seems to be false because of the MID signaling in SDP.

I also don't understand the last line.

-Ekr

>       The identication-tag is
>>
>>
>> Still misspelled.
>>
>
> Yes, there was actually two misspelled instances left, and I had corrected
> one.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Mar 2017 10:51:09 +0100

Hi,

EKR, I think I understood your issue with the SDP MID usage. I 
restructured the section to move the issues with moving the MID into RTP 
layer as the second paragraph and made it clear that this is a new 
security consideration compared to before in the introduction.

Regarding the integrity and authenticity I have made some small changes. 
I don't see how removing the requirements help, even if they are 
normally resolved when using an existing mechanism. I guess this is is a 
matter of view. I am not comfortable with simple assuming that people 
will use a security mechanism and therefore this is not an issue. And it 
makes future work to analyses potential mechanism a bit harder as one 
have to redo more analysis, such as in PERC.

Anyway here is an updated text. I have sent the XML of this one to 
Christer and he has told me he will update the PR he already have.

    The security considerations defined in [RFC3264] and [RFC5888] apply
    to the BUNDLE extension.  Bundle does not change which information,
    e.g.  RTP streams, that flows over the network, with the exception of
    the usage of the MID SDES item as discussed below.  Primarily it
    changes which addresses and ports, and thus in which (RTP) sessions
    that the information is flowing in.  This affects the security
    contexts being used and can cause previously separated information
    flows to share security context.  This has very little impact on the
    performance of the security mechanism of the RTP sessions.  In cases
    where one would have applied different security policies on the
    different RTP streams being bundled, or where the parties having
    access to the security contexts would have differed between the RTP
    stream additional analysis of the implications are needed before
    selecting to apply BUNDLE.

    configurations and other security mechanisms protecting the whole
    RTP/RTCP packets will provide the necessary protection.

    When the BUNDLE extension is used, a single set of security
    credentials over the bundled media descriptions will need to be used,
    at least per direction or endpoint.  When using SRTP this will be the
    case, at least for the IETF defined key-management solutions due to
    their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their
    classification in [I-D.ietf-mmusic-sdp-mux-attributes].

Den 2017-03-07 kl. 18:47, skrev Eric Rescorla:
>
>
> On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund
>     I didn't have any specific security mechanism in mind. I simply want
>     to make clear the requirements that arises due to the new mechanisms
>     that BUNDLE creates. As you commented I can only think of mechanism
>     that protects the whole packet.
>
>
>     So lets start with the question of MID without using BUNDLE. As MID
>     is used in grouping of media lines use cases, i.e. RFC 5888 there
>     are certainly uses. However, there exist no need to signal MIDs on
>     RTP session level in those cases as there already exist a one to one
>     mapping between the MID and the transport addresses used for that
>     RTP session. Only with BUNDLE do the RTP streams from the different
>     m= lines start sharing transport context.
>
>
>     So strictly the above is incorrect. What was multiple security
>     context due to different RTP sessions, or other sessions are now
>     moved into a single context. I think we could reformulate this to say:
>
>     <tel:%2B46%2010%207148287>
>     <tel:%2B46%2073%200949079>
>     <mailto:[email-masked]>

-- 

Magnus Westerlund

Media Technologies, Ericsson Research

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Mar 2017 07:31:37 -0800

On Fri, Mar 10, 2017 at 1:51 AM, Magnus Westerlund <
[email-masked]> wrote:

> layer as the second paragraph and made it clear that this is a new security
> consideration compared to before in the introduction.
>
> Regarding the integrity and authenticity I have made some small changes. I
> don't see how removing the requirements help, even if they are normally
> resolved when using an existing mechanism. I guess this is is a matter of
> view. I am not comfortable with simple assuming that people will use a
> security mechanism and therefore this is not an issue. And it makes future
> work to analyses potential mechanism a bit harder as one have to redo more
> analysis, such as in PERC.
>

What I am trying to do is to avoid confusing people who think that SRTP is
fine but
some other mechanism which they might actually use is not fine. With that
said,
I consider your current text to be clear enogh on this point.

>    e.g.  RTP streams, that flows over the network, with the exception of

e.g. has a comma after it.

>    at least per direction or endpoint.

Actually, why does this have to be the case? I mean, we require it, but
if you have the MID extension, you could easily not do this.

> When using SRTP this will be the

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Mar 2017 09:47:05 +0100

> if you have the MID extension, you could easily not do this.

You are correct, this is actually misstating the problem. It is not the 
security credentials that need to be a single set. Any SDP level 
security configuration used on individual media description MUST be 
possible to use when creating a bundle group across the full or a 
sub-set of the media description offered as a bundle group.

This works fine for the below listed ones by following the limiations 
indicated in SDP MUX attributes, i.e. transport or identical. But for a 
future mechanism that is defined with bundle in mind from the start 
could have individual configurations.

>        classification in [I-D.ietf-mmusic-sdp-mux-attributes].

I will have to think on how to re-write this.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 26 Mar 2017 13:41:46 -0500

Hi,

I have attempted to address the issue discussed below by reformulating 
that paragraph to read:

    When the BUNDLE extension is used, the set of configurations of the
    security mechanism used in all the bundled media descriptions will
    need to be compatible for simultaneously use, at least per direction
    or endpoint.  When using SRTP this will be the case, at least for the
    IETF defined key-management solutions due to their SDP attributes
    (a=crypto, a=fingerprint, a=mikey) and their classification in
    [I-D.ietf-mmusic-sdp-mux-attributes].

So, does this work?

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Mar 2017 09:20:52 -0500

Hi,

I have created a PR for the proposed update of the security 
consideration text.

https://github.com/cdh4u/draft-sdp-bundle/pull/30

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Mar 2017 09:52:56 -0500

On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund <
[email-masked]> wrote:

>    or endpoint.

I'm not sure I understand what "compatible for simultaneously use" means.

-Ekr

When using SRTP this will be the case, at least for the

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Mar 2017 10:21:09 -0500

Den 2017-03-27 kl. 09:52, skrev Eric Rescorla:
>
>
> On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund
>     I have attempted to address the issue discussed below by
>     reformulating that paragraph to read:
>

That if one have multiple configurations they can co-exist in the same 
BUNDLED context beging used in parallel. Is this better?

    When the BUNDLE extension is used, the set of configurations of the
    security mechanism used in all the bundled media descriptions will
    need to be compatible so that they can simultaneously used in
    parallel, at least per direction or endpoint.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Mar 2017 11:02:29 -0500

LGTM

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Mar 2017 15:09:54 +0000

Hi Ekr,

Just to verify, are you now ok with the text in the PR?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 27 March 2017 19:02
To: Magnus Westerlund <[email-masked]>
Cc: [email-masked]; mmusic (E-mail) <[email-masked]>
Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration

LGTM

On Mon, Mar 27, 2017 at 10:21 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
Den 2017-03-27 kl. 09:52, skrev Eric Rescorla:

On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
wrote:

    Hi,

That if one have multiple configurations they can co-exist in the same BUNDLED context beging used in parallel. Is this better?

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                 | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------