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

[Lorenzo Miniero <[e-mail]>]

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.

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


-- 
Lorenzo Miniero, COB

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