From bew@cisco.com Mon Mar 1 17:20:29 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193B228C20F for ; Mon, 1 Mar 2010 17:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaizaUHJigzi for ; Mon, 1 Mar 2010 17:20:28 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 59C943A8BEF for ; Mon, 1 Mar 2010 17:20:28 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFL2i0urRN+J/2dsb2JhbACbBnOlFYpwCY0NgmqCEQSDFw X-IronPort-AV: E=Sophos;i="4.49,563,1262563200"; d="scan'208";a="158879610" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2010 01:20:29 +0000 Received: from dhcp-128-107-163-86.cisco.com (dhcp-128-107-163-86.cisco.com [128.107.163.86]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o221KT24018861 for ; Tue, 2 Mar 2010 01:20:29 GMT Message-Id: <03FBD9DB-6F0A-491B-A0A7-6254DC1C83A8@cisco.com> From: Brian Weis To: msec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Mar 2010 17:20:15 -0800 X-Mailer: Apple Mail (2.936) Subject: [MSEC] Agenda items for IETF-77 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 01:20:29 -0000 Greetings, MSEC WG will be meeting in Anaheim. If you would like to propose an agenda item, please send it to me or post it to the list. Thanks, Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Tue Mar 2 08:04:01 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D356D28C185 for ; Tue, 2 Mar 2010 08:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9YBOw3MHS33 for ; Tue, 2 Mar 2010 08:04:01 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 43A4428C17F for ; Tue, 2 Mar 2010 08:04:01 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEbFjEurRN+J/2dsb2JhbACbAnOmW4pyCY1ZgmqCEQSDFw X-IronPort-AV: E=Sophos;i="4.49,568,1262563200"; d="scan'208";a="243501105" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2010 16:04:02 +0000 Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o22G42Dj001267; Tue, 2 Mar 2010 16:04:02 GMT Message-Id: <33DCB880-55B7-45B9-A6A3-814B49040F4D@cisco.com> From: Brian Weis To: Vincent Roca In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Mar 2010 08:04:01 -0800 References: X-Mailer: Apple Mail (2.936) Cc: msec@ietf.org, Sean Turner , "Pasi.Eronen@nokia.com Eronen" , "Polk, William T." Subject: Re: [MSEC] Announcing new Co-Chair for msec X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 16:04:01 -0000 Many thanks to Vincent for his willingness to step into this position of leadership. Thanks, Brian On Mar 2, 2010, at 7:21 AM, Polk, William T. wrote: > I am pleased to announce that Vincent Roca has agreed to serve as > msec WG > co-chair. Vincent has been an active participant and contributor to > the > WG, so I am sure he will hit the ground running! > > Thanks, Vincent, for volunteering and accepting this position. I'm > looking forward to working with you in this new role. > > Tim Polk > -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From vincent.roca@inrialpes.fr Tue Mar 2 08:30:23 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B493A8BC8 for ; Tue, 2 Mar 2010 08:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk7PkG2Tpi0f for ; Tue, 2 Mar 2010 08:30:23 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 8613E3A8B8C for ; Tue, 2 Mar 2010 08:30:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,568,1262559600"; d="scan'208";a="53892833" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 02 Mar 2010 17:30:22 +0100 Message-ID: <4B8D3D1E.8010001@inrialpes.fr> Date: Tue, 02 Mar 2010 17:30:22 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Brian Weis References: <33DCB880-55B7-45B9-A6A3-814B49040F4D@cisco.com> In-Reply-To: <33DCB880-55B7-45B9-A6A3-814B49040F4D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: msec@ietf.org, Sean Turner , "Pasi.Eronen@nokia.com Eronen" Subject: Re: [MSEC] Announcing new Co-Chair for msec X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 16:30:23 -0000 I am very honored by the confidence you have in me. Thanks! See you at Anaheim. Vincent On 03/02/2010 05:04 PM, Brian Weis wrote: > Many thanks to Vincent for his willingness to step into this position > of leadership. > > Thanks, > Brian > > On Mar 2, 2010, at 7:21 AM, Polk, William T. wrote: > >> I am pleased to announce that Vincent Roca has agreed to serve as >> msec WG >> co-chair. Vincent has been an active participant and contributor to the >> WG, so I am sure he will hit the ground running! >> >> Thanks, Vincent, for volunteering and accepting this position. I'm >> looking forward to working with you in this new role. >> >> Tim Polk >> From bew@cisco.com Tue Mar 2 20:55:54 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D7E3A8C1A for ; Tue, 2 Mar 2010 20:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ytvwWNAin9 for ; Tue, 2 Mar 2010 20:55:53 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 634103A81D8 for ; Tue, 2 Mar 2010 20:55:53 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHJ6jUurRN+K/2dsb2JhbACbDHOmFIp4CY1CgmqCEQSDFw X-IronPort-AV: E=Sophos;i="4.49,572,1262563200"; d="scan'208";a="215047975" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2010 04:55:54 +0000 Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o234tsZg001092; Wed, 3 Mar 2010 04:55:54 GMT Message-Id: <125FE3E0-8ED6-44A0-91B2-D35B533FD9B0@cisco.com> From: Brian Weis To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Mar 2010 20:55:53 -0800 X-Mailer: Apple Mail (2.936) Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= Subject: [MSEC] New version of draft-ietf-msec-ipsec-group-counter-modes X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 04:55:54 -0000 Folks, A new version of this WG draft has been published. It addresses Alfred =20= H=CEnes' recent comments, which suggest that the draft should not be =20 specific to AES. The authors concurred, and changes broadening the =20 scope of the draft were minimal. (For example, note the first sentence =20= of the Abstract below.) Comments regarding those changes are =20 appreciated. Thanks, Brian > A new version of I-D, draft-ietf-msec-ipsec-group-counter-=20 > modes-05.txt has been successfuly submitted by Brian Weis and posted =20= > to the IETF repository. > > Filename: draft-ietf-msec-ipsec-group-counter-modes > Revision: 05 > Title: Using Counter Modes with Encapsulating Security = Payload =20 > (ESP) and Authentication Header (AH) to Protect Group Traffic > Creation_date: 2010-03-05 > WG ID: msec > Number_of_pages: 14 > > Abstract: > Counter modes have been defined for block ciphers such as the > Advanced Encryption Standard (AES). Counter modes use a counter, > which is typically assumed to be incremented by a single sender. > This memo describes the use of counter modes when applied to the > Encapsulating Security Payload (ESP) and Authentication Header (AH) > in multiple-sender group applications. --=20 Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From cyyeung@cisco.com Thu Mar 4 07:36:43 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05BE28C18A for ; Thu, 4 Mar 2010 07:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCuwIbk6GWc5 for ; Thu, 4 Mar 2010 07:36:40 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5401928C18F for ; Thu, 4 Mar 2010 07:36:40 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFALdhj0urRN+J/2dsb2JhbACBRJl7c58EmF+EfASDFw X-IronPort-AV: E=Sophos;i="4.49,581,1262563200"; d="scan'208,217";a="160652340" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2010 15:36:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o24Fagic006722 for ; Thu, 4 Mar 2010 15:36:42 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 07:36:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABBB0.7D197A2B" Date: Thu, 4 Mar 2010 07:36:42 -0800 Message-ID: <6E7590A4D7F8244BA8ECE4FEC6782F650BF8952B@xmb-sjc-22d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Group Key Management using IKEv2 draft Thread-Index: Acq7bLkjNsbIcSJ9TgiMmwDkGRRWHg== From: "Aldous Yeung (cyyeung)" To: X-OriginalArrivalTime: 04 Mar 2010 15:36:42.0389 (UTC) FILETIME=[7D467C50:01CABBB0] Cc: "Paulina Tran \(ptran\)" Subject: [MSEC] Group Key Management using IKEv2 draft X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 15:36:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABBB0.7D197A2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 We posted a draft updating GDOI using IKEv2 called "G-IKEv2". http://datatracker.ietf.org/doc/draft-yeung-g-ikev2/ =20 Please review and consider taking this on as a working group item. =20 Thanks, Aldous =20 >> Manual Posting Requested for following Internet-Draft: >>=20 >> I-D Submission Tool URL: >> https://datatracker.ietf.org/idst/status.cgi?submission_id=3D21996 >>=20 >>=20 >> Filename: draft-yeung-g-ikev2 >> Version: 00 >> Staging URL: > http://www.ietf.org/staging/draft-yeung-g-ikev2-00.txt >> Title: Group Key Management for IKEv2 >> Creation_date: 2010-03-01 >> WG ID: Individual Submission >> Number_of_pages: 45 >> Abstract: >> This document presents a new group key distribution protocol, using=20 >> group key distribution RFC 3547 with IKEv2 RFC 4306. The new=20 >> protocol is similar to IKEv2 in message and payload formats as well=20 >> as message semantics. The protocol is in conformance with MSEC key=20 >> management architecture that it contains two components: member=20 >> registration and group rekeying, both downloading group security=20 >> associations from the GCKS to a member of the group. >>=20 >> Submitter: Aldous Yeung (cyyeung@cisco.com) >>=20 >> Author(s): >> Sheela Rowles, sheela@cisco.com >> Aldous Yeung, cyyeung@cisco.com >> Paulina Tran, ptran@cisco.com ------_=_NextPart_001_01CABBB0.7D197A2B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We posted a draft updating GDOI using IKEv2 called “G-IKEv2”.

http://dat= atracker.ietf.org/doc/draft-yeung-g-ikev2/

 

Please review and consider taking this on as a = working group item.

 

Thanks,

Aldous

 

>> Manual Posting Requested for following Internet-Draft:

>> 

>> I-D Submission Tool URL:

>> https://datatracker.ietf.org/idst/status.cgi?submission_id=3D21996=

>> 

>> 

>> Filename:         draft-yeung-g-ikev2

>> Version:    00

>> Staging URL:

> http://ww= w.ietf.org/staging/draft-yeung-g-ikev2-00.txt

>> Title:            = Group Key Management for IKEv2

>> Creation_date:    = 2010-03-01

>> WG ID:            = Individual Submission

>> Number_of_pages: 45

>> Abstract:

>> This document presents a new group key distribution protocol, using

>> group key distribution RFC 3547 with = IKEv2 RFC 4306.  The new

>> protocol is similar to IKEv2 in message = and payload formats as well

>> as message semantics.  The = protocol is in conformance with MSEC key

>> management architecture that it = contains two components: member

>> registration and group rekeying, both = downloading group security

>> associations from the GCKS to a member = of the group.

>> 

>> Submitter: Aldous Yeung (cyyeung@cisco.com)

>> 

>> Author(s):

>> Sheela Rowles, sheela@cisco.com

>> Aldous Yeung, cyyeung@cisco.com

>> Paulina Tran, ptran@cisco.com

------_=_NextPart_001_01CABBB0.7D197A2B-- From kavithac@cisco.com Thu Mar 4 10:06:24 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F003A8DCC for ; Thu, 4 Mar 2010 10:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqADZZJYs9U0 for ; Thu, 4 Mar 2010 10:06:23 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 195C83A8DDD for ; Thu, 4 Mar 2010 10:06:23 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAFeFj0urR7H+/2dsb2JhbACBRJl4c59kmF+EfASDFw X-IronPort-AV: E=Sophos;i="4.49,582,1262563200"; d="scan'208,217";a="215417043" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2010 18:06:25 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o24I6Phe015042 for ; Thu, 4 Mar 2010 18:06:25 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 10:06:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CABBC5.671D798B" Date: Thu, 4 Mar 2010 10:06:28 -0800 Message-ID: <413FABF5DCE22849AF86F442E472B78B0830D57C@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Submitted Draft: Management Information Base for the Group Domain of Interpretation Thread-Index: Acq7xWlP5WOpz1RCR6O8Kz0HNJ/4iw== From: "Kavitha Kamarthy (kavithac)" To: X-OriginalArrivalTime: 04 Mar 2010 18:06:25.0160 (UTC) FILETIME=[676C9080:01CABBC5] Cc: "Tanya Roosta \(roosta\)" , "Preethi Sundaradevan \(prsundar\)" , "Mike Hamada \(michamad\)" Subject: [MSEC] Submitted Draft: Management Information Base for the Group Domain of Interpretation X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 18:06:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CABBC5.671D798B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We submitted a draft on MIB definitions for GDOI protocol (RFC 3547) Please find the draft at http://www.ietf.org/staging/draft-gdoi-mib-module-00.txt =20 Draft Title : Management Information Base for the Group Domain of Interpretation =20 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular this document describes a high-level Management Information Base for Group Domain of Interpretation (GDOI), which is used for secure group communication in Ipsec VPNs. This draft describes managed objects used for implementations of the GDOI protocol. =20 We request the WG to review this draft and consider taking on this work. =20 Thanks kavitha ------_=_NextPart_001_01CABBC5.671D798B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

  We submitted a draft on MIB definitions for = GDOI protocol (RFC 3547)

Please find the draft at

http://= www.ietf.org/staging/draft-gdoi-mib-module-00.txt

 

Draft Title : Management Information Base for the = Group Domain of Interpretation

 

Abstract:

This memo defines a portion of the Management = Information Base (MIB) for use with network management protocols.  In = particular this document describes a high-level Management Information Base for Group = Domain of Interpretation (GDOI), which is used for secure group communication in = Ipsec VPNs.  This draft describes managed objects used for = implementations of the GDOI protocol.

 

We request the WG to review this draft and consider = taking on this work.

 

Thanks

kavitha

------_=_NextPart_001_01CABBC5.671D798B-- From root@core3.amsl.com Mon Mar 8 15:00:01 2010 Return-Path: X-Original-To: msec@ietf.org Delivered-To: msec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 767D23A69E6; Mon, 8 Mar 2010 15:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308230001.767D23A69E6@core3.amsl.com> Date: Mon, 8 Mar 2010 15:00:01 -0800 (PST) Cc: msec@ietf.org Subject: [MSEC] I-D Action:draft-ietf-msec-gdoi-update-05.txt X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Group Domain of Interpretation Author(s) : B. Weis, S. Rowles Filename : draft-ietf-msec-gdoi-update-05.txt Pages : 59 Date : 2010-03-08 This document describes an updated version of the Group Domain of Interpretation (GDOI) protocols. GDOI is an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-update-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08144732.I-D@ietf.org> --NextPart-- From john.mattsson@ericsson.com Wed Mar 10 00:54:41 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151B73A676A for ; Wed, 10 Mar 2010 00:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGIt8Nln4CsB for ; Wed, 10 Mar 2010 00:54:40 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 054F93A6765 for ; Wed, 10 Mar 2010 00:54:39 -0800 (PST) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1b-4b975e53fe2f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 37.12.23532.35E579B4; Wed, 10 Mar 2010 09:54:43 +0100 (CET) Received: from ESESSCMS0357.eemea.ericsson.se ([169.254.2.37]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 10 Mar 2010 09:54:42 +0100 From: John Mattsson To: "msec@ietf.org" Date: Wed, 10 Mar 2010 09:54:40 +0100 Thread-Topic: Draft update: draft-mattsson-mikey-ticket-02 Thread-Index: AcrAL1I5dEGFybWiScilwxPDfcO1HA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [MSEC] Draft update: draft-mattsson-mikey-ticket-02 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 08:54:41 -0000 Dear all, We have submitted an updated version of the draft "MIKEY-TICKET: An Additio= nal Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)". This v= ersion is intended for IETF last call. http://tools.ietf.org/html/draft-mattsson-mikey-ticket-02 Updates since the 01 version includes: - Updated the key derivation figures - Removed the option to have Initiator generated keys in KMS created ticket= s as the same functionality could be achieved by doing a CSB update. - Moved KEMAC from REQUEST_INIT to TP Data in the Ticket Policy payload. - Added possibility to send a KEMAC in TICKET_TRANSFER (an early CSB update= ) - Updated the error processing, and added a new Section 5.4. - Updated the security policy handling and added a new CS ID map type GENER= IC-ID, which is intended to eliminate the limitations with the existing SRT= P-ID map type. - Added a new RANDR payload - Moved the Pre-Encrypted Content Section - Rewrote the Group Communication Section - Removed Application ID from the key derivation label - Combined the description of TP and TICKET payloads - Editorials Comments/recommendations would be appreciated. Best regards, John Mattsson =20 = From A.Hoenes@TR-Sys.de Mon Mar 15 09:44:56 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A5A3A6939 for ; Mon, 15 Mar 2010 09:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.118 X-Spam-Level: *** X-Spam-Status: No, score=3.118 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwAK8P-qz4wt for ; Mon, 15 Mar 2010 09:44:56 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C7C1F3A6C47 for ; Mon, 15 Mar 2010 09:44:48 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA295981471; Mon, 15 Mar 2010 17:44:31 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA17140 for msec@ietf.org; Mon, 15 Mar 2010 17:44:30 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003151644.RAA17140@TR-Sys.de> To: msec@ietf.org Date: Mon, 15 Mar 2010 17:44:29 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 15 Mar 2010 11:18:30 -0700 Subject: [MSEC] draft-ietf-msec-ipsec-group-counter-modes-05 -- nits (fwd) X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:44:56 -0000 Hello again, I've followed up to your revised Group CTR Modes draft, draft-ietf-msec-ipsec-group-counter-modes-05. The generalization has been smooth and everything looks quite well now; I only saw two minor editorial glitches left: a) In Section 1, s/Camilla/Camellia/ (someone affiliated with poor Prince Charles ? :-) ) b) In the last paragraph of Section 2, ... known as a Many-to-Many Applications ... should say: ... known as Many-to-Many Applications ... Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From Simon_SG_ENG@nyp.gov.sg Mon Mar 15 13:04:36 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2703A6B73 for ; Mon, 15 Mar 2010 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OiKJm38kM5B for ; Mon, 15 Mar 2010 13:04:35 -0700 (PDT) Received: from mars.gems2.gov.sg (mars.gems2.gov.sg [160.96.65.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCFD3A67DA for ; Mon, 15 Mar 2010 13:04:34 -0700 (PDT) Received: from sehubm001.gems2.gov.sg ([10.235.129.12]) by mars.gems2.gov.sg (AIX5.3/8.13.4/8.11.0) with ESMTP id o2FK4baU608938 for ; Tue, 16 Mar 2010 04:04:39 +0800 From: Simon SG ENG To: msec Message-ID: Date: Tue, 16 Mar 2010 04:04:37 +0800 X-MIMETrack: Serialize by Router on SEHUBM001/GOV/H/SINEXTRA(Release 6.5.5FP2HF618 | July 7, 2008) at 03/16/2010 04:04:38 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [MSEC] Simon ENG Soo Guan is not in NYP. X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 20:04:36 -0000 I will be out of the office from 03/16/2010 to 03/19/2010. I am on course. I will not be able to respond to your message in time. From john.mattsson@ericsson.com Fri Mar 19 03:20:57 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87B53A6867 for ; Fri, 19 Mar 2010 03:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDuLrfsmXel7 for ; Fri, 19 Mar 2010 03:20:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2B5DF3A67F3 for ; Fri, 19 Mar 2010 03:20:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-3c-4ba350117626 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4C.E8.23532.11053AB4; Fri, 19 Mar 2010 11:21:05 +0100 (CET) Received: from ESESSCMS0357.eemea.ericsson.se ([169.254.2.37]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 19 Mar 2010 11:21:04 +0100 From: John Mattsson To: "iana@iana.org" , "msec@ietf.org" Date: Fri, 19 Mar 2010 11:21:03 +0100 Thread-Topic: Error in the Multimedia Internet KEYing (Mikey) Payload Name Spaces Thread-Index: AcrB6Lv068JJ529sT4ytGvYdHfgqugFYx1DQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Karl Norrman , Fredrik Lindholm , Jari Arkko Subject: [MSEC] Error in the Multimedia Internet KEYing (Mikey) Payload Name Spaces X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 10:20:57 -0000 Hi, =20 I discovered an error in the Multimedia Internet KEYing (Mikey) Payload Nam= e Spaces =20 http://www.iana.org/assignments/mikey-payloads =20 The CS ID map type is listed as a 7-bit field (It seems to have been copied= from the PRF func table) Sub-registry: CS ID map type Value CS ID map type Reference ------- ---------------- --------- 0 SRTP-ID [RFC3830] 1 Empty map [RFC4563] 2-111 Unassigned 112-127 Reserved =20 CS ID map type should be 8-bit and the table should look like this: Sub-registry: CS ID map type Value CS ID map type Reference ------- ---------------- --------- 0 SRTP-ID [RFC3830] 1 Empty map [RFC4563] 2-240 Unassigned 241-255 Reserved Best Regards /John Mattsson=20 From vincent.roca@inrialpes.fr Mon Mar 22 19:15:08 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5BE3A69C7 for ; Mon, 22 Mar 2010 19:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=-1.617, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZU0TVdw9QMQ for ; Mon, 22 Mar 2010 19:15:05 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 6C1523A69B6 for ; Mon, 22 Mar 2010 19:15:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,291,1267398000"; d="scan'208";a="55734359" Received: from vpnloria47.inrialpes.fr (HELO dhcp-wireless-open-abg-30-29.meeting.ietf.org) ([194.199.16.175]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 23 Mar 2010 03:15:09 +0100 Message-ID: <4BA82427.2050108@inrialpes.fr> Date: Tue, 23 Mar 2010 03:15:03 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: draft-mattsson-mikey-ticket.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tim.polk@nist.gov, Vincent Roca , rolf.j.blom@ericsson.com, msec@ietf.org Subject: [MSEC] Review of draft-mattsson-mikey-ticket-02 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 02:15:08 -0000 Dear John/Tian, Here are a few comments, after a careful reading your I-D. Sorry if it's a bit long... Do not hesitate to tell me if I misunderstood some parts. I must also confess I'm not a MIKEY expert and therefore I cannot judge the most technical parts. Finally it's also possible there are some duplicate items with Tobias' secdir review (I didn't check). Hope it will be useful, it's the goal. Regards, Vincent Main comments: -------------- ** The specified intended status is Informational. Is this motivated by the fact this is an individual submission? ** Fig. 3, p 12: If I understand well, mode (3) is also for the case where I requests in advance some tickets for future use as explained in section 5.3, "Ticket reuse". Am I right? I'm asking the question since the text refers to a different situation. ** Section 4.2.1.4, p15: it is said: "the KMS SHOULD send a REQUEST_RESP message." I don't agree, if everything is okay, the KMS *MUST* send a REQUEST_RESP message. ** Section 4.2.1.5, p15: it is said: "The KMS SHALL generate a fresh timestamp [...]. If COUNTER [...] is used, the timestamp MAY be equal to the one in the REQUEST_INIT message." There's a contradiction here. You can't say at the same time that the timestamp SHALL be a fresh one and that it MAY be equal to a previously sent value. This remark can be made to Section 4.2.3.5 where the same text appears. ** Section 4.2.1.5, p15: it is said: "The KEMAC payload SHOULD use the NULL authentication algorithm, as a MAC is included in the V payload." Okay, I understand the meaning, but why are you saying SHOULD? I'm wondering if a MUST/SHALL is not preferable here to save useless complexity. This remark can be made to Section 4.2.2.3 where the same text appears. ** Section 4.2.1.6, p16: it is said: "If the Initiator can verify the integrity of the received message and the message can be correctly parsed, the ticket and the associated session information SHOULD be stored." Why are you saying SHOULD whereas, as I understand, "I" has no reason not to store this information and use it? Later in this section: "If not, the Initiator SHALL either discard or send a new REQUEST_INIT message suggesting a different Ticket Policy than before." Instead of "either ... or", I'd rather say "the Initiator SHALL discard and send a new REQUEST_INIT...". Another point, why is it said that the "Initiator SHOULD check the granted Ticket Policy"? Why SHOULD rather than MUST? What's the point of launching a Ticket Transfer if the policy is not appropriate? There's a risk this incoherency be discovered quite late in the whole process, after having wasting significant resources. This remark can be made to Section 4.2.2.4 where the same text appears. ** Section 4.2.2, p 16: it is said: "The messages are preferably included in the session setup signaling (e.g. SIP INVITE and 200 OK)." There's an ambiguity here. I have problems figuring out which messages are concerned here. Please clarify. Thanks. ** Section 4.2.3.6, p22: If I understand well, rather than "MPK", you'd better say "with the MPKi received from the KMS". Another point: why "SHOULD" the Responder verify the TRANSFER_INIT? It is a SHALL/MUST, not a SHOULD. ** Section 5.1: For the first case, I suggest to say: "The KEMAC shown is the KEMAC sent from the KMS to the Initiator." i.e. be symmetric to the similar sentence in the second case. Later in Fig 5, what does "ID Data and RAND" refer to? Is this the content of the MOD field? ** 5.2, p 27: it is said: "The ticket and other static payloads that were provided in the initial exchange SHOULD NOT be included." Is the "SHOULD NOT" appropriate? I have the feeling that the simplest, the better (in particular there are fewer security risks). If it's useless, then we'd better say that they MUST NOT be included. ** Section 5.4: it is said: "If an error occurs, the message SHOULD be discarded and the the error SHOULD be reported with an error message." Remove the additional "the". Besides, to whom SHOULD the error be reported? Is it to a local log system, or to the peer, or the KMS? I guess it depends on the precise type of error, but I'd like to see more precision here. Later in this section (2 occurrences): Error message = HDR, T, {ERR}, [V|SIGNx] Since {} means there can be one or more occurrences, it means that the Error message may well contain *no* error field!!! What's the point, then? ** Table 5.2: I have a problem here... I have the feeling that nowhere before it has been mentioned that *_RESP messages must include a copy of the initial *_INIT message. It's not a small detail! It should be clearly stated before, and not in a section that discusses MAC/Signature coverage. ** Section 6.1: When describing the "V" field, it is said: "It SHALL be ignored in all messages except TRANSFER_INIT messages used for CSB updating (see Section 5.2)." I don't agree, you must say: "It MUST be set to 0 in all messages..." And also, you'd better say: "* V (1 bit): flag to indicate whether a response message is expected (V=1) or not (V=0)." to remove any ambiguity. ** Section 6.1.1: In the first figure, it's not very clear whether padding is needed or not so as to have 32-bit alignment. In theory, there's no padding, but this figure shows an SPI that finishes on a 32-bit boundary. And it's also the case with th Ps figure... If there's no alignment consideration, make it explicit in the provided examples. ** Section 6.5: I have the feeling that the ID Type field is more an *encoding type* of the ID, than an "ID Type". Anyway the content of this field is a little bit unclear to me. ** Section 6.6: Why is the ID Len field 16-bit long? Do you really expect such long ID fields? (that's a naive question, sure!) Also, is this a size in terms of bytes, it's not said. ** Section 6.11: Similar question concerning the Ticket Type. This is a 16-bit field whereas there are only two entries specified. Do you really expect this field to be populated to a point where you need 32 bits? ** Section 7: I didn't understand. Can you reformulate please? ** Section 8: How does R know the TEK used by the content provider? I guess you assume that the Responder initiated an exchange with the content provider to get the right of accessing the content, and obtained the TEK as a result. This is not explained however. ** Section 9: the scenario of Fig 7 is not really clear to me. Does it use a GTGK? I also suggest you add in Fig 7 caption "Centralized signaling around host A". ** Section 10, p43: it is said: "The KMSs SHALL be mutually authenticated and signaling between them SHALL be integrity protected." I don't agree. Signaling MUST be fully protected, i.e. encrypted, integrity/replay protected, authenticated. Otherwise it's an ideal target for attacks or eavesdropping. Another question: is there some commonly agreed way of naming the various entities (KMSs, I and R)? Because here the KMS may belong to different domains which means we need a common identification basis. ** Section 12.1, p44: Don't mention "random number generator". We are using "pseudo-random number generator" (PRNG)! ** Section 12.1, p45: it is said: "In other words, a 2^n work enables an attacker to get all k n-bit keys." I don't understand what you mean by "work". ** Section 12.3, last line of p46: "it is RECOMMENDED to use key forking and TGKs unless required by the use case." I guess you mean "NOT RECOMMENDED to use..." ** Section 12.4: it is said: "To prevent all forms of eavesdropping, only the endpoint that answers should get access to the session keys." Are you sure it is a should (BTW, it must be an uppercase "SHOULD"). I think the following wording is more appropriate: "...no entity except the endpoint that answers MUST be able to get access..." Typos and other minor comments: ------------------------------- ** p9: "Such scenarios excludes all key management" => "exclude" ** Section 4.2.1.4, p15: Split the first sentence in two sentences, please. ** Section 4.2.2.1, p 17: it is said: "but IDRi MAY be left out when it can be expected that the Responder has a single identity, and IDRr MAY be left out if the Responder can identify the Initiator by other means." I think IDRi and IRDr should be permuted here. ** Section 4.2.3.5: remove the initial ">" character. ** Section 5.2: It is said: "The CSB updating MAY be started by either the Initiator or the Responder." I'd rather say "CAN". ** Table 6.6: is "HMAC-SHA-256-256" the result of a typo or not? ** p40: " An omitted TRs means that the validity period has defined beginning." Can you check this sentence. I'm not sure how to interpret it... ** p40: typos: "SHALL NOT be longer the the number of seconds" => "than the" ** Section 12.1, p45, last line: "then" -> "than" From william.polk@nist.gov Tue Mar 23 16:46:25 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31F33A6BEC for ; Tue, 23 Mar 2010 16:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agjO7vYTFmNk for ; Tue, 23 Mar 2010 16:46:24 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id AA2F73A6974 for ; Tue, 23 Mar 2010 16:46:21 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o2NNkVkp028273 for ; Tue, 23 Mar 2010 19:46:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 23 Mar 2010 19:46:30 -0400 From: "Polk, William T." To: "msec@ietf.org" Date: Tue, 23 Mar 2010 19:51:06 -0400 Thread-Topic: NIST cryptographic transition strategy Thread-Index: AcrK47QDxFSdxQwB+E2KO/JJQft24Q== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [MSEC] NIST cryptographic transition strategy X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:46:25 -0000 As discussed in the msec session today, the draft NIST cryptographic transition document has implications for msec implementers that wg members may wish to comment on. I thought I should forward some details to the lis= t so interested meeting participants can easily find the document. Note: while the comment period has officially closed, late comments are always accepted. > Jan. 14, 2010 >=20 > SP 800-131 >=20 > DRAFT Recommendation for the Transitioning of Cryptographic Algorithms an= d Key > Sizes >=20 > Draft Special Publication 800-131, Recommendation for the Transitioning o= f > Cryptographic Algorithms and Key Sizes, is available for public comment. = NIST > Special Publication (SP) 800-57, Part 1 included a general approach for > transitioning from one algorithm or key length to another. This Recommend= ation > (SP 800-131) provides more specific guidance for transitions to stronger > cryptographic keys and more robust algorithms. Public comments should be = sent > to CryptoTransitions@nist.gov by March 15, 2010. The authors of this docu= ment, > Elaine Barker and Allen Roginsky, will be available for discussions at th= e RSA > Conference in San Francisco on March 1-5. >=20 See http://csrc.nist.gov/publications/PubsDrafts.html to get the document. Thanks, Tim PPolk From vincent.roca@inrialpes.fr Wed Mar 24 11:59:41 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9C53A6778 for ; Wed, 24 Mar 2010 11:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnjLTFBCPtbV for ; Wed, 24 Mar 2010 11:59:40 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id A820A3A67FC for ; Wed, 24 Mar 2010 11:59:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,302,1267398000"; d="scan'208";a="55862328" Received: from vpnrocq37.inrialpes.fr (HELO macbook-pro-de-roca.local) ([194.199.16.101]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 24 Mar 2010 19:59:50 +0100 Message-ID: <4BAA611E.3010501@inrialpes.fr> Date: Wed, 24 Mar 2010 19:59:42 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: msec@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brian Adamson , Lorenzo Vicisano Subject: [MSEC] Can somebody have a look at draft-ietf-rmt-simple-auth-for-alc-norm? X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:59:41 -0000 Hello everybody, As explained yesterday during the MSEC meeting, here is the "simple authentication methods for ALC/NORM" document. Its goal is to describe how to use such techniques as digital sig and/or group MAC within the two transport protocols designed within the RMT group, namely ALC and NORM. Therefore it complements our TESLA for ALC/NORM document. So, if somebody volunteers to give a look at it, it would be great. http://datatracker.ietf.org/doc/draft-ietf-rmt-simple-auth-for-alc-norm/ Thanks a lot! Vincent From vincent.roca@inrialpes.fr Thu Mar 25 11:02:48 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7033A6813 for ; Thu, 25 Mar 2010 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=1.440, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SJ14-0ku0Ry for ; Thu, 25 Mar 2010 11:02:47 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 339363A6E33 for ; Thu, 25 Mar 2010 11:02:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,308,1267398000"; d="scan'208";a="59708549" Received: from vpnrocq38.inrialpes.fr (HELO dhcp-wired-48-132.meeting.ietf.org) ([194.199.16.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Mar 2010 19:02:54 +0100 Message-ID: <4BABA54A.9090901@inrialpes.fr> Date: Thu, 25 Mar 2010 19:02:50 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: msec@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MSEC] Concerning draft-ietf-msec-ipsec-group-counter-modes-05 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:02:48 -0000 Hello everybody, Concerning draft-ietf-msec-ipsec-group-counter-modes-05 http://www.ietf.org/proceedings/10mar/slides/msec-5.pdf This document already passed WGLC (quite a long time ago however) and comments have been addressed. Nobody in the room objected to the proposal of continuing the standards procedure. I'd like to confirm this on the list. So unless somebody objects, I'll sent it to our AD next Friday, on April 2nd. Regards, Vincent From vincent.roca@inrialpes.fr Thu Mar 25 11:29:52 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9553A6E8C for ; Thu, 25 Mar 2010 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.159 X-Spam-Level: X-Spam-Status: No, score=-4.159 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlzFo4NCnB8H for ; Thu, 25 Mar 2010 11:29:51 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 11ECE3A6E01 for ; Thu, 25 Mar 2010 11:27:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,308,1267398000"; d="scan'208";a="59709600" Received: from vpnrocq38.inrialpes.fr (HELO dhcp-wired-48-132.meeting.ietf.org) ([194.199.16.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Mar 2010 19:27:33 +0100 Message-ID: <4BABAB13.5090505@inrialpes.fr> Date: Thu, 25 Mar 2010 19:27:31 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: msec@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [MSEC] Concerning draft-ietf-msec-gdoi-update-05 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:29:52 -0000 Hello, Concerning draft-ietf-msec-gdoi-update-05 http://www.ietf.org/proceedings/10mar/slides/msec-2.pdf I'd like to have the group feeling about the possibility of going into WGLC soon. We also need a few volunteers to review the document (there was one during the meeting). Thanks in advance! Regards, Vincent From john.mattsson@ericsson.com Mon Mar 29 01:06:06 2010 Return-Path: X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84813A6878 for ; Mon, 29 Mar 2010 01:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJfBXJO+s-w1 for ; Mon, 29 Mar 2010 01:06:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 437DC3A67B4 for ; Mon, 29 Mar 2010 01:06:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-c6-4bb05f853afd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 77.35.23532.58F50BB4; Mon, 29 Mar 2010 10:06:29 +0200 (CEST) Received: from ESESSCMS0357.eemea.ericsson.se ([169.254.2.37]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 29 Mar 2010 10:06:29 +0200 From: John Mattsson To: Vincent Roca , "draft-mattsson-mikey-ticket.all@tools.ietf.org" Date: Mon, 29 Mar 2010 10:06:27 +0200 Thread-Topic: Review of draft-mattsson-mikey-ticket-02 Thread-Index: AcrKLrlyFOXjTZhxShOhes+NMphDWwE50YLg Message-ID: References: <4BA82427.2050108@inrialpes.fr> In-Reply-To: <4BA82427.2050108@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "msec@ietf.org" , "tim.polk@nist.gov" , Vincent Roca , Blom J , Rolf Subject: Re: [MSEC] Review of draft-mattsson-mikey-ticket-02 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:06:07 -0000 Dear Vincent, Many thanks for the careful and detailed review. I agree with the vast majo= rity of your comments and will update the draft accordingly. Misunderstandi= ngs are often a sign that the text should be rewritten (but you did not mis= understand much at all). It was very useful. Regards, John -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]=20 Sent: den 23 mars 2010 03:15 To: draft-mattsson-mikey-ticket.all@tools.ietf.org Cc: Brian Weis; tim.polk@nist.gov; Vincent Roca; msec@ietf.org; Rolf Blom J Subject: Review of draft-mattsson-mikey-ticket-02 > Dear John/Tian, >=20 > Here are a few comments, after a careful reading your I-D. Sorry > if it's a bit long... Do not hesitate to tell me if I misunderstood > some parts. I must also confess I'm not a MIKEY expert and therefore > I cannot judge the most technical parts. Finally it's also possible > there are some duplicate items with Tobias' secdir review > (I didn't check). >=20 > Hope it will be useful, it's the goal. > Regards, >=20 > Vincent Main comments: -------------- > ** The specified intended status is Informational. Is this motivated > by the fact this is an individual submission? Yes, and there was no interest in msec to have it as a WG item. Having it i= nformal is in line with some other 3GPP related RFCs like EAP-SIM and EAP-A= KA. > ** Fig. 3, p 12: If I understand well, mode (3) is also for the case > where I requests in advance some tickets for future use as > explained in section 5.3, "Ticket reuse". Am I right? > I'm asking the question since the text refers to a different > situation. No, text is correct. The case when tickets are fetched in advance by the In= itiator follows mode (1) or (2). Mode (3) is when the Initiator is allowed = to generate tickets on its own. Maybe this can be clarified better. > ** Section 4.2.1.4, p15: it is said: > "the KMS SHOULD send a REQUEST_RESP message." > I don't agree, if everything is okay, the KMS *MUST* send a > REQUEST_RESP message. Yes, I agree. I'll change it to MUST. > ** Section 4.2.1.5, p15: it is said: > "The KMS SHALL generate a fresh timestamp [...]. > If COUNTER [...] is used, the timestamp MAY be equal to the one > in the REQUEST_INIT message." > There's a contradiction here. You can't say at the same time that > the timestamp SHALL be a fresh one and that it MAY be equal to a > previously sent value. >=20 > This remark can be made to Section 4.2.3.5 where the same text > appears. Yes, this seems like a contradiction and needs to be rewritten. > ** Section 4.2.1.5, p15: it is said: > "The KEMAC payload SHOULD use the NULL authentication algorithm, > as a MAC is included in the V payload." > Okay, I understand the meaning, but why are you saying SHOULD? > I'm wondering if a MUST/SHALL is not preferable here to save > useless complexity. >=20 > This remark can be made to Section 4.2.2.3 where the same text > appears. OK, let's change it to MUST/SHALL. > ** Section 4.2.1.6, p16: it is said: > "If the Initiator can verify the integrity of the received > message and the message can be correctly parsed, the ticket > and the associated session information SHOULD be stored." > Why are you saying SHOULD whereas, as I understand, "I" has no > reason not to store this information and use it? Yes, I agree that is should be SHALL/MUST. I'll rewrite this sentence.=20 > Later in this section: > "If not, the Initiator SHALL > either discard or send a new REQUEST_INIT message suggesting > a different Ticket Policy than before." > Instead of "either ... or", I'd rather say "the Initiator SHALL > discard and send a new REQUEST_INIT...". Yes, I see your point but "the Initiator SHALL discard and send a new REQUE= ST_INIT..." may lead to an infinite loop. I'll change it to "the Initiator = SHALL discard and MAY send a new REQUEST_INIT". > Another point, why is it said that the "Initiator SHOULD check > the granted Ticket Policy"? Why SHOULD rather than MUST? What's > the point of launching a Ticket Transfer if the policy is not > appropriate? There's a risk this incoherency be discovered > quite late in the whole process, after having wasting > significant resources. >=20 > This remark can be made to Section 4.2.2.4 where the same text > appears. Agree, let's change to MUST. > ** Section 4.2.2, p 16: it is said: > "The messages are preferably included in the session setup > signaling (e.g. SIP INVITE and 200 OK)." > There's an ambiguity here. I have problems figuring out which > messages are concerned here. Please clarify. Thanks. Yes, we will. It should be "The MIKEY messages are preferably ..." > ** Section 4.2.3.6, p22: If I understand well, rather than "MPK", > you'd better say "with the MPKi received from the KMS". > Another point: why "SHOULD" the Responder verify the > TRANSFER_INIT? It is a SHALL/MUST, not a SHOULD. Yes, Yes. > ** Section 5.1: For the first case, I suggest to say: > "The KEMAC shown is the KEMAC sent from the KMS to the > Initiator." > i.e. be symmetric to the similar sentence in the second case. Yes, I'll change to "The KEMAC shown is the KEMAC sent from the KMS to the = Initiator and Responder." > Later in Fig 5, what does "ID Data and RAND" refer to? Is > this the content of the MOD field? Yes, they are the relevant fields from the modifier (IDRr, RANDRkms). > ** 5.2, p 27: it is said: > "The ticket and other static payloads that were > provided in the initial exchange SHOULD NOT be included." > Is the "SHOULD NOT" appropriate? > I have the feeling that the simplest, the better (in particular > there are fewer security risks). If it's useless, then we'd > better say that they MUST NOT be included. Yes, that's better. > ** Section 5.4: it is said: > "If an error occurs, the message SHOULD be discarded and > the the error SHOULD be reported with an error message." > Remove the additional "the". Yes > Besides, to whom SHOULD the error be reported? Is it to > a local log system, or to the peer, or the KMS? I guess > it depends on the precise type of error, but I'd like to > see more precision here. It should be reported to the other party (Initiator, Responder, KMS). I'll = make it more precise. > Later in this section (2 occurrences): > Error message =3D > HDR, T, {ERR}, [V|SIGNx] > Since {} means there can be one or more occurrences, it means > that the Error message may well contain *no* error field!!! > What's the point, then? Yes, an error inherited from RFC 3830. I'll correct to "HDR, T, (ERR), [V|S= IGNx]" > ** Table 5.2: I have a problem here... I have the feeling that > nowhere before it has been mentioned that *_RESP messages > must include a copy of the initial *_INIT message. It's not > a small detail! It should be clearly stated before, and not in > a section that discusses MAC/Signature coverage. The *_RESP messages does not include a copy. It is only the MAC/Signature t= hat covers the *_INIT message. And this is stated before. Is there a specif= ic sentence that should be clarified? > ** Section 6.1: When describing the "V" field, it is said: > "It SHALL be ignored in all messages except TRANSFER_INIT > messages used for CSB updating (see Section 5.2)." > I don't agree, you must say: "It MUST be set to 0 in all > messages..." I'll change to "It MUST be set to 0 and ignored in all messages..." > And also, you'd better say: > "* V (1 bit): flag to indicate whether a response message is > expected (V=3D1) or not (V=3D0)." to remove any ambiguity. Ok > ** Section 6.1.1: In the first figure, it's not very clear whether > padding is needed or not so as to have 32-bit alignment. In theory, > there's no padding, but this figure shows an SPI that finishes > on a 32-bit boundary. > And it's also the case with th Ps figure... > If there's no alignment consideration, make it explicit in the > provided examples. There is no 32-bit alignment consideration for any MIKEY payload (even in 3= 830), only octet alignmnet. Maybe I can write a general sentence about this= . Is there any better way to illustrate alignment in figures? Currently the= figures are as in RFC 3830. > ** Section 6.5: I have the feeling that the ID Type field is more an > *encoding type* of the ID, than an "ID Type". > Anyway the content of this field is a little bit unclear to me. Yes, the name is not very good. This is inherited from 3830. Maybe it shoul= d be clarified a little. > ** Section 6.6: Why is the ID Len field 16-bit long? Do you really > expect such long ID fields? (that's a naive question, sure!) > Also, is this a size in terms of bytes, it's not said. This is inherited from RFC 3830, so it should not be changed. And identitie= s may be very long, so I think it is better to be safe than sorry. I'll add= that it is in bytes. > ** Section 6.11: Similar question concerning the Ticket Type. This is a > 16-bit field whereas there are only two entries specified. > Do you really expect this field to be populated to a point where > you need 32 bits? This first 16 bit is the "global" part of the identifier; like "3GPP", "OMA= ", "EnterpriseABC" etc. So keeping it at 16-bits is reasonable as it is ass= igned by "specification required" and that private use can be expected. The= private use range should maybe be expanded. 32 bits will clearly not be po= pulated, but some extra fields are desirable to ease the use of subtypes. > ** Section 7: I didn't understand. Can you reformulate please? Ok > ** Section 8: How does R know the TEK used by the content provider? > I guess you assume that the Responder initiated an exchange with > the content provider to get the right of accessing the content, > and obtained the TEK as a result. This is not explained however. Ok, I'll expand and update this section. > ** Section 9: the scenario of Fig 7 is not really clear to me. > Does it use a GTGK? They do not even need to use a group key. I'll try to clarify.=20 > I also suggest you add in Fig 7 caption > "Centralized signaling around host A". Good idea. > ** Section 10, p43: it is said: > "The KMSs SHALL be mutually authenticated and signaling > between them SHALL be integrity protected." > I don't agree. Signaling MUST be fully protected, i.e. encrypted, > integrity/replay protected, authenticated. Otherwise it's an > ideal target for attacks or eavesdropping. Yes, fully protected. > Another question: is there some commonly agreed way of > naming the various entities (KMSs, I and R)? Because here > the KMS may belong to different domains which means we need > a common identification basis. No, we have not specified this but we assume that a KMS is defined by a FQD= N and that I and R have identities based on SIP URIs. > ** Section 12.1, p44: Don't mention "random number generator". > We are using "pseudo-random number generator" (PRNG)! OK. I'll change. > ** Section 12.1, p45: it is said: > "In other words, a 2^n work enables an attacker to get all > k n-bit keys." > I don't understand what you mean by "work". I'll change to: "In other words, the time needed by an attacker to get all = k n-bit keys is proportional to 2^n". > ** Section 12.3, last line of p46: > "it is RECOMMENDED to use key forking and TGKs unless required > by the use case." > I guess you mean "NOT RECOMMENDED to use..." I'll rewrite the sentence. The beginning is correct: "it is RECOMMENDED to = use key forking and TGKs."=20 > ** Section 12.4: it is said: > "To prevent all forms of eavesdropping, only the endpoint that > answers should get access to the session keys." > Are you sure it is a should (BTW, it must be an uppercase "SHOULD"). > I think the following wording is more appropriate: > "...no entity except the endpoint that answers MUST be able to > get access..." Yes I'll rewrite. Typos and other minor comments: ------------------------------- > ** p9: "Such scenarios excludes all key management" =3D> "exclude" Yes > ** Section 4.2.1.4, p15: Split the first sentence in two sentences, > please. OK > ** Section 4.2.2.1, p 17: it is said: > "but IDRi MAY be left > out when it can be expected that the Responder has a single > identity, and IDRr MAY be left out if the Responder can > identify the Initiator by other means." > I think IDRi and IRDr should be permuted here. Yes > ** Section 4.2.3.5: remove the initial ">" character. Yes > ** Section 5.2: It is said: > "The CSB updating MAY be started by either the Initiator > or the Responder." > I'd rather say "CAN". OK > ** Table 6.6: is "HMAC-SHA-256-256" the result of a typo or not? No, the thought was to have a similar syntax as the already defined HMAC-SH= A-1-160. > ** p40: > " An omitted TRs means that the validity period has defined beginnin= g." > Can you check this sentence. I'm not sure how to interpret it... Yes, there is a "no" missing. It should be "An omitted TRs means that the v= alidity period has no defined beginning."=20 > ** p40: typos: > "SHALL NOT be longer the the number of seconds" =3D> "than the" Yes > ** Section 12.1, p45, last line: "then" -> "than" Yes=20