Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17
Tina TSOU <Tina.Tsou.Zouting@huawei.com> Thu, 23 August 2012 04:36 UTC
Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3DB21F84BF; Wed, 22 Aug 2012 21:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.08
X-Spam-Level:
X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeDCuruMh07p; Wed, 22 Aug 2012 21:36:20 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 06CA721F84B8; Wed, 22 Aug 2012 21:36:19 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJW09263; Wed, 22 Aug 2012 20:36:18 -0800 (PST)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 21:30:32 -0700
Received: from dfweml513-mbx.china.huawei.com ([169.254.3.159]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 22 Aug 2012 21:30:21 -0700
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: Qin Wu <bill.wu@huawei.com>
Thread-Topic: [secdir] Secdir review of draft-ietf-avtcore-monarch-17
Thread-Index: AQHNgBtTN3CPcwvDt0SdX/BDBNBFzZdlQAPegAAjoBqAAWwpjA==
Date: Thu, 23 Aug 2012 04:30:21 +0000
Message-ID: <0AB75B72-FD89-4328-BCF6-CF29A2223B20@huawei.com>
References: <D9F20FFCA69244C59DB1F3E69C2F48EB@china.huawei.com> <58D08DCC-37CD-4DE9-A574-719F5409153C@huawei.com>, <F28317B9B6B74C169E15A3C800BBFC21@china.huawei.com>
In-Reply-To: <F28317B9B6B74C169E15A3C800BBFC21@china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_0AB75B72FD894328BCF6CF29A2223B20huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: The IESG <iesg@ietf.org>, "draft-ietf-avtcore-monarch@tools.ietf.org" <draft-ietf-avtcore-monarch@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Aug 2012 04:36:21 -0000
OK, our replies resolve my comments. Tina On Aug 21, 2012, at 11:46 PM, "Qin Wu" <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote: ----- Original Message ----- From: Tina TSOU<mailto:Tina.Tsou.Zouting@huawei.com> To: Qin Wu<mailto:bill.wu@huawei.com> Cc: draft-ietf-avtcore-monarch@tools.ietf.org<mailto:draft-ietf-avtcore-monarch@tools.ietf.org> ; secdir@ietf.org<mailto:secdir@ietf.org> ; The IESG<mailto:iesg@ietf.org> Sent: Wednesday, August 22, 2012 12:39 PM Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 Here is what I meant: which parties trust each other? The other parties will be excluded from receiving the measurements. What does each case imply in terms of requirements for key management? [Qin]: If the other parties are allowed to receive the measurement, they should be authenticated using SRTP in RFC3711. If the parties that are trusted access to some RTCP flows but not other, authentication using SRTP in RFC3711 also can be used. Regarding key managment requirement, RFC 3711 has already pointed out what key management standards can be used to establish an SRTP cryptographic context.