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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: straw [mailto:[e-mail]] On Behalf Of Sergio Garcia Murillo
> Sent: Wednesday, July 30, 2014 3:20 PM
> To: [e-mail]
> Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft
> STRAW minutes]
> 
> The sole purpose of a B2BUA is to become and endpoint (well two endpoints in
> fact) between two other endpoints:
> 
> Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
>           logical entity that receives a request and processes it as a
>           user agent server (UAS).  In order to determine how the request
>           should be answered, it acts as a user agent client (UAC) and
>           generates requests.

Yes, B2BA is a trusted proxy through which SIP signaling will be exchanged over TLS. B2BUA offers end-edge-end security i.e. it allows hop-by-hop trust between intermediaries and does not provide end-to-end security. With B2BUA the assumption is that MIM involved in SIP signaling have mutual trust relationship. 

We can update the draft to make it more clear in the Introduction.

Cheers,
-Tiru

> 
> Best regards
> Sergio
> 
> On 30/07/2014 11:34, Stephen Farrell wrote:
> > 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.
> >>
> >>
> >>
> >>
> >>
> >>
> > _______________________________________________
> > straw mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/straw
> 
> _______________________________________________
> straw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/straw