From nobody Fri Aug 1 05:00:12 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1D71ABB2F for ; Fri, 1 Aug 2014 05:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4gIPCILC8sd for ; Fri, 1 Aug 2014 05:00:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33621A0ADC for ; Fri, 1 Aug 2014 05:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9366; q=dns/txt; s=iport; t=1406894405; x=1408104005; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=nZnLiPtvIWmhgnOTRyNnF+xLmxCBDbhdDJKaXerXXBA=; b=jWE0vwNy+EHeu1f9okGec1Lfyl5qqaooJe37EUxoapnpe0w3Qcem6gIB e7RgkJRZ7b8Z5eGEtiibzgFkKtBuukZ0vziVFTESRTgkkG49ZIQHflLpx AejR98ifT08eJB8lf45WpkwEiEGNre/0hukB3y5pk0Z9jjMOX+a+UX42u M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAFyA21OtJV2d/2dsb2JhbABbgw1SVwTLfgqHSwGBBhZ3hAMBAQECAQEBAQE3NAQTBgEIEQEDAQEBChQJLgsUAwYJAQQBEggBCweIHwgNyWQXjxs+gymBHAWXTJkBg0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,779,1400025600"; d="scan'208";a="344473856" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2014 12:00:04 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s71C046u014929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:00:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:00:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Sergio Garcia Murillo , "straw@ietf.org" Thread-Topic: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] Thread-Index: Ac+tgBxn0upMU2JnQYKQ71uP3jDX+A== Date: Fri, 1 Aug 2014 12:00:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282FF832@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.238] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/Wm4d-_bpjbbK7s2Qnb8DjHSdCsQ Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 12:00:11 -0000 > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Sergio Garcia Mu= rillo > Sent: Wednesday, July 30, 2014 3:20 PM > To: straw@ietf.org > Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft > STRAW minutes] >=20 > The sole purpose of a B2BUA is to become and endpoint (well two endpoints= in > fact) between two other endpoints: >=20 > Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a > logical entity that receives a request and processes it as a > user agent server (UAS). In order to determine how the request > should be answered, it acts as a user agent client (UAC) and > generates requests. Yes, B2BA is a trusted proxy through which SIP signaling will be exchanged = over TLS. B2BUA offers end-edge-end security i.e. it allows hop-by-hop trus= t between intermediaries and does not provide end-to-end security. With B2B= UA the assumption is that MIM involved in SIP signaling have mutual trust r= elationship.=20 We can update the draft to make it more clear in the Introduction. Cheers, -Tiru >=20 > Best regards > Sergio >=20 > On 30/07/2014 11:34, Stephen Farrell wrote: > > 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) an= d 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 oth= er SIP > enhancements as well. > >> > >> > >> > >> Thanks > >> > >> Partha > >> > >> > >> > >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer > >> Holmberg > >> Sent: Saturday, July 26, 2014 7:54 PM > >> To: straw@ietf.org > >> Cc: Richard Barnes (rlb@ipv.sx); 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 cha= irs 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 regar= ding > 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 c= ause > 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 > > straw@ietf.org > > https://www.ietf.org/mailman/listinfo/straw >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw