From msec-admin@securemulticast.org Thu Aug 1 10:45:52 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02525 for ; Thu, 1 Aug 2002 10:45:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7F107535ED; Thu, 1 Aug 2002 10:43:52 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0D442535AB for ; Thu, 1 Aug 2002 10:43:00 -0400 (EDT) Received: (qmail 70141 invoked by uid 3269); 1 Aug 2002 14:45:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70138 invoked from network); 1 Aug 2002 14:45:27 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 1 Aug 2002 14:45:27 -0000 Received: from charlie.columbia.sparta.com (charlie.columbia.sparta.com [157.185.80.121]) by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g71EjGs9015492 for ; Thu, 1 Aug 2002 09:45:26 -0500 Received: (from umeth@localhost) by charlie.columbia.sparta.com (8.11.6/8.11.6) id g71Ej7O28141 for msec@securemulticast.org; Thu, 1 Aug 2002 10:45:07 -0400 From: Uri Meth To: msec@securemulticast.org Message-ID: <20020801104507.B28059@charlie.columbia.sparta.com> Reply-To: umeth@sparta.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organization: SPARTA Inc. (Secure Systems Engineering Division) USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x233 Fax: (410) 381-5559 Subject: [MSEC] release of doc draft-ietf-msec-gsakmp-light-sec-01.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, 1 Aug 2002 10:45:07 -0400 draft-ietf-msec-gsakmp-light-sec-01.txt Document expiration: December 31, 2002 Abstract A protocol specification must balance two often conflicting goals: to produce as general a protocol as possible, and to produce a simple protocol. The Group Secure Association Key Management Protocol (GSAKMP) is a general protocol for creating and managing cryptographic groups on a network. This document describes the GSAKMP-Light (GL) profile, a way to shorten the number of messages exchanged during secure group establishment. The GSAKMP protocol assumed that group members joining a secure group had no information about the specific security mechanisms used by the group (for example, the key length, encryption protocol, etc). GSAKMP-Light provides a profile for the case where group members This is a rerelease of the original GSAKMP-Light specification to keep it current, the original document had expired. UM -- Uri Meth (410) 381 - 9400 x233 (voice) SPARTA, Inc. (410) 381 - 5559 (fax) 9861 Broken Land Parkway, Suite 300 umeth@sparta.com Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 7 16:31:03 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07537 for ; Wed, 7 Aug 2002 16:31:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 84DDA535F9; Wed, 7 Aug 2002 16:29:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7786A5362A for ; Wed, 7 Aug 2002 16:28:05 -0400 (EDT) Received: (qmail 53907 invoked by uid 3269); 7 Aug 2002 20:30:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53900 invoked from network); 7 Aug 2002 20:30:48 -0000 Received: from pigeon.verisign.com (65.205.251.71) by klesh.pair.com with SMTP; 7 Aug 2002 20:30:48 -0000 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g77KOteD024965 for ; Wed, 7 Aug 2002 13:25:23 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.35.42.233 [10.35.42.233]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PZCFVC9F; Wed, 7 Aug 2002 13:32:06 -0700 Message-Id: <5.0.0.25.2.20020807163144.01920cf0@pop.mail.yahoo.com> X-Sender: thardjono@10.25.1.45 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] test - ignore 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: Wed, 07 Aug 2002 16:31:59 -0400 test - ignore _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 7 16:52:59 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08238 for ; Wed, 7 Aug 2002 16:52:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9FAB5535C7; Wed, 7 Aug 2002 16:50:57 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7BACF5367E for ; Wed, 7 Aug 2002 16:41:05 -0400 (EDT) Received: (qmail 55774 invoked by uid 3269); 7 Aug 2002 20:43:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55771 invoked from network); 7 Aug 2002 20:43:47 -0000 Received: from pigeon.verisign.com (65.205.251.71) by klesh.pair.com with SMTP; 7 Aug 2002 20:43:47 -0000 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g77KcIeD026681; Wed, 7 Aug 2002 13:38:18 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.35.42.233 [10.35.42.233]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PZCFVDW5; Wed, 7 Aug 2002 13:45:28 -0700 Message-Id: <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> X-Sender: thardjono@10.25.1.45 X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: hh@columbia.sparta.com, jis@mit.edu, smb@research.att.com, canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] GSAKMP to Informational RFC (resend) 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: Wed, 07 Aug 2002 16:45:22 -0400 (Resend: I posted this yesterday, but it never showed-up on the list.) Folks, After some discussion with the authors of GSAKMP, we have decided to direct the GSAKMP draft to Informational RFC status. The original GSAKMP document was one of the earliest submissions to SMuG, and was submitted also to MSEC. The MSEC version on the IETF site has expired but the same document can be found here: http://www.securemulticast.org/draft-irtf-smug-gsakmp-02.txt If anyone has any comments/issues/complaints regarding moving the original GSAKMP document to Informational RFC, please send them to this mailing list within the next couple of weeks. Regards, Ran/Thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 8 11:10:00 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15326 for ; Thu, 8 Aug 2002 11:09:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 29D7E53713; Thu, 8 Aug 2002 11:07:58 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 255D453713 for ; Thu, 8 Aug 2002 11:02:41 -0400 (EDT) Received: (qmail 82959 invoked by uid 3269); 8 Aug 2002 15:05:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 82956 invoked from network); 8 Aug 2002 15:05:23 -0000 Received: from igw3.watson.ibm.com (198.81.209.18) by klesh.pair.com with SMTP; 8 Aug 2002 15:05:23 -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 g78F2DF06266; Thu, 8 Aug 2002 11:02:13 -0400 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 g78F2DH28162; Thu, 8 Aug 2002 11:02:13 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id LAA28746; Thu, 8 Aug 2002 11:02:11 -0400 From: Ran Canetti Message-Id: <200208081502.LAA28746@ornavella.watson.ibm.com> To: authtime@nist.gov, ietf-ipsra@vpnc.org, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-openpgp@imc.org, ietf-otp@research.telcordia.com, ietf-pkix@imc.org, ietf-sacred@imc.org, ietf-smime@imc.org, ietf-ssh@netbsd.org, ietf-tls@lists.certicom.com, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com, msec@securemulticast.org, saag@mit.edu, w3c-ietf-xmldsig@w3.org Cc: canetti@ornavella.watson.ibm.com, mcgrew@cisco.com Subject: [MSEC] A new crypto forum at the IRTF 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, 8 Aug 2002 11:02:11 -0400 Folks, this note is to announce the formation of a new IRTF Research Group, called "Crypto Forum Research Group" (CFRG). The group is intended to answer the need for a single forum where cryptographers, network security experts, and protocol designers can exchange ideas and investigate the use of cryptographic techniques for network protocols in general and for the IETF in particular. CFRG is of course NOT intended as a replacement for the work done at the IETF Working Groups in standardizing actual protocols. Rather, it the group provides a forum where general techniques and tools can be developed and scrutinized to the benefit of multiple Working Groups. Apart from disseminating the understanding of cryptographic techniques within the IETF, the outputs of CFRG are expected to come in the form of informational RFCs (in the tradition of, e.g., RFCs 1321 [MD5] and 2104 [HMAC]). You are cordially invited to join the mailing list and bring forth the cryptographic question that deprived you of sleep lately. The list is open. To reduce spam, the chairs will moderate mails from non-members. For Charter, more information, and subscription instructions, see http://www.irtf.org/cfrg. Best, David Mcgrew and Ran Canetti, CFRG co-chairs. PS. We'd like to thank Mark Baugher for his great help in setting up the new research group. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 12 17:49:19 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12840 for ; Mon, 12 Aug 2002 17:49:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8ACDC53636; Mon, 12 Aug 2002 17:47:07 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4A83453532 for ; Mon, 12 Aug 2002 17:46:35 -0400 (EDT) Received: (qmail 50774 invoked by uid 3269); 12 Aug 2002 21:49:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50768 invoked from network); 12 Aug 2002 21:49:31 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.54) by klesh.pair.com with SMTP; 12 Aug 2002 21:49:31 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7CLn06I003901; Mon, 12 Aug 2002 14:49:00 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ACH16286; Mon, 12 Aug 2002 14:46:05 -0700 (PDT) Message-Id: <4.3.2.7.2.20020812144402.04ba2678@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Thomas Hardjono From: Mark Baugher Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) Cc: msec@securemulticast.org In-Reply-To: <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 12 Aug 2002 14:46:32 -0700 Thomas, I don't see the point of taking GSAKMP to Informational RFC while taking GSAKMP-lite to standards track. I'd chose one or the other. Mark At 04:45 PM 8/7/2002 -0400, Thomas Hardjono wrote: >(Resend: I posted this yesterday, but it never showed-up on the list.) > >Folks, > >After some discussion with the authors of GSAKMP, we have decided >to direct the GSAKMP draft to Informational RFC status. > >The original GSAKMP document was one of the earliest submissions to SMuG, >and was submitted also to MSEC. The MSEC version on the IETF site has expired >but the same document can be found here: >http://www.securemulticast.org/draft-irtf-smug-gsakmp-02.txt > >If anyone has any comments/issues/complaints regarding moving >the original GSAKMP document to Informational RFC, please send them to >this mailing list within the next couple of weeks. > >Regards, > >Ran/Thomas > > >_______________________________________________ >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 Aug 13 09:01:37 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10521 for ; Tue, 13 Aug 2002 09:01:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E94A05383A; Tue, 13 Aug 2002 08:59:26 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 7EC76536DA for ; Tue, 13 Aug 2002 08:58:42 -0400 (EDT) Received: (qmail 49449 invoked by uid 3269); 13 Aug 2002 13:01:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49446 invoked from network); 13 Aug 2002 13:01:40 -0000 Received: from smtp012.mail.yahoo.com (216.136.173.32) by klesh.pair.com with SMTP; 13 Aug 2002 13:01:40 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Aug 2002 13:01:39 -0000 Message-Id: <5.0.0.25.2.20020813085337.02517da0@10.25.1.45> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Mark Baugher From: Thomas Hardjono Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) Cc: msec@securemulticast.org, hh@sparta.com In-Reply-To: <4.3.2.7.2.20020812144402.04ba2678@mira-sjc5-6.cisco.com> References: <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 13 Aug 2002 09:03:25 -0400 Mark, Perhaps my earlier email needs some clarification. We are talking about two documents: GSAKMP-Light and the original GSAKMP (ie. what I call "GSAKMP-Original", which is the version proposed since the SMuG days). The plan is indeed to advance GSAKMP-Light to Standards Track. Thus, the question pertains instead to GSAKMP-Original. I think for anyone reading the GSAKMP-Light documents, it would be useful to provide them with background information (ie. the original GSAKMP documents). Thus, there is some benefit in keeping around the GSAKMP-Original documents, rather than seeing them expire and disappear. Hence my suggestion that GSAKMP-Original be put into Informational while advancing GSAKMP-Light to Standards Track. thomas ------ At 8/12/2002||02:46 PM, Mark Baugher wrote: >Thomas, > I don't see the point of taking GSAKMP to Informational RFC while > taking GSAKMP-lite to standards track. I'd chose one or the other. > >Mark >At 04:45 PM 8/7/2002 -0400, Thomas Hardjono wrote: > >>(Resend: I posted this yesterday, but it never showed-up on the list.) >> >>Folks, >> >>After some discussion with the authors of GSAKMP, we have decided >>to direct the GSAKMP draft to Informational RFC status. >> >>The original GSAKMP document was one of the earliest submissions to SMuG, >>and was submitted also to MSEC. The MSEC version on the IETF site has >>expired >>but the same document can be found here: >>http://www.securemulticast.org/draft-irtf-smug-gsakmp-02.txt >> >>If anyone has any comments/issues/complaints regarding moving >>the original GSAKMP document to Informational RFC, please send them to >>this mailing list within the next couple of weeks. >> >>Regards, >> >>Ran/Thomas >> >> >>_______________________________________________ >>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 Wed Aug 14 11:48:12 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14167 for ; Wed, 14 Aug 2002 11:48:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7382C5358A; Wed, 14 Aug 2002 11:45:40 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DFB015357F for ; Wed, 14 Aug 2002 11:45:00 -0400 (EDT) Received: (qmail 47639 invoked by uid 3269); 14 Aug 2002 15:48:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47630 invoked from network); 14 Aug 2002 15:47:57 -0000 Received: from prue.eim.surrey.ac.uk (exim@131.227.76.5) by klesh.pair.com with SMTP; 14 Aug 2002 15:47:57 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 17f0N5-0004PG-00; Wed, 14 Aug 2002 16:47:43 +0100 Message-ID: <3D5A7B96.67EC4CAE@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Hardjono Cc: msec@securemulticast.org, hh@sparta.com Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) References: <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> <5.0.0.25.2.20020813085337.02517da0@10.25.1.45> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-99.6 required=7.0 tests=DEAR_SOMEBODY,DOUBLE_CAPSWORD,USER_IN_WHITELIST version=2.31 X-Scanner: exiscan *17f0N5-0004PG-00*ZLWDqfuXaqs* (SECM, UniS) 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: Wed, 14 Aug 2002 16:47:34 +0100 Content-Transfer-Encoding: 7bit Dear Thomas and Hugh, I think Thomas's idea is good to keep both GSAKMP and GSAKMP-Lite documentation. This is important for us (University of Surrey, UK) where we are planning to implement GSAKMP-Lite. Since there is a plan to progress toward RFCs, then I think there are two issues should be addressed in the GSAKMP-Lite (and/or GSAKMP) drafts: * DoS attacks (especially on the GSAKM-Lite Server) are not addressed in the draft. The people who follow the ipsec mailing list know that IKEv2 is in a very good shape, and in combinations with some features of JFK, could be adopted as the SOI. I just wanted to draw attention to the use of stateless cookies in phase1 of IKEv2 messages, if the Responder feels it is under DoS attack. Can the authors of GSAKM-Lite document address this issue and possibly adopt the IKEv2 techniques (possible software reuse). This means that normal Light Group Establishment messages are 3 and if DoS is detected then 5 messages will be exchanged. * The second issue is interworking with ipsec and passing the GSAKM-Lite keys to the ipsec engine: I appreciate that GSAKM architecture is application level and independent of ipsec, however I think that many multicast applications with GSAKM-Lite want to use ipsec for subsequent multicast security services (privacy, integrity, etc.). Is it possible for the GSAKM-Lite authors to include some guidelines for interworking with ipsec (general or more specific such as how to populate the SPD and SAD in ipsec engine with GSAKM-Lite keys, etc.) Haitham Thomas Hardjono wrote: > Mark, > > Perhaps my earlier email needs some clarification. We are talking about > two documents: GSAKMP-Light and the original GSAKMP (ie. what I call > "GSAKMP-Original", which is the version proposed since the SMuG days). > > The plan is indeed to advance GSAKMP-Light to Standards Track. Thus, the > question pertains instead to GSAKMP-Original. > > I think for anyone reading the GSAKMP-Light documents, it would be > useful to provide them with background information (ie. the original > GSAKMP documents). Thus, there is some benefit in keeping around > the GSAKMP-Original documents, rather than seeing them expire and disappear. > > Hence my suggestion that GSAKMP-Original be put into Informational while > advancing GSAKMP-Light to Standards Track. > > thomas > ------ > > At 8/12/2002||02:46 PM, Mark Baugher wrote: > >Thomas, > > I don't see the point of taking GSAKMP to Informational RFC while > > taking GSAKMP-lite to standards track. I'd chose one or the other. > > > >Mark > >At 04:45 PM 8/7/2002 -0400, Thomas Hardjono wrote: > > > >>(Resend: I posted this yesterday, but it never showed-up on the list.) > >> > >>Folks, > >> > >>After some discussion with the authors of GSAKMP, we have decided > >>to direct the GSAKMP draft to Informational RFC status. > >> > >>The original GSAKMP document was one of the earliest submissions to SMuG, > >>and was submitted also to MSEC. The MSEC version on the IETF site has > >>expired > >>but the same document can be found here: > >>http://www.securemulticast.org/draft-irtf-smug-gsakmp-02.txt > >> > >>If anyone has any comments/issues/complaints regarding moving > >>the original GSAKMP document to Informational RFC, please send them to > >>this mailing list within the next couple of weeks. > >> > >>Regards, > >> > >>Ran/Thomas > >> > >> > >>_______________________________________________ > >>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 -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 14 13:00:37 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17120 for ; Wed, 14 Aug 2002 13:00:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5683853723; Wed, 14 Aug 2002 12:58:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 6A912535B5 for ; Wed, 14 Aug 2002 12:57:37 -0400 (EDT) Received: (qmail 57911 invoked by uid 3269); 14 Aug 2002 17:00:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57908 invoked from network); 14 Aug 2002 17:00:37 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 14 Aug 2002 17:00:37 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7EGxW0Y003660; Wed, 14 Aug 2002 09:59:32 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ACH54706; Wed, 14 Aug 2002 09:56:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20020814093909.07bbd350@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Haitham Cruickshank From: Mark Baugher Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) Cc: msec@securemulticast.org In-Reply-To: <3D5A7B96.67EC4CAE@eim.surrey.ac.uk> References: <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> <5.0.0.25.2.20020813085337.02517da0@10.25.1.45> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 14 Aug 2002 09:57:02 -0700 Haitham, At 04:47 PM 8/14/2002 +0100, Haitham Cruickshank wrote: >Dear Thomas and Hugh, > >I think Thomas's idea is good to keep both GSAKMP and GSAKMP-Lite >documentation. This is important for us (University of Surrey, UK) where >we are >planning to implement GSAKMP-Lite. If there's something in GSAKMP that you need for GSAKMP-lite, I would expect that to be in GSAKMP-lite. I'd like to know if/why the GSAKMP authors think that an Informational RFC is the best way to document work that has been eclipsed by GSAKMP-lite even before GSAKMP is published. This is not a big issue apart from the fact that people often expect that it's worthwhile to implement protocols and algorithms that are Informational RFCs. There is no "obsoleted by" clause for Informational RFCs, is there? So, this strikes me as potentially confusing to the industry. Another issue is that we may need to assure the RFC editor that we are not treating the Informational RFC process as a vanity press. So, what's in GSAKMP but not in GSAKMP-lite that needs to be document by an Informational RFC as opposed to other means? Mark >Since there is a plan to progress toward RFCs, then I think there are two >issues should be addressed in the GSAKMP-Lite (and/or GSAKMP) drafts: > >* DoS attacks (especially on the GSAKM-Lite Server) are not addressed in the >draft. The people who follow the ipsec mailing list know that IKEv2 is in a >very good shape, and in combinations with some features of JFK, could be >adopted >as the SOI. I just wanted to draw attention to the use of stateless >cookies in >phase1 of IKEv2 messages, if the Responder feels it is under DoS attack. Can >the authors of GSAKM-Lite document address this issue and possibly adopt the >IKEv2 techniques (possible software reuse). This means that normal Light >Group >Establishment messages are 3 and if DoS is detected then 5 messages will be >exchanged. > >* The second issue is interworking with ipsec and passing the GSAKM-Lite >keys to >the ipsec engine: I appreciate that GSAKM architecture is application >level and >independent of ipsec, however I think that many multicast applications with >GSAKM-Lite want to use ipsec for subsequent multicast security services >(privacy, integrity, etc.). Is it possible for the GSAKM-Lite authors to >include some guidelines for interworking with ipsec (general or more specific >such as how to populate the SPD and SAD in ipsec engine with GSAKM-Lite keys, >etc.) > >Haitham > >Thomas Hardjono wrote: > > > Mark, > > > > Perhaps my earlier email needs some clarification. We are talking about > > two documents: GSAKMP-Light and the original GSAKMP (ie. what I call > > "GSAKMP-Original", which is the version proposed since the SMuG days). > > > > The plan is indeed to advance GSAKMP-Light to Standards Track. Thus, the > > question pertains instead to GSAKMP-Original. > > > > I think for anyone reading the GSAKMP-Light documents, it would be > > useful to provide them with background information (ie. the original > > GSAKMP documents). Thus, there is some benefit in keeping around > > the GSAKMP-Original documents, rather than seeing them expire and > disappear. > > > > Hence my suggestion that GSAKMP-Original be put into Informational while > > advancing GSAKMP-Light to Standards Track. > > > > thomas > > ------ > > > > At 8/12/2002||02:46 PM, Mark Baugher wrote: > > >Thomas, > > > I don't see the point of taking GSAKMP to Informational RFC while > > > taking GSAKMP-lite to standards track. I'd chose one or the other. > > > > > >Mark > > >At 04:45 PM 8/7/2002 -0400, Thomas Hardjono wrote: > > > > > >>(Resend: I posted this yesterday, but it never showed-up on the list.) > > >> > > >>Folks, > > >> > > >>After some discussion with the authors of GSAKMP, we have decided > > >>to direct the GSAKMP draft to Informational RFC status. > > >> > > >>The original GSAKMP document was one of the earliest submissions to SMuG, > > >>and was submitted also to MSEC. The MSEC version on the IETF site has > > >>expired > > >>but the same document can be found here: > > >>http://www.securemulticast.org/draft-irtf-smug-gsakmp-02.txt > > >> > > >>If anyone has any comments/issues/complaints regarding moving > > >>the original GSAKMP document to Informational RFC, please send them to > > >>this mailing list within the next couple of weeks. > > >> > > >>Regards, > > >> > > >>Ran/Thomas > > >> > > >> > > >>_______________________________________________ > > >>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 > >-- >Dr. Haitham S. Cruickshank > >Senior Research Fellow in Communications >Centre for Communication Systems Research (CCSR) >School of Electronics, Computing and Mathematics >University of Surrey >Guildford, Surrey GU2 7XH, UK > >Tel: +44 1483 686007 (indirect 689844) >Fax: +44 1483 686011 >e-mail: H.Cruickshank@surrey.ac.uk >http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > >_______________________________________________ >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 Wed Aug 14 17:50:04 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25822 for ; Wed, 14 Aug 2002 17:50:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CE4B8537BE; Wed, 14 Aug 2002 17:47:43 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id E034953850 for ; Wed, 14 Aug 2002 17:46:51 -0400 (EDT) Received: (qmail 4733 invoked by uid 3269); 14 Aug 2002 21:49:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4730 invoked from network); 14 Aug 2002 21:49:52 -0000 Received: from cs.gmu.edu (129.174.87.2) by klesh.pair.com with SMTP; 14 Aug 2002 21:49:52 -0000 Received: from tigger (tigger [129.174.87.170]) by cs.gmu.edu (8.12.2+Sun/8.12.2) with SMTP id g7ELnpmI022255; Wed, 14 Aug 2002 17:49:51 -0400 (EDT) Reply-To: From: "Sanjeev Setia" To: , Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [MSEC] paper on reliable rekey transport protocols 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: Wed, 14 Aug 2002 17:49:51 -0400 Content-Transfer-Encoding: 7bit Hi, We have recently authored a paper on the performance of reliable group rekey transport protocols. The abstract and URL are given below. Comments and feedback would be much appreciated. Cheers, Sanjeev Setia ----------------------------------------------------------- Title: A Comparative Performance Analysis of Reliable Group Rekey Transport Protocols for Secure Multicast. URL: http://www.ise.gmu.edu/techrep/2002/02_05.pdf Abstract: We present a new scalable and reliable key distribution protocol for group key management schemes that use logical key hierarchies for scalable group rekeying. Our protocol, called WKA-BKR, is based upon two ideas, weighted key assignment and batched key retransmission, both of which exploitthe special properties of logical key hierarchies and the group rekey transport payload to reduce the bandwidth overhead of the reliable key delivery protocol. We have compared the performance of WKA-BKR with that of other rekey transport protocols, including a recently proposed protocol based on proactive FEC. Our results show that for most network loss scenarios, the bandwidth used by WKA-BKR is lower than that of the other protocols examined. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Aug 15 19:04:51 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19446 for ; Thu, 15 Aug 2002 19:04:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9FF905388D; Thu, 15 Aug 2002 19:02:18 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 397635365B for ; Thu, 15 Aug 2002 19:01:56 -0400 (EDT) Received: (qmail 83171 invoked by uid 3269); 15 Aug 2002 23:04:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83165 invoked from network); 15 Aug 2002 23:04:59 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 15 Aug 2002 23:04:59 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7FN4K0Y013848; Thu, 15 Aug 2002 16:04:22 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (stealth-10-34-251-94.cisco.com [10.34.251.94]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ACH89334; Thu, 15 Aug 2002 16:01:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20020815144144.04a899c0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: jari.arkko@ericsson.com, Elisabetta.Carrara@era.ericsson.se, Fredrik Lindholm , Mats =?iso-8859-1?Q?N=E4slund?= , Karl Norrman From: Mark Baugher Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MIKEY key generation 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 Aug 2002 16:01:49 -0700 hi I gave http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-03.txt a first read. I think it is a pretty complete specification. I have a few comments and questions and plan to post a few notes this week and the week after next (when I return from vacation). I have questions about sections 4.1 and 4.1.4. SRTP does not need the TEK-from-TGK generation method, does it? MIKEY does not define any other security protocols beside SRTP. So the key generation method won't be used until you define some other security protocol that needs it. True? Regarding section 4.1.5, both public-key and pre-shared messages convey TGKs. I don't understand the point of these derivations. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Aug 17 11:41:20 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28743 for ; Sat, 17 Aug 2002 11:41:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 54924535AF; Sat, 17 Aug 2002 11:39:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 632CC535E2 for ; Sat, 17 Aug 2002 11:38:03 -0400 (EDT) Received: (qmail 55276 invoked by uid 3269); 17 Aug 2002 15:41:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55273 invoked from network); 17 Aug 2002 15:41:07 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.49) by klesh.pair.com with SMTP; 17 Aug 2002 15:41:07 -0000 Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7HFearU022076; Sat, 17 Aug 2002 17:40:46 +0200 (MEST) Received: from e00d05937ed1e (permit151.er.ki.sw.ericsson.se [147.214.97.151]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id PN0M09J4; Sat, 17 Aug 2002 17:40:31 +0200 Message-ID: <002001c24604$644d5b80$0300a8c0@e00d05937ed1e.telia.com> X-Sybari-Trust: 39b3dad4 9c5d1ec5 22781ed6 00000138 From: "Fredrik Lindholm" To: "Mark Baugher" Cc: , , , "=?iso-8859-1?Q?Mats_N=E4slund?=" , "Karl Norrman" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [MSEC] Re: MIKEY key generation 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 Aug 2002 17:40:19 +0200 Content-Transfer-Encoding: 7bit Hi Mark, see comments inline. >hi > I gave >http://search.ietf.org/internet-drafts/draft-ietf-msec-mikey-03.txt a first >read. I think it is a pretty complete specification. I have a few >comments and questions and plan to post a few notes this week and the week >after next (when I return from vacation). > > I have questions about sections 4.1 and 4.1.4. SRTP does not need the >TEK-from-TGK generation method, does it? MIKEY does not define any other >security protocols beside SRTP. So the key generation method won't be used >until you define some other security protocol that needs it. True? I agree that SRTP might not need the TGK to TEK derivation in some scenarios. However, we address scenarios where both parties will be sending media. As stated in SRTP Section 9.1. (http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-05.txt) "It is RECOMMENDED that RTP senders on different hosts not use the same master key to send.". One of our main applications is conversational multimedia, where we can expect the RTP senders to be on different hosts. For this and similar scenarios, I believe the TGK to TEK derivation is useful. > > Regarding section 4.1.5, both public-key and pre-shared messages convey >TGKs. I don't understand the point of these derivations. To encrypt and message authenticate the TGKs, one encryption and one message authentication key are needed. This derivation specify how to do this from one single pre-shared key (and analogous for an envelop key), so that the output keys will be "independent" (and fresh from previous CSB in the case of the pre-shared key). Thanks (and have a nice vacation), Fredrik _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 19 10:41:43 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03535 for ; Mon, 19 Aug 2002 10:41:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1C902535C7; Mon, 19 Aug 2002 10:39:03 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 360F0535B3 for ; Mon, 19 Aug 2002 10:38:06 -0400 (EDT) Received: (qmail 24952 invoked by uid 3269); 19 Aug 2002 14:41:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24948 invoked from network); 19 Aug 2002 14:41:19 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 19 Aug 2002 14:41:19 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g7JEeqs9023256; Mon, 19 Aug 2002 09:41:12 -0500 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA15050; Mon, 19 Aug 2002 10:40:36 -0400 (EDT) Message-Id: <4.2.2.20020819100503.01c20af0@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Mark Baugher , Haitham Cruickshank From: Hugh Harney Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) Cc: msec@securemulticast.org In-Reply-To: <4.3.2.7.2.20020814093909.07bbd350@mira-sjc5-6.cisco.com> References: <3D5A7B96.67EC4CAE@eim.surrey.ac.uk> <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> <5.0.0.25.2.20020813085337.02517da0@10.25.1.45> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 19 Aug 2002 10:36:10 -0400 Mark, I suggested that GSAKMP heavy be moved to informational status because it is a viable protocol for multicast keying. It documents how one could use a pairwise SA to protect a key exchange. While you are correct that GSAKMP Lite will need to contain everything necessary to implement it. I thought it may be helpful to the community to document the group keying under an SA approach. I'm very willing to include all the relevant pieces of GSAKMP heavy into the GSAKMP-Lite document. So that means the GSAKMP-Lite document will continue to be a living document. However, GSAKMP-heavy contains some ideas and mechanisms that Lite will not contain. It wasn't my intention to use any process as a vanity press. It was my intention to provide documentation of an alternative method for group key management. Also, GSAKMP (heavy) has helped several people design key and security management protocols (judging from the number of e-mails I've received). It certainly contributed to the creation of (GSAKMP-Lite and GDOI). My thinking was that this document should be available as a reference. I thought that it would best be documented as an Informational RFC. Would it be better to continue to submit GSAKMP-heavy and GSAKMP-Lite as Internt Dafts? Hugh ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Aug 19 10:59:19 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04224 for ; Mon, 19 Aug 2002 10:59:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8CFA0535DB; Mon, 19 Aug 2002 10:55:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1F855535C0 for ; Mon, 19 Aug 2002 10:54:10 -0400 (EDT) Received: (qmail 26984 invoked by uid 3269); 19 Aug 2002 14:57:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26981 invoked from network); 19 Aug 2002 14:57:23 -0000 Received: from m5.sparta.com (root@157.185.61.1) by klesh.pair.com with SMTP; 19 Aug 2002 14:57:23 -0000 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by M5.sparta.com (8.12.3/8.12.3) with ESMTP id g7JEvCs9023848; Mon, 19 Aug 2002 09:57:12 -0500 Received: from robin (robin.columbia.sparta.com [157.185.80.228]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA15342; Mon, 19 Aug 2002 10:57:08 -0400 (EDT) Message-Id: <4.2.2.20020819104123.013ef860@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Haitham Cruickshank From: Hugh Harney Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) Cc: msec@securemulticast.org In-Reply-To: <3D5A7B96.67EC4CAE@eim.surrey.ac.uk> References: <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> <5.0.0.25.2.20020813085337.02517da0@10.25.1.45> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_-1952780214==_.ALT" 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 Aug 2002 10:52:42 -0400 --=====================_-1952780214==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Haitham, >* DoS attacks (especially on the GSAKM-Lite Server) are not addressed in the >draft. The people who follow the ipsec mailing list know that IKEv2 is in a >very good shape, and in combinations with some features of JFK, could be >adopted >as the SOI. I just wanted to draw attention to the use of stateless >cookies in >phase1 of IKEv2 messages, if the Responder feels it is under DoS attack. Can >the authors of GSAKM-Lite document address this issue and possibly adopt the >IKEv2 techniques (possible software reuse). This means that normal Light >Group >Establishment messages are 3 and if DoS is detected then 5 messages will be >exchanged. I understand your reasoning for wanting stateless cookies. I try to use good protocol design techniques, and steal any good ideas I find, so I'll add this to the next revision of GSAKMP-Lite. >* The second issue is interworking with ipsec and passing the GSAKM-Lite >keys to >the ipsec engine: I appreciate that GSAKM architecture is application >level and >independent of ipsec, however I think that many multicast applications with >GSAKM-Lite want to use ipsec for subsequent multicast security services >(privacy, integrity, etc.). Is it possible for the GSAKM-Lite authors to >include some guidelines for interworking with ipsec (general or more specific >such as how to populate the SPD and SAD in ipsec engine with GSAKM-Lite keys, >etc.) I think that the IPSec SPD and SAD would benefit from a standard API. I don't think one is in the works. The closest I've seen is documented in an Informational RFC 2367 (PF_KEY Key Management API, Version 2). I think there is some code available that implements this API, with modification it should suit our purposes. At least using the approach outlined in this Informational RFC, we will not have to reinvent the wheel. Hugh ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ --=====================_-1952780214==_.ALT Content-Type: text/html; charset="us-ascii" Haitham,

* DoS attacks (especially on the GSAKM-Lite Server) are not addressed in the
draft.  The people who follow the ipsec mailing list know that IKEv2 is in a
very good shape, and in combinations with some features of JFK, could be adopted
as the SOI.  I just wanted to draw attention to the use of stateless cookies in
phase1 of IKEv2 messages, if the Responder feels it is under DoS attack.  Can
the authors of GSAKM-Lite document address this issue and possibly  adopt the
IKEv2 techniques (possible software reuse).  This means that normal  Light Group
Establishment messages are 3 and if DoS is detected then 5 messages will be
exchanged.

I understand your reasoning for wanting stateless cookies. I try to use good protocol design techniques, and steal any good ideas I find, so I'll add this to the next revision of GSAKMP-Lite.

* The second issue is interworking with ipsec and passing the GSAKM-Lite keys to
the ipsec engine:  I appreciate that GSAKM architecture is application level and
independent of ipsec, however I think that many multicast applications with
GSAKM-Lite want to use ipsec for subsequent multicast security services
(privacy, integrity, etc.).  Is it possible for the GSAKM-Lite authors to
include some guidelines for interworking with ipsec (general or more specific
such as how to populate the SPD and SAD in ipsec engine with GSAKM-Lite keys,
etc.)

I think that the IPSec SPD and SAD would benefit from a standard API. I don't think one is in the works. The closest I've seen is documented in an Informational RFC 2367 (PF_KEY Key Management API, Version 2). I think there is some code available that implements this API, with modification it should suit our purposes. At least using the approach outlined in this Informational RFC, we will not have to reinvent the wheel.

