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

["Parthasarathi R" <[e-mail]>]

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.

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