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

[Christer Holmberg <[e-mail]>]

(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.

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.
> >
> >
> >
> >
> >
> >