Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes]

[Stephen Farrell <[e-mail]>]

on vacation, back in a week

terminating DTLS-SRTP is maybe fine but means being one of the
endpoints intended to be involved in the TLS session. Doing a
MITM on TLS is  not at all fine.

S.

On 30/07/14 02:34, Parthasarathi R wrote:
> Hi all,
> 
>  
> 
> I have different view than the security folks look at this draft. This draft
> intention is not to violate RFC 2804. In case this draft is not
> standardized, all B2BUA handling DTLS-SRTP will end up in violating RFC 2804
> due to the lack of guidelines/standards to follow. Please look into this
> draft from SIP recording architecture in B2BUA (Fig 1 of RFC 7245) usage
> perspective wherein the senders/receiver is informed about the call
> recording (like call centre usage scenario) and no RFC 2804 violation.
> 
>  
> 
> In IETF-90 meeting, the security concerns are raised about this draft usage.
> It will be good to document as part of this document if it is really
> security issue. I'm not seeing any major security concerns as B2BUA is yet
> another UA. Please let me know the list of security concern specific to
> B2BUA in DTLS-SRTP.
> 
>  
> 
> In reality, B2BUA terminating DTLS-SRTP is not avoidable because of the
> different codec profile between the deployed SIP UAs. Say SIPoWS in browser
> (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of today and SIP
> Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to terminate the
> media in the middle as there is no solution exists in IETF for the same. The
> lack of standard leads to proprietary session border controller (SBC)
> solutions which breaks other SIP enhancements as well.
> 
>  
> 
> Thanks
> 
> Partha
> 
>  
> 
> From: straw [mailto:[e-mail]] On Behalf Of Christer Holmberg
> Sent: Saturday, July 26, 2014 7:54 PM
> To: [e-mail]
> Cc: Richard Barnes ([e-mail]); Sean Turner; Stephen Farrell
> Subject: [straw] IETF#90: Draft STRAW minutes
> 
>  
> 
> (Co-chair)
> 
>  
> 
> Hi,
> 
>  
> 
> Below are the STRAW minutes that the chairs intend to upload.
> 
>  
> 
> However, before we do that, we would like to ask the community to take a
> look at least at the notes associated with the DTLS-SRTP presentation, as it
> caused lots of discussion.
> 
>  
> 
> Note that the minutes do not contain who-said-what information (that can be
> found elsewhere), but if you think there are some important things missing,
> or if you think something is wrong, please let the chairs now.
> 
>  
> 
> Thanks!
> 
>  
> 
> Regards,
> 
>  
> 
> Christer & Victor
> 
>  
> 
> -------------------
> 
>  
> 
> IETF 90 - STRAW
> 
> 1150-1320 EDT    Friday Afternoon Session I
> 
>  
> 
>  
> 
> Topic:     Agenda bashing, IETF Note Well and WG status
> 
> Presenter: Christer Holmberg (co-chair)
> 
> Slides:
> http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf
> 
> Draft:     N/A
> 
>  
> 
>  
> 
> No issues were identified.
> 
>  
> 
>  
> 
>  
> 
> Topic:     Guidelines to support RTCP in B2BUAs
> 
> Presenter: Lorenzo Miniero
> 
> Slides:
> http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf 
> 
> Draft:     draft-ietf-straw-b2bua-rtcp 
> 
>  
> 
>  
> 
> It was indicated that XR needs to be looked into, to see whether something
> needs to be covered in the draft.
> 
>  
> 
> It was indicated that the terminology will be aligned with the
> grouping-taxonomy draft. In case there are conflicts, or other issues are
> found, the STRAW community is requested to provide comments on the
> grouping-taxonomy draft.
> 
>  
> 
> It was requested whether the draft should also cover RTP specific issues. It
> was indicated that the scope of the RTCP, and that we should be very careful
> about introducing RTP issues. It was recommended to talk to Colin Perkins
> whether he has any opinions regarding the need to cover RTP.
> 
>  
> 
> I was asked how the document will relate to the work on multisource
> optimisation taking place in AVTEXT.
> 
>  
> 
> It was indicated that the text recommending man in the middle functionality
> for SRTP most likely will cause issues with IESG. After the DTLS-SRTP
> discussion (see further down) it was suggested that the RTCP draft should
> not talk about SRTP.
> 
>  
> 
>  
> 
>  
> 
> Topic:     Taxonomy Discussion
> 
> Presenter: Lorenzo Miniero
> 
> Slides:
> http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf 
> 
> Draft:     All STRAW deliveries 
> 
>  
> 
>  
> 
> It was agreed the STRAW shall use the terms in the avtext-grouping-taxonomy
> document in preference to definitions elsewhere is they are appropriate,
> with a note indicating any differences in other documents that may influence
> understanding.
> 
>  
> 
>  
> 
>  
> 
> Topic:     STUN handling in B2BUAs
> 
> Presenter: Lorenzo Miniero (on behalf of the draft authors)
> 
> Slides:
> http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf 
> 
> Draft:     draft-ram-straw-b2bua-stun 
> 
>  
> 
>  
> 
> It was indicated that B2BUA, due to policy reasons, may strip candidates
> from SDP.
> 
>  
> 
> It was indicated that B2BUAs must be very careful to not perform actions
> that will cause ICE mismatch.
> 
>  
> 
> The chair informed the community that a WG adoption request will be sent out
> within the upcoming weeks.
> 
>  
> 
> It was indicated that the group needs to follow the ICE bis work taking
> place in MMUSIC, in case there will be any impacts on the STRAW draft.
> 
>  
> 
>  
> 
>  
> 
> Topic:     DTLS-SRTP handling in B2BUAs
> 
> Presenter: Lorenzo Miniero (on behalf of the draft authors)
> 
> Slides:
> http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf 
> 
> Draft:     draft-ram-straw-b2bua-dtls-srtp 
> 
>  
> 
>  
> 
> The presentation triggered lots of discussions and controversy, as it was
> seen as an attempt to standardize MITM (man in the middle procedures). While
> people did realize such actions take place in deployments, they claimed that
> IETF/STRAW should not standardize such procedures. It was also indicated
> that it goes against a number of BCP specifications, and RFC 2804. Others
> indicated that the purpose is to make sure that entities doing this kind of
> functionality do it in a way which does not cause interoperability problems,
> which could cause people to not use security to begin with.
> 
>  
> 
> It was indicated that one possible way forward could be to simply document,
> in an informal delivery, how different vendors do things in the network, but
> in such case the vendors should also be listed in the document.
> 
>  
> 
> Before the draft is adopted as a WG item, further discussions need to take
> place. The ADs will help with finding the correct people (security, IESG,
> etc) to involve in such discussions. The chair indicated that the draft
> implements a charter delivery, but that one possible outcome will be to
> remove/re-scope the charter delivery.
> 
>  
> 
>  
> 
>