From msec-admin@securemulticast.org Fri Jan 9 11:52:55 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13724 for ; Fri, 9 Jan 2004 11:52:55 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 955985368F; Fri, 9 Jan 2004 11:52:20 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 77F805353F for ; Fri, 9 Jan 2004 11:51:34 -0500 (EST) Received: (qmail 54371 invoked by uid 3269); 9 Jan 2004 16:51:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54368 invoked from network); 9 Jan 2004 16:51:34 -0000 Received: from thoth.sbs.de (192.35.17.2) by klesh.pair.com with SMTP; 9 Jan 2004 16:51:34 -0000 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i09GpUS16251; Fri, 9 Jan 2004 17:51:30 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i09GpTL08284; Fri, 9 Jan 2004 17:51:29 +0100 (MET) Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id RAA00669; Fri, 9 Jan 2004 17:51:16 +0100 (MET) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Jan 2004 17:51:28 +0100 Message-ID: <8C878B55C96F924389908D4A7384842A0139E2C8@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: msec@securemulticast.org, Euchner Martin Cc: "'thardjono@verisign.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: I-D ACTION:draft-ietf-msec-mikey-dhhmac-05.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 9 Jan 2004 17:51:26 +0100 I just forgot to send this message following the announcement. DHHMAC-05 addresses the issues raised on the mailing list a while ago as well as discussed during the Minneapolis meeting. Changes against draft-ietf-msec-mikey-dhhmac-04.txt: * Introduction section modified: PFS property of DH, requirement for 4th MIKEY key management variant motivated. * MIKEY-DHSIGN, MIKEY-PK and MIKEY-PS added to section 1.2 Abbreviations. * Note on secure time synchronization added to section 2.0. * New section 2.2 "Relation to GMKARCH" added. * New section 2.1.1 "Usage in H.235" added: this section outlines a use case of DHHMAC in the context of H.235. * Trade-off between identity-protection and security & performance added to section 5.1. * New section 5.6 "Authorization and Trust Model" added. * Some further informative references added. Unless I miss anything, this should bring closure on DHHMAC. I assume that DHHMAC may progress to IESG review. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, December 04, 2003 9:39 PM Cc: msec@securemulticast.org Subject: I-D ACTION:draft-ietf-msec-mikey-dhhmac-05.txt << Message: Untitled Attachment >> 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 : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-05.txt Pages : 32 Date : 2003-12-4 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-dhhmac-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jan 15 16:11:10 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28590 for ; Thu, 15 Jan 2004 16:11:09 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CA21F53592; Thu, 15 Jan 2004 16:10:38 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5778153547 for ; Thu, 15 Jan 2004 16:09:55 -0500 (EST) Received: (qmail 90575 invoked by uid 3269); 15 Jan 2004 21:09:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90572 invoked from network); 15 Jan 2004 21:09:55 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 15 Jan 2004 21:09:55 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28486; Thu, 15 Jan 2004 16:09:52 -0500 (EST) Message-Id: <200401152109.QAA28486@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-arch-05.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 15 Jan 2004 16:09:52 -0500 --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 Multicast Security Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-05.txt Pages : 24 Date : 2004-1-15 This document provides an overview and rationale of the multicast security architecture used for large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-arch-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-arch-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-15152510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-arch-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-15152510.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 16 16:29:34 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00102 for ; Fri, 16 Jan 2004 16:29:33 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BBE1453807; Fri, 16 Jan 2004 16:28:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C3BC4537A6 for ; Fri, 16 Jan 2004 16:26:47 -0500 (EST) Received: (qmail 20594 invoked by uid 3269); 16 Jan 2004 21:26:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20591 invoked from network); 16 Jan 2004 21:26:47 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 16 Jan 2004 21:26:47 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i0GLQE820141; Fri, 16 Jan 2004 16:26:14 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CZNTHA5B; Fri, 16 Jan 2004 16:26:13 -0500 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YZQX9G8V; Fri, 16 Jan 2004 16:26:14 -0500 Message-ID: <400856F5.4060609@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Cc: Brian Weis , George Gross Subject: Rekey SA identifier (Re: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability) References: <3F859D19.9030506@americasm06.nt.com> <3F8DC241.C8EC0BE9@cisco.com> In-Reply-To: <3F8DC241.C8EC0BE9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 16 Jan 2004 16:26:13 -0500 Content-Transfer-Encoding: 7bit GKMarch-06- says that a Rekey SA is identified by a triple . Brian and George noted that there is no need for the third parameter. I agree (can't recall why we put it there :-[ ). However, I have two questions. Existing protocols use the following: GDOI: Brian noted that GDOI uses {protocol, src addr/port, dst addr/port, SPI}. Do we really need all those? GSAKMP: uses Group ID TLV 2) I notice on further thought that or any of the above two sets of parameters might not be collision-proof. If a member is part of two secure groups managed by two different GCKSs, it may receive the same Group ID and SPI for two rekey SAs. If the "Group ID" is an SSM address , this can be avoided. In other cases, e.g., ASM/ISM address or an arbitrary 32-bit number, we might run into problems. Any ideas? regards, Lakshminath Brian Weis wrote: > 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not > >>>clear from the text here why this extra identifier was needed in >>>addition to the SPI? >>> >>> >>> >>The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. >> >> > >I'm still confused ... why would we need a protocol id to identify a >rekey message? I can see where a group identifier (as defined in Section >6.3.1) could be useful to uniquely identifier a rekey message as being >part of a specific group, but not why the rekey message would need its >own protocol type? > >In GDOI, a receiver of a rekey message recognizes a rekey message >matching {protocol, src addr/port, dst addr/port, SPI}. Strictly >speaking, there is neither a group identifier nor a rekey identifier. I >can see where adding a group identifier might be useful in the rare case >that two GDOI groups used the same network layer address, and also chose >the same SPIs. But how would a rekey identifier help? > >Thanks, >Brian > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Jan 17 11:15:09 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11200 for ; Sat, 17 Jan 2004 11:15:03 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0A2AB53873; Sat, 17 Jan 2004 11:14:15 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id CD507535EA for ; Sat, 17 Jan 2004 11:13:42 -0500 (EST) Received: (qmail 60436 invoked by uid 3269); 17 Jan 2004 16:13:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60433 invoked from network); 17 Jan 2004 16:13:42 -0000 Received: from smtp-out1.oct.nac.net (209.123.233.211) by klesh.pair.com with SMTP; 17 Jan 2004 16:13:42 -0000 Received: (qmail 39477 invoked from network); 17 Jan 2004 16:13:42 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 17 Jan 2004 16:13:42 -0000 Received: (qmail 8000 invoked from network); 17 Jan 2004 11:13:41 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.76) by mail1.oct.nac.net with SMTP; 17 Jan 2004 11:13:41 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id i0HEsMn06670; Sat, 17 Jan 2004 09:54:22 -0500 From: George Gross To: "Dondeti, Lakshminath" Cc: , Brian Weis , George Gross Subject: Re: Rekey SA identifier (Re: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability) In-Reply-To: <400856F5.4060609@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sat, 17 Jan 2004 09:54:22 -0500 (EST) Hi Lakshminath, On Fri, 16 Jan 2004, Dondeti, Lakshminath wrote: > GKMarch-06- says that a Rekey SA is identified by a triple SPI, Identifier for "Rekey Protocol" a la ESP/AH>. Brian and George > noted that there is no need for the third parameter. I agree (can't > recall why we put it there :-[ ). However, I have two questions. > > Existing protocols use the following: > GDOI: Brian noted that GDOI uses {protocol, src addr/port, dst > addr/port, SPI}. Do we really need all those? I'm fairly sure that you do. You would need to fully qualify your SPD entries to direct the "right" traffic into the group data SA. On the receive side, you may be dealing with source-specific multicast, so there is a requirement for source address. As per the rfc401bis Internet Draft, right? > GSAKMP: uses Group ID TLV Yup. The GSAKMP group policy token is being reworked, and the IPSEC mapping aspects will initialize the multicast data SPD/SAD entries. The Group ID is simply a handle that refs that policy token blob. > > 2) I notice on further thought that or any of the above > two sets of parameters might not be collision-proof. If a member is > part of two secure groups managed by two different GCKSs, it may receive > the same Group ID and SPI for two rekey SAs. If the "Group ID" is an > SSM address , this can be avoided. In other cases, e.g., > ASM/ISM address or an arbitrary 32-bit number, we might run into problems. > > Any ideas? This topic has been discussed among the GSAKMP co-authors. However, the spec probably won't be rev'd to change bits on the wire to handle this issue. The algorithm I thought up to mitigate it didn't cover all cases and was complex. I think the best defence is static configuration of the multiple GC/KS to avoid duplicate SPI assignments to a common multicast channel. You're probably faced with an operational step like this anyway to avoid SPI collisions with IKE originated unicast SA. Lakshminath, did you have a solution in mind? br, George > > regards, > Lakshminath > > Brian Weis wrote: > > > 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not > > > >>>clear from the text here why this extra identifier was needed in > >>>addition to the SPI? > >>> > >>> > >>> > >>The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. > >> > >> > > > >I'm still confused ... why would we need a protocol id to identify a > >rekey message? I can see where a group identifier (as defined in Section > >6.3.1) could be useful to uniquely identifier a rekey message as being > >part of a specific group, but not why the rekey message would need its > >own protocol type? > > > >In GDOI, a receiver of a rekey message recognizes a rekey message > >matching {protocol, src addr/port, dst addr/port, SPI}. Strictly > >speaking, there is neither a group identifier nor a rekey identifier. I > >can see where adding a group identifier might be useful in the rare case > >that two GDOI groups used the same network layer address, and also chose > >the same SPIs. But how would a rekey identifier help? > > > >Thanks, > >Brian > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 19 07:34:37 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14536 for ; Mon, 19 Jan 2004 07:34:35 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 89E33535CA; Mon, 19 Jan 2004 07:34:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 13CA35355F for ; Mon, 19 Jan 2004 07:32:31 -0500 (EST) Received: (qmail 6930 invoked by uid 3269); 19 Jan 2004 12:32:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6927 invoked from network); 19 Jan 2004 12:32:30 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 19 Jan 2004 12:32:30 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i0JCWTS22064; Mon, 19 Jan 2004 13:32:29 +0100 (MET) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id i0JCWSP07411; Mon, 19 Jan 2004 13:32:28 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mars.cert.siemens.de (8.12.10/8.12.10/$SiemensCERT: mail/cert.mc.pre,v 1.56 2003/11/06 20:07:28 ust Exp $) with ESMTP id i0JCWSEB086827; Mon, 19 Jan 2004 13:32:28 +0100 (CET) Received: from mhpaba5c (mhpaba5c [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id i0JCWSXG001418; Mon, 19 Jan 2004 13:32:28 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: "Elisabetta Carrara (KI/EAB)" MIME-Version: 1.0 Subject: Re: [MSEC] RE: MIKEY Question Reply-To: steffen.fries@siemens.com Cc: msec@securemulticast.org Message-ID: <400BDC6D.21218.EE610BF@localhost> Priority: normal In-reply-to: <4E85E49D1F0CBF4F96EA08E335750D7D062EFF2A@Esealnt877.al.sw.ericsson.se> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 13:32:29 +0100 Content-Transfer-Encoding: 7BIT Hi Elisabetta, I've got a question to the MAC Calculation in MIKEY. In the 08 version of the draft, section 5.2, the following abstact describes the MAC calculation on the receiver side: * Calculate the MAC/signature over the entire MIKEY message, except the MAC/Signature field, and add the MAC/signature in the field. In the case of the verification message, the Identity_i || Identity_r || Timestamp MUST follow directly after the MIKEY message in the Verification MAC calculation. Note that the identities and the timestamp that are added are identical to those transported in the ID and T payloads. I have two questions to this: 1. Since the ID payload is an optional field, can I assume, that the sender did not include the ID field in the hash calculation, when this ID payload is not part of the message? 2. When calculating the hash over the entire message, as described above, do I simply exclude the MAC field from the message or is it set to a defined value, e.g., 0x00? Regards Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 19 10:12:30 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19483 for ; Mon, 19 Jan 2004 10:12:22 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6C3215362C; Mon, 19 Jan 2004 10:08:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AC02E53656 for ; Mon, 19 Jan 2004 10:06:05 -0500 (EST) Received: (qmail 46044 invoked by uid 3269); 19 Jan 2004 15:06:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 46041 invoked from network); 19 Jan 2004 15:06:05 -0000 Received: from eagle.ericsson.se (193.180.251.53) by klesh.pair.com with SMTP; 19 Jan 2004 15:06:05 -0000 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i0JF64Ah010530; Mon, 19 Jan 2004 16:06:04 +0100 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Jan 2004 16:07:52 +0100 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D062F0171@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (KI/EAB)" To: "'steffen.fries@siemens.com'" Cc: msec@securemulticast.org Subject: RE: [MSEC] RE: MIKEY Question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 16:00:37 +0100 Hi Steffen, > > * Calculate the MAC/signature over the entire MIKEY message, > except the MAC/Signature field, and add the MAC/signature in > the field. In the case of the verification message, the > Identity_i || Identity_r || Timestamp MUST follow directly > after the MIKEY message in the Verification MAC calculation. > Note that the identities and the timestamp that are added are > identical to those transported in the ID and T payloads. > > I have two questions to this: > 1. Since the ID payload is an optional field, can I assume, > that the sender did not include the ID field in the hash > calculation, when this ID payload is not part of the > message? correct > 2. When calculating the hash over the entire message, as > described above, do I simply exclude the MAC field from the > message or is it set to a defined value, e.g., 0x00? you exclude the MAC field. Cheers /E _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 19 16:15:11 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08830 for ; Mon, 19 Jan 2004 16:15:06 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 83FA8535CC; Mon, 19 Jan 2004 16:14:16 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0142153585 for ; Mon, 19 Jan 2004 16:12:42 -0500 (EST) Received: (qmail 22423 invoked by uid 3269); 19 Jan 2004 21:12:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22420 invoked from network); 19 Jan 2004 21:12:38 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 19 Jan 2004 21:12:38 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i0JL5dA292928; Mon, 19 Jan 2004 16:05:39 -0500 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i0JL5cN37106; Mon, 19 Jan 2004 16:05:38 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i0JL5Xx40428; Mon, 19 Jan 2004 16:05:33 -0500 From: canetti To: George Gross Cc: "Dondeti, Lakshminath" , msec@securemulticast.org, Brian Weis Subject: Re: Rekey SA identifier (Re: [MSEC] msec-gkmarch-06.txt: GCKS implosion, scalability) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 16:05:32 -0500 (EST) I'm a bit confused, since I dont see an "update period" counter included in the signed message. Is this information implicit in another field? Ran On Sat, 17 Jan 2004, George Gross wrote: > Hi Lakshminath, > > On Fri, 16 Jan 2004, Dondeti, Lakshminath wrote: > > > GKMarch-06- says that a Rekey SA is identified by a triple > SPI, Identifier for "Rekey Protocol" a la ESP/AH>. Brian and George > > noted that there is no need for the third parameter. I agree (can't > > recall why we put it there :-[ ). However, I have two questions. > > > > Existing protocols use the following: > > GDOI: Brian noted that GDOI uses {protocol, src addr/port, dst > > addr/port, SPI}. Do we really need all those? > > I'm fairly sure that you do. You would need to fully qualify your SPD > entries to direct the "right" traffic into the group data SA. On the > receive side, you may be dealing with source-specific multicast, so there > is a requirement for source address. As per the rfc401bis Internet Draft, > right? > > > GSAKMP: uses Group ID TLV > > Yup. The GSAKMP group policy token is being reworked, and the IPSEC > mapping aspects will initialize the multicast data SPD/SAD entries. The > Group ID is simply a handle that refs that policy token blob. > > > > > 2) I notice on further thought that or any of the above > > two sets of parameters might not be collision-proof. If a member is > > part of two secure groups managed by two different GCKSs, it may receive > > the same Group ID and SPI for two rekey SAs. If the "Group ID" is an > > SSM address , this can be avoided. In other cases, e.g., > > ASM/ISM address or an arbitrary 32-bit number, we might run into problems. > > > > Any ideas? > > This topic has been discussed among the GSAKMP co-authors. However, the > spec probably won't be rev'd to change bits on the wire to handle this > issue. The algorithm I thought up to mitigate it didn't cover all cases > and was complex. I think the best defence is static configuration of the > multiple GC/KS to avoid duplicate SPI assignments to a common multicast > channel. You're probably faced with an operational step like this anyway > to avoid SPI collisions with IKE originated unicast SA. > > Lakshminath, did you have a solution in mind? > > br, > George > > > > > > regards, > > Lakshminath > > > > Brian Weis wrote: > > > > > 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not > > > > > >>>clear from the text here why this extra identifier was needed in > > >>>addition to the SPI? > > >>> > > >>> > > >>> > > >>The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. > > >> > > >> > > > > > >I'm still confused ... why would we need a protocol id to identify a > > >rekey message? I can see where a group identifier (as defined in Section > > >6.3.1) could be useful to uniquely identifier a rekey message as being > > >part of a specific group, but not why the rekey message would need its > > >own protocol type? > > > > > >In GDOI, a receiver of a rekey message recognizes a rekey message > > >matching {protocol, src addr/port, dst addr/port, SPI}. Strictly > > >speaking, there is neither a group identifier nor a rekey identifier. I > > >can see where adding a group identifier might be useful in the rare case > > >that two GDOI groups used the same network layer address, and also chose > > >the same SPIs. But how would a rekey identifier help? > > > > > >Thanks, > > >Brian > > > > > > > > > > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jan 20 00:11:18 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01111 for ; Tue, 20 Jan 2004 00:11:17 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 637A6536BF; Tue, 20 Jan 2004 00:10:47 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B81AA53633 for ; Mon, 19 Jan 2004 20:25:10 -0500 (EST) Received: (qmail 69464 invoked by uid 3269); 20 Jan 2004 01:25:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69459 invoked from network); 20 Jan 2004 01:25:10 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 20 Jan 2004 01:25:10 -0000 Received: from cisco.com ([128.107.177.199]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i0K1OZVM016462; Mon, 19 Jan 2004 17:24:36 -0800 (PST) Message-ID: <400C8352.E2ED38D@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: canetti Cc: msec@securemulticast.org Subject: Re: Rekey SA identifier (Re: [MSEC] msec-gkmarch-06.txt: GCKSimplosion, scalability) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 19 Jan 2004 17:24:34 -0800 Content-Transfer-Encoding: 7bit Hi Ran, It's called a "sequence number" in Section 5.3, and specified in Section 6.2.5. Brian canetti wrote: > > I'm a bit confused, since I dont see an "update period" counter included > in the signed message. Is this information implicit in another field? > > Ran > > On Sat, 17 Jan 2004, George Gross wrote: > > > Hi Lakshminath, > > > > On Fri, 16 Jan 2004, Dondeti, Lakshminath wrote: > > > > > GKMarch-06- says that a Rekey SA is identified by a triple > > SPI, Identifier for "Rekey Protocol" a la ESP/AH>. Brian and George > > > noted that there is no need for the third parameter. I agree (can't > > > recall why we put it there :-[ ). However, I have two questions. > > > > > > Existing protocols use the following: > > > GDOI: Brian noted that GDOI uses {protocol, src addr/port, dst > > > addr/port, SPI}. Do we really need all those? > > > > I'm fairly sure that you do. You would need to fully qualify your SPD > > entries to direct the "right" traffic into the group data SA. On the > > receive side, you may be dealing with source-specific multicast, so there > > is a requirement for source address. As per the rfc401bis Internet Draft, > > right? > > > > > GSAKMP: uses Group ID TLV > > > > Yup. The GSAKMP group policy token is being reworked, and the IPSEC > > mapping aspects will initialize the multicast data SPD/SAD entries. The > > Group ID is simply a handle that refs that policy token blob. > > > > > > > > 2) I notice on further thought that or any of the above > > > two sets of parameters might not be collision-proof. If a member is > > > part of two secure groups managed by two different GCKSs, it may receive > > > the same Group ID and SPI for two rekey SAs. If the "Group ID" is an > > > SSM address , this can be avoided. In other cases, e.g., > > > ASM/ISM address or an arbitrary 32-bit number, we might run into problems. > > > > > > Any ideas? > > > > This topic has been discussed among the GSAKMP co-authors. However, the > > spec probably won't be rev'd to change bits on the wire to handle this > > issue. The algorithm I thought up to mitigate it didn't cover all cases > > and was complex. I think the best defence is static configuration of the > > multiple GC/KS to avoid duplicate SPI assignments to a common multicast > > channel. You're probably faced with an operational step like this anyway > > to avoid SPI collisions with IKE originated unicast SA. > > > > Lakshminath, did you have a solution in mind? > > > > br, > > George > > > > > > > > > > regards, > > > Lakshminath > > > > > > Brian Weis wrote: > > > > > > > 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not > > > > > > > >>>clear from the text here why this extra identifier was needed in > > > >>>addition to the SPI? > > > >>> > > > >>> > > > >>> > > > >>The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. > > > >> > > > >> > > > > > > > >I'm still confused ... why would we need a protocol id to identify a > > > >rekey message? I can see where a group identifier (as defined in Section > > > >6.3.1) could be useful to uniquely identifier a rekey message as being > > > >part of a specific group, but not why the rekey message would need its > > > >own protocol type? > > > > > > > >In GDOI, a receiver of a rekey message recognizes a rekey message > > > >matching {protocol, src addr/port, dst addr/port, SPI}. Strictly > > > >speaking, there is neither a group identifier nor a rekey identifier. I > > > >can see where adding a group identifier might be useful in the rare case > > > >that two GDOI groups used the same network layer address, and also chose > > > >the same SPIs. But how would a rekey identifier help? > > > > > > > >Thanks, > > > >Brian > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jan 20 14:14:20 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16538 for ; Tue, 20 Jan 2004 14:14:20 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 14B62539E5; Tue, 20 Jan 2004 13:45:15 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2549B53543 for ; Tue, 20 Jan 2004 13:03:21 -0500 (EST) Received: (qmail 98559 invoked by uid 3269); 20 Jan 2004 18:03:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98556 invoked from network); 20 Jan 2004 18:03:20 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 20 Jan 2004 18:03:20 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i0KI2gA301232; Tue, 20 Jan 2004 13:02:42 -0500 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i0KI2gF46848; Tue, 20 Jan 2004 13:02:42 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i0KI2fR58104; Tue, 20 Jan 2004 13:02:41 -0500 From: canetti To: Brian Weis Cc: msec@securemulticast.org Subject: Re: Rekey SA identifier (Re: [MSEC] msec-gkmarch-06.txt: GCKSimplosion, scalability) In-Reply-To: <400C8352.E2ED38D@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 20 Jan 2004 13:02:40 -0500 (EST) Yes. thanks for the reminder. But, looking at the text again, it seems to me that the need to authenticate the rekey messages is not stressed enough in the text (section 5). Some language should be added... Ran On Mon, 19 Jan 2004, Brian Weis wrote: > Hi Ran, > > It's called a "sequence number" in Section 5.3, and specified in Section > 6.2.5. > > Brian > > canetti wrote: > > > > I'm a bit confused, since I dont see an "update period" counter included > > in the signed message. Is this information implicit in another field? > > > > Ran > > > > On Sat, 17 Jan 2004, George Gross wrote: > > > > > Hi Lakshminath, > > > > > > On Fri, 16 Jan 2004, Dondeti, Lakshminath wrote: > > > > > > > GKMarch-06- says that a Rekey SA is identified by a triple > > > SPI, Identifier for "Rekey Protocol" a la ESP/AH>. Brian and George > > > > noted that there is no need for the third parameter. I agree (can't > > > > recall why we put it there :-[ ). However, I have two questions. > > > > > > > > Existing protocols use the following: > > > > GDOI: Brian noted that GDOI uses {protocol, src addr/port, dst > > > > addr/port, SPI}. Do we really need all those? > > > > > > I'm fairly sure that you do. You would need to fully qualify your SPD > > > entries to direct the "right" traffic into the group data SA. On the > > > receive side, you may be dealing with source-specific multicast, so there > > > is a requirement for source address. As per the rfc401bis Internet Draft, > > > right? > > > > > > > GSAKMP: uses Group ID TLV > > > > > > Yup. The GSAKMP group policy token is being reworked, and the IPSEC > > > mapping aspects will initialize the multicast data SPD/SAD entries. The > > > Group ID is simply a handle that refs that policy token blob. > > > > > > > > > > > 2) I notice on further thought that or any of the above > > > > two sets of parameters might not be collision-proof. If a member is > > > > part of two secure groups managed by two different GCKSs, it may receive > > > > the same Group ID and SPI for two rekey SAs. If the "Group ID" is an > > > > SSM address , this can be avoided. In other cases, e.g., > > > > ASM/ISM address or an arbitrary 32-bit number, we might run into problems. > > > > > > > > Any ideas? > > > > > > This topic has been discussed among the GSAKMP co-authors. However, the > > > spec probably won't be rev'd to change bits on the wire to handle this > > > issue. The algorithm I thought up to mitigate it didn't cover all cases > > > and was complex. I think the best defence is static configuration of the > > > multiple GC/KS to avoid duplicate SPI assignments to a common multicast > > > channel. You're probably faced with an operational step like this anyway > > > to avoid SPI collisions with IKE originated unicast SA. > > > > > > Lakshminath, did you have a solution in mind? > > > > > > br, > > > George > > > > > > > > > > > > > > regards, > > > > Lakshminath > > > > > > > > Brian Weis wrote: > > > > > > > > > 2. section 6.2.6 mentions "an identifier for Rekey SA", and I was not > > > > > > > > > >>>clear from the text here why this extra identifier was needed in > > > > >>>addition to the SPI? > > > > >>> > > > > >>> > > > > >>> > > > > >>The identifier would be similar to protocol IDs, viz., AH and ESP, in IPsec. > > > > >> > > > > >> > > > > > > > > > >I'm still confused ... why would we need a protocol id to identify a > > > > >rekey message? I can see where a group identifier (as defined in Section > > > > >6.3.1) could be useful to uniquely identifier a rekey message as being > > > > >part of a specific group, but not why the rekey message would need its > > > > >own protocol type? > > > > > > > > > >In GDOI, a receiver of a rekey message recognizes a rekey message > > > > >matching {protocol, src addr/port, dst addr/port, SPI}. Strictly > > > > >speaking, there is neither a group identifier nor a rekey identifier. I > > > > >can see where adding a group identifier might be useful in the rare case > > > > >that two GDOI groups used the same network layer address, and also chose > > > > >the same SPIs. But how would a rekey identifier help? > > > > > > > > > >Thanks, > > > > >Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > -- > Brian Weis > Strategic Cryptographic Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jan 22 18:50:46 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20681 for ; Thu, 22 Jan 2004 18:50:45 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 477FB538B1; Thu, 22 Jan 2004 18:50:14 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5D06D5371E for ; Thu, 22 Jan 2004 18:49:19 -0500 (EST) Received: (qmail 7731 invoked by uid 3269); 22 Jan 2004 23:49:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7728 invoked from network); 22 Jan 2004 23:49:19 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 22 Jan 2004 23:49:19 -0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id i0MNnDRt000697; Thu, 22 Jan 2004 15:49:13 -0800 (PST) Received: from mou1thardjon-l1.verisign.com (mou1thardjon-l1.vcorp.ad.vrsn.com [10.25.161.62]) by mou1wnexc02.vcorp.ad.vrsn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DC96CY0Y; Thu, 22 Jan 2004 15:49:13 -0800 Message-Id: <6.0.0.22.2.20040122154236.01e54210@pop.mail.yahoo.com> X-Sender: thardjono@MOU1WNEXM03.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, housley@vigilsec.com, smb@research.att.com, thardjono@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] WG Last Call for GKM-Architecture draft (closing date 4 Feb 2004) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 22 Jan 2004 15:51:17 -0800 Folks, The authors of the GKM-Architecture draft have indicated that the draft is ready for WG Last Call. You can get the latest version here: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-07.txt Since this draft has been in-discussion for a long time, I would like to begin WG Last Call for the GKM-Arch draft, with a closing date of 4 February 2004. Please send your comments to the list a.s.a.p. Regards. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 23 12:01:00 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11339 for ; Fri, 23 Jan 2004 12:00:58 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 89AC053AA2; Fri, 23 Jan 2004 12:00:07 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A3E2853AAC for ; Fri, 23 Jan 2004 11:59:23 -0500 (EST) Received: (qmail 42287 invoked by uid 3269); 23 Jan 2004 16:59:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42284 invoked from network); 23 Jan 2004 16:59:23 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 23 Jan 2004 16:59:23 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i0NGwqu53112 for ; Fri, 23 Jan 2004 11:58:52 -0500 Received: from ornavella.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i0NGwqP47372 for ; Fri, 23 Jan 2004 11:58:52 -0500 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i0NGwpE36892 for ; Fri, 23 Jan 2004 11:58:51 -0500 From: canetti To: msec@securemulticast.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] Msec meeting in Seoul Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 23 Jan 2004 11:58:50 -0500 (EST) Folks, We would like to get a sense of how many people are planning on attending an MSEC meeting in Seoul. There will be several business items, including (but not limited to): -An updated GKMARCH document (after last call, on its way to IESG review) -ESP with digital signatures draft -Updated informational TESLA document -TESLA on ESP document -TESLA on SRTP document -Potentially MSEC requirements document So if you plan on attending then please drop one of us a note (especially if you're one of the active contributors to msec). Thanks, Ran and Thomas - _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 23 16:02:53 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22616 for ; Fri, 23 Jan 2004 16:02:52 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1581453A17; Fri, 23 Jan 2004 16:02:15 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C22FE53545 for ; Fri, 23 Jan 2004 16:01:32 -0500 (EST) Received: (qmail 97323 invoked by uid 3269); 23 Jan 2004 21:01:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97320 invoked from network); 23 Jan 2004 21:01:32 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 23 Jan 2004 21:01:32 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22458; Fri, 23 Jan 2004 16:01:29 -0500 (EST) Message-Id: <200401232101.QAA22458@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-gkmarch-07.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 23 Jan 2004 16:01:29 -0500 --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 : MSEC Group Key Management Architecture Author(s) : M. Baugher Filename : draft-ietf-msec-gkmarch-07.txt Pages : 37 Date : 2004-1-23 This document defines the common architecture for Multicast Security (MSEC) key management protocols that support a variety of application, transport, and network layer security protocols. It also defines the group SA (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document allow for a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. Comments on this document should be sent to msec@securemulticast.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gkmarch-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gkmarch-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-23162159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-23162159.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jan 30 15:52:28 2004 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15990 for ; Fri, 30 Jan 2004 15:52:28 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5C3D45395B; Fri, 30 Jan 2004 15:50:22 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B64CD53736 for ; Fri, 30 Jan 2004 15:48:40 -0500 (EST) Received: (qmail 81400 invoked by uid 3269); 30 Jan 2004 20:48:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81396 invoked from network); 30 Jan 2004 20:48:40 -0000 Received: from s2.itd.nrl.navy.mil (132.250.83.3) by klesh.pair.com with SMTP; 30 Jan 2004 20:48:40 -0000 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i0UKmULh028083 for ; Fri, 30 Jan 2004 15:48:40 -0500 (EST) Received: from itd.nrl.navy.mil ([132.250.196.100]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.3.37) with SMTP id M2004013015483919824 for ; Fri, 30 Jan 2004 15:48:39 -0500 Received: from itd.nrl.navy.mil (liverwurst [10.0.3.31]) by itd.nrl.navy.mil (8.9.3p2/8.9.0) with ESMTP id PAA01364; Fri, 30 Jan 2004 15:47:40 -0500 (EST) Received: (from meadows@localhost) by itd.nrl.navy.mil (8.12.9/8.12.9/Submit) id i0UKlddP001659; Fri, 30 Jan 2004 15:47:39 -0500 (EST) From: "Catherine A. Meadows" Message-Id: <200401302047.i0UKlddP001659@itd.nrl.navy.mil> To: msec@securemulticast.org Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Subject: [MSEC] security problem in GDOI proof of possesion (and fix) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 30 Jan 2004 15:47:39 -0500 (EST) This message describes a security problem that Dusko Pavlovic and I found in the GDOI proof of possession while doing a formal analysis, as well as a proposed fix, which we have developed in cooperation with Ran Canetti and the GDOI authors. Comments are welcome. 1. Background. Proof-of-possession prvides and optional means of providing authorization for group members. For example, suppose that a group member has made arrangements with a content provider, and then wants to join a group that distributes the content. Proof-of-possesion provides the means by which the member can prove to the GCKS that the content provider has authorized it to join the group. Proof-of-possession works as follows. A member obtains a credential containing certain privileges, a public key, and a new identity (this new identity could actually be the key, as in SPKI/SDSI). The member also receives the corresponding private key. The member joins a group by initiating a groopkey-pull protocol with a GCKS that is encrypted and authenticated with a Phase 1 IKE key. Ownership of the private key (and hence possession of the authorizations) is given by signing two nonces, one provided by the member, and one by the GCKS, along with the prepended string "pop" (to prevent type confusion attacks. This is call proof-of-posession, or POP. A protocol with member PoP (slightly simplifed) appears as follows. All information is assumed to be encrypted and authenticated with the Phase 1 key. 1. M --> GCKS : Ni, ID ID is the identifier of the group 2. GCKS --> M : Nr, SA SA is the security association of the current group key 3. M --> GCKS : CERT, POP = S_P(hash(pop,Ni,Nr)) CERT is the certificate containing the new identity and authorizations, POP is the signature with the key corresponding to the new identity on the nonces Ni and Nr 4. GCKS --> M : KD KD is the the actual keying material, and SEQ is a sequence number Suppose now that there are two groups. Group 1 is managed by a rogue GCKS who does not have authorization to join Group 2. Let A be a member with a CERT that gives it authorization to join both Groups 1 and 2,let B be the GCKS of group 2, and let I be the Group 1 GCKS. I can use the PoP to pass off A's credentials as its own, as follows: 1. A --> I : Ni, ID1 A requests to join I's Group 1, sending a nonce Ni 1.' I_member --> B : Ni, ID2 I requests to join B's group, forwarding A's nonce Ni 2.' B --> I_member : Nr', SA' B responds to I with its nonce Nr' 2. I --> A : Nr', SA I responds to member A, but using B's nonce Nr' 3. A --> I: CERT(for A's ID P in Group 2), POP = S_P(hash(pop,Ni,Nr')) A responds to I with a POP taken over A's and B's nonce 3.' I_member --> B: CERT(for A's ID in Group 2), POP = S_P(hash(Ni,Nr')) I as a member responds to B, using A's CERT and POP 4. B --> I_member : KD B sends keying information for Group 2 to I under impression the identity in A's certificate belongs to I step 4' is not necessary and isn't included Proof-of-possesion is also optionally provided for the GCKS, and other attacks involving a dishonest group member impersonating a GCKS are possible if that option is used. We are recommending the following solution for fixing this problem: The point of proof-of-possession is to prove that the owner of the identity associated with the Phase 1 key is the same as the owner of the key distributed in the CERT. One way of achieving this is to use a PoP that could only be constructed with a knowledge of the Phase 1 key and the CERT key. The version of the PoP we recommend using is thus of the following form: S_P(hash("pop",SKEY_A,Ni,Nr)), where SKEY_A is a key derived from the Phase 1 key, Ni is the member's nonce, and Nr is GCKS's nonce. We are working on an ID describing the problem and the recommended change, with the ultimate goal of including it in the next GDOI RFC. Comments are welcome. Cathy Meadows _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec