From msec-admin@securemulticast.org Tue Dec 4 13:55:00 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06583 for ; Tue, 4 Dec 2001 13:54:59 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D953153D66; Tue, 4 Dec 2001 13:46:19 -0500 (EST) Delivered-To: msec@pairlist.net Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by pairlist.net (Postfix) with ESMTP id A26ED5388A for ; Wed, 28 Nov 2001 17:25:36 -0500 (EST) Received: by sentry.gw.tislabs.com; id RAA09342; Wed, 28 Nov 2001 17:30:25 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma009317; Wed, 28 Nov 01 17:30:00 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fASMOxQ14603 for msec@lists.securemulticast.org; Wed, 28 Nov 2001 17:24:59 -0500 (EST) Message-Id: <200111282224.fASMOxQ14603@raven.gw.tislabs.com> From: balenson@tislabs.com To: msec@lists.securemulticast.org Subject: [MSEC] ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) 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 list List-Unsubscribe: , List-Archive: Date: Wed, 28 Nov 2001 17:24:59 -0500 (EST) R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 4 14:01:22 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06864 for ; Tue, 4 Dec 2001 14:01:22 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C2E0853D6A; Tue, 4 Dec 2001 13:46:21 -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 E011853993 for ; Fri, 30 Nov 2001 06:02:04 -0500 (EST) Received: (qmail 97110 invoked by uid 3269); 30 Nov 2001 11:02:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97107 invoked from network); 30 Nov 2001 11:02:04 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 30 Nov 2001 11:02:04 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02770; Fri, 30 Nov 2001 06:01:53 -0500 (EST) Message-Id: <200111301101.GAA02770@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-gdoi-02.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 list List-Unsubscribe: , List-Archive: Date: Fri, 30 Nov 2001 06:01: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 Group Domain of Interpretation Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gdoi-02.txt Pages : 39 Date : 29-Nov-01 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The 'GDOI' borrows definitions from GSAKMP, incorporates the Phase 1 SA of the Internet DOI, and proposes new payloads and exchanges according to the ISAKMP and IKE standards. The GDOI manages group security associations, which are used by 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-02.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-gdoi-02.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-gdoi-02.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: <20011129144603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011129144603.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 4 14:04:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07061 for ; Tue, 4 Dec 2001 14:04:54 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A85CF53D6F; Tue, 4 Dec 2001 13:46:23 -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 4B35B53A34 for ; Tue, 4 Dec 2001 10:01:19 -0500 (EST) Received: (qmail 39600 invoked by uid 3269); 4 Dec 2001 15:01:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39595 invoked from network); 4 Dec 2001 15:01:18 -0000 Received: from ws130.nomadiclab.com (195.165.196.130) by klesh.pair.com with SMTP; 4 Dec 2001 15:01:18 -0000 Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id A690874403; Tue, 4 Dec 2001 17:07:03 +0200 (EET) Received: from nomadiclab.com (ws211.nomadiclab.com [195.165.196.211]) by ws34.nomadiclab.com (Postfix) with ESMTP id B6023BA21; Tue, 4 Dec 2001 17:00:25 +0200 (EET) Message-ID: <3C0CE509.6000803@nomadiclab.com> From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6+) Gecko/20011129 X-Accept-Language: en-us MIME-Version: 1.0 To: Claude Castelluccia Cc: msec@securemulticast.org, ipng@sunroof.eng.sun.com, smug@cs.umass.edu, gab@sun.com References: <3C0275D9.484A2A4@inrialpes.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Comments to draft-castelluccia-sgmv6-00.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 list List-Unsubscribe: , List-Archive: Date: Tue, 04 Dec 2001 17:00:25 +0200 Content-Transfer-Encoding: 7bit Claude, [I am not a member in msec or smug, and therefore I don't know if this point has been taken up there already. It may even be that my message is rejected from those list due to my non-membership status.] I find the idea presented in the draft very refreshing and beautiful. The fact that multicast group IDs are 112 bits (instead of 64 bits) makes it work even better than for basic SUCV/CAM. On the other hand, since I am no expert in multicast and have only a very bad understanding on how you create new multicast groups in the first place, I cannot comment that side. Anyway, in Section 5.3 you write: > 2. The private key, the public key, the counter and the GroupID > are distributed to the (authorized) group members. Note that > private key requires confidentiality because it only has to > be known to the authorized group members. The public key, > the counter and the GroupID can be sent in clear but require > integrity. Now, I was left wondering why to send the private key itself? If we assume that all the hosts in the multicast group have their own public/private key pair (e.g. for basic SUCV or in order to authenticate them for some other reason), wouldn't it be easier just to delegate the right to join the multicast group? That is, instead of sending the private key, you would send an SPKI or KeyNote2 certificate stating that the public key of the host is authorized to join the multicast group represented by the group key? Delegation would make key distribution easier. Instead of sending the private key in a secure channel you just distribute the certificate. You don't even need to authenticate the member host if you know its public key beforehand. The certificate could take care of the integrity of the group public key, the counter and the GroupID, i.e. it would basically be a self-signed certificate. Furthermore, the delegation model would have additional benefits, i.e. it would allow better control of membership. If you add validity time to the certificate, you could control how long the hosts are members of the group. Secondly, if you distribute the private key, any host in the group can leak the private key, and you don't know who it was. In the delegation model, if a host leaks its own private key, you definitely know who it was, and you don't renew that host's certificate when it expires. (I assume, here, of course that the certificates would have relatively short lifetime, e.g. in the order of minutes or hours.) The delegation approach would also help with the replay attack problem (Section 6.3), since it would effectively limit the validity of the reports with the validity of the certificate. I am not so sure about the anycast case, though. My understanding about anycast is that in anycast you want all anycast hosts to behave equally. Therefore they should look the same, and distributing the private key might actually be a good idea. --Pekka Nikander _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Dec 7 16:52:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00897 for ; Fri, 7 Dec 2001 16:52:30 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8C0835355E; Fri, 7 Dec 2001 16:52: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 0B95453667 for ; Fri, 7 Dec 2001 16:50:05 -0500 (EST) Received: (qmail 38577 invoked by uid 3269); 7 Dec 2001 21:50:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38574 invoked from network); 7 Dec 2001 21:50:04 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.10) by klesh.pair.com with SMTP; 7 Dec 2001 21:50:04 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7Lmt906412; Fri, 7 Dec 2001 13:48:55 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sj-dial-3-230.cisco.com [171.68.180.231]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAL62688; Fri, 7 Dec 2001 13:48:21 -0800 (PST) Message-Id: <4.3.2.7.2.20011207134608.055f2940@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Pekka Nikander From: Mark Baugher Subject: Re: [MSEC] Comments to draft-castelluccia-sgmv6-00.txt Cc: Claude Castelluccia , msec@securemulticast.org, gsec@lists.tislabs.com In-Reply-To: <3C0CE509.6000803@nomadiclab.com> References: <3C0275D9.484A2A4@inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 list List-Unsubscribe: , List-Archive: Date: Fri, 07 Dec 2001 13:46:58 -0800 I can't find this draft on Internet Drafts. thanks, Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Dec 7 23:09:31 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07647 for ; Fri, 7 Dec 2001 23:09:30 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6A59C53EE8; Fri, 7 Dec 2001 23:01:18 -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 0E6CD535BA for ; Fri, 7 Dec 2001 20:27:26 -0500 (EST) Received: (qmail 67498 invoked by uid 3269); 8 Dec 2001 01:27:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67492 invoked from network); 8 Dec 2001 01:27:25 -0000 Received: from unknown (HELO mx1.ustc.edu.cn) (61.132.182.1) by klesh.pair.com with SMTP; 8 Dec 2001 01:27:25 -0000 Received: from xiongjiping (infonet.ustc.edu.cn [202.38.75.11]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id JAA04360; Sat, 8 Dec 2001 09:18:14 -0800 Message-Id: <200112081718.JAA04360@mx1.ustc.edu.cn> From: joe To: Mark Baugher Cc: "msec@securemulticast.org" , "gsec@lists.tislabs.com" Subject: Re: Re: [MSEC] Comments to draft-castelluccia-sgmv6-00.txt X-mailer: FoxMail 3.0 beta 2 [cn] 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 list List-Unsubscribe: , List-Archive: Date: Sat, 8 Dec 2001 9:28:42 +0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA07647 Mark You can get the draft from the URL http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-sgmv6-00.txt joe 2001-12-7 13:46:00 you wrote£º >I can't find this draft on Internet Drafts. > >thanks, Mark > > >_______________________________________________ >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 Thu Dec 13 17:59:54 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01082 for ; Thu, 13 Dec 2001 17:59:53 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1528653BC5; Thu, 13 Dec 2001 17:34:11 -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 16D4353BBD for ; Thu, 13 Dec 2001 17:32:33 -0500 (EST) Received: (qmail 17813 invoked by uid 3269); 13 Dec 2001 22:32:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17810 invoked from network); 13 Dec 2001 22:32:32 -0000 Received: from chmls05.mediaone.net (24.147.1.143) by klesh.pair.com with SMTP; 13 Dec 2001 22:32:32 -0000 Received: from THARDJONO-LAP.mediaone.net (202-200-131-12.bellhead.com [12.131.200.202]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id fBDMW8908204 for ; Thu, 13 Dec 2001 17:32:08 -0500 (EST) Message-Id: <5.0.0.25.2.20011213172717.01c98b38@pop.ne.mediaone.net> X-Sender: thardjono@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC WG meeting will be in Grand D ballroom on Friday morning 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 list List-Unsubscribe: , List-Archive: Date: Thu, 13 Dec 2001 17:31:34 -0500 Folks, The MSEC WG meeting will now be in grand D ballroom on Friday morning, which will allow the meeting to be recorded and multicasted. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Dec 17 17:14:11 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20420 for ; Mon, 17 Dec 2001 17:14:11 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AD004535B1; Mon, 17 Dec 2001 17:13:41 -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 20B44535B4 for ; Mon, 17 Dec 2001 17:09:54 -0500 (EST) Received: (qmail 53790 invoked by uid 3269); 17 Dec 2001 22:09:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53787 invoked from network); 17 Dec 2001 22:09:53 -0000 Received: from s2.itd.nrl.navy.mil (HELO itd.nrl.navy.mil) (132.250.83.3) by klesh.pair.com with SMTP; 17 Dec 2001 22:09:53 -0000 Received: from itd.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA04732 for ; Mon, 17 Dec 2001 17:09:47 -0500 (EST) Received: from liverwurst.fw5540.net (liverwurst [10.0.3.31]) by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id RAA16382; Mon, 17 Dec 2001 17:09:19 -0500 (EST) From: "Catherine A. Meadows" Received: (from meadows@localhost) by liverwurst.fw5540.net (8.9.0/8.8.8) id RAA01021; Mon, 17 Dec 2001 17:09:19 -0500 (EST) Message-Id: <200112172209.RAA01021@liverwurst.fw5540.net> To: msec@securemulticast.org Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Subject: [MSEC] GDOI 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 list List-Unsubscribe: , List-Archive: Date: Mon, 17 Dec 2001 17:09:19 -0500 (EST) Hi everybody: Brian Weis gave a brief account of a possible attack on GDOI that I had found at the msec meeting last Friday, along with a fix. There were more questions about this than could be answered in such a short time, so I promised to send a more in-depth account to the list. I actually found two attacks. One relies on more assumptions than the other, so I will discribe the simpler one first. ATTACK 1: There are two places where digital signatures are used in GDOI. One is where the GCKS sends the signed GROUPKEY-PUSH message. and the other is the optional use of Proof-of-Possesion signatures in the GROUPKEY-PULL protocol, in which member and/or GCKS may sign the concatenation I_i || I_r where I_i is a nonce supplied by the initiator (the member) and I_r is a nonce supplied by the responder (the GCKS). Under certain circumstances, it is possible for a dishonest group member to trick a GCKS into signing a bogus GROUPKEY-PUSH message when it thinks it is signing a POP. Recall that the GROUPKEY-PUSH message is of the form: HDR*, SEQ, SA, KD, [CERT,] SIG where the signed portion is HDR, SEQ, KD, [CERT] The format of the KD is not specified, but it is likely to end in a random number (that is, a key). So, if the optional CERT is not included, the signed message is likely to end in a random number. A dishonest member can use this fact to spoof a GROUPKEY-PUSH message in the following way, assuming that the following assumptions hold: A. The GCKS uses the same signature key to sign both its POP and the GROUPKEY-PUSH message. B. The nonce N_r supplied by the GCKS in the GROUPKEY-PULL protocol is no longer than the random number that could be found at the end of a KD. C. Even with the above restriction on the length of N_r, the GCKS will accept an N-i such that the length of N_i || N_r is the same as that of a possible GROUPKEY-PUSH message. Then the attack is as follows: 1. A dishonest group member initiaties a GROUPKEY-PULL protocol, but the N_i it supplies to the GCKS is of the form HDR, SEQ, KD' where KD' is a KD minus a portion at the end whose length is equal to the N_r supplied by the GCKS. 2. The GCKS returns a signature SIG on HDR, SEQ, KD' || N_r 3. The member encrypts the message and the signature with the current KEK (which it will know since it is a member of the group), to obtain HDR* SEQ, KD' || N_r, SIG and sends it out as a GROUPKEY-PUSH message. Note that the dishonest member has no control over the last part of the fake KD, since this is supplied by the GCKS. However, it would still be enough to mislead the other group members. The recommendations Brian had for changes to the document were to i. suggest that GCKS's use different signature keys and/or hash functions when signing POP's than when signing GROUPKEY-PUSH messages. ii. put an upper bound on the size of N_i and N_r, so that N_i || N _r would always be shorter than the shortest possible GROUPKEY-PUSH message. Mark Baugher also asked if having the GCKS sign N_r || N_i (insted of N_r || N_r) when signing the POP would prevent the attack. However, this would not work, because HDR, SEQ, KD begins, as well as ends, in a random number: the 16-octet SPI. Thus the dishonest member could mount the same attack by replacing part or all of the SPI with N_r instead of part of the KD. It also occurred to me, after following the discussion on IPSEC, that it would be possible to foil this attack by requiring POP signatures to be on the two nonces followed by some short non-random field. Thus, POP_I could be over (N_i || N_r || 0 ) and POP_R could be over (N_i || N_r || 1), although we might want to use different integers besides 0 and 1, since those are the ones currently being used by JFK. If we don't want to put a limit on the nonce sizes for whatever reason, this could be preferable. __________________________________ ATTACK 2 I also found another attack, which is converse of the one I presented above. It requires more assumptions than the first attack, so it is less of a threat, but I include it because it does not require that much more (if any) further change to the protocol to protect against it as well. Suppose that the following assumptions hold: A'. there is a group member that is also a GCKS, and that uses the same key for signing POPs as for signing GROUPKEY-PUSH messages. B'. a pairwise member/GCKS key is compromised, so that a bad guy is able to impersonate a GCKS to a member, although it does not know the GCKS's signature key. C'. the N_i generated by the group member/GCKS when it initiates a GROUPKEY-PULL protocol is no larger than a SPI D'. Even with the above restriction on the length of N_i, a group member will accept an N_r such that the length of N_i || N_r is the same as that of a possible GROUPKEY-PUSH message. 1. The group member, Alice, (who is also a GCKS) initiates a GROUPKEY-PULL protocol with the bad GCKS. The bad GCKS, Eve, sends a nonce N_r of the form HDR', SEQ, KD where HDR is is the HDR minus an initial portion equal in length to the N_i that would be generated by the group member/GCKS. 2. Alice signs the POP N_i || N_r = N_i || HDR', SEQ, KD 3.Eve encrypts N_i || HDR', SEQ, KD, SIG with the current KEK, and is able to pass off the message as a legitimately signed GROUPKEY-PUSH message. Note that Eve also has total control over what the KD looks like. This attack is somewhat less likely than the other one, since it requires that a principal act both as GCKS and member, and that it use the same signing key for both roles, and that a pairwise key is compromised. However, the same restriction on length that prevents the first attack will also prevent this one. If we instead wanted to use the option of including a non-random field in each message, we would have to either include such a non-random field in the beginning as well as the end of the message, or reverse the order of N_i and N_r in the POP message signed by the group member. Hope that this helps, Cathy _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Dec 18 13:35:32 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23636 for ; Tue, 18 Dec 2001 13:35:32 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 15D34536F4; Tue, 18 Dec 2001 13:35:01 -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 88E3A53550 for ; Tue, 18 Dec 2001 13:32:40 -0500 (EST) Received: (qmail 84227 invoked by uid 3269); 18 Dec 2001 18:32:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84224 invoked from network); 18 Dec 2001 18:32:39 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 18 Dec 2001 18:32:39 -0000 Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fBIIW3016322; Tue, 18 Dec 2001 10:32:03 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn3-490.cisco.com [10.21.65.234]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAN22451; Tue, 18 Dec 2001 10:31:31 -0800 (PST) Message-Id: <4.3.2.7.2.20011218101941.052cb0b8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Catherine A. Meadows" From: Mark Baugher Subject: Re: [MSEC] GDOI fix Cc: msec@securemulticast.org, meadows@itd.nrl.navy.mil In-Reply-To: <200112172209.RAA01021@liverwurst.fw5540.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 list List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 10:30:10 -0800 Cathy Thanks a lot, this is very helpful. I am still unclear about the second attack. But before delving into that, I have a couple of questions. First, the KD does not necessarily end with an SPI but with key attributes, which include a key and some metadata about the key. If this were always the case, would this prevent ATTACK 1? I don't like having this restriction on the KD payload since attributes are optional by definition. Second, what do you think about placing the SEQ after the KD since a message having an invalid SEQ would be rejected? I don't think that Brian's solution of using different keys for signing GROUPKEY-PULL (aka REGISTRATION) messages is a bad idea. But I wonder if there is a more parsimonious solution. thanks, Mark At 05:09 PM 12/17/2001 -0500, Catherine A. Meadows wrote: >Hi everybody: > >Brian Weis gave a brief account of a possible attack on GDOI that >I had found at the msec >meeting last Friday, along with a fix. There were more questions about this >than could be answered in such a short time, so I promised to send a more >in-depth account to the list. > >I actually found two attacks. One relies on more assumptions than the other, >so I will discribe the simpler one first. > >ATTACK 1: > >There are two places where digital signatures are used in GDOI. One >is where the GCKS sends the signed GROUPKEY-PUSH message. and the other >is the optional use of Proof-of-Possesion signatures in the GROUPKEY-PULL >protocol, in which member and/or GCKS may sign the concatenation I_i || I_r >where I_i is a nonce supplied by the initiator (the member) >and I_r is a nonce supplied by the responder (the GCKS). > >Under certain circumstances, it is possible for a dishonest group >member to trick a GCKS into signing a bogus GROUPKEY-PUSH message >when it thinks it is signing a POP. Recall that the GROUPKEY-PUSH message >is of the form: > >HDR*, SEQ, SA, KD, [CERT,] SIG > >where the signed portion is HDR, SEQ, KD, [CERT] >The format of the KD is not specified, but it is likely to end in >a random number (that is, a key). So, if the optional CERT is >not included, the signed message is likely to end in a random number. > >A dishonest member can use this fact to spoof a GROUPKEY-PUSH message >in the following way, assuming that the following assumptions hold: > >A. The GCKS uses the same signature key to sign both its POP >and the GROUPKEY-PUSH message. > >B. The nonce N_r supplied by the GCKS in the GROUPKEY-PULL protocol >is no longer than the random number that could be found at the end of >a KD. > >C. Even with the above restriction on the length of N_r, the GCKS >will accept an N-i such that the length of N_i || N_r is the same >as that of a possible GROUPKEY-PUSH message. > >Then the attack is as follows: > >1. A dishonest group member initiaties a GROUPKEY-PULL protocol, >but the N_i it supplies to the GCKS is of the form > >HDR, SEQ, KD' > >where KD' is a KD minus a portion at the end whose length is equal to >the N_r supplied by the GCKS. > >2. The GCKS returns a signature SIG on > >HDR, SEQ, KD' || N_r > >3. The member encrypts the message and the signature with the current >KEK (which it will know since it is a member of the group), to obtain > >HDR* SEQ, KD' || N_r, SIG > >and sends it out as a GROUPKEY-PUSH message. > >Note that the dishonest member has no control over the last part >of the fake KD, since this is supplied by the GCKS. However, it would >still be enough to mislead the other group members. > >The recommendations Brian had for changes to the document were to > >i. suggest that GCKS's use different signature keys and/or hash functions >when signing POP's than when signing GROUPKEY-PUSH messages. > >ii. put an upper bound on the size of N_i and N_r, so that N_i || N _r >would always be shorter than the shortest possible GROUPKEY-PUSH message. > >Mark Baugher also asked if having the GCKS sign N_r || N_i (insted of >N_r || N_r) when signing the POP >would prevent the attack. However, this would not work, because HDR, SEQ, KD >begins, as well as ends, in a random number: the 16-octet SPI. Thus >the dishonest member could mount the same attack by replacing part or >all of the SPI with N_r instead of part of the KD. > >It also occurred to me, after following the discussion on IPSEC, that it >would be possible to foil this attack by requiring POP signatures >to be on the two nonces followed by some short non-random field. Thus, >POP_I could be over (N_i || N_r || 0 ) and POP_R could be over >(N_i || N_r || 1), although we might want to use different integers >besides 0 and 1, since those are the ones currently being used by JFK. >If we don't want to put a limit on the nonce sizes for whatever reason, >this could be preferable. > >__________________________________ >ATTACK 2 > >I also found another attack, which is converse of the one I presented >above. It requires more assumptions than the first attack, so it is >less of a threat, but I include it because it does not require that much >more (if any) further change to the protocol to protect against it as well. > >Suppose that the following assumptions hold: > >A'. there is a group >member that is also a GCKS, and that uses the same key for signing >POPs as for signing GROUPKEY-PUSH messages. >B'. a pairwise member/GCKS key is compromised, so that a bad guy is able to >impersonate a GCKS to a member, although it does not know the GCKS's signature >key. >C'. the N_i generated by the group member/GCKS when it initiates >a GROUPKEY-PULL protocol is no larger than a SPI >D'. Even with the above restriction on the length of N_i, a group member >will accept an N_r such that the length of N_i || N_r is the same >as that of a possible GROUPKEY-PUSH message. > > >1. The group member, Alice, (who is also a GCKS) initiates a GROUPKEY-PULL >protocol >with the bad GCKS. The bad GCKS, Eve, sends a nonce N_r of >the form HDR', SEQ, KD where HDR is is the HDR minus an initial portion >equal in length to the N_i that would be generated by the group member/GCKS. > >2. Alice signs the POP N_i || N_r = >N_i || HDR', SEQ, KD > >3.Eve encrypts N_i || HDR', SEQ, KD, SIG with the current KEK, and >is able to pass off the message as a legitimately signed GROUPKEY-PUSH >message. Note that Eve also has total control over what the KD looks like. > >This attack is somewhat less likely than the other one, since it requires >that a principal act both as GCKS and member, and that it use the >same signing key for both roles, and that a pairwise key is compromised. >However, the same restriction on length that prevents the first attack >will also prevent this one. If we instead wanted to use the option >of including a non-random field in each message, we would have to >either include such a non-random field in the beginning as well as the >end of the message, or reverse the order of N_i and N_r in the POP >message signed by the group member. > >Hope that this helps, > >Cathy > > >_______________________________________________ >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 Dec 18 18:21:05 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29143 for ; Tue, 18 Dec 2001 18:21:05 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3D5515387F; Tue, 18 Dec 2001 18:14:58 -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 57CB5538D8 for ; Tue, 18 Dec 2001 14:09:59 -0500 (EST) Received: (qmail 88555 invoked by uid 3269); 18 Dec 2001 19:09:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88552 invoked from network); 18 Dec 2001 19:09:58 -0000 Received: from s2.itd.nrl.navy.mil (HELO itd.nrl.navy.mil) (132.250.83.3) by klesh.pair.com with SMTP; 18 Dec 2001 19:09:58 -0000 Received: from itd.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA21892; Tue, 18 Dec 2001 14:09:50 -0500 (EST) Received: from liverwurst.fw5540.net (liverwurst [10.0.3.31]) by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id OAA01853; Tue, 18 Dec 2001 14:09:10 -0500 (EST) From: "Catherine A. Meadows" Received: (from meadows@localhost) by liverwurst.fw5540.net (8.9.0/8.8.8) id OAA01633; Tue, 18 Dec 2001 14:09:09 -0500 (EST) Message-Id: <200112181909.OAA01633@liverwurst.fw5540.net> To: mbaugher@cisco.com Subject: Re: [MSEC] GDOI fix Cc: msec@securemulticast.org, meadows@itd.nrl.navy.mil X-Sun-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 list List-Unsubscribe: , List-Archive: Date: Tue, 18 Dec 2001 14:09:09 -0500 (EST) Mark: Thanks much for your comments and suggestions. Here are my responses: > First, the > KD does not necessarily end with an SPI but with key attributes, which > include a key and some metadata about the key. If this were always the > case, would this prevent ATTACK 1? If the KD always ended with the metadata instead of the key, this would prevent the attack, which requires that the signed part of the GROUPKEY-PUSH message end in random data. > I don't like having this restriction on > the KD payload since attributes are optional by definition. I agree. In order to keep the specification as modular as possible, we want to avoid putting any restrictions on what the KD payload looks like. > Second, what > do you think about placing the SEQ after the KD since a message having an > invalid SEQ would be rejected? I think that this would work against the first attack. Anything that would force the signed part of GROUPKEY-PUSH to end in recognizable instead of random data would prevent the first attack. It would not work against the second attack, unless we also had the group member sign I_r || I_i in the POP instead of I_i || I_r. So if we decide that we want to defend against both the first and second attacks by altering the position of the SEQ number, we should also have the group member sign I_r || I_i in the POP. > I don't think that Brian's solution of using different keys for signing > GROUPKEY-PULL (aka REGISTRATION) messages is a bad idea. > But I wonder if there is a more parsimonious solution. Brian and I agreed on that, which is why he made that a SHOULD instead of a MUST. There was also some concern that not all installations would have the ability to support two different keys. So he also included a restriction on the size of I_r and I_r which would guarantee that they would never be long enough so that I_r || I_i could be used to spoof a GROUPKEY-PUSH message. Cathy _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 19 14:50:27 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05545 for ; Wed, 19 Dec 2001 14:50:26 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2EEC753550; Wed, 19 Dec 2001 14:49:08 -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 98C115391F for ; Wed, 19 Dec 2001 14:47:17 -0500 (EST) Received: (qmail 34841 invoked by uid 3269); 19 Dec 2001 19:47:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34838 invoked from network); 19 Dec 2001 19:47:17 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 19 Dec 2001 19:47:17 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBJJkan34132; Wed, 19 Dec 2001 14:46:36 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBJJkan26504; Wed, 19 Dec 2001 14:46:36 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id OAA36210; Wed, 19 Dec 2001 14:46:36 -0500 From: Ran Canetti Message-Id: <200112191946.OAA36210@ornavella.watson.ibm.com> To: meadows@itd.nrl.navy.mil, msec@securemulticast.org Subject: Re: [MSEC] GDOI 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 list List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 14:46:36 -0500 Hi Cathy, Good catch! These are indeed potentially bad attacks. Fortunately, they are easy to thwart, as you noted in your mail: >It also occurred to me, after following the discussion on IPSEC, that it >would be possible to foil this attack by requiring POP signatures >to be on the two nonces followed by some short non-random field. Thus, >POP_I could be over (N_i || N_r || 0 ) and POP_R could be over >(N_i || N_r || 1), although we might want to use different integers >besides 0 and 1, since those are the ones currently being used by JFK. >If we don't want to put a limit on the nonce sizes for whatever reason, >this could be preferable. I agree - all that has to be done is when the GCKS signs a POP challenge, it should add to the signed text a reserved string that is interpreted as the message "this is a signature on a POP challenge". This way, the POP signatures will be worthless as GROUPKEY-PUSH signatures and the attacks will be thwarted. I'd suggest though that: -The special string will be prepended rahter than appended, to avoid potential decoding ambiguities. -The special string be a bit more distinctive, again to avoid mistakes. How about, say, the string "POP" in ascii. (A general lesson for us in protocol design: When using a signature in a protocol, make sure to add a special string that ties the signature to its particular use in the protocol.) (A first place to implement the above lesson: Add a similar string also to the POP signature by the group member.) Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 19 15:17:50 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06214 for ; Wed, 19 Dec 2001 15:17:49 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 30F6F539B9; Wed, 19 Dec 2001 15:17:04 -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 609E753550 for ; Wed, 19 Dec 2001 15:15:59 -0500 (EST) Received: (qmail 37951 invoked by uid 3269); 19 Dec 2001 20:15:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37948 invoked from network); 19 Dec 2001 20:15:58 -0000 Received: from s2.itd.nrl.navy.mil (HELO itd.nrl.navy.mil) (132.250.83.3) by klesh.pair.com with SMTP; 19 Dec 2001 20:15:58 -0000 Received: from itd.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA10893; Wed, 19 Dec 2001 15:15:52 -0500 (EST) Received: from liverwurst.fw5540.net (liverwurst [10.0.3.31]) by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id PAA20302; Wed, 19 Dec 2001 15:14:55 -0500 (EST) From: "Catherine A. Meadows" Received: (from meadows@localhost) by liverwurst.fw5540.net (8.9.0/8.8.8) id PAA02374; Wed, 19 Dec 2001 15:14:55 -0500 (EST) Message-Id: <200112192014.PAA02374@liverwurst.fw5540.net> To: msec@securemulticast.org, canetti@watson.ibm.com Subject: Re: [MSEC] GDOI fix Cc: meadows@itd.nrl.navy.mil X-Sun-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 list List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 15:14:55 -0500 (EST) Ran: Thanks! It wasn't my catch, though, but the NRL Protocol Analyzer's. I agree, prepending a special string to the POP challenge when it is signed by the GCKS or by the SPI would work, but only if a different special string (such as "push") was prepended to the GROUPKEY-PUSH message when it is signed by the GCKS. That is because the signed part of the GROUPKEY-PUSH message is HDR, SEQ, KD, and HDR begins in a random number, the SPI, which is supplied by the GCKS. So all a bad guy would have to do to get the GCKS to sign a forged GROUPKEY-PUSH message would be to send it an Ni of the form HDR, SEQ, KD', where HDR begins in a SPI of the form "pop" || random stuff. The group member who verifies the signature presumably is just going to accept that the SPI is random, without chcking that it begins with "pop". If we have the GCKS sign "push", HDR, SEQ, KD instead, that will prevent that. All in all, I think I like the idea of prepending special fields to all signed messages the best. It's easy for the verifier to check for, and if for some reason it's necessary to add new signed messages to GDOI, it's easy to prepend special strings to them too without having to worry about whether or not what you're doing breaks the defenses against this sort of attack that you'd already built into the protocol. Cathy _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 19 18:20:44 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10204 for ; Wed, 19 Dec 2001 18:20:44 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E3A7453A02; Wed, 19 Dec 2001 18:20:13 -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 0435E539CD for ; Wed, 19 Dec 2001 18:19:40 -0500 (EST) Received: (qmail 56114 invoked by uid 3269); 19 Dec 2001 23:19:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56111 invoked from network); 19 Dec 2001 23:19:39 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 19 Dec 2001 23:19:39 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBJNJ3n38210; Wed, 19 Dec 2001 18:19:03 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBJNJ3n28180; Wed, 19 Dec 2001 18:19:03 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id SAA22496; Wed, 19 Dec 2001 18:19:02 -0500 From: Ran Canetti Message-Id: <200112192319.SAA22496@ornavella.watson.ibm.com> To: canetti@watson.ibm.com, meadows@itd.nrl.navy.mil, msec@securemulticast.org Subject: Re: [MSEC] GDOI 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 list List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 18:19:02 -0500 I'm not sure I completely follow the attack below but in any case I very much agree with the conclusion - the GROUPKEY-PUSH signature text should have a leading identifier also. (This indeed is in agreement with the general "design principle".) Please congratualate your protocol analyzer, :) Ran > From meadows@itd.nrl.navy.mil Wed Dec 19 15:16:05 2001 > > Ran: > > Thanks! It wasn't my catch, though, but the NRL Protocol Analyzer's. > > I agree, prepending a special string to the POP challenge when it > is signed by the GCKS or by the SPI would work, but only if a different > special string (such as "push") was prepended to the GROUPKEY-PUSH > message when it is signed by the GCKS. That is because the > signed part of the GROUPKEY-PUSH message is HDR, SEQ, KD, > and HDR begins in a random number, the SPI, which is supplied > by the GCKS. So all a bad guy would have to do to get the GCKS > to sign a forged GROUPKEY-PUSH message would be to send it an Ni > of the form HDR, SEQ, KD', where HDR begins in a SPI of the > form "pop" || random stuff. The group member who verifies the signature > presumably is just going to accept that the SPI is random, without > chcking that it begins with "pop". If we have the GCKS sign > "push", HDR, SEQ, KD instead, that will prevent that. > > All in all, I think I like the idea of prepending special fields to all > signed messages the > best. It's easy for the verifier to check for, and if for some reason > it's necessary to add new signed messages to GDOI, it's easy to prepend > special strings to them too without having to worry about whether or not > what you're doing breaks the defenses against this sort of attack > that you'd already built into the protocol. > > Cathy > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 19 20:19:41 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11372 for ; Wed, 19 Dec 2001 20:19:40 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C3C8B53990; Wed, 19 Dec 2001 20:19:10 -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 E9193538C0 for ; Wed, 19 Dec 2001 20:17:49 -0500 (EST) Received: (qmail 95705 invoked by uid 3269); 20 Dec 2001 01:17:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95702 invoked from network); 20 Dec 2001 01:17:48 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 20 Dec 2001 01:17:48 -0000 Received: from cisco.com ([10.34.255.60]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with SMTP id fBK1H8s22010; Wed, 19 Dec 2001 17:17:08 -0800 (PST) Message-ID: <3C213C0C.2129038B@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: Ran Canetti Cc: meadows@itd.nrl.navy.mil, msec@securemulticast.org Subject: Re: [MSEC] GDOI fix References: <200112192319.SAA22496@ornavella.watson.ibm.com> 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 list List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 17:17:00 -0800 Content-Transfer-Encoding: 7bit Hi Ran & Cathy, Thanks for your analysis on finding ways to mitigate the attacks. We could either prepend or append a string to the POP data as you suggest. But prepending won't be possible for the GROUPKEY-PUSH message since the message must start with a HDR payload, and the HDR is a standard ISAKMP header. (That would be like adding a string before an IKE message HDR.) We could however append a specific value to the GROUPKEY-PUSH protocol, for example at the end of the KD payload. I assume that it makes no sense to prepend in one case and append in the other. So I propose implementing the earlier suggestion of appending a string to the data signed in the POP: (N_i || N_r || "pop") and adding the following key semantics to the KD payload: 1. Add a new KD payload type in section 5.5: o Key Download (KD) Type (1 octet) -- Identifier for the Key Data field of this Key Packet. Key Download Type Value ----------------- ----- RESERVED 0 TEK 1 KEK 2 LKH 3 OFT 4 REKEY_MARKER 5 <----- NEW RESERVED 6-127 Private Use 128-255 2. Text would be added requiring that the PUSH_MARKER must be the last key packet in the KD payload. 3. The REKEY_MARKER type has the following attributes: a. SPI Size must be 0. b. SPI must be 0 c. Key Packet Attributes must be "rekey". I don't really like encumbering the KD payload this way, but it does save the processing of a whole new payload type for the protocol. Does that sound sufficient? Thanks, Brian Ran Canetti wrote: > > I'm not sure I completely follow the attack below but in any case I very > much agree with the conclusion - the GROUPKEY-PUSH signature text should > have a leading identifier also. (This indeed is in agreement with the > general "design principle".) > > Please congratualate your protocol analyzer, :) > > Ran > > > From meadows@itd.nrl.navy.mil Wed Dec 19 15:16:05 2001 > > > > Ran: > > > > Thanks! It wasn't my catch, though, but the NRL Protocol Analyzer's. > > > > I agree, prepending a special string to the POP challenge when it > > is signed by the GCKS or by the SPI would work, but only if a different > > special string (such as "push") was prepended to the GROUPKEY-PUSH > > message when it is signed by the GCKS. That is because the > > signed part of the GROUPKEY-PUSH message is HDR, SEQ, KD, > > and HDR begins in a random number, the SPI, which is supplied > > by the GCKS. So all a bad guy would have to do to get the GCKS > > to sign a forged GROUPKEY-PUSH message would be to send it an Ni > > of the form HDR, SEQ, KD', where HDR begins in a SPI of the > > form "pop" || random stuff. The group member who verifies the signature > > presumably is just going to accept that the SPI is random, without > > chcking that it begins with "pop". If we have the GCKS sign > > "push", HDR, SEQ, KD instead, that will prevent that. > > > > All in all, I think I like the idea of prepending special fields to all > > signed messages the > > best. It's easy for the verifier to check for, and if for some reason > > it's necessary to add new signed messages to GDOI, it's easy to prepend > > special strings to them too without having to worry about whether or not > > what you're doing breaks the defenses against this sort of attack > > that you'd already built into the protocol. > > > > Cathy > > > > _______________________________________________ > 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 Wed Dec 19 20:41:07 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11573 for ; Wed, 19 Dec 2001 20:41:06 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EFFF853A93; Wed, 19 Dec 2001 20:40:27 -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 9A081538C0 for ; Wed, 19 Dec 2001 20:39:20 -0500 (EST) Received: (qmail 97197 invoked by uid 3269); 20 Dec 2001 01:39:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97194 invoked from network); 20 Dec 2001 01:39:20 -0000 Received: from s2.itd.nrl.navy.mil (HELO itd.nrl.navy.mil) (132.250.83.3) by klesh.pair.com with SMTP; 20 Dec 2001 01:39:20 -0000 Received: from itd.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA19864; Wed, 19 Dec 2001 20:38:52 -0500 (EST) Received: from liverwurst.fw5540.net (liverwurst [10.0.3.31]) by itd.nrl.navy.mil (8.9.0/8.9.0) with ESMTP id UAA24188; Wed, 19 Dec 2001 20:38:38 -0500 (EST) From: "Catherine A. Meadows" Received: (from meadows@localhost) by liverwurst.fw5540.net (8.9.0/8.8.8) id UAA02523; Wed, 19 Dec 2001 20:38:38 -0500 (EST) Message-Id: <200112200138.UAA02523@liverwurst.fw5540.net> To: canetti@watson.ibm.com, bew@cisco.com Subject: Re: [MSEC] GDOI fix Cc: meadows@itd.nrl.navy.mil, msec@securemulticast.org X-Sun-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 list List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 20:38:38 -0500 (EST) Brian: I think that either appending or prepending would work. However, Ran had some concerns about decoding ambiguities if it was appended. I'm not sure what his concerns were, so I will let him answer on that. It seems to me that if you append special strings to both groupkey push messages and POP's you would avoid this problem, but I would want to let him speak for himself. As to your solution, I think that it should work. The only possible drawback that I see is that if an optional CERT is included, and the CERT itself ends in random data (unlikely but possible, and out of our control) than the attack is still possible. I think that what we want to avoid here is the case where one of the signed messages begins in random data, and the other ends in random data. Once we do that, we can avoid both spoofing attacks. In my case, I wasn't suggesting prepending the "push" string to the message as it is sent, but prepending the "push" to what is signed by the GCKS. Thus the GROUPKEY-PUSH message would look like HDR* SEQ, KD, [CERT], SIG where SIG is the result of signing a hash of "push", HDR, SEQ, KD, [CERT] I'd originally had your concerns about changing the syntax of HDR, which is why I hadn't suggested prepending before, but if you just prepend to what is signed, without including the prepended string to the message as it is sent, it seems to me that you avoid this problem. What is everyone's thoughts on this? Cathy _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Dec 19 22:22:13 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13461 for ; Wed, 19 Dec 2001 22:22:12 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6E54F53AED; Wed, 19 Dec 2001 22:21:18 -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 5A64E53A75 for ; Wed, 19 Dec 2001 22:19:14 -0500 (EST) Received: (qmail 4345 invoked by uid 3269); 20 Dec 2001 03:19:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4342 invoked from network); 20 Dec 2001 03:19:13 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 20 Dec 2001 03:19:13 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBK3IZn10344; Wed, 19 Dec 2001 22:18:35 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id fBK3IZn26346; Wed, 19 Dec 2001 22:18:35 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id WAA28942; Wed, 19 Dec 2001 22:18:34 -0500 From: Ran Canetti Message-Id: <200112200318.WAA28942@ornavella.watson.ibm.com> To: bew@cisco.com, canetti@watson.ibm.com Subject: Re: [MSEC] GDOI fix Cc: meadows@itd.nrl.navy.mil, msec@securemulticast.org 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 list List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 22:18:34 -0500 Brian, Prpending is just an easy way to be certain that there are no decoding ambiguities: If the signed text contains variable-length fields and the encoding is stupid then an attacker may be able to play with the boundaries of fields to fool the signer. With prepending this is not possible. As Cathy said, the reserved strings need only be prepended to the signed text, not to the message itself. (BTW, this means that the bandwidth overhead is zero.) But if this is still a problem then sticking the reserved strings in a place with fixed offset from the beginning of the signed text is just as good. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Dec 20 12:24:30 2001 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13328 for ; Thu, 20 Dec 2001 12:24:29 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 71A8153940; Thu, 20 Dec 2001 12:24: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 4A43B53BDC for ; Thu, 20 Dec 2001 12:20:24 -0500 (EST) Received: (qmail 84099 invoked by uid 3269); 20 Dec 2001 17:20:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84096 invoked from network); 20 Dec 2001 17:20:23 -0000 Received: from sj-msg-core-2.cisco.com (171.69.24.11) by klesh.pair.com with SMTP; 20 Dec 2001 17:20:23 -0000 Received: from cisco.com ([10.34.255.60]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with SMTP id fBKHJfs08284; Thu, 20 Dec 2001 09:19:42 -0800 (PST) Message-ID: <3C221D9F.B3454B59@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: Ran Canetti Cc: meadows@itd.nrl.navy.mil, msec@securemulticast.org Subject: Re: [MSEC] GDOI fix References: <200112200318.WAA28942@ornavella.watson.ibm.com> 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 list List-Unsubscribe: , List-Archive: Date: Thu, 20 Dec 2001 09:19:27 -0800 Content-Transfer-Encoding: 7bit Thanks Ran and Cathy for both your replies. I had also thought of the logical prepending of the string, but initially disliked it due to the complexity added to preparing the data for the signing process. However, I think it might be less messy overall than the KD payload append trick I mentioned earlier. I'll take a look at the GDOI implementations to see how much of a problem it really is. Ran, thanks for the alternate idea of using a fixed offset too. Brian Ran Canetti wrote: > > Brian, > > Prpending is just an easy way to be certain that there are no > decoding ambiguities: If the signed text contains variable-length fields > and the encoding is stupid then an attacker may be able to play with the > boundaries of fields to fool the signer. With prepending this is not possible. > > As Cathy said, the reserved strings need only be prepended to the signed > text, not to the message itself. (BTW, this means that the bandwidth > overhead is zero.) But if this is still a problem then > sticking the reserved strings in a place with fixed offset from the > beginning of the signed text is just as good. > > Ran > > _______________________________________________ > 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