From vincent.roca@inrialpes.fr Sat Nov 6 20:21: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 AEF793A6981 for ; Sat, 6 Nov 2010 20:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 d+-+kkeK5x5f for ; Sat, 6 Nov 2010 20:21:44 -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 4D2863A6974 for ; Sat, 6 Nov 2010 20:21:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,308,1286143200"; d="scan'208";a="86438881" Received: from ral072r.vpn.inria.fr (HELO macbook-pro-de-roca.local) ([128.93.178.72]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Nov 2010 04:21:57 +0100 Message-ID: <4CD61B4E.8030606@inrialpes.fr> Date: Sun, 07 Nov 2010 04:21:50 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Brian Weis , sheela@cisco.com, hardjono@mit.edu References: <20101025234502.9B26E3A6868@core3.amsl.com> In-Reply-To: <20101025234502.9B26E3A6868@core3.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: msec@ietf.org Subject: Re: [MSEC] I-D Action:draft-ietf-msec-gdoi-update-07.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: Sun, 07 Nov 2010 03:21:48 -0000 Hello Brian, Sheela and Thomas, After reading -07, I have a certain number of comments: I- Concerning section 7 "Security considerations" ** Risks associated to compromised group members. It is said: "The security of GDOI, therefore, is as good as the degree to which group members can be trusted..." I agree. However I'd like to know what could happen if one of the GM is compromised. Last sentence of 7.3.5 mentions that a compromised GM may launch a DoS. Is there anything else? This is an important question since as the group size increases, so does the probability of having a compromised GM. ** Section 7.2.4 "Replay/Reflection Attack Protection" I have two comments: first of all, the first paragraph is essentially devoted to "liveness" (following section 3 terminology) rather than replay protection. This should be reflected in the title IMHO since the goal is different. Then to provide replay protection you suggest to "keep a record of recently received GROUPKEY-PULL messages and reject messages that have already been processed." This method is inherently limited since the number of messages kept (and to which each incoming message is compared) is limited. Last sentence says this mechanism provides an "early discard" protection, which suggests there is an additional solution, but nothing is said. ** Section 7.2.5 "Denial of Service Protection" It is said: "The replay protection mechanisms described above provide the basis for denial of service protection." Is it sufficient? Is there anything else (in addition to the cookie pair weak protection mentioned above)? It's not clear to me. ** Section 7.3.4. "Replay/Reflection Attack Protection" I agree that comparing incoming messages to those recently received can help identifying duplicates that may be caused by a replay attack. But it's also an additional processing (each messages is compared to 1, 10, 100 messages) and the benefit is in any case limited (an attacker, knowing this limit, can replay older messages). The SEQ mechanism is sufficient, isn't it? And a GM can retrieve the SEQ after a symmetric deciphering, so it does not create a major risk of DoS. ** 7.3.5. Denial of Service Protection Deliberately limiting the number of GROUPKEY-PUSH messages that will be processed per second is another way of mitigating a DoS attack. It does not guaranty that a valid message will be processed, but that's another problem. At least the GM will save some CPU for other tasks. II- Concerning the other sections: ** A section listing acronyms would be welcome. ** I have the feeling that the terminology list should be extended. ** Section 1.5.1. discusses Forward Access Control Requirements but there is no 1.5.2 for Backward Access Control. Is it done on purpose? ** Section 3.3. "Initiator Operations" A novice question... It is said: "If the policy in the SA payload is acceptable to the initiator, it continues the protocol." Is anything special should be done otherwise? Said differently, is there a recommended way of aborting the exchange and let the GCKS know that, so that he can reset its exchange context? Is it done at a lower level or is it achieved only with a timeout mechanism? There are several places in the document where the same kind of remark can be formulated (something wrong happens and the exchange is stopped). If a context needs to be kept for some time at the GCKS, isn't it another way to launch a DoS attack (it reminds me of the attack to TCP consisting in partially opening a large number of connections). (NB: I assume here the GM has been compromised which is a strong assumption, otherwise anti-replay will prevent it). ** Section 5.3. "SA KEK payload" There must be a valid reason, but the presence of the RESERVED2 field remains mysterious to me... Another remark: there is no guaranteed 32-bit alignment in this payload since the last field is of variable length. Is it an issue for the following payloads? I think it's not discussed. I have many minor comments (typos and ambiguities) but we'll see that together, it's simpler for everybody. Cheers, Vincent From bew@cisco.com Sun Nov 7 16:53:45 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 34A673A6898 for ; Sun, 7 Nov 2010 16:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 fFQaAhHKquLF for ; Sun, 7 Nov 2010 16:53:43 -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 A24D03A6894 for ; Sun, 7 Nov 2010 16:53:43 -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: AloFAH/Y1kyrR7Hu/2dsb2JhbACUBo1/cZ8pmmKDC4I9BIRWV4Uo X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="282292922" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2010 00:54:03 +0000 Received: from dhcp-4101.meeting.ietf.org ([10.21.73.250]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oA80s2KJ008084 for ; Mon, 8 Nov 2010 00:54:03 GMT Message-Id: <835D45EE-A74E-437C-AA3A-BD41B24B2491@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, 8 Nov 2010 08:54:01 +0800 X-Mailer: Apple Mail (2.936) Subject: [MSEC] MSEC WG meets today 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 Nov 2010 00:53:45 -0000 Folks, Just a reminder that the MSEC WG meets today at 3:10PM Beijing local time. Two presentations are scheduled. Brian -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Sun Nov 7 17:32: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 02E1A3A688F for ; Sun, 7 Nov 2010 17:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 o0DI-5dcD7ms for ; Sun, 7 Nov 2010 17:32:52 -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 AE36F3A67C3 for ; Sun, 7 Nov 2010 17:32:52 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="282304447" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2010 01:33:12 +0000 Received: from dhcp-4101.meeting.ietf.org ([10.21.73.250]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA81XAbk026427; Mon, 8 Nov 2010 01:33:11 GMT Message-Id: <009C88CA-2D24-48C7-A802-07E4BDAD1A97@cisco.com> From: Brian Weis To: Mark Baugher In-Reply-To: <1468C929-4C24-4EC3-B89F-358D1E3DD1CA@cisco.com> 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, 8 Nov 2010 09:33:09 +0800 References: <1468C929-4C24-4EC3-B89F-358D1E3DD1CA@cisco.com> X-Mailer: Apple Mail (2.936) Cc: msec@ietf.org Subject: Re: [MSEC] Comments on draft-ietf-msec-gdoi-update-06 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 Nov 2010 01:32:54 -0000 Hi Mark, Many thanks for your thoughtful comments and suggestions. I believe we've addressed them all in version -07. Please let us know if any of them are not satisfactory. Thanks, Brian, Sheela, and Thomas On Sep 6, 2010, at 5:53 PM, Mark Baugher wrote: > I took some time this weekend to review draft-ietf-msec-gdoi- > update-06. I thought it was a good job with several improvements > over RFC 3547. I think I found a few problems that you might want > to consider changing. And I have a number of other comments for > your consideration. > > Sec. 1.4: "A future RTP security protocol may benefit from using > GDOI to establish group SAs" is now an anachronism since RFC 3711 > was published after RFC 3547. In fact, SRTP has had a GDOI data > security I-D and even an implementation. This work has not been > completed since other means of keying SRTP are being standardized > and published in the IETF. I would remove this sentence. Good catch, thanks. > > Appendix B: SA GAP is arguably a significant change that probably > should be in your list. Harmonization of GDOI with RFC 5374 might > also be worthy of mention. Actually, the harmonization is mentioned as the 6th bullet in Appendix B. But it's definitely a good idea to specifically call out the GAP payload as well. > > Sec. 3.1: If we no longer have a Phase 2 CERT and POP payloads, then > I think you might consider making the SHOULD into a MUST. There are two SHOULDs in this section. The first one makes sense as a SHOULD, because when authorization credentials are restricted to use with just one group, that's actually an implicit authorization. But I think you meant the second SHOULD. Making this a MUST foils the Meadows attack, so that's a great suggestion. We'll change the second SHOULD to a MUST. > > Sec 1.3: This section defines terms used in Sec 1.0, the > Introduction, which uses terms (e.g. rekey SA) without defining them > or pointing to where they are defined in the document. We'll look into adding more terms to Section 1.2. > > Sec 1.0: The last paragraph contains two paragraphs: The sentence > that begins "In summary" should start a new paragraph. OK. > > Sec 1.0, bottom of page 3: I don't understand this sentence from > point 2, "It is treated as a ISAKMP phase 2 protocol, where the > "phase 1" cryptographic policy and keying material is included in > the group policy distributed by the GCKS in the GROUPKEY-PULL > exchange." This text is not quite right. The main point meant here was that a rekey protocol is actually an ISAKMP protocol, not that it was a phase 1 protocol. We'll re-word this to say as much. > > Sec 1.0, top of page 4: "exchange, all authorized group members have > received and installed updates to group policy" reads strange to me > since this process is not ack'd and it is possible that some > authorized grup members have not received or have not installed the > updates due to e.g. network partition. Good point. How about we replace this with "At the culmination of a GROUPKEY-PUSH exchange the key server has sent group policy to all authorized group members, allowing receiving group members to participate in secure group communications." > > Sec 1.3: Ten years ago, it could be argued that GDOI is applicable > to video broadcast key management. But it was not picked up by > anyone for this application over the years including the IPTV Forum > ATIS and the previously-mentioned SRTP. I do know that it is used > in large-scale VPNs and it is probably more likely to be used for > managing a large number of CPEs like settop boxes than it is for > protecting video broadcast. I think that shipped has sailed and the > more real and more promising applications might be mentioned instead. OK, good point. We'll re-work this section. However, the video broadcast application is a good example of a simple use case that we'd like to include. > > Sec 1.3, last sentence: "In all cases, the relevant policy is > defined on the GCKS and relayed to group members. Specific policy > choices possible by the GCKS depends on each application and further > discussion of policy is beyond the scope of this memo" is a little > misleading since there is a lot of policy including the new SA GAP > that is defined in the memo. This section was intending to convey that there are different choices that can be made in the use of a Rekey SA based on the application type. We'll clarify this. > > Sec 3.3: "If the KD payload included an LKH array of keys, the > initiator takes the last key in the array as the group KEK. The > array is then stored without further processing." Ten years ago we > were optimistic that group member management would emerge as an > important application. This has not matured but we have done some > LKH prototyping IIRC, but there is no published specification for > how to do this. The problem I have with the LKH normative language > is that there is no specification or best practices to guide > implementers. It's not clear to me how to implement LKH based on > RFC 3547 or this update. A couple of points here. LKH isn't mandated ("normative"), but it is listed as a SHOULD in Section 6.1, so it's a reasonable request that implementers "should" be able to find guidance. Section 5.4 of RFC 2627 does describe the basic operations required to implemented LKH, and the draft references this section several places. The only LKH processing that is required to be described in the GDOI Update document is the format for distributing key packets to group members, group member processing of the key packets, and the group member semantics for deriving a new KEK. Thomas' and Lakshminath's book "Multicast and Group Security" has a helpful discussion of how to use LKH and we've added that as a reference. > > Sec 4.0, second paragraph: The delete payload is used here but > defined below. This happens several times in this document. It > would help the reader to define the terms when they are used, or to > at least reference them (RFC 2409 in this case). We'll add a section for the Delete payload in Section 5 and reference it here. > > Sec 4.0: "If the SA defines an LKH KEK array or single KEK, KD > contains a KEK or KEK array for a new Re-key SA, which has a new > cookie pair" seems to be a normative statement but does not use > normative language. Thanks ... we've added a MUST here. > > Sec 5.4.1: "If a group member receives a TEK with an ATD value, but > discovers that it has no current SAs matching the policy in the TEK, > then it SHOULD create and install SAs from the TEK immediately." I > don't understand this. Doesn't the SA GAP precede the TEK that it > applies to? This sentence is misleading and will be removed. > > Sec 5.4.2: The relationship between ATD and DTD is not mentioned. > Is the DTD value the number of seconds of activation? Does DTD > start when the SA is activated, in which case the de-activation time > is ATD + DTD or not? We've clarified that the two values are independent. > > Sec 5.4.3.1: How does a GCKS allocate all possible SID values if the > number space is up to 2^256? We've added some discussion on possible SID values. > > cheers, Mark > > > -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Sun Nov 7 19:30:12 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 AAEEF3A6956 for ; Sun, 7 Nov 2010 19:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 MBfJcx05fz5j for ; Sun, 7 Nov 2010 19:30:11 -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 BF1F43A692C for ; Sun, 7 Nov 2010 19:30:11 -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: AloFAP/91kyrR7Hu/2dsb2JhbACUBo1/cZ5+ml2DC4I9BIRWV4Uo X-IronPort-AV: E=Sophos;i="4.58,312,1286150400"; d="scan'208";a="282340345" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2010 03:30:31 +0000 Received: from dhcp-4101.meeting.ietf.org ([10.21.73.250]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oA83UUs6015798 for ; Mon, 8 Nov 2010 03:30:31 GMT Message-Id: <6602DD39-F293-48E1-913A-9AFBA68C4D07@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, 8 Nov 2010 11:30:30 +0800 X-Mailer: Apple Mail (2.936) Subject: [MSEC] draft-yeung-g-ikev2-01.txt as WG item 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 Nov 2010 03:30:12 -0000 Folks, A couple of meetings ago we had a presentation on , which is implementing GDOI-like exchanges within an IKEv2 framework. IKEv1 (upon which GDOI is based) has been deprecated by IKEv2, so this seems to be a logical draft to bring into the working group. We previously had a working group draft that was similar to this one but whose authors did not continue their work (). There was interest in the meeting for taking this on as a WG item at that time, but the chairs would like to see support or concerns for taking on this draft sent to the list. Thanks, Brian & Vincent -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Wed Nov 17 15:57: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 609E53A69B8 for ; Wed, 17 Nov 2010 15:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 guahhavMJlKf for ; Wed, 17 Nov 2010 15:57:21 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BE8E93A69B1 for ; Wed, 17 Nov 2010 15:57:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAJv640yrRN+K/2dsb2JhbACUUo4BcaRYmzyDDII/BIRaVYUp X-IronPort-AV: E=Sophos;i="4.59,213,1288569600"; d="scan'208";a="621808204" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 17 Nov 2010 23:58:06 +0000 Received: from dhcp-128-107-151-32.cisco.com (dhcp-128-107-151-32.cisco.com [128.107.151.32]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oAHNw7Oo023913 for ; Wed, 17 Nov 2010 23:58:07 GMT Message-Id: <1F6551A3-9471-47A9-A3DA-3AED8F107042@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: Wed, 17 Nov 2010 15:57:59 -0800 X-Mailer: Apple Mail (2.936) Subject: [MSEC] MSEC WG IETF79 Minutes 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, 17 Nov 2010 23:57:23 -0000 Greetings, The minutes from the most recent MSEC WG meeting has been posted: . Thanks go to Frederic Detienne for providing them. Corrections may be either sent to the mailing list, or privately to the chairs. Thanks, Brian -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From wwwrun@rfc-editor.org Mon Nov 22 10:26: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 A4B5028C14F; Mon, 22 Nov 2010 10:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 rknqPyAKhzrn; Mon, 22 Nov 2010 10:26:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 30A2028C15B; Mon, 22 Nov 2010 10:26:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 20DBBE070E; Mon, 22 Nov 2010 10:26:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101122182646.20DBBE070E@rfc-editor.org> Date: Mon, 22 Nov 2010 10:26:46 -0800 (PST) Cc: msec@ietf.org, rfc-editor@rfc-editor.org Subject: [MSEC] RFC 6054 on Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic 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, 22 Nov 2010 18:26:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6054 Title: Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic Author: D. McGrew, B. Weis Status: Standards Track Stream: IETF Date: November 2010 Mailbox: mcgrew@cisco.com, bew@cisco.com Pages: 10 Characters: 22672 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-msec-ipsec-group-counter-modes-06.txt URL: http://www.rfc-editor.org/rfc/rfc6054.txt 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. [STANDARDS-TRACK] This document is a product of the Multicast Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC