From msec-admin@securemulticast.org Fri May 2 06:42:28 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10921 for ; Fri, 2 May 2003 06:42:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 906DB5369A; Fri, 2 May 2003 06:44:05 -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 980375365D for ; Fri, 2 May 2003 06:43:57 -0400 (EDT) Received: (qmail 84616 invoked by uid 3269); 2 May 2003 10:43:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84613 invoked from network); 2 May 2003 10:43:57 -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; 2 May 2003 10:43:57 -0000 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h42Aht1b013866; Fri, 2 May 2003 12:43:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 2 May 2003 12:43:54 +0200 Message-ID: <1F55F6582266314A85A55F6241509B670575B3BF@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: "'martin.euchner@siemens.com'" Cc: "Elisabetta Carrara (EAB)" , msec@securemulticast.org, "'steffen.fries@siemens.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [MSEC] RE: MIKEY Identity payload question 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, 2 May 2003 12:40:04 +0200 Hi Martin, > -----Original Message----- > From: Euchner Martin ICN M SR 3 [mailto:martin.euchner@siemens.com] > Sent: den 2 maj 2003 11:49 > To: msec@securemulticast.org; Euchner Martin ICN M SR 3 > Cc: Elisabetta Carrara (EAB); 'steffen.fries@siemens.com' > Subject: MIKEY Identity payload question > > > Quick question regarding the IDi, IDr payloads in the MIKEY protocols: > > While IDr is optional in the MIKEY-preshared and public-key > protocols, the > Diffie-Hellman variant is lightly different in that the additional IDi > reflected by the sender is not optional. > > Is IDi in MIKEY-DHSIGN R_message really a mandatory field even if the > initiator did not provide any explicit identity information? Yes > This sounds > like the responder would have to defer the initiator's ID > through some other > means. Correct (the assumption is basically, if you know how to verify the signature, then you also know the ID). > My naive assumption of understanding would be that the IDi at the > responder's side is understood as an optional field. The > responder should > provide IDi payload at least if an IDi payload was received. > Otherwise, if > no IDi payload had been received, IDi payload would not be > responded. Is > this the intention? No The reason for mandating the IDi was mainly to avoid that the following attack could take place: Alice (IDi) Carol (IDi') Bob (IDr) ---I-mesasge --> Change ID and add own signature --- I'-message ---> <--- R-message --- <--- R-message --- <------------- communication -------------> I'm talking to Bob! I'm talking to Carol! (You could see this as: Alice should submit her homework to her teacher Bob. Carol didn't do her homework but knows that Alice is a very good student. Therefore, she would like to send in Alice's homework as her own...) Even though Carol will not be able to eavesdrop on the communication, it is still a problem that Bob cannot know for sure who he is actually talking to. So this was the reason why we mandated the IDi in the response of the DH-mode. > I further assuming that making the ID payloads optional has > nothing to do > with identity protection? Correct Best Regards, Fredrik > > > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | ICN M SR 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://intranet.icn.siemens.de/marketing/cs27/topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > -------------------------------------------------------------- > --------- > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri May 2 10:26:50 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16157 for ; Fri, 2 May 2003 10:26:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4DC7053931; Fri, 2 May 2003 10:28:19 -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 C0A1D536D7 for ; Fri, 2 May 2003 10:26:12 -0400 (EDT) Received: (qmail 16551 invoked by uid 3269); 2 May 2003 14:26:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16544 invoked from network); 2 May 2003 14:26:12 -0000 Received: from albatross-ext.wise.edt.ericsson.se (HELO albatross.tn.sw.ericsson.se) (193.180.251.49) by klesh.pair.com with SMTP; 2 May 2003 14:26:12 -0000 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h42EQB0J012356; Fri, 2 May 2003 16:26:11 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 2 May 2003 16:26:09 +0200 Message-ID: <1F55F6582266314A85A55F6241509B670575B3C1@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: "'Euchner Martin ICN M SR 3'" Cc: "Elisabetta Carrara (EAB)" , msec@securemulticast.org, "'steffen.fries@siemens.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [MSEC] RE: MIKEY DH-payload question 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, 2 May 2003 16:22:20 +0200 > From: Euchner Martin ICN M SR 3 [mailto:martin.euchner@siemens.com] > Sent: den 2 maj 2003 14:47 > > Fredrick, > > many thanks for the fast response. I fully agree with your > answers, and I > will add some clarifications into my ID. > > > However, I just came across another issue in the MIKEY DH > key-update method > (see section 4.5): > > The DH-method allows [DHi] and [DHi, DHr] being optional. > > I assume that [X, Y] means either X and Y present or both absent Correct assumption. > (in contrast to using [X], [Y] for the other cases) ? > > > Still, there are some combinations of options that are not > entirely clear to > me: Possible reasons are that a DH payload may be a new one > or a previous > one; > > > 1.) Initiator sends DHi, Responder sends no DH half key(s) > 2.) Initiator doesn't any DHi, Responder sends DHi & DHr: The > responder can > just reuse the existing DHi but certainly SHOULD generate a new DHr ? I would not recommended this. If you like to reuse previous value, you should still send it. One reason to send it is because you may map the value to a lifetime or an MKI. It would be very confusing to guess what DH value to use if there would have existed more than one during a MIKEY session. > > Case 1) would thus compute a new TGK based upon the new DHi and the > old/currently active DHr? > Case 2) would compute a new TGK based upon the new DHr and > currently active > DHi? > > Thus case 1) and case 2) could be seen as a partial key > update; a feature > that certainly may have its value! I agree that partial update might be a nice feature, but as stated above, I do think one always should send the value (even if it is not a "fresh" one) just to avoid confusion. The reason that you could leave the DH values out was to be able to update other parameters without the need to update the key. This might be something we need to clarify in the draft. > Generally, I see some necessity that the notion of optional > be clarified. My > understanding of the [X] payloads is that such fields SHOULD > be present as > much as possible, but MAY be left out in certain > circumstances. Is that > true? Yes > > Since those "certain circumstances" and their impact on the (reduced) > security is not entirely obvious from the text, I fear that some > implementers may simply discard any optional fields from > implementation for > the sake of simplicity. Thus, some warning statements should > be considered > when an option is not taken... Sounds like a good idea. Thanks, Fredrik > > > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | ICN M SR 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://intranet.icn.siemens.de/marketing/cs27/topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > -------------------------------------------------------------- > --------- > > -----Original Message----- > From: Fredrik Lindholm (EAB) > [mailto:Fredrik.Lindholm@era.ericsson.se] > Sent: Friday, May 02, 2003 12:40 PM > To: Euchner Martin ICN M SR 3 > Cc: Elisabetta Carrara (EAB); msec@securemulticast.org; > 'steffen.fries@siemens.com' > Subject: RE: MIKEY Identity payload question > > > Hi Martin, > > > -----Original Message----- > > From: Euchner Martin ICN M SR 3 [mailto:martin.euchner@siemens.com] > > Sent: den 2 maj 2003 11:49 > > To: msec@securemulticast.org; Euchner Martin ICN M SR 3 > > Cc: Elisabetta Carrara (EAB); 'steffen.fries@siemens.com' > > Subject: MIKEY Identity payload question > > > > > > Quick question regarding the IDi, IDr payloads in the MIKEY > protocols: > > > > While IDr is optional in the MIKEY-preshared and public-key > > protocols, the > > Diffie-Hellman variant is lightly different in that the > additional IDi > > reflected by the sender is not optional. > > > > Is IDi in MIKEY-DHSIGN R_message really a mandatory field > even if the > > initiator did not provide any explicit identity information? > > Yes > > > This sounds > > like the responder would have to defer the initiator's ID > > through some other > > means. > > Correct (the assumption is basically, if you know how to verify the > signature, then you also know the ID). > > > My naive assumption of understanding would be that the IDi at the > > responder's side is understood as an optional field. The > > responder should > > provide IDi payload at least if an IDi payload was received. > > Otherwise, if > > no IDi payload had been received, IDi payload would not be > > responded. Is > > this the intention? > > No > > The reason for mandating the IDi was mainly to avoid that the > following attack could take place: > > Alice (IDi) Carol (IDi') Bob (IDr) > > ---I-mesasge --> > Change ID and > add own signature > --- I'-message ---> > <--- R-message --- > <--- R-message --- > > <------------- communication -------------> > I'm talking to Bob! I'm talking to Carol! > > > (You could see this as: Alice should submit her homework to her > teacher Bob. Carol didn't do her homework but knows that Alice > is a very good student. Therefore, she would like to send in > Alice's homework as her own...) > > Even though Carol will not be able to eavesdrop on the > communication, it is still a problem that Bob cannot know > for sure who he is actually talking to. So this was the reason > why we mandated the IDi in the response of the DH-mode. > > > > I further assuming that making the ID payloads optional has > > nothing to do > > with identity protection? > > Correct > > Best Regards, > Fredrik > > > > > > > With kind regards > > > > Martin Euchner. > > -------------------------------------------------------------- > > --------- > > | Dipl.-Inf. Rapporteur Q.G/SG16 > > | Martin Euchner Phone: +49 89 722 55790 > > | Siemens AG.....................Fax : +49 89 722 62366 > > | ICN M SR 3 mailto:Martin.Euchner@siemens.com > > | mailto:martin.euchner@ties.itu.int > > | Hofmannstr. 51 Intranet: > > http://intranet.icn.siemens.de/marketing/cs27/topics/security/ > > | D-81359 Muenchen Internet: http://www.siemens.de/ > > | __________________ > > | Germany > > -------------------------------------------------------------- > > --------- > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu May 8 15:35:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06189 for ; Thu, 8 May 2003 15:35:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D7906537AC; Thu, 8 May 2003 15:38:06 -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 414255385E for ; Thu, 8 May 2003 15:37:20 -0400 (EDT) Received: (qmail 41125 invoked by uid 3269); 8 May 2003 19:37:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41122 invoked from network); 8 May 2003 19:37:20 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 8 May 2003 19:37:20 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05973; Thu, 8 May 2003 15:34:20 -0400 (EDT) Message-Id: <200305081934.PAA05973@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-arch-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, 08 May 2003 15:34:19 -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 : The Multicast Security (MSEC) Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-01.txt Pages : 21 Date : 2003-5-8 This document provides a foundation for the protocols developed by the Multicast Security (MSEC) group. The document begins by introducing a Reference Framework, and proceeds to identify functional areas which must be addressed as part of a secure multicast solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-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-arch-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-arch-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-5-8110434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-8110434.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu May 8 15:35:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06219 for ; Thu, 8 May 2003 15:35:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 161D253871; Thu, 8 May 2003 15:38:10 -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 9C64E536AB for ; Thu, 8 May 2003 15:37:33 -0400 (EDT) Received: (qmail 41179 invoked by uid 3269); 8 May 2003 19:37:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41173 invoked from network); 8 May 2003 19:37:33 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 8 May 2003 19:37:33 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06024; Thu, 8 May 2003 15:34:33 -0400 (EDT) Message-Id: <200305081934.PAA06024@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-08.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, 08 May 2003 15:34:33 -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 : The Group Domain of Interpretation Author(s) : M. Baugher, T. Hardjono, H. Harney, B. Weis Filename : draft-ietf-msec-gdoi-08.txt Pages : 42 Date : 2003-5-8 This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data 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-08.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-08.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-08.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-5-8112424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gdoi-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gdoi-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-8112424.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu May 8 18:01:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13032 for ; Thu, 8 May 2003 18:01:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 108DD53615; Thu, 8 May 2003 18:04: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 E9D3C53552 for ; Thu, 8 May 2003 18:02:14 -0400 (EDT) Received: (qmail 70075 invoked by uid 3269); 8 May 2003 22:02:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70072 invoked from network); 8 May 2003 22:02:14 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 8 May 2003 22:02:14 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h48M2CwE018077 for ; Thu, 8 May 2003 15:02:12 -0700 (PDT) Message-ID: <3EBAD3E3.8A6452CC@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: msec@securemulticast.org Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-08.txt References: <200305081934.PAA06024@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 08 May 2003 15:02:11 -0700 Content-Transfer-Encoding: 7bit For those who may be wondering, this draft of GDOI reflects changes made as a result of the IANA review. No other changes were made. Brian Internet-Drafts@ietf.org wrote: > > 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, T. Hardjono, H. Harney, B. Weis > Filename : draft-ietf-msec-gdoi-08.txt > Pages : 42 > Date : 2003-5-8 > > This document presents an ISAMKP Domain of Interpretation (DOI) for > group key management to support secure group communications. The > GDOI manages group security associations, which are used by IPSEC and > potentially other data 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-08.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-08.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-08.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. -- 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 Mon May 12 13:25:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24717 for ; Mon, 12 May 2003 13:25:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DAFB05369A; Mon, 12 May 2003 13:27:24 -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 4DDD0538C5 for ; Mon, 12 May 2003 13:25:50 -0400 (EDT) Received: (qmail 96119 invoked by uid 3269); 12 May 2003 17:25:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96116 invoked from network); 12 May 2003 17:25:47 -0000 Received: from web41609.mail.yahoo.com (66.218.93.109) by klesh.pair.com with SMTP; 12 May 2003 17:25:47 -0000 Message-ID: <20030512172547.4628.qmail@web41609.mail.yahoo.com> Received: from [131.227.89.21] by web41609.mail.yahoo.com via HTTP; Tue, 13 May 2003 01:25:47 CST From: =?iso-8859-1?q?Tommy=20Chan?= To: msec@securemulticast.org, gsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [MSEC] Source Code 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 May 2003 01:25:47 +0800 (CST) Content-Transfer-Encoding: 8bit Hi Everybody, May i know where can i find the source code for the Key distribution algorithm such as LKH, OFT, Subnet Difference etc ? Or is there any website that contains relevant source code related to Multicast Key Management? Thanks for your time. Cheers. __________________________________________________ Do You Yahoo!? Promote your business from just $5 a month! http://sg.biztools.yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue May 13 03:33:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29850 for ; Tue, 13 May 2003 03:33:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D7481538B4; Tue, 13 May 2003 03:34: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 78EF95360B for ; Tue, 13 May 2003 03:33:08 -0400 (EDT) Received: (qmail 67857 invoked by uid 3269); 13 May 2003 07:33:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67853 invoked from network); 13 May 2003 07:33:05 -0000 Received: from dukas.upc.es (147.83.2.62) by klesh.pair.com with SMTP; 13 May 2003 07:33:05 -0000 Received: from mat.upc.es (mat.upc.es [147.83.39.3]) by dukas.upc.es (8.12.1/8.12.1) with ESMTP id h4D7WhhA026982; Tue, 13 May 2003 09:32:44 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by mat.upc.es (Postfix) with ESMTP id ABADFDE84; Tue, 13 May 2003 09:32:13 +0200 (MET DST) Received: from mat.upc.es (rho.upc.es [147.83.39.183]) by mat.upc.es (Postfix) with ESMTP id AEFE8DE89; Tue, 13 May 2003 09:32:02 +0200 (MET DST) Message-ID: <3EC0A56D.3050001@mat.upc.es> From: Josep Pegueroles User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: es, en-us MIME-Version: 1.0 To: Tommy Chan , gsec@lists.tislabs.com, msec@securemulticast.org References: <20030512172547.4628.qmail@web41609.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Subject: [MSEC] Re: [GSEC] Source Code 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 May 2003 09:57:33 +0200 Content-Transfer-Encoding: 7bit Hello Tommy (and everybody), Here is Josep Pegueroles from the Information Security Group of the Technical University of Catalonia (in Spain). (htp://isg.upc.es). Although we have joined the gsec (and msec) mailing list many time ago, it is the first time I have decided to write. Anyway, our research group have been working in developing some applications supporting LKH and we have generated some code in Java and C. You can view some of the results of our work in htp://isg.upc.es/gsec/work.html Mainly, we have a Class Tree and two standalone applications (one for client and one for key-server/client) enabling LKH multicast rekeying. They have been used for educational purposes but their class structure can also be profitable to include LKH functionalities to other applications. You can see more information in http://isg.upc.es/gsec/lkh_java.html and download the package from http://isg.upc.es/gsec/download/lkh_class.jar (the first version is finished and currently we are working in the second one, which includes batch-lkh and improved-LKH, one of our proposals) We also have added LKH functionalities to Brian Weis' (Hi, Brian!) gdoi C code. It is not finished yet but we hope it will be ready in a couple of weeks. You also can see the current status of our work in http://isg.upc.es/gsec/lkh_gdoi.html and download the current version. However, we keep in touch with Brian to provide a fully working version in the near future. I will announce it in this forum when ready. Hope to be useful, Regards, Josep Pegueroles Tommy Chan wrote: >Hi Everybody, >May i know where can i find the source code for the >Key distribution algorithm such as LKH, OFT, Subnet >Difference etc ? Or is there any website that contains >relevant source code related to Multicast Key >Management? > >Thanks for your time. > >Cheers. > >__________________________________________________ >Do You Yahoo!? >Promote your business from just $5 a month! >http://sg.biztools.yahoo.com > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 21 08:12:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16209 for ; Wed, 21 May 2003 08:12:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 771585375C; Wed, 21 May 2003 08:12: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 14574536E9 for ; Wed, 21 May 2003 08:11:08 -0400 (EDT) Received: (qmail 9989 invoked by uid 3269); 21 May 2003 12:11:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9984 invoked from network); 21 May 2003 12:11:07 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 21 May 2003 12:11:07 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16146; Wed, 21 May 2003 08:11:06 -0400 (EDT) Message-Id: <200305211211.IAA16146@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-tgsakmp-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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 21 May 2003 08:11:05 -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 : Tunneled Group Secure Association Key Management Protocol Author(s) : H. Harney et al. Filename : draft-ietf-msec-tgsakmp-00.txt Pages : 52 Date : 2003-5-20 The Tunneled Group Secure Association Key Management Protocol (T-GSAKMP) provides a security framework for creating cryptographic groups on a network. It is designed to provide key distribution services under the cryptographic protection of a pairwise SA, like IPSec. T-GSAKMP relies on the pairwise SA to provide data confidentiality services for policy, DoS mitigation services, and protection from 'man-in-the-middle' attacks. It provides mechanisms to disseminate group security policy, perform access control based upon PKI certificates, generate group keys, and recover from compromise. This framework addresses group scalability issues by facilitating delegation of process-intensive actions in a secure and controlled manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-tgsakmp-00.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-tgsakmp-00.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-tgsakmp-00.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-5-20124945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-tgsakmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-tgsakmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-20124945.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 21 09:21:05 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20301 for ; Wed, 21 May 2003 09:21:05 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 63F6753791; Wed, 21 May 2003 09:20:35 -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 33604535D2 for ; Wed, 21 May 2003 09:19:13 -0400 (EDT) Received: (qmail 21882 invoked by uid 3269); 21 May 2003 13:19:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21876 invoked from network); 21 May 2003 13:19:13 -0000 Received: from unknown (HELO db1.contentcatcher.com) (64.19.188.18) by klesh.pair.com with SMTP; 21 May 2003 13:19:13 -0000 Received: from CC2 ([192.168.200.3]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 09:15:39 -0400 x-sender: owner-ietf-announce@ietf.org x-receiver: spamtrap@spam.clearnetwork.com Received: from pf2.contentcatcher.com ([192.168.100.3]) by CC2 with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 09:20:00 -0400 Received: by pf2.contentcatcher.com (Postfix, from userid 500) id 17C919F103; Wed, 21 May 2003 09:07:05 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by pf2.contentcatcher.com (Postfix) with ESMTP id 478429F113; Wed, 21 May 2003 09:06:54 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19ISTg-0003Yj-Hu for ietf-announce-list@asgard.ietf.org; Wed, 21 May 2003 08:13:52 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by asgard.ietf.org with esmtp (Exim 4.14) id 19ISR2-0003V4-FD for all-ietf@asgard.ietf.org; Wed, 21 May 2003 08:11:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16146; Wed, 21 May 2003 08:11:06 -0400 (EDT) Message-Id: <200305211211.IAA16146@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Reply-To: Internet-Drafts@ietf.org Precedence: bulk X-Spam-Status: Yes, hits=9.6 required=5.0tests=BAYES_70,CC_Bulk_Header_1,MIME_BOUND_NEXTPART,TO_MALFORMEDversion=2.53-contentcatcher X-Spam-Level: ********* X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results9.60 points, 5 required;* 1.8 -- To: has a malformed address* 5.0 -- Mail has precedence set to bulk* 2.5 -- BODY: Bayesian classifier says spam probability is 70 to 80%[score: 0.7307]* 0.3 -- Spam tool pattern in MIME boundary---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-ietf-announce@ietf.org X-GHOST-RECEIVER: braja@tellium.com X-OriginalArrivalTime: 21 May 2003 13:20:00.0578 (UTC) FILETIME=[AE933220:01C31F9B] x-contentCatcher: ContentCatcher build 0407021738 Cc: msec@securemulticast.org To: braja@tellium.com From: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-tgsakmp-00.txt [owner-ietf-announce@ietf.org in Pass-Through List] ['from' in Pass-Through List] Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 21 May 2003 08:11:05 -0400 This is a multi-part message in MIME format. --NextPart Title : Tunneled Group Secure Association Key Management Protocol Author(s) : H. Harney et al. Filename : draft-ietf-msec-tgsakmp-00.txt Pages : 52 Date : 2003-5-20 The Tunneled Group Secure Association Key Management Protocol (T-GSAKMP) provides a security framework for creating cryptographic groups on a network. It is designed to provide key distribution services under the cryptographic protection of a pairwise SA, like IPSec. T-GSAKMP relies on the pairwise SA to provide data confidentiality services for policy, DoS mitigation services, and protection from 'man-in-the-middle' attacks. It provides mechanisms to disseminate group security policy, perform access control based upon PKI certificates, generate group keys, and recover from compromise. This framework addresses group scalability issues by facilitating delegation of process-intensive actions in a secure and controlled manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-tgsakmp-00.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-tgsakmp-00.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-tgsakmp-00.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" This is a multi-part message in MIME format. --OtherAccess Content-Type: Message/External-body;access-type="mail-server";server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-20124945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-tgsakmp-00.txt --OtherAccess Content-Type: Message/External-body;name="draft-ietf-msec-tgsakmp-00.txt";site="ftp.ietf.org";access-type="anon-ftp";directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-20124945.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 28 14:39:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15399 for ; Wed, 28 May 2003 14:39:44 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E76E35357A; Wed, 28 May 2003 14:39:05 -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 4CE7C5357A for ; Wed, 28 May 2003 14:37:24 -0400 (EDT) Received: (qmail 86748 invoked by uid 3269); 28 May 2003 18:37:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86745 invoked from network); 28 May 2003 18:37:24 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 28 May 2003 18:37:24 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4SIbL9x025473 for ; Wed, 28 May 2003 11:37:22 -0700 (PDT) Message-ID: <3ED501E1.C3DAB306@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: msec@securemulticast.org Content-Type: multipart/mixed; boundary="------------6F1AF5DF3680C22EC2800808" Subject: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts] 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 May 2003 11:37:21 -0700 This is a multi-part message in MIME format. --------------6F1AF5DF3680C22EC2800808 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Note that the new ESP and AH drafts are now officially in last call. These drafts contain a number of changes from RFCs 2402/2406 that make them more useful when used to protect IP multicast packets. If anyone has any additional issues, now is the time to speak! From my memory, there was only one change in these latest versions that affects the multicast case. That was the removal of the "protocol" from the SPI lookup for multicast packets. (I.e., from {destination, SPI, protocol} to {destination, SPI} for any source multicast groups). The effect of this change seems minor. It slightly increases the possibility of ambiguous SPI lookups. This should only happen if two key servers are not choosing SPIs in a coordinated fashion for the same destination. (E.g., if two applications were using the same destination address.) But it is still a problem whether or not the protocol field remains in the SPI lookup, so it does not seem worth arguing about. Other than that, I personally didn't have any concerns with the drafts. Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --------------6F1AF5DF3680C22EC2800808 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHM25452; Tue, 27 May 2003 06:29:02 -0700 (PDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h4RDVTNb006377; Tue, 27 May 2003 06:31:29 -0700 (PDT) Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id h4RDUx19003511; Tue, 27 May 2003 06:31:00 -0700 (PDT) Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by proxy3.cisco.com (8.12.8p1/8.11.2) with ESMTP id h4RDW2Wd011253; Tue, 27 May 2003 06:32:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05996 Tue, 27 May 2003 09:20:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 May 2003 18:45:48 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: LAST CALL: ESP and AH ESN drafts Cc: tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_364919486==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk X-Mozilla-Status2: 00000000 --=====================_364919486==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed This is a working group last call for comments on the following drafts, for progression to Proposed Standard: draft-ietf-ipsec-esp-v3-05.txt draft-ietf-ipsec-rfc2402bis-03.txt draft-ietf-ipsec-esn-addendum-01.txt These drafts have not received a great amount of attention so Ted and I would like to urge everyone to take a good look at them. We are extending the working group last call to 3 weeks to give folks adequate time to comment. This last call will expire on June 16. thanks, Barb and Ted --=====================_364919486==_.ALT Content-Type: text/html; charset="us-ascii" This is a working group last call for comments on the following drafts, for progression to Proposed Standard:

draft-ietf-ipsec-esp-v3-05.txt
draft-ietf-ipsec-rfc2402bis-03.txt
draft-ietf-ipsec-esn-addendum-01.txt

These drafts have not received a great amount of attention so Ted and I would like to urge everyone to take a good look at them. We are extending the working group last call to 3 weeks to give folks adequate time to comment. This last call will expire on June 16. 

thanks,
Barb and Ted --=====================_364919486==_.ALT-- --------------6F1AF5DF3680C22EC2800808-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 28 14:50:57 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16315 for ; Wed, 28 May 2003 14:50:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8526B536FE; Wed, 28 May 2003 14:50:27 -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 742E053992 for ; Wed, 28 May 2003 14:48:42 -0400 (EDT) Received: (qmail 88353 invoked by uid 3269); 28 May 2003 18:48:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 88350 invoked from network); 28 May 2003 18:48:42 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 28 May 2003 18:48:42 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4SIltt08442; Wed, 28 May 2003 13:47:55 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LGT1YBAP; Wed, 28 May 2003 11:47:55 -0700 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2RDTRSG6; Wed, 28 May 2003 14:47:53 -0400 Message-ID: <3ED50430.6010406@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Weis Cc: msec@securemulticast.org Subject: Re: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts] References: <3ED501E1.C3DAB306@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 28 May 2003 14:47:12 -0400 Content-Transfer-Encoding: 7bit I guess we still need an MESP I-D! I was hoping that there would be one ESP RFC that will work for both multicast and unicast. regards, Lakshminath Brian Weis wrote: > Note that the new ESP and AH drafts are now officially in last call. > These drafts contain a number of changes from RFCs 2402/2406 that make > them more useful when used to protect IP multicast packets. If anyone > has any additional issues, now is the time to speak! > >>From my memory, there was only one change in these latest versions that > affects the multicast case. That was the removal of the "protocol" from > the SPI lookup for multicast packets. (I.e., from {destination, SPI, > protocol} to {destination, SPI} for any source multicast groups). > > The effect of this change seems minor. It slightly increases the > possibility of ambiguous SPI lookups. This should only happen if two key > servers are not choosing SPIs in a coordinated fashion for the same > destination. (E.g., if two applications were using the same destination > address.) But it is still a problem whether or not the protocol field > remains in the SPI lookup, so it does not seem worth arguing about. > > Other than that, I personally didn't have any concerns with the drafts. > > Brian > > > ------------------------------------------------------------------------ > > Subject: > LAST CALL: ESP and AH ESN drafts > From: > Barbara Fraser > Date: > Mon, 26 May 2003 18:45:48 -0700 > To: > ipsec@lists.tislabs.com > > > This is a working group last call for comments on the following drafts, > for progression to Proposed Standard: > > draft-ietf-ipsec-esp-v3-05.txt > draft-ietf-ipsec-rfc2402bis-03.txt > draft-ietf-ipsec-esn-addendum-01.txt > > These drafts have not received a great amount of attention so Ted and I > would like to urge everyone to take a good look at them. We are > extending the working group last call to 3 weeks to give folks adequate > time to comment. This last call will expire on June 16. > > thanks, > Barb and Ted _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 28 15:57:11 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20725 for ; Wed, 28 May 2003 15:57:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6FE11539A3; Wed, 28 May 2003 15:56:38 -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 39EE0535C2 for ; Wed, 28 May 2003 15:55:08 -0400 (EDT) Received: (qmail 608 invoked by uid 3269); 28 May 2003 19:55:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 605 invoked from network); 28 May 2003 19:55:08 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 28 May 2003 19:55:08 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4SJt59x008817; Wed, 28 May 2003 12:55:05 -0700 (PDT) Received: from cscoamera13263.mbaugher.com (sjc-vpn1-576.cisco.com [10.21.98.64]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEN87947; Wed, 28 May 2003 12:55:04 -0700 (PDT) Message-Id: <5.1.1.5.2.20030528125453.02dd0dc0@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Brian Weis From: Mark Baugher Subject: Re: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts] Cc: msec@securemulticast.org In-Reply-To: <3ED501E1.C3DAB306@cisco.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: Wed, 28 May 2003 12:55:03 -0700 Neither do I. Mark At 11:37 AM 5/28/2003 -0700, Brian Weis wrote: >Note that the new ESP and AH drafts are now officially in last call. >These drafts contain a number of changes from RFCs 2402/2406 that make >them more useful when used to protect IP multicast packets. If anyone >has any additional issues, now is the time to speak! > > >From my memory, there was only one change in these latest versions that >affects the multicast case. That was the removal of the "protocol" from >the SPI lookup for multicast packets. (I.e., from {destination, SPI, >protocol} to {destination, SPI} for any source multicast groups). > >The effect of this change seems minor. It slightly increases the >possibility of ambiguous SPI lookups. This should only happen if two key >servers are not choosing SPIs in a coordinated fashion for the same >destination. (E.g., if two applications were using the same destination >address.) But it is still a problem whether or not the protocol field >remains in the SPI lookup, so it does not seem worth arguing about. > >Other than that, I personally didn't have any concerns with the drafts. > >Brian >-- >Brian Weis >Strategic Cryptographic Development, ITD, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.comReturn-Path: >Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) > by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) > with ESMTP id AHM25452; > Tue, 27 May 2003 06:29:02 -0700 (PDT) >Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) > by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h4RDVTNb006377; > Tue, 27 May 2003 06:31:29 -0700 (PDT) >Received: from proxy3.cisco.com (proxy3.cisco.com [128.107.241.181]) > by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id > h4RDUx19003511; > Tue, 27 May 2003 06:31:00 -0700 (PDT) >Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) > by proxy3.cisco.com (8.12.8p1/8.11.2) with ESMTP id h4RDW2Wd011253; > Tue, 27 May 2003 06:32:02 -0700 (PDT) >Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05996 > Tue, 27 May 2003 09:20:40 -0400 (EDT) >Message-Id: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> >X-Sender: byfraser@mira-sjc5-4.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Mon, 26 May 2003 18:45:48 -0700 >To: ipsec@lists.tislabs.com >From: Barbara Fraser >Subject: LAST CALL: ESP and AH ESN drafts >Cc: tytso@mit.edu, byfraser@cisco.com >Mime-Version: 1.0 >Content-Type: multipart/alternative; > boundary="=====================_364919486==_.ALT" >Sender: owner-ipsec@lists.tislabs.com >Precedence: bulk >X-Mozilla-Status2: 00000000 > >This is a working group last call for comments on the following drafts, >for progression to Proposed Standard: > >draft-ietf-ipsec-esp-v3-05.txt >draft-ietf-ipsec-rfc2402bis-03.txt >draft-ietf-ipsec-esn-addendum-01.txt > >These drafts have not received a great amount of attention so Ted and I >would like to urge everyone to take a good look at them. We are extending >the working group last call to 3 weeks to give folks adequate time to >comment. This last call will expire on June 16. > >thanks, >Barb and Ted _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed May 28 16:23:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22024 for ; Wed, 28 May 2003 16:23:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BD189539DB; Wed, 28 May 2003 16:22:41 -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 D22A05375A for ; Wed, 28 May 2003 16:21:25 -0400 (EDT) Received: (qmail 6915 invoked by uid 3269); 28 May 2003 20:21:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6910 invoked from network); 28 May 2003 20:21:25 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 28 May 2003 20:21:25 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h4SKLO53023632 for ; Wed, 28 May 2003 13:21:24 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 May 2003 13:21:24 -0700 Message-ID: <9F4EAC17FAE99D4AB9CB27A54D86AD8B02C2962C@vhqpostal3.verisign.com> From: "Hardjono, Thomas" To: msec@securemulticast.org Subject: RE: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 May 2003 13:21:15 -0700 We've been asking for changes since the SMuG days. So the doc is worth a look. For those who have memorized 2406, here are the key paragraphs/changes that affect multicast: For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). Since the SPI value is generated by the receiver for a unicast SA, whether the value is sufficient to identify an SA by itself, or whether it must be used in conjunction with the IPsec protocol value is a local matter. This mechanism for mapping inbound traffic to unicast SAs MUST be supported by all ESP implementations. If an IPsec implementation supports multicast, then it MUST support multicast SAs using the following algorithm for mapping inbound IPsec datagrams to SAs. (Implementations that support only unicast traffic need not implement this demultiplexing algorithm.) Each entry in the Security Association Database (SAD) [KA98] must indicate whether the SA lookup makes use of the source and destination IP addresses, in addition to the SPI. (For multicast SAs, the protocol field is not employed for SA lookups.) Nominally, this indication can be represented by two bits, one associated with the source IP address and the other for the destination IP address. A "1" value for each bit indicates the need to match against the corresponding address field as part of the SA lookup process. Thus, for example, unicast SAs would have both bits set to zero, since neither the source nor destination IP address is used for SA matching. (Only the SPI, and, optionally, the protocol field are employed.) For multicast methods that rely only on the destination address to specify a multicast group, only the second bit would be set to "1," implying the need to use the destination address plus the SPI to determine the appropriate SA. For multicast methods (e.g., SSM [HC03]) that also require the source address to identify a multicast group, both bits would be set to "1." (There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.) The indication whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE. cheers, thomas ------ > -----Original Message----- > From: Brian Weis [mailto:bew@cisco.com] > Sent: Wednesday, May 28, 2003 11:37 AM > To: msec@securemulticast.org > Subject: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts] > > > Note that the new ESP and AH drafts are now officially in > last call. These drafts contain a number of changes from RFCs > 2402/2406 that make them more useful when used to protect IP > multicast packets. If anyone has any additional issues, now > is the time to speak! > > From my memory, there was only one change in these latest > versions that affects the multicast case. That was the > removal of the "protocol" from the SPI lookup for multicast > packets. (I.e., from {destination, SPI, protocol} to > {destination, SPI} for any source multicast groups). > > The effect of this change seems minor. It slightly increases > the possibility of ambiguous SPI lookups. This should only > happen if two key servers are not choosing SPIs in a > coordinated fashion for the same destination. (E.g., if two > applications were using the same destination > address.) But it is still a problem whether or not the > protocol field remains in the SPI lookup, so it does not seem > worth arguing about. > > Other than that, I personally didn't have any concerns with > the drafts. > > Brian > -- > 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 May 28 17:25:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24999 for ; Wed, 28 May 2003 17:25:24 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 64029539D8; Wed, 28 May 2003 17:24:55 -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 A712E539E2 for ; Wed, 28 May 2003 17:22:10 -0400 (EDT) Received: (qmail 17096 invoked by uid 3269); 28 May 2003 21:22:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17093 invoked from network); 28 May 2003 21:22:10 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by klesh.pair.com with SMTP; 28 May 2003 21:22:10 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4SLLaFW017273; Wed, 28 May 2003 14:21:36 -0700 (PDT) Message-ID: <3ED5285F.7E0C727D@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: Lakshminath Dondeti Cc: msec@securemulticast.org Subject: Re: [MSEC] [Fwd: LAST CALL: ESP and AH ESN drafts] References: <3ED501E1.C3DAB306@cisco.com> <3ED50430.6010406@nortelnetworks.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 (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 28 May 2003 14:21:35 -0700 Content-Transfer-Encoding: 7bit Hi Lakshminath, Lakshminath Dondeti wrote: > > I guess we still need an MESP I-D! I was hoping that there would be one > ESP RFC that will work for both multicast and unicast. We still need a document like MESP to be able to describe how to do source origin authentication, replay protection for multi-sender SAs, and other such topics that are germane only to the multicast usage. The good news is that MESP can be ESP with some additional semantics, rather than a new protocol altogether. The latest version of MESP reflects this goal. Brian > regards, > Lakshminath > > Brian Weis wrote: > > Note that the new ESP and AH drafts are now officially in last call. > > These drafts contain a number of changes from RFCs 2402/2406 that make > > them more useful when used to protect IP multicast packets. If anyone > > has any additional issues, now is the time to speak! > > > >>From my memory, there was only one change in these latest versions that > > affects the multicast case. That was the removal of the "protocol" from > > the SPI lookup for multicast packets. (I.e., from {destination, SPI, > > protocol} to {destination, SPI} for any source multicast groups). > > > > The effect of this change seems minor. It slightly increases the > > possibility of ambiguous SPI lookups. This should only happen if two key > > servers are not choosing SPIs in a coordinated fashion for the same > > destination. (E.g., if two applications were using the same destination > > address.) But it is still a problem whether or not the protocol field > > remains in the SPI lookup, so it does not seem worth arguing about. > > > > Other than that, I personally didn't have any concerns with the drafts. > > > > Brian > > > > > > ------------------------------------------------------------------------ > > > > Subject: > > LAST CALL: ESP and AH ESN drafts > > From: > > Barbara Fraser > > Date: > > Mon, 26 May 2003 18:45:48 -0700 > > To: > > ipsec@lists.tislabs.com > > > > > > This is a working group last call for comments on the following drafts, > > for progression to Proposed Standard: > > > > draft-ietf-ipsec-esp-v3-05.txt > > draft-ietf-ipsec-rfc2402bis-03.txt > > draft-ietf-ipsec-esn-addendum-01.txt > > > > These drafts have not received a great amount of attention so Ted and I > > would like to urge everyone to take a good look at them. We are > > extending the working group last call to 3 weeks to give folks adequate > > time to comment. This last call will expire on June 16. > > > > thanks, > > Barb and Ted -- 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