From msec-admin@securemulticast.org Fri Jan 3 14:19:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16970 for ; Fri, 3 Jan 2003 14:19:31 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EF9ED536A4; Fri, 3 Jan 2003 14:22:12 -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 1F7915364D for ; Fri, 3 Jan 2003 14:20:45 -0500 (EST) Received: (qmail 27117 invoked by uid 3269); 3 Jan 2003 19:20:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27112 invoked from network); 3 Jan 2003 19:20:44 -0000 Received: from smtp015.mail.yahoo.com (216.136.173.59) by klesh.pair.com with SMTP; 3 Jan 2003 19:20:44 -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; 3 Jan 2003 19:20:43 -0000 Message-Id: <5.0.0.25.2.20030103141628.04104cd0@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: Russ Housley , Thomas Hardjono From: Thomas Hardjono Cc: kent@bbn.com, canetti@watson.ibm.com, mbaugher@cisco.com, bew@cisco.com, msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <5.2.0.9.2.20030102135017.020f1450@mail.binhost.com> References: <5.0.0.25.2.20021223112252.02b02200@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: Proposed text changes to ESPbis and AHbis for multicast support 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, 03 Jan 2003 14:20:41 -0500 Russ, The SMuG group a couple of years did consider putting some structure/meaning into the SPI, but the idea was not followed through due to the (perceived) difficulty of moving the idea through the IPsec WG. cheers, thomas ------ At 1/2/2003||01:55 PM, Russ Housley wrote: >Thomas: > >I have a follow up question to your first ESP recommendation. > >>--------------------------------------------------------------------- >>ESPbis-change#1: SPI allocation and SA lookup >> >>Section 2.1 (Security Parameters Index) specifies exactly how the >>SPI should be dealt with: >> >> For multicast SAs, the SPI (and optionally the protocol ID) in >> combination with the destination address is used to select an SA. >> This is because multicast SAs are defined by a multicast >> controller, not by each IPsec receiver. (See the Security >> Architecture document for more details) [ESPbis]. >> >>We propose this section to be replaced with the following wording: >> >> For broadcast, multicast, and anycast SAs, the SPI and protocol >> ID (ESP) in combination with the destination address is used to >> select an SA. In some cases, other parameters (such as a source >> address) MAY be used by a receiver to further identify the >> correct SA. This is because multicast SAs may be defined by more >> than one multicast group controller. >>--------------------------------------------------------------------- > >Would it help if the SPI indicated whether the associated security >association was unicastor multicast (which includes broadcast and >anycast)? If there were an indication in the SPI itself, then the >implementation would know if the unicast or multicast rules should be applied. > >If this is of value, the most significant bit could be used to indicate >the security association type. > >Russ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jan 9 17:35:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28553 for ; Thu, 9 Jan 2003 17:35:18 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CF1BE5354C; Thu, 9 Jan 2003 17:38:03 -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 2AE8E53547 for ; Thu, 9 Jan 2003 17:37:01 -0500 (EST) Received: (qmail 25620 invoked by uid 3269); 9 Jan 2003 22:37:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25617 invoked from network); 9 Jan 2003 22:37:01 -0000 Received: from sj-msg-core-3.cisco.com (171.70.157.152) by klesh.pair.com with SMTP; 9 Jan 2003 22:37:00 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn2-1307.cisco.com [10.21.117.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h09MaMjT010506; Thu, 9 Jan 2003 14:36:22 -0800 (PST) Message-Id: <5.1.1.5.2.20030109143112.064fe738@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: From: Mark Baugher Cc: , , , , , msec@securemulticast.org In-Reply-To: <200301091649.h09GnBS18635@web170.megawebservers.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Re: [GSEC] Security protocol which supports multicast 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, 09 Jan 2003 14:36:53 -0800 Eyal There are some works in progress, see http://www.ietf.org/html.charters/msec-charter.html and one of the specifications, GDOI, is soon to be published as an Internet Proposed Standard. My guess is that you need a product solution and not an architecture or a set of nascent standards documents. We generally don't discuss vendors products on these lists, but I encourage list members whose companies have product solutions to contact you. Mark At 04:49 PM 1/9/2003 +0000, eyaln@giritcanada.com wrote: > Hi , > > Our company is looking for a way to encrypt\authenticate data that > is sent over ip network using multicast. > > We have video encoders and decoders using multicast traffic > and we would like to prevent unauthorized clients > from viewing the data. > > We would like to use a standard encryption protocol > (A win2000 based solution is preferred) > > > Any suggestions for solutions\protocols ? > > Thanks > Eyal > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jan 16 22:58:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01766 for ; Thu, 16 Jan 2003 22:58:52 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 520475363F; Thu, 16 Jan 2003 23:01: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 356CC535B2 for ; Thu, 16 Jan 2003 17:19:48 -0500 (EST) Received: (qmail 58179 invoked by uid 3269); 16 Jan 2003 22:19:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58167 invoked from network); 16 Jan 2003 22:19:47 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 16 Jan 2003 22:19:47 -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 h0GMJaHB028444; Thu, 16 Jan 2003 16:19:36 -0600 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id RAA01867; Thu, 16 Jan 2003 17:19:35 -0500 (EST) Message-ID: <3E272FF9.7C098DE1@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ldondeti@nortelnetworks.com Cc: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MSEC] GKM Architecture Comments 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, 16 Jan 2003 17:19:37 -0500 Content-Transfer-Encoding: 7bit Lakshminath, Here are the changes to the msec architecture document that I promised we would send for inclusion in the next draft. Comments and discussion are welcome. Section 2, #3: Key material are delivered securely to members of the group so that they are secret, authenticated to group members, and verified as coming from an authorized source. Section 2, #4: delete, redundant with #3 Section 2, #5: This is not a general requirement, but rather could come from local group policy. For example, some systems may wish to grant archival access. Suggest deletion of requirement. Section 2, #7: Suggest breaking up this requirement into key management performance and key management interoperability with applications. Section 2, Requirements list addition. "Groups must be capable of securely recovering from compromise of keys." Paragraph after Section 2, #8: The example given is rather tangential. Suggest removing text after initial statement that group key management protocols are useful for non-multicast groups. Second paragraph after Section 2, #8: "... But for large, single-source ..." This statement is incorrect. Scalability studies show otherwise. Please delete from this sentence on to the end of the paragraph. Section 3.1, first paragraph: "The main goal of a group key management protocol is to SECURELY provide the group members with an up-to-date and TRUSTWORTHY security association (SA), which contains ..." Suggested additions are in caps -- I am not yelling ;-) Section 3.1, (2), last sentence: Change "the GCKS" to "a GCKS" Section 3.1, (2), paragraph after second bullet: "The Re-key protocol ensures that all members receive the re-key information is a timely manner." Since timely is relative, and since failure to receive is recoverable with a re-join, suggest removing this statement as it is vague and inaccurate. Section 3.2, first paragraph: TEK, this term implies encryption. How about DPK = Data Protection Key? Section 3.3, Distributed operation sentences dangling at end Suggest adding "and (4) allowing distributed operation of the GCKS, when ..." Section 3.4, Figure 2: SAD and SPD are too IPsec-specific. Control function isn't really discussed elsewhere and is largely integral to the GKM, telephony is outside the scope of the WG, etc. Suggest removing Section 3.4. Section 4.0, second paragraph -- GSAKMP is no longer using a secure-channel protocol. Suggest removing remainder of paragraph after the first sentence. Add table showing differences in features of GDOI, GSAKMP, and MIKEY. Not tradeoff analysis, but just introduction to features. General comment -- more telephony discussion. Suggest removing all references to telephony throughout document. Section 4.1, Registration Protocol Message Exchange: Mikey uses tunnelling, but GDOI reuses design. This is not the same approach. GSAKMP also reuses design. This section needs reworking to truly differentiate all approaches. Section 5.4: Define implosion -- denial of service against self? Section 6.1: First paragraph, Second sentence. "It CAN be distributed through announcement, other external means, or in-band with the registration and rekey protocols." Section 6.1: First paragraph, Last sentence. Not sure that this makes sense. Section 6.1: Second paragraph: These only true for GDOI and MIKEY, but are not true as general architectural constructs. GSAKMP provides both through announcement and through in-band means. Does this discussion belong in this document? Section 6.1, Third Paragraph: "This memo assumes ..." Huh? These are features of MIKEY and GDOI, but not of the generic architecture. GSAKMP provides these. Section 7: Other areas of the document consider topologies other than one to many large scale. Shouldn't this section as well? Section 8, fifth paragraph, last sentence: A great deal has been published on group security. --- Andrea and Hugh _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jan 20 12:12:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24375 for ; Mon, 20 Jan 2003 12:12:11 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8B173535D6; Mon, 20 Jan 2003 12:15: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 8D37B535C4 for ; Mon, 20 Jan 2003 12:12:09 -0500 (EST) Received: (qmail 85785 invoked by uid 3269); 20 Jan 2003 17:12:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85781 invoked from network); 20 Jan 2003 17:12:09 -0000 Received: from www.elias-on-curve.org (HELO linux.nue.et-inf.uni-siegen.de) (141.99.152.2) by klesh.pair.com with SMTP; 20 Jan 2003 17:12:09 -0000 Received: from localhost (localhost [127.0.0.1]) by linux.nue.et-inf.uni-siegen.de (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 860723CE6D for ; Mon, 20 Jan 2003 18:12:04 +0100 (CET) Received: from nue100 (nue181 [141.99.152.181]) by linux.nue.et-inf.uni-siegen.de (Postfix on SuSE Linux 7.3 (i386)) with SMTP id F22AD16EFD for ; Mon, 20 Jan 2003 18:12:03 +0100 (CET) From: "Namhi Kang" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS perl-11 Subject: [MSEC] Location of Flames reports 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, 21 Jan 2003 02:10:20 +0900 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id MAA24375 Dear all, Does anybody know where i can find following report? I found it on the tesla-spec-00 draft but I couldn't find it at the refered web site. B. Briscoe, "Flames: Fast, loss-tolerant authentication of mul ticast streams," tech. rep., BT Research, 2000. http://www.labs.bt.com/people/briscorj/papers.html. Thanks in advance. Best regards Namhi Kang&j)b b٬yy˫zk'm 0X޷Ybا~ From msec-admin@securemulticast.org Fri Jan 24 07:59:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17537 for ; Fri, 24 Jan 2003 07:59:11 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7D1A5535AF; Fri, 24 Jan 2003 08:02: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 6AA85535AF for ; Fri, 24 Jan 2003 08:00:29 -0500 (EST) Received: (qmail 49505 invoked by uid 3269); 24 Jan 2003 13:00:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49502 invoked from network); 24 Jan 2003 13:00:29 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 24 Jan 2003 13:00:29 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17440; Fri, 24 Jan 2003 07:57:00 -0500 (EST) Message-Id: <200301241257.HAA17440@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-dhhmac-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: Fri, 24 Jan 2003 07:56:59 -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 : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-01.txt Pages : 19 Date : 2003-1-23 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC- SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-dhhmac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-01.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: <2003-1-23095515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-dhhmac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-23095515.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec