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

[Lorenzo Miniero <[e-mail]>]

On Thu, 30 Oct 2014 10:56:18 +0000
Stephen Farrell <[e-mail]> wrote:

> 
> 
> On 30/10/14 07:07, Lorenzo Miniero wrote:
> > On Thu, 30 Oct 2014 05:20:37 +0530 "Parthasarathi R"
> > <[e-mail]> wrote:
> > 
> >> Hi Lorenzo,
> >> 
> >> I'm not seeing the convincing mechanism in your proposal which
> >> overcome MITM issue except trusting B2BUA. The most complex
> >> requirement in your e-mail is that
> >> 
> >> <snip> " Without preventing additional mechanismsto be involved
> >> for
> >>> end-to-end validation of some kind, of course.
> >> </snip>
> >> 
> >> Could you please elaborate end-to-end validation in your mind.
> >> 
> > 
> > 
> > Hi Partha,
> > 
> > sorry, I should have been clearer about an aspect. I agree it's still
> > MITM: when I said "everything else's MITM" I actually meant
> > "everything else is not any different from a MITM attack", and that's
> > why I believe the trust is an important aspect.
> 
> And the IETF has also decided a number of times to not MITM TLS.
> The impact of making that mistake would be huge and none of the
> proponents of the various MITM schemes have ever evaluated that
> impact as part of their proposal. That, and the fact that changing
> from a two-part to a multi-party security protocol is very very
> hard are among the reasons that all such proposals so far have
> been DOA.
> 
> Gratuitously throwing the misplaced word "trust" into such a
> discussion does not help.
> 
> S.
> 


I don't disagree, so I won't argue (especially since I'm all but a security expert). I'll just reinstate that my only concern, and I'm sure I'm not alone in this, is the risk of dropping a whole set of scenarios STRAW identified, and leave them in the wild without guidance on how to address them. The text I proposed is probably not the right one, and one can do better, but I'd rather say something than nothing at all. I already mentioned some attempts in other WGs to accomodate similar scenarios that *might* be first steps in the right direction, and I'm sure more will follow.

Lorenzo


> > 
> > About the additional mechanism, I don't have any specific solution in
> > mind. It's my understanding, though, that the IETF community has
> > understood there's a problem to solve there, and is already trying to
> > address it somehow, which is why I continue to believe we shouldn't
> > give up on it either. For insta,ce, I do recall a presentation at the
> > AVTCORE session in Toronto which tried to address a similar concern:
> > 
> > http://www.ietf.org/proceedings/90/slides/slides-90-avtcore-6.pdf
> > 
> > The presentation was called "Requirements for Secure RTP Media
> > Switching", which should at least allow for a more proper management
> > of media-aware as well, for instance.  I believe there are use cases
> > that justify both media-aware and media-termination in secure
> > scenarios, and ignoring them will result in the same unpredictable
> > consequences that lead to WGs like BLISS or STRAW itself: without
> > some guide from IETF documents, developers will either drop security
> > entirely (something we obviously don't want) or start doing things
> > one way or another to make it work.
> > 
> > Lorenzo
> > 
> > 
> >> Thanks Partha
> >> 
> >>> -----Original Message----- From: Lorenzo Miniero
> >>> [mailto:[e-mail]] Sent: Wednesday, October 29, 2014
> >>> 12:49 PM To: Christer Holmberg Cc: Parthasarathi R; 'Stephen
> >>> Farrell'; [e-mail]; 'Richard Barnes'; 'Sean Turner' 
> >>> Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE:
> >>> IETF#90: Draft STRAW minutes]
> >>> 
> >>> On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg
> >>> <[e-mail]> wrote:
> >>> 
> >>>> (As co-chair)
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> If anyone has an issue with the general approach suggested by
> >>>> Partha,
> >>> please indicate to on the list, so that we in Honolulu can focus
> >>> on the technical aspects.
> >>>> 
> >>> 
> >>> 
> >>> I'm not convinced that we should give up on those. Media Aware
> >>> and Media Termination are part of the STRAW taxonomy, and act as
> >>> if they just didn't exist doesn't seem the right thing to do
> >>> IMHO.
> >>> 
> >>> In Toronto it has been made clear that there are issues and
> >>> concerns about what looked like standardizing a MITM for media.
> >>> My personal feeling is that this can be considered mostly a
> >>> matter of trust. The B2BUA should not necessarily be a sneaky or
> >>> "transparent" component as long as participants are involved.
> >>> This means that, as long as I trust the B2BUA in any scenario
> >>> that involves Media Aware/Terminartion stuff, and so trust the
> >>> B2BUA to secure the session on the other end or not do anything I
> >>> didn't sign up for, the B2BUA is actually my "peer" in that 
> >>> respect. Without preventing additional mechanismsto be involved
> >>> for end-to-end validation of some kind, of course. Everytihng
> >>> outside of that is, I agree, MITM and shouldn't be avalled or
> >>> fostered in any way.
> >>> 
> >>> These are just some thoughts I tried to give to the idea, and how
> >>> I basically changed the related text in the RTCP draft as well to
> >>> try and address the issue, so I guess there will be plenty of
> >>> time to bash me when I talk about this in Honolulu :-)
> >>> 
> >>> Lorenzo
> >>> 
> >>> 
> >>>> Regards,
> >>>> 
> >>>> Christer
> >>>> 
> >>>> -----Original Message----- From: Parthasarathi R
> >>>> [mailto:[e-mail]] Sent: 29. lokakuuta 2014
> >>>> 1:28 To: 'Stephen Farrell'; Christer Holmberg; [e-mail] 
> >>>> Cc: 'Richard Barnes'; 'Sean Turner' Subject: RE: B2BUA handling
> >>>> in DTLS-SRTP [was RE: [straw] IETF#90:
> >>> Draft STRAW minutes]
> >>>> 
> >>>> Hi all,
> >>>> 
> >>>> One of the way to address MITM issue in STRAW WG B2BUA handling
> >>>> of
> >>> DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of
> >>> draft- ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or
> >>> Media Termination" (Sec 3.2 of
> >>> draft-ram-straw-b2bua-dtls-srtp-00).
> >>>> 
> >>>> By this proposal, the scope of the work is to cover only
> >>>> end-to-end
> >>> DTLS-SRTP through B2BUA. The media relay provides end-to-end
> >>> security but there are challenges w.r.t NAT, forking, ICE,
> >>> identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted
> >>> out in this milestone.
> >>>> 
> >>>> During IETF-90 and in the mailing alias, I haven't heard any
> >>>> concern
> >>> for Media relay handling in B2BUA. please let me know your
> >>> opinion on the same.
> >>>> 
> >>>> Thanks Partha
> >>>> 
> >>>>> -----Original Message----- From: Stephen Farrell
> >>>>> [mailto:[e-mail]] Sent: Wednesday, July 30,
> >>>>> 2014 3:05 PM To: Parthasarathi R; 'Christer Holmberg';
> >>>>> [e-mail] Cc: 'Richard Barnes'; 'Sean Turner' Subject:
> >>>>> Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: 
> >>>>> Draft STRAW minutes]
> >>>>> 
> >>>>> 
> >>>>> 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
> >>> 
> >>> 
> >>> -- Lorenzo Miniero, COB
> >>> 
> >>> Meetecho s.r.l. Web Conferencing and Collaboration Tools 
> >>> http://www.meetecho.com
> >> 
> >> _______________________________________________ straw mailing list 
> >> [e-mail] https://www.ietf.org/mailman/listinfo/straw
> > 
> > 
> 
> _______________________________________________
> straw mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/straw


-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com