Hugh

________________________________________________________
Hugh Harney             hh@sparta.com           410-381-9400 x203
________________________________________________________ --=====================_-1952780214==_.ALT-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Aug 27 03:35:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14095 for ; Tue, 27 Aug 2002 03:35:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 05175537D3; Tue, 27 Aug 2002 03:31:08 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A67C35357A for ; Mon, 26 Aug 2002 20:51:56 -0400 (EDT) Received: (qmail 63032 invoked by uid 3269); 27 Aug 2002 00:55:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63029 invoked from network); 27 Aug 2002 00:55:28 -0000 Received: from sj-msg-core-4.cisco.com (171.71.163.54) by klesh.pair.com with SMTP; 27 Aug 2002 00:55:28 -0000 Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7R0svW4021272; Mon, 26 Aug 2002 17:54:58 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-221.cisco.com [10.21.96.221]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id ACJ74299; Mon, 26 Aug 2002 17:52:02 -0700 (PDT) Message-Id: <4.3.2.7.2.20020826174742.0497dea0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hugh Harney From: Mark Baugher Subject: Re: [MSEC] GSAKMP to Informational RFC (resend) Cc: msec@securemulticast.org In-Reply-To: <4.2.2.20020819100503.01c20af0@pop.columbia.sparta.com> References: <4.3.2.7.2.20020814093909.07bbd350@mira-sjc5-6.cisco.com> <3D5A7B96.67EC4CAE@eim.surrey.ac.uk> <5.0.0.25.2.20020807164316.02bd51e8@pop.mail.yahoo.com> <5.0.0.25.2.20020813085337.02517da0@10.25.1.45> 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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 26 Aug 2002 17:52:21 -0700 Hugh At 10:36 AM 8/19/2002 -0400, Hugh Harney wrote: >Mark, > >I suggested that GSAKMP heavy be moved to informational status because it >is a viable protocol for multicast keying. It documents how one could use >a pairwise SA to protect a key exchange. While you are correct that GSAKMP >Lite will need to contain everything necessary to implement it. I thought >it may be helpful to the community to document the group keying under an >SA approach. So you expect that some will want to implement GSAKMP and other GSAKMP-lite? >I'm very willing to include all the relevant pieces of GSAKMP heavy into >the GSAKMP-Lite document. So that means the GSAKMP-Lite document will >continue to be a living document. However, GSAKMP-heavy contains some >ideas and mechanisms that Lite will not contain. Ok. It might be useful to identify those when the document is taken forward to Informational RFC. Up to this point, no one has listed the things in GSAKMP that are not in GSAKMP-lite and which should be preserved in an informational RFC. Also, no one has stated that different communities may be interested in both. It seems to be a bit much to take two variants of the protocol to standards track, I agree. >It wasn't my intention to use any process as a vanity press. It was my >intention to provide documentation of an alternative method for group key >management. Also, GSAKMP (heavy) has helped several people design key and >security management protocols (judging from the number of e-mails I've >received). It certainly contributed to the creation of (GSAKMP-Lite and >GDOI). My thinking was that this document should be available as a >reference. I thought that it would best be documented as an Informational RFC. > >Would it be better to continue to submit GSAKMP-heavy and GSAKMP-Lite as >Internt Dafts? I guess that they both need to be current I-Ds if they are both going to be taken to RFC status. regards, Mark >Hugh > > >________________________________________________________ >Hugh Harney hh@sparta.com 410-381-9400 x203 >________________________________________________________ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Aug 28 18:24:01 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22352 for ; Wed, 28 Aug 2002 18:24:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 094A6536B1; Wed, 28 Aug 2002 18:20:33 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id C4C9453552 for ; Wed, 28 Aug 2002 18:19:59 -0400 (EDT) Received: (qmail 91390 invoked by uid 3269); 28 Aug 2002 22:23:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91387 invoked from network); 28 Aug 2002 22:23:37 -0000 Received: from smtp017.mail.yahoo.com (216.136.174.114) by klesh.pair.com with SMTP; 28 Aug 2002 22:23:37 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Aug 2002 22:23:36 -0000 Message-Id: <5.0.0.25.2.20020828174951.02567430@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, jis@mit.edu, smb@research.att.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Last Call for MIKEY 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: Wed, 28 Aug 2002 17:55:14 -0400 Folks, We want to begin Last Call for MIKEY. If you have any open issues with respect to MIKEY, please do bring them up on the mailing list. Corrections/updates/clarifications are sought after at this time, as mikey-03 looks near-complete. Regards, Ran/Thomas _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Aug 30 07:51:44 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12434 for ; Fri, 30 Aug 2002 07:51:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 15F6253557; Fri, 30 Aug 2002 07:49:02 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 920EE53547 for ; Fri, 30 Aug 2002 07:47:37 -0400 (EDT) Received: (qmail 74592 invoked by uid 3269); 30 Aug 2002 11:51:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74589 invoked from network); 30 Aug 2002 11:51:19 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 30 Aug 2002 11:51:19 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12284; Fri, 30 Aug 2002 07:49:45 -0400 (EDT) Message-Id: <200208301149.HAA12284@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-mikey-04.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, 30 Aug 2002 07:49:45 -0400 --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 : MIKEY: Multimedia Internet KEYing Author(s) : J. Arkko et al. Filename : draft-ietf-msec-mikey-04.txt Pages : 53 Date : 2002-8-29 Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. Such a solution has to be suitable to be used in the context of conversational multimedia in a heterogeneous environment. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-04.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-04.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-04.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: <2002-8-29142328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-29142328.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 Aug 30 09:19:58 2002 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15835 for ; Fri, 30 Aug 2002 09:19:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D1ACF53669; Fri, 30 Aug 2002 09:17:14 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 597A15356E for ; Fri, 30 Aug 2002 09:15:50 -0400 (EDT) Received: (qmail 84424 invoked by uid 3269); 30 Aug 2002 13:19:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84419 invoked from network); 30 Aug 2002 13:19:30 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.wise.edt.ericsson.se) (193.180.251.49) by klesh.pair.com with SMTP; 30 Aug 2002 13:19:30 -0000 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g7UDJIrU015133; Fri, 30 Aug 2002 15:19:18 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 30 Aug 2002 15:19:18 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E070CBD4D@esealnt416> From: "Fredrik Lindholm (EAB)" To: msec@securemulticast.org Cc: canetti@watson.ibm.com, jis@mit.edu, smb@research.att.com, "'Thomas Hardjono'" Subject: RE: [MSEC] Last Call for MIKEY MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: Fri, 30 Aug 2002 15:17:56 +0200 A new version of MIKEY was submitted before the LC was announced. Unfortunately, it didn't appear in the archive until now. If you have started to read the -03 draft, I can tell you that changes are not that big (you can safely continue reading that version). We have only added some more explanations in the -04 draft to address the comment Martin sent out recently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-04.txt Fredrik > -----Original Message----- > From: Thomas Hardjono [mailto:thardjono@yahoo.com] > Sent: den 28 augusti 2002 23:55 > To: msec@securemulticast.org > Cc: canetti@watson.ibm.com; jis@mit.edu; smb@research.att.com > Subject: [MSEC] Last Call for MIKEY > > > > Folks, > > We want to begin Last Call for MIKEY. > > If you have any open issues with respect to MIKEY, please do > bring them > up on the mailing list. Corrections/updates/clarifications are > sought after at this time, as mikey-03 looks near-complete. > > Regards, > > Ran/Thomas > > > > > _______________________________________________ > 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