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

[Christer Holmberg <[e-mail]>]

(As co-chair)

People are of course also welcome to (actually, encouraged to) bash on the list, between meetings :)

Regards,

Christer

-----Original Message-----
From: Lorenzo Miniero [mailto:[e-mail]] 
Sent: 29. lokakuuta 2014 9:19
